Changeset 965

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".

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.xml (modified) (31 diffs)
• p2-semantics.xml (modified) (41 diffs)
• p3-payload.xml (modified) (14 diffs)
• p4-conditional.xml (modified) (5 diffs)
• p5-range.xml (modified) (5 diffs)
• p6-cache.xml (modified) (5 diffs)
• p7-auth.xml (modified) (4 diffs)

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

@@ -24 +24 @@
   <!ENTITY diff-mime              "<xref target='Part3' x:rel='#differences.between.http.and.mime' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY representation         "<xref target='Part3' x:rel='#representation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
-  <!ENTITY entity-header-fields   "<xref target='Part3' x:rel='#entity.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY header-cache-control   "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY header-expect          "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -521 +520 @@
   <x:anchor-alias value="request-header"/>
   <x:anchor-alias value="response-header"/>
-  <x:anchor-alias value="entity-header"/>
   <x:anchor-alias value="Cache-Control"/>
   <x:anchor-alias value="Pragma"/>
@@ -534 +532 @@
 </artwork></figure>
 <figure><!-- Part3--><artwork type="abnf2616">
-  <x:ref>entity-header</x:ref>   = &lt;entity-header, defined in &entity-header-fields;&gt;
   <x:ref>MIME-Version</x:ref>    = &lt;MIME-Version, defined in &header-mime-version;&gt;
 </artwork></figure>
@@ -556 +553 @@
 
 <section title="Client/Server Messaging" anchor="operation">
-<iref item="client"/>
-<iref item="server"/>
-<iref item="connection"/>
+<iref primary="true" item="client"/>
+<iref primary="true" item="server"/>
+<iref primary="true" item="connection"/>
 <t>
    HTTP is a stateless request/response protocol that operates by exchanging
@@ -567 +564 @@
    sending HTTP responses.
 </t>
-<iref item="user agent"/>
-<iref item="origin server"/>
+<iref primary="true" item="user agent"/>
+<iref primary="true" item="origin server"/>
+<iref primary="true" item="browser"/>
+<iref primary="true" item="spider"/>
 <t>
    Note that the terms client and server refer only to the roles that
@@ -576 +575 @@
    such as a WWW browser, editor, or spider (web-traversing robot), and
    the term "origin server" to refer to the program that can originate
-   authoritative responses to a request.
+   authoritative responses to a request.  For general requirements, we use
+   the term "sender" to refer to whichever component sent a given message
+   and the term "recipient" to refer to any component that receives the
+   message.
 </t>
 <t>
@@ -589 +591 @@
                                 &lt;   response
 </artwork></figure>
-<iref item="message"/>
-<iref item="request"/>
-<iref item="response"/>
+<iref primary="true" item="message"/>
+<iref primary="true" item="request"/>
+<iref primary="true" item="response"/>
 <t>
    A client sends an HTTP request to the server in the form of a request
@@ -639 +641 @@
 
 <section title="Intermediaries" anchor="intermediaries">
+<iref primary="true" item="intermediary"/>
 <t>
    A more complicated situation occurs when one or more intermediaries
@@ -665 +668 @@
 </t>
 <t>
-<iref item="upstream"/><iref item="downstream"/>
-<iref item="inbound"/><iref item="outbound"/>
+<iref primary="true" item="upstream"/><iref primary="true" item="downstream"/>
+<iref primary="true" item="inbound"/><iref primary="true" item="outbound"/>
    We use the terms "upstream" and "downstream" to describe various
    requirements in relation to the directional flow of a message:
@@ -674 +677 @@
    the origin server and "outbound" means toward the user agent.
 </t>
-<t><iref item="proxy"/>
+<t><iref primary="true" item="proxy"/>
    A "proxy" is a message forwarding agent that is selected by the
    client, usually via local configuration rules, to receive requests
@@ -685 +688 @@
    sake of security, annotation services, or shared caching.
 </t>
-<t><iref item="gateway"/><iref item="reverse proxy"/>
+<t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/>
    A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
    as a layer above some other server(s) and translates the received
@@ -692 +695 @@
    multiple machines.
    Unlike a proxy, a gateway receives requests as if it were the
-   origin server for the requested resource; the requesting client
+   origin server for the target resource; the requesting client
    will not be aware that it is communicating with a gateway.
    A gateway communicates with the client as if the gateway is the
@@ -701 +704 @@
    specification.
 </t>
-<t><iref item="tunnel"/>
+<t><iref primary="true" item="tunnel"/>
    A "tunnel" acts as a blind relay between two connections
    without changing the messages. Once active, a tunnel is not
@@ -714 +717 @@
 
 <section title="Caches" anchor="caches">
-<iref item="cache"/>
+<iref primary="true" item="cache"/>
 <t>
    A "cache" is a local store of previous response messages and the
@@ -735 +738 @@
                   &lt;             &lt;
 </artwork></figure>
-<t><iref item="cacheable"/>
+<t><iref primary="true" item="cacheable"/>
    A response is "cacheable" if a cache is allowed to store a copy of
    the response message for use in answering subsequent requests.
@@ -1128 +1131 @@
    like UTF-16 might introduce security flaws due to the differing ways
    that such parsers interpret invalid characters.
+</t>
+<t>
+   HTTP allows the set of defined header fields to be extended without
+   changing the protocol version (see <xref target="header.field.registration"/>).
+   However, such fields might not be recognized by a downstream recipient
+   and might be stripped by non-transparent intermediaries.
+   Unrecognized header fields &MUST; be forwarded by transparent proxies
+   and &SHOULD; be ignored by a recipient.
 </t>
 </section>
@@ -1444 +1455 @@
    experimental header fields might be given the semantics of general
    header fields if all parties in the communication recognize them to
-   be general-header fields. Unrecognized header fields are treated as
-   entity-header fields.
+   be general-header fields.
 </t>
 </section>
@@ -1460 +1470 @@
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request"/>
   <x:ref>Request</x:ref>       = <x:ref>Request-Line</x:ref>              ; <xref target="request-line"/>
-                  *(( <x:ref>general-header</x:ref>        ; <xref target="general.header.fields"/>
-                   / <x:ref>request-header</x:ref>         ; &request-header-fields;
-                   / <x:ref>entity-header</x:ref> ) <x:ref>CRLF</x:ref> ) ; &entity-header-fields;
+                  *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> )    ; <xref target="header.fields"/>
                   <x:ref>CRLF</x:ref>
                   [ <x:ref>message-body</x:ref> ]          ; <xref target="message.body"/>
@@ -1658 +1666 @@
 
 <section title="Effective Request URI" anchor="effective.request.uri">
-  <iref primary="true" item="Effective Request URI"/>
+  <iref primary="true" item="effective request URI"/>
+  <iref primary="true" item="target resource"/>
 <t>
    HTTP requests often do not carry the absolute URI (<xref target="RFC3986" x:fmt="," x:sec="4.3"/>)
-   for the resource they are intended for; instead, the value needs to be inferred from the
-   request-target, Host header and other context. The result of this process is
-   the "Effective Request URI".
-</t>
-<t>
-   If the request-target is an absolute-URI, then the Effective Request URI is
+   for the target resource; instead, the URI needs to be inferred from the
+   request-target, Host header field, and connection context. The result of
+   this process is called the "effective request URI".  The "target resource"
+   is the resource identified by the effective request URI.
+</t>
+<t>
+   If the request-target is an absolute-URI, then the effective request URI is
    the request-target.
 </t>
 <t>
    If the request-target uses the path-absolute (plus optional query) syntax
-   or if it is just the asterisk "*", then the Effective Request URI is
+   or if it is just the asterisk "*", then the effective request URI is
    constructed by concatenating
 </t>
@@ -1704 +1714 @@
 <figure>
 <preamble>
-   Example 1: the Effective Request URI for the message
+   Example 1: the effective request URI for the message
 </preamble> 
 <artwork type="example" x:indent-with="  ">
@@ -1719 +1729 @@
 <figure>
 <preamble>
-   Example 2: the Effective Request URI for the message
+   Example 2: the effective request URI for the message
 </preamble> 
 <artwork type="example" x:indent-with="  ">
@@ -1731 +1741 @@
 </figure>
 <t>
-   Effective Request URIs are compared using the rules described in 
+   Effective request URIs are compared using the rules described in 
    <xref target="uri.comparison"/>, except that empty path components &MUST-NOT;
    be treated as equivalent to an absolute path of "/".
@@ -1748 +1758 @@
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Response"/>
   <x:ref>Response</x:ref>      = <x:ref>Status-Line</x:ref>               ; <xref target="status-line"/>
-                  *(( <x:ref>general-header</x:ref>        ; <xref target="general.header.fields"/>
-                   / <x:ref>response-header</x:ref>        ; &response-header-fields;
-                   / <x:ref>entity-header</x:ref> ) <x:ref>CRLF</x:ref> ) ; &entity-header-fields;
+                  *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> )    ; <xref target="header.fields"/>
                   <x:ref>CRLF</x:ref>
                   [ <x:ref>message-body</x:ref> ]          ; <xref target="message.body"/>
@@ -2031 +2039 @@
    The chunked encoding modifies the body of a message in order to
    transfer it as a series of chunks, each with its own size indicator,
-   followed by an &OPTIONAL; trailer containing entity-header fields. This
+   followed by an &OPTIONAL; trailer containing header fields. This
    allows dynamically produced content to be transferred along with the
    information necessary for the recipient to verify that it has
@@ -2052 +2060 @@
   <x:ref>chunk-ext-val</x:ref>  = <x:ref>token</x:ref> / <x:ref>quoted-str-nf</x:ref>
   <x:ref>chunk-data</x:ref>     = 1*<x:ref>OCTET</x:ref> ; a sequence of chunk-size octets
-  <x:ref>trailer-part</x:ref>   = *( <x:ref>entity-header</x:ref> <x:ref>CRLF</x:ref> )
+  <x:ref>trailer-part</x:ref>   = *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> )
   
   <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>
@@ -2843 +2851 @@
    related to message framing and transport protocols.
 </t>
-<t>
-   For entity-header fields, both sender and recipient refer to either the
-   client or the server, depending on who sends and who receives the message.
-</t>
 
 <section title="Connection" anchor="header.connection">
@@ -3231 +3235 @@
    &MUST; be listed in the order in which they were applied.
    Additional information about the encoding parameters &MAY; be provided
-   by other entity-header fields not defined by this specification.
+   by other header fields not defined by this specification.
 </t>
 <t>
@@ -4936 +4940 @@
 <x:ref>RWS</x:ref> = 1*( [ obs-fold ] WSP )
 <x:ref>Reason-Phrase</x:ref> = *( WSP / VCHAR / obs-text )
-<x:ref>Request</x:ref> = Request-Line *( ( general-header / request-header /
- entity-header ) CRLF ) CRLF [ message-body ]
+<x:ref>Request</x:ref> = Request-Line *( header-field CRLF ) CRLF [ message-body ]
 <x:ref>Request-Line</x:ref> = Method SP request-target SP HTTP-Version CRLF
-<x:ref>Response</x:ref> = Status-Line *( ( general-header / response-header /
- entity-header ) CRLF ) CRLF [ message-body ]
+<x:ref>Response</x:ref> = Status-Line *( header-field CRLF ) CRLF [ message-body ]
 
 <x:ref>Status-Code</x:ref> = 3DIGIT
@@ -5001 +5003 @@
  / %x53.75.6E.64.61.79 ; Sunday
 
-<x:ref>entity-header</x:ref> = &lt;entity-header, defined in [Part3], Section 3.1&gt;
-
 <x:ref>field-content</x:ref> = *( WSP / VCHAR / obs-text )
 <x:ref>field-name</x:ref> = token
@@ -5081 +5081 @@
 <x:ref>time-of-day</x:ref> = hour ":" minute ":" second
 <x:ref>token</x:ref> = 1*tchar
-<x:ref>trailer-part</x:ref> = *( entity-header CRLF )
+<x:ref>trailer-part</x:ref> = *( header-field CRLF )
 <x:ref>transfer-coding</x:ref> = "chunked" / "compress" / "deflate" / "gzip" /
  transfer-extension
@@ -5638 +5638 @@
     </t>
     <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/109"/>:
+      "Clarify entity / representation / variant terminology"
+    </t>
+    <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
       "consider removing the 'changes from 2068' sections"

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

@@ -277 +277 @@
    agreed upon semantics of the HTTP uniform interface, the intentions defined
    by each request method, and the various response messages that might be
-   expected as a result of applying that method for the requested resource.
+   expected as a result of applying that method to the target resource.
 </t>
 <t>
@@ -434 +434 @@
 <t>
    The Method token indicates the method to be performed on the resource
-   identified by the Effective Request URI (&effective-request-uri;). The
+   identified by the effective request URI (&effective-request-uri;). The
    method is case-sensitive.
 </t>
@@ -451 +451 @@
 <t>
    The list of methods allowed by a resource can be specified in an
-   Allow header field (<xref target="header.allow"/>). The return code of the response
+   Allow header field (<xref target="header.allow"/>). The status code of the response
    always notifies the client whether a method is currently allowed on a
    resource, since the set of allowed methods can change dynamically. An
-   origin server &SHOULD; return the status code 405 (Method Not Allowed)
+   origin server &SHOULD; respond with the status code 405 (Method Not Allowed)
    if the method is known by the origin server but not allowed for the
-   requested resource, and 501 (Not Implemented) if the method is
+   resource, and 501 (Not Implemented) if the method is
    unrecognized or not implemented by the origin server. The methods GET
    and HEAD &MUST; be supported by all general-purpose servers. All other
@@ -522 +522 @@
    experimental header fields &MAY; be given the semantics of request-header
    fields if all parties in the communication recognize them to
-   be request-header fields. Unrecognized header fields are treated as
-   entity-header fields.
+   be request-header fields.
 </t>
 </section>
@@ -635 +634 @@
    information about the response which cannot be placed in the Status-Line.
    These header fields give information about the server and about
-   further access to the resource identified by the Effective Request URI
+   further access to the resource identified by the effective request URI
    (&effective-request-uri;).
 </t>
@@ -655 +654 @@
    experimental header fields &MAY; be given the semantics of response-header
    fields if all parties in the communication recognize them to
-   be response-header fields. Unrecognized header fields are treated as
-   entity-header fields.
+   be response-header fields.
 </t>
 </section>
@@ -678 +676 @@
 <section title="Identifying the Resource Associated with a Representation" anchor="identifying.response.associated.with.representation">
 <t>
-   It is sometimes necessary to determine the identity of the resource
+   It is sometimes necessary to determine an identifier for the resource
    associated with a representation.
 </t>
@@ -687 +685 @@
 <t>
    In the common case, an HTTP response is a representation of the resource
-   located at the Effective Request URI (see &effective-request-uri;). However,
+   located at the effective request URI (see &effective-request-uri;). However,
    this is not always the case. To determine the URI of the resource a
    response is associated with, the following rules are used (with the first
@@ -694 +692 @@
 <t><list style="numbers">
    <t>If the response status code is 200 or 203 and the request method was GET,
-   the response is a representation of the resource at the Effective Request URI.</t>
+   the response payload is a representation of the resource identified by the effective request URI.</t>
    <t>If the response status code is 204, 206, or 304 and the request method was GET
-   or HEAD, the response is a partial representation of the resource at the
-   Effective Request URI (see &caching-combining-headers;).</t>
+   or HEAD, the response payload is a partial representation of the resource identified
+   by the effective request URI (see &caching-combining-headers;).</t>
    <t>If the response has a Content-Location header, and that URI is the same
-   as the Effective Request URI, the response is a representation of the
-   resource at the Effective Request URI.</t>
+   as the effective request URI, the response payload is a representation of the
+   resource identified by the effective request URI.</t>
    <t>If the response has a Content-Location header, and that URI is not the
-   same as the Effective Request URI, the response asserts that it is a
-   representation of the resource at the Content-Location URI (but it might not
-   be).</t>
+   same as the effective request URI, then the response asserts that its
+   payload is a representation of the resource identified by the
+   Content-Location URI. However, such an assertion cannot be trusted unless
+   it can be verified by other means (not defined by HTTP).</t>
    <t>Otherwise, the response is a representation of an anonymous (i.e.,
    unidentified) resource.</t>
@@ -776 +775 @@
    The OPTIONS method represents a request for information about the
    communication options available on the request/response chain
-   identified by the Effective Request URI. This method allows the client to
+   identified by the effective request URI. This method allows the client to
    determine the options and/or requirements associated with a resource,
    or the capabilities of a server, without implying a resource action
@@ -835 +834 @@
    The GET method means retrieve whatever information (in the form of a
    representation) currently corresponds to the resource identified by the
-   Effective Request URI.
+   effective request URI.
 </t>
 <t>   
-   If the Effective Request URI identifies a data-producing process, it is the
+   If the effective request URI identifies a data-producing process, it is the
    produced data which shall be returned as the representation in the response and not
    the source text of the process, unless that text happens to be the output of
@@ -903 +902 @@
    The POST method is used to request that the origin server accept the
    representation enclosed in the request as data to be processed by the resource
-   identified by the Effective Request URI. POST is designed
+   identified by the effective request URI. POST is designed
    to allow a uniform method to cover the following functions:
   <list style="symbols">
@@ -924 +923 @@
 <t>
    The actual function performed by the POST method is determined by the
-   server and is usually dependent on the Effective Request URI.
+   server and is usually dependent on the effective request URI.
 </t>
 <t>
@@ -958 +957 @@
 <t>
    The PUT method requests that the enclosed representation be stored at the
-   Effective Request URI. If the Effective Request URI refers to an already
+   effective request URI. If the effective request URI refers to an already
    existing resource, the enclosed representation &SHOULD; be considered a
    modified version of the one residing on the origin server. Otherwise, if the
-   Effective Request URI does not point to an existing resource, and that URI is
+   effective request URI does not point to an existing resource, and that URI is
    capable of being defined as a new resource by the requesting user
    agent, the origin server can create the resource with that URI.
 </t>
 <t>   
-   If a new resource is created at the Effective Request URI, the origin
+   If a new resource is created at the effective request URI, the origin
    server &MUST; inform the user agent
    via the 201 (Created) response. If an existing resource is modified,
@@ -973 +972 @@
 </t>
 <t>   
-   If the resource identified by the Effective Request URI could not be
+   If the resource identified by the effective request URI could not be
    created or modified, an appropriate error response &SHOULD; be given
    that reflects the nature of the problem.
@@ -983 +982 @@
 <t>
    If the request passes through a cache that has one or more stored
-   responses for the Effective Request URI, those stored responses
+   responses for the effective request URI, those stored responses
    &SHOULD; be marked as stale if the response to the PUT request
    has a success status code. Responses to the PUT method are 
@@ -990 +989 @@
 <t>
    The fundamental difference between the POST and PUT requests is
-   reflected in the different meaning of the Effective Request URI. The URI in a
+   reflected in the different meaning of the effective request URI. The URI in a
    POST request identifies the resource that will handle the enclosed
    representation. That resource might be a data-accepting process, a gateway to
@@ -1015 +1014 @@
 </t>
 <t>
-   Unless otherwise specified for a particular entity-header, the
-   entity-headers in the PUT request &SHOULD; be applied to the resource
-   created or modified by the PUT.
+   Header fields in a PUT request that are recognized as representation
+   metadata &SHOULD; be applied to the resource created or modified by
+   the PUT.  Unrecognized header fields &SHOULD; be ignored.
 </t>
 </section>
@@ -1026 +1025 @@
 <t>
    The DELETE method requests that the origin server delete the resource
-   identified by the Effective Request URI. This method &MAY; be overridden by
+   identified by the effective request URI. This method &MAY; be overridden by
    human intervention (or other means) on the origin server. The client cannot
    be guaranteed that the operation has been carried out, even if the
@@ -1042 +1041 @@
 </t>
 <t>
-   If the request passes through a cache and the Effective Request URI
+   If the request passes through a cache and the effective request URI
    identifies one or more currently cached representations, those entries &SHOULD; be
    treated as stale. Responses to the DELETE method are not cacheable.
@@ -1168 +1167 @@
   <iref primary="true" item="Status Codes" subitem="200 OK" x:for-anchor=""/>
 <t>
-   The request has succeeded. The information returned with the response
+   The request has succeeded. The payload returned with the response
    is dependent on the method used in the request, for example:
   <list style="hanging">
     <t hangText="GET">
-          a representation corresponding to the requested resource is sent in
-          the response;
+          a representation of the resource corresponding to the effective
+          request URI is sent in the response;
     </t>
     <t hangText="HEAD">
-          the entity-header fields corresponding to the requested
-          resource are sent in the response without any message-body;
+          the same representation as GET, except without the message-body;
     </t>
     <t hangText="POST">
@@ -1243 +1241 @@
   <iref primary="true" item="Status Codes" subitem="203 Non-Authoritative Information" x:for-anchor=""/>
 <t>
-   The returned metadata in the entity-header is not the
+   The returned metadata in the header fields is not the
    definitive set as available from the origin server, but is gathered
    from a local or a third-party copy. The set presented &MAY; be a subset
@@ -1266 +1264 @@
    additional content to return in the response payload body.  The
    resource metadata and representation metadata in the response message's
-   header fields refer to the requested resource and its current
-   representation, respectively, after the requested action.
+   header fields refer to the target resource
+   and its current representation, respectively, after the requested action.
    For example, if a 204 status code is received in response to a PUT
    and the response contains an ETag header field, then the value of
    that field is the current entity-tag for the representation that
-   was successfully PUT to the requested resource.
+   was successfully PUT.
 </t>
 <t>
@@ -1340 +1338 @@
   <iref primary="true" item="Status Codes" subitem="300 Multiple Choices" x:for-anchor=""/>
 <t>
-   The requested resource corresponds to any one of a set of
-   representations, each with its own specific location, and agent-driven
+   The target resource more than one
+   representation, each with its own specific location, and agent-driven
    negotiation information (&content-negotiation;) is being provided so that
-   the user (or user agent) can select a preferred representation and
-   redirect its request to that location.
+   the user (or user agent) can select a preferred representation by
+   redirecting its request to that location.
 </t>
 <t>
    Unless it was a HEAD request, the response &SHOULD; include a representation
-   containing a list of resource characteristics and location(s) from
+   containing a list of representation metadata and location(s) from
    which the user or user agent can choose the one most appropriate. The
    data format is specified by the media type given in the Content-Type
@@ -1373 +1371 @@
   <iref primary="true" item="Status Codes" subitem="301 Moved Permanently" x:for-anchor=""/>
 <t>
-   The requested resource has been assigned a new permanent URI and any
+   The target resource has been assigned a new permanent URI and any
    future references to this resource &SHOULD; use one of the returned
    URIs.  Clients with link editing capabilities ought to automatically
-   re-link references to the Effective Request URI to one or more of the new
+   re-link references to the effective request URI to one or more of the new
    references returned by the server, where possible.
 </t>
@@ -1410 +1408 @@
   <iref primary="true" item="Status Codes" subitem="302 Found" x:for-anchor=""/>
 <t>
-   The requested resource resides temporarily under a different URI.
+   The target resource resides temporarily under a different URI.
    Since the redirection might be altered on occasion, the client &SHOULD;
-   continue to use the Effective Request URI for future requests.
+   continue to use the effective request URI for future requests.
 </t>
 <t>
@@ -1457 +1455 @@
    representation corresponding to the response, be redirected again,
    or end with an error status.  The Location URI is not a substitute
-   reference for the originally requested resource.
+   reference for the effective request URI.
 </t>
 <t>
@@ -1471 +1469 @@
    resource does not have a representation of its own that can be
    transferred by the server over HTTP.  The Location URI indicates a
-   resource that is descriptive of the requested resource such that
-   the follow-on representation might be useful without implying that
-   it adequately represents the previously requested resource.
+   resource that is descriptive of the target resource, such that the
+   follow-on representation might be useful to recipients without
+   implying that it adequately represents the target resource.
    Note that answers to the questions of what can be represented, what
    representations are adequate, and what might be a useful description
@@ -1520 +1518 @@
   <iref primary="true" item="Status Codes" subitem="307 Temporary Redirect" x:for-anchor=""/>
 <t>
-   The requested resource resides temporarily under a different URI.
+   The target resource resides temporarily under a different URI.
    Since the redirection can change over time, the client &SHOULD;
-   continue to use the Effective Request URI for future requests.
+   continue to use the effective request URI for future requests.
 </t>
 <t>
@@ -1610 +1608 @@
   <iref primary="true" item="Status Codes" subitem="404 Not Found" x:for-anchor=""/>
 <t>
-   The server has not found anything matching the Effective Request URI. No
+   The server has not found anything matching the effective request URI. No
    indication is given of whether the condition is temporary or
    permanent. The 410 (Gone) status code &SHOULD; be used if the server
@@ -1625 +1623 @@
   <iref primary="true" item="Status Codes" subitem="405 Method Not Allowed" x:for-anchor=""/>
 <t>
-   The method specified in the Request-Line is not allowed for the
-   resource identified by the Effective Request URI. The response &MUST; include an
+   The method specified in the Request-Line is not allowed for the target
+   resource. The response &MUST; include an
    Allow header containing a list of valid methods for the requested
    resource.
@@ -1714 +1712 @@
   <iref primary="true" item="Status Codes" subitem="410 Gone" x:for-anchor=""/>
 <t>
-   The requested resource is no longer available at the server and no
+   The target resource is no longer available at the server and no
    forwarding address is known. This condition is expected to be
    considered permanent. Clients with link editing capabilities &SHOULD;
-   delete references to the Effective Request URI after user approval. If the
+   delete references to the effective request URI after user approval. If the
    server does not know, or has no facility to determine, whether or not
    the condition is permanent, the status code 404 (Not Found) &SHOULD; be
@@ -1784 +1782 @@
   <iref primary="true" item="Status Codes" subitem="414 URI Too Long" x:for-anchor=""/>
 <t>
-   The server is refusing to service the request because the Effective Request URI
+   The server is refusing to service the request because the effective request URI
    is longer than the server is willing to interpret. This rare
    condition is only likely to occur when a client has improperly
@@ -1792 +1790 @@
    itself), or when the server is under attack by a client attempting to
    exploit security holes present in some servers using fixed-length
-   buffers for reading or manipulating the Effective Request URI.
+   buffers for reading or manipulating the effective request URI.
 </t>
 </section>
@@ -1801 +1799 @@
 <t>
    The server is refusing to service the request because the representation of
-   the request is in a format not supported by the requested resource
+   the request is in a format not supported by the target resource
    for the requested method.
 </t>
@@ -1932 +1930 @@
    related to request and response semantics.
 </t>
-<t>
-   For entity-header fields, both sender and recipient refer to either the
-   client or the server, depending on who sends and who receives the message.
-</t>
 
 <section title="Allow" anchor="header.allow">
@@ -1944 +1938 @@
 <t>
    The "Allow" response-header field lists the set of methods advertised as
-   supported by the resource identified by the Effective Request URI. The purpose of
+   supported by the target resource. The purpose of
    this field is strictly to inform the recipient of valid methods
    associated with the resource.
@@ -2177 +2171 @@
 <t>
    The "Referer" [sic] request-header field allows the client to specify the
-   URI of the resource from which the Effective Request URI was obtained (the
+   URI of the resource from which the effective request URI was obtained (the
    "referrer", although the header field is misspelled.).
 </t>
@@ -2189 +2183 @@
 </t>
 <t>
-   If the Effective Request URI was obtained from a source that does not have its own
+   If the effective request URI was obtained from a source that does not have its own
    URI (e.g., input from the user keyboard), the Referer field &MUST; either be
    sent with the value "about:blank", or not be sent at all. Note that this
@@ -2206 +2200 @@
 <t>
    If the field value is a relative URI, it &SHOULD; be interpreted
-   relative to the Effective Request URI. The URI &MUST-NOT; include a fragment. See
+   relative to the effective request URI. The URI &MUST-NOT; include a fragment. See
    <xref target="encoding.sensitive.information.in.uris"/> for security considerations.
 </t>
@@ -3290 +3284 @@
 <t>
   Deprecate 305 Use Proxy status code, because user agents did not implement it.
-  It used to indicate that the requested resource must be accessed through the
+  It used to indicate that the target resource must be accessed through the
   proxy given by the Location field. The Location field gave the URI of the
   proxy. The recipient was expected to repeat this single request via the proxy.

draft-ietf-httpbis/latest/p3-payload.xml

@@ -260 +260 @@
   </list>
 </t>
-<t>
-  <iref item="payload"/>
-  <x:dfn>payload</x:dfn>
-  <list>
-    <t>
-      The information transferred within a given message is called the
-      payload, consisting  of optional payload metadata and an optional
-      payload body.  The payload in HTTP is always a partial or complete
-      representation of some resource, though which resource is represented
-      is dependent on the type of message (request or response), the
-      request method, and the response status code.
-    </t>
-  </list>
-</t>
-<t>
-  <iref item="representation"/>
-  <x:dfn>representation</x:dfn>
-  <list>
-    <t>
-      A representation is information in a format that can be readily
-      communicated from one party to another.  For our purposes, a
-      representation is binary data and its associated metadata.
-      A representation of a resource is information that reflects the
-      state of that resource, as observed at some point in the past
-      or to be desired at some point in the future.
-    </t>
-  </list>
-</t>
 </section>
 
@@ -705 +677 @@
 </section>
 
-<section title="Representation" anchor="representation">
-<t>
-   Request and Response messages &MAY; transfer a representation if not otherwise
-   restricted by the request method or response status code. A representation
-   consists of entity-header fields and a representation body, although some
-   responses will only include the entity-headers.
-</t>
-<t>
-   In this section, both sender and recipient refer to either the client
-   or the server, depending on who sends and who receives the message.
-</t>
-
-<section title="Entity Header Fields" anchor="entity.header.fields">
-  <x:anchor-alias value="entity-header"/>
-  <x:anchor-alias value="extension-header"/>
-<t>
-   Entity-header fields define metadata about the representation data
-   enclosed in the message-body or, if no message-body is present, about
-   the representation that would have been transferred in a 200 response
-   to a simultaneous GET request on the Effective Request URI.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="entity-header"/><iref primary="true" item="Grammar" subitem="extension-header"/>
-  <x:ref>entity-header</x:ref>  = <x:ref>Content-Encoding</x:ref>         ; <xref target="header.content-encoding"/>
-                 / <x:ref>Content-Language</x:ref>         ; <xref target="header.content-language"/>
-                 / <x:ref>Content-Length</x:ref>           ; &header-content-length;
-                 / <x:ref>Content-Location</x:ref>         ; <xref target="header.content-location"/>
-                 / <x:ref>Content-MD5</x:ref>              ; <xref target="header.content-md5"/>
-                 / <x:ref>Content-Range</x:ref>            ; &header-content-range;
-                 / <x:ref>Content-Type</x:ref>             ; <xref target="header.content-type"/>
-                 / <x:ref>Expires</x:ref>                  ; &header-expires;
-                 / <x:ref>Last-Modified</x:ref>            ; &header-last-modified;
-                 / <x:ref>extension-header</x:ref>
-  
-  <x:ref>extension-header</x:ref> = <x:ref>header-field</x:ref>
-</artwork></figure>
-<t>
-   The extension-header mechanism allows additional entity-header fields
-   to be defined without changing the protocol, but these fields cannot
-   be assumed to be recognizable by the recipient. Unrecognized header
-   fields &SHOULD; be ignored by the recipient and &MUST; be forwarded by
-   transparent proxies.
-</t>
+<section title="Payload" anchor="payload">
+<t>
+   HTTP messages &MAY; transfer a payload if not otherwise restricted by
+   the request method or response status code.  The payload consists of
+   metadata, in the form of header fields, and data, in the form of the
+   sequence of octets in the message-body after any transfer-coding has
+   been decoded.
+</t>
+<iref item="payload"/>
+<t>   
+   A "<x:dfn>payload</x:dfn>" in HTTP is always a partial or complete
+   representation of some resource.  We use separate terms for payload
+   and representation because some messages contain only the associated
+   representation's header fields (e.g., responses to HEAD) or only some
+   part(s) of the representation (e.g., the 206 status code).
+</t>
+<t>
+    define metadata for the whole representation, which we refer
+   to as "representation header fields", while others define only metadata
+   about what is included in the message, which we 
+</t>
+<section title="Payload Header Fields" anchor="payload.header.fields">
+  <x:anchor-alias value="payload-header"/>
+<t>
+   HTTP header fields that specifically define the payload, rather than the
+   associated representation, are referred to as "payload header fields".
+   The following payload header fields are defined by HTTP/1.1:
+</t>
+<figure><artwork>
+   <x:ref>Content-Length</x:ref>           ; &header-content-length;
+   <x:ref>Content-MD5</x:ref>              ; <xref target="header.content-md5"/>
+   <x:ref>Content-Range</x:ref>            ; &header-content-range;
+</artwork></figure>
 </section>
 
 <section title="Payload Body" anchor="payload.body">
   <x:anchor-alias value="payload-body"/>
-<t>
-   The payload body (if any) sent with an HTTP request or response is in
-   a format and encoding defined by the entity-header fields.
-</t>
 <t>
    A payload body is only present in a message when a message-body is
@@ -761 +720 @@
    have been applied to ensure safe and proper transfer of the message.
 </t>
-
-<section title="Type" anchor="type">
-<t>
-   When a payload body is included with a message, the data type of that
-   body is determined via the header fields Content-Type and Content-Encoding.
+</section>
+</section>
+
+<section title="Representation" anchor="representation">
+<iref item="representation"/>
+<t>
+   A "<x:dfn>representation</x:dfn>" is information in a format that can be readily
+   communicated from one party to another.  A resource representation
+   is information that reflects the state of that resource, as observed
+   at some point in the past (e.g., in a response to GET) or to be
+   desired at some point in the future (e.g., in a PUT request).
+</t>
+<t>
+   Most, but not all, representations transferred via HTTP are intended
+   to be a representation of the target resource (the resource identified
+   by the effective request URI).  The precise semantics of a representation
+   are determined by the type of message (request or response), the request
+   method, the response status code, and the representation metadata.
+   For example, the above semantic is true for the representation in any
+   200 (OK) response to GET and for the representation in any PUT request.
+   A 200 response to PUT, in contrast, contains either a representation
+   that describes the successful action or a representation of the target
+   resource, with the latter indicated by a Content-Location header field
+   with the same value as the effective request URI.  Likewise, response
+   messages with an error status code usually contain a representation that
+   describes the error and what next steps are suggested for resolving it.
+</t>
+
+<section title="Representation Header Fields" anchor="representation.header.fields">
+  <x:anchor-alias value="representation-header"/>
+<t>
+   Representation header fields define metadata about the representation data
+   enclosed in the message-body or, if no message-body is present, about
+   the representation that would have been transferred in a 200 response
+   to a simultaneous GET request with the same effective request URI.
+</t>
+<t>
+   The following header fields are defined as representation metadata:
+</t>
+<figure><artwork>
+   <x:ref>Content-Encoding</x:ref>         ; <xref target="header.content-encoding"/>
+   <x:ref>Content-Language</x:ref>         ; <xref target="header.content-language"/>
+   <x:ref>Content-Location</x:ref>         ; <xref target="header.content-location"/>
+   <x:ref>Content-Type</x:ref>             ; <xref target="header.content-type"/>
+   <x:ref>Expires</x:ref>                  ; &header-expires;
+   <x:ref>Last-Modified</x:ref>            ; &header-last-modified;
+</artwork></figure>
+</section>
+
+<section title="Representation Data" anchor="representation.data">
+  <x:anchor-alias value="representation-data"/>
+<t>
+   The representation body associated with an HTTP message is
+   either provided as the payload body of the message or
+   referred to by the message semantics and the effective request
+   URI.  The representation data is in a format and encoding defined by
+   the representation metadata header fields.
+</t>
+<t>
+   The data type of the representation data
+   is determined via the header fields Content-Type and Content-Encoding.
    These define a two-layer, ordered encoding model:
 </t>
 <figure><artwork type="example">
-  payload-body := Content-Encoding( Content-Type( data ) )
-</artwork></figure>
-<t>
-   Content-Type specifies the media type of the underlying data. Any HTTP/1.1
-   message containing a payload body &SHOULD; include a Content-Type header
-   field defining the media type of that body, unless that information is
-   unknown.
-</t>
-<t>   
+  representation-data := Content-Encoding( Content-Type( bits ) )
+</artwork></figure>
+<t>
+   Content-Type specifies the media type of the underlying data, which
+   defines both the data format and how that data &SHOULD; be processed
+   by the recipient (within the scope of the request method semantics).
+   Any HTTP/1.1 message containing a payload body &SHOULD; include a
+   Content-Type header field defining the media type of the associated
+   representation unless that metadata is unknown to the sender.
    If the Content-Type header field is not present, it indicates that
-   the sender does not know the media type of the data; recipients &MAY;
-   either assume that it is "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
+   the sender does not know the media type of the representation;
+   recipients &MAY; either assume that the media type is
+   "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
    or examine the content to determine its type.
 </t>
 <t>
-   In practice, currently-deployed servers sometimes provide a Content-Type
-   header which does not correctly convey the intended interpretation of the
-   content sent, with the result that some clients will examine the response
-   body's content and override the specified type.
-</t>
-<t>
+   In practice, resource owners do not always properly configure their origin
+   server to provide the correct Content-Type for a given representation,
+   with the result that some clients will examine a response body's content
+   and override the specified type.
    Clients that do so risk drawing incorrect conclusions, which might expose
-   additional security risks (e.g., "privilege escalation"). Implementers are
-   encouraged to provide a means of disabling such "content sniffing" when it
-   is used.
+   additional security risks (e.g., "privilege escalation").  Furthermore,
+   it is impossible to determine the sender's intent by examining the data
+   format: many data formats match multiple media types that differ only in
+   processing semantics.  Implementers are encouraged to provide a means of
+   disabling such "content sniffing" when it is used.
 </t>
 <t>
    Content-Encoding is used to indicate any additional content
    codings applied to the data, usually for the purpose of data
-   compression, that are a property of the representation.  There is
-   no default encoding.
-</t>
-</section>
-   
+   compression, that are a property of the representation.  If
+   Content-Encoding is not present, then there is no additional
+   encoding beyond that defined by the Content-Type.
+</t>
 </section>
 </section>
@@ -962 +977 @@
    This section defines the syntax and semantics of HTTP/1.1 header fields
    related to the payload of messages.
-</t>
-<t>
-   For entity-header fields, both sender and recipient refer to either the
-   client or the server, depending on who sends and who receives the message.
 </t>
 
@@ -1309 +1320 @@
   <x:anchor-alias value="Content-Encoding-v"/>
 <t>
-   The "Content-Encoding" entity-header field indicates what content-codings 
+   The "Content-Encoding" header field indicates what content-codings 
    have been applied to the representation, and thus what decoding mechanisms
    must be applied in order to obtain the media-type referenced by the 
@@ -1359 +1370 @@
   <x:anchor-alias value="Content-Language-v"/>
 <t>
-   The "Content-Language" entity-header field describes the natural
+   The "Content-Language" header field describes the natural
    language(s) of the intended audience for the representation. Note that this might
    not be equivalent to all the languages used within the representation.
@@ -1434 +1445 @@
 <t>
    If Content-Location is included in a response message and its value
-   is the same as the Effective Request URI, then the response payload
+   is the same as the effective request URI, then the response payload
    &SHOULD; be considered the current representation of that resource.
    For a GET or HEAD request, this is the same as the default semantics
@@ -1446 +1457 @@
 <t>
    If Content-Location is included in a response message and its value
-   differs from the Effective Request URI, then the origin server is
+   differs from the effective request URI, then the origin server is
    informing recipients that this representation has its own, presumably
    more specific, identifier.  For a GET or HEAD request, this is an
-   indication that the Effective Request URI identifies a resource that
+   indication that the effective request URI identifies a resource that
    is subject to content negotiation and the representation selected for
    this response can also be found at the identified URI.  For other
@@ -1491 +1502 @@
 </t>
 <t>
-   If the Content-Location value is a partial URI, it is
-   interpreted relative to the Effective Request URI.
+   If the Content-Location value is a partial URI, the partial URI is
+   interpreted relative to the effective request URI.
 </t>
 </section>
@@ -1502 +1513 @@
   <x:anchor-alias value="Content-MD5-v"/>
 <t>
-   The "Content-MD5" entity-header field, as defined in <xref target="RFC1864"/>, is
+   The "Content-MD5" header field, as defined in <xref target="RFC1864"/>, is
    an MD5 digest of the payload body that provides an end-to-end message
    integrity check (MIC) of the payload body (the message-body after any
@@ -1577 +1588 @@
   <x:anchor-alias value="Content-Type-v"/>
 <t>
-   The "Content-Type" entity-header field indicates the media type of the
+   The "Content-Type" header field indicates the media type of the
    representation. In the case of responses to the HEAD method, the media type is
    that which would have been sent had the request been a GET.
@@ -1592 +1603 @@
 </artwork></figure>
 <t>
-   Further discussion of methods for identifying the media type of a
-   representation is provided in <xref target="type"/>.
+   Further discussion of Content-Type is provided in <xref target="representation.data"/>.
 </t>
 </section>
@@ -2818 +2828 @@
 <x:ref>disposition-type</x:ref> = "attachment" / disp-extension-token
 
-<x:ref>entity-header</x:ref> = Content-Encoding / Content-Language / Content-Length
- / Content-Location / Content-MD5 / Content-Range / Content-Type /
- Expires / Last-Modified / extension-header
-<x:ref>extension-header</x:ref> = header-field
-
 <x:ref>filename-parm</x:ref> = "filename=" quoted-string
 
@@ -2857 +2862 @@
 ; MIME-Version defined but not used
 ; content-disposition defined but not used
-; entity-header defined but not used
 </artwork></figure></section>
 <?ENDINC p3-payload.abnf-appendix ?>

draft-ietf-httpbis/latest/p4-conditional.xml

@@ -312 +312 @@
   <x:anchor-alias value="weak"/>
 <t>
-   Entity-tags are used for comparing two or more representations from the same
-   requested resource. HTTP/1.1 uses entity-tags in the ETag (<xref target="header.etag"/>),
+   Entity-tags are used for comparing two or more representations of the same
+   resource. HTTP/1.1 uses entity-tags in the ETag (<xref target="header.etag"/>),
    If-Match (<xref target="header.if-match"/>), If-None-Match (<xref target="header.if-none-match"/>), and
    If-Range (&header-if-range;) header fields. The definition of how they
@@ -725 +725 @@
    related to conditional requests.
 </t>
-<t>
-   For entity-header fields, both sender and recipient refer to either the
-   client or the server, depending on who sends and who receives the message.
-</t>
 
 <section title="ETag" anchor="header.etag">
@@ -738 +734 @@
    The "ETag" response-header field provides the current value of the
    entity-tag (see <xref target="entity.tags"/>) for one representation of
-   the resource identified by the Effective Request URI.  An entity-tag
+   the resource identified by the effective request URI.  An entity-tag
    is intended for use as a resource-local identifier for differentiating
    between representations of the same resource that vary over time or via
@@ -1058 +1054 @@
   <x:anchor-alias value="Last-Modified-v"/>
 <t>
-   The "Last-Modified" entity-header field indicates the date and time at
+   The "Last-Modified" header field indicates the date and time at
    which the origin server believes the representation was last modified.
 </t>
@@ -1098 +1094 @@
 </t>
 <t>
-   The Last-Modified entity-header field value is often used as a cache
+   The Last-Modified header field value is often used as a cache
    validator. In simple terms, a cache entry is considered to be valid
    if the representation has not been modified since the Last-Modified value.

draft-ietf-httpbis/latest/p5-range.xml

@@ -397 +397 @@
 <t>
    If the 206 response is the result of an If-Range request, the response
-   &SHOULD-NOT; include other entity-headers. Otherwise, the response
-   &MUST; include all of the entity-headers that would have been returned
+   &SHOULD-NOT; include other representation header fields. Otherwise, the response
+   &MUST; include all of the representation header fields that would have been returned
    with a 200 (OK) response to the same request.
 </t>
@@ -428 +428 @@
 <t>
    When this status code is returned for a byte-range request, the
-   response &SHOULD; include a Content-Range entity-header field
-   specifying the current length of the selected resource (see <xref target="header.content-range"/>).
+   response &SHOULD; include a Content-Range header field
+   specifying the current length of the representation (see <xref target="header.content-range"/>).
    This response &MUST-NOT; use the multipart/byteranges content-type.
 </t>
@@ -467 +467 @@
    This section defines the syntax and semantics of HTTP/1.1 header fields
    related to range requests and partial responses.
-</t>
-<t>
-   For entity-header fields, both sender and recipient refer to either the
-   client or the server, depending on who sends and who receives the message.
 </t>
 
@@ -523 +519 @@
   <x:anchor-alias value="other-range-resp-spec"/>
 <t>
-   The "Content-Range" entity-header field is sent with a partial representation to
-   specify where in the full representation the partial body should be
+   The "Content-Range" header field is sent with a partial representation to
+   specify where in the full representation the payload body should be
    applied.
 </t>
@@ -1632 +1628 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
-      "Clarify entity / representation / variant terminology"
-    </t>
-    <t>
-      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
       "consider removing the 'changes from 2068' sections"
     </t>

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

@@ -504 +504 @@
    unless:
    <list style="symbols">
-      <t>The presented Effective Request URI (&effective-request-uri;) and
+      <t>The presented effective request URI (&effective-request-uri;) and
       that of the stored response match, and</t>
       <t>the request method associated with the stored response allows it to
@@ -868 +868 @@
    An invalidation based on a URI from a Location or Content-Location header
    &MUST-NOT; be performed if the host part of that URI differs from the host
-   part in the Effective Request URI (&effective-request-uri;). This helps
+   part in the effective request URI (&effective-request-uri;). This helps
    prevent denial of service attacks.
 </t>
 <t>
    A cache that passes through requests for methods it does not understand
-   &SHOULD; invalidate the Effective Request URI (&effective-request-uri;).
+   &SHOULD; invalidate the effective request URI (&effective-request-uri;).
 </t>
 <t>
    Here, "invalidate" means that the cache will either remove all stored
-   responses related to the Effective Request URI, or will mark these as
+   responses related to the effective request URI, or will mark these as
    "invalid" and in need of a mandatory validation before they can be returned
    in response to a subsequent request.
@@ -1010 +1010 @@
    related to caching.
 </t>
-<t>
-   For entity-header fields, both sender and recipient refer to either the
-   client or the server, depending on who sends and who receives the message.
-</t>
 
 <section anchor="header.age" title="Age">
@@ -1435 +1431 @@
    <x:anchor-alias value="Expires-v"/>
 <t>
-   The "Expires" entity-header field gives the date/time after which the
+   The "Expires" header field gives the date/time after which the
    response is considered stale. See <xref target="expiration.model" /> for
    further discussion of the freshness model.
@@ -2608 +2604 @@
   <list style="symbols"> 
     <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/109"/>:
+      "Clarify entity / representation / variant terminology"
+    </t>
+    <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
       "consider removing the 'changes from 2068' sections"

draft-ietf-httpbis/latest/p7-auth.xml

@@ -303 +303 @@
    The request requires user authentication. The response &MUST; include a
    WWW-Authenticate header field (<xref target="header.www-authenticate"/>) containing a challenge
-   applicable to the requested resource. The client &MAY; repeat the
+   applicable to the target resource. The client &MAY; repeat the
    request with a suitable Authorization header field (<xref target="header.authorization"/>). If
    the request already included Authorization credentials, then the 401
@@ -323 +323 @@
    client must first authenticate itself with the proxy. The proxy &MUST;
    return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a
-   challenge applicable to the proxy for the requested resource. The
+   challenge applicable to the proxy for the target resource. The
    client &MAY; repeat the request with a suitable Proxy-Authorization
    header field (<xref target="header.proxy-authorization"/>). HTTP access authentication is explained
@@ -402 +402 @@
    The "Proxy-Authenticate" response-header field consists of a challenge that
    indicates the authentication scheme and parameters applicable to the proxy
-   for this Effective Request URI (&effective-request-uri;). It &MUST; be included as part
+   for this effective request URI (&effective-request-uri;). It &MUST; be included as part
    of a 407 (Proxy Authentication Required) response.
 </t>
@@ -461 +461 @@
    The "WWW-Authenticate" response-header field consists of at least one
    challenge that indicates the authentication scheme(s) and parameters
-   applicable to the Effective Request URI (&effective-request-uri;). It &MUST; be included in 401
+   applicable to the effective request URI (&effective-request-uri;). It &MUST; be included in 401
    (Unauthorized) response messages.
 </t>