Changeset 1875 for draft-ietf-httpbis/latest/p5-range.xml

Timestamp:

10/09/12 02:46:17 (9 years ago)

Author:

fielding@…

Message:

Be more consistent regarding targeting conformance requirements.
Only define conformance criteria once, but repeat required nits.

Remove antiquated requirement about media type parameters not being
recognized by 1993-era browsers.

Add reference to TLS in p1.

File:

• draft-ietf-httpbis/latest/p5-range.xml (modified) (3 diffs)

draft-ietf-httpbis/latest/p5-range.xml

@@ -17 +17 @@
   <!ENTITY Note "<x:h xmlns:x='http://purl.org/net/xml2rfc/ext'>Note:</x:h>">
   <!ENTITY architecture               "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY conformance                "<xref target='Part1' x:rel='#conformance' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY notation                   "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY abnf-extension             "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -153 +154 @@
 </t>
 
-<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
+<section title="Conformance and Error Handling" anchor="conformance">
 <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -160 +161 @@
 </t>
 <t>
-   This specification targets conformance criteria according to the role of
-   a participant in HTTP communication.  Hence, HTTP requirements are placed
-   on senders, recipients, clients, servers, user agents, intermediaries,
-   origin servers, proxies, gateways, or caches, depending on what behavior
-   is being constrained by the requirement. See &architecture; for definitions
-   of these terms.
-</t>
-<t>
-   The verb "generate" is used instead of "send" where a requirement
-   differentiates between creating a protocol element and merely forwarding a
-   received element downstream.
-</t>
-<t>
-   An implementation is considered conformant if it complies with all of the
-   requirements associated with the roles it partakes in HTTP. 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 do not match the grammar defined by the
-   ABNF rules for those protocol elements that are applicable to the sender's
-   role. If a received protocol element is processed, the recipient &MUST; be
-   able to parse any value that would match the ABNF rules for that protocol
-   element, excluding only those rules not applicable to the recipient's role.
-</t>
-<t>
-   Unless noted otherwise, a recipient &MAY; attempt to recover a usable
-   protocol element from an invalid construct.  HTTP does not define
-   specific error handling mechanisms except when they have a direct impact
-   on security, since different applications of the protocol require
-   different error handling strategies.  For example, a Web browser might
-   wish to transparently recover from a response where the
-   <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
-   whereas a systems control client might consider any form of error recovery
-   to be dangerous.
+   Conformance criteria and considerations regarding error handling
+   are defined in &conformance;.
 </t>
 </section>