Ignore:
Timestamp:
Sep 9, 2012, 7:46:17 PM (7 years ago)
Author:
fielding@…
Message:

Be more consistent regarding targeting conformance requirements.
Only define conformance criteria once, but repeat required nits.

Remove antiquated requirement about media type parameters not being
recognized by 1993-era browsers.

Add reference to TLS in p1.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p5-range.xml

    r1867 r1875  
    1717  <!ENTITY Note "<x:h xmlns:x='http://purl.org/net/xml2rfc/ext'>Note:</x:h>">
    1818  <!ENTITY architecture               "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     19  <!ENTITY conformance                "<xref target='Part1' x:rel='#conformance' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1920  <!ENTITY notation                   "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2021  <!ENTITY abnf-extension             "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    153154</t>
    154155
    155 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
     156<section title="Conformance and Error Handling" anchor="conformance">
    156157<t>
    157158   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     
    160161</t>
    161162<t>
    162    This specification targets conformance criteria according to the role of
    163    a participant in HTTP communication.  Hence, HTTP requirements are placed
    164    on senders, recipients, clients, servers, user agents, intermediaries,
    165    origin servers, proxies, gateways, or caches, depending on what behavior
    166    is being constrained by the requirement. See &architecture; for definitions
    167    of these terms.
    168 </t>
    169 <t>
    170    The verb "generate" is used instead of "send" where a requirement
    171    differentiates between creating a protocol element and merely forwarding a
    172    received element downstream.
    173 </t>
    174 <t>
    175    An implementation is considered conformant if it complies with all of the
    176    requirements associated with the roles it partakes in HTTP. Note that
    177    SHOULD-level requirements are relevant here, unless one of the documented
    178    exceptions is applicable.
    179 </t>
    180 <t>
    181    This document also uses ABNF to define valid protocol elements
    182    (<xref target="notation"/>).
    183    In addition to the prose requirements placed upon them, senders &MUST-NOT;
    184    generate protocol elements that do not match the grammar defined by the
    185    ABNF rules for those protocol elements that are applicable to the sender's
    186    role. If a received protocol element is processed, the recipient &MUST; be
    187    able to parse any value that would match the ABNF rules for that protocol
    188    element, excluding only those rules not applicable to the recipient's role.
    189 </t>
    190 <t>
    191    Unless noted otherwise, a recipient &MAY; attempt to recover a usable
    192    protocol element from an invalid construct.  HTTP does not define
    193    specific error handling mechanisms except when they have a direct impact
    194    on security, since different applications of the protocol require
    195    different error handling strategies.  For example, a Web browser might
    196    wish to transparently recover from a response where the
    197    <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
    198    whereas a systems control client might consider any form of error recovery
    199    to be dangerous.
     163   Conformance criteria and considerations regarding error handling
     164   are defined in &conformance;.
    200165</t>
    201166</section>
Note: See TracChangeset for help on using the changeset viewer.