Subject: Re: [apps-discuss] ??: New round of comments on draft-greevenbosch-appsawg-cbor-cddl-04

From: "Jim Schaad" <[email-masked]>
Date: Wed, 21 Jan 2015 10:51:48 -0800

From: Bert Greevenbosch [mailto:[email-masked]] 
Sent: Monday, January 19, 2015 10:56 PM
To: Jim Schaad
Cc: [email-masked]
Subject: Re: ??: New round of comments on draft-greevenbosch-appsawg-cbor-cddl-04

Hi Jim,

Thank you for your comments. They are very helpful. Please find my answers below.

B.T.W.,would you mind including the apps-discuss mailing list in this discussion? It may be good for the chairs and others to see activity on this draft.

1. You have a length restriction on float, do you see a need for begin able to do length restrictions on int, tstr and bstr? I don't know if a restriction based on number of bytes or based on a value range would be better. It make sense to use the () syntax to specify a length restriction since you are already using it for float. 

I started out with such notation, e.g. "int(16)" for a 16-bit integer. However, there is a difference between ints and floats: for any integer number, it is easy to find out how much bits are needed. Hence we could allow some freedom in choosing the number of bits on a per-number basis on the encoder side. This was a comment from Carsten, and we subsequently removed the "int(16)" notation.

For floats, this is harder, as the number of bits does not depend on the value of the variable, but on the precision with which we want to represent that variable. For example, the value 1/3 can be represented using both a float(16) and a float(32), but the latter representation would be closer to the real value than the former.

[JLS] What I was looking for was a size limitation which might be helpful.  That is the integer that goes here is limited to 16 bits.

3. I will reiterate the request for some type of alternate syntax for types - i.e. TypeA or TypeB

I like your earlier proposed notation:

price: uint | float(16)

and think we can implement this in the next version of the draft.

2. You have removed the union/choice structure from the document. I highly recommend that this be added back in some form. 

I think we can use the same solution for (3) as well, as follows:

*smallStructure1 {
   dish: tstr;
   recipe: tstr;
}

*smallStructure2 {
   drink: tstr;
   price: int;
}

*BigStructure : {
   subStructure: smallStructure1 | smallStructure2; 
}

Interesting would be how to distinguish between smallStructure1 and smallStructure2. Especially in the following case:

*smallStructure1 {
   dish: tstr;
   recipe: tstr;
}

*smallStructure2 {
   drink: tstr;
   ingredients: tstr;
}

*BigStructure : {
   subStructure: smallStructure1 | smallStructure2; 
}

The last may need some more consideration.

[JLS] while one could use tags – is there a reason not to go back to the world of using an int field to discriminate?

4. A structure can be folded at the top level into a structure by not using the '*' operator on a type. Do you want to be able to do the same type of thing for a map?

Not sure about this. Do you have an example?

CDDL maps need a CBOR map encoding. A structure, however, does not necessarily require what I call an "encompassing array". Thus the encompassing array is signalled by the asterisk, because there is a choice.

[JLS]  If one looks at the COSE document that I am working on.  One can define three maps, one each for an EC key, for an RSA key and for a secret key.  One can then define a base key with common fields that are not algorithm specific.  One could then define  single map that included each of the other items into it by reference rather than as sub items.

COSE_KEY : map { base_key; rsa_key; ec_key; secret_key }

5. I don't understand the last example in section 4.5.1 - You are combining a structure and a map together into a single item. Would the syntax "ToString: map(., tstr)" be a better example? This is a map in this case and that is what you are talking about 

Yes, indeed this would be better:

toString: map( ., tstr );

(Notice the lower case "t" at the beginning, this is a convention I use for variable names, although it is not mandatory.)

Best regards,
Bert

On 19-01-15 01:59, Sunruinan wrote:

Hi Bert， I received such email from Jim. Since I can't find it in appsawg email list, I think this is a system automatic email, is it right? Can I find some web pages about these comments? As the title of this email, it means New round of comments. Are these comments has some relationship with the previous round comments? Thank you in advance for your reply! Best Regards! Ruinan -----邮件原件----- 发件人: Jim Schaad [mailto:[email-masked]] 发送时间: 2015年1月17日 10:34 收件人: [email-masked] 主题: New round of comments on draft-greevenbosch-appsawg-cbor-cddl-04 Here comes a new round of comments on the draft. I have tried not hit the same points again. 1. You have a length restriction on float, do you see a need for begin able to do length restrictions on int, tstr and bstr? I don't know if a restriction based on number of bytes or based on a value range would be better. It make sense to use the () syntax to specify a length restriction since you are already using it for float. 2. You have removed the union/choice structure from the document. I highly recommend that this be added back in some form. 3. I will reiterate the request for some type of alternate syntax for types - i.e. TypeA or TypeB 4. A structure can be folded at the top level into a structure by not using the '*' operator on a type. Do you want to be able to do the same type of thing for a map? 5. I don't understand the last example in section 4.5.1 - You are combining a structure and a map together into a single item. Would the syntax "ToString: map(., tstr)" be a better example? This is a map in this case and that is what you are talking about Jim . 

-- Bert Greevenbosch [email-masked] 

Best regards,
Bert

On 20-01-15 07:09, Sunruinan wrote:

Hi Jim,
Thank you for your comments!
Since Bert is original editor of this draft and more familiar with previous discussion, I forward your comments to his new email address.
He can give some answers.
 
Best Regards!
Ruinan Sun
Huawei
 
-----邮件原件-----
发件人: Jim Schaad [mailto:[email-masked]] 
发送时间: 2015年1月17日 10:34
收件人: [email-masked]
主题: New round of comments on draft-greevenbosch-appsawg-cbor-cddl-04
 
Here comes a new round of comments on the draft.  I have tried not hit the same points again.
 
1. You have a length restriction on float, do you see a need for begin able to do length restrictions on int, tstr and bstr?  I don't know if a restriction based on number of bytes or based on a value range would be better.  It make sense to use the () syntax to specify a length restriction since you are already using it for float.
 
2. You have removed the union/choice structure from the document.  I highly recommend that this be added back in some form.
 
3. I will reiterate the request for some type of alternate syntax for types
- i.e. TypeA or TypeB
 
4. A structure can be folded at the top level into a structure by not using
the '*' operator on a type.   Do you want to be able to do the same type of
thing for a map? 
 
5. I don't understand the last example in section 4.5.1 - You are combining a structure and a map together into a single item.  Would the syntax
"ToString: map(., tstr)" be a better example?  This is a map in this case and that is what you are talking about

Jim
.

---

From: Bert Greevenbosch <[email-masked]>
Date: Mon, 26 Jan 2015 11:30:15 +0100

Hi Jim,

Thank you for your feedback. Please find my response inline, preceded 
with "[BG]".

Best regards,
Bert

On 21-01-15 19:51, Jim Schaad wrote:
>
> *From:*Bert Greevenbosch [mailto:[email-masked]]
> *Sent:* Monday, January 19, 2015 10:56 PM
> *To:* Jim Schaad
> *Cc:* [email-masked]
> *Subject:* Re: ??: New round of comments on 
> draft-greevenbosch-appsawg-cbor-cddl-04
>
> Hi Jim,
>
> B.T.W.,would you mind including the apps-discuss mailing list in this 
> discussion? It may be good for the chairs and others to see activity 
> on this draft.
>
> /1. You have a length restriction on float, do you see a need for 
> begin able to do length restrictions on int, tstr and bstr? I don't 
> know if a restriction based on number of bytes or based on a value 
> range would be better. It make sense to use the () syntax to specify a 
> length restriction since you are already using it for float. /
>
> I started out with such notation, e.g. "int(16)" for a 16-bit integer. 
> However, there is a difference between ints and floats: for any 
> integer number, it is easy to find out how much bits are needed. Hence 
> we could allow some freedom in choosing the number of bits on a 
> per-number basis on the encoder side. This was a comment from Carsten, 
> and we subsequently removed the "int(16)" notation.
>
> For floats, this is harder, as the number of bits does not depend on 
> the value of the variable, but on the precision with which we want to 
> represent that variable. For example, the value 1/3 can be represented 
> using both a float(16) and a float(32), but the latter representation 
> would be closer to the real value than the former.
>
> [JLS] What I was looking for was a size limitation which might be 
> helpful.  That is the integer that goes here is limited to 16 bits.
>
[BG] Ah yes, that may be helpful. It would mean a slightly different 
meaning of "(16)" in "float(16)" and "uint(16)", but I could easily get 
used to that.
>
>
> /3. I will reiterate the request for some type of alternate syntax for 
> types - i.e. TypeA or TypeB
> /
> /2. You have removed the union/choice structure from the document. I 
> highly recommend that this be added back in some form. /
>
> Interesting would be how to distinguish between smallStructure1 and 
> smallStructure2. Especially in the following case:
>
> *smallStructure1 {
>    dish: tstr;
>    recipe: tstr;
> }
>
> *smallStructure2 {
>    drink: tstr;
>    ingredients: tstr;
> }
>
> *BigStructure : {
> [JLS] while one could use tags – is there a reason not to go back to 
> the world of using an int field to discriminate?
>
[BG] Any way of signalling to the application which of the two 
structures is meant is indeed required. This could be through an integer 
that contains a field-id, or in other ways e.g. through the semantics of 
the rest of the data structure. What I mean is, that it may be obvious 
to the application which structure is meant by inspecting earlier fields.

For automatic parsing of such structure, this would be much harder 
though. A complex parser could perform "best effort parsing", whereas a 
simpler parser could consider ignoring verification of variables with 
alternative structures as datatype. (Simple datatypes should be easy to 
handle for simple parsers too.)

>
> /4. A structure can be folded at the top level into a structure by not 
> using the '*' operator on a type. Do you want to be able to do the 
> same type of thing for a map?
> /
> CDDL maps need a CBOR map encoding. A structure, however, does not 
> necessarily require what I call an "encompassing array". Thus the 
> encompassing array is signalled by the asterisk, because there is a 
> choice.
>
> [JLS] If one looks at the COSE document that I am working on.  One can 
> define three maps, one each for an EC key, for an RSA key and for a 
> secret key.  One can then define a base key with common fields that 
> are not algorithm specific.  One could then define  single map that 
> included each of the other items into it by reference rather than as 
> sub items.
>
[BG] OK, I see, so you want to define a single base_key, and then only 
one of rsa_key, ec_key, secret_key. Something like:

map {
   "base_key": bstr;
   choice {
     "rsa_key": bstr;
     "ec_key" : bstr;
     "secret_key": bstr;
   }
}

(The choice construct doesn't exist in CDDL, I am just thinking here.)

With the issue of identifiers above in mind, one could think of 
something like a simple switch statement, which only takes primitive 
types as input. For example:

map {
   "base_key": bstr;
   "key_type": uint;
   switch("key_type") {
     0: "rsa_key": bstr;
     1: "ec_key": bstr;
     2: "secret_key": bstr;
   }
}

Maybe something to about further.

Best regards,
Bert

>
>
> /5. I don't understand the last example in section 4.5.1 - You are 
> combining a structure and a map together into a single item. Would the 
> syntax "ToString: map(., tstr)" be a better example? This is a map in 
> this case and that is what you are talking about
> /
> (Notice the lower case "t" at the beginning, this is a convention I 
> use for variable names, although it is not mandatory.)
>
> Best regards,
> Bert
>
>     Hi Bert， I received such email from Jim. Since I can't find it in
>     appsawg email list, I think this is a system automatic email, is
>     it right? Can I find some web pages about these comments? As the
>     title of this email, it means New round of comments. Are these
>     comments has some relationship with the previous round comments?
>     Thank you in advance for your reply! Best Regards! Ruinan -----邮
>     件原件----- 发 件人: Jim Schaad [mailto:[email-masked]] 发
>     送时间: 2015年1月17日 10:34 收 件人:
>     [email-masked]
>     <mailto:[email-masked]> 主题:
>     New round of comments on draft-greevenbosch-appsawg-cbor-cddl-04
>     Here comes a new round of comments on the draft. I have tried not
>     hit the same points again. 1. You have a length restriction on
>     float, do you see a need for begin able to do length restrictions
>     on int, tstr and bstr? I don't know if a restriction based on
>     number of bytes or based on a value range would be better. It make
>     sense to use the () syntax to specify a length restriction since
>     you are already using it for float. 2. You have removed the
>     union/choice structure from the document. I highly recommend that
>     this be added back in some form. 3. I will reiterate the request
>     for some type of alternate syntax for types - i.e. TypeA or TypeB
>     4. A structure can be folded at the top level into a structure by
>     not using the '*' operator on a type. Do you want to be able to do
>     the same type of thing for a map? 5. I don't understand the last
>     example in section 4.5.1 - You are combining a structure and a map
>     together into a single item. Would the syntax "ToString: map(.,
>     tstr)" be a better example? This is a map in this case and that is
>     what you are talking about Jim .
>
>
> <mailto:[email-masked]>
>
>
>
> Best regards,
> Bert
>
>     收件人:[email-masked]  <mailto:[email-masked]>
>

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 26 Jan 2015 08:26:53 -0800

From: Bert Greevenbosch [mailto:[email-masked]] 
Sent: Monday, January 26, 2015 2:30 AM
To: Jim Schaad
Cc: [email-masked]; [email-masked]
Subject: Re: ??: New round of comments on draft-greevenbosch-appsawg-cbor-cddl-04

Hi Jim,

Thank you for your feedback. Please find my response inline, preceded with "[BG]".

Best regards,
Bert

 

Hi Jim,

[BG] Ah yes, that may be helpful. It would mean a slightly different meaning of "(16)" in "float(16)" and "uint(16)", but I could easily get used to that.

price: uint | float(16)

*smallStructure1 {
   dish: tstr;
   recipe: tstr;
}

*smallStructure2 {
   drink: tstr;
   price: int;
}

*BigStructure : {

*smallStructure1 {
   dish: tstr;
   recipe: tstr;
}

*smallStructure2 {
   drink: tstr;
   ingredients: tstr;
}

*BigStructure : {

[BG] Any way of signalling to the application which of the two structures is meant is indeed required. This could be through an integer that contains a field-id, or in other ways e.g. through the semantics of the rest of the data structure. What I mean is, that it may be obvious to the application which structure is meant by inspecting earlier fields.

For automatic parsing of such structure, this would be much harder though. A complex parser could perform "best effort parsing", whereas a simpler parser could consider ignoring verification of variables with alternative structures as datatype. (Simple datatypes should be easy to handle for simple parsers too.)

[BG] OK, I see, so you want to define a single base_key, and then only one of rsa_key, ec_key, secret_key. Something like:

map {
  "base_key": bstr;
  choice {
    "rsa_key": bstr;
    "ec_key" : bstr;
    "secret_key": bstr;
  }
}

With the issue of identifiers above in mind, one could think of something like a simple switch statement, which only takes primitive types as input. For example:

map {
  "base_key": bstr;
  "key_type": uint;
  switch("key_type") {
    0: "rsa_key": bstr;
    1: "ec_key": bstr;
    2: "secret_key": bstr;
  }
}

[JLS} No I was not going to have a switch statement – I was just having all of the fields be part of the map.  Using field names is sufficient for distinguishing which set of fields I was looking for.

Best regards,
Bert

Best regards,
Bert

Hi Bert， I received such email from Jim. Since I can't find it in appsawg email list, I think this is a system automatic email, is it right? Can I find some web pages about these comments? As the title of this email, it means New round of comments. Are these comments has some relationship with the previous round comments? Thank you in advance for your reply! Best Regards! Ruinan -----邮件原件----- 发 件人: Jim Schaad [mailto:[email-masked]] 发 送时间: 2015年1月17日 10:34 收 件人: [email-masked] 主题: New round of comments on draft-greevenbosch-appsawg-cbor-cddl-04 Here comes a new round of comments on the draft. I have tried not hit the same points again. 1. You have a length restriction on float, do you see a need for begin able to do length restrictions on int, tstr and bstr? I don't know if a restriction based on number of bytes or based on a value range would be better. It make sense to use the () syntax to specify a length restriction since you are already using it for float. 2. You have removed the union/choice structure from the document. I highly recommend that this be added back in some form. 3. I will reiterate the request for some type of alternate syntax for types - i.e. TypeA or TypeB 4. A structure can be folded at the top level into a structure by not using the '*' operator on a type. Do you want to be able to do the same type of thing for a map? 5. I don't understand the last example in section 4.5.1 - You are combining a structure and a map together into a single item. Would the syntax "ToString: map(., tstr)" be a better example? This is a map in this case and that is what you are talking about Jim . 

Best regards,
Bert

Hi Jim,
 
Best Regards!
Ruinan Sun
Huawei
 
-----邮件原件-----
发件人: Jim Schaad [mailto:[email-masked]] 
发送时间: 2015年1月17日 10:34
收件人: [email-masked]
主题: New round of comments on draft-greevenbosch-appsawg-cbor-cddl-04

 

 

Jim
.