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

Joel Halpern <jmh@joelhalpern.com> Fri, 15 September 2023 02:15 UTC

Return-Path: <jmh@joelhalpern.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 8E651C151546 for <dispatch@ietfa.amsl.com>; Thu, 14 Sep 2023 19:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.895
X-Spam-Level:
X-Spam-Status: No, score=-2.895 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.091, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 yYDMw4R7KQd1 for <dispatch@ietfa.amsl.com>; Thu, 14 Sep 2023 19:14:56 -0700 (PDT)
Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (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 7B220C151545 for <dispatch@ietf.org>; Thu, 14 Sep 2023 19:14:56 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by mailb1.tigertech.net (Postfix) with ESMTP id 4RmySc1gzkz5bpNM for <dispatch@ietf.org>; Thu, 14 Sep 2023 19:14:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4RmySc0BpKz1pdQD; Thu, 14 Sep 2023 19:14:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1694744096; bh=yrTRzKZfH360cGSbXNbbk2WjcAcd7QjfsV0kp+uUnhc=; h=Date:Subject:To:References:From:In-Reply-To:From; b=rQuE2Y3QDYtRn7kd4SXH3ADVGtK4eTJCadU4CAyIXBI+lYBt6+RAIyCXZ6FRldIZB 1FAntGy1yPFrQN309XTmdwDaWSnAtRNBbMKeP+0Mn+IVHcn4jW63ZdrX8FDMJpVlRD fhEx4+n+9tlgyNaCnc+WTex8ppjlnt60y4bT7tFM=
X-Quarantine-ID: <ZbCX_CiEulyt>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.20.19] (unknown [50.233.136.230]) (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 mailb2.tigertech.net (Postfix) with ESMTPSA id 4RmySb2BYqz1pdPS; Thu, 14 Sep 2023 19:14:54 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------06xhTIbWYROMXsglZoQJ0Gmj"
Message-ID: <8c7a3d53-c150-2b15-d77a-59446c391343@joelhalpern.com>
Date: Thu, 14 Sep 2023 22:14:52 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1
Content-Language: en-US
To: 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>
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <4cv1A92QvTpimy732OIF2k6A0wFytnq0aCO4VyOOAfzcdhCGIxpdF79iedbG3XJbbhKOO3RZxRmcF2ctcK5jxv7J-apkFJkD6eu6Bcy9fak=@protonmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/-ccGbUFMwOeSVtCm7V668Gtdlzo>
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: Fri, 15 Sep 2023 02:15:00 -0000

The advice that commented that the Introduction was always normative was 
misleaading.  There are not normative vs informative sections in RFCs.  
Instead, as others have tried to say, statements are normative if they 
use normative language.  They are informative if they are descriptive or 
informational.  The most common way of making this clear is that 
normative portions include uses of terms from RFC 2119 in upper case.  
(There are exceptions such as RFC 8200 which expect readers to figure 
out what is normative.  Most documents try to be more explicit.)

Yours,

Joel

On 9/14/2023 9:01 PM, Rahul Gupta wrote:
> Thank you Eric, John, Tom, Carsten for your advice:
>
> Some specific comments:
>
>> On 14. Sep 2023, at 13:34, tom petch <daedulus@btconnect.com> wrote:
>>
>> Now my browser and operating system have been upgraded and I no 
>> longer can.
> Is there anything I can do to make the page available? You can also 
> find the markdown source (still fairly readable at) 
> <https://github.com/CxRes/per-resource-events/>. I-D version is still 
> pending, unfortunately.
>
>
> Re Non-normative sections: To counterpose Carsten's point - RFC7322 
> Section 4.8 states:
>
> 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.
>
> If the entirety of numbered sections are to be considered normative, 
> this requirement is contradictory!
>
>
> Re License: Thank you, Eric, John on your advice. I believe that 
> should work!
>
> While not a priority, it is something I shall bring up with IETF Trust 
> at a later date.
>
> BR/Rahul
>
> ------- Original Message -------
> On Thursday, September 14th, 2023 at 11:25 PM, Carsten Bormann 
> <cabo@tzi.org> wrote:
>
>> 
>>
>> Sent from mobile, sorry for terse
>>
>>> On 14. Sep 2023, at 13:34, tom petch <daedulus@btconnect.com> wrote:
>>>
>>> Appendices are Informative unless there is a statement to the contrary
>>
>> Julian is right. Everything that uses normative language is 
>> normative, unless specified otherwise. Position or heading style has 
>> no bearing (of course you can declare it otherwise in each document).
>>
>> The habit of marking crucial parts of a document as non-normative had 
>> irritated me before. Try to use any of these documents without using 
>> the “non-normative” parts. Bizarre.
>
>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest@rfc-editor.org
> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest