Changeset 972

Timestamp:

02/08/10 13:20:54 (12 years ago)

Author:

julian.reschke@…

Message:

lowercase "effective request URI" throughout, use "target resource" instead of "resource identified by the effective request URI" where possible.

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (5 diffs)
• p1-messaging.xml (modified) (1 diff)
• p2-semantics.html (modified) (13 diffs)
• p2-semantics.xml (modified) (9 diffs)
• p3-payload.html (modified) (5 diffs)
• p3-payload.xml (modified) (1 diff)
• p4-conditional.html (modified) (5 diffs)
• p4-conditional.xml (modified) (1 diff)
• p5-range.html (modified) (4 diffs)
• p6-cache.html (modified) (5 diffs)
• p6-cache.xml (modified) (1 diff)
• p7-auth.html (modified) (4 diffs)

draft-ietf-httpbis/latest/p1-messaging.html

@@ -404 +404 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2010-08-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-08-02">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -435 +435 @@
             </tr>
             <tr>
-               <td class="left">Expires: February 2, 2011</td>
+               <td class="left">Expires: February 3, 2011</td>
                <td class="right">HP</td>
             </tr>
@@ -488 +488 @@
             <tr>
                <td class="left"></td>
-               <td class="right">August 1, 2010</td>
+               <td class="right">August 2, 2010</td>
             </tr>
          </tbody>
@@ -516 +516 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on February 2, 2011.</p>
+      <p>This Internet-Draft will expire on February 3, 2011.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1434 +1434 @@
          <li>the request-target obtained from the Request-Line, unless the request-target is just the asterisk "*".</li>
       </ul>
-      <p id="rfc.section.4.3.p.5">Otherwise, when request-target uses the authority form, the Effective Request URI is undefined.</p>
+      <p id="rfc.section.4.3.p.5">Otherwise, when request-target uses the authority form, the effective Request URI is undefined.</p>
       <div id="rfc.figure.u.40"></div> 
       <p>Example 1: the effective request URI for the message</p>  <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1

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

@@ -1709 +1709 @@
 </t>
 <t>
-   Otherwise, when request-target uses the authority form, the Effective
+   Otherwise, when request-target uses the authority form, the effective
    Request URI is undefined.
 </t>

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

@@ -403 +403 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2010-08-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-08-02">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -434 +434 @@
             </tr>
             <tr>
-               <td class="left">Expires: February 2, 2011</td>
+               <td class="left">Expires: February 3, 2011</td>
                <td class="right">HP</td>
             </tr>
@@ -487 +487 @@
             <tr>
                <td class="left"></td>
-               <td class="right">August 1, 2010</td>
+               <td class="right">August 2, 2010</td>
             </tr>
          </tbody>
@@ -514 +514 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on February 2, 2011.</p>
+      <p>This Internet-Draft will expire on February 3, 2011.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -753 +753 @@
              &lt;WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 3.4</a>&gt;
 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="method" href="#method">Method</a></h1>
-      <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
+      <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
       </p>
       <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span>  <a href="#method" class="smpl">Method</a>         = %x4F.50.54.49.4F.4E.53   ; "OPTIONS", <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section&nbsp;7.2</a>
@@ -881 +881 @@
       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1>
       <p id="rfc.section.5.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the
-         Status-Line. These header fields give information about the server and about further access to the resource identified by
-         the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
+         Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
       </p>
       <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#response.header.fields" class="smpl">response-header</a> = <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a>           ; <a href="#Part5" id="rfc.xref.Part5.9"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a>
@@ -909 +908 @@
       <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
       <p id="rfc.section.6.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p>
-      <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the effective request URI (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
+      <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
          rules are used (with the first applicable one being selected):
       </p>
       <ol>
          <li>If the response status code is 200 or 203 and the request method was GET, the response payload is a representation of the
-            resource identified by the effective request URI.
+            target resource.
          </li>
          <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial
-            representation of the resource identified by the effective request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
+            representation of the target (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
          </li>
          <li>If the response has a Content-Location header, and that URI is the same as the effective request URI, the response payload
-            is a representation of the resource identified by the effective request URI.
+            is a representation of the target resource.
          </li>
          <li>If the response has a Content-Location header, and that URI is not the same as the effective request URI, then the response
@@ -984 +983 @@
       <div id="rfc.iref.g.8"></div>
       <div id="rfc.iref.m.2"></div>
-      <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of a representation) currently corresponds to the resource
-         identified by the effective request URI.
-      </p>
-      <p id="rfc.section.7.3.p.2">If the effective request URI identifies a data-producing process, it is the produced data which shall be returned as the representation
+      <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of a representation) currently corresponds to the target resource.</p>
+      <p id="rfc.section.7.3.p.2">If the target resource is a data-producing process, it is the produced data which shall be returned as the representation
          in the response and not the source text of the process, unless that text happens to be the output of the process.
       </p>
@@ -1019 +1016 @@
       <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="POST" href="#POST">POST</a></h2>
       <p id="rfc.section.7.5.p.1">The POST method is used to request that the origin server accept the representation enclosed in the request as data to be
-         processed by the resource identified by the effective request URI. POST is designed to allow a uniform method to cover the
-         following functions: 
+         processed by the target resource. POST is designed to allow a uniform method to cover the following functions: 
       </p>
       <ul>
@@ -1038 +1034 @@
          a Location header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;9.4</a>).
       </p>
-      <p id="rfc.section.7.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the Effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
+      <p id="rfc.section.7.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
       </p>
       <p id="rfc.section.7.5.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent
@@ -1054 +1050 @@
          Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request.
       </p>
-      <p id="rfc.section.7.6.p.3">If the resource identified by the effective request URI could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
+      <p id="rfc.section.7.6.p.3">If the target resource could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
       </p>
       <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the effective request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable.
@@ -1075 +1071 @@
       <div id="rfc.iref.m.6"></div>
       <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a>&nbsp;<a id="DELETE" href="#DELETE">DELETE</a></h2>
-      <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the effective request URI. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation
+      <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the target resource. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation
          has been carried out, even if the status code returned from the origin server indicates that the action has been completed
          successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible
@@ -1145 +1141 @@
       <dl>
          <dt>GET</dt>
-         <dd>a representation of the resource corresponding to the effective request URI is sent in the response;</dd>
+         <dd>a representation of the target resource is sent in the response;</dd>
          <dt>HEAD</dt>
          <dd>the same representation as GET, except without the message-body;</dd>

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

@@ -433 +433 @@
   <x:anchor-alias value="extension-method"/>
 <t>
-   The Method token indicates the method to be performed on the resource
-   identified by the effective request URI (&effective-request-uri;). The
-   method is case-sensitive.
+   The Method token indicates the method to be performed on the target
+   resource (&effective-request-uri;). The method is case-sensitive.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/><iref primary="true" item="Grammar" subitem="extension-method"/>
@@ -634 +633 @@
    information about the response which cannot be placed in the Status-Line.
    These header fields give information about the server and about
-   further access to the resource identified by the effective request URI
-   (&effective-request-uri;).
+   further access to the target resource (&effective-request-uri;).
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="response-header"/>
@@ -684 +682 @@
 </t>
 <t>
-   In the common case, an HTTP response is a representation of the resource
-   located at the effective request URI (see &effective-request-uri;). However,
-   this is not always the case. To determine the URI of the resource a
-   response is associated with, the following rules are used (with the first
-   applicable one being selected):
+   In the common case, an HTTP response is a representation of the target
+   resource (see &effective-request-uri;). However, this is not always the
+   case. To determine the URI of the resource a response is associated with,
+   the following rules are used (with the first applicable one being selected):
 </t>
 <t><list style="numbers">
    <t>If the response status code is 200 or 203 and the request method was GET,
-   the response payload is a representation of the resource identified by the effective request URI.</t>
+   the response payload is a representation of the target resource.</t>
    <t>If the response status code is 204, 206, or 304 and the request method was GET
-   or HEAD, the response payload is a partial representation of the resource identified
-   by the effective request URI (see &caching-combining-headers;).</t>
+   or HEAD, the response payload is a partial representation of the target
+   (see &caching-combining-headers;).</t>
    <t>If the response has a Content-Location header, and that URI is the same
    as the effective request URI, the response payload is a representation of the
-   resource identified by the effective request URI.</t>
+   target resource.</t>
    <t>If the response has a Content-Location header, and that URI is not the
    same as the effective request URI, then the response asserts that its
@@ -833 +830 @@
 <t>
    The GET method means retrieve whatever information (in the form of a
-   representation) currently corresponds to the resource identified by the
-   effective request URI.
+   representation) currently corresponds to the target resource.
 </t>
 <t>   
-   If the effective request URI identifies a data-producing process, it is the
+   If the target resource is a data-producing process, it is the
    produced data which shall be returned as the representation in the response and not
    the source text of the process, unless that text happens to be the output of
@@ -901 +897 @@
 <t>
    The POST method is used to request that the origin server accept the
-   representation enclosed in the request as data to be processed by the resource
-   identified by the effective request URI. POST is designed
-   to allow a uniform method to cover the following functions:
+   representation enclosed in the request as data to be processed by the 
+   target resource. POST is designed to allow a uniform method to cover the
+   following functions:
   <list style="symbols">
     <t>
@@ -942 +938 @@
    include explicit freshness information (see &p6-explicit;). A
    cached POST response with a Content-Location header 
-   (see &header-content-location;) whose value is the Effective 
+   (see &header-content-location;) whose value is the effective 
    Request URI &MAY; be used to satisfy subsequent GET and HEAD requests.
 </t>
@@ -972 +968 @@
 </t>
 <t>   
-   If the resource identified by the effective request URI could not be
-   created or modified, an appropriate error response &SHOULD; be given
-   that reflects the nature of the problem.
+   If the target resource could not be created or modified, an appropriate
+   error response &SHOULD; be given that reflects the nature of the problem.
    The recipient of the representation &MUST-NOT; ignore any Content-*
    headers (headers starting with the prefix "Content-") that it does
@@ -1024 +1019 @@
   <iref primary="true" item="Methods" subitem="DELETE" x:for-anchor=""/>
 <t>
-   The DELETE method requests that the origin server delete the resource
-   identified by the effective request URI. This method &MAY; be overridden by
+   The DELETE method requests that the origin server delete the target
+   resource. This method &MAY; be overridden by
    human intervention (or other means) on the origin server. The client cannot
    be guaranteed that the operation has been carried out, even if the
@@ -1171 +1166 @@
   <list style="hanging">
     <t hangText="GET">
-          a representation of the resource corresponding to the effective
-          request URI is sent in the response;
+          a representation of the target resource is sent in the response;
     </t>
     <t hangText="HEAD">

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

@@ -402 +402 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2010-08-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-08-02">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -428 +428 @@
             </tr>
             <tr>
-               <td class="left">Expires: February 2, 2011</td>
+               <td class="left">Expires: February 3, 2011</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -485 +485 @@
             <tr>
                <td class="left"></td>
-               <td class="right">August 1, 2010</td>
+               <td class="right">August 2, 2010</td>
             </tr>
          </tbody>
@@ -511 +511 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on February 2, 2011.</p>
+      <p>This Internet-Draft will expire on February 3, 2011.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1271 +1271 @@
   <a href="#header.content-location" class="smpl">Content-Location-v</a> =
                     <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
-</pre><p id="rfc.section.6.7.p.3">The Content-Location value is not a replacement for the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
+</pre><p id="rfc.section.6.7.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
          body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients.
       </p>

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

@@ -1431 +1431 @@
 </artwork></figure>
 <t>
-   The Content-Location value is not a replacement for the Effective
+   The Content-Location value is not a replacement for the effective
    Request URI (&effective-request-uri;).  It is representation metadata.
    It has the same syntax and semantics as the header field of the same name

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

@@ -400 +400 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2010-08-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-08-02">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -426 +426 @@
             </tr>
             <tr>
-               <td class="left">Expires: February 2, 2011</td>
+               <td class="left">Expires: February 3, 2011</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -483 +483 @@
             <tr>
                <td class="left"></td>
-               <td class="right">August 1, 2010</td>
+               <td class="right">August 2, 2010</td>
             </tr>
          </tbody>
@@ -509 +509 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on February 2, 2011.</p>
+      <p>This Internet-Draft will expire on February 3, 2011.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -896 +896 @@
       <div id="rfc.iref.h.1"></div>
       <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.etag" href="#header.etag">ETag</a></h2>
-      <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity-Tags">Section&nbsp;2</a>) for one representation of the resource identified by the effective request URI. An entity-tag is intended for use as a resource-local
-         identifier for differentiating between representations of the same resource that vary over time or via content negotiation
-         (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>).
+      <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity-Tags">Section&nbsp;2</a>) for one representation of the target resource. An entity-tag is intended for use as a resource-local identifier for differentiating
+         between representations of the same resource that vary over time or via content negotiation (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>).
       </p>
       <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span>  <a href="#header.etag" class="smpl">ETag</a>   = "ETag" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.etag" class="smpl">ETag-v</a>

draft-ietf-httpbis/latest/p4-conditional.xml

@@ -734 +734 @@
    The "ETag" response-header field provides the current value of the
    entity-tag (see <xref target="entity.tags"/>) for one representation of
-   the resource identified by the effective request URI.  An entity-tag
+   the target resource.  An entity-tag
    is intended for use as a resource-local identifier for differentiating
    between representations of the same resource that vary over time or via

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

@@ -400 +400 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2010-08-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-08-02">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -426 +426 @@
             </tr>
             <tr>
-               <td class="left">Expires: February 2, 2011</td>
+               <td class="left">Expires: February 3, 2011</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -483 +483 @@
             <tr>
                <td class="left"></td>
-               <td class="right">August 1, 2010</td>
+               <td class="right">August 2, 2010</td>
             </tr>
          </tbody>
@@ -509 +509 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on February 2, 2011.</p>
+      <p>This Internet-Draft will expire on February 3, 2011.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

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

@@ -402 +402 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2010-08-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-08-02">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -428 +428 @@
             </tr>
             <tr>
-               <td class="left">Expires: February 2, 2011</td>
+               <td class="left">Expires: February 3, 2011</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -489 +489 @@
             <tr>
                <td class="left"></td>
-               <td class="right">August 1, 2010</td>
+               <td class="right">August 2, 2010</td>
             </tr>
          </tbody>
@@ -515 +515 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on February 2, 2011.</p>
+      <p>This Internet-Draft will expire on February 3, 2011.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -938 +938 @@
       <p id="rfc.section.2.5.p.1">Because unsafe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) have the potential for changing state on the origin server, intervening caches can use them to keep their contents up-to-date.
       </p>
-      <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location headers (if present): 
+      <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location headers (if present): 
       </p>
       <ul>

draft-ietf-httpbis/latest/p6-cache.xml

@@ -854 +854 @@
 </t>
 <t>
-   The following HTTP methods &MUST; cause a cache to invalidate the Effective
+   The following HTTP methods &MUST; cause a cache to invalidate the effective
    Request URI (&effective-request-uri;) as well as the URI(s) in the Location
    and Content-Location headers (if present):

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

@@ -393 +393 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2010-08-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-08-02">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -424 +424 @@
             </tr>
             <tr>
-               <td class="left">Expires: February 2, 2011</td>
+               <td class="left">Expires: February 3, 2011</td>
                <td class="right">HP</td>
             </tr>
@@ -477 +477 @@
             <tr>
                <td class="left"></td>
-               <td class="right">August 1, 2010</td>
+               <td class="right">August 2, 2010</td>
             </tr>
          </tbody>
@@ -503 +503 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on February 2, 2011.</p>
+      <p>This Internet-Draft will expire on February 3, 2011.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>