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

Timestamp:

Sep 9, 2012, 7:46:17 PM (7 years ago)

Author:

fielding@…

Message:

Be more consistent regarding targeting conformance requirements.
Only define conformance criteria once, but repeat required nits.

Remove antiquated requirement about media type parameters not being
recognized by 1993-era browsers.

Add reference to TLS in p1.

File:

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

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

@@ -478 +478 @@
    are minimal, such as for proxy requests for "http" URIs, whereas
    other requests might require translation to and from entirely different
-   application-layer protocols. Proxies are often used to group an
+   application-level protocols. Proxies are often used to group an
    organization's HTTP requests through a common intermediary for the
    sake of security, annotation services, or shared caching.
@@ -533 +533 @@
    both ends of the relayed connection are closed. Tunnels are used to
    extend a virtual connection through an intermediary, such as when
-   transport-layer security is used to establish confidential communication
-   through a shared firewall proxy.
+   Transport Layer Security (TLS, <xref target="RFC5246"/>) is used to
+   establish confidential communication through a shared firewall proxy.
 </t>
 <t><iref primary="true" item="interception proxy"/>
@@ -617 +617 @@
    on senders, recipients, clients, servers, user agents, intermediaries,
    origin servers, proxies, gateways, or caches, depending on what behavior
-   is being constrained by the requirement.
+   is being constrained by the requirement. Additional (social) requirements
+   are placed on implementations, resource owners, and protocol element
+   registrations when they apply beyond the scope of a single communication.
 </t>
 <t>
@@ -1049 +1051 @@
 </artwork></figure>
 <t>
-   Implementations &MUST-NOT; send whitespace between the start-line and
+   A sender &MUST-NOT; send whitespace between the start-line and
    the first header field. The presence of such whitespace in a request
    might be an attempt to trick a server into ignoring that field or
@@ -1709 +1711 @@
    Since there is no way to distinguish a successfully completed,
    close-delimited message from a partially-received message interrupted
-   by network failure, implementations &SHOULD; use encoding or
+   by network failure, a server &SHOULD; use encoding or
    length-delimited messages whenever possible.  The close-delimiting
    feature exists primarily for backwards compatibility with HTTP/1.0.
@@ -3097 +3099 @@
    Upgrade cannot be used to insist on a protocol change; its acceptance and
    use by the server is optional. The capabilities and nature of the
-   application-layer communication after the protocol change is entirely
+   application-level communication after the protocol change is entirely
    dependent upon the new protocol chosen, although the first action
    after changing the protocol &MUST; be a response to the initial HTTP
@@ -3122 +3124 @@
 </t>
 <t>
-   The Upgrade header field only applies to switching application-layer
-   protocols on the existing transport-layer connection; it cannot be used
+   The Upgrade header field only applies to switching application-level
+   protocols on the existing connection; it cannot be used
    to switch to a protocol on a different connection. For that purpose, it is
    more appropriate to use a <x:ref>3xx (Redirection)</x:ref> response
@@ -3582 +3584 @@
 <section title="Attacks Based On File and Path Names" anchor="attack.pathname">
 <t>
-   Implementations of HTTP origin servers &SHOULD; be careful to restrict
+   Origin servers &SHOULD; be careful to restrict
    the documents returned by HTTP requests to be only those that were
    intended by the server administrators. If an HTTP server translates
@@ -3596 +3598 @@
    files, configuration files, and script code) &MUST; be protected from
    inappropriate retrieval, since they might contain sensitive
-   information. Experience has shown that minor bugs in such HTTP server
-   implementations have turned into security risks.
+   information.
 </t>
 </section>
@@ -3661 +3662 @@
 </t>
 <t>
-   Other fields (including but not limited to request methods, response status
-   phrases, header field-names, and body chunks) &SHOULD; be limited by
-   implementations carefully, so as to not impede interoperability.
+   Recipients &SHOULD; carefully limit the extent to which they read other
+   fields, including (but not limited to) request methods, response status
+   phrases, header field-names, and body chunks, so as to avoid denial of
+   service attacks without impeding interoperability.
 </t>
 </section>
@@ -4557 +4559 @@
 </reference>
 
+<reference anchor='RFC5246'>
+   <front>
+      <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
+      <author initials='T.' surname='Dierks' fullname='T. Dierks'>
+         <organization />
+      </author>
+      <author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
+         <organization>RTFM, Inc.</organization>
+      </author>
+      <date year='2008' month='August' />
+   </front>
+   <seriesInfo name='RFC' value='5246' />
+</reference>
+
 <reference anchor="RFC5322">
   <front>