Subject: [COSE] Issue - Change the definition of label

From: "Jim Schaad" <[email-masked]>
Date: Wed, 13 Jan 2016 20:23:40 -0800

In a piece of mail, Hannes raised the following issue.

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

If we make this change, I would have it affect more than just label, it
would affect all of the registries.

Currently the definition of label is

label = uint / sint / tstring

That is a label can be an unsigned integer, a signed integer or a text
string.   I added the string to the definition of label in order to expand
the size of the registration space for two byte identifiers.  If we are
willing to accept the decrease of the availability of short labels then we
can easily remove tstring from the definition.

Part of the reason that is given by Hannes was the idea that this increases
the complexity for little gain.  The amount of complexity introduced is
going to depend for a large part on how the CBOR library is implemented and
the willingness of the programmer to make potentially incorrect assumptions.
(I am currently really guilty of doing this.) 

A correct implementation would check both the type of the field and the
value of the field.  An incorrect implementation would fold the two types
together and just check the value of the field.  This means that there is
already a requirement to have two case statements (or a small number of if
statements) in order to check if the value is correct.  Going from two to
three does not really add a great deal of complexity as the code for the
string case would be the same for short strings, it only becomes more
complicated if the strings are sufficiently long to require a string compare
rather than a cast followed by an integer compare.

While I have allowed for the registration space, I have very carefully
avoided doing any registrations in the string portion of the registry.  I
have however used this range extensively during code development for dealing
with items which I have not yet assigned code points to.  (I.e. the use of
ES384 rather than the -35 that I just recently assigned to it).

People have expressed concern about the small registration space, this is a
place where we are expanding it, but at some additional complexity.  Which
of the two items is more important?

I would like to resolve this by the end of next week.

Jim

---

From: Samuel Erdtman <[email-masked]>
Date: Fri, 15 Jan 2016 07:11:08 +0100

Hi Jim,

I like the idea of just having way to do thing i.e. only allow labels to be
one of the suggested datatypes uint / sint / tstring.

You say that doing so would limit the number of two byte identifiers to use
(clearly). To make an informed decision I think it would be good to know
how many two byte identifier we loos by selecting one of the datatypes for
labels. (The answer might be obvious but with my limited CBOR skills I
cannot see it).

Best regards
//Samuel

On Thu, Jan 14, 2016 at 5:23 AM, Jim Schaad <[email-masked]> wrote:

> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose
>

---

From: Samuel Erdtman <[email-masked]>
Date: Fri, 15 Jan 2016 07:16:31 +0100

I found the answer to my question in an earlier mail from you Jim

"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.)"

With this input I think the added value of string label is not worth the
added code complexity.

Best Regards
//Samuel

On Fri, Jan 15, 2016 at 7:11 AM, Samuel Erdtman <[email-masked]> wrote:

> Hi Jim,
>
> I like the idea of just having way to do thing i.e. only allow labels to
> be one of the suggested datatypes uint / sint / tstring.
>
> You say that doing so would limit the number of two byte identifiers to
> use (clearly). To make an informed decision I think it would be good to
> know how many two byte identifier we loos by selecting one of the datatypes
> for labels. (The answer might be obvious but with my limited CBOR skills I
> cannot see it).
>
> Best regards
> //Samuel
>
>
>
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 15 Jan 2016 10:05:03 +0100

The main reason to have string labels is to make it easier to coordinate
label use in the experimental, pre-registration phase.
More JSONy, and all that.

We could instead adopt a convention of goedelizing those strings into
numbers.
To give a real-world example for that: one CBOR tag was registered with
the number 22098.
That is 0x5652, or "RV" when read in a hex dump in LSB order (it is a
tag for Perl "Reference Value").  Makes debugging from a hex dump
slightly easier...
Of course, that only works well for 1, 2, 4, or 8 byte strings.

Grüße, Carsten

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 16 Jan 2016 12:07:33 -0800

I am not sure that I have a solid answer from you here.

You have said that there is enough space with just integer, but you have also said you want to only have one type. I want to make sure that you understand that in CBOR integer is two types and not one.  Thus in answer to your original question.  What you end up with is

Unsigned integer – 255 values

Signed integer – 255 values

Text strings – about 180 values (give or take)

Are you saying keep both of the integer types and drop the text type or are you saying use only one of the integer types?

Jim

From: Samuel Erdtman [mailto:[email-masked]] 
Sent: Thursday, January 14, 2016 10:17 PM
To: Jim Schaad <[email-masked]>
Cc: cose <[email-masked]>; Hannes Tschofenig <[email-masked]>
Subject: Re: [COSE] Issue - Change the definition of label

"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.)"

With this input I think the added value of string label is not worth the added code complexity.

Best Regards

//Samuel

On Fri, Jan 15, 2016 at 7:11 AM, Samuel Erdtman <[email-masked] <mailto:[email-masked]> > wrote:

Hi Jim,

I like the idea of just having way to do thing i.e. only allow labels to be one of the suggested datatypes uint / sint / tstring.

You say that doing so would limit the number of two byte identifiers to use (clearly). To make an informed decision I think it would be good to know how many two byte identifier we loos by selecting one of the datatypes for labels. (The answer might be obvious but with my limited CBOR skills I cannot see it).

Best regards

//Samuel

 

On Thu, Jan 14, 2016 at 5:23 AM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

Jim

_______________________________________________
COSE mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/cose

---

From: Samuel Erdtman <[email-masked]>
Date: Sun, 17 Jan 2016 13:39:40 +0100

To really get the desired simplification of the code I think we should go
for only one of the integer options.

If I look at the JOSE specifications and the number of labels defined there
I get the following by doing a quick look through.
JWS (https://tools.ietf.org/html/rfc7515) has 11 registered header
parameter (if I´m counting correctly)
JWT (https://tools.ietf.org/html/rfc7515) has 2 header parmeters and 7
claims names (if I´m counting correctly)
JWE (https://tools.ietf.org/html/rfc7516) has 13 registered header
parameter (if I´m counting correctly)
JWA (https://tools.ietf.org/html/rfc7518) has 10 registered header
parameter and 14 key parameters (if I´m counting correctly)
They come from different context so some of them could overlap without
problem e.g. header parameters and claims does not share context and can
thus the same numbers could be reused. If we despite this sum all of them
we end up at 57 i.e quite a good margin to 255 and when we have reached
that limit I guess we could have three byte identifiers.

With this said I don´t have a strong opinion but I prefer this choice.

Best Regards
//Samuel

On Sat, Jan 16, 2016 at 9:07 PM, Jim Schaad <[email-masked]> wrote:

> You have said that there is enough space with just integer, but you have
> also said you want to only have one type. I want to make sure that you
> understand that in CBOR integer is two types and not one.  Thus in answer
> to your original question.  What you end up with is
>
>
>
> Are you saying keep both of the integer types and drop the text type or
> are you saying use only one of the integer types?
>
>
>
> Jim
>
>
>
>
>
> *From:* Samuel Erdtman [mailto:[email-masked]]
> *Sent:* Thursday, January 14, 2016 10:17 PM
> *To:* Jim Schaad <[email-masked]>
> *Cc:* cose <[email-masked]>; Hannes Tschofenig <[email-masked]>
> *Subject:* Re: [COSE] Issue - Change the definition of label
>
>
>
> "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.)"
>
>
>

---

From: Derek Atkins <[email-masked]>
Date: Thu, 21 Jan 2016 11:21:26 -0500

Hi

> Of course, that only works well for 1, 2, 4, or 8 byte strings.

Coming at this a week later, but I'm with Carsten.  I think allowing
string labels (in general) is extremely useful for extension
prototyping, or for making "private-use" data structures that could have
a low probability of clashing with someone else's private-use label.

I'll note that the code required to support all three data types
(sint/uint/tstring) is NOT significant, and frankly IMHO it does not add
much complexity.

> Grüße, Carsten

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 21 Jan 2016 15:28:35 -0800

You are not too late to weigh in on this issue, however you have made it impossible for me to say that there is a consensus one way or the other on it.  There is basically an even split.

Chairs can you please weight in?

Jim

> -----Original Message-----
> From: Derek Atkins [mailto:[email-masked]]
> Sent: Thursday, January 21, 2016 8:21 AM
> To: Carsten Bormann <[email-masked]>
> Cc: Jim Schaad <[email-masked]>; [email-masked]
> > The main reason to have string labels is to make it easier to
> > coordinate label use in the experimental, pre-registration phase.
> > To give a real-world example for that: one CBOR tag was registered
> > with the number 22098.
> Coming at this a week later, but I'm with Carsten.  I think allowing string labels
> (in general) is extremely useful for extension prototyping, or for making
> "private-use" data structures that could have a low probability of clashing with
> someone else's private-use label.
> 
> (sint/uint/tstring) is NOT significant, and frankly IMHO it does not add much
> complexity.
> 
> > Grüße, Carsten
> 
> -derek
> --

---

From: Mike Jones <[email-masked]>
Date: Fri, 22 Jan 2016 06:02:23 +0000

String labels are very valuable.  Please keep them.

				-- Mike

-----Original Message-----
From: COSE [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Thursday, January 21, 2016 3:29 PM
To: 'Derek Atkins' <[email-masked]>; 'Carsten Bormann' <[email-masked]>
Cc: [email-masked]
Subject: Re: [COSE] Issue - Change the definition of label

Jim

> > We could instead adopt a convention of goedelizing those strings 
> > into numbers.
> > That is 0x5652, or "RV" when read in a hex dump in LSB order (it is 
> > a tag for Perl "Reference Value").  Makes debugging from a hex dump 
> > slightly easier...
> prototyping, or for making "private-use" data structures that could 
> have a low probability of clashing with someone else's private-use label.
> 
> (sint/uint/tstring) is NOT significant, and frankly IMHO it does not 
> add much complexity.
> 
> > Grüße, Carsten
> 
> -derek
> --

---

From: Justin Richer <[email-masked]>
Date: Sun, 24 Jan 2016 16:29:10 -0500

The chairs have discussed the issue in this thread. There seems to be almost equal support for both aspects, with a rough preference for allowing strings to aid in certain scenarios, particularly development and debugging. As such the chairs have decided to continue to allow strings as labels. More specifically, to allow the uint/sint/tstring data type as defined currently. 

The argument against having this is one of code complexity, which we certainly hear. Therefore, if those who would like to see the label simplified can demonstrate the difference in code complexity overhead cased by this decision, with actual concrete COSE code to compare, then the working group can reconsider. 

Thank you all for the discussion, 

 — Justin & Kepeng, your COSE Chairs

        .-===-.
        | . . |
        | .'. |
       ()_____()
       ||_____||
   jgs  W     W

> On Jan 21, 2016, at 6:28 PM, Jim Schaad <[email-masked]> wrote:
>