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

Paul Kyzivat pkyzivat at alum.mit.edu
Fri Jul 12 13:25:18 PDT 2013

On 7/12/13 4:16 PM, Paul Hoffman wrote:
> On Jul 12, 2013, at 1:08 PM, Nico Williams <nico at cryptonector.com> wrote:
>> On Fri, Jul 12, 2013 at 1:33 PM, Paul Hoffman <paul.hoffman at vpnc.org> wrote:
>>> Is the problem statement:
>>>    Some RFCs have stuff (code, etc.) inline, and it would be useful for a reader
>>>    to be able to get it easily without having to unindent, remove page breaks,
>>>    split into separate files, and so on?
>>> If so, a simple solution would be "the stuff (code, etc.) in this RFC can be found at http://www.rfc-editor.org/rfc-stuff/rfc7890.tgz". The URL would be canonical, the response one gets when resolving it would not be, just as is the response one gets for other non-canonical stuff like PDF versions of RFCs.
>> We'd have to include a cryptographic (SHA-2, say) hash of the tarball.
> Works for me.
>> RFC5662 should be the canonical RFC *today* for code extraction.
> +1
> But the RFC Editor should consider the tarball approach as well for thing that are not as code-y, such as ABNF, XML, and so on.

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 

If it is supplementary material, then is it equally reviewed, etc.?

If it is rendered in the draft, how do we assure coherence?

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.


More information about the rfc-interest mailing list