Ignore:
Timestamp:
Jul 14, 2012, 5:41:41 AM (7 years ago)
Author:
julian.reschke@…
Message:

Make ABNF/conformance terminology consistent (see #362)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1768 r1770  
    629629   on senders, recipients, clients, servers, user agents, intermediaries,
    630630   origin servers, proxies, gateways, or caches, depending on what behavior
    631    is being constrained by the requirement. The verb "generate" is used
    632    instead of "send" where a requirement differentiates between creating a
    633    protocol element and merely forwarding a received element downstream.
     631   is being constrained by the requirement.
     632</t>
     633<t>
     634   The verb "generate" is used instead of "send" where a requirement
     635   differentiates between creating a protocol element and merely forwarding a
     636   received element downstream.
    634637</t>
    635638<t>
    636639   An implementation is considered conformant if it complies with all of the
    637    requirements associated with the roles it partakes in HTTP.
    638 </t>
    639 <t>
    640    A sender &MUST-NOT; generate protocol elements that do not match
    641    the grammar defined by the ABNF rules for those protocol elements that
    642    are applicable to the sender's role.
    643    If a received protocol element is processed, the recipient &MUST; be able
    644    to parse any value that would match the ABNF rules for that protocol
     640   requirements associated with the roles it partakes in HTTP. Note that
     641   SHOULD-level requirements are relevant here, unless one of the documented
     642   exceptions is applicable.
     643</t>
     644<t>
     645   In addition to the prose requirements placed upon them, senders &MUST-NOT;
     646   generate protocol elements that do not match the grammar defined by the
     647   ABNF rules for those protocol elements that are applicable to the sender's
     648   role. If a received protocol element is processed, the recipient &MUST; be
     649   able to parse any value that would match the ABNF rules for that protocol
    645650   element, excluding only those rules not applicable to the recipient's role.
    646651</t>
     
    651656   on security, since different applications of the protocol require
    652657   different error handling strategies.  For example, a Web browser might
    653    wish to transparently recover from a response where the <x:ref>Location</x:ref>
    654    header field doesn't parse according to the ABNF, whereas a systems control
    655    client might consider any form of error recovery to be dangerous.
     658   wish to transparently recover from a response where the
     659   <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
     660   whereas a systems control client might consider any form of error recovery
     661   to be dangerous.
    656662</t>
    657663</section>
Note: See TracChangeset for help on using the changeset viewer.