Changeset 1043


Ignore:
Timestamp:
Oct 21, 2010, 7:18:34 PM (9 years ago)
Author:
mnot@…
Message:

Remove RFC2119 from status code considerations; for #229.

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1042 r1043  
    905905         and currently defined status codes are inadequate, a new status code can be registered.
    906906      </p>
    907       <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).
    908       </p>
    909       <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).
    910       </p>
    911       <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
    912          method(s)), they <em class="bcp14">SHOULD</em> be described in detail.
    913       </p>
    914       <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
    915          are not specific to that application or extension.
     907      <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,
     908         "type" of resource, or application. As such, it is preferred that new HTTP status codes be registered in a document that isn't
     909         specific to a single application, so that this is clear.
     910      </p>
     911      <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
     912         code (e.g., combinations of request headers and/or method(s)), along with any interactions with response headers (e.g., those
     913         that are required, those that modify the semantics of the response).
     914      </p>
     915      <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
     916         a zero-length response body. They can require the presence of one or more particular HTTP response header(s).
     917      </p>
     918      <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).
    916919      </p>
    917920      <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>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1042 r1043  
    660660</t>
    661661<t>
    662    New HTTP status codes &MUST; be defined in one of the categories defined
    663    in <xref target="status.codes"/>. They &MUST-NOT; disallow a response body,
    664    although they &MAY; mandate a zero-length response body. They &MAY; require
    665    the presence of one or more particular HTTP response header(s).
    666 </t>
    667 <t>
    668    Likewise, their definitions &MAY; specify that caches are allowed to use
     662   HTTP status codes are generic; that is, they are potentially applicable to
     663   any resource, not just one particular media type, "type" of resource, or
     664   application. As such, it is preferred that new HTTP status codes be
     665   registered in a document that isn't specific to a single application, so
     666   that this is clear.
     667</t>
     668<t>
     669   Definitions of new HTTP status codes typically explain the request
     670   conditions that produce a response containing the status code (e.g.,
     671   combinations of request headers and/or method(s)), along with any
     672   interactions with response headers (e.g., those that are required, those
     673   that modify the semantics of the response).
     674</t>
     675<t>
     676   New HTTP status codes are required to fall under one of the categories
     677   defined in <xref target="status.codes"/>. To allow existing parsers to
     678   properly handle them, new status codes cannot disallow a response body,
     679   although they can mandate a zero-length response body. They can require the
     680   presence of one or more particular HTTP response header(s).
     681</t>
     682<t>
     683   Likewise, their definitions can specify that caches are allowed to use
    669684   heuristics to determine their freshness (see &caching;; by default, it is
    670    not allowed), and &MAY; define how to determine the resource which they
     685   not allowed), and can define how to determine the resource which they
    671686   carry a representation for (see <xref
    672687   target="identifying.response.associated.with.representation"/>; by default,
    673688   it is anonymous).
    674 </t>
    675 <t>
    676    If there are particular request conditions that produce a response
    677    containing the status code (e.g., request headers and/or method(s)), they
    678    &SHOULD; be described in detail.
    679 </t>
    680 <t>
    681    New HTTP status codes &SHOULD; be registered in a document that isn't
    682    specific to a single application or other use of HTTP, so that it's clear that
    683    they are not specific to that application or extension.
    684689</t>
    685690</section>
Note: See TracChangeset for help on using the changeset viewer.