[rfc-i] Does the canonical RFC format need to be "readable" by developers and others?
"Martin J. Dürst"
duerst at it.aoyama.ac.jp
Mon Jul 9 21:29:51 PDT 2012
On 2012/07/08 0:02, Phillip Hallam-Baker wrote:
> The XML2RFC format is not a good document format. The designer seems
> to have decided to do things their way without any good reason not to
> follow the HTML approach. So things that are easy in HTML, like lists
> require reference to manuals. Why they chose to use<t> instead of<p>
> and so on? Its like the inventor was deliberately trying to make the
> thing different and hard.
I talked to Marshall Rose, the creator of XML2RFC, I think it was at
IETF 54 in Yokohama (2002, that would just be 10 years ago). To
summarize, the issues we all know about XML2RFC were definitely not
introduced deliberately. Marshall had a great idea (use a widely
deployed structure format for RFC production) and a lot of energy to do
the implementation, but didn't know that apparently minor structure
details (elements vs. attributes, additional nesting elements or
not,...) can make a big difference for general usability.
In his defense, one has to say that this isn't something that is called
out in the specs; one has to learn by trial and error, with a lot of
experience, when details are arbitrary and when they matter.
> That said, XML2RFC exists and is somewhat tailored to IETF documents
> so it makes a reasonable interchange format, albeit a rather tedious
> one and it is a fixed point that is not going to change over time
> unless IETF requirements change.
I think that if we end up using XML2RFC as a main piece of the puzzle
(definitely something that would make sense), then we should invest some
time to fix the most annoying issues.
More information about the rfc-interest