Changeset 1707 for draft-ietf-httpbis/latest

Timestamp:

03/07/12 17:25:39 (10 years ago)

Author:

julian.reschke@…

Message:

tune conformance requirements (see #271)

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (1 diff)
• p1-messaging.xml (modified) (1 diff)
• p2-semantics.html (modified) (8 diffs)
• p2-semantics.xml (modified) (4 diffs)
• p6-cache.html (modified) (1 diff)
• p6-cache.xml (modified) (1 diff)

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

@@ -818 +818 @@
          <p> <b>Note:</b> The term 'user agent' covers both those situations where there is a user (human) interacting with the software agent (and
             for which user interface or interactive suggestions might be made, e.g., warning the user or given the user an option in the
-            case of security or privacy options) and also those where the software agent may act autonomously.
+            case of security or privacy options) and also those where the software agent can act autonomously.
          </p> 
       </div>

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

@@ -313 +313 @@
     user interface or interactive suggestions might be made, e.g., warning the
     user or given the user an option in the case of security or privacy
-    options) and also those where the software agent may act autonomously.
+    options) and also those where the software agent can act autonomously.
   </t>
 </x:note>

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 2, 2013"; 
+       content: "Expires January 4, 2013"; 
   } 
   @bottom-right {
@@ -497 +497 @@
       <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="2012-07-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-03">
       <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 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. Furthermore, it defines HTTP message content, metadata, and content negotiation.">
@@ -528 +528 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 2, 2013</td>
+               <td class="left">Expires: January 4, 2013</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">July 1, 2012</td>
+               <td class="right">July 3, 2012</td>
             </tr>
          </tbody>
@@ -563 +563 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 2, 2013.</p>
+      <p>This Internet-Draft will expire on January 4, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -941 +941 @@
          can specify that only zero-length bodies (as opposed to absent bodies) are allowed.
       </p>
-      <p id="rfc.section.2.2.1.p.4">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section&nbsp;2.1.1</a>), what semantics (if any) the request body has, and whether they are idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section&nbsp;2.1.2</a>). They also need to state whether they can be cached (<a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>); in particular what conditions a cache may store the response, and under what conditions such a stored response may be used
-         to satisfy a subsequent request.
+      <p id="rfc.section.2.2.1.p.4">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section&nbsp;2.1.1</a>), what semantics (if any) the request body has, and whether they are idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section&nbsp;2.1.2</a>). They also need to state whether they can be cached (<a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>); in particular under what conditions a cache can store the response, and under what conditions such a stored response can
+         be used to satisfy a subsequent request.
       </p>
       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="method.definitions" href="#method.definitions">Method Definitions</a></h2>
@@ -1153 +1153 @@
          to reject the request.
       </p>
-      <p id="rfc.section.2.3.8.p.9">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data may be discarded
-         if the eventual response is negative, and the connection may be reset with no response if more than one TCP segment is outstanding.
+      <p id="rfc.section.2.3.8.p.9">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded
+         if the eventual response is negative, and the connection can be reset with no response if more than one TCP segment is outstanding.
       </p>
       <p id="rfc.section.2.3.8.p.10">It might be the case that the proxy itself can only reach the requested origin server through another proxy. In this case,
@@ -1230 +1230 @@
          </li>
          <li>
-            <p>Whether the header field should be preserved across redirects.</p>
+            <p>Whether the header field ought to be preserved across redirects.</p>
          </li>
       </ul>
@@ -1861 +1861 @@
       <p id="rfc.section.4.5.4.p.1">The 303 status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI
          in the Location header field, that is intended to provide an indirect response to the original request. In order to satisfy
-         the original request, a user agent <em class="bcp14">SHOULD</em> perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which may itself be redirected further,
+         the original request, a user agent <em class="bcp14">SHOULD</em> perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further,
          and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is
          not considered equivalent to the effective request URI.

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

@@ -489 +489 @@
    and whether they are idempotent (<xref target="idempotent.methods"/>). 
    They also need to state whether they can be cached (&caching;); in 
-   particular what conditions a cache may store the response, and under what 
-   conditions such a stored response may be used to satisfy a subsequent 
+   particular under what conditions a cache can store the response, and under
+   what conditions such a stored response can be used to satisfy a subsequent 
    request.
 </t>
@@ -931 +931 @@
    to server &MAY; be sent immediately after the request (before a response
    is received). The usual caveats also apply:
-   data may be discarded if the eventual response is negative, and the
-   connection may be reset with no response if more than one TCP segment
+   data can be discarded if the eventual response is negative, and the
+   connection can be reset with no response if more than one TCP segment
    is outstanding.
 </t>
@@ -1044 +1044 @@
     <x:lt><t>Whether the header field is useful or allowable in trailers (see
     &chunked-encoding;).</t></x:lt>
-    <x:lt><t>Whether the header field should be preserved across redirects.</t></x:lt>
+    <x:lt><t>Whether the header field ought to be preserved across redirects.</t></x:lt>
   </list>
 </t>
@@ -1675 +1675 @@
    request, a user agent &SHOULD; perform a retrieval request using the
    Location URI (a GET or HEAD request if using HTTP), which
-   may itself be redirected further, and present the eventual result as an
+   can itself be redirected further, and present the eventual result as an
    answer to the original request.
    Note that the new URI in the Location header field is not considered

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

@@ -1447 +1447 @@
       <p id="rfc.section.3.2.3.p.3">For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive.
          We define this new directive to mean that, in addition to any private cache, any cache that is shared only by members of the
-         community named within its value may cache the response. An origin server wishing to allow the UCI community to use an otherwise
-         private response in their shared cache(s) could do so by including
+         community named within its value is allowed to cache the response. An origin server wishing to allow the UCI community to
+         use an otherwise private response in their shared cache(s) could do so by including
       </p>
       <div id="rfc.figure.u.10"></div><pre class="text">  Cache-Control: private, community="UCI"

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

@@ -1611 +1611 @@
    this new directive to mean that, in addition to any private cache, any
    cache that is shared only by members of the community named within its
-   value may cache the response. An origin server wishing to allow the UCI
-   community to use an otherwise private response in their shared cache(s)
-   could do so by including
+   value is allowed to cache the response. An origin server wishing to allow
+   the UCI community to use an otherwise private response in their shared
+   cache(s) could do so by including
 </t>
 <figure><artwork type="example">