Changeset 716 for draft-ietf-httpbis/latest

Timestamp:

Oct 22, 2009, 4:13:10 AM (10 years ago)

Author:

julian.reschke@…

Message:

In description of C-L, add a reference to Part 2 where it defines client processing (see #110)

Location:

draft-ietf-httpbis/latest

Files:

• p3-payload.html (modified) (7 diffs)
• p3-payload.xml (modified) (3 diffs)

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

@@ -407 +407 @@
       <meta name="DC.Creator" content="Reschke, J. F.">
       <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
-      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-10-14">
+      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-10-22">
       <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
       <meta name="DC.Description.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.">
@@ -439 +439 @@
          </tr>
          <tr>
-            <td class="header left">Expires: April 17, 2010</td>
+            <td class="header left">Expires: April 25, 2010</td>
             <td class="header right">HP</td>
          </tr>
@@ -492 +492 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">October 14, 2009</td>
+            <td class="header right">October 22, 2009</td>
          </tr>
       </table>
@@ -516 +516 @@
       <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
       </p>
-      <p>This Internet-Draft will expire in April 17, 2010.</p>
+      <p>This Internet-Draft will expire in April 25, 2010.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1299 +1299 @@
          the resource corresponding to this particular entity at the time of the request. Future requests <em class="bcp14">MAY</em> specify the Content-Location URI as the request-target if the desire is to identify the source of that particular entity.
       </p>
-      <p id="rfc.section.5.7.p.5">A cache cannot assume that an entity with a Content-Location different from the URI used to retrieve it can be used to respond
+      <p id="rfc.section.5.7.p.5"> <a href="p2-semantics.html#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section 6.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> describes how clients may process the Content-Location header field.
+      </p>
+      <p id="rfc.section.5.7.p.6">A cache cannot assume that an entity with a Content-Location different from the URI used to retrieve it can be used to respond
          to later requests on that Content-Location URI. However, the Content-Location can be used to differentiate between multiple
          entities retrieved from a single requested resource, as described in <a href="p6-cache.html#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.6</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
       </p>
-      <p id="rfc.section.5.7.p.6">If the Content-Location is a relative URI, the relative URI is interpreted relative to the request-target.</p>
-      <p id="rfc.section.5.7.p.7">The meaning of the Content-Location header in requests is undefined; servers are free to ignore it in those cases.</p>
+      <p id="rfc.section.5.7.p.7">If the Content-Location is a relative URI, the relative URI is interpreted relative to the request-target.</p>
+      <p id="rfc.section.5.7.p.8">The meaning of the Content-Location header in requests is undefined; servers are free to ignore it in those cases.</p>
       <div id="rfc.iref.c.10"></div>
       <div id="rfc.iref.h.8"></div>
@@ -2027 +2029 @@
       <ul>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/13">http://tools.ietf.org/wg/httpbis/trac/ticket/13</a>&gt;: "Updated reference for language tags"
+         </li>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/110">http://tools.ietf.org/wg/httpbis/trac/ticket/110</a>&gt;: "Clarify rules for determining what entities a response carries"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/154">http://tools.ietf.org/wg/httpbis/trac/ticket/154</a>&gt;: "Content-Location base-setting problems"
@@ -2198 +2202 @@
                      </ul>
                   </li>
-                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">4.1</a>, <a class="iref" href="#Part2"><b>9.1</b></a><ul class="ind">
+                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">4.1</a>, <a class="iref" href="#rfc.xref.Part2.2">5.7</a>, <a class="iref" href="#Part2"><b>9.1</b></a><ul class="ind">
+                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.2">5.7</a></li>
                         <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">4.1</a></li>
                      </ul>

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

@@ -36 +36 @@
   <!ENTITY deflate-coding           "<xref target='Part1' x:rel='#deflate.coding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY gzip-coding              "<xref target='Part1' x:rel='#gzip.coding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY response-representation  "<xref target='Part2' x:rel='#identifying.response.associated.with.representation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
 ]>
 <?rfc toc="yes" ?>
@@ -1466 +1467 @@
    if the desire is to identify the source of that particular
    entity.
+</t>
+<t>
+   &response-representation; describes how clients may process the Content-Location header field.
 </t>
 <t>
@@ -3068 +3072 @@
     </t>
     <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/110"/>:
+      "Clarify rules for determining what entities a response carries"
+    </t>
+    <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/154"/>:
       "Content-Location base-setting problems"