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/p6-cache.xml

    r1449 r1452  
    1515  <!ENTITY ID-MONTH "October">
    1616  <!ENTITY ID-YEAR "2011">
     17  <!ENTITY architecture               "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1718  <!ENTITY notation                    "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1819  <!ENTITY acks                        "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    388389</section>
    389390
    390 <section anchor="intro.requirements" title="Requirements">
     391<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
    391392<t>
    392393   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     
    395396</t>
    396397<t>
    397    An implementation is not compliant if it fails to satisfy one or more of
    398    the "MUST" or "REQUIRED" level requirements for the protocols it
    399    implements. An implementation that satisfies all the "MUST" or "REQUIRED"
    400    level and all the "SHOULD" level requirements for its protocols is said to
    401    be "unconditionally compliant"; one that satisfies all the "MUST" level
    402    requirements but not all the "SHOULD" level requirements for its protocols
    403    is said to be "conditionally compliant".
     398   This document defines conformance criteria for several roles in HTTP
     399   communication, including Senders, Recipients, Clients, Servers, User-Agents,
     400   Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
     401   for definitions of these terms.
     402</t>
     403<t>
     404   An implementation is considered conformant if it complies with all of the
     405   requirements associated with its role(s). Note that SHOULD-level requirements
     406   are relevant here, unless one of the documented exceptions is applicable.
     407</t>
     408<t>
     409   This document also uses ABNF to define valid protocol elements
     410   (<xref target="notation"/>). In addition to the prose requirements placed
     411   upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
     412</t>
     413<t>
     414   Unless noted otherwise, Recipients &MAY; take steps to recover a usable
     415   protocol element from an invalid construct. However, HTTP does not define
     416   specific error handling mechanisms, except in cases where it has direct
     417   impact on security. This is because different uses of the protocol require
     418   different error handling strategies; for example, a Web browser may wish to
     419   transparently recover from a response where the Location header field
     420   doesn't parse according to the ABNF, whereby in a systems control protocol
     421   using HTTP, this type of error recovery could lead to dangerous consequences.
    404422</t>
    405423</section>
     
    28952913  <list style="symbols">
    28962914    <t>
     2915      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>:
     2916      "Document HTTP's error-handling philosophy"
     2917    </t>
     2918    <t>
    28972919      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/317"/>:
    28982920      "Cache-Control directive case sensitivity"
Note: See TracChangeset for help on using the changeset viewer.