Subject: Re: [core] Vendor-specific options

From: Alper Yegin <[email-masked]>
Date: Mon, 6 Feb 2012 11:43:41 +0200

On Jan 19, 2012, at 6:10 PM, TianLinyi wrote:

>> Are there other people who want to do something in this space?
> 
>  Not very much. They can do it in CoAP payload anyway. The vendor option can't convey enough info and may also be complex.
> 

I didn't understand this response from Tian. I think there is a misunderstanding about the proposal here. 

Without a well-defined vendor-specific option support, there is no way for a vendor (or a user, etc.) to be defining new options for its own use. 

I don't understand how "doing it in CoAP payload" as stated above can work.

Alper

> 
>> Creating a new registry for CoAP option vendor-IDs would be possible, but I'm not convinced yet we want to set this up.
>> Among other considerations, most companies in this space already need an enterprise number, so it is much more stealthy to use this instead of applying for a number out of a focused registry...
> This would cause too much effort for not very important thing. (again it can be done in CoAP payload)
> 
> Grüße, Carsten
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 6 Feb 2012 13:04:53 +0100

> I don't understand how "doing it in CoAP payload" as stated above can work.

I'll let Linyi speak for himself, but I think there is one important observation here.

In protocols like DHCP, RADIUS etc. (and PANA!), if you want to do something new, you need a new option/attribute/AVP/whatever.
There is one main extension point, and all evolution has to go through it.

In HTTP and CoAP, most evolution is going on in the URIs and the payloads.
When you need new semantics for a transfer, often building the right URIs into the server, and, possibly, defining a new media type, is all you need.
CoAP is just a transfer protocol, and this is the way to define new semantics *of* the transfer.
Only if you need new semantics *governing* a transfer, this is where you need new options.

So this is how I read "do it in the payload".

Grüße, Carsten

---

From: TianLinyi <[email-masked]>
Date: Tue, 07 Feb 2012 03:42:01 +0000

Hi, All

That's it. I agree with Carsten. Define a new media type is what I mean for doing it in payload.

Cheers,
Linyi

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Monday, February 06, 2012 8:05 PM
To: Alper Yegin
Cc: TianLinyi; core WG
Subject: Re: [core] Vendor-specific options

Grüße, Carsten

---

From: Alper Yegin <[email-masked]>
Date: Wed, 8 Feb 2012 12:24:44 +0200

Thank you Carsten, now I understand what Linyi meant.

I see the extensibility in the URI/media type direction, but I still think we need some leg room in the Options direction too. 

My 0.02 cents.

Alper

---

From: Zach Shelby <[email-masked]>
Date: Wed, 8 Feb 2012 12:44:19 +0200

I agree with Alper that there will be custom additions to CoAP needed in the future that fit best in an extensible option (related to the CoAP message or req/res level rather than the application). For application related extensions then URIs and media types are fine.

Should something like that be added to the base spec, I am not sure. If we are not in a hurry for it, then a separate specification in the future is fine.

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 Feb 2012 12:45:23 +0100

> Should something like that be added to the base spec, I am not sure. If we are not in a hurry for it, then a separate specification in the future is fine.

I think the interesting question is when are people going to need these, and what is the danger that they will they go ahead and ship something in a widely deployed product that will create a backwards compatibility headache for us.

Defining the vendor-specific option in the base spec would enable us to make very clear that squatting is not the way to go (by demonstrating the right way to go).  Keeping the option definition in coap-misc works for me, but has two disadvantages:

1) the details may not be vetted as well, possibly creating another headache later,
2) people might not find it, and/or may think what is in the personal draft is not relevant for "conformance".

In any case, we need to agree on and reserve the option number (is 14 it?), so we might as well standardize the option.

So far, the only thing I know that might need some more thought here is my "SDNV of enterprise ID" tagging proposal.  Putting option 14 into the base spec might get us some more input on that :-)

Grüße, Carsten