< draft-thaler-appsawg-multi-transport-uris-00.txt		draft-thaler-appsawg-multi-transport-uris-01.txt >
	Network Working Group D. Thaler		Network Working Group D. Thaler
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Informational June 28, 2017		Intended status: Informational July 3, 2017
	Expires: December 30, 2017		Expires: January 4, 2018
	Using URIs With Multiple Transport Stacks		Using URIs With Multiple Transport Stacks
	draft-thaler-appsawg-multi-transport-uris-00		draft-thaler-appsawg-multi-transport-uris-01
	Abstract		Abstract
	Many Uniform Resource Identifiers (URIs) today have some mechanism to		Many Uniform Resource Identifiers (URIs) today have some mechanism to
	resolve them to one or more specific endpoints where that resource is		resolve them to one or more specific endpoints where that resource is
	available. This document discusses issues that arise when the same		available. This document discusses issues that arise when the same
	resource can be reached over multiple protocol stacks, and discusses		resource can be reached over multiple protocol stacks, and discusses
	various approaches that have been used or discussed, and the		various approaches that have been used or discussed, and the
	tradeoffs between them. Such issues are important to consider when		tradeoffs between them. Such issues are important to consider when
	defining new URI schemes and resolution mechanisms.		defining new URI schemes and resolution mechanisms.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 30, 2017.		This Internet-Draft will expire on January 4, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3		2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
	3. Transport endpoint discovery . . . . . . . . . . . . . . . . 4		3. Transport endpoint discovery . . . . . . . . . . . . . . . . 4
	3.1. Specified by the URI scheme specification . . . . . . . . 4		3.1. Specified by the URI scheme specification . . . . . . . . 4
	3.2. Passed in one URI . . . . . . . . . . . . . . . . . . . . 4		3.2. Passed in one URI . . . . . . . . . . . . . . . . . . . . 4
	3.3. Use separate URI for each transport endpoint . . . . . . 6		3.3. Use separate URI for each transport endpoint . . . . . . 6
	3.4. Use another protocol for discovery . . . . . . . . . . . 6		3.4. Use another mechanism for discovery . . . . . . . . . . . 7
	4. Transport endpoint selection . . . . . . . . . . . . . . . . 7		4. Transport endpoint selection . . . . . . . . . . . . . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	7. Informative References . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
			8. Informative References . . . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	For Uniform Resource Identifier (URI) schemes that function as		For Uniform Resource Identifier (URI) schemes that function as
	locators, [RFC3986] explains that URI "resolution" is the process of		locators, [RFC3986] explains that URI "resolution" is the process of
	determining an access mechanism and the appropriate parameters		determining an access mechanism and the appropriate parameters
	necessary to deference a URI; this resolution may require several		necessary to deference a URI; this resolution may require several
	iterations. To use that access mechanism to perform an action on the		iterations. To use that access mechanism to perform an action on the
	URI's resource is to "dereference" the URI.		URI's resource is to "dereference" the URI.
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 33 ¶
	connection to a client or another proxy. This does not suggest		connection to a client or another proxy. This does not suggest
	either that proxies would arbitrarily "upgrade" SIP URIs to SIPS		either that proxies would arbitrarily "upgrade" SIP URIs to SIPS
	URIs when forwarding a request (see Section 5.3). Rather, it		URIs when forwarding a request (see Section 5.3). Rather, it
	means that when a resource is addressable with SIP, it will also		means that when a resource is addressable with SIP, it will also
	be addressable with SIPS.		be addressable with SIPS.
	Thus, the same resource might be identified by multiple URIs that		Thus, the same resource might be identified by multiple URIs that
	differ only in URI scheme, or authority component, or path (e.g.,		differ only in URI scheme, or authority component, or path (e.g.,
	using ".." resolution).		using ".." resolution).
			For URIs used in the World Wide Web, Section 2.3.1 of "Architecture
			of the World Wide Web" [AWWW] further discusses such aliasing,
			explaining that links to a resource increase the value of that
			resource, and multiple URIs for it interfere with such valuation, and
			also makes it difficult to correlate two sources as pointing to the
			same resource via differing aliases. Thus to maximize the benefit to
			the Web, URI aliases should be minimized.
	2. Problem Statement		2. Problem Statement
	Besides specifying one or more URI scheme names to be used and the		Besides specifying one or more URI scheme names to be used and the
	syntax for each (e.g., what the authority component contains), there		syntax for each (e.g., what the authority component contains), there
	are two issues a URI scheme definer must deal with when multiple		are two issues a URI scheme definer must deal with when multiple
	transports are available for accessing a given resource:		transports are available for accessing a given resource:
	1. Specifying how the set of transport endpoint identifiers (e.g.,		1. Specifying how the set of transport endpoint identifiers (e.g.,
	TCP and UDP port numbers) for a given URI can be discovered by an		TCP and UDP port numbers) for a given URI can be discovered by an
	entity wishing to resolve it, and		entity wishing to resolve it, and
	skipping to change at page 4, line 23 ¶		skipping to change at page 4, line 33 ¶
	but it is important to remember that a URI scheme could specify		but it is important to remember that a URI scheme could specify
	discovery of the set of transport protocols via one approach, and		discovery of the set of transport protocols via one approach, and
	discovery of the identifier(s) for each transport protocol via		discovery of the identifier(s) for each transport protocol via
	another approach.		another approach.
	3.1. Specified by the URI scheme specification		3.1. Specified by the URI scheme specification
	In this approach, every resource is assumed to use the exact same set		In this approach, every resource is assumed to use the exact same set
	of transport protocols (i.e., stacks of protocols above the network		of transport protocols (i.e., stacks of protocols above the network
	layer) and identifiers. The identifiers can be IANA assigned and		layer) and identifiers. The identifiers can be IANA assigned and
	specified as part of the URI scheme specification. If support for a		specified as part of the URI scheme or protocol specification. For
	new transport protocol is added later, different entities may thus		example, TFTP only supports UDP port 69, and so no port number is
	have different hard-coded assumptions about the set of possible		permitted in a tftp URI.
	transport protocols, which just pushes the rest of the burden to the
	problem of selection among the known set (see Section 4).		If support for a new transport protocol is later added under a
			protocol with a given URI scheme, different entities may thus have
			different hard-coded assumptions about the set of possible transport
			protocols, which just pushes the rest of the burden to the problem of
			selection among the known set (see Section 4).
	A disadvantage of this approach for many use cases is that it does		A disadvantage of this approach for many use cases is that it does
	not allow for non-default configurations such as custom ports.		not allow for non-default configurations such as custom ports.
	3.2. Passed in one URI		3.2. Passed in one URI
	For single-transport protocols, a common mechanism is to specify a		For single-transport protocols, a common mechanism is to specify a
	default port for the URI scheme, and to allow putting a non-default		default port for the URI scheme, and to allow putting a non-default
	port number in the URI authority component.		port number in the URI authority component.
	skipping to change at page 5, line 36 ¶		skipping to change at page 5, line 51 ¶
	than a literal port number, and allow the service name to be resolved		than a literal port number, and allow the service name to be resolved
	to the relevant transport-layer identifier. Indeed, [RFC6335]		to the relevant transport-layer identifier. Indeed, [RFC6335]
	section 3 says:		section 3 says:
	Because the port number space is finite (and therefore		Because the port number space is finite (and therefore
	conservation is an important goal), the alternative of using		conservation is an important goal), the alternative of using
	service names instead of port numbers is RECOMMENDED whenever		service names instead of port numbers is RECOMMENDED whenever
	possible.		possible.
	Unfortunately, it is not possible to follow this recommendation with		Unfortunately, it is not possible to follow this recommendation with
	the URI authority component, since the URI syntax does not support		the port field in URI authority component, since the URI syntax only
	the use of service names in the authority. Another limitation of		allows integers in the port field.
	service names is that they are currently limited only to TCP, UDP,
	SCTP, and DCCP, and so cannot be used with other layers (e.g.,		For new URI schemes, it may be possible in some cases to place a
	websockets) or protocols. Thus, a URI scheme for a protocol that		service name in the host field, such as "_myservice._tcp.example.org"
	supports both, say, websockets and raw TCP as possible transports for		as would be used with a DNS SRV record [RFC2782]. That example still
	resource access, cannot use a service name as a common identifier for		specifies only a single transport protocol stack ("_tcp") however,
	transport-layer endpoint resolution.		rather than a list of supported stacks.
			Another limitation of service names is that they are currently
			limited only to TCP, UDP, SCTP, and DCCP, and so cannot be used with
			other layers (e.g., websockets) or protocols. Thus, a URI scheme for
			a protocol that supports both, say, websockets and raw TCP as
			possible transports for resource access, cannot use a service name as
			a common identifier for transport-layer endpoint resolution.
	It is usually also undesirable to put transport-layer endpoint		It is usually also undesirable to put transport-layer endpoint
	information (the list of supported transport protocols or the		information (the list of supported transport protocols or the
	identifier(s) used with the transport protocols) in the path or query		identifier(s) used with the transport protocols) in the path or query
	components for two reasons. First, those components are typically		components for two reasons. First, those components are typically
	passed over the wire to the server when accessing a resource, which		passed over the wire to the server when accessing a resource, which
	only consumes extra bandwidth with no benefit. Second, if the		only consumes extra bandwidth with no benefit. Second, if the
	transport-layer identifiers might change over the lifetime of the		transport-layer identifiers might change over the lifetime of the
	resource, then the URI would need to change even if the change did		resource, then the URI would need to change even if the change did
	not affect the actual endpoint chosen by the client. Such a change		not affect the actual endpoint chosen by the client. Such a change
	skipping to change at page 6, line 38 ¶		skipping to change at page 7, line 11 ¶
	For cases where there are multiple transport protocols but only one		For cases where there are multiple transport protocols but only one
	such layer, this approach results in needing to identify a single		such layer, this approach results in needing to identify a single
	transport protocol per URI. As discussed in Section 3.2, this often		transport protocol per URI. As discussed in Section 3.2, this often
	cannot be put in the authority component and is undesirable to put in		cannot be put in the authority component and is undesirable to put in
	the path or query component. As a result, such cases involve		the path or query component. As a result, such cases involve
	specifying a separate URI scheme per transport. For example, "sip"		specifying a separate URI scheme per transport. For example, "sip"
	and "sips" do this. The CoRE WG also proposed this approach for CoAP		and "sips" do this. The CoRE WG also proposed this approach for CoAP
	with "coap", "coaps", "coap+tcp", "coaps+tcp", etc.		with "coap", "coaps", "coap+tcp", "coaps+tcp", etc.
	3.4. Use another protocol for discovery		3.4. Use another mechanism for discovery
	In this approach, a URI scheme definer would specify a mechanism		In this approach, a URI scheme definer would specify a mechanism
	whereby transport stack identifiers can be resolved for a given URI.		whereby transport stack identifiers can be resolved for a given URI.
	If multiple layers exist, then such resolution might involve a		If multiple layers exist, then such resolution might involve a
	resolution step for each layer.		resolution step for each layer.
	DNS records (e.g., SRV records) provide one potential mechanism that		DNS records (e.g., SRV records) provide one potential mechanism that
	can be used to discover a set of supported transports and their		can be used to discover a set of supported transports and their
	associated identifiers. Other types of directories might be usable		associated identifiers. Other types of directories might be usable
	in other cases.		in other cases. For example, HTTP now provides an "Alt-Svc"
			[RFC7838] mechanism that can discover alternate transport endpoints
			for the same HTTP URI.
	One challenge is defining a common mechanism that could discover		One challenge in many cases is defining a common mechanism that could
	identifiers for different transport protocols. For example,		discover identifiers for different transport protocols. For example,
	websockets use URIs and TCP uses port numbers (and there is currently		websockets use URIs and TCP uses port numbers (and there is currently
	no URI scheme for TCP itself), and so the syntax of such identifiers		no URI scheme for TCP itself), and so the syntax of such identifiers
	may differ if an application layer protocol could use both TCP and		may differ if an application layer protocol could use both TCP and
	websockets.		websockets.
	The advantage of requiring a resolution protocol is that the resource		The advantage of requiring a separate resolution mechanism is that
	URI itself can be kept short and simple. The downside is extra		the resource URI itself can be kept short and simple. The downside
	complexity in both clients and servers, and potentially extra		is extra complexity in both clients and servers, and potentially
	specification work for the URI scheme definer, and the possible		extra specification work for the URI scheme definer, and the possible
	additional deployment burden of provisioning and operating extra		additional deployment burden of provisioning and operating extra
	protocols or servers to facilitate such resolution.		protocols or servers to facilitate such resolution.
			In some contexts, it might also be feasible to discover the
			additional identifiers using the same mechanism used to discover the
			URI itself, perhaps even in the same message.
	4. Transport endpoint selection		4. Transport endpoint selection
	The URI scheme must specify the mechanism for choosing among		The URI scheme must specify the mechanism for choosing among
	transport protocol stacks, such as specifying at least one that is		transport protocol stacks, such as specifying at least one that is
	mandatory to implement and an algorithm for trying possible transport		mandatory to implement and an algorithm for trying possible transport
	stacks in some order until one works.		stacks in some order until one works.
	This problem is similar to that of choosing among multiple discovered		This problem is similar to that of choosing among multiple discovered
	IP addresses for the same transport stack, and two common solutions		IP addresses for the same transport stack, and two common solutions
	are used today in that context. One category of algorithm is to sort		are used today in that context. One category of algorithm is to sort
	skipping to change at page 8, line 13 ¶		skipping to change at page 8, line 35 ¶
	This document has no actions for IANA.		This document has no actions for IANA.
	6. Security Considerations		6. Security Considerations
	The security considerations in section 3.7 of [RFC7595] and section 7		The security considerations in section 3.7 of [RFC7595] and section 7
	of [RFC3986] apply. [RFC6943] also discusses security considerations		of [RFC3986] apply. [RFC6943] also discusses security considerations
	with determining equivalence, and section 3.1.4 of that document is		with determining equivalence, and section 3.1.4 of that document is
	relevant to resolution. This document does not raise additional		relevant to resolution. This document does not raise additional
	security issues.		security issues.
	7. Informative References		7. Acknowledgements
			Thanks to Graham Klyne, Alexey Melnikov, and Gabriel Montenegro for
			helpful suggestions on this document.
			8. Informative References
	[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for		[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
	specifying the location of services (DNS SRV)", RFC 2782,		specifying the location of services (DNS SRV)", RFC 2782,
	DOI 10.17487/RFC2782, February 2000,		DOI 10.17487/RFC2782, February 2000,
	<http://www.rfc-editor.org/info/rfc2782>.		<http://www.rfc-editor.org/info/rfc2782>.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<http://www.rfc-editor.org/info/rfc3986>.		<http://www.rfc-editor.org/info/rfc3986>.
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 30 ¶
	[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,		[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
	"Default Address Selection for Internet Protocol Version 6		"Default Address Selection for Internet Protocol Version 6
	(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,		(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
	<http://www.rfc-editor.org/info/rfc6724>.		<http://www.rfc-editor.org/info/rfc6724>.
	[RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for		[RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for
	Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May		Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May
	2013, <http://www.rfc-editor.org/info/rfc6943>.		2013, <http://www.rfc-editor.org/info/rfc6943>.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252,
	DOI 10.17487/RFC7252, June 2014,
	<http://www.rfc-editor.org/info/rfc7252>.
	[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190,		[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190,
	RFC 7320, DOI 10.17487/RFC7320, July 2014,		RFC 7320, DOI 10.17487/RFC7320, July 2014,
	<http://www.rfc-editor.org/info/rfc7320>.		<http://www.rfc-editor.org/info/rfc7320>.
	[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines		[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
	and Registration Procedures for URI Schemes", BCP 35,		and Registration Procedures for URI Schemes", BCP 35,
	RFC 7595, DOI 10.17487/RFC7595, June 2015,		RFC 7595, DOI 10.17487/RFC7595, June 2015,
	<http://www.rfc-editor.org/info/rfc7595>.		<http://www.rfc-editor.org/info/rfc7595>.
	[I-D.ietf-core-coap-tcp-tls]		[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
	Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,		Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
	Silverajan, B., and B. Raymor, "CoAP (Constrained		April 2016, <http://www.rfc-editor.org/info/rfc7838>.
	Application Protocol) over TCP, TLS, and WebSockets",
	draft-ietf-core-coap-tcp-tls-09 (work in progress), May
	2017.
	[ListDiscussion]		[AWWW] Jacobs, I. and N. Walsh, "Architecture of the World Wide
	Bormann, C., "Question about Location and redirection",		Web, Volume One", December 2004,
	Symposium on Security and Privacy 2003, October 2013,		<http://www.w3.org/TR/webarch>.
	<https://www.ietf.org/mail-archive/web/core/current/
	msg04867.html>.
	Author's Address		Author's Address
	Dave Thaler		Dave Thaler
	Microsoft		Microsoft
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	USA		USA
	Email: dthaler@microsoft.com		Email: dthaler@microsoft.com
End of changes. 19 change blocks.
	46 lines changed or deleted		66 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/