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

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

1 edited


  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1451 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 acks                       "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2526  <!ENTITY auth                       "<xref target='Part7' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2627  <!ENTITY content-negotiation        "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    27   <!ENTITY agent-driven-negotiation    "<xref target='Part3' x:rel='#agent-driven.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     28  <!ENTITY agent-driven-negotiation   "<xref target='Part3' x:rel='#agent-driven.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2829  <!ENTITY notation-abnf              "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2930  <!ENTITY basic-rules                "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    303 <section title="Requirements" anchor="intro.requirements">
     304<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
    305306   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    310    An implementation is not compliant if it fails to satisfy one or more
    311    of the "MUST" or "REQUIRED" level requirements for the protocols it
    312    implements. An implementation that satisfies all the "MUST" or "REQUIRED"
    313    level and all the "SHOULD" level requirements for its protocols is said
    314    to be "unconditionally compliant"; one that satisfies all the "MUST"
    315    level requirements but not all the "SHOULD" level requirements for its
    316    protocols is said to be "conditionally compliant".
     311   This document defines conformance criteria for several roles in HTTP
     312   communication, including Senders, Recipients, Clients, Servers, User-Agents,
     313   Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
     314   for definitions of these terms.
     317   An implementation is considered conformant if it complies with all of the
     318   requirements associated with its role(s). Note that SHOULD-level requirements
     319   are relevant here, unless one of the documented exceptions is applicable.
     322   This document also uses ABNF to define valid protocol elements
     323   (<xref target="notation"/>). In addition to the prose requirements placed
     324   upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
     327   Unless noted otherwise, Recipients &MAY; take steps to recover a usable
     328   protocol element from an invalid construct. However, HTTP does not define
     329   specific error handling mechanisms, except in cases where it has direct
     330   impact on security. This is because different uses of the protocol require
     331   different error handling strategies; for example, a Web browser may wish to
     332   transparently recover from a response where the Location header field
     333   doesn't parse according to the ABNF, whereby in a systems control protocol
     334   using HTTP, this type of error recovery could lead to dangerous consequences.
    46414659    </t>
    46424660    <t>
     4661      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>:
     4662      "Document HTTP's error-handling philosophy"
     4663    </t>
     4664    <t>
    46434665      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/310"/>:
    46444666      "clarify 303 redirect on HEAD"
Note: See TracChangeset for help on using the changeset viewer.