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/p7-auth.xml

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