Changeset 373


Ignore:
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:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest-roy/p1-messaging.html

    r361 r373  
    365365      <link rel="Index" href="#rfc.index">
    366366      <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
    367       <link rel="Chapter" title="2 When to use HTTP" href="#rfc.section.2">
     367      <link rel="Chapter" title="2 HTTP architecture" href="#rfc.section.2">
    368368      <link rel="Chapter" title="3 Protocol Parameters" href="#rfc.section.3">
    369369      <link rel="Chapter" title="4 HTTP Message" href="#rfc.section.4">
     
    477477         <tr>
    478478            <td class="header left"></td>
    479             <td class="header right">November 12, 2008</td>
     479            <td class="header right">November 13, 2008</td>
    480480         </tr>
    481481      </table>
     
    529529            </ul>
    530530         </li>
    531          <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#when">When to use HTTP</a><ul class="toc">
     531         <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#architecture">HTTP architecture</a><ul class="toc">
    532532               <li class="tocline1">2.1&nbsp;&nbsp;&nbsp;<a href="#uri">Uniform Resource Identifiers</a><ul class="toc">
    533533                     <li class="tocline1">2.1.1&nbsp;&nbsp;&nbsp;<a href="#http.uri">http URI scheme</a></li>
     
    669669      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
    670670      <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and
    671          MIME-like message payloads for flexible interaction with network-based hypermedia information systems. HTTP relies upon the
    672          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
    673          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).
    674       </p>
    675       <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,
     671         MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the
     672         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
     673         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).
     674      </p>
     675      <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
     676         by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do
     677         not need to be aware of each client's purpose: an HTTP request can be considered in isolation rather than being associated
     678         with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used
     679         effectively in many different contexts and for which implementations can evolve independently over time.
     680      </p>
     681      <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,
    676682         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
    677683         a hypermedia format that can be viewed and manipulated by clients in the same way as HTTP services.
    678684      </p>
    679       <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
    680          operation with transport protocol connection management, and HTTP message framing. Our goal is to define all of the mechanisms
    681          necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements
    682          for an HTTP message relay or generic message parser.
     685      <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.
     686         Instead, we are limited to restricting the syntax of communication, defining the intent of received communication, and the
     687         expected behavior of recipients. If the communication is considered in isolation, then successful actions should be reflected
     688         in the observable interface provided by servers. However, since many clients are potentially acting in parallel and perhaps
     689         at cross-purposes, it would be meaningless to require that such behavior be observable.
     690      </p>
     691      <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
     692         management, and HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for
     693         HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for a message
     694         parser and transparent message-forwarding intermediaries.
    683695      </p>
    684696      <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>
     
    797809  <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;
    798810  <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;
    799 </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>
    800       <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
    801          by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do
    802          not need to be aware of the client's purpose: each HTTP request can be considered independently rather than being associated
    803          with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used
    804          effectively in many different contexts and for which implementations can evolve independently over time.
    805       </p>
    806       <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.
    807          Instead, we are limited to restricting the syntax of communication, defining the intent of received communication, and the
    808          expected behavior of recipients. If the communication is considered in isolation, then successful actions should be reflected
    809          in the observable interface provided by servers. However, since many clients are potentially acting in parallel and perhaps
    810          at cross-purposes, it would be meaningless to require that such behavior be observable.
    811       </p>
    812       <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
    813          and how such contexts differ in terms of their resulting communication.
     811</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="architecture" href="#architecture">HTTP architecture</a></h1>
     812      <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
     813         the scalability needs of a worldwide hypertext system. Much of that architecture is reflected in the terminology used to define
     814         HTTP. This section describes the larger architecture surrounding expected usage of HTTP that is used by this specification
     815         to define HTTP.
    814816      </p>
    815817      <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

    r361 r373  
    230230   The Hypertext Transfer Protocol (HTTP) is an application-level
    231231   request/response protocol that uses extensible semantics and MIME-like
    232    message payloads for flexible interaction with network-based hypermedia
     232   message payloads for flexible interaction with network-based hypertext
    233233   information systems. HTTP relies upon the Uniform Resource Identifier (URI)
    234    standard <xref target="RFC3986"/> to indicate resource targets for
    235    interaction and to identify other resources.
     234   standard <xref target="RFC3986"/> to indicate resource targets and
     235   relationships between resources.
    236236   Messages are passed in a format similar to that used by Internet mail
    237237   <xref target="RFC5322"/> and the Multipurpose Internet Mail Extensions
    238238   (MIME) <xref target="RFC2045"/> (see &diff2045entity; for the differences
    239239   between HTTP and MIME messages).
     240</t>
     241<t>
     242   HTTP is a generic interface protocol for informations systems. It is
     243   designed to hide the details of how a service is implemented by presenting
     244   a uniform interface to clients that is independent of the types of
     245   resources provided. Likewise, servers do not need to be aware of each
     246   client's purpose: an HTTP request can be considered in isolation rather
     247   than being associated with a specific type of client or a predetermined
     248   sequence of application steps. The result is a protocol that can be used
     249   effectively in many different contexts and for which implementations can
     250   evolve independently over time.
    240251</t>
    241252<t>
     
    251262</t>
    252263<t>
     264   One consequence of HTTP flexibility is that we cannot define the protocol
     265   in terms of how to implement it behind the interface. Instead, we are
     266   limited to restricting the syntax of communication, defining the intent
     267   of received communication, and the expected behavior of recipients. If
     268   the communication is considered in isolation, then successful actions
     269   should be reflected in the observable interface provided by servers.
     270   However, since many clients are potentially acting in parallel and
     271   perhaps at cross-purposes, it would be meaningless to require that such
     272   behavior be observable.
     273</t>
     274<t>
    253275   This document is Part 1 of the seven-part specification of HTTP,
    254276   defining the protocol referred to as "HTTP/1.1" and obsoleting
    255277   <xref target="RFC2616"/>.
    256    Part 1 defines how clients determine when to use HTTP, the URI schemes
    257    specific to HTTP-based resources, overall network operation with
    258    transport protocol connection management, and HTTP message framing.
     278   Part 1 defines the URI schemes specific to HTTP-based resources, overall
     279   network operation, transport protocol connection management, and HTTP
     280   message framing and forwarding requirements.
    259281   Our goal is to define all of the mechanisms necessary for HTTP message
    260282   handling that are independent of message semantics, thereby defining the
    261    complete set of requirements for an HTTP message relay or generic
    262    message parser.
     283   complete set of requirements for a message parser and transparent
     284   message-forwarding intermediaries.
    263285</t>
    264286
     
    493515</section>
    494516
    495 <section title="When to use HTTP" anchor="when">
    496 <t>
    497    HTTP is a generic interface protocol for informations systems. It is
    498    designed to hide the details of how a service is implemented by presenting
    499    a uniform interface to clients that is independent of the types of
    500    resources provided. Likewise, servers do not need to be aware of the
    501    client's purpose: each HTTP request can be considered independently rather
    502    than being associated with a specific type of client or a predetermined
    503    sequence of application steps. The result is a protocol that can be used
    504    effectively in many different contexts and for which implementations can
    505    evolve independently over time.
    506 </t>
    507 <t>
    508    One consequence of HTTP flexibility is that we cannot define the protocol
    509    in terms of how to implement it behind the interface. Instead, we are
    510    limited to restricting the syntax of communication, defining the intent
    511    of received communication, and the expected behavior of recipients. If
    512    the communication is considered in isolation, then successful actions
    513    should be reflected in the observable interface provided by servers.
    514    However, since many clients are potentially acting in parallel and
    515    perhaps at cross-purposes, it would be meaningless to require that such
    516    behavior be observable.
    517 </t>
    518 <t>
    519    This section describes the most common contexts in which a user agent is
    520    encouraged or instructed to use HTTP for communication and how such
    521    contexts differ in terms of their resulting communication.
     517<section title="HTTP architecture" anchor="architecture">
     518<t>
     519   Nevertheless, HTTP was created with a specific architecture in mind, the
     520   World Wide Web, and has evolved over time to support the scalability needs
     521   of a worldwide hypertext system. Much of that architecture is reflected in
     522   the terminology used to define HTTP. This section describes the larger
     523   architecture surrounding expected usage of HTTP that is used by this
     524   specification to define HTTP.
    522525</t>
    523526
Note: See TracChangeset for help on using the changeset viewer.