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

[Bert Greevenbosch <[e-mail]>]

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:[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.
>
[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
> /
> 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?
>
[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?
> /
> 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 }
>
[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
> /
> 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]
>     <mailto:[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] 
> <mailto:[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]  <mailto:[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
>
>     .
>
>       
>