If people want document editing tools, may I recommend my RFCTool?
It is written in C#, runs on Linux, OSX and Windows and is MIT License.
It accepts as input formats: xml2rfc, markdown, Word, HTML
It generates as output formats: xml2rfc, markdown, Word, HTML, TXT
It converts citations of the form <norm="RFC322"> to the proper reference automatically and builds tables of figures, contents and normative language.
The main limitation is that it is designed to target the new formats and so I haven't made it a priority of late till the tooling for those is ready. I wanted to be able to make use of diagrams and math notation in my docs:
If it was to be taken further, the main change I would make is to change the markdown format to use the same tags that GitHub uses as this has emerged as the standard.
The code is here:
On Mon, Jul 8, 2019 at 7:40 PM Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote:
On Mon, Jul 08, 2019 at 07:22:20PM -0400, Keith Moore wrote:
> On 7/8/19 6:33 PM, Nico Williams wrote:
>
> > xml2rfc is great, but it lacks wiki-ness, though we could probably
> > develop HTML+JS tooling to give xml2rfc that missing wiki-ness.
>
> Actually I'd love it if xml2rfc were phased out in favor of something
> better. IMO it imposes a significant barrier to contributions, especially
> from newer IETF participants, but really from everybody. But I realize
> that it's hard for IETF to build and maintain real document editing tools
> that run on everybody's platforms. It's hard enough to maintain xml2rfc.
> And I could certainly imagine worse tools, like (gasp!) Word.
>
> (I'm not exactly fond of wikis' UIs either.)
Well, I don't really care what it is, as long as a) we get the
typesetting right, b) we get the UI right.
Markdown seems incomplete.
XML with webby $EDITOR tooling would do.
> > Also, think of the channel binding type IANA registry, which doesn't
> > require an RFC for each type, just a specification somewhere. A lot of
> > what we do in the IETF doesn't really need a publication process as
> > heavy-duty as the RFC publication process.
>
> Well, IANA exists for the case you're citing already. (such things used to
> be published in RFCs) What other cases do you have in mind?
PKIX extensions (e.g., SANs). Kerberos extensions. TLS extensions.
SSHv2 extensions. And so on and on.
> > None of the above addresses the need for I-D stability markers. We're
> > identifying a lot of related issues and thinking up possible solutions.
> > Let's not lose track of the specific needs/problems we identify.
>
> Keeping explicit track of those things in one place seems like a good next
> step.
Yes. And I think we have enough material to justify a BoF.
