Subject: [core] Alternative Transports: Yes/No consensus on URI scheme governance

From: Bill Silverajan <[email-masked]>
Date: Wed, 22 Jul 2015 15:55:19 +0300

Hello,

We ran out of time to discuss some things at yesterday's CoRE meeting. 
So I'm firing this at the mailing list.

As you already know, the working group has settled upon the using 
"coap+<transport>" as the URI scheme to identify CoAP resources 
available over alternative transports. And as you many already know, 
people in the appsarea wg floated the idea some time back, about 
namespaces in URI schemes, and establishing an IANA registry for URI 
scheme prefix registration. That idea was subsequently voted down, and 
therefore the URI scheme still remains an opaque component.

I'd appreciate your feedback in considering if the working group needs 
to develop some guidelines or governance mechanisms for using the 
<coap+transport> URI scheme. I'll take your comments onboard for 
developing the next version of 
draft-silverajan-core-coap-alternative-transports.

I'll give a few examples where guidelines might be useful based on 
feedback and current usage:

* Is coap+udp:// URI equivalent to a coap:// URI?

This was raised as a reviewer comment from Akbar, as to whether the new 
URI format should consider compatibility with a CoAP-over-UDP URI.

* Semantic interpretations: Recommendations for precisely describing 
transports (and their secure versions). As an example, I consider TLS as 
a CoAP transport, and not as a secure version of TCP for conveying CoAP 
packets. Therefore, CoAP over TLS should use coap+tls:// instead of 
coaps+tcp:// or coap+tcps://, etc. Similarly, I would also like to see 
the "coaps+transport" be used mean CoAP-over-DTLS-over-transport. 
coaps+sms:// is far easier to understand than coap+smss://

* Practical considerations: coap+lwm2m:// URI scheme is a great example 
of where it is essential to consider adopting (at least for some time) 
to ease the difficulty of browser-based handlers in differentiating CoAP 
usage in different environments (in this case, to differentiate using 
the URI for the LWM2M devkit as opposed to the Copper plug-in in Mozilla 
browsers).

So I'd appreciate your feedback: Should we establish recommendations, if 
so, is it sufficient to specify this in the document and if we 
shouldn't, then why not.

Thanks,
Bill

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 Jul 2015 15:16:00 +0200

(Chair hat off.)

> * Is coap+udp:// URI equivalent to a coap:// URI?

No.  Having two schemes for the same resource provides no benefit, but
splits up caches, creates interop problems etc.

Consistency is the hobgoblin of the little mind :-)

> coaps+sms:// is far easier to understand than coap+smss://

Given that coaps is not called coap+dtls, I beleive it is more
consistent to call the secure version of coap+tcp:// coaps+tcp://
Note that in the end scheme names are just opaque strings, and doing
arithmetic on them doesn't work very well.

> * Practical considerations: coap+lwm2m:// URI scheme 

???  Does something like that exist?   Ouch!

Encoding implementation selection preferences in URI schemes is leading
down a very dark road.

Grüße, Carsten

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Wed, 22 Jul 2015 13:39:36 +0000

Hi Bill,

>so, is it sufficient to specify this in the document and if we

Another point that I'd add to your list is:

* scheme compatibility from a caching perspective

which I think should boil down to just partitioning secure from insecure
transports, e.g.:

coap://x/y == coap+sms/x/y != coaps://x/y

Cheers, t

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 24 Jul 2015 06:04:42 +0530

Hi all,

I agree with Thomas that it is sufficient to have two URI schemes coap &
coaps.

I have provided the same comment to CoAP TCP draft as well.

Thanks
Partha

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of FOSSATI, Thomas
(Thomas)
Sent: Wednesday, July 22, 2015 7:10 PM
To: Bill Silverajan; [email-masked]
Subject: Re: [core] Alternative Transports: Yes/No consensus on URI scheme
governance

Hi Bill,

Cheers, t

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Bill Silverajan <[email-masked]>
Date: Fri, 24 Jul 2015 10:52:06 +0300

Hi Carsten, Thomas,

It seems both of you are in agreement that the draft should provide some 
sort of guidance about using the URI scheme.

However, I made those bullet points to illustrate examples of what could 
happen if we *don't* have guidance or governance. The question still 
remains.

To rephrase: Given the list of Do's and Dont's, do you see a need (and 
can it,actually) be taken further into a governance model for the alt 
transports URI schemes?

"Enforcement" seems too harsh a word, but I'd be happy to hear what 
mechanisms exist, so implementers can be comfortable the schemes they 
select won't be going against the spirit and design goals of why we 
decided on minting new "coap+<transport>" schemes.

I'll also add the pointer Thomas gave to my list of Do's and Dont's with 
the Alternative Transports URI scheme, in addition to the points Carsten 
made.

I'll appreciate your further thoughts on this, thanks.

Regards,
Bill