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

["Jim Schaad" <[e-mail]>]

 

 

From: Bert Greevenbosch [mailto:[e-mail]] 
Sent: Monday, January 19, 2015 10:56 PM
To: Jim Schaad
Cc: [e-mail]
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:[e-mail]] 发送时间: 2015年1月17日 10:34 收件人: [e-mail] 主题: 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 [e-mail] 



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:[e-mail]] 
发送时间: 2015年1月17日 10:34
收件人: [e-mail]
主题: 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
.