David,
Like Adam, I appreciate the detailed feedback. However, let me
make a small appeal on the part of those of us who see (and
would like to see discussion of) issues in Adam's document that
have more to do with strategy (and alternative strategies) than
with particular text and that of people who follow the IETF list
but who have little interest in this particular topic. There
are mail systems out there that, at least in the absence of
prior arrangements, treat large, multiple-body-part, messages
(yours was more than eight megabytes in size) as an attack
and/or as requiring special per-message approval. Even for
those of us with mail systems that are friendlier to larger
messages (at least from IETF lists), multi-megabyte messages may
discourage reading. Could you please try to figure out a way
to go easy on this, possibly putting files up somewhere and
supplying links to them and/or aggressively trimming previous
messages?
By the way, at least some of the issues with xml2rfc versions of
documents and regenerating equivalent text from them result from
the design of generic text markup systems: that approach was
never intended to produce closely-controlled page formatting
and, while the degree has changed over time, the RFC Editor has
done a certain amount of page layout formatting after final
approval of documents by authors and what we now call the
relevant stream. rfcdiff can compensate for some of those
changes but not others; "fixing" to to adjust for all such
changes would probably require heuristics that, not being
perfect, would then lead us to complain about incorrect results.
More important, as the RFC Editor moves toward xml2rfc v3 and
treating those source documents as the authoritative/archival
form, the problems you describe are either going to get worse
(more differences between older documents and documents in the
source form preferred by the authors and the published xml2rfc
v3 form) or better (because xml2rfc v3 seems to drift
significantly in the direction of formatting markup, once
documents are published in that form, they should be more stable
and questions about matching output should become irrelevant).
Some of don't consider those trends desirable, but we are fairly
clearly in the rough.
If you decide to take on that topic, please start a separate
thread. In the interim, if Adam's document is going anywhere,
he (and you) should be quite careful about changes that get down
to the xml2rfc level without carefully considering both v3 and
the RFC evolution (including "authoritative XML") plan and their
implications.
thanks,
john
--On Sunday, May 19, 2019 10:54 -0400 David Noveck
<davenoveck@xxxxxxxxx> wrote:
> Thanks to everyone for their suggestions. Now that I've
> followed up on many of them, I'd like to tell everybody what
> I've found so that people can consider the implicationss for
> Adam's document and for the processing of upcoming updates to
> RFC5661. In particular, use of the existing v1 tools has
> proved quite helpful although it is not a panacea.
>
> So what I've found is that:
>
> - Even with the v1 xml2rfc, the .xml that I have gotten for
> RFC5661 from the RFC editor cannot be successfully
> processed. Whether you use the existing v2 xml2rfc or
> the v1 xml2rfc available on the web, considerable effort is
> required to get to an xml that can be processed successfully.
>...
