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/p2-semantics.html

    r1769 r1770  
    846846         in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
    847847      </p>
    848       <p id="rfc.section.1.2.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
    849          Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
    850       </p>
    851       <p id="rfc.section.1.2.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that
    852          SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
    853       </p>
    854       <p id="rfc.section.1.2.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.3</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid.
    855       </p>
    856       <p id="rfc.section.1.2.p.5">Unless noted otherwise, Recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling
    857          mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    858          different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
    859          the <a href="#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery
    860          could lead to dangerous consequences.
     848      <p id="rfc.section.1.2.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
     849         requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
     850         or caches, depending on what behavior is being constrained by the requirement. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
     851      </p>
     852      <p id="rfc.section.1.2.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
     853         forwarding a received element downstream.
     854      </p>
     855      <p id="rfc.section.1.2.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
     856         in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
     857      </p>
     858      <p id="rfc.section.1.2.p.5">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.3</a>). In addition to the prose requirements placed upon them, senders <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements that are applicable
     859         to the sender's role. If a received protocol element is processed, the recipient <em class="bcp14">MUST</em> be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable
     860         to the recipient's role.
     861      </p>
     862      <p id="rfc.section.1.2.p.6">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms
     863         except when they have a direct impact on security, since different applications of the protocol require different error handling
     864         strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery
     865         to be dangerous.
    861866      </p>
    862867      <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
Note: See TracChangeset for help on using the changeset viewer.