Re: [ietf-smtp] Should we update an RFC if people refuse to implement parts of it ?
John C Klensin <john-ietf@jck.com> Tue, 25 May 2021 20:07 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 A7D113A1D21; Tue, 25 May 2021 13:07:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Pu1fFUBdTdtd; Tue, 25 May 2021 13:06:59 -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 E751D3A1D20; Tue, 25 May 2021 13:06:58 -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 1lldKK-00015H-GD; Tue, 25 May 2021 16:06:56 -0400
Date: Tue, 25 May 2021 16:06:49 -0400
From: John C Klensin <john-ietf@jck.com>
To: Viktor Dukhovni <ietf-dane@dukhovni.org>
cc: ietf-smtp@ietf.org, YAO Jiankang <yaojk@cnnic.cn>, art-ads@ietf.org
Message-ID: <DC10732A3EA64E1140BDE349@PSB>
In-Reply-To: <YK1Q5Nrn58iPfhbW@straasha.imrryr.org>
References: <dde03886-a735-b52e-5cc2-3f9df96ef7a6@iecc.com> <YK1Q5Nrn58iPfhbW@straasha.imrryr.org>
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/RJ4viu-toH85_aW_2tSxh2_ENxg>
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: Tue, 25 May 2021 20:07:04 -0000
Victor, John, and probably others, (explicitly adding Jiankang and the ART ADs in case they not been following this list closely.) In addition to believing the text is probably right as it now appears, I should be explicit about why I'm pushing back on doing anything about this other that reassuming implementers who use A-labels that no one is likely to call the Protocol Police. The other reasons, and the more important ones, are completely pragmatic. First, given the heavy dependencies of the SMTPUTF8 documents on RFCs 5321 and 5322 and that the latter are being revised, I think it would not be helpful to revises the SMTPUTF8 documents until after we have finished with the revisions of the base documents. As I assume others have noticed, those revisions are not proceeding quickly... and, wherever the fault lies, is it not with Pete or myself. Second, even if there is sufficient energy to do serious work on email (and the rate of progress in EMAILCORE could be interpreted as evidence to the contrary), there is ample evidence (painful to me personally) that there is little or none of the combined knowledge, expertise, and energy to do serious i18n work. Revision of these specs requires knowledge and interest in both (and, for this particular case, specific knowledge and experience with some of the subtle tradeoffs in IDNA2008). And finally, unless I have misread the signals from the ADs, we are not likely to see many (if any at all) no-WG, AD-sponsored standards track documents about which there is any controversy. In the case, the controversies are already clear from this fairly short thread. So, unless someone is really to propose a WG and make a serious suggestion about where the energy is going to come from --especially when EMAILCORE is still going on-- well... I would add to this disclaimer that my hope and expectation when the EAI WG wound down was that fully conforming implementations would deploy rapidly and extensively enough that, by the time we got around to revising 5321 and 5322, we could just fold most of those specs in, maybe talking about "minimal" and "recommended" (i.e., fully internationalized) implementations. Silly me. best, john --On Tuesday, May 25, 2021 15:32 -0400 Viktor Dukhovni <ietf-dane@dukhovni.org> wrote: > On Mon, May 24, 2021 at 07:05:53PM -0400, John R. Levine wrote: > >> I've been doing some EAI tests. RFC 6531 section 3.7.3 says >> that domain names in trace headers SHOULD all be U-labels. >> In practice, everyone uses A-labels for reasons that are not >> absurd. The FROM clause has the name from the EHLO command >> which has to be sent as A-labels, and it's quite plausible >> to have a message where the message itself is entirely ASCII, >> sent to a UTF-8 address, which then could be forwarded to an >> ASCII address except that it has those U-labels in the trace >> header which would have to be downgraded. I've talked to a >> couple of MTA maintainers who have told me forget it, that's >> silly, not doing that. > > Disclaimer: I'm one of the MTA maintainers who found the RFC > advice in question to be unworthy of implementation. > >> In a situation like this, would it make sense in a future >> update to the RFC to adjust the advice to the reality? > > Without daring to generalise to broader questions of > whether/when the spec or the implementations have the final > say, on the particulars of this specific case I think it is > easy to conclude that it best to amend the specification. > > * The specification in question prescribes the format of > some fields of trace headers that most users will not > see. > > * The specifications causes the format used in the trace > header to differ from the actual data exchanged on the > wire. These are the client-to-server EHLO name and the > server-to-client greeting name, also repeated in the > first line of the EHLO response. > > Because both are exchanged prior to negotiation of > SMTPUTF8, they always in A-label form. > > * The trace headers should match data recorded in system > logs and are mostly for the benefit of the postmaster. > There's more value in making them readable to any/all > the postmasters along the delivery path, than to those > versed in the native tongue of the message sender and > ultimate recipients. > > * It is possible that the message headers are all ASCII, > and the only presence of UTF8 is in the envelope, which > may get rewritted or narrowed in transit. By the time > the message is delivered to some mailboxes, the only > non-ASCII content that might remain could be the trace > headers in question (if they follow the RFC). > > Given that not all IMAP clients, MUAs, ... support EAI, > the conservative thing to do (a la Postel) is to not > needlessly inject UTF8 content into the message headers. > > Therefore, I find the specific RFC text to be misguided, and > not only inessential to interoperability/utility, but actually > working against both. I am therefore inclined to ignore this > part of the RFC with prejudice. If there's an opportunity to > revise (remove) the text, that'd be great.
- [ietf-smtp] Should we update an RFC if people ref… John R. Levine
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… Viktor Dukhovni
- Re: [ietf-smtp] Should we update an RFC if people… John Levine
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… John Levine
- Re: [ietf-smtp] Should we update an RFC if people… Jiankang Yao
- Re: [ietf-smtp] Should we update an RFC if people… Viktor Dukhovni
- Re: [ietf-smtp] Should we update an RFC if people… Ned Freed
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… Ned Freed
- Re: [ietf-smtp] Should we update an RFC if people… Alessandro Vesely
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… Dave Crocker
- Re: [ietf-smtp] Should we update an RFC if people… Sam Varshavchik
- Re: [ietf-smtp] Should we update an RFC if people… Dave Crocker
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… Dave Crocker
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… Dave Crocker
- Re: [ietf-smtp] Should we update an RFC if people… John Levine
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… Alessandro Vesely
- Re: [ietf-smtp] Should we update an RFC if people… Dave Crocker
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… John Levine
- Re: [ietf-smtp] Should we update an RFC if people… Valdis Kl ē tnieks
- Re: [ietf-smtp] Should we update an RFC if people… Viktor Dukhovni