Changeset 866 for draft-ietf-httpbis/latest/p3-payload.xml

Timestamp:

Jul 22, 2010, 2:06:27 AM (9 years ago)

Author:

fielding@…

Message:

Addresses #109: Clarify entity / representation / variant terminology

Replaced entity with representation.

File:

• draft-ietf-httpbis/latest/p3-payload.xml (modified) (12 diffs)

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

@@ -465 +465 @@
 <t>
    Content coding values indicate an encoding transformation that has
-   been or can be applied to an entity. Content codings are primarily
-   used to allow a document to be compressed or otherwise usefully
+   been or can be applied to a representation. Content codings are primarily
+   used to allow a representation to be compressed or otherwise usefully
    transformed without losing the identity of its underlying media type
-   and without loss of information. Frequently, the entity is stored in
+   and without loss of information. Frequently, the representation is stored in
    coded form, transmitted directly, and only decoded by the recipient.
 </t>
@@ -707 +707 @@
 <section title="Entity" anchor="entity">
 <t>
-   Request and Response messages &MAY; transfer an entity if not otherwise
-   restricted by the request method or response status code. An entity
-   consists of entity-header fields and an entity-body, although some
+   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 entity.
+   or the server, depending on who sends and who receives the message.
 </t>
 
@@ -966 +966 @@
 <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 entity.
+   client or the server, depending on who sends and who receives the message.
 </t>
 
@@ -1049 +1049 @@
    Verbally, this would be interpreted as "text/html and text/x-c are
    the preferred media types, but if they do not exist, then send the
-   text/x-dvi entity, and if that does not exist, send the text/plain
-   entity."
+   text/x-dvi representation, and if that does not exist, send the text/plain
+   representation."
 </t>
 <t>
@@ -1311 +1311 @@
 <t>
    The "Content-Encoding" entity-header field indicates what content-codings 
-   have been applied to the entity-body, and thus what decoding mechanisms
+   have been applied to the representation, and thus what decoding mechanisms
    must be applied in order to obtain the media-type referenced by the 
    Content-Type header field. Content-Encoding is primarily used to allow a
-   document to be compressed without losing the identity of its underlying
+   representation to be compressed without losing the identity of its underlying
    media type.
 </t>
@@ -1328 +1328 @@
 </artwork></figure>
 <t>
-   The content-coding is a characteristic of the entity identified by
-   the Effective Request URI (&effective-request-uri;). Typically, the entity-body is stored with this
+   The content-coding is a characteristic of the representation.
+   Typically, the representation body is stored with this
    encoding and is only decoded before rendering or analogous usage.
    However, a non-transparent proxy &MAY; modify the content-coding if the
@@ -1336 +1336 @@
 </t>
 <t>
-   If the content-coding of an entity is not "identity", then the
-   response &MUST; include a Content-Encoding entity-header (<xref target="header.content-encoding"/>)
+   If the content-coding of a representation is not "identity", then the
+   representation metadata &MUST; include a Content-Encoding header
+   field (<xref target="header.content-encoding"/>)
    that lists the non-identity content-coding(s) used.
 </t>
@@ -1346 +1347 @@
 </t>
 <t>
-   If multiple encodings have been applied to an entity, the content
+   If multiple encodings have been applied to a representation, the content
    codings &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>
 </section>
@@ -1360 +1361 @@
 <t>
    The "Content-Language" entity-header field describes the natural
-   language(s) of the intended audience for the entity. Note that this might
+   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.
 </t>
@@ -1370 +1371 @@
    Language tags are defined in <xref target="language.tags"/>. The primary purpose of
    Content-Language is to allow a user to identify and differentiate
-   entities according to the user's own preferred language. Thus, if the
+   representations according to the user's own preferred language. Thus, if the
    body content is intended only for a Danish-literate audience, the
    appropriate field is
@@ -1393 +1394 @@
 </artwork></figure>
 <t>
-   However, just because multiple languages are present within an entity
+   However, just because multiple languages are present within a representation
    does not mean that it is intended for multiple linguistic audiences.
    An example would be a beginner's language primer, such as "A First
@@ -1526 +1527 @@
    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 entity.
+   prior to checking the Content-MD5 value against the received representation.
 </t>
 <t>