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

Remove conditional compliance. Switch from compliance to conformance.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • 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
Note: See TracChangeset for help on using the changeset viewer.