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

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Adam Roach-3
On 7/14/17 14:44, Carsten Bormann wrote:
> On Jul 7, 2017, at 17:15, Henry S. Thompson <[hidden email]> 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

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Loading...