Subject: [core] Range issue in core-parameters registry

From: Michelle Cotton <[email-masked]>
Date: Thu, 23 Jul 2015 12:15:36 +0000

Hello!

After consultations with Barry Leiba and the expert for the core-parameters
registry (Zach Shelby) we believe that the range descriptions in the
following registry may be backwards:

http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#conten
t-formats

The registration procedures as defined in RFC 7252 are as follows:

0-255            Expert Review
256-9999      IETF Review or IESG Approval

It has been suggested that possibly an errata is needed to reverse the
ranges so the Expert Review range is much larger.
Any issues with this plan?  Thoughts?  Comments?

I have copied the designated expert for this registry as well.

Thank you,

Michelle Cotton
Protocol Parameters Engagement Manager
IANA Department
ICANN

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 23 Jul 2015 14:29:57 +0200

The range 256-9999 has been put away for the great unification of media
type and content format registries, something we haven't quite gotten to
(it will involve some discussion of updating existing registries etc.).

TL;DR: Everything is as it should be.

That said, the instructions for the expert about 0..255 are not very
specific.  The idea is of course not to use up that space in a jiffy, so
some pushback is expected from the expert; the preference for allocating
these golden 1-byte numbers should go to IETF review specifications.

Grüße, Carsten

Michelle Cotton wrote:
> Hello!
> 
> After consultations with Barry Leiba and the expert for the
> core-parameters registry (Zach Shelby) we believe that the range
> descriptions in the following registry may be backwards:
> 
> http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Zach Shelby <[email-masked]>
Date: Thu, 23 Jul 2015 05:44:19 -0700

Carsten,

Yes, the 0..255 range should be used sparingly, preferably for widely used RFCs and CoRE specifications. No problem here.

The problem is what to do with other requests? Since we have not done a great unification of media types, we are now getting requests for those on a one-by-one basis as they come into use on CoAP. The natural place to assign these would be 256-9999, the jump from 255 to 10000 is pretty extreme. I would prefer to use the experimental range for things that really are experimental, and assign requests based on solid specifications to 256-9999.

Maybe time to give up on the great unification experiment? We need to do it very soon, or end up with a bunch of duplicates.

Zach

>> Protocol Parameters Engagement Manager

Zach Shelby
Vice President, Marketing
ARM Internet of Things BU
www.arm.com
US: +1 (408) 203-9434
Finland: +358 407796297
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: Michelle Cotton <[email-masked]>
Date: Mon, 27 Jul 2015 22:49:03 +0000

Any resolution of what needs to be done here?

Thanks in advance.

Michelle Cotton

On 7/23/15, 5:44 AM, "Zach Shelby" <[email-masked]> wrote:

>Carsten,
>
>Yes, the 0..255 range should be used sparingly, preferably for widely
>used RFCs and CoRE specifications. No problem here.
>
>The problem is what to do with other requests? Since we have not done a
>great unification of media types, we are now getting requests for those
>on a one-by-one basis as they come into use on CoAP. The natural place to
>assign these would be 256-9999, the jump from 255 to 10000 is pretty
>extreme. I would prefer to use the experimental range for things that
>really are experimental, and assign requests based on solid
>specifications to 256-9999.
>
>Maybe time to give up on the great unification experiment? We need to do
>it very soon, or end up with a bunch of duplicates.
>
>Zach
>
>-- IMPORTANT NOTICE: The contents of this email and any attachments are
>confidential and may also be privileged. If you are not the intended
>recipient, please notify the sender immediately and do not disclose the
>contents to any other person, use it for any purpose, or store or copy
>the information in any medium.  Thank you.
>
>ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>Registered in England & Wales, Company No:  2557590
>ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>Registered in England & Wales, Company No:  2548782
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 28 Jul 2015 04:55:33 +0200

> The problem is what to do with other requests? Since we have not done a great unification of media types, we are now getting requests for those on a one-by-one basis as they come into use on CoAP.…

There is no difference in quality between an assigned value of 256 and
an assigned value of 10123 -- both need two bytes in the packet.

> Maybe time to give up on the great unification experiment? We need to do it very soon, or end up with a bunch of duplicates.

To me it seems we should accelerate the unification.
The most expedient approach would be to simply assign the values from

	https://svn.tools.ietf.org/svn/wg/core/mediatypes.txt

for each combination of an existing media type and the identity content
coding that is being requested.  (Note how this file grows over time by
(pseudo-)randomly assigning numbers to new media types, while keeping
the assignments of old media types stable.)  We probably need to write
up how this happens in order to satisfy the "reserved for future use in
IETF specifications (IETF Review or IESG Approval)" requirement of RFC
7252.  For a while, we can continue generating these numbers in the WG,
but ultimately it should be IANA that is generating the numbers
alongside a media type registration.

Grüße, Carsten