Subject: Re: [apps-discuss] New draft: "CBOR data definition language: a notational convention to express CBOR data structures."

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 6 Jan 2014 23:25:03 +0000

Interesting.  Based on experience with XML, calling this "schema" may set
the expectation that this information might be used to validate inputs or
generate special-purpose parsers.  Both of these approaches are fraught
with peril in the real world.  Your requirement G7 in section 2 will lead
people toward the attractive nuisance.

I do agree it would be nice to have a consistent ABNF-like mechanism for
specifying CBOR protocols, but the types of protocols you are envisioning
seem to be a little less self-describing than the kinds of JSON protocols
that are more resilient to change over time.  The typical approach for
these is maps that have a set of keys defined for the first version, with
receivers instructed to ignore any map value they don't understand.  In
subsequent versions, new map values can be added safely.  Your section 4.5
doesn't have the nuance yet to handle this approach.

Sections 4.3-4.5, include simple examples.

Section 4.4, the idea of structs that don't have corresponding CBOR wire
protocol is odd, except as a mechanism to make the schema syntax more
readable.  I'm not sure if that's useful enough in practice.

Section 4.6, the const type does seem less useful than it is complex to
me, as you point out at the end of the section.

Section 4.8, optional values seem to me like they're going to cause
interop problems, particularly if the struct isn't defined in the *
(array) form.

Overall, I think you've got something a little more complicated than it
could be to solve the slightly smaller problem that is safe (ish) to solve.

On 1/1/14 11:06 PM, "Bert Greevenbosch" <[email-masked]>
wrote:

>Hello all,
> 
>I have uploaded the following draft:
>https://datatracker.ietf.org/doc/draft-greevenbosch-appsawg-cbor-cddl/
> 
>The draft introduces a notation to express CBOR data structures.
> 
>CBOR has recently been defined in RFC 7049. It is a general binary data
>format, which can be used to encode data in a structural way. Next to
>general data fields such as "integer" and "string", CBOR also supports
>signalling
> of e.g. arrays and maps.
> 
>RFC 7049 does not define how to write down CBOR data structures in
>specifications. I think it would be useful to have a standardised way for
>this, hence this new draft.
> 
>Since there is no working group chartered to do CBOR work, I have
>uploaded it as input to the general Applications Area working group.
> 
>I look forward to discussions on this, both technical and procedural. :-)
> 
>I wish you all a happy 2014!
> 
>Best regards,
>Bert
>
>

-- 
Joe Hildebrand

---

From: Bert Greevenbosch <[email-masked]>
Date: Fri, 10 Jan 2014 02:50:02 +0000

Hi Joe,

Thanks a lot for your feedback. Please find my response inline.

> people toward the attractive nuisance.

Indeed XML schema is too complex, and I have no intention to develop something as complex as that.

I think making the syntax machine processable gives a good chance to define unambiguous data structures. The main goal, however, is to have a way to express CBOR data structures in standards.

> doesn't have the nuance yet to handle this approach.

Yes, indeed it may make sense to add a notation for map keys, and text about ignoring unknown keys.

> Sections 4.3-4.5, include simple examples.

I'll add some examples.

> readable.  I'm not sure if that's useful enough in practice.

Indeed the mechanism was included for readability.

> me, as you point out at the end of the section.

Yes, its current "const" mechanism certainly is too complex, so there will be pruning. I'll think how much of it may make sense to remain, or do you think we should remove it completely and let protocols define such values in their textual descriptions?

> interop problems, particularly if the struct isn't defined in the *

Indeed that is a problem, as indicated at the end of the section. I see a use for optional fields, so it would be good to express them somehow. The current optional field mechanism, however, does lead to possible ambiguity in the code, and thus possible issues when machine processing the data without a proper context.

An alternative would indeed be using maps for optional fields, since then the receiver has a hint from the map on the existence of such optional field, and can ignore it safely.

However that would lead to more bytes, which may be undesirable depending on the protocol that is being specified, especially when it can already determine the availability of the optional field in other ways.

This requires more thought. :-)

> could be to solve the slightly smaller problem that is safe (ish) to

Thanks again for your feedback. This is just v00 of the draft, so I would be happy to simplify things and reduce complexity.

Best regards,
Bert