Subject: [core] Vendor-specific options

From: Alper Yegin <[email-masked]>
Date: Wed, 18 Jan 2012 19:27:18 +0200

Hello,

Is there a specific reason why vendor-specific options are not supported by CoAP?
Shall that be added?

Alper

---

From: Likepeng <[email-masked]>
Date: Thu, 19 Jan 2012 00:25:38 +0000

Hi,

> Is there a specific reason why vendor-specific options are not supported by CoAP?

Vendors can choose any unused numbers for vendor-specific options. I can say, it is already supported. 

> Shall that be added?

Do you mean, standardize a specific number for this purpose? I don’t see the need.

Thanks,
Kind Regards
Kepeng
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Alper Yegin
发送时间: 2012年1月19日 1:27
收件人: core WG
主题: [core] Vendor-specific options

Hello,

Alper

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

---

From: TianLinyi <[email-masked]>
Date: Thu, 19 Jan 2012 05:53:49 +0000

Hi, Alper

Do you mean reserve a range of option numbers for vendor specific extensions?

Cheers,
Linyi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Likepeng
Sent: Thursday, January 19, 2012 8:26 AM
To: Alper Yegin; core WG
Subject: Re: [core] Vendor-specific options

Hi,

Thanks,
Kind Regards
Kepeng
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Alper Yegin
发送时间: 2012年1月19日 1:27
收件人: core WG
主题: [core] Vendor-specific options

Hello,

Alper

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 19 Jan 2012 07:43:00 +0100

> Is there a specific reason why vendor-specific options are not supported by CoAP?

I have proposed one way to do them in coap-misc, section 4.
If the WG believes that this is a necessary mechanism (and that the specific way I have proposed to do it is the right way), we should move it over to core-coap.

Grüße, Carsten

---

From: Alper Yegin <[email-masked]>
Date: Thu, 19 Jan 2012 12:46:24 +0200

> If the WG believes that this is a necessary mechanism (and that the specific way I have proposed to do it is the right way), we should move it over to core-coap.

I think this makes sense. Let's call it vendor-specific option, not user-defined option though.

Alper

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 19 Jan 2012 12:29:04 +0100

On Jan 19, 2012, at 11:46, Alper Yegin wrote:

> Let's call it vendor-specific option, not user-defined option though.

(Option names are a bike shed color decision, so I'm sorry for responding to this, but:

You don't have to sell anything to define such an option :-)

But given all the "vendoring" that is going on, I don't have a strong opinion.)

                    .oOo.

Now back to the question:

> I think this makes sense.

Are there other people who want to do something in this space?

                    .oOo.

Let me quickly explain why I think the obvious approaches don't work:

1) Just squatting on option numbers.

This creates a lot of problems in other protocols.
Products that use squatted-on option numbers get deployed and make the number unavailable for any further use (even if the product then fades out).
Squatting is somewhat more acceptable for text-named options (lower probability of collision), but works very badly for a small number space.
Even more so as there are "good" and "worse" numbers (amount of fence posting required): the small numbers will be quickly squatted away for vendor vanity options, and we get to assign 93 for the next standards-based option.
There is a reason why coap-core defines the option number space as:

   The IANA policy for future additions to this registry is "IETF
   Review" as described in [RFC5226].

2) Defining a small "experimental" range.

This essentially means all the squatting is focused on a small range.
This works so badly in practice that tcpm has a draft trying to define a way to survive their current setup.

	draft-touch-tcpm-experimental-options-00.txt

TCP options and CoAP options pose related requirements, but are not the same.

I think Joe and I developed our proposals in parallel, from the same kind of thinking.
Joe is prepared to spend 32 bits for option identification, I'm *trying* to be a bit more frugal, but that works only very well for vendors (here they are again) that have been in play for long enough to have a 14-bit or smaller enterprise ID.
(16384 is "California State Polytechnic University, Pomona"…)

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...

Grüße, Carsten

---

From: TianLinyi <[email-masked]>
Date: Thu, 19 Jan 2012 16:10:28 +0000

>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.

> 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