Changeset 1452 for draft-ietf-httpbis/latest/p7-auth.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/p7-auth.xml (modified) (4 diffs)

draft-ietf-httpbis/latest/p7-auth.xml

@@ -16 +16 @@
   <!ENTITY ID-YEAR "2011">
   <!ENTITY mdash "&#8212;">
+  <!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 notation-abnf                "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -230 +231 @@
 </t>
 
-<section title="Requirements" anchor="intro.requirements">
+<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
 <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -237 +238 @@
 </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>
@@ -1389 +1407 @@
 <section title="Since draft-ietf-httpbis-p7-auth-16" anchor="changes.since.16">
 <t>
-  None yet.
+  Closed issues:
+  <list style="symbols"> 
+    <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>:
+      "Document HTTP's error-handling philosophy"
+    </t>
+  </list>
 </t>
 </section>