From arnt@gulbrandsen.priv.no Thu Feb 2 05:44:26 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F03721F8859 for ; Thu, 2 Feb 2012 05:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.159 X-Spam-Level: X-Spam-Status: No, score=-1.159 tagged_above=-999 required=5 tests=[AWL=-0.974, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGiJx1LCWjdL for ; Thu, 2 Feb 2012 05:44:25 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5F12C21F882F for ; Thu, 2 Feb 2012 05:44:25 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3D251F8C20E; Thu, 2 Feb 2012 13:44:22 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1328190261-30173-30172/11/1; Thu, 2 Feb 2012 13:44:21 +0000 Message-Id: <4F268A40.1090408@gulbrandsen.priv.no> Date: Mon, 30 Jan 2012 13:17:04 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 Mime-Version: 1.0 To: ima@ietf.org References: <906D2BFAC8B2DEEDFAF06D2D@PST.JCK.COM> <01OBFSKUNLTE00ZUIL@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [EAI] Unhappy with the complexity of pop-imap-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 13:44:26 -0000 TL;DR: Change downgrading to support what's most important to the end=20 user, and drop the rest. Lessen the amount of code provided to implement=20 downgrade to the minimum possible. Rationale: While I find the downgrading document is well written, the=20 downgrade itself is IMO much too complex to be worthwhile. There's too=20 much to implement, too many cases to test, etc. It defines new header fields that are intended to be parsable by new=20 code and even encourages parsing them. That's not good. We want people=20 to spend their time and energy implementing EAI natively, not writing=20 clientside parsers for Downgraded-Header-Field-X. Details: Below I give section numbers and suggested action. Section 4 (about new parsable header fields, Downgraded-This-That): New text: "Server MAY generate Downgraded- fields. Clients MUST NOT rely=20 on such fields or try to parse such fields." Section 5 (about downgrading various syntax elements): 5.1.1: If any Received field cannot be sent to non-EAI POP or IMAP=20 clients, then all Received fields are silently suppressed. 5.1.4: Any comments that require EAI are silently excised when the=20 header field is sent to an non-EAI client. As an aside, I really, really hate this: Date: 14 aug 2011 12:00:00 +0200 (Mitteleurop=C3=A4ische Zeit) 5.1.5: Any MIME values that require EAI MAY be silently excised, or MAY=20 be converted to use RFC2231 syntax. 5.1.8: I like the algorithm, but I would prefer that the exact address=20 be explicitly undefined, so noone is tempted to detect EAI by looking at=20 a magic group name. Btw. For reasons I cannot at the moment remember, I generate "=C3=A6@=C3=A6.no" instead of an empty group. I'm sure I had a reason, though. 5.1.9: Seems to overlap with 4. I think 5.1.9 is a better location than=20 5 for this. 5.2.x: I would change most of these to be examples showing the effect of=20 the relevant 5.1.x rule. 6 (about MIME bodypart fields): Replace with "If any MIME values (e.g. a=20 file name in content-disposition) require EAI, these values are silently=20 excised before showing the header field to the client. If any other part=20 of a bodypart fields requires EAI, the entire field is silently excised." 7. Strike about half, particularly the bit about parsing downgrade-*.=20 Add a sentence such as "Sending EAI to non-EAI aware recipients offers=20 new opportunities for misunderstandings, spoofing and deception, if the=20 recipient is unable to read or understand a part of the message's = meaning". I apologise for suggesting such large changes so late. Arnt From johnl@iecc.com Thu Feb 2 07:59:34 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61ABE21F85D6 for ; Thu, 2 Feb 2012 07:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.402 X-Spam-Level: X-Spam-Status: No, score=-109.402 tagged_above=-999 required=5 tests=[AWL=1.797, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpGeYUTZE5wD for ; Thu, 2 Feb 2012 07:59:33 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 6655D21F85D3 for ; Thu, 2 Feb 2012 07:59:33 -0800 (PST) Received: (qmail 68126 invoked from network); 2 Feb 2012 15:59:29 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Feb 2012 15:59:29 -0000 Date: 2 Feb 2012 15:59:07 -0000 Message-ID: <20120202155907.68354.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <4F268A40.1090408@gulbrandsen.priv.no> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: arnt@gulbrandsen.priv.no Subject: Re: [EAI] Unhappy with the complexity of pop-imap-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 15:59:34 -0000 In article <4F268A40.1090408@gulbrandsen.priv.no> you write: >TL;DR: Change downgrading to support what's most important to the end >user, and drop the rest. Lessen the amount of code provided to implement >downgrade to the minimum possible. I have to agree. The current document is basically a detailed design to tunnel EAI messages through hostile MUAs that is so complex that it seems unlikely to me that two implementations would ever match in practice. If that's what you want to do, you can always wrap the messages as message/global attachments. Arnt's suggested changes seem right, chop it down to the minimum needed to produce a version of a message that won't break MUAs. R's, John From klensin@jck.com Thu Feb 2 08:19:41 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0370321F8581 for ; Thu, 2 Feb 2012 08:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNiRdGqNHdvn for ; Thu, 2 Feb 2012 08:19:40 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCFF21F855B for ; Thu, 2 Feb 2012 08:19:40 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RszKI-000BJP-9d; Thu, 02 Feb 2012 11:15:58 -0500 Date: Thu, 02 Feb 2012 11:19:31 -0500 From: John C Klensin To: John Levine , ima@ietf.org Message-ID: <4E827E8757009681283FD43E@PST.JCK.COM> In-Reply-To: <20120202155907.68354.qmail@joyce.lan> References: <20120202155907.68354.qmail@joyce.lan> 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: arnt@gulbrandsen.priv.no Subject: Re: [EAI] Unhappy with the complexity of pop-imap-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 16:19:41 -0000 --On Thursday, February 02, 2012 15:59 +0000 John Levine wrote: > In article <4F268A40.1090408@gulbrandsen.priv.no> you write: >> TL;DR: Change downgrading to support what's most important to >> the end user, and drop the rest. Lessen the amount of code >> provided to implement downgrade to the minimum possible. > > I have to agree. The current document is basically a detailed > design to tunnel EAI messages through hostile MUAs that is so > complex that it seems unlikely to me that two implementations > would ever match in practice. If that's what you want to do, > you can always wrap the messages as message/global attachments. > > Arnt's suggested changes seem right, chop it down to the > minimum needed to produce a version of a message that won't > break MUAs. For the moment, let me note that there are other options and that circumstances may differ in different environments. Just to help with the discussion (this isn't a proposal yet, much less one that I'm ready to advocate), note that this entire downgrading model is something that happens between the delivery MTA, the mail store, and the MUA. We make strong assumptions here and elsewhere about that being a relatively tight, mutual-consent, relationship. That is not traditionally IETF territory. More important, the nature of interoperability issues are quite different from having multiple, independent, systems at different edges of the Internet. Noting that I will continue to leave consensus decisions up to Joseph, I also note that two voices (or even a few more) don't change the presumed WG consensus to move forward with the current spec as is. The fact that we've gone a few years without any discussion along this line certainly entitles the existing document to the presumption that it is the way the WG wants to go. I wonder if it would be possible to define a family of self-consistent downgrade options, such that we could preserve the current model for those environments that needed it and were willing to go to the trouble of implementing (or finding implementations) and deploying it, a second option along the lines the Arnt and John L are outlining, and possibly a third or fourth option. For example, it occurs to me that, for some environments, the right response to a retrieval request from a legacy IMAP or POP client for a message that requires SMTPUTF8 capability might be to leave the message in the mail store and deliver a synthesized cousin of an DSN to the client that identifies the message and suggests finding an upgraded client. Going that route would take some work, but perhaps not much more work than constructing the stripped-down version of Downgrade. Possibly most of the hard parts are done already. Is that worth thinking about as a group? john From arnt@gulbrandsen.priv.no Thu Feb 2 08:36:55 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4768521F8615 for ; Thu, 2 Feb 2012 08:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsgmFIRvPlS8 for ; Thu, 2 Feb 2012 08:36:54 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id B6D6521F8613 for ; Thu, 2 Feb 2012 08:36:54 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 42C87F8C1AD; Thu, 2 Feb 2012 16:36:53 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1328200612-30173-30172/11/2; Thu, 2 Feb 2012 16:36:52 +0000 User-Agent: Kaiten Mail for Android In-Reply-To: <4E827E8757009681283FD43E@PST.JCK.COM> References: <20120202155907.68354.qmail@joyce.lan> <4E827E8757009681283FD43E@PST.JCK.COM> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=----L2BFZRA2WPN177LGPFNWPY7GT0OB42 From: Arnt Gulbrandsen Date: Thu, 2 Feb 2012 17:36:45 +0100 To: John C Klensin , John Levine , ima@ietf.org Message-Id: <197be1bb-3551-41a9-bfec-044bd0165bc2@email.android.com> Subject: Re: [EAI] Unhappy with the complexity of pop-imap-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 16:36:55 -0000 ------L2BFZRA2WPN177LGPFNWPY7GT0OB42 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To be honest I think it's not. This isn't the common path. Sending mail to people who cannot really = read it is an exceptional activity, not the kind of thing that warrants = very much server code or several different protocol variants. Arnt ------L2BFZRA2WPN177LGPFNWPY7GT0OB42 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable To be honest I think it's not.

This isn't the common path. Sending mail to people who cannot really = read it is an exceptional activity, not the kind of thing that warrants = very much server code or several different protocol variants.

Arnt ------L2BFZRA2WPN177LGPFNWPY7GT0OB42-- From johnl@taugh.com Sun Feb 5 17:42:39 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C04E21F8497 for ; Sun, 5 Feb 2012 17:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXZGfQO8C2Az for ; Sun, 5 Feb 2012 17:42:38 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4492A21F845F for ; Sun, 5 Feb 2012 17:42:38 -0800 (PST) Received: (qmail 72961 invoked from network); 6 Feb 2012 01:42:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=11cfe.4f2f3009.k1202; bh=l3DBURJ3br/qhaCEMg3nY++VhKrD4oYemzUSXUbTTy8=; b=QUxXbNet0vbCOvhuudHmYctHrraQRT0aYGCc/PQAruFKxcNXgj8EkCCttz7VTTUsOPRHsbM9gdbyf9rdPCfM1QO715QUbSNN3AdlTDN0559vOMeCYujAKc2n8GTazDHFWZotBUbUHmWoc9mBYPuTd7LgvYhtSM9aBXAUQeUtXlU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=11cfe.4f2f3009.k1202; bh=l3DBURJ3br/qhaCEMg3nY++VhKrD4oYemzUSXUbTTy8=; b=s6zzR7hhp2TldKe4IxgasM12ttnU/WDydpTcwbs+wn8hDSM5H9MnrR5VKE95VZOpywz43SBuZAPlJ1q1SOyG4zo3kmMDpU9jyJVJgQP132WKwcLTFq4Lexd+2s4BlstVbzFTWXczS+SJsSpNT/T6kPkm9cXLb7r61+Ut3nrje0Q= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Feb 2012 01:42:11 -0000 Date: 5 Feb 2012 20:42:32 -0500 Message-ID: From: "John R Levine" To: "John C Klensin" In-Reply-To: <4E827E8757009681283FD43E@PST.JCK.COM> References: <20120202155907.68354.qmail@joyce.lan> <4E827E8757009681283FD43E@PST.JCK.COM> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: ima@ietf.org Subject: Re: [EAI] Unhappy with the complexity of pop-imap-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 01:42:39 -0000 > The fact that we've gone a few years without any discussion along this > line certainly entitles the existing document to the presumption that it > is the way the WG wants to go. You're right, although it might also mean that nobody's been paying attention recently. It feels to me like a vestige of the downgrade on demand model that EAI rejected for mail transport. > I wonder if it would be possible to define a family of > self-consistent downgrade options, such that we could preserve > the current model for those environments that needed it Possibly. In order of distance from the current text, I'd suggest: 1. Since downgrades aren't reversible, there isn't really an interop reason to specify the details. Say that for headers that contain UTF8 text, do some combination of MIME encoding where possible (most headers), redacting parts of them (address headers), and throwing them away (trace headers). 2. To deliver an EAI message to a non-EAI MUA, wrap it as a message/global, copy whatever headers you can into the wrapper message, and it's the MUA's problem. 3. John's suggestion, synhesize a DSN that says you need a better MUA and deliver that to the user. 4. For the rest of EAI, we made the decision that the EAI and legacy mail streams are parallel but separate, if you want to send an EAI message and there isn't an EAI path to the recipient, you lose. Why should this be any different? If the user doesn't have an EAI MUA, he can't pick up mail from an EAI POP or IMAP server. My inclination leans toward #2, since MUAs that don't support EAI can often nonetheless display UTF-8 text. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From arnt@gulbrandsen.priv.no Mon Feb 6 03:18:02 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC6521F8604 for ; Mon, 6 Feb 2012 03:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWHK3PLslizM for ; Mon, 6 Feb 2012 03:18:02 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0934021F8602 for ; Mon, 6 Feb 2012 03:18:02 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4A6F5F8C382; Mon, 6 Feb 2012 11:17:59 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1328527078-27816-27816/11/2; Mon, 6 Feb 2012 11:17:58 +0000 User-Agent: Kaiten Mail for Android In-Reply-To: References: <20120202155907.68354.qmail@joyce.lan> <4E827E8757009681283FD43E@PST.JCK.COM> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=----92LIYRI7MIN823RUXZUFCQ7BSCJAOZ From: Arnt Gulbrandsen Date: Mon, 6 Feb 2012 12:17:45 +0100 To: John R Levine , John C Klensin Message-Id: Cc: ima@ietf.org Subject: Re: [EAI] Unhappy with the complexity of pop-imap-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 11:18:02 -0000 ------92LIYRI7MIN823RUXZUFCQ7BSCJAOZ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Fwiw, the reason for me to implement a kind of downgrade is that EAI = mail may appear in folders whet you don't expect it, such as the one in = which you store this mailing list. It would be rather irritating if, say, your EAI-ignorant smartphone = could not read any mail in that folder merely because someone posted a = message to the list using EAI. Downgrade needs to be good enough to let = you read the rest of your mail and have some idea of what's in the mail = you cannot properly read. Locking your phone out of the entire folder = would not be good. Arnt ------92LIYRI7MIN823RUXZUFCQ7BSCJAOZ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Fwiw, the reason for me to implement a kind of downgrade is that EAI = mail may appear in folders whet you don't expect it, such as the one = in which you store this mailing list.

It would be rather irritating if, say, your EAI-ignorant smartphone = could not read any mail in that folder merely because someone posted a = message to the list using EAI. Downgrade needs to be good enough to let = you read the rest of your mail and have some idea of what's in the = mail you cannot properly read. Locking your phone out of the entire = folder would not be good.

Arnt ------92LIYRI7MIN823RUXZUFCQ7BSCJAOZ-- From fujiwara@jprs.co.jp Mon Feb 6 03:19:23 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2623521F862B for ; Mon, 6 Feb 2012 03:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jX7DUC0pLVlK for ; Mon, 6 Feb 2012 03:19:22 -0800 (PST) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5E221F8629 for ; Mon, 6 Feb 2012 03:19:22 -0800 (PST) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q16BJLoD008935; Mon, 6 Feb 2012 20:19:21 +0900 X-AuditID: ac120820-b7f2a6d0000076cf-18-4f2fb739c472 Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id BB.DD.30415.937BF2F4; Mon, 6 Feb 2012 20:19:21 +0900 (JST) Date: Mon, 06 Feb 2012 20:19:20 +0900 (JST) Message-Id: <20120206.201920.250832792.fujiwara@jprs.co.jp> To: johnl@taugh.com From: fujiwara@jprs.co.jp In-Reply-To: References: <20120202155907.68354.qmail@joyce.lan> <4E827E8757009681283FD43E@PST.JCK.COM> X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLIsWRmVeSWpSXmKPExsWyRoiFT9dyu76/Qe9nZovrS9exW5zuWcNk 0X6lgd2B2WPJkp9MHpdXvmb2uLclNIA5issmJTUnsyy1SN8ugSvj3rIPLAU/eComfrzP2sC4 jquLkYNDQsBE4tblsi5GTiBTTOLCvfVsXYxcHEICJxklbs36xA6SYBHQlvh9dyGYzStgLbG9 ZQsriC0iICyxdfY8sDizgKJE+9MlTCC2sICLROu+jYwgNpuApMTmz63MIDYnUO+DH19ZIBb0 MEpcmHmbDWKzncSJ5ytYQQ7iFRCU+LtDGGKmlkTPjMdQ8+Ultr+dwzyBkX8WQtUsJFWzkFQt YGRexSiTn5amW5yal1Kcm25gqFdSma+XVVBUrJcMojcxgkOTQ2EH44xTBocYBTgYlXh4DU30 /YVYE8uKK3MPMUpyMCmJ8q7YChTiS8pPqcxILM6ILyrNSS0+xCjBwawkwqs2CSjHm5JYWZVa lA+TkuZgURLnPX52h5+QQHpiSWp2ampBahFMVoaDQ0mCd+42oEbBotT01Iq0zJwShDQTByfI cB6g4atBaniLCxJzizPTIfKnGCWlxHkngSQEQBIZpXlwva8YxYFeEOZtBMnyANMMXNcroIFM QAP3semCDCxJREhJNTCuFLjG8Gpq9/a/Ed79F4O1i+LjbQMzgnPfHJbjjile5bnf7c5q72Pi W5x4Zh74H3PVLU5GW2K/UMWrPI6HrgfW5RtLMW/yM79Qp3+CYcf9q89unbn4h8nuoGC/v51q 8dk7DkYWik91Jq+Zm3Ds2trWJec530k4fZ0Uwxot2h124tAW2yPrc+WUWIozEg21mIuKEwF6 Na4G8AIAAA== Cc: ima@ietf.org Subject: Re: [EAI] Unhappy with the complexity of pop-imap-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 11:19:23 -0000 The purpose of post-delivery message downgrading is that POP/IMAP servers can send/remove internalionalized messages to traditional POP/IMAP clients and receivers can know they received internationalized messages. No popimap-downgrading, POP/IMAP server could not send EAI messages to traditional clients and POP server cound not remove the messages. > From: "John R Levine" > 1. Since downgrades aren't reversible, there isn't really an interop > reason to specify the details. Say that for headers that contain UTF8 > text, do some combination of MIME encoding where possible (most > headers), redacting parts of them (address headers), and throwing them > away (trace headers). Current draft. Tried not to break current MUAs. (Except allowing empty from:). > 2. To deliver an EAI message to a non-EAI MUA, wrap it as a > message/global, copy whatever headers you can into the wrapper > message, and it's the MUA's problem. Do you think that end user understands what happend? > 3. John's suggestion, synhesize a DSN that says you need a better MUA > and deliver that to the user. > > 4. For the rest of EAI, we made the decision that the EAI and legacy > mail streams are parallel but separate, if you want to send an EAI > message and there isn't an EAI path to the recipient, you lose. Why > should this be any different? If the user doesn't have an EAI MUA, he > can't pick up mail from an EAI POP or IMAP server. Any MUA can access EAI POP servers which offer EAI messages for the MUA. Port number and protocols are the same. -- Kazunori Fujiwara, JPRS From johnl@taugh.com Mon Feb 6 07:15:34 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8409221F86C6 for ; Mon, 6 Feb 2012 07:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10TlvotOPapu for ; Mon, 6 Feb 2012 07:15:28 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 76D6021F86C3 for ; Mon, 6 Feb 2012 07:15:28 -0800 (PST) Received: (qmail 71655 invoked from network); 6 Feb 2012 15:15:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=117e1.4f2fee8f.k1202; bh=m5ayn2VJjib+tGvHChl+xTYu9bs9RS/F5K3qrvqnoTc=; b=C19tpvnaNex4aVE6dEkOTIBsPD1rqwwBWk7ieE75EsSUzcIVpIo54cmP/CFJJzxFuG5i2k6L3YZBHfs6v6LOTVWnZjPIbaDuLaJJ7myCLXV0602MXjqz091vbqM+dFGU1i8I5a/m+GacAu99BWWFUXu5uBAvJIaeeCG4sCuf53I= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=117e1.4f2fee8f.k1202; bh=m5ayn2VJjib+tGvHChl+xTYu9bs9RS/F5K3qrvqnoTc=; b=BN26gURHuWvdFyPvS6XBVI2cjTK8NnfZXY8WuDmUJ41Z3VerBxTq7TToLtDU/kyxfaCSxuotYbxoNkKIHuGGe1jOFwJoUcHidIrvCeBWATvrM1Rv/JfS2Fk4UirRTOzYfPyP/XtxJp8tYVrNNlWQI9tUuVwbS3OgPKdfZPtWKkE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Feb 2012 15:15:05 -0000 Date: 6 Feb 2012 10:15:26 -0500 Message-ID: From: "John R Levine" To: "Arnt Gulbrandsen" In-Reply-To: References: <20120202155907.68354.qmail@joyce.lan> <4E827E8757009681283FD43E@PST.JCK.COM> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] Unhappy with the complexity of pop-imap-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 15:15:34 -0000 > Fwiw, the reason for me to implement a kind of downgrade is that EAI mail may appear in folders whet you don't expect it, such as the one in which you store this mailing list. Understood, but there's simpler ways to do that than to specify a detailed non-reversible downgrade scheme. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From johnl@taugh.com Mon Feb 6 07:37:47 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A161221F855E for ; Mon, 6 Feb 2012 07:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UArOSWBzwmTS for ; Mon, 6 Feb 2012 07:37:36 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7097621F8486 for ; Mon, 6 Feb 2012 07:37:36 -0800 (PST) Received: (qmail 89448 invoked from network); 6 Feb 2012 15:37:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=15d65.4f2ff3be.k1202; bh=JO88tpefQu8oYQxPiPZF1wtqy3lucy/yUCs0Ur0GBf0=; b=I68VwNRINYCI+3lY0oKnGEnRpEhnFjoHVXhclO1E9+OY64zy5GxLqipISNoUkvj0M0JIZteoHM8IccM3XREstlBA9xe28yg2GZajLhwuL3kD5g+3E/cVAnx8WK1VePEWoeW1S9+8vuysRoKqP0xC+1VNTg5IgHdoDAc7SEiAfUA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=15d65.4f2ff3be.k1202; bh=JO88tpefQu8oYQxPiPZF1wtqy3lucy/yUCs0Ur0GBf0=; b=NkI7abqYAI9duCm5ys7Kyby+1JaTOyqNmuJpzHPUjPhSJvZo47RXyBmr+n66BJ3Iz5QDDInFimcOB7YiM6RqxIXrLe7z+SeOzxdgptCqtC+7i2IMT6VG4yVR4bPtv7v3x+j+Z4hSZowsVSNPwFHBLzrNiY7CNHN/uPYwSMN6pAk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Feb 2012 15:37:11 -0000 Date: 6 Feb 2012 10:37:32 -0500 Message-ID: From: "John R Levine" To: fujiwara@jprs.co.jp In-Reply-To: <20120206.201920.250832792.fujiwara@jprs.co.jp> References: <20120202155907.68354.qmail@joyce.lan> <4E827E8757009681283FD43E@PST.JCK.COM> <20120206.201920.250832792.fujiwara@jprs.co.jp> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] Unhappy with the complexity of pop-imap-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 15:37:47 -0000 >> 1. Since downgrades aren't reversible, there isn't really an interop >> reason to specify the details. Say that for headers that contain UTF8 >> text, do some combination of MIME encoding where possible (most >> headers), redacting parts of them (address headers), and throwing them >> away (trace headers). > > Current draft. > Tried not to break current MUAs. (Except allowing empty from:). Agreed, but we could strip out a great deal of the detail and just say here are the three techniques you can use to fix headers, use whichever ones you want. Since the transformations aren't reversible and the user can't reply to a message with an EAI return address, the details don't really matter. >> 2. To deliver an EAI message to a non-EAI MUA, wrap it as a >> message/global, copy whatever headers you can into the wrapper >> message, and it's the MUA's problem. > > Do you think that end user understands what happend? I don't know, but I don't see any reason to think that it's more or less baffling than a message full of Downgraded-this and redacted that headers. The IETF has never been very good at user interface design. >> 4. For the rest of EAI, we made the decision that the EAI and legacy >> mail streams are parallel but separate, if you want to send an EAI >> message and there isn't an EAI path to the recipient, you lose. Why >> should this be any different? If the user doesn't have an EAI MUA, he >> can't pick up mail from an EAI POP or IMAP server. > > Any MUA can access EAI POP servers which offer EAI messages for the MUA. > > Port number and protocols are the same. We could simplify section 3.1 of RFC5721bis and section 4 or RFC5738bis, so that if the client hasn't said UTF8, requests to retrieve EAI messages fail. They currently offer a choice between fail and downgrade, just take out the downgrade choice. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From klensin@jck.com Mon Feb 6 21:40:03 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F41521F852D for ; Mon, 6 Feb 2012 21:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.683 X-Spam-Level: X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xrux5cwdUMCk for ; Mon, 6 Feb 2012 21:40:02 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 48FCC21F852B for ; Mon, 6 Feb 2012 21:40:02 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Rudix-000Kii-3b for ima@ietf.org; Tue, 07 Feb 2012 00:36:15 -0500 Date: Tue, 07 Feb 2012 00:39:56 -0500 From: John C Klensin To: EAI WG Message-ID: <897EFBFD97C27926F15BAB3C@PST.JCK.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 Subject: [EAI] Question about AUTH48 text for 5336bis/ proto-RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 05:40:03 -0000 Hi. We have encountered a small problem at AUTH48 with some text in 5336bis (RFC-to-be 6531). The text in Section 3.2 of draft-ietf-eai-rfc5336bis-16 (just before the numbered list) reads: "Instead, if a UTF8SMTPbis-aware SMTP client "(UTF8SMTPbis-aware SMTP sender) attempts to transfer an internationalized message and encounters an SMTP server that does not support the extension, it MUST make one of the following three choices and the priority order is 1, 2 and 3." The last part of that sentence was added in response to a Last Call comment. If there is a moral here, it is that folks should be really careful with changes in response to even seemingly-editorial comments made during Last Call. In any event, "the priority order is 1, 2 and 3" is ambiguous as to whether the WG thinks choice 1 or choice 3 should come first. But it is a little worse than that because, in trying to fix this, we discovered that the phrasing of those three choices may not have been quite right. In particular, the third case seemed to contradict a very carefully-worded exception case in RFC 5321. To be clear what we are talking about before I outline what I think are the options and ask for a decision, the current AUTH48 working text reads (please don't worry about spacing): ...Instead, if an SMTPUTF8-aware SMTP client (sender) attempts to transfer an internationalized message and encounters an SMTP server that does not support the extension, it MUST make one of the following three choices. These are listed in decreasing order of preference. 1. It MAY either reject the message during the SMTP transaction or accept the message and then generate and transmit a notification of non-deliverability. Such notification MUST be done as specified in RFC 5321 [RFC5321], RFC 3464 [RFC3464], and RFC 6533 [RFC6533]. 2. If and only if the SMTPUTF8-aware SMTP client (sender) is a Message Submission Agent (MSA) [RFC6409] [RFC5598], it MAY choose its own way to deal with this scenario according to the provisions of RFC 6409 [RFC6409] or its future versions. However, the detailed specification of this process and its results are outside the scope of this document. 3. It MAY find an alternate route to the destination that permits SMTPUTF8. That route MAY be discovered by trying alternate Mail eXchanger (MX) hosts (using preference rules as specified in RFC 5321) or using other means available to the SMTPUTF8-aware SMTP client. There was an earlier stage in which the text was the same, but "increasing" was substituted for "decreasing". With an adjustment for what RFC 5321 actually allows, Pete summarized these three cases as: 1. It MAY reject the message. 2. If and only if it's a submission server, it MAY something of its own choosing. 3. It MAY try another MX. If we take RFC 5321 Section 2.2.3 into account, 3 can be expanded to "It MAY try another MX if it decides to do so based on the particular circumstances." It is absolutely clear to us (myself, Joseph, and Pete) that the WG intended to encourage letting submission servers fix up messages if they knew how (case 2 above) and rejecting/bouncing messages back to those servers so that they could fix things (case 1 above). The third case is certainly reasonable as long as it makes clear, somehow, that the circumstances are important. Indeed, although it is a useful clarification that RFC 5321 Section 2.2.3 may apply to this particular extension, it actually adds nothing to what RFC 5321 would permit if this document said nothing at all. So we probably need to fix the text (and to spend as little time as possible making a decision). I think the following are a complete list of options although, if someone has a better idea, he or she should raise it. I hope that the WG can reach consensus by mid-week (please make comments quickly so the WG has a chance to discuss them if needed or, if you need more time, say so). If there is no consensus on choice of text, Joseph, Jiankang, Pete, and I will make a decision. If we have to make a decision, we will consider both preferences for particular approaches and remarks along the line of "do whatever you like as long as you don't pick option 99". Note that I'm not asking whether the WG still believes in correction by submission servers, etc.: those issues are closed unless someone comes up with a _really_ strong argument, presumably strong enough to put all of this back into WG and IETF LC. We are only trying to figure how to most clearly and accurately reflect the WG's existing conclusions in the document. Note that whatever is chosen may still be fine-tuned editorially. These options are deliberately in no particular order: A. Drop case 3 entirely to be consistent with the model of putting nothing in these specs that is really part of the base protocol (RFC 5321 in this case) and then clean up the text. Note that this drops one piece of information that is not in the base protocol, i.e., the WG's belief that SMTPUTF8 is an extension to which Section 2.2.3 might reasonably be applied. ...Instead, if an SMTPUTF8-aware SMTP client (sender) attempts to transfer an internationalized message and encounters an SMTP server that does not support the extension, it SHOULD make one of the following two choices. These are listed in decreasing order of preference. 1. It MAY either reject the message during the SMTP transaction or accept the message and then generate and transmit a notification of non-deliverability. Such notification MUST be done as specified in RFC 5321 [RFC5321], RFC 3464 [RFC3464], and RFC 6533 [RFC6533]. 2. If and only if the SMTPUTF8-aware SMTP client (sender) is a Message Submission Agent (MSA) [RFC6409] [RFC5598], it MAY choose its own way to deal with this scenario according to the provisions of RFC 6409 [RFC6409] or its future versions. However, the detailed specification of this process and its results are outside the scope of this document. Note the change from MUST to SHOULD because there is another choice (the MX searching of RFC 5321 Section 2.2.3) out there. It could just be left alone on the theory that whatever 5321 says overrides whatever is said here. Or we could explain the SHOULD, but that takes us back to three cases and... B. We leave all three cases as above and come up with revised text as needed to clarify both the order and fact that case 3 isn't to be used unless the client has the information (presumably out of band) that permits it to conform to the key requirement in RFC 5321 Section 2.2.3. That requirement (second paragraph of 2.2.3) starts: In particular, if an extension implies that the delivery path normally supports special features of that extension, and an intermediate SMTP system finds a next hop that does not support the required extension, it MAY choose, based on the specific extension and circumstances, to requeue the message and try later and/or try an alternate MX host. Note that 2.2.3 goes on to impose additional requirements on timeouts in that case. C. We conclude that the "preference" order doesn't actually mean much in this case. From that point of view, option 2 applies only if the client is a submission server, option 3 applies only if the client has special additional information or circumstances (information or circumstances that presumably could override either of the other preference), and option 1 applies otherwise. If we then turn the wording around a bit, we would get something like (borrowing text from the above where possibe)... ...Instead, if an SMTPUTF8-aware SMTP client (sender) attempts to transfer an internationalized message and encounters an SMTP server that does not support the extension, the best action for it to take depends on other conditions. In particular: o If it is a Message Submission Agent (MSA) [RFC6409] [RFC5598], it MAY choose its own way to deal with this scenario using the wide discretion for changing addresses or otherwise fixing up and transforming messages allowed by RFC 6409. As long as the resulting message conforms to the requirements of RFC 5321 (i.e., without the SMTPUTF8 extension), the details of that transformation are outside the scope of this document. o Otherwise, it SHOULD reject the message. As usual, this can be done either by generating an appropriate reply during the SMTP transaction or by accepting the message and then generating and transmit a non-delivery notification. If the latter choice is made, the notification process MUST conform to the requirements of RFC 5321 [RFC5321], RFC 3464 [RFC3464], and RFC 6533 [RFC6533]. o As specified in RFC 5321 Section 2.2.3, an SMTP client with additional information and/or knowledge of special circumstances MAY choose to requeue the message and try later and/or try an alternate MX host as specified in that section. D. Just about the same thing could be done, in somewhat more terse form, by saying something like: "If the client is a submission agent [RFC6409], it SHOULD, if possible, fix the message to be consistent with SMTP requirements (in the absence of this extension) and resend the transformed message. If it cannot or is not a submission agent, it SHOULD reject or bounce the message to give the user an opportunity to make her own corrections. Alternately, if the client has sufficient additional information to know that special circumstances exist, it MAY examine hosts specified in DNS MX records with equal or lower preferences as specified in RFC 5321 Section 2.2.3." That approach assumes that the NDN requirements are covered in other standards and need not be repeated here. Of course, they could be listed if the WG prefers. john From yangwooko@gmail.com Tue Feb 7 00:04:11 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDF721F8737 for ; Tue, 7 Feb 2012 00:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRIfWe4cKmc9 for ; Tue, 7 Feb 2012 00:04:09 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 89D5E21F870A for ; Tue, 7 Feb 2012 00:04:08 -0800 (PST) Received: by iagf6 with SMTP id f6so11683333iag.31 for ; Tue, 07 Feb 2012 00:04:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=27ODib7sdLYDf0zSAbUL7s6f2U5gcwEp8vBMbFTDnRs=; b=mpe3odhUlGSsB+YffYA9xquRZaoLp8OS+HoxtRHFcgUcvHoJX9GzDs/sJDCsVf8oUS +eeURFfQkvr8VQwlbmaWyL73PIP+Dv+rb8BKOoeGiIuvdF0DFy4mfs52JXOJfF05O1F7 9o6ISgrcNjmtduVK3mRnWV1BYrS0FKwEKie+M= Received: by 10.42.151.196 with SMTP id f4mr23618475icw.29.1328601846262; Tue, 07 Feb 2012 00:04:06 -0800 (PST) MIME-Version: 1.0 Sender: yangwooko@gmail.com Received: by 10.42.18.200 with HTTP; Tue, 7 Feb 2012 00:03:46 -0800 (PST) In-Reply-To: <897EFBFD97C27926F15BAB3C@PST.JCK.COM> References: <897EFBFD97C27926F15BAB3C@PST.JCK.COM> From: Yangwoo Ko Date: Tue, 7 Feb 2012 17:03:46 +0900 X-Google-Sender-Auth: _Khqe4qYDLOQGm-p4eOMqlHPc5U Message-ID: To: John C Klensin Content-Type: multipart/alternative; boundary=90e6ba6e8378182aa504b85b39fd Cc: EAI WG Subject: Re: [EAI] Question about AUTH48 text for 5336bis/ proto-RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 08:04:11 -0000 --90e6ba6e8378182aa504b85b39fd Content-Type: text/plain; charset=UTF-8 Considering relations between 5321 and EAI documents, I like either choice A or choice C. Among A and C, C looks better because it explicitly reminds relations between 5321 and EAI documents. On Tue, Feb 7, 2012 at 2:39 PM, John C Klensin wrote: > > > Hi. > > We have encountered a small problem at AUTH48 with some text in > 5336bis (RFC-to-be 6531). The text in Section 3.2 of > draft-ietf-eai-rfc5336bis-16 (just before the numbered list) > reads: > > "Instead, if a UTF8SMTPbis-aware SMTP client > "(UTF8SMTPbis-aware SMTP sender) attempts to transfer an > internationalized message and encounters an SMTP server > that does not support the extension, it MUST make one of > the following three choices and the priority order is 1, 2 > and 3." > > The last part of that sentence was added in response to a Last > Call comment. If there is a moral here, it is that folks > should be really careful with changes in response to even > seemingly-editorial comments made during Last Call. In any > event, "the priority order is 1, 2 and 3" is ambiguous as to > whether the WG thinks choice 1 or choice 3 should come first. > > But it is a little worse than that because, in trying to fix > this, we discovered that the phrasing of those three choices > may not have been quite right. In particular, the third case > seemed to contradict a very carefully-worded exception case in > RFC 5321. > > To be clear what we are talking about before I outline what I > think are the options and ask for a decision, the current > AUTH48 working text reads (please don't worry about spacing): > > ...Instead, if an SMTPUTF8-aware SMTP client > (sender) attempts to transfer an internationalized message > and encounters an SMTP server that does not support the > extension, it MUST make one of the following three choices. > These are listed in decreasing order of preference. > > 1. It MAY either reject the message during the SMTP > transaction or > accept the message and then generate and transmit a > notification of non-deliverability. Such notification > MUST be done as specified in RFC 5321 [RFC5321], RFC > 3464 [RFC3464], and RFC 6533 [RFC6533]. > > 2. If and only if the SMTPUTF8-aware SMTP client (sender) > is a > Message Submission Agent (MSA) [RFC6409] [RFC5598], it > MAY choose its own way to deal with this scenario > according to the provisions of RFC 6409 [RFC6409] or its > future versions. However, the detailed specification of > this process and its results are outside the scope of > this document. > > 3. It MAY find an alternate route to the destination that > permits > SMTPUTF8. That route MAY be discovered by trying > alternate Mail eXchanger (MX) hosts (using preference > rules as specified in RFC 5321) or using other means > available to the SMTPUTF8-aware SMTP client. > > There was an earlier stage in which the text was the same, but > "increasing" was substituted for "decreasing". > > With an adjustment for what RFC 5321 actually allows, Pete > summarized these three cases as: > > 1. It MAY reject the message. > 2. If and only if it's a submission server, it MAY > something of its own choosing. > 3. It MAY try another MX. > > If we take RFC 5321 Section 2.2.3 into account, 3 can be > expanded to "It MAY try another MX if it decides to do so > based on the particular circumstances." > > > It is absolutely clear to us (myself, Joseph, and Pete) that > the WG intended to encourage letting submission servers fix up > messages if they knew how (case 2 above) and rejecting/bouncing > messages back to those servers so that they could fix things > (case 1 above). The third case is certainly reasonable as long > as it makes clear, somehow, that the circumstances are > important. Indeed, although it is a useful clarification that > RFC 5321 Section 2.2.3 may apply to this particular extension, > it actually adds nothing to what RFC 5321 would permit if this > document said nothing at all. > > So we probably need to fix the text (and to spend as little > time as possible making a decision). I think the following are > a complete list of options although, if someone has a better > idea, he or she should raise it. I hope that the WG can reach > consensus by mid-week (please make comments quickly so the WG > has a chance to discuss them if needed or, if you need more > time, say so). If there is no consensus on choice of text, > Joseph, Jiankang, Pete, and I will make a decision. If we have > to make a decision, we will consider both preferences for > particular approaches and remarks along the line of "do > whatever you like as long as you don't pick option 99". Note > that I'm not asking whether the WG still believes in correction > by submission servers, etc.: those issues are closed unless > someone comes up with a _really_ strong argument, presumably > strong enough to put all of this back into WG and IETF LC. We > are only trying to figure how to most clearly and accurately > reflect the WG's existing conclusions in the document. > > Note that whatever is chosen may still be fine-tuned > editorially. > > These options are deliberately in no particular order: > > A. Drop case 3 entirely to be consistent with the model of > putting nothing in these specs that is really part of the base > protocol (RFC 5321 in this case) and then clean up the text. > Note that this drops one piece of information that is not in > the base protocol, i.e., the WG's belief that SMTPUTF8 is an > extension to which Section 2.2.3 might reasonably be applied. > > ...Instead, if an SMTPUTF8-aware SMTP client > (sender) attempts to transfer an internationalized message > and encounters an SMTP server that does not support the > extension, it SHOULD make one of the following two choices. > These are listed in decreasing order of preference. > > 1. It MAY either reject the message during the SMTP > transaction or > accept the message and then generate and transmit a > notification of non-deliverability. Such notification > MUST be done as specified in RFC 5321 [RFC5321], RFC > 3464 [RFC3464], and RFC 6533 [RFC6533]. > > 2. If and only if the SMTPUTF8-aware SMTP client (sender) > is a > Message Submission Agent (MSA) [RFC6409] [RFC5598], it > MAY choose its own way to deal with this scenario > according to the provisions of RFC 6409 [RFC6409] or its > future versions. However, the detailed specification of > this process and its results are outside the scope of > this document. > > Note the change from MUST to SHOULD because there is another > choice (the MX searching of RFC 5321 Section 2.2.3) out there. > It could just be left alone on the theory that whatever 5321 > says overrides whatever is said here. Or we could explain the > SHOULD, but that takes us back to three cases and... > > > B. We leave all three cases as above and come up with revised > text as needed to clarify both the order and fact that case 3 > isn't to be used unless the client has the information > (presumably out of band) that permits it to conform to the key > requirement in RFC 5321 Section 2.2.3. That requirement > (second paragraph of 2.2.3) starts: > > In particular, if an extension implies that the delivery > path normally supports special features of that extension, > and an intermediate SMTP system finds a next hop that does > not support the required extension, it MAY choose, based on > the specific extension and circumstances, to requeue the > message and try later and/or try an alternate MX host. > > Note that 2.2.3 goes on to impose additional requirements on > timeouts in that case. > > C. We conclude that the "preference" order doesn't actually > mean much in this case. From that point of view, option 2 > applies only if the client is a submission server, option 3 > applies only if the client has special additional information > or circumstances (information or circumstances that presumably > could override either of the other preference), and option 1 > applies otherwise. If we then turn the wording around a bit, > we would get something like (borrowing text from the above > where possibe)... > > ...Instead, if an SMTPUTF8-aware SMTP client > (sender) attempts to transfer an internationalized message > and encounters an SMTP server that does not support the > extension, the best action for it to take depends on other > conditions. In particular: > > o If it is a Message Submission Agent (MSA) [RFC6409] > [RFC5598], it MAY choose its own way to deal with this > scenario using the wide discretion for changing addresses > or otherwise fixing up and transforming messages allowed > by RFC 6409. As long as the resulting message conforms > to the requirements of RFC 5321 (i.e., without the > SMTPUTF8 extension), the details of that transformation > are outside the scope of this document. > > o Otherwise, it SHOULD reject the message. As usual, this > can be done either by generating an appropriate reply > during the SMTP transaction or by accepting the message > and then generating and transmit a non-delivery > notification. If the latter choice is made, the > notification process MUST conform to the requirements of > RFC 5321 [RFC5321], RFC 3464 [RFC3464], and RFC 6533 > [RFC6533]. > > o As specified in RFC 5321 Section 2.2.3, an SMTP client > with additional information and/or knowledge of special > circumstances MAY choose to requeue the message and try > later and/or try an alternate MX host as specified in > that section. > > > D. Just about the same thing could be done, in somewhat more > terse form, by saying something like: > > "If the client is a submission agent [RFC6409], it SHOULD, > if possible, fix the message to be consistent with SMTP > requirements (in the absence of this extension) and resend > the transformed message. If it cannot or is not a > submission agent, it SHOULD reject or bounce the message > to give the user an opportunity to make her own > corrections. Alternately, if the client has sufficient > additional information to know that special circumstances > exist, it MAY examine hosts specified in DNS MX records > with equal or lower preferences as specified in RFC 5321 > Section 2.2.3." > > That approach assumes that the NDN requirements are covered in > other standards and need not be repeated here. Of course, they > could be listed if the WG prefers. > > john > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > -- a human known as yangwooko@gmail.com @ gtalk --90e6ba6e8378182aa504b85b39fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Considering relations between 5321 and EAI documents, I like either choice = A or choice C. Among A and C, C looks better because it explicitly reminds = relations between 5321 and EAI documents.

On Tue, Feb 7, 2012 at 2:39 PM, John C Klensin <klensin@jck.com> wrote:


Hi.

We have encountered a small problem at AUTH48 with some text in
5336bis (RFC-to-be 6531). =C2=A0The text in Section 3.2 of
draft-ietf-eai-rfc5336bis-16 (just before the numbered list)
reads:

=C2=A0 =C2=A0 =C2=A0 =C2=A0"Instead, if a UTF8SMTPbis-aware SMTP clie= nt
=C2=A0 =C2=A0 =C2=A0 =C2=A0"(UTF8SMTPbis-aware SMTP sender) attempts = to transfer an
=C2=A0 =C2=A0 =C2=A0 =C2=A0internationalized message and encounters an SMT= P server
=C2=A0 =C2=A0 =C2=A0 =C2=A0that does not support the extension, it MUST ma= ke one of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the following three choices and the priority or= der is 1, 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0and 3."

The last part of that sentence was added in response to a Last
Call comment. =C2=A0If there is a moral here, it is that folks
should be really careful with changes in response to even
seemingly-editorial comments made during Last Call. =C2=A0In any
event, "the priority order is 1, 2 and 3" is ambiguous as to
whether the WG thinks choice 1 or choice 3 should come first.

But it is a little worse than that because, in trying to fix
this, we discovered that the phrasing of those three choices
may not have been quite right. =C2=A0In particular, the third case
seemed to contradict a very carefully-worded exception case in
RFC 5321.

To be clear what we are talking about before I outline what I
think are the options and ask for a decision, the current
AUTH48 working text reads (please don't worry about spacing):

=C2=A0 ...Instead, if an SMTPUTF8-aware SMTP client
=C2=A0 (sender) attempts to transfer an internationalized message
=C2=A0 and encounters an SMTP server that does not support the
=C2=A0 extension, it MUST make one of the following three choices.
=C2=A0 These are listed in decreasing order of preference.

=C2=A0 1. =C2=A0It MAY either reject the message during the SMTP
=C2=A0 =C2=A0 =C2=A0 transaction or
=C2=A0 =C2=A0 =C2=A0 accept the message and then generate and transmit a =C2=A0 =C2=A0 =C2=A0 notification of non-deliverability. =C2=A0Such notifi= cation
=C2=A0 =C2=A0 =C2=A0 MUST be done as specified in RFC 5321 [RFC5321], RFC<= br> =C2=A0 =C2=A0 =C2=A0 3464 [RFC3464], and RFC 6533 [RFC6533].

=C2=A0 2. =C2=A0If and only if the SMTPUTF8-aware SMTP client (sender)
=C2=A0 =C2=A0 =C2=A0is a
=C2=A0 =C2=A0 =C2=A0 Message Submission Agent (MSA) [RFC6409] [RFC5598], i= t
=C2=A0 =C2=A0 =C2=A0 MAY choose its own way to deal with this scenario
=C2=A0 =C2=A0 =C2=A0 according to the provisions of RFC 6409 [RFC6409] or = its
=C2=A0 =C2=A0 =C2=A0 future versions. =C2=A0However, the detailed specific= ation of
=C2=A0 =C2=A0 =C2=A0 this process and its results are outside the scope of=
=C2=A0 =C2=A0 =C2=A0 this document.

=C2=A0 3. =C2=A0It MAY find an alternate route to the destination that
=C2=A0 =C2=A0 =C2=A0 permits
=C2=A0 =C2=A0 =C2=A0 SMTPUTF8. =C2=A0That route MAY be discovered by tryin= g
=C2=A0 =C2=A0 =C2=A0 alternate Mail eXchanger (MX) hosts (using preference=
=C2=A0 =C2=A0 =C2=A0 rules as specified in RFC 5321) or using other means<= br> =C2=A0 =C2=A0 =C2=A0 available to the SMTPUTF8-aware SMTP client.

There was an earlier stage in which the text was the same, but
"increasing" was substituted for "decreasing".

With an adjustment for what RFC 5321 actually allows, Pete
summarized these three cases as:

=C2=A0 =C2=A0 =C2=A0 =C2=A01. It MAY reject the message.
=C2=A0 =C2=A0 =C2=A0 =C2=A02. If and only if it's a submission server,= it MAY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 something of its own choosing.
=C2=A0 =C2=A0 =C2=A0 =C2=A03. It MAY try another MX.

=C2=A0 =C2=A0 =C2=A0 =C2=A0If we take RFC 5321 Section 2.2.3 into account,= 3 can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0expanded to "It MAY try another MX if it d= ecides to do so
=C2=A0 =C2=A0 =C2=A0 =C2=A0based on the particular circumstances."

It is absolutely clear to us (myself, Joseph, and Pete) that
the WG intended to encourage letting submission servers fix up
messages if they knew how (case 2 above) and rejecting/bouncing
messages back to those servers so that they could fix things
(case 1 above). =C2=A0The third case is certainly reasonable as long
as it makes clear, somehow, that the circumstances are
important. =C2=A0Indeed, although it is a useful clarification that
RFC 5321 Section 2.2.3 may apply to this particular extension,
it actually adds nothing to what RFC 5321 would permit if this
document said nothing at all.

So we probably need to fix the text (and to spend as little
time as possible making a decision). =C2=A0I think the following are
a complete list of options although, if someone has a better
idea, he or she should raise it. =C2=A0I hope that the WG can reach
consensus by mid-week (please make comments quickly so the WG
has a chance to discuss them if needed or, if you need more
time, say so). =C2=A0If there is no consensus on choice of text,
Joseph, Jiankang, Pete, and I will make a decision. =C2=A0If we have
to make a decision, we will consider both preferences for
particular approaches and remarks along the line of "do
whatever you like as long as you don't pick option 99". =C2=A0Note=
that I'm not asking whether the WG still believes in correction
by submission servers, etc.: those issues are closed unless
someone comes up with a _really_ strong argument, presumably
strong enough to put all of this back into WG and IETF LC. =C2=A0We
are only trying to figure how to most clearly and accurately
reflect the WG's existing conclusions in the document.

Note that whatever is chosen may still be fine-tuned
editorially.

These options are deliberately in no particular order:

A. =C2=A0Drop case 3 entirely to be consistent with the model of
putting nothing in these specs that is really part of the base
protocol (RFC 5321 in this case) and then clean up the text.
Note that this drops one piece of information that is not in
the base protocol, i.e., the WG's belief that SMTPUTF8 is an
extension to which Section 2.2.3 might reasonably be applied.

=C2=A0 ...Instead, if an SMTPUTF8-aware SMTP client
=C2=A0 (sender) attempts to transfer an internationalized message
=C2=A0 and encounters an SMTP server that does not support the
=C2=A0 extension, it SHOULD make one of the following two choices.
=C2=A0 These are listed in decreasing order of preference.

=C2=A0 1. =C2=A0It MAY either reject the message during the SMTP
=C2=A0 =C2=A0 =C2=A0 transaction or
=C2=A0 =C2=A0 =C2=A0 accept the message and then generate and transmit a =C2=A0 =C2=A0 =C2=A0 notification of non-deliverability. =C2=A0Such notifi= cation
=C2=A0 =C2=A0 =C2=A0 MUST be done as specified in RFC 5321 [RFC5321], RFC<= br> =C2=A0 =C2=A0 =C2=A0 3464 [RFC3464], and RFC 6533 [RFC6533].

=C2=A0 2. =C2=A0If and only if the SMTPUTF8-aware SMTP client (sender)
=C2=A0 =C2=A0 =C2=A0 is a
=C2=A0 =C2=A0 =C2=A0 Message Submission Agent (MSA) [RFC6409] [RFC5598], i= t
=C2=A0 =C2=A0 =C2=A0 MAY choose its own way to deal with this scenario
=C2=A0 =C2=A0 =C2=A0 according to the provisions of RFC 6409 [RFC6409] or = its
=C2=A0 =C2=A0 =C2=A0 future versions. =C2=A0However, the detailed specific= ation of
=C2=A0 =C2=A0 =C2=A0 this process and its results are outside the scope of=
=C2=A0 =C2=A0 =C2=A0 this document.

Note the change from MUST to SHOULD because there is another
choice (the MX searching of RFC 5321 Section 2.2.3) out there.
It could just be left alone on the theory that whatever 5321
says overrides whatever is said here. =C2=A0 Or we could explain the
SHOULD, but that takes us back to three cases and...


B. =C2=A0We leave all three cases as above and come up with revised
text as needed to clarify both the order and fact that case 3
isn't to be used unless the client has the information
(presumably out of band) that permits it to conform to the key
requirement in RFC 5321 Section 2.2.3. =C2=A0That requirement
(second paragraph of 2.2.3) starts:

=C2=A0 In particular, if an extension implies that the delivery
=C2=A0 path normally supports special features of that extension,
=C2=A0 and an intermediate SMTP system finds a next hop that does
=C2=A0 not support the required extension, it MAY choose, based on
=C2=A0 the specific extension and circumstances, to requeue the
=C2=A0 message and try later and/or try an alternate MX host.

Note that 2.2.3 goes on to impose additional requirements on
timeouts in that case.

C. =C2=A0We conclude that the "preference" order doesn't actu= ally
mean much in this case. =C2=A0From that point of view, option 2
applies only if the client is a submission server, option 3
applies only if the client has special additional information
or circumstances (information or circumstances that presumably
could override either of the other preference), and option 1
applies otherwise. =C2=A0If we then turn the wording around a bit,
we would get something like (borrowing text from the above
where possibe)...

=C2=A0 ...Instead, if an SMTPUTF8-aware SMTP client
=C2=A0 (sender) attempts to transfer an internationalized message
=C2=A0 and encounters an SMTP server that does not support the
=C2=A0 extension, the best action for it to take depends on other
=C2=A0 conditions. =C2=A0In particular:

=C2=A0 =C2=A0o If it is a Message Submission Agent (MSA) [RFC6409]
=C2=A0 =C2=A0 =C2=A0[RFC5598], it MAY choose its own way to deal with this=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scenario using the wide discretion for c= hanging addresses
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or otherwise fixing up and transforming = messages allowed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by RFC 6409. As long as the resulting me= ssage conforms
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to the requirements of RFC 5321 (i.e., w= ithout the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SMTPUTF8 extension), the details of that= transformation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0are outside the scope of this document.<= br>
=C2=A0 =C2=A0o Otherwise, it SHOULD reject the message. =C2=A0As usual, th= is
=C2=A0 =C2=A0 =C2=A0can be done either by generating an appropriate reply<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0during the SMTP transaction or by accept= ing the message
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and then generating and transmit a non-d= elivery
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0notification. =C2=A0If the latter choice= is made, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0notification process MUST conform to the= requirements of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5321 [RFC5321], RFC 3464 [RFC3464], = and RFC 6533
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC6533].

=C2=A0 =C2=A0o As specified in RFC 5321 Section 2.2.3, an SMTP client
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with additional information and/or knowl= edge of special
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0circumstances MAY choose to requeue the = message and try
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0later and/or try an alternate MX host as= specified in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that section.


D. =C2=A0Just about the same thing could be done, in somewhat more
terse form, by saying something like:

=C2=A0 =C2=A0 =C2=A0 =C2=A0"If the client is a submission agent [RFC6= 409], it SHOULD,
=C2=A0 =C2=A0 =C2=A0 =C2=A0if possible, fix the message to be consistent w= ith SMTP
=C2=A0 =C2=A0 =C2=A0 =C2=A0requirements (in the absence of this extension)= and resend
=C2=A0 =C2=A0 =C2=A0 =C2=A0the transformed message. =C2=A0 If it cannot or= is not a
=C2=A0 =C2=A0 =C2=A0 =C2=A0submission agent, it SHOULD reject or bounce th= e message
=C2=A0 =C2=A0 =C2=A0 =C2=A0to give the user an opportunity to make her own=
=C2=A0 =C2=A0 =C2=A0 =C2=A0corrections. =C2=A0Alternately, if the client h= as sufficient
=C2=A0 =C2=A0 =C2=A0 =C2=A0additional information to know that special cir= cumstances
=C2=A0 =C2=A0 =C2=A0 =C2=A0exist, it MAY examine hosts specified in DNS MX= records
=C2=A0 =C2=A0 =C2=A0 =C2=A0with equal or lower preferences as specified in= RFC 5321
=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 2.2.3."

That approach assumes that the NDN requirements are covered in
other standards and need not be repeated here. =C2=A0Of course, they
could be listed if the WG prefers.

=C2=A0 =C2=A0 john

_______________________________________________
IMA mailing list
IMA@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/ima



--
a human know= n as yangwooko@gma= il.com @ gtalk<= /a>
--90e6ba6e8378182aa504b85b39fd-- From arnt@gulbrandsen.priv.no Tue Feb 7 02:01:37 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7BF21F87B8 for ; Tue, 7 Feb 2012 02:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6H4tbqV0Mzs for ; Tue, 7 Feb 2012 02:01:37 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id D9F0721F87B7 for ; Tue, 7 Feb 2012 02:01:36 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 12771FA0993; Tue, 7 Feb 2012 10:01:34 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1328608892-27816-27816/10/5; Tue, 7 Feb 2012 10:01:32 +0000 Message-Id: <4F30F690.8030106@gulbrandsen.priv.no> Date: Tue, 7 Feb 2012 11:01:52 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: John R Levine References: <20120202155907.68354.qmail@joyce.lan> <4E827E8757009681283FD43E@PST.JCK.COM> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1 Cc: ima@ietf.org Subject: Re: [EAI] Unhappy with the complexity of pop-imap-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 10:01:37 -0000 On 02/06/2012 04:15 PM, John R Levine wrote: >> Fwiw, the reason for me to implement a kind of downgrade is that EAI >> mail may appear in folders whet you don't expect it, such as the one >> in which you store this mailing list. > > Understood, but there's simpler ways to do that than to specify a > detailed non-reversible downgrade scheme. Exactly. _A_ downgrade is justified, not a high-fidelity one. Arnt From johnl@iecc.com Tue Feb 7 08:46:58 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AD021F8816 for ; Tue, 7 Feb 2012 08:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.593 X-Spam-Level: X-Spam-Status: No, score=-109.593 tagged_above=-999 required=5 tests=[AWL=1.606, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gF0FlYWzOCQh for ; Tue, 7 Feb 2012 08:46:57 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8097421F87F7 for ; Tue, 7 Feb 2012 08:46:57 -0800 (PST) Received: (qmail 31276 invoked from network); 7 Feb 2012 16:46:52 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Feb 2012 16:46:52 -0000 Date: 7 Feb 2012 16:46:29 -0000 Message-ID: <20120207164629.35965.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <897EFBFD97C27926F15BAB3C@PST.JCK.COM> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] Question about AUTH48 text for 5336bis/ proto-RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:46:58 -0000 I also have a mild preference for option C. Here's the possibilities, do what works for you. I do think we should mention trying another MX, if only via a pointer to 5321. R's, John From Shawn.Steele@microsoft.com Tue Feb 7 08:54:59 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687C521F8861 for ; Tue, 7 Feb 2012 08:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfLVeIXRTNcP for ; Tue, 7 Feb 2012 08:54:58 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id C1D2521F883E for ; Tue, 7 Feb 2012 08:54:58 -0800 (PST) Received: from mail180-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Tue, 7 Feb 2012 16:54:57 +0000 Received: from mail180-ch1 (localhost [127.0.0.1]) by mail180-ch1-R.bigfish.com (Postfix) with ESMTP id 16C732A036F for ; Tue, 7 Feb 2012 16:54:57 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail180-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail180-ch1 (localhost.localdomain [127.0.0.1]) by mail180-ch1 (MessageSwitch) id 1328633696245017_26048; Tue, 7 Feb 2012 16:54:56 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236]) by mail180-ch1.bigfish.com (Postfix) with ESMTP id 2E71814004A for ; Tue, 7 Feb 2012 16:54:56 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 7 Feb 2012 16:54:53 +0000 Received: from TK5EX14MBXC133.redmond.corp.microsoft.com ([169.254.2.138]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0247.005; Tue, 7 Feb 2012 08:54:38 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Question about AUTH48 text for 5336bis/ proto-RFC 6531 Thread-Index: Aczlt5FHFTaxAKDLSTudnmZVxjvQYw== Date: Tue, 7 Feb 2012 16:54:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [EAI] Question about AUTH48 text for 5336bis/ proto-RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:54:59 -0000 I agree that the priority isn't particularly helpful, and could be damaging= . Which of the 3 choices is taken depends on which one applies to the curr= ent situation, regardless of priority. I kind of like C, although I'd remove the "otherwise" from the 2nd bullet, = which is implicitly asserting a priority. I do like the "reminder" in the = 3rd bullet of C that other routes are available. Although that's fairly cl= ear in RFC5231 section 2.2.3, it may not be obvious in this context. I'd also be fine with A, or your corrected original example. I'm more wary= of B & D because they are significantly revised and this isn't worth ratho= ling on. Though awkward, I don't even think the original text would block = implementers. -Shawn From klensin@jck.com Tue Feb 7 08:55:48 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC0921F885F for ; Tue, 7 Feb 2012 08:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.672 X-Spam-Level: X-Spam-Status: No, score=-2.672 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SbLTQeJIiY5 for ; Tue, 7 Feb 2012 08:55:47 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7844021F8850 for ; Tue, 7 Feb 2012 08:55:47 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RuoGr-000MiL-An; Tue, 07 Feb 2012 11:51:57 -0500 Date: Tue, 07 Feb 2012 11:55:39 -0500 From: John C Klensin To: John R Levine , fujiwara@jprs.co.jp Message-ID: <4BB722109CB6AFE6C88F6931@PST.JCK.COM> In-Reply-To: References: <20120202155907.68354.qmail@joyce.lan> <4E827E8757009681283FD43E@PST.JCK.COM> <20120206.201920.250832792.fujiwara@jprs.co.jp> 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: ima@ietf.org Subject: Re: [EAI] Unhappy with the complexity of pop-imap-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:55:48 -0000 Folks, I'd like to suggest that people dial down the rhetoric and try extra-hard to listen to and understand each other because there may be a lot of different, valid, perspectives on the subject. A few of us have pointed out that the IETF doesn't do well with UI designs, but, while there may be some assumptions, UI designs are not really the issue here. What is an issue is the relationship among the delivery MTA, the message store, the IMAP or POP server, the user and her MUA (and IMAP or POP client), and maybe some other pieces. Operational deployment policies may be important too: if I'm an operator or IT department in an organization that is basically ASCII-oriented and I'm not going to advertise SMTPUTF8 capability from the delivery MTA until I have EAI-competent IMAP and POP clients available and have told people to convert to them, my attitude toward downgrades may be very different from, e.g., being in a mostly non-ASCII environment in which people are very anxious to enable SMTPUTF8 and non-ASCII addresses on the delivery servers but where I expect the deployment rate for upgraded clients to have a very long tail. For obvious reasons, the IETF has traditionally stayed away from trying to put requirements on those operational relationships among consenting (and usually connected) parties. None of us really know each other's operational environments or assumptions; we know even less about environments and assumptions that are not represented in the WG. So, while I think it is useful for us to explore and, if appropriate, document, a range of options for different scenarios, I think we should skip trying to tell others what they do or do not need. I noted that, for one scenario, I'd like to explore mechanisms for giving the IMAP or POP user a clear "there are messages waiting for you that you aren't going to see until you switch clients or find a different access method" message. I don't think that is the only answer, or even a "best" answer, just that it matches at least one plausible scenario. So, while I'm open to other ideas, I'd like to see those who think that scenarios other than the one anticipated by the current pop-imap-downgrade are important to prepare I-Ds describing the scenarios they anticipate and what the corresponding protocol would look like, both in enough detail that the WG can look at the drafts and figure out whether there is consensus on publication. As part of this, I think we should try to modify the current pop-imap-downgrade draft to include a description of the scenario(s) that would justify its "preserve all possible information even if it cannot be used in automated replies" approach. Please remember that our target is still to have the set of POP-IMAP documents in the hands of the IESG well before the Paris IETF so, if you are going to write, write quickly. That said, I don't know that there would be a big problem handling additional scenarios/protocol specifications as individual submissions if that were necessary. It would be nice to end up with no more than three scenario-solution combinations: no downgrade (refuse to deliver), full information preservation, and somewhere in between. But I see no need to require that at this point, nor any possibility of doing so. Let's see some drafts. If anyone has better ideas that would help us move forward efficiently, please say so. john From alexey.melnikov@isode.com Tue Feb 7 09:35:56 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B9221F8892 for ; Tue, 7 Feb 2012 09:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.158 X-Spam-Level: X-Spam-Status: No, score=-102.158 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wbe4YRd0984H for ; Tue, 7 Feb 2012 09:35:55 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5742821F888E for ; Tue, 7 Feb 2012 09:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1328636153; d=isode.com; s=selector; i=@isode.com; bh=RcOlyb/Rldo0D0NxZAwbZ7F0x2fyix2TeSBVpC2NhUk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=kwFwg2g7e7E8kEA9sWi1oKnozStmxkauVzX53Hzd5z4Be+EzDjBxUplmunFi2nsOq5wuKk 6Qzjb+OfptlYcY7/hUniXCK3JPU0WROyHHrkzcEMxiuHFzJ00keh5OBf4/fRwDe4m8Bwpk WHysG/VkAIXf5TFeGPjk/QWdnbx3xcI=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 7 Feb 2012 17:35:53 +0000 Message-ID: <4F3160FA.8030409@isode.com> Date: Tue, 07 Feb 2012 17:35:54 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 To: John C Klensin References: <897EFBFD97C27926F15BAB3C@PST.JCK.COM> In-Reply-To: <897EFBFD97C27926F15BAB3C@PST.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: EAI WG Subject: Re: [EAI] Question about AUTH48 text for 5336bis/ proto-RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 17:35:56 -0000 Hi John, C or D work for me. B is acceptable. I dislike A. From johnl@taugh.com Tue Feb 7 20:37:42 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3413E21F864F for ; Tue, 7 Feb 2012 20:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydUEqL4My-OX for ; Tue, 7 Feb 2012 20:37:41 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E531421F8644 for ; Tue, 7 Feb 2012 20:37:40 -0800 (PST) Received: (qmail 99131 invoked from network); 8 Feb 2012 04:37:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=1833a.4f31fc11.k1202; bh=pLZ3XXSvE9mfxfn0YVgnMXZLMXER21soRgIw9RZkeu4=; b=qQV3dZwIRQumRVssquGH3M6jUVd17z/mqROa613xG/3GiJPivSdct5k6VGoDWlm6zC3mNrC6HzDm0zJCg3pGN2Q2kfwBjYQaZTwPnIICTUP2gyFQvypstLIsr8qF9IzZX62+LjhGurGKp9gwNS3Gpici2/cXTiIzYm7cM7gon2c= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=1833a.4f31fc11.k1202; bh=pLZ3XXSvE9mfxfn0YVgnMXZLMXER21soRgIw9RZkeu4=; b=Kzqra63VUxm66/Fngvq9mExfCyjOM6aQPRVAPTiFJq/UIBp0L6ecRZh5GlKqVPOIk09HQ3YXBs5Jh24XgMwZcyGMKEamyFfwtxIq2ES5DrmvdQEZuG5SpF0X/8BXHidEOSfs+qH1btEENkXrY9urjPqirXxxwpvZIUQnZ/kGz4M= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Feb 2012 04:37:15 -0000 Date: 7 Feb 2012 23:37:36 -0500 Message-ID: From: "John R Levine" To: "John C Klensin" In-Reply-To: <4BB722109CB6AFE6C88F6931@PST.JCK.COM> References: <20120202155907.68354.qmail@joyce.lan> <4E827E8757009681283FD43E@PST.JCK.COM> <20120206.201920.250832792.fujiwara@jprs.co.jp> <4BB722109CB6AFE6C88F6931@PST.JCK.COM> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: ima@ietf.org Subject: Re: [EAI] Unhappy with the complexity of pop-imap-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 04:37:42 -0000 > I'd like to suggest that people dial down the rhetoric and try > extra-hard to listen to and understand each other because there > may be a lot of different, valid, perspectives on the subject. You're right, it really depends on your model of how users will make the transition from legacy to EAI mail. Here's some possibilities I can think of when an MTA starts handling EAI mail: 1. Users don't have to upgrade, but get EAI mail anyway: the server creates some version of EAI messages for legacy clients, downgraded or wrapped. If they're serious about supporting legacy clients, they'd need some way for legacy users to respond to EAI mail, e.g., the server creates local forwarding addresses for EAI addresses in downgraded or wrapped messages, and substitutes them into the headers. (I am most definitely not suggesting we spec out the way that would work.) 2. Users are expected to upgrade: server can synthesize DSNs that say "upgrade your MUA like we told you to if you want to see your mail." 3. Users who want EAI mail upgrade, users who don't care, don't: the server remembers which users are EAI enabled, based on whether they've sent EAI mail or set the UTF8 flag in a POP or IMAP session. Server rejects incoming EAI mail to non-EAI users. For legacy POP and IMAP sessions from EAI users, it synthesizes DSNs that say "use your EAI mail program." I can see any of these being reasonable, depending on the user community and its relationship to the mail service. But I have to say, the current downgrade where you can mostly see messages but not respond to them seems cruel. If you want to provide backward compatibility for your legacy users, it should let them use mail like they're accustomed to using it. R's, John From duerst@it.aoyama.ac.jp Wed Feb 8 02:54:56 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACDC21F86CF for ; Wed, 8 Feb 2012 02:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.809 X-Spam-Level: X-Spam-Status: No, score=-100.809 tagged_above=-999 required=5 tests=[AWL=-1.019, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bd3ZtlFtnOyb for ; Wed, 8 Feb 2012 02:54:55 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 897D821F84E0 for ; Wed, 8 Feb 2012 02:54:55 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q18AsmC1016238 for ; Wed, 8 Feb 2012 19:54:48 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 4007_177a_518c347a_5243_11e1_9755_001d096c5782; Wed, 08 Feb 2012 19:54:48 +0900 Received: from [IPv6:::1] ([133.2.210.1]:38407) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 8 Feb 2012 19:54:52 +0900 Message-ID: <4F325470.1030903@it.aoyama.ac.jp> Date: Wed, 08 Feb 2012 19:54:40 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John C Klensin References: <20120202155907.68354.qmail@joyce.lan> <4E827E8757009681283FD43E@PST.JCK.COM> <20120206.201920.250832792.fujiwara@jprs.co.jp> <4BB722109CB6AFE6C88F6931@PST.JCK.COM> In-Reply-To: <4BB722109CB6AFE6C88F6931@PST.JCK.COM> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] Unhappy with the complexity of pop-imap-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 10:54:56 -0000 On 2012/02/08 1:55, John C Klensin wrote: > > Please remember that our target is still to have the set of > POP-IMAP documents in the hands of the IESG well before the > Paris IETF so, if you are going to write, write quickly. That > said, I don't know that there would be a big problem handling > additional scenarios/protocol specifications as individual > submissions if that were necessary. Quick question: Is downgrade an integral part of the POP-IMAP documents set, or could it be treated as a separate thing, so that the main POP and IMAP documents could move ahead even if we have to take some more time with downgrade? Regards, Martin. From duerst@it.aoyama.ac.jp Wed Feb 8 02:58:09 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA4B21F85CC for ; Wed, 8 Feb 2012 02:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.716 X-Spam-Level: X-Spam-Status: No, score=-100.716 tagged_above=-999 required=5 tests=[AWL=-0.926, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wodzNlWc-sjV for ; Wed, 8 Feb 2012 02:58:08 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 78E1121F842D for ; Wed, 8 Feb 2012 02:58:08 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q18Aw7vo009091 for ; Wed, 8 Feb 2012 19:58:07 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 4015_a847_c82ef932_5243_11e1_9755_001d096c5782; Wed, 08 Feb 2012 19:58:07 +0900 Received: from [IPv6:::1] ([133.2.210.1]:57296) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 8 Feb 2012 19:58:11 +0900 Message-ID: <4F325537.3090000@it.aoyama.ac.jp> Date: Wed, 08 Feb 2012 19:57:59 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Shawn Steele References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "ima@ietf.org" Subject: Re: [EAI] Question about AUTH48 text for 5336bis/ proto-RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 10:58:09 -0000 On 2012/02/08 1:54, Shawn Steele wrote: > I agree that the priority isn't particularly helpful, and could be damaging. Which of the 3 choices is taken depends on which one applies to the current situation, regardless of priority. > > I kind of like C, although I'd remove the "otherwise" from the 2nd bullet, which is implicitly asserting a priority. I do like the "reminder" in the 3rd bullet of C that other routes are available. Although that's fairly clear in RFC5231 section 2.2.3, it may not be obvious in this context. Same here, with the same tweak. But I'm only an observer in this game, so please ignore me if it helps moving forward. Regards, Martin. From arnt@gulbrandsen.priv.no Wed Feb 8 03:13:31 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1611521F8625 for ; Wed, 8 Feb 2012 03:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FEA6118UUSs for ; Wed, 8 Feb 2012 03:13:30 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7910021F8618 for ; Wed, 8 Feb 2012 03:13:30 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4465AF8C516; Wed, 8 Feb 2012 11:13:28 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1328699607-31942-31942/10/7; Wed, 8 Feb 2012 11:13:27 +0000 Message-Id: <4F3258ED.5050505@gulbrandsen.priv.no> Date: Wed, 8 Feb 2012 12:13:49 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: ima@ietf.org References: <20120202155907.68354.qmail@joyce.lan> <4E827E8757009681283FD43E@PST.JCK.COM> <20120206.201920.250832792.fujiwara@jprs.co.jp> <4BB722109CB6AFE6C88F6931@PST.JCK.COM> <4F325470.1030903@it.aoyama.ac.jp> In-Reply-To: <4F325470.1030903@it.aoyama.ac.jp> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [EAI] Unhappy with the complexity of pop-imap-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 11:13:31 -0000 On 02/08/2012 11:54 AM, Martin J. D=FCrst wrote: > Quick question: Is downgrade an integral part of the POP-IMAP documents > set, or could it be treated as a separate thing, so that the main POP > and IMAP documents could move ahead even if we have to take some more > time with downgrade? I'm not sure. As far as I could tell, none of the IMAP, POP, SMTP or Submission extensions involve a promise on part of the server to support IMAP/POP downgrading. But I find that a little surprising, so maybe there is a promise I've overlooked? Arnt From klensin@jck.com Wed Feb 8 04:06:22 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1DC21F86B6 for ; Wed, 8 Feb 2012 04:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzvGnv5yuuVv for ; Wed, 8 Feb 2012 04:06:21 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id D813821F86B4 for ; Wed, 8 Feb 2012 04:06:20 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Rv6EI-000OLF-0X; Wed, 08 Feb 2012 07:02:30 -0500 Date: Wed, 08 Feb 2012 07:06:13 -0500 From: John C Klensin To: John R Levine Message-ID: <7912B5C2EEAFF66C78BC0B6D@PST.JCK.COM> In-Reply-To: References: <20120202155907.68354.qmail@joyce.lan> <4E827E8757009681283FD43E@PST.JCK.COM> <20120206.201920.250832792.fujiwara@jprs.co.jp> <4BB722109CB6AFE6C88F6931@PST.JCK.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: ima@ietf.org Subject: Re: [EAI] Unhappy with the complexity of pop-imap-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 12:06:22 -0000 --On Tuesday, February 07, 2012 23:37 -0500 John R Levine wrote: >... > I can see any of these being reasonable, depending on the user > community and its relationship to the mail service. But I > have to say, the current downgrade where you can mostly see > messages but not respond to them seems cruel. If you want to > provide backward compatibility for your legacy users, it > should let them use mail like they're accustomed to using it. It is maybe worth noting that one of the old jokes about X.400 was the the only way to reply to most X.400 messages involved picking up the phone (either to respond directly or to find a route). We know how much X.400 traffic there is today, probably in part as a consequence. On the other hand, people can eliminate those problems by upgrading (either an MUA or a provider) which, for X.400 users who didn't like the "reply by phone" option, there was mostly the possibility of "upgrading" to Internet mail. Many did. So I would suggest that cruelty lies somewhat in the eye of the beholder. And, while circumstances differ, if it encourages upgrading, maybe one should be in favor of a little cruelty :-( john From klensin@jck.com Wed Feb 8 04:43:50 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7F721F86C8 for ; Wed, 8 Feb 2012 04:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MACuIz0A9XNo for ; Wed, 8 Feb 2012 04:43:49 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE6A21F86BB for ; Wed, 8 Feb 2012 04:43:49 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Rv6oV-000OO5-Me; Wed, 08 Feb 2012 07:39:55 -0500 Date: Wed, 08 Feb 2012 07:43:38 -0500 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= Message-ID: <7FE44A102AF3230A5E5A91F1@PST.JCK.COM> In-Reply-To: <4F325470.1030903@it.aoyama.ac.jp> References: <20120202155907.68354.qmail@joyce.lan> <4E827E8757009681283FD43E@PST.JCK.COM> <20120206.201920.250832792.fujiwara@jprs.co.jp> <4BB722109CB6AFE6C88F6931@PST.JCK.COM> <4F325470.1030903@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] Unhappy with the complexity of pop-imap-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 12:43:50 -0000 --On Wednesday, February 08, 2012 19:54 +0900 "\"Martin J. D=C3=BCrst\"" wrote: > On 2012/02/08 1:55, John C Klensin wrote: >> >=20 >> Please remember that our target is still to have the set of >> POP-IMAP documents in the hands of the IESG well before the >> Paris IETF so, if you are going to write, write quickly. = That >> said, I don't know that there would be a big problem handling >> additional scenarios/protocol specifications as individual >> submissions if that were necessary. >=20 > Quick question: Is downgrade an integral part of the POP-IMAP > documents set, or could it be treated as a separate thing, so > that the main POP and IMAP documents could move ahead even if > we have to take some more time with downgrade? Your quick question doesn't have a quick answer. It would almost certainly be possible to restructure the POP and IMAP documents to make a downgrade model (very broadly construed and probably including the explicit "there is a message here that you can't read" possibility that John Levine and I have been poking at) a future task. Whether the IETF Last Call and the IESG would let us get away with that is a different question -- the IETF has often, but not always, been uncomfortable with situations that require transitions but where the documents come with no plan or discussion of a strategy. In addition and even more important, the WG has so far assumed that some sort of plan is needed to deal with the case of a delivery MTA that accepts SMTPUTF8 messages but that something between there and the user can't handle them. I think it might be hard to get consensus in the WG to walk away from that position although, if there were enough interest, we could ask the question (while remembering that the IETF community might push back and at least require a thorough analysis if not a protocol). Speaking personally, I'd also hope the WG would ask the question as to whether "POP and IMAP now; downgrade after we take some more time" would actually buy anything. Remembering that our target isn't to get documents published but to get systems and capabilities deployed, unless there was evidence that there were important actors who would deploy without these post-delivery-MTA issues being resolved by the WG, splitting downgrade handling into a separate, later, task might actually result in a longer time before deployment occurred (because we'd have to spend time revising and reviewing the POP and IMAP documents to deal with the change rather than focusing that energy on getting the downgrading model resolved. john From klensin@jck.com Wed Feb 8 05:03:14 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DC421F8565 for ; Wed, 8 Feb 2012 05:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MD6kq7O3S+We for ; Wed, 8 Feb 2012 05:03:13 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id B123B21F8552 for ; Wed, 8 Feb 2012 05:03:09 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Rv77F-000OPQ-6P; Wed, 08 Feb 2012 07:59:17 -0500 Date: Wed, 08 Feb 2012 08:03:00 -0500 From: John C Klensin To: Arnt Gulbrandsen , ima@ietf.org Message-ID: In-Reply-To: <4F3258ED.5050505@gulbrandsen.priv.no> References: <20120202155907.68354.qmail@joyce.lan> <4E827E8757009681283FD43E@PST.JCK.COM> <20120206.201920.250832792.fujiwara@jprs.co.jp> <4BB722109CB6AFE6C88F6931@PST.JCK.COM> <4F325470.1030903@it.aoyama.ac.jp> <4F3258ED.5050505@gulbrandsen.priv.no> 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 Subject: Re: [EAI] Unhappy with the complexity of pop-imap-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 13:03:14 -0000 --On Wednesday, February 08, 2012 12:13 +0100 Arnt Gulbrandsen wrote: >... > As far as I could tell, none of the IMAP, POP, SMTP or > Submission extensions involve a promise on part of the server > to support IMAP/POP downgrading. But I find that a little > surprising, so maybe there is a promise I've overlooked? The problem is that the server can't know and the promise should not be necessary in the long term (everything past the delivery server EAI-capable). Trying to draw a picture that covers all of the cases, including closely-connected message stores and ones to whom messages are passed (via LMTP, shared NFS-like storage, or otherwise), POP/IMAP clients with varying capabilities, and so on. is really illuminating about how many cases there are, what information has to be available in what places, etc. A delivery server _could_ promise to always downgrade a message before depositing it in or transferring it to the the mail store but that is exactly the behavior we want to discourage in order to favor EAI-capable mail stores. john From arnt@gulbrandsen.priv.no Wed Feb 8 05:42:27 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBC121F8504 for ; Wed, 8 Feb 2012 05:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9K9onESgpGdu for ; Wed, 8 Feb 2012 05:42:27 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 06C4E21F845E for ; Wed, 8 Feb 2012 05:42:27 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 38371F8C524; Wed, 8 Feb 2012 13:42:25 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1328708544-31942-31942/10/8; Wed, 8 Feb 2012 13:42:24 +0000 User-Agent: Kaiten Mail for Android In-Reply-To: References: <20120202155907.68354.qmail@joyce.lan> <4E827E8757009681283FD43E@PST.JCK.COM> <20120206.201920.250832792.fujiwara@jprs.co.jp> <4BB722109CB6AFE6C88F6931@PST.JCK.COM> <4F325470.1030903@it.aoyama.ac.jp> <4F3258ED.5050505@gulbrandsen.priv.no> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=----J29ULHLDW2LVSFTLRCETG42D41Y5M0 From: Arnt Gulbrandsen Date: Wed, 8 Feb 2012 14:38:18 +0100 To: John C Klensin , ima@ietf.org Message-Id: <8caa9e63-2623-496e-8d4b-20ebde053793@email.android.com> Subject: Re: [EAI] Unhappy with the complexity of pop-imap-downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 13:42:27 -0000 ------J29ULHLDW2LVSFTLRCETG42D41Y5M0 Content-Type: text/plain; charset=utf-8 That answer makes perfect sense to me. A fine, coherent design. Arnt ------J29ULHLDW2LVSFTLRCETG42D41Y5M0 Content-Type: text/html; charset=utf-8 That answer makes perfect sense to me. A fine, coherent design.

Arnt ------J29ULHLDW2LVSFTLRCETG42D41Y5M0-- From chris.newman@oracle.com Wed Feb 8 10:25:32 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6923521F85C4 for ; Wed, 8 Feb 2012 10:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.437 X-Spam-Level: X-Spam-Status: No, score=-105.437 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9-xYvogPwg4 for ; Wed, 8 Feb 2012 10:25:31 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF9321E8010 for ; Wed, 8 Feb 2012 10:25:31 -0800 (PST) Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id q18IPTsm013246; Wed, 8 Feb 2012 18:25:29 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail2-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id q18IPIOI013065; Wed, 8 Feb 2012 18:25:18 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.03 64bit (built Oct 25 2011)) with ESMTPA id <0LZ300M4T761GH00@gotmail.us.oracle.com>; Wed, 08 Feb 2012 10:25:18 -0800 (PST) Date: Tue, 07 Feb 2012 09:50:22 -0800 From: Chris Newman To: John C Klensin , EAI WG Message-id: In-reply-to: <897EFBFD97C27926F15BAB3C@PST.JCK.COM> References: <897EFBFD97C27926F15BAB3C@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Mac OS X) Subject: Re: [EAI] Question about AUTH48 text for 5336bis/ proto-RFC 6531 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:25:32 -0000 I really like the wording in the third bullet of option C, so that's my mild preference as a result. All four options are acceptable to me, but I think the proposed text in option C will result in minimal time expenditure on this issue. - Chris --On February 7, 2012 0:39:56 -0500 John C Klensin wrote: > Hi. > > We have encountered a small problem at AUTH48 with some text in > 5336bis (RFC-to-be 6531). The text in Section 3.2 of > draft-ietf-eai-rfc5336bis-16 (just before the numbered list) > reads: > > "Instead, if a UTF8SMTPbis-aware SMTP client > "(UTF8SMTPbis-aware SMTP sender) attempts to transfer an > internationalized message and encounters an SMTP server > that does not support the extension, it MUST make one of > the following three choices and the priority order is 1, 2 > and 3." > > The last part of that sentence was added in response to a Last > Call comment. If there is a moral here, it is that folks > should be really careful with changes in response to even > seemingly-editorial comments made during Last Call. In any > event, "the priority order is 1, 2 and 3" is ambiguous as to > whether the WG thinks choice 1 or choice 3 should come first. > > But it is a little worse than that because, in trying to fix > this, we discovered that the phrasing of those three choices > may not have been quite right. In particular, the third case > seemed to contradict a very carefully-worded exception case in > RFC 5321. > > To be clear what we are talking about before I outline what I > think are the options and ask for a decision, the current > AUTH48 working text reads (please don't worry about spacing): > > ...Instead, if an SMTPUTF8-aware SMTP client > (sender) attempts to transfer an internationalized message > and encounters an SMTP server that does not support the > extension, it MUST make one of the following three choices. > These are listed in decreasing order of preference. > > 1. It MAY either reject the message during the SMTP > transaction or > accept the message and then generate and transmit a > notification of non-deliverability. Such notification > MUST be done as specified in RFC 5321 [RFC5321], RFC > 3464 [RFC3464], and RFC 6533 [RFC6533]. > > 2. If and only if the SMTPUTF8-aware SMTP client (sender) > is a > Message Submission Agent (MSA) [RFC6409] [RFC5598], it > MAY choose its own way to deal with this scenario > according to the provisions of RFC 6409 [RFC6409] or its > future versions. However, the detailed specification of > this process and its results are outside the scope of > this document. > > 3. It MAY find an alternate route to the destination that > permits > SMTPUTF8. That route MAY be discovered by trying > alternate Mail eXchanger (MX) hosts (using preference > rules as specified in RFC 5321) or using other means > available to the SMTPUTF8-aware SMTP client. > > There was an earlier stage in which the text was the same, but > "increasing" was substituted for "decreasing". > > With an adjustment for what RFC 5321 actually allows, Pete > summarized these three cases as: > > 1. It MAY reject the message. > 2. If and only if it's a submission server, it MAY > something of its own choosing. > 3. It MAY try another MX. > > If we take RFC 5321 Section 2.2.3 into account, 3 can be > expanded to "It MAY try another MX if it decides to do so > based on the particular circumstances." > > > It is absolutely clear to us (myself, Joseph, and Pete) that > the WG intended to encourage letting submission servers fix up > messages if they knew how (case 2 above) and rejecting/bouncing > messages back to those servers so that they could fix things > (case 1 above). The third case is certainly reasonable as long > as it makes clear, somehow, that the circumstances are > important. Indeed, although it is a useful clarification that > RFC 5321 Section 2.2.3 may apply to this particular extension, > it actually adds nothing to what RFC 5321 would permit if this > document said nothing at all. > > So we probably need to fix the text (and to spend as little > time as possible making a decision). I think the following are > a complete list of options although, if someone has a better > idea, he or she should raise it. I hope that the WG can reach > consensus by mid-week (please make comments quickly so the WG > has a chance to discuss them if needed or, if you need more > time, say so). If there is no consensus on choice of text, > Joseph, Jiankang, Pete, and I will make a decision. If we have > to make a decision, we will consider both preferences for > particular approaches and remarks along the line of "do > whatever you like as long as you don't pick option 99". Note > that I'm not asking whether the WG still believes in correction > by submission servers, etc.: those issues are closed unless > someone comes up with a _really_ strong argument, presumably > strong enough to put all of this back into WG and IETF LC. We > are only trying to figure how to most clearly and accurately > reflect the WG's existing conclusions in the document. > > Note that whatever is chosen may still be fine-tuned > editorially. > > These options are deliberately in no particular order: > > A. Drop case 3 entirely to be consistent with the model of > putting nothing in these specs that is really part of the base > protocol (RFC 5321 in this case) and then clean up the text. > Note that this drops one piece of information that is not in > the base protocol, i.e., the WG's belief that SMTPUTF8 is an > extension to which Section 2.2.3 might reasonably be applied. > > ...Instead, if an SMTPUTF8-aware SMTP client > (sender) attempts to transfer an internationalized message > and encounters an SMTP server that does not support the > extension, it SHOULD make one of the following two choices. > These are listed in decreasing order of preference. > > 1. It MAY either reject the message during the SMTP > transaction or > accept the message and then generate and transmit a > notification of non-deliverability. Such notification > MUST be done as specified in RFC 5321 [RFC5321], RFC > 3464 [RFC3464], and RFC 6533 [RFC6533]. > > 2. If and only if the SMTPUTF8-aware SMTP client (sender) > is a > Message Submission Agent (MSA) [RFC6409] [RFC5598], it > MAY choose its own way to deal with this scenario > according to the provisions of RFC 6409 [RFC6409] or its > future versions. However, the detailed specification of > this process and its results are outside the scope of > this document. > > Note the change from MUST to SHOULD because there is another > choice (the MX searching of RFC 5321 Section 2.2.3) out there. > It could just be left alone on the theory that whatever 5321 > says overrides whatever is said here. Or we could explain the > SHOULD, but that takes us back to three cases and... > > > B. We leave all three cases as above and come up with revised > text as needed to clarify both the order and fact that case 3 > isn't to be used unless the client has the information > (presumably out of band) that permits it to conform to the key > requirement in RFC 5321 Section 2.2.3. That requirement > (second paragraph of 2.2.3) starts: > > In particular, if an extension implies that the delivery > path normally supports special features of that extension, > and an intermediate SMTP system finds a next hop that does > not support the required extension, it MAY choose, based on > the specific extension and circumstances, to requeue the > message and try later and/or try an alternate MX host. > > Note that 2.2.3 goes on to impose additional requirements on > timeouts in that case. > > C. We conclude that the "preference" order doesn't actually > mean much in this case. From that point of view, option 2 > applies only if the client is a submission server, option 3 > applies only if the client has special additional information > or circumstances (information or circumstances that presumably > could override either of the other preference), and option 1 > applies otherwise. If we then turn the wording around a bit, > we would get something like (borrowing text from the above > where possibe)... > > ...Instead, if an SMTPUTF8-aware SMTP client > (sender) attempts to transfer an internationalized message > and encounters an SMTP server that does not support the > extension, the best action for it to take depends on other > conditions. In particular: > > o If it is a Message Submission Agent (MSA) [RFC6409] > [RFC5598], it MAY choose its own way to deal with this > scenario using the wide discretion for changing addresses > or otherwise fixing up and transforming messages allowed > by RFC 6409. As long as the resulting message conforms > to the requirements of RFC 5321 (i.e., without the > SMTPUTF8 extension), the details of that transformation > are outside the scope of this document. > > o Otherwise, it SHOULD reject the message. As usual, this > can be done either by generating an appropriate reply > during the SMTP transaction or by accepting the message > and then generating and transmit a non-delivery > notification. If the latter choice is made, the > notification process MUST conform to the requirements of > RFC 5321 [RFC5321], RFC 3464 [RFC3464], and RFC 6533 > [RFC6533]. > > o As specified in RFC 5321 Section 2.2.3, an SMTP client > with additional information and/or knowledge of special > circumstances MAY choose to requeue the message and try > later and/or try an alternate MX host as specified in > that section. > > > D. Just about the same thing could be done, in somewhat more > terse form, by saying something like: > > "If the client is a submission agent [RFC6409], it SHOULD, > if possible, fix the message to be consistent with SMTP > requirements (in the absence of this extension) and resend > the transformed message. If it cannot or is not a > submission agent, it SHOULD reject or bounce the message > to give the user an opportunity to make her own > corrections. Alternately, if the client has sufficient > additional information to know that special circumstances > exist, it MAY examine hosts specified in DNS MX records > with equal or lower preferences as specified in RFC 5321 > Section 2.2.3." > > That approach assumes that the NDN requirements are covered in > other standards and need not be repeated here. Of course, they > could be listed if the WG prefers. > > john > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From klensin@jck.com Thu Feb 9 03:24:49 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D673621F86B0 for ; Thu, 9 Feb 2012 03:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3pdj8ibiFgZ for ; Thu, 9 Feb 2012 03:24:49 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 388CD21F85F8 for ; Thu, 9 Feb 2012 03:24:48 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RvS3d-0000X6-7d for ima@ietf.org; Thu, 09 Feb 2012 06:20:57 -0500 Date: Thu, 09 Feb 2012 06:24:42 -0500 From: John C Klensin To: EAI WG Message-ID: In-Reply-To: <897EFBFD97C27926F15BAB3C@PST.JCK.COM> References: <897EFBFD97C27926F15BAB3C@PST.JCK.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 Subject: [EAI] Proto-RFC 6531 Conclusion (was:Re: Question about AUTH48 text for 5336bis/ proto-RFC 6531) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 11:24:49 -0000 Hi. Ok, everyone who has spoken up has either identified option C as their first preference or as one of a set of more-or-less equal preferences. Some were concerned about "Otherwise". I had used it to avoid having to use several more words and am not sure I really see the preference implication, but have changed it. The following text is going to the RFC Editor and, subject to editorial revisions by them or changes made by the ADs, will appear in the document. Based on a note from the RFC Editor yesterday, this is the last outstanding issue for 5336bis/ proto-RFC 6531. ------------ ...Instead, if an SMTPUTF8-aware SMTP client (sender) attempts to transfer an internationalized message and encounters an SMTP server that does not support the extension, the best action for it to take depends on other conditions. In particular: o If it is a Message Submission Agent (MSA) [RFC6409] [RFC5598], it MAY choose its own way to deal with this scenario using the wide discretion for changing addresses or otherwise fixing up and transforming messages allowed by RFC 6409. As long as the resulting message conforms to the requirements of RFC 5321 (i.e., without the SMTPUTF8 extension), the details of that transformation are outside the scope of this document. o If is not an MSA or is an MSA and does not choose to transform the message the message to one that does not require the SMTPUTF8 extension, it SHOULD reject the message. As usual, this can be done either by generating an appropriate reply during the SMTP transaction or by accepting the message and then generating and transmit a non-delivery notification. If the latter choice is made, the notification process MUST conform to the requirements of RFC 5321 [RFC5321], RFC 3464 [RFC3464], and RFC 6533 [RFC6533]. o As specified in RFC 5321 Section 2.2.3, an SMTP client with additional information and/or knowledge of special circumstances MAY choose to requeue the message and try later and/or try an alternate MX host as specified in that section. ------------ A quick check on the RFC Editor's status pages indicates that our current status is: RFC-to-be (was) status 6530 4952bis Complete 6531 5336bis See above. Still needs formal AD signoff, but I think that is routine at this point. 6532 5335bis Complete 6533 5337bis RFC Editor processing comments from Chris Newman, awaiting signoff from Tony Hansen A separate note on next steps will follow soon. john From klensin@jck.com Thu Feb 9 04:15:31 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288B421F86C5 for ; Thu, 9 Feb 2012 04:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0zbhoFX96-r for ; Thu, 9 Feb 2012 04:15:30 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE4621F86EA for ; Thu, 9 Feb 2012 04:15:29 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RvSqg-0000bR-Qf for ima@ietf.org; Thu, 09 Feb 2012 07:11:38 -0500 Date: Thu, 09 Feb 2012 07:15:23 -0500 From: John C Klensin To: EAI WG Message-ID: 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 Subject: [EAI] EAI Next Steps: moving forward with POP, IMAP, and associated downgrade models X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 12:15:31 -0000 WG participants, My last note covered the status of the documents we have approved but that are not yet published. This one is an attempt to summarize where we are --and, more important, what people should be doing-- going forward (starting now). With the core documents out of the WG's hands, people should turn their attention to the POP, IMAP, and downgrade sets, including examining the current documents. The WG and authors of the IMAP and POP documents should think about how to modify those documents to accommodate multiple downgrade models, some of which might still be unspecified when the POP and IMAP documents are published. We are also looking for an I-D on the stripped-down downgrade option suggested by Arnt, John Leslie, and others and for author(s) for an I-D on the pseudo-DSN for "you don't get this message until you upgrade" option. As I indicated in an earlier note, I think those two, plus an updated version of pop-imap-downgrade, would form the core of the new strategy. That strategy is a hypothesis, not a conclusion: those with other ideas should speak up. Anyone who believes the WG needs a formal consensus call on moving in the direction of multiple downgrade options should say so (private notes to Joseph and/or myself would be sufficient; if it is desired, I'd prefer to just do a consensus call rather than spend time debating whether or not it is necessary). john From arnt@gulbrandsen.priv.no Thu Feb 9 04:58:50 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E0C21F8725 for ; Thu, 9 Feb 2012 04:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnXHo-oryegH for ; Thu, 9 Feb 2012 04:58:49 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id CC40321F8619 for ; Thu, 9 Feb 2012 04:58:44 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 38C89F8C548; Thu, 9 Feb 2012 12:58:42 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1328792321-31942-31942/10/10; Thu, 9 Feb 2012 12:58:41 +0000 Message-Id: <4F33C318.2040600@gulbrandsen.priv.no> Date: Thu, 9 Feb 2012 13:59:04 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: ima@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1 Subject: Re: [EAI] EAI Next Steps: moving forward with POP, IMAP, and associated downgrade models X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 12:58:50 -0000 On 02/09/2012 01:15 PM, John C Klensin wrote: > We are also looking for an I-D on the stripped-down downgrade > option suggested by Arnt, John Leslie, and others I'll happily write one. Arnt From arnt@gulbrandsen.priv.no Thu Feb 9 07:32:48 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E883021F8567 for ; Thu, 9 Feb 2012 07:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj-VDQqti2tT for ; Thu, 9 Feb 2012 07:32:44 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id E855D21F857F for ; Thu, 9 Feb 2012 07:32:42 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 1D8D4F8C58A; Thu, 9 Feb 2012 15:32:41 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1328801560-31942-31942/10/14; Thu, 9 Feb 2012 15:32:40 +0000 Message-Id: <4F33E730.5020105@gulbrandsen.priv.no> Date: Thu, 9 Feb 2012 16:33:04 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: ima@ietf.org References: <4F33C318.2040600@gulbrandsen.priv.no> In-Reply-To: <4F33C318.2040600@gulbrandsen.priv.no> Content-Type: multipart/mixed; boundary=------------020502000303080804040106 Subject: Re: [EAI] EAI Next Steps: moving forward with POP, IMAP, and associated downgrade models X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 15:32:49 -0000 --------------020502000303080804040106 Content-Type: text/plain; charset=iso-8859-1 On 02/09/2012 01:59 PM, Arnt Gulbrandsen wrote: > On 02/09/2012 01:15 PM, John C Klensin wrote: >> We are also looking for an I-D on the stripped-down downgrade >> option suggested by Arnt, John Leslie, and others > > I'll happily write one. I hate having TODOs and couldn't concentrate on programming anyway. My new desktop isn't properly set up for RFCs yet; appended is a protodraft. Arnt --------------020502000303080804040106 Content-Type: text/plain; name=protodraft-gulbrandsen-eai-simplifieddowngrade-00.txt Content-Disposition: attachment; filename=protodraft-gulbrandsen-eai-simplifieddowngrade-00.txt Network Working Group Arnt Gulbrandsen Internet-Draft February 2012 Intended Status: Proposed Standard EAI: Simplified POP/IMAP downgrading draft-gulbrandsen-eai-simpledowngrade-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft expires in August 2012 Gulbrandsen Expires August 2012 FF[Page 1] Internet-draft June 2011 Abstract This document specifies a method for IMAP and POP servers to serve EAI messages to non-EAI clients. The specification is simple, easy to implement and provides only rudimentary results. 1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Formal syntax is defined by [RFC5234]. Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. The five characters [...] means that something has been elided. 2. Overview It may happen that an EAI-ignorant IMAP or POP client opens a mailbox containing EAI messages, or even read EAI messages, for instance when a user has both EAI-capable and EAI-ignorant MUAs. This document specifies a way to present such messages to the client. It values simplicity of implementation over accuracy of representation, on the theory that anyone who wants accuracy should use EAI, and implementers' time should be used for implementing EAI proper. The server is assumed to be EAI-capable internally. When it needs to present an EAI message (the "real message") to a non-EAI client, it synthesizes a non-EAI message containing most of the information and presents that (the "synthetic message"). 3. Information preserved and lost The synthetic message is intended to convey the most important information to the user. Where information is lost, the user should see the message as incomplete rather than modified. The synthetic message is not intended to convey any EAI information to the MUA. Nothing parsable is added. Gulbrandsen Expires August 2012 FF[Page 2] Internet-draft June 2011 3.1 Email addresses Each regular EAI-specific email address in the 14 header fields listed below is replaced with an invalid email address whose display- name tells the user what happened. The format of the display-name is explicitly unspecified. Given an EAI address "Fred " or "Fred ". Irregular email addresses (that is, those to which the user cannot reply, such as "unknown:;") are silently excised. The affected header fields are Bcc, Cc, From, ReplyTo, ResentBcc, ResentCc, ResentFrom, ResentSender, ResentTo, ReturnPath, Sender and To. Any addresses present in other header fields are not regarded as addresses by this specification. 3.2 Mime values and comments Any mime field (whether in the message header or a bodypart header) which cannot be presented as-is to the client is silently excised along with its name. Given a field such as "Content-Disposition: attachment; filename=foo; signed-off-by=fred@EXAMPLE.com", the field is presented as "Content- Disposition: attachment; filename=foo". 3.3 Remaining header fields Any header field which cannot be presented to the client even after the modifications in sections 3.1 and 3.2 is silently excised. 4. IMAP-specific details IMAP offers a way to retrieve the message size without downloading it, RFC822.SIZE. RFC 3501 requires that this size be exactly correct. This specification relaxes that requirement: An IMAP server is permitted to send the size of the real message as RFC822.SIZE, even though the synthetic message's size differs. Gulbrandsen Expires August 2012 FF[Page 3] Internet-draft June 2011 4. POP-specific details None appear to be needed. 6. Security Considerations If the real message contains signed body parts, the synthetic message may contain an invalid signature. If any excised information is significant, then that information does not arrive at the recipient. Notably, the message-id, in-reference-to and/or references fields may be excised, which might cause to a lack of context when the recipient reads the message. 8. Acknowledgements John Levine and someone whose name I forget, maybe Ned Freed. 9. Normative References [RFC2119] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [RFC3501] Crispin, "Internet Message Access Protocol - Version 4rev1", RFC 3501, University of Washington, June 2003. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. 10. Author's Address Arnt Gulbrandsen Schweppermannstr. 8 D-81671 Muenchen Germany Fax: +49 89 4502 9758 Email: arnt@gulbrandsen.priv.no Gulbrandsen Expires August 2012 FF[Page 4] Internet-draft June 2011 (RFC Editor: Please delete everything after this point) Open Issues Only those noted as "fixme" in the text. Changes since -00 Gulbrandsen Expires August 2012 FF[Page 5] --------------020502000303080804040106-- From fujiwara@wide.ad.jp Thu Feb 9 09:00:01 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654F221E8034 for ; Thu, 9 Feb 2012 09:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvfPQL666LFU for ; Thu, 9 Feb 2012 09:00:00 -0800 (PST) Received: from sh.wide.ad.jp (sh.wide.ad.jp [IPv6:2001:200:0:1001::6]) by ietfa.amsl.com (Postfix) with ESMTP id CB0CD21E8030 for ; Thu, 9 Feb 2012 09:00:00 -0800 (PST) Received: from localhost (i114-185-21-46.s41.a013.ap.plala.or.jp [114.185.21.46]) (authenticated (0 bits)) by mail.wide.ad.jp (8.14.1+3.5Wbeta/8.14.1/smtpfeed 1.20) with ESMTP id q19GxveA027131 for ; Fri, 10 Feb 2012 01:59:59 +0900 (JST) Date: Fri, 10 Feb 2012 01:59:57 +0900 (JST) Message-Id: <20120210.015957.598552788702433724.fujiwara@wide.ad.jp> To: ima@ietf.org From: Kazunori Fujiwara In-Reply-To: <4F33E730.5020105@gulbrandsen.priv.no> References: <4F33C318.2040600@gulbrandsen.priv.no> <4F33E730.5020105@gulbrandsen.priv.no> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [EAI] EAI Next Steps: moving forward with POP, IMAP, and associated downgrade models X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 17:00:01 -0000 Starting with old document may work well. MIME encapsulation is easy. http://tools.ietf.org/html/draft-ietf-eai-downgrade-01 Or, another downgraded message may contain multi parts part1 (main part): message/delivery-status ? text/plain; charset=ascii ? Error message a message to update receiver's MUA part2: text/plain; charset=utf-8 header fields of the non-ascii message some of lines of the body of the non-ascii message part3: message/global? The original non-ascii message which may contain multipart # However RFC 2045 disallow nested encoding. > From: Arnt Gulbrandsen > EAI: Simplified POP/IMAP downgrading > draft-gulbrandsen-eai-simpledowngrade-00.txt > > "fred@EXAMPLE.com " or "Fred > ". Before you use 'invalid' TLD, you should reserve 'invalid' TLD even if you use it as an example. > 3.2 Mime values and comments > > Any mime field (whether in the message header or a bodypart header) > which cannot be presented as-is to the client is silently excised > along with its name. > > Given a field such as "Content-Disposition: attachment; filename=foo; > signed-off-by=fred@EXAMPLE.com", the field is presented as "Content- > Disposition: attachment; filename=foo". MIME header fields are easily converted by RFC 2231. > 3.3 Remaining header fields > > Any header field which cannot be presented to the client even after > the modifications in sections 3.1 and 3.2 is silently excised. Do you mean deleting 'Subject:' header fields which contains non-ASCII character? -- Kazunori Fujiwara From arnt@gulbrandsen.priv.no Thu Feb 9 11:23:19 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AC721E8032 for ; Thu, 9 Feb 2012 11:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEf5sU29irND for ; Thu, 9 Feb 2012 11:23:03 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1B33521F85DD for ; Thu, 9 Feb 2012 11:23:02 -0800 (PST) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 47E31F8C595; Thu, 9 Feb 2012 19:22:44 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1328815363-31942-31942/10/18; Thu, 9 Feb 2012 19:22:43 +0000 Message-Id: <4F341D1B.8080103@gulbrandsen.priv.no> Date: Thu, 9 Feb 2012 20:23:07 +0100 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 Mime-Version: 1.0 To: ima@ietf.org References: <4F33C318.2040600@gulbrandsen.priv.no> <4F33E730.5020105@gulbrandsen.priv.no> <20120210.015957.598552788702433724.fujiwara@wide.ad.jp> In-Reply-To: <20120210.015957.598552788702433724.fujiwara@wide.ad.jp> Content-Type: text/plain; charset=iso-8859-1 Subject: Re: [EAI] EAI Next Steps: moving forward with POP, IMAP, and associated downgrade models X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 19:23:20 -0000 On 02/09/2012 05:59 PM, Kazunori Fujiwara wrote: > Starting with old document may work well. MIME encapsulation is easy. > > http://tools.ietf.org/html/draft-ietf-eai-downgrade-01 Perhaps. I found it quick and easy to write what I wanted to say (using the source of a quite different draft for the boilerplate). >> From: Arnt Gulbrandsen >> EAI: Simplified POP/IMAP downgrading >> draft-gulbrandsen-eai-simpledowngrade-00.txt >> >> "fred@EXAMPLE.com " or "Fred >> ". > > Before you use 'invalid' TLD, you should reserve 'invalid' TLD > even if you use it as an example. RFC 2606 reserves it. >> 3.2 Mime values and comments >> >> Any mime field (whether in the message header or a bodypart header) >> which cannot be presented as-is to the client is silently excised >> along with its name. >> >> Given a field such as "Content-Disposition: attachment; filename=foo; >> signed-off-by=fred@EXAMPLE.com", the field is presented as "Content- >> Disposition: attachment; filename=foo". > > MIME header fields are easily converted by RFC 2231. Many things are easily done; the sum isn't easy any more. This draft is about specifying a minimal proposal. In that context, even easy conversions must be individually justified. >> 3.3 Remaining header fields >> >> Any header field which cannot be presented to the client even after >> the modifications in sections 3.1 and 3.2 is silently excised. > > Do you mean deleting 'Subject:' header fields which contains non-ASCII > character? Hm. That omission comes from my code, where subject is orthogonal to EAI. I had to take care of unlabelled 8-bit subject fields already (there are many in the wild), therefore I didn't need to add that for EAI. I guess it should go in. Thank you for your comments. Arnt From johnl@iecc.com Thu Feb 9 13:41:43 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE9421E8042 for ; Thu, 9 Feb 2012 13:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.663 X-Spam-Level: X-Spam-Status: No, score=-109.663 tagged_above=-999 required=5 tests=[AWL=1.536, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4l6MIfi112az for ; Thu, 9 Feb 2012 13:41:43 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 83FC721E8019 for ; Thu, 9 Feb 2012 13:41:41 -0800 (PST) Received: (qmail 67630 invoked from network); 9 Feb 2012 21:41:37 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 Feb 2012 21:41:37 -0000 Date: 9 Feb 2012 21:41:14 -0000 Message-ID: <20120209214114.47802.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <4F33E730.5020105@gulbrandsen.priv.no> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: arnt@gulbrandsen.priv.no Subject: Re: [EAI] EAI Next Steps: moving forward with POP, IMAP, and associated downgrade models X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 21:41:43 -0000 Looks pretty reasonable to me. Perhaps add a sentence allowing but not requiring servers to beautify headers if they want, e.g., turn UTF-8 into MIME, but stress that it is OPTIONAL and the primary goal here is to let the user know he or she has mail that the MUA can't handle. R's, John From wwwrun@rfc-editor.org Fri Feb 17 09:20:48 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F5121F85DA; Fri, 17 Feb 2012 09:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDDMQD42SvwH; Fri, 17 Feb 2012 09:20:48 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 372B821F85CF; Fri, 17 Feb 2012 09:20:48 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 51C6272E042; Fri, 17 Feb 2012 09:15:55 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120217171555.51C6272E042@rfc-editor.org> Date: Fri, 17 Feb 2012 09:15:55 -0800 (PST) Cc: ima@ietf.org, rfc-editor@rfc-editor.org Subject: [EAI] RFC 6530 on Overview and Framework for Internationalized Email X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 17:20:48 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6530 Title: Overview and Framework for Internationalized Email Author: J. Klensin, Y. Ko Status: Standards Track Stream: IETF Date: February 2012 Mailbox: john-ietf@jck.com, yangwooko@gmail.com Pages: 26 Characters: 64371 Obsoletes: RFC4952, RFC5504, RFC5825 I-D Tag: draft-ietf-eai-frmwrk-4952bis-12.txt URL: http://www.rfc-editor.org/rfc/rfc6530.txt Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published. [STANDARDS-TRACK] This document is a product of the Email Address Internationalization Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Fri Feb 17 09:21:00 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0247921F867D; Fri, 17 Feb 2012 09:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7f9LIVlImRA7; Fri, 17 Feb 2012 09:20:59 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 86A5B21F85C2; Fri, 17 Feb 2012 09:20:58 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B9A6C72E06D; Fri, 17 Feb 2012 09:16:05 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120217171605.B9A6C72E06D@rfc-editor.org> Date: Fri, 17 Feb 2012 09:16:05 -0800 (PST) Cc: ima@ietf.org, rfc-editor@rfc-editor.org Subject: [EAI] RFC 6531 on SMTP Extension for Internationalized Email X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 17:21:00 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6531 Title: SMTP Extension for Internationalized Email Author: J. Yao, W. Mao Status: Standards Track Stream: IETF Date: February 2012 Mailbox: yaojk@cnnic.cn, maowei_ietf@cnnic.cn Pages: 18 Characters: 40977 Obsoletes: RFC5336 I-D Tag: draft-ietf-eai-rfc5336bis-16.txt URL: http://www.rfc-editor.org/rfc/rfc6531.txt This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. [STANDARDS-TRACK] This document is a product of the Email Address Internationalization Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Fri Feb 17 09:21:37 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6352221E8038; Fri, 17 Feb 2012 09:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.538 X-Spam-Level: X-Spam-Status: No, score=-103.538 tagged_above=-999 required=5 tests=[AWL=1.538, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCoFeNEILv3Y; Fri, 17 Feb 2012 09:21:10 -0800 (PST) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3477321E801C; Fri, 17 Feb 2012 09:21:09 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 72F6F72E08A; Fri, 17 Feb 2012 09:16:16 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120217171616.72F6F72E08A@rfc-editor.org> Date: Fri, 17 Feb 2012 09:16:16 -0800 (PST) Cc: ima@ietf.org, rfc-editor@rfc-editor.org Subject: [EAI] RFC 6532 on Internationalized Email Headers X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 17:21:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6532 Title: Internationalized Email Headers Author: A. Yang, S. Steele, N. Freed Status: Standards Track Stream: IETF Date: February 2012 Mailbox: abelyang@twnic.net.tw, Shawn.Steele@microsoft.com, ned+ietf@mrochek.com Pages: 11 Characters: 22725 Obsoletes: RFC5335 Updates: RFC2045 I-D Tag: draft-ietf-eai-rfc5335bis-13.txt URL: http://www.rfc-editor.org/rfc/rfc6532.txt Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content. This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer- encodings on subtypes of "message/". [STANDARDS-TRACK] This document is a product of the Email Address Internationalization Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Fri Feb 17 09:23:51 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E03B21F86F2; Fri, 17 Feb 2012 09:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmeJ13wuJL+n; Fri, 17 Feb 2012 09:23:50 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C691421F86C9; Fri, 17 Feb 2012 09:23:49 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 1D13572E07E; Fri, 17 Feb 2012 09:18:57 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120217171857.1D13572E07E@rfc-editor.org> Date: Fri, 17 Feb 2012 09:18:57 -0800 (PST) Cc: ima@ietf.org, rfc-editor@rfc-editor.org Subject: [EAI] RFC 6533 on Internationalized Delivery Status and Disposition Notifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 17:23:51 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6533 Title: Internationalized Delivery Status and Disposition Notifications Author: T. Hansen, Ed., C. Newman, A. Melnikov Status: Standards Track Stream: IETF Date: February 2012 Mailbox: tony+eaidsn@maillennium.att.com, chris.newman@oracle.com, Alexey.Melnikov@isode.com Pages: 19 Characters: 37990 Obsoletes: RFC5337 Updates: RFC3461, RFC3464, RFC3798, RFC6522 I-D Tag: draft-ietf-eai-rfc5337bis-dsn-06.txt URL: http://www.rfc-editor.org/rfc/rfc6533.txt Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3464, RFC 6522) are presently limited to ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522. [STANDARDS-TRACK] This document is a product of the Email Address Internationalization Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From Shawn.Steele@microsoft.com Fri Feb 17 12:46:02 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E7E21E8020 for ; Fri, 17 Feb 2012 12:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukw88QWENfhi for ; Fri, 17 Feb 2012 12:46:02 -0800 (PST) Received: from AM1EHSOBE003.bigfish.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF7121E805F for ; Fri, 17 Feb 2012 12:46:01 -0800 (PST) Received: from mail99-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 17 Feb 2012 20:46:01 +0000 Received: from mail99-am1 (localhost [127.0.0.1]) by mail99-am1-R.bigfish.com (Postfix) with ESMTP id 997BCC04EF for ; Fri, 17 Feb 2012 20:46:01 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail99-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail99-am1 (localhost.localdomain [127.0.0.1]) by mail99-am1 (MessageSwitch) id 1329511556754909_19670; Fri, 17 Feb 2012 20:45:56 +0000 (UTC) Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.240]) by mail99-am1.bigfish.com (Postfix) with ESMTP id 957861A0045 for ; Fri, 17 Feb 2012 20:45:56 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 17 Feb 2012 20:45:50 +0000 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.168]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0247.005; Fri, 17 Feb 2012 12:45:33 -0800 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: RFC 6530 on Overview and Framework for Internationalized Email Thread-Index: AczttRYGGACT0IGZRTeC3HF7T3p2iw== Date: Fri, 17 Feb 2012 20:45:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [EAI] RFC 6530 on Overview and Framework for Internationalized Email X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 20:46:02 -0000 >> A new Request for Comments is now available in online RFC libraries. Yippee! From klensin@jck.com Fri Feb 17 13:24:53 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3252C11E8085 for ; Fri, 17 Feb 2012 13:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ypNThTroLcs for ; Fri, 17 Feb 2012 13:24:52 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 70D7011E8076 for ; Fri, 17 Feb 2012 13:24:52 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RyVEN-000JFs-UR; Fri, 17 Feb 2012 16:20:39 -0500 Date: Fri, 17 Feb 2012 16:24:39 -0500 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: <6681E50B8077EB2FA9908C7D@PST.JCK.COM> In-Reply-To: References: 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 Subject: Re: [EAI] RFC 6530 on Overview and Framework for Internationalized Email X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 21:24:53 -0000 --On Friday, February 17, 2012 20:45 +0000 Shawn Steele wrote: >>> A new Request for Comments is now available in online RFC >>> libraries. > > Yippee! Indeed. Now on to POP- IMAP- and one, two, or more Downgrade documents john From johnl@iecc.com Fri Feb 17 17:27:16 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1493F11E80BF for ; Fri, 17 Feb 2012 17:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.84 X-Spam-Level: X-Spam-Status: No, score=-109.84 tagged_above=-999 required=5 tests=[AWL=1.359, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNjdQTggRHlX for ; Fri, 17 Feb 2012 17:27:15 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id AC82911E80B7 for ; Fri, 17 Feb 2012 17:27:06 -0800 (PST) Received: (qmail 5138 invoked from network); 18 Feb 2012 01:27:03 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Feb 2012 01:27:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f3efe67.xn--3zv.k1202; i=johnl@user.iecc.com; bh=jchwgH5Eg5R6FtYsRdMcTikY52dZHr+pzWi6AGDsdQg=; b=QlkPk70ryerHd35LJmNF4P2ePmAlocTFLQFhW6HMxAXQpiy6QF3xXtJowwebVtw7RwnuVm701nm4dia3algtgeh0DTKsWiuDSPMdkUYOHb4UDdeHpe6ASYX9ctYCH3KZzKZBUvDd1zaWNzOcLbfklopxKXtUchaxJwdVbYunILk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f3efe67.xn--3zv.k1202; olt=johnl@user.iecc.com; bh=jchwgH5Eg5R6FtYsRdMcTikY52dZHr+pzWi6AGDsdQg=; b=JQOqS3WXCLfPVaFrSd3hedsa3twUu33VAfzdAwBkwfivLgwhxGv/RZYaUniBpj6aJdCWfPcsZPY36u8VPtkeIkmRHKiJYzz7nqKjIoIM/VypUnxFmj0IJB8NxFSGmIAJhmXQYIxOV71S47yIn9UNMOACYBscXlOHgPvbcowgxqs= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Feb 2012 01:26:41 -0000 Message-ID: <20120218012641.83933.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: <6681E50B8077EB2FA9908C7D@PST.JCK.COM> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] RFC 6530 on Overview and Framework for Internationalized Email X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 01:27:16 -0000 >Now on to POP- IMAP- and one, two, or more Downgrade documents Any interest in the draft I did about mailing lists? If not, I won't be heart broken. draft-ietf-eai-mailinglistbis-01.txt -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From klensin@jck.com Mon Feb 20 09:09:39 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189F921F86D8 for ; Mon, 20 Feb 2012 09:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep4EtSsXpD5S for ; Mon, 20 Feb 2012 09:09:38 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9361D21F8680 for ; Mon, 20 Feb 2012 09:09:30 -0800 (PST) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RzWfw-000PYZ-Da; Mon, 20 Feb 2012 12:05:20 -0500 X-Vipre-Scanned: 0700B1BF002C310700B30C-TDI Date: Mon, 20 Feb 2012 12:09:29 -0500 From: John C Klensin To: John Levine , ima@ietf.org Message-ID: In-Reply-To: <20120218012641.83933.qmail@joyce.lan> References: <20120218012641.83933.qmail@joyce.lan> 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 Subject: Re: [EAI] RFC 6530 on Overview and Framework for Internationalized Email X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 17:09:39 -0000 --On Saturday, February 18, 2012 01:26 +0000 John Levine wrote: >> Now on to POP- IMAP- and one, two, or more Downgrade >> documents > > Any interest in the draft I did about mailing lists? If not, > I won't be heart broken. > > draft-ietf-eai-mailinglistbis-01.txt Actually, considerable interest and that really should be our next agenda item -- either to move it forward or decide to not do so. My apologies: I've just been saying "finish the core documents, then move on to POP, IMAP, and the supporting materials" for so long that I typed without thinking about mailing lists. john From Shawn.Steele@microsoft.com Mon Feb 20 12:09:55 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B082021F8716 for ; Mon, 20 Feb 2012 12:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mnc7xnF6W9PM for ; Mon, 20 Feb 2012 12:09:54 -0800 (PST) Received: from VA3EHSOBE010.bigfish.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id D2AF621F870E for ; Mon, 20 Feb 2012 12:09:53 -0800 (PST) Received: from mail57-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Mon, 20 Feb 2012 20:09:48 +0000 Received: from mail57-va3 (localhost [127.0.0.1]) by mail57-va3-R.bigfish.com (Postfix) with ESMTP id 1B14F4A0209 for ; Mon, 20 Feb 2012 20:09:48 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzc89bhc857hzz1202hzz8275bhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail57-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail57-va3 (localhost.localdomain [127.0.0.1]) by mail57-va3 (MessageSwitch) id 1329768586176826_19909; Mon, 20 Feb 2012 20:09:46 +0000 (UTC) Received: from VA3EHSMHS006.bigfish.com (unknown [10.7.14.250]) by mail57-va3.bigfish.com (Postfix) with ESMTP id 1C8191A004E for ; Mon, 20 Feb 2012 20:09:46 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS006.bigfish.com (10.7.99.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 20 Feb 2012 20:09:41 +0000 Received: from TK5EX14MBXC141.redmond.corp.microsoft.com ([169.254.9.168]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0247.005; Mon, 20 Feb 2012 20:09:37 +0000 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: SMTPUTF8 implementations? Thread-Index: AczwC3QXhCeDSd/mTDueg46P4vgy4w== Date: Mon, 20 Feb 2012 20:09:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_E14011F8737B524BB564B05FF748464A5B00C91ATK5EX14MBXC141r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [EAI] SMTPUTF8 implementations? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 20:09:55 -0000 --_000_E14011F8737B524BB564B05FF748464A5B00C91ATK5EX14MBXC141r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdCBjdXJpb3VzLCBub3cgdGhhdCB0aGUgUkZDIGlzIHB1Ymxpc2hlZCwgYXJlIHRoZXJlIGFu eSBTTVRQVVRGOCBpbXBsZW1lbnRhdGlvbnMgYXJvdW5kIHRoYXQgY2FuIGJlIHBsYXllZCB3aXRo Pw0KDQotU2hhd24NCg0K76Oi76OQ76On76ObIO+jou+jo++jl++jlO+jmQ0KaHR0cDovL2Jsb2dz Lm1zZG4uY29tL3NoYXduc3RlDQoNCg== --_000_E14011F8737B524BB564B05FF748464A5B00C91ATK5EX14MBXC141r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNvZGUyMDAwOw0KCXBhbm9zZS0xOjIgMCA2IDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0IGN1 cmlvdXMsIG5vdyB0aGF0IHRoZSBSRkMgaXMgcHVibGlzaGVkLCBhcmUgdGhlcmUgYW55IFNNVFBV VEY4IGltcGxlbWVudGF0aW9ucyBhcm91bmQgdGhhdCBjYW4gYmUgcGxheWVkIHdpdGg/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi1TaGF3bjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q29kZTIwMDAiPu+jou+jkO+jp++jmyDvo6Lvo6Pvo5fvo5Tvo5k8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRw Oi8vYmxvZ3MubXNkbi5jb20vc2hhd25zdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj5odHRw Oi8vYmxvZ3MubXNkbi5jb20vc2hhd25zdGU8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_E14011F8737B524BB564B05FF748464A5B00C91ATK5EX14MBXC141r_-- From yaojk@cnnic.cn Mon Feb 20 17:08:01 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659F521F85A3 for ; Mon, 20 Feb 2012 17:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.299 X-Spam-Level: X-Spam-Status: No, score=-99.299 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXrxpBdbnR25 for ; Mon, 20 Feb 2012 17:08:00 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 1487421F8591 for ; Mon, 20 Feb 2012 17:07:56 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 21 Feb 2012 09:07:53 +0800 Message-ID: <83C462D2AE7A4E6FAD6DD6005B21BC3E@LENOVO47E041CF> From: "Jiankang YAO" To: "Shawn Steele" , References: Date: Tue, 21 Feb 2012 09:08:03 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A0_01CCF078.50DD1670" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [EAI] SMTPUTF8 implementations? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 01:08:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01A0_01CCF078.50DD1670 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 b25lIG9mIHRoZSB0b3AgY29tbWVyY2lhbCBlbWFpbCBzeXN0ZW0gc29mdHdhcmUgcHJvdmlkZXJz IGlzIGltcGxlbWVudGluZyBzbXRwdXRmOC4NCkkgdGhpbmsgdGhhdCBpdCB3aWxsIGJlIHJlYWR5 IGluIGEgZmV3IG1vbnRocy4NCg0KSmlhbmthbmcgWWFvDQogIC0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0gDQogIEZyb206IFNoYXduIFN0ZWVsZSANCiAgVG86IGltYUBpZXRmLm9yZyANCiAg U2VudDogVHVlc2RheSwgRmVicnVhcnkgMjEsIDIwMTIgNDowOSBBTQ0KICBTdWJqZWN0OiBbRUFJ XSBTTVRQVVRGOCBpbXBsZW1lbnRhdGlvbnM/DQoNCg0KICBKdXN0IGN1cmlvdXMsIG5vdyB0aGF0 IHRoZSBSRkMgaXMgcHVibGlzaGVkLCBhcmUgdGhlcmUgYW55IFNNVFBVVEY4IGltcGxlbWVudGF0 aW9ucyBhcm91bmQgdGhhdCBjYW4gYmUgcGxheWVkIHdpdGg/DQoNCg0KDQogIC1TaGF3bg0KDQoN Cg0KICDvo6Lvo5Dvo6fvo5sg76Oi76Oj76OX76OU76OZDQoNCiAgaHR0cDovL2Jsb2dzLm1zZG4u Y29tL3NoYXduc3RlDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICBJTUEgbWFpbGlu ZyBsaXN0DQogIElNQUBpZXRmLm9yZw0KICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ltYQ0K ------=_NextPart_000_01A0_01CCF078.50DD1670 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv bnRlbnQ9Ik1TSFRNTCA4LjAwLjYwMDEuMTkxOTAiPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZv bnQtZmFtaWx5OiBDYWxpYnJpOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IENvZGUy MDAwOw0KfQ0KQHBhZ2UgV29yZFNlY3Rpb24xIHtzaXplOiA4LjVpbiAxMS4waW47IG1hcmdpbjog MS4waW4gMS4waW4gMS4waW4gMS4waW47IH0NClAuTXNvTm9ybWFsIHsNCglNQVJHSU46IDBpbiAw aW4gMHB0OyBGT05ULUZBTUlMWTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIjsgRk9OVC1TSVpFOiAx MXB0DQp9DQpMSS5Nc29Ob3JtYWwgew0KCU1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZ OiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOyBGT05ULVNJWkU6IDExcHQNCn0NCkRJVi5Nc29Ob3Jt YWwgew0KCU1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOyBGT05ULVNJWkU6IDExcHQNCn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQt REVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpTUEFOLk1z b0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBt c28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRF WFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpTUEFO Lk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046 IHVuZGVybGluZTsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcg ew0KCUZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOyBDT0xPUjogd2luZG93dGV4 dDsgbXNvLXN0eWxlLXR5cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCi5Nc29DaHBEZWZhdWx0IHsN CglGT05ULUZBTUlMWTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIjsgbXNvLXN0eWxlLXR5cGU6IGV4 cG9ydC1vbmx5DQp9DQpESVYuV29yZFNlY3Rpb24xIHsNCglwYWdlOiBXb3JkU2VjdGlvbjENCn0N CjwvU1RZTEU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t PjwvSEVBRD4NCjxCT0RZIGxhbmc9RU4tVVMgbGluaz1ibHVlIGJnQ29sb3I9I2NjZThjZiB2TGlu az1wdXJwbGU+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPeWui+S9kz5vbmUgb2YgdGhlIHRvcCBj b21tZXJjaWFsIGVtYWlsJm5ic3A7c3lzdGVtIHNvZnR3YXJlIA0KcHJvdmlkZXJzIGlzIGltcGxl bWVudGluZyBzbXRwdXRmOC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPeWu i+S9kz5JIHRoaW5rIHRoYXQgaXQgd2lsbCBiZSByZWFkeSBpbiBhIGZldyANCm1vbnRocy48L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPeWui+S9kz48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPeWui+S9kz5KaWFua2FuZyBZYW88L0ZPTlQ+PC9E SVY+DQo8QkxPQ0tRVU9URSANCnN0eWxlPSJCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7 IFBBRERJTkctTEVGVDogNXB4OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7 IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+LS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0 IOWui+S9kzsgQkFDS0dST1VORDogI2U0ZTRlNDsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206 PC9CPiANCiAgPEEgdGl0bGU9U2hhd24uU3RlZWxlQG1pY3Jvc29mdC5jb20gDQogIGhyZWY9Im1h aWx0bzpTaGF3bi5TdGVlbGVAbWljcm9zb2Z0LmNvbSI+U2hhd24gU3RlZWxlPC9BPiA8L0RJVj4N CiAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+PEI+VG86PC9CPiA8QSB0aXRsZT1pbWFA aWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzppbWFAaWV0Zi5vcmciPmltYUBpZXRmLm9yZzwvQT4g PC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlNlbnQ6PC9CPiBUdWVz ZGF5LCBGZWJydWFyeSAyMSwgMjAxMiA0OjA5IA0KQU08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9O VDogOXB0IOWui+S9kyI+PEI+U3ViamVjdDo8L0I+IFtFQUldIFNNVFBVVEY4IA0KaW1wbGVtZW50 YXRpb25zPzwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJViBjbGFzcz1Xb3JkU2VjdGlv bjE+DQogIDxQIGNsYXNzPU1zb05vcm1hbD5KdXN0IGN1cmlvdXMsIG5vdyB0aGF0IHRoZSBSRkMg aXMgcHVibGlzaGVkLCBhcmUgdGhlcmUgYW55IA0KICBTTVRQVVRGOCBpbXBsZW1lbnRhdGlvbnMg YXJvdW5kIHRoYXQgY2FuIGJlIHBsYXllZCB3aXRoPzxPOlA+PC9POlA+PC9QPg0KICA8UCBjbGFz cz1Nc29Ob3JtYWw+PE86UD48L086UD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD4tU2hhd248 TzpQPjwvTzpQPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxPOlA+PC9POlA+PC9QPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb2RlMjAwMCI+76Oi 76OQ76On76ObIA0KICDvo6Lvo6Pvo5fvo5Tvo5k8TzpQPjwvTzpQPjwvU1BBTj48L1A+DQogIDxQ IGNsYXNzPU1zb05vcm1hbD48QSBocmVmPSJodHRwOi8vYmxvZ3MubXNkbi5jb20vc2hhd25zdGUi PjxTUEFOIA0KICBzdHlsZT0iQ09MT1I6IGJsdWUiPmh0dHA6Ly9ibG9ncy5tc2RuLmNvbS9zaGF3 bnN0ZTwvU1BBTj48L0E+PE86UD48L086UD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48TzpQ PjwvTzpQPjwvUD48L0RJVj4NCiAgPFA+DQogIDxIUj4NCg0KICA8UD48L1A+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+SU1BIG1haWxpbmcgDQogIGxp c3Q8QlI+PEEgaHJlZj0ibWFpbHRvOklNQUBpZXRmLm9yZyI+SU1BQGlldGYub3JnPC9BPjxCUj48 QSANCiAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWEiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1hPC9BPjxCUj48L0JMT0NLUVVP VEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_01A0_01CCF078.50DD1670-- From internet-drafts@ietf.org Mon Feb 27 03:08:36 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD1421F86B9; Mon, 27 Feb 2012 03:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.403 X-Spam-Level: X-Spam-Status: No, score=-102.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deb+opE-gyoq; Mon, 27 Feb 2012 03:08:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F24021F86AD; Mon, 27 Feb 2012 03:08:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120227110815.1690.70586.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2012 03:08:15 -0800 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-popimap-downgrade-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 11:08:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Email Address Internationalization Wo= rking Group of the IETF. Title : Post-delivery Message Downgrading for Internationalized = Email Messages Author(s) : Kazunori Fujiwara Filename : draft-ietf-eai-popimap-downgrade-04.txt Pages : 20 Date : 2012-02-27 The Email Address Internationalization (SMTPUTF8) extension allows UTF-8 characters in mail header fields. Upgraded POP and IMAP servers support internationalized email messages. If a POP/IMAP client does not support Email Address Internationalization, POP/IMAP servers cannot send Internationalized Email Headers to the client and cannot remove the message. To avoid the situation, this document describes a conversion mechanism for internationalized Email messages to be traditional message format. The purpose of post-delivery message downgrading is to enable POP/IMAP servers to deliver internationalized messages to traditional POP/IMAP clients. In the process, message elements requiring internationalized treatment can be removed or recoded and receivers can know they received messages containing such elements even if they cannot receive the elements themselves. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-popimap-downgrade-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-eai-popimap-downgrade-04.txt From Shawn.Steele@microsoft.com Wed Feb 29 15:43:49 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA90921F86F0 for ; Wed, 29 Feb 2012 15:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMvpVFm8t7gG for ; Wed, 29 Feb 2012 15:43:49 -0800 (PST) Received: from VA3EHSOBE008.bigfish.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id EA87321F86C9 for ; Wed, 29 Feb 2012 15:43:48 -0800 (PST) Received: from mail144-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Feb 2012 23:43:48 +0000 Received: from mail144-va3 (localhost [127.0.0.1]) by mail144-va3-R.bigfish.com (Postfix) with ESMTP id 34943120061 for ; Wed, 29 Feb 2012 23:43:48 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzc89bhc857hzz1202hzz8275bhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail144-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail144-va3 (localhost.localdomain [127.0.0.1]) by mail144-va3 (MessageSwitch) id 1330559026721422_11616; Wed, 29 Feb 2012 23:43:46 +0000 (UTC) Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.252]) by mail144-va3.bigfish.com (Postfix) with ESMTP id AAE6C20046 for ; Wed, 29 Feb 2012 23:43:46 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Feb 2012 23:43:43 +0000 Received: from TK5EX14MBXC139.redmond.corp.microsoft.com ([169.254.7.137]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0283.004; Wed, 29 Feb 2012 23:43:26 +0000 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: Experimental EAI accounts? Thread-Index: Acz3O7KBkR/C6TpQRROkbPUjaQK9sA== Date: Wed, 29 Feb 2012 23:43:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: multipart/alternative; boundary="_000_E14011F8737B524BB564B05FF748464A5B04D409TK5EX14MBXC139r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [EAI] Experimental EAI accounts? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 23:43:50 -0000 --_000_E14011F8737B524BB564B05FF748464A5B04D409TK5EX14MBXC139r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzb3J0IG9mIGdvdCBhbiBhbnN3ZXIgYWJvdXQgd2hldGhlciBhbnlvbmXigJlzIGltcGxlbWVu dGluZyBFQUkgKHllcyksIGJ1dCBkbyB0aGVyZSBoYXBwZW4gdG8gYmUgYW55IHRlc3Qgc2VydmVy cyB0aGF0IEkgZ2V0IGEgdGVzdCBlbWFpbCBhZGRyZXNzIGZyb20/ICAoSSBrbm93IHRoZXJlIGEg ZmV3IHBlb3BsZSBoYWQgbWFkZSBpbXBsZW1lbnRhdGlvbnMgZnJvbSB0aGUgb2xkIGV4cGVyaW1l bnRhbCBSRkNzKS4NCg0KLVNoYXduDQoNCu+jou+jkO+jp++jmyDvo6Lvo6Pvo5fvo5Tvo5kNCmh0 dHA6Ly9ibG9ncy5tc2RuLmNvbS9zaGF3bnN0ZQ0KDQo= --_000_E14011F8737B524BB564B05FF748464A5B04D409TK5EX14MBXC139r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEg TWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb2RlMjAwMDsNCglwYW5vc2UtMToyIDAgNiAwIDAgMCAw IDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAQ29kZTIwMDAiOw0KCXBhbm9z ZS0xOjIgMCA2IDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNvcnQgb2YgZ290IGFuIGFuc3dlciBhYm91 dCB3aGV0aGVyIGFueW9uZeKAmXMgaW1wbGVtZW50aW5nIEVBSSAoeWVzKSwgYnV0IGRvIHRoZXJl IGhhcHBlbiB0byBiZSBhbnkgdGVzdCBzZXJ2ZXJzIHRoYXQgSSBnZXQgYSB0ZXN0IGVtYWlsIGFk ZHJlc3MgZnJvbT8mbmJzcDsgKEkga25vdyB0aGVyZSBhIGZldyBwZW9wbGUgaGFkIG1hZGUgaW1w bGVtZW50YXRpb25zIGZyb20gdGhlIG9sZCBleHBlcmltZW50YWwgUkZDcykuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi1TaGF3bjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q29kZTIwMDAiPu+jou+jkO+jp++jmyDvo6Lvo6Pvo5fvo5Tvo5k8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vYmxv Z3MubXNkbi5jb20vc2hhd25zdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj5odHRwOi8vYmxv Z3MubXNkbi5jb20vc2hhd25zdGU8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_E14011F8737B524BB564B05FF748464A5B04D409TK5EX14MBXC139r_--