RE: [Fwd: Re: Last Call: 'Proposed Experiment: Normative Format in Additionto ASCII Text' to Experimental RFC (draft-ash-alt-formats)]

["David Harrington" <ietfdbh@xxxxxxxxxxx>]

So, since most programming languages work in ascii, what you are saying is that this pretty diagram would be quite difficult to convert to a lot of words in ascii, which may or may not be correct.

 

So why do we want to make such diagrams the normative specification rather than using something like pseudocode, which is much easier to convert to a programming language?

 

And we should consider that if we need to convert from a non-normative pretty diagram to pseudocode or code, that would presumably be more easily done by the specification authors who have a profound understanding of the design, than for a reader not involved in working on the design.

 

I fully agree that, for the reasons you give, using such pretty diagrams as normative would generally be a problem.

 

David Harrington
dharrington@xxxxxxxxxx
dbharrington@xxxxxxxxxxx
ietfdbh@xxxxxxxxxxx

---

From: Stewart Bryant [mailto:stbryant@xxxxxxxxx]
Sent: Sunday, June 25, 2006 4:42 PM
To: iljitsch@xxxxxxxxx; stephen@xxxxxxxxxx; ietf@xxxxxxxx
Subject: [Fwd: Re: Last Call: 'Proposed Experiment: Normative Format in Additionto ASCII Text' to Experimental RFC (draft-ash-alt-formats)]

As an example,  this .gif extracted from the Y.1711 OAM protocol
would be quite difficult in ASCII. It would take a lot of words
to describe, which many people would then have to transcribe to
some sort of timing diagram - which then may or may not be
correct.

For those that cannot see the GIF it's figure 9

This is a timing diagram which is a problem that few folks have so far mentioned.

- Stewart

<!--[if !vml]-->

<!--[if !vml]--><!--[endif]-->

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf