Alfred,
thanks for your detailed comments; I've attached a
drafty draft including your proposed changes.
That's a very good point on the recursive definition; I've
gotten around it by
extended-scheme = scheme [][][][][]
(decently laid out)
which is intended to be clear to the reader, though the
formal correctness of this retrofitting of punctuation pairs
within the scheme definition is, as you point out, difficult
to achieve.
Many thanks!
L.
<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood at surrey.ac.uk>
--- On Wed, 28/10/09, Alfred Hönes <ah at TR-Sys.de> wrote:
> From: Alfred Hönes <ah at TR-Sys.de>
> Subject: draft-wood-tae-specifying-uri-transports-07
> To: L.Wood at society.surrey.ac.uk
> Cc: uri-review at ietf.org
> Date: Wednesday, 28 October, 2009, 10:52
> Hello,
> I've followed up to your updated Internet-Draft,
> draft-wood-tae-specifying-uri-transports-07, and would
> like to submit a few (mostly) editorial comments.
>
>
> (1) Section 2 -- general
>
> This section is so long that it becomes tedious to point
> to particular text in it. Maybe structuring it into
> sub-sections would help.
>
>
> (2) Section 2 -- syntax definition
>
> The integration of the new syntax with RFC 3986 is difficult,
> since the rule name <scheme> from RFC 3986 is made use of in
> all modern specifications of URI Schemes.
>
> The draft specifies:
>
> scheme = scheme [ "-+" port behaviour ] ["++" transport ] ["+-" interface ] [ "--" dynamic configuration]
>
> At first glance, it looks like there were distinct tokens
> "port", "behavior", "dynamic", and "configuration".
> For clarity, I recommend to join the word pairs using hyphens.
> Further, the visual appearance of the syntax rule would be
> improved substantially by matching the line break with the
> logical structure and using indentation:
>
> scheme = scheme [ "-+" port-behaviour ] ["++" transport ]
>
> [ "+-" interface ] [ "--" dynamic-configuration ]
>
> In this prsentation form, however, it becomes apparent that
> this rule is recursive; that would essentially allow repeating
> the new suffix elements in any number and order, which you
> apparently do not want.
> My initial idea to fix that,
>
> scheme = basic-scheme
> [ "-+" port-behaviour ] [ "++" transport ]
> [ "+-" interface ] [ "--" dynamic-configuration ]
>
> basic-scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
> ;
> <scheme> in RFC 3986
>
> ... makes integration with existing URI Scheme definitions
> cumbersome;
> there seems no easy way to do that in a formally correct
> manner;
> maybe this integrated alternative would be slightly better
> (yet not
> satisfactorily):
>
> scheme =/ ALPHA *( ALPHA
> / DIGIT / "+" / "-" / "." )
>
> ; <scheme> definition in RFC 3986
>
> [ "-+" port-behaviour ] [ "++" transport
> ]
>
> [ "+-" interface ] [ "--"
> dynamic-configuration ]
>
> Another possibility with less ambiguities:
>
> scheme
> =/ basic-scheme
>
> [ "-+"
> port-behaviour ]
>
> [ "++"
> transport ]
>
> [ "+-"
> interface ]
>
> [ "--"
> dynamic-configuration ]
>
> basic-scheme
> = scheme-token
>
> ; any
> IANA-registered URI Scheme name
>
> port-behaviour
> = scheme-token
> transport
> = scheme-token
> interface
> = scheme-token
> dynamic-configuration = scheme-token
>
> scheme-token
> = ALPHA *( [ "+" / "-" / "." ] (ALPHA / DIGIT) )
>
>
> (3) Section 2 -- referal to DNS
>
> The single DNS based mechanism containing service
> information down
> to the port level I am aware of is the SRV Resource Record
> (RR).
> Therefore, it might be better to modify:
>
> The optionally-included "--" gets
> configuration information and
> | transport/services to use dynamically via some
> method, e.g. DNS
> | records, but can be partly overriden by other
> locally-provided
> configuration from the other three
> modifier types described above.
> ---
> The optionally-included "--" gets
> configuration information and
> | transport/services to use dynamically via some
> method (e.g., via DNS
> | SRV records), but can be partly overriden by other
> locally-provided
> configuration from the other three
> modifier types described above.
>
> With "via", the proposed phrase implicitly also comprises
> DNS-based
> DDDS using NAPTR RRs (RFC 3403 et al.).
>
>
> (4) Section 3, 3rd para -- language
>
> I suggest to improve the grammar:
>
> ... has proposed using ... and could
> indicates ...
> ---
>
> ^^^^^^^^^^^^^^^
> ... has proposed using ... and indicating
> ...
>
> I.e., with the full context:
>
> [I-D.jennings-http-srv] has proposed
> using DNS lookup of a SRV record
> to return a dynamic port value, as well
> as an address, and could
> indicates this using http--srv:// and
> http--srv:// in line with the
> use of a service name as indicated
> above.
> ---
> [I-D.jennings-http-srv] has proposed
> using DNS lookup of a SRV record
> | to return a dynamic port value, as well as an
> address, and indicating
> this using http--srv:// and http--srv://
> in line with the use of a
> service name as indicated above.
>
>
> Kind regards,
> Alfred Hönes.
>
> --
>
> +------------------------+--------------------------------------------+
> | TR-Sys Alfred Hoenes | Alfred
> Hoenes Dipl.-Math., Dipl.-Phys. |
> | Gerlinger Strasse 12 | Phone:
> (+49)7156/9635-0, Fax: -18
> |
> | D-71254 Ditzingen |
> E-Mail: ah at TR-Sys.de
>
> |
> +------------------------+--------------------------------------------+
>
>
Network Working Group L. Wood
Internet-Draft Surrey
Intended status: Experimental October 29, 2009
Expires: May 2, 2010
Specifying transport mechanisms in Uniform Resource Identifiers
draft-wood-tae-specifying-uri-transports-08
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 May 2, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes a simple extension of the Uniform Resource
Identifier (URI) format that allows preferred transport mechanisms,
including protocols, ports and interfaces, to be specified as
Wood Expires May 2, 2010 [Page 1]
Internet-Draft Specifying URI transports October 2009
parseable additions to the scheme name. This explicit configuration
is beneficial for separation of the HyperText Transfer Protocol
(HTTP) from underlying transports, which has been increasingly
recognised as useful when a variety of ways of transporting or
configuring use of HTTP are available and a choice of mechanism to
use must be indicated.
Table of Contents
1. Background and Introduction . . . . . . . . . . . . . . . . . . 3
2. Foundations of URI scheme syntax . . . . . . . . . . . . . . . 4
3. Extending the URI scheme to indicate transports and
interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Use of these modifiers . . . . . . . . . . . . . . . . . . . . 5
5. Relevant work . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Wood Expires May 2, 2010 [Page 2]
Internet-Draft Specifying URI transports October 2009
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, and
infrastructure such as DNS cannot be queried for advice.
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. This
transport layer has commonly (and almost universally) been TCP in the
terrestrial Internet, although alternative transport layers, such as
SCTP, can also be used under HTTP [I-D.natarajan-http-over-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. In
the examples given above, TCP or SCTP are used to carry HTTP over the
congestion-sensitive public Internet, while Saratoga would be used
for HTTP across dedicated 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 even have to run over a TCP/IP stack, 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
popular waists (layers that other layers interface to) exist: IP and
Wood Expires May 2, 2010 [Page 3]
Internet-Draft Specifying URI transports October 2009
HTTP. The transport protocol and physical enviroment that IP and
HTTP are used with will vary more, depending on local conditions and
needs.
Being able to specify how HTTP or other schemes are carried is useful
when a variety of methods are available to choose from. The syntax
described here is useful for local configuration, e.g. in a scripting
language that is aware of the local host and remote host's shared
support of a given transport protocol. It is less useful on the
public world-wide web, because users (and web page designers) are not
generally capable of determining which transport protocol(s) are
supported by their web browser, operating system, or network.
However, the option to explicitly choose a communication method is
useful.
2. Foundations of URI scheme syntax
Before describing an extension to URI scheme syntax, it is worthwhile
to lay out the foundations on which this syntax is based.
HTTP is not explicitly tied to use over TCP. To quote [RFC2616],
section 1.4:
"HTTP communication usually takes place over TCP/IP connections. The
default port is TCP 80, but other ports can be used. This does not
preclude HTTP from being implemented on top of any other protocol on
the Internet, or on other networks. HTTP only presumes a reliable
transport; any protocol that provides such guarantees can be used;
the mapping of the HTTP/1.1 request and response structures onto the
transport data units of the protocol in question is outside the scope
of this specification."
The URI format syntax ([RFC3986], section 3.1) defines the scheme as:
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
The period (.) is in use in a number of scheme names; the other
punctuation characters appear unused.
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."
Wood Expires May 2, 2010 [Page 4]
Internet-Draft Specifying URI transports October 2009
3. Extending the URI scheme to indicate transports and interfaces
Within the established foundation, this draft proposes that schemes
can be extended to include configuration elements that indicate
transport and interface. These modify use of the http request, and
are in the format as given in the following figure:
extended-scheme = scheme ["-+" port-behaviour ]
["++" transport ]
["+-" interface ]
["--" dynamic-configuration]
Figure 1
where the optionally-included -+port is a description mapping to the
default IANA-assigned port number, or the equivalent name, indicating
the desired behaviour over a transport. This information is
specified locally as service names in e.g. /etc/services on unix
machines.
The optionally-included ++transport is the transport name or IANA
protocol identifier number that that name maps to. As we aim to
separate HTTP from TCP and place it over other transports, nicknaming
this proposal 'http++' obviously follows.
The optionally-included +-interface can contain a locally-meaningful
specifier identifying the local interface to use; useful on multi-
homed devices. The local interface identifier may identify a virtual
or physical interface or one that is only capable of using IPv4,
IPv6, or another network protocol (in the case of HTTP being run over
something other than a TCP/IP stack.) Defining virtual interfaces
limited to one network protocol allows the choice of network protocol
to be made.
The optionally-included "--" gets configuration information and
transport/services to use dynamically via some method, e.g. via DNS
records, but can be partly overriden by other locally-provided
configuration from the other three modifier types described above.
This is described more in the 'relevant work' section below.
4. Use of these modifiers
Use of these modifiers would permit http++sctp:// or
http-+saratoga++udp:// for the uses outlined in
[I-D.natarajan-http-over-sctp] and
[I-D.wood-dtnrg-http-dtn-delivery]. Port and internet protocol
numbers assigned by IANA are accepted as equivalent to assigned names
Wood Expires May 2, 2010 [Page 5]
Internet-Draft Specifying URI transports October 2009
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.
Adding these optional transport indicators to the scheme name does
not change the namespace in any way; the URI should still be treated
as if it began simply http: and is the http namespace. Similarly,
'https++' shares the https namespace, only indicating services,
transports and interfaces for the https request to use.
This document deliberately does not state what 'http:' by itself
implies; local use may invoke dynamic configuration, or simultaneous
attempts to use multiple available transports or interfaces. 'http:'
is NOT restricted to mean 'http++tcp:'.
If required, the port the scheme is actually run over, which the
behaviour of any 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 for that tranport behaviour is used. For
example, Saratoga runs over UDP and is assigned default port 7452 by
IANA. Saying 'http-+7452:' means do the default behaviour for port
7452, i.e. use the Saratoga protocol. http-+7452://blah:1024
indicates that the default behaviour on port 7452 - that is, Saratoga
- should be carried over to port 1024, i.e. use the Saratoga protocol
on port 1024 instead.
Knowing that a '-+' service port behaviour stated in the scheme is
only associated with either TCP or UDP would mean that ++tcp or ++udp
can be omitted when that -+behaviour is given. That is, -+saratoga
is known to mean -+saratoga++udp.
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://.
5. Relevant work
[I-D.natarajan-http-over-sctp] proposes carrying http over sctp.
This can be indicated with http++sctp:.
[I-D.wood-dtnrg-http-dtn-delivery] proposes separating HTTP from the
underlying transport entirely, and running it over other transports,
such as Saratoga [I-D.wood-tsvwg-saratoga]. This can be specified
locally with http-+saratoga++udp: or simply http-+saratoga:.
We can also use '--' to indicate that information on resolving the
Wood Expires May 2, 2010 [Page 6]
Internet-Draft Specifying URI transports October 2009
URI must be sought from the network.
[I-D.jennings-http-srv] has proposed using DNS lookup of a SRV record
to return a dynamic port value, as well as an address, and could
indicate this using http--srv:// and http--srv:// in line with the
use of a service name as indicated above. [Ed note: need to double-
check Cullen's current draft.]
Alternatively, some new DNS record type returning address, port and
other access information could be explicitly accessed via e.g.
http--dns:// or some other indication of method. This could take
advantage of DNS Name Authority Pointers (NAPTR) via S-NAPTR and
U-NAPTR [RFC3958] [RFC4848], and encourage the use of and testing
with those protocols before wider deployment. [I-D.faltstrom-uri]
expands further on this approach. Both SRV and NAPTR can be used by
SIP in allocating SIP servers [RFC3263].
Other work on evolving the URI format to enable service discovery
with DNS for different transport protocols is in e.g. [Uruena05].
It should be possible to combine the static configuration in the
parseable scheme format described here with getting other
configuration information that is not explicitly given, but that is
needed to access the URI dyamically, from DNS records when
appropriate. Any static information explicitly provided should
override information from dynamic configuration, just as explicitly
indicating a port with e.g. :80 in the URI explicitly overrides the
port returned by http--srv:.
6. Security Considerations
No additional security concerns have been thought of at this time.
7. IANA Considerations
No additional IANA considerations have been thought of at this time.
8. Acknowledgements
Thanks go to Fred Baker, Leslie Daigle, Alfred Hoenes, Cullen
Jennings, Jonathan Leighton, Preethi Natarajan, Chip Sharp and Dan
Wing for discussion on points of this draft.
9. References
Wood Expires May 2, 2010 [Page 7]
Internet-Draft Specifying URI transports October 2009
9.1. Normative References
[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.
9.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.faltstrom-uri]
Faltstrom, P. and O. Kolkman, "The Uniform Resource
Identifier (URI) DNS Resource Record",
draft-faltstrom-uri-04 (work in progress), May 2009.
[I-D.jennings-http-srv]
Jennings, C., "DNS SRV Records for HTTP",
draft-jennings-http-srv-05 (work in progress), March 2009.
[I-D.natarajan-http-over-sctp]
Natarajan, P., Amer, P., Leighton, J., and F. Baker,
"Using SCTP as a Transport Layer Protocol for HTTP",
draft-natarajan-http-over-sctp-02 (work in progress),
July 2009.
[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-delivery-04 (work in progress) ,
October 2009.
[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-04 (work in progress) ,
October 2009.
[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.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Wood Expires May 2, 2010 [Page 8]
Internet-Draft Specifying URI transports October 2009
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007.
[Uruena05]
Uruena, M. and D. Larrabeiti, "Nested Uniform Resource
Identifiers", Proceedings of the 31st EUROMICRO Conference
on Software Engineering and Advanced Applications, pp.
380-385 , August 2005.
Author's Address
Lloyd Wood
Surrey, England
Email: L.Wood at society.surrey.ac.uk
Wood Expires May 2, 2010 [Page 9]