Re: [dispatch] [rfc-i] Advice when converting W3C ED to I-D

Carsten Bormann <cabo@tzi.org> Mon, 18 September 2023 12:00 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D08DC151987 for <dispatch@ietfa.amsl.com>; Mon, 18 Sep 2023 05:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 sDtU5xeKq5T3 for <dispatch@ietfa.amsl.com>; Mon, 18 Sep 2023 05:00:50 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::21]) (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 53A7EC151985 for <dispatch@ietf.org>; Mon, 18 Sep 2023 05:00:48 -0700 (PDT)
Received: from smtpclient.apple (p548dc15c.dip0.t-ipconnect.de [84.141.193.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Rq3K84sFfzDCdW; Mon, 18 Sep 2023 14:00:44 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <4cv1A92QvTpimy732OIF2k6A0wFytnq0aCO4VyOOAfzcdhCGIxpdF79iedbG3XJbbhKOO3RZxRmcF2ctcK5jxv7J-apkFJkD6eu6Bcy9fak=@protonmail.com>
Date: Mon, 18 Sep 2023 14:00:34 +0200
Cc: "rfc-interest@rfc-editor.org" <rfc-interest@rfc-editor.org>, "dispatch@ietf.org" <dispatch@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4BB74C8E-5A2A-47F3-878A-52E11A1A82BF@tzi.org>
References: <FC5975A9-E5B2-4853-88D5-1B0A797DE82F@tzi.org> <4cv1A92QvTpimy732OIF2k6A0wFytnq0aCO4VyOOAfzcdhCGIxpdF79iedbG3XJbbhKOO3RZxRmcF2ctcK5jxv7J-apkFJkD6eu6Bcy9fak=@protonmail.com>
To: Rahul Gupta <cxres=40protonmail.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3731.700.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/AvExK7is5s5V3hRg14GjqAuWlN0>
Subject: Re: [dispatch] [rfc-i] Advice when converting W3C ED to I-D
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Sep 2023 12:00:54 -0000

On 15. Sep 2023, at 03:01, Rahul Gupta <cxres=40protonmail.com@dmarc.ietf.org> wrote:
> 
> Each RFC must include an Introduction section that (among other
>    things) explains the motivation for the RFC and (if appropriate)
>    describes the applicability of the document, e.g., whether it
>    specifies a protocol, provides a discussion of some problem, is
>    simply of interest to the Internet community, or provides a status
>    report on some activity.
> 
> In my epistemic understanding, it is unclear how this can ever be normative. To use simpler language, only "What" a user of the spec is supposed to do should be normative. “How” and “Why” the specification came about, i.e. the introduction, cannot be normative.

Please read the paragraph again: “among other things”.
Besides the items listed, most introduction sections describe the overall structure of what is being standardized.
If you don’t understand the overall structure, the other normative statements in the document are likely meaningless.
(I have seen plenty of RFC introductions that sport RFC 2119 language, which I consider bad style.
However, “describes the applicability of the document” is about as normative as it gets.)

I think the term normative simply means something different in the IETF: “normative” statements are statements that you need to understand to achieve an interoperable implementation.  I don’t know a clear reference for this definition, but [1] contains a form of it that is specialized for references.

Grüße, Carsten

[1]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/#:~:text=Normative%20references%20specify%20documents%20that,it%20only%20provides%20additional%20information.