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

Make ABNF/conformance terminology consistent (see #362)

1 edited


  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1764 r1770  
    177    This document defines conformance criteria for several roles in HTTP
    178    communication, including Senders, Recipients, Clients, Servers, User-Agents,
    179    Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
    180    for definitions of these terms.
     177   This specification targets conformance criteria according to the role of
     178   a participant in HTTP communication.  Hence, HTTP requirements are placed
     179   on senders, recipients, clients, servers, user agents, intermediaries,
     180   origin servers, proxies, gateways, or caches, depending on what behavior
     181   is being constrained by the requirement. See &architecture; for definitions
     182   of these terms.
     185   The verb "generate" is used instead of "send" where a requirement
     186   differentiates between creating a protocol element and merely forwarding a
     187   received element downstream.
    183190   An implementation is considered conformant if it complies with all of the
    184    requirements associated with its role(s). Note that SHOULD-level requirements
    185    are relevant here, unless one of the documented exceptions is applicable.
     191   requirements associated with the roles it partakes in HTTP. Note that
     192   SHOULD-level requirements are relevant here, unless one of the documented
     193   exceptions is applicable.
    188196   This document also uses ABNF to define valid protocol elements
    189    (<xref target="notation"/>). In addition to the prose requirements placed
    190    upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
    191 </t>
    192 <t>
    193    Unless noted otherwise, Recipients &MUST; be able to parse all protocol
    194    elements matching the ABNF rules defined for them and &MAY; take steps to
    195    recover a usable protocol element from an invalid construct. However, HTTP does not define
    196    specific error handling mechanisms, except in cases where it has direct
    197    impact on security. This is because different uses of the protocol require
    198    different error handling strategies; for example, a Web browser might wish to
    199    transparently recover from a response where the <x:ref>Location</x:ref>
    200    header field doesn't parse according to the ABNF, whereby in a systems
    201    control protocol using HTTP, this type of error recovery could lead to
    202    dangerous consequences.
     197   (<xref target="notation"/>).
     198   In addition to the prose requirements placed upon them, senders &MUST-NOT;
     199   generate protocol elements that do not match the grammar defined by the
     200   ABNF rules for those protocol elements that are applicable to the sender's
     201   role. If a received protocol element is processed, the recipient &MUST; be
     202   able to parse any value that would match the ABNF rules for that protocol
     203   element, excluding only those rules not applicable to the recipient's role.
     206   Unless noted otherwise, a recipient &MAY; attempt to recover a usable
     207   protocol element from an invalid construct.  HTTP does not define
     208   specific error handling mechanisms except when they have a direct impact
     209   on security, since different applications of the protocol require
     210   different error handling strategies.  For example, a Web browser might
     211   wish to transparently recover from a response where the
     212   <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
     213   whereas a systems control client might consider any form of error recovery
     214   to be dangerous.
Note: See TracChangeset for help on using the changeset viewer.