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

Jean Mahoney <jmahoney@amsl.com> Thu, 16 February 2023 23:45 UTC

Return-Path: <jmahoney@amsl.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 594D0C169509 for <rswg@ietfa.amsl.com>; Thu, 16 Feb 2023 15:45:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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 B-Jz0tw04JwU for <rswg@ietfa.amsl.com>; Thu, 16 Feb 2023 15:45:09 -0800 (PST)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (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 9B1E8C14F74E for <rswg@rfc-editor.org>; Thu, 16 Feb 2023 15:45:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 8B0DA424B445; Thu, 16 Feb 2023 15:45:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpAi-5lDjmCl; Thu, 16 Feb 2023 15:45:09 -0800 (PST)
Received: from [192.168.1.203] (unknown [47.186.48.51]) by c8a.amsl.com (Postfix) with ESMTPSA id 5ECC8424B444; Thu, 16 Feb 2023 15:45:09 -0800 (PST)
Message-ID: <a36baf25-b850-1fcb-dc92-0a5f1e165bbe@amsl.com>
Date: Thu, 16 Feb 2023 17:45:08 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.7.2
Content-Language: en-US
To: Eric Rescorla <ekr@rtfm.com>, RSWG <rswg@rfc-editor.org>
References: <CABcZeBM1TKqRkXJ8JErVijoKhEKOa+ebWDpxfERuq1NhUrSG4g@mail.gmail.com>
From: Jean Mahoney <jmahoney@amsl.com>
In-Reply-To: <CABcZeBM1TKqRkXJ8JErVijoKhEKOa+ebWDpxfERuq1NhUrSG4g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rswg/F_3Zmh_IzhkR-PTceYjQnob_L8g>
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: Thu, 16 Feb 2023 23:45:13 -0000

Hi all,

On 2/13/23 2:27 PM, Eric Rescorla wrote:
> 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
> 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.
[JM] This one, right?
https://mailarchive.ietf.org/arch/msg/rswg/bn6VISUwjaeCZhq-A6Lb9SKXWT8/

>
> - Adopt draft-irse-draft-irse-xml2rfcv3-implemented as a WG document
>   to use as the basis for v3.1.
>
> - 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.
[JM] I believe that RFC 7991 "The "xml2rfc" Version 3 Vocabulary" is 
meant here rather than RFC 7990 "RFC Format Framework".

>
> - 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.

[JM]  (With my RPC hat on) I'd like to clarify this point.

A definition of "emergency" here would be that the RPC cannot publish an 
RFC because of an XML issue. The RPC would consult with RPAT on 
technical aspects and take the issue to RSAB. The emergency would be 
handled by RSAB and the RPC.

Does the following capture the RSWG procedure? If the resolution of the 
emergency caused any changes to the XML vocabulary, then the RSWG would 
handle those changes like the other XML changes: capture it in the I-D 
and label it as provisional. The RSWG would then discuss and adopt the 
change or move it to the appendix. This part of the process can happen 
later; that is, the publication of an RFC does not wait on the RSWG's 
discussion and labeling of any changes.

Also hoping that this will be a rare thing.

Best regards,
Jean


>
> 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?