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

Make ABNF/conformance terminology consistent (see #362)

1 edited


  • draft-ietf-httpbis/latest/p5-range.xml

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