Subject: [COSE] cddl

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 30 Aug 2015 17:53:10 +0200

Dear WG draft authors, Hi all,

I have two comments regarding the use of CDDL in the COSE draft.

1) I don't believe it helps anyone to use a (formal) data definition
language. Natural text is sufficient. The COSE specification is
hopefully not so complex in the end that such a data definition language
is needed. In general, I believe this typically just creates a
misalignment between what is described in the text and what is contained
in the formal description. There are many examples where the two
descriptions disagree.

I don't think it will help a human to understand the specification
better (instead focus on better examples) and it will not help to
automatically create code (which has often been mentioned as a benefit
with other formal languages).

2) Please explain what the status of CDDL in the IETF is. The COSE spec
references it normatively but the specification is an individual
submission.

My preferences is to remove the reference to CDDL and remove the CDDL
related content from the draft making the spec shorter and easier to
read. I hope others agree with me.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 30 Aug 2015 18:07:15 +0200

Hannes Tschofenig wrote:
> language. 

Hannes, with all due respect: speak for yourself.

There are people who benefit from ABNF in other protocol specifications,
and the same is definitely true here.

(CDDL is also useful for automatically verifying the examples, but that
is an effect that accrues independently of whether the spec actually
contains it or not.  Not publishing the CDDL that was used for verifying
the examples would not be a bright move, though.)

> Natural text is sufficient. The COSE specification is

True for ABNF as well.  The main effect of an ABNF spec has been that
people have been more careful when actually creating the spec.

> references it normatively but the specification is an individual

Right.  Given the number of efforts that have started looking at CDDL,
it is likely that we'll go for standardizing CDDL.  But the timeline for
CDDL becoming an RFC is likely longer than that for COSE.

> read. I hope others agree with me.

I definitely don't.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 30 Aug 2015 18:25:03 +0200

Hi Carsten

thanks for your quick response.

> Hannes, with all due respect: speak for yourself.

I am not sure how you got the impression that I am not speaking for
myself in this email.

> and the same is definitely true here.

Speaking for myself again: I have never benefited from ABNF and I have
used it a lot in Diameter.

I had to use it in the documents since there was the perceived need to
do so not because it provided a benefit for me. The same has, btw, been
true for me for XML schemas.

> the examples would not be a bright move, though.)

I believe you are biased in this case since one of the authors is from TZI.

One should also be able to verify examples based on the text in the
specification. Furthermore, you will not be able to verify the examples
purely based on the CDDL anyway since you need tools to actually verify
the cryptographic operations (which is the main purpose of the
specification).

> True for ABNF as well.

I also don't like ABNF.

>  The main effect of an ABNF spec has been that

I fear that this is wishful thinking.

I am a strong believer that examples help people to understand
specifications faster.

> CDDL becoming an RFC is likely longer than that for COSE.

Not a good thing either.

>> read. I hope others agree with me.
That's fine. I hope that others carefully think about this issue and
make up their mind themselves. This is why I raise it here on the list.

Ciao
Hannes

> 
> Grüße, Carsten
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose
>

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 30 Aug 2015 18:58:21 +0200

> I am not sure how you got the impression that I am not speaking for

You said you don't believe it helps anyone.
I just wanted to point out that this belief is false.

> used it a lot in Diameter.

Again, I wanted to point out that there are people who do benefit from
ABNF (even if it is a slightly strange instance of the class of
specification languages known as EBNF).

> true for me for XML schemas.

We can agree there are some bad schema languages out there...
Still, most XML-based specifications do benefit from a document
structure definition language, in particular if it is a state of the art
language such as Relax-NG in compact form.

> I believe you are biased in this case since one of the authors is from TZI.

(Well, I'm actually helping with their work.
And the reason I'm doing this is: I strongly believe that formal
specifications do help, under a number of conditions that have only
recently become understood well enough.)

> specification. 

Sure.  Let's get rid of those pesky math expressions, too.
(If you have been present in the software development community in the
last couple of decades, you know that you get better quality from better
automation.  It is hard to automate testing from English text, and
that's why formats such as Cucumber's Gherkin have been developed.  But
this is off-topic from this WG's work...)

> Furthermore, you will not be able to verify the examples

Certainly.  ABNF and CDDL only give you syntax, which is a small part of
the specification problem.  But it is a frequent source of
interoperability problems, and it is a part where we know how to
automate at low cost.  It is simply not very good workmanship not to.

> I am a strong believer that examples help people to understand

I absolutely agree.

ABNF or CDDL are not at all substitutes for examples.  But like tests,
examples can only ever be examples, not demonstrate the boundary of the
spec.

All that said, I do understand a good counter-argument against
specification languages: They can make it too easy to add complexity.
Good thing we are not falling into this trap with COSE.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 30 Aug 2015 20:37:31 +0200

Hi Carsten,

Let us see whether others in the group have an opinion about this topic.
I don't believe anyone in the group was asked whether they want to use a
data definition language at all, CCDL, or something else in the COSE WG
document.

I guess we two have a different view about this subject. More discussion
will not change our perspective.

Ciao
Hannes

---

From: Phil Hunt <[email-masked]>
Date: Sun, 30 Aug 2015 12:09:37 -0700

I don't see the need for CDDL. Especially if it will delay COSE. 

Phil

> On Aug 30, 2015, at 11:37, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Carsten,
>

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 30 Aug 2015 21:52:37 +0200

Phil Hunt wrote:
> I don't see the need for CDDL. 

I don't think anybody sees a "need", as in "it can't be done without".
But that is no reason to do without.

> Especially if it will delay COSE. 

There is no need for that to happen.
The current plan is to relegate the CDDL specs to an appendix once the
structures are stable.  The normative part will be the English text (at
least unless CDDL manages to overtake COSE...).
(Just as the examples aren't what's normative, either, but are what is
being used by implementers anyway.)

Grüße, Carsten

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 30 Aug 2015 13:54:48 -0700

> -----Original Message-----
> From: COSE [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Sunday, August 30, 2015 8:53 AM
> To: [email-masked]
> Subject: [COSE] cddl
> 
> 1) I don't believe it helps anyone to use a (formal) data definition language.
> Natural text is sufficient. The COSE specification is hopefully not so complex in
> the end that such a data definition language is needed. In general, I believe this
> typically just creates a misalignment between what is described in the text and
> what is contained in the formal description. There are many examples where the
> two descriptions disagree.
> 
> I don't think it will help a human to understand the specification better (instead
> focus on better examples) and it will not help to automatically create code
> (which has often been mentioned as a benefit with other formal languages).

I totally disagree.  I think that there are huge advantages to using formal languages.  And while automatic code creation is a benefit, it is hardly the only one. I find such structures easier to read than natural code for many things.  When there is formal language in a specification, that is generally where I start with understanding the major parts of the document, and use the natural language for finer points.  It is much easier to locate and skip a formal language section than to look through several hundred lines of text to find the one that you need.  It was just pointed out to me that I had missed some text in the document that is only required because CDDL is not normative and thus it needs to be duplicated.

If I could make CDDL normative, then I would start ripping out natural language descriptions are being duplicated by the formal language.  Where ever possible I would have only one description and it would be the formal language.  Having natural language do the same thing except for clarifications is what I would object to.

I have never liked the idea of document by examples.  It can be both very limiting - I do something that is legal but not in the examples.  You do not process it because it is not in the examples.  Examples should be illustrative not where the specification is understood.

That being said.  What examples do you think need to be added to the document to improve it.

Jim

> references it normatively but the specification is an individual submission.
> 
> related content from the draft making the spec shorter and easier to read. I
> hope others agree with me.
> 
> Ciao
> Hannes
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 31 Aug 2015 06:40:42 +0200

Hi Jim,

thanks for your response.

It is interesting to see how different people are in terms of writing
documents.

I personally liked the JOSE documents quite a bit -- they are easy to
read and to understand. They got away without CDDL.

You asked about the examples. I have just tried to work on the multicast
use case and found none of the examples applicable.

It would be interesting to know what IoT use cases you had in mind when
you added the examples.

Ciao
Hannes

On 08/30/2015 10:54 PM, Jim Schaad wrote:
> 
> 
>> -----Original Message----- From: COSE
>> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig Sent:
>> Sunday, August 30, 2015 8:53 AM To: [email-masked] Subject: [COSE]
>> cddl
>> 
>> 1) I don't believe it helps anyone to use a (formal) data
>> definition language. Natural text is sufficient. The COSE
>> specification is hopefully not so complex in the end that such a
>> data definition language is needed. In general, I believe this 
>> typically just creates a misalignment between what is described in
>> the text and what is contained in the formal description. There are
>> many examples where the two descriptions disagree.
>> 
>> automatically create code (which has often been mentioned as a
>> benefit with other formal languages).
> 
> I totally disagree.  I think that there are huge advantages to using
> formal languages.  And while automatic code creation is a benefit, it
> is hardly the only one. I find such structures easier to read than
> natural code for many things.  When there is formal language in a
> specification, that is generally where I start with understanding the
> major parts of the document, and use the natural language for finer
> points.  It is much easier to locate and skip a formal language
> section than to look through several hundred lines of text to find
> the one that you need.  It was just pointed out to me that I had
> missed some text in the document that is only required because CDDL
> is not normative and thus it needs to be duplicated.
> 
> If I could make CDDL normative, then I would start ripping out
> natural language descriptions are being duplicated by the formal
> language.  Where ever possible I would have only one description and
> it would be the formal language.  Having natural language do the same
> thing except for clarifications is what I would object to.
> 
> I have never liked the idea of document by examples.  It can be both
> very limiting - I do something that is legal but not in the examples.
> You do not process it because it is not in the examples.  Examples
> should be illustrative not where the specification is understood.
> 
>> 2) Please explain what the status of CDDL in the IETF is. The COSE
>> spec references it normatively but the specification is an
>> individual submission.
>> 
>> My preferences is to remove the reference to CDDL and remove the
>> CDDL related content from the draft making the spec shorter and
>> easier to read. I hope others agree with me.
>> 
>> Ciao Hannes
>> 
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 31 Aug 2015 06:41:11 +0200

Hi Carsten,

> being used by implementers anyway.)

Who came up with this plan?

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 31 Aug 2015 07:06:08 +0200

> Who came up with this plan?

I don't remember, because it's the obvious thing to do.
Its been a while when we discussed this.  E.g.,

http://www.ietf.org/mail-archive/web/cose/current/msg00239.html

(No, I haven't written the English language generator yet, but it is
still tempting to do so.)

Grüße, Carsten

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 31 Aug 2015 13:47:27 -0700

In my boredom yesterday working at the winery, I kind of obsessed on this issue.  (Not having anything else to think about for some reason.)

I have seen a lot of incorrect examples in documents as well.  In fact I probably have seen more incorrect examples than I have cases where formal language and natural language conflicted.   All too often I have seen informational examples basically become normative language.   Taking your argument to its logical (but extreme) conclusion:  We should eliminate examples from the documents so that incorrect examples do not mislead people.  This is obviously not going to happen.

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Sunday, August 30, 2015 9:41 PM
> To: Jim Schaad <[email-masked]>; [email-masked]
> Subject: Re: [COSE] cddl
> 
> Hi Jim,
> 
> It is interesting to see how different people are in terms of writing documents.
> 
> I personally liked the JOSE documents quite a bit -- they are easy to read and to
> understand. They got away without CDDL.
> 
> You asked about the examples. I have just tried to work on the multicast use
> case and found none of the examples applicable.
> 
> It would be interesting to know what IoT use cases you had in mind when you
> added the examples.

I don't know that I had any IoT cases specifically in mind when I did the examples.  Many of them either came from or were influenced by the examples that were donefor JOSE.

Jim

> >> -----Original Message----- From: COSE [mailto:[email-masked]]
> >> On Behalf Of Hannes Tschofenig Sent:
> >> hopefully not so complex in the end that such a data definition
> >> language is needed. In general, I believe this typically just creates
> >> a misalignment between what is described in the text and what is
> >> contained in the formal description. There are many examples where
> >> the two descriptions disagree.
> >>
> > section than to look through several hundred lines of text to find the
> > one that you need.  It was just pointed out to me that I had missed
> > some text in the document that is only required because CDDL is not
> > normative and thus it needs to be duplicated.
> >
> > If I could make CDDL normative, then I would start ripping out natural
> > language descriptions are being duplicated by the formal language.
> > Where ever possible I would have only one description and it would be
> > the formal language.  Having natural language do the same thing except
> > for clarifications is what I would object to.
> >
> >> spec references it normatively but the specification is an individual
> >> submission.
> >>