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

Paul Kyzivat pkyzivat at alum.mit.edu
Fri Jul 12 18:30:00 PDT 2013

On 7/12/13 8:05 PM, Paul Hoffman wrote:
> On Jul 12, 2013, at 1:25 PM, Paul Kyzivat <pkyzivat at alum.mit.edu> wrote:
>> Do these tarballs contain copies of stuff that is rendered in the draft?
>> Or do they contain supplementary material that is *not* rendered in the draft.
> Rendered.
>> If it is rendered in the draft, how do we assure coherence?
> The same way we assure coherence with the non-canonical PDF and HTML versions the RFC Editor publishes: we don't. We assume that the RFC Editor is probably doing it right, and will respond to email when someone finds something they did wrong. This has worked fine for at least a few decades.
>> I have a problem now because I submit the xml and the txt. There is no guarantee that they are consistent. IMO I should only submit *one* form, and all others should be algorithmically derived from that.
> You don't actually "submit" anything. The RFC Editor receives the .txt from the stream that approved your RFC. The RFC Editor asked you to help their process with the XML. Diffs against the .txt are done at many points, certainly including in front of the stream leadership during AUTH48.

With *drafts*, I *submit* the txt and the xml via the online submission 
tool. That tool happily posts those, making the leap of faith that the 
xml and the txt correspond.

I would much prefer that only one form (e.g. the xml) be submitted, and 
everything else be derived from it.

	Paul K

More information about the rfc-interest mailing list