Re: [Rswg] Fwd: I-D Action: draft-hoffman-rfc7990-updates-02.txt

John C Klensin <john-ietf@jck.com> Mon, 06 February 2023 15:02 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: rswg@ietfa.amsl.com
Delivered-To: rswg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF7FC152564 for <rswg@ietfa.amsl.com>; Mon, 6 Feb 2023 07:02:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level:
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 tUqdotfYDh5p for <rswg@ietfa.amsl.com>; Mon, 6 Feb 2023 07:02:02 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53646C1522AA for <rswg@rfc-editor.org>; Mon, 6 Feb 2023 07:02:01 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1pP30F-000D8Q-4S; Mon, 06 Feb 2023 10:01:55 -0500
Date: Mon, 06 Feb 2023 10:01:48 -0500
From: John C Klensin <john-ietf@jck.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Paul Hoffman <paul.hoffman@icann.org>
cc: rswg@rfc-editor.org
Message-ID: <A89B86BE3881F62D575785F6@PSB>
In-Reply-To: <05d2f798-0873-e181-746d-00add1160f56@it.aoyama.ac.jp>
References: <167563623265.40427.755378709553486458@ietfa.amsl.com> <05d2f798-0873-e181-746d-00add1160f56@it.aoyama.ac.jp>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/rswg/u2-eV3q7s973CZJ5UEOxuwgg4Ug>
Subject: Re: [Rswg] Fwd: I-D Action: draft-hoffman-rfc7990-updates-02.txt
X-BeenThere: rswg@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RFC Series Working Group \(RSWG\)" <rswg.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/rswg>, <mailto:rswg-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rswg/>
List-Post: <mailto:rswg@rfc-editor.org>
List-Help: <mailto:rswg-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/rswg>, <mailto:rswg-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Feb 2023 15:02:06 -0000

Hi.
Agree with Martin.

In addition, if changes to the canonical XML format are allowed
when deemed necessary, it may be time for serious discussions
about:

(1) The relationship between "canonical" and "archival"
discussed in Section 2 of this document and whether we now mean
"most recent archived" as that section says.

(2) What the actual threshold for what Martin describes as
"deemed necessary" and if we have any opinion about how often
that might occur.  "XML format errors, and better design
choices" can be interpreted as allowing ongoing, perhaps
continual, tinkering and my impression has been that is not what
all of the community wants.

(3) Whether, given recent discussions about different ways to
prepare RFCXML documents and differences between the set of
elements that are expected to be used by document authors and
the set used by the RPC, there are actually two canonical forms
(or variants on one) and, if so, which one should be archived.
If the archived version is intended only to preserve a
historical record and, potentially, generate different output
forms as needs change, the answer is probably obvious.  If it is
also intended to provide a starting for substantive document
revisions (i.e., replacement / "obsoleting" RFCs), the answer
may be less obvious.

(4) Whether, referring back to recent comments, we really want
the XML to be the official, stable, archival form or whether we
treat that as a slightly failed experiment, define a canonical
form for the XML and retain it and keep it available but make
one of the output formats (presumably PDF/A) the archival form
and, where relevant, the reference form for very long=lived
substantive references.

(5) "The RFC Editor must also make available all earlier
versions of the XML file." does not imply (at least to me) any
community commitment to make it possible to process those
earlier versions.  The alternative is, I think, to keep them as
artifacts to be admired with little expectation of being able to
processing them directly into output formats.

thanks,
   john


--On Monday, February 6, 2023 17:48 +0900 "Martin J. Dürst"
<duerst@it.aoyama.ac.jp> wrote:

> I guess this document is intended for the RSWG, because it
> defines policy for the RFC Editor. That's why I'm sending my
> comments to this list.
> 
> My understanding is that this document essentially says that
> changing the canonical XML format is allowed when it is deemed
> necessary.
> 
> I can live with this (I guess I could also live with not
> allowing changes to the canonical XML). But I think it may be
> a hot topic. Therefore, I think it would be good to say, in
> the Abstract and the Introduction, *how* the definition of the
> "canonical format" for RFCs is (proposed to be) changed.
> Possibly even changing the title to include this information
> might be good.
> 
> Regards,   Martin.
> 
> 
> -------- Forwarded Message --------
> Subject: I-D Action: draft-hoffman-rfc7990-updates-02.txt
> Date: Sun, 05 Feb 2023 14:30:32 -0800
> From: internet-drafts@ietf.org
> Reply-To: internet-drafts@ietf.org
> To: i-d-announce@ietf.org
> 
> 
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> 
> 
>          Title           : Canonical Format for RFCs
>          Author          : Paul Hoffman
>    Filename        : draft-hoffman-rfc7990-updates-02.txt
>    Pages           : 4
>    Date            : 2023-02-05
> 
> Abstract:
>     This document updates RFC 7990 by changing the definition
> of the
>     "canonical format" for RFCs.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-hoffman-rfc7990-updates/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-hoffman-rfc7990-up
> dates-02
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-hoffman-rfc799
> 0-updates-02
> 
> 
> Internet-Drafts are also available by rsync at
> rsync.ietf.org::internet-drafts
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt