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

Make ABNF/conformance terminology consistent (see #362)

File:
1 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
Note: See TracChangeset for help on using the changeset viewer.