[rfc-i] Embedding stuff (code, etc.) in RFCs
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.
> 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