[rfc-i] Canonical input formats

Phillip Hallam-Baker hallam at gmail.com
Tue Jul 31 12:15:09 PDT 2012


Fred,

I agree with the problem statement. What I think really important is
that the RFC editor have a defined interface to the rest of the world
and that this consist of:

* One input format
* Canonical output in the input format
* Canonical output for presentation

The input format should be stable over extended periods of time and
encapsulate all the metadata required for production of an rfc.

My choice would be XML since this allows the format to be closely
tailored to IETF needs and is independent of external events. I would
see the XML format changing only when it was decided that additional
metadata was required. For reasons I explained in the BOF, I think the
canonical presentation format should be PDF/A.:

Input Format : XML2RFC
Output Format: XML2RFC
Presentation: PDF/A

With this fixed interface, it is easy to produce tools that convert to
or from the input format. So the submit interface would accept
documents in a range of formats, HTML, possibly even Word or ODF and
generate output in various versions of HTML.

On the other side of the interface, the RFC Editor is of course free
to pick whatever tool they like. The only constraint being that the
documents output by the RFC editor have to be at least as good as the
ones submitted. That is, the documents cannot lose data. Use of nroff
would not be acceptable unless nroff could be used in such a way that
the process does not lose the metadata provided in the original input.




On Tue, Jul 31, 2012 at 11:40 AM, Fred Baker (fred) <fred at cisco.com> wrote:
> I'm sitting in the BOF and listening to all that is being said. If you want to know what I like, I like XML2RFC, for the same reason that Joe likes HTML. It's familiar to me, contains metadata, is supported by tools I know how to use, and at least mostly works.
>
> One thing I am currently a little worried about is how one reworks a prior work. Context: I have been asked by the OSPF Chair to modify an existing MIB document. There are a lot of ways I could do that, one of which would be to take the current RFC, turn it into XML, add the two sentences that are necessary (or whatever), produce the output, and post the draft. Or, something I think I might be happier with, I could ask the RFC Editor for whatever they produced said RFC from, modify that, and produce the updated document.
>
> So now I'm having visions of:
>    - there are folks in our community that use nroff, Word, XML2RFC, presumably HTML, and probably something else.
>    - I'm not sure what the RFC Editor uses - I suspect it's still nroff.
>    - Therefore, what I expect the RFC Editor to send me is whatever they use, perhaps nroff.
>
> Yes, I have an nroff tool on my Mac and on mainframes in Cisco. Linux users probably do too. I'll bet Windows users are less likely to. Hmmm. Joe has HTML tools on his computer; if the RFC Editor were to send me HTML, I would have to download and learn those tools. I own a copy of Word, and if the RFC Editor sent me a Word document I could make that work. Were I a Linux user, I would find myself changing that to Open Office (and if I worked at Apple, I would find myself tempted to convert to Pages), but document conversion has all the pitfalls NAT has.
>
> You see where I'm going. It would be nice if the RFC Editor could advise the community what input format they use, so that in these exercises, we have some consistent expectation (however reasonable or not we might consider it) of what we should be prepared for. "No canonical input format" not only means that the RFC Editor continues the current free-for-all, but folks like me do as well.
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest



-- 
Website: http://hallambaker.com/


More information about the rfc-interest mailing list