30/03/12 14:44:42 (9 years ago)

Step 3 of p2/p3-merge (see #351)

1 edited


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

    r1640 r1641  
    129 <section title="Terminology" anchor="terminology">
    130 <t>
    131    This specification uses a number of terms to refer to the roles
    132    played by participants in, and objects of, the HTTP communication.
    133 </t>
    134 <t>
    135   <iref item="content negotiation"/>
    136   <x:dfn>content negotiation</x:dfn>
    137   <list>
    138     <t>
    139       The mechanism for selecting the appropriate representation when
    140       servicing a request. The representation in any response
    141       can be negotiated (including error responses).
    142     </t>
    143   </list>
    144 </t>
    145 <t>
    146   <iref primary="true" item="selected representation"/>
    147   <x:dfn>selected representation</x:dfn>
    148   <list>
    149     <t>
    150       The current representation of the target resource that would have been
    151       selected in a successful response if the same request had used the
    152       method GET and excluded any conditional request header fields.
    153     </t>
    154   </list>
    155 </t>
    156 </section>
    158 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
    159 <t>
    160    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    161    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    162    document are to be interpreted as described in <xref target="RFC2119"/>.
    163 </t>
    164 <t>
    165    This document defines conformance criteria for several roles in HTTP
    166    communication, including Senders, Recipients, Clients, Servers, User-Agents,
    167    Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
    168    for definitions of these terms.
    169 </t>
    170 <t>
    171    An implementation is considered conformant if it complies with all of the
    172    requirements associated with its role(s). Note that SHOULD-level requirements
    173    are relevant here, unless one of the documented exceptions is applicable.
    174 </t>
    175 <t>
    176    This document also uses ABNF to define valid protocol elements
    177    (<xref target="notation"/>). In addition to the prose requirements placed
    178    upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
    179 </t>
    180 <t>
    181    Unless noted otherwise, Recipients &MAY; take steps to recover a usable
    182    protocol element from an invalid construct. However, HTTP does not define
    183    specific error handling mechanisms, except in cases where it has direct
    184    impact on security. This is because different uses of the protocol require
    185    different error handling strategies; for example, a Web browser may wish to
    186    transparently recover from a response where the Location header field
    187    doesn't parse according to the ABNF, whereby in a systems control protocol
    188    using HTTP, this type of error recovery could lead to dangerous consequences.
    189 </t>
    190 </section>
    192129<section title="Syntax Notation" anchor="notation">
    193130  <x:anchor-alias value="ALPHA"/>
    1679 <reference anchor="RFC2119">
    1680   <front>
    1681     <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    1682     <author initials="S." surname="Bradner" fullname="Scott Bradner">
    1683       <organization>Harvard University</organization>
    1684       <address><email>sob@harvard.edu</email></address>
    1685     </author>
    1686     <date month="March" year="1997"/>
    1687   </front>
    1688   <seriesInfo name="BCP" value="14"/>
    1689   <seriesInfo name="RFC" value="2119"/>
    1690 </reference>
    16921616<reference anchor='RFC4647'>
    16931617  <front>
Note: See TracChangeset for help on using the changeset viewer.