Changeset 2533

Timestamp:

04/01/14 01:46:01 (6 years ago)

Author:

fielding@…

Message:

rephrase [2528] to be more understandable by non-spec-authors; see #540

Location:

draft-ietf-httpbis/latest

Files:

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

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

@@ -1272 +1272 @@
          <div id="header.fields">
             <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a href="#header.fields">Header Fields</a></h2>
-            <p id="rfc.section.3.2.p.1">Each HTTP header field consists of a case-insensitive field name followed by a colon (":"), optional leading whitespace, the
-               field value, and optional trailing whitespace.
+            <p id="rfc.section.3.2.p.1">Each header field consists of a case-insensitive field name followed by a colon (":"), optional leading whitespace, the field
+               value, and optional trailing whitespace.
             </p>
             <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span>  <a href="#header.fields" class="smpl">header-field</a>   = <a href="#header.fields" class="smpl">field-name</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.fields" class="smpl">field-value</a> <a href="#rule.whitespace" class="smpl">OWS</a>
@@ -1285 +1285 @@
                the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
             </p>
-            <p id="rfc.section.3.2.p.4">Extraction of field-name/field-value pairs from a message is generic and thus independent of the actual field name. Consequently,
-               the ABNF specified for each header field only defines the syntax of the field-value (not the whole header-field, as it was
-               the case in previous revisions of this specification).
+            <p id="rfc.section.3.2.p.4">Since messages are parsed using a generic algorithm, independent of the individual header field names, the contents within
+               a given field-value are not parsed until a later stage of message interpretation (usually after the message's entire header
+               section has been processed). Consequently, this specification does not use specific ABNF rules to define each "Field-Name:
+               Field Value" pair, as was done in previous editions. Instead, this specification defines each of its header fields using an
+               ABNF rule that is named according to the registered field-name and that defines only the syntax within the field-value (i.e.,
+               after it has been extracted from the header section by a generic field parser).
             </p>
             <div id="field.extensibility">

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

@@ -1216 +1216 @@
   <x:anchor-alias value="obs-fold"/>
 <t>
-   Each HTTP header field consists of a case-insensitive field name
+   Each header field consists of a case-insensitive field name
    followed by a colon (":"), optional leading whitespace, the field value,
    and optional trailing whitespace.
@@ -1236 +1236 @@
 </t>
 <t>
-   Extraction of field-name/field-value pairs from a message is generic and
-   thus independent of the actual field name. Consequently, the ABNF specified
-   for each header field only defines the syntax of the field-value (not the
-   whole header-field, as it was the case in previous revisions of this
-   specification).
+   Since messages are parsed using a generic algorithm, independent of the
+   individual header field names, the contents within a given field-value are
+   not parsed until a later stage of message interpretation (usually after the
+   message's entire header section has been processed).
+   Consequently, this specification does not use specific ABNF rules to define
+   each "Field-Name: Field Value" pair, as was done in previous editions.
+   Instead, this specification defines each of its header fields using an ABNF
+   rule that is named according to the registered field-name and that defines
+   only the syntax within the field-value (i.e., after it has been extracted
+   from the header section by a generic field parser).
 </t>