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

Timestamp:

31/07/10 01:06:01 (12 years ago)

Author:

fielding@…

Message:

Replace lowercase should with less normative words, where possible.

File:

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

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

@@ -263 +263 @@
    of received communication, and the expected behavior of recipients.
    If the communication is considered in isolation, then successful
-   actions should be reflected in corresponding changes to the
+   actions ought to be reflected in corresponding changes to the
    observable interface provided by servers. However, since multiple
    clients might act in parallel and perhaps at cross-purposes, we
@@ -1107 +1107 @@
    empty line received where a Request-Line is expected. In other words, if
    the server is reading the protocol stream at the beginning of a
-   message and receives a CRLF first, it should ignore the CRLF.
+   message and receives a CRLF first, it &SHOULD; ignore the CRLF.
 </t>
 <t>
@@ -1333 +1333 @@
      Such a message might indicate an attempt to perform request or response
      smuggling (bypass of security-related checks on message routing or content)
-     and thus should be handled as an error.  The provided Content-Length &MUST;
+     and thus ought to be handled as an error.  The provided Content-Length &MUST;
      be removed, prior to forwarding the message downstream, or replaced with
      the real message-body length after the transfer-coding is decoded.
@@ -1603 +1603 @@
     meaning of the request when the origin server is improperly using
     a non-reserved URI character for a reserved purpose.  Implementors
-    should be aware that some pre-HTTP/1.1 proxies have been known to
+    need to be aware that some pre-HTTP/1.1 proxies have been known to
     rewrite the request-target.
   </t>
@@ -3311 +3311 @@
    The HTTP Upgrade Token Registry defines the name space for product
    tokens used to identify protocols in the Upgrade header field.
-   Each registered token should be associated with one or a set of
-   specifications, and with contact information.
-</t>
-<t>
-   Registrations should be allowed on a First Come First Served basis as
-   described in <xref target="RFC5226" x:sec="4.1" x:fmt="of"/>. These
-   specifications need not be IETF documents or be subject to IESG review, but
-   should obey the following rules:
+   Each registered token is associated with contact information and
+   an optional set of specifications that details how the connection
+   will be processed after it has been upgraded.
+</t>
+<t>
+   Registrations are allowed on a First Come First Served basis as
+   described in <xref target="RFC5226" x:sec="4.1" x:fmt="of"/>. The
+   specifications need not be IETF documents or be subject to IESG review.
+   Registrations are subject to the following rules:
   <list style="numbers">
     <t>A token, once registered, stays registered forever.</t>
@@ -3324 +3325 @@
        registration.</t>
     <t>The registration &MUST; name a point of contact.</t>
-    <t>The registration &MAY; name the documentation required for the
-       token.</t>
+    <t>The registration &MAY; name a set of specifications associated with that
+       token. Such specifications need not be publicly available.</t>
     <t>The responsible party &MAY; change the registration at any time.
        The IANA will keep a record of all such changes, and make them
@@ -3337 +3338 @@
   </list>
 </t>
-<t>
-   It is not required that specifications for upgrade tokens be made
-   publicly available, but the contact information for the registration
-   should be.
-</t>
 </section>
 
@@ -3453 +3449 @@
 <section title="Header Field Registration" anchor="header.field.registration">
 <t>
-   The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> should be updated
+   The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated
    with the permanent registrations below (see <xref target="RFC3864"/>):
 </t>
@@ -3530 +3526 @@
    The entries for the "http" and "https" URI Schemes in the registry located at
    <eref target="http://www.iana.org/assignments/uri-schemes.html"/>
-   should be updated to point to Sections <xref target="http.uri" format="counter"/>
+   shall be updated to point to Sections <xref target="http.uri" format="counter"/>
    and <xref target="https.uri" format="counter"/> of this document
    (see <xref target="RFC4395"/>).
@@ -3693 +3689 @@
 <t>
    The HTTP Transfer Codings Registry located at <eref target="http://www.iana.org/assignments/http-parameters"/>
-   should be updated with the registrations below:
+   shall be updated with the registrations below:
 </t>
 <texttable align="left" suppress-title="true" anchor="iana.transfer.coding.registration.table">
@@ -3732 +3728 @@
 <t>
    The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-upgrade-tokens/"/>
-   should be updated with the registration below:
+   shall be updated with the registration below:
 </t>
 <texttable align="left" suppress-title="true">
@@ -3860 +3856 @@
 </t>
 <t>
-   Proxy operators should protect the systems on which proxies run as
+   Proxy operators need to protect the systems on which proxies run as
    they would protect any system that contains or transports sensitive
    information. In particular, log information gathered at proxies often
    contains highly sensitive personal information, and/or information
-   about organizations. Log information should be carefully guarded, and
-   appropriate guidelines for use should be developed and followed.
+   about organizations. Log information needs to be carefully guarded, and
+   appropriate guidelines for use need to be developed and followed.
    (<xref target="abuse.of.server.log.information"/>).
 </t>
 <t>
-   Proxy implementors should consider the privacy and security
+   Proxy implementors need to consider the privacy and security
    implications of their design and coding decisions, and of the
    configuration options they provide to proxy operators (especially the