Changeset 1520 for draft-ietf-httpbis/latest/p1-messaging.xml

Timestamp:

30/01/12 03:09:15 (9 years ago)

Author:

fielding@…

Message:

Remove conditional compliance. Switch from compliance to conformance.

File:

• draft-ietf-httpbis/latest/p1-messaging.xml (modified) (13 diffs)

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

@@ -589 +589 @@
    the scope of this specification.  However, an HTTP-to-HTTP gateway
    that wishes to interoperate with third-party HTTP servers &MUST;
-   comply with HTTP user agent requirements on the gateway's inbound
+   conform to HTTP user agent requirements on the gateway's inbound
    connection and &MUST; implement the Connection
    (<xref target="header.connection"/>) and Via (<xref target="header.via"/>)
@@ -710 +710 @@
    HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate
    versions of the protocol. This specification defines version "1.1".
-   The protocol version as a whole indicates the sender's compliance
+   The protocol version as a whole indicates the sender's conformance
    with the set of requirements laid out in that version's corresponding
    specification of HTTP.
@@ -726 +726 @@
    (period or decimal point).  The first digit ("major version") indicates the
    HTTP messaging syntax, whereas the second digit ("minor version") indicates
-   the highest minor version to which the sender is at least conditionally
-   compliant and able to understand for future communication.  The minor
+   the highest minor version to which the sender is
+   conformant and able to understand for future communication.  The minor
    version advertises the sender's communication capabilities even when the
    sender is only using a backwards-compatible subset of the protocol,
@@ -739 +739 @@
    as a valid HTTP/1.0 message if all of the newer features are ignored.
    This specification places recipient-version requirements on some
-   new features so that a compliant sender will only use compatible
+   new features so that a conformant sender will only use compatible
    features until it has determined, through configuration or the
    receipt of a message, that the recipient supports HTTP/1.1.
@@ -750 +750 @@
    defined for all versions of HTTP/1.x.  In particular, the Host and
    Connection header fields ought to be implemented by all HTTP/1.x
-   implementations whether or not they advertise compliance with HTTP/1.1.
+   implementations whether or not they advertise conformance with HTTP/1.1.
 </t>
 <t>
@@ -763 +763 @@
    (see <xref target="header.connection"/>).
    These requirements allow HTTP's functionality to be enhanced without
-   requiring prior update of all compliant intermediaries.
+   requiring prior update of deployed intermediaries.
 </t>
 <t>
@@ -770 +770 @@
    in forwarded messages.  In other words, they &MUST-NOT; blindly
    forward the first line of an HTTP message without ensuring that the
-   protocol version matches what the intermediary understands, and
-   is at least conditionally compliant to, for both the receiving and
+   protocol version in that message matches a version to which that
+   intermediary is conformant for both the receiving and
    sending of messages.  Forwarding an HTTP message without rewriting
    the HTTP-Version might result in communication errors when downstream
@@ -779 +779 @@
 <t>
    An HTTP client &SHOULD; send a request version equal to the highest
-   version for which the client is at least conditionally compliant and
+   version to which the client is conformant and
    whose major version is no higher than the highest version supported
    by the server, if this is known.  An HTTP client &MUST-NOT; send a
-   version for which it is not at least conditionally compliant.
+   version to which it is not conformant.
 </t>
 <t>
@@ -793 +793 @@
 <t>
    An HTTP server &SHOULD; send a response version equal to the highest
-   version for which the server is at least conditionally compliant and
+   version to which the server is conformant and
    whose major version is less than or equal to the one received in the
-   request.  An HTTP server &MUST-NOT; send a version for which it is not
-   at least conditionally compliant.  A server &MAY; send a 505 (HTTP
+   request.  An HTTP server &MUST-NOT; send a version to which it is not
+   conformant.  A server &MAY; send a 505 (HTTP
    Version Not Supported) response if it cannot send a response using the
    major version used in the client's request.
@@ -806 +806 @@
    version responses, such as when a client fails to parse the version
    number correctly or when an intermediary is known to blindly forward
-   the HTTP-Version even when it doesn't comply with the given minor
+   the HTTP-Version even when it doesn't conform to the given minor
    version of the protocol. Such protocol downgrades &SHOULD-NOT; be
    performed unless triggered by specific client attributes, such as when
@@ -2166 +2166 @@
    message is being received by an HTTP/1.1 (or later) proxy and
    forwarded to an HTTP/1.0 recipient. It avoids a situation where
-   compliance with the protocol would have necessitated a possibly
+   conformance with the protocol would have necessitated a possibly
    infinite buffer on the proxy.
 </t>
@@ -2930 +2930 @@
    within the Connection field-value, then the recipient &MUST; ignore
    the connection-specific header field because it has likely been
-   forwarded by an intermediary that is only partially compliant.
+   forwarded by an intermediary that is only partially conformant.
 </t>
 <t>
@@ -4847 +4847 @@
    those new features that will either be safely ignored by an HTTP/1.0
    recipient or only sent when communicating with a party advertising
-   compliance with HTTP/1.1.
+   conformance with HTTP/1.1.
 </t>
 <t>
    It is beyond the scope of a protocol specification to mandate
-   compliance with previous versions. HTTP/1.1 was deliberately
+   conformance with previous versions. HTTP/1.1 was deliberately
    designed, however, to make supporting previous versions easy.
    We would expect a general-purpose HTTP/1.1 server to understand