[rfc-i] Fwd: New Version Notification for draft-flanagan-plaintext-00.txt

Paul Kyzivat pkyzivat at alum.mit.edu
Tue Jun 24 09:35:40 PDT 2014

On 6/24/14 12:13 PM, Elwyn Davies wrote:
> On Tue, 2014-06-24 at 16:59 +0200, Julian Reschke wrote:
>> On 2014-06-24 16:55, Joe Touch wrote:
>>> On 6/24/2014 7:48 AM, Julian Reschke wrote:
>>>> On 2014-06-24 16:35, Joe Touch wrote:
>>>>> On 6/24/2014 4:04 AM, Dearlove, Christopher (UK) wrote:
>>>>>> This does appear to convert plain text from normative to close to
>>>>>> useless.
>>>>> +1
>>>>> I'm particularly concerned about the notion that figures that aren't
>>>>> available as ASCII-art will be resolved using URLs.
>>>> Do you have a better suggestion?
>>> Either provide an ASCII-art version of the figure or *require* that the
>>> descriptive text is normative and that the figure is supplemental only.
>> AFAIU, the latter is the intent, but I'm not sure whether this has been
>> captured in any RSE document yet.
>>> ...
> Presumably this means that we are stuck with producing ASCII art
> versions for some diagrams where it would be tedious to say everything
> in words.  Protocol field diagrams and architecture block diagrams seem
> to be two prime examples.
> At present, I think we treat protocol field diagrams as normative at
> least for the order of fields and to some extent for layout of fields
> even if we don't have this idea written down.  We never (or at least
> hardly ever) explicitly say that the words define the order of fields;
> nor do the words say what bit positions fields have in the overall
> protocol packet.
> If I have understood correctly and we have to continue doing ASCII art
> or add in many more words for such cases, I am not sure this is a gain.
> Maybe the protocol field diagram is amenable to a specification language
> that will generate the ASCII art or some SVG alternative according to
> output rendering.
> Message flow diagrams and architecture/structure block diagrams are more
> difficult.

The limitations of ASCII art are one of my major annoyances with ietf 
document format. A common form that is problematic is a state transition 
diagram. Not only are these hard to draw, but when they get beyond a 
minimal level of complexity they are very hard to fit with current line 
length limitations and remain easy to understand.

Also, I find UML diagrams very useful. IETF documents use some of these 
without knowing it (state diagrams and sequence diagrams (call flows)). 
But I also strongly favor UML class diagrams, because they can capture a 
great deal of information concisely. The spatial arrangement of elements 
does not affect the semantics of a class diagram, but can be essential 
for a human to grasp those semantics. Beyond the most simplistic ones, 
they just don't work with ASCII art.

I don't have a perfect answer here. Some of these might only work well 
in PDF format or some tool-specific format.


> I am sure there must be tools out there that will do most of this
> already.
> Regards,
> Elwyn
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

More information about the rfc-interest mailing list