Re: [Uri-review] Request review for URI schemes for CoAP over reliable transports

[Graham Klyne <[e-mail]>]

Carsten,
all,

First, my apologies for the very delayed response.  (I've (a) had some email 
problems which meant I couldn't post to this list, and (b) been travelling with 
very limited Internet access.)  So I've only just reinstated my access to post 
to this list.

So, hoping it's not *too* late to chip in...


I am concerned that these scheme registrations (with multiple schemes for the 
same resource accessed using a different protocol) present an "antipattern" that 
was controversial when a similar proposal was raised about 18 months ago; e.g. 
see an earlier thread [1] about the "rr+*" URI proposal, and in particular the 
response from Roy Fielding [2], specifically this:

[[
A URI scheme should define what it names and how that naming maps to the URI syntax.
There is nothing wrong with using separate schemes for different transports if 
those transports
are essential parts of the name (e.g., if something named Fred at TCP:80 is 
different from something
named Fred at UDP:89898).

[...]

In short, I think you need to better document what each URI scheme means from 
the perspective of
a server and then what the client is expected to do with such a URI.
]]

[1] 
https://mailarchive.ietf.org/arch/search/?email_list=uri-review&gbt=1&index=ZXTfNQ7PDxHBSccrqrrbGH5N-Ko

[2] https://mailarchive.ietf.org/arch/msg/uri-review/ZXTfNQ7PDxHBSccrqrrbGH5N-Ko

I can see no difference between a CoAP resource referenced using the different 
URI schemes defined in the draft, and as such it appears to be an abuse of the 
URI framework, a principle of which is that multiple URIs for identifying the 
same resources should be avoided where possible [3].  Part of the role of URIs 
as identifiers is that they hide rather than expose the purely technical 
mechanisms used when accessing a resource. (Where a technical mechanism is 
exposed, as in "http:", it is as part of the identifying mechanism.

[3] http://www.w3.org/TR/webarch/#uri-aliases

How is this use of CoAP expected to sit within the wider framework of the World 
Wide Web (for which URIs are a core specification).  If you're just using these 
strings to select different transports, why do they need to be URIs at all?

#g
--


On 21/04/2017 06:32, Carsten Bormann wrote:
> It seems we never formally requested a review of the four new URI schemes for CoAP over TCP, TLS, and WebSockets, as requested in
>
> https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-07#section-10.5
>
> To summarize these four schemes:
>
>       coap-tcp-URI = "coap+tcp:" "//" host [ ":" port ]
>         path-abempty [ "?" query ]  [ "#" fragment ]
>
>       coaps-tcp-URI = "coaps+tcp:" "//" host [ ":" port ]
>         path-abempty [ "?" query ] [ "#" fragment ]
>
>       coap-ws-URI = "coap+ws:" "//" host [ ":" port ]
>         path-abempty [ "?" query ] [ "#" fragment ]
>
>       coaps-ws-URI = "coaps+ws:" "//" host [ ":" port ]
>         path-abempty [ "?" query ] [ "#" fragment ]
>
> For the details, please see the draft, which has completed IETF last call.
> (These are patterned after “coap:” and “coaps:” in RFC 7252, which are defined over UDP and DTLS, respectively.)
>
> Grüße, Carsten
>
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review
>