[rfc-i] Embedding stuff (code, etc.) in RFCs

Dearlove, Christopher (UK) chris.dearlove at baesystems.com
Fri Jul 12 09:39:32 PDT 2013


The .txt is the definitive RFC, so extracting from that has its advantages.

Perhaps we should have a <code> or whatever in the XML, and then xml2rfc to map that to something distinctive, plus a tool to pull the distinctive text out of the .txt, while extracting the code from <code> ... </code> in the XML would be trivial.

-- 
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-bounces at rfc-editor.org [mailto:rfc-interest-bounces at rfc-editor.org] On Behalf Of Paul Kyzivat
Sent: 12 July 2013 17:26
To: rfc-interest at rfc-editor.org
Subject: Re: [rfc-i] Embedding stuff (code, etc.) in RFCs

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Riccardo,

The approach you propose depends on explicit syntax in a draft, so that 
file content can be identified and extracted. It is complicated by the 
need to disambiguate it visually, and to deal with formatting issues.

IMO it would be better to extract content from the *markup* document. 
The xml2rfc format already has *some* support for this: the <artwork> 
element has a type attribute. This is already used, by some, to identify 
some content like abnf. And some tools already use this - e.g. to drive 
syntax checkers.

Of course that mechanism is somewhat rudimentary, and could stand some 
beefing up. But I think it would be a better starting point than trying 
to parse file content out of the draft .txt file.

What would help would be a mechanism to apply type-specific formatting 
to artwork content when formatting as an RFC. That would allow the "raw" 
content of the artwork to be in "native" format.

I've been interested in this for a slightly different but related goal: 
I want to extend the abnf syntax to allow reference/importing of ABNF 
from other sources. And I want that to work when the ABNF being 
referenced is embedded in an RFC/draft.

	Thanks,
	Paul

On 7/12/13 11:21 AM, Riccardo Bernardini wrote:
> Dear all,
> recently there was a discussion about the problem of publishing source
> code associated with RFCs. I gave some thought to the problem and
> developed a general and very light-weight format for embedding code in
> an RFC that allows for automatic extraction while maintaining the
> readability of the code. I collected my reflections and my proposal
> (with the respective software embedded, of course!:) in an I-D
>
>         http://www.ietf.org/internet-drafts/draft-bernardini-embedded-code-00.txt
>
> The I-D is still a bit rough  and the code is still to be fully
> tested, but before investing some more time I would like to know if
> this can be of some interest.  Of course, suggestions and observations
> (polite ones :-) :-) are welcome.
>
> Best regards,
>
> Riccardo
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>

_______________________________________________
rfc-interest mailing list
rfc-interest at rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

********************************************************************
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