One document matched: draft-wood-tae-specifying-uri-transports-00.txt
Network Working Group L. Wood
Internet-Draft Cisco Systems
Intended status: Experimental December 15, 2008
Expires: June 18, 2009
Specifying transport mechanisms for retrieval or delivery of URIs
draft-wood-tae-specifying-uri-transports-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 18, 2009.
Abstract
This document describes a simple extension of the URI format to allow
preferred transport mechanisms and interfaces to be specified. This
explicit configuration is beneficial for separation of HTTP from
underlying transports, which has been increasingly recognised as
useful. Explicit configuration in the URI for programs is valuable
when TCP, traditionally used to carry HTTP, is not present or not
desired, or when other methods of determining or negotiating the
appropriate transport method to use, e.g. the Domain Name System
(DNS), are absent.
Wood Expires June 18, 2009 [Page 1]
Internet-Draft Specifying URI transports December 2008
Table of Contents
1. Background and Introduction . . . . . . . . . . . . . . . . . . 3
2. Extending the URI scheme to indicate transports and
interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 7
Wood Expires June 18, 2009 [Page 2]
Internet-Draft Specifying URI transports December 2008
1. Background and Introduction
Desire to separate the Hypertext Transfer Protocol (HTTP) [RFC2616]
from its traditional transport of the Transmission Control Protocol
(TCP) is increasing.
There are environments where TCP is not suitable, or absent, yet HTTP
can still be used as a method to transfer data. Being able to
indicate the desired transport and interface to use in the URI for a
program to interpret when executing HTTP GETs or PUTs is useful when
a choice of mechanisms and interfaces are available.
This document outlines how the desired transport and interface can be
indicated in the Uniform Resource Identifier (URI) format [RFC3986]
by a simple extension to that format using existing syntax.
This syntax is useful for carrying HTTP over different transport
protocols. HTTP can be thought of a session layer, running over a
transport layer providing reliable delivery of the HTTP stream
between hops. This transport layer is commonly (and almost
universally) TCP in the terrestrial Internet, although alternative
transport layers, such as SCTP, can also be used under HTTP
[I-D.natarajan-httpbis-sctp]. For long-delay networks, or for
network conditions where TCP or an equivalent is not suitable, an
alternative transport layer such as Saratoga
[I-D.wood-tsvwg-saratoga] can be used under HTTP instead in hop-by-
hop communications between nodes. This has been described in detail
[I-D.wood-dtnrg-http-dtn-delivery]. HTTP requires only reliable
streaming that can be used to provide ordered delivery to the
application; how that reliable streaming is provided is up to the
local transport layer in the local network. TCP or SCTP would be
used to carry HTTP over the congestion-sensitive public Internet,
while Saratoga would be used for HTTP across private links.
Steve Deering has often described IP as 'the waist in the hourglass'
[Deering98] - what is above and touching on IP can be changed, what
is below and touching on IP can be changed, but provided the new
elements continue to interface to and work with IP, the hourglass
remains complete and the network stack remains functional. Here,
HTTP is the waist in this particular hourglass; applications can use
HTTP to communicate, provided HTTP runs over a reliable transport
stream. The applications can vary. The transport stream can be
changed; HTTP does not have to run over TCP/IP, but could even be
made to run directly over something else entirely. Given the
prevalence of IP in many networks, it is likely that two waists
exist; IP and HTTP are likely choices, but the transport protocol and
physical enviroment will vary more.
Wood Expires June 18, 2009 [Page 3]
Internet-Draft Specifying URI transports December 2008
Being able to specify how HTTP or other schemes are carried is useful
when a variety of methods are available to choose from. This is far
more likely to be used for local configuration from e.g. a scripting
language, in the absence of DNS, than it is to be used for URIs on
the public world-wide web.
2. Extending the URI scheme to indicate transports and interfaces
The URI format syntax ([RFC3986], section 3.1) defines the scheme as:
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
To quote [RFC2718], section 2.2.2:
"When a scheme is associated with a network protocol, the
specification should completely describe how URLs are translated into
protocol actions in sufficient detail to make the access of the
network resource unambiguous. If an implementation of the URL scheme
requires some configuration, the configuration elements must be
clearly identified."
Within these constraints, this draft proposes that schemes can be
extended to indicate transport and interface, in the format:
scheme = scheme name [ "+" port ] [ "-" transport ] ["." interface ]
where the optionally-included +port is a description mapping to the
default IANA-assigned port number, or the port number, indicating the
desired behaviour over a transport. The optionally-included
-transport is the transport name or IANA protocol identifier number
that that name maps to. The optionally-included .interface can
contain a locally-meaningful specifier identifying that interface.
This would permit http-sctp:// or http+saratoga-udp:// for the uses
outlined in [I-D.natarajan-httpbis-sctp] and
[I-D.wood-dtnrg-http-dtn-delivery]. Port and internet protocol
numbers assigned by IANA are accepted as equivalents for these
underlying protocols, so http+7542-17:// specifies HTTP over Saratoga
over UDP. http-132 is equivalent to http-sctp in specifying HTTP over
SCTP. As is usual, these are case insensitive, so that http-sctp,
HTTP-sctp, and HtTp-ScTp are all equivalent.
If required, the port the scheme is actually run over, which the
behaviour of the specified default port is mapped to, is still
indicated later in the URI as :number, e.g. :80. When this is not
specified the default port is used.
Wood Expires June 18, 2009 [Page 4]
Internet-Draft Specifying URI transports December 2008
Knowing that a higher-layer protocol is always associated with TCP or
UDP would mean that -tcp or -udp could be omitted. http by itself is
taken to mean http-tcp, and is therefore backwards-compatible with
current use.
Being able to specify the local interface to initiate a transaction
on when a choice of interfaces is available on a multihomed device is
useful, e.g. http+saratoga.serial0://.
3. Security Considerations
No additional security concerns have been thought of at this time.
4. IANA Considerations
No additional IANA considerations have been thought of at this time.
5. References
5.1. Normative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
"Guidelines for new URL Schemes", RFC 2718, November 1999.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
5.2. Informative References
[Deering98]
Deering, S., "Watching the Waist of the Protocol
Hourglass", keynote, IEEE International Conference on
Network Protocols (ICNP), Austin Texas, October 1998.
[I-D.natarajan-httpbis-sctp]
Natarajan, P., Amer, P., Leighton, J., and F. Baker,
"Using SCTP as a Transport Layer Protocol for HTTP",
draft-natarajan-httpbis-sctp-00 (work in progress),
October 2008.
Wood Expires June 18, 2009 [Page 5]
Internet-Draft Specifying URI transports December 2008
[I-D.wood-dtnrg-http-dtn-delivery]
Wood, L. and P. Holliday, "Using HTTP for delivery in
Delay/Disruption-Tolerant Networks",
draft-wood-dtnrg-http-dtn-delivery-02 (work in progress),
October 2008.
[I-D.wood-tsvwg-saratoga]
Wood, L., McKim, J., Eddy, W., Ivancic, W., and C.
Jackson, "Saratoga: A Scalable File Transfer Protocol",
draft-wood-tsvwg-saratoga-02 (work in progress),
October 2008.
Author's Address
Lloyd Wood
Cisco Systems
11 New Square Park, Bedfont Lakes
Feltham, Middlesex TW14 8HA
United Kingdom
Phone: +44-20-8824-4236
Email: lwood@cisco.com
Wood Expires June 18, 2009 [Page 6]
Internet-Draft Specifying URI transports December 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Wood Expires June 18, 2009 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-24 06:54:36 |