[rfc-i] Embedding stuff (code, etc.) in RFCs
framefritti at gmail.com
Sat Jul 13 01:53:04 PDT 2013
On Fri, Jul 12, 2013 at 10:16 PM, Paul Hoffman <paul.hoffman at vpnc.org> 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.
Let me emphasize that there are not many differences between the
RFC5662 approach and mine: in both cases we mark each line to be
extracted with a special punctuation: /// in RFC5662, "!." and "!," in
mine. It is true that the RFC5662 is simpler and it requires only a
shell line for extraction; however, the RFC5662 approach
* cannot handle more than one file
* cannot handle lines longer than 60-something characters
(considering the margin and the marker)
* cannot handle non-7-bit octects
Those limitations were not a problem in RFC5662 because of the
specific nature of the files to be extracted. If we want a system
that is general enough to be used in a reasonable variety of cases,
you need a way to handle the cases above and this makes the format
more complex: the first issue requires to introduce a "begin marker"
with the filename, the second issue requires the introduction of
different markers to denote a continuation line, the third issue
requires an escaping mechanism. As you can see, given the requirement
of being general, the proposed format is quite minimal.
> 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.
> --Paul Hoffman
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest