* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Changeset 1707


Ignore:
Timestamp:
2012-07-03 10:25:39 (2 years ago)
Author:
julian.reschke@gmx.de
Message:

tune conformance requirements (see #271)

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1706 r1707  
    818818         <p> <b>Note:</b> The term 'user agent' covers both those situations where there is a user (human) interacting with the software agent (and 
    819819            for which user interface or interactive suggestions might be made, e.g., warning the user or given the user an option in the 
    820             case of security or privacy options) and also those where the software agent may act autonomously. 
     820            case of security or privacy options) and also those where the software agent can act autonomously. 
    821821         </p>  
    822822      </div> 
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1706 r1707  
    313313    user interface or interactive suggestions might be made, e.g., warning the 
    314314    user or given the user an option in the case of security or privacy 
    315     options) and also those where the software agent may act autonomously. 
     315    options) and also those where the software agent can act autonomously. 
    316316  </t> 
    317317</x:note> 
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1697 r1707  
    449449  }  
    450450  @bottom-center { 
    451        content: "Expires January 2, 2013";  
     451       content: "Expires January 4, 2013";  
    452452  }  
    453453  @bottom-right { 
     
    497497      <meta name="dct.creator" content="Reschke, J. F."> 
    498498      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 
    499       <meta name="dct.issued" scheme="ISO8601" content="2012-07-01"> 
     499      <meta name="dct.issued" scheme="ISO8601" content="2012-07-03"> 
    500500      <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 
    501501      <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."> 
     
    528528            </tr> 
    529529            <tr> 
    530                <td class="left">Expires: January 2, 2013</td> 
     530               <td class="left">Expires: January 4, 2013</td> 
    531531               <td class="right">greenbytes</td> 
    532532            </tr> 
    533533            <tr> 
    534534               <td class="left"></td> 
    535                <td class="right">July 1, 2012</td> 
     535               <td class="right">July 3, 2012</td> 
    536536            </tr> 
    537537         </tbody> 
     
    563563         in progress”. 
    564564      </p> 
    565       <p>This Internet-Draft will expire on January 2, 2013.</p> 
     565      <p>This Internet-Draft will expire on January 4, 2013.</p> 
    566566      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 
    567567      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> 
     
    941941         can specify that only zero-length bodies (as opposed to absent bodies) are allowed. 
    942942      </p> 
    943       <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 
    944          to satisfy a subsequent request. 
     943      <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 
     944         be used to satisfy a subsequent request. 
    945945      </p> 
    946946      <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> 
     
    11531153         to reject the request. 
    11541154      </p> 
    1155       <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 
    1156          if the eventual response is negative, and the connection may be reset with no response if more than one TCP segment is outstanding. 
     1155      <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 
     1156         if the eventual response is negative, and the connection can be reset with no response if more than one TCP segment is outstanding. 
    11571157      </p> 
    11581158      <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, 
     
    12301230         </li> 
    12311231         <li> 
    1232             <p>Whether the header field should be preserved across redirects.</p> 
     1232            <p>Whether the header field ought to be preserved across redirects.</p> 
    12331233         </li> 
    12341234      </ul> 
     
    18611861      <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 
    18621862         in the Location header field, that is intended to provide an indirect response to the original request. In order to satisfy 
    1863          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, 
     1863         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, 
    18641864         and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is 
    18651865         not considered equivalent to the effective request URI. 
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1697 r1707  
    489489   and whether they are idempotent (<xref target="idempotent.methods"/>).  
    490490   They also need to state whether they can be cached (&caching;); in  
    491    particular what conditions a cache may store the response, and under what  
    492    conditions such a stored response may be used to satisfy a subsequent  
     491   particular under what conditions a cache can store the response, and under 
     492   what conditions such a stored response can be used to satisfy a subsequent  
    493493   request. 
    494494</t> 
     
    931931   to server &MAY; be sent immediately after the request (before a response 
    932932   is received). The usual caveats also apply: 
    933    data may be discarded if the eventual response is negative, and the 
    934    connection may be reset with no response if more than one TCP segment 
     933   data can be discarded if the eventual response is negative, and the 
     934   connection can be reset with no response if more than one TCP segment 
    935935   is outstanding. 
    936936</t> 
     
    10441044    <x:lt><t>Whether the header field is useful or allowable in trailers (see 
    10451045    &chunked-encoding;).</t></x:lt> 
    1046     <x:lt><t>Whether the header field should be preserved across redirects.</t></x:lt> 
     1046    <x:lt><t>Whether the header field ought to be preserved across redirects.</t></x:lt> 
    10471047  </list> 
    10481048</t> 
     
    16751675   request, a user agent &SHOULD; perform a retrieval request using the 
    16761676   Location URI (a GET or HEAD request if using HTTP), which 
    1677    may itself be redirected further, and present the eventual result as an 
     1677   can itself be redirected further, and present the eventual result as an 
    16781678   answer to the original request. 
    16791679   Note that the new URI in the Location header field is not considered 
  • draft-ietf-httpbis/latest/p6-cache.html

    r1702 r1707  
    14471447      <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. 
    14481448         We define this new directive to mean that, in addition to any private cache, any cache that is shared only by members of the 
    1449          community named within its value may cache the response. An origin server wishing to allow the UCI community to use an otherwise 
    1450          private response in their shared cache(s) could do so by including 
     1449         community named within its value is allowed to cache the response. An origin server wishing to allow the UCI community to 
     1450         use an otherwise private response in their shared cache(s) could do so by including 
    14511451      </p> 
    14521452      <div id="rfc.figure.u.10"></div><pre class="text">  Cache-Control: private, community="UCI" 
  • draft-ietf-httpbis/latest/p6-cache.xml

    r1702 r1707  
    16111611   this new directive to mean that, in addition to any private cache, any 
    16121612   cache that is shared only by members of the community named within its 
    1613    value may cache the response. An origin server wishing to allow the UCI 
    1614    community to use an otherwise private response in their shared cache(s) 
    1615    could do so by including 
     1613   value is allowed to cache the response. An origin server wishing to allow 
     1614   the UCI community to use an otherwise private response in their shared 
     1615   cache(s) could do so by including 
    16161616</t> 
    16171617<figure><artwork type="example"> 
Note: See TracChangeset for help on using the changeset viewer.