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

[Carsten Bormann <[e-mail]>]

A couple of comments to some specifics:

> 
> Epsilon (and emacs) are "just" editors.  Their modes for
> handling XML are not aware of schema, just such fundamental
> --and essentially lexical-- issues as formatting, element
> matching, and so on. 

Emacs' nxml-mode can use a Relax-NG grammar (which is the usual way I edit RFCXML if I really really have to).

> (1) They would seem to lead to documents that are v2-v3 hybrids.
> I don't know how the current versions of xml2rfc would deal with
> that but, given assorted v2 elements and constructions that were
> deprecated in v3, I'd guess it would be very hard to get right
> and that going in that direction would be a bad idea.

One of the problems with RFC 7991 is that it doesn’t make explicit the relationship between authoring/contribution and publishing formats.  So there is tons of deprecated stuff in the published RFCs which is just needed to supply defaults to attributes that are deprecated in v3.
Of course a published RFC should be clean of that and conform to a publishing grammar, which should be related to, but not identical, to the contribution grammar.

> […] given the very

> large number of documents in the RFC Editor's collection in v2
> format

The RFC editor does not really deal in v2 RFCXML.
They can give out some v2 RFCXML that was used in the publishing of a pre-8650 RFC, but it is then the job of the author to:

> that, I assume, have not been converted to v3 and tested
> for consistency with the output produced,

I generally convert dusty XML decks to an authoring format (not v3, but kramdown-rfc) and then do an rfcdiff to the actual published RFC, tweaking the authoring format until the rfcdiff is empty (or just has some inevitable differences).

So this is not really a good argument in favor of:

> a decision to retire
> support for v2 should be taken only with great care (and, IMO,
> given the risks and tradeoffs, made only with IESG signoff after
> a community Last Call).  Until then, I believe the tools team
> and IETF staff have considerable responsibility for keeping
> version 2 supported.  I don't think a few spurious warning
> messages are a big deal unless they are a sign of things to
> come,

Which I agree wholeheartedly with until this:

> but, when the answer to a problem with constructions that
> are valid and well-documented under v2 is "convert to v3", that
> is not supporting v2 properly and as the community has a
> reasonable right to expect.  

Converting to v3 *is* the answer.
If we had infinite resources, we could spend some of the energy keeping v2 more alive than it is, but with 138 open issues, we’ll need to focus on keeping v3 alive.

To me, continuing to work on a document in v2 format really is a waste of time, unless there are some very specific reasons that we haven’t discussed here.
Convert to an authoring format, e.g., kramdown-rfc, mmark, or if it must be, RFCXMLv3, and take it from there.

We need some continued working v2 support in xml2rfc to do other things with pre-8650 contributions, but we don’t need to make it good enough for authoring RFCs, as these will be v3, and the earlier in the authoring process you can make the conversion, the less the pain and the better the results will be.

Grüße, Carsten