Ignore:
Timestamp:
10/09/12 02:46:17 (8 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/p4-conditional.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'/>">
     
    172173</t>
    173174
    174 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
     175<section title="Conformance and Error Handling" anchor="conformance">
    175176<t>
    176177   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     
    179180</t>
    180181<t>
    181    This specification targets conformance criteria according to the role of
    182    a participant in HTTP communication.  Hence, HTTP requirements are placed
    183    on senders, recipients, clients, servers, user agents, intermediaries,
    184    origin servers, proxies, gateways, or caches, depending on what behavior
    185    is being constrained by the requirement. See &architecture; for definitions
    186    of these terms.
    187 </t>
    188 <t>
    189    The verb "generate" is used instead of "send" where a requirement
    190    differentiates between creating a protocol element and merely forwarding a
    191    received element downstream.
    192 </t>
    193 <t>
    194    An implementation is considered conformant if it complies with all of the
    195    requirements associated with the roles it partakes in HTTP. Note that
    196    SHOULD-level requirements are relevant here, unless one of the documented
    197    exceptions is applicable.
    198 </t>
    199 <t>
    200    This document also uses ABNF to define valid protocol elements
    201    (<xref target="notation"/>).
    202    In addition to the prose requirements placed upon them, senders &MUST-NOT;
    203    generate protocol elements that do not match the grammar defined by the
    204    ABNF rules for those protocol elements that are applicable to the sender's
    205    role. If a received protocol element is processed, the recipient &MUST; be
    206    able to parse any value that would match the ABNF rules for that protocol
    207    element, excluding only those rules not applicable to the recipient's role.
    208 </t>
    209 <t>
    210    Unless noted otherwise, a recipient &MAY; attempt to recover a usable
    211    protocol element from an invalid construct.  HTTP does not define
    212    specific error handling mechanisms except when they have a direct impact
    213    on security, since different applications of the protocol require
    214    different error handling strategies.  For example, a Web browser might
    215    wish to transparently recover from a response where the
    216    <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
    217    whereas a systems control client might consider any form of error recovery
    218    to be dangerous.
     182   Conformance criteria and considerations regarding error handling
     183   are defined in &conformance;.
    219184</t>
    220185</section>
Note: See TracChangeset for help on using the changeset viewer.