Ignore:
Timestamp:
13/11/08 21:26:18 (12 years ago)
Author:
fielding@…
Message:

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

File:
1 edited

Legend:

Unmodified
Added
Removed
  • 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.