[rfc-i] Fwd: New Version Notification for draft-flanagan-plaintext-00.txt
elwynd at folly.org.uk
Tue Jun 24 09:13:13 PDT 2014
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
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
Message flow diagrams and architecture/structure block diagrams are more
I am sure there must be tools out there that will do most of this
More information about the rfc-interest