Ignore:
Timestamp:
Jul 15, 2012, 10:38:18 PM (8 years ago)
Author:
julian.reschke@…
Message:

Undo the part of [1783] that removed/moved the conformance/syntax sections.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1786 r1796  
    171171   for the selected representation.
    172172</t>
     173
     174<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
     175<t>
     176   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     177   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     178   document are to be interpreted as described in <xref target="RFC2119"/>.
     179</t>
     180<t>
     181   This specification targets conformance criteria according to the role of
     182   a participant in HTTP communication.  Hence, HTTP requirements are placed
     183   on senders, recipients, clients, servers, user agents, intermediaries,
     184   origin servers, proxies, gateways, or caches, depending on what behavior
     185   is being constrained by the requirement. See &architecture; for definitions
     186   of these terms.
     187</t>
     188<t>
     189   The verb "generate" is used instead of "send" where a requirement
     190   differentiates between creating a protocol element and merely forwarding a
     191   received element downstream.
     192</t>
     193<t>
     194   An implementation is considered conformant if it complies with all of the
     195   requirements associated with the roles it partakes in HTTP. Note that
     196   SHOULD-level requirements are relevant here, unless one of the documented
     197   exceptions is applicable.
     198</t>
     199<t>
     200   This document also uses ABNF to define valid protocol elements
     201   (<xref target="notation"/>).
     202   In addition to the prose requirements placed upon them, senders &MUST-NOT;
     203   generate protocol elements that do not match the grammar defined by the
     204   ABNF rules for those protocol elements that are applicable to the sender's
     205   role. If a received protocol element is processed, the recipient &MUST; be
     206   able to parse any value that would match the ABNF rules for that protocol
     207   element, excluding only those rules not applicable to the recipient's role.
     208</t>
     209<t>
     210   Unless noted otherwise, a recipient &MAY; attempt to recover a usable
     211   protocol element from an invalid construct.  HTTP does not define
     212   specific error handling mechanisms except when they have a direct impact
     213   on security, since different applications of the protocol require
     214   different error handling strategies.  For example, a Web browser might
     215   wish to transparently recover from a response where the
     216   <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
     217   whereas a systems control client might consider any form of error recovery
     218   to be dangerous.
     219</t>
     220</section>
     221
     222<section title="Syntax Notation" anchor="notation">
     223  <x:anchor-alias value="ALPHA"/>
     224  <x:anchor-alias value="CR"/>
     225  <x:anchor-alias value="DIGIT"/>
     226  <x:anchor-alias value="DQUOTE"/>
     227  <x:anchor-alias value="LF"/>
     228  <x:anchor-alias value="OCTET"/>
     229  <x:anchor-alias value="VCHAR"/>
     230  <x:anchor-alias value="core.rules"/>
     231  <x:anchor-alias value="obs-text"/>
     232  <x:anchor-alias value="OWS"/>
     233  <x:anchor-alias value="HTTP-date"/>
     234<t>
     235   This specification uses the Augmented Backus-Naur Form (ABNF) notation
     236   of <xref target="RFC5234"/> with the list rule extension defined in
     237   &notation;.  <xref target="collected.abnf"/> shows the collected ABNF
     238   with the list rule expanded.
     239</t>
     240<t>
     241  The following core rules are included by
     242  reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>:
     243  ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
     244  DIGIT (decimal 0-9), DQUOTE (double quote),
     245  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
     246  OCTET (any 8-bit sequence of data), SP (space), and
     247  VCHAR (any visible US-ASCII character).
     248</t>
     249<t>
     250  The ABNF rules below are defined in <xref target="Part1"/> and
     251  <xref target="Part2"/>:
     252</t>
     253<figure><artwork type="abnf2616">
     254  <x:ref>OWS</x:ref>           = &lt;OWS, defined in &whitespace;&gt;
     255  <x:ref>obs-text</x:ref>      = &lt;obs-text, defined in &field-components;&gt;
     256  <x:ref>HTTP-date</x:ref>     = &lt;HTTP-date, defined in &http-date;&gt;
     257</artwork></figure>
     258</section>
    173259</section>
    174260
     
    10021088</t>
    10031089</section>
    1004 </section>
    1005 
    1006 <section title="ABNF Rules Defined Elsewhere" anchor="abnf.dependencies">
    1007   <x:anchor-alias value="ALPHA"/>
    1008   <x:anchor-alias value="CR"/>
    1009   <x:anchor-alias value="DIGIT"/>
    1010   <x:anchor-alias value="DQUOTE"/>
    1011   <x:anchor-alias value="LF"/>
    1012   <x:anchor-alias value="OCTET"/>
    1013   <x:anchor-alias value="VCHAR"/>
    1014   <x:anchor-alias value="core.rules"/>
    1015   <x:anchor-alias value="obs-text"/>
    1016   <x:anchor-alias value="OWS"/>
    1017   <x:anchor-alias value="HTTP-date"/>
    1018 <t>
    1019    This specification uses the Augmented Backus-Naur Form (ABNF) notation
    1020    of <xref target="RFC5234"/> with the list rule extension defined in
    1021    &notation;.  <xref target="collected.abnf"/> shows the collected ABNF
    1022    with the list rule expanded.
    1023 </t>
    1024 <t>
    1025   The following core rules are included by
    1026   reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>:
    1027   ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
    1028   DIGIT (decimal 0-9), DQUOTE (double quote),
    1029   HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
    1030   OCTET (any 8-bit sequence of data), SP (space), and
    1031   VCHAR (any visible US-ASCII character).
    1032 </t>
    1033 <t>
    1034   The ABNF rules below are defined in <xref target="Part1"/> and
    1035   <xref target="Part2"/>:
    1036 </t>
    1037 <figure><artwork type="abnf2616">
    1038   <x:ref>OWS</x:ref>           = &lt;OWS, defined in &whitespace;&gt;
    1039   <x:ref>obs-text</x:ref>      = &lt;obs-text, defined in &field-components;&gt;
    1040   <x:ref>HTTP-date</x:ref>     = &lt;HTTP-date, defined in &http-date;&gt;
    1041 </artwork></figure>
    1042 <t>
    1043    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    1044    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    1045    document are to be interpreted as described in <xref target="RFC2119"/>.
    1046 </t>
    10471090</section>
    10481091
Note: See TracChangeset for help on using the changeset viewer.