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

Dearlove, Christopher (UK) chris.dearlove at baesystems.com
Tue Jun 24 10:06:40 PDT 2014

Not quite never. RFC 5444 defines the format in the text, the pictures are non-normative.

But that was a hard struggle with at least one AD.

Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove at baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: rfc-interest [mailto:rfc-interest-bounces at rfc-editor.org] On Behalf Of Elwyn Davies
Sent: 24 June 2014 17:13
To: Julian Reschke
Cc: rfc-interest at rfc-editor.org
Subject: Re: [rfc-i] Fwd: New Version Notification for draft-flanagan-plaintext-00.txt

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.

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.

I am sure there must be tools out there that will do most of this already.


rfc-interest mailing list
rfc-interest at rfc-editor.org

This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.

More information about the rfc-interest mailing list