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

Timestamp:

18/01/14 05:06:05 (9 years ago)

Author:

fielding@…

Message:

(editorial) define WWW where World Wide Web first appears and remove redundant bits from the abstract and history; see #531 and [2555]

File:

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

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

@@ -113 +113 @@
 <abstract>
 <t>
-   The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for
-   distributed, collaborative, hypertext information systems. HTTP has been in
-   use by the World Wide Web global information initiative since 1990.
+   The Hypertext Transfer Protocol (HTTP) is a stateless application-level
+   protocol for distributed, collaborative, hypertext information systems.
    This document provides an overview of HTTP architecture and its associated
    terminology, defines the "http" and "https" Uniform Resource Identifier
-   (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements,
-   and describes general security concerns for implementations.
+   (URI) schemes, defines the HTTP/1.1 message syntax and parsing
+   requirements, and describes related security concerns for implementations.
 </t>   
 </abstract>
@@ -144 +143 @@
 <t>
    The Hypertext Transfer Protocol (HTTP) is a stateless application-level
-   request/response protocol that uses extensible semantics and self-descriptive
-   message payloads for flexible interaction with network-based hypertext
-   information systems. This document is the first in a series of documents
-   that collectively form the HTTP/1.1 specification:
+   request/response protocol that uses extensible semantics and
+   self-descriptive message payloads for flexible interaction with
+   network-based hypertext information systems. This document is the first in
+   a series of documents that collectively form the HTTP/1.1 specification:
    <list style="empty">
     <t>RFC xxx1: Message Syntax and Routing</t>
@@ -273 +272 @@
 <section title="Architecture" anchor="architecture">
 <t>
-   HTTP was created for the World Wide Web architecture
+   HTTP was created for the World Wide Web (WWW) architecture
    and has evolved over time to support the scalability needs of a worldwide
    hypertext system. Much of that architecture is reflected in the terminology
@@ -5030 +5029 @@
 <section title="HTTP Version History" anchor="compatibility">
 <t>
-   HTTP has been in use by the World-Wide Web (WWW) global information initiative
-   since 1990. The first version of HTTP, later referred to as HTTP/0.9,
-   was a simple protocol for hypertext data transfer across the Internet
-   with only a single request method (GET) and no metadata.
+   HTTP has been in use since 1990. The first version, later referred to as
+   HTTP/0.9, was a simple protocol for hypertext data transfer across the
+   Internet, using only a single request method (GET) and no metadata.
    HTTP/1.0, as defined by <xref target="RFC1945"/>, added a range of request
-   methods and MIME-like messaging that could include metadata about the data
-   transferred and modifiers on the request/response semantics. However,
+   methods and MIME-like messaging, allowing for metadata to be transferred
+   and modifiers placed on the request/response semantics. However,
    HTTP/1.0 did not sufficiently take into consideration the effects of
    hierarchical proxies, caching, the need for persistent connections, or
@@ -5047 +5045 @@
    HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
    requirements that enable reliable implementations, adding only
-   those new features that will either be safely ignored by an HTTP/1.0
+   those features that can either be safely ignored by an HTTP/1.0
    recipient or only sent when communicating with a party advertising
    conformance with HTTP/1.1.
 </t>
 <t>
-   It is beyond the scope of a protocol specification to mandate
-   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
-   any valid request in the format of HTTP/1.0 and respond appropriately
-   with an HTTP/1.1 message that only uses features understood (or
-   safely ignored) by HTTP/1.0 clients.  Likewise, we would expect
-   an HTTP/1.1 client to understand any valid HTTP/1.0 response.
-</t>
-<t>
-   Since HTTP/0.9 did not support header fields in a request,
-   there is no mechanism for it to support name-based virtual
-   hosts (selection of resource by inspection of the <x:ref>Host</x:ref> header
-   field).  Any server that implements name-based virtual hosts
-   ought to disable support for HTTP/0.9.  Most requests that
-   appear to be HTTP/0.9 are, in fact, badly constructed HTTP/1.x
-   requests wherein a buggy client failed to properly encode
-   linear whitespace found in a URI reference and placed in
-   the request-target.
+   HTTP/1.1 has been designed to make supporting previous versions easy.
+   A general-purpose HTTP/1.1 server ought to be able to understand any valid
+   request in the format of HTTP/1.0, responding appropriately with an
+   HTTP/1.1 message that only uses features understood (or safely ignored) by
+   HTTP/1.0 clients. Likewise, an HTTP/1.1 client can be expected to
+   understand any valid HTTP/1.0 response.
+</t>
+<t>
+   Since HTTP/0.9 did not support header fields in a request, there is no
+   mechanism for it to support name-based virtual hosts (selection of resource
+   by inspection of the <x:ref>Host</x:ref> header field).
+   Any server that implements name-based virtual hosts ought to disable
+   support for HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in
+   fact, badly constructed HTTP/1.x requests caused by a client failing to
+   properly encode the request-target.
 </t>