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

Make ABNF/conformance terminology consistent (see #362)

1 edited


  • draft-ietf-httpbis/latest/p7-auth.xml

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