Changeset 1101 for draft-ietf-httpbis


Ignore:
Timestamp:
08/01/11 14:27:21 (9 years ago)
Author:
julian.reschke@…
Message:

use mdash for long dashes, make use of dashes consistent

Location:
draft-ietf-httpbis/latest
Files:
11 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>

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1099 r1101  
    1515  <!ENTITY ID-MONTH "January">
    1616  <!ENTITY ID-YEAR "2011">
     17  <!ENTITY mdash "&#8212;">
    1718  <!ENTITY caching-overview       "<xref target='Part6' x:rel='#caching.overview' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1819  <!ENTITY cache-incomplete       "<xref target='Part6' x:rel='#errors.or.incomplete.response.cache.behavior' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    961962   the "https" scheme (below) is used for servers that require an SSL/TLS
    962963   transport layer on a connection. Other protocols might also be used to
    963    provide access to "http" identified resources --- it is only the
     964   provide access to "http" identified resources &mdash; it is only the
    964965   authoritative interface used for mapping the namespace that is
    965966   specific to TCP.
    … …  
    35693570        </t>
    35703571        <t hangText="msgtype:">
    3571           The message type -- "request" or "response". If not
     3572          The message type &mdash; "request" or "response". If not
    35723573          present, the type can be determined from the first
    35733574          line of the body.
    … …  
    36383639        </t>
    36393640        <t hangText="msgtype:">
    3640           The message type -- "request" or "response". If not
     3641          The message type &mdash; "request" or "response". If not
    36413642          present, the type can be determined from the first
    36423643          line of the body.
    … …  
    37253726<section title="Upgrade Token Registration" anchor="upgrade.token.registration">
    37263727<t>
    3727    The registration procedure for HTTP Upgrade Tokens -- previously defined
    3728    in <xref target="RFC2817" x:fmt="of" x:sec="7.2"/> -- is now defined
     3728   The registration procedure for HTTP Upgrade Tokens &mdash; previously defined
     3729   in <xref target="RFC2817" x:fmt="of" x:sec="7.2"/> &mdash; is now defined
    37293730   by <xref target="upgrade.token.registry"/> of this document.
    37303731</t>
    … …  
    38953896<t>
    38963897   HTTP has evolved considerably over the years. It has
    3897    benefited from a large and active developer community--the many
    3898    people who have participated on the www-talk mailing list--and it is
     3898   benefited from a large and active developer community &mdash; the many
     3899   people who have participated on the www-talk mailing list &mdash; and it is
    38993900   that community which has been most responsible for the success of
    39003901   HTTP and of the World-Wide Web in general. Marc Andreessen, Robert
    … …  
    52675268    <t>
    52685269      Add rules for terms imported from URI spec ("absoluteURI", "authority",
    5269       "path-absolute", "port", "query", "relativeURI", "host) -- these will
     5270      "path-absolute", "port", "query", "relativeURI", "host) &mdash; these will
    52705271      have to be updated when switching over to RFC3986.
    52715272    </t>

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

    r1099 r1101  
    403403      <meta name="dct.creator" content="Reschke, J. F.">
    404404      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    405       <meta name="dct.issued" scheme="ISO8601" content="2011-01-01">
     405      <meta name="dct.issued" scheme="ISO8601" content="2011-01-08">
    406406      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    407407      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia 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.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: July 5, 2011</td>
     436               <td class="left">Expires: July 12, 2011</td>
    437437               <td class="right">HP</td>
    438438            </tr>
    … …  
    487487            <tr>
    488488               <td class="left"></td>
    489                <td class="right">January 1, 2011</td>
     489               <td class="right">January 8, 2011</td>
    490490            </tr>
    491491         </tbody>
    … …  
    514514         in progress”.
    515515      </p>
    516       <p>This Internet-Draft will expire on July 5, 2011.</p>
     516      <p>This Internet-Draft will expire on July 12, 2011.</p>
    517517      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    518518      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    848848      </p>
    849849      <p id="rfc.section.4.p.3">The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase
    850          values, are presented below. The reason phrases listed here are only recommendations -- they <em class="bcp14">MAY</em> be replaced by local equivalents without affecting the protocol.
     850         values, are presented below. The reason phrases listed here are only recommendations — they <em class="bcp14">MAY</em> be replaced by local equivalents without affecting the protocol.
    851851      </p>
    852852      <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> =
    … …  
    11521152Host: server.example.com:80
    11531153
    1154 </pre><p id="rfc.section.7.9.p.4">Other HTTP mechanisms can be used normally with the CONNECT method -- except end-to-end protocol Upgrade requests, since the
     1154</pre><p id="rfc.section.7.9.p.4">Other HTTP mechanisms can be used normally with the CONNECT method — except end-to-end protocol Upgrade requests, since the
    11551155         tunnel must be established first.
    11561156      </p>
    … …  
    14921492         is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's
    14931493         site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time
    1494          -- that is left to the discretion of the server owner.
     1494         — that is left to the discretion of the server owner.
    14951495      </p>
    14961496      <p id="rfc.section.8.4.11.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 410 responses.
    … …  
    16171617      <div id="rfc.figure.u.16"></div><pre class="text">  Allow: GET, HEAD, PUT
    16181618</pre><p id="rfc.section.9.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p>
    1619       <p id="rfc.section.9.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field -- it does not need to understand all the methods specified in order to handle them according
     1619      <p id="rfc.section.9.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all the methods specified in order to handle them according
    16201620         to the generic message handling rules.
    16211621      </p>
    … …  
    18641864      </div>
    18651865      <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Status Code Registry</a></h2>
    1866       <p id="rfc.section.10.2.p.1">The registration procedure for HTTP Status Codes -- previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</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="#status.code.registry" title="Status Code Registry">Section&nbsp;4.1</a> of this document.
     1866      <p id="rfc.section.10.2.p.1">The registration procedure for HTTP Status Codes — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</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="#status.code.registry" title="Status Code Registry">Section&nbsp;4.1</a> of this document.
    18671867      </p>
    18681868      <p id="rfc.section.10.2.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; shall be updated with the registrations below:

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

    r1099 r1101  
    1515  <!ENTITY ID-MONTH "January">
    1616  <!ENTITY ID-YEAR "2011">
     17  <!ENTITY mdash "&#8212;">
    1718  <!ENTITY notation                   "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1819  <!ENTITY messaging                  "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    573574   HTTP/1.1, and an example set of corresponding Reason-Phrase values, are
    574575   presented below. The reason phrases listed here are only
    575    recommendations -- they &MAY; be replaced by local equivalents without
     576   recommendations &mdash; they &MAY; be replaced by local equivalents without
    576577   affecting the protocol.
    577578</t>
    … …  
    11591160</artwork></figure>
    11601161<t>
    1161    Other HTTP mechanisms can be used normally with the CONNECT method --
     1162   Other HTTP mechanisms can be used normally with the CONNECT method &mdash;
    11621163   except end-to-end protocol Upgrade requests, since the
    11631164   tunnel must be established first.
    … …  
    18541855   individuals no longer working at the server's site. It is not
    18551856   necessary to mark all permanently unavailable resources as "gone" or
    1856    to keep the mark for any length of time -- that is left to the
     1857   to keep the mark for any length of time &mdash; that is left to the
    18571858   discretion of the server owner.
    18581859</t>
    … …  
    21052106</t>
    21062107<t>
    2107    A proxy &MUST-NOT; modify the Allow header field -- it does not need to
     2108   A proxy &MUST-NOT; modify the Allow header field &mdash; it does not need to
    21082109   understand all the methods specified in order to handle them according to
    21092110   the generic message handling rules.
    … …  
    25502551<section title="Status Code Registry" anchor="status.code.registration">
    25512552<t>
    2552    The registration procedure for HTTP Status Codes -- previously defined
    2553    in <xref target="RFC2817" x:fmt="of" x:sec="7.1"/> -- is now defined
     2553   The registration procedure for HTTP Status Codes &mdash; previously defined
     2554   in <xref target="RFC2817" x:fmt="of" x:sec="7.1"/> &mdash; is now defined
    25542555   by <xref target="status.code.registry"/> of this document.
    25552556</t>

  • draft-ietf-httpbis/latest/p3-payload.html

    r1099 r1101  
    402402      <meta name="dct.creator" content="Reschke, J. F.">
    403403      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    404       <meta name="dct.issued" scheme="ISO8601" content="2011-01-01">
     404      <meta name="dct.issued" scheme="ISO8601" content="2011-01-08">
    405405      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    406406      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia 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.">
    … …  
    428428            </tr>
    429429            <tr>
    430                <td class="left">Expires: July 5, 2011</td>
     430               <td class="left">Expires: July 12, 2011</td>
    431431               <td class="right">J. Mogul</td>
    432432            </tr>
    … …  
    485485            <tr>
    486486               <td class="left"></td>
    487                <td class="right">January 1, 2011</td>
     487               <td class="right">January 8, 2011</td>
    488488            </tr>
    489489         </tbody>
    … …  
    511511         in progress”.
    512512      </p>
    513       <p>This Internet-Draft will expire on July 5, 2011.</p>
     513      <p>This Internet-Draft will expire on July 12, 2011.</p>
    514514      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    515515      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    813813      </p>
    814814      <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="multipart.types" href="#multipart.types">Multipart Types</a></h3>
    815       <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message-body.
     815      <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types — encapsulations of one or more representations within a single message-body.
    816816         All multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts.
    817817      </p>
    … …  
    923923      <p id="rfc.section.5.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence
    924924         which representation, among those available from the server, would be best for the server to deliver. For this reason, HTTP
    925          provides mechanisms for "content negotiation" -- a process of allowing selection of a representation of a given resource,
    926          when more than one is available.
     925         provides mechanisms for "content negotiation" — a process of allowing selection of a representation of a given resource, when
     926         more than one is available.
    927927      </p>
    928928      <p id="rfc.section.5.p.3">This specification defines two patterns of content negotiation; "server-driven", where the server selects the representation
    … …  
    12541254         intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en".
    12551255      </p>
    1256       <p id="rfc.section.6.6.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type -- it is not limited to textual documents.
     1256      <p id="rfc.section.6.6.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type — it is not limited to textual documents.
    12571257      </p>
    12581258      <div id="rfc.iref.c.9"></div>
    … …  
    13231323         and Content-Encoding header fields). If a body-part has a Content-Transfer-Encoding or Content-Encoding header field, it is
    13241324         assumed that the content of the body-part has had the encoding applied, and the body-part is included in the Content-MD5 digest
    1325          as is -- i.e., after the application. The Transfer-Encoding header field is not allowed within body-parts.
     1325         as is — i.e., after the application. The Transfer-Encoding header field is not allowed within body-parts.
    13261326      </p>
    13271327      <p id="rfc.section.6.8.p.7">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest.
    … …  
    19191919      <p id="rfc.section.E.5.p.2">Other changes: </p>
    19201920      <ul>
    1921          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/68">http://tools.ietf.org/wg/httpbis/trac/ticket/68</a>&gt;: "Encoding References Normative" -- rephrase the annotation and reference <a href="#BCP97" id="rfc.xref.BCP97.4"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
     1921         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/68">http://tools.ietf.org/wg/httpbis/trac/ticket/68</a>&gt;: "Encoding References Normative" — rephrase the annotation and reference <a href="#BCP97" id="rfc.xref.BCP97.4"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
    19221922         </li>
    19231923      </ul>

  • draft-ietf-httpbis/latest/p3-payload.xml

    r1099 r1101  
    1515  <!ENTITY ID-MONTH "January">
    1616  <!ENTITY ID-YEAR "2011">
     17  <!ENTITY mdash "&#8212;">
    1718  <!ENTITY notation                 "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1819  <!ENTITY notation-abnf            "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    607608<section title="Multipart Types" anchor="multipart.types">
    608609<t>
    609    MIME provides for a number of "multipart" types -- encapsulations of
     610   MIME provides for a number of "multipart" types &mdash; encapsulations of
    610611   one or more representations within a single message-body. All multipart
    611612   types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>,
    … …  
    824825   which representation, among those available from the server,
    825826   would be best for the server to deliver. For this reason, HTTP
    826    provides mechanisms for "content negotiation" -- a process of
     827   provides mechanisms for "content negotiation" &mdash; a process of
    827828   allowing selection of a representation of a given resource,
    828829   when more than one is available.
    … …  
    14011402</t>
    14021403<t>
    1403    Content-Language &MAY; be applied to any media type -- it is not
     1404   Content-Language &MAY; be applied to any media type &mdash; it is not
    14041405   limited to textual documents.
    14051406</t>
    … …  
    15441545   or Content-Encoding header field, it is assumed that the content
    15451546   of the body-part has had the encoding applied, and the body-part is
    1546    included in the Content-MD5 digest as is -- i.e., after the
     1547   included in the Content-MD5 digest as is &mdash; i.e., after the
    15471548   application. The Transfer-Encoding header field is not allowed within
    15481549   body-parts.
    … …  
    28872888    <t>
    28882889      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/68"/>:
    2889       "Encoding References Normative" -- rephrase the annotation and reference
     2890      "Encoding References Normative" &mdash; rephrase the annotation and reference
    28902891      <xref target="BCP97"/>.
    28912892    </t>

  • draft-ietf-httpbis/latest/p4-conditional.html

    r1099 r1101  
    400400      <meta name="dct.creator" content="Reschke, J. F.">
    401401      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    402       <meta name="dct.issued" scheme="ISO8601" content="2011-01-01">
     402      <meta name="dct.issued" scheme="ISO8601" content="2011-01-08">
    403403      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    404404      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
    … …  
    426426            </tr>
    427427            <tr>
    428                <td class="left">Expires: July 5, 2011</td>
     428               <td class="left">Expires: July 12, 2011</td>
    429429               <td class="right">J. Mogul</td>
    430430            </tr>
    … …  
    483483            <tr>
    484484               <td class="left"></td>
    485                <td class="right">January 1, 2011</td>
     485               <td class="right">January 8, 2011</td>
    486486            </tr>
    487487         </tbody>
    … …  
    509509         in progress”.
    510510      </p>
    511       <p>This Internet-Draft will expire on July 5, 2011.</p>
     511      <p>This Internet-Draft will expire on July 12, 2011.</p>
    512512      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    513513      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

  • draft-ietf-httpbis/latest/p5-range.html

    r1099 r1101  
    400400      <meta name="dct.creator" content="Reschke, J. F.">
    401401      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    402       <meta name="dct.issued" scheme="ISO8601" content="2011-01-01">
     402      <meta name="dct.issued" scheme="ISO8601" content="2011-01-08">
    403403      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    404404      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests.">
    … …  
    426426            </tr>
    427427            <tr>
    428                <td class="left">Expires: July 5, 2011</td>
     428               <td class="left">Expires: July 12, 2011</td>
    429429               <td class="right">J. Mogul</td>
    430430            </tr>
    … …  
    483483            <tr>
    484484               <td class="left"></td>
    485                <td class="right">January 1, 2011</td>
     485               <td class="right">January 8, 2011</td>
    486486            </tr>
    487487         </tbody>
    … …  
    509509         in progress”.
    510510      </p>
    511       <p>This Internet-Draft will expire on July 5, 2011.</p>
     511      <p>This Internet-Draft will expire on July 12, 2011.</p>
    512512      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    513513      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

  • draft-ietf-httpbis/latest/p6-cache.html

    r1099 r1101  
    402402      <meta name="dct.creator" content="Reschke, J. F.">
    403403      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    404       <meta name="dct.issued" scheme="ISO8601" content="2011-01-01">
     404      <meta name="dct.issued" scheme="ISO8601" content="2011-01-08">
    405405      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    406406      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
    … …  
    428428            </tr>
    429429            <tr>
    430                <td class="left">Expires: July 5, 2011</td>
     430               <td class="left">Expires: July 12, 2011</td>
    431431               <td class="right">J. Mogul</td>
    432432            </tr>
    … …  
    489489            <tr>
    490490               <td class="left"></td>
    491                <td class="right">January 1, 2011</td>
     491               <td class="right">January 8, 2011</td>
    492492            </tr>
    493493         </tbody>
    … …  
    515515         in progress”.
    516516      </p>
    517       <p>This Internet-Draft will expire on July 5, 2011.</p>
     517      <p>This Internet-Draft will expire on July 12, 2011.</p>
    518518      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    519519      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

  • draft-ietf-httpbis/latest/p7-auth.html

    r1099 r1101  
    397397      <meta name="dct.creator" content="Reschke, J. F.">
    398398      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    399       <meta name="dct.issued" scheme="ISO8601" content="2011-01-01">
     399      <meta name="dct.issued" scheme="ISO8601" content="2011-01-08">
    400400      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    401401      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication.">
    … …  
    428428            </tr>
    429429            <tr>
    430                <td class="left">Expires: July 5, 2011</td>
     430               <td class="left">Expires: July 12, 2011</td>
    431431               <td class="right">HP</td>
    432432            </tr>
    … …  
    481481            <tr>
    482482               <td class="left"></td>
    483                <td class="right">January 1, 2011</td>
     483               <td class="right">January 8, 2011</td>
    484484            </tr>
    485485         </tbody>
    … …  
    507507         in progress”.
    508508      </p>
    509       <p>This Internet-Draft will expire on July 5, 2011.</p>
     509      <p>This Internet-Draft will expire on July 12, 2011.</p>
    510510      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    511511      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    648648         scheme. Note that there can be multiple challenges with the same auth-scheme but different realms.
    649649      </p>
    650       <p id="rfc.section.2.p.10">A user agent that wishes to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401
    651          (Unauthorized) -- <em class="bcp14">MAY</em> do so by including an Authorization header field with the request. A client that wishes to authenticate itself with a proxy
    652          -- usually, but not necessarily, after receiving a 407 (Proxy Authentication Required) -- <em class="bcp14">MAY</em> do so by including a Proxy-Authorization header field with the request. Both the Authorization field value and the Proxy-Authorization
     650      <p id="rfc.section.2.p.10">A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a 401
     651         (Unauthorized) — <em class="bcp14">MAY</em> do so by including an Authorization header field with the request. A client that wishes to authenticate itself with a proxy
     652         — usually, but not necessarily, after receiving a 407 (Proxy Authentication Required) — <em class="bcp14">MAY</em> do so by including a Proxy-Authorization header field with the request. Both the Authorization field value and the Proxy-Authorization
    653653         field value consist of credentials containing the authentication information of the client for the realm of the resource being
    654654         requested. The user agent <em class="bcp14">MUST</em> choose to use one of the challenges with the strongest auth-scheme it understands and request credentials from the user based
    … …  
    705705      <div id="rfc.iref.h.1"></div>
    706706      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="header.authorization" href="#header.authorization">Authorization</a></h2>
    707       <p id="rfc.section.4.1.p.1">The "Authorization" request-header field allows a user agent to authenticate itself with a server -- usually, but not necessarily,
     707      <p id="rfc.section.4.1.p.1">The "Authorization" request-header field allows a user agent to authenticate itself with a server — usually, but not necessarily,
    708708         after receiving a 401 (Unauthorized) response. Its value consists of credentials containing information of the user agent
    709709         for the realm of the resource being requested.

  • draft-ietf-httpbis/latest/p7-auth.xml

    r1099 r1101  
    1515  <!ENTITY ID-MONTH "January">
    1616  <!ENTITY ID-YEAR "2011">
     17  <!ENTITY mdash "&#8212;">
    1718  <!ENTITY notation                     "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1819  <!ENTITY notation-abnf                "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    352353<t>
    353354   A user agent that wishes to authenticate itself with an origin
    354    server -- usually, but not necessarily, after receiving a 401
    355    (Unauthorized) -- &MAY; do so by including an Authorization header field
     355   server &mdash; usually, but not necessarily, after receiving a 401
     356   (Unauthorized) &mdash; &MAY; do so by including an Authorization header field
    356357   with the request. A client that wishes to authenticate itself with a
    357    proxy -- usually, but not necessarily, after receiving a 407 (Proxy
    358    Authentication Required) -- &MAY; do so by including a Proxy-Authorization
     358   proxy &mdash; usually, but not necessarily, after receiving a 407 (Proxy
     359   Authentication Required) &mdash; &MAY; do so by including a Proxy-Authorization
    359360   header field with the request.  Both the Authorization
    360361   field value and the Proxy-Authorization field value consist of
    … …  
    475476<t>
    476477   The "Authorization" request-header field allows a user agent to authenticate
    477    itself with a server -- usually, but not necessarily, after receiving a 401
     478   itself with a server &mdash; usually, but not necessarily, after receiving a 401
    478479   (Unauthorized) response. Its value consists of credentials containing
    479480   information of the user agent for the realm of the resource being
Note: See TracChangeset for help on using the changeset viewer.