Subject: [COSE] Label vs integer for keys

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

Hannes,

The reason for allowing both strings and integers for keys was to maximize the amount of short encoding registration space that is available.  Using just integers already introduces the problem that there are actually two different encodings that need to be taking into account, non-negative and negative integers.  Depending on how the library works for decoding this means that one needs to deal with that for doing key lookups.  If that is the case then adding the text version does not seem to be a huge factor.

If we allow only integers to be used, then there is a maximum of 255 + 255 values that can be encoded as a two bytes (a portion of those are actually encoded as single bytes).  If we add the text string to that then we allow for an additional 180 points where we can have a single byte encoding be added.  (Respecting the UTF8-ness of the field shrinks it slightly.)

I think that the additional small encoding space makes up for the slight complication in matching tag headers.

Jim

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> .  <https://github.com/notifications/beacon/AEt4dS5SbRpcQ-u05bpDUox1eztVMVDvks5pObaNgaJpZM4GZqZb.gif>