Re: [Gen-art] Gen-ART LC Review of draft-ietf-eai-5738bis-09
John C Klensin <john-ietf@jck.com> Wed, 19 September 2012 11:54 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C77821F86E1; Wed, 19 Sep 2012 04:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.515
X-Spam-Level:
X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bguZcZSViNC1; Wed, 19 Sep 2012 04:54:05 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id CE1DA21F8690; Wed, 19 Sep 2012 04:54:05 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1TEIqt-000PNm-HA; Wed, 19 Sep 2012 07:53:59 -0400
Date: Wed, 19 Sep 2012 07:53:54 -0400
From: John C Klensin <john-ietf@jck.com>
To: Ben Campbell <ben@nostrum.com>, draft-ietf-eai-5738bis.all@tools.ietf.org
Message-ID: <C5852787C87923CBA226D36A@JcK-HP8200.jck.com>
In-Reply-To: <2549BC7F-FD4D-4D65-817F-98833573D899@nostrum.com>
References: <2549BC7F-FD4D-4D65-817F-98833573D899@nostrum.com>
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
Cc: "gen-art@ietf.org Review Team" <gen-art@ietf.org>, "ietf@ietf.org List" <ietf@ietf.org>
Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-eai-5738bis-09
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Sep 2012 11:54:06 -0000
Following up on my earlier note about a comment from you that really applies to the strategy on which all four documents are really based... --On Tuesday, September 18, 2012 20:44 -0500 Ben Campbell <ben@nostrum.com> wrote: >... > Along the same lines, section 7 seems to go to lengths to > illustrate why downgrading is somewhere between hard and > problematic. Do we really believe that downgrading will ever > be the "least bad"? As compared to what, Ben? One alternative is to not support delivery of SMTPUTF8 messages at all except in environments in which it can be guaranteed that all IMAP and POP clients that might contact the servers are already upgraded. It is operationally possible to make that guarantee in a few scenarios, but they are rare. In those scenarios, many people in the WG would say "do that" (easily managed by not having the delivery servers accept SMTPUTF8 messages until the POP/IMAP client upgrades are complete). But, for all of the more usual cases in which the IMAP/POP server operator cannot control exactly what clients might be used, the only alternate is to not allow such messages, ever. We don't think that is a desirable choice (or we wouldn't have done the work in the WG) but nothing in these protocols require that anyone deploy i18n mail. For the other alternatives, yes, downgrading --by one of these scenarios or some other one-- is, indeed, likely to be "less bad" than others in some operational scenarios. In particular, one alternate is for the server to silently delete all messages requiring SMTPUTF8 (EAI) capability if a client connects that doesn't support the needed capability. If only because the user might later come back with a more capable client (or a message access mechanism that doesn't use a POP or IMAP client at all), that messaging-deleting alternative is almost certainly the worst option of all, making almost anything else "less bad". And, again, yes the WG discussed these issues at length, perhaps even ad nauseam. john
- [Gen-art] Gen-ART LC Review of draft-ietf-eai-573… Ben Campbell
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-eai… John C Klensin
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-eai… Ben Campbell