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

Timestamp:

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

Author:

julian.reschke@…

Message:

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

File:

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

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

@@ -127 +127 @@
 </t>
 
-<section title="Terminology" anchor="terminology">
-<t>
-   This specification uses a number of terms to refer to the roles
-   played by participants in, and objects of, the HTTP communication.
-</t>
-<t>
-  <iref item="content negotiation"/>
-  <x:dfn>content negotiation</x:dfn>
-  <list>
-    <t>
-      The mechanism for selecting the appropriate representation when
-      servicing a request. The representation in any response
-      can be negotiated (including error responses).
-    </t>
-  </list>
-</t>
-<t>
-  <iref primary="true" item="selected representation"/>
-  <x:dfn>selected representation</x:dfn>
-  <list>
-    <t>
-      The current representation of the target resource that would have been
-      selected in a successful response if the same request had used the
-      method GET and excluded any conditional request header fields.
-    </t>
-  </list>
-</t>
-</section>
-
-<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
-<t>
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in <xref target="RFC2119"/>.
-</t>
-<t>
-   This document defines conformance criteria for several roles in HTTP
-   communication, including Senders, Recipients, Clients, Servers, User-Agents,
-   Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
-   for definitions of these terms.
-</t>
-<t>
-   An implementation is considered conformant if it complies with all of the
-   requirements associated with its role(s). Note that SHOULD-level requirements
-   are relevant here, unless one of the documented exceptions is applicable.
-</t>
-<t>
-   This document also uses ABNF to define valid protocol elements
-   (<xref target="notation"/>). In addition to the prose requirements placed
-   upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
-</t>
-<t>
-   Unless noted otherwise, Recipients &MAY; take steps to recover a usable
-   protocol element from an invalid construct. However, HTTP does not define
-   specific error handling mechanisms, except in cases where it has direct
-   impact on security. This is because different uses of the protocol require
-   different error handling strategies; for example, a Web browser may wish to
-   transparently recover from a response where the Location header field
-   doesn't parse according to the ABNF, whereby in a systems control protocol
-   using HTTP, this type of error recovery could lead to dangerous consequences.
-</t>
-</section>
-
 <section title="Syntax Notation" anchor="notation">
   <x:anchor-alias value="ALPHA"/>
@@ -1677 +1614 @@
 </reference>
 
-<reference anchor="RFC2119">
-  <front>
-    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
-    <author initials="S." surname="Bradner" fullname="Scott Bradner">
-      <organization>Harvard University</organization>
-      <address><email>sob@harvard.edu</email></address>
-    </author>
-    <date month="March" year="1997"/>
-  </front>
-  <seriesInfo name="BCP" value="14"/>
-  <seriesInfo name="RFC" value="2119"/>
-</reference>
-
 <reference anchor='RFC4647'>
   <front>