Re: [Rfc-markdown] Carsten: Re: [rfc-i] summary of Removing postal information from RFCs

Jay Daley <jay@ietf.org> Tue, 20 July 2021 20:55 UTC

Return-Path: <jay@ietf.org>
X-Original-To: rfc-markdown@ietfa.amsl.com
Delivered-To: rfc-markdown@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8593A31D6 for <rfc-markdown@ietfa.amsl.com>; Tue, 20 Jul 2021 13:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nukOgqR6NLJ8; Tue, 20 Jul 2021 13:55:14 -0700 (PDT)
Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 117FD3A31D2; Tue, 20 Jul 2021 13:55:12 -0700 (PDT)
From: Jay Daley <jay@ietf.org>
Message-Id: <BA4E84AD-22C2-470F-A41D-09942DF33B00@ietf.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9A14EDC9-FE9F-42FF-9BED-FF69EC8E0158"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Wed, 21 Jul 2021 08:55:09 +1200
In-Reply-To: <65E34C78-8090-4534-8046-7E271B0ED07A@tzi.org>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, rfc-markdown@ietf.org, Toerless Eckert <tte@cs.fau.de>
To: Carsten Bormann <cabo@tzi.org>
References: <20210712034838.B461E209AFFB@ary.qy> <6c781dab-7a40-7031-be1c-d77a182f4cf4@gmail.com> <DE0CD982-D4BE-44A6-9234-B53A756E9717@mnot.net> <bbb8302a-4041-35db-ce61-d2a18b8ebeee@taugh.com> <AB6E5013-C14E-4962-8907-17F241971F9D@tzi.org> <20210719171839.GB24216@faui48e.informatik.uni-erlangen.de> <DBCC4252-8A2D-473C-82CD-B1B2688586D3@tzi.org> <15571.1626787687@localhost> <65E34C78-8090-4534-8046-7E271B0ED07A@tzi.org>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-markdown/0VPmLlhOHtAPOBMZC7KauE-z0SQ>
Subject: Re: [Rfc-markdown] Carsten: Re: [rfc-i] summary of Removing postal information from RFCs
X-BeenThere: rfc-markdown@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "rfc-markdown is a discussion list for people writing I-Ds and RFCs in Markdown and the authors of the tools used for that." <rfc-markdown.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rfc-markdown>, <mailto:rfc-markdown-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfc-markdown/>
List-Post: <mailto:rfc-markdown@ietf.org>
List-Help: <mailto:rfc-markdown-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rfc-markdown>, <mailto:rfc-markdown-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Jul 2021 20:55:22 -0000


> On 21/07/2021, at 1:59 AM, Carsten Bormann <cabo@tzi.org> wrote:
> 
> On 2021-07-20, at 15:28, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>> 
>> 
>> Carsten Bormann <cabo@tzi.org> wrote:
>>>> So, what is the relationship kramdown-rfc2629 to this ?
>>>> 
>>>> - Can the kramdown create xmlv3 output ?
>> 
>>> Yes, via the --v2v3 process in xml2rfc.
>> 
>> Do you think that you'll change to producing pure v3 output at some point?
> 
> Yes.
> 
> But since most processing of RFCXML involves xml2rfc already, and that already has a (by definition) perfect v3 generator, this doesn’t have very high priority.
> Any mistake I make there in kramdown-rfc leads to a show-stopper for an author, and that is exactly what kramdown-rfc is trying never to create.

I’m confused.  How is this different from the pre-v3 situation where kramdown-rfc was producing v2 and that could be rejected by xml2rfc if there was a mistake in it?

Jay

> 
>> I understand that might be awhile, or that -3 might become the default before
>> that point.
> 
> Right.  Again, there is very little reason to invalidate existing Makefiles etc., so changing defaults pretty much means making a renamed copy of a wrap-around processor like kdrfc.
> That is actually likely to happen quite soon.
> 
> (-3 is already default in, and the only way to run, kdwatch [1].)
> 
>> I'm just asking about processing plans.
> 
> I think progress here will be pretty much issue-driven; if an author finds an inconvenience in the current setup, that is more likely to be addressed than some abstract notion of compliance.
> (The main driver is actually AUTH48 processing, as the RPC operates on the converted v3 XML, so making diffs is harder for the authors when there are still pieces of v2 packaging around.  But making that process less impenetrable for authors is currently frustrated in more ways, so that is a larger project.  The other driver is missing features, mainly tables at this point.)
> 
>>> With the --v3 (-3) flag, kramdown-rfc2629 produces XML that xml2rfc can
>>> process, and that --v2v3 can turn into the current version of v3.
>>> This XML is no longer v2 compliant, as it uses the new features of v3.
>> 
>> So it's some kind of v2 / v3 mutt :-)
> 
> It is pretty much one of the two authoring interfaces provided by xml2rfc to v3; it is just weird that the I-D submission interface is in denial about that.
> 
> Grüße, Carsten
> 
> [1]: https://github.com/cabo/kdwatch
> 
> _______________________________________________
> Rfc-markdown mailing list
> Rfc-markdown@ietf.org
> https://www.ietf.org/mailman/listinfo/rfc-markdown

-- 
Jay Daley
IETF Executive Director
jay@ietf.org