Changeset 2065 for draft-ietf-httpbis


Ignore:
Timestamp:
29/12/12 08:22:04 (9 years ago)
Author:
fielding@…
Message:

(editorial) rephrase Date for better targeting of subject requirements

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

Legend:

Unmodified
Added
Removed

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

    r2064 r2065  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 1, 2013";
     451       content: "Expires July 2, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    495495      <meta name="dct.creator" content="Reschke, J. F.">
    496496      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    497       <meta name="dct.issued" scheme="ISO8601" content="2012-12-28">
     497      <meta name="dct.issued" scheme="ISO8601" content="2012-12-29">
    498498      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    499499      <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.">
    … …  
    523523            <tr>
    524524               <td class="left">Intended status: Standards Track</td>
    525                <td class="right">December 28, 2012</td>
     525               <td class="right">December 29, 2012</td>
    526526            </tr>
    527527            <tr>
    528                <td class="left">Expires: July 1, 2013</td>
     528               <td class="left">Expires: July 2, 2013</td>
    529529               <td class="right"></td>
    530530            </tr>
    … …  
    554554         in progress”.
    555555      </p>
    556       <p>This Internet-Draft will expire on July 1, 2013.</p>
     556      <p>This Internet-Draft will expire on July 2, 2013.</p>
    557557      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    558558      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    23562356      <div id="rfc.iref.70"></div>
    23572357      <div id="rfc.iref.s.2"></div>
    2358       <p id="rfc.section.6.2.p.1">This class of status code indicates a provisional response, consisting only of the status-line and optional header fields,
    2359          and is terminated by an empty line. There are no required header fields for this class of status code. Since HTTP/1.0 did
    2360          not define any 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
     2358      <p id="rfc.section.6.2.p.1">This class of status code indicates an interim response, consisting only of the status-line and optional header fields, and
     2359         is terminated by an empty line. There are no required header fields for this class of status code. Since HTTP/1.0 did not
     2360         define any 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
    23612361      </p>
    23622362      <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a <a href="#status.100" class="smpl">100
    … …  
    28742874      <h4 id="rfc.section.7.1.1.2"><a href="#rfc.section.7.1.1.2">7.1.1.2</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h4>
    28752875      <p id="rfc.section.7.1.1.2.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the
    2876          Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section&nbsp;7.1.1.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
     2876         Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section&nbsp;7.1.1.1</a>, though a sender <em class="bcp14">MUST</em> generate a Date value in the rfc1123-date format.
    28772877      </p>
    28782878      <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.55"></span>  <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a>
    28792879</pre><p id="rfc.section.7.1.1.2.p.3">An example is</p>
    28802880      <div id="rfc.figure.u.50"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
    2881 </pre><p id="rfc.section.7.1.1.2.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:
    2882       </p>
    2883       <ol>
    2884          <li>If the response status code is <a href="#status.100" class="smpl">100 (Continue)</a> or <a href="#status.101" class="smpl">101 (Switching Protocols)</a>, the response <em class="bcp14">MAY</em> include a Date header field, at the server's option.
    2885          </li>
    2886          <li>If the response status code conveys a server error, e.g., <a href="#status.500" class="smpl">500
    2887                (Internal Server Error)</a> or <a href="#status.503" class="smpl">503 (Service Unavailable)</a>, and it is inconvenient or impossible to generate a valid Date.
    2888          </li>
    2889          <li>If the server does not have a clock that can provide a reasonable approximation of the current time, its responses <em class="bcp14">MUST NOT</em> include a Date header field.
    2890          </li>
    2891       </ol>
    2892       <p id="rfc.section.7.1.1.2.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient.
    2893       </p>
    2894       <p id="rfc.section.7.1.1.2.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it
    2895          when it doesn't convey any useful information (as is usually the case for requests that do not contain a payload).
    2896       </p>
    2897       <p id="rfc.section.7.1.1.2.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means
    2898          of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload
    2899          is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic
    2900          value.
     2881</pre><p id="rfc.section.7.1.1.2.p.5">When a Date header field is generated, the sender <em class="bcp14">SHOULD</em> generate its field value as the best available approximation of the date and time of message generation. In theory, the date
     2882         ought to represent the moment just before the payload is generated. In practice, the date can be generated at any time during
     2883         message origination.
     2884      </p>
     2885      <p id="rfc.section.7.1.1.2.p.6">An origin server <em class="bcp14">MUST NOT</em> send a Date header field if it does not have a clock capable of providing a reasonable approximation of the current time.
     2886         An origin server <em class="bcp14">MAY</em> send a Date header field if the response is in the <a href="#status.1xx" class="smpl">1xx (Informational)</a> or <a href="#status.5xx" class="smpl">5xx (Server Error)</a> class of status codes. An origin server <em class="bcp14">MUST</em> send a Date header field in all other cases.
     2887      </p>
     2888      <p id="rfc.section.7.1.1.2.p.7">A recipient with a clock that receives a response message without a Date header field <em class="bcp14">MUST</em> record the time it was received and append a corresponding Date header field to the message's header block if it is cached
     2889         or forwarded downstream.
     2890      </p>
     2891      <p id="rfc.section.7.1.1.2.p.8">A user agent <em class="bcp14">MAY</em> send a Date header field in a request, though generally will not do so unless it is believed to convey useful information
     2892         to the server. For example, custom applications of HTTP might convey a Date if the server is expected to adjust its interpretation
     2893         of the user's request based on differences between the user agent and server clocks.
    29012894      </p>
    29022895      <div id="rfc.iref.l.1"></div>

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

    r2064 r2065  
    25852585  <iref primary="true" item="Status Codes Classes" subitem="1xx Informational" x:for-anchor=""/>
    25862586<t>
    2587    This class of status code indicates a provisional response,
     2587   This class of status code indicates an interim response,
    25882588   consisting only of the status-line and optional header fields, and is
    25892589   terminated by an empty line. There are no required header fields for this
    … …  
    36283628   the message was originated, having the same semantics as the Origination
    36293629   Date Field (orig-date) defined in <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>.
    3630    The field value is an HTTP-date, as defined in <xref target="http.date"/>;
    3631    it &MUST; be sent in rfc1123-date format.
     3630   The field value is an HTTP-date, as defined in <xref target="http.date"/>,
     3631   though a sender &MUST; generate a Date value in the rfc1123-date format.
    36323632</t>
    36333633<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/>
    … …  
    36413641</artwork></figure>
    36423642<t>
    3643    Origin servers &MUST; include a Date header field in all responses,
    3644    except in these cases:
    3645   <list style="numbers">
    3646       <t>If the response status code is <x:ref>100 (Continue)</x:ref> or
    3647          <x:ref>101 (Switching Protocols)</x:ref>, the response &MAY; include a
    3648          Date header field, at the server's option.</t>
    3649 
    3650       <t>If the response status code conveys a server error, e.g., <x:ref>500
    3651          (Internal Server Error)</x:ref> or <x:ref>503 (Service Unavailable)</x:ref>,
    3652          and it is inconvenient or impossible to generate a valid Date.</t>
    3653 
    3654       <t>If the server does not have a clock that can provide a
    3655          reasonable approximation of the current time, its responses
    3656          &MUST-NOT; include a Date header field.</t>
    3657   </list>
    3658 </t>
    3659 <t>
    3660    A received message that does not have a Date header field &MUST; be
    3661    assigned one by the recipient if the message will be cached by that
    3662    recipient.
    3663 </t>
    3664 <t>
    3665    Clients can use the Date header field as well; in order to keep request
    3666    messages small, they are advised not to include it when it doesn't convey
    3667    any useful information (as is usually the case for requests that do not
    3668    contain a payload).
    3669 </t>
    3670 <t>
    3671    The HTTP-date sent in a Date header field &SHOULD-NOT; represent a date and
    3672    time subsequent to the generation of the message. It &SHOULD; represent
    3673    the best available approximation of the date and time of message
    3674    generation, unless the implementation has no means of generating a
    3675    reasonably accurate date and time. In theory, the date ought to
    3676    represent the moment just before the payload is generated. In
    3677    practice, the date can be generated at any time during the message
    3678    origination without affecting its semantic value.
     3643   When a Date header field is generated, the sender &SHOULD; generate its
     3644   field value as the best available approximation of the date and time of
     3645   message generation. In theory, the date ought to represent the moment just
     3646   before the payload is generated. In practice, the date can be generated at
     3647   any time during message origination.
     3648</t>
     3649<t>
     3650   An origin server &MUST-NOT; send a Date header field if it does not have a
     3651   clock capable of providing a reasonable approximation of the current time.
     3652   An origin server &MAY; send a Date header field if the response is in the
     3653   <x:ref>1xx (Informational)</x:ref> or <x:ref>5xx (Server Error)</x:ref>
     3654   class of status codes.
     3655   An origin server &MUST; send a Date header field in all other cases.
     3656</t>
     3657<t>
     3658   A recipient with a clock that receives a response message without a Date
     3659   header field &MUST; record the time it was received and append a
     3660   corresponding Date header field to the message's header block if it is
     3661   cached or forwarded downstream.
     3662</t>
     3663<t>
     3664   A user agent &MAY; send a Date header field in a request, though generally
     3665   will not do so unless it is believed to convey useful information to the
     3666   server. For example, custom applications of HTTP might convey a Date if
     3667   the server is expected to adjust its interpretation of the user's request
     3668   based on differences between the user agent and server clocks.
    36793669</t>
    36803670</section>
Note: See TracChangeset for help on using the changeset viewer.