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

John C Klensin <john-ietf@jck.com> Fri, 04 June 2021 22:22 UTC

Return-Path: <john-ietf@jck.com>
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 E2CD13A2345 for <ietf-smtp@ietfa.amsl.com>; Fri, 4 Jun 2021 15:22:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 4C9vbDRu_6eJ for <ietf-smtp@ietfa.amsl.com>; Fri, 4 Jun 2021 15:22:06 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.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 08B5E3A2344 for <ietf-smtp@ietf.org>; Fri, 4 Jun 2021 15:22:05 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1lpICa-0002ah-I9; Fri, 04 Jun 2021 18:22:04 -0400
Date: Fri, 04 Jun 2021 18:21:58 -0400
From: John C Klensin <john-ietf@jck.com>
To: dcrocker@bbiw.net, ietf-smtp <ietf-smtp@ietf.org>
Message-ID: <F7279E1A825BAAA33F28BA85@PSB>
In-Reply-To: <e9a6ce3e-3f83-a221-d132-fd021a2b5002@dcrocker.net>
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>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/wpBv8eOhrzLYm5HLZzadPQ0v3qc>
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: Fri, 04 Jun 2021 22:22:12 -0000

Dave (and others),

There are old sayings, at least when and where I was growing up,
about hindsight being almost perfect and far easier and more
accurate that looking ahead.  Would the EAI WG have made
different decisions in some cases had there been full
understanding of what we know now, including what and how people
would choose to implement?  I'd like to think so for some cases,
but there is no way that any of can be sure now.  Were these
issues and options, including what forms should appear in
"Received:" fields, considered by the WG?  As Jiankang has
indicated, yes.    Were they considered carefully enough, and
the tradeoffs analyzed adequately, given what we knew then?
Well, it seemed so at the time.

I can tell you a few things that I remember very clearly:

(1) The active participants in the WG included significantly
more people whose interest and expertise was in i18n matters
despite some knowledge of Internet email than people with a
really strong background in Internet email and some background
in the i18n issues.  That made me, as WG co-chair,
uncomfortable.  I assume it made my co-chair Joseph and our
predecessors Harald and Xiaodong uncomfortable too but don't
ever remember discussing it with them.  Could we do anything
about it?  No.  I have often wished that, when a WG was
proposed, we could explicitly identify the expertise and balance
of perspectives needed, write it into the charter, decline to
start the WG is those conditions could not be met and shut it
down immediately if they were never met.  Profoundly unrealistic
and I'd probably also like a pony, but an idea that, if we are
going to talk about informed consensus, has some theoretical
appeal.  

(2) No one in the WG and no one during IETF Last Call raised the
question of whether the choice of U-labels in "Received:" fields
was appropriate.  If what became RFC 6531 were under active
consideration today and that issue were raised with the
conclusions or arguments you and others are reaching now, I
think that appropriate WG response (and certainly the response
from the co-chairs) would have been "even though we would have
preferred it earlier, good catch and that was probably not
discussed sufficient".   But it is not in that state.  Instead,
it is a Proposed Standard published more than eleven years ago
and the issue is coming up only now.  Isn't hindsight great?

(3) By contrast, the idea of using an overlay or special
encoding as you suggest was extensively discussed in the WG
(long before I became co-chair).  That discussion was, for
better or worse, dominated by questions of what to do about the
local part in mailbox names.  While it was obvious how to encode
IDN labels using something like Base64 and later, once the
problems with that were understood, Punycode encoding, it was
critical to that idea that RFC 1034 specified a very restrictive
syntax while allowing almost any octet string of reasonable
length as a label and that we could scan a significant portion
of the DNS to find out what was actually being used.  For
mailbox local parts, we had the related problems of (i) email
addresses being used to convey all sorts of strange information
including system commands and instruction sequences, hashes as
part of addresses, and a wide variety of indicators about what
was going on and (ii) the combination of extremely permissive
syntax rules (dating, you will recall, to before RFCs 822 and
821).   The WG concluded that the only possibilities were to
make a semi-arbitrary choice of encoding indicators and accept
the notion that any existing addresses that were broken in the
process were just causalities of progress and to give up on
encoding.  It also concluded, for reasons entirely consistent
with ones you have made in the past even more forcefully than I
have, that the "some breakage is ok" option was unacceptable.
I don't think we would change that even in hindsight.  

The conclusion was then to specify U-labels in addresses and
even isolated domain names with the one exception of the initial
"220" greeting and the EHLO command, neither of which could use
non-ASCII forms because the extension had not been negotiated
yet.  Should that have been parsed out more carefully on a
case-by-case basis?  Maybe.  Isn't hindsight fun?  And isn't
second-guessing even more so?

(4) One of the consequences of the composition and focus of the
EAI WG is that many of those who actively participated,
including some document authors and probably past co-chairs, are
not represented on this list.   Whatever else we do, I think it
would be unfair and improper for us to make decisions without
reaching out to those people and giving them an opportunity to
be involved.  In particular, it is possible that their view of
some of the tradeoffs might be different from that of most of
the people on this (more email-oriented) list.

Finally, let me say again, more strongly, that discussions here,
perhaps especially those that involve second-guessing or
applying hindsight to decisions made more than a decade ago, are
not getting us anywhere.  Suggestions about whether a sentence
written before 2005 should have said "SHOULD" or "MAY" appear to
be even less useful.  If someone wants to propose a WG to reopen
old questions and revise the SMTPFUT8 specs, by all means go for
it but please try to be sure that the perspectives that were
represented in the EAI WG are represented again.  Or, if someone
wants to propose taking some or all of the SMTPUTF8 specs to
Internet Standard, please do the needed reports and get that
process started: we could certainly reduce a SHOULD to a MAY
and/or add supplemental text as part of that process.

Otherwise, please explain how additional discussions of the
wording of the specs -- perhaps as distinguished from sharing
implementation experience and perspectives -- are helpful.

best,
    john


--On Friday, June 4, 2021 10:12 -0700 Dave Crocker
<dhc@dcrocker.net> wrote:

> 
>> But in the bigger picture, every time you use a U-label or a
>> UTF-8 local-part, you make it more difficult to deal with the
>> case when you hit a point where the SMTPUTF8 extension isn't
>> available.
>> 
>> We have two downgrading options defined, but neither of them
>> is terribly attractive.
>> 
>> What this argues for is to eliminate as much use of the
>> extension as you possibly can. And if that means using
>> A-labels, or even dropping the use of "for" clauses - which
>> are optional anyhow - so be it.
> 
> 
> If I've read this thread correct, the main argument for the
> original SHOULD was convenient display to (end) users.  While
> that's a laudable goal, it's quite different from a typical
> protocol mandate to achieve interoperability.
> 
> Further, it appears that implementers have chosen to widely
> ignore the SHOULD, in favor of A-labels.  Again, this does not
> hurt interoperability, but makes reading by /some/ humans more
> challenging, though not impossible.  Even further, it appears
> that A-labels work well for some other readers.
> 
> My impression is that the SHOULD represented idealism over
> simple pragmatism.
> 
> The basic work was to extend an existing service to support a
> wider range of characters.  With some consistency, that kind
> of task fares much better with an overlay solution.  (Think
> MIME.)  A-labels are an overlay.  U-labels are not.
> 
> If the operational industry has voted with its code and
> clearly prefers A-labels, than the SHOULD is an especially
> counter-productive choice, since it creates debate about the
> specification where, really, it has no benefit.  I suspect MAY
> is the better choice.  It gives permission and even implicit
> encouragement, but eliminates the standards tension caused by
> not using U-labels.
> 
> d/