Ignore:
Timestamp:
05/01/13 13:09:32 (8 years ago)
Author:
fielding@…
Message:

(editorial) more consistency regarding representation

File:
1 edited

Legend:

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

    r2089 r2090  
    207207   HTTP provides a uniform interface for interacting with a resource
    208208   (<xref target="resources"/>), regardless of its type, nature, or
    209    implementation, and for transferring content  in message payloads in the
    210    form of a representation (<xref target="representations"/>).
     209   implementation, via the manipulation and transfer of representations
     210   (<xref target="representations"/>).
    211211</t>
    212212<t>
     
    486486   assume a media type of
    487487   "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
    488    or examine the representation data to determine its type.
     488   or examine the data to determine its type.
    489489</t>
    490490<t>
     
    774774   response message and its field-value refers to a URI that differs from the
    775775   effective request URI, then the origin server claims that the field-value
    776    is an identifier for the payload's representation. Such a claim can only be
    777    trusted if both identifiers share the same resource owner, which cannot be
    778    programmatically determined via HTTP.
     776   is an identifier for the representation enclosed as the payload. Such a
     777   claim can only be trusted if both identifiers share the same resource
     778   owner, which cannot be programmatically determined via HTTP.
    779779   <list style="symbols">
    780780    <t>For a response to a GET or HEAD request, this is an indication that the
     
    813813<t>
    814814   For example, if a client makes a PUT request on a negotiated resource and
    815    the origin server accepts that PUT (without redirection), then the new set
    816    of values for that resource is expected to be consistent with the one
     815   the origin server accepts that PUT (without redirection), then the new
     816   state of that resource is expected to be consistent with the one
    817817   representation supplied in that PUT; the Content-Location cannot be used as
    818818   a form of reverse content selection identifier to update only one of the
     
    868868<t>
    869869   Likewise, the payload of a <x:ref>200 (OK)</x:ref> response to GET
    870    (<xref target="GET"/>) contains a representation of the <x:ref>target resource</x:ref>,
    871    as observed at the time of the message origination date
    872    (<xref target="header.date"/>), whereas the same status code in a response
    873    to POST might contain either a representation of the processing result or
    874    a current representation of the target resource after applying the
    875    processing. Response messages with an error status code usually contain
    876    a representation that describes the error and what next steps are suggested
    877    for resolving it.
     870   (<xref target="GET"/>) ought to contain a representation of the
     871   <x:ref>target resource</x:ref>, as observed at the time of the message
     872   origination date (<xref target="header.date"/>), whereas the same status
     873   code in a response to POST might contain either a representation of the
     874   processing result or a current representation of the target resource after
     875   applying the processing. Response messages with an error status code
     876   usually contain a representation of the error condition, such that it
     877   describes the error state and what next steps are suggested for resolving
     878   it.
    878879</t>
    879880<t>
     
    896897  <x:anchor-alias value="content negotiation"/>
    897898<t>
    898    When responses convey a representation, whether indicating a success or
     899   When responses convey payload information, whether indicating a success or
    899900   an error, the origin server often has different ways of representing that
    900901   information; for example, in different formats, languages, or encodings.
     
    12881289   in the HTTP header fields in response to a HEAD request &SHOULD; be identical
    12891290   to the information sent in response to a GET request. This method can
    1290    be used for obtaining metadata about the representation implied by the
    1291    request without transferring the representation data. This method is
     1291   be used for obtaining metadata about the selected representation
     1292   without transferring the representation data. This method is
    12921293   often used for testing hypertext links for validity, accessibility,
    12931294   and recent modification.
Note: See TracChangeset for help on using the changeset viewer.