Changeset 1770 for draft-ietf-httpbis/latest/p4-conditional.html

Timestamp:

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

Author:

julian.reschke@…

Message:

Make ABNF/conformance terminology consistent (see #362)

File:

• draft-ietf-httpbis/latest/p4-conditional.html (modified) (6 diffs)

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>