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

Eliot Lear <lear@lear.ch> Sat, 16 September 2023 14:38 UTC

Return-Path: <lear@lear.ch>
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 3D2E4C15155C; Sat, 16 Sep 2023 07:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.987
X-Spam-Level:
X-Spam-Status: No, score=-0.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.091, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
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 wjUYBpTQC3Vh; Sat, 16 Sep 2023 07:38:22 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [IPv6:2a00:bd80:aa::2]) (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 4CBC7C151557; Sat, 16 Sep 2023 07:38:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1694875092; bh=tpAFvyafurbqdlRL1wCNroYUD+DA3QGhX8jNf1nJhjU=; h=Date:Subject:To:References:From:In-Reply-To:From; b=nZRe83PA3mNsVBpy1FKu1/Ypd6B6gIBlz2OTli2zOlQ6WC8PJ2m27Nt4YSxLECmLo 6I/HWE/4SgyCZn5nwBM5h52iwsYnYPB6t1bLzWDdAa/FHGFQ14cEFTa1yxTQs0Gpin YkgTHATCSlQPSpis+O1cpdCjjoKoycPHwyvhzCAs=
Received: from [IPV6:2001:420:c0c0:1011::5] ([IPv6:2001:420:c0c0:1011:0:0:0:5]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTPSA id 38GEcA5O092584 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 16 Sep 2023 16:38:11 +0200
Content-Type: multipart/alternative; boundary="------------7GY0XiSSTNHAS0ysi40jtalX"
Message-ID: <03b87591-a1a4-c175-9ebb-d144bf2a424a@lear.ch>
Date: Sat, 16 Sep 2023 16:38:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.0
Content-Language: en-US
To: tom petch <daedulus@btconnect.com>, Rahul Gupta <cxres=40protonmail.com@dmarc.ietf.org>, "rfc-interest@rfc-editor.org" <rfc-interest@rfc-editor.org>, "dispatch@ietf.org" <dispatch@ietf.org>
References: <FC5975A9-E5B2-4853-88D5-1B0A797DE82F@tzi.org> <4cv1A92QvTpimy732OIF2k6A0wFytnq0aCO4VyOOAfzcdhCGIxpdF79iedbG3XJbbhKOO3RZxRmcF2ctcK5jxv7J-apkFJkD6eu6Bcy9fak=@protonmail.com> <VI1PR07MB6704265F4B7264A8D8DB3B94C6F6A@VI1PR07MB6704.eurprd07.prod.outlook.com>
From: Eliot Lear <lear@lear.ch>
In-Reply-To: <VI1PR07MB6704265F4B7264A8D8DB3B94C6F6A@VI1PR07MB6704.eurprd07.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/OdUVnYF7wemBzAgLdTNOeVDUBAU>
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: Sat, 16 Sep 2023 14:38:27 -0000

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


Eliot