Re: [rfc-i] RECOMMENDS

[Brian E Carpenter <[e-mail]>]

On 01-Jan-24 08:46, tjw ietf wrote:
> 
> I agree with Scott on it being a speaker change.

True, and there's no difficulty for a fluent English speaker to deal with it. I'm not certain that this applies to people who are less fluent in English.

However, it's undefined in the one place that we actually (re)define common English words. And for those who care, it is not tagged in XML2RFC in the way that the other normative keywords are tagged, so any processing that depends on that tag will miss it.

(Rather cleverly, kramdown generates <strong>RECOMMENDS</strong> rather than <strong><bcp14>RECOMMENDS</bcp14></strong> .)

    Brian

> 
> Tim
> 
> Sent from my iPhone
> 
> On Dec 31, 2023, at 14:43, Scott Bradner <[e-mail]> wrote:
> 
> well, the 2119 includes RECOMMENDED
> 
> there are a LOT more RFCs that include RECOMMENDS - starting with 1755 (referring to RFC 1577)
> (93 lines in the RFCs include RECOMMENDS)
> 
> seems to me that RECOMMENDS is just a speaker change to RECOMMENDED and should not be considered an issue
> 
> 
> Scott
> 
> 
>> On Dec 31, 2023, at 2:24 PM, Brian E Carpenter <[e-mail]> wrote:
>>
>> Hi,
>>
>> To start off 2024 with a question, should we do anything about the mystery normative keyword "RECOMMENDS"?
>>
>> Even with the small subset of RFCs that I keep on disk, grep "RECOMMENDS" rfc* produces this:
>>
>> rfc3280.txt:   of attribute types defined below.  This specification RECOMMENDS
>> rfc3280.txt:   over time.  This profile RECOMMENDS that names not be reused for
>> rfc3280.txt:   RECOMMENDS use of one of these methods for generating keyIdentifiers.
>> rfc3280.txt:   This profile RECOMMENDS support for the key identifier method by all
>> rfc3280.txt:   specification RECOMMENDS use of one of these methods for generating
>> rfc3280.txt:   To promote interoperability, this profile RECOMMENDS that policy
>> rfc3280.txt:   RECOMMENDS support for this extension by CAs and applications.
>> rfc3280.txt:   RECOMMENDS that implementations recognize this extension.
>> rfc5681.txt:   document RECOMMENDS increasing the congestion window based on the
>> rfc8064.txt:   this document RECOMMENDS that nodes do not generate stable IIDs with
>> rfc8325.txt:   This document assumes and RECOMMENDS that all wireless APs (as the
>> rfc8325.txt:   This document further assumes and RECOMMENDS that all wireless
>> rfc8995.html:  therefore RECOMMENDS that no key usage restrictions be included.
>>
>> As I'm sure we all know, this keyword is not defined in RFC 2119 or RFC 8174, but it is present in RFCs spanning at least 2002 through 2021. (A subtlety is that in RFC 8995, it is not in bold-face in the HTML version.)
>>
>> Should we fix this with an erratum? (That has implications for XML2RFC, so it isn't quite a no-brainer.)
>>
>> Regards
>>   Brian Carpenter
>>
>> _______________________________________________
>> rfc-interest mailing list
>> [e-mail]
>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
> 
> _______________________________________________
> rfc-interest mailing list
> [e-mail]
> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest