Ignore:
Timestamp:
15/07/12 06:40:35 (8 years ago)
Author:
fielding@…
Message:

Update p4 abstract and introduction; replace redundancies with reference to p1

File:
1 edited

Legend:

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

    r1773 r1783  
    105105<t>
    106106   The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
    107    distributed, collaborative, hypertext information systems. HTTP has been in
    108    use by the World Wide Web global information initiative since 1990. This
    109    document is Part 4 of the seven-part specification that defines the protocol
    110    referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616.
    111 </t>
    112 <t>
    113    Part 4 defines request header fields for indicating conditional requests and
    114    the rules for constructing responses to those requests.
     107   distributed, collaborative, hypertext information systems. This document
     108   defines HTTP/1.1 conditional requests, including metadata header fields
     109   for indicating state changes, request header fields for making
     110   preconditions on such state, and rules for constructing the responses to a
     111   conditional request when one or more preconditions evaluate to false.
    115112</t>
    116113</abstract>
     
    133130</note>
    134131</front>
     132
    135133<middle>
    136134<section title="Introduction" anchor="introduction">
    137135<t>
    138    This document defines the HTTP/1.1 conditional request mechanisms,
    139    including both metadata for indicating/observing changes in resource
    140    representations and request header fields that specify preconditions
    141    on that metadata; to be checked before performing the request method.
     136   Conditional requests are HTTP requests <xref target="Part2"/> that include
     137   one or more header fields indicating a precondition to be tested before
     138   applying the method semantics to the target resource.
     139   Each precondition is based on metadata that is expected to change if the
     140   selected representation of the target resource is changed.
     141   This document defines the HTTP/1.1 conditional request mechanisms in terms
     142   of the architecture, syntax notation, and conformance criteria defined in
     143   &architecture;.
     144</t>
     145<t>
    142146   Conditional GET requests are the most efficient mechanism for HTTP
    143147   cache updates &caching;.  Conditionals can also be
     
    167171   for the selected representation.
    168172</t>
    169 
    170 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
    171 <t>
    172    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    173    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    174    document are to be interpreted as described in <xref target="RFC2119"/>.
    175 </t>
    176 <t>
    177    This specification targets conformance criteria according to the role of
    178    a participant in HTTP communication.  Hence, HTTP requirements are placed
    179    on senders, recipients, clients, servers, user agents, intermediaries,
    180    origin servers, proxies, gateways, or caches, depending on what behavior
    181    is being constrained by the requirement. See &architecture; for definitions
    182    of these terms.
    183 </t>
    184 <t>
    185    The verb "generate" is used instead of "send" where a requirement
    186    differentiates between creating a protocol element and merely forwarding a
    187    received element downstream.
    188 </t>
    189 <t>
    190    An implementation is considered conformant if it complies with all of the
    191    requirements associated with the roles it partakes in HTTP. Note that
    192    SHOULD-level requirements are relevant here, unless one of the documented
    193    exceptions is applicable.
    194 </t>
    195 <t>
    196    This document also uses ABNF to define valid protocol elements
    197    (<xref target="notation"/>).
    198    In addition to the prose requirements placed upon them, senders &MUST-NOT;
    199    generate protocol elements that do not match the grammar defined by the
    200    ABNF rules for those protocol elements that are applicable to the sender's
    201    role. If a received protocol element is processed, the recipient &MUST; be
    202    able to parse any value that would match the ABNF rules for that protocol
    203    element, excluding only those rules not applicable to the recipient's role.
    204 </t>
    205 <t>
    206    Unless noted otherwise, a recipient &MAY; attempt to recover a usable
    207    protocol element from an invalid construct.  HTTP does not define
    208    specific error handling mechanisms except when they have a direct impact
    209    on security, since different applications of the protocol require
    210    different error handling strategies.  For example, a Web browser might
    211    wish to transparently recover from a response where the
    212    <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
    213    whereas a systems control client might consider any form of error recovery
    214    to be dangerous.
    215 </t>
    216 </section>
    217 
    218 <section title="Syntax Notation" anchor="notation">
    219   <x:anchor-alias value="ALPHA"/>
    220   <x:anchor-alias value="CR"/>
    221   <x:anchor-alias value="DIGIT"/>
    222   <x:anchor-alias value="DQUOTE"/>
    223   <x:anchor-alias value="LF"/>
    224   <x:anchor-alias value="OCTET"/>
    225   <x:anchor-alias value="VCHAR"/>
    226   <x:anchor-alias value="core.rules"/>
    227   <x:anchor-alias value="obs-text"/>
    228   <x:anchor-alias value="OWS"/>
    229   <x:anchor-alias value="HTTP-date"/>
    230 <t>
    231    This specification uses the Augmented Backus-Naur Form (ABNF) notation
    232    of <xref target="RFC5234"/> with the list rule extension defined in
    233    &notation;.  <xref target="collected.abnf"/> shows the collected ABNF
    234    with the list rule expanded.
    235 </t>
    236 <t>
    237   The following core rules are included by
    238   reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>:
    239   ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
    240   DIGIT (decimal 0-9), DQUOTE (double quote),
    241   HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
    242   OCTET (any 8-bit sequence of data), SP (space), and
    243   VCHAR (any visible US-ASCII character).
    244 </t>
    245 <t>
    246   The ABNF rules below are defined in <xref target="Part1"/> and
    247   <xref target="Part2"/>:
    248 </t>
    249 <figure><artwork type="abnf2616">
    250   <x:ref>OWS</x:ref>           = &lt;OWS, defined in &whitespace;&gt;
    251   <x:ref>obs-text</x:ref>      = &lt;obs-text, defined in &field-components;&gt;
    252   <x:ref>HTTP-date</x:ref>     = &lt;HTTP-date, defined in &http-date;&gt;
    253 </artwork></figure>
    254 </section>
    255173</section>
    256174
     
    10841002</t>
    10851003</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>
    10861047</section>
    10871048
Note: See TracChangeset for help on using the changeset viewer.