Just to explain why I'm agreeing here...
It doesn't use 2329; it extends it based on its unofficial successor
(see the web pages).
Yes, but:
1) If there'd be a decision to officially use rfc2629bis for document
production, we certainly would revise rfc2629 first, so the extensions
then would be sufficiently described in an RFC, and
(Because the XML2RFC community is not excessively perverse - see following
point where their lack of perversity also matters)
2) how's that relevant for the initial question? As long as future
versions of xml2rfc are compatible with the one you used, why would you
*need* to keep a snapshot of an old version?
Without reference to any other point that has been made in this thread or
its predecessors, I have to say that the idea of the XML2RFC tool breaking
compatbility with RFC2629/RFC2629bis is simply amazing.
Please see the last three letters of "XML2RFC" to better understand why I
think this is less likely than me winning the lottery. In an jurisdiction
that doesn't have a lottery. And blocks access to Internet lottery sites.
Given that I don't buy lottery tickets.
And, if the XML2RFC community lost its collective mind, it would not be
beyond the realm of possibilities that we might ask for a translator to be
produced before adopting the new and even more wonderful XML2RFC, and that
this community (which includes RFC authors who just MIGHT have
RFC2629/RFC2629bis input files they don't want to cut-and-paste themselves)
might even think of this on their own.
XML2RFC is "a moving target", but we could have a lot of influence on where
this target moves, and when, and whether there's still a target in the same
place as last year, after "moving".
Sheesh. Can we go back to discussing appeals about appeals again? Even that
was more productive.
Spencer
p.s. I didn't start using XML2RFC the first day the tool existed, but I have
been using it since the late 1990s, when it was not much/any easier to use
than nroff. It's not perfect now, but it's gotten a lot better, especially
on providing line numbers where processing failed (this used to be a real
gamble) for diagnostics.
If we could decide on using XML input (as opposed to ASCII output from XML
input), XML2RFC would probably work even better. The most recent
frustrations *I've* been having were about combining formatting and
verification/enforcement - for example, the standard tool doesn't produce an
output at all, if you have more than five authors listed, and if someone
manages to create a document with a section called "Security Consideration",
that's also a fatal error (because it's not "Security Considerations",
plural). If we could make a decision about using this tool as a part of the
process, it would make sense to bitch about stuff like this, but if the tool
is only one way of producing ASCII text, why bother?
And yet I use XML2RFC to this very day. I must be nuts.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf