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

Make ABNF/conformance terminology consistent (see #362)

1 edited


  • draft-ietf-httpbis/latest/p2-semantics.xml

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