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

Kesara Rathnayake <kesara@staff.ietf.org> Sun, 12 June 2022 23:36 UTC

Return-Path: <kesara@staff.ietf.org>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D4EC14792F for <tools-discuss@ietfa.amsl.com>; Sun, 12 Jun 2022 16:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.785
X-Spam-Level:
X-Spam-Status: No, score=-8.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.876, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIkmuhyNE3BE for <tools-discuss@ietfa.amsl.com>; Sun, 12 Jun 2022 16:36:47 -0700 (PDT)
Received: from ietfx.amsl.com (ietfx.amsl.com [50.223.129.196]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958AAC14792E for <tools-discuss@ietf.org>; Sun, 12 Jun 2022 16:36:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by ietfx.amsl.com (Postfix) with ESMTP id 5ED5B4053E27; Sun, 12 Jun 2022 16:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from ietfx.amsl.com ([50.223.129.196]) by localhost (ietfx.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaW17F7fH0XH; Sun, 12 Jun 2022 16:36:47 -0700 (PDT)
Received: from [192.168.1.87] (122-58-156-70-adsl.sparkbb.co.nz [122.58.156.70]) by ietfx.amsl.com (Postfix) with ESMTPSA id 9934D4053E26; Sun, 12 Jun 2022 16:36:46 -0700 (PDT)
Message-ID: <7a438ea5-ec35-536d-2252-5dbc6cd66ad9@staff.ietf.org>
Date: Mon, 13 Jun 2022 11:36:44 +1200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.0
Content-Language: en-NZ
To: John C Klensin <john-ietf@jck.com>, Carsten Bormann <cabo@tzi.org>
Cc: tools-discuss@ietf.org
References: <B39D28F0353AE74800217ADC@PSB> <7EDFAAE2-3109-4D16-BC16-1A47DB365522@ietf.org> <E022AAF289DF04D70F449FF7@PSB> <5B8EC861-46AF-497A-88F1-8F1024F7EF81@tzi.org> <CCFF6F19FB455A9C283B1885@PSB> <4BF83022-22DB-41CD-A34A-525AFB3D9183@tzi.org> <F00F40BF854CE44940245317@PSB>
From: Kesara Rathnayake <kesara@staff.ietf.org>
Organization: IETF Administration LLC
In-Reply-To: <F00F40BF854CE44940245317@PSB>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/nH16LiAMqjbdTwadrGCg5cLUuPg>
Subject: Re: [Tools-discuss] xml2rfc in --v2 mode -- bug report?
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Jun 2022 23:36:49 -0000


On 13/06/22 10:49 am, John C Klensin wrote:
> 
> 
> --On Sunday, June 12, 2022 23:09 +0200 Carsten Bormann
> <cabo@tzi.org> 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 - Tools-discuss@ietf.org
> This list is for discussion, not for action requests or bug reports.
> * Report datatracker and mailarchive bugs to: datatracker-project@ietf.org
> * Report all other bugs or issues to: support@ietf.org
> List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss
> 

-- 
Kesara Rathnayake
Senior Software Development Engineer - IETF LLC
kesara@staff.ietf.org