Changeset 2147


Ignore:
Timestamp:
Jan 20, 2013, 11:43:33 PM (7 years ago)
Author:
fielding@…
Message:

(editorial) Fix a few cases where the term payload is used beyond the scope of a message

Location:
draft-ietf-httpbis/latest
Files:
11 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p0-introduction.html

    r2116 r2147  
    393393  }
    394394  @bottom-center {
    395        content: "Expires July 16, 2013";
     395       content: "Expires July 24, 2013";
    396396  }
    397397  @bottom-right {
     
    426426      <meta name="dct.creator" content="Reschke, J. F.">
    427427      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p0-introduction-latest">
    428       <meta name="dct.issued" scheme="ISO8601" content="2013-01-12">
     428      <meta name="dct.issued" scheme="ISO8601" content="2013-01-20">
    429429      <meta name="dct.abstract" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1.">
    430430      <meta name="description" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1.">
     
    446446            </tr>
    447447            <tr>
    448                <td class="left">Expires: July 16, 2013</td>
     448               <td class="left">Expires: July 24, 2013</td>
    449449               <td class="right">W3C</td>
    450450            </tr>
     
    467467            <tr>
    468468               <td class="left"></td>
    469                <td class="right">January 12, 2013</td>
     469               <td class="right">January 20, 2013</td>
    470470            </tr>
    471471         </tbody>
     
    490490         in progress”.
    491491      </p>
    492       <p>This Internet-Draft will expire on July 16, 2013.</p>
     492      <p>This Internet-Draft will expire on July 24, 2013.</p>
    493493      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    494494      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
  • draft-ietf-httpbis/latest/p1-messaging.html

    r2146 r2147  
    13721372         forming the message body.
    13731373      </p>
    1374       <p id="rfc.section.3.3.1.p.6">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and any recipient along the request/response chain <em class="bcp14">MAY</em> decode the received transfer coding(s) or apply additional transfer coding(s) to the message body, assuming that corresponding
     1374      <p id="rfc.section.3.3.1.p.6">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the representation, and any recipient along the request/response
     1375         chain <em class="bcp14">MAY</em> decode the received transfer coding(s) or apply additional transfer coding(s) to the message body, assuming that corresponding
    13751376         changes are made to the Transfer-Encoding field-value. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    13761377      </p>
     
    14141415      </p>
    14151416      <p id="rfc.section.3.3.2.p.11">Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of
    1416          an HTTP payload, recipients <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (<a href="#attack.protocol.element.size.overflows" title="Buffer Overflows">Section&nbsp;8.3</a>).
     1417         a payload, recipients <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (<a href="#attack.protocol.element.size.overflows" title="Buffer Overflows">Section&nbsp;8.3</a>).
    14171418      </p>
    14181419      <p id="rfc.section.3.3.2.p.12">If a message is received that has multiple Content-Length header fields with field-values consisting of the same decimal value,
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2146 r2147  
    15351535<t>
    15361536   Unlike <x:ref>Content-Encoding</x:ref> (&content-codings;),
    1537    Transfer-Encoding is a property of the message, not of the payload, and
     1537   Transfer-Encoding is a property of the message, not of the representation, and
    15381538   any recipient along the request/response chain &MAY; decode the received
    15391539   transfer coding(s) or apply additional transfer coding(s) to the message
     
    16361636<t>
    16371637   Any Content-Length field value greater than or equal to zero is valid.
    1638    Since there is no predefined limit to the length of an HTTP payload,
     1638   Since there is no predefined limit to the length of a payload,
    16391639   recipients &SHOULD; anticipate potentially large decimal numerals and
    16401640   prevent parsing errors due to integer conversion overflows
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2132 r2147  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 23, 2013";
     451       content: "Expires July 24, 2013";
    452452  }
    453453  @bottom-right {
     
    494494      <meta name="dct.creator" content="Reschke, J. F.">
    495495      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    496       <meta name="dct.issued" scheme="ISO8601" content="2013-01-19">
     496      <meta name="dct.issued" scheme="ISO8601" content="2013-01-20">
    497497      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    498498      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
     
    522522            <tr>
    523523               <td class="left">Intended status: Standards Track</td>
    524                <td class="right">January 19, 2013</td>
     524               <td class="right">January 20, 2013</td>
    525525            </tr>
    526526            <tr>
    527                <td class="left">Expires: July 23, 2013</td>
     527               <td class="left">Expires: July 24, 2013</td>
    528528               <td class="right"></td>
    529529            </tr>
     
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on July 23, 2013.</p>
     555      <p>This Internet-Draft will expire on July 24, 2013.</p>
    556556      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    557557      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    10111011         not be restated in Content-Encoding even if it happens to be the same algorithm as one of the content codings. Such a content
    10121012         coding would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise,
    1013          an origin server might choose to publish the same payload data as multiple representations that differ only in whether the
    1014          coding is defined as part of <a href="#header.content-type" class="smpl">Content-Type</a> or Content-Encoding, since some user agents will behave differently in their handling of each response (e.g., open a "Save
     1013         an origin server might choose to publish the same data as multiple representations that differ only in whether the coding
     1014         is defined as part of <a href="#header.content-type" class="smpl">Content-Type</a> or Content-Encoding, since some user agents will behave differently in their handling of each response (e.g., open a "Save
    10151015         as ..." dialog instead of automatic decompression and rendering of content).
    10161016      </p>
     
    10591059         or the recipient to determine, an identifier for a resource corresponding to that representation.
    10601060      </p>
    1061       <p id="rfc.section.3.1.4.1.p.2">The following rules are used to determine such a URI for the payload of a request message: </p>
     1061      <p id="rfc.section.3.1.4.1.p.2">For a request message: </p>
    10621062      <ul>
    10631063         <li>If the request has a <a href="#header.content-location" class="smpl">Content-Location</a> header field, then the sender asserts that the payload is a representation of the resource identified by the Content-Location
     
    10671067         <li>Otherwise, the payload is unidentified.</li>
    10681068      </ul>
    1069       <p id="rfc.section.3.1.4.1.p.3">The following rules, to be applied in order until a match is found, are used to determine such a URI for the payload of a
    1070          response message:
    1071       </p>
     1069      <p id="rfc.section.3.1.4.1.p.3">For a response message, the following rules are applied in order until a match is found: </p>
    10721070      <ol>
    1073          <li>If the request is GET or HEAD and the response status code is <a href="#status.200" class="smpl">200 (OK)</a>, <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a>, the payload's identifier is the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    1074          </li>
    1075          <li>If the request is GET or HEAD and the response status code is <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a>, the payload is intended to be a representation of the <a href="#resources" class="smpl">target resource</a> that has been modified by an intermediary.
    1076          </li>
    1077          <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to the same URI as the effective request URI, the payload's identifier is
    1078             the effective request URI.
     1071         <li>If the request is GET or HEAD and the response status code is <a href="#status.200" class="smpl">200 (OK)</a>, <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a>, the payload is a representation of the resource identified by the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
     1072         </li>
     1073         <li>If the request is GET or HEAD and the response status code is <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a>, the payload is a potentially modified or enhanced representation of the <a href="#resources" class="smpl">target resource</a> as provided by an intermediary.
     1074         </li>
     1075         <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to the same URI as the effective request URI, the payload is a representation
     1076            of the resource identified by the effective request URI.
    10791077         </li>
    10801078         <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to a URI different from the effective request URI, then the sender asserts
     
    10861084      <div id="rfc.iref.c.7"></div>
    10871085      <h4 id="rfc.section.3.1.4.2"><a href="#rfc.section.3.1.4.2">3.1.4.2</a>&nbsp;<a id="header.content-location" href="#header.content-location">Content-Location</a></h4>
    1088       <p id="rfc.section.3.1.4.2.p.1">The "Content-Location" header field references a URI that can be used as a specific identifier for the representation in this
    1089          message payload. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a <a href="#status.200" class="smpl">200 (OK)</a> response would contain the same representation that is enclosed as payload in this message.
     1086      <p id="rfc.section.3.1.4.2.p.1">The "Content-Location" header field references a URI that can be used as an identifier for a specific resource corresponding
     1087         to the representation in this message's payload. In other words, if one were to perform a GET request on this URI at the time
     1088         of this message's generation, then a <a href="#status.200" class="smpl">200 (OK)</a> response would contain the same representation that is enclosed as payload in this message.
    10901089      </p>
    10911090      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.14"></span>  <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#imported.abnf" class="smpl">absolute-URI</a> / <a href="#imported.abnf" class="smpl">partial-URI</a>
     
    11011100      </p>
    11021101      <p id="rfc.section.3.1.4.2.p.5">If Content-Location is included in a <a href="#status.2xx" class="smpl">2xx (Successful)</a> response message and its field-value refers to a URI that differs from the effective request URI, then the origin server claims
    1103          that the field-value is an identifier for the representation enclosed as the payload. Such a claim can only be trusted if
    1104          both identifiers share the same resource owner, which cannot be programmatically determined via HTTP.
     1102         that the URI is an identifier for a different resource corresponding to the enclosed representation. Such a claim can only
     1103         be trusted if both identifiers share the same resource owner, which cannot be programmatically determined via HTTP.
    11051104      </p>
    11061105      <ul>
     
    11691168               <tr>
    11701169                  <td class="left">Content-Range</td>
    1171                   <td class="left"><a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
     1170                  <td class="left"><a href="p5-range.html#header.content-range" title="Content-Range">Section 4.4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    11721171               </tr>
    11731172               <tr>
     
    13901389         to be refreshed without requiring multiple requests or transferring data already held by the client.
    13911390      </p>
    1392       <p id="rfc.section.4.3.1.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#Part5" id="rfc.xref.Part5.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>). A partial GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations
     1391      <p id="rfc.section.4.3.1.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a <a href="p5-range.html#header.range" class="smpl">Range</a> header field (<a href="#Part5" id="rfc.xref.Part5.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>). A partial GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>. The partial GET request is intended to reduce unnecessary network usage by allowing partially-retrieved representations
    13931392         to be completed without transferring data already held by the client.
    13941393      </p>
     
    14961495         the related resources.
    14971496      </p>
    1498       <p id="rfc.section.4.3.4.p.11">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header field (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>), since it might be misinterpreted as partial content (or might be partial content that is being mistakenly PUT as a full
     1497      <p id="rfc.section.4.3.4.p.11">An origin server <em class="bcp14">SHOULD</em> reject any PUT request that contains a <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header field (<a href="p5-range.html#header.content-range" title="Content-Range">Section 4.4</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>), since it might be misinterpreted as partial content (or might be partial content that is being mistakenly PUT as a full
    14991498         representation). Partial content updates are possible by targeting a separately identified resource with state that overlaps
    15001499         a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for
     
    16481647               <tr>
    16491648                  <td class="left">Range</td>
    1650                   <td class="left"><a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
     1649                  <td class="left"><a href="p5-range.html#header.range" title="Range">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    16511650               </tr>
    16521651               <tr>
     
    17751774               <tr>
    17761775                  <td class="left">If-Range</td>
    1777                   <td class="left"><a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
     1776                  <td class="left"><a href="p5-range.html#header.if-range" title="If-Range">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    17781777               </tr>
    17791778            </tbody>
     
    21672166      </ul>
    21682167      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2>
    2169       <p id="rfc.section.6.1.p.1">The status codes listed below are defined in this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the
     2168      <p id="rfc.section.6.1.p.1">The status codes listed below are defined in this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#range.response" title="Responses to a Range Request">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the
    21702169         protocol.
    21712170      </p>
     
    22232222                  <td class="left">206</td>
    22242223                  <td class="left">Partial Content</td>
    2225                   <td id="status.206" class="left"><a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
     2224                  <td id="status.206" class="left"><a href="p5-range.html#status.206" title="206 Partial Content">Section 4.2</a> of <a href="#Part5" id="rfc.xref.Part5.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    22262225               </tr>
    22272226               <tr>
     
    23432342                  <td class="left">416</td>
    23442343                  <td class="left">Range Not Satisfiable</td>
    2345                   <td id="status.416" class="left"><a href="p5-range.html#status.416" title="416 Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
     2344                  <td id="status.416" class="left"><a href="p5-range.html#status.416" title="416 Range Not Satisfiable">Section 4.3</a> of <a href="#Part5" id="rfc.xref.Part5.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    23462345               </tr>
    23472346               <tr>
     
    31183117               <tr>
    31193118                  <td class="left">Accept-Ranges</td>
    3120                   <td class="left"><a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> of <a href="#Part5" id="rfc.xref.Part5.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
     3119                  <td class="left"><a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 2.3</a> of <a href="#Part5" id="rfc.xref.Part5.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    31213120               </tr>
    31223121               <tr>
     
    35453544      </p>
    35463545      <p id="rfc.section.8.3.1.p.4">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed
    3547          in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the
    3548          quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
     3546         in the field-value. Typically, components that might contain a comma are protected with double-quotes using the quoted-string
     3547         ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    35493548      </p>
    35503549      <p id="rfc.section.8.3.1.p.5">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like
     
    46464645                  </li>
    46474646                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.1.1.4</a>, <a href="#rfc.xref.Part5.2">3.3</a>, <a href="#rfc.xref.Part5.3">4.3.1</a>, <a href="#rfc.xref.Part5.4">4.3.1</a>, <a href="#rfc.xref.Part5.5">4.3.4</a>, <a href="#rfc.xref.Part5.6">5.1</a>, <a href="#rfc.xref.Part5.7">5.2</a>, <a href="#rfc.xref.Part5.8">6.1</a>, <a href="#rfc.xref.Part5.9">6.1</a>, <a href="#rfc.xref.Part5.10">6.1</a>, <a href="#rfc.xref.Part5.11">7.4</a>, <a href="#rfc.xref.Part5.12">8.1.2</a>, <a href="#Part5"><b>11.1</b></a>, <a href="#rfc.xref.Part5.13">A.6</a><ul>
    4648                         <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.8">6.1</a></li>
    4649                         <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.9">6.1</a></li>
    4650                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.10">6.1</a></li>
    4651                         <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.11">7.4</a></li>
    4652                         <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.2">3.3</a>, <a href="#rfc.xref.Part5.5">4.3.4</a></li>
    4653                         <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.7">5.2</a></li>
    4654                         <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.4">4.3.1</a>, <a href="#rfc.xref.Part5.6">5.1</a></li>
     4647                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.11">7.4</a></li>
     4648                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.4">4.3.1</a>, <a href="#rfc.xref.Part5.6">5.1</a></li>
     4649                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.7">5.2</a></li>
     4650                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.8">6.1</a></li>
     4651                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.9">6.1</a></li>
     4652                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.10">6.1</a></li>
     4653                        <li><em>Section 4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.2">3.3</a>, <a href="#rfc.xref.Part5.5">4.3.4</a></li>
    46554654                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.13">A.6</a></li>
    46564655                     </ul>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2132 r2147  
    8383  <!ENTITY status-416                 "<xref target='Part5' x:rel='#status.416' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    8484  <!ENTITY p4-status-codes            "<xref target='Part4' x:rel='#status.code.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    85   <!ENTITY p5-status-codes            "<xref target='Part5' x:rel='#status.code.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     85  <!ENTITY p5-status-codes            "<xref target='Part5' x:rel='#range.response' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    8686  <!ENTITY p7-status-codes            "<xref target='Part7' x:rel='#status.code.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    8787  <!ENTITY p6-heuristic               "<xref target='Part6' x:rel='#heuristic.freshness' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    598598   for some bizarre reason, it is applied a second time to form the
    599599   representation.  Likewise, an origin server might choose to publish the
    600    same payload data as multiple representations that differ only in whether
     600   same data as multiple representations that differ only in whether
    601601   the coding is defined as part of <x:ref>Content-Type</x:ref> or
    602602   Content-Encoding, since some user agents will behave differently in their
     
    701701</t>
    702702<t>
    703    The following rules are used to determine such a URI for the payload of a
    704    request message:
     703   For a request message:
    705704   <list style="symbols">
    706705      <t>If the request has a <x:ref>Content-Location</x:ref> header field,
     
    714713</t>
    715714<t>
    716    The following rules, to be applied in order until a match is found, are
    717    used to determine such a URI for the payload of a response message:
     715   For a response message, the following rules are applied in order until a
     716   match is found:
    718717   <list style="numbers">
    719718      <t>If the request is GET or HEAD and the response status code is
     
    722721         <x:ref>206 (Partial Content)</x:ref>, or
    723722         <x:ref>304 (Not Modified)</x:ref>,
    724          the payload's identifier is the effective request URI
    725          (&effective-request-uri;).</t>
     723         the payload is a representation of the resource identified by the
     724         effective request URI (&effective-request-uri;).</t>
    726725      <t>If the request is GET or HEAD and the response status code is
    727726         <x:ref>203 (Non-Authoritative Information)</x:ref>, the payload is
    728          intended to be a representation of the <x:ref>target resource</x:ref>
    729          that has been modified by an intermediary.</t>
     727         a potentially modified or enhanced representation of the
     728         <x:ref>target resource</x:ref> as provided by an intermediary.</t>
    730729      <t>If the response has a <x:ref>Content-Location</x:ref> header field
    731730         and its field-value is a reference to the same URI as the effective
    732          request URI, the payload's identifier is the effective request URI.</t>
     731         request URI, the payload is a representation of the resource
     732         identified by the effective request URI.</t>
    733733      <t>If the response has a <x:ref>Content-Location</x:ref> header field
    734734         and its field-value is a reference to a URI different from the
     
    747747<t>
    748748   The "Content-Location" header field references a URI that can be used
    749    as a specific identifier for the representation in this message payload.
    750    In other words, if one were to perform a GET on this URI at the time
     749   as an identifier for a specific resource corresponding to the
     750   representation in this message's payload.
     751   In other words, if one were to perform a GET request on this URI at the time
    751752   of this message's generation, then a <x:ref>200 (OK)</x:ref> response would
    752753   contain the same representation that is enclosed as payload in this message.
     
    780781   If Content-Location is included in a <x:ref>2xx (Successful)</x:ref>
    781782   response message and its field-value refers to a URI that differs from the
    782    effective request URI, then the origin server claims that the field-value
    783    is an identifier for the representation enclosed as the payload. Such a
    784    claim can only be trusted if both identifiers share the same resource
    785    owner, which cannot be programmatically determined via HTTP.
     783   effective request URI, then the origin server claims that the URI
     784   is an identifier for a different resource corresponding to the enclosed
     785   representation. Such a claim can only be trusted if both identifiers share
     786   the same resource owner, which cannot be programmatically determined via
     787   HTTP.
    786788   <list style="symbols">
    787789    <t>For a response to a GET or HEAD request, this is an indication that the
     
    45204522<t>
    45214523   Because commas (",") are used as a generic delimiter between field-values,
    4522    they need to be treated with care if they are allowed in the field-value's
    4523    payload. Typically, components that might contain a comma are protected with
    4524    double-quotes using the quoted-string ABNF production (&field-components;). 
     4524   they need to be treated with care if they are allowed in the field-value.
     4525   Typically, components that might contain a comma are protected with
     4526   double-quotes using the quoted-string ABNF production (&field-components;).
    45254527</t>
    45264528<t>
  • draft-ietf-httpbis/latest/p4-conditional.html

    r2137 r2147  
    672672         is changed (e.g., <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a>), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored
    673673         responses held by remote caches and authoring tools. A strong validator is unique across all representations of a given resource,
    674          such that no two representations of that resource share the same validator unless their payload body would be identical.
     674         such that no two representations of that resource can share the same validator unless their representation data is identical.
    675675      </p>
    676676      <p id="rfc.section.2.1.p.4">Cache entries might persist for arbitrarily long periods, regardless of expiration times. Thus, a cache might attempt to validate
     
    707707      </p>
    708708      <p id="rfc.section.2.1.p.9">A "use" of a validator occurs when either a client generates a request and includes the validator in a precondition or when
    709          a server compares two validators. Weak validators are only usable in contexts that do not depend on exact equality of a representation's
    710          payload body. Strong validators are usable and preferred for all conditional requests, including cache validation, partial
    711          content ranges, and "lost update" avoidance.
     709         a server compares two validators. Weak validators are only usable in contexts that do not depend on exact equality of the
     710         representation data. Strong validators are usable and preferred for all conditional requests, including cache validation,
     711         partial content ranges, and "lost update" avoidance.
    712712      </p>
    713713      <div id="rfc.iref.l.1"></div>
     
    999999</pre><p id="rfc.section.3.3.p.3">An example of the field is:</p>
    10001000      <div id="rfc.figure.u.13"></div><pre class="text">  If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    1001 </pre><p id="rfc.section.3.3.p.5">A GET method with an If-Modified-Since header field and no <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> header field requests that the selected representation be transferred only if it has been modified since the date given by
     1001</pre><p id="rfc.section.3.3.p.5">A GET method with an If-Modified-Since header field and no <a href="p5-range.html#header.range" class="smpl">Range</a> header field requests that the selected representation be transferred only if it has been modified since the date given by
    10021002         the If-Modified-Since header field. The algorithm for determining this includes the following cases:
    10031003      </p>
     
    10411041      </p>
    10421042      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="header.if-range" href="#header.if-range">If-Range</a></h2>
    1043       <p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar to <a href="#header.if-match" class="smpl">If-Match</a> and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> but specific to range requests. If-Range is defined in <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>.
     1043      <p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar to <a href="#header.if-match" class="smpl">If-Match</a> and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> but specific to range requests. If-Range is defined in <a href="p5-range.html#header.if-range" title="If-Range">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>.
    10441044      </p>
    10451045      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="status.code.definitions" href="#status.code.definitions">Status Code Definitions</a></h1>
     
    11071107            </ul>
    11081108         </li>
    1109          <li>When the method is GET and both <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> and <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> are present, evaluate If-Range:
     1109         <li>When the method is GET and both <a href="p5-range.html#header.range" class="smpl">Range</a> and <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> are present, evaluate If-Range:
    11101110            <ul>
    11111111               <li>if the validator matches and the Range specification is applicable to the selected representation, respond <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>  <a href="#Part5" id="rfc.xref.Part5.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></li>
     
    14511451                  </li>
    14521452                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.5</a>, <a href="#rfc.xref.Part5.2">5</a>, <a href="#Part5"><b>9.1</b></a><ul>
    1453                         <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.5</a></li>
     1453                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.5</a></li>
    14541454                     </ul>
    14551455                  </li>
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r2137 r2147  
    220220   the stored responses held by remote caches and authoring tools. A strong
    221221   validator is unique across all representations of a given resource, such
    222    that no two representations of that resource share the same validator
    223    unless their payload body would be identical.
     222   that no two representations of that resource can share the same validator
     223   unless their representation data is identical.
    224224</t>
    225225<t>
     
    289289   compares two validators.
    290290   Weak validators are only usable in contexts that do not depend on exact
    291    equality of a representation's payload body.
     291   equality of the representation data.
    292292   Strong validators are usable and preferred for all conditional requests,
    293293   including cache validation, partial content ranges, and "lost update"
  • draft-ietf-httpbis/latest/p5-range.html

    r2145 r2147  
    713713         is satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> send a response with a <a href="#status.416" class="smpl">416 (Range Not Satisfiable)</a> status code. Otherwise, the server <em class="bcp14">SHOULD</em> send a response with a <a href="#status.206" class="smpl">206 (Partial Content)</a> status code containing the satisfiable ranges of the representation.
    714714      </p>
    715       <p id="rfc.section.2.1.p.13">In the byte range syntax, <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a>, <a href="#rule.ranges-specifier" class="smpl">last-byte-pos</a>, and <a href="#rule.ranges-specifier" class="smpl">suffix-length</a> are expressed as decimal number of octets. Since there is no predefined limit to the length of an HTTP payload, recipients <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows.
     715      <p id="rfc.section.2.1.p.13">In the byte range syntax, <a href="#rule.ranges-specifier" class="smpl">first-byte-pos</a>, <a href="#rule.ranges-specifier" class="smpl">last-byte-pos</a>, and <a href="#rule.ranges-specifier" class="smpl">suffix-length</a> are expressed as decimal number of octets. Since there is no predefined limit to the length of a payload, recipients <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows.
    716716      </p>
    717717      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="range.units.other" href="#range.units.other">Other Range Units</a></h2>
     
    834834      <div id="rfc.iref.c.1"></div>
    835835      <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="header.content-range" href="#header.content-range">Content-Range</a></h2>
    836       <p id="rfc.section.4.4.p.1">The "Content-Range" header field is sent with a partial representation to specify where in the full representation the payload
    837          body is intended to be applied.
     836      <p id="rfc.section.4.4.p.1">The "Content-Range" header field is sent with a partial representation to specify what range of the full representation is
     837         enclosed as payload.
    838838      </p>
    839839      <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span>  <a href="#header.content-range" class="smpl">Content-Range</a>       = <a href="#header.content-range" class="smpl">byte-content-range</a>
  • draft-ietf-httpbis/latest/p5-range.xml

    r2145 r2147  
    316316   <x:ref>last-byte-pos</x:ref>, and <x:ref>suffix-length</x:ref> are
    317317   expressed as decimal number of octets.  Since there is no predefined limit
    318    to the length of an HTTP payload, recipients &SHOULD; anticipate
     318   to the length of a payload, recipients &SHOULD; anticipate
    319319   potentially large decimal numerals and prevent parsing errors due to integer
    320320   conversion overflows.
     
    624624<t>
    625625   The "Content-Range" header field is sent with a partial representation to
    626    specify where in the full representation the payload body is intended to be
    627    applied.
     626   specify what range of the full representation is enclosed as payload.
    628627</t>
    629628<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Range"/><iref primary="true" item="Grammar" subitem="byte-content-range"/><iref primary="true" item="Grammar" subitem="byte-range-resp"/><iref primary="true" item="Grammar" subitem="byte-range"/><iref primary="true" item="Grammar" subitem="unsatisfied-range"/><iref primary="true" item="Grammar" subitem="other-content-range"/><iref primary="true" item="Grammar" subitem="other-range-resp"/><iref primary="true" item="Grammar" subitem="complete-length"/>
  • draft-ietf-httpbis/latest/p6-cache.html

    r2116 r2147  
    452452  }
    453453  @bottom-center {
    454        content: "Expires July 16, 2013";
     454       content: "Expires July 24, 2013";
    455455  }
    456456  @bottom-right {
     
    498498      <meta name="dct.creator" content="Reschke, J. F.">
    499499      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    500       <meta name="dct.issued" scheme="ISO8601" content="2013-01-12">
     500      <meta name="dct.issued" scheme="ISO8601" content="2013-01-20">
    501501      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    502502      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
     
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: July 16, 2013</td>
     526               <td class="left">Expires: July 24, 2013</td>
    527527               <td class="right">J. Reschke, Editor</td>
    528528            </tr>
     
    533533            <tr>
    534534               <td class="left"></td>
    535                <td class="right">January 12, 2013</td>
     535               <td class="right">January 20, 2013</td>
    536536            </tr>
    537537         </tbody>
     
    559559         in progress”.
    560560      </p>
    561       <p>This Internet-Draft will expire on July 16, 2013.</p>
     561      <p>This Internet-Draft will expire on July 24, 2013.</p>
    562562      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    563563      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    841841      <p id="rfc.section.3.1.p.1">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is <a href="p2-semantics.html#status.200" class="smpl">200
    842842            (OK)</a>, and the entire response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="p2-semantics.html#status.200" class="smpl">200
    843             (OK)</a> cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> and <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header fields or if it does not understand the range units used in those fields.
     843            (OK)</a> cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the <a href="p5-range.html#header.range" class="smpl">Range</a> and <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header fields or if it does not understand the range units used in those fields.
    844844      </p>
    845845      <p id="rfc.section.3.1.p.2">A cache <em class="bcp14">MAY</em> complete a stored incomplete response by making a subsequent range request (<a href="#Part5" id="rfc.xref.Part5.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>) and combining the successful response with the stored entry, as defined in <a href="#combining.responses" title="Combining Partial Content">Section&nbsp;4.4</a>. A cache <em class="bcp14">MUST NOT</em> use an incomplete response to answer requests unless the response has been made complete or the request is partial and specifies
     
    11201120      <p id="rfc.section.4.4.p.1">A response might transfer only a partial representation if the connection closed prematurely or if the request used one or
    11211121         more Range specifiers (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>). After several such transfers, a cache might have received several ranges of the same representation. A cache <em class="bcp14">MAY</em> combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the
    1122          same strong validator and the cache complies with the client requirements in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4.2</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>.
     1122         same strong validator and the cache complies with the client requirements in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4.5</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>.
    11231123      </p>
    11241124      <p id="rfc.section.4.4.p.2">When combining the new response with one or more stored responses, a cache <em class="bcp14">MUST</em>:
     
    21562156                  </li>
    21572157                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.1</a>, <a href="#rfc.xref.Part5.2">4.4</a>, <a href="#rfc.xref.Part5.3">4.4</a>, <a href="#Part5"><b>12.1</b></a><ul>
    2158                         <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.3">4.4</a></li>
     2158                        <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.3">4.4</a></li>
    21592159                     </ul>
    21602160                  </li>
  • draft-ietf-httpbis/latest/p7-auth.html

    r2116 r2147  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 16, 2013";
     451       content: "Expires July 24, 2013";
    452452  }
    453453  @bottom-right {
     
    489489      <meta name="dct.creator" content="Reschke, J. F.">
    490490      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    491       <meta name="dct.issued" scheme="ISO8601" content="2013-01-12">
     491      <meta name="dct.issued" scheme="ISO8601" content="2013-01-20">
    492492      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    493493      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.">
     
    517517            <tr>
    518518               <td class="left">Intended status: Standards Track</td>
    519                <td class="right">January 12, 2013</td>
     519               <td class="right">January 20, 2013</td>
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: July 16, 2013</td>
     522               <td class="left">Expires: July 24, 2013</td>
    523523               <td class="right"></td>
    524524            </tr>
     
    546546         in progress”.
    547547      </p>
    548       <p>This Internet-Draft will expire on July 16, 2013.</p>
     548      <p>This Internet-Draft will expire on July 24, 2013.</p>
    549549      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    550550      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset for help on using the changeset viewer.