Changeset 2013 for draft-ietf-httpbis/latest/p2-semantics.xml

Timestamp:

29/11/12 00:49:18 (9 years ago)

Author:

mnot@…

Message:

Clean up Changes from RFC2616; partially addresses #419.

File:

• draft-ietf-httpbis/latest/p2-semantics.xml (modified) (3 diffs)

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

@@ -5652 +5652 @@
 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
 <t>
-  Remove base URI setting semantics for "<x:ref>Content-Location</x:ref>" due to
-  poor implementation support (which was caused by too many broken servers emitting
-  bogus Content-Location header fields, and also the potentially undesirable effect
-  of potentially breaking relative links in content-negotiated resources).
+  <x:ref>Content-Location</x:ref> no longer sets a base URI, due to poor
+  implementation support (which was caused by too many broken servers emitting
+  bogus Content-Location header fields, and also the potentially undesirable
+  effect of potentially breaking relative links in content-negotiated
+  resources).
   (<xref target="header.content-location"/>)
 </t>
 <t>
-  Clarify definition of POST.
+  The definition of POST has been clarified.
   (<xref target="POST"/>)
 </t>
 <t>
-  Remove requirement to handle all Content-* header fields; ban use of
-  <x:ref>Content-Range</x:ref> with PUT.
+  Servers are no longer required to handle all Content-* header fields in 
+  requests.
   (<xref target="PUT"/>)
 </t>
 <t>
-  Take over definition of CONNECT method from <xref target="RFC2817"/>.
+  Use of <x:ref>Content-Range</x:ref> is explicitly banned on PUT requests.
+  (<xref target="PUT"/>)
+</t>
+<t>
+  The CONNECT method is now defined by this specification, taking over from
+  <xref target="RFC2817"/>.
   (<xref target="CONNECT"/>)
 </t>
 <t>
-  Restrict "<x:ref>Max-Forwards</x:ref>" header field to OPTIONS and TRACE
-  (previously, extension methods could have used it as well).
+  The "<x:ref>Max-Forwards</x:ref>" header field is now restricted to the
+  OPTIONS and TRACE methods (previously, extension methods could have used it
+  as well).
   (<xref target="header.max-forwards"/>)
 </t>
@@ -5684 +5691 @@
 </t>
 <t>
-  Remove ISO-8859-1 special-casing in <x:ref>Accept-Charset</x:ref>.
+  Special casing for ISO-8859-1 in <x:ref>Accept-Charset</x:ref> has been
+  removed.
   (<xref target="header.accept-charset"/>)
 </t>
 <t>
-  Allow "<x:ref>Referer</x:ref>" field value of "about:blank" as alternative to
-  not specifying it. 
+  "<x:ref>Referer</x:ref>" can now hoave a field value of "about:blank" as an
+  alternative to not sending a Referer header field.
   (<xref target="header.referer"/>)
 </t>
 <t>
-  Broadened the definition of <x:ref>203 (Non-Authoritative Information)</x:ref>
-  to include cases of payload transformations as well.
+  The definition of <x:ref>203 (Non-Authoritative Information)</x:ref> has
+  been broadened to include cases of payload transformations as well.
   (<xref target="status.203"/>)
 </t>
 <t>
-  Status codes <x:ref>301</x:ref>, <x:ref>302</x:ref>, and <x:ref>307</x:ref>:
-  removed the normative requirements on both response payloads and user interaction.
+  Redirect status codes <x:ref>301</x:ref>, <x:ref>302</x:ref>, and
+  <x:ref>307</x:ref> no longer have normative requirements on response
+  payloads and user interaction.
   (<xref target="status.3xx"/>)
 </t>
 <t>
-  Failed to consider that there are many other request methods that are safe
-  to automatically redirect, and further that the user agent is able to make
-  that determination based on the request method semantics.
-  Furthermore, allow user agents to rewrite the method from POST to GET
+  The request methods that are safe to automatically redirect is no
+  longer a closed set; user agents are able to make that determination
+  based upon the request method semantics.
+  (<xref target="status.3xx"/>)
+</t>
+<t>
+  User agents are now allowed to rewrite the method from POST to GET
   for status codes <x:ref>301</x:ref> and <x:ref>302</x:ref>.
   (Sections <xref format="counter" target="status.301"/>,
@@ -5713 +5725 @@
 </t>
 <t>
-  Deprecate <x:ref>305 (Use Proxy)</x:ref> status code, because user agents did
-  not implement it. It used to indicate that the target resource needs to be
-  accessed through the proxy given by the <x:ref>Location</x:ref> field. The
-  Location field gave the URI of the proxy. The recipient was expected to
-  repeat this single request via the proxy.
+  The <x:ref>305 (Use Proxy)</x:ref> status code is now deprecated, because
+  user agents did not implement it. It used to indicate that the target
+  resource needed to be accessed through the proxy given by the
+  <x:ref>Location</x:ref> field. The recipient was expected to repeat this
+  single request via the proxy.
   (<xref target="status.305"/>)
 </t>
 <t>
-  Define status <x:ref>426 (Upgrade Required)</x:ref> (this was incorporated
-  from <xref target="RFC2817"/>).
+  The <x:ref>426 (Upgrade Required)</x:ref> status code has been incorporated
+  from <xref target="RFC2817"/>.
   (<xref target="status.426"/>)
 </t>
 <t>
-  Correct syntax of "<x:ref>Location</x:ref>" header field to allow URI
-  references (including relative references and fragments), as referred symbol
-  "absoluteURI" wasn't what was expected, and add some clarifications as to
-  when use of fragments would not be appropriate.
+  The syntax of the <x:ref>Location</x:ref> header field has been corrected
+  to allow URI references (including relative references and fragments), along
+  with some clarifications as to when use of fragments would not be
+  appropriate.
   (<xref target="header.location"/>)
 </t>
 <t>
-  Reclassify "<x:ref>Allow</x:ref>" as response header field, removing the
-  option to specify it in a PUT request.
-  Relax the server requirement on the contents of the Allow header field and
-  remove requirement on clients to always trust the header field value.
+  <x:ref>Allow</x:ref> has been reclassified as a response header field,
+  removing the option to specify it in a PUT request.
   (<xref target="header.allow"/>)
-</t>
-<t>
-  In the description of the "<x:ref>Server</x:ref>" header field, the
-  "<x:ref>Via</x:ref>" field was described as a SHOULD. The requirement was and
-  is stated correctly in the description of the Via header field in
+</t>  
+<t>  
+  Requirements relating to the content of the Allow header have been relaxed;
+  correspondingly, clients are not required to always trust its value.
+  (<xref target="header.allow"/>)
+</t>
+<t>
+  The requirement to produce a <x:ref>Via</x:ref> header field has been moved
+  from the description of the <x:ref>Server</x:ref> header field to
   &header-via;.
   (<xref target="header.server"/>)
 </t>
 <t>
-  Clarify contexts that charset is used in.
+  The contexts that charset is used in have been clarified.
   (<xref target="charset"/>)
 </t>
 <t>
-  Remove the default charset of "ISO-8859-1" for text media
-  types; the default now is whatever the media type definition says.
+  The default charset of "ISO-8859-1" for text media types has been removed;
+  the default now is whatever the media type definition says.
   (<xref target="canonicalization.and.text.defaults"/>)
 </t>
 <t>
-  Registration of Content Codings now requires IETF Review
+  Registration of Content Codings now requires IETF Review.
   (<xref target="content.coding.registry"/>)
 </t>
 <t>
-  Remove definition of "Content-MD5 header" field because it was inconsistently
+  The Content-MD5 header field has been removed, because it was inconsistently
   implemented with respect to partial responses, and also because of known
-  deficiencies in the hash algorithm itself (see <xref target="RFC6151"/> for details).
-</t>
-<t>
-  Introduce Method Registry.
+  deficiencies in the hash algorithm itself (see <xref target="RFC6151"/> for
+  details).
+</t>
+<t>
+  This specification introduces a Method Registry.
   (<xref target="method.registry"/>)
 </t>
 <t>
-  Take over the Status Code Registry, previously defined in
-  <xref target="RFC2817" x:fmt="of" x:sec="7.1"/>.
+  The Status Code Registry is now defined by this specification; previously,
+  it was defined in <xref target="RFC2817" x:fmt="of" x:sec="7.1"/>.
   (<xref target="status.code.registry"/>)
 </t>
 <t>
-  Remove reference to non-existant identity transfer-coding value tokens.
+  References to the "identity" transfer-coding value token have been removed.
   (<xref target="no.content-transfer-encoding"/>)
 </t>
 <t>
-  Remove discussion of Content-Disposition header field, it is now defined
-  by <xref target="RFC6266"/>.
+  The Content-Disposition header field is now defined by <xref
+  target="RFC6266"/>.
   (<xref target="additional.features"/>)
 </t>