Ignore:
Timestamp:
21/02/12 02:12:49 (8 years ago)
Author:
fielding@…
Message:

For consistency and readability, do not hyphenate "message body"
unless we are referring to the message-body ABNF rule.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p3-payload.xml

    r1523 r1544  
    558558<t>
    559559   MIME provides for a number of "multipart" types &mdash; encapsulations of
    560    one or more representations within a single message-body. All multipart
     560   one or more representations within a single message body. All multipart
    561561   types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>,
    562562   and &MUST; include a boundary parameter as part of the media type
     
    565565</t>
    566566<t>
    567    In general, HTTP treats a multipart message-body no differently than
     567   In general, HTTP treats a multipart message body no differently than
    568568   any other media type: strictly as payload.  HTTP does not use the
    569    multipart boundary as an indicator of message-body length.
     569   multipart boundary as an indicator of message body length.
    570570   <!-- jre: re-insert removed text pointing to caching? -->
    571571   In all other respects, an HTTP user agent &SHOULD; follow the same or similar
    572572   behavior as a MIME user agent would upon receipt of a multipart type.
    573    The MIME header fields within each body-part of a multipart message-body
     573   The MIME header fields within each body-part of a multipart message body
    574574   do not have any significance to HTTP beyond that defined by
    575575   their MIME semantics.
     
    627627   the request method or response status code.  The payload consists of
    628628   metadata, in the form of header fields, and data, in the form of the
    629    sequence of octets in the message-body after any transfer-coding has
     629   sequence of octets in the message body after any transfer-coding has
    630630   been decoded.
    631631</t>
     
    657657  <x:anchor-alias value="payload-body"/>
    658658<t>
    659    A payload body is only present in a message when a message-body is
     659   A payload body is only present in a message when a message body is
    660660   present, as described in &message-body;. The payload body is obtained
    661    from the message-body by decoding any Transfer-Encoding that might
     661   from the message body by decoding any Transfer-Encoding that might
    662662   have been applied to ensure safe and proper transfer of the message.
    663663</t>
     
    694694<t>
    695695   Representation header fields define metadata about the representation data
    696    enclosed in the message-body or, if no message-body is present, about
     696   enclosed in the message body or, if no message body is present, about
    697697   the representation that would have been transferred in a 200 response
    698698   to a simultaneous GET request with the same effective request URI.
     
    23632363<t>
    23642364   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
    2365    allow a message-body to be transmitted in an open variety of
     2365   allow a message body to be transmitted in an open variety of
    23662366   representations and with extensible mechanisms. However, RFC 2045
    23672367   discusses mail, and HTTP has a few features that are different from
Note: See TracChangeset for help on using the changeset viewer.