[rfc-i] draft-rfc-image-files-03

Iljitsch van Beijnum iljitsch at muada.com
Mon Apr 9 08:14:45 PDT 2012

On 9 Apr 2012, at 16:27 , Andrew Sullivan wrote:

> Your 1 != 2.5, which is the source
> format that the RFC editor uses to prepare 3.

Sure. But in all protocol design we treat the implementations as black boxes. What we care about are the interfaces in and out.

> In any case, the actual input to (3) isn't
> public, which is why I said that we don't actually have the source
> file as the archival format today. 

The part we care about is when someone wants to write a new version of an RFC, they can take the old version and start rewriting it. Obviously tracking down the original authors and requesting from them the file they submitted to the RFC Editor would be very problematic, and also not really work as that way you lose the edits made by the RFC Editor. Which, as we know from shared experience, can be of technical relevance.

The alternative would be to ask the RFC Editor for the file in submission format that has their final edits, but if the submission format is different from the publication format, that promotes the submission format to a second publication format, with all the authoritativeness issues that may end up biting us at some point down the line. It would then be easier to make format 3 the same as format 2 and make what previously was format 3 a format 4.

>> Think about how useful it would be if 1 - 4 could all be one and the
>> same. (Which explains why many other organizations use .doc format.)
>> I don't think we can get there for the full 100%, because the
>> overlap between the tools most people like to use and the tools that
>> have had file format stability in the past is rather small.

> Right.  Also, (4) is by definition not going to be the same,

Yes, of course.

> I guess I don't understand why we should insist that every format be
> the same thing.  We know how to write protocols.  Why is a
> transformation protocol of this sort something we couldn't specify?
> There might be a trade-off argument -- maintaining the tools is
> expensive, ensuring a bug-free system is hard, and so on.  But that's
> an argument about trade-offs that I haven't seen much of (there have
> been notable exceptions).

So far I haven't seen anyone insisting. There will be many tools that work on RFCs and drafts either way; the ability to be parsed by relatively simple tools is an important goal for a new RFC format. Having different formats at different steps through the pipeline just means more tools and more chances for mistakes.

So we should only have different formats if that buys us something important. If we could accept .doc format, that would make life a lot simpler for many people. But we really can't, for many reasons: the format changes too often, is probably too complex to allow for robust tools, and I don't see a way to encode the metadata in a way that is both strict enough to be useful and easy enough to enter to not reduce Word or another .doc creating program to a very memory hungry plain text editor.

So if people are going to have to perform relatively complex steps from source format to submission format anyway, we may as well take that hit there and have the submission format be (in principle) the same as the publication format.

But the main thing is that metadata is retained at every step. Unless I missed something there is currently no RFC2XML...

More information about the rfc-interest mailing list