Changeset 1770 for draft-ietf-httpbis/latest/p4-conditional.xml

Timestamp:

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

Author:

julian.reschke@…

Message:

Make ABNF/conformance terminology consistent (see #362)

File:

• draft-ietf-httpbis/latest/p4-conditional.xml (modified) (1 diff)

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

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