Ignore:
Timestamp:
Jan 8, 2011, 6:27:21 AM (9 years ago)
Author:
julian.reschke@…
Message:

use mdash for long dashes, make use of dashes consistent

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1099 r1101  
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2011-01-01">
     406      <meta name="dct.issued" scheme="ISO8601" content="2011-01-08">
    407407      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    408408      <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 1 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.">
     
    435435            </tr>
    436436            <tr>
    437                <td class="left">Expires: July 5, 2011</td>
     437               <td class="left">Expires: July 12, 2011</td>
    438438               <td class="right">HP</td>
    439439            </tr>
     
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">January 1, 2011</td>
     490               <td class="right">January 8, 2011</td>
    491491            </tr>
    492492         </tbody>
     
    516516         in progress”.
    517517      </p>
    518       <p>This Internet-Draft will expire on July 5, 2011.</p>
     518      <p>This Internet-Draft will expire on July 12, 2011.</p>
    519519      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    520520      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    712712         MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the
    713713         Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate request targets and relationships between resources. Messages are passed in a format similar to that used by Internet
    714          mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</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> for the differences between HTTP and MIME messages).
     714         mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.and.mime" title="ERROR: Anchor 'differences.between.http.and.mime' not found in p3-payload.xml.">Appendix ERROR: Anchor 'differences.between.http.and.mime' in Part3 not found in source file 'p3-payload.xml'.</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> for the differences between HTTP and MIME messages).
    715715      </p>
    716716      <p id="rfc.section.1.p.2">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented
     
    860860      <div id="rfc.figure.u.12"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">request-header</a>  = &lt;request-header, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 3</a>&gt;
    861861  <a href="#abnf.dependencies" class="smpl">response-header</a> = &lt;response-header, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 5</a>&gt;
    862 </pre><div id="rfc.figure.u.13"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">MIME-Version</a>    = &lt;MIME-Version, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a>&gt;
     862</pre><div id="rfc.figure.u.13"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">MIME-Version</a>    = &lt;MIME-Version, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="ERROR: Anchor 'mime-version' not found in p3-payload.xml.">Appendix ERROR: Anchor 'mime-version' in Part3 not found in source file 'p3-payload.xml'.</a>&gt;
    863863</pre><div id="rfc.figure.u.14"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">Cache-Control</a>   = &lt;Cache-Control, defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>&gt;
    864864  <a href="#abnf.dependencies" class="smpl">Pragma</a>          = &lt;Pragma, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>&gt;
     
    10801080         would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for servers that require
    10811081         an SSL/TLS transport layer on a connection. Other protocols might also be used to provide access to "http" identified resources
    1082          --- it is only the authoritative interface used for mapping the namespace that is specific to TCP.
     1082          it is only the authoritative interface used for mapping the namespace that is specific to TCP.
    10831083      </p>
    10841084      <p id="rfc.section.2.6.1.p.7">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.15"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. The userinfo subcomponent (and its "@" delimiter) <em class="bcp14">MUST NOT</em> be used in an "http" URI. URI reference recipients <em class="bcp14">SHOULD</em> parse for the existence of userinfo and treat its presence as an error, likely indicating that the deprecated subcomponent
     
    13131313                 / <a href="#header.via" class="smpl">Via</a>                      ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;9.9</a>
    13141314                 / <a href="#abnf.dependencies" class="smpl">Warning</a>                  ; <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a>
    1315                  / <a href="#abnf.dependencies" class="smpl">MIME-Version</a>             ; <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a>
     1315                 / <a href="#abnf.dependencies" class="smpl">MIME-Version</a>             ; <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="ERROR: Anchor 'mime-version' not found in p3-payload.xml.">Appendix ERROR: Anchor 'mime-version' in Part3 not found in source file 'p3-payload.xml'.</a>
    13161316</pre><p id="rfc.section.3.4.p.3">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    13171317         or experimental header fields might be given the semantics of general header fields if all parties in the communication recognize
     
    17071707         <li>Pointer to specification text</li>
    17081708      </ul>
    1709       <p id="rfc.section.6.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;6.2.2</a>).
     1709      <p id="rfc.section.6.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="ERROR: Anchor 'content.codings' not found in p3-payload.xml.">Appendix ERROR: Anchor 'content.codings' in Part3 not found in source file 'p3-payload.xml'.</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;6.2.2</a>).
    17101710      </p>
    17111711      <p id="rfc.section.6.2.3.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 transfer coding defined in this section.
     
    17261726      </p>
    17271727      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h2>
    1728       <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
     1728      <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="ERROR: Anchor 'content.negotiation' not found in p3-payload.xml.">Appendix ERROR: Anchor 'content.negotiation' in Part3 not found in source file 'p3-payload.xml'.</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
    17291729         is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has
    17301730         a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion.
     
    21832183      <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2>
    21842184      <p id="rfc.section.9.7.p.1">The "Transfer-Encoding" general-header field indicates what transfer-codings (if any) have been applied to the message body.
    2185          It differs from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings
     2185         It differs from Content-Encoding (<a href="p3-payload.html#content.codings" title="ERROR: Anchor 'content.codings' not found in p3-payload.xml.">Appendix ERROR: Anchor 'content.codings' in Part3 not found in source file 'p3-payload.xml'.</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings
    21862186         are not.
    21872187      </p>
     
    24072407               </dd>
    24082408               <dt>msgtype:</dt>
    2409                <dd>The message type -- "request" or "response". If not present, the type can be determined from the first line of the body.</dd>
     2409               <dd>The message type "request" or "response". If not present, the type can be determined from the first line of the body.</dd>
    24102410            </dl>
    24112411         </dd>
     
    24602460               </dd>
    24612461               <dt>msgtype:</dt>
    2462                <dd>The message type -- "request" or "response". If not present, the type can be determined from the first line of the body.</dd>
     2462               <dd>The message type "request" or "response". If not present, the type can be determined from the first line of the body.</dd>
    24632463            </dl>
    24642464         </dd>
     
    25402540      </div>
    25412541      <h2 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a>&nbsp;<a id="upgrade.token.registration" href="#upgrade.token.registration">Upgrade Token Registration</a></h2>
    2542       <p id="rfc.section.10.5.p.1">The registration procedure for HTTP Upgrade Tokens -- previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> -- is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;9.8.1</a> of this document.
     2542      <p id="rfc.section.10.5.p.1">The registration procedure for HTTP Upgrade Tokens — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;9.8.1</a> of this document.
    25432543      </p>
    25442544      <p id="rfc.section.10.5.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>&gt; shall be updated with the registration below:
     
    26312631      <p id="rfc.section.11.6.p.1">They exist. They are hard to defend against. Research continues. Beware.</p>
    26322632      <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a>&nbsp;<a id="ack" href="#ack">Acknowledgments</a></h1>
    2633       <p id="rfc.section.12.p.1">HTTP has evolved considerably over the years. It has benefited from a large and active developer community--the many people
    2634          who have participated on the www-talk mailing list--and it is that community which has been most responsible for the success
     2633      <p id="rfc.section.12.p.1">HTTP has evolved considerably over the years. It has benefited from a large and active developer community — the many people
     2634         who have participated on the www-talk mailing list — and it is that community which has been most responsible for the success
    26352635         of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, John Franks,
    26362636         Jean-Francois Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, Tony Sanders,
     
    32613261         <li>Avoid underscore character in rule names ("http_URL" -&gt; "http-URL", "abs_path" -&gt; "path-absolute").</li>
    32623262         <li>Add rules for terms imported from URI spec ("absoluteURI", "authority", "path-absolute", "port", "query", "relativeURI", "host)
    3263             -- these will have to be updated when switching over to RFC3986.
     3263            these will have to be updated when switching over to RFC3986.
    32643264         </li>
    32653265         <li>Synchronize core rules with RFC5234.</li>
     
    37253725                  </li>
    37263726                  <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">1.2.3</a>, <a href="#rfc.xref.Part3.3">3.4</a>, <a href="#rfc.xref.Part3.4">6.2.3</a>, <a href="#rfc.xref.Part3.5">6.4</a>, <a href="#rfc.xref.Part3.6">7.1.3.2</a>, <a href="#rfc.xref.Part3.7">9.7</a>, <a href="#Part3"><b>13.1</b></a>, <a href="#rfc.xref.Part3.8">A</a><ul>
    3727                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.4">6.2.3</a>, <a href="#rfc.xref.Part3.7">9.7</a></li>
    3728                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.5">6.4</a></li>
    3729                         <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a></li>
    3730                         <li><em>Appendix A.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">1.2.3</a>, <a href="#rfc.xref.Part3.3">3.4</a></li>
     3727                        <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a></li>
     3728                        <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">1.2.3</a>, <a href="#rfc.xref.Part3.3">3.4</a></li>
     3729                        <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.4">6.2.3</a>, <a href="#rfc.xref.Part3.7">9.7</a></li>
     3730                        <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.5">6.4</a></li>
    37313731                     </ul>
    37323732                  </li>
Note: See TracChangeset for help on using the changeset viewer.