Ignore:
Timestamp:
Jan 29, 2012, 7:09:15 PM (8 years ago)
Author:
fielding@…
Message:

Remove conditional compliance. Switch from compliance to conformance.

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

Legend:

Unmodified
Added
Removed

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

    r1519 r1520  
    892892         applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound
    893893         servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification.
    894          However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> comply with HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;8.8</a>) header fields for both connections.
     894         However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> conform to HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;8.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;8.8</a>) header fields for both connections.
    895895      </p>
    896896      <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party
    … …  
    951951      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="http.version" href="#http.version">Protocol Versioning</a></h2>
    952952      <p id="rfc.section.2.6.p.1">HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions of the protocol. This specification defines version "1.1".
    953          The protocol version as a whole indicates the sender's compliance with the set of requirements laid out in that version's
     953         The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's
    954954         corresponding specification of HTTP.
    955955      </p>
    … …  
    959959</pre><p id="rfc.section.2.6.p.4">The HTTP version number consists of two decimal digits separated by a "." (period or decimal point). The first digit ("major
    960960         version") indicates the HTTP messaging syntax, whereas the second digit ("minor version") indicates the highest minor version
    961          to which the sender is at least conditionally compliant and able to understand for future communication. The minor version
    962          advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the
    963          protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future
    964          requests (by clients).
     961         to which the sender is conformant and able to understand for future communication. The minor version advertises the sender's
     962         communication capabilities even when the sender is only using a backwards-compatible subset of the protocol, thereby letting
     963         the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients).
    965964      </p>
    966965      <p id="rfc.section.2.6.p.5">When an HTTP/1.1 message is sent to an HTTP/1.0 recipient <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> or a recipient whose version is unknown, the HTTP/1.1 message is constructed such that it can be interpreted as a valid HTTP/1.0
    967966         message if all of the newer features are ignored. This specification places recipient-version requirements on some new features
    968          so that a compliant sender will only use compatible features until it has determined, through configuration or the receipt
     967         so that a conformant sender will only use compatible features until it has determined, through configuration or the receipt
    969968         of a message, that the recipient supports HTTP/1.1.
    970969      </p>
    … …  
    972971         behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1
    973972         are defined for all versions of HTTP/1.x. In particular, the Host and Connection header fields ought to be implemented by
    974          all HTTP/1.x implementations whether or not they advertise compliance with HTTP/1.1.
     973         all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1.
    975974      </p>
    976975      <p id="rfc.section.2.6.p.7">New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation
    977976         of previously defined header fields. When an implementation receives an unrecognized header field, the recipient <em class="bcp14">MUST</em> ignore that header field for local processing regardless of the message's HTTP version. An unrecognized header field received
    978          by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;8.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries.
    979       </p>
    980       <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version matches what the intermediary
    981          understands, and is at least conditionally compliant to, for both the receiving and sending of messages. Forwarding an HTTP
    982          message without rewriting the HTTP-Version might result in communication errors when downstream recipients use the message
    983          sender's version to determine what features are safe to use for later communication with that sender.
    984       </p>
    985       <p id="rfc.section.2.6.p.9">An HTTP client <em class="bcp14">SHOULD</em> send a request version equal to the highest version for which the client is at least conditionally compliant and whose major
    986          version is no higher than the highest version supported by the server, if this is known. An HTTP client <em class="bcp14">MUST NOT</em> send a version for which it is not at least conditionally compliant.
     977         by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;8.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries.
     978      </p>
     979      <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version in that message matches a version
     980         to which that intermediary is conformant for both the receiving and sending of messages. Forwarding an HTTP message without
     981         rewriting the HTTP-Version might result in communication errors when downstream recipients use the message sender's version
     982         to determine what features are safe to use for later communication with that sender.
     983      </p>
     984      <p id="rfc.section.2.6.p.9">An HTTP client <em class="bcp14">SHOULD</em> send a request version equal to the highest version to which the client is conformant and whose major version is no higher
     985         than the highest version supported by the server, if this is known. An HTTP client <em class="bcp14">MUST NOT</em> send a version to which it is not conformant.
    987986      </p>
    988987      <p id="rfc.section.2.6.p.10">An HTTP client <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after
    … …  
    990989         that the server improperly handles higher request versions.
    991990      </p>
    992       <p id="rfc.section.2.6.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version for which the server is at least conditionally compliant and whose major
    993          version is less than or equal to the one received in the request. An HTTP server <em class="bcp14">MUST NOT</em> send a version for which it is not at least conditionally compliant. A server <em class="bcp14">MAY</em> send a 505 (HTTP Version Not Supported) response if it cannot send a response using the major version used in the client's
     991      <p id="rfc.section.2.6.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant and whose major version is less than
     992         or equal to the one received in the request. An HTTP server <em class="bcp14">MUST NOT</em> send a version to which it is not conformant. A server <em class="bcp14">MAY</em> send a 505 (HTTP Version Not Supported) response if it cannot send a response using the major version used in the client's
    994993         request.
    995994      </p>
    996995      <p id="rfc.section.2.6.p.12">An HTTP server <em class="bcp14">MAY</em> send an HTTP/1.0 response to an HTTP/1.0 request if it is known or suspected that the client incorrectly implements the HTTP
    997996         specification and is incapable of correctly processing later version responses, such as when a client fails to parse the version
    998          number correctly or when an intermediary is known to blindly forward the HTTP-Version even when it doesn't comply with the
     997         number correctly or when an intermediary is known to blindly forward the HTTP-Version even when it doesn't conform to the
    999998         given minor version of the protocol. Such protocol downgrades <em class="bcp14">SHOULD NOT</em> be performed unless triggered by specific client attributes, such as when one or more of the request header fields (e.g.,
    1000999         User-Agent) uniquely match the values sent by a client known to be in error.
    … …  
    16591658      </ol>
    16601659      <p id="rfc.section.5.1.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and
    1661          forwarded to an HTTP/1.0 recipient. It avoids a situation where compliance with the protocol would have necessitated a possibly
     1660         forwarded to an HTTP/1.0 recipient. It avoids a situation where conformance with the protocol would have necessitated a possibly
    16621661         infinite buffer on the proxy.
    16631662      </p>
    … …  
    20612060         connection behavior based on the presence of connection options <em class="bcp14">MUST</em> do so based on the presence of the connection-token rather than only the presence of the optional header field. In other words,
    20622061         if the connection option is received as a header field but not indicated within the Connection field-value, then the recipient <em class="bcp14">MUST</em> ignore the connection-specific header field because it has likely been forwarded by an intermediary that is only partially
    2063          compliant.
     2062         conformant.
    20642063      </p>
    20652064      <p id="rfc.section.8.1.p.7">When defining new connection options, specifications ought to carefully consider existing deployed header fields and ensure
    … …  
    29052904      <p id="rfc.section.A.p.2">HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent requirements that enable reliable implementations, adding
    29062905         only those new features that will either be safely ignored by an HTTP/1.0 recipient or only sent when communicating with a
    2907          party advertising compliance with HTTP/1.1.
    2908       </p>
    2909       <p id="rfc.section.A.p.3">It is beyond the scope of a protocol specification to mandate compliance with previous versions. HTTP/1.1 was deliberately
     2906         party advertising conformance with HTTP/1.1.
     2907      </p>
     2908      <p id="rfc.section.A.p.3">It is beyond the scope of a protocol specification to mandate conformance with previous versions. HTTP/1.1 was deliberately
    29102909         designed, however, to make supporting previous versions easy. We would expect a general-purpose HTTP/1.1 server to understand
    29112910         any valid request in the format of HTTP/1.0 and respond appropriately with an HTTP/1.1 message that only uses features understood

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

    r1518 r1520  
    589589   the scope of this specification.  However, an HTTP-to-HTTP gateway
    590590   that wishes to interoperate with third-party HTTP servers &MUST;
    591    comply with HTTP user agent requirements on the gateway's inbound
     591   conform to HTTP user agent requirements on the gateway's inbound
    592592   connection and &MUST; implement the Connection
    593593   (<xref target="header.connection"/>) and Via (<xref target="header.via"/>)
    … …  
    710710   HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate
    711711   versions of the protocol. This specification defines version "1.1".
    712    The protocol version as a whole indicates the sender's compliance
     712   The protocol version as a whole indicates the sender's conformance
    713713   with the set of requirements laid out in that version's corresponding
    714714   specification of HTTP.
    … …  
    726726   (period or decimal point).  The first digit ("major version") indicates the
    727727   HTTP messaging syntax, whereas the second digit ("minor version") indicates
    728    the highest minor version to which the sender is at least conditionally
    729    compliant and able to understand for future communication.  The minor
     728   the highest minor version to which the sender is
     729   conformant and able to understand for future communication.  The minor
    730730   version advertises the sender's communication capabilities even when the
    731731   sender is only using a backwards-compatible subset of the protocol,
    … …  
    739739   as a valid HTTP/1.0 message if all of the newer features are ignored.
    740740   This specification places recipient-version requirements on some
    741    new features so that a compliant sender will only use compatible
     741   new features so that a conformant sender will only use compatible
    742742   features until it has determined, through configuration or the
    743743   receipt of a message, that the recipient supports HTTP/1.1.
    … …  
    750750   defined for all versions of HTTP/1.x.  In particular, the Host and
    751751   Connection header fields ought to be implemented by all HTTP/1.x
    752    implementations whether or not they advertise compliance with HTTP/1.1.
     752   implementations whether or not they advertise conformance with HTTP/1.1.
    753753</t>
    754754<t>
    … …  
    763763   (see <xref target="header.connection"/>).
    764764   These requirements allow HTTP's functionality to be enhanced without
    765    requiring prior update of all compliant intermediaries.
     765   requiring prior update of deployed intermediaries.
    766766</t>
    767767<t>
    … …  
    770770   in forwarded messages.  In other words, they &MUST-NOT; blindly
    771771   forward the first line of an HTTP message without ensuring that the
    772    protocol version matches what the intermediary understands, and
    773    is at least conditionally compliant to, for both the receiving and
     772   protocol version in that message matches a version to which that
     773   intermediary is conformant for both the receiving and
    774774   sending of messages.  Forwarding an HTTP message without rewriting
    775775   the HTTP-Version might result in communication errors when downstream
    … …  
    779779<t>
    780780   An HTTP client &SHOULD; send a request version equal to the highest
    781    version for which the client is at least conditionally compliant and
     781   version to which the client is conformant and
    782782   whose major version is no higher than the highest version supported
    783783   by the server, if this is known.  An HTTP client &MUST-NOT; send a
    784    version for which it is not at least conditionally compliant.
     784   version to which it is not conformant.
    785785</t>
    786786<t>
    … …  
    793793<t>
    794794   An HTTP server &SHOULD; send a response version equal to the highest
    795    version for which the server is at least conditionally compliant and
     795   version to which the server is conformant and
    796796   whose major version is less than or equal to the one received in the
    797    request.  An HTTP server &MUST-NOT; send a version for which it is not
    798    at least conditionally compliant.  A server &MAY; send a 505 (HTTP
     797   request.  An HTTP server &MUST-NOT; send a version to which it is not
     798   conformant.  A server &MAY; send a 505 (HTTP
    799799   Version Not Supported) response if it cannot send a response using the
    800800   major version used in the client's request.
    … …  
    806806   version responses, such as when a client fails to parse the version
    807807   number correctly or when an intermediary is known to blindly forward
    808    the HTTP-Version even when it doesn't comply with the given minor
     808   the HTTP-Version even when it doesn't conform to the given minor
    809809   version of the protocol. Such protocol downgrades &SHOULD-NOT; be
    810810   performed unless triggered by specific client attributes, such as when
    … …  
    21662166   message is being received by an HTTP/1.1 (or later) proxy and
    21672167   forwarded to an HTTP/1.0 recipient. It avoids a situation where
    2168    compliance with the protocol would have necessitated a possibly
     2168   conformance with the protocol would have necessitated a possibly
    21692169   infinite buffer on the proxy.
    21702170</t>
    … …  
    29302930   within the Connection field-value, then the recipient &MUST; ignore
    29312931   the connection-specific header field because it has likely been
    2932    forwarded by an intermediary that is only partially compliant.
     2932   forwarded by an intermediary that is only partially conformant.
    29332933</t>
    29342934<t>
    … …  
    48474847   those new features that will either be safely ignored by an HTTP/1.0
    48484848   recipient or only sent when communicating with a party advertising
    4849    compliance with HTTP/1.1.
     4849   conformance with HTTP/1.1.
    48504850</t>
    48514851<t>
    48524852   It is beyond the scope of a protocol specification to mandate
    4853    compliance with previous versions. HTTP/1.1 was deliberately
     4853   conformance with previous versions. HTTP/1.1 was deliberately
    48544854   designed, however, to make supporting previous versions easy.
    48554855   We would expect a general-purpose HTTP/1.1 server to understand

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

    r1519 r1520  
    14081408         to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful
    14091409         as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server.
    1410          For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof).
     1410         For example, this can be used to test a proxy for HTTP/1.1 conformance (or lack thereof).
    14111411      </p>
    14121412      <p id="rfc.section.6.2.p.5">If the request-target is not an asterisk, the OPTIONS request applies only to the options that are available when communicating
    … …  
    17841784            (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3.4">Section 10.3.4</a>). As user agents did not change their behavior to maintain backwards compatibility, the first revision of HTTP/1.1 added
    17851785            yet another status code, 307 (Temporary Redirect), for which the backwards compatibility problems did not apply (<a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-10.3.8">Section 10.3.8</a>). Over 10 years later, most user agents still do method rewriting for status codes 301 and 302, therefore this specification
    1786             makes that behavior compliant in case the original request was POST.
     1786            makes that behavior conformant in case the original request was POST.
    17871787         </p>
    17881788      </div>

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

    r1518 r1520  
    945945   type of method; it does nothing beyond allowing the client to test
    946946   the capabilities of the server. For example, this can be used to test
    947    a proxy for HTTP/1.1 compliance (or lack thereof).
     947   a proxy for HTTP/1.1 conformance (or lack thereof).
    948948</t>
    949949<t>
    … …  
    17021702    Over 10 years later, most user agents still do method rewriting for
    17031703    status codes 301 and 302, therefore this specification makes that behavior
    1704     compliant in case the original request was POST.
     1704    conformant in case the original request was POST.
    17051705  </t>
    17061706</x:note>

  • draft-ietf-httpbis/latest/p3-payload.html

    r1519 r1520  
    16871687      <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a id="mime-version" href="#mime-version">MIME-Version</a></h2>
    16881688      <p id="rfc.section.A.1.p.1">HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages <em class="bcp14">MAY</em> include a single MIME-Version header field to indicate what version of the MIME protocol was used to construct the message.
    1689          Use of the MIME-Version header field indicates that the message is in full compliance with the MIME protocol (as defined in <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>). Proxies/gateways are responsible for ensuring full compliance (where possible) when exporting HTTP messages to strict MIME
    1690          environments.
     1689         Use of the MIME-Version header field indicates that the message is in full conformance with the MIME protocol (as defined
     1690         in <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>). Proxies/gateways are responsible for ensuring full conformance (where possible) when exporting HTTP messages to strict
     1691         MIME environments.
    16911692      </p>
    16921693      <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.24"></span>  <a href="#mime-version" class="smpl">MIME-Version</a> = 1*<a href="#notation" class="smpl">DIGIT</a> "." 1*<a href="#notation" class="smpl">DIGIT</a>

  • draft-ietf-httpbis/latest/p3-payload.xml

    r1518 r1520  
    23892389   version of the MIME protocol was used to construct the message. Use
    23902390   of the MIME-Version header field indicates that the message is in
    2391    full compliance with the MIME protocol (as defined in <xref target="RFC2045"/>).
    2392    Proxies/gateways are responsible for ensuring full compliance (where
     2391   full conformance with the MIME protocol (as defined in <xref target="RFC2045"/>).
     2392   Proxies/gateways are responsible for ensuring full conformance (where
    23932393   possible) when exporting HTTP messages to strict MIME environments.
    23942394</t>
Note: See TracChangeset for help on using the changeset viewer.