* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #271 (closed editorial: incorporated)

Opened 4 years ago

Last modified 12 months ago

Review SHOULD-level requirements

Reported by: mnot@pobox.com Owned by: mnot@mnot.net
Priority: normal Milestone: 24
Component: non-specific Severity: Active WG Document
Keywords: Cc:
Origin:

Description

We need to audit the SHOULDs and make sure that they are in the spirit of 2119; i.e., things that need a good reason to break. Ideally, we should list the reasons.

This may spawn some design tickets.

Attachments

271-p7.diff (2.7 KB) - added by julian.reschke@gmx.de 2 years ago.
Proposed patch for Part 7

Change History

comment:1 follow-up: ↓ 2 Changed 3 years ago by mnot@pobox.com

Rough proposal: replace "Requirements" sections with following.

Conformance and Error Handling

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See [ref to Terminology] for a definition of each.

An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.

This document also uses ABNF to define valid protocol elements. In addition to the prose requirements placed upon them, Senders MUST NOT generate protocol elements that are invalid.

Unless noted otherwise, Recipients MAY take steps to recover a usable protocol element from an invalid construct, and SHOULD NOT reject the message outright.

However, HTTP does not define specific error handling mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the Content-Type header doesn't match the body, whereby in a systems control protocol using HTTP, this type of error recovery could lead to dangerous consequences.

comment:2 in reply to: ↑ 1 Changed 3 years ago by mnot@pobox.com

Replying to mnot@…:

Oops, wrong ticket; nothing to see here.

comment:3 Changed 2 years ago by mnot@pobox.com

Reviews for p4-p7 done.

Changed 2 years ago by julian.reschke@gmx.de

Proposed patch for Part 7

comment:4 Changed 2 years ago by julian.reschke@gmx.de

From [1691]:

tune conformance requirements (see #271)

comment:5 Changed 2 years ago by julian.reschke@gmx.de

From [1694]:

tune conformance language (see #271)

comment:6 Changed 2 years ago by julian.reschke@gmx.de

From [1707]:

tune conformance requirements (see #271)

comment:7 Changed 12 months ago by fielding@gbiv.com

  • Status changed from new to closed
  • Resolution set to incorporated
  • Milestone changed from unassigned to 24
Note: See TracTickets for help on using tickets.