Ignore:
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:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p7-auth.xml

    r1443 r1452  
    1616  <!ENTITY ID-YEAR "2011">
    1717  <!ENTITY mdash "&#8212;">
     18  <!ENTITY architecture                 "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1819  <!ENTITY notation                     "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1920  <!ENTITY notation-abnf                "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    230231</t>
    231232
    232 <section title="Requirements" anchor="intro.requirements">
     233<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
    233234<t>
    234235   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     
    237238</t>
    238239<t>
    239    An implementation is not compliant if it fails to satisfy one or more
    240    of the "MUST" or "REQUIRED" level requirements for the protocols it
    241    implements. An implementation that satisfies all the "MUST" or "REQUIRED"
    242    level and all the "SHOULD" level requirements for its protocols is said
    243    to be "unconditionally compliant"; one that satisfies all the "MUST"
    244    level requirements but not all the "SHOULD" level requirements for its
    245    protocols is said to be "conditionally compliant".
     240   This document defines conformance criteria for several roles in HTTP
     241   communication, including Senders, Recipients, Clients, Servers, User-Agents,
     242   Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
     243   for definitions of these terms.
     244</t>
     245<t>
     246   An implementation is considered conformant if it complies with all of the
     247   requirements associated with its role(s). Note that SHOULD-level requirements
     248   are relevant here, unless one of the documented exceptions is applicable.
     249</t>
     250<t>
     251   This document also uses ABNF to define valid protocol elements
     252   (<xref target="notation"/>). In addition to the prose requirements placed
     253   upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
     254</t>
     255<t>
     256   Unless noted otherwise, Recipients &MAY; take steps to recover a usable
     257   protocol element from an invalid construct. However, HTTP does not define
     258   specific error handling mechanisms, except in cases where it has direct
     259   impact on security. This is because different uses of the protocol require
     260   different error handling strategies; for example, a Web browser may wish to
     261   transparently recover from a response where the Location header field
     262   doesn't parse according to the ABNF, whereby in a systems control protocol
     263   using HTTP, this type of error recovery could lead to dangerous consequences.
    246264</t>
    247265</section>
     
    13891407<section title="Since draft-ietf-httpbis-p7-auth-16" anchor="changes.since.16">
    13901408<t>
    1391   None yet.
     1409  Closed issues:
     1410  <list style="symbols">
     1411    <t>
     1412      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>:
     1413      "Document HTTP's error-handling philosophy"
     1414    </t>
     1415  </list>
    13921416</t>
    13931417</section>
Note: See TracChangeset for help on using the changeset viewer.