Ignore:
Timestamp:
22/09/12 06:35:14 (8 years ago)
Author:
fielding@…
Message:

(editorial) be more consistent when referring to a "body", preferring the
defined terms for message (body), payload (body), and representation (data).

File:
1 edited

Legend:

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

    r1909 r1910  
    302302   that can be readily communicated via the protocol, consisting of a set of
    303303   metadata (representation header fields) and a potentially unbounded stream
    304    of data (representation body).
     304   of octets (representation data).
    305305</t>
    306306
     
    371371<t>
    372372   The content-coding is a characteristic of the representation.
    373    Typically, the representation body is stored with this
     373   Typically, the representation data is stored with this
    374374   encoding and is only decoded before rendering or analogous usage.
    375375   However, a transforming proxy &MAY; modify the content-coding if the
     
    422422   Content-Language is to allow a user to identify and differentiate
    423423   representations according to the user's own preferred language. Thus, if the
    424    body content is intended only for a Danish-literate audience, the
     424   content is intended only for a Danish-literate audience, the
    425425   appropriate field is
    426426</t>
     
    569569  <x:anchor-alias value="representation-data"/>
    570570<t>
    571    The representation body associated with an HTTP message is
     571   The representation data associated with an HTTP message is
    572572   either provided as the payload body of the message or
    573573   referred to by the message semantics and the effective request
     
    599599   In practice, resource owners do not always properly configure their origin
    600600   server to provide the correct Content-Type for a given representation,
    601    with the result that some clients will examine a response body's content
     601   with the result that some clients will examine a payload's content
    602602   and override the specified type.
    603603   Clients that do so risk drawing incorrect conclusions, which might expose
     
    623623   message "<x:dfn>payload</x:dfn>".  In some cases, a payload might only
    624624   contain the associated representation's header fields (e.g., responses to
    625    HEAD) or only some part(s) of the representation body
     625   HEAD) or only some part(s) of the representation data
    626626   (e.g., the <x:ref>206 (Partial Content)</x:ref> status code).
    627627</t>
     
    646646   to POST might contain either a representation of the processing result or
    647647   a current representation of the target resource after applying the
    648    processing. Some responses only contain the representation's header fields
    649    as the payload. Response messages with an error status code usually contain
     648   processing. Response messages with an error status code usually contain
    650649   a representation that describes the error and what next steps are suggested
    651650   for resolving it.
     
    11121111</t>
    11131112<t>
    1114    Bodies on GET requests have no defined semantics. Note that sending a body
    1115    on a GET request might cause some existing implementations to reject the
    1116    request.
     1113   A payload within a GET request message has no defined semantics;
     1114   sending a payload body on a GET request might cause some existing
     1115   implementations to reject the request.
    11171116</t>
    11181117<t>
     
    11371136   to the information sent in response to a GET request. This method can
    11381137   be used for obtaining metadata about the representation implied by the
    1139    request without transferring the representation body. This method is
     1138   request without transferring the representation data. This method is
    11401139   often used for testing hypertext links for validity, accessibility,
    11411140   and recent modification.
     
    11471146</t>
    11481147<t>
    1149    Bodies on HEAD requests have no defined semantics. Note that sending a body
    1150    on a HEAD request might cause some existing implementations to reject the
    1151    request.
     1148   A payload within a HEAD request message has no defined semantics;
     1149   sending a payload body on a HEAD request might cause some existing
     1150   implementations to reject the request.
    11521151</t>
    11531152</section>
     
    13581357</t>
    13591358<t>
    1360    Bodies on DELETE requests have no defined semantics. Note that sending a body
    1361    on a DELETE request might cause some existing implementations to reject the
    1362    request.
     1359   A payload within a DELETE request message has no defined semantics;
     1360   sending a payload body on a DELETE request might cause some existing
     1361   implementations to reject the request.
    13631362</t>
    13641363<t>
     
    14171416</artwork></figure>
    14181417<t>
    1419    A message body on a CONNECT request has no defined semantics. Sending a
    1420    body on a CONNECT request might cause existing implementations to reject
    1421    the request.
     1418   A payload within a CONNECT request message has no defined semantics;
     1419   sending a payload body on a CONNECT request might cause some existing
     1420   implementations to reject the request.
    14221421</t>
    14231422<t>
     
    14691468</t>
    14701469<t>
    1471    If the OPTIONS request includes a message body (as indicated by the
    1472    presence of <x:ref>Content-Length</x:ref> or <x:ref>Transfer-Encoding</x:ref>),
     1470   If the OPTIONS request includes a payload,
    14731471   then the media type &MUST; be indicated by a <x:ref>Content-Type</x:ref>
    14741472   field. Although this specification does not define any use for such a body,
     
    14951493   indicate optional features implemented by the server and applicable to that
    14961494   resource (e.g., <x:ref>Allow</x:ref>), possibly including extensions not
    1497    defined by this specification. The response body, if any, &SHOULD; also
     1495   defined by this specification. The response payload, if any, &SHOULD; also
    14981496   include information about the communication options. The format for such a
    1499    body is not defined by this specification, but might be defined by
     1497   payload is not defined by this specification, but might be defined by
    15001498   future extensions to HTTP. Content negotiation &MAY; be used to select
    1501    the appropriate response format. If no response body is included, the
     1499   the appropriate representation. If no payload body is included, the
    15021500   response &MUST; include a <x:ref>Content-Length</x:ref> field with a
    15031501   field-value of "0".
     
    16601658   The purpose of the <x:ref>100 (Continue)</x:ref> status code
    16611659   (<xref target='status.100'/>)
    1662    is to allow a client that is sending a request message with a request body
     1660   is to allow a client that is sending a request message with a payload
    16631661   to determine if the origin server is willing to accept the request
    1664    (based on the request header fields) before the client sends the request
     1662   (based on the request header fields) before the client sends the payload
    16651663   body. In some cases, it might either be inappropriate or highly
    1666    inefficient for the client to send the body if the server will reject
    1667    the message without looking at the body.
     1664   inefficient for the client to send the payload body if the server will
     1665   reject the message without looking at the body.
    16681666</t>
    16691667<t>
     
    16721670    <t>
    16731671        If a client will wait for a <x:ref>100 (Continue)</x:ref> response before
    1674         sending the request body, it &MUST; send an <x:ref>Expect</x:ref> header
     1672        sending the payload body, it &MUST; send an <x:ref>Expect</x:ref> header
    16751673        field with the "100-continue" expectation.
    16761674    </t>
    16771675    <t>
    16781676        A client &MUST-NOT; send an <x:ref>Expect</x:ref> header field with
    1679         the "100-continue" expectation if it does not intend to send a request
     1677        the "100-continue" expectation if it does not intend to send a payload
    16801678        body.
    16811679    </t>
     
    16891687   header field to an origin server (possibly via a proxy) from which it
    16901688   has never seen a <x:ref>100 (Continue)</x:ref> status code, the client &SHOULD-NOT; 
    1691    wait for an indefinite period before sending the request body.
     1689   wait for an indefinite period before sending the payload body.
    16921690</t>
    16931691<t>
     
    16981696        either respond with <x:ref>100 (Continue)</x:ref> status code and continue to read
    16991697        from the input stream, or respond with a final status code. The
    1700         origin server &MUST-NOT; wait for the request body before sending
     1698        origin server &MUST-NOT; wait for the payload body before sending
    17011699        the <x:ref>100 (Continue)</x:ref> response. If it responds with a final status
    17021700        code, it &MAY; close the transport connection or it &MAY; continue
     
    17191717    </t>
    17201718    <t> An origin server &MAY; omit a <x:ref>100 (Continue)</x:ref> response if it has
    1721         already received some or all of the request body for the
     1719        already received some or all of the payload body for the
    17221720        corresponding request.
    17231721    </t>
    17241722    <t> An origin server that sends a <x:ref>100 (Continue)</x:ref> response &MUST;
    1725         ultimately send a final status code, once the request body is
     1723        ultimately send a final status code, once the payload body is
    17261724        received and processed, unless it terminates the transport
    17271725        connection prematurely.
     
    17291727    <t> If an origin server receives a request that does not include an
    17301728        <x:ref>Expect</x:ref> header field with the "100-continue" expectation,
    1731         the request includes a request body, and the server responds
    1732         with a final status code before reading the entire request body
     1729        the request includes a payload body, and the server responds
     1730        with a final status code before reading the entire payload body
    17331731        from the transport connection, then the server &SHOULD-NOT;  close
    17341732        the transport connection until it has read the entire request,
     
    30213019   state of the resource. This code is only allowed in situations where
    30223020   it is expected that the user might be able to resolve the conflict
    3023    and resubmit the request. The response body &SHOULD; include enough
     3021   and resubmit the request. The payload &SHOULD; include enough
    30243022   information for the user to recognize the source of the conflict.
    30253023   Ideally, the response representation would include enough information for the
     
    40264024<section title="Considerations for New Methods" anchor="considerations.for.new.methods">
    40274025<t>
    4028    Standardized HTTP methods are generic; that is, they are potentially
     4026   Standardized methods are generic; that is, they are potentially
    40294027   applicable to any resource, not just one particular media type, kind of
    4030    resource, or application. As such, it is preferred that new HTTP methods
     4028   resource, or application. As such, it is preferred that new methods
    40314029   be registered in a document that isn't specific to a single application or
    40324030   data format, since orthogonal technologies deserve orthogonal specification.
    40334031</t>
    40344032<t>
    4035    Since HTTP message parsing (&message-body;) is independent of method
    4036    semantics (aside from responses to HEAD), definitions of new HTTP methods
     4033   Since message parsing (&message-body;) needs to be independent of method
     4034   semantics (aside from responses to HEAD), definitions of new methods
    40374035   cannot change the parsing algorithm or prohibit the presence of a message
    40384036   body on either the request or the response message.
    4039    Definitions of new methods can specify that only zero-length bodies are
    4040    allowed, which would imply that each such messages would be required to
    4041    contain a Content-Length header field with a value of "0".
     4037   Definitions of new methods can specify that only a zero-length message body
     4038   is allowed by requiring a Content-Length header field with a value of "0".
    40424039</t>
    40434040<t>
     
    40454042   target="safe.methods"/>), idempotent (<xref target="idempotent.methods"/>),
    40464043   cacheable (<xref target="cacheable.methods"/>), and what
    4047    semantics are to be associated with the request body if any is present
     4044   semantics are to be associated with the payload body if any is present
    40484045   in the request.  If a method is cacheable, the method definition ought
    40494046   to describe how, and under what conditions, a cache can store a response
     
    41484145   New status codes are required to fall under one of the categories
    41494146   defined in <xref target="status.codes"/>. To allow existing parsers to
    4150    properly handle them, new status codes cannot disallow a response body,
    4151    although they can mandate a zero-length response body.
     4147   properly handle them, new status codes cannot disallow a payload,
     4148   although they can mandate a zero-length payload body.
    41524149</t>
    41534150<t>
     
    62666263    <t>
    62676264      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/98"/>:
    6268       "OPTIONS request bodies"
     6265      "OPTIONS payload bodies"
    62696266    </t>
    62706267    <t>
Note: See TracChangeset for help on using the changeset viewer.