Ignore:
Timestamp:
Jul 29, 2010, 11:11:34 PM (9 years ago)
Author:
fielding@…
Message:

Addresses #109: Clarify entity / representation / variant terminology

Removed entity-header adjective and ABNF and clarified distinction
between payload and representation.

Uncapitalize the phrase effective request URI so that it doesn't
dominate the prose, and define the term "target resource" to be
used instead of the "resource identified by the effective request URI".

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r963 r965  
    2424  <!ENTITY diff-mime              "<xref target='Part3' x:rel='#differences.between.http.and.mime' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2525  <!ENTITY representation         "<xref target='Part3' x:rel='#representation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    26   <!ENTITY entity-header-fields   "<xref target='Part3' x:rel='#entity.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2726  <!ENTITY header-cache-control   "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2827  <!ENTITY header-expect          "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    521520  <x:anchor-alias value="request-header"/>
    522521  <x:anchor-alias value="response-header"/>
    523   <x:anchor-alias value="entity-header"/>
    524522  <x:anchor-alias value="Cache-Control"/>
    525523  <x:anchor-alias value="Pragma"/>
    … …  
    534532</artwork></figure>
    535533<figure><!-- Part3--><artwork type="abnf2616">
    536   <x:ref>entity-header</x:ref>   = &lt;entity-header, defined in &entity-header-fields;&gt;
    537534  <x:ref>MIME-Version</x:ref>    = &lt;MIME-Version, defined in &header-mime-version;&gt;
    538535</artwork></figure>
    … …  
    556553
    557554<section title="Client/Server Messaging" anchor="operation">
    558 <iref item="client"/>
    559 <iref item="server"/>
    560 <iref item="connection"/>
     555<iref primary="true" item="client"/>
     556<iref primary="true" item="server"/>
     557<iref primary="true" item="connection"/>
    561558<t>
    562559   HTTP is a stateless request/response protocol that operates by exchanging
    … …  
    567564   sending HTTP responses.
    568565</t>
    569 <iref item="user agent"/>
    570 <iref item="origin server"/>
     566<iref primary="true" item="user agent"/>
     567<iref primary="true" item="origin server"/>
     568<iref primary="true" item="browser"/>
     569<iref primary="true" item="spider"/>
    571570<t>
    572571   Note that the terms client and server refer only to the roles that
    … …  
    576575   such as a WWW browser, editor, or spider (web-traversing robot), and
    577576   the term "origin server" to refer to the program that can originate
    578    authoritative responses to a request.
     577   authoritative responses to a request.  For general requirements, we use
     578   the term "sender" to refer to whichever component sent a given message
     579   and the term "recipient" to refer to any component that receives the
     580   message.
    579581</t>
    580582<t>
    … …  
    589591                                &lt;   response
    590592</artwork></figure>
    591 <iref item="message"/>
    592 <iref item="request"/>
    593 <iref item="response"/>
     593<iref primary="true" item="message"/>
     594<iref primary="true" item="request"/>
     595<iref primary="true" item="response"/>
    594596<t>
    595597   A client sends an HTTP request to the server in the form of a request
    … …  
    639641
    640642<section title="Intermediaries" anchor="intermediaries">
     643<iref primary="true" item="intermediary"/>
    641644<t>
    642645   A more complicated situation occurs when one or more intermediaries
    … …  
    665668</t>
    666669<t>
    667 <iref item="upstream"/><iref item="downstream"/>
    668 <iref item="inbound"/><iref item="outbound"/>
     670<iref primary="true" item="upstream"/><iref primary="true" item="downstream"/>
     671<iref primary="true" item="inbound"/><iref primary="true" item="outbound"/>
    669672   We use the terms "upstream" and "downstream" to describe various
    670673   requirements in relation to the directional flow of a message:
    … …  
    674677   the origin server and "outbound" means toward the user agent.
    675678</t>
    676 <t><iref item="proxy"/>
     679<t><iref primary="true" item="proxy"/>
    677680   A "proxy" is a message forwarding agent that is selected by the
    678681   client, usually via local configuration rules, to receive requests
    … …  
    685688   sake of security, annotation services, or shared caching.
    686689</t>
    687 <t><iref item="gateway"/><iref item="reverse proxy"/>
     690<t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/>
    688691   A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
    689692   as a layer above some other server(s) and translates the received
    … …  
    692695   multiple machines.
    693696   Unlike a proxy, a gateway receives requests as if it were the
    694    origin server for the requested resource; the requesting client
     697   origin server for the target resource; the requesting client
    695698   will not be aware that it is communicating with a gateway.
    696699   A gateway communicates with the client as if the gateway is the
    … …  
    701704   specification.
    702705</t>
    703 <t><iref item="tunnel"/>
     706<t><iref primary="true" item="tunnel"/>
    704707   A "tunnel" acts as a blind relay between two connections
    705708   without changing the messages. Once active, a tunnel is not
    … …  
    714717
    715718<section title="Caches" anchor="caches">
    716 <iref item="cache"/>
     719<iref primary="true" item="cache"/>
    717720<t>
    718721   A "cache" is a local store of previous response messages and the
    … …  
    735738                  &lt;             &lt;
    736739</artwork></figure>
    737 <t><iref item="cacheable"/>
     740<t><iref primary="true" item="cacheable"/>
    738741   A response is "cacheable" if a cache is allowed to store a copy of
    739742   the response message for use in answering subsequent requests.
    … …  
    11281131   like UTF-16 might introduce security flaws due to the differing ways
    11291132   that such parsers interpret invalid characters.
     1133</t>
     1134<t>
     1135   HTTP allows the set of defined header fields to be extended without
     1136   changing the protocol version (see <xref target="header.field.registration"/>).
     1137   However, such fields might not be recognized by a downstream recipient
     1138   and might be stripped by non-transparent intermediaries.
     1139   Unrecognized header fields &MUST; be forwarded by transparent proxies
     1140   and &SHOULD; be ignored by a recipient.
    11301141</t>
    11311142</section>
    … …  
    14441455   experimental header fields might be given the semantics of general
    14451456   header fields if all parties in the communication recognize them to
    1446    be general-header fields. Unrecognized header fields are treated as
    1447    entity-header fields.
     1457   be general-header fields.
    14481458</t>
    14491459</section>
    … …  
    14601470<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request"/>
    14611471  <x:ref>Request</x:ref>       = <x:ref>Request-Line</x:ref>              ; <xref target="request-line"/>
    1462                   *(( <x:ref>general-header</x:ref>        ; <xref target="general.header.fields"/>
    1463                    / <x:ref>request-header</x:ref>         ; &request-header-fields;
    1464                    / <x:ref>entity-header</x:ref> ) <x:ref>CRLF</x:ref> ) ; &entity-header-fields;
     1472                  *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> )    ; <xref target="header.fields"/>
    14651473                  <x:ref>CRLF</x:ref>
    14661474                  [ <x:ref>message-body</x:ref> ]          ; <xref target="message.body"/>
    … …  
    16581666
    16591667<section title="Effective Request URI" anchor="effective.request.uri">
    1660   <iref primary="true" item="Effective Request URI"/>
     1668  <iref primary="true" item="effective request URI"/>
     1669  <iref primary="true" item="target resource"/>
    16611670<t>
    16621671   HTTP requests often do not carry the absolute URI (<xref target="RFC3986" x:fmt="," x:sec="4.3"/>)
    1663    for the resource they are intended for; instead, the value needs to be inferred from the
    1664    request-target, Host header and other context. The result of this process is
    1665    the "Effective Request URI".
    1666 </t>
    1667 <t>
    1668    If the request-target is an absolute-URI, then the Effective Request URI is
     1672   for the target resource; instead, the URI needs to be inferred from the
     1673   request-target, Host header field, and connection context. The result of
     1674   this process is called the "effective request URI".  The "target resource"
     1675   is the resource identified by the effective request URI.
     1676</t>
     1677<t>
     1678   If the request-target is an absolute-URI, then the effective request URI is
    16691679   the request-target.
    16701680</t>
    16711681<t>
    16721682   If the request-target uses the path-absolute (plus optional query) syntax
    1673    or if it is just the asterisk "*", then the Effective Request URI is
     1683   or if it is just the asterisk "*", then the effective request URI is
    16741684   constructed by concatenating
    16751685</t>
    … …  
    17041714<figure>
    17051715<preamble>
    1706    Example 1: the Effective Request URI for the message
     1716   Example 1: the effective request URI for the message
    17071717</preamble>
    17081718<artwork type="example" x:indent-with="  ">
    … …  
    17191729<figure>
    17201730<preamble>
    1721    Example 2: the Effective Request URI for the message
     1731   Example 2: the effective request URI for the message
    17221732</preamble>
    17231733<artwork type="example" x:indent-with="  ">
    … …  
    17311741</figure>
    17321742<t>
    1733    Effective Request URIs are compared using the rules described in
     1743   Effective request URIs are compared using the rules described in
    17341744   <xref target="uri.comparison"/>, except that empty path components &MUST-NOT;
    17351745   be treated as equivalent to an absolute path of "/".
    … …  
    17481758<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Response"/>
    17491759  <x:ref>Response</x:ref>      = <x:ref>Status-Line</x:ref>               ; <xref target="status-line"/>
    1750                   *(( <x:ref>general-header</x:ref>        ; <xref target="general.header.fields"/>
    1751                    / <x:ref>response-header</x:ref>        ; &response-header-fields;
    1752                    / <x:ref>entity-header</x:ref> ) <x:ref>CRLF</x:ref> ) ; &entity-header-fields;
     1760                  *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> )    ; <xref target="header.fields"/>
    17531761                  <x:ref>CRLF</x:ref>
    17541762                  [ <x:ref>message-body</x:ref> ]          ; <xref target="message.body"/>
    … …  
    20312039   The chunked encoding modifies the body of a message in order to
    20322040   transfer it as a series of chunks, each with its own size indicator,
    2033    followed by an &OPTIONAL; trailer containing entity-header fields. This
     2041   followed by an &OPTIONAL; trailer containing header fields. This
    20342042   allows dynamically produced content to be transferred along with the
    20352043   information necessary for the recipient to verify that it has
    … …  
    20522060  <x:ref>chunk-ext-val</x:ref>  = <x:ref>token</x:ref> / <x:ref>quoted-str-nf</x:ref>
    20532061  <x:ref>chunk-data</x:ref>     = 1*<x:ref>OCTET</x:ref> ; a sequence of chunk-size octets
    2054   <x:ref>trailer-part</x:ref>   = *( <x:ref>entity-header</x:ref> <x:ref>CRLF</x:ref> )
     2062  <x:ref>trailer-part</x:ref>   = *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> )
    20552063 
    20562064  <x:ref>quoted-str-nf</x:ref>  = <x:ref>DQUOTE</x:ref> *( <x:ref>qdtext-nf</x:ref> / <x:ref>quoted-pair</x:ref> ) <x:ref>DQUOTE</x:ref>
    … …  
    28432851   related to message framing and transport protocols.
    28442852</t>
    2845 <t>
    2846    For entity-header fields, both sender and recipient refer to either the
    2847    client or the server, depending on who sends and who receives the message.
    2848 </t>
    28492853
    28502854<section title="Connection" anchor="header.connection">
    … …  
    32313235   &MUST; be listed in the order in which they were applied.
    32323236   Additional information about the encoding parameters &MAY; be provided
    3233    by other entity-header fields not defined by this specification.
     3237   by other header fields not defined by this specification.
    32343238</t>
    32353239<t>
    … …  
    49364940<x:ref>RWS</x:ref> = 1*( [ obs-fold ] WSP )
    49374941<x:ref>Reason-Phrase</x:ref> = *( WSP / VCHAR / obs-text )
    4938 <x:ref>Request</x:ref> = Request-Line *( ( general-header / request-header /
    4939  entity-header ) CRLF ) CRLF [ message-body ]
     4942<x:ref>Request</x:ref> = Request-Line *( header-field CRLF ) CRLF [ message-body ]
    49404943<x:ref>Request-Line</x:ref> = Method SP request-target SP HTTP-Version CRLF
    4941 <x:ref>Response</x:ref> = Status-Line *( ( general-header / response-header /
    4942  entity-header ) CRLF ) CRLF [ message-body ]
     4944<x:ref>Response</x:ref> = Status-Line *( header-field CRLF ) CRLF [ message-body ]
    49434945
    49444946<x:ref>Status-Code</x:ref> = 3DIGIT
    … …  
    50015003 / %x53.75.6E.64.61.79 ; Sunday
    50025004
    5003 <x:ref>entity-header</x:ref> = &lt;entity-header, defined in [Part3], Section 3.1&gt;
    5004 
    50055005<x:ref>field-content</x:ref> = *( WSP / VCHAR / obs-text )
    50065006<x:ref>field-name</x:ref> = token
    … …  
    50815081<x:ref>time-of-day</x:ref> = hour ":" minute ":" second
    50825082<x:ref>token</x:ref> = 1*tchar
    5083 <x:ref>trailer-part</x:ref> = *( entity-header CRLF )
     5083<x:ref>trailer-part</x:ref> = *( header-field CRLF )
    50845084<x:ref>transfer-coding</x:ref> = "chunked" / "compress" / "deflate" / "gzip" /
    50855085 transfer-extension
    … …  
    56385638    </t>
    56395639    <t>
     5640      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/109"/>:
     5641      "Clarify entity / representation / variant terminology"
     5642    </t>
     5643    <t>
    56405644      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
    56415645      "consider removing the 'changes from 2068' sections"
Note: See TracChangeset for help on using the changeset viewer.