Re: [Uri-review] [dispatch] [art] Internet-Draft: Using URIs With Multiple Transport Stacks

[Adam Roach <[e-mail]>]

On 7/14/17 14:44, Carsten Bormann wrote:
> On Jul 7, 2017, at 17:15, Henry S. Thompson <[e-mail]> wrote:
>>   https://www.w3.org/2001/tag/doc/SchemeProtocols.html
> 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 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