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

[Andrew Sullivan]

On Mon, Apr 09, 2012 at 01:49:38PM +0200, Iljitsch van Beijnum wrote:
> But it's more complicated than that. We have:
> 
> 1. the source format: what the author uses to edit the text
> 2. the submission format: what the author uploads to the IETF servers
> 3. the authoritative format archived by the RFC editor
> 4. zero or more additional display formats, which may or may not be hosted by the IETF and/or RFC editor
> 

This doesn't get it quite, either.  Your 1 != 2.5, which is the source
format that the RFC editor uses to prepare 3.  For a long time, that
was *roff, although I understand that they'll now use the xml2rfc
source if you send it.  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. 

> 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, unless we
have a set of display rules in the document.  (Organizations that use
Word for this are in effect saying that phones don't matter.  I've
tried to use Word-type things on my phone, and frankly they suck.)

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).

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com