Changeset 1717


Ignore:
Timestamp:
05/07/12 04:02:58 (10 years ago)
Author:
mnot@…
Message:

Initial go at p0; see #326

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p0-introduction.xml

    r1697 r1717  
    1717  <!ENTITY ID-YEAR "2012">
    1818  <!ENTITY mdash "&#8212;">
     19  <!ENTITY status-codes "<xref target='Part2' x:rel='#status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     20  <!ENTITY header-cache-control "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1921]>
    2022<?rfc toc="yes" ?>
    … …  
    9698<abstract>
    9799<t>
    98   <cref>TODO</cref>
     100   This document is the first in a series that, collectively, define the
     101   HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1.
    99102</t>
    100103</abstract>
    … …  
    118121</front>
    119122<middle>
    120 <section title="Introduction" anchor="introduction">
    121 <t>
    122   <cref>TODO</cref>
    123 </t>
     123
     124<section title="Introduction to the HTTP Document Series">
     125<t>
     126   This document is the first in a series that, collectively, define
     127   the HyperText Transfer Protocol, version 1.1; otherwise known as
     128   HTTP/1.1.
     129</t>
     130<t>The document series is organised as follows:</t>
     131<t><list style="symbols">
     132   <t>HTTP/1.1 Introduction - this document</t>
     133   <t><xref target="Part1"/> HTTP/1.1 Message Parsing and Connection Handling
     134   - How to parse a HTTP/1.1 (or below) message, and layer it onto
     135   connection-oriented protocols.</t>
     136   <t><xref target="Part2"/> HTTP/1.1 Core Semantics - Protocol elements such
     137   as methods, status codes, and payload-specific headers. Also includes
     138   content negotiation mechanisms.</t>
     139   <t><xref target="Part4"/> HTTP/1.1 Conditional Requests - An extension to
     140   make requests contingent upon their current state.</t>
     141   <t><xref target="Part5"/> HTTP/1.1 Partial Content - An extension to
     142   request that only a portion of a response be sent back.</t>
     143   <t><xref target="Part6"/> HTTP/1.1 Caching - An extension to allow storage
     144   and reuse of responses.</t>
     145   <t><xref target="Part7"/> HTTP/1.1 Authentication Framework - extension
     146   enabling client authentication to proxy and origin servers</t>
     147</list></t>
     148
     149<t>The "core" of HTTP/1.1 is defined by the first two specifications. The
     150remaining specifications in the series are generally optional, but may be
     151required in some implementation or deployment scenarios; when this is the
     152case, it will be noted.</t>
     153
     154<t>Collectively, these documents obsolete <xref target="RFC2616"/>. Note that
     155many other specifications extend and refine the use of HTTP (generally, as
     156protocol extensions, where allowed by these specifications); they are not
     157considered part of this series, but they are still "part of HTTP".</t>
     158
    124159</section>
     160
     161<section title="What is HTTP?" anchor="wat">
     162<t>
     163   The Hypertext Transfer Protocol (HTTP) is an application-level
     164   request/response protocol that uses extensible semantics and MIME-like
     165   message payloads for flexible interaction with network-based hypertext
     166   information systems. HTTP relies upon the Uniform Resource Identifier (URI)
     167   standard <xref target="RFC3986"/> to indicate the target resource
     168   and relationships between resources.
     169</t>
     170<t>
     171   HTTP is a generic interface protocol for information systems. It is
     172   designed to hide the details of how a service is implemented by presenting
     173   a uniform interface to clients that is independent of the types of
     174   resources provided. Likewise, servers do not need to be aware of each
     175   client's purpose: an HTTP request can be considered in isolation rather
     176   than being associated with a specific type of client or a predetermined
     177   sequence of application steps. The result is a protocol that can be used
     178   effectively in many different contexts and for which implementations can
     179   evolve independently over time.
     180</t>
     181<t>
     182   HTTP is also designed for use as an intermediation protocol for translating
     183   communication to and from non-HTTP information systems.
     184   HTTP proxies and gateways can provide access to alternative information
     185   services by translating their diverse protocols into a hypertext
     186   format that can be viewed and manipulated by clients in the same way
     187   as HTTP services.
     188</t>
     189<t>
     190   One consequence of HTTP flexibility is that the protocol cannot be
     191   defined in terms of what occurs behind the interface. Instead, we
     192   are limited to defining the syntax of communication, the intent
     193   of received communication, and the expected behavior of recipients.
     194   If the communication is considered in isolation, then successful
     195   actions ought to be reflected in corresponding changes to the
     196   observable interface provided by servers. However, since multiple
     197   clients might act in parallel and perhaps at cross-purposes, we
     198   cannot require that such changes be observable beyond the scope
     199   of a single response.
     200</t>
     201<t>
     202  <cref>TODO: remove corresponding text from p1 Introduction.</cref>
     203</t>
     204</section>
     205
     206
     207
     208
    125209</middle>
    126210<back>
    … …  
    255339  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-&ID-VERSION;" />
    256340  <x:source basename="p7-auth" href="p7-auth.xml" />
     341</reference>
     342
     343<reference anchor="RFC3986">
     344 <front>
     345  <title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
     346  <author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
     347    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
     348    <address>
     349       <email>timbl@w3.org</email>
     350       <uri>http://www.w3.org/People/Berners-Lee/</uri>
     351    </address>
     352  </author>
     353  <author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
     354    <organization abbrev="Day Software">Day Software</organization>
     355    <address>
     356      <email>fielding@gbiv.com</email>
     357      <uri>http://roy.gbiv.com/</uri>
     358    </address>
     359  </author>
     360  <author initials='L.' surname='Masinter' fullname='Larry Masinter'>
     361    <organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization>
     362    <address>
     363      <email>LMM@acm.org</email>
     364      <uri>http://larry.masinter.net/</uri>
     365    </address>
     366  </author>
     367  <date month='January' year='2005'></date>
     368 </front>
     369 <seriesInfo name="STD" value="66"/>
     370 <seriesInfo name="RFC" value="3986"/>
    257371</reference>
    258372
    … …  
    297411</reference>
    298412
     413
    299414</references>
    300415</back>
Note: See TracChangeset for help on using the changeset viewer.