Re: Things that used to be clear (was Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)

[Phillip Hallam-Baker <[e-mail]>]

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:

http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html

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:

https://github.com/hallambaker/PHB-Build-Tools



On Mon, Jul 8, 2019 at 7:40 PM Nico Williams <[e-mail]> 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.
>
>