Changeset 373

Timestamp:

Nov 13, 2008, 1:26:18 PM (11 years ago)

Author:

fielding@…

Message:

change tactics -- define HTTP architecture instead of when to use HTTP

Location:

draft-ietf-httpbis/latest-roy

Files:

• p1-messaging.html (modified) (5 diffs)
• p1-messaging.xml (modified) (3 diffs)

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

@@ -365 +365 @@
       <link rel="Index" href="#rfc.index">
       <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
-      <link rel="Chapter" title="2 When to use HTTP" href="#rfc.section.2">
+      <link rel="Chapter" title="2 HTTP architecture" href="#rfc.section.2">
       <link rel="Chapter" title="3 Protocol Parameters" href="#rfc.section.3">
       <link rel="Chapter" title="4 HTTP Message" href="#rfc.section.4">
@@ -477 +477 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">November 12, 2008</td>
+            <td class="header right">November 13, 2008</td>
          </tr>
       </table>
@@ -529 +529 @@
             </ul>
          </li>
-         <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#when">When to use HTTP</a><ul class="toc">
+         <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#architecture">HTTP architecture</a><ul class="toc">
                <li class="tocline1">2.1&nbsp;&nbsp;&nbsp;<a href="#uri">Uniform Resource Identifiers</a><ul class="toc">
                      <li class="tocline1">2.1.1&nbsp;&nbsp;&nbsp;<a href="#http.uri">http URI scheme</a></li>
@@ -669 +669 @@
       <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
       <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and
-         MIME-like message payloads for flexible interaction with network-based hypermedia information systems. HTTP relies upon the
-         Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate resource targets for interaction and to identify other resources. Messages are passed in a format similar to that
-         used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages).
-      </p>
-      <p id="rfc.section.1.p.2">HTTP is also designed for use as a generic protocol for translating communication to and from other Internet information systems,
+         MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the
+         Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate resource targets and relationships between resources. Messages are passed in a format similar to that used by
+         Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages).
+      </p>
+      <p id="rfc.section.1.p.2">HTTP is a generic interface protocol for informations systems. It is designed to hide the details of how a service is implemented
+         by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do
+         not need to be aware of each client's purpose: an HTTP request can be considered in isolation rather than being associated
+         with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used
+         effectively in many different contexts and for which implementations can evolve independently over time.
+      </p>
+      <p id="rfc.section.1.p.3">HTTP is also designed for use as a generic protocol for translating communication to and from other Internet information systems,
          such as USENET news services via NNTP <a href="#RFC3977" id="rfc.xref.RFC3977.1"><cite title="Network News Transfer Protocol (NNTP)">[RFC3977]</cite></a>, file services via FTP <a href="#RFC959" id="rfc.xref.RFC959.1"><cite title="File Transfer Protocol">[RFC959]</cite></a>, Gopher <a href="#RFC1436" id="rfc.xref.RFC1436.1"><cite title="The Internet Gopher Protocol (a distributed document search and retrieval protocol)">[RFC1436]</cite></a>, and WAIS <a href="#WAIS" id="rfc.xref.WAIS.1"><cite title="WAIS Interface Protocol Prototype Functional Specification (v1.5)">[WAIS]</cite></a>. HTTP proxies and gateways provide access to alternative information services by translating their diverse protocols into
          a hypermedia format that can be viewed and manipulated by clients in the same way as HTTP services.
       </p>
-      <p id="rfc.section.1.p.3">This document is Part 1 of the seven-part specification of HTTP, defining the protocol referred to as "HTTP/1.1" and obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. Part 1 defines how clients determine when to use HTTP, the URI schemes specific to HTTP-based resources, overall network
-         operation with transport protocol connection management, and HTTP message framing. Our goal is to define all of the mechanisms
-         necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements
-         for an HTTP message relay or generic message parser.
+      <p id="rfc.section.1.p.4">One consequence of HTTP flexibility is that we cannot define the protocol in terms of how to implement it behind the interface.
+         Instead, we are limited to restricting the syntax of communication, defining the intent of received communication, and the
+         expected behavior of recipients. If the communication is considered in isolation, then successful actions should be reflected
+         in the observable interface provided by servers. However, since many clients are potentially acting in parallel and perhaps
+         at cross-purposes, it would be meaningless to require that such behavior be observable.
+      </p>
+      <p id="rfc.section.1.p.5">This document is Part 1 of the seven-part specification of HTTP, defining the protocol referred to as "HTTP/1.1" and obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. Part 1 defines the URI schemes specific to HTTP-based resources, overall network operation, transport protocol connection
+         management, and HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for
+         HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for a message
+         parser and transparent message-forwarding intermediaries.
       </p>
       <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
@@ -797 +809 @@
   <a href="#abnf.dependencies" class="smpl">Pragma</a>          = &lt;Pragma, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a>&gt;
   <a href="#abnf.dependencies" class="smpl">Warning</a>         = &lt;Warning, defined in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 16.6</a>&gt;
-</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="when" href="#when">When to use HTTP</a></h1>
-      <p id="rfc.section.2.p.1">HTTP is a generic interface protocol for informations systems. It is designed to hide the details of how a service is implemented
-         by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do
-         not need to be aware of the client's purpose: each HTTP request can be considered independently rather than being associated
-         with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used
-         effectively in many different contexts and for which implementations can evolve independently over time.
-      </p>
-      <p id="rfc.section.2.p.2">One consequence of HTTP flexibility is that we cannot define the protocol in terms of how to implement it behind the interface.
-         Instead, we are limited to restricting the syntax of communication, defining the intent of received communication, and the
-         expected behavior of recipients. If the communication is considered in isolation, then successful actions should be reflected
-         in the observable interface provided by servers. However, since many clients are potentially acting in parallel and perhaps
-         at cross-purposes, it would be meaningless to require that such behavior be observable.
-      </p>
-      <p id="rfc.section.2.p.3">This section describes the most common contexts in which a user agent is encouraged or instructed to use HTTP for communication
-         and how such contexts differ in terms of their resulting communication.
+</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="architecture" href="#architecture">HTTP architecture</a></h1>
+      <p id="rfc.section.2.p.1">Nevertheless, HTTP was created with a specific architecture in mind, the World Wide Web, and has evolved over time to support
+         the scalability needs of a worldwide hypertext system. Much of that architecture is reflected in the terminology used to define
+         HTTP. This section describes the larger architecture surrounding expected usage of HTTP that is used by this specification
+         to define HTTP.
       </p>
       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="uri" href="#uri">Uniform Resource Identifiers</a></h2>

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

@@ -230 +230 @@
    The Hypertext Transfer Protocol (HTTP) is an application-level
    request/response protocol that uses extensible semantics and MIME-like
-   message payloads for flexible interaction with network-based hypermedia
+   message payloads for flexible interaction with network-based hypertext
    information systems. HTTP relies upon the Uniform Resource Identifier (URI)
-   standard <xref target="RFC3986"/> to indicate resource targets for
-   interaction and to identify other resources.
+   standard <xref target="RFC3986"/> to indicate resource targets and
+   relationships between resources.
    Messages are passed in a format similar to that used by Internet mail
    <xref target="RFC5322"/> and the Multipurpose Internet Mail Extensions
    (MIME) <xref target="RFC2045"/> (see &diff2045entity; for the differences
    between HTTP and MIME messages).
+</t>
+<t>
+   HTTP is a generic interface protocol for informations systems. It is
+   designed to hide the details of how a service is implemented by presenting
+   a uniform interface to clients that is independent of the types of
+   resources provided. Likewise, servers do not need to be aware of each
+   client's purpose: an HTTP request can be considered in isolation rather
+   than being associated with a specific type of client or a predetermined
+   sequence of application steps. The result is a protocol that can be used
+   effectively in many different contexts and for which implementations can
+   evolve independently over time.
 </t>
 <t>
@@ -251 +262 @@
 </t>
 <t>
+   One consequence of HTTP flexibility is that we cannot define the protocol
+   in terms of how to implement it behind the interface. Instead, we are
+   limited to restricting the syntax of communication, defining the intent
+   of received communication, and the expected behavior of recipients. If
+   the communication is considered in isolation, then successful actions
+   should be reflected in the observable interface provided by servers.
+   However, since many clients are potentially acting in parallel and
+   perhaps at cross-purposes, it would be meaningless to require that such
+   behavior be observable.
+</t>
+<t>
    This document is Part 1 of the seven-part specification of HTTP,
    defining the protocol referred to as "HTTP/1.1" and obsoleting
    <xref target="RFC2616"/>.
-   Part 1 defines how clients determine when to use HTTP, the URI schemes
-   specific to HTTP-based resources, overall network operation with
-   transport protocol connection management, and HTTP message framing.
+   Part 1 defines the URI schemes specific to HTTP-based resources, overall
+   network operation, transport protocol connection management, and HTTP
+   message framing and forwarding requirements.
    Our goal is to define all of the mechanisms necessary for HTTP message
    handling that are independent of message semantics, thereby defining the
-   complete set of requirements for an HTTP message relay or generic
-   message parser.
+   complete set of requirements for a message parser and transparent
+   message-forwarding intermediaries.
 </t>
 
@@ -493 +515 @@
 </section>
 
-<section title="When to use HTTP" anchor="when">
-<t>
-   HTTP is a generic interface protocol for informations systems. It is
-   designed to hide the details of how a service is implemented by presenting
-   a uniform interface to clients that is independent of the types of
-   resources provided. Likewise, servers do not need to be aware of the
-   client's purpose: each HTTP request can be considered independently rather
-   than being associated with a specific type of client or a predetermined
-   sequence of application steps. The result is a protocol that can be used
-   effectively in many different contexts and for which implementations can
-   evolve independently over time.
-</t>
-<t>
-   One consequence of HTTP flexibility is that we cannot define the protocol
-   in terms of how to implement it behind the interface. Instead, we are
-   limited to restricting the syntax of communication, defining the intent
-   of received communication, and the expected behavior of recipients. If
-   the communication is considered in isolation, then successful actions
-   should be reflected in the observable interface provided by servers.
-   However, since many clients are potentially acting in parallel and
-   perhaps at cross-purposes, it would be meaningless to require that such
-   behavior be observable.
-</t>
-<t>
-   This section describes the most common contexts in which a user agent is
-   encouraged or instructed to use HTTP for communication and how such
-   contexts differ in terms of their resulting communication.
+<section title="HTTP architecture" anchor="architecture">
+<t>
+   Nevertheless, HTTP was created with a specific architecture in mind, the
+   World Wide Web, and has evolved over time to support the scalability needs
+   of a worldwide hypertext system. Much of that architecture is reflected in
+   the terminology used to define HTTP. This section describes the larger
+   architecture surrounding expected usage of HTTP that is used by this
+   specification to define HTTP.
 </t>