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

[Robert Sparks <[e-mail]>]

On 6/12/22 6:36 PM, Kesara Rathnayake wrote:
>
>
> On 13/06/22 10:49 am, John C Klensin wrote:
>
Trimming to just the discussion of rfcdiff itself:
>
>>
>>> 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.
>>
>> Sadly, I run two sets of operating systems here, neither of
>> which is a Mac or Linux.  I suppose I could figure out how to
>> get either Homebrew or rfcdiff itself to run under FreeBSD if I
>> could find an appropriate clean copy, but have many other things
>> to do at the moment {day, week, year}..  The only pointer I have
>> to rfcdiff is to https://tools.ietf.org/rfcdiff.   That seems to
>> be available at some times and not at many others. And neither
>> that page nor https://tools.ietf.org/ seem to give a pointer to
>> the program itself rather than a web interface.
>
> rfcdiff mirror is available on GitHub [1].
> Note that this tool is not supported.
>
> [1] https://github.com/ietf-tools/rfcdiff-mirror

Like idnits, this is really the _actual_ repository now, not just a 
mirror, and the name will be updated accordingly.

the rfcdiff shell script code has been stable for a long time, and if 
good contributions are provided, we'll continue to merge them. It should 
be package-able and useful for people on their own systems for quite 
some time to come.

We are moving to iddiff (a reimplementation) for the online service we 
provide for several reasons. One large one is that the current online 
service wraps the shell-script in a web templating language Henrik 
started some time ago that it doesn't make sense to maintain. It relies 
on a python 2.7 version of mod_python (see 
https://github.com/ietf-tools/rfcdiff-pyht). Another are changing 
requirements in what the online service will be allowed to retrieve and 
where it will be allowed to retrieve it from.

RjS

>
>   --Kesara
>>
>>>>   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.
>>
>> Based on my experience trying to work my way through those pages
>> while simulating a newcomer and that experience of a couple of
>> guide-free newcomers I've been able to check with, that is the
>> impression.  That is, of course, a rather small sample.
>>
>>>>   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.
>>
>> That may depend on one's perspective.  For the viewpoint of
>> someone who used xml2rfc with v2 source for years without
>> encountering any problems that could not be easily debugged
>> (from the error messages) and fixed but who encounters
>> undocumented and badly described/reported problems with v3 (and
>> needs help from generous colleagues to track them down and get
>> fixes or workarounds back to me), well, it is all relative,
>> but...
>>
>>>> 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.
>>
>> Again, a matter of perspective, some questions about "actual
>> production for whom", and with your comment about "jet engine
>> in-flight" in flight included.
>>
>> A different way to say almost the same thing is that the
>> publication of RFC 8650 proves that the RPC, with whatever
>> support (I presume even including paid professional support)
>> they need, can generate RFCs in all three important formats.
>> That is certainly one sort of "production" and a vitally
>> important one.  It does not prove that none of those output
>> formats will need tweaking later (I understand there have been
>> cases where such tweaking has been needed).  But, far more
>> important, it does not prove that xml2rfc, the RFCXML v3 syntax,
>> and the well-documented supporting tools are ready for
>> "production" use by either experienced RFC (and I-D) authors who
>> have gotten used to RFCXML v2 (idiosyncrasies, bugs, and all)
>> and who have not been participants in the tools effort or who
>> are new to the IETF and I-D writing.   Those two groups are very
>> different at least wrt the supporting documentation or tutorials
>> they might need and how they are navigated, but my assumption (I
>> hope correct), is that the IETF should care about both and does
>> so.
>>
>> And we are now straying into the territory that, IMO, should be
>> on the IETF list because, AFAICT, relatively few of those who
>> are most affected are on this one.
>>
>> best,
>>     john
>>
>> ___________________________________________________________
>> Tools-discuss mailing list - [e-mail]
>> This list is for discussion, not for action requests or bug reports.
>> * Report datatracker and mailarchive bugs to: 
>> [e-mail]
>> * Report all other bugs or issues to: [e-mail]
>> List info (including how to Unsubscribe): 
>> https://www.ietf.org/mailman/listinfo/tools-discuss
>>
>