Changeset 2471

Timestamp:

Nov 4, 2013, 3:28:11 PM (6 years ago)

Author:

fielding@…

Message:

reduce two MUSTs to a clarified ought; addresses #502

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (1 diff)
• p1-messaging.xml (modified) (1 diff)

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

@@ -2131 +2131 @@
             <p id="rfc.section.6.1.p.7">A sender <em class="bcp14">MUST NOT</em> send a connection option corresponding to a header field that is intended for all recipients of the payload. For example, <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a> is never appropriate as a connection option (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
             </p>
-            <p id="rfc.section.6.1.p.8">The connection options do not have to correspond to a header field present in the message, since a connection-specific header
-               field might not be needed if there are no parameters associated with that connection option. Recipients that trigger certain
-               connection behavior based on the presence of connection options <em class="bcp14">MUST</em> do so based on the presence of the connection-option rather than only the presence of the optional header field. In other
-               words, 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
-               conformant.
-            </p>
-            <p id="rfc.section.6.1.p.9">When defining new connection options, specifications ought to carefully consider existing deployed header fields and ensure
-               that the new connection option does not share the same name as an unrelated header field that might already be deployed. Defining
-               a new connection option essentially reserves that potential field-name for carrying additional information related to the
-               connection option, since it would be unwise for senders to use that field-name for anything else.
+            <p id="rfc.section.6.1.p.8">The connection options do not always correspond to a header field present in the message, since a connection-specific header
+               field might not be needed if there are no parameters associated with a connection option. In contrast, a connection-specific
+               header field that is received without a corresponding connection option usually indicates that the field has been improperly
+               forwarded by an intermediary and ought to be ignored by the recipient.
+            </p>
+            <p id="rfc.section.6.1.p.9">When defining new connection options, specification authors ought to survey existing header field names and ensure that the
+               new connection option does not share the same name as an already deployed header field. Defining a new connection option essentially
+               reserves that potential field-name for carrying additional information related to the connection option, since it would be
+               unwise for senders to use that field-name for anything else.
             </p>
             <p id="rfc.section.6.1.p.10">The "<dfn>close</dfn>" connection option is defined for a sender to signal that this connection will be closed after completion of the response.

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

@@ -2881 +2881 @@
 </t>
 <t>
-   The connection options do not have to correspond to a header field
+   The connection options do not always correspond to a header field
    present in the message, since a connection-specific header field
-   might not be needed if there are no parameters associated with that
-   connection option.  Recipients that trigger certain connection
-   behavior based on the presence of connection options &MUST; do so
-   based on the presence of the connection-option rather than only the
-   presence of the optional header field.  In other words, if the
-   connection option is received as a header field but not indicated
-   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 conformant.
-</t>
-<t>
-   When defining new connection options, specifications ought to
-   carefully consider existing deployed header fields and ensure
-   that the new connection option does not share the same name as
-   an unrelated header field that might already be deployed.
+   might not be needed if there are no parameters associated with a
+   connection option. In contrast, a connection-specific header field that
+   is received without a corresponding connection option usually indicates
+   that the field has been improperly forwarded by an intermediary and
+   ought to be ignored by the recipient.
+</t>
+<t>
+   When defining new connection options, specification authors ought to survey
+   existing header field names and ensure that the new connection option does
+   not share the same name as an already deployed header field.
    Defining a new connection option essentially reserves that potential
    field-name for carrying additional information related to the