Changeset 1770 for draft-ietf-httpbis/latest/p1-messaging.html

Timestamp:

Jul 14, 2012, 5:41:41 AM (8 years ago)

Author:

julian.reschke@…

Message:

Make ABNF/conformance terminology consistent (see #362)

File:

• draft-ietf-httpbis/latest/p1-messaging.html (modified) (5 diffs)

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 14, 2013"; 
+       content: "Expires January 15, 2013"; 
   } 
   @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="2012-07-13">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-14">
       <meta name="dct.replaces" content="urn:ietf:rfc:2145">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
@@ -523 +523 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 14, 2013</td>
+               <td class="left">Expires: January 15, 2013</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">July 13, 2012</td>
+               <td class="right">July 14, 2012</td>
             </tr>
          </tbody>
@@ -560 +560 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 14, 2013.</p>
+      <p>This Internet-Draft will expire on January 15, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -965 +965 @@
       <p id="rfc.section.2.6.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
          requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
-         or caches, depending on what behavior is being constrained by the requirement. The verb "generate" is used instead of "send"
-         where a requirement differentiates between creating a protocol element and merely forwarding a received element downstream.
-      </p>
-      <p id="rfc.section.2.6.p.2">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
-         in HTTP.
-      </p>
-      <p id="rfc.section.2.6.p.3">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
+         or caches, depending on what behavior is being constrained by the requirement.
+      </p>
+      <p id="rfc.section.2.6.p.2">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
+         forwarding a received element downstream.
+      </p>
+      <p id="rfc.section.2.6.p.3">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
+         in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
+      </p>
+      <p id="rfc.section.2.6.p.4">In addition to the prose requirements placed upon them, senders <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.6.p.4">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.6.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
          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