Re: [xml2rfc] Differentiating prepped from unprepared documents

"John R. Levine" <johnl@iecc.com> Wed, 22 June 2022 21:47 UTC

Return-Path: <johnl@iecc.com>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05946C15AAC4 for <xml2rfc@ietfa.amsl.com>; Wed, 22 Jun 2022 14:47:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com
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 Nyo6Vwru6KgX for <xml2rfc@ietfa.amsl.com>; Wed, 22 Jun 2022 14:47:52 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 610E0C164773 for <xml2rfc@ietf.org>; Wed, 22 Jun 2022 14:47:48 -0700 (PDT)
Received: (qmail 80567 invoked from network); 22 Jun 2022 21:47:46 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=13ab5.62b38e02.k2206; bh=N4Ee3YhRuqZjqNIeaOjSzI/tsOqaJNekOdSLCdSlDGM=; b=Z+xbYVfw3oSG7dq8KaKADQFHRTZ8/ViV5cJtpkwnZDUXxaVG7Q3J9ZQ8cH0sQOZyWQz8m4VqidnbWbN4262DqQLCbdlqj8ki/DLEEMbIAM9UUBPkzP1kENX3828Q+F4lhpf3KCkSeHFYXHBCtSIULxirD9T4DcjY/pGiH/FK2urG5CddcmjMLZi98SiNYH2X9wJcIar0W4HA2RvQK7iyFjjD35nFRODze/1GOH8ROMVBWZHsb/enzNUaZwzs9brLgFOQXVbvYrsQiJwlVROntRf6ya77ZM3JiO1dxiHP4ojIq1mh/QgClzB2ooZ3KykLhFEgrH1UFaZIpkGd1Me0Cg==
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.3 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 22 Jun 2022 21:47:45 -0000
Received: by ary.qy (Postfix, from userid 501) id 79539441D743; Wed, 22 Jun 2022 17:47:44 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id D0248441D725; Wed, 22 Jun 2022 17:47:44 -0400 (EDT)
Date: Wed, 22 Jun 2022 17:47:44 -0400
Message-ID: <d6bb380d-f000-0388-bbf3-1423846b5ebe@iecc.com>
From: "John R. Levine" <johnl@iecc.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Jay Daley <exec-director@ietf.org>, xml2rfc@ietf.org
Cc: Julian Reschke <julian.reschke@gmx.de>
X-X-Sender: johnl@ary.qy
In-Reply-To: <d8b7991c-344a-5741-afd8-52f5db1f8f50@gmail.com>
References: <222A7719-518F-45FB-BE05-A3CA1172DD9B@ietf.org> <d8b7991c-344a-5741-afd8-52f5db1f8f50@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/_EVpU7AmNIG7GWa_yH4A_Kr0EjE>
Subject: Re: [xml2rfc] Differentiating prepped from unprepared documents
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: XML2RFC discussion list <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jun 2022 21:47:57 -0000

> From the viewpoint of a user, this sounds very sensible. However, I have a 
> couple of questions:
>
> 1. (minor) Will things that are only of use in an I-D look as they do now? 
> For example
> <note removeInRFC="true">

Not having designed it yet, I dunno.

> 2. (substantive) A common need when working on a bis document is to retrieve 
> the *unprepped* XML as opposed to the canonical prepped XML, and ideally it 
> should include exactly what was in an I-D that never existed - all the user's 
> non-default choices, but also the text edits made by the RFC Editor. Can that 
> need be satisfied?

Assuming we make the unprep tool work, that's what you should get if you 
unpprep a published RFC. I suppose there might be a minor tweak or two to 
the header turn it from an RFC back into an I-D.

Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly