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

Make ABNF/conformance terminology consistent (see #362)

Location:
draft-ietf-httpbis/latest
Files:
12 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r1768 r1770  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 14, 2013";
     451       content: "Expires January 15, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2012-07-13">
     493      <meta name="dct.issued" scheme="ISO8601" content="2012-07-14">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: January 14, 2013</td>
     525               <td class="left">Expires: January 15, 2013</td>
    526526               <td class="right">greenbytes</td>
    527527            </tr>
    528528            <tr>
    529529               <td class="left"></td>
    530                <td class="right">July 13, 2012</td>
     530               <td class="right">July 14, 2012</td>
    531531            </tr>
    532532         </tbody>
    … …  
    560560         in progress”.
    561561      </p>
    562       <p>This Internet-Draft will expire on January 14, 2013.</p>
     562      <p>This Internet-Draft will expire on January 15, 2013.</p>
    563563      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    564564      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    965965      <p id="rfc.section.2.6.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
    966966         requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
    967          or caches, depending on what behavior is being constrained by the requirement. The verb "generate" is used instead of "send"
    968          where a requirement differentiates between creating a protocol element and merely forwarding a received element downstream.
    969       </p>
    970       <p id="rfc.section.2.6.p.2">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
    971          in HTTP.
    972       </p>
    973       <p id="rfc.section.2.6.p.3">A sender <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
     967         or caches, depending on what behavior is being constrained by the requirement.
     968      </p>
     969      <p id="rfc.section.2.6.p.2">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
     970         forwarding a received element downstream.
     971      </p>
     972      <p id="rfc.section.2.6.p.3">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
     973         in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
     974      </p>
     975      <p id="rfc.section.2.6.p.4">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
    974976         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
    975977         to the recipient's role.
    976978      </p>
    977       <p id="rfc.section.2.6.p.4">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
     979      <p id="rfc.section.2.6.p.5">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
    978980         except when they have a direct impact on security, since different applications of the protocol require different error handling
    979981         strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#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

  • 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>

  • 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>

  • draft-ietf-httpbis/latest/p2-semantics.xml

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

  • draft-ietf-httpbis/latest/p4-conditional.html

    r1764 r1770  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 14, 2013";
     451       content: "Expires January 15, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    490490      <meta name="dct.creator" content="Reschke, J. F.">
    491491      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    492       <meta name="dct.issued" scheme="ISO8601" content="2012-07-13">
     492      <meta name="dct.issued" scheme="ISO8601" content="2012-07-14">
    493493      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    494494      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
    … …  
    516516            </tr>
    517517            <tr>
    518                <td class="left">Expires: January 14, 2013</td>
     518               <td class="left">Expires: January 15, 2013</td>
    519519               <td class="right">J. Reschke, Editor</td>
    520520            </tr>
    … …  
    525525            <tr>
    526526               <td class="left"></td>
    527                <td class="right">July 13, 2012</td>
     527               <td class="right">July 14, 2012</td>
    528528            </tr>
    529529         </tbody>
    … …  
    554554         in progress”.
    555555      </p>
    556       <p>This Internet-Draft will expire on January 14, 2013.</p>
     556      <p>This Internet-Draft will expire on January 15, 2013.</p>
    557557      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    558558      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    649649         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>.
    650650      </p>
    651       <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
    652          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.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
    653       </p>
    654       <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that
    655          SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
    656       </p>
    657       <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid.
    658       </p>
    659       <p id="rfc.section.1.1.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
    660          mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    661          different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
    662          the <a href="p2-semantics.html#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
    663          could lead to dangerous consequences.
     651      <p id="rfc.section.1.1.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
     652         requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
     653         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.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
     654      </p>
     655      <p id="rfc.section.1.1.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
     656         forwarding a received element downstream.
     657      </p>
     658      <p id="rfc.section.1.1.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
     659         in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
     660      </p>
     661      <p id="rfc.section.1.1.p.5">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</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
     662         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
     663         to the recipient's role.
     664      </p>
     665      <p id="rfc.section.1.1.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
     666         except when they have a direct impact on security, since different applications of the protocol require different error handling
     667         strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#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
     668         to be dangerous.
    664669      </p>
    665670      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>

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

    r1764 r1770  
    175175</t>
    176176<t>
    177    This document defines conformance criteria for several roles in HTTP
    178    communication, including Senders, Recipients, Clients, Servers, User-Agents,
    179    Origin Servers, Intermediaries, Proxies and Gateways. See &architecture;
    180    for definitions of these terms.
     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.
    181188</t>
    182189<t>
    183190   An implementation is considered conformant if it complies with all of the
    184    requirements associated with its role(s). Note that SHOULD-level requirements
    185    are relevant here, unless one of the documented exceptions is applicable.
     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.
    186194</t>
    187195<t>
    188196   This document also uses ABNF to define valid protocol elements
    189    (<xref target="notation"/>). In addition to the prose requirements placed
    190    upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
    191 </t>
    192 <t>
    193    Unless noted otherwise, Recipients &MUST; be able to parse all protocol
    194    elements matching the ABNF rules defined for them and &MAY; take steps to
    195    recover a usable protocol element from an invalid construct. However, HTTP does not define
    196    specific error handling mechanisms, except in cases where it has direct
    197    impact on security. This is because different uses of the protocol require
    198    different error handling strategies; for example, a Web browser might wish to
    199    transparently recover from a response where the <x:ref>Location</x:ref>
    200    header field doesn't parse according to the ABNF, whereby in a systems
    201    control protocol using HTTP, this type of error recovery could lead to
    202    dangerous consequences.
     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.
    203215</t>
    204216</section>

  • draft-ietf-httpbis/latest/p5-range.html

    r1767 r1770  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 14, 2013";
     451       content: "Expires January 15, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    492492      <meta name="dct.creator" content="Reschke, J. F.">
    493493      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    494       <meta name="dct.issued" scheme="ISO8601" content="2012-07-13">
     494      <meta name="dct.issued" scheme="ISO8601" content="2012-07-14">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    496496      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range requests and the rules for constructing and combining responses to those requests.">
    … …  
    518518            </tr>
    519519            <tr>
    520                <td class="left">Expires: January 14, 2013</td>
     520               <td class="left">Expires: January 15, 2013</td>
    521521               <td class="right">J. Reschke, Editor</td>
    522522            </tr>
    … …  
    527527            <tr>
    528528               <td class="left"></td>
    529                <td class="right">July 13, 2012</td>
     529               <td class="right">July 14, 2012</td>
    530530            </tr>
    531531         </tbody>
    … …  
    554554         in progress”.
    555555      </p>
    556       <p>This Internet-Draft will expire on January 14, 2013.</p>
     556      <p>This Internet-Draft will expire on January 15, 2013.</p>
    557557      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    558558      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    671671         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>.
    672672      </p>
    673       <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
    674          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.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
    675       </p>
    676       <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that
    677          SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
    678       </p>
    679       <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid.
    680       </p>
    681       <p id="rfc.section.1.1.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
    682          mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    683          different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
    684          the <a href="p2-semantics.html#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
    685          could lead to dangerous consequences.
     673      <p id="rfc.section.1.1.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
     674         requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
     675         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.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
     676      </p>
     677      <p id="rfc.section.1.1.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
     678         forwarding a received element downstream.
     679      </p>
     680      <p id="rfc.section.1.1.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
     681         in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
     682      </p>
     683      <p id="rfc.section.1.1.p.5">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</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
     684         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
     685         to the recipient's role.
     686      </p>
     687      <p id="rfc.section.1.1.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
     688         except when they have a direct impact on security, since different applications of the protocol require different error handling
     689         strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#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
     690         to be dangerous.
    686691      </p>
    687692      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>

  • draft-ietf-httpbis/latest/p5-range.xml

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

  • draft-ietf-httpbis/latest/p6-cache.html

    r1769 r1770  
    787787         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>.
    788788      </p>
    789       <p id="rfc.section.1.3.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
    790          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.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
    791       </p>
    792       <p id="rfc.section.1.3.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that
    793          SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
    794       </p>
    795       <p id="rfc.section.1.3.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.4</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid.
    796       </p>
    797       <p id="rfc.section.1.3.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
    798          mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    799          different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
    800          the <a href="p2-semantics.html#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
    801          could lead to dangerous consequences.
     789      <p id="rfc.section.1.3.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
     790         requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
     791         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.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
     792      </p>
     793      <p id="rfc.section.1.3.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
     794         forwarding a received element downstream.
     795      </p>
     796      <p id="rfc.section.1.3.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
     797         in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
     798      </p>
     799      <p id="rfc.section.1.3.p.5">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.4</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
     800         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
     801         to the recipient's role.
     802      </p>
     803      <p id="rfc.section.1.3.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
     804         except when they have a direct impact on security, since different applications of the protocol require different error handling
     805         strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#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
     806         to be dangerous.
    802807      </p>
    803808      <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>

  • draft-ietf-httpbis/latest/p6-cache.xml

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

  • draft-ietf-httpbis/latest/p7-auth.html

    r1764 r1770  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 14, 2013";
     451       content: "Expires January 15, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    489489      <meta name="dct.creator" content="Reschke, J. F.">
    490490      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    491       <meta name="dct.issued" scheme="ISO8601" content="2012-07-13">
     491      <meta name="dct.issued" scheme="ISO8601" content="2012-07-14">
    492492      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    493493      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework.">
    … …  
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: January 14, 2013</td>
     522               <td class="left">Expires: January 15, 2013</td>
    523523               <td class="right">greenbytes</td>
    524524            </tr>
    525525            <tr>
    526526               <td class="left"></td>
    527                <td class="right">July 13, 2012</td>
     527               <td class="right">July 14, 2012</td>
    528528            </tr>
    529529         </tbody>
    … …  
    552552         in progress”.
    553553      </p>
    554       <p>This Internet-Draft will expire on January 14, 2013.</p>
     554      <p>This Internet-Draft will expire on January 15, 2013.</p>
    555555      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    556556      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    636636         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>.
    637637      </p>
    638       <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
    639          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.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
    640       </p>
    641       <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that
    642          SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
    643       </p>
    644       <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid.
    645       </p>
    646       <p id="rfc.section.1.1.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
    647          mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
    648          different error handling strategies; for example, a Web browser might wish to transparently recover from a response where
    649          the <a href="p2-semantics.html#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
    650          could lead to dangerous consequences.
     638      <p id="rfc.section.1.1.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
     639         requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
     640         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.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
     641      </p>
     642      <p id="rfc.section.1.1.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
     643         forwarding a received element downstream.
     644      </p>
     645      <p id="rfc.section.1.1.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
     646         in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
     647      </p>
     648      <p id="rfc.section.1.1.p.5">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</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
     649         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
     650         to the recipient's role.
     651      </p>
     652      <p id="rfc.section.1.1.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
     653         except when they have a direct impact on security, since different applications of the protocol require different error handling
     654         strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#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
     655         to be dangerous.
    651656      </p>
    652657      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>

  • draft-ietf-httpbis/latest/p7-auth.xml

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