14/07/12 12:41:41 (10 years ago)

Make ABNF/conformance terminology consistent (see #362)

1 edited


  • draft-ietf-httpbis/latest/p6-cache.xml

    r1769 r1770  
    312    This document defines conformance criteria for several roles in HTTP
    313    communication, including Senders, Recipients, Clients, Servers, User-Agents,
    314    Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
    315    for definitions of these terms.
     312   This specification targets conformance criteria according to the role of
     313   a participant in HTTP communication.  Hence, HTTP requirements are placed
     314   on senders, recipients, clients, servers, user agents, intermediaries,
     315   origin servers, proxies, gateways, or caches, depending on what behavior
     316   is being constrained by the requirement. See &architecture; for definitions
     317   of these terms.
     320   The verb "generate" is used instead of "send" where a requirement
     321   differentiates between creating a protocol element and merely forwarding a
     322   received element downstream.
    318325   An implementation is considered conformant if it complies with all of the
    319    requirements associated with its role(s). Note that SHOULD-level requirements
    320    are relevant here, unless one of the documented exceptions is applicable.
     326   requirements associated with the roles it partakes in HTTP. Note that
     327   SHOULD-level requirements are relevant here, unless one of the documented
     328   exceptions is applicable.
    323331   This document also uses ABNF to define valid protocol elements
    324    (<xref target="notation"/>). In addition to the prose requirements placed
    325    upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
    326 </t>
    327 <t>
    328    Unless noted otherwise, Recipients &MUST; be able to parse all protocol
    329    elements matching the ABNF rules defined for them and &MAY; take steps to
    330    recover a usable protocol element from an invalid construct. However, HTTP does not define
    331    specific error handling mechanisms, except in cases where it has direct
    332    impact on security. This is because different uses of the protocol require
    333    different error handling strategies; for example, a Web browser might wish to
    334    transparently recover from a response where the <x:ref>Location</x:ref>
    335    header field doesn't parse according to the ABNF, whereby in a systems
    336    control protocol using HTTP, this type of error recovery could lead to
    337    dangerous consequences.
     332   (<xref target="notation"/>).
     333   In addition to the prose requirements placed upon them, senders &MUST-NOT;
     334   generate protocol elements that do not match the grammar defined by the
     335   ABNF rules for those protocol elements that are applicable to the sender's
     336   role. If a received protocol element is processed, the recipient &MUST; be
     337   able to parse any value that would match the ABNF rules for that protocol
     338   element, excluding only those rules not applicable to the recipient's role.
     341   Unless noted otherwise, a recipient &MAY; attempt to recover a usable
     342   protocol element from an invalid construct.  HTTP does not define
     343   specific error handling mechanisms except when they have a direct impact
     344   on security, since different applications of the protocol require
     345   different error handling strategies.  For example, a Web browser might
     346   wish to transparently recover from a response where the
     347   <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
     348   whereas a systems control client might consider any form of error recovery
     349   to be dangerous.
Note: See TracChangeset for help on using the changeset viewer.