Re: [Rswg] Making progress on evolving the XML format

Jay Daley <exec-director@ietf.org> Mon, 13 February 2023 22:48 UTC

Return-Path: <jay@staff.ietf.org>
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 AF898C187984 for <rswg@ietfa.amsl.com>; Mon, 13 Feb 2023 14:48:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ietf-org.20210112.gappssmtp.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 1CuDZpaXV-UQ for <rswg@ietfa.amsl.com>; Mon, 13 Feb 2023 14:48:02 -0800 (PST)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 E7808C18798A for <rswg@rfc-editor.org>; Mon, 13 Feb 2023 14:48:02 -0800 (PST)
Received: by mail-wr1-x432.google.com with SMTP id h16so13769246wrz.12 for <rswg@rfc-editor.org>; Mon, 13 Feb 2023 14:48:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ietf-org.20210112.gappssmtp.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=vDxzKD7oQss9suik/+qm6pxy+It4VPpgYi8LSewvZWI=; b=SmIMJ7E4dpdFGFseEKACpIALc2u+G4tR1E1YLPU2FPBuNHwyWYaOoW//NDr7IqPARJ +yd+4DqZUG211GKZq2V2g36gw/msOrp1Xem/M3BVyvXZ9YtCFJTwgAaKmK4Dsia2aNEt AFLbV6Ik+DJ1gnE9isElbJ20rbwCfWT8/MXD/LJRWkGMZX/D+JZTEgINGgaMuH/Ltql+ LfA+lMnbDEhvFN6lnABuTHuXk4ninmmnUU1MKw2/IAq6rKxk/Cut2jQzMcNYqdvyRw1v Z4pT39S6uNzg3p1i/LMI7bjZ+PIygr+p739ULgXN8O5cQGS3n/SNc2njBuBoSSFN0UAm 58Ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vDxzKD7oQss9suik/+qm6pxy+It4VPpgYi8LSewvZWI=; b=7hvQwNZiCmV5VwkzatahwyE7lNW5ujaoZYvJK3w8Lw8J45E/fzZEqBmwxjn5kPbWV2 QtX/fTZyfJAPybtxopCb2Dh0NnbZmRwjXVJ16rocixdhATszTCwegYN4YUoZTtrCaIgd 9VhzukSMh/uc6YJaNmPvcI1c29zrW7TUBRkQ7VunkH4UnacF92i9iq01doPkC3E8s8Xo RvpkVa5vKVB3eWnTaXi0RnfkBcGfd1ONgDpHjrdbxrFdipn7/6gB0SBL3CXT2Zann5sm Nt9ogTWhX99kci5qMPvISi0xae8xr6xUKmuykd/pQhJ4hz7GALnYhC4AAj10UCm2iyvl WXqA==
X-Gm-Message-State: AO0yUKXjZ1s/fMMaWp2U8n1L9pelRqJMV2J0+XB2AUUMeCVcLaCF5ZC3 /mPMB5/GgpKAhVplm4BxehvRLWsz6KGCQwczpI0=
X-Google-Smtp-Source: AK7set9CtB2d5ZlPCEwblYGlKf+DNqoZ7/CpV0SEpuhRE/lSNnbyZRUyV+XrfKvp0KxrsAmmHwvRDw==
X-Received: by 2002:a5d:544d:0:b0:2c3:e7f5:be8c with SMTP id w13-20020a5d544d000000b002c3e7f5be8cmr181620wrv.26.1676328480085; Mon, 13 Feb 2023 14:48:00 -0800 (PST)
Received: from smtpclient.apple (host-92-27-125-209.static.as13285.net. [92.27.125.209]) by smtp.gmail.com with ESMTPSA id t15-20020a5d534f000000b002c55306f6edsm5555814wrv.54.2023.02.13.14.47.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Feb 2023 14:47:58 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Jay Daley <exec-director@ietf.org>
Mime-Version: 1.0 (1.0)
Date: Mon, 13 Feb 2023 22:47:47 +0000
Message-Id: <01187D4D-5033-41B5-A027-4917E14787E7@ietf.org>
References: <CABcZeBM1TKqRkXJ8JErVijoKhEKOa+ebWDpxfERuq1NhUrSG4g@mail.gmail.com>
Cc: RSWG <rswg@rfc-editor.org>
In-Reply-To: <CABcZeBM1TKqRkXJ8JErVijoKhEKOa+ebWDpxfERuq1NhUrSG4g@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: iPad Mail (20C65)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rswg/usgqxU8pua0CxCMxN764uVQQR5Y>
Subject: Re: [Rswg] Making progress on evolving the XML format
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, 13 Feb 2023 22:48:06 -0000

Seems a practical way forward.  A few points below:

> On 13 Feb 2023, at 20:28, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> Hi RSWG members,
> 
> Pete and I have been chatting about the best way forward for evolving
> the XMLv3 grammar. We think that there's broad agreement that:
> 
> 1. We need some document that describes the "as-is" xmlv3 format.
>    - That document should be published in some form that implies
>      it doesn't have consensus.
>    - The WG should do the work of making sure that happens

Would we assign that a version number? If so then would it replace v3 or be a v3.1 with no documents ever having been published in v3?  Before answering this you might want to read further on. 

> 2. We need to work on a new format (v3.1?) that will have consensus.
> 
> I think people are assuming that the new format will need an RFC but
> there is not agreement on whether the "as-is" should be.
> 
> 
> Pete and I would like to propose the following way forward, based
> on a suggestion from Martin Thomson in January.
> 
> - Adopt draft-irse-draft-irse-xml2rfcv3-implemented as a WG document
>   to use as the basis for v3.1.

Wouldn’t that draft also be the basis for 1. above?

> 
> - Everything that doesn't match RFC 7990 will be marked as
>   "provisional". We go through all of these and either adopt them as
>   having consensus or decline to make the change, in which case we
>   move them to an Appendix.

If we did remove something, then documents in the new grammar would no longer be backwards compatible (unless that thing had never been used) with those in the as-is grammar. I would prefer then that we numbered it v4 to signal that. If we were to keep the version number 3.1 then we would have

- v3/7990 which was never used for a document 
- version ”as-is” which all the current documents are in
- v3.1 which none of the existing documents are in and which all future ones will be

Jay

-- 
Jay Daley
IETF Executive Director 
> 
> - If necessary, we can also update the I-D to make consensus changes
>   to the as-is version on an "emergency" basis, though hopefully
>   this will not be needed often.
> 
> At the end of this process, we will have a document which describes
> the consensus format and also an appendix which describes how "as
> implemented" differs from the consensus format. These can be published
> together as an RFC, which will provide archival forms of both but
> without requiring that we publish an RFC of the current document while
> the consensus version is still in flux. In the meantime, the ID
> can serve as the definition of the current format.
> 
> What do people think of this proposal?
> -Ekr
> -- 
> rswg mailing list
> rswg@rfc-editor.org
> https://mailman.rfc-editor.org/mailman/listinfo/rswg