Require publicly visible stable specifications for IANA registrations

[selfissued]

The COSE Header Parameter Registry in Section 15.2 describes the “specification” registration parameter as “This contains a pointer to the specification defining the header field (where public).” It’s not reasonable for people to be able reserve values in our registries without providing a publicly visible stable specification defining the meaning of the value. Please delete the “(where public)” and similar phrases such as “(if publicly available)” and “if one exists” from all the registries.

[jimsch]

You seem to have missed the entire purpose of the private registration section of the registry. The entire object is to allow for individuals and companies to register the usage of a code point and allow for it to be assigned specifically to that owner for a specific purpose. There are many reasons for not wanting to provide a specification for an item to the general public, including doing testing of some type.

Nothing should be done to address this issue except close it.

[selfissued]

If we were registering a plentiful resource, then I would agree with you, but there's a limited quantify of short integers, which is what we're talking about registering there. It's not too much to ask for a publicly visible specification saying what a value means so that it can be used in an interoperable manner in exchange for dedicating one of the rare small integers. For testing, private use values can be used from the <-65536 range, which needn't be registered, so the needs for private testing and private deployments would still be met.

[jimsch]

The range for first come, first serve, which is where I would expect this to be generally done, starts with the > 65536 range. The private range works for testing, but not for deployment except for closed systems. Numbers in the lower positive range could be issued on a early basis in which case the specification might not be immediately required. Again a case where the spec is not registered. There is no real shortage of points to register in and there would be more careful monitoring of the smaller number range.

[selfissued]

As far as I can tell, there was no action taken in response to this issue. I therefore request that either the action taken be pointed out so that it can be reviewed or the issue be reopened. Thank you.

At a minimum, I would suggest that the instructions to the designated experts be updated to incorporate a description of the number allocation discipline Jim suggests. In particular, the "careful monitoring of the smaller number range" should be described. I would think that this monitoring should include requiring a publicly visible specification as a condition for allocating this scarce resource.

[hannestschofenig]

Here are my thoughts on the topic Mike raised.

In summary, the COSE Header Parameter Registry contains an address space that is divided into different ranges (each with a different policy), namely: [I only focus on the integer values below.]

• 1 - 255: Standards Track Document required.
• 256 - 65535: Specification Required
• 65535>: first come, first served
• -1 to -65536: delegated to the "COSE Header Algorithm Label" registry.
• Integer values beyond -65536: private use.

I agree with Mike that we should require a publically available specification with some level of review. The First Come, First Served policy does not give us what we want. For this reason, I would get rid of the first come, first serve registry range and merge it with the Specification Required range. I believe we will increase interoperability when companies are not introducing random parameters but the bar with specification required is not that high either.

Additionally, I also don't like the idea of having a label be either an integer or a string. Why cannot we just use integers? This sounds like introducing options for no good reasons that just increase the implementation complexity.

The text in the first paragraph of Section 16.2. "COSE Header Parameter Registry" of https://tools.ietf.org/html/draft-ietf-cose-msg-08#section-16.2 says: " The registery is to be created as Expert Review Required."

This is clearly wrong given the text that follows afterwards. I suggest that this sentence is removed.

[jricher]

Re-opening for further discussion.

[selfissued]

See the thread with Jim and I discussing this at https://mailarchive.ietf.org/arch/msg/cose/okLF3q9KvRg-FmacxJlJKCytJJE.

[selfissued]

If a message sent by your system to my system requires interoperability on the use of a code point, then it should be registered and a public description should be available of what it means, which is necessary for interoperability among non-affiliated parties.

Asking people to define what a code point means at the time it's being registered is by no means onerous.

Since this action has not been taken, it is incorrect to categorize this issue as "complete". Also, like other issues, it would be useful to have others weigh in beyond Jim and myself.

[jimsch]

If a message is sent from my system to your system and it is not required that you understand the attribute, then it is necessary that you do not define an attribute at the same code point and it is not necessary that you understand this code point.

Information that is company private should be able to remain company private and it should be able to be updated at any time by the company without having to publish new documents.

This is what this allows for and is a totally reasonable issue. This corresponds to using the public header parameter names defined in JOSE.