Ignore:
Timestamp:
26/01/12 14:54:04 (8 years ago)
Author:
julian.reschke@…
Message:

spelling & grammar

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p3-payload.html

    r1506 r1514  
    358358  }
    359359  @bottom-center {
    360        content: "Expires July 17, 2012";
     360       content: "Expires July 29, 2012";
    361361  }
    362362  @bottom-right {
     
    409409      <meta name="dct.creator" content="Reschke, J. F.">
    410410      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    411       <meta name="dct.issued" scheme="ISO8601" content="2012-01-14">
     411      <meta name="dct.issued" scheme="ISO8601" content="2012-01-26">
    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 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
     
    435435            </tr>
    436436            <tr>
    437                <td class="left">Expires: July 17, 2012</td>
     437               <td class="left">Expires: July 29, 2012</td>
    438438               <td class="right">J. Mogul</td>
    439439            </tr>
     
    492492            <tr>
    493493               <td class="left"></td>
    494                <td class="right">January 14, 2012</td>
     494               <td class="right">January 26, 2012</td>
    495495            </tr>
    496496         </tbody>
     
    520520         in progress”.
    521521      </p>
    522       <p>This Internet-Draft will expire on July 17, 2012.</p>
     522      <p>This Internet-Draft will expire on July 29, 2012.</p>
    523523      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    524524      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    753753         <li>Pointer to specification text</li>
    754754      </ul>
    755       <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 5.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     755      <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 5.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    756756      </p>
    757757      <p id="rfc.section.2.2.1.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of content coding defined in this section.
     
    995995         <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li>
    996996      </ol>
    997       <p id="rfc.section.5.1.p.4">Server-driven negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honour
     997      <p id="rfc.section.5.1.p.4">Server-driven negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor
    998998         them. For example, the origin server might not implement server-driven negotiation, or it might decide that sending a response
    999999         that doesn't conform to them is better than sending a 406 (Not Acceptable) response.
     
    14751475      </p>
    14761476      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="privacy.issues.connected.to.accept.header.fields" href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h2>
    1477       <p id="rfc.section.8.1.p.1">Accept headers fields can reveal information about the user to all servers which are accessed. The Accept-Language header
    1478          field in particular can reveal information the user would consider to be of a private nature, because the understanding of
    1479          particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer
    1480          the option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged
    1481          to let the configuration process include a message which makes the user aware of the loss of privacy involved.
     1477      <p id="rfc.section.8.1.p.1">Accept header fields can reveal information about the user to all servers which are accessed. The Accept-Language header field
     1478         in particular can reveal information the user would consider to be of a private nature, because the understanding of particular
     1479         languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option
     1480         to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged to let the
     1481         configuration process include a message which makes the user aware of the loss of privacy involved.
    14821482      </p>
    14831483      <p id="rfc.section.8.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language header fields
Note: See TracChangeset for help on using the changeset viewer.