Subject: [dispatch] Internet-Draft: Using URIs With Multiple Transport Stacks

From: Dave Thaler <[email-masked]>
Date: Thu, 6 Jul 2017 19:45:09 +0000

Recently we've seen multiple requests (including from three different SDOs) and
discussions on different lists regarding using URI schemes for application-layer protocols
that can operate over multiple transport stacks (e.g., UDP, TCP, websockets, HTTP, etc.). 
This draft summarizes the various technical discussions and issues raised.

Not sure if there is any regular meeting time available at IETF, but I at least wanted
to share this more broadly for visibility, and to solicit additional feedback.

Dave

-----Original Message-----
A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Using URIs With Multiple Transport Stacks
        Author          : Dave Thaler
	Filename        : draft-thaler-appsawg-multi-transport-uris-01.txt
	Pages           : 10
	Date            : 2017-07-03

Abstract:
   Many Uniform Resource Identifiers (URIs) today have some mechanism to
   resolve them to one or more specific endpoints where that resource is
   available.  This document discusses issues that arise when the same
   resource can be reached over multiple protocol stacks, and discusses
   various approaches that have been used or discussed, and the
   tradeoffs between them.  Such issues are important to consider when
   defining new URI schemes and resolution mechanisms.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-thaler-appsawg-multi-transport-uris/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-thaler-appsawg-multi-transport-uris-01
https://datatracker.ietf.org/doc/html/draft-thaler-appsawg-multi-transport-uris-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-thaler-appsawg-multi-transport-uris-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: [email-masked] (Henry S. Thompson)
Date: Fri, 07 Jul 2017 16:15:08 +0100

Dave Thaler writes:

> Recently we've seen multiple requests (including from three different
> SDOs) and discussions on different lists regarding using URI schemes
> for application-layer protocols that can operate over multiple
> transport stacks (e.g., UDP, TCP, websockets, HTTP, etc.). This draft
> summarizes the various technical discussions and issues raised.
>
> Not sure if there is any regular meeting time available at IETF, but I
> at least wanted to share this more broadly for visibility, and to
> solicit additional feedback.

The W3C TAG devoted a fair amount of effort to this issue about 12 years
ago, and our thinking at the time (2005) is recorded here:

  https://www.w3.org/2001/tag/doc/SchemeProtocols.html

which may provide a useful independent perspective, albeit somewhat
dated in some respects.

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: Dave Thaler <[email-masked]>
Date: Fri, 7 Jul 2017 18:17:34 +0000

Thanks Henry for the pointer, that is very relevant and I will cite it (and some points in it)
in a future version of this draft.

Dave

-----Original Message-----
From: Henry S. Thompson [mailto:[email-masked]] 
Sent: Friday, July 7, 2017 8:15 AM
To: Dave Thaler <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Uri-review] Internet-Draft: Using URIs With Multiple Transport Stacks

> solicit additional feedback.

The W3C TAG devoted a fair amount of effort to this issue about 12 years ago, and our thinking at the time (2005) is recorded here:

  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2001%2Ftag%2Fdoc%2FSchemeProtocols.html&data=02%7C01%7Cdthaler%40microsoft.com%7C8ef6fcd0d8f64853727a08d4c54af6f5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636350373145131799&sdata=7tkNgY68gW0EwKJQGU676kclstxp88Pf1CveKwVzdmM%3D&reserved=0

which may provide a useful independent perspective, albeit somewhat dated in some respects.

ht
                       URL: https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.ltg.ed.ac.uk%2F~ht%2F&data=02%7C01%7Cdthaler%40microsoft.com%7C8ef6fcd0d8f64853727a08d4c54af6f5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636350373145141803&sdata=N5MVPCx%2BN%2FeOzkFQLmC%2BPeq9JClVApoWwysXCPq4FGc%3D&reserved=0

---

From: Graham Klyne <[email-masked]>
Date: Sun, 09 Jul 2017 08:09:13 +0100

Henry, thanks for this reminder.

FWIW, looking at section 4 
(http://www.w3.org/2001/tag/doc/SchemeProtocols.html#findings), I think R1, R3, 
G5, G6, R7, G8, G9 (i.e., most of the findings!) all have some bearing on the 
issues being discussed, insofar as they affect the World Wide Web.  On a brief 
scan, I think the discussion here is as relevant today as it was in 2005 - some 
maybe more so with the move to HTTPS-everywhere.

#g
--

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 10 Jul 2017 19:30:43 +1000

Hi Henry,

Thanks for that. Looping in Noah and Dan (sorry for including you on a list reply!).

Why was the document left in draft state? Does the current TAG have any interest in progressing a finding like this one?

Cheers,

> On 8 Jul 2017, at 1:15 am, Henry S. Thompson <[email-masked]> wrote:
> 
> Dave Thaler writes:
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

--
Mark Nottingham   https://www.mnot.net/

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Jul 2017 14:44:49 +0200

I think this is an interesting reference, as it confirms what has been my perception of the debate so far:

> Although new protocols have traditionally been associated with new URI schemes, there are also advantages to supporting new protocols using existing schemes. In particular, the URIs of existing resources may be widely known, may have been bookmarked or otherwise recorded, or may have been the subject of semantic web assertions.

It seems to me that the conventional wisdom in this space is shaped by experience with URIs that are intended to be long-term, stable, possibly user-visible. Like https://facebook.com — a *strategic* use of URIs.  The stability of this URI is so important that the additional time and effort to do discovery (here: DNS lookup, possibly Happy Eyeballs) is apparently justified (*).

In CoRE, URIs are quite often the *result* of discovery (e.g., involving a resource directory).  They are meant to be instantly usable.  They are much more likely to contain IP addresses than in the Browser Web, to avoid additional lookups.  They are *tactical* URIs.

I’m not sure we should be applying the wisdom we have for strategic URIs to tactical URIs without checking whether the underlying assumptions still apply.

Maybe using the URI concept for tactical purposes is the wrong approach.  URIs were the one part of the three pillars of the Web we thought we could use unmodified, but that caused some trade-offs.  There are multiple proposals to define a URI-like data structure for the purpose that I called “tactical” above.  Doing that would also enable us to solve the rather limited support for security that URIs have; right now URIs often need to be packaged with security information in a larger structure, so we might want to unpack the URI into that.

But for now, URIs are in wide use, and it would be good if we could use them for tactical purposes without getting stuck with all the baggage of strategic use.

Grüße, Carsten

(*) And yet, it only recently replaced http://facebook.com...

---

From: Adam Roach <[email-masked]>
Date: Sat, 15 Jul 2017 10:48:57 +0200

> In CoRE, URIs are quite often the *result* of discovery (e.g., involving a resource directory).  They are meant to be instantly usable.  They are much more likely to contain IP addresses than in th…

I think you stopped quoting the paragraph before it got to something 
highly relevant for CoAP: "...there are serious drawbacks to naming the 
same resource with more than one URI..."  I do see that the TCP draft as 
submitted for consideration tries to deal with this by making making the 
TCP-only schemes use a different namespace than the original schemes, 
but this looks like a sleight of hand: in practice, it seems highly 
likely that servers will need to make resources available to both 
TCP-only clients and UDP-only clients, which makes this kind of aliasing 
inevitable.

I do not believe the "tactical versus strategic" distinction you're 
trying to draw here has any bearing on that aspect of URL use.

/a

---

From: Dave Thaler <[email-masked]>
Date: Sat, 15 Jul 2017 09:12:47 +0000

Adam Roach wrote:
> I think you stopped quoting the paragraph before it got to something highly relevant for CoAP: 
> "...there are serious drawbacks to naming the same resource with more than one URI..."  I do 
> see that the TCP draft as submitted for consideration tries to deal with this by making making 
> the TCP-only schemes use a different namespace than the original schemes, but this looks like
> a sleight of hand: in practice, it seems highly likely that servers will need to make resources
> available to both TCP-only clients and UDP-only clients, which makes this kind of aliasing inevitable.
>
> I do not believe the "tactical versus strategic" distinction you're trying to draw here has any bearing
> on that aspect of URL use.

OCF defines a higher layer URI which is the same regardless of which transport you use (COAP over
UDP, COAP over TCP, HTTP, whatever else) for the reasons you allude to, but that URI is at the 
layer that apps should use (which I take it is what Carsten calls "strategic").   But that has to be resolved
to a set of transport endpoints, and in some cases the transport endpoints are already expressed
via URIs (e.g., a websocket).   That's the layer that I think Carsten is calling "tactical".   A different
terminology might be id vs locator, where URIs are also used for locators in that sense.   That's
what the COAP-TCP draft is doing... defining schemes usable for locators underneath ids.   One point
in my doc is that there can be multiple layers not just two (id vs locator) and so using URIs at each 
layer allows such chaining/stacking.

Dave

---

From: Noah Mendelsohn <[email-masked]>
Date: Mon, 31 Jul 2017 00:17:50 -0400

> Why was the document left in draft state? Does the current TAG have any interest in progressing a finding like this one?

A little history on the drafts at:

There were two of these drafts, the first one dated 16 June 2005 and the 
second one 21 November 2005. As a newly appointed member of the TAG at the 
time I found the relationship between URIs to be interesting, somewhat 
confusing, and as far as I could tell not completely documented. I did not 
at the time consider myself expert in the nuances, so I decided to write a 
draft (June version) that set out how I assumed things worked. My 
assumption was that the relationship was in fact clear. My hope was to set 
down the rules clearly, and in the process to learn them myself.

Discussion at the subsequent TAG meeting made clear that several members 
had serious concerns with some of what was said, so I wrote the November 
draft to try to get closer to "the truth" and to capture the advice I'd 
received. Discussion of the November draft also resulted in strong concerns 
being expressed, some of which seemed to contradict what I had been advised 
in June. On a break at the meeting I expressed my newcomer's confusion to 
someone (probably Dan Connolly) who said: "well, you know that TAG members 
XXXX, YYYY and ZZZZ famously disagree about this subject?" No, I hadn't 
known. I thought all Web experts must have agreed on something so 
fundamental. One aspect of the disagreement was whether schemes and 
protocols should always be 1-to-1 (modulo incremental versioning of the 
protocol), but there were other disagreements as well.

My perception (not necessarily correct) was that Tim BL preferred that 
there be (nearly) no new schemes introduced, with use of http/https schemes 
encouraged wherever possible. The reason, I believe, was so that resourcews 
could have stable names that wouldn't change even if the protocols used for 
deployment evolved over time. New protocols would be introduced either as 
HTTP X.Y, or activated by retrieval via traditional HTTP of a document that 
would as a consequence of its Content-type and contents lead to further 
interactions using some new protocol. So, video resources would be named 
something like http://example.com/myvideo. If some non-HTTP peer-to-peer 
protocol were to be used, there would be an initial traditional HTTP 
interaction; the video server would return a document of a Content-type 
that could convey the instruction to "start using P2P to get the video".

In any case, the creation of and confusing debate about the draft TAG 
finding convinced me that (1) what I had assumed to be a straightforward 
aspect of the Web that merely needed better documention was in fact subtle 
and a source of disagreement even among the best experts and (2) that I as 
a new TAG member who had not been part of the prior debates was not the 
right person to drive the discussion to consensus.

I therefore abandoned work on the drafts and as I recall the TAG did not 
revisit the topic in its general form during my time in the group. Maybe or 
maybe not there is useful discussion in either of the drafts, but there was 
no TAG consensus on either. Furthermore it's not clear that there was more 
agreement with the 2nd draft than with the first.

I hope this is helpful.

Noah

---

From: Noah Mendelsohn <[email-masked]>
Date: Mon, 31 Jul 2017 11:34:14 -0400

On 7/31/2017 12:17 AM, Noah Mendelsohn wrote:
> As a newly appointed member of the TAG at the time I found the relationship 
> between URIs to be interesting

Typo. I meant:

"As a newly appointed member of the TAG at the time I found the 
relationship between URI schemes and Web protocols to be interesting"

Noah