Ignore:
Timestamp:
13/11/08 22:27:55 (12 years ago)
Author:
julian.reschke@…
Message:

Resolve #34: update to current URI spec, get rid of discussion of URI history (closes #34)

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r372 r374  
    229229<t>
    230230   The Hypertext Transfer Protocol (HTTP) is an application-level
    231    protocol for distributed, collaborative, hypermedia information
    232    systems. HTTP has been in use by the World-Wide Web global
    233    information initiative since 1990. The first version of HTTP, commonly
    234    referred to as HTTP/0.9, was a simple protocol for raw data transfer
    235    across the Internet with only a single method and no metadata.
    236    HTTP/1.0, as defined by <xref target="RFC1945"/>, improved
    237    the protocol by allowing messages to be in the format of MIME-like
    238    messages, containing metadata about the data transferred and
    239    modifiers on the request/response semantics. However, HTTP/1.0 did
    240    not sufficiently take into consideration the effects of hierarchical
    241    proxies, caching, the need for persistent connections, or name-based
    242    virtual hosts. In addition, the proliferation of incompletely-implemented
    243    applications calling themselves "HTTP/1.0" necessitated a
    244    protocol version change in order for two communicating applications
    245    to determine each other's true capabilities.
    246 </t>
    247 <t>
    248    This document is Part 1 of the seven-part specification that defines
    249    the protocol referred to as "HTTP/1.1", obsoleting <xref target="RFC2616"/>.
    250    HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
    251    requirements that enable reliable implementations and adding only
    252    those new features that will either be safely ignored by an HTTP/1.0
    253    recipient or only sent when communicating with a party advertising
    254    compliance with HTTP/1.1.
    255    Part 1 defines those aspects of HTTP/1.1 related to overall network
    256    operation, message framing, interaction with transport protocols, and
    257    URI schemes.
    258 </t>
    259 <t>
    260    This document is currently disorganized in order to minimize the changes
    261    between drafts and enable reviewers to see the smaller errata changes.
    262    The next draft will reorganize the sections to better reflect the content.
    263    In particular, the sections will be organized according to the typical
    264    process of deciding when to use HTTP (URI schemes), overall network operation,
    265    connection management, message framing, and generic message parsing.
    266    The current mess reflects how widely dispersed these topics and associated
    267    requirements had become in <xref target="RFC2616"/>.
    268 </t>
    269 
    270 <section title="Purpose" anchor="intro.purpose">
    271 <t>
    272    Practical information systems require more functionality than simple
    273    retrieval, including search, front-end update, and annotation. HTTP
    274    allows an open-ended set of methods and headers that indicate the
    275    purpose of a request <xref target="RFC2324"/>. It builds on the discipline of reference
    276    provided by the Uniform Resource Identifier (URI) <xref target="RFC1630"/>, as a location
    277    (URL) <xref target="RFC1738"/> or name (URN) <xref target="RFC1737"/>, for indicating the resource to which a
    278    method is to be applied. Messages are passed in a format similar to
    279    that used by Internet mail <xref target="RFC5322"/> as defined by the Multipurpose
    280    Internet Mail Extensions (MIME) <xref target="RFC2045"/>.
    281 </t>
    282 <t>
    283    HTTP is also used as a generic protocol for communication between
    284    user agents and proxies/gateways to other Internet systems, including
    285    those supported by the SMTP <xref target="RFC2821"/>, NNTP <xref target="RFC3977"/>, FTP <xref target="RFC959"/>, Gopher <xref target="RFC1436"/>,
    286    and WAIS <xref target="WAIS"/> protocols. In this way, HTTP allows basic hypermedia
    287    access to resources available from diverse applications.
    288 </t>
    289 </section>
     231   request/response protocol that uses extensible semantics and MIME-like
     232   message payloads for flexible interaction with network-based hypermedia
     233   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.
     236   Messages are passed in a format similar to that used by Internet mail
     237   <xref target="RFC5322"/> and the Multipurpose Internet Mail Extensions
     238   (MIME) <xref target="RFC2045"/> (see &diff2045entity; for the differences
     239   between HTTP and MIME messages).
     240</t>
     241<t>
     242   HTTP is also designed for use as a generic protocol for translating
     243   communication to and from other Internet information systems, such as
     244   USENET news services via NNTP <xref target="RFC3977"/>,
     245   file services via FTP <xref target="RFC959"/>,
     246   Gopher <xref target="RFC1436"/>, and WAIS <xref target="WAIS"/>.
     247   HTTP proxies and gateways provide access to alternative information
     248   services by translating their diverse protocols into a hypermedia
     249   format that can be viewed and manipulated by clients in the same way
     250   as HTTP services.
     251</t>
     252<t>
     253   This document is Part 1 of the seven-part specification of HTTP,
     254   defining the protocol referred to as "HTTP/1.1" and obsoleting
     255   <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.
     259   Our goal is to define all of the mechanisms necessary for HTTP message
     260   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.
     263</t>
    290264
    291265<section title="Requirements" anchor="intro.requirements">
    … …  
    697671<section title="Uniform Resource Identifiers" anchor="uri">
    698672<t>
    699    URIs have been known by many names: WWW addresses, Universal Document
    700    Identifiers, Universal Resource Identifiers <xref target="RFC1630"/>, and finally the
    701    combination of Uniform Resource Locators (URL) <xref target="RFC1738"/> and Names (URN)
    702    <xref target="RFC1737"/>. As far as HTTP is concerned, Uniform Resource Identifiers are
    703    simply formatted strings which identify--via name, location, or any
    704    other characteristic--a resource.
    705 </t>
    706 
    707 <section title="General Syntax" anchor="general.syntax">
    708   <x:anchor-alias value="absoluteURI"/>
     673   Uniform Resource Identifiers (URIs) <xref target="RFC3986"/> are used in HTTP
     674   to indicate the target of a request and to identify additional resources related
     675   to that resource, the request, or the response. Each protocol element in HTTP
     676   that allows a URI reference will indicate in its ABNF whether the element allows
     677   only a URI in absolute form, any relative reference, or some limited subset of
     678   the URI-reference grammar. Unless otherwise indicated, relative URI references
     679   are to be parsed relative to the URI corresponding to the request target
     680   (the base URI).
     681</t>
     682  <x:anchor-alias value="URI-reference"/>
     683  <x:anchor-alias value="absolute-URI"/>
    709684  <x:anchor-alias value="authority"/>
    710685  <x:anchor-alias value="fragment"/>
     686  <x:anchor-alias value="path-abempty"/>
    711687  <x:anchor-alias value="path-absolute"/>
    712688  <x:anchor-alias value="port"/>
    713689  <x:anchor-alias value="query"/>
    714690  <x:anchor-alias value="relativeURI"/>
     691  <x:anchor-alias value="relative-part"/>
    715692  <x:anchor-alias value="uri-host"/>
    716693<t>
    717    URIs in HTTP can be represented in absolute form or relative to some
    718    known base URI <xref target="RFC1808"/>, depending upon the context of their use. The two
    719    forms are differentiated by the fact that absolute URIs always begin
    720    with a scheme name followed by a colon. For definitive information on
    721    URL syntax and semantics, see "Uniform Resource Identifiers (URI):
    722    Generic Syntax and Semantics," <xref target="RFC2396"/> (which replaces <xref target="RFC1738"/>
    723    and <xref target="RFC1808"/>). This specification adopts the
    724    definitions of "URI-reference", "absoluteURI", "fragment", "relativeURI", "port",
    725    "host", "abs_path", "query", and "authority" from that specification:
    726 </t>
    727 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="absoluteURI"/><iref primary="true" item="Grammar" subitem="authority"/><iref primary="true" item="Grammar" subitem="path-absolute"/><iref primary="true" item="Grammar" subitem="port"/><iref primary="true" item="Grammar" subitem="query"/><iref primary="true" item="Grammar" subitem="relativeURI"/><iref primary="true" item="Grammar" subitem="uri-host"/>
    728   <x:ref>absoluteURI</x:ref>   = &lt;absoluteURI, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>>
    729   <x:ref>authority</x:ref>     = &lt;authority, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2"/>>
    730   <x:ref>fragment</x:ref>      = &lt;fragment, defined in <xref target="RFC2396" x:fmt="," x:sec="4.1"/>>
    731   <x:ref>path-absolute</x:ref> = &lt;abs_path, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>>
    732   <x:ref>port</x:ref>          = &lt;port, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>>
    733   <x:ref>query</x:ref>         = &lt;query, defined in <xref target="RFC2396" x:fmt="," x:sec="3.4"/>>
    734   <x:ref>relativeURI</x:ref>   = &lt;relativeURI, defined in <xref target="RFC2396" x:fmt="," x:sec="5"/>>
    735   <x:ref>uri-host</x:ref>      = &lt;host, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>>
    736 </artwork></figure>
    737 <t>
    738    HTTP does not place any a priori limit on the length of
     694   This specification adopts the definitions of "URI-reference", "absolute-URI", "fragment", "port",
     695   "host", "path-abempty", "path-absolute", "query", and "authority" from <xref target="RFC3986"/>:
     696</t>
     697<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="URI-reference"/><iref primary="true" item="Grammar" subitem="absolute-URI"/><iref primary="true" item="Grammar" subitem="authority"/><iref primary="true" item="Grammar" subitem="path-absolute"/><iref primary="true" item="Grammar" subitem="port"/><iref primary="true" item="Grammar" subitem="query"/><iref primary="true" item="Grammar" subitem="uri-host"/><iref primary="true" item="Grammar" subitem="relativeURI"/><iref primary="true" item="Grammar" subitem="relative-part"/>
     698  <x:ref>absolute-URI</x:ref>   = &lt;absolute-URI, defined in <xref target="RFC3986" x:fmt="," x:sec="4.3"/>>
     699  <x:ref>authority</x:ref>     = &lt;authority, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2"/>>
     700  <x:ref>fragment</x:ref>      = &lt;fragment, defined in <xref target="RFC3986" x:fmt="," x:sec="3.5"/>>
     701  <x:ref>path-abempty</x:ref>  = &lt;path-abempty, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>>
     702  <x:ref>path-absolute</x:ref> = &lt;path-absolute, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>>
     703  <x:ref>port</x:ref>          = &lt;port, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.3"/>>
     704  <x:ref>query</x:ref>         = &lt;query, defined in <xref target="RFC3986" x:fmt="," x:sec="3.4"/>>
     705  <x:ref>uri-host</x:ref>      = &lt;host, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>>
     706
     707  <x:ref>relative-part</x:ref> = &lt;relative-part, defined in <xref target="RFC3986" x:fmt="," x:sec="4.2"/>>
     708  <x:ref>relativeURI</x:ref>   = <x:ref>relative-part</x:ref> [ "?" <x:ref>query</x:ref> ]
     709</artwork></figure>
     710<t>
     711   HTTP does not place an a priori limit on the length of
    739712   a URI. Servers &MUST; be able to handle the URI of any resource they
    740713   serve, and &SHOULD; be able to handle URIs of unbounded length if they
    … …  
    752725  </list>
    753726</t>
    754 </section>
    755 
    756 <section title="http URL" anchor="http.url">
    757   <x:anchor-alias value="http-URL"/>
     727
     728<section title="http URI scheme" anchor="http.uri">
     729  <x:anchor-alias value="http-URI"/>
    758730  <iref item="http URI scheme" primary="true"/>
    759731  <iref item="URI scheme" subitem="http" primary="true"/>
    760732<t>
    761733   The "http" scheme is used to locate network resources via the HTTP
    762    protocol. This section defines the scheme-specific syntax and
    763    semantics for http URLs.
    764 </t>
    765 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URL"/>
    766   <x:ref>http-URL</x:ref> = "http:" "//" <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ]
    767              [ <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ]]
     734   protocol. This section defines the syntax and semantics for identifiers
     735   using the http or https URI schemes.
     736</t>
     737<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URI"/>
     738  <x:ref>http-URI</x:ref> = "http:" "//" <x:ref>authority</x:ref> <x:ref>path-abempty</x:ref> [ "?" <x:ref>query</x:ref> ]
    768739</artwork></figure>
    769740<t>
    … …  
    802773<t>
    803774   Characters other than those in the "reserved" set (see
    804    <xref target="RFC2396" x:fmt="," x:sec="2.2"/>) are equivalent to their
     775   <xref target="RFC3986" x:fmt="," x:sec="2.2"/>) are equivalent to their
    805776   ""%" <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding.
    806777</t>
    … …  
    14491420<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request-URI"/>
    14501421  <x:ref>Request-URI</x:ref>    = "*"
    1451                  / <x:ref>absoluteURI</x:ref>
     1422                 / <x:ref>absolute-URI</x:ref>
    14521423                 / ( <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ] )
    14531424                 / <x:ref>authority</x:ref>
    … …  
    14641435</artwork></figure>
    14651436<t>
    1466    The absoluteURI form is &REQUIRED; when the request is being made to a
     1437   The absolute-URI form is &REQUIRED; when the request is being made to a
    14671438   proxy. The proxy is requested to forward the request or service it
    14681439   from a valid cache, and return the response. Note that the proxy &MAY;
    14691440   forward the request on to another proxy or directly to the server
    1470    specified by the absoluteURI. In order to avoid request loops, a
     1441   specified by the absolute-URI. In order to avoid request loops, a
    14711442   proxy &MUST; be able to recognize all of its server names, including
    14721443   any aliases, local variations, and the numeric IP address. An example
    … …  
    14771448</artwork></figure>
    14781449<t>
    1479    To allow for transition to absoluteURIs in all requests in future
    1480    versions of HTTP, all HTTP/1.1 servers &MUST; accept the absoluteURI
     1450   To allow for transition to absolute-URIs in all requests in future
     1451   versions of HTTP, all HTTP/1.1 servers &MUST; accept the absolute-URI
    14811452   form in requests, even though HTTP/1.1 clients will only generate
    14821453   them in requests to proxies.
    … …  
    14881459   The most common form of Request-URI is that used to identify a
    14891460   resource on an origin server or gateway. In this case the absolute
    1490    path of the URI &MUST; be transmitted (see <xref target="general.syntax"/>, path-absolute) as
     1461   path of the URI &MUST; be transmitted (see <xref target="http.uri"/>, path-absolute) as
    14911462   the Request-URI, and the network location of the URI (authority) &MUST;
    14921463   be transmitted in a Host header field. For example, a client wishing
    … …  
    15061477<t>
    15071478   The Request-URI is transmitted in the format specified in
    1508    <xref target="general.syntax"/>. If the Request-URI is encoded using the
     1479   <xref target="http.uri"/>. If the Request-URI is encoded using the
    15091480   "% <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding
    1510    (<xref target="RFC2396" x:fmt="," x:sec="2.4.1"/>), the origin server
     1481   (<xref target="RFC3986" x:fmt="," x:sec="2.4"/>), the origin server
    15111482   &MUST; decode the Request-URI in order to
    15121483   properly interpret the request. Servers &SHOULD; respond to invalid
    … …  
    15481519   resource on an HTTP/1.1 request:
    15491520  <list style="numbers">
    1550     <t>If Request-URI is an absoluteURI, the host is part of the
     1521    <t>If Request-URI is an absolute-URI, the host is part of the
    15511522     Request-URI. Any Host header field value in the request &MUST; be
    15521523     ignored.</t>
    1553     <t>If the Request-URI is not an absoluteURI, and the request includes
     1524    <t>If the Request-URI is not an absolute-URI, and the request includes
    15541525     a Host header field, the host is determined by the Host header
    15551526     field value.</t>
    … …  
    22462217   number of the resource being requested, as obtained from the original
    22472218   URI given by the user or referring resource (generally an HTTP URL,
    2248    as described in <xref target="http.url"/>). The Host field value &MUST; represent
     2219   as described in <xref target="http.uri"/>). The Host field value &MUST; represent
    22492220   the naming authority of the origin server or gateway given by the
    22502221   original URL. This allows the origin server or gateway to
    … …  
    22542225<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/><iref primary="true" item="Grammar" subitem="Host-v"/>
    22552226  <x:ref>Host</x:ref>   = "Host" ":" <x:ref>OWS</x:ref> <x:ref>Host-v</x:ref>
    2256   <x:ref>Host-v</x:ref> = <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="http.url"/>
     2227  <x:ref>Host-v</x:ref> = <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="http.uri"/>
    22572228</artwork></figure>
    22582229<t>
    … …  
    26772648   The entry for the "http" URI Scheme in the registry located at
    26782649   <eref target="http://www.iana.org/assignments/uri-schemes.html"/>
    2679    should be updated to point to <xref target="http.url"/> of this document
     2650   should be updated to point to <xref target="http.uri"/> of this document
    26802651   (see <xref target="RFC4395"/>).
    26812652</t>
    … …  
    29762947<section title="Acknowledgments" anchor="ack">
    29772948<t>
    2978    This specification makes heavy use of the augmented BNF and generic
    2979    constructs defined by David H. Crocker for <xref target="RFC5234"/>. Similarly, it
    2980    reuses many of the definitions provided by Nathaniel Borenstein and
    2981    Ned Freed for MIME <xref target="RFC2045"/>. We hope that their inclusion in this
    2982    specification will help reduce past confusion over the relationship
    2983    between HTTP and Internet mail message formats.
    2984 </t>
    2985 <t>
    29862949   HTTP has evolved considerably over the years. It has
    29872950   benefited from a large and active developer community--the many
    … …  
    30312994   discovery of many of the problems that this document attempts to
    30322995   rectify.
     2996</t>
     2997<t>
     2998   This specification makes heavy use of the augmented BNF and generic
     2999   constructs defined by David H. Crocker for <xref target="RFC5234"/>. Similarly, it
     3000   reuses many of the definitions provided by Nathaniel Borenstein and
     3001   Ned Freed for MIME <xref target="RFC2045"/>. We hope that their inclusion in this
     3002   specification will help reduce past confusion over the relationship
     3003   between HTTP and Internet mail message formats.
    30333004</t>
    30343005</section>
    … …  
    33053276</reference>
    33063277
    3307 <reference anchor="RFC2396">
    3308   <front>
    3309     <title abbrev="URI Generic Syntax">Uniform Resource Identifiers (URI): Generic Syntax</title>
    3310     <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
    3311       <organization abbrev="MIT/LCS">World Wide Web Consortium</organization>
    3312       <address><email>timbl@w3.org</email></address>
    3313     </author>
    3314     <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
    3315       <organization abbrev="U.C. Irvine">Department of Information and Computer Science</organization>
    3316       <address><email>fielding@ics.uci.edu</email></address>
    3317     </author>
    3318     <author initials="L." surname="Masinter" fullname="Larry Masinter">
    3319       <organization abbrev="Xerox Corporation">Xerox PARC</organization>
    3320       <address><email>masinter@parc.xerox.com</email></address>
    3321     </author>
    3322     <date month="August" year="1998"/>
    3323   </front>
    3324   <seriesInfo name="RFC" value="2396"/>
     3278<reference anchor="RFC3986">
     3279 <front>
     3280  <title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
     3281  <author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
     3282    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
     3283    <address>
     3284       <email>timbl@w3.org</email>
     3285       <uri>http://www.w3.org/People/Berners-Lee/</uri>
     3286    </address>
     3287  </author>
     3288  <author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
     3289    <organization abbrev="Day Software">Day Software</organization>
     3290    <address>
     3291      <email>fielding@gbiv.com</email>
     3292      <uri>http://roy.gbiv.com/</uri>
     3293    </address>
     3294  </author>
     3295  <author initials='L.' surname='Masinter' fullname='Larry Masinter'>
     3296    <organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization>
     3297    <address>
     3298      <email>LMM@acm.org</email>
     3299      <uri>http://larry.masinter.net/</uri>
     3300    </address>
     3301  </author>
     3302  <date month='January' year='2005'></date>
     3303 </front>
     3304 <seriesInfo name="RFC" value="3986"/>
     3305 <seriesInfo name="STD" value="66"/>
    33253306</reference>
    33263307
    … …  
    34623443</reference>
    34633444
    3464 <reference anchor="RFC1630">
    3465   <front>
    3466     <title abbrev="URIs in WWW">Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web</title>
    3467     <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
    3468       <organization>CERN, World-Wide Web project</organization>
    3469       <address><email>timbl@info.cern.ch</email></address>
    3470     </author>
    3471     <date month="June" year="1994"/>
    3472   </front>
    3473   <seriesInfo name="RFC" value="1630"/>
    3474 </reference>
    3475 
    3476 <reference anchor="RFC1737">
    3477   <front>
    3478     <title abbrev="Requirements for Uniform Resource Names">Functional Requirements for Uniform Resource Names</title>
    3479     <author initials="L." surname="Masinter" fullname="Larry Masinter">
    3480       <organization>Xerox Palo Alto Research Center</organization>
    3481       <address><email>masinter@parc.xerox.com</email></address>
    3482     </author>
    3483     <author initials="K." surname="Sollins" fullname="Karen Sollins">
    3484       <organization>MIT Laboratory for Computer Science</organization>
    3485       <address><email>sollins@lcs.mit.edu</email></address>
    3486     </author>
    3487     <date month="December" year="1994"/>
    3488   </front>
    3489   <seriesInfo name="RFC" value="1737"/>
    3490 </reference>
    3491 
    3492 <reference anchor="RFC1738">
    3493   <front>
    3494     <title>Uniform Resource Locators (URL)</title>
    3495     <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
    3496       <organization>CERN, World-Wide Web project</organization>
    3497       <address><email>timbl@info.cern.ch</email></address>
    3498     </author>
    3499     <author initials="L." surname="Masinter" fullname="Larry Masinter">
    3500       <organization>Xerox PARC</organization>
    3501       <address><email>masinter@parc.xerox.com</email></address>
    3502     </author>
    3503     <author initials="M." surname="McCahill" fullname="Mark McCahill">
    3504       <organization>University of Minnesota, Computer and Information Services</organization>
    3505       <address><email>mpm@boombox.micro.umn.edu</email></address>
    3506     </author>
    3507     <date month="December" year="1994"/>
    3508   </front>
    3509   <seriesInfo name="RFC" value="1738"/>
    3510 </reference>
    3511 
    3512 <reference anchor="RFC1808">
    3513   <front>
    3514     <title>Relative Uniform Resource Locators</title>
    3515     <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
    3516       <organization>University of California Irvine, Department of Information and Computer Science</organization>
    3517       <address><email>fielding@ics.uci.edu</email></address>
    3518     </author>
    3519     <date month="June" year="1995"/>
    3520   </front>
    3521   <seriesInfo name="RFC" value="1808"/>
    3522 </reference>
    3523 
    35243445<reference anchor="RFC1900">
    35253446  <front>
    … …  
    36263547</reference>
    36273548
    3628 <reference anchor="RFC2324">
    3629   <front>
    3630     <title abbrev="HTCPCP/1.0">Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</title>
    3631     <author initials="L." surname="Masinter" fullname="Larry Masinter">
    3632       <organization>Xerox Palo Alto Research Center</organization>
    3633       <address><email>masinter@parc.xerox.com</email></address>
    3634     </author>
    3635     <date month="April" day="1" year="1998"/>
    3636   </front>
    3637   <seriesInfo name="RFC" value="2324"/>
    3638 </reference>
    3639 
    36403549<reference anchor="RFC2616">
    36413550  <front>
    … …  
    36843593  </front>
    36853594  <seriesInfo name='RFC' value='2818' />
    3686 </reference>
    3687 
    3688 <reference anchor="RFC2821">
    3689   <front>
    3690     <title>Simple Mail Transfer Protocol</title>
    3691     <author initials="J." surname="Klensin" fullname="J. Klensin">
    3692       <organization>AT&amp;T Laboratories</organization>
    3693       <address><email>klensin@research.att.com</email></address>
    3694     </author>
    3695     <date year="2001" month="April"/>
    3696   </front>
    3697   <seriesInfo name="RFC" value="2821"/>
    36983595</reference>
    36993596
    … …  
    39463843<section title="Compatibility with Previous Versions" anchor="compatibility">
    39473844<t>
     3845   HTTP has been in use by the World-Wide Web global information initiative
     3846   since 1990. The first version of HTTP, later referred to as HTTP/0.9,
     3847   was a simple protocol for hypertext data transfer across the Internet
     3848   with only a single method and no metadata.
     3849   HTTP/1.0, as defined by <xref target="RFC1945"/>, added a range of request
     3850   methods and MIME-like messaging that could include metadata about the data
     3851   transferred and modifiers on the request/response semantics. However,
     3852   HTTP/1.0 did not sufficiently take into consideration the effects of
     3853   hierarchical proxies, caching, the need for persistent connections, or
     3854   name-based virtual hosts. The proliferation of incompletely-implemented
     3855   applications calling themselves "HTTP/1.0" further necessitated a
     3856   protocol version change in order for two communicating applications
     3857   to determine each other's true capabilities.
     3858</t>
     3859<t>
     3860   HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
     3861   requirements that enable reliable implementations, adding only
     3862   those new features that will either be safely ignored by an HTTP/1.0
     3863   recipient or only sent when communicating with a party advertising
     3864   compliance with HTTP/1.1.
     3865</t>
     3866<t>
    39483867   It is beyond the scope of a protocol specification to mandate
    39493868   compliance with previous versions. HTTP/1.1 was deliberately
    … …  
    41154034</t>
    41164035<t>
    4117   Fix BNF to add query, as the abs_path production in
    4118   <xref x:sec="3" x:fmt="of" target="RFC2396"/> doesn't define it.
     4036  Update use of abs_path production from RFC1808 to the path-absolute + query
     4037  components of RFC3986.
    41194038  (<xref target="request-uri"/>)
    41204039</t>
    … …  
    45244443      Add rules for terms imported from URI spec ("absoluteURI", "authority",
    45254444      "path-absolute", "port", "query", "relativeURI", "host) -- these will
    4526       have to be updated when switching over to RFC3986. 
     4445      have to be updated when switching over to RFC3986.
    45274446    </t>
    45284447    <t>
    … …  
    46314550  <list style="symbols">
    46324551    <t>
     4552      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/34"/>:
     4553      "Out-of-date reference for URIs"
     4554    </t>
     4555    <t>
    46334556      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/132"/>:
    46344557      "RFC 2822 is updated by RFC 5322"
Note: See TracChangeset for help on using the changeset viewer.