[rfc-i] Does the canonical RFC format need to be "readable" by developers and others?
Iljitsch van Beijnum
iljitsch at muada.com
Mon Jun 25 05:58:32 PDT 2012
On 22 Jun 2012, at 23:52 , Julian Reschke wrote:
>> Remember, 40 years is a long time. But I'm pretty sure people will still be reading the IPv6 RFCs 40 years after their publication.
> I still don't quite understand what point you're trying to make.
That relying on code is a big liability.
> Are you arguing for a format that can be read without conversion, that is, in a text editor? I believe that's the case for the xml2rfc vocabulary, if you really need to.
What I'm arguing for is something that is still usable if today's tools don't exist to a usable degree anymore.
ASCII text scores very high here, because it's trivial to decode.
Something like PDF doesn't score at all, because you need very complex software to decode PDFs.
XML2RFC and HTML score somewhere in the middle: the plain text is in there and can be extracted. In both cases, it's not entirely inconceivable for someone to write a conversion utility that displays the RFCs more or less as intended. But with HTML this would be easier, I think.
Separately, although we haven't identified any tools that can generate a prospective HTML RFCng format, we know that we can create such a format such that browsers can display them natively in a useful way, so the chances of things ever coming down to the text extraction level are reduced.
A question for you: how hard would it be to re-imagine XML2RFC as HTML2RFC? (I.e., come up with a format that conforms to HTML that does what the XML2RFC format does now and modify the tool(s) accordingly.)
More information about the rfc-interest