Re: [dispatch] [rfc-i] Advice when converting W3C ED to I-D
John C Klensin <john@jck.com> Mon, 18 September 2023 22:15 UTC
Return-Path: <john@jck.com>
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 E6DCFC15108A; Mon, 18 Sep 2023 15:15:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 BW254XbTIqJg; Mon, 18 Sep 2023 15:15:49 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B797C13AE4C; Mon, 18 Sep 2023 15:15:43 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john@jck.com>) id 1qiMWn-00030Z-9L; Mon, 18 Sep 2023 18:15:37 -0400
Date: Mon, 18 Sep 2023 18:15:30 -0400
From: John C Klensin <john@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Eliot Lear <lear@lear.ch>, tom petch <daedulus@btconnect.com>, Rahul Gupta <cxres@protonmail.com>, rfc-interest@rfc-editor.org, dispatch@ietf.org
Message-ID: <FB169B84C5D2EF14DF7CCA9E@PSB>
In-Reply-To: <3bed3227-35d2-7eaf-75f5-d0c24d6fb38c@gmail.com>
References: <FC5975A9-E5B2-4853-88D5-1B0A797DE82F@tzi.org> <4cv1A92QvTpimy732OIF2k6A0wFytnq0aCO4VyOOAfzcdhCGIxpdF79iedbG3XJbbhKOO3RZxRmcF2ctcK5jxv7J-apkFJkD6eu6Bcy9fak=@protonmail.com> <VI1PR07MB6704265F4B7264A8D8DB3B94C6F6A@VI1PR07MB6704.eurprd07.pr od.outlook.com> <03b87591-a1a4-c175-9ebb-d144bf2a424a@lear.ch> <3bed3227-35d2-7eaf-75f5-d0c24d6fb38c@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/ABAwuDVjqBO3Hll76taUYZZcoBg>
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 22:15:55 -0000
--On Sunday, September 17, 2023 08:41 +1200 Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > On 17-Sep-23 02:38, Eliot Lear wrote: >> I agree with others; there is no standard way to separate all >> of what is normative v. informative. However, it is >> perfectly fine to be explicit in a draft. A good example of >> how this was done was in DKIM, RFC 6376. Here is a snippet: >> >>> DKIM supports multiple digital signature algorithms. >>> Two algorithms are defined by this specification at this >>> time: rsa-sha1 and rsa- sha256. Signers MUST implement >>> and SHOULD sign using rsa-sha256. Verifiers MUST >>> implement both rsa-sha1 and rsa-sha256. >>> >>> INFORMATIVE NOTE: Although rsa-sha256 is strongly >>> encouraged, some senders might prefer to use rsa-sha1 >>> when balancing security strength against performance, >>> complexity, or other needs. In general, however, >>> rsa-sha256 should always be used whenever possible > > In RFC 8994, the WG decided to label the sections explicitly, > e.g. > > 4. Requirements (Informative) > 5. Overview (Informative) > 6. Self-Creation of an Autonomic Control Plane (ACP) > (Normative) Brian, Unless there is a plan about stepping back from the longstanding principle of allowing considerable flexibility on a per-document basis as long as there is (i) a sensible reason, (ii) the document is internally consistent, and (iii) the document is clear, it seems to me that your comment, Eliot's advice, and other comments including Joel's are roughly consistent even though they might lead to somewhat different results. I think the conclusion when they are taken together is that W3C has different norms, conventions, and vocabulary than the IETF and that, in the general case, automated mapping from one of their documents to one of ours is unlikely to work and may create something that is conceptually different from the original. Some of the differences derive from WC3 being a membership organization while the IETF is a different sort of creature. Two particularly important examples have not even, AFAICT, come up in the discussion: Even though the required text is usually generated as boilerplate rather than spelled out by authors, our IPR rules are largely based on an obligation to disclose while W3C's, at least when last I paid careful attention, involved an obligation to release rights. Similarly, our requirement for a Security Considerations section and what is supposed to be in it, have, AFAICT, no strong W3C parallel. So, my advice to authors wanting to move a document over is that it is necessary to at least minimally understand the IETF's rules and requirements and then rewrite accordingly. That may involve some, perhaps even a lot of, copying and pasting but those operations then will require some hand=editing of the text. best, john
- Re: [dispatch] [rfc-i] Advice when converting W3C… tom petch
- [dispatch] Advice when converting W3C ED to I-D Rahul Gupta
- Re: [dispatch] [rfc-i] Advice when converting W3C… Eric Rescorla
- Re: [dispatch] [rfc-i] Advice when converting W3C… John Levine
- Re: [dispatch] [rfc-i] Advice when converting W3C… tom petch
- Re: [dispatch] [rfc-i] Advice when converting W3C… Carsten Bormann
- Re: [dispatch] [rfc-i] Advice when converting W3C… Carsten Bormann
- Re: [dispatch] [rfc-i] Advice when converting W3C… Rahul Gupta
- Re: [dispatch] [rfc-i] Advice when converting W3C… Joel Halpern
- Re: [dispatch] [rfc-i] Advice when converting W3C… tom petch
- Re: [dispatch] [rfc-i] Advice when converting W3C… Eliot Lear
- Re: [dispatch] [rfc-i] Advice when converting W3C… Brian E Carpenter
- Re: [dispatch] [rfc-i] Advice when converting W3C… Carsten Bormann
- Re: [dispatch] [rfc-i] Advice when converting W3C… John C Klensin
- Re: [dispatch] [rfc-i] Advice when converting W3C… Martin J. Dürst