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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 25 November 2022 19:34 UTC

Return-Path: <brian.e.carpenter@gmail.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 8B2D5C14CE4A for <rswg@ietfa.amsl.com>; Fri, 25 Nov 2022 11:34:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 Xp77TFOuWkkP for <rswg@ietfa.amsl.com>; Fri, 25 Nov 2022 11:34:14 -0800 (PST)
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 ACC5FC14CE47 for <rswg@rfc-editor.org>; Fri, 25 Nov 2022 11:34:14 -0800 (PST)
Received: by mail-pj1-x102c.google.com with SMTP id a22-20020a17090a6d9600b0021896eb5554so8517890pjk.1 for <rswg@rfc-editor.org>; Fri, 25 Nov 2022 11:34:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=vLgArjyr+ylVTIa2PzyGU+glT/49sG00p5yPGhtJ7RI=; b=T6ibwy3rZDzAM3wDJjEQPIa+9c6jLNvabU/NJcB74b+gLzbpUhiNNAwH7qTnGJ8I0I wxJQHdrcotp1370f3qbquk4qpfPYgEiJnVFFiLnKrY5/3h5HrJoNwXvHDTUDWbHLa6WE 1MAxh+Vti1cpbF05iT1/hytpdnwV1iprX1hYzS2REArhFKr7/m9qcCbOF03PjMqaosoL 9ZLIDHvMhumGl5y8fQtZ7pE7BR21O6Lnfv23loZTuOAoX6p3Lpz/umC11mBncJgMB22c d/O2Xt3cPe4rTVHL03MXddx4ve+J4OzJXEuk+bYSBRGy/ZJxhew4W5Xo/1by1OPj2cnT wyNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vLgArjyr+ylVTIa2PzyGU+glT/49sG00p5yPGhtJ7RI=; b=kvVy8lW4/5vWdoX8qyzSjxR8LYPUcP7JSMTwuiw7qXkpnxeYHfCxNv5BO3fClmFjhE YXwNwrIheH8buhzbni8q4uiTWh8nF/FCuXR/JI/kgTuSsfeAMF1q7Wn0YIuCep4r90YP Ss5JrMRJKMCgbxzONFWwDcWk+mXnCqrqTslrwBSURCj4C669QILv0CxaB/DI3GLQi22S uIhLuHWRYbetcUe4BS4yAvu6JTfXbVYAXVg3dbuou9EMqiVkbXZD0mqGB5Ct5K4ZN9Wz l/tCkKvPZpZQmlNDECnBpRuCDRgpSlnMacQtHKe91gk+oPWEIb6+1rcL0e1oZB6s2Yk2 BVHA==
X-Gm-Message-State: ANoB5pkU9SfdwbxIEgBc85XSbbhenpoHULI6w91Uedo+Dqh5v9RwsmQQ fkQUldEiuozKswQB4USam1GLEV9KQyxM6Q==
X-Google-Smtp-Source: AA0mqf707c8KMmnGSxTmT531p8ZS8Ffzj4dCOej+MBG2yttwdN63XCHzc/DWs3m03PvURBM4ZlBgbg==
X-Received: by 2002:a17:903:22d0:b0:188:b840:deec with SMTP id y16-20020a17090322d000b00188b840deecmr33021463plg.15.1669404853884; Fri, 25 Nov 2022 11:34:13 -0800 (PST)
Received: from ?IPV6:2406:e003:1124:9301:672e:17ee:b374:8a9b? ([2406:e003:1124:9301:672e:17ee:b374:8a9b]) by smtp.gmail.com with ESMTPSA id h11-20020a170902f54b00b00177faf558b5sm3756108plf.250.2022.11.25.11.34.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Nov 2022 11:34:12 -0800 (PST)
Message-ID: <87133f12-fefc-6e94-1078-743a004ea77e@gmail.com>
Date: Sat, 26 Nov 2022 08:34:09 +1300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Jay Daley <exec-director@ietf.org>
Cc: Mark Nottingham <mnot@mnot.net>, RSWG <rswg@rfc-editor.org>
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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <0C8A8326-49A2-4218-BE78-3DFF41205838@ietf.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/rswg/gwsA_kgtX99-rQQhrnFMLTYW444>
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:34:18 -0000

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

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