Ignore:
Timestamp:
15/09/13 02:23:08 (7 years ago)
Author:
fielding@…
Message:

uniform terminology for private cache (not non-shared), user agent, and avoid plural subjects in requirements; clarify that recipients don't have to parse all received URIs; addresses #234

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2401 r2402  
    446446   transfer of text media with plain CR or LF alone representing a line
    447447   break, when such line breaks are consistent for an entire representation.
    448    HTTP senders &MAY; generate, and recipients &MUST; be able to parse,
     448   An HTTP sender &MAY; generate, and a recipient &MUST; be able to parse,
    449449   line breaks in text media that consist of CRLF, bare CR, or bare LF.
    450450   In addition, text media in HTTP is not limited to charsets that
     
    507507   generate a Content-Type header field in that message unless the intended
    508508   media type of the enclosed representation is unknown to the sender.
    509    If a Content-Type header field is not present, recipients &MAY; either
     509   If a Content-Type header field is not present, the recipient &MAY; either
    510510   assume a media type of
    511511   "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
     
    24572457</t>
    24582458<t>
    2459    Robotic user agents &SHOULD; send a valid From header field so that the
     2459   A robotic user agent &SHOULD; send a valid From header field so that the
    24602460   person responsible for running the robot can be contacted if problems
    24612461   occur on servers, such as if the robot is sending excessive, unwanted,
     
    24632463</t>
    24642464<t>
    2465    Servers &SHOULD-NOT; use the From header field for access control or
     2465   A server &SHOULD-NOT; use the From header field for access control or
    24662466   authentication, since most recipients will assume that the field value is
    24672467   public information.
     
    25242524   changes to specific edits, such as replacing internal domain names with
    25252525   pseudonyms or truncating the query and/or path components.
    2526    Intermediaries &SHOULD-NOT; modify or delete the Referer field when the
    2527    field value shares the same scheme and host as the request target.
     2526   An intermediary &SHOULD-NOT; modify or delete the Referer header field when
     2527   the field value shares the same scheme and host as the request target.
    25282528</t>
    25292529</section>
     
    25592559</artwork></figure>
    25602560<t>
    2561    Senders &SHOULD; limit generated product identifiers to what is necessary
    2562    to identify the product; senders &MUST-NOT; generate advertising or other
     2561   A sender &SHOULD; limit generated product identifiers to what is necessary
     2562   to identify the product; a sender &MUST-NOT; generate advertising or other
    25632563   non-essential information within the product identifier.
    2564    Senders &SHOULD-NOT; generate information in <x:ref>product-version</x:ref>
     2564   A sender &SHOULD-NOT; generate information in <x:ref>product-version</x:ref>
    25652565   that is not a version identifier (i.e., successive versions of the same
    25662566   product name ought to only differ in the product-version portion of the
     
    26002600   HTTP status codes are extensible. HTTP clients are not required
    26012601   to understand the meaning of all registered status codes, though such
    2602    understanding is obviously desirable. However, clients &MUST;
     2602   understanding is obviously desirable. However, a client &MUST;
    26032603   understand the class of any status code, as indicated by the first
    26042604   digit, and treat an unrecognized status code as being equivalent to the
     
    27252725   fields, and thus are terminated by the empty line at the end of the header
    27262726   section.
    2727    Since HTTP/1.0 did not define any 1xx status codes, servers &MUST-NOT; send
    2728    a 1xx response to an HTTP/1.0 client except under experimental conditions.
     2727   Since HTTP/1.0 did not define any 1xx status codes, a server &MUST-NOT; send
     2728   a 1xx response to an HTTP/1.0 client.
    27292729</t>
    27302730<t>
     
    30493049</x:note>
    30503050<t>
    3051    Clients &SHOULD; detect and intervene in cyclical redirections (i.e.,
     3051   A client &SHOULD; detect and intervene in cyclical redirections (i.e.,
    30523052   "infinite" redirection loops).
    30533053</t>
     
    31273127<x:note>
    31283128  <t>
    3129     &Note; For historic reasons, user agents &MAY; change the
     3129    &Note; For historic reasons, a user agent &MAY; change the
    31303130    request method from POST to GET for the subsequent request. If this
    3131     behavior is undesired, status code <x:ref>307 (Temporary Redirect)</x:ref>
    3132     can be used instead.
     3131    behavior is undesired, the <x:ref>307 (Temporary Redirect)</x:ref>
     3132    status code can be used instead.
    31333133  </t>
    31343134</x:note>
     
    31583158<x:note>
    31593159  <t>
    3160     &Note; For historic reasons, user agents &MAY; change the
     3160    &Note; For historic reasons, a user agent &MAY; change the
    31613161    request method from POST to GET for the subsequent request. If this
    3162     behavior is undesired, status code <x:ref>307 (Temporary Redirect)</x:ref>
    3163     can be used instead.
     3162    behavior is undesired, the <x:ref>307 (Temporary Redirect)</x:ref>
     3163    status code can be used instead.
    31643164  </t>
    31653165</x:note>
     
    35483548   representation containing an explanation of the error situation, and
    35493549   whether it is a temporary or permanent condition.
    3550    User agents &SHOULD; display any included representation to the user.
     3550   A user agent &SHOULD; display any included representation to the user.
    35513551   These response codes are applicable to any request method.
    35523552</t>
     
    50395039   the user. Likewise, Cookie header fields are deliberately designed to
    50405040   enable re-identification, so we can assume that fingerprinting concerns
    5041    only apply to situations where cookies are disabled or restricted by
    5042    browser configuration.
     5041   only apply to situations where cookies are disabled or restricted by the
     5042   user agent's configuration.
    50435043</t>
    50445044<t>
Note: See TracChangeset for help on using the changeset viewer.