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

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

Location:
draft-ietf-httpbis/latest
Files:
2 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>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1458 r1463  
    545545   parameters (for instance, Content-Type, defined in &header-content-type;).
    546546   Allowing both unquoted (token) and quoted (quoted-string) syntax for the
    547    parameter value enables recipients to use existing parser components. Also,
    548    the meaning of a value ought to be independent of the syntax variant used
    549    for it (for an example, see the notes on parameter handling for media types
    550    in &media-types;).
     547   parameter value enables recipients to use existing parser components. When
     548   allowing both forms, the meaning of a parameter value ought to be
     549   independent of the syntax used for it (for an example, see the notes on
     550   parameter handling for media types in &media-types;).
    551551</t>
    552552<t>
     
    557557      <t>Whether the field is a single value, or whether it can be a list
    558558      (delimited by commas; see &header-fields;).</t>
    559       <t>If it does not use the list syntax, how to treat messages where the
    560       header field occurs multiple times (a sensible default would be to ignore
    561       the header field, but this might not always be the right choice).</t>
    562       <t>Furthermore, intermediaries and software libraries might combine
     559      <t>If it does not use the list syntax, document how to treat messages
     560      where the header field occurs multiple times (a sensible default would
     561      be to ignore the header field, but this might not always be the right
     562      choice).</t>
     563      <t>Note that intermediaries and software libraries might combine
    563564      multiple header field instances into a single one, despite the header
    564565      field not allowing this. A robust format enables recipients to discover
Note: See TracChangeset for help on using the changeset viewer.