Re: [Cbor] 🔔 Confirmation call for Working Group Adoption for draft-greevenbosch-appsawg-cbor-cddl

> On Jul 19, 2017, at 6:26 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 20/07/2017 03:50, Sean Leonard wrote:
>> As expressed at the IETF 99 meeting, I support WG adoption of this draft.
> 
> Yes
> 
>> At this time, I also support it being on the Informational track (its current track). The track can be changed later if needed.
> 
> It's needed now. The IESG just approved at least one draft that has it as
> a normative reference. How else do you plan to precisely specify CBOR
> message formats?

“Need” is a very subjective word. It is nice to have. It is better to have a stable reference. But “stable references” are also harder to make technical changes to as more people rely on it and come up with arguments for how things can never change because they already wrote/deployed stuff.

It’s not just the documents that reference this one: it’s also the documents that CDDL references. By way of example, CDDL depends on regular expressions, and specifically calls out PCRE. PCRE is great but is in no way a Standard; it’s a single implementation. There is a lot of variation in regular expression engines, and the most useful ones (thinking about PCRE, Python, Perl, and .NET) are not SDO standards. There are some features in this draft that have not even been implemented yet.

There are other examples of documents (most notably, JSON) that started off as Informational and got promoted to Standards Track later.

CDDL is descriptive (data description language), rather than prescriptive. Sections 4.1 and 4.2. It currently falls far more into the Markdown-esque side of things (Postel’s Law), rather than the XML schema-esque side of things (all errors are fatal). “The matter in how far the data description must be enforced by an application is left to the designers and implementers of that application […].” This is a Good Thing. One glaring point is that a CDDL grammar does not exclusively define all possibilities. You can define a struct with members {foo: tstr, bar: tstr, baz: uint} in CDDL. What if the data contains {foo: “a”, bar: “b”, baz: 6, fred: ‘ffdeff’} ? What if you have {foo: -1}? CDDL doesn’t say whether those are fatal errors. That’s okay, Postel’s law and all. It means that a CDDL processor can be implemented in far less code for resource-constrained devices. But there may be very serious security considerations.

For now, you can precisely define your CBOR message format using prose. Or you can use some combination of CDDL and prose. Just reference CDDL informatively.

As has been pointed out, it’s a one-line change, and it can be done later.

Best regards,

Sean

> 
>    Brian
> 
>> 
>> Sean
>> 
>>> On Jul 5, 2017, at 2:48 AM, Francesca Palombini <francesca.palombini@ericsson.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> At the IETF98 meeting, we had in-room consensus to adopt draft-greevenbosch-appsawg-cbor-cddl as a starting point to work on CBOR data definition language. The authors have now updated the document and feel this is ready to be a wg item.
>>> 
>>> This is a confirmation call for adopting this draft as a working group item. If you do not agree with the in-room consensus that we had in Chicago to adopt this as a WG document, please speak up until 2017-07-19. If you weren’t in the room but do agree with adopting this document, you can also tell us.
>>> 
>>> https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11 <https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11>
>>> 
>>> Thanks,
>>> Francesca
>>> _______________________________________________
>>> CBOR mailing list
>>> CBOR@ietf.org
>>> https://www.ietf.org/mailman/listinfo/cbor
>> 
>> 
>> 
>> 
>> _______________________________________________
>> CBOR mailing list
>> CBOR@ietf.org
>> https://www.ietf.org/mailman/listinfo/cbor
>> 
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor