Changeset 1043 for draft-ietf-httpbis/latest/p2-semantics.html

Timestamp:

Oct 21, 2010, 7:18:34 PM (9 years ago)

Author:

mnot@…

Message:

Remove RFC2119 from status code considerations; for #229.

File:

• draft-ietf-httpbis/latest/p2-semantics.html (modified) (1 diff)

draft-ietf-httpbis/latest/p2-semantics.html

@@ -905 +905 @@
          and currently defined status codes are inadequate, a new status code can be registered.
       </p>
-      <p id="rfc.section.4.1.1.p.2">New HTTP status codes <em class="bcp14">MUST</em> be defined in one of the categories defined in <a href="#status.codes" title="Status Code Definitions">Section&nbsp;8</a>. They <em class="bcp14">MUST NOT</em> disallow a response body, although they <em class="bcp14">MAY</em> mandate a zero-length response body. They <em class="bcp14">MAY</em> require the presence of one or more particular HTTP response header(s).
-      </p>
-      <p id="rfc.section.4.1.1.p.3">Likewise, their definitions <em class="bcp14">MAY</em> specify that caches are allowed to use heuristics to determine their freshness (see <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>; by default, it is not allowed), and <em class="bcp14">MAY</em> define how to determine the resource which they carry a representation for (see <a href="#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section&nbsp;6.1</a>; by default, it is anonymous).
-      </p>
-      <p id="rfc.section.4.1.1.p.4">If there are particular request conditions that produce a response containing the status code (e.g., request headers and/or
-         method(s)), they <em class="bcp14">SHOULD</em> be described in detail.
-      </p>
-      <p id="rfc.section.4.1.1.p.5">New HTTP status codes <em class="bcp14">SHOULD</em> be registered in a document that isn't specific to a single application or other use of HTTP, so that it's clear that they
-         are not specific to that application or extension.
+      <p id="rfc.section.4.1.1.p.2">HTTP status codes are generic; that is, they are potentially applicable to any resource, not just one particular media type,
+         "type" of resource, or application. As such, it is preferred that new HTTP status codes be registered in a document that isn't
+         specific to a single application, so that this is clear.
+      </p>
+      <p id="rfc.section.4.1.1.p.3">Definitions of new HTTP status codes typically explain the request conditions that produce a response containing the status
+         code (e.g., combinations of request headers and/or method(s)), along with any interactions with response headers (e.g., those
+         that are required, those that modify the semantics of the response).
+      </p>
+      <p id="rfc.section.4.1.1.p.4">New HTTP status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Status Code Definitions">Section&nbsp;8</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a response body, although they can mandate
+         a zero-length response body. They can require the presence of one or more particular HTTP response header(s).
+      </p>
+      <p id="rfc.section.4.1.1.p.5">Likewise, their definitions can specify that caches are allowed to use heuristics to determine their freshness (see <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>; by default, it is not allowed), and can define how to determine the resource which they carry a representation for (see <a href="#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section&nbsp;6.1</a>; by default, it is anonymous).
       </p>
       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1>