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/p6-cache.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 acks                        "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    298299</section>
    299300
    300 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
     301<section title="Conformance and Error Handling" anchor="conformance">
    301302<t>
    302303   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     
    305306</t>
    306307<t>
    307    This specification targets conformance criteria according to the role of
    308    a participant in HTTP communication.  Hence, HTTP requirements are placed
    309    on senders, recipients, clients, servers, user agents, intermediaries,
    310    origin servers, proxies, gateways, or caches, depending on what behavior
    311    is being constrained by the requirement. See &architecture; for definitions
    312    of these terms.
    313 </t>
    314 <t>
    315    The verb "generate" is used instead of "send" where a requirement
    316    differentiates between creating a protocol element and merely forwarding a
    317    received element downstream.
    318 </t>
    319 <t>
    320    An implementation is considered conformant if it complies with all of the
    321    requirements associated with the roles it partakes in HTTP. Note that
    322    SHOULD-level requirements are relevant here, unless one of the documented
    323    exceptions is applicable.
    324 </t>
    325 <t>
    326    This document also uses ABNF to define valid protocol elements
    327    (<xref target="notation"/>).
    328    In addition to the prose requirements placed upon them, senders &MUST-NOT;
    329    generate protocol elements that do not match the grammar defined by the
    330    ABNF rules for those protocol elements that are applicable to the sender's
    331    role. If a received protocol element is processed, the recipient &MUST; be
    332    able to parse any value that would match the ABNF rules for that protocol
    333    element, excluding only those rules not applicable to the recipient's role.
    334 </t>
    335 <t>
    336    Unless noted otherwise, a recipient &MAY; attempt to recover a usable
    337    protocol element from an invalid construct.  HTTP does not define
    338    specific error handling mechanisms except when they have a direct impact
    339    on security, since different applications of the protocol require
    340    different error handling strategies.  For example, a Web browser might
    341    wish to transparently recover from a response where the
    342    <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
    343    whereas a systems control client might consider any form of error recovery
    344    to be dangerous.
     308   Conformance criteria and considerations regarding error handling
     309   are defined in &conformance;.
    345310</t>
    346311</section>
     
    816781<t>
    817782  <list style="symbols">
    818      <t>HTTP/1.1 clients and caches &SHOULD; assume that an RFC-850 date
     783     <t>Recipients &SHOULD; assume that an RFC-850 date
    819784        which appears to be more than 50 years in the future is in fact
    820785        in the past (this helps solve the "year 2000" problem).</t>
     
    824789        case-insensitively.</t>
    825790             
    826      <t>An HTTP/1.1 implementation &MAY; internally represent a parsed
     791     <t>An implementation &MAY; internally represent a parsed
    827792        <x:ref>Expires</x:ref> date as earlier than the proper value, but
    828793        &MUST-NOT; internally represent a parsed Expires date as later than the
    829794        proper value.</t>
    830795
    831      <t>All expiration-related calculations &MUST; be done in GMT. The
    832         local time zone &MUST-NOT; influence the calculation or comparison
     796     <t>Recipients &MUST; perform all expiration-related calculations in GMT.
     797        The local time zone &MUST-NOT; influence the calculation or comparison
    833798        of an age or expiration time.</t>
    834799
Note: See TracChangeset for help on using the changeset viewer.