Subject: Re: [COSE] [cose-issues] Require publicly visible stable specifications for IANA registrations (#39)

From: Justin Richer <[email-masked]>
Date: Thu, 10 Dec 2015 14:07:32 -0800

Re-opening for further discussion.

---
Reply to this email directly or view it on GitHub:
https://github.com/cose-wg/cose-issues/issues/39#issuecomment-163763417

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 10 Dec 2015 15:19:24 -0800

The text on expert review was inserted at IANA’s request.  

I think that the text we may want to change is the first come, first server.  However, I don’t see any problems with saying that it is first-come, first serve and still require the expert review portion.

From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Thursday, December 10, 2015 10:06 AM
To: cose-wg/cose-issues <[email-masked]>
Cc: Jim Schaad <[email-masked]>
Subject: Re: [cose-issues] Require publicly visible stable specifications for IANA registrations (#39)

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. 

—
Reply to this email directly or view it on GitHub <https://github.com/cose-wg/cose-issues/issues/39#issuecomment-163704771> .

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 21 Dec 2015 16:31:34 -0800

Mike,

I was wondering if you could address what might be seen as a change in your attitude to this over time.

The JOSE specifications allow for a privately defined header field to be created.

Something similar to the current COSE allocations is done in the JOSE documents by the following:

Registered Header Parameter Names in JOSE:  This corresponds to the general area of Specification Required assignment area of COSE documents.  I note that although a reference to a document is required, it implicitly but does not explicitly require that the document be publicly available. 

Public Header Parameter Names in JOSE: This correspond to the set of first-come, first serve assignment area of COSE documents.  JOSE deals with this by saying that it should be collision resistant by prefixing (or some other method) to make the name statistically unique.  For COSE it would not be possible to have any degree of uniqueness of the headers in the same way while still maintaining the desire to have very short identifiers.  There is a big difference in size between "http://example.org/COSE/foobar" and 0x100000 when doing the encodings in CBOR.

Private Header Parameter Names in JOSE:  This corresponds to the private registry assignment area of COSE documents.

It would appear from this that there is an implicit registry area for JOSE which allows for a section header parameters which does not have publicly available specifications when implicitly registered.  To wit, the Public Header Parameter Names.

I am not sure if this really represents a change in your opinions or if you have just not considered these as being equivalent.

Jim