Re: [ietf-smtp] Should we update an RFC if people refuse to implement parts of it ?

Dave Crocker <dhc@dcrocker.net> Sat, 05 June 2021 16:21 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC98C3A27DD for <ietf-smtp@ietfa.amsl.com>; Sat, 5 Jun 2021 09:21:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGeHXeQF__bd for <ietf-smtp@ietfa.amsl.com>; Sat, 5 Jun 2021 09:21:17 -0700 (PDT)
Received: from beige.elm.relay.mailchannels.net (beige.elm.relay.mailchannels.net [23.83.212.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980D23A27DE for <ietf-smtp@ietf.org>; Sat, 5 Jun 2021 09:21:17 -0700 (PDT)
X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 0A01B1E21A9; Sat, 5 Jun 2021 16:21:16 +0000 (UTC)
Received: from nl-srv-smtpout4.hostinger.io (100-101-162-58.trex.outbound.svc.cluster.local [100.101.162.58]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 193B61E24F5; Sat, 5 Jun 2021 16:21:13 +0000 (UTC)
X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net
Received: from nl-srv-smtpout4.hostinger.io ([UNAVAILABLE]. [145.14.159.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.101.162.58 (trex/6.3.1); Sat, 05 Jun 2021 16:21:15 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net
X-MailChannels-Auth-Id: hostingeremail
X-Desert-Cellar: 15514f416159bde8_1622910075795_3452054752
X-MC-Loop-Signature: 1622910075795:3236295732
X-MC-Ingress-Time: 1622910075795
Received: from [192.168.0.106] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout4.hostinger.io (smtp.hostinger.com) with ESMTPSA id ED5D831A0C8D; Sat, 5 Jun 2021 16:21:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1622910072; bh=56AI9Re6Hpqq/Aisni5p8ZykDu26VOJ/u/u1GPawbQU=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=UTFcPiHSDy/Dccwed4L6xDxaHbne0JhL5rUZ0hGCGlY+2PVPiufRgPCKFmdAX1+Ud UiEfeMzregoTz/chVCGQRPBVXNd94vydzkP+qeaXXy+4iJSvEcOngs1NYZGTGD+k0Y dJkM1HSQfhSupIG6yww6Map+4ZZ+JM15MZTm79+2YTT9aSuMKA8uzggsJ1E6xNvlkV fdQw95MXuhZdlyUzDv7gFcnoSnya/rZAcKJl5rrv2eOKezPmVsNm+Clr6eGlq0mdQx kfGJT2J/h0EHiAc/Pc/MuRFEO1GgJ+y3LdXJvJuR6ghYTsjE6HaPaUKpbSGEtMsgqn FuFnY6j/cHBPg==
Reply-To: dcrocker@bbiw.net
To: John C Klensin <john-ietf@jck.com>, ietf-smtp <ietf-smtp@ietf.org>
References: <20210525182946.079748B872C@ary.qy> <EFDA46E00EFF0E48802D046A@PSB> <2021052700585304660213@cnnic.cn> <YK7E1dBKneP8B8Ib@straasha.imrryr.org> <01RZNI90M6SS0085YQ@mauve.mrochek.com> <E23639ADA7487360C9B5A93C@PSB> <01RZPUQVP8TU0085YQ@mauve.mrochek.com> <e9a6ce3e-3f83-a221-d132-fd021a2b5002@dcrocker.net> <F7279E1A825BAAA33F28BA85@PSB> <a8e45f33-3678-0a30-cca2-7f12c609e232@dcrocker.net> <C744AD1CDF9E8214916463BB@PSB>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <61d523d4-7941-a506-639e-b2fb558e1bd4@dcrocker.net>
Date: Sat, 5 Jun 2021 09:21:08 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <C744AD1CDF9E8214916463BB@PSB>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/woPqI_q2RwATAYrnqdPiS7l5EjM>
Subject: Re: [ietf-smtp] Should we update an RFC if people refuse to implement parts of it ?
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Jun 2021 16:21:23 -0000

On 6/5/2021 12:21 AM, John C Klensin wrote:
> --On Friday, June 4, 2021 16:14 -0700 Dave Crocker
> <dhc@dcrocker.net> wrote:
>> You appear to be asking how it would be helpful to have the
>> specification reflect extensive field experience.  But maybe
>> not?
> 
> No.  I am asking a much more pragmatic question or pair of
> questions: (i) whether making a change in this area (see below)
> is worth, at this particular point, opening up RFC 6531 and/or
> 6532 (and reviewing whether other documents in the SMTPUTF8
> collection to see if they need similar adjustments) would be
> worth the trouble and (ii) whether there is the energy to do
> that and to do it well.

Oh?  On re-reading your previous two postings, I'm still not finding 
those questions.

At any rate, it appears that you are suggesting expanding the proposed, 
very simple, very narrow, very pragmatic and entirely experience-based 
proposal into a larger and more generic activity.

While the latter might be worth considering, there is nothing about the 
current issue that requires coupling it to the larger task.


> I think it is particularly important to ask the second question
> because the apparently  underwhelming speed at which EMAILCORE
> is converging on 5321bis and 5322bis does not support the
> hypothesis that there is a lot of energy to do work like this
> and because there are i18n issues associated with what the right
> solutions might be and there appears to be even less energy in
> the IETF for that kind of work.

Seems like a good reason for a) decoupling the larger task from the 
immediate, narrower one, and b) deferring the larger task until more 
immediate concerns are addressed.


> And, finally, while I am personally convinced, at least at this
> moment, that changes to the relevant text would be appropriate
> if we had the collective time and energy, it is much less clear
> to me that swapping MAY for SHOULD is the correct change to
> make.  If, in the long term and when SMTPUTF8 is ubiquitous,
> U-labels were really the better answer for this case, then the
> test ought to explain why that is the right target even while
> explaining why A-labels may be appropriate during the transition
> period (however long that lasts). 

Your 'if' is problematic.  You are invoking a desirable but indefinite 
-- and, based on history, a discouraging -- future state as a reason to 
refrain from making a simple, practical change, responding to 
established reality.



  Simply saying "everyone who
> has spoken up about implementations is using A-labels" is
> actually not a sufficient reason to change the spec.

Oh? Really?  Why is that?


>  And I
> again note that the people who were represented in the WG with
> the strongest perceived need for non-ASCII email addresses do
> not appear to be represented on this list. 

The IETF has established practice of making decisions based on those who 
show up.  It's not as if this is a hidden activity.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net