Changeset 1452 for draft-ietf-httpbis/latest/p6-cache.xml

Timestamp:

Oct 23, 2011, 1:20:31 PM (8 years ago)

Author:

julian.reschke@…

Message:

Rephrase description of conformance; explain how the spec handles error handling (see #186)

File:

• draft-ietf-httpbis/latest/p6-cache.xml (modified) (4 diffs)

draft-ietf-httpbis/latest/p6-cache.xml

@@ -15 +15 @@
   <!ENTITY ID-MONTH "October">
   <!ENTITY ID-YEAR "2011">
+  <!ENTITY architecture               "<xref target='Part1' x:rel='#architecture' 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 acks                        "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -388 +389 @@
 </section>
 
-<section anchor="intro.requirements" title="Requirements">
+<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
 <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -395 +396 @@
 </t>
 <t>
-   An implementation is not compliant if it fails to satisfy one or more of
-   the "MUST" or "REQUIRED" level requirements for the protocols it
-   implements. An implementation that satisfies all the "MUST" or "REQUIRED"
-   level and all the "SHOULD" level requirements for its protocols is said to
-   be "unconditionally compliant"; one that satisfies all the "MUST" level
-   requirements but not all the "SHOULD" level requirements for its protocols
-   is said to be "conditionally compliant".
+   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>
@@ -2895 +2913 @@
   <list style="symbols">
     <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>:
+      "Document HTTP's error-handling philosophy"
+    </t>
+    <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/317"/>:
       "Cache-Control directive case sensitivity"