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

Joe Hildebrand jhildebr at cisco.com
Mon Apr 9 08:08:14 PDT 2012

On 4/9/12 5:49 AM, "Iljitsch van Beijnum" <iljitsch at muada.com> wrote:

> On 9 Apr 2012, at 13:00 , Andrew Sullivan wrote:
>> To make progress on this question, though, we have to decide whether
>> we want the source format, or some particular rendering, to be the
>> archival format.  I will note that, by and large, today we do not use
>> the source format as the archival one (indeed, I can think of no
>> counterexample).
> That is indeed a good question. However, traditionally, we have been doing
> this as the draft format is pretty much the RFC format and the draft format is
> the canonical input format. Of course now that many/most people use XML2RFC
> this is less true than it used to be.
> 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
> 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.

I think that Larry's idea that we have a tool that takes in whatever crap
HTML you throw at it and outputs well-formed, nit-cleaned XHTML in a
near-idempotent (except for dates, perhaps) way gets us what is needed.

> However, with an HTML-based format we could come pretty close. Unless I'm
> seriously mistaken, HTML can be made to do everything that the XML2RFC format
> can do, but unlike XML2RFC format it's also a display format so it can easily
> be displayed natively in browsers. And it's text based, so text-based tools
> can still work.
> The most problematic part is the step from the source format to the submission
> format. I've never used HTML editors so I don't know how good they are, but
> when I've looked at generated HTML it has always looked terrible and even if
> that's not an issue then general purpose HTML editors are probably not going
> to support all the XML2RFC-like metadata tagging that we need.

If we use class names and id's to tag semantics, then most HTML tools should
be able to generate a rough enough approximation that idemponit should be
able to clean it up.

Joe Hildebrand

More information about the rfc-interest mailing list