search

cbor-wg / cddl-more-control

Second extension pack of CDDL control operators after RFC 9165
Other
0 stars 1 forks source link

Maybe more standards-oriented language for section on byte strings? #7

Open laurencelundblade opened 3 months ago

laurencelundblade commented 3 months ago

For example, 

The target of .b64u MUST be a text string type
The controller MUST be a byte string type (or a text string type)

Maybe add columns to the table of operators to indicate the types of the target and controller? I think someone implementing this needs to know what the types allowed for the target and controller are.

Other language in the section could be more specification-like using MUST more and such.

cabo commented 3 months ago

The question would be what is the target of the MUST. Are you describing what a specification writer is supposed to do? That would require defining what a "text string type" is -- CDDL rules are more complex than that. Are you describing what a data item is supposed to look like? The approach in a data modeling language is that you can try a match with anything and will get "match" or "no match". So I think the language needs to be on this level, not 2119 "interoperability requirements".

laurencelundblade commented 3 months ago

I think the MUSTs should be directed at the authors of CDDL validation tools. It can say "MUST match xxx". I think that will work well for those writing specifications in CDDL too.

Interoperability and clarity are just as important here as in any other IETF document, so I think 2119 language is applicable.

When I was working on EAT, Hannes made the comment to me that I should use more requirement-oriented language. I think he was right. I reworked a lot of the language and EAT is much better for it.

cabo commented 3 months ago

It's easy to get a lot of "2+2 MUST be 4", while still struggling to explain the concept of addition in general. The examples you gave above are not statements about the tools and what they MUST do. (I think a single "MUST work right" would work best, but wouldn't add anything either.) I think it is useful to attempt to further some truth in advertising about what a specific kind of tool is, such as a validating tool. We could spend some time setting up a taxonomy. I think that will change a lot in the next round where we add annotations as a first order concept, so now would not be the best time to do that work.