Changeset 2332

Timestamp:

31/07/13 17:43:09 (9 years ago)

Author:

fielding@…

Message:

Explain in more detail the conformance requirements related to specific roles, recipients, and workarounds; addresses #484

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (5 diffs)
• p1-messaging.xml (modified) (2 diffs)

draft-ietf-httpbis/latest/p1-messaging.html

@@ -449 +449 @@
   }
   @bottom-center {
-       content: "Expires January 29, 2014";
+       content: "Expires February 1, 2014";
   }
   @bottom-right {
@@ -491 +491 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2013-07-28">
+      <meta name="dct.issued" scheme="ISO8601" content="2013-07-31">
       <meta name="dct.replaces" content="urn:ietf:rfc:2145">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
@@ -520 +520 @@
             <tr>
                <td class="left">Intended status: Standards Track</td>
-               <td class="right">July 28, 2013</td>
+               <td class="right">July 31, 2013</td>
             </tr>
             <tr>
-               <td class="left">Expires: January 29, 2014</td>
+               <td class="left">Expires: February 1, 2014</td>
                <td class="right"></td>
             </tr>
@@ -551 +551 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 29, 2014.</p>
+      <p>This Internet-Draft will expire on February 1, 2014.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -955 +955 @@
          in HTTP.
       </p>
-      <p id="rfc.section.2.5.p.4">Conformance applies to both the syntax and semantics of HTTP protocol elements. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that convey a meaning that is known by that sender to be false. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements that are applicable
-         to the sender's role. If a received protocol element is processed, the recipient <em class="bcp14">MUST</em> be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable
-         to the recipient's role.
-      </p>
-      <p id="rfc.section.2.5.p.5">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms
+      <p id="rfc.section.2.5.p.4">Conformance includes both the syntax and semantics of HTTP protocol elements. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that convey a meaning that is known by that sender to be false. A sender <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the corresponding ABNF rules. Within a given message,
+         a sender <em class="bcp14">MUST NOT</em> generate protocol elements or syntax alternatives that are only allowed to be generated by participants in other roles (i.e.,
+         a role that the sender does not have for that message).
+      </p>
+      <p id="rfc.section.2.5.p.5">When a received protocol element is parsed, the recipient <em class="bcp14">MUST</em> be able to parse any value of reasonable length that is applicable to the recipient's role and matches the grammar defined
+         by the corresponding ABNF rules. Note, however, that some received protocol elements might not be parsed. For example, an
+         intermediary forwarding a message might parse a header-field into generic field-name and field-value components, but then
+         forward the header field without further parsing inside the field-value.
+      </p>
+      <p id="rfc.section.2.5.p.6">HTTP does not have specific length limitations for many of its protocol elements because the lengths that might be appropriate
+         will vary widely, depending on the deployment context and purpose of the implementation. Hence, interoperability between senders
+         and recipients depends on shared expectations regarding what is a reasonable length for each protocol element. Furthermore,
+         what is commonly understood to be a reasonable length for some protocol elements has changed over the course of the past two
+         decades of HTTP use, and is expected to continue changing in the future.
+      </p>
+      <p id="rfc.section.2.5.p.7">At a minimum, a recipient <em class="bcp14">MUST</em> be able to parse and process protocol element lengths that are at least as long as the values that it generates for those
+         same protocol elements in other messages. For example, an origin server that publishes very long URI references to its own
+         resources needs to be able to parse and process those same references when received as a request target.
+      </p>
+      <p id="rfc.section.2.5.p.8">A recipient <em class="bcp14">MUST</em> interpret a received protocol element according to the semantics defined for it by this specification, including extensions
+         to this specification, unless the recipient has determined (through experience or configuration) that the sender incorrectly
+         implements what is implied by those semantics. For example, an origin server might disregard the contents of a received <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> header field if inspection of the <a href="p2-semantics.html#header.user-agent" class="smpl">User-Agent</a> header field indicates a specific implementation version that is known to fail on receipt of certain content codings.
+      </p>
+      <p id="rfc.section.2.5.p.9">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms
          except when they have a direct impact on security, since different applications of the protocol require different error handling
          strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery

draft-ietf-httpbis/latest/p1-messaging.xml

@@ -620 +620 @@
 </t>
 <t>
-   Conformance applies to both the syntax and semantics of HTTP protocol
+   Conformance includes both the syntax and semantics of HTTP protocol
    elements. A sender &MUST-NOT; generate protocol elements that convey a
    meaning that is known by that sender to be false. A sender &MUST-NOT;
    generate protocol elements that do not match the grammar defined by the
-   ABNF rules for those protocol elements that are applicable to the sender's
-   role. If a received protocol element is processed, the recipient &MUST; be
-   able to parse any value that would match the ABNF rules for that protocol
-   element, excluding only those rules not applicable to the recipient's role.
+   corresponding ABNF rules. Within a given message, a sender &MUST-NOT;
+   generate protocol elements or syntax alternatives that are only allowed to
+   be generated by participants in other roles (i.e., a role that the sender
+   does not have for that message).
+</t>
+<t>
+   When a received protocol element is parsed, the recipient &MUST; be able to
+   parse any value of reasonable length that is applicable to the recipient's
+   role and matches the grammar defined by the corresponding ABNF rules.
+   Note, however, that some received protocol elements might not be parsed.
+   For example, an intermediary forwarding a message might parse a
+   header-field into generic field-name and field-value components, but then
+   forward the header field without further parsing inside the field-value.
+</t>
+<t>
+   HTTP does not have specific length limitations for many of its protocol
+   elements because the lengths that might be appropriate will vary widely,
+   depending on the deployment context and purpose of the implementation.
+   Hence, interoperability between senders and recipients depends on shared
+   expectations regarding what is a reasonable length for each protocol
+   element. Furthermore, what is commonly understood to be a reasonable length
+   for some protocol elements has changed over the course of the past two
+   decades of HTTP use, and is expected to continue changing in the future.
+</t>
+<t>
+   At a minimum, a recipient &MUST; be able to parse and process protocol
+   element lengths that are at least as long as the values that it generates
+   for those same protocol elements in other messages. For example, an origin
+   server that publishes very long URI references to its own resources needs
+   to be able to parse and process those same references when received as a
+   request target.
+</t>
+<t>
+   A recipient &MUST; interpret a received protocol element according to the
+   semantics defined for it by this specification, including extensions to
+   this specification, unless the recipient has determined (through experience
+   or configuration) that the sender incorrectly implements what is implied by
+   those semantics.
+   For example, an origin server might disregard the contents of a received
+   <x:ref>Accept-Encoding</x:ref> header field if inspection of the
+   <x:ref>User-Agent</x:ref> header field indicates a specific implementation
+   version that is known to fail on receipt of certain content codings.
 </t>
 <t>
@@ -4088 +4126 @@
     <x:defines>502 (Bad Gateway)</x:defines>
     <x:defines>505 (HTTP Version Not Supported)</x:defines>
+    <x:defines>Accept-Encoding</x:defines>
     <x:defines>Allow</x:defines>
     <x:defines>Content-Encoding</x:defines>