Ignore:
Timestamp:
Oct 30, 2011, 7:36:49 PM (8 years ago)
Author:
mnot@…
Message:

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

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1458 r1463  
    359359  }
    360360  @bottom-center {
    361        content: "Expires April 29, 2012";
     361       content: "Expires May 3, 2012";
    362362  }
    363363  @bottom-right {
     
    409409      <meta name="dct.creator" content="Reschke, J. F.">
    410410      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    411       <meta name="dct.issued" scheme="ISO8601" content="2011-10-27">
     411      <meta name="dct.issued" scheme="ISO8601" content="2011-10-31">
    412412      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    413413      <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.">
     
    440440            </tr>
    441441            <tr>
    442                <td class="left">Expires: April 29, 2012</td>
     442               <td class="left">Expires: May 3, 2012</td>
    443443               <td class="right">HP</td>
    444444            </tr>
     
    493493            <tr>
    494494               <td class="left"></td>
    495                <td class="right">October 27, 2011</td>
     495               <td class="right">October 31, 2011</td>
    496496            </tr>
    497497         </tbody>
     
    523523         in progress”.
    524524      </p>
    525       <p>This Internet-Draft will expire on April 29, 2012.</p>
     525      <p>This Internet-Draft will expire on May 3, 2012.</p>
    526526      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    527527      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    877877  Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
    878878</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
    879          parser components. Also, the meaning of a value ought to be independent of the syntax variant used for it (for an example,
    880          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>).
     879         parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for
     880         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>).
    881881      </p>
    882882      <p id="rfc.section.3.1.p.8">Authors of specifications defining new header fields are advised to consider documenting: </p>
     
    885885            <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>).
    886886            </p>
    887             <p>If it does not use the list syntax, how to treat messages where the header field occurs multiple times (a sensible default
    888                would be to ignore the header field, but this might not always be the right choice).
     887            <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible
     888               default would be to ignore the header field, but this might not always be the right choice).
    889889            </p>
    890             <p>Furthermore, intermediaries and software libraries might combine multiple header field instances into a single one, despite
    891                the header field not allowing this. A robust format enables recipients to discover these situations (good example: "Content-Type",
     890            <p>Note that intermediaries and software libraries might combine multiple header field instances into a single one, despite the
     891               header field not allowing this. A robust format enables recipients to discover these situations (good example: "Content-Type",
    892892               as the comma can only appear inside quoted strings; bad example: "Location", as a comma can occur inside a URI).
    893893            </p>
Note: See TracChangeset for help on using the changeset viewer.