Changeset 874

Timestamp:

23/07/10 05:43:26 (12 years ago)

Author:

fielding@…

Message:

Addresses #109: Clarify entity / representation / variant terminology

Replace more entity, entities, and entity-body, as appropriate.

Addresses #183: "requested resource" in content-encoding definition

Fixed.

Clarifies #178: Content-MD5 and partial responses

New terminology makes it easier to understand what is digested.

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.xml (modified) (1 diff)
• p2-semantics.xml (modified) (21 diffs)
• p3-payload.xml (modified) (24 diffs)
• p4-conditional.xml (modified) (30 diffs)
• p5-range.xml (modified) (13 diffs)
• p6-cache.xml (modified) (7 diffs)
• p7-auth.xml (modified) (1 diff)

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

@@ -22 +22 @@
   <!ENTITY CONNECT                "<xref target='Part2' x:rel='#CONNECT' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY content.negotiation    "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
-  <!ENTITY diff-mime              "<xref target='Part3' x:rel='#differences.between.http.entities.and.rfc.2045.entities' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
-  <!ENTITY entity                 "<xref target='Part3' x:rel='#entity' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!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'/>">

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

@@ -654 +654 @@
 </section>
 
-<section title="Representation" anchor="entity">
+<section title="Representation" anchor="representation">
 <t>
    Request and Response messages &MAY; transfer a representation if not otherwise
@@ -779 +779 @@
 </t>
 <t>
-   If the OPTIONS request includes an entity-body (as indicated by the
+   If the OPTIONS request includes a message-body (as indicated by the
    presence of Content-Length or Transfer-Encoding), then the media type
    &MUST; be indicated by a Content-Type field. Although this
@@ -833 +833 @@
   <iref primary="true" item="Methods" subitem="GET" x:for-anchor=""/>
 <t>
-   The GET method means retrieve whatever information (in the form of an
-   entity) currently corresponds to the resource identified by the
+   The GET method means retrieve whatever information (in the form of a
+   representation) currently corresponds to the resource identified by the
    Effective Request URI.
 </t>
@@ -850 +850 @@
    circumstances described by the conditional header field(s). The
    conditional GET method is intended to reduce unnecessary network
-   usage by allowing cached entities to be refreshed without requiring
+   usage by allowing cached representations to be refreshed without requiring
    multiple requests or transferring data already held by the client.
 </t>
@@ -889 +889 @@
    The response to a HEAD request &MAY; be cacheable in the sense that the
    information contained in the response &MAY; be used to update a
-   previously cached entity from that resource. If the new field values
-   indicate that the cached entity differs from the current entity (as
+   previously cached representation from that resource. If the new field values
+   indicate that the cached representation differs from the current representation (as
    would be indicated by a change in Content-Length, Content-MD5, ETag
    or Last-Modified), then the cache &MUST; treat the cache entry as
@@ -902 +902 @@
 <t>
    The POST method is used to request that the origin server accept the
-   entity enclosed in the request as data to be processed by the resource
+   representation enclosed in the request as data to be processed by the resource
    identified by the Effective Request URI. POST is designed
    to allow a uniform method to cover the following functions:
@@ -930 +930 @@
    resource that can be identified by a URI. In this case, either 200
    (OK) or 204 (No Content) is the appropriate response status,
-   depending on whether or not the response includes an entity that
+   depending on whether or not the response includes a representation that
    describes the result.
 </t>
 <t>
    If a resource has been created on the origin server, the response
-   &SHOULD; be 201 (Created) and contain an entity which describes the
+   &SHOULD; be 201 (Created) and contain a representation which describes the
    status of the request and refers to the new resource, and a Location
    header (see <xref target="header.location"/>).
@@ -1030 +1030 @@
 <t>
    A successful response &SHOULD; be 200 (OK) if the response includes an
-   entity describing the status, 202 (Accepted) if the action has not
+   representation describing the status, 202 (Accepted) if the action has not
    yet been enacted, or 204 (No Content) if the action has been enacted
    but the response does not include a representation.
@@ -1036 +1036 @@
 <t>
    If the request passes through a cache and the Effective Request URI
-   identifies one or more currently cached entities, those entries &SHOULD; be
-   treated as stale. Responses to this method are not cacheable.
+   identifies one or more currently cached representations, those entries &SHOULD; be
+   treated as stale. Responses to the DELETE method &MUST-NOT; be cached.
 </t>
 </section>
@@ -1051 +1051 @@
    of the request message. The final recipient of the request
    &SHOULD; reflect the message received back to the client as the
-   entity-body of a 200 (OK) response. The final recipient is either the
+   message-body of a 200 (OK) response. The final recipient is either the
    origin server or the first proxy or gateway to receive a Max-Forwards
    value of zero (0) in the request (see <xref target="header.max-forwards"/>).
@@ -1066 +1066 @@
 </t>
 <t>
-   If the request is valid, the response &SHOULD; contain the entire
-   request message in the entity-body, with a Content-Type of
-   "message/http" (see &media-type-message-http;). Responses to this method
-   &MUST-NOT; be cached.
+   If the request is valid, the response &SHOULD; have a Content-Type of
+   "message/http" (see &media-type-message-http;) and contain a message-body
+   that encloses a copy of the entire request message.
+   Responses to the TRACE method &MUST-NOT; be cached.
 </t>
 </section>
@@ -1165 +1165 @@
   <list style="hanging">
     <t hangText="GET">
-          an entity corresponding to the requested resource is sent in
+          a representation corresponding to the requested resource is sent in
           the response;
     </t>
@@ -1173 +1173 @@
     </t>
     <t hangText="POST">
-      an entity describing or containing the result of the action;
+      a representation describing or containing the result of the action;
     </t>
     <t hangText="TRACE">
-      an entity containing the request message as received by the
+      a representation containing the request message as received by the
       end server.
     </t>
@@ -1201 +1201 @@
 <t>
    A 201 response &MAY; contain an ETag response header field indicating
-   the current value of the entity tag for the representation of the resource
+   the current value of the entity-tag for the representation of the resource
    just created (see &header-etag;).
 </t>
@@ -1292 +1292 @@
 <t>
    The server has fulfilled the partial GET request for the resource
-   and the enclosed entity is a partial representation as defined in &status-206;.
+   and the enclosed payload is a partial representation as defined in &status-206;.
 </t>
 </section>
@@ -1525 +1525 @@
    The 4xx class of status code is intended for cases in which the
    client seems to have erred. Except when responding to a HEAD request,
-   the server &SHOULD; include an entity containing an explanation of the
+   the server &SHOULD; include a representation containing an explanation of the
    error situation, and whether it is a temporary or permanent
    condition. These status codes are applicable to any request method.
-   User agents &SHOULD; display any included entity to the user.
+   User agents &SHOULD; display any included representation to the user.
 </t>
 <t>
@@ -1614 +1614 @@
 <t>
    The resource identified by the request is only capable of generating
-   response entities which have content characteristics not acceptable
+   response representations which have content characteristics not acceptable
    according to the accept headers sent in the request.
 </t>
@@ -1671 +1671 @@
    and resubmit the request. The response body &SHOULD; include enough
    information for the user to recognize the source of the conflict.
-   Ideally, the response entity would include enough information for the
+   Ideally, the response representation would include enough information for the
    user or user agent to fix the problem; however, that might not be
    possible and is not required.
@@ -1741 +1741 @@
 <t>
    The server is refusing to process a request because the request
-   entity is larger than the server is willing or able to process. The
+   representation is larger than the server is willing or able to process. The
    server &MAY; close the connection to prevent the client from continuing
    the request.
@@ -1808 +1808 @@
    which the server is aware that it has erred or is incapable of
    performing the request. Except when responding to a HEAD request, the
-   server &SHOULD; include an entity containing an explanation of the
+   server &SHOULD; include a representation containing an explanation of the
    error situation, and whether it is a temporary or permanent
-   condition. User agents &SHOULD; display any included entity to the
+   condition. User agents &SHOULD; display any included representation to the
    user. These response codes are applicable to any request method.
 </t>
@@ -1890 +1890 @@
    using the same major version as the client, as described in &http-version;,
    other than with this error message. The response &SHOULD; contain
-   an entity describing why that version is not supported and what other
+   a representation describing why that version is not supported and what other
    protocols are supported by that server.
 </t>

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

@@ -602 +602 @@
 <section title="Canonicalization and Text Defaults" anchor="canonicalization.and.text.defaults">
 <t>
-   Internet media types are registered with a canonical form. An
-   entity-body transferred via HTTP messages &MUST; be represented in the
+   Internet media types are registered with a canonical form. A
+   representation transferred via HTTP messages &MUST; be in the
    appropriate canonical form prior to its transmission except for
    "text" types, as defined in the next paragraph.
@@ -611 +611 @@
    the text line break. HTTP relaxes this requirement and allows the
    transport of text media with plain CR or LF alone representing a line
-   break when it is done consistently for an entire entity-body. HTTP
-   applications &MUST; accept CRLF, bare CR, and bare LF as being
-   representative of a line break in text media received via HTTP. In
-   addition, if the text is represented in a character set that does not
+   break when it is done consistently for an entire representation. HTTP
+   applications &MUST; accept CRLF, bare CR, and bare LF as indicating
+   a line break in text media received via HTTP. In
+   addition, if the text is in a character encoding that does not
    use octets 13 and 10 for CR and LF respectively, as is the case for
-   some multi-byte character sets, HTTP allows the use of whatever octet
-   sequences are defined by that character set to represent the
+   some multi-byte character encodings, HTTP allows the use of whatever octet
+   sequences are defined by that character encoding to represent the
    equivalent of CR and LF for line breaks. This flexibility regarding
-   line breaks applies only to text media in the entity-body; a bare CR
+   line breaks applies only to text media in the payload body; a bare CR
    or LF &MUST-NOT; be substituted for CRLF within any of the HTTP control
    structures (such as header fields and multipart boundaries).
 </t>
 <t>
-   If an entity-body is encoded with a content-coding, the underlying
+   If a representation is encoded with a content-coding, the underlying
    data &MUST; be in a form defined above prior to being encoded.
 </t>
 <t>
    The "charset" parameter is used with some media types to define the
-   character set (<xref target="character.sets"/>) of the data. When no explicit charset
+   character encoding (<xref target="character.sets"/>) of the data. When no explicit charset
    parameter is provided by the sender, media subtypes of the "text"
    type are defined to have a default charset value of "ISO-8859-1" when
-   received via HTTP. Data in character sets other than "ISO-8859-1" or
+   received via HTTP. Data in character encodings other than "ISO-8859-1" or
    its subsets &MUST; be labeled with an appropriate charset value. See
    <xref target="missing.charset"/> for compatibility problems.
@@ -641 +641 @@
 <t>
    MIME provides for a number of "multipart" types -- encapsulations of
-   one or more entities within a single message-body. All multipart
+   one or more representations within a single message-body. All multipart
    types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>,
    and &MUST; include a boundary parameter as part of the media type
@@ -705 +705 @@
 </section>
 
-<section title="Entity" anchor="entity">
+<section title="Representation" anchor="representation">
 <t>
    Request and Response messages &MAY; transfer a representation if not otherwise
@@ -721 +721 @@
   <x:anchor-alias value="extension-header"/>
 <t>
-   Entity-header fields define metadata about the entity-body or,
-   if no body is present, about the resource identified by the request.
+   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"/>
@@ -747 +749 @@
 </section>
 
-<section title="Entity Body" anchor="entity.body">
-  <x:anchor-alias value="entity-body"/>
-<t>
-   The entity-body (if any) sent with an HTTP request or response is in
+<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>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="entity-body"/>
-  <x:ref>entity-body</x:ref>    = *<x:ref>OCTET</x:ref>
-</artwork></figure>
-<t>
-   An entity-body is only present in a message when a message-body is
-   present, as described in &message-body;. The entity-body is obtained
+<t>
+   A payload body is only present in a message when a message-body is
+   present, as described in &message-body;. The payload body is obtained
    from the message-body by decoding any Transfer-Encoding that might
    have been applied to ensure safe and proper transfer of the message.
@@ -765 +764 @@
 <section title="Type" anchor="type">
 <t>
-   When an entity-body is included with a message, the data type of that
+   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.
    These define a two-layer, ordered encoding model:
 </t>
 <figure><artwork type="example">
-  entity-body := Content-Encoding( Content-Type( data ) )
+  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 an entity-body &SHOULD; include a Content-Type header
+   message containing a payload body &SHOULD; include a Content-Type header
    field defining the media type of that body, unless that information is
    unknown.
@@ -791 +790 @@
 </t>
 <t>
-   Client that do so risk drawing incorrect conclusions, which may expose
+   Clients that do so risk drawing incorrect conclusions, which may expose
    additional security risks (e.g., "privilege escalation"). Implementers are
    encouraged to provide a means of disabling such "content sniffing" when it
@@ -799 +798 @@
    Content-Encoding may be used to indicate any additional content
    codings applied to the data, usually for the purpose of data
-   compression, that are a property of the requested resource.  There is
+   compression, that are a property of the representation.  There is
    no default encoding.
 </t>
@@ -928 +927 @@
    initial response from the origin server. Selection is based on a list
    of the available representations of the response included within the
-   header fields or entity-body of the initial response, with each
+   header fields or body of the initial response, with each
    representation identified by its own URI. Selection from among the
    representations may be performed automatically (if the user agent is
@@ -1342 +1341 @@
 </t>
 <t>
-   If the content-coding of an entity in a request message is not
+   If the content-coding of a representation in a request message is not
    acceptable to the origin server, the server &SHOULD; respond with a
    status code of 415 (Unsupported Media Type).
@@ -1362 +1361 @@
    The "Content-Language" entity-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 entity-body.
+   not be equivalent to all the languages used within the representation.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/><iref primary="true" item="Grammar" subitem="Content-Language-v"/>
@@ -1504 +1503 @@
 <t>
    The "Content-MD5" entity-header field, as defined in <xref target="RFC1864"/>, is
-   an MD5 digest of the entity-body that provides an end-to-end message
-   integrity check (MIC) of the entity-body. Note that a MIC is good for
-   detecting accidental modification of the entity-body in transit, but is not
+   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
+   transfer-coding is decoded). Note that a MIC is good for
+   detecting accidental modification of the payload body in transit, but is not
    proof against malicious attacks.
 </t>
@@ -1515 +1515 @@
 <t>
    The Content-MD5 header field &MAY; be generated by an origin server or
-   client to function as an integrity check of the entity-body. Only
-   origin servers or clients &MAY; generate the Content-MD5 header field;
+   client to function as an integrity check of the payload body. Only
+   origin servers or user agents &MAY; generate the Content-MD5 header field;
    proxies and gateways &MUST-NOT; generate it, as this would defeat its
-   value as an end-to-end integrity check. Any recipient of the entity-body,
-   including gateways and proxies, &MAY; check that the digest value
-   in this header field matches that of the entity-body as received.
-</t>
-<t>
-   The MD5 digest is computed based on the content of the entity-body,
-   including any content-coding that has been applied, but not including
-   any transfer-encoding applied to the message-body. If the message is
-   received with a transfer-encoding, that encoding &MUST; be removed
-   prior to checking the Content-MD5 value against the received representation.
-</t>
-<t>
-   This has the result that the digest is computed on the octets of the
-   entity-body exactly as, and in the order that, they would be sent if
-   no transfer-encoding were being applied.
+   value as an end-to-end integrity check. Any recipient &MAY; check that
+   the digest value in this header field matches a corresponding digest
+   calculated on payload body as received.
+</t>
+<t>
+   The MD5 digest is computed based on the content of the payload body,
+   including any content-coding, but not including any transfer-coding
+   applied to the message-body because such transfer-codings might be
+   applied or removed anywhere along the request/response chain.
+   If the message is received with a transfer-coding, that encoding &MUST;
+   be decoded prior to checking the Content-MD5 value against the received
+   payload.
 </t>
 <t>
@@ -1541 +1538 @@
 </t>
 <t>
-   There are several consequences of this. The entity-body for composite
+   There are several consequences of this. The payload for composite
    types &MAY; contain many body-parts, each with its own MIME and HTTP
    headers (including Content-MD5, Content-Transfer-Encoding, and
@@ -1581 +1578 @@
 <t>
    The "Content-Type" entity-header field indicates the media type of the
-   entity-body. In the case of responses to the HEAD method, the media type is
+   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.
 </t>
@@ -1595 +1592 @@
 </artwork></figure>
 <t>
-   Further discussion of methods for identifying the media type of an
-   entity is provided in <xref target="type"/>.
+   Further discussion of methods for identifying the media type of a
+   representation is provided in <xref target="type"/>.
 </t>
 </section>
@@ -2534 +2531 @@
 </references>
 
-<section title="Differences Between HTTP Entities and RFC 2045 Entities" anchor="differences.between.http.entities.and.rfc.2045.entities">
+<section title="Differences between HTTP and MIME" anchor="differences.between.http.and.mime">
 <t>
    HTTP/1.1 uses many of the constructs defined for Internet Mail (<xref target="RFC5322"/>) and the Multipurpose Internet Mail Extensions (MIME <xref target="RFC2045"/>) to
-   allow entities to be transmitted in an open variety of
+   allow a message-body to be transmitted in an open variety of
    representations and with extensible mechanisms. However, RFC 2045
    discusses mail, and HTTP has a few features that are different from
-   those described in RFC 2045. These differences were carefully chosen
+   those described in MIME. These differences were carefully chosen
    to optimize performance over binary connections, to allow greater
    freedom in the use of new media types, to make date comparisons
@@ -2547 +2544 @@
 </t>
 <t>
-   This appendix describes specific areas where HTTP differs from RFC
-   2045. Proxies and gateways to strict MIME environments &SHOULD; be
+   This appendix describes specific areas where HTTP differs from MIME.
+   Proxies and gateways to strict MIME environments &SHOULD; be
    aware of these differences and provide the appropriate conversions
    where necessary. Proxies and gateways from MIME environments to HTTP
@@ -2582 +2579 @@
 <section title="Conversion to Canonical Form" anchor="conversion.to.canonical.form">
 <t>
-   <xref target="RFC2045"/> requires that an Internet mail entity be converted to
+   MIME requires that an Internet mail body-part be converted to
    canonical form prior to being transferred, as described in <xref target="RFC2049" x:fmt="of" x:sec="4"/>.
    <xref target="canonicalization.and.text.defaults"/> of this document describes the forms
@@ -2623 +2620 @@
 <section title="Introduction of Content-Encoding" anchor="introduction.of.content-encoding">
 <t>
-   RFC 2045 does not include any concept equivalent to HTTP/1.1's
+   MIME does not include any concept equivalent to HTTP/1.1's
    Content-Encoding header field. Since this acts as a modifier on the
    media type, proxies and gateways from HTTP to MIME-compliant
    protocols &MUST; either change the value of the Content-Type header
-   field or decode the entity-body before forwarding the message. (Some
+   field or decode the representation before forwarding the message. (Some
    experimental applications of Content-Type for Internet mail have used
    a media-type parameter of ";conversions=&lt;content-coding&gt;" to perform
    a function equivalent to Content-Encoding. However, this parameter is
-   not part of RFC 2045).
+   not part of the MIME standards).
 </t>
 </section>
@@ -2637 +2634 @@
 <section title="No Content-Transfer-Encoding" anchor="no.content-transfer-encoding">
 <t>
-   HTTP does not use the Content-Transfer-Encoding field of RFC
-   2045. Proxies and gateways from MIME-compliant protocols to HTTP &MUST;
+   HTTP does not use the Content-Transfer-Encoding field of MIME.
+   Proxies and gateways from MIME-compliant protocols to HTTP &MUST;
    remove any Content-Transfer-Encoding
    prior to delivering the response message to an HTTP client.
@@ -2846 +2843 @@
 <x:ref>disposition-type</x:ref> = "attachment" / disp-extension-token
 
-<x:ref>entity-body</x:ref> = *OCTET
 <x:ref>entity-header</x:ref> = Content-Encoding / Content-Language / Content-Length
  / Content-Location / Content-MD5 / Content-Range / Content-Type /
@@ -2886 +2882 @@
 ; MIME-Version defined but not used
 ; content-disposition defined but not used
-; entity-body defined but not used
 ; entity-header defined but not used
 </artwork></figure></section>

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

@@ -307 +307 @@
 </section>
 
-<section title="Entity Tags" anchor="entity.tags">
+<section title="Entity-Tags" anchor="entity.tags">
   <x:anchor-alias value="entity-tag"/>
   <x:anchor-alias value="opaque-tag"/>
   <x:anchor-alias value="weak"/>
 <t>
-   Entity tags are used for comparing two or more entities 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 from the same
+   requested 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
    are used and compared as cache validators is in <xref target="weak.and.strong.validators"/>. An
-   entity tag consists of an opaque quoted string, possibly prefixed by
+   entity-tag consists of an opaque quoted string, possibly prefixed by
    a weakness indicator.
 </t>
@@ -326 +326 @@
 </artwork></figure>
 <t>
-   A "strong entity tag" &MAY; be shared by two entities of a resource
+   A "strong entity-tag" &MAY; be shared by two representations of a resource
    only if they are equivalent by octet equality.
 </t>
 <t>
-   A "weak entity tag," indicated by the "W/" prefix, &MAY; be shared by
-   two entities of a resource only if the entities are equivalent and
+   A "weak entity-tag," indicated by the "W/" prefix, &MAY; be shared by
+   two representations of a resource only if the representations are equivalent and
    could be substituted for each other with no significant change in
-   semantics. A weak entity tag can only be used for weak comparison.
-</t>
-<t>
-   An entity tag &MUST; be unique across all versions of all entities
-   associated with a particular resource. A given entity tag value &MAY;
-   be used for entities obtained by requests on different URIs. The use
-   of the same entity tag value in conjunction with entities obtained by
+   semantics. A weak entity-tag can only be used for weak comparison.
+</t>
+<t>
+   An entity-tag &MUST; be unique across all versions of all representations
+   associated with a particular resource. A given entity-tag value &MAY;
+   be used for representations obtained by requests on different URIs. The use
+   of the same entity-tag value in conjunction with representations obtained by
    requests on different URIs does not imply the equivalence of those
-   entities.
-</t>
-
-<section title="Example: Entity Tags varying on Content-Negotiated Resources" anchor="example.entity.tag.vs.conneg">
+   representations.
+</t>
+
+<section title="Example: Entity-tags varying on Content-Negotiated Resources" anchor="example.entity.tag.vs.conneg">
 <t>
    Consider a resource that is subject to content negotiation (&content-negotiation;),
@@ -390 +390 @@
   <t>
     <x:h>Note:</x:h> Content codings are a property of the representation,
-    so therefore an entity tag of an encoded representation must be distinct
+    so therefore an entity-tag of an encoded representation must be distinct
     from an unencoded representation to prevent conflicts during cache updates
     and range requests.  In contrast, transfer codings (&transfer-codings;)
-    apply only during message transfer and do not require distinct entity tags.
+    apply only during message transfer and do not require distinct entity-tags.
   </t>
 </x:note>
@@ -469 +469 @@
 </t>
 <t>
-   Entity tags are normally "strong validators," but the protocol
-   provides a mechanism to tag an entity tag as "weak." One can think of
+   An entity-tag is normally a strong validator, but the protocol
+   provides a mechanism to tag an entity-tag as "weak." One can think of
    a strong validator as one that changes whenever the sequence of bits
    in a representation changes, while a weak value changes whenever the
@@ -481 +481 @@
       incremented in stable storage every time a representation is changed.
     </t><t>
-      An entity's modification time, if defined with only one-second
+      A representation's modification time, if defined with only one-second
       resolution, could be a weak validator, since it is possible that
       the representation might be modified twice during a single second.
@@ -524 +524 @@
 </t>
 <t>
-   The example below shows the results for a set of entity tag pairs,
+   The example below shows the results for a set of entity-tag pairs,
    and both the weak and strong comparison function results:
 </t>
@@ -554 +554 @@
 </texttable>
 <t>
-   An entity tag is strong unless it is explicitly tagged as weak.
-   <xref target="entity.tags"/> gives the syntax for entity tags.
+   An entity-tag is strong unless it is explicitly tagged as weak.
+   <xref target="entity.tags"/> gives the syntax for entity-tags.
 </t>
 <t>
@@ -621 +621 @@
 </section>
 
-<section title="Rules for When to Use Entity Tags and Last-Modified Dates" anchor="rules.for.when.to.use.entity.tags.and.last-modified.dates">
+<section title="Rules for When to Use Entity-tags and Last-Modified Dates" anchor="rules.for.when.to.use.entity.tags.and.last-modified.dates">
 <t>
    We adopt a set of rules and recommendations for origin servers,
@@ -630 +630 @@
    HTTP/1.1 origin servers:
   <list style="symbols">
-     <t>&SHOULD; send an entity tag validator unless it is not feasible to
+     <t>&SHOULD; send an entity-tag validator unless it is not feasible to
         generate one.</t>
 
-     <t>&MAY; send a weak entity tag instead of a strong entity tag, if
-        performance considerations support the use of weak entity tags,
-        or if it is unfeasible to send a strong entity tag.</t>
+     <t>&MAY; send a weak entity-tag instead of a strong entity-tag, if
+        performance considerations support the use of weak entity-tags,
+        or if it is unfeasible to send a strong entity-tag.</t>
 
      <t>&SHOULD; send a Last-Modified value if it is feasible to send one,
@@ -645 +645 @@
 <t>
    In other words, the preferred behavior for an HTTP/1.1 origin server
-   is to send both a strong entity tag and a Last-Modified value.
-</t>
-<t>
-   In order to be legal, a strong entity tag &MUST; change whenever the
-   associated entity changes in any way. A weak entity tag &SHOULD;
-   change whenever the associated entity changes in a semantically
+   is to send both a strong entity-tag and a Last-Modified value.
+</t>
+<t>
+   In order to be legal, a strong entity-tag &MUST; change whenever the
+   associated representation changes in any way. A weak entity-tag &SHOULD;
+   change whenever the associated representation changes in a semantically
    significant way.
 </t>
@@ -656 +656 @@
   <t>
     <x:h>Note:</x:h> In order to provide semantically transparent caching, an
-    origin server must avoid reusing a specific strong entity tag
-    value for two different entities, or reusing a specific weak
-    entity tag value for two semantically different entities. Cache
+    origin server must avoid reusing a specific strong entity-tag
+    value for two different representations, or reusing a specific weak
+    entity-tag value for two semantically different representations. Cache
     entries might persist for arbitrarily long periods, regardless of
     expiration times, so it might be inappropriate to expect that a
@@ -668 +668 @@
    HTTP/1.1 clients:
   <list style="symbols">
-     <t>&MUST; use that entity tag in any cache-conditional request (using
-        If-Match or If-None-Match) if an entity tag has been provided by the
+     <t>&MUST; use that entity-tag in any cache-conditional request (using
+        If-Match or If-None-Match) if an entity-tag has been provided by the
         origin server.</t>
 
@@ -682 +682 @@
 
      <t>&SHOULD; use both validators in cache-conditional requests if both an
-        entity tag and a Last-Modified value have been provided by the origin
+        entity-tag and a Last-Modified value have been provided by the origin
         server. This allows both HTTP/1.0 and HTTP/1.1 caches to respond
         appropriately.</t>
@@ -690 +690 @@
    An HTTP/1.1 origin server, upon receiving a conditional request that
    includes both a Last-Modified date (e.g., in an If-Modified-Since or
-   If-Unmodified-Since header field) and one or more entity tags (e.g.,
+   If-Unmodified-Since header field) and one or more entity-tags (e.g.,
    in an If-Match, If-None-Match, or If-Range header field) as cache
    validators, &MUST-NOT; return a response status of 304 (Not Modified)
@@ -698 +698 @@
 <t>
    An HTTP/1.1 caching proxy, upon receiving a conditional request that
-   includes both a Last-Modified date and one or more entity tags as
+   includes both a Last-Modified date and one or more entity-tags as
    cache validators, &MUST-NOT; return a locally cached response to the
    client unless that cached response is consistent with all of the
@@ -709 +709 @@
       conservative assumptions about the validators they receive.
   </t><t>
-      HTTP/1.0 clients and caches will ignore entity tags. Generally,
+      HTTP/1.0 clients and caches will ignore entity-tags. Generally,
       last-modified values received or used by these systems will
       support transparent and efficient caching, and so HTTP/1.1 origin
@@ -737 +737 @@
 <t>
    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
+   entity-tag (see <xref target="entity.tags"/>) for one representation of
+   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
@@ -756 +756 @@
 </artwork></figure>
 <t>
-   An entity tag provides an "opaque" cache validator that allows for
+   An entity-tag provides an "opaque" cache validator that allows for
    more reliable validation than modification dates in situations where
    it is inconvenient to store modification dates,
@@ -764 +764 @@
 </t>
 <t>
-   The principle behind entity tags is that only the service author
+   The principle behind entity-tags is that only the service author
    knows the semantics of a resource well enough to select an
    appropriate cache validation mechanism, and the specification of any
@@ -781 +781 @@
 <t>
    The "If-Match" request-header field is used to make a request method
-   conditional. A client that has one or more entities previously
-   obtained from the resource can verify that one of those entities is
-   current by including a list of their associated entity tags in the
+   conditional. A client that has one or more representations previously
+   obtained from the resource can verify that one of those representations is
+   current by including a list of their associated entity-tags in the
    If-Match header field.
 </t>
@@ -790 +790 @@
    transaction overhead. It is also used when updating resources, to prevent
    inadvertent modification of the wrong version of a resource. As a special
-   case, the value "*" matches any current entity of the resource.
+   case, the value "*" matches any current representation of the resource.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Match"/><iref primary="true" item="Grammar" subitem="If-Match-v"/>
@@ -797 +797 @@
 </artwork></figure>
 <t>
-   If any of the entity tags match the entity tag of the representation that
+   If any of the entity-tags match the entity-tag of the representation that
    would have been returned in the response to a similar GET request
    (without the If-Match header) on that resource, or if "*" is given
-   and any current entity exists for that resource, then the server &MAY;
+   and any current representation exists for that resource, then the server &MAY;
    perform the requested method as if the If-Match header field did not
    exist.
 </t>
 <t>
-   If none of the entity tags match, or if "*" is given and no current
+   If none of the entity-tags match, or if "*" is given and no current
    representation exists, the server &MUST-NOT; perform the requested method, and
    &MUST; return a 412 (Precondition Failed) response. This behavior is
@@ -827 +827 @@
    If-Match header field to signal that the request method &MUST-NOT; be
    applied if the representation corresponding to the If-Match value (a single
-   entity tag) is no longer a representation of that resource. This
+   entity-tag) is no longer a representation of that resource. This
    allows the user to indicate that they do not wish the request to be
    successful if the resource has been changed without their knowledge.
@@ -936 +936 @@
 <t>
    The "If-None-Match" request-header field is used to make a request method
-   conditional. A client that has one or more entities previously
-   obtained from the resource can verify that none of those entities is
-   current by including a list of their associated entity tags in the
+   conditional. A client that has one or more representations previously
+   obtained from the resource can verify that none of those representations is
+   current by including a list of their associated entity-tags in the
    If-None-Match header field.
 </t>
@@ -948 +948 @@
 </t>
 <t>
-   As a special case, the value "*" matches any current entity of the
+   As a special case, the value "*" matches any current representation of the
    resource.
 </t>
@@ -956 +956 @@
 </artwork></figure>
 <t>
-   If any of the entity tags match the entity tag of the representation that
+   If any of the entity-tags match the entity-tag of the representation that
    would have been returned in the response to a similar GET request
    (without the If-None-Match header) on that resource, or if "*" is
@@ -970 +970 @@
 </t>
 <t>
-   If none of the entity tags match, then the server &MAY; perform the
+   If none of the entity-tags match, then the server &MAY; perform the
    requested method as if the If-None-Match header field did not exist,
    but &MUST; also ignore any If-Modified-Since header field(s) in the
-   request. That is, if no entity tags match, then the server &MUST-NOT;
+   request. That is, if no entity-tags match, then the server &MUST-NOT;
    return a 304 (Not Modified) response.
 </t>
@@ -1075 +1075 @@
    of the origin server and the nature of the original resource. For
    files, it may be just the file system last-modified time. For
-   entities with dynamically included parts, it may be the most recent
+   representations with dynamically included parts, it may be the most recent
    of the set of last-modify times for its component parts. For database
    gateways, it may be the last-update time stamp of the record. For
@@ -1091 +1091 @@
    as close as possible to the time that it generates the Date value of
    its response. This allows a recipient to make an accurate assessment
-   of the entity's modification time, especially if the representation changes
+   of the representation's modification time, especially if the representation changes
    near the time that the response is generated.
 </t>
@@ -1490 +1490 @@
 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
 <t>
-  Allow weak entity tags in all requests except range requests (Sections
+  Allow weak entity-tags in all requests except range requests (Sections
   <xref target="weak.and.strong.validators" format="counter"/> and
   <xref target="header.if-none-match" format="counter"/>).

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

@@ -316 +316 @@
 <t>
    HTTP/1.1 allows a client to request that only part (a range of) the
-   response entity be included within the response. HTTP/1.1 uses range
+   representation be included within the response. HTTP/1.1 uses range
    units in the Range (<xref target="header.range"/>) and Content-Range (<xref target="header.content-range"/>)
-   header fields. An entity can be broken down into subranges according
+   header fields. A representation can be broken down into subranges according
    to various structural units.
 </t>
@@ -412 +412 @@
 <section title="Combining Ranges" anchor="combining.byte.ranges">
 <t>
-   A response might transfer only a subrange of an entity-body, either because
+   A response might transfer only a subrange of a representation, either because
    the request included one or more Range specifications, or because 
-   a connection was broken prematurely.
+   a connection closed prematurely.
    After several such transfers, a cache might have received several 
-   ranges of the same entity-body.
+   ranges of the same representation.
 </t>
 <t>
@@ -498 +498 @@
   <x:anchor-alias value="other-range-resp-spec"/>
 <t>
-   The "Content-Range" entity-header field is sent with a partial entity-body to
-   specify where in the full entity-body the partial body should be
+   The "Content-Range" entity-header field is sent with a partial representation to
+   specify where in the full representation the partial body should be
    applied. Range units are defined in <xref target="range.units"/>.
 </t>
@@ -522 +522 @@
 </artwork></figure>
 <t>
-   The header &SHOULD; indicate the total length of the full entity-body,
+   The header &SHOULD; indicate the total length of the full representation,
    unless this length is unknown or difficult to determine. The asterisk
    "*" character means that the instance-length is unknown at the time
@@ -617 +617 @@
    invalid, the server &SHOULD; treat the request as if the invalid Range
    header field did not exist. (Normally, this means return a 200
-   response containing the full entity).
+   response containing the full representation).
 </t>
 <t>
@@ -643 +643 @@
   <x:anchor-alias value="If-Range-v"/>
 <t>
-   If a client has a partial copy of an entity in its cache, and wishes
-   to have an up-to-date copy of the entire entity in its cache, it
+   If a client has a partial copy of a representation in its cache, and wishes
+   to have an up-to-date copy of the entire representation in its cache, it
    could use the Range request-header with a conditional GET (using
    either or both of If-Unmodified-Since and If-Match.) However, if the
@@ -662 +662 @@
 </artwork></figure>
 <t>
-   If the client has no entity tag for a representation, but does have a Last-Modified
+   If the client has no entity-tag for a representation, but does have a Last-Modified
    date, it &MAY; use that date in an If-Range header. (The
    server can distinguish between a valid HTTP-date and any form of
@@ -671 +671 @@
 </t>
 <t>
-   If the entity tag given in the If-Range header matches the current
+   If the entity-tag given in the If-Range header matches the current
    cache validator for the representation, then the server &SHOULD; provide the
    specified sub-range of the representation using a 206 (Partial Content)
@@ -744 +744 @@
    A suffix-byte-range-spec is used to specify the suffix of the
    representation body, of a length given by the suffix-length value. (That is,
-   this form specifies the last N bytes of an entity-body.) If the
+   this form specifies the last N bytes of a representation.) If the
    representation is shorter than the specified suffix-length, the entire
    representation is used.
@@ -751 +751 @@
    If a syntactically valid byte-range-set includes at least one byte-range-spec
    whose first-byte-pos is less than the current length of
-   the entity-body, or at least one suffix-byte-range-spec with a non-zero
+   the representation, or at least one suffix-byte-range-spec with a non-zero
    suffix-length, then the byte-range-set is satisfiable.
    Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
@@ -760 +760 @@
 </t>
 <t>
-   Examples of byte-ranges-specifier values (assuming an entity-body of
+   Examples of byte-ranges-specifier values (assuming a representation of
    length 10000):
   <list style="symbols">
@@ -820 +820 @@
    possible, since Range supports efficient recovery from partially
    failed transfers, and supports efficient partial retrieval of large
-   entities.
+   representations.
 </t>
 <t>
    If the server supports the Range header and the specified range or
-   ranges are appropriate for the entity:
+   ranges are appropriate for the representation:
   <list style="symbols">
      <t>The presence of a Range header in an unconditional GET modifies
@@ -845 +845 @@
 <t>
    If a proxy that supports ranges receives a Range request, forwards
-   the request to an inbound server, and receives an entire entity in
+   the request to an inbound server, and receives an entire representation in
    reply, it &SHOULD; only return the requested range to its client. It
    &SHOULD; store the entire received response in its cache if that is

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

@@ -271 +271 @@
   <x:dfn>explicit expiration time</x:dfn>
   <list>
-    <t>The time at which the origin server intends that an entity should no longer be
+    <t>The time at which the origin server intends that a representation should no longer be
       returned by a cache without further validation.</t>
   </list>
@@ -324 +324 @@
   <x:dfn>validator</x:dfn>
   <list>
-    <t>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find
+    <t>A protocol element (e.g., an entity-tag or a Last-Modified time) that is used to find
       out whether a stored response has an equivalent copy of a representation.</t>
   </list>
@@ -929 +929 @@
   The updated response can <cref anchor="TODO-is-req">requirement?</cref> be used to replace the  
   stored response in cache. In the case of a 206 response, the combined  
-  entity-body &MAY; be stored.
+  representation &MAY; be stored.
 </t>
 <t>
@@ -1107 +1107 @@
     <t>The no-transform request directive indicates that an intermediate cache or proxy
       &MUST-NOT; change the Content-Encoding, Content-Range or Content-Type request
-      headers, nor the request entity-body.</t>
+      headers, nor the request representation.</t>
   </list>
 </t>
@@ -1263 +1263 @@
     <t>The no-transform response directive indicates that an intermediate cache or proxy
       &MUST-NOT; change the Content-Encoding, Content-Range or Content-Type response
-      headers, nor the response entity-body.</t>
+      headers, nor the response representation.</t>
   </list>
 </t>
@@ -1585 +1585 @@
   214 Transformation applied
   <list>
-    <t>&MUST; be added by an intermediate cache or proxy if it applies any
-      transformation changing the content-coding (as specified in the Content-Encoding
-      header) or media-type (as specified in the Content-Type header) of the response, or
-      the entity-body of the response, unless this Warning code already appears in the
-      response.</t>
+    <t>&MUST; be added by an intermediate proxy if it applies any
+      transformation to the representation, such as changing the content-coding,
+      media-type, or modifying the representation data, unless this Warning code
+      already appears in the response.</t>
   </list>
 </t>
@@ -1607 +1606 @@
 <t>
   User agents often have history mechanisms, such as "Back" buttons and history lists, that
-  can be used to redisplay an entity retrieved earlier in a session.
+  can be used to redisplay a representation retrieved earlier in a session.
 </t>
 <t>

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

@@ -310 +310 @@
    prior response, and the user agent has already attempted
    authentication at least once, then the user &SHOULD; be presented the
-   entity that was given in the response, since that entity might
+   representation that was given in the response, since that representation might
    include relevant diagnostic information. HTTP access authentication
    is explained in "HTTP Authentication: Basic and Digest Access