Re: [Rswg] Alternative approach to RFC 7991 "as-is"

Jay Daley <exec-director@ietf.org> Fri, 25 November 2022 14:24 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 A5164C14CE5B for <rswg@ietfa.amsl.com>; Fri, 25 Nov 2022 06:24:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, 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 9c8DkTLE1uGj for <rswg@ietfa.amsl.com>; Fri, 25 Nov 2022 06:24:46 -0800 (PST)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 B6B6BC14CE51 for <rswg@rfc-editor.org>; Fri, 25 Nov 2022 06:24:46 -0800 (PST)
Received: by mail-wr1-x431.google.com with SMTP id d1so6979978wrs.12 for <rswg@rfc-editor.org>; Fri, 25 Nov 2022 06:24:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ietf-org.20210112.gappssmtp.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Axy+HNGuvjuthiZjZX6MgZFcdCA00BFNjEewOBKNEpI=; b=jYWxtSJWc2hFuFWsVKG1wA5W1qJyD6GE9Qb8KzIvQsZpxQ6F1C//GKiSjuT/8AB4ML jBCzJ5TxbvE7ki/OHmI1FuGFjsNphekaF/JxSDOxEEy2cyz0BtGxH3nf/8KooE4piPkW X21O7FZxHbRervFCKTIWDHuKX3Q4tOI6jUk5gHSE3YbVwYeChcFeR8mPPKrXgwGD5gKK dWR57WTbigN28iEI4SwKwtLoKBrUpbwS//jhDoywCNwH9ZHjKpQVXpNfOeyRp8jHwlql jQ6/wljNVzzppyQwy64cojEmkLXoebClP4RcLcJHF13iU/jFSSXVZUszwJwxpN5MVxnR Xx+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Axy+HNGuvjuthiZjZX6MgZFcdCA00BFNjEewOBKNEpI=; b=OS1RCZByjQsqPbDg2T0Cqsulni7PqSMWmfZ38g7pJILe2Quc4fmtI1WOAE32inrZKe upE5m6/lZYiP1MH4FzSIaRxcZMjbNuJZq45BwVY6uaqK2Pf3ps5kksic8pY+OdBMAgKf wbXKYSHl4C/cUGwqieTxgWGcysBsaQAtoIKMOBONkUkiqH4a1etLrhhTxFa796pwv1tw rXPt7PR3x3Ow2iKYBoxmJr7AyEMqtYy+f510WArUI7a8EGNM+AgKV8l0hFrbe3YHCfWM Npgc0mj0+PZ1ZPW180DAWlODCspV53fY53g7ny6Lhu9UmMKPW/LXXn70FPc6IsRQmhMg jxVQ==
X-Gm-Message-State: ANoB5plpfHYHS1RePwkK4FvC7EFK+wyYXsnRQzdlIh2usHTI3xkZqNIQ Tf8HmWkMBCDN4pxE6fu9RFGkuA==
X-Google-Smtp-Source: AA0mqf5zlbFNL7sJBciQ6pMe/5qtcknqpD8iLyp3heAfD2cE4ijz6SNtxeaaxAhQ07PgEUdU4lA3mA==
X-Received: by 2002:adf:f54d:0:b0:242:9e6:ea4d with SMTP id j13-20020adff54d000000b0024209e6ea4dmr215832wrp.251.1669386284000; Fri, 25 Nov 2022 06:24:44 -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 m1-20020a05600c4f4100b003b4fe03c881sm8958161wmq.48.2022.11.25.06.24.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Nov 2022 06:24:43 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Jay Daley <exec-director@ietf.org>
In-Reply-To: <a0b7f382-bdd0-a64b-b71e-cfa84d653234@gmail.com>
Date: Fri, 25 Nov 2022 14:24:42 +0000
Cc: Mark Nottingham <mnot@mnot.net>, RSWG <rswg@rfc-editor.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C8A8326-49A2-4218-BE78-3DFF41205838@ietf.org>
References: <9C4AE8BA-5A17-4569-A2DE-EFC203FD2B04@ietf.org> <C1D494F3-DF69-44E1-A369-110FE79CDB96@mnot.net> <a0b7f382-bdd0-a64b-b71e-cfa84d653234@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rswg/DK2DD_rhE58KRvwWeosd0AAsL3k>
Subject: Re: [Rswg] Alternative approach to RFC 7991 "as-is"
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: Fri, 25 Nov 2022 14:24:50 -0000


> On 25 Nov 2022, at 01:27, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 25-Nov-22 12:25, Mark Nottingham wrote:
>> I was not happy about publishing RFC7991-as-is, but had convinced myself that doing so would allow us to move forward and wouldn't cause too much harm. I felt that we could put disclaimers at the top of the document that described its status adequately.
>> Jay, your message has convinced me to reconsider that stance. Describing the status of the document accurately effectively reduces it to tool documentation, not something worthy of being published as an RFC that represents any kind of consensus. I'm MUCH more comfortable with your proposal -- we document the state of the world right now, rather than digging further.
>> In other words, let's just publish the disclaimers, not the actual grammar. It's not ready, nor stable.
> 
> As far as this group's job as an RFC-producer goes, I think you are correct. On the other hand, from a purely practical point of view, as an RFC author, I'd like to easily find a pointer to the currently implemented grammar.
> 
> That seems to exist, as https://authors.ietf.org/rfcxml-vocabulary, but could we be assured that it is *definitively* what is currently implemented? This is implied rather than stated at https://authors.ietf.org/rfcxml-overview#background, but I'd rather it was said clearly, including the statement that it's a different grammar than RFC7991 describes.

Does this address your concerns?  https://github.com/ietf/authors.ietf.org/pull/48

Jay

> 
> In that case, both draft-hoffman-rfc-format-framework-as-implemented-01 and draft-irse-draft-irse-xml2rfcv3-implemented-02 should probably be set aside for now.
> 
>   Brian
> 
>> Cheers,
>>> On 25 Nov 2022, at 4:02 am, Jay Daley <exec-director@ietf.org> wrote:
>>> 
>>> I’ve finally watched the video of the RSWG meeting at IETF 115 having missed the first part of the meeting and I have some reactions to Martin’s presentation recommending that the RSWG doesn’t develop a 'RFC 7991 "as-is"' (an RFC that documents the currently implemented RFCXML grammar, and which John Levine has already largely completed).  I was initially going to write a long post setting out why I disagree with Martin but I suspect that approach would not get us any closer to consensus, so I’m going to suggest an alternative approach.
>>> 
>>> The big problem I see is that RFC 7991 is wrong and perhaps we ought to address that wrongness as the priority.  In other words, maybe we just need an RFC that says
>>> 
>>> 1.  RFC 7991is obsoleted
>>> 2.  There is no replacement RFC
>>> 3.  v4 is being worked on, and
>>>   a.  it will be published as a consensus RFC (but we may change our mind)
>>>   b.  A wide range of issues will be considered
>>>   c.  It may not be backwards compatible with v3
>>> 4.  Until such time as there is a v4
>>>   a. The v3 grammar may change
>>>   b. If the v3 grammar does change then it will only do so in a way that is backwardly compatible with all RFCs published in v3 (the originally published XML will continue to validate)
>>>   c. The IETF website (or the authors.ietf.org sub-site) should be considered the authoritative source of documentation for v3
>>>   d. The IETF Tools GitHub repository should be considered the authoritative source of the v3 grammar files.
>>> 
>>> This doesn’t address the point that we need a document that acts as the historical record of the final v3 grammar so that people can correctly interpret the XML in 20 years (because we can assume the documentation site will have changed), but it does buy us time and of course we can publish that at the same time as we publish v4 because that’s when it’s actually needed.
>>> 
>>> Any thoughts?
>>> 
>>> Jay
>>> 
>>> -- 
>>> Jay Daley
>>> IETF Executive Director
>>> exec-director@ietf.org
>>> 
>>> -- 
>>> rswg mailing list
>>> rswg@rfc-editor.org
>>> https://mailman.rfc-editor.org/mailman/listinfo/rswg
>> --
>> Mark Nottingham   https://www.mnot.net/

-- 
Jay Daley
IETF Executive Director
exec-director@ietf.org