Changeset 2180 for draft-ietf-httpbis/latest/p2-semantics.html

Timestamp:

11/02/13 09:14:49 (10 years ago)

Author:

julian.reschke@…

Message:

re-gen HTML

File:

• draft-ietf-httpbis/latest/p2-semantics.html (modified) (5 diffs)

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires August 5, 2013"; 
+       content: "Expires August 15, 2013"; 
   } 
   @bottom-right {
@@ -494 +494 @@
       <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="2013-02-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2013-02-11">
       <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. 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.">
@@ -522 +522 @@
             <tr>
                <td class="left">Intended status: Standards Track</td>
-               <td class="right">February 1, 2013</td>
+               <td class="right">February 11, 2013</td>
             </tr>
             <tr>
-               <td class="left">Expires: August 5, 2013</td>
+               <td class="left">Expires: August 15, 2013</td>
                <td class="right"></td>
             </tr>
@@ -553 +553 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on August 5, 2013.</p>
+      <p>This Internet-Draft will expire on August 15, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -3302 +3302 @@
          to indicate the class of the proposed status code(s) without consuming a number prematurely.
       </p>
-      <p id="rfc.section.8.2.2.p.4">A definition for a new status code ought to explain the request conditions that would cause a response containing that status
+      <p id="rfc.section.8.2.2.p.4">The definition of a new status code ought to explain the request conditions that would cause a response containing that status
          code (e.g., combinations of request header fields and/or method(s)) along with any dependencies on response header fields
          (e.g., what fields are required, what fields can modify the semantics, and what header field semantics are further refined
          when used with the new status code).
       </p>
-      <p id="rfc.section.8.2.2.p.5">A response that can transfer a payload ought to specify expected cache behavior (e.g., cacheability and freshness criteria,
-         as described in <a href="#Part6" id="rfc.xref.Part6.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) and whether the payload has any implied association with an identified resource (<a href="#identifying.payload" title="Identifying a Representation">Section&nbsp;3.1.4.1</a>).
+      <p id="rfc.section.8.2.2.p.5">The definition of a new status code ought to specify whether or not it is cacheable. Note that all status codes can be cached
+         if the response they occur in has explicit freshness information; however, status codes that are defined as being cacheable
+         are allowed to be cached without explicit freshness information. Likewise, the definition of a status code can place constraints
+         upon cache behaviour. See <a href="#Part6" id="rfc.xref.Part6.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> for more information.
+      </p>
+      <p id="rfc.section.8.2.2.p.6">Finally, the definition of a new status code ought to indicate whether the payload has any implied association with an identified
+         resource (<a href="#identifying.payload" title="Identifying a Representation">Section&nbsp;3.1.4.1</a>).
       </p>
       <h3 id="rfc.section.8.2.3"><a href="#rfc.section.8.2.3">8.2.3</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Registrations</a></h3>