Re: [Tools-discuss] xml2rfc in --v2 mode -- bug report?

[Carsten Bormann <[e-mail]>]

Again only picking up a few points here, which may be quite relevant for tools-discuss:

> I note that rfcdiff has largely
> stopped being available and that iddiff, while it has improved
> hugely in the last few months, is still not problem-free.  And,
> unless what works for you works for everyone else, we either
> figure out different ways of working or we impose more barriers
> on participation (no matter how the possible argument of how
> high those barriers are comes out). 

Rfcdiff is still readily available; for me it’s a simple install of `brew install larseggert/mytap/rfcdiff`.  If author-tools has broken it, we need to fix it.  Iddiff is getting there, but rfcdiff is the fully-debugged workhorse.

>  Drawing on a different
> conversation, if I (pretending to be a naive newcomer) somehow
> get to author-tools.ietf.org, click on the "Getting Started"
> link there, it seems to send me down the path of editing RFCXML
> directly, not using Kramdown-RFC of anything else.

If that is the impression author-tools leaves, we do have a serious problem.

>  When someone describes a relatively
> new piece of software as having a rather large number of open
> issues, insufficient resources to deal with them quickly and
> well, and a "need to focus on keeping it alive", the message I
> get --after over a half-century of involvement in software
> development projects in a variety of roles -- is "not ready for
> production use".  That is a rather scary thought.

Yes, we are fixing the jet engine in-flight.
But RFCXMLv3 is very much ready for production, I’d even say more so than RFCXMLv2 ever was.

> The other problem is that, if the authoring languages are really
> an important part of the solution, the web pages under
> authors.ietf.org appear to be in need of considerable work. 

(See above.)
But yes, authoring languages (including the direct use of RFCXMLv3) are really
an important part of the solution.

> The problem is that conversion failures send a message
> of either "not possible yet, wait a few more months" or "v3
> isn't ready; just continue for a while with something that
> works".

That potential impression is the main reason why I am even reacting here:  v3 is in actual production; the question whether it is production ready became moot in November 2019 with the publication of RFC 8650.

Grüße, Carsten