Changeset 1770 for draft-ietf-httpbis/latest

Timestamp:

14/07/12 12:41:41 (10 years ago)

Author:

julian.reschke@…

Message:

Make ABNF/conformance terminology consistent (see #362)

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (5 diffs)
• p1-messaging.xml (modified) (2 diffs)
• p2-semantics.html (modified) (1 diff)
• p2-semantics.xml (modified) (1 diff)
• p4-conditional.html (modified) (6 diffs)
• p4-conditional.xml (modified) (1 diff)
• p5-range.html (modified) (6 diffs)
• p5-range.xml (modified) (1 diff)
• p6-cache.html (modified) (1 diff)
• p6-cache.xml (modified) (1 diff)
• p7-auth.html (modified) (5 diffs)
• p7-auth.xml (modified) (1 diff)

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

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

@@ -629 +629 @@
    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.
+   is being constrained by the requirement.
+</t>
+<t>
+   The verb "generate" is used instead of "send" where a requirement
+   differentiates between creating a protocol element and merely forwarding a
+   received element downstream.
 </t>
 <t>
    An implementation is considered conformant if it complies with all of the
-   requirements associated with the roles it partakes in HTTP.
-</t>
-<t>
-   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
+   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.
+</t>
+<t>
+   In addition to the prose requirements placed upon them, senders &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.
 </t>
@@ -651 +656 @@
    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 <x:ref>Location</x:ref>
-   header field doesn't parse according to the ABNF, whereas a systems control
-   client might consider any form of error recovery to be dangerous.
+   wish to transparently recover from a response where the
+   <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
+   whereas a systems control client might consider any form of error recovery
+   to be dangerous.
 </t>
 </section>

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

@@ -846 +846 @@
          in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
       </p>
-      <p id="rfc.section.1.2.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
-         Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
-      </p>
-      <p id="rfc.section.1.2.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that
-         SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
-      </p>
-      <p id="rfc.section.1.2.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.3</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid.
-      </p>
-      <p id="rfc.section.1.2.p.5">Unless noted otherwise, Recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling
-         mechanisms, except in cases where it has direct impact on security. This is because different uses 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="#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery
-         could lead to dangerous consequences.
+      <p id="rfc.section.1.2.p.2">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. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
+      </p>
+      <p id="rfc.section.1.2.p.3">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.1.2.p.4">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.1.2.p.5">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.3</a>). 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.1.2.p.6">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="#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
+         to be dangerous.
       </p>
       <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>

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

@@ -283 +283 @@
 </t>
 <t>
-   This document defines conformance criteria for several roles in HTTP
-   communication, including Senders, Recipients, Clients, Servers, User-Agents,
-   Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
-   for definitions of these terms.
+   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. See &architecture; for definitions
+   of these terms.
+</t>
+<t>
+   The verb "generate" is used instead of "send" where a requirement
+   differentiates between creating a protocol element and merely forwarding a
+   received element downstream.
 </t>
 <t>
    An implementation is considered conformant if it complies with all of the
-   requirements associated with its role(s). Note that SHOULD-level requirements
-   are relevant here, unless one of the documented exceptions is applicable.
+   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.
 </t>
 <t>
    This document also uses ABNF to define valid protocol elements
-   (<xref target="notation"/>). In addition to the prose requirements placed
-   upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
-</t>
-<t>
-   Unless noted otherwise, Recipients &MUST; be able to parse all protocol
-   elements matching the ABNF rules defined for them and &MAY; take steps to
-   recover a usable protocol element from an invalid construct. However, HTTP does not define
-   specific error handling mechanisms, except in cases where it has direct
-   impact on security. This is because different uses of the protocol require
-   different error handling strategies; for example, a Web browser might wish to
-   transparently recover from a response where the <x:ref>Location</x:ref>
-   header field doesn't parse according to the ABNF, whereby in a systems
-   control protocol using HTTP, this type of error recovery could lead to
-   dangerous consequences.
+   (<xref target="notation"/>).
+   In addition to the prose requirements placed upon them, senders &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.
+</t>
+<t>
+   Unless noted otherwise, a recipient &MAY; 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
+   <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
+   whereas a systems control client might consider any form of error recovery
+   to be dangerous.
 </t>
 </section>

draft-ietf-httpbis/latest/p4-conditional.html

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 14, 2013"; 
+       content: "Expires January 15, 2013"; 
   } 
   @bottom-right {
@@ -490 +490 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-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:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
@@ -516 +516 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 14, 2013</td>
+               <td class="left">Expires: January 15, 2013</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -525 +525 @@
             <tr>
                <td class="left"></td>
-               <td class="right">July 13, 2012</td>
+               <td class="right">July 14, 2012</td>
             </tr>
          </tbody>
@@ -554 +554 @@
          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>
@@ -649 +649 @@
          in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
       </p>
-      <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
-         Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
-      </p>
-      <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that
-         SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
-      </p>
-      <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid.
-      </p>
-      <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling
-         mechanisms, except in cases where it has direct impact on security. This is because different uses 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, whereby in a systems control protocol using HTTP, this type of error recovery
-         could lead to dangerous consequences.
+      <p id="rfc.section.1.1.p.2">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. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
+      </p>
+      <p id="rfc.section.1.1.p.3">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.1.1.p.4">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.1.1.p.5">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</a>). 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.1.1.p.6">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
+         to be dangerous.
       </p>
       <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>

draft-ietf-httpbis/latest/p4-conditional.xml

@@ -175 +175 @@
 </t>
 <t>
-   This document defines conformance criteria for several roles in HTTP
-   communication, including Senders, Recipients, Clients, Servers, User-Agents,
-   Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
-   for definitions of these terms.
+   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. See &architecture; for definitions
+   of these terms.
+</t>
+<t>
+   The verb "generate" is used instead of "send" where a requirement
+   differentiates between creating a protocol element and merely forwarding a
+   received element downstream.
 </t>
 <t>
    An implementation is considered conformant if it complies with all of the
-   requirements associated with its role(s). Note that SHOULD-level requirements
-   are relevant here, unless one of the documented exceptions is applicable.
+   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.
 </t>
 <t>
    This document also uses ABNF to define valid protocol elements
-   (<xref target="notation"/>). In addition to the prose requirements placed
-   upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
-</t>
-<t>
-   Unless noted otherwise, Recipients &MUST; be able to parse all protocol
-   elements matching the ABNF rules defined for them and &MAY; take steps to
-   recover a usable protocol element from an invalid construct. However, HTTP does not define
-   specific error handling mechanisms, except in cases where it has direct
-   impact on security. This is because different uses of the protocol require
-   different error handling strategies; for example, a Web browser might wish to
-   transparently recover from a response where the <x:ref>Location</x:ref>
-   header field doesn't parse according to the ABNF, whereby in a systems
-   control protocol using HTTP, this type of error recovery could lead to
-   dangerous consequences.
+   (<xref target="notation"/>).
+   In addition to the prose requirements placed upon them, senders &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.
+</t>
+<t>
+   Unless noted otherwise, a recipient &MAY; 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
+   <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
+   whereas a systems control client might consider any form of error recovery
+   to be dangerous.
 </t>
 </section>

draft-ietf-httpbis/latest/p5-range.html

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 14, 2013"; 
+       content: "Expires January 15, 2013"; 
   } 
   @bottom-right {
@@ -492 +492 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-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:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range requests and the rules for constructing and combining responses to those requests.">
@@ -518 +518 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 14, 2013</td>
+               <td class="left">Expires: January 15, 2013</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -527 +527 @@
             <tr>
                <td class="left"></td>
-               <td class="right">July 13, 2012</td>
+               <td class="right">July 14, 2012</td>
             </tr>
          </tbody>
@@ -554 +554 @@
          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>
@@ -671 +671 @@
          in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
       </p>
-      <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
-         Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
-      </p>
-      <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that
-         SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
-      </p>
-      <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid.
-      </p>
-      <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling
-         mechanisms, except in cases where it has direct impact on security. This is because different uses 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, whereby in a systems control protocol using HTTP, this type of error recovery
-         could lead to dangerous consequences.
+      <p id="rfc.section.1.1.p.2">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. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
+      </p>
+      <p id="rfc.section.1.1.p.3">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.1.1.p.4">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.1.1.p.5">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</a>). 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.1.1.p.6">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
+         to be dangerous.
       </p>
       <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>

draft-ietf-httpbis/latest/p5-range.xml

@@ -165 +165 @@
 </t>
 <t>
-   This document defines conformance criteria for several roles in HTTP
-   communication, including Senders, Recipients, Clients, Servers, User-Agents,
-   Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
-   for definitions of these terms.
+   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. See &architecture; for definitions
+   of these terms.
+</t>
+<t>
+   The verb "generate" is used instead of "send" where a requirement
+   differentiates between creating a protocol element and merely forwarding a
+   received element downstream.
 </t>
 <t>
    An implementation is considered conformant if it complies with all of the
-   requirements associated with its role(s). Note that SHOULD-level requirements
-   are relevant here, unless one of the documented exceptions is applicable.
+   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.
 </t>
 <t>
    This document also uses ABNF to define valid protocol elements
-   (<xref target="notation"/>). In addition to the prose requirements placed
-   upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
-</t>
-<t>
-   Unless noted otherwise, Recipients &MUST; be able to parse all protocol
-   elements matching the ABNF rules defined for them and &MAY; take steps to
-   recover a usable protocol element from an invalid construct. However, HTTP does not define
-   specific error handling mechanisms, except in cases where it has direct
-   impact on security. This is because different uses of the protocol require
-   different error handling strategies; for example, a Web browser might wish to
-   transparently recover from a response where the <x:ref>Location</x:ref>
-   header field doesn't parse according to the ABNF, whereby in a systems
-   control protocol using HTTP, this type of error recovery could lead to
-   dangerous consequences.
+   (<xref target="notation"/>).
+   In addition to the prose requirements placed upon them, senders &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.
+</t>
+<t>
+   Unless noted otherwise, a recipient &MAY; 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
+   <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
+   whereas a systems control client might consider any form of error recovery
+   to be dangerous.
 </t>
 </section>

draft-ietf-httpbis/latest/p6-cache.html

@@ -787 +787 @@
          in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
       </p>
-      <p id="rfc.section.1.3.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
-         Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
-      </p>
-      <p id="rfc.section.1.3.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that
-         SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
-      </p>
-      <p id="rfc.section.1.3.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.4</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid.
-      </p>
-      <p id="rfc.section.1.3.p.5">Unless noted otherwise, Recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling
-         mechanisms, except in cases where it has direct impact on security. This is because different uses 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, whereby in a systems control protocol using HTTP, this type of error recovery
-         could lead to dangerous consequences.
+      <p id="rfc.section.1.3.p.2">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. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
+      </p>
+      <p id="rfc.section.1.3.p.3">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.1.3.p.4">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.1.3.p.5">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.4</a>). 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.1.3.p.6">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
+         to be dangerous.
       </p>
       <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>

draft-ietf-httpbis/latest/p6-cache.xml

@@ -310 +310 @@
 </t>
 <t>
-   This document defines conformance criteria for several roles in HTTP
-   communication, including Senders, Recipients, Clients, Servers, User-Agents,
-   Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
-   for definitions of these terms.
+   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. See &architecture; for definitions
+   of these terms.
+</t>
+<t>
+   The verb "generate" is used instead of "send" where a requirement
+   differentiates between creating a protocol element and merely forwarding a
+   received element downstream.
 </t>
 <t>
    An implementation is considered conformant if it complies with all of the
-   requirements associated with its role(s). Note that SHOULD-level requirements
-   are relevant here, unless one of the documented exceptions is applicable.
+   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.
 </t>
 <t>
    This document also uses ABNF to define valid protocol elements
-   (<xref target="notation"/>). In addition to the prose requirements placed
-   upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
-</t>
-<t>
-   Unless noted otherwise, Recipients &MUST; be able to parse all protocol
-   elements matching the ABNF rules defined for them and &MAY; take steps to
-   recover a usable protocol element from an invalid construct. However, HTTP does not define
-   specific error handling mechanisms, except in cases where it has direct
-   impact on security. This is because different uses of the protocol require
-   different error handling strategies; for example, a Web browser might wish to
-   transparently recover from a response where the <x:ref>Location</x:ref>
-   header field doesn't parse according to the ABNF, whereby in a systems
-   control protocol using HTTP, this type of error recovery could lead to
-   dangerous consequences.
+   (<xref target="notation"/>).
+   In addition to the prose requirements placed upon them, senders &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.
+</t>
+<t>
+   Unless noted otherwise, a recipient &MAY; 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
+   <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
+   whereas a systems control client might consider any form of error recovery
+   to be dangerous.
 </t>
 </section>

draft-ietf-httpbis/latest/p7-auth.html

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 14, 2013"; 
+       content: "Expires January 15, 2013"; 
   } 
   @bottom-right {
@@ -489 +489 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-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:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework.">
@@ -520 +520 @@
             </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>
@@ -552 +552 @@
          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>
@@ -636 +636 @@
          in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
       </p>
-      <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
-         Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
-      </p>
-      <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that
-         SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
-      </p>
-      <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid.
-      </p>
-      <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling
-         mechanisms, except in cases where it has direct impact on security. This is because different uses 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, whereby in a systems control protocol using HTTP, this type of error recovery
-         could lead to dangerous consequences.
+      <p id="rfc.section.1.1.p.2">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. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
+      </p>
+      <p id="rfc.section.1.1.p.3">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.1.1.p.4">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.1.1.p.5">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</a>). 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.1.1.p.6">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
+         to be dangerous.
       </p>
       <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>

draft-ietf-httpbis/latest/p7-auth.xml

@@ -151 +151 @@
 </t>
 <t>
-   This document defines conformance criteria for several roles in HTTP
-   communication, including Senders, Recipients, Clients, Servers, User-Agents,
-   Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
-   for definitions of these terms.
+   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. See &architecture; for definitions
+   of these terms.
+</t>
+<t>
+   The verb "generate" is used instead of "send" where a requirement
+   differentiates between creating a protocol element and merely forwarding a
+   received element downstream.
 </t>
 <t>
    An implementation is considered conformant if it complies with all of the
-   requirements associated with its role(s). Note that SHOULD-level requirements
-   are relevant here, unless one of the documented exceptions is applicable.
+   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.
 </t>
 <t>
    This document also uses ABNF to define valid protocol elements
-   (<xref target="notation"/>). In addition to the prose requirements placed
-   upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
-</t>
-<t>
-   Unless noted otherwise, Recipients &MUST; be able to parse all protocol
-   elements matching the ABNF rules defined for them and &MAY; take steps to
-   recover a usable protocol element from an invalid construct. However, HTTP does not define
-   specific error handling mechanisms, except in cases where it has direct
-   impact on security. This is because different uses of the protocol require
-   different error handling strategies; for example, a Web browser might wish to
-   transparently recover from a response where the <x:ref>Location</x:ref>
-   header field doesn't parse according to the ABNF, whereby in a systems
-   control protocol using HTTP, this type of error recovery could lead to
-   dangerous consequences.
+   (<xref target="notation"/>).
+   In addition to the prose requirements placed upon them, senders &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.
+</t>
+<t>
+   Unless noted otherwise, a recipient &MAY; 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
+   <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
+   whereas a systems control client might consider any form of error recovery
+   to be dangerous.
 </t>
 </section>