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

Jay Daley <exec-director@ietf.org> Fri, 25 November 2022 19:43 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 834A6C1524A2 for <rswg@ietfa.amsl.com>; Fri, 25 Nov 2022 11:43:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 nxiqe9sU0EYM for <rswg@ietfa.amsl.com>; Fri, 25 Nov 2022 11:43:29 -0800 (PST)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 13E9BC1522A9 for <rswg@rfc-editor.org>; Fri, 25 Nov 2022 11:43:29 -0800 (PST)
Received: by mail-wm1-x32c.google.com with SMTP id p16so4209212wmc.3 for <rswg@rfc-editor.org>; Fri, 25 Nov 2022 11:43:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ietf-org.20210112.gappssmtp.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=8hwFYU6dpCXDMin5kfvVVBS8k60hvgdvtIiFfrPBObs=; b=In9oRNVt4JLbn9ZnoyA6Age5ynHYZv4Lzw8g4whqOdjjsgfjAry/vIgAV/7CBUY4BO ec5WnQDad3zbWutA7FQU/4NfZrgay2dYMWEbKvkUL9GWM12SwA1JetLZKSLENbnMPTRt 3zra+yrmkCgqTq30GFPrkjO9BczJ60O5vx7QMn/SCsVUe4vwKRTSUtNRrMeyYFsWM4yr 4p+n9ne+5bNrLOADjvj4wH2CkiW0TzLN/Nla7n6sAxfpAJMgJpZvLa/MIXs9QUHh9ibt 7Wlvl0uEo12w0mWkOnqgJp/AlW55+VuyGPFcPTpeIkwQ7Yak0yQOl+nwWYNE5QiAmHCm tuMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8hwFYU6dpCXDMin5kfvVVBS8k60hvgdvtIiFfrPBObs=; b=VyNiULu9jZjtqzVglw6YVVqXHX3zS6Xcx9S0oF6BU1GUptOYvYOPSwRxPsQppPVNoS MRFoS95PgsLJ9onWtil4LMr5PVuMrDx34dcEbG2nqCtgmYHsXwTIdJd2zZkXn1LY9xid oi4ztBVunkIJvenvI09cSCRAIJGGzwkAx6Sc+tiNozvrscTKKS7PJXIbBCgZxIK8jNBw WG1MXBx3Urrg6NEb3Hi5JaWMST+GDEJkdSZXnK61bhnXFQLDya+c2Tw779c9EEsb04YZ w7RDY8hHGEii8mQx0x0xN/IHo1Aqz8zPeFi9kIt937EVph7hIMBIGZNs47NJb9DyFFfp Gl3w==
X-Gm-Message-State: ANoB5pl5GwvP8Renh9cz/mU1zDwtQzpkyU7Ww3lnDUQ6+edPlV25KeKg pk0DWwqLAq+RH2RN5OShxgFAAg==
X-Google-Smtp-Source: AA0mqf5ywcx0mIeGhx6X+UWBVw9lg6iKXncBDkJxyMfj/PpDXnBDCZv6uuWjJ6YxbMKD+l4k5c0XtQ==
X-Received: by 2002:a1c:f616:0:b0:3cf:b1c2:c911 with SMTP id w22-20020a1cf616000000b003cfb1c2c911mr21919233wmc.16.1669405406765; Fri, 25 Nov 2022 11:43:26 -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 f13-20020a05600c4e8d00b003c6c182bef9sm13644444wmq.36.2022.11.25.11.43.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Nov 2022 11:43:25 -0800 (PST)
From: Jay Daley <exec-director@ietf.org>
Message-Id: <00AC2319-E2A7-4E50-843D-81A95A99062E@ietf.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A4B26E1F-FB84-47C9-9C9D-23D0133BB79B"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Fri, 25 Nov 2022 19:43:23 +0000
In-Reply-To: <87133f12-fefc-6e94-1078-743a004ea77e@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>, RSWG <rswg@rfc-editor.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <9C4AE8BA-5A17-4569-A2DE-EFC203FD2B04@ietf.org> <C1D494F3-DF69-44E1-A369-110FE79CDB96@mnot.net> <a0b7f382-bdd0-a64b-b71e-cfa84d653234@gmail.com> <0C8A8326-49A2-4218-BE78-3DFF41205838@ietf.org> <87133f12-fefc-6e94-1078-743a004ea77e@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rswg/hnQAZc8Xa2Er4AtmkI10891yncc>
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 19:43:33 -0000


> On 25 Nov 2022, at 19:34, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 26-Nov-22 03:24, Jay Daley wrote:
>>> 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
> 
> Yes! (I noted one typo on GitHub.)

Fixed and the text has been updated.

Jay

> 
> Thanks
>    Brian
> 
>> 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