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

Paul Kyzivat pkyzivat at alum.mit.edu
Fri Jul 12 09:48:55 PDT 2013


On 7/12/13 12:40 PM, Riccardo Bernardini wrote:
> On Fri, Jul 12, 2013 at 6:26 PM, Paul Kyzivat <pkyzivat at alum.mit.edu> wrote:
>> 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.
>
> I agree that maybe starting from the xml would be a higher-level (and
> simpler) approach. However, as long as the text file remains the
> official RFC format, you can be sure you can get the .txt, but you
> cannot be granted having the XML.  For example, in the case of my
> draft I uploaded only the .txt.
>
> Actually, the XML could not even exist.  You could edit directly the
> text file (Yuk!), you could use nroff or some other formatting tool.
> For example, I do not love XML too much and I would prefer a
> LaTeX-like syntax for my I-Ds, so I toyed for a while with the idea of
> making my LaTeX-based tool (I have a faint memory seeing something
> like that, but maybe it was a sleeping project... Faint, faint...).

While what you say is true, I don't find it compellilng.
Whatever is done will only work for drafts published in a say that 
supports the mechanism. So if they want to embed extractable code, then 
publish in a way that supports it.

	Thanks,
	Paul

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