[rfc-i] RFC editing tools

Stefan Santesson stefan at aaa-sec.com
Wed Dec 5 01:57:37 PST 2012


I'm sorry if what I say here comes out of context. Due to my workload I just
subscribed to this list today and have not read any previous conversation.
Encouraged by Nico, I would just give my thoughts, based on my work with the
Nroff Edit tool and other hands on work in the area.

The current problem as I see it is that there is no format today that
captures all information that is needed in order to generate all other
In fact, this is in my mind the root cause of all problems. I would call
such a format, the source format and such format need to capture:

- Content (Text, titles, table data, reference info, etc)
- Metadata (internal references and markup of types of data)
- Formatting (Line breaks, page breaks and similar)

It does not have to cover style (in a HTML sense). I think it would be
acceptable if style was managed on a generic level that could apply to all
RFCs. I.e. It could be implicit.
The need to capture formatting is of course dependent on the publishing
format. If it is just HTML, then the need for page breaks is null, but there
might still be a need to format the content in other ways.
However, if we still want to be able to render text documents in the
traditional style, then formatting becomes more important.

Formatting is evidently so important to RFC publishing, that the RFC editor
feels that they have to convert each RFC to nroff before completing the
editing process.
When doing so they loose quite an amour of important metadata.
There is also a risk that the source format providing formatting (nroff) and
the source format providing metadata (xml2rfc) may come to differ in content
in this process, is it must be hard to guarantee that they are 100%

Having one source format that covers all, solves a lot here.

The second problem on my list is editing.
For many people, editing in XML is NOT user friendly.
I know that it does not have to be hard, once you get your system set up and
using good software. For example using Oxygen in authoring mode supported
with a good XML Style sheet makes editing a lot easier.
But that is quite a barrier for some people.
The only reason why NroffEdit is there, is to provide an alternative to XML

If this was my call, here is what I think I would have as the final goal:
1. Extend the current xml2rfc shema to capture all information necessary to
become the one and only source format, from which you can render all
publishing formats (text, html, pdf)
2. Develop XML Stylesheets that can support advanced user's XML editing as
well as handle rendering to text, html and pdf).
3. Develop a web tool, and publish the code as Open-Source, that offers
basic editing of RFCs in a simple and user friendly fashion, producing
source formatted data.
4. Retire all use of Nroff
5. Reverse engineer all published RFCs into the new source format.
6. Encourage the market and volunteers to create good collaborative tools
for editing RFC:s using the new source format, based on the Open-Source

Just my 2 cents.


From:  Nico Williams <nico at cryptonector.com>
Date:  Wednesday, December 5, 2012 7:19 AM
To:  Nico Williams <nico at cryptonector.com>
Cc:  RFC Interest <rfc-interest at rfc-editor.org>, Stefan Santesson
<stefan at aaa-sec.com>
Subject:  Re: RFC editing tools

> i should add that Stefan had some comments about ways in which nroff is better
> that I recall resonated with me, but I don't recall what they were.  Also,
> NroffEdit is quite nice.
> Declaring xml2rfc schema the canonical I-D/RFC format will tend to preclude
> tools that cannot easily convert their formats to XML.  That may be OK, but we
> should think about it carefully before deciding to do just that.
> Nico
> -- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20121205/5c3b2c9e/attachment.htm>

More information about the rfc-interest mailing list