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
- [Tools-discuss] xml2rfc in --v2 mode -- bug repor… John C Klensin
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… Carsten Bormann
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… Carsten Bormann
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… Julian Reschke
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… Jay Daley
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… John C Klensin
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… Carsten Bormann
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… John C Klensin
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… Carsten Bormann
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… John C Klensin
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… Kesara Rathnayake
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… John C Klensin
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… Kesara Rathnayake
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… Jay Daley
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… Robert Sparks
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… Carsten Bormann
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… John C Klensin
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… John C Klensin
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… Julian Reschke
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… Julian Reschke
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… Julian Reschke
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… Julian Reschke
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… Jay Daley
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… John C Klensin
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… John Levine
- Re: [Tools-discuss] xml2rfc in --v2 mode -- bug r… Martin Thomson