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

[John C Klensin <[e-mail]>]

Kesara,

(top post)

I will take your comment about issues as an invitation to start
comparing rfcdiff and iddiff, making a list, and getting it to
you.  I hope Carsten will do the same.  Part of the problem, of
course, is that there is likely a boundary between "real
problem" and "not exactly what I'm used to" and it may be hard
to discern sometimes.

And that github link is probably just what I need.  Now I just
need to find time to do something with it.

thanks,
   john


--On Monday, June 13, 2022 11:36 +1200 Kesara Rathnayake
<[e-mail]> wrote:

> 
> 
> On 13/06/22 10:49 am, John C Klensin wrote:
>> 
>> 
>> --On Sunday, June 12, 2022 23:09 +0200 Carsten Bormann
>> <[e-mail]> wrote:
>> 
>>> 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).
> 
> Let me know any issues that you find with iddiff.
> 
>> 
>>> 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
> 
>    --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