Changeset 1463 for draft-ietf-httpbis

Timestamp:

31/10/11 02:36:49 (11 years ago)

Author:

mnot@…

Message:

Minor editorial tweaks to considerations for new headers ( #231 )

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (7 diffs)
• p2-semantics.xml (modified) (2 diffs)

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

@@ -359 +359 @@
   } 
   @bottom-center {
-       content: "Expires April 29, 2012"; 
+       content: "Expires May 3, 2012"; 
   } 
   @bottom-right {
@@ -409 +409 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2011-10-27">
+      <meta name="dct.issued" scheme="ISO8601" content="2011-10-31">
       <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 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields.">
@@ -440 +440 @@
             </tr>
             <tr>
-               <td class="left">Expires: April 29, 2012</td>
+               <td class="left">Expires: May 3, 2012</td>
                <td class="right">HP</td>
             </tr>
@@ -493 +493 @@
             <tr>
                <td class="left"></td>
-               <td class="right">October 27, 2011</td>
+               <td class="right">October 31, 2011</td>
             </tr>
          </tbody>
@@ -523 +523 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on April 29, 2012.</p>
+      <p>This Internet-Draft will expire on May 3, 2012.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -877 +877 @@
   Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
 </pre><p id="rfc.section.3.1.p.7">Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in <a href="p3-payload.html#header.content-type" title="Content-Type">Section 6.8</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing
-         parser components. Also, the meaning of a value ought to be independent of the syntax variant used for it (for an example,
-         see the notes on parameter handling for media types in <a href="p3-payload.html#media.types" title="Media Types">Section 2.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
+         parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for
+         it (for an example, see the notes on parameter handling for media types in <a href="p3-payload.html#media.types" title="Media Types">Section 2.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
       </p>
       <p id="rfc.section.3.1.p.8">Authors of specifications defining new header fields are advised to consider documenting: </p>
@@ -885 +885 @@
             <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
             </p>
-            <p>If it does not use the list syntax, how to treat messages where the header field occurs multiple times (a sensible default
-               would be to ignore the header field, but this might not always be the right choice).
+            <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible
+               default would be to ignore the header field, but this might not always be the right choice).
             </p>
-            <p>Furthermore, intermediaries and software libraries might combine multiple header field instances into a single one, despite
-               the header field not allowing this. A robust format enables recipients to discover these situations (good example: "Content-Type",
+            <p>Note that intermediaries and software libraries might combine multiple header field instances into a single one, despite the
+               header field not allowing this. A robust format enables recipients to discover these situations (good example: "Content-Type",
                as the comma can only appear inside quoted strings; bad example: "Location", as a comma can occur inside a URI).
             </p>

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

@@ -545 +545 @@
    parameters (for instance, Content-Type, defined in &header-content-type;).
    Allowing both unquoted (token) and quoted (quoted-string) syntax for the
-   parameter value enables recipients to use existing parser components. Also,
-   the meaning of a value ought to be independent of the syntax variant used
-   for it (for an example, see the notes on parameter handling for media types
-   in &media-types;).
+   parameter value enables recipients to use existing parser components. When
+   allowing both forms, the meaning of a parameter value ought to be
+   independent of the syntax used for it (for an example, see the notes on
+   parameter handling for media types in &media-types;).
 </t>
 <t>
@@ -557 +557 @@
       <t>Whether the field is a single value, or whether it can be a list
       (delimited by commas; see &header-fields;).</t>
-      <t>If it does not use the list syntax, how to treat messages where the
-      header field occurs multiple times (a sensible default would be to ignore
-      the header field, but this might not always be the right choice).</t>
-      <t>Furthermore, intermediaries and software libraries might combine
+      <t>If it does not use the list syntax, document how to treat messages
+      where the header field occurs multiple times (a sensible default would
+      be to ignore the header field, but this might not always be the right
+      choice).</t>
+      <t>Note that intermediaries and software libraries might combine
       multiple header field instances into a single one, despite the header
       field not allowing this. A robust format enables recipients to discover