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

From: Mike Jones <[email-masked]>
Date: Mon, 11 Jan 2016 20:35:34 +0000

I don't think that registering COSE values without making a specification publicly available so that the registered value can be understood and having private header parameter names in JOSE, which are not registered, are equivalent.  The difference is that in the current COSE methodology, it's possible to have registered values but no way for implementers to follow a link from the registry to understand what the meaning of the value is.  In JOSE, if it's registered, there's always a link from the registry to the definition.  That seems a lot more consistent and useful to me, hence my request for the change.

I'm fine with private values for private usages.  Just don't register them.  Registrations should all be specification-required.

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Monday, December 21, 2015 4:32 PM
To: Mike Jones <[email-masked]>
Cc: [email-masked]
Subject: RE: [cose-issues] Require publicly visible stable specifications for IANA registrations (#39)

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

---

From: Mike Jones <[email-masked]>
Date: Mon, 11 Jan 2016 14:28:06 -0800

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

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

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 11 Jan 2016 16:47:32 -0800

So you are saying that there is not a problem as long as we don't register the fact that we are using a code point for identifying the private item we are using.  Even though we might be using the same code point to mean different things and a message set by my system might be received by your system.

The need for registration is because there is not the ability that JOSE has where there is a statement about trying to use private identifiers that are somehow scoped to be private.  The world of identifiers for COSE maps closer to that of the public but unregistered world of JOSE.

Jim

> From: Mike Jones [mailto:[email-masked]]
> Sent: Monday, January 11, 2016 12:36 PM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]
> I don't think that registering COSE values without making a specification publicly
> available so that the registered value can be understood and having private
> header parameter names in JOSE, which are not registered, are equivalent.  The
> difference is that in the current COSE methodology, it's possible to have
> registered values but no way for implementers to follow a link from the registry
> to understand what the meaning of the value is.  In JOSE, if it's registered,
> there's always a link from the registry to the definition.  That seems a lot more
> consistent and useful to me, hence my request for the change.
> 
> I'm fine with private values for private usages.  Just don't register them.
> Registrations should all be specification-required.
> 
> 				-- Mike
> 
> 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
>