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

[Kesara Rathnayake <[e-mail]>]

On 13/06/22 12:39 pm, John C Klensin wrote:
> 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.

You can create issues under author-tools [1]. I can transfer them to 
appropriate places.

[1] https://github.com/ietf-tools/ietf-at/issues

Cheers,
Kesara

> 
> 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
> 
> 

-- 
Kesara Rathnayake
Senior Software Development Engineer - IETF LLC
[e-mail]