Ignore:
Timestamp:
Oct 23, 2011, 1:20:31 PM (8 years ago)
Author:
julian.reschke@…
Message:

Rephrase description of conformance; explain how the spec handles error handling (see #186)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1451 r1452  
    359359  }
    360360  @bottom-center {
    361        content: "Expires April 22, 2012";
     361       content: "Expires April 25, 2012";
    362362  }
    363363  @bottom-right {
     
    408408      <meta name="dct.creator" content="Reschke, J. F.">
    409409      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2011-10-20">
     410      <meta name="dct.issued" scheme="ISO8601" content="2011-10-23">
    411411      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    412412      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    440440            </tr>
    441441            <tr>
    442                <td class="left">Expires: April 22, 2012</td>
     442               <td class="left">Expires: April 25, 2012</td>
    443443               <td class="right">HP</td>
    444444            </tr>
     
    493493            <tr>
    494494               <td class="left"></td>
    495                <td class="right">October 20, 2011</td>
     495               <td class="right">October 23, 2011</td>
    496496            </tr>
    497497         </tbody>
     
    526526         in progress”.
    527527      </p>
    528       <p>This Internet-Draft will expire on April 22, 2012.</p>
     528      <p>This Internet-Draft will expire on April 25, 2012.</p>
    529529      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    530530      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    545545      <ul class="toc">
    546546         <li>1.&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul>
    547                <li>1.1&nbsp;&nbsp;&nbsp;<a href="#intro.requirements">Requirements</a></li>
     547               <li>1.1&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
    548548               <li>1.2&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul>
    549549                     <li>1.2.1&nbsp;&nbsp;&nbsp;<a href="#notation.abnf">ABNF Extension: #rule</a></li>
     
    751751         thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries.
    752752      </p>
    753       <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
     753      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2>
    754754      <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    755755         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>.
    756756      </p>
    757       <p id="rfc.section.1.1.p.2">An implementation is not compliant if it fails to satisfy one or more of the "MUST" or "REQUIRED" level requirements for the
    758          protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements
    759          for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not
    760          all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant".
     757      <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients,
     758         Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="#architecture" title="Architecture">Section&nbsp;2</a> for definitions of these terms.
     759      </p>
     760      <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
     761         SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
     762      </p>
     763      <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.
     764      </p>
     765      <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <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
     766         mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require
     767         different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the
     768         Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of
     769         error recovery could lead to dangerous consequences.
    761770      </p>
    762771      <div id="rfc.iref.g.1"></div>
     
    34753484      <p id="rfc.section.C.18.p.1">Closed issues: </p>
    34763485      <ul>
     3486         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/186">http://tools.ietf.org/wg/httpbis/trac/ticket/186</a>&gt;: "Document HTTP's error-handling philosophy"
     3487         </li>
    34773488         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/215">http://tools.ietf.org/wg/httpbis/trac/ticket/215</a>&gt;: "Explain header registration"
    34783489         </li>
Note: See TracChangeset for help on using the changeset viewer.