From ima-bounces@ietf.org Tue Aug 01 07:55:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7sqn-0003tz-Nq; Tue, 01 Aug 2006 07:55:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7sqm-0003tu-PD
	for ima@ietf.org; Tue, 01 Aug 2006 07:55:52 -0400
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7sqh-00060c-Ej
	for ima@ietf.org; Tue, 01 Aug 2006 07:55:52 -0400
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 0F6922596C7;
	Tue,  1 Aug 2006 13:54:08 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 14665-09; Tue,  1 Aug 2006 13:54:00 +0200 (CEST)
Received: from [192.168.0.109] (unknown [12.108.168.215])
	by eikenes.alvestrand.no (Postfix) with ESMTP id DF5432596C6;
	Tue,  1 Aug 2006 13:53:59 +0200 (CEST)
Message-ID: <44CF411A.3070408@alvestrand.no>
Date: Tue, 01 Aug 2006 13:55:06 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Tony Finch <dot@dotat.at>
Subject: Re: [EAI] RCPT TO and ALT-ADDRESS - do we have a consensus?
References: <24EAE5D4448B9D4592C6D234CBEBD59707531E46@stntexch03.cis.neustar.com>
	<op.tdhuqilc6hl8nm@clerew.man.ac.uk>
	<44CD9D3C.5020800@alvestrand.no>
	<Pine.LNX.4.64.0607311936290.2500@hermes-2.csi.cam.ac.uk>
In-Reply-To: <Pine.LNX.4.64.0607311936290.2500@hermes-2.csi.cam.ac.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: Charles Lindsey <chl@clerew.man.ac.uk>, ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Tony Finch wrote:
> On Mon, 31 Jul 2006, Harald Alvestrand wrote:
>
>   
>> As far as I read the Montreal minutes, the WG there decided to abandon the
>> idea of messing with the syntax inside the angle brackets.
>>     
>
> That's true at the 821 level but not the 822 level. That is, the sense of
> the room was that UTF8SMTP should use the existing ESMTP extension
> mechanisms for downgrade metadata (MAIL extension parameters) and not
> change the essential <path> syntax. This should minimize the changes
> necessary for 821 implementations. It does not affect the choice of syntax
> used in message headers etc. which will need some other way to express the
> downgrade metadata.
Thank you - this was not clear from the minutes. Can you suggest 
corrected/clarified text for the minutes?

(I've seen minutes be used 10 years later to determine what was decided 
at a meeting. They're important!)

                 Harald


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 01 09:16:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7u6J-0005R4-S2; Tue, 01 Aug 2006 09:15:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7u6I-0005QP-Px
	for ima@ietf.org; Tue, 01 Aug 2006 09:15:58 -0400
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7u6E-00039d-Ga
	for ima@ietf.org; Tue, 01 Aug 2006 09:15:58 -0400
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:45844)
	by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G7u64-0000GG-0R (Exim 4.54) for
	ima@ietf.org
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 01 Aug 2006 14:15:44 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk
	(hermes.cam.ac.uk)
	with local-esmtp id 1G7u64-0002jZ-2e (Exim 4.54) for ima@ietf.org
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 01 Aug 2006 14:15:44 +0100
Date: Tue, 1 Aug 2006 14:15:44 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: ima@ietf.org
In-Reply-To: <44C9F47D.9070809@alvestrand.no>
Message-ID: <Pine.LNX.4.64.0608011412480.2500@hermes-2.csi.cam.ac.uk>
References: <44C9F47D.9070809@alvestrand.no>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Subject: [EAI] mailing lists and downgrade metadata
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

If downgrade metadata is not needed on recipient addresses, then mailing
lists do not need any special considerations. In particular, the list
manager does not need to worry about maintaining downgrade metadata for
list members.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 01 09:41:26 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7uUv-0000YQ-VM; Tue, 01 Aug 2006 09:41:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7uUv-0000YL-Dn
	for ima@ietf.org; Tue, 01 Aug 2006 09:41:25 -0400
Received: from lon-mail-4.gradwell.net ([193.111.201.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7uUs-0004Sd-KN
	for ima@ietf.org; Tue, 01 Aug 2006 09:41:25 -0400
Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk
	country=GB ident=postmaster^pop3$clerew*man&ac^uk)
	by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.231) id
	44cf57b3.fcb2.cb2 for ima@ietf.org; Tue,  1 Aug 2006 14:31:31 +0100
	(envelope-sender <chl@clerew.man.ac.uk>)
Received: from clerew.man.ac.uk (localhost [127.0.0.1])
	by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k71DVRoe023444
	for <ima@ietf.org>; Tue, 1 Aug 2006 14:31:28 +0100 (BST)
Date: Tue, 01 Aug 2006 14:31:27 +0100
To: "ima@ietf.org" <ima@ietf.org>
Subject: Re: [EAI] RCPT TO and ALT-ADDRESS - do we have a consensus?
References: <24EAE5D4448B9D4592C6D234CBEBD59707531E46@stntexch03.cis.neustar.com>
	<op.tdhuqilc6hl8nm@clerew.man.ac.uk>
	<44CD9D3C.5020800@alvestrand.no>
	<Pine.LNX.4.64.0607311936290.2500@hermes-2.csi.cam.ac.uk>
From: "Charles Lindsey" <chl@clerew.man.ac.uk>
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <op.tdlw6pjv6hl8nm@clerew.man.ac.uk>
In-Reply-To: <Pine.LNX.4.64.0607311936290.2500@hermes-2.csi.cam.ac.uk>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

On Mon, 31 Jul 2006 19:41:26 +0100, Tony Finch <dot@dotat.at> wrote:

> On Mon, 31 Jul 2006, Harald Alvestrand wrote:
>
>> As far as I read the Montreal minutes, the WG there decided to abandon  
>> the
>> idea of messing with the syntax inside the angle brackets.
>
> That's true at the 821 level but not the 822 level. That is, the sense of
> the room was that UTF8SMTP should use the existing ESMTP extension
> mechanisms for downgrade metadata (MAIL extension parameters) and not
> change the essential <path> syntax. This should minimize the changes
> necessary for 821 implementations. It does not affect the choice of  
> syntax
> used in message headers etc. which will need some other way to express  
> the
> downgrade metadata.

Yes, that makes good sense.

So <utf8@utf8:ascii@ascii>
or maybe <utf8@utf8:downgradeable>

will still appear in various headers, and will become the normal way for  
people to write down their email address on business-cards etc, and in  
Reply-To, and in some extended mailto URL. So users (with UTF8 capability)  
will expect to be able to copy or paste or click it into their MUAs and  
have the MUA figure out what to do with it.

Which was the third scenario I proposed to add to Harald's two.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 01 13:00:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7xbx-0003NA-Co; Tue, 01 Aug 2006 13:00:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7xbv-0003N4-BL
	for ima@ietf.org; Tue, 01 Aug 2006 13:00:51 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7tbV-0001B1-FD
	for ima@ietf.org; Tue, 01 Aug 2006 08:44:09 -0400
Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7sz1-0002XD-Cc
	for ima@ietf.org; Tue, 01 Aug 2006 08:04:26 -0400
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:58729)
	by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G7syi-00085Y-TW (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 01 Aug 2006 13:04:04 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1G7syh-0003ez-Qk (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 01 Aug 2006 13:04:03 +0100
Date: Tue, 1 Aug 2006 13:04:03 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Harald Alvestrand <harald@alvestrand.no>
Subject: Re: [EAI] RCPT TO and ALT-ADDRESS - do we have a consensus?
In-Reply-To: <44CF411A.3070408@alvestrand.no>
Message-ID: <Pine.LNX.4.64.0608011303080.2500@hermes-2.csi.cam.ac.uk>
References: <24EAE5D4448B9D4592C6D234CBEBD59707531E46@stntexch03.cis.neustar.com>
	<op.tdhuqilc6hl8nm@clerew.man.ac.uk> <44CD9D3C.5020800@alvestrand.no>
	<Pine.LNX.4.64.0607311936290.2500@hermes-2.csi.cam.ac.uk>
	<44CF411A.3070408@alvestrand.no>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: -2.2 (--)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

On Tue, 1 Aug 2006, Harald Alvestrand wrote:
> Tony Finch wrote:
> >
> > That's true at the 821 level but not the 822 level. That is, the sense of
> > the room was that UTF8SMTP should use the existing ESMTP extension
> > mechanisms for downgrade metadata (MAIL extension parameters) and not
> > change the essential <path> syntax. This should minimize the changes
> > necessary for 821 implementations. It does not affect the choice of syntax
> > used in message headers etc. which will need some other way to express the
> > downgrade metadata.
>
> Thank you - this was not clear from the minutes. Can you suggest
> corrected/clarified text for the minutes?

Are the sentences above not suitable?

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 01 18:49:32 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G833G-0007qA-3u; Tue, 01 Aug 2006 18:49:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G833E-0007q2-L6
	for ima@ietf.org; Tue, 01 Aug 2006 18:49:24 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7zuu-0006xo-VN
	for ima@ietf.org; Tue, 01 Aug 2006 15:28:36 -0400
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7zge-0004bi-5x
	for ima@ietf.org; Tue, 01 Aug 2006 15:13:54 -0400
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:35849)
	by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G7zgW-0002Zr-1d (Exim 4.54) for
	ima@ietf.org
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 01 Aug 2006 20:13:44 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk
	(hermes.cam.ac.uk)
	with local-esmtp id 1G7zgW-0004qR-Ej (Exim 4.54) for ima@ietf.org
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 01 Aug 2006 20:13:44 +0100
Date: Tue, 1 Aug 2006 20:13:44 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: ima@ietf.org
Message-ID: <Pine.LNX.4.64.0608012012250.2500@hermes-2.csi.cam.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: -2.3 (--)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Subject: [EAI] handling ACE addresses
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Is there an archive anywhere of the past discussions about the
difficulties of handling ACE local parts?

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Wed Aug 02 02:57:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G8Afg-0000w1-Qf; Wed, 02 Aug 2006 02:57:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Aff-0000sB-B7
	for ima@ietf.org; Wed, 02 Aug 2006 02:57:35 -0400
Received: from [159.226.7.146] (helo=cnnic.cn)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G8Afa-00047T-Kb
	for ima@ietf.org; Wed, 02 Aug 2006 02:57:35 -0400
Received: (eyou send program); Wed, 02 Aug 2006 14:57:18 +0800
Message-ID: <354501838.19167@cnnic.cn>
X-EYOUMAIL-SMTPAUTH: lee@cnnic.cn
Received: from unknown (HELO [159.226.203.56]) (127.0.0.1)
	by 127.0.0.1 with SMTP; Wed, 02 Aug 2006 14:57:18 +0800
Message-ID: <44D04CC8.9050006@cnnic.cn>
Date: Tue, 01 Aug 2006 23:57:12 -0700
From: Xiaodong Lee <lee@cnnic.cn>
Organization: CNNIC
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Tony Finch <dot@dotat.at>
Subject: Re: [EAI] handling ACE addresses
References: <354472617.17837@cnnic.cn>
In-Reply-To: <354472617.17837@cnnic.cn>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: lee@cnnic.cn
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

I think you might get answer from former discussion of IEA, which is not 
included in
this list.

-- 
-- Xiaodong LEE [The best answer is doing]
   +86-10-58813020 
   mailto:lee@cnnic.cn
   http://www.lixiaodong.cn



Tony Finch wrote:
> Is there an archive anywhere of the past discussions about the
> difficulties of handling ACE local parts?
>
> Tony.
>   

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Wed Aug 02 23:02:29 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G8TTZ-0007T6-VI; Wed, 02 Aug 2006 23:02:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G8TTY-0007SZ-3k
	for ima@ietf.org; Wed, 02 Aug 2006 23:02:20 -0400
Received: from [159.226.7.146] (helo=cnnic.cn)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G8TTU-00005Q-C3
	for ima@ietf.org; Wed, 02 Aug 2006 23:02:20 -0400
Received: (eyou send program); Thu, 03 Aug 2006 11:01:59 +0800
Message-ID: <354574119.21788@cnnic.cn>
X-EYOUMAIL-SMTPAUTH: lee@cnnic.cn
Received: from unknown (HELO [159.226.203.56]) (127.0.0.1)
	by 127.0.0.1 with SMTP; Thu, 03 Aug 2006 11:01:59 +0800
Message-ID: <44D16723.4020708@cnnic.cn>
Date: Thu, 03 Aug 2006 11:01:55 +0800
From: Xiaodong Lee <lee@cnnic.cn>
Organization: CNNIC
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: "ima@ietf.org" <ima@ietf.org>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b
Subject: [EAI] Minutes of EAI WG Montreal Meeting(Welcome comments)
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: lee@cnnic.cn
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Dear All,

This is the minutes of EAI Wg Montreal meeting, please check it, and note
the rough consensus in the end of this minutes.

Thanks a lot for Alexy Melnikov taking this minutes.

Regards!

*****************************
*****************************
The meeting has started with short review of WG status:
1)interim meeting in Beijing in June 2006
2)8 WG drafts, one new -00 (Mailing list draft)since the interim

1.1 Presentation:
John quickly talked about -framework-01.txt document. Changes since the
previous revision:
Added comments about PGP/SMIME/DKIM. PGP and S/MIME don't sign headers,
so they should not be affected by EAI, but DKIM is.
John also updated terminology used in the document.

1.2 Questions or Comments:
Ted: how EAI affects mailto IRI and IRI in general. Is this in scope for
the WG?
Tony Finch (in jabber): also vcards, ldap schemas....
John: Martin has asked to add some text to -framework.
Ted suggests to use new URI schema, as this is a major syntax change.
Philip Guenther: mail3
Philip: S/MIME messages containing RFC 2047 encoded word will have to
continue to use RFC 2047 in the future.
John: Sure. Text is welcomed.

2.1 Presentation:
John quickly presented Harald's document. There were only editorial
changes since the previous revision. No questions were asked about the
document.

2.2 Questions or Comments:
No.

3.1 Presentation:
Yao Jiankang presented -smtpext-00.txt draft.
Main changes since the previous revision
1). Refined the Mailbox Address Syntax definition
2). Changed the ESMTP name for the extension to be UTF8SMTP
Open issues:
1). Do we recommend to use SASLPrep (RFC 4013) for local part of an EAI
address?
2). EHLO keyword for the extension
3). Syntax of SMTP commands: where to put alternative address and what
is the exact syntax for MAIL FROM/RCPT TO after that)

4.1 Presentation:
After that Yao did live demo of sending EAI email (different cases from
Harald's draft) using extended qmail.
The demo implementation doesn't do mailing list related examples, but
authors are working on it.
The demo contained a bug: "Content-transfer-encoding: 8bit utf8", but
otherwise worked well.

4.2Questions or Comments:
Note that demo didn't exactly match the latest draft, but it will be
updated. In particular the demo was using a single parameter to carry
either alt-address or [old] atomic=yes semantics (as per rough consensus
at Beijing interim).
John commented that a single parameter versa 2 parameters is another
open issue.

Discussion about how to parse a single parameter followed in jabber
Chris (in jabber): I like the fact eaipara eliminates the silly state of
both ALT-ADDR and ATOMIC parameters. But it's badly named.

Ted: it seems that in Beijing there was an agreement to change from 2
parameters (for alt address and atomic) to 1 parameter. Why?
Yao: to avoid the silly state when both are present.
John: we need to get consensus on the change today.
John: disadvantage of a single parameter: the only way to distinguish
keyword from alt-address is by looking at @ sign. What happens if some
implementation misspells the keyword?
John: there is also a possible performance implication of the change.
Chris: I find the silly state to be a more serious design error than
John's concern about forward parsing.
Many (actually John agrees with them): Having a single parameter is a
good thing.

Pete: I'm still not clear on the difference between ATOMIC and the
absence of the parameter?
Ted: In the absence, it seems like it would mean you don't know that it
is downgradable, so bounce the message.

Suggestion to change "eaiparam=" to something like "downgrade=".

Randy: Why have an ATOMIC parameter at all? If its purpose is to permit
the RCPT TO address to be converted when ALT-ADDRESS is not supplied,
why can't the sender just do the conversion and use the converted
address as ALT-ADDRESS?
Many: We like that.
Ted: Would there be some clients that don't have code to downconvert
utf8 addresses? This is the only good justification for having "atomic".
John: We can have atomic flag in the submission server, so that the
client doesn't need the code to downconvert the address.
Tony Finch warns about importance of the user interface, specially
address books, mailto: urls ...
Tony Finch raises some concern of having a submission only extension: it
doesn't actually create less work for people, as most MSAs are also
MTAs, so the code is shared.

Pete: What about the change to put alternative address inside the <> of
the mail from/rcpt to? This requires changes to RFC 2821. Pete is
proposing that this move outside the angle brackets
Chris: Agree with Pete, I would rather reuse existing ESMTP parameter
parsing code.
[Poll]: the alt-address parameter outside of the <> (i.e. == separate
ESMTP parameter)
Consensus to move alt-address outside of the <>.

[Coming back to discussion about encoding atomic =yes or alt-address in
a single parameter]
Eric A.: we can put @ sign before a keyword to make it distinguishable
from an address
Pete: if we can agree to remove atomic, we don't need to decide on how
to encode keywords.
Many: agree.
[Poll]: eliminate atomic?
John: I want to give an argument I don't like. Only the receiving server
really knows its addresses.
Chris: We can not impose semantics on ASCII local parts without breaking
the current model. But we _could_ impose semantics on UTF-8 local parts
when we introduce them. I'd say we should impose as few such semantics
as possible, but having explicit downgrading rules makes sense to me.
Consensus to remove the atomic from MTAs.
Ted (with AD hat on): who is doing the draft for submission only atomic
parameter?
John/Randy: will do a draft on atomic in submission.
John/Randy: but we would prefer to not have the atomic anywhere.

5.1 Presentation
Nai-Wen Hsu presented "UTF8 Header" draft.
Major changes:
1). i-Email header was added
2). ABNF has changed
Pending changes:
Update ABNF to disallow UTF-8 in Message-ID and Received header
Open Issues:
1). alt-separator - currently using { }
2). name of the i-Email parameter

5.2 Qeustions or Comments:
Discussion (in jabber) about alt-separator has followed. '{' and '}' are
not "special" in RFC 2822, if a parser finds them in the domain part
(e.g. <local-part@domain{downgraded-local@downgraded-domain}>), it will
happily treat them as a part of the domain, but domain lookup later will
fail.
Tony Finch suggests ':', saying that Microsoft consuses ';' and ','.
Philip G.: how about nesting <>s for the downgrade?
Marcos.Sanz: utf8@utf8 [ascii@punycode] ?

6.1 Presentation
testing report (also by Nai-Wen Hsu).
Test based on Sendmail.
Different test cases:
1) downgrade envelope
2) downgrade headers (punicode in Received header, add i-Email header, etc.)
3). also tested mailing lists
Linux "mail" was used as EAI-aware client. Outlook Express as non
EAI-aware client
A simple EAI POP3 server was written in Perl.
Tested with CAPA UTF8 and without it
Issues:
1) May add-spec change? Should we use ESMTP argument for alt-address?
(no longer relavant due to todays discussions)
2) Recommend: alt-separator for mailing lists is the same as for
'utf8header'
3) EAI-parameter replaces Envelope from: can alt-address be from another
domain; interaction with DSN ESMTP extension, etc.
4). SPF: is EAI parameter restricted to the MTA domain? If not, how to
setup SPF?
5) Interaction with DKIM: downgrade/upgrade can break signatures
6.2 Questions or Comments:
No

7.1 Presentation:
Pete Resnick presented IMAP draft. Couple of offline comments were received.
Major Issues:
1) non extended LIST returning UTF-8 stuff? Will try to address in the
next revision
2) Does the server have to upgrade all messages in the mailstore?

7.2 Qeustions or Comments:
Philip: there is some complexity with server not willing to do upgrade
for *some* mailboxes. Can we eliminate this (all mailboxes are UTF8)?
There is performance issue for servers, e.g. calculating proper RFC822.SIZE

Chris: It was less effort to write the draft in a way that is UW
c-client compatible than to write the simpler always-upgrade design and
deal with the political fallout.
Cyrus: I still think a mode switch with a '* NOUTF8' response on select
for those mailboxes the server won't 'upgrade' is a simpler
implementation approach.
Chris: please suggest some text
John: "* NOUTF8" is also consistent with the principle that one should
design for the long term then work in transitions, rather than designing
kludges that one has to carry around forever.
Cyrus promised to write some text

8.1 Presentation:
Edmon Chung presented draft on EAI Mailing lists.
Draft philosophy: "mailing lists should not introduce any additional
protocol requirements for EAI"
Open issues:
1) Is it a requirement to obtain alt-addresses on mailing list expansion?
If yes, how to obtain them?
Different mailing list scenarios:
a) Pure case (only UTF-8 subscribers involved)
b) Mixed case (some members might not have alt-addresses)
2). "Downgrade Considerations for mailto URLs"
List-* headers are mostly using URIs, so they should be using IRIs. So
there is an issue of extending mailto: schema to allow for EAI.
3). Operational policy of requiring alt-address/ atomic info

8.2 Questions or Comments:
Ted: we can't require all addresses to be downgradable (e.g. if there is
a community of tai users exchanging email in tai - why do they need to
have alt-addresses?) Legislating human behaviour is impossible task.

Example problem: sender has non-downgradable address, some subscribers
have ascii-only addresses - is the message to be bounced?
William L.: if mail from was non downgradable, but the mailing list
rewrites MAIL FROM, bounce might not be needed.
Philip G.: EAI mailing list can help two groups of people to communicate
(one is ascii only, ther other is utf8 only)
Pete: is it realistic to expect that people are not going to have
algorithmically derivable ascii addresses?
John: it is difficult to prevent people from doing stupid things
(referring to previous Ted's comment about legislating human behavior)
John: needs to describe possible implementation options for "bounce non
downgradable sender addresses"

Ted: So the clear thing is that making a mailing list address with a
non-downgradable address is a bad idea.

Chris: Thought experiment: what if the mailing list simply replaced all
UTF-8 addresses with the list submission address?
Tony Finch: the problem posters might not be subscribers

It seems that there are many open issues with the draft. This document
is really hard.

9.1 Presentation:
No presentation for POP3 draft, only to recieve comments
9.2 Questions or Comments:
No comments in the room on Chris's POP3 draft.

Side conversation in jabber on non-atom email addresses. One example is
subaddressing <utf8+detail@domain.com>. Consensus that implementations
that support plus addressing must be able to decode punycode before
extracting subaddress.
This followed by a diffsicuin that punicode loses information, as it
uses normalization. Whatever EAI will end up using for encoding UTF-8
will have to be lossless.

10.1 Presentation:
Next presentation: Fujiwara report downgrade-01
Major changes:
1) Follow new header format, added i-Email header, etc.
2) Received header field is not allowed to contain UTF-8
Overview of the draft, 3 downgrade options
1) Don't downgrade headers (new?)
2) Downgrade headers
3). MIME encapsulation

10.2 Questions or Comments
Pete: why "Downgraded: To:" instead of "Downgraded-To:"?
Cyrus: many tools do grep on headers (include IMAP servers), so having
Downgrade-to: would work better for them.
Philip (rephrasing previous question): can we just check for 8-bit,
instead of requiring all implementations to check for UTF-8? The former
is certainly easier to do.
Chris: checking for UTF-8 is not hard (pasted some code into jabber).
Marcos.Sanz: First, it is a stateful check. Second the code does
necessary checks, but they are not sufficient for valid UTF-8.
Chris: There are three case: Message is standards compliant and has
UTF-8 headers. Message is standards compliant and has 7-bit headers
only. Message is not standards compliant. Treating the third case as
"Garbage In Garbage Out" (GIGO) is not a problem in my book. So the
UTF-8 test is necessary and sufficient, IMHO.
Marcos.Sanz: If the GIGO case can be ignored, then checking for the
highest bit set is sufficient and necessary, too.
Chris: true, except for any potential security issues with overlong
UTF-8 sequences.

John: Assume I have UTF-8 headers and a body part that is, itself,
CTE=foobar (a type you don't recognize). If I now encapsulate the whole
thing as base64, the multiple encoding rule is broken. You can't upgrade
CTE foobar to 8bit and then re-encode the whole business (as you could
in principle do with Base64) because you have never heard of foobar.
[Problem]: MIME-encapsulating is going to break nested encoding rules.

tlr: Downgrade can replace utf8-only address with MAIL FROM address,
which are not necessarily the same thing

William L.: Some ESMTP parameters (e.g. ORCPT) pass addresses,how do
utf8 addresses get encoded in them?
Chris: ORCPT has a tagged address: ORCPT=rfc822;encoded-addr. So we
could use ORCPT=eai;encoded-addr. Of course, the xtext encoding used by
ORCPT explicitly forbids 8-bit, we'd have to change that to permit UTF-8.

Comparison of different downgrade methods: MIME encapsulation preserves
all header information, but make information unreadable in old UAs.
There is also different cost associated with different methods.


At the end of the meeting Xiaodong has summarized the rough consensus on
outstanding issues for all docs:
1) ATOMIC parameter
Answer:agreement to remove it
2) Syntax for alt-address in the envelope
Answer: move it outside of bracket
3) Do we need new extended SMTP error codes for cover bouncing and
downgrade cases?
Answer:we don't need
4) Encapsulation Model issue: is it satisfactory?
Answer:Multiple issues with existing text, need to be discussed deeply
5) Consistent terminology
Answer: Every Author should update their draft within two weeks, if
necessary, and should keep consistent terminology with framework draft.

-- 
-- Xiaodong LEE [The best answer is doing]
   +86-10-58813020 
   mailto:lee@cnnic.cn
   http://www.lixiaodong.cn


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Mon Aug 07 16:35:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GABoe-0002wi-Iv; Mon, 07 Aug 2006 16:35:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GABod-0002wY-FN
	for ima@ietf.org; Mon, 07 Aug 2006 16:35:11 -0400
Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GABob-0002v2-1N
	for ima@ietf.org; Mon, 07 Aug 2006 16:35:11 -0400
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:47965)
	by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25)
	with esmtpa (EXTERNAL:fanf2) id 1GABoX-0008Ud-PW (Exim 4.54) for
	ima@ietf.org
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 07 Aug 2006 21:35:05 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk
	(hermes.cam.ac.uk)
	with local-esmtp id 1GABoX-0007rp-OM (Exim 4.54) for ima@ietf.org
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 07 Aug 2006 21:35:05 +0100
Date: Mon, 7 Aug 2006 21:35:05 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: ima@ietf.org
Message-ID: <Pine.LNX.4.64.0608072017420.5999@hermes-2.csi.cam.ac.uk>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED;
	BOUNDARY="1870870024-1285228341-1154982905=:5999"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Subject: [EAI] UTF8 and ESMTP extension parameters
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1870870024-1285228341-1154982905=:5999
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE

ESMTP extensions that want to have interesting values in their MAIL or
RCPT parameters generally use the xtext syntax to encode them. (I hope I
haven't missed any extensions that don't do this.) There are three uses of
xtext in ESMTP extension parameters: ORCPT, AUTH, and ENVID. Of these we
probably do not need to worry about ENVID, since it can remain ASCII-only,
the same as has been decided for Message-ID header fields.

The AUTH parameter [RFC2554] on MAIL FROM does not have any provision for
gatewaying between different message transport systems. However it is only
of use within a group of mutually authenticating MTAs so perhaps we can
punt and assume that such a group will be upgraded to UTF8 en masse, or
perhaps that when one of these gateways is downgrading that it knows
enough about these addresses to be able to downgrade them without further
information.

I think ORCPT is easier to handle within the framework of the existing
specifications, though there are some awkward areas.

I suggest that we should consider UTF8 addresses to be a different type
from ASCII addresses, i.e. that they use an addr-type tag of (say)
utf8smtp instead of rfc822. This means that we can use the DSN gatewaying
framework to preserve information about UTF8 addresses even when downgrade
occurs.

There are two interesting cases for the outbound message, one of which
might be removed from the specs. In both cases I think it makes sense for
the ORCPT parameter to contain just the original UTF8 recipient address,
without the downgrade metadata.

(1) A message is sent to a UTF8 address which is aliased to an ASCII
address, and the message gets downgraded during the second leg of its
journey. On the first leg,

  MAIL FROM:<fanf2@cam.ac.uk>
  RCPT TO:<d=F6t@dot=E4t.at>

On the second leg:

  MAIL FROM:<fanf2@cam.ac.uk>
  RCPT TO:<dot@dotat.at> ORCPT=3Dutf8smtp;d+f6t@dot+e4t.at

(2) A message is sent to a UTF8 address which does not have proper
UTF8SMTP infrastructure, so the message gets downgraded. (We might
not support this.)

  MAIL FROM:<fanf2@cam.ac.uk>
  RCPT TO:<d=F6t@dot=E4t.at> ALT-ADDRESS=3Ddot@dotat.at

After downgrade it is the same as before:

  MAIL FROM:<fanf2@cam.ac.uk>
  RCPT TO:<dot@dotat.at> ORCPT=3Dutf8smtp;d+f6t@dot+e4t.at

There are two problems with this model:

(a) RFC 3461 does not allow non-ASCII characters in an xtext

(b) the message/delivery-status content-type is restricted to 7bit
content transfer encoding

Is it worth updating the DSN specs to allow 8bit CTEs? Would we still have
to specify how to downgrade an 8bit DSN into 7bit? RFC2047 encoding? UTF7?
or something else?

We could define that 8bit DSNs are allowed within the UTF8SMTP network,
and then define how to downgrade 8bit DSNs to 7bit, including how to
downgrade UTF8 ORCPT parameters to 7bit.

Tony.
--=20
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE O=
R
GOOD.
--1870870024-1285228341-1154982905=:5999
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima

--1870870024-1285228341-1154982905=:5999--




From ima-bounces@ietf.org Wed Aug 09 17:31:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GAveL-0000JA-5n; Wed, 09 Aug 2006 17:31:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GAveH-0000H7-V7; Wed, 09 Aug 2006 17:31:33 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GAu7A-000483-9m; Wed, 09 Aug 2006 15:53:16 -0400
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1GAu4W-0001kB-5O; Wed, 09 Aug 2006 15:50:35 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 17F3E2ACA1;
	Wed,  9 Aug 2006 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1GAu41-0002fL-Qv; Wed, 09 Aug 2006 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1GAu41-0002fL-Qv@stiedprstage1.ietf.org>
Date: Wed, 09 Aug 2006 15:50:01 -0400
X-Spam-Score: -5.9 (-----)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: ima@ietf.org
Subject: [EAI] I-D ACTION:draft-ietf-eai-utf8headers-01.txt 
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Email Address Internationalization Working Group of the IETF.

	Title		: Internationalized Email Headers
	Author(s)	: J. Yeh
	Filename	: draft-ietf-eai-utf8headers-01.txt
	Pages		: 14
	Date		: 2006-8-9
	
Full internationalization of electronic mail requires not only the
capability to transmit non-ASCII content, to encode selected
information in specific header fields, and to use non-ASCII
characters in envelope addresses.  It also requires being able to
express those addresses and information based on them in mail header
fields.  This document specifies the use of Unicode encoded in UTF-8,
rather than ASCII, as the base form for Internet email header field
bodies.  This form is permitted in transmission only if authorized by
an SMTP extension, as specified in an associated specification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eai-utf8headers-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-eai-utf8headers-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-eai-utf8headers-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-8-9103119.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-eai-utf8headers-01.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-eai-utf8headers-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-8-9103119.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima

--NextPart--





From ima-bounces@ietf.org Thu Aug 10 21:08:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GBLW4-0000O1-Bw; Thu, 10 Aug 2006 21:08:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GBLW2-0000KN-TJ
	for ima@ietf.org; Thu, 10 Aug 2006 21:08:46 -0400
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBLW0-0006sE-Fq
	for ima@ietf.org; Thu, 10 Aug 2006 21:08:46 -0400
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:50663)
	by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25)
	with esmtpa (EXTERNAL:fanf2) id 1GBLVw-0006pq-05 (Exim 4.54) for
	ima@ietf.org
	(return-path <fanf2@hermes.cam.ac.uk>); Fri, 11 Aug 2006 02:08:40 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk
	(hermes.cam.ac.uk)
	with local-esmtp id 1GBLVv-0006SP-VV (Exim 4.54) for ima@ietf.org
	(return-path <fanf2@hermes.cam.ac.uk>); Fri, 11 Aug 2006 02:08:39 +0100
Date: Fri, 11 Aug 2006 02:08:39 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: ima@ietf.org
Message-ID: <Pine.LNX.4.64.0608110132420.6747@hermes-2.csi.cam.ac.uk>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED;
	BOUNDARY="1870870024-1000358717-1155258519=:6747"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Subject: [EAI] header (822) address syntax
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1870870024-1000358717-1155258519=:6747
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

One long-standing ugliness in the Internet email standards is the
difference between the 821 and 822 syntax for email addresses (even if you
ignore differences in where [CFWS] is permitted). Unfortunately the
current EAI drafts make the difference bigger not smaller. The reason some
of us suggested putting the downgrade information in the "path" part of
MAIL and RCPT commands in UTF8SMTP was to try and keep the envelope and
header syntax reasonably similar. However the WG has decided to minimize
the differences from ASCII SMTP, which is probably the right decision. So
I would like another way of minimizing the differences between envelope
and header which fits this decision.

At the moment, the UTF-8 header draft specifies addresses like

=09From: Tony Finch <d=C3=B6t@dot=C3=A4t.at{dot@dotat.at}>

Digression: A small nit: The spec allows whitespace within the {} but not
between the UTF8 domain and the { whereas the examples have no whitespace
inside the {} but do have whitespace where it isn't allowed.

I propose the following syntax, which keeps the primary UTF8 address and
the downgrade address separate (by analogy with the 821 layer), and which
only uses special characters for special purposes. {} are atext and so
should not be used for punctuation, so I am using [] instead.

=09mailbox =3D (utf8-name-addr / utf8-addr-spec) [downgrade]
=09downgrade =3D "[" ascii-addr-spec "]"

i.e. one of

=09From: Tony Finch <d=C3=B6t@dot=C3=A4t.at> [dot@dotat.at]
=09From: d=C3=B6t@dot=C3=A4t.at (Tony Finch) [dot@dotat.at]

The downgraded form could be

=09mailbox =3D (name-addr / addr-spec) [downgrade-comment]
=09downgrade-comment =3D "([" rfc2047-addr-spec "])"

where the latter part is the RFC 2047 encoding of the UTF8 address. The
([]) is a comment wrapping a [] bracketed address, so that it parses as a
comment but still has a distinctive form. For example,

=09From: Tony Finch <dot@dotat.at> ([=3D?utf-8?q?d=3DF6t@dot=3DA4t.at])
=09From: dot@dotat.at (Tony Finch) ([=3D?utf-8?q?d=3DF6t@dot=3DA4t.at])

This might get mangled into one of the following, which I think is OK.

=09From: Tony Finch "[=3D?utf-8?q?d=3DF6t@dot=3DA4t.at]" <dot@dotat.at>
=09From: dot@dotat.at (Tony Finch [=3D?utf-8?q?d=3DF6t@dot=3DA4t.at])

Note that this proposal makes the UTF8 header and downgraded ASCII header
forms look quite similar, and keeps the UTF8 email address easily
accessible.

Tony.
--=20
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE O=
R
GOOD.
--1870870024-1000358717-1155258519=:6747
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima

--1870870024-1000358717-1155258519=:6747--




From ima-bounces@ietf.org Mon Aug 14 11:31:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GCeP1-0002Qd-3m; Mon, 14 Aug 2006 11:30:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GCeP0-0002QY-7t
	for ima@ietf.org; Mon, 14 Aug 2006 11:30:54 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCeP0-000457-5O
	for ima@ietf.org; Mon, 14 Aug 2006 11:30:54 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GCeM0-0007IV-OL
	for ima@ietf.org; Mon, 14 Aug 2006 11:27:51 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Mon, 14 Aug 2006 16:27:46 +0100
Message-ID: <44E09667.8070704@isode.com>
Date: Mon, 14 Aug 2006 16:27:35 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ima@ietf.org
Content-Type: multipart/mixed; boundary="------------090004070003060603030608"
X-Spam-Score: -2.2 (--)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f
Subject: [EAI] New draft for allowing UTF-8 in SMTP responses
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

--------------090004070003060603030608
Content-type: text/plain; charset="us-ascii"



--------------090004070003060603030608
Content-type: message/rfc822; name="I-D ACTION:draft-melnikov-smtp-lang-05.txt"
Content-transfer-encoding: 7bit
Content-Disposition: inline;
	filename="I-D ACTION:draft-melnikov-smtp-lang-05.txt"

Return-Path: <i-d-announce-bounces@ietf.org>
Received: from rufus.isode.com (canine.isode.net [/var/run/lmtp 172.16.0.23])
	by canine.isode.net (Isode M-Box/11.4v0) with LMTP;
	Wed, 02 Aug 2006 20:51:27 +0100 (BST)
Received: from megatron.ietf.org (odin.ietf.org [156.154.16.145]) by
	rufus.isode.com via TCP (external) with ESMTP
	for <Alexey.Melnikov@isode.com>; Wed, 2 Aug 2006 20:51:18 +0100
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G8MjM-0005QH-Ky; Wed, 02 Aug 2006 15:50:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G8MjC-00052s-LE
	for i-d-announce@ietf.org; Wed, 02 Aug 2006 15:50:02 -0400
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8MjC-000058-8k
	for i-d-announce@ietf.org; Wed, 02 Aug 2006 15:50:02 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 3BBD832894
	for <i-d-announce@ietf.org>; Wed,  2 Aug 2006 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1G8MjC-00011W-2T
	for i-d-announce@ietf.org; Wed, 02 Aug 2006 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: 
From: Internet-Drafts@ietf.org
Message-Id: <E1G8MjC-00011W-2T@stiedprstage1.ietf.org>
Date: Wed, 02 Aug 2006 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Subject: I-D ACTION:draft-melnikov-smtp-lang-05.txt 
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: internet-drafts@ietf.org
List-Id: i-d-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:i-d-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
List-Post: <mailto:i-d-announce@ietf.org>
List-Help: <mailto:i-d-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:i-d-announce-request@ietf.org?subject=subscribe>
Errors-To: i-d-announce-bounces@ietf.org

--NextPart
Content-type: text/plain; charset="us-ascii"

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: SMTP Language Extension
	Author(s)	: M. Gahrns, A. Melnikov
	Filename	: draft-melnikov-smtp-lang-05.txt
	Pages		: 0
	Date		: 2006-8-2
	
The Simple Mail Transfer Protocol (RFC 2821) allows server responses to
include human-readable text that in many cases needs to be presented to
the user.  This document specifies a way for a client to negotiate which language the server should use when sending human-readable text. It also extends DSN format to include language field for the human-readable text.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melnikov-smtp-lang-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-melnikov-smtp-lang-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-melnikov-smtp-lang-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-type: Multipart/Alternative; boundary="OtherAccess"

--OtherAccess
Content-type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-8-2145035.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-melnikov-smtp-lang-05.txt

--OtherAccess
Content-type: Message/External-body; name="draft-melnikov-smtp-lang-05.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-8-2145035.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

--------------090004070003060603030608
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima

--------------090004070003060603030608--




From ima-bounces@ietf.org Mon Aug 14 12:09:37 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GCf0S-0007tf-F5; Mon, 14 Aug 2006 12:09:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GCf0R-0007tW-1z
	for ima@ietf.org; Mon, 14 Aug 2006 12:09:35 -0400
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCf0M-00071i-Nj
	for ima@ietf.org; Mon, 14 Aug 2006 12:09:35 -0400
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:52757)
	by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25)
	with esmtpa (EXTERNAL:fanf2) id 1GCf0C-0003hn-2r (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 14 Aug 2006 17:09:20 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1GCf0C-00057o-0i (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 14 Aug 2006 17:09:20 +0100
Date: Mon, 14 Aug 2006 17:09:20 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [Filtered!] [EAI] New draft for allowing UTF-8 in SMTP responses
In-Reply-To: <44E09667.8070704@isode.com>
Message-ID: <Pine.LNX.4.64.0608141658260.15599@hermes-2.csi.cam.ac.uk>
References: <44E09667.8070704@isode.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

This draft looks pretty good to me.

I think that the DSN section should be moved to a separate document. Both
the LANG extension and UTF8 email addresses need to extend the DSN format
to allow 8bit content transfer encodings, as I mentioned last week (URL
below). I don't know whether the DSN extension should be of the
just-send-8 kind, or whether it needs some kind of signalling and
downgrade, or just a 7bit encoding. I don't think the signalling can be
based on UTF8SMTP because DSNs are to be interpreted by MUAs after final
delivery, by which time SMTP signalling is too late. I hope just-send-8 is
OK, probably limited to just the original-recipient and diagnostic-code
fields.

http://www1.ietf.org/mail-archive/web/ima/current/msg00553.html

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Mon Aug 14 13:45:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GCgVZ-0000mS-Va; Mon, 14 Aug 2006 13:45:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GCgVY-0000mN-Nz
	for ima@ietf.org; Mon, 14 Aug 2006 13:45:48 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCgVX-0004Ux-9r
	for ima@ietf.org; Mon, 14 Aug 2006 13:45:48 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Mon, 14 Aug 2006 18:44:54 +0100
Message-ID: <44E0B67A.9080909@isode.com>
Date: Mon, 14 Aug 2006 18:44:26 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tony Finch <dot@dotat.at>
Subject: Re: [Filtered!] [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com>
	<Pine.LNX.4.64.0608141658260.15599@hermes-2.csi.cam.ac.uk>
In-Reply-To: <Pine.LNX.4.64.0608141658260.15599@hermes-2.csi.cam.ac.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Tony Finch wrote:

>This draft looks pretty good to me.
>
>I think that the DSN section should be moved to a separate document. Both
>the LANG extension and UTF8 email addresses need to extend the DSN format
>to allow 8bit content transfer encodings, as I mentioned last week (URL
>below).
>
Yes, I thought about this too.

>I don't know whether the DSN extension should be of the
>just-send-8 kind, or whether it needs some kind of signalling and
>downgrade, or just a 7bit encoding.
>
I am not entirely sure myself. I hope that charset parameter to the 
Content-Type header field would suffice.

>I don't think the signalling can be
>based on UTF8SMTP because DSNs are to be interpreted by MUAs after final
>delivery, by which time SMTP signalling is too late.
>
I agree.

>I hope just-send-8 is
>OK, probably limited to just the original-recipient and diagnostic-code
>fields.
>  
>
>http://www1.ietf.org/mail-archive/web/ima/current/msg00553.html
>
>Tony.
>  
>


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Mon Aug 14 13:55:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GCgf6-0004QR-HX; Mon, 14 Aug 2006 13:55:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GCgf5-0004QJ-3x
	for ima@ietf.org; Mon, 14 Aug 2006 13:55:39 -0400
Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCgf2-00052N-Qf
	for ima@ietf.org; Mon, 14 Aug 2006 13:55:39 -0400
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:44120)
	by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25)
	with esmtpa (EXTERNAL:fanf2) id 1GCgey-0007SW-TQ (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 14 Aug 2006 18:55:33 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1GCgey-0006m2-2k (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 14 Aug 2006 18:55:32 +0100
Date: Mon, 14 Aug 2006 18:55:32 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [Filtered!] [EAI] New draft for allowing UTF-8 in SMTP responses
In-Reply-To: <44E0B67A.9080909@isode.com>
Message-ID: <Pine.LNX.4.64.0608141848400.15599@hermes-2.csi.cam.ac.uk>
References: <44E09667.8070704@isode.com>
	<Pine.LNX.4.64.0608141658260.15599@hermes-2.csi.cam.ac.uk>
	<44E0B67A.9080909@isode.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: Tony Finch <dot@dotat.at>, ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

On Mon, 14 Aug 2006, Alexey Melnikov wrote:
>
> > I don't know whether the DSN extension should be of the just-send-8
> > kind, or whether it needs some kind of signalling and downgrade, or
> > just a 7bit encoding.

> I am not entirely sure myself. I hope that charset parameter to the
> Content-Type header field would suffice.

I don't think a charset parameter would be much use. Both UTF8SMTP and
LANG specify UTF-8 only. Also, this is a message/ subtype, and therefore
more similar to 822 headers than to a text/ subtype, and 8bit headers will
also be UTF-8 only. It would seem sensible to me to say that a 7bit C-T-E
implies ASCII and an 8bit C-T-E implies UTF-8.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Mon Aug 14 16:50:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GCjNy-0003TQ-2k; Mon, 14 Aug 2006 16:50:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GCjNx-0003TL-Im
	for ima@ietf.org; Mon, 14 Aug 2006 16:50:09 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCgPH-00043f-Mt
	for ima@ietf.org; Mon, 14 Aug 2006 13:39:19 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GCg9l-0000cW-JS
	for ima@ietf.org; Mon, 14 Aug 2006 13:23:19 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Mon, 14 Aug 2006 18:22:55 +0100
Message-ID: <44E0B14C.80808@isode.com>
Date: Mon, 14 Aug 2006 18:22:20 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
To: Yangwoo Ko <newcat@icu.ac.kr>
Subject: Re: [EAI] ORCPT / RFC3461
References: <Pine.LNX.4.62.0607211004500.11416@sokol.elan.net>
	<44C27ABE.5000704@isode.com> <44C43499.7080107@icu.ac.kr>
In-Reply-To: <44C43499.7080107@icu.ac.kr>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Spam-Score: -2.2 (--)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Yangwoo Ko wrote:

> At a first glance, ORCPT is flexible than most of existing email
> address slots.
> I guess we may use something like;
>
>    ORCPT=utf8smtp; utf8@idn ALT-ADDR=all-ASCII@domain

Yes, something like this would work. Sadly, RFC 3461 says:

|4.2 The ORCPT parameter to the ESMTP RCPT command
|
|   Due to limitations in the Delivery Status Notification format, the
|   value of the original recipient address prior to encoding as "xtext"
|   MUST consist entirely of printable (graphic and white space)
|   characters from the US-ASCII [4] repertoire.  If an addr-type is
|   defined for addresses which use characters outside of this
|   repertoire, the specification for that addr-type MUST define the
|   means of encoding those addresses in printable US-ASCII characters
|   when are then encoded as xtext.

So we should either remove this requirement or invent an US-ASCII 
encoding of the UTF-8 address.

> If we do this, then EAI downgrade procedure also needs to handle
> this if session downgrade is inevitable.

Right.

I wonder how existing implementations handle unrecognized <addr-type>s 
in ORCPT. I hope they are treating them as opaque strings.


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Mon Aug 14 16:54:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GCjSM-0004jf-6U; Mon, 14 Aug 2006 16:54:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GCjSL-0004jX-5g
	for ima@ietf.org; Mon, 14 Aug 2006 16:54:41 -0400
Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCjSI-0005kP-TC
	for ima@ietf.org; Mon, 14 Aug 2006 16:54:41 -0400
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:38327)
	by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25)
	with esmtpa (EXTERNAL:fanf2) id 1GCjS9-0001pN-Va (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 14 Aug 2006 21:54:29 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1GCjS9-0003cq-Nn (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 14 Aug 2006 21:54:29 +0100
Date: Mon, 14 Aug 2006 21:54:29 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [EAI] ORCPT / RFC3461
In-Reply-To: <44E0B14C.80808@isode.com>
Message-ID: <Pine.LNX.4.64.0608142153240.15599@hermes-2.csi.cam.ac.uk>
References: <Pine.LNX.4.62.0607211004500.11416@sokol.elan.net>
	<44C27ABE.5000704@isode.com> <44C43499.7080107@icu.ac.kr>
	<44E0B14C.80808@isode.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

On Mon, 14 Aug 2006, Alexey Melnikov wrote:
>
> I wonder how existing implementations handle unrecognized <addr-type>s in
> ORCPT. I hope they are treating them as opaque strings.

It looks like utf8smtp will be the second addr-type after rfc822, which is
slightly surprising. I would have thought there'd be something for x.400
gatewaying.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 15 05:03:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GCuq1-0004HD-VB; Tue, 15 Aug 2006 05:03:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GCuq1-0004H8-CW
	for ima@ietf.org; Tue, 15 Aug 2006 05:03:53 -0400
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCuq0-0004fa-36
	for ima@ietf.org; Tue, 15 Aug 2006 05:03:53 -0400
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 988022596C4;
	Tue, 15 Aug 2006 11:02:02 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 32271-09; Tue, 15 Aug 2006 11:01:56 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 8ED672596C3;
	Tue, 15 Aug 2006 11:01:56 +0200 (CEST)
Message-ID: <44E18DF1.7090808@alvestrand.no>
Date: Tue, 15 Aug 2006 02:03:45 -0700
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com>
In-Reply-To: <44E09667.8070704@isode.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Thoughts:

1) looks good.
2) I don't see an argument for selecting any language except the ones 
the server lists support for. That means that fallback can be a 
client-side matter, not a server-side; simpler server.
3) I'd format the new DSN field as "localized-diagnostic: fr;ce'st la 
vie" and say that multiple localized diagnostics are allowed.
That removes the problem of detaching the diagnostic from its language 
code, and makes it possible to give useful feedback in situations like 
Belgium where multiple languages have to be treated "equally".

Not an EAI WG matter for sure - but nice to see!


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 15 05:56:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GCves-0002rX-V4; Tue, 15 Aug 2006 05:56:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GCver-0002pV-Dm
	for ima@ietf.org; Tue, 15 Aug 2006 05:56:25 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCveq-0005ax-0e
	for ima@ietf.org; Tue, 15 Aug 2006 05:56:25 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Tue, 15 Aug 2006 10:56:21 +0100
Message-ID: <44E19A2F.2000607@isode.com>
Date: Tue, 15 Aug 2006 10:55:59 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Harald Alvestrand <harald@alvestrand.no>
Subject: Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com> <44E18DF1.7090808@alvestrand.no>
In-Reply-To: <44E18DF1.7090808@alvestrand.no>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Harald Alvestrand wrote:

> Thoughts:
>
> 1) looks good.
> 2) I don't see an argument for selecting any language except the ones 
> the server lists support for. That means that fallback can be a 
> client-side matter, not a server-side; simpler server.

Sounds good. Should I add (reword) an informative text on client side 
fallback?

> 3) I'd format the new DSN field as "localized-diagnostic: fr;ce'st la 
> vie" and say that multiple localized diagnostics are allowed.

Sure.

How about using "localized-diagnostic;fr: c'est la vie", to be similar 
to LDIF? (i.e. move the language tag to the name), or is ';' going to 
cause problems with parsers?

> That removes the problem of detaching the diagnostic from its language 
> code, and makes it possible to give useful feedback in situations like 
> Belgium where multiple languages have to be treated "equally".
>
> Not an EAI WG matter for sure - but nice to see!



_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 15 06:28:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GCwAE-0003Tc-U1; Tue, 15 Aug 2006 06:28:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GCwAD-0003TX-Ro
	for ima@ietf.org; Tue, 15 Aug 2006 06:28:49 -0400
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCwAC-0003Q2-Hl
	for ima@ietf.org; Tue, 15 Aug 2006 06:28:49 -0400
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id D0D232596C7;
	Tue, 15 Aug 2006 12:26:58 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 02495-02; Tue, 15 Aug 2006 12:26:54 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id F40432596C6;
	Tue, 15 Aug 2006 12:26:53 +0200 (CEST)
Message-ID: <44E1A1DA.9040601@alvestrand.no>
Date: Tue, 15 Aug 2006 03:28:42 -0700
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com> <44E18DF1.7090808@alvestrand.no>
	<44E19A2F.2000607@isode.com>
In-Reply-To: <44E19A2F.2000607@isode.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Alexey Melnikov wrote:
> Harald Alvestrand wrote:
>
>> Thoughts:
>>
>> 1) looks good.
>> 2) I don't see an argument for selecting any language except the ones 
>> the server lists support for. That means that fallback can be a 
>> client-side matter, not a server-side; simpler server.
>
> Sounds good. Should I add (reword) an informative text on client side 
> fallback?
makes sense - or just point to the ltru-matching doc and say "client's 
problem".
>
>> 3) I'd format the new DSN field as "localized-diagnostic: fr;ce'st la 
>> vie" and say that multiple localized diagnostics are allowed.
>
> Sure.
>
> How about using "localized-diagnostic;fr: c'est la vie", to be similar 
> to LDIF? (i.e. move the language tag to the name), or is ';' going to 
> cause problems with parsers?
makes sense to me to be ldif-compatible, but others will have to speak 
to the parsers.



_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 15 06:36:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GCwHy-0005pZ-NL; Tue, 15 Aug 2006 06:36:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GCwHy-0005pU-3j
	for ima@ietf.org; Tue, 15 Aug 2006 06:36:50 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCwHw-0004bs-MT
	for ima@ietf.org; Tue, 15 Aug 2006 06:36:50 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Tue, 15 Aug 2006 11:36:45 +0100
Message-ID: <44E1A3A8.1070305@isode.com>
Date: Tue, 15 Aug 2006 11:36:24 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tony Finch <dot@dotat.at>
Subject: Re: [EAI] ORCPT / RFC3461
References: <Pine.LNX.4.62.0607211004500.11416@sokol.elan.net>
	<44C27ABE.5000704@isode.com> <44C43499.7080107@icu.ac.kr>
	<44E0B14C.80808@isode.com>
	<Pine.LNX.4.64.0608142153240.15599@hermes-2.csi.cam.ac.uk>
In-Reply-To: <Pine.LNX.4.64.0608142153240.15599@hermes-2.csi.cam.ac.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Tony Finch wrote:

>On Mon, 14 Aug 2006, Alexey Melnikov wrote:
>  
>
>>I wonder how existing implementations handle unrecognized <addr-type>s in
>>ORCPT. I hope they are treating them as opaque strings.
>>    
>>
>
>It looks like utf8smtp will be the second addr-type after rfc822, which is
>slightly surprising. I would have thought there'd be something for x.400
>gatewaying.
>  
>
RFC 2156 section 3.1 defines "x400" addr-type.
Isode MTA (M-Switch) supports it..


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 15 07:41:23 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GCxIM-0007Nj-3B; Tue, 15 Aug 2006 07:41:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GCxIK-0007Ne-O7
	for ima@ietf.org; Tue, 15 Aug 2006 07:41:16 -0400
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCxIJ-00023H-Ee
	for ima@ietf.org; Tue, 15 Aug 2006 07:41:16 -0400
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id B86762596C7
	for <ima@ietf.org>; Tue, 15 Aug 2006 13:39:25 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP id 03992-03 for <ima@ietf.org>;
	Tue, 15 Aug 2006 13:39:20 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 903022596C6
	for <ima@ietf.org>; Tue, 15 Aug 2006 13:39:20 +0200 (CEST)
Message-ID: <44E1B2D5.8040105@alvestrand.no>
Date: Tue, 15 Aug 2006 04:41:09 -0700
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: EAI WG <ima@ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Subject: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

In draft-ietf-eai-downgrade-01 section 5, the editors have identified a 
design decision that the WG needs to take: Whether to use an 
encapsulation strategy or a conversion strategy when downgrading 
messages from an UTF8SMTP user to an ASCII user.

A few of us (editors + chairs) have had a discussion about this, and 
reached a proposed resolution:

- It is of paramount importance that ASCII users are able to interpret 
downgraded messages without special software. Therefore, a conversion 
approach MUST be used, and this will be documented in the next version.

- In some cases (MUAs that attach both to UTF8SMTP MTAs and ASCII MTAs, 
for instance), accurate reconstruction of the UTF8SMTP headers can 
provide some benefit to the user. One way of accomplishing this is by 
attaching a copy of the headers as they were before downgrading to the 
downgraded message, attached as a special (new) MIME body part. However, 
this also carries security risks, and makes an unpleasant irritation in 
pure ASCII user interfaces.
Edmun Chong has promised to write a separate draft that explores this 
approach.

Main point: Version -02 of the -downgrade- draft will document the 
header conversion approach (currently in section 5.3 of the draft) only.

Of course, no decision is final until consensus has been verified on the 
mailing list. So this is a proposal.
Please comment.

                  Harald, for the chairs


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 15 08:10:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GCxkL-000758-Pw; Tue, 15 Aug 2006 08:10:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GCxkK-00074n-Cx
	for ima@ietf.org; Tue, 15 Aug 2006 08:10:12 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCxkH-0004sz-UC
	for ima@ietf.org; Tue, 15 Aug 2006 08:10:12 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Tue, 15 Aug 2006 13:10:06 +0100
Message-ID: <44E1B988.8030609@isode.com>
Date: Tue, 15 Aug 2006 13:09:44 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tony Finch <dot@dotat.at>
Subject: Re: [EAI] ORCPT / RFC3461
References: <Pine.LNX.4.62.0607211004500.11416@sokol.elan.net>
	<44C27ABE.5000704@isode.com> <44C43499.7080107@icu.ac.kr>
	<44E0B14C.80808@isode.com>
	<Pine.LNX.4.64.0608142153240.15599@hermes-2.csi.cam.ac.uk>
	<44E1A3A8.1070305@isode.com>
	<Pine.LNX.4.64.0608151258530.15599@hermes-2.csi.cam.ac.uk>
In-Reply-To: <Pine.LNX.4.64.0608151258530.15599@hermes-2.csi.cam.ac.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Tony Finch wrote:

>On Tue, 15 Aug 2006, Alexey Melnikov wrote:
>  
>
>>RFC 2156 section 3.1 defines "x400" addr-type.
>>Isode MTA (M-Switch) supports it..
>>    
>>
>
>In that case http://www.iana.org/assignments/mail-parameters needs to be
>corrected.
>  
>
Good point.
I've just sent a message to iana and Ted Hardie regarding this.



_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 15 09:21:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GCyrk-0002p4-OM; Tue, 15 Aug 2006 09:21:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GCyri-0002oz-P1
	for ima@ietf.org; Tue, 15 Aug 2006 09:21:54 -0400
Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCyrg-00027r-FW
	for ima@ietf.org; Tue, 15 Aug 2006 09:21:54 -0400
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:33888)
	by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25)
	with esmtpa (EXTERNAL:fanf2) id 1GCyr7-0001ds-UJ (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 15 Aug 2006 14:21:17 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1GCyr7-0007q2-8q (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 15 Aug 2006 14:21:17 +0100
Date: Tue, 15 Aug 2006 14:21:17 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Harald Alvestrand <harald@alvestrand.no>
Subject: Re: [EAI] New draft for allowing UTF-8 in SMTP responses
In-Reply-To: <44E18DF1.7090808@alvestrand.no>
Message-ID: <Pine.LNX.4.64.0608151417520.15599@hermes-2.csi.cam.ac.uk>
References: <44E09667.8070704@isode.com> <44E18DF1.7090808@alvestrand.no>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

On Tue, 15 Aug 2006, Harald Alvestrand wrote:

> 3) I'd format the new DSN field as "localized-diagnostic: fr;ce'st la vie" and
> say that multiple localized diagnostics are allowed.
> That removes the problem of detaching the diagnostic from its language code,
> and makes it possible to give useful feedback in situations like Belgium where
> multiple languages have to be treated "equally".

The language in the diagnostic field was the one chosen by the sender of
the message and signalled via SMTP, and the extension doesn't allow for
more than one of those. As far as equal treatment of official languages is
concerned, that would be interpreted as a requirement on server operators
that they support all the languages, not a requirement on users that they
must see all languages.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 15 09:29:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GCyzB-0004rS-EE; Tue, 15 Aug 2006 09:29:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GCyzA-0004rI-KP
	for ima@ietf.org; Tue, 15 Aug 2006 09:29:36 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCxrq-0005TB-5a
	for ima@ietf.org; Tue, 15 Aug 2006 08:17:58 -0400
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GCxbP-00062z-B0
	for ima@ietf.org; Tue, 15 Aug 2006 08:01:01 -0400
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:46044)
	by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25)
	with esmtpa (EXTERNAL:fanf2) id 1GCxan-0004KT-0e (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 15 Aug 2006 13:00:21 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1GCxan-0007fO-5d (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 15 Aug 2006 13:00:21 +0100
Date: Tue, 15 Aug 2006 13:00:21 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [EAI] ORCPT / RFC3461
In-Reply-To: <44E1A3A8.1070305@isode.com>
Message-ID: <Pine.LNX.4.64.0608151258530.15599@hermes-2.csi.cam.ac.uk>
References: <Pine.LNX.4.62.0607211004500.11416@sokol.elan.net>
	<44C27ABE.5000704@isode.com> <44C43499.7080107@icu.ac.kr>
	<44E0B14C.80808@isode.com>
	<Pine.LNX.4.64.0608142153240.15599@hermes-2.csi.cam.ac.uk>
	<44E1A3A8.1070305@isode.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: -2.3 (--)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

On Tue, 15 Aug 2006, Alexey Melnikov wrote:
>
> RFC 2156 section 3.1 defines "x400" addr-type.
> Isode MTA (M-Switch) supports it..

In that case http://www.iana.org/assignments/mail-parameters needs to be
corrected.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 15 09:35:41 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GCz52-00069Z-T4; Tue, 15 Aug 2006 09:35:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GCz51-000688-Ba
	for ima@ietf.org; Tue, 15 Aug 2006 09:35:39 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCz51-0003Zr-9z
	for ima@ietf.org; Tue, 15 Aug 2006 09:35:39 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GCz2P-0007IC-AT
	for ima@ietf.org; Tue, 15 Aug 2006 09:32:59 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Tue, 15 Aug 2006 14:32:46 +0100
Message-ID: <44E1CCDF.1070702@isode.com>
Date: Tue, 15 Aug 2006 14:32:15 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tony Finch <dot@dotat.at>
Subject: Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com> <44E18DF1.7090808@alvestrand.no>
	<Pine.LNX.4.64.0608151417520.15599@hermes-2.csi.cam.ac.uk>
In-Reply-To: <Pine.LNX.4.64.0608151417520.15599@hermes-2.csi.cam.ac.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.2 (--)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Tony Finch wrote:

>On Tue, 15 Aug 2006, Harald Alvestrand wrote:
>  
>
>>3) I'd format the new DSN field as "localized-diagnostic: fr;ce'st la vie" and
>>say that multiple localized diagnostics are allowed.
>>That removes the problem of detaching the diagnostic from its language code,
>>and makes it possible to give useful feedback in situations like Belgium where
>>multiple languages have to be treated "equally".
>>    
>>
>The language in the diagnostic field was the one chosen by the sender of
>the message and signalled via SMTP, and the extension doesn't allow for
>more than one of those.
>
That is correct, but I don't see much harm in allowing for multiple 
languages in the DSN report.

>As far as equal treatment of official languages is
>concerned, that would be interpreted as a requirement on server operators
>that they support all the languages, not a requirement on users that they
>must see all languages.
>  
>


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 15 15:43:24 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD4oH-0007v1-IK; Tue, 15 Aug 2006 15:42:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD4oH-0007uv-3U
	for ima@ietf.org; Tue, 15 Aug 2006 15:42:45 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCznW-0007Yo-Dw
	for ima@ietf.org; Tue, 15 Aug 2006 10:21:38 -0400
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GCzk6-00086e-U8
	for ima@ietf.org; Tue, 15 Aug 2006 10:18:09 -0400
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 998FA2596C8;
	Tue, 15 Aug 2006 16:16:13 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 07539-05; Tue, 15 Aug 2006 16:16:08 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 2780A2596C7;
	Tue, 15 Aug 2006 16:16:08 +0200 (CEST)
Message-ID: <44E1D794.402@alvestrand.no>
Date: Tue, 15 Aug 2006 07:17:56 -0700
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: Tony Finch <dot@dotat.at>
Subject: Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com> <44E18DF1.7090808@alvestrand.no>
	<Pine.LNX.4.64.0608151417520.15599@hermes-2.csi.cam.ac.uk>
In-Reply-To: <Pine.LNX.4.64.0608151417520.15599@hermes-2.csi.cam.ac.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Tony Finch wrote:
> On Tue, 15 Aug 2006, Harald Alvestrand wrote:
>
>   
>> 3) I'd format the new DSN field as "localized-diagnostic: fr;ce'st la vie" and
>> say that multiple localized diagnostics are allowed.
>> That removes the problem of detaching the diagnostic from its language code,
>> and makes it possible to give useful feedback in situations like Belgium where
>> multiple languages have to be treated "equally".
>>     
>
> The language in the diagnostic field was the one chosen by the sender of
> the message and signalled via SMTP, and the extension doesn't allow for
> more than one of those. As far as equal treatment of official languages is
> concerned, that would be interpreted as a requirement on server operators
> that they support all the languages, not a requirement on users that they
> must see all languages.
Somehow I think that coupling the SMTP signalling with the DSN field is 
not a Good Thing.
People will want to do things like "hey, this message looks like it's in 
Russian, let's put the error message in Russian too" - and they 
shouldn't be barred from doing that if they want to, in my opinion.

Note (just thought of it).... if people want to multilingualize DSNs, 
the first thing they'll multilingualize is the first, text part... I 
have samples of that in my DSN collection....


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Wed Aug 16 06:03:06 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDIEL-0000OD-7p; Wed, 16 Aug 2006 06:02:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDIEK-0000O7-Md
	for ima@ietf.org; Wed, 16 Aug 2006 06:02:32 -0400
Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDIEH-00048F-1Z
	for ima@ietf.org; Wed, 16 Aug 2006 06:02:32 -0400
Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17])
	by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id
	k7GA2LRR006014; Wed, 16 Aug 2006 19:02:21 +0900 (JST)
Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp
	id 7102_4f2ebdd4_2d0e_11db_8d5b_0014221f2a2d;
	Wed, 16 Aug 2006 19:02:21 +0900
Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k7GA2Gbi006163; 
	Wed, 16 Aug 2006 19:02:21 +0900
Message-Id: <6.0.0.20.2.20060816114455.06794e30@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6J
Date: Wed, 16 Aug 2006 11:51:02 +0900
To: Harald Alvestrand <harald@alvestrand.no>, EAI WG <ima@ietf.org>
From: Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP
In-Reply-To: <44E1B2D5.8040105@alvestrand.no>
References: <44E1B2D5.8040105@alvestrand.no>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: 
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

At 20:41 06/08/15, Harald Alvestrand wrote:
>In draft-ietf-eai-downgrade-01 section 5, the editors have identified a design decision that the WG needs to take: Whether to use an encapsulation strategy or a conversion strategy when downgrading messages from an UTF8SMTP user to an ASCII user.
>
>A few of us (editors + chairs) have had a discussion about this, and reached a proposed resolution:
>
>- It is of paramount importance that ASCII users are able to interpret downgraded messages without special software. Therefore, a conversion approach MUST be used, and this will be documented in the next version.
>
>- In some cases (MUAs that attach both to UTF8SMTP MTAs and ASCII MTAs, for instance), accurate reconstruction of the UTF8SMTP headers can provide some benefit to the user. One way of accomplishing this is by attaching a copy of the headers as they were before downgrading to the downgraded message, attached as a special (new) MIME body part.

This would mean that overall, we would get a multipart even if
the original message wasn't multipart, and straight conversion
wouldn't produce multipart. I'd assume this would be fine,
because we can assume that multipart is widely deployed.
But I just wanted to mention it here.

>However, this also carries security risks,

What in particular? Some scenarios with one set of headers
being tweaked/cheated, but the other not?

>and makes an unpleasant irritation in pure ASCII user interfaces.

We wouldn't downgrade pure US-ASCII email anyway, would we?
Anything non-ASCII will irritate pure ASCII user interfaces
one way or another. So I don't get the point you wanted to
make here, sorry.

Regards,     Martin.

>Edmun Chong has promised to write a separate draft that explores this approach.
>
>Main point: Version -02 of the -downgrade- draft will document the header conversion approach (currently in section 5.3 of the draft) only.
>
>Of course, no decision is final until consensus has been verified on the mailing list. So this is a proposal.
>Please comment.
>
>                  Harald, for the chairs
>
>
>_______________________________________________
>IMA mailing list
>IMA@ietf.org
>https://www1.ietf.org/mailman/listinfo/ima


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp     


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Thu Aug 17 08:12:16 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDgik-0007jZ-LM; Thu, 17 Aug 2006 08:11:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDgik-0007jU-1C
	for ima@ietf.org; Thu, 17 Aug 2006 08:11:34 -0400
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDgid-0004c5-Hj
	for ima@ietf.org; Thu, 17 Aug 2006 08:11:34 -0400
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 3E1042596CB;
	Thu, 17 Aug 2006 14:09:35 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 16613-03; Thu, 17 Aug 2006 14:08:44 +0200 (CEST)
Received: from [172.28.60.169] (unknown [62.92.16.50])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 124332596BE;
	Thu, 17 Aug 2006 14:08:44 +0200 (CEST)
Message-ID: <44E45CBA.2030700@alvestrand.no>
Date: Thu, 17 Aug 2006 14:10:34 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: Re: [EAI] Proposal for decision, approach for downgrading in  UTF8SMTP
References: <44E1B2D5.8040105@alvestrand.no>
	<6.0.0.20.2.20060816114455.06794e30@localhost>
In-Reply-To: <6.0.0.20.2.20060816114455.06794e30@localhost>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: EAI WG <ima@ietf.org>
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Martin Duerst wrote:
> At 20:41 06/08/15, Harald Alvestrand wrote:
>   
>> In draft-ietf-eai-downgrade-01 section 5, the editors have identified a design decision that the WG needs to take: Whether to use an encapsulation strategy or a conversion strategy when downgrading messages from an UTF8SMTP user to an ASCII user.
>>
>> A few of us (editors + chairs) have had a discussion about this, and reached a proposed resolution:
>>
>> - It is of paramount importance that ASCII users are able to interpret downgraded messages without special software. Therefore, a conversion approach MUST be used, and this will be documented in the next version.
>>
>> - In some cases (MUAs that attach both to UTF8SMTP MTAs and ASCII MTAs, for instance), accurate reconstruction of the UTF8SMTP headers can provide some benefit to the user. One way of accomplishing this is by attaching a copy of the headers as they were before downgrading to the downgraded message, attached as a special (new) MIME body part.
>>     
>
> This would mean that overall, we would get a multipart even if
> the original message wasn't multipart, and straight conversion
> wouldn't produce multipart. I'd assume this would be fine,
> because we can assume that multipart is widely deployed.
> But I just wanted to mention it here.
>   
Yes.
>   
>> However, this also carries security risks,
>>     
>
> What in particular? Some scenarios with one set of headers
> being tweaked/cheated, but the other not?
>   
This was extensively discussed when we discussed the options for S/MIME 
signatures (some wanted to have the message sent twice, once in 
cleartext and once signed; it was pointed out that an attacker could 
modify the cleartext part and fool anyone who did not bother to decode 
the message).

I remember a similar discussion wrt Multipart/Alternative, but couldn't 
find that in the RFC's security considerations.

>> and makes an unpleasant irritation in pure ASCII user interfaces.
>>     
>
> We wouldn't downgrade pure US-ASCII email anyway, would we?
> Anything non-ASCII will irritate pure ASCII user interfaces
> one way or another. So I don't get the point you wanted to
> make here, sorry.
>   
An otherwise pure US-ASCII message sent from an UTF8SMTP address, with 
that address in the From: header, would have such a section added to it. 
I believe that will be a rather common scenario.
> Regards,     Martin.
Thanks for the feedback.


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Fri Aug 18 16:54:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GEBLD-0004uR-5V; Fri, 18 Aug 2006 16:53:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GEBLA-0004tx-PO; Fri, 18 Aug 2006 16:53:16 -0400
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GEBLA-0006nS-IC; Fri, 18 Aug 2006 16:53:16 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 53D4A26E12;
	Fri, 18 Aug 2006 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1GEALy-0006GR-7M; Fri, 18 Aug 2006 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1GEALy-0006GR-7M@stiedprstage1.ietf.org>
Date: Fri, 18 Aug 2006 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: ima@ietf.org
Subject: [EAI] I-D ACTION:draft-ietf-eai-downgrade-02.txt 
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Email Address Internationalization Working Group of the IETF.

	Title		: Downgrading mechanism for Email Address Internationalization (EAI)
	Author(s)	: Y. Yoneya, K. Fujiwara
	Filename	: draft-ietf-eai-downgrade-02.txt
	Pages		: 17
	Date		: 2006-8-18
	
Traditional mail systems handle only US-ASCII characters in SMTP
   envelope and mail headers.  The Email Address Internationalization
   (EAI) is implemented by allowing UTF-8 characters in SMTP envelope
   and mail headers.  To deliver Non-ASCII mail address through EAI
   incompliant environment, some sort of converting mechanism (i.e.
   downgrading) is required.  This document describes requirements for
   downgrading, SMTP Downgrading, SMTP DATA/Header Downgrading and
   implementation consideration

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eai-downgrade-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-eai-downgrade-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-eai-downgrade-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-8-18131656.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-eai-downgrade-02.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-eai-downgrade-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-8-18131656.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima

--NextPart--





From ima-bounces@ietf.org Sat Aug 19 04:01:26 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GELlC-0006jQ-58; Sat, 19 Aug 2006 04:00:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GELlB-0006jE-A1; Sat, 19 Aug 2006 04:00:49 -0400
Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GELl8-0008Oe-I4; Sat, 19 Aug 2006 04:00:49 -0400
Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17])
	by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id
	k7J80XVV010771; Sat, 19 Aug 2006 17:00:33 +0900 (JST)
Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp
	id 7d11_ca2f5b3c_2f58_11db_8b57_0014221f2a2d;
	Sat, 19 Aug 2006 17:00:32 +0900
Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k7J80QRA004889; 
	Sat, 19 Aug 2006 17:00:29 +0900
Message-Id: <6.0.0.20.2.20060818150743.097d4ec0@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6J
Date: Fri, 18 Aug 2006 16:30:51 +0900
To: Alexey Melnikov <alexey.melnikov@isode.com>, ima@ietf.org
From: Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: Re: [EAI] New draft for allowing UTF-8 in SMTP responses
In-Reply-To: <44E09667.8070704@isode.com>
References: <44E09667.8070704@isode.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
Cc: LTRU Working Group <ltru@ietf.org>
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Hello Alexey,

I have looked at the draft. I'm not totally familiar with
all the details of email transmission, but will comment
mostly from an LTRU perspective. I have cc'ed the LTRU
WG, because I think your draft makes a good usage example
for the work of the LTRU WG, and some people may be able
to provide more feedback.

At 00:27 06/08/15, Alexey Melnikov wrote:

>       Title           : SMTP Language Extension
>       Author(s)       : M. Gahrns, A. Melnikov
This list of authors and the one in the draft seem to be
out of sync, probably a clerical error?

>       Filename        : draft-melnikov-smtp-lang-05.txt
>       Pages           : 0
This seems to be some administrative error, too, probably
a tool that counts drafts without explicit page breaks as
0 pages (I'd understand 1 page, 0 is really weird).

>       Date            : 2006-8-2


Section 3: "It also recommends that server recognizes languges that
   have multiple different tags (for example "ru" and "rus")."

   This is a bad idea. RFC 3066, and its successor RFC 3066bis
   (draft-ietf-ltru-registry-14.txt, approved by the IESG and in
    operation) both make it very clear that for languages that
   have both two-letter and three-letter codes, only the two-letter
   codes are used.

Please update the reference to RFC 3066 to RFC3066bis.

For language fallback, I suggest you have a look at
http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-15.txt
(also IESG-approved). This gives you the (basic) "language-range" ABNF
construct that includes the "*" wildcard.

Also, it seems that the matching going on on the server when the
client issues a LANG command (e.g. in Example 5) is very close to
and can (and should) be described in terms of Section 3.4, Lookup,
of the above draft. The only difference I see is that Section 3.4
requires a solution (maybe default) in all cases, whereas in your
case, the default if no matching language is found is not i-default,
but "no change" or in other words, "previously selected language".


I think the discussion of mul and und is overkill. There is no
interoperability problem if the client uses 'mul', it is just
a language that's not supported. Suggesting, as in Example 2,
that the server has specific code for that issue is a bad idea,
it will tend to make the server more complex than necessary.


Somewhere in example 1, probably in the comment that starts with
"< Once the client changes...", you should say that the example
here doesn't show accents because they cannot be represented
in this format, but that accented characters, encoded in UTF-8,
would be present in the actual protocol exchange.


Note 1: This is in part overkill, and in part incorrect.
If you do fallback on the server, then you have to leave
the decision to the server (or the server programmer or
administrator). There is no a-priori difference between
the special prefixes i- and x- and two-letter and three-
letter prefixes. It's very well possible that for i-foo-bar
and i-foo-baz, there is a mutually intellegible i-foo on
the server. The server will most probably only have i-foo
if the mutual intellegibility is a reasonal assumption.
On the other hand, for some people, zh-Hans (Chinese
written in simplifed script) and zh-Hant (Chinese written
in traditional script) are not mutually intellegible,
and so it may be a bad idea to make "zh" available on
the server. I think that if you refer to the abovementioned
two drafts, that should be enough.

Aside: You could get rid of server-side fallbacks if you
could assume that the server can always send the complete
list of available languages. However, I think this would
be a bad idea, because a) there may be dozenz or hundreds
of languages, and just sending the list may present somewhat
of a scalability problem, and b) it may be much easier
computationally for the server to check for the existence
of a requested language (or it's fallback) than to list
all languages available (which may require an extensive
search for files in a large number of directories).


For the LANG command, you only allow one language.
You could extend that to use a language priority list,
but this is not really necessary, the client can
simulate a language priority list by using successive
requests until one of them is successful.

On the other hand, for the LANG parameter for the MAIL
command should allow a language priority list. The reason
for this is that (if my understanding is correct), this
parameter is passed on along the relay chain of SMTP servers,
and is supposed to go back to the original sender, and
using a list increases the chance that there is something
at the relevant server that can be understood by the
originator.

I'm also not completely clear on / happy with the following
paragraph:

>>>>
   If the message is relayed to another SMTP server that supports LANGUAGE
   ESMTP extension, the MTA acting as the client MUST check if the receiving
   MTA lists the language specified in lang-param ("requested language") in
   the list of supported language tags in LANGUAGE EHLO response.  If the
   receiving MTA either lists the requested language or doesn't list any
   language tag (i.e. the receiving MTA is unable to list languages it
   supports) the sender MUST issue LANG command for the requested language.
   After that, regardless of the result of LANG command, the client MTA MUST
   specify LANG parameter in MAIL command.
>>>>

After repeated reading, I think this is okay, but some clarification
might help. In particular, it should be pointed out that trying to
use the LANG command is done so that potential error messages in
this relay step can be sent back to the original sender in the
appropriate language if possible.

Also, on a first reading, I was thinking that if the desired language
wasn't available, the LANG parameter would no longer be used.
I think the reason for this misunderstanding is that the last two
lines come very late. I think it would be easier to understand if
the paragraph started out as follows:

   If the message is relayed to another SMTP server that supports the
   LANGUAGE ESMTP extension, the MTA acting as the client MUST do
   the following two things, in the following order:
   1) Attempt to set the language of server responses to the requested
      language(s).
   2) Independently of whether 1) is successful, use the LANG
      parameter on the MAIL command to transmit the requested
      language(s) to the next relay.

If you think more explanations and details for 1) are needed, they
should come after this list.


Regards,     Martin.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp     


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Mon Aug 21 11:08:26 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFBNN-0002n0-03; Mon, 21 Aug 2006 11:07:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFBNM-0002mm-6h; Mon, 21 Aug 2006 11:07:40 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GF8er-0001On-En; Mon, 21 Aug 2006 08:13:33 -0400
Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1GF8WN-0005nY-8E; Mon, 21 Aug 2006 08:04:51 -0400
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:44518)
	by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25)
	with esmtpa (EXTERNAL:fanf2) id 1GF8W2-0004nU-NM (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 21 Aug 2006 13:04:26 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1GF8W2-0002mK-5V (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 21 Aug 2006 13:04:26 +0100
Date: Mon, 21 Aug 2006 13:04:26 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: Re: [EAI] New draft for allowing UTF-8 in SMTP responses
In-Reply-To: <6.0.0.20.2.20060818150743.097d4ec0@localhost>
Message-ID: <Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>
References: <44E09667.8070704@isode.com>
	<6.0.0.20.2.20060818150743.097d4ec0@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: -2.3 (--)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: LTRU Working Group <ltru@ietf.org>, ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

On Fri, 18 Aug 2006, Martin Duerst wrote:
>
> For the LANG command, you only allow one language. You could extend that
> to use a language priority list, but this is not really necessary, the
> client can simulate a language priority list by using successive
> requests until one of them is successful.

The client knows which languages that the server supports (unless the
server can't enumerate them), so it can simply do any priority matching
within itself then choose the best match with one LANG command. Perhaps
the draft should clarify this.

The idea of using multiple LANG commands to implement a priority list is
really bad for latency. If the LANG command could be pipelined then you
could just issue a load of them in order of increasing priority, so the
last one to succeed would be the best match. But this might not be very
efficient on some servers.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 22 01:49:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFP7v-0002pc-6W; Tue, 22 Aug 2006 01:48:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFEGZ-0000SZ-Ke; Mon, 21 Aug 2006 14:12:51 -0400
Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GFECB-0001QC-H3; Mon, 21 Aug 2006 14:08:23 -0400
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=dk20050327; d=mindspring.com;
	b=h5sFbLg/FrPVMcjJ+8oWUot84Y3QdVOWqCbtczNXz0/Wx3kn1FEnGD7faXv848pV;
	h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [68.166.188.70] (helo=oemcomputer)
	by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34)
	id 1GFECA-0005A0-GR; Mon, 21 Aug 2006 14:08:18 -0400
Message-ID: <003401c6c54d$18765640$6501a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "LTRU Working Group" <ltru@ietf.org>
References: <44E09667.8070704@isode.com><6.0.0.20.2.20060818150743.097d4ec0@localhost>
	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
Date: Mon, 21 Aug 2006 11:10:26 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7af6e6a90c086875e11f11efb69192b565a350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 68.166.188.70
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
X-Mailman-Approved-At: Tue, 22 Aug 2006 01:48:38 -0400
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Hi -

as a technical contributor...

> From: "Tony Finch" <dot@dotat.at>
> To: "Martin Duerst" <duerst@it.aoyama.ac.jp>
> Cc: "Alexey Melnikov" <alexey.melnikov@isode.com>; "LTRU Working Group" <ltru@ietf.org>; <ima@ietf.org>
> Sent: Monday, August 21, 2006 5:04 AM
> Subject: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
...
> The client knows which languages that the server supports (unless the
> server can't enumerate them),
...

Or (if I read the draft correctly) if their tags won't all fit on one line.

I also think the statement in the draft that "for the purpose of this
document it is safe to treat all languages, whose tags starts with
primary language described in ISO 639-1 and ISO 639-2 (i.e. all 2
or 3 letters primary languages) as hierarchical" is incorrect
for languages for which multiple scripts are in common use.

Randy


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 22 08:37:49 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFVVH-0007Wt-7g; Tue, 22 Aug 2006 08:37:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFVVG-0007Wi-2y; Tue, 22 Aug 2006 08:37:10 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GFVVD-0002xc-5w; Tue, 22 Aug 2006 08:37:10 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Tue, 22 Aug 2006 13:36:59 +0100
Message-ID: <44EAFA49.2050605@isode.com>
Date: Tue, 22 Aug 2006 13:36:25 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com>
	<6.0.0.20.2.20060818150743.097d4ec0@localhost>
In-Reply-To: <6.0.0.20.2.20060818150743.097d4ec0@localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53
Cc: LTRU Working Group <ltru@ietf.org>, ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Martin Duerst wrote:

>Hello Alexey,
>
>I have looked at the draft. I'm not totally familiar with
>all the details of email transmission, but will comment
>mostly from an LTRU perspective. I have cc'ed the LTRU
>WG, because I think your draft makes a good usage example
>for the work of the LTRU WG, and some people may be able
>to provide more feedback.
>  
>
Thank you for your feedback Martin.
Draft draft-melnikov-smtp-lang-05.txt is a revision of a draft that 
expired in 2001 (before LTRU was chartered) and I haven't been following 
LTRU.

>At 00:27 06/08/15, Alexey Melnikov wrote:
>  
>
>>      Title           : SMTP Language Extension
>>      Author(s)       : M. Gahrns, A. Melnikov
>>    
>>
>This list of authors and the one in the draft seem to be
>out of sync, probably a clerical error?
>  
>
No. Mike Garhns written the original IMAP LANGUAGE extension, this 
document is based on it.

>>      Filename        : draft-melnikov-smtp-lang-05.txt
>>      Pages           : 0
>>    
>>
>This seems to be some administrative error, too, probably
>a tool that counts drafts without explicit page breaks as
>0 pages (I'd understand 1 page, 0 is really weird).
>  
>
I think you are right.

>>      Date            : 2006-8-2
>>    
>>
>Section 3: "It also recommends that server recognizes languges that
>   have multiple different tags (for example "ru" and "rus")."
>
>   This is a bad idea. RFC 3066, and its successor RFC 3066bis
>   (draft-ietf-ltru-registry-14.txt, approved by the IESG and in
>    operation) both make it very clear that for languages that
>   have both two-letter and three-letter codes, only the two-letter
>   codes are used.
>  
>
Ok, I've removed the paragraph.

>Please update the reference to RFC 3066 to RFC3066bis.
>  
>
Done.

>For language fallback, I suggest you have a look at
>http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-15.txt
>(also IESG-approved). This gives you the (basic) "language-range" ABNF
>construct that includes the "*" wildcard.
>
>Also, it seems that the matching going on on the server when the
>client issues a LANG command (e.g. in Example 5) is very close to
>and can (and should) be described in terms of Section 3.4, Lookup,
>of the above draft. The only difference I see is that Section 3.4
>requires a solution (maybe default) in all cases, whereas in your
>case, the default if no matching language is found is not i-default,
>but "no change" or in other words, "previously selected language".
>  
>
Ok, this change would require some editing work on my part. I've added 
to my todo list.

>I think the discussion of mul and und is overkill. There is no
>interoperability problem if the client uses 'mul', it is just
>a language that's not supported.
>
Ok, removed.

>Suggesting, as in Example 2,
>that the server has specific code for that issue is a bad idea,
>it will tend to make the server more complex than necessary._
>_
>
The server is actually [re-]using the same error code, but the error 
text might be different.
This is actually quite useful for debugging implementation errors. 
However SMTP implementations are not required to do that anyway.

>Somewhere in example 1, probably in the comment that starts with
>"< Once the client changes...", you should say that the example
>here doesn't show accents because they cannot be represented
>in this format, but that accented characters, encoded in UTF-8,
>would be present in the actual protocol exchange.*
>*
>
Done.

>Note 1: This is in part overkill, and in part incorrect.
>If you do fallback on the server, then you have to leave
>the decision to the server (or the server programmer or
>administrator). There is no a-priori difference between
>the special prefixes i- and x- and two-letter and three-
>letter prefixes. It's very well possible that for i-foo-bar
>and i-foo-baz, there is a mutually intellegible i-foo on
>the server. The server will most probably only have i-foo
>if the mutual intellegibility is a reasonable assumption.
>On the other hand, for some people, zh-Hans (Chinese
>written in simplifed script) and zh-Hant (Chinese written
>in traditional script) are not mutually intellegible,
>and so it may be a bad idea to make "zh" available on
>the server. I think that if you refer to the abovementioned
>two drafts, that should be enough.
>  
>
Thanks. I removed the note.

>Aside: You could get rid of server-side fallbacks if you
>could assume that the server can always send the complete
>list of available languages. However, I think this would
>be a bad idea, because a) there may be dozenz or hundreds
>of languages, and just sending the list may present somewhat
>of a scalability problem, and b) it may be much easier
>computationally for the server to check for the existence
>of a requested language (or it's fallback) than to list
>all languages available (which may require an extensive
>search for files in a large number of directories).*
>*
>
Agreed. The list of all available langues is not returned for the 
reasons you stated.

>For the LANG command, you only allow one language.
>You could extend that to use a language priority list,
>but this is not really necessary, the client can
>simulate a language priority list by using successive
>requests until one of them is successful.*
>*
>
Actually, the LANG command already allows for priority list.

>On the other hand, for the LANG parameter for the MAIL
>command should allow a language priority list. The reason
>for this is that (if my understanding is correct), this
>parameter is passed on along the relay chain of SMTP servers,
>and is supposed to go back to the original sender, and
>using a list increases the chance that there is something
>at the relevant server that can be understood by the
>originator.
>  
>
Ok, this is a valid point. I will try to do this in a future revision.

>I'm also not completely clear on / happy with the following
>paragraph:
>  
>
>   If the message is relayed to another SMTP server that supports LANGUAGE
>   ESMTP extension, the MTA acting as the client MUST check if the receiving
>   MTA lists the language specified in lang-param ("requested language") in
>   the list of supported language tags in LANGUAGE EHLO response.  If the
>   receiving MTA either lists the requested language or doesn't list any
>   language tag (i.e. the receiving MTA is unable to list languages it
>   supports) the sender MUST issue LANG command for the requested language.
>   After that, regardless of the result of LANG command, the client MTA MUST
>   specify LANG parameter in MAIL command.
>  
>
>
>After repeated reading, I think this is okay, but some clarification
>might help. In particular, it should be pointed out that trying to
>use the LANG command is done so that potential error messages in
>this relay step can be sent back to the original sender in the
>appropriate language if possible.
>  
>
I've clarified this, thanks.

>Also, on a first reading, I was thinking that if the desired language
>wasn't available, the LANG parameter would no longer be used.*
>*
>
Yes, that was my original intent. But this would change, if the draft is 
changed to allow for priority list.

>I think the reason for this misunderstanding is that the last two
>lines come very late. I think it would be easier to understand if
>the paragraph started out as follows:
>
>   If the message is relayed to another SMTP server that supports the
>   LANGUAGE ESMTP extension, the MTA acting as the client MUST do
>   the following two things, in the following order:
>   1) Attempt to set the language of server responses to the requested
>      language(s).
>   2) Independently of whether 1) is successful, use the LANG
>      parameter on the MAIL command to transmit the requested
>      language(s) to the next relay.
>
>If you think more explanations and details for 1) are needed, they
>should come after this list.
>  
>


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 22 12:35:37 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFZDY-0001VL-PZ; Tue, 22 Aug 2006 12:35:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFZDW-0001Ud-Qq; Tue, 22 Aug 2006 12:35:06 -0400
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GFZDV-0007Te-7q; Tue, 22 Aug 2006 12:35:06 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1GFZDU-000OVc-0m; Tue, 22 Aug 2006 12:35:04 -0400
Date: Tue, 22 Aug 2006 12:35:02 -0400
From: John C Klensin <klensin@jck.com>
To: Randy Presuhn <randy_presuhn@mindspring.com>,
	LTRU Working Group <ltru@ietf.org>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in
 SMTP responses
Message-ID: <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>
In-Reply-To: <003401c6c54d$18765640$6501a8c0@oemcomputer>
References: <44E09667.8070704@isode.com>
	<6.0.0.20.2.20060818150743.097d4ec0@localhost>
	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>
	<003401c6c54d$18765640$6501a8c0@oemcomputer>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

I've deferred comment on this draft to see what others think,
but now seems to be the time...

--On Monday, 21 August, 2006 11:10 -0700 Randy Presuhn
<randy_presuhn@mindspring.com> wrote:

> Hi -
> 
> as a technical contributor...
> 
>> From: "Tony Finch" <dot@dotat.at>
>> To: "Martin Duerst" <duerst@it.aoyama.ac.jp>
>> Cc: "Alexey Melnikov" <alexey.melnikov@isode.com>; "LTRU
>> Working Group" <ltru@ietf.org>; <ima@ietf.org> Sent: Monday,
>> August 21, 2006 5:04 AM
>> Subject: [Ltru] Re: [EAI] New draft for allowing UTF-8 in
>> SMTP responses
> ...
>> The client knows which languages that the server supports
>> (unless the server can't enumerate them),
> ...
> 
> Or (if I read the draft correctly) if their tags won't all fit
> on one line.

that is ok, because the basic statement is false in the general
case -- in a relay situation, which the draft does not appear to
completely analyze, the originating client (which is the only
system that really knows the user's language preferences, if it
does) may have no practical way to know the server's language
capability.

> I also think the statement in the draft that "for the purpose
> of this document it is safe to treat all languages, whose tags
> starts with primary language described in ISO 639-1 and ISO
> 639-2 (i.e. all 2 or 3 letters primary languages) as
> hierarchical" is incorrect for languages for which multiple
> scripts are in common use.

Yes.

Another issue you didn't mention is that, in an environment in
which the language negotiated runs right to left, it not clear
where all the pieces go.   Presumably, if this specification
doesn't change the syntax specified in 2821 (the examples in
this document imply that, but don't state it), we have

        Reply-line = Reply-code [ SP text ] CRLF

But, if "text" can run right to left, do extended reply codes go
at the beginning of the string (i.e., to the right) or do they
imply a separate subfield... noting that either raises all of
the BIDI issues simply because the Reply-code and SP are
required to be expressed in Western digits and ASCII characters.

Even if we can make this model work, I suggest it is the wrong
model.  I further suggest that the difficulties with the small,
inconvenient, cases, such as those above, are symptomatic of why
it is the wrong model.  

The issue of making the text of SMTP responses
language-appropriate has been recognized since RFC 821 was
written.  As with many other Internet protocols, the most
effective model is to use a single form on the wire and then
perform translations (of character sets, terminal information,
formats, and, yes, languages) at the endpoints.   The "rely on
the codes" requirement of 821 was, and is, part of that concern.
When the codes proved inadequate in practice, we extended the
codes, which was entirely consistent with that general model.

If a user needs to look at an SMTP reply message directly, then
I suggest that either there is a debugging case in action or the
relevant MUA is broken.  Debugging cases are easier with more
uniformity and simplicity, not more options.  

So I suggest that:

	(1) This draft be dropped in favor of an effort to make
	SMTP reply text easier to translate to other languages
	or generate-able from the codes.
	
	(2) Any server implementer who is concerned about
	internationalization -- and I think all of us should be
	-- should be generating extended reply codes.  If one
	were to adopt a LANG extension, I would suggest that it
	would make extended codes mandatory anyway.
	
	(3) We should look at the text associated with extended
	reply codes to be sure that the portions of those lines
	that are not boilerplate explanations are easily
	identified and extracted by automatic processes.  If we
	discover cases where that goal is not met, we should fix
	them.

With the latter two conditions in place, I believe the right
(and fairly simple) way to get an SMTP reply tailored to local
language needs would become:

	(i) MUA that receives the reply, or MTA that is about to
	deliver the reply to such an MUA, extracts the extended
	reply code and non-boilerplace, message-dependent,
	material from the "text" and discards the rest.
	
	(ii) The extended reply code is used to generate
	response text in the appropriate language, substituting
	the non-boilerplate elements as needed.  

While this requires the efforts in (1) - (3) above, it does not
require SMTP changes.  And the recipient systems can do the
right thing as dictated by their environments (which they should
do even if the text is more friendly to their usual practices).

SMTP is already too complicated.  Let's avoid adding more
complexity unless it is strictly necessary.  This is not.

    john



_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 22 13:05:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFZhF-00048m-89; Tue, 22 Aug 2006 13:05:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFZhD-00048h-QY
	for ima@ietf.org; Tue, 22 Aug 2006 13:05:47 -0400
Received: from lon-mail-4.gradwell.net ([193.111.201.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFZh9-0003to-4l
	for ima@ietf.org; Tue, 22 Aug 2006 13:05:47 -0400
Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk
	country=GB ident=postmaster#pop3&clerew*man^ac^uk)
	by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.231) id
	44eb3965.15cc8.803 for ima@ietf.org; Tue, 22 Aug 2006 18:05:41 +0100
	(envelope-sender <chl@clerew.man.ac.uk>)
Received: from clerew.man.ac.uk (localhost [127.0.0.1])
	by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k7MH5cra027317
	for <ima@ietf.org>; Tue, 22 Aug 2006 18:05:39 +0100 (BST)
To: ima@ietf.org
Subject: Re: [EAI] header (822) address syntax
References: <Pine.LNX.4.64.0608110132420.6747@hermes-2.csi.cam.ac.uk>
Message-ID: <op.teo23nl36hl8nm@clerew.man.ac.uk>
Date: Tue, 22 Aug 2006 18:05:37 +0100
From: "Charles Lindsey" <chl@clerew.man.ac.uk>
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
In-Reply-To: <Pine.LNX.4.64.0608110132420.6747@hermes-2.csi.cam.ac.uk>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

On Fri, 11 Aug 2006 02:08:39 +0100, Tony Finch <dot@dotat.at> wrote:


> 	mailbox = (utf8-name-addr / utf8-addr-spec) [downgrade]
> 	downgrade = "[" ascii-addr-spec "]"
>
> i.e. one of
>
> 	From: Tony Finch <döt@dotät.at> [dot@dotat.at]
> 	From: döt@dotät.at (Tony Finch) [dot@dotat.at]
>

Having been on holiday for 10 days, and just seen this, I am surprised to  
find that there has been no response to this proposal on the list.

It seems to have some merit, insofar as it is a less drastic change to the  
present syntax, and it would seem to permit CFWS in more reasonable  
places. I certainly think it is worth looking at (especially, as we still  
have not really decided on a precise syntax for the current proposal).

> The downgraded form could be
>
> 	mailbox = (name-addr / addr-spec) [downgrade-comment]
> 	downgrade-comment = "([" rfc2047-addr-spec "])"

OTOH, I share the general dislike for putting meaningful stuff in comments  
(though my arm is twistable, and it may be the only way to get a utf-8  
'for' field in a Received header).

> 	From: Tony Finch <dot@dotat.at> ([=?utf-8?q?d=F6t@dot=A4t.at])
> 	From: dot@dotat.at (Tony Finch) ([=?utf-8?q?d=F6t@dot=A4t.at])
>
> This might get mangled into one of the following, which I think is OK.
>
> 	From: Tony Finch "[=?utf-8?q?d=F6t@dot=A4t.at]" <dot@dotat.at>
> 	From: dot@dotat.at (Tony Finch [=?utf-8?q?d=F6t@dot=A4t.at])

Do such manglings actually occur in meatspace? They seem pretty ugly to me.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 22 13:10:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFZls-0006TH-UH; Tue, 22 Aug 2006 13:10:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFZls-0006TC-0c
	for ima@ietf.org; Tue, 22 Aug 2006 13:10:36 -0400
Received: from lon-mail-4.gradwell.net ([193.111.201.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFZlq-0004Mu-EG
	for ima@ietf.org; Tue, 22 Aug 2006 13:10:35 -0400
Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk
	country=GB ident=postmaster$pop3^clerew*man#ac^uk)
	by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.231) id
	44eb3a88.1524b.e3b; Tue, 22 Aug 2006 18:10:32 +0100
	(envelope-sender <chl@clerew.man.ac.uk>)
Received: from clerew.man.ac.uk (localhost [127.0.0.1])
	by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k7MHAUKB027615;
	Tue, 22 Aug 2006 18:10:32 +0100 (BST)
To: "Harald Alvestrand" <harald@alvestrand.no>, "EAI WG" <ima@ietf.org>
Subject: Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP
References: <44E1B2D5.8040105@alvestrand.no>
Message-ID: <op.teo3bslu6hl8nm@clerew.man.ac.uk>
Date: Tue, 22 Aug 2006 18:10:30 +0100
From: "Charles Lindsey" <chl@clerew.man.ac.uk>
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
In-Reply-To: <44E1B2D5.8040105@alvestrand.no>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: 
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

On Tue, 15 Aug 2006 12:41:09 +0100, Harald Alvestrand  
<harald@alvestrand.no> wrote:

> In draft-ietf-eai-downgrade-01 section 5, the editors have identified a  
> design decision that the WG needs to take: Whether to use an  
> encapsulation strategy or a conversion strategy when downgrading  
> messages from an UTF8SMTP user to an ASCII user.
>
> A few of us (editors + chairs) have had a discussion about this, and  
> reached a proposed resolution:
>
> - It is of paramount importance that ASCII users are able to interpret  
> downgraded messages without special software. Therefore, a conversion  
> approach MUST be used, and this will be documented in the next version.

Yes, I agree.
>
> - In some cases (MUAs that attach both to UTF8SMTP MTAs and ASCII MTAs,  
> for instance), accurate reconstruction of the UTF8SMTP headers can  
> provide some benefit to the user. One way of accomplishing this is by  
> attaching a copy of the headers as they were before downgrading to the  
> downgraded message, attached as a special (new) MIME body part. However,  
> this also carries security risks, and makes an unpleasant irritation in  
> pure ASCII user interfaces.

And I don't really like that. It will create multiparts where there were  
none before, and scammers will find some benefit in making the two  
versions different.

Whilst the ability to retain or reconstitute the Utf=8 form of an address  
is useful, I do not regard it as an _essential_ requirement of our project.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 22 19:24:35 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFfbP-0008Pr-Gx; Tue, 22 Aug 2006 19:24:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFfbO-0008Pf-5d; Tue, 22 Aug 2006 19:24:10 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GFcTF-0007rL-GQ; Tue, 22 Aug 2006 16:03:33 -0400
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1GFcEt-0000Xq-Mx; Tue, 22 Aug 2006 15:48:47 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1GFcEq-000PvO-Jk; Tue, 22 Aug 2006 15:48:40 -0400
Date: Tue, 22 Aug 2006 15:48:39 -0400
From: John C Klensin <klensin@jck.com>
To: Addison Phillips <addison@yahoo-inc.com>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in
 SMTP responses
Message-ID: <CA5C301C3FE7D5F20D5A3DBE@p3.JCK.COM>
In-Reply-To: <44EB4886.5010009@yahoo-inc.com>
References: <44E09667.8070704@isode.com>
	<6.0.0.20.2.20060818150743.097d4ec0@localhost>
	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>
	<003401c6c54d$18765640$6501a8c0@oemcomputer>
	<6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>
	<44EB4886.5010009@yahoo-inc.com>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: -2.0 (--)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
Cc: Randy Presuhn <randy_presuhn@mindspring.com>,
	LTRU Working Group <ltru@ietf.org>, ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org



--On Tuesday, 22 August, 2006 11:10 -0700 Addison Phillips
<addison@yahoo-inc.com> wrote:

> A few comments follow...
> 
> John C Klensin wrote:
>>> ...
>>>> The client knows which languages that the server supports
>>>> (unless the server can't enumerate them),
>>> ...
> 
> Enumerating languages can be difficult. Most locale systems
> are quite extensive, with hundreds of potential values
> available. The server would have to attempt to load resources
> in each and enumerate whether the resources were extant in the
> locale or not in order to build an accurate list. In practice,
> few languages are actually available, but the code to figure
> it out is not available either.

That is consistent with what I had assumed, and reinforces the
impression that this proposal is not a good idea.
 
>> Another issue you didn't mention is that, in an environment in
>> which the language negotiated runs right to left, it not clear
>> where all the pieces go.  
> 
> This is a common misperception. The logical order of the text
> is left-to-right until the [ SP text ] is reached. This text
> is rendered RTL, if appropriate to do so, up to the CRLF
> (which ends the RTL "run"). See http://www.w3.org/TR/CharMod
> and http://www.unicode.org/reports/tr9/

Exactly (!).    If I said that badly, I apologize, but I read
821/ 2821 as requiring a three digit code and the SP (in
left-to-right order) followed by "text".  The extended status
code stuff is specific about the text, but wasn't written
anticipating internationalization and is not required by the
proposed specification anyway.   And, to the best of my
knowledge, there is no standard requiring the used of W3C
CharMod or Unicore TR9 in Internet mail replies.

I believe that could be fixed for this spec, and even that it
wouldn't be hard to do.  But it is, IMO, evidence that the spec
is not completely worked out even if it were a good idea.

>> Even if we can make this model work, I suggest it is the wrong
>> model.  I further suggest that the difficulties with the
>> small, inconvenient, cases, such as those above, are
>> symptomatic of why it is the wrong model.  
> 
> The examples given are not very convincing. However... I tend
> to agree that this is the wrong model. The design of SMTP and
> other protocols is such that user-agents can present
> "friendly" messages (including localized messages) to end
> users. Almost no one interacts with SMTP servers directly.

Right

>> 	(1) This draft be dropped in favor of an effort to make
>> 	SMTP reply text easier to translate to other languages
>> 	or generate-able from the codes.
> 
> Allowing UTF-8 would still seem to be a Good Thing, since even
> boilerplate messages might need to include runtime data that
> is non-ASCII. Language negotiation is another issue.

Clearly, the EAI effort is going to need to deal, in some way,
with replies that contain non-ASCII addresses.  But, as you say,
that is a different issue from language negotiation.

>> 	(3) We should look at the text associated with extended
>> 	reply codes to be sure that the portions of those lines
>> 	that are not boilerplate explanations are easily
>> 	identified and extracted by automatic processes.  If we
>> 	discover cases where that goal is not met, we should fix
>> 	them.

> If extended reply codes permit the server to emit its own
> internal error messages which are not entirely standardized
> (i.e. boilerplate), then the user-agent may have not choice
> other than to render the string on to   the user. This is
> unsatisfactory.

I think that is what I said.   In the current situation, the
parts that are clearly non-boilerplate (going back to 821) are
situations in which the reply is expected to include an address
or part of one.  And I was suggesting only that those pieces
needed to be easily identified and parsed out.

>> 	(i) MUA that receives the reply, or MTA that is about to
>> 	deliver the reply to such an MUA, extracts the extended
>> 	reply code and non-boilerplace, message-dependent,
>> 	material from the "text" and discards the rest.
> 
> This works best if the message dependent material were clearly
> separate and in a machine-friendly format. This:
> 
>    9106 Invalid user name; user=nobody, domain=example.org
> 
> Is easier to deal with than:
> 
>    "9106 Invalid user name 'nobody' for domain 'example.org'"

Yes.  How much of this we can successfully change now, after two
or three decades of practice, is an open question.  But that is
one of the reasons for pushing toward the use of extended reply
codes (and formats) which, at the moment, the EAI work is
expected to require.


>> SMTP is already too complicated.  Let's avoid adding more
>> complexity unless it is strictly necessary.  This is not.
>> 
> 
> +1

Thanks.

     john


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Tue Aug 22 20:53:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFh0B-0006Nk-KZ; Tue, 22 Aug 2006 20:53:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFh09-0006Mi-PN
	for ima@ietf.org; Tue, 22 Aug 2006 20:53:49 -0400
Received: from sniper.icu.ac.kr ([210.107.128.51])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFh04-0000rc-52
	for ima@ietf.org; Tue, 22 Aug 2006 20:53:49 -0400
Received: (snipe 3199 invoked by uid 0); 23 Aug 2006 09:54:11 +0900
Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.083800
	secs); 
Received: from unknown (HELO ?218.36.241.55?) (Zc??own@218.36.241.55)
	by unknown with SMTP; 23 Aug 2006 09:54:11 +0900
X-RCPTTO: ima@ietf.org
Message-ID: <44EBA711.70109@icu.ac.kr>
Date: Wed, 23 Aug 2006 09:53:37 +0900
From: Yangwoo Ko <newcat@icu.ac.kr>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: ima@ietf.org
Subject: Re: [EAI] I-D ACTION:draft-ietf-eai-downgrade-02.txt
References: <E1GEALy-0006GR-7M@stiedprstage1.ietf.org>
In-Reply-To: <E1GEALy-0006GR-7M@stiedprstage1.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org


Dear Yoneya and Fujiwara,

<quote>
    Even if no downgrading is performed for envelope from/to, MUA/MTA
    MUST downgrade mail headers including UTF-8 or bounce.  This is
    described in next section.
</quote>

The condition for header downgrade (or bounce) is not clear from
the above paragraph. Even though, we can "guess" from proceeding
paragraphs, you'd better specify it explicitly here.

Regards

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Wed Aug 23 05:51:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFpOO-0001pp-S0; Wed, 23 Aug 2006 05:51:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFpOO-0001pk-E7
	for ima@ietf.org; Wed, 23 Aug 2006 05:51:24 -0400
Received: from lon-mail-1.gradwell.net ([193.111.201.125])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFpOL-0003dD-Nb
	for ima@ietf.org; Wed, 23 Aug 2006 05:51:24 -0400
Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk
	country=GB ident=postmaster*pop3$clerew&man^ac^uk)
	by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id
	44ec2517.cc0c.e35 for ima@ietf.org; Wed, 23 Aug 2006 10:51:19 +0100
	(envelope-sender <chl@clerew.man.ac.uk>)
Received: from clerew.man.ac.uk (localhost [127.0.0.1])
	by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k7N9pGdW001984
	for <ima@ietf.org>; Wed, 23 Aug 2006 10:51:17 +0100 (BST)
To: "ima@ietf.org" <ima@ietf.org>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com>
	<6.0.0.20.2.20060818150743.097d4ec0@localhost>
	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>
	<003401c6c54d$18765640$6501a8c0@oemcomputer>
	<6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>
Message-ID: <op.teqdnqjm6hl8nm@clerew.man.ac.uk>
Date: Wed, 23 Aug 2006 10:51:16 +0100
From: "Charles Lindsey" <chl@clerew.man.ac.uk>
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
In-Reply-To: <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

On Tue, 22 Aug 2006 17:35:02 +0100, John C Klensin <klensin@jck.com> wrote:

>
> The issue of making the text of SMTP responses
> language-appropriate has been recognized since RFC 821 was
> written.  As with many other Internet protocols, the most
> effective model is to use a single form on the wire and then
> perform translations (of character sets, terminal information,
> formats, and, yes, languages) at the endpoints.   The "rely on
> the codes" requirement of 821 was, and is, part of that concern.
> When the codes proved inadequate in practice, we extended the
> codes, which was entirely consistent with that general model.

Yes, but that only works if all possible reply messages are known in  
advance, so that agents can have translations in various languages ready  
to plug in. But many reply messages are system/site specific.
>
> If a user needs to look at an SMTP reply message directly, then
> I suggest that either there is a debugging case in action or the
> relevant MUA is broken.  Debugging cases are easier with more
> uniformity and simplicity, not more options.

There are two cases where a MUA will need to exhibit at least the text  
part of a response from a server.

1) The server (acting as a submission agent) rejects the message for some  
site-specific reason ("You are not authorized to send this message"; "This  
message was refused because it contained virus/spam/whatever with the  
following details"). In this case, it could be useful for the responding  
server to know what language the sender might like to read this in.

2) Bounce messages regularly contain the full response line, and very  
useful they are too. But there are many strtange reasons why particular  
sites may bounce, and hence strange texts to explain them. Unfortunately,  
the language in which the original sender would like to see the  
explanation is unlikely to be known to the bouncing agent.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Wed Aug 23 05:54:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFpRm-0003Rb-Ar; Wed, 23 Aug 2006 05:54:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFpRl-0003OH-5Y
	for ima@ietf.org; Wed, 23 Aug 2006 05:54:53 -0400
Received: from lon-mail-1.gradwell.net ([193.111.201.125])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFpRj-0004OM-EC
	for ima@ietf.org; Wed, 23 Aug 2006 05:54:52 -0400
Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk
	country=GB ident=postmaster$pop3&clerew&man&ac$uk)
	by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id
	44ec25e7.1127b.aa6 for ima@ietf.org; Wed, 23 Aug 2006 10:54:47 +0100
	(envelope-sender <chl@clerew.man.ac.uk>)
Received: from clerew.man.ac.uk (localhost [127.0.0.1])
	by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k7N9sjZl002199
	for <ima@ietf.org>; Wed, 23 Aug 2006 10:54:46 +0100 (BST)
Date: Tue, 22 Aug 2006 18:34:03 +0100
From: "Charles Lindsey" <chl@clerew.man.ac.uk>
To: "Alexey Melnikov" <alexey.melnikov@isode.com>, ima@ietf.org
Subject: Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com>
Message-ID: <op.teo4e1ip6hl8nm@clerew.man.ac.uk>
In-Reply-To: <44E09667.8070704@isode.com>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
Resent-To: "ima@ietf.org" <ima@ietf.org>
Resent-From: "Charles Lindsey" <chl@clerew.man.ac.uk>
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Resent-Date: Wed, 23 Aug 2006 10:54:44 +0100
Resent-Message-ID: <op.teqdtirl6hl8nm@clerew.man.ac.uk>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: 
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Sender: ima-bounces@ietf.org
Errors-To: ima-bounces@ietf.org

On Mon, 14 Aug 2006 16:27:35 +0100, Alexey Melnikov
<alexey.melnikov@isode.com> wrote:

> To: 	i-d-announce@ietf.org	
> Cc: 		
> From: 	Internet-Drafts@ietf.org	
> Date: 	Wed, 02 Aug 2006 15:50:02 -0400	
> Subject: 	I-D ACTION:draft-melnikov-smtp-lang-05.txt 	
> Reply-To: 	internet-drafts@ietf.org	
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
>
>
> Title: SMTP Language Extension
>
> Author(s): M. Gahrns, A. Melnikov
>
> Filename: draft-melnikov-smtp-lang-05.txt
>
> Pages: 0
>
> Date: 2006-8-2
>
>
>
> The Simple Mail Transfer Protocol (RFC 2821) allows server responses to
>
> include human-readable text that in many cases needs to be presented to
>
> the user.  This document specifies a way for a client to negotiate which
> language the server should use when sending human-readable text. It also  
> extends
> DSN format to include language field for the human-readable text.
>

Having just returned from 10 days holiday, I have not had an opportunity
to read this draft yet.

However, draft-ietf-nntpext-base-27.txt (which is just waiting for the RFC
editor to publish it as proposed standard) allows such rsponses in UTF-8
in NNTP, so please do not do anything that would be unnecessarily
different from that draft.

I grant you that said draft provides no mechanism for the user to specify
which language the user would like his responses to be in, which is a
serious omission.

Does anybody know whether other standards that produce responses in the
form of 3 digits followed by free text have made provision for strangs
languages/charsets?



-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 
   Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Wed Aug 23 07:21:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFqnv-0007HB-E4; Wed, 23 Aug 2006 07:21:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFqnu-0007H3-JV; Wed, 23 Aug 2006 07:21:50 -0400
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GFqnt-0002SF-4T; Wed, 23 Aug 2006 07:21:50 -0400
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 8324B2596DE;
	Wed, 23 Aug 2006 13:19:53 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 17190-04; Wed, 23 Aug 2006 13:19:47 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 1E25B2596DA;
	Wed, 23 Aug 2006 13:19:47 +0200 (CEST)
Message-ID: <44EC3A45.90201@alvestrand.no>
Date: Wed, 23 Aug 2006 04:21:41 -0700
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: John C Klensin <klensin@jck.com>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com>	<6.0.0.20.2.20060818150743.097d4ec0@localhost>	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>	<003401c6c54d$18765640$6501a8c0@oemcomputer>
	<6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>
In-Reply-To: <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: Randy Presuhn <randy_presuhn@mindspring.com>,
	LTRU Working Group <ltru@ietf.org>, ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

>
> The issue of making the text of SMTP responses
> language-appropriate has been recognized since RFC 821 was
> written.  As with many other Internet protocols, the most
> effective model is to use a single form on the wire and then
> perform translations (of character sets, terminal information,
> formats, and, yes, languages) at the endpoints.   The "rely on
> the codes" requirement of 821 was, and is, part of that concern.
> When the codes proved inadequate in practice, we extended the
> codes, which was entirely consistent with that general model.
>
> If a user needs to look at an SMTP reply message directly, then
> I suggest that either there is a debugging case in action or the
> relevant MUA is broken.  Debugging cases are easier with more
> uniformity and simplicity, not more options.  
>
>   
just because I have some available, here are some examples of SMTP error 
codes...


| SMTP error in RCPT TO: 553 '<@>' <n5ial@n5ial> not matched: (ERR |
| Error in RCPT TO: 550 5.1.1 unknown or illegal alias: @ (MX) |
| Error in RCPT TO: 501 5.7.1 This system is not configured to rel |
| Connect(raw) failed: Connection refused |
| 5.1.1 (Unknown user): QMail; 550 <brandl@htu.tu-graz.ac.at>... U |
| Error in RCPT TO: 550 Sorry, no mailbox here by that name. (#5.1 |
| Error in RCPT TO: 554 5.0.0 Mail to ace3 is not permitted (MX) |
| Error in RCPT TO: 550 5.1.1 <@>... email address lookup in domai |
| Error in RCPT TO: 553 5.3.0 <@>... Unknown user jwessel@staff.ui |
| 5.1.1 (Unknown user): QMail; 550 <sn@plato.chemietechnik.uni-dor |
| Error in RCPT TO: 550 5.7.1 Unable to relay for @ (MX) |
| Error in RCPT TO: 554 Mail for @ rejected for policy reasons. (M |
| RELAY problem: 550 5.7.1 <@>... Relaying denied (MX) |
| Error in RCPT TO: 553 sorry, that domain isn't in my list of all |
| Error in RCPT TO: 554 5.7.1 <@>... User unknown (MX) |

<@> is an abbreviation for "the original email address was here". These 
are truncated to 64 chars.

the important points are:

- a lot of servers return quite different errors with the same error code
- the servers try to return info that's useful for the sender, not for 
the relay agent

Query: Has anyone seen a production piece of software that tries to 
decode the extendedstatuscodes as text for display to the users?

Harald


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Wed Aug 23 07:26:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFqsZ-00019b-TO; Wed, 23 Aug 2006 07:26:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFahk-0001iP-Q0; Tue, 22 Aug 2006 14:10:24 -0400
Received: from rsmtp1.corp.yahoo.com ([207.126.228.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GFahj-00081O-Cm; Tue, 22 Aug 2006 14:10:24 -0400
Received: from [172.21.148.169] (wlanvpn-mc2e-246-169.corp.yahoo.com
	[172.21.148.169]) (authenticated bits=0)
	by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id
	k7MIAEGM047539
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Aug 2006 11:10:15 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject:
	references:in-reply-to:content-type:content-transfer-encoding;
	b=nT1oA2+yXCXfz0ws69bNp61dlq0bwqOb9idqH6hFRz0PnxvmrkgOaTO3T1/UoSeh
Message-ID: <44EB4886.5010009@yahoo-inc.com>
Date: Tue, 22 Aug 2006 11:10:14 -0700
From: Addison Phillips <addison@yahoo-inc.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: John C Klensin <klensin@jck.com>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com>	<6.0.0.20.2.20060818150743.097d4ec0@localhost>	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>	<003401c6c54d$18765640$6501a8c0@oemcomputer>
	<6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>
In-Reply-To: <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -15.0 (---------------)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
X-Mailman-Approved-At: Wed, 23 Aug 2006 07:26:38 -0400
Cc: Randy Presuhn <randy_presuhn@mindspring.com>,
	LTRU Working Group <ltru@ietf.org>, ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

A few comments follow...

John C Klensin wrote:
>> ...
>>> The client knows which languages that the server supports
>>> (unless the server can't enumerate them),
>> ...

Enumerating languages can be difficult. Most locale systems are quite 
extensive, with hundreds of potential values available. The server would 
have to attempt to load resources in each and enumerate whether the 
resources were extant in the locale or not in order to build an accurate 
list. In practice, few languages are actually available, but the code to 
figure it out is not available either.


> 
> Another issue you didn't mention is that, in an environment in
> which the language negotiated runs right to left, it not clear
> where all the pieces go.  

This is a common misperception. The logical order of the text is 
left-to-right until the [ SP text ] is reached. This text is rendered 
RTL, if appropriate to do so, up to the CRLF (which ends the RTL "run"). 
See http://www.w3.org/TR/CharMod and http://www.unicode.org/reports/tr9/

> 
> Even if we can make this model work, I suggest it is the wrong
> model.  I further suggest that the difficulties with the small,
> inconvenient, cases, such as those above, are symptomatic of why
> it is the wrong model.  

The examples given are not very convincing. However... I tend to agree 
that this is the wrong model. The design of SMTP and other protocols is 
such that user-agents can present "friendly" messages (including 
localized messages) to end users. Almost no one interacts with SMTP 
servers directly.
> 
> 	(1) This draft be dropped in favor of an effort to make
> 	SMTP reply text easier to translate to other languages
> 	or generate-able from the codes.

Allowing UTF-8 would still seem to be a Good Thing, since even 
boilerplate messages might need to include runtime data that is 
non-ASCII. Language negotiation is another issue.

> 	
> 	(3) We should look at the text associated with extended
> 	reply codes to be sure that the portions of those lines
> 	that are not boilerplate explanations are easily
> 	identified and extracted by automatic processes.  If we
> 	discover cases where that goal is not met, we should fix
> 	them.
If extended reply codes permit the server to emit its own internal error 
messages which are not entirely standardized (i.e. boilerplate), then 
the user-agent may have not choice other than to render the string on to 
  the user. This is unsatisfactory.

> 
> 	(i) MUA that receives the reply, or MTA that is about to
> 	deliver the reply to such an MUA, extracts the extended
> 	reply code and non-boilerplace, message-dependent,
> 	material from the "text" and discards the rest.

This works best if the message dependent material were clearly separate 
and in a machine-friendly format. This:

   9106 Invalid user name; user=nobody, domain=example.org

Is easier to deal with than:

   "9106 Invalid user name 'nobody' for domain 'example.org'"

> 
> SMTP is already too complicated.  Let's avoid adding more
> complexity unless it is strictly necessary.  This is not.
> 

+1

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Wed Aug 23 11:10:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFuMJ-00081U-Cl; Wed, 23 Aug 2006 11:09:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFuMI-00081L-Jg; Wed, 23 Aug 2006 11:09:34 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GFsK4-0006up-NV; Wed, 23 Aug 2006 08:59:08 -0400
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1GFrxy-0008G3-Fh; Wed, 23 Aug 2006 08:36:21 -0400
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:52637)
	by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25)
	with esmtpa (EXTERNAL:fanf2) id 1GFrxZ-0006SQ-1G (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Wed, 23 Aug 2006 13:35:53 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1GFrxZ-0007fS-Ax (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Wed, 23 Aug 2006 13:35:53 +0100
Date: Wed, 23 Aug 2006 13:35:53 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Harald Alvestrand <harald@alvestrand.no>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
In-Reply-To: <44EC3A45.90201@alvestrand.no>
Message-ID: <Pine.LNX.4.64.0608231231070.5633@hermes-2.csi.cam.ac.uk>
References: <44E09667.8070704@isode.com>
	<6.0.0.20.2.20060818150743.097d4ec0@localhost>
	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>
	<003401c6c54d$18765640$6501a8c0@oemcomputer>
	<6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>
	<44EC3A45.90201@alvestrand.no>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: -2.4 (--)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: Randy Presuhn <randy_presuhn@mindspring.com>,
	LTRU Working Group <ltru@ietf.org>,
	Addison Phillips <addison@yahoo-inc.com>, ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

On Wed, 23 Aug 2006, Harald Alvestrand wrote:
>
> Query: Has anyone seen a production piece of software that tries to decode the
> extendedstatuscodes as text for display to the users?

Yes, and the result is usually unhelpful in my experience. A significant
number of support queries that I have to deal with are solved by me
pulling an error message out of the logs that was hidden by some software
between my servers and the user. (Admittedly, this is more likely to
happen for us because we don't support enhanced status codes, but since
they carry so little extra information I doubt they would help.)

John says:
>
> As with many other Internet protocols, the most effective model is to
> use a single form on the wire and then perform translations (of
> character sets, terminal information, formats, and, yes, languages) at
> the endpoints.  The "rely on the codes" requirement of 821 was, and is,
> part of that concern.

That's not the way I read it. To me it says that the non-enhanced codes
are for the client state machine and the text is for a human; it does not
imply that a client should replace the server's text with its own idea of
what went wrong.

> If a user needs to look at an SMTP reply message directly, then I
> suggest that either there is a debugging case in action or the relevant
> MUA is broken.  Debugging cases are easier with more uniformity and
> simplicity, not more options.

If a user sees an SMTP response then something has gone wrong so it's a
debugging case by definition.

Addison says:
>
> Almost no one interacts with SMTP servers directly.

Of course they do, to the same extent that they interact with IMAP or POP
or HTTP servers - mediated by a user agent.

>From my point of view, and from the point of view of my colleagues on the
help desk, it would be much easier if MUAs did not try to impose their own
gloss on my servers' error messages (or do other stupid things like
truncate them). That way I can provide helpful text that explains what
went wrong, and/or a URL to help pages or a directory.

The current set of enhanced status codes is non-orthogonal and does not
cover the range of possibilities or provide enough detail within their
coverage. For example, there are codes for bad syntax and bad domain for
both sender and recipient addresses, but you can only specifically say the
local part is bad for destination addresses, and there are different OK
codes for senders and recipients. There's a code for "too many recipients"
but not "too few recipients" (e.g. RFC 4468 has a different gloss of 5.5.0
for this situation). In SMTP you can say that an address has changed (551)
but not with enhanced status codes. (We've had a number departments
changing name recently where it might have been useful to use the 551
feature, but since no-one implements it we just used an ad-hoc "try
newname.cam.ac.uk instead" error.) The range of codes for client policy
restrictions is inadequate: there's no way of expressing the distinction
between "relaying is not permitted", "you have been blacklisted", "you are
making too many concurrent connections", "you have been rate-limited",
"you have been greylisted", etc. There are no codes for saying that the
message content violates security restrictions, such as a virus infection
or a forbidden attachment type or a spam classification.

Even if you solve these problems, there is no provision for extending the
set of status codes except as a standards action - there is no IANA
registry. And in fact an IANA registry wouldn't solve the problem because
no existing software will have glosses for any new status codes you might
register, so the new codes would be useless.

The idea of a fixed set of status codes is fundamentally unable to cope
with evolving operational requirements.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Wed Aug 23 19:13:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GG1ub-0007cV-JS; Wed, 23 Aug 2006 19:13:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GG1ua-0007aA-CR
	for ima@ietf.org; Wed, 23 Aug 2006 19:13:28 -0400
Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG1oc-0002Ai-6d
	for ima@ietf.org; Wed, 23 Aug 2006 19:07:20 -0400
Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17])
	by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id
	k7NN2HiS009699; Thu, 24 Aug 2006 08:02:17 +0900 (JST)
Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp
	id 174a_6c951f4c_32fb_11db_9c19_0014221f2a2d;
	Thu, 24 Aug 2006 08:02:16 +0900
Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k7NN1lXo000606; 
	Thu, 24 Aug 2006 08:02:16 +0900
Message-Id: <6.0.0.20.2.20060824071631.08dc2b70@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6J
Date: Thu, 24 Aug 2006 07:27:58 +0900
To: "Charles Lindsey" <chl@clerew.man.ac.uk>,
	"Alexey Melnikov" <alexey.melnikov@isode.com>, ima@ietf.org
From: Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: Re: [EAI] New draft for allowing UTF-8 in SMTP responses
In-Reply-To: <op.teo4e1ip6hl8nm@clerew.man.ac.uk>
References: <44E09667.8070704@isode.com> <op.teo4e1ip6hl8nm@clerew.man.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: 
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

At 02:34 06/08/23, Charles Lindsey wrote:

>Does anybody know whether other standards that produce responses in the
>form of 3 digits followed by free text have made provision for strangs
>languages/charsets?

HTTP has Accept-Language for indicating user preferences
(mainly for the 'payload', but this of course can also be
used for textual data in reply headers.

The encoding that the HTTP spec prescribes is hopelessly weird.
It is raw iso-8859-1, or anything else if encoded using RFC 2047.
I have seen quite a few proposals to extend HTTP in one way or
another that for the headers they use just prescribe UTF-8,
which is a lot simpler and more straightforward. I haven't
observed things in practice too much; in HTTP, on top of
getting e.g.
   404 Resource not found
you also get an HTML page that can say the same thing much
more nicely, and that is easier to provide in many languages.

I think protocols such as ACAP, IMAP,... have facilities similar
to what Alex is proposing.

Regards,    Martin.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp     


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Wed Aug 23 19:14:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GG1w2-0008CR-IN; Wed, 23 Aug 2006 19:14:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GG1us-0007bJ-3W; Wed, 23 Aug 2006 19:13:46 -0400
Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GG1k4-0001bP-1M; Wed, 23 Aug 2006 19:02:38 -0400
Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16])
	by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id
	k7NN2Oee009716; Thu, 24 Aug 2006 08:02:24 +0900 (JST)
Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp
	id 02e3_7093ee52_32fb_11db_9971_0014221fa3c9;
	Thu, 24 Aug 2006 08:02:24 +0900
Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k7NN1lXq000606; 
	Thu, 24 Aug 2006 08:02:20 +0900
Message-Id: <6.0.0.20.2.20060824072912.08dc0e60@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6J
Date: Thu, 24 Aug 2006 07:50:58 +0900
To: John C Klensin <klensin@jck.com>, Addison Phillips <addison@yahoo-inc.com>
From: Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 inSMTP
  responses
In-Reply-To: <CA5C301C3FE7D5F20D5A3DBE@p3.JCK.COM>
References: <44E09667.8070704@isode.com>
	<6.0.0.20.2.20060818150743.097d4ec0@localhost>
	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>
	<003401c6c54d$18765640$6501a8c0@oemcomputer>
	<6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>
	<44EB4886.5010009@yahoo-inc.com>
	<CA5C301C3FE7D5F20D5A3DBE@p3.JCK.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: LTRU Working Group <ltru@ietf.org>, ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

At 04:48 06/08/23, John C Klensin wrote:
>
>
>--On Tuesday, 22 August, 2006 11:10 -0700 Addison Phillips
><addison@yahoo-inc.com> wrote:

>> This is a common misperception. The logical order of the text
>> is left-to-right until the [ SP text ] is reached. This text
>> is rendered RTL, if appropriate to do so, up to the CRLF
>> (which ends the RTL "run"). See http://www.w3.org/TR/CharMod
>> and http://www.unicode.org/reports/tr9/
>
>Exactly (!).    If I said that badly, I apologize, but I read
>821/ 2821 as requiring a three digit code and the SP (in
>left-to-right order) followed by "text".

The protocol only defines logical order, i.e. on the wire, the
bytes for the three digit code are followed by (a SP and then)
the extended error code and then (a SP and then) the TEXT.
As Doug has said, how to display these is entirely up to the
client. For an Arabic or Hebrew client, something like
                              [(RTL) TEXT goes here] 5.1.1 550
is okay and may make sense.                                 

>The extended status
>code stuff is specific about the text, but wasn't written
>anticipating internationalization and is not required by the
>proposed specification anyway.   And, to the best of my
>knowledge, there is no standard requiring the used of W3C
>CharMod or Unicore TR9 in Internet mail replies.

TR9 is an Unicode Standards Annex (UAX), which means it is
part of the Standard. In many ways, at the very moment you
say UTF-8, you include it. For the IETF,
http://www.rfc-editor.org/rfc/rfc3629.txt normatively references
Unicode 4.0, and this includes TR9 at
http://www.unicode.org/unicode/standard/versions/components-4.0.0.html
(and I'm sure that the actual book says the same).

>> The examples given are not very convincing. However... I tend
>> to agree that this is the wrong model. The design of SMTP and
>> other protocols is such that user-agents can present
>> "friendly" messages (including localized messages) to end
>> users. Almost no one interacts with SMTP servers directly.
>
>Right

I think I agree to quite some extent with John and Addison, but
as most of us know and Harald has shown again, the situation
with SMTP error message consistency is much worse than with any
other, comparable protocol.

Also, while these error messages with their codes may not have
been intended to be show to users, they routinely turn up in
bounce messages, which go directly to the end user. Telling
the end user that s/he may have mistyped an address should be done
in the user's language, should not require support staff invention,
and should not be treated as a protocol debugging problem.


For EAI, I think it would be immensly helpful to have return
messages defined with enough precision so that an MUA
receiving a bounce can tell the user directly, or otherwise
take an appropriate action (e.g. flagging the relevant entry
in the address book as questionable) without necessarily having
to show the actual message to the user. If we don't manage to
get that for EAI, where we have a fresh slate, I don't think we
are in a position to try anything for the vast reminder of
error codes and error messages.

Regards,     Martin.


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp     


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Thu Aug 24 01:55:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GG8Am-0007iR-IH; Thu, 24 Aug 2006 01:54:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GG8Al-0007iJ-0R
	for ima@ietf.org; Thu, 24 Aug 2006 01:54:35 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG6UB-0001kn-4Z
	for ima@ietf.org; Thu, 24 Aug 2006 00:06:31 -0400
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GG6JA-0006pP-QY
	for ima@ietf.org; Wed, 23 Aug 2006 23:55:10 -0400
Received: from root by ciao.gmane.org with local (Exim 4.43)
	id 1GG6J3-0002S5-M8 for ima@ietf.org; Thu, 24 Aug 2006 05:55:01 +0200
Received: from pd9fbad01.dip0.t-ipconnect.de ([217.251.173.1])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <ima@ietf.org>; Thu, 24 Aug 2006 05:55:01 +0200
Received: from nobody by pd9fbad01.dip0.t-ipconnect.de with local (Gmexim 0.1
	(Debian)) id 1AlnuQ-0007hv-00
	for <ima@ietf.org>; Thu, 24 Aug 2006 05:55:01 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ima@ietf.org
From: Frank Ellermann <nobody@xyzzy.claranet.de>
Subject: Re: [EAI] New draft for allowing UTF-8 inSMTP
	  responses
Date: Thu, 24 Aug 2006 05:52:09 +0200
Organization: <URL:http://purl.net/xyzzy>
Lines: 63
Message-ID: <44ED2269.70F3@xyzzy.claranet.de>
References: <44E09667.8070704@isode.com>
	<6.0.0.20.2.20060818150743.097d4ec0@localhost>
	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>
	<003401c6c54d$18765640$6501a8c0@oemcomputer>
	<6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>
	<44EB4886.5010009@yahoo-inc.com>
	<CA5C301C3FE7D5F20D5A3DBE@p3.JCK.COM>
	<6.0.0.20.2.20060824072912.08dc0e60@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: pd9fbad01.dip0.t-ipconnect.de
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: ltru@lists.ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Martin Duerst wrote:

> TR9 is an Unicode Standards Annex (UAX), which means it is
> part of the Standard. In many ways, at the very moment you
> say UTF-8, you include it.

You could take UTF-8 as "ASCII plus opaque garbage" in various
protocols, and then other parts of [Unicode] are not relevant.

Nobody's forced to use say Unicode collation or hyphenation
only because (s)he uses UTF-8 referencing STD 63,  Another
example would be 3066bis, it references ISO 3166.  Nobody
using language tags is now forced to use also 3166-3 codes,
they can still make up their own stuff, use CLDR or what else.

> as most of us know and Harald has shown again, the situation
> with SMTP error message consistency is much worse than with
> any other, comparable protocol.

The RFC 4408 folks made sure that URIs work, indirectly that
arrives as whatever e.g. http offers.  A scenario for RFC 4408
is a user trying to send on a route not permitted by the sender
policy of his domain.

What really happens:  User submits mail to the "wrong" MSA, and 
this MSA doesnt't enforce submission rights (RFC 4409 6.1), it
tries to forward the mail towards the recipient.  The MX checks
the sender policy (RFC 4408) by querying a nameserver of the
domain in the Return-Path.

That policy says "FAIL" and offers an explanation in the form
of an URI (optional of course).  The MX "encodes" this as 5.7.1
error response (RFC 2034) - oops, the 2034-reference was still
correct in draft 00, odd, maybe the missing 2034 was my bad -
while talking with the "wrong" MSA (or its mailout).  Of course
the MX is not forced to add the explanation of this third party
to its 5.7.1, but it can, let's assume that it did.

The MSA had accepted the mail for forward or delivery, and that
didn't work, therefore it MUST (RFC 821/2821) generate a non-
delivery message (aka "bounce", not the definition in 2821).
It will probably copy the 5.7.1 error message verbatim into
its non-delivery message.  

It then puts the error message in the mailbox of the user of
this domain.  Or forwards it if the user arranged it this way.

Later the user finds the bounce, that quotes the 5.7.1 (maybe),
and the 5.7.1 quotes the FAIL-explanation (maybe), that is an
URI, and now the user can contact that URI (maybe), and if it
is HTTP depending on the server, the browser, LTRU, matching,
and some other details the user can read the explanation of
an admin in his domain in their preferred language, why this
mail didn't make it on the wrong route.

That's in a nutshell the reason why there are no explicit I18N
considerations in RFC 4408:  It would never do to tunnel some
non-ASCII text from DNS through a 5.7.1 and a bounce, besides
it would be pointless, the domain can have many users with many
different languages.

Frank



_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Thu Aug 24 12:45:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GGIKD-0008GI-B9; Thu, 24 Aug 2006 12:45:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GGIKC-0008ET-Ic; Thu, 24 Aug 2006 12:45:00 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GGG6v-0007nv-VW; Thu, 24 Aug 2006 10:23:10 -0400
Received: from lon-mail-1.gradwell.net ([193.111.201.125])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1GGFsM-0004zP-A3; Thu, 24 Aug 2006 10:08:14 -0400
Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk
	country=GB ident=postmaster^pop3^clerew#man^ac$uk)
	by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id
	44edb2bf.3c15.334; Thu, 24 Aug 2006 15:07:59 +0100
	(envelope-sender <chl@clerew.man.ac.uk>)
Received: from clerew.man.ac.uk (localhost [127.0.0.1])
	by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k7OE7uts004672;
	Thu, 24 Aug 2006 15:07:56 +0100 (BST)
To: "LTRU Working Group" <ltru@ietf.org>, ima@ietf.org
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 inSMTP  responses
References: <44E09667.8070704@isode.com>
	<6.0.0.20.2.20060818150743.097d4ec0@localhost>
	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>
	<003401c6c54d$18765640$6501a8c0@oemcomputer>
	<6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>
	<44EB4886.5010009@yahoo-inc.com>
	<CA5C301C3FE7D5F20D5A3DBE@p3.JCK.COM>
	<6.0.0.20.2.20060824072912.08dc0e60@localhost>
Message-ID: <op.tesj7hji6hl8nm@clerew.man.ac.uk>
Date: Thu, 24 Aug 2006 15:07:55 +0100
From: "Charles Lindsey" <chl@clerew.man.ac.uk>
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
In-Reply-To: <6.0.0.20.2.20060824072912.08dc0e60@localhost>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: -2.6 (--)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: 
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

On Wed, 23 Aug 2006 23:50:58 +0100, Martin Duerst <duerst@it.aoyama.ac.jp>  
wrote:

> At 04:48 06/08/23, John C Klensin wrote:
>>
>>
>> --On Tuesday, 22 August, 2006 11:10 -0700 Addison Phillips
>> <addison@yahoo-inc.com> wrote:
>
>>> This is a common misperception. The logical order of the text
>>> is left-to-right until the [ SP text ] is reached. This text
>>> is rendered RTL, if appropriate to do so, up to the CRLF
>>> (which ends the RTL "run"). See http://www.w3.org/TR/CharMod
>>> and http://www.unicode.org/reports/tr9/
>>
>> Exactly (!).    If I said that badly, I apologize, but I read
>> 821/ 2821 as requiring a three digit code and the SP (in
>> left-to-right order) followed by "text".
>
> The protocol only defines logical order, i.e. on the wire, the
> bytes for the three digit code are followed by (a SP and then)
> the extended error code and then (a SP and then) the TEXT.
> As Doug has said, how to display these is entirely up to the
> client. For an Arabic or Hebrew client, something like
>                               [(RTL) TEXT goes here] 5.1.1 550
> is okay and may make sense.

Actually, I don't see a problem. The "[(RTL) TEXT goes here] 5.1.1 550",  
if that is how it appears, should be fine for the human reader. Nothing  
breaks protocol-wise.

For an agent which needs to take some protocol action (e.g. whether to  
hold on to the message and try again later), all it needs to see is the  
"550", and for that all it has to do is to look as the first 3 characters  
as they come off the wire

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Sun Aug 27 10:27:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHLbZ-00058q-QP; Sun, 27 Aug 2006 10:27:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHLbW-00058X-DC; Sun, 27 Aug 2006 10:27:14 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GHLbU-0007so-S3; Sun, 27 Aug 2006 10:27:14 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Sun, 27 Aug 2006 15:26:40 +0100
Message-ID: <44F18DD7.90304@isode.com>
Date: Sun, 27 Aug 2006 13:19:35 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John C Klensin <klensin@jck.com>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com>	<6.0.0.20.2.20060818150743.097d4ec0@localhost>	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>	<003401c6c54d$18765640$6501a8c0@oemcomputer>	<6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>	<44EB4886.5010009@yahoo-inc.com>
	<CA5C301C3FE7D5F20D5A3DBE@p3.JCK.COM>
In-Reply-To: <CA5C301C3FE7D5F20D5A3DBE@p3.JCK.COM>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: LTRU Working Group <ltru@ietf.org>,
	Addison Phillips <addison@yahoo-inc.com>, ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

John C Klensin wrote:

>>>	(1) This draft be dropped in favor of an effort to make
>>>	SMTP reply text easier to translate to other languages
>>>	or generate-able from the codes.      
>>>
>>Allowing UTF-8 would still seem to be a Good Thing, since even
>>boilerplate messages might need to include runtime data that
>>is non-ASCII. Language negotiation is another issue.
>>    
>>
>Clearly, the EAI effort is going to need to deal, in some way,
>with replies that contain non-ASCII addresses.  But, as you say,
>that is a different issue from language negotiation.
>
My draft is trying to address the following issues. Let's try to discuss 
them separately whenever possible, I will split the draft into multiple 
(or even drop some of them) based on feedback:
1). Allowing for UTF-8 in response text.
This is required for both UTF-8 email addresses and localized human 
readable text

2). Language negotiation.
If we agree that localized human readable text is a good idea, then 
there is a need for the sender to select a language. If the sender is 
Russian and the server emits responses in Chinese (or vice versa) by 
default, the response text would be of no much use for the sender. And 
as many others said, users end up seeing such text in non-delivery 
reports or in MUAs on message submission.

3). Allow for localized text in DSN messages. There are multiple ways of 
doing this:
a). localize the first text/plain part
b). extend format for message/delivery-status to allow for localized 
reason string, in addition to non-delivery reason in English.
c). extend multipart/report to allow for extra bodyparts, that would 
convey this information. (I am not sure how well this will interoperate 
in real world, but I am listing this choice here for completeness)

4). Allow for UTF-8 addresses in DSN messages. There are also several 
ways of achieving this:
a). Use ACE in message/delivery-status bodypartFrom ima-bounces@ietf.org Sun Aug 27 10:27:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHLbZ-00058q-QP; Sun, 27 Aug 2006 10:27:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHLbW-00058X-DC; Sun, 27 Aug 2006 10:27:14 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GHLbU-0007so-S3; Sun, 27 Aug 2006 10:27:14 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Sun, 27 Aug 2006 15:26:40 +0100
Message-ID: <44F18DD7.90304@isode.com>
Date: Sun, 27 Aug 2006 13:19:35 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John C Klensin <klensin@jck.com>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com>	<6.0.0.20.2.20060818150743.097d4ec0@localhost>	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>	<003401c6c54d$18765640$6501a8c0@oemcomputer>	<6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>	<44EB4886.5010009@yahoo-inc.com>
	<CA5C301C3FE7D5F20D5A3DBE@p3.JCK.COM>
In-Reply-To: <CA5C301C3FE7D5F20D5A3DBE@p3.JCK.COM>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: LTRU Working Group <ltru@ietf.org>,
	Addison Phillips <addison@yahoo-inc.com>, ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

John C Klensin wrote:

>>>	(1) This draft be dropped in favor of an effort to make
>>>	SMTP reply text easier to translate to other languages
>>>	or generate-able from the codes.      
>>>
>>Allowing UTF-8 would still seem to be a Good Thing, since even
>>boilerplate messages might need to include runtime data that
>>is non-ASCII. Language negotiation is another issue.
>>    
>>
>Clearly, the EAI effort is going to need to deal, in some way,
>with replies that contain non-ASCII addresses.  But, as you say,
>that is a different issue from language negotiation.
>
My draft is trying to address the following issues. Let's try to discuss 
them separately whenever possible, I will split the draft into multiple 
(or even drop some of them) based on feedback:
1). Allowing for UTF-8 in response text.
This is required for both UTF-8 email addresses and localized human 
readable text

2). Language negotiation.
If we agree that localized human readable text is a good idea, then 
there is a need for the sender to select a language. If the sender is 
Russian and the server emits responses in Chinese (or vice versa) by 
default, the response text would be of no much use for the sender. And 
as many others said, users end up seeing such text in non-delivery 
reports or in MUAs on message submission.

3). Allow for localized text in DSN messages. There are multiple ways of 
doing this:
a). localize the first text/plain part
b). extend format for message/delivery-status to allow for localized 
reason string, in addition to non-delivery reason in English.
c). extend multipart/report to allow for extra bodyparts, that would 
convey this information. (I am not sure how well this will interoperate 
in real world, but I am listing this choice here for completeness)

4). Allow for UTF-8 addresses in DSN messages. There are also several 
ways of achieving this:
a). Use ACE in message/delivery-status bodypartFrom ima-bounces@ietf.org Sun Aug 27 10:27:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHLbZ-00058q-QP; Sun, 27 Aug 2006 10:27:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHLbW-00058X-DC; Sun, 27 Aug 2006 10:27:14 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GHLbU-0007so-S3; Sun, 27 Aug 2006 10:27:14 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Sun, 27 Aug 2006 15:26:40 +0100
Message-ID: <44F18DD7.90304@isode.com>
Date: Sun, 27 Aug 2006 13:19:35 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John C Klensin <klensin@jck.com>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com>	<6.0.0.20.2.20060818150743.097d4ec0@localhost>	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>	<003401c6c54d$18765640$6501a8c0@oemcomputer>	<6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>	<44EB4886.5010009@yahoo-inc.com>
	<CA5C301C3FE7D5F20D5A3DBE@p3.JCK.COM>
In-Reply-To: <CA5C301C3FE7D5F20D5A3DBE@p3.JCK.COM>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: LTRU Working Group <ltru@ietf.org>,
	Addison Phillips <addison@yahoo-inc.com>, ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

John C Klensin wrote:

>>>	(1) This draft be dropped in favor of an effort to make
>>>	SMTP reply text easier to translate to other languages
>>>	or generate-able from the codes.      
>>>
>>Allowing UTF-8 would still seem to be a Good Thing, since even
>>boilerplate messages might need to include runtime data that
>>is non-ASCII. Language negotiation is another issue.
>>    
>>
>Clearly, the EAI effort is going to need to deal, in some way,
>with replies that contain non-ASCII addresses.  But, as you say,
>that is a different issue from language negotiation.
>
My draft is trying to address the following issues. Let's try to discuss 
them separately whenever possible, I will split the draft into multiple 
(or even drop some of them) based on feedback:
1). Allowing for UTF-8 in response text.
This is required for both UTF-8 email addresses and localized human 
readable text

2). Language negotiation.
If we agree that localized human readable text is a good idea, then 
there is a need for the sender to select a language. If the sender is 
Russian and the server emits responses in Chinese (or vice versa) by 
default, the response text would be of no much use for the sender. And 
as many others said, users end up seeing such text in non-delivery 
reports or in MUAs on message submission.

3). Allow for localized text in DSN messages. There are multiple ways of 
doing this:
a). localize the first text/plain part
b). extend format for message/delivery-status to allow for localized 
reason string, in addition to non-delivery reason in English.
c). extend multipart/report to allow for extra bodyparts, that would 
convey this information. (I am not sure how well this will interoperate 
in real world, but I am listing this choice here for completeness)

4). Allow for UTF-8 addresses in DSN messages. There are also several 
ways of achieving this:
a). Use ACE in message/delivery-status bodypart.
b). Extend message/delivery-status to allow for 8bit data. RFC 3464 seem 
to disallow this:

2.1 The message/delivery-status content-type

   The message/delivery-status content-type is defined as follows:

   MIME type name:             message
   MIME subtype name:          delivery-status
   Optional parameters:        none
   Encoding considerations:    "7bit" encoding is sufficient and
                               MUST be used to maintain readability
                               when viewed by non-MIME mail readers.

And RFC 2046 seem to advise against non-7bit encodings in message/*:

5.2.4. Other Message Subtypes

   MIME implementations must in general treat unrecognized subtypes of
   "message" as being equivalent to "application/octet-stream".

   Future subtypes of "message" intended for use with email should be
   restricted to "7bit" encoding. A type other than "message" should be
   used if restriction to "7bit" is not possible.


Alexey

P.S. However I still thing that encouraging servers to implement 
Enhanced Status Codes is a good idea.
I would also like to work on response boilerplates.



_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Sun Aug 27 10:27:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHLbV-00058P-KP; Sun, 27 Aug 2006 10:27:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHLbU-00058D-Ow; Sun, 27 Aug 2006 10:27:12 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GHLbT-0007so-8R; Sun, 27 Aug 2006 10:27:12 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Sun, 27 Aug 2006 15:26:38 +0100
Message-ID: <44F18DB8.4040601@isode.com>
Date: Sun, 27 Aug 2006 13:19:04 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
To: Tony Finch <dot@dotat.at>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com>	<6.0.0.20.2.20060818150743.097d4ec0@localhost>	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>	<003401c6c54d$18765640$6501a8c0@oemcomputer>	<6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>	<44EC3A45.90201@alvestrand.no>
	<Pine.LNX.4.64.0608231231070.5633@hermes-2.csi.cam.ac.uk>
In-Reply-To: <Pine.LNX.4.64.0608231231070.5633@hermes-2.csi.cam.ac.uk>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: Greg Vaudreuil <gregv@lucent.com>, LTRU Working Group <ltru@ietf.org>,
	Addison Phillips <addison@yahoo-inc.com>, ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Tony Finch wrote:

>Addison says:
>  
>
>>Almost no one interacts with SMTP servers directly.
>>    
>>
>Of course they do, to the same extent that they interact with IMAP or POP
>or HTTP servers - mediated by a user agent.
>
>From my point of view, and from the point of view of my colleagues on the
>help desk, it would be much easier if MUAs did not try to impose their own
>gloss on my servers' error messages (or do other stupid things like
>truncate them). That way I can provide helpful text that explains what
>went wrong, and/or a URL to help pages or a directory.
>
>The curre.
b). Extend message/delivery-status to allow for 8bit data. RFC 3464 seem 
to disallow this:

2.1 The message/delivery-status content-type

   The message/delivery-status content-type is defined as follows:

   MIME type name:             message
   MIME subtype name:          delivery-status
   Optional parameters:        none
   Encoding considerations:    "7bit" encoding is sufficient and
                               MUST be used to maintain readability
                               when viewed by non-MIME mail readers.

And RFC 2046 seem to advise against non-7bit encodings in message/*:

5.2.4. Other Message Subtypes

   MIME implementations must in general treat unrecognized subtypes of
   "message" as being equivalent to "application/octet-stream".

   Future subtypes of "message" intended for use with email should be
   restricted to "7bit" encoding. A type other than "message" should be
   used if restriction to "7bit" is not possible.


Alexey

P.S. However I still thing that encouraging servers to implement 
Enhanced Status Codes is a good idea.
I would also like to work on response boilerplates.



_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Sun Aug 27 10:27:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHLbV-00058P-KP; Sun, 27 Aug 2006 10:27:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHLbU-00058D-Ow; Sun, 27 Aug 2006 10:27:12 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GHLbT-0007so-8R; Sun, 27 Aug 2006 10:27:12 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Sun, 27 Aug 2006 15:26:38 +0100
Message-ID: <44F18DB8.4040601@isode.com>
Date: Sun, 27 Aug 2006 13:19:04 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
To: Tony Finch <dot@dotat.at>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com>	<6.0.0.20.2.20060818150743.097d4ec0@localhost>	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>	<003401c6c54d$18765640$6501a8c0@oemcomputer>	<6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>	<44EC3A45.90201@alvestrand.no>
	<Pine.LNX.4.64.0608231231070.5633@hermes-2.csi.cam.ac.uk>
In-Reply-To: <Pine.LNX.4.64.0608231231070.5633@hermes-2.csi.cam.ac.uk>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: Greg Vaudreuil <gregv@lucent.com>, LTRU Working Group <ltru@ietf.org>,
	Addison Phillips <addison@yahoo-inc.com>, ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Tony Finch wrote:

>Addison says:
>  
>
>>Almost no one interacts with SMTP servers directly.
>>    
>>
>Of course they do, to the same extent that they interact with IMAP or POP
>or HTTP servers - mediated by a user agent.
>
>From my point of view, and from the point of view of my colleagues on the
>help desk, it would be much easier if MUAs did not try to impose their own
>gloss on my servers' error messages (or do other stupid things like
>truncate them). That way I can provide helpful text that explains what
>went wrong, and/or a URL to help pages or a directory.
>
>The curre.
b). Extend message/delivery-status to allow for 8bit data. RFC 3464 seem 
to disallow this:

2.1 The message/delivery-status content-type

   The message/delivery-status content-type is defined as follows:

   MIME type name:             message
   MIME subtype name:          delivery-status
   Optional parameters:        none
   Encoding considerations:    "7bit" encoding is sufficient and
                               MUST be used to maintain readability
                               when viewed by non-MIME mail readers.

And RFC 2046 seem to advise against non-7bit encodings in message/*:

5.2.4. Other Message Subtypes

   MIME implementations must in general treat unrecognized subtypes of
   "message" as being equivalent to "application/octet-stream".

   Future subtypes of "message" intended for use with email should be
   restricted to "7bit" encoding. A type other than "message" should be
   used if restriction to "7bit" is not possible.


Alexey

P.S. However I still thing that encouraging servers to implement 
Enhanced Status Codes is a good idea.
I would also like to work on response boilerplates.



_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Sun Aug 27 10:27:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHLbV-00058P-KP; Sun, 27 Aug 2006 10:27:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHLbU-00058D-Ow; Sun, 27 Aug 2006 10:27:12 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GHLbT-0007so-8R; Sun, 27 Aug 2006 10:27:12 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Sun, 27 Aug 2006 15:26:38 +0100
Message-ID: <44F18DB8.4040601@isode.com>
Date: Sun, 27 Aug 2006 13:19:04 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
To: Tony Finch <dot@dotat.at>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com>	<6.0.0.20.2.20060818150743.097d4ec0@localhost>	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>	<003401c6c54d$18765640$6501a8c0@oemcomputer>	<6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>	<44EC3A45.90201@alvestrand.no>
	<Pine.LNX.4.64.0608231231070.5633@hermes-2.csi.cam.ac.uk>
In-Reply-To: <Pine.LNX.4.64.0608231231070.5633@hermes-2.csi.cam.ac.uk>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: Greg Vaudreuil <gregv@lucent.com>, LTRU Working Group <ltru@ietf.org>,
	Addison Phillips <addison@yahoo-inc.com>, ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Tony Finch wrote:

>Addison says:
>  
>
>>Almost no one interacts with SMTP servers directly.
>>    
>>
>Of course they do, to the same extent that they interact with IMAP or POP
>or HTTP servers - mediated by a user agent.
>
>From my point of view, and from the point of view of my colleagues on the
>help desk, it would be much easier if MUAs did not try to impose their own
>gloss on my servers' error messages (or do other stupid things like
>truncate them). That way I can provide helpful text that explains what
>went wrong, and/or a URL to help pages or a directory.
>
>The current set of enhanced status codes is non-orthogonal and does not
>cover the range of possibilities or provide enough detail within their
>coverage.
>
Having recently reviewed Enhanced Status Codes and error messages 
emitted by Isode's SMTP server, I fully agree with this statement.

>For example, there are codes for bad syntax and bad domain for
>both sender and recipient addresses, but you can only specifically say the
>local part is bad for destination addresses, and there are different OK
>codes for senders and recipients. There's a code for "too many recipients"
>but not "too few recipients" (e.g. RFC 4468 has a different gloss of 5.5.0
>for this situation). In SMTP you can say that an address has changed (551)
>but not with enhanced status codes.
>
(slightly off topic)
Indeed. Some time ago I've tried to use 551 in order to implement Sieve 
redirect in LMTP server. I wanted to avoid adding SMTP client to Sieve 
engine, but after looking at Enhanced Status Codes I can only found:
      X.1.6   Destination mailbox has moved, No forwarding address
while I was expecting a status code saying "mailbox moved, send your 
message here <address>".

> (We've had a number departments
>changing name recently where it might have been useful to use the 551
>feature, but since no-one implements it we just used an ad-hoc "try
>newname.cam.ac.uk instead" error.)
>
Speaking of 551 and response boilerplates. Is there any interest in 
standardizing "mailbox moved, send your message here <address>" Enhanced 
Status Code with explicit boilerplate, so that the forwarding address is 
easily extractable?

> The range of codes for client policy restrictions is inadequate: there's no way of expressing the distinction
>between "relaying is not permitted", "you have been blacklisted", "you are
>making too many concurrent connections", "you have been rate-limited",
>"you have been greylisted", etc. There are no codes for saying that the
>message content violates security restrictions, such as a virus infection
>or a forbidden attachment type or a spam classification.
>
>Even if you solve these problems, there is no provision for extending the
>set of status codes except as a standards action - there is no IANA
>registry. And in fact an IANA registry wouldn't solve the problem because
>no existing software will have glosses for any new status codes you might
>register, so the new codes would be useless.
>  
>
Very true. Software is unlikely to be written to automatically download 
updates to an IANA registry. There are many cases when this is not 
practical or explicitly prohibited by IT department.

>The idea of a fixed set of status codes is fundamentally unable to cope
>with evolving operational requirements.
>  
>



_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima

From ima-bounces@ietf.org Sun Aug 27 10:27:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHLbU-000584-EV; Sun, 27 Aug 2006 10:27:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GHLbT-00057z-5M
	for ima@ietf.org; Sun, 27 Aug 2006 10:27:11 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHLbQ-0007so-LN
	for ima@ietf.org; Sun, 27 Aug 2006 10:27:11 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Sun, 27 Aug 2006 15:26:37 +0100
Message-ID: <44F188C4.40405@isode.com>
Date: Sun, 27 Aug 2006 12:57:56 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
To: Charles Lindsey <chl@clerew.man.ac.uk>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com>	<6.0.0.20.2.20060818150743.097d4ec0@localhost>	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>	<003401c6c54d$18765640$6501ant set of enhanced status codes is non-orthogonal and does not
>cover the range of possibilities or provide enough detail within their
>coverage.
>
Having recently reviewed Enhanced Status Codes and error messages 
emitted by Isode's SMTP server, I fully agree with this statement.

>For example, there are codes for bad syntax and bad domain for
>both sender and recipient addresses, but you can only specifically say the
>local part is bad for destination addresses, and there are different OK
>codes for senders and recipients. There's a code for "too many recipients"
>but not "too few recipients" (e.g. RFC 4468 has a different gloss of 5.5.0
>for this situation). In SMTP you can say that an address has changed (551)
>but not with enhanced status codes.
>
(slightly off topic)
Indeed. Some time ago I've tried to use 551 in order to implement Sieve 
redirect in LMTP server. I wanted to avoid adding SMTP client to Sieve 
engine, but after looking at Enhanced Status Codes I can only found:
      X.1.6   Destination mailbox has moved, No forwarding address
while I was expecting a status code saying "mailbox moved, send your 
message here <address>".

> (We've had a number departments
>changing name recently where it might have been useful to use the 551
>feature, but since no-one implements it we just used an ad-hoc "try
>newname.cam.ac.uk instead" error.)
>
Speaking of 551 and response boilerplates. Is there any interest in 
standardizing "mailbox moved, send your message here <address>" Enhanced 
Status Code with explicit boilerplate, so that the forwarding address is 
easily extractable?

> The range of codes for client policy restrictions is inadequate: there's no way of expressing the distinction
>between "relaying is not permitted", "you have been blacklisted", "you are
>making too many concurrent connections", "you have been rate-limited",
>"you have been greylisted", etc. There are no codes for saying that the
>message content violates security restrictions, such as a virus infection
>or a forbidden attachment type or a spam classification.
>
>Even if you solve these problems, there is no provision for extending the
>set of status codes except as a standards action - there is no IANA
>registry. And in fact an IANA registry wouldn't solve the problem because
>no existing software will have glosses for any new status codes you might
>register, so the new codes would be useless.
>  
>
Very true. Software is unlikely to be written to automatically download 
updates to an IANA registry. There are many cases when this is not 
practical or explicitly prohibited by IT department.

>The idea of a fixed set of status codes is fundamentally unable to cope
>with evolving operational requirements.
>  
>



_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima

From ima-bounces@ietf.org Sun Aug 27 10:27:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHLbU-000584-EV; Sun, 27 Aug 2006 10:27:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GHLbT-00057z-5M
	for ima@ietf.org; Sun, 27 Aug 2006 10:27:11 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHLbQ-0007so-LN
	for ima@ietf.org; Sun, 27 Aug 2006 10:27:11 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Sun, 27 Aug 2006 15:26:37 +0100
Message-ID: <44F188C4.40405@isode.com>
Date: Sun, 27 Aug 2006 12:57:56 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
To: Charles Lindsey <chl@clerew.man.ac.uk>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com>	<6.0.0.20.2.20060818150743.097d4ec0@localhost>	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>	<003401c6c54d$18765640$6501ant set of enhanced status codes is non-orthogonal and does not
>cover the range of possibilities or provide enough detail within their
>coverage.
>
Having recently reviewed Enhanced Status Codes and error messages 
emitted by Isode's SMTP server, I fully agree with this statement.

>For example, there are codes for bad syntax and bad domain for
>both sender and recipient addresses, but you can only specifically say the
>local part is bad for destination addresses, and there are different OK
>codes for senders and recipients. There's a code for "too many recipients"
>but not "too few recipients" (e.g. RFC 4468 has a different gloss of 5.5.0
>for this situation). In SMTP you can say that an address has changed (551)
>but not with enhanced status codes.
>
(slightly off topic)
Indeed. Some time ago I've tried to use 551 in order to implement Sieve 
redirect in LMTP server. I wanted to avoid adding SMTP client to Sieve 
engine, but after looking at Enhanced Status Codes I can only found:
      X.1.6   Destination mailbox has moved, No forwarding address
while I was expecting a status code saying "mailbox moved, send your 
message here <address>".

> (We've had a number departments
>changing name recently where it might have been useful to use the 551
>feature, but since no-one implements it we just used an ad-hoc "try
>newname.cam.ac.uk instead" error.)
>
Speaking of 551 and response boilerplates. Is there any interest in 
standardizing "mailbox moved, send your message here <address>" Enhanced 
Status Code with explicit boilerplate, so that the forwarding address is 
easily extractable?

> The range of codes for client policy restrictions is inadequate: there's no way of expressing the distinction
>between "relaying is not permitted", "you have been blacklisted", "you are
>making too many concurrent connections", "you have been rate-limited",
>"you have been greylisted", etc. There are no codes for saying that the
>message content violates security restrictions, such as a virus infection
>or a forbidden attachment type or a spam classification.
>
>Even if you solve these problems, there is no provision for extending the
>set of status codes except as a standards action - there is no IANA
>registry. And in fact an IANA registry wouldn't solve the problem because
>no existing software will have glosses for any new status codes you might
>register, so the new codes would be useless.
>  
>
Very true. Software is unlikely to be written to automatically download 
updates to an IANA registry. There are many cases when this is not 
practical or explicitly prohibited by IT department.

>The idea of a fixed set of status codes is fundamentally unable to cope
>with evolving operational requirements.
>  
>



_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima

From ima-bounces@ietf.org Sun Aug 27 10:27:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHLbU-000584-EV; Sun, 27 Aug 2006 10:27:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GHLbT-00057z-5M
	for ima@ietf.org; Sun, 27 Aug 2006 10:27:11 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHLbQ-0007so-LN
	for ima@ietf.org; Sun, 27 Aug 2006 10:27:11 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Sun, 27 Aug 2006 15:26:37 +0100
Message-ID: <44F188C4.40405@isode.com>
Date: Sun, 27 Aug 2006 12:57:56 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
To: Charles Lindsey <chl@clerew.man.ac.uk>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <44E09667.8070704@isode.com>	<6.0.0.20.2.20060818150743.097d4ec0@localhost>	<Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk>	<003401c6c54d$18765640$6501a8c0@oemcomputer>	<6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>
	<op.teqdnqjm6hl8nm@clerew.man.ac.uk>
In-Reply-To: <op.teqdnqjm6hl8nm@clerew.man.ac.uk>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: "ima@ietf.org" <ima@ietf.org>
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Charles Lindsey wrote:

> On Tue, 22 Aug 2006 17:35:02 +0100, John C Klensin <klensin@jck.com> 
> wrote:
>
>> The issue of making the text of SMTP responses
>> language-appropriate has been recognized since RFC 821 was
>> written.  As with many other Internet protocols, the most
>> effective model is to use a single form on the wire and then
>> perform translations (of character sets, terminal information,
>> formats, and, yes, languages) at the endpoints.   The "rely on
>> the codes" requirement of 821 was, and is, part of that concern.
>> When the codes proved inadequate in practice, we extended the
>> codes, which was entirely consistent with that general model.
>
> Yes, but that only works if all possible reply messages are known in  
> advance, so that agents can have translations in various languages 
> ready  to plug in. But many reply messages are system/site specific. 

+1.

>> If a user needs to look at an SMTP reply message directly, then
>> I suggest that either there is a debugging case in action or the
>> relevant MUA is broken.  Debugging cases are easier with more
>> uniformity and simplicity, not more options.
>
> There are two cases where a MUA will need to exhibit at least the 
> text  part of a response from a server.
>
> 1) The server (acting as a submission agent) rejects the message for 
> some  site-specific reason ("You are not authorized to send this 
> message"; "This  message was refused because it contained 
> virus/spam/whatever with the  following details"). In this case, it 
> could be useful for the responding  server to know what language the 
> sender might like to read this in.
>
> 2) Bounce messages regularly contain the full response line, and very  
> useful they are too. But there are many strtange reasons why 
> particular  sites may bounce, and hence strange texts to explain them. 
> Unfortunately,  the language in which the original sender would like 
> to see the  explanation is unlikely to be known to the bouncing agent.

+1



_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima





8c0@oemcomputer>	<6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>
	<op.teqdnqjm6hl8nm@clerew.man.ac.uk>
In-Reply-To: <op.teqdnqjm6hl8nm@clerew.man.ac.uk>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: "ima@ietf.org" <ima@ietf.org>
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Charles Lindsey wrote:

> On Tue, 22 Aug 2006 17:35:02 +0100, John C Klensin <klensin@jck.com> 
> wrote:
>
>> The issue of making the text of SMTP responses
>> language-appropriate has been recognized since RFC 821 was
>> written.  As with many other Internet protocols, the most
>> effective model is to use a single form on the wire and then
>> perform translations (of character sets, terminal information,
>> formats, and, yes, languages) at the endpoints.   The "rely on
>> the codes" requirement of 821 was, and is, part of that concern.
>> When the codes proved inadequate in practice, we extended the
>> codes, which was entirely consistent with that general model.
>
> Yes, but that only works if all possible reply messages are known in  
> advance, so that agents can have translations in various languages 
> ready  to plug in. But many reply messages are system/site specific. 

+1.

>> If a user needs to look at an SMTP reply message directly, then
>> I suggest that either there is a debugging case in action or the
>> relevant MUA is broken.  Debugging cases are easier with more
>> uniformity and simplicity, not more options.
>
> There are two cases where a MUA will need to exhibit at least the 
> text  part of a response from a server.
>
> 1) The server (acting as a submission agent) rejects the message for 
> some  site-specific reason ("You are not authorized to send this 
> message"; "This  message was refused because it contained 
> virus/spam/whatever with the  following details"). In this case, it 
> could be useful for the responding  server to know what language the 
> sender might like to read this in.
>
> 2) Bounce messages regularly contain the full response line, and very  
> useful they are too. But there are many strtange reasons why 
> particular  sites may bounce, and hence strange texts to explain them. 
> Unfortunately,  the language in which the original sender would like 
> to see the  explanation is unlikely to be known to the bouncing agent.

+1



_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima





8c0@oemcomputer>	<6AD3D4FD1D4C386BE716C69C@p3.JCK.COM>
	<op.teqdnqjm6hl8nm@clerew.man.ac.uk>
In-Reply-To: <op.teqdnqjm6hl8nm@clerew.man.ac.uk>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: "ima@ietf.org" <ima@ietf.org>
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Charles Lindsey wrote:

> On Tue, 22 Aug 2006 17:35:02 +0100, John C Klensin <klensin@jck.com> 
> wrote:
>
>> The issue of making the text of SMTP responses
>> language-appropriate has been recognized since RFC 821 was
>> written.  As with many other Internet protocols, the most
>> effective model is to use a single form on the wire and then
>> perform translations (of character sets, terminal information,
>> formats, and, yes, languages) at the endpoints.   The "rely on
>> the codes" requirement of 821 was, and is, part of that concern.
>> When the codes proved inadequate in practice, we extended the
>> codes, which was entirely consistent with that general model.
>
> Yes, but that only works if all possible reply messages are known in  
> advance, so that agents can have translations in various languages 
> ready  to plug in. But many reply messages are system/site specific. 

+1.

>> If a user needs to look at an SMTP reply message directly, then
>> I suggest that either there is a debugging case in action or the
>> relevant MUA is broken.  Debugging cases are easier with more
>> uniformity and simplicity, not more options.
>
> There are two cases where a MUA will need to exhibit at least the 
> text  part of a response from a server.
>
> 1) The server (acting as a submission agent) rejects the message for 
> some  site-specific reason ("You are not authorized to send this 
> message"; "This  message was refused because it contained 
> virus/spam/whatever with the  following details"). In this case, it 
> could be useful for the responding  server to know what language the 
> sender might like to read this in.
>
> 2) Bounce messages regularly contain the full response line, and very  
> useful they are too. But there are many strtange reasons why 
> particular  sites may bounce, and hence strange texts to explain them. 
> Unfortunately,  the language in which the original sender would like 
> to see the  explanation is unlikely to be known to the bouncing agent.

+1



_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima





From ima-bounces@ietf.org Sun Aug 27 10:27:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHLbZ-00058w-UR; Sun, 27 Aug 2006 10:27:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GHLbX-00058j-SX
	for ima@ietf.org; Sun, 27 Aug 2006 10:27:15 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHLbW-0007so-Fu
	for ima@ietf.org; Sun, 27 Aug 2006 10:27:15 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Sun, 27 Aug 2006 15:26:45 +0100
Message-ID: <44F19505.7030701@isode.com>
Date: Sun, 27 Aug 2006 13:50:13 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tony Finch <dot@dotat.at>
Subject: Re: [EAI] UTF8 and ESMTP extension parameters
References: <Pine.LNX.4.64.0608072017420.5999@hermes-2.csi.cam.ac.uk>
In-Reply-To: <Pine.LNX.4.64.0608072017420.5999@hermes-2.csi.cam.ac.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Tony Finch wrote:

>There are two problems with this model:
>
>(a) RFC 3461 does not allow non-ASCII characters in an xtext
>
>(b) the message/delivery-status content-type is restricted to 7bit
>content transfer encoding
>
>Is it worth updating the DSN specs to allow 8bit CTEs?
>
After our off-list conversation I think changing message/delivery-status 
to at least allow for quoted-printable CTE would be highly desirable.

>Would we still have
>to specify how to downgrade an 8bit DSN into 7bit? RFC2047 encoding? UTF7?
>or something else?
>
>We could define that 8bit DSNs are allowed within the UTF8SMTP network,
>and then define how to downgrade 8bit DSNs to 7bit, including how to
>downgrade UTF8 ORCPT parameters to 7bit.
>
>  
>



_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Mon Aug 28 04:20:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHcKw-0007UZ-Sj; Mon, 28 Aug 2006 04:19:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GHcKv-0007UR-4Q
	for ima@ietf.org; Mon, 28 Aug 2006 04:19:13 -0400
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHcKp-00033e-QO
	for ima@ietf.org; Mon, 28 Aug 2006 04:19:13 -0400
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id EF80625972F
	for <ima@ietf.org>; Mon, 28 Aug 2006 09:49:44 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP id 17836-08 for <ima@ietf.org>;
	Mon, 28 Aug 2006 09:49:40 +0200 (CEST)
Received: from [172.28.60.169] (unknown [62.92.16.50])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 10CAA25972E
	for <ima@ietf.org>; Mon, 28 Aug 2006 09:49:40 +0200 (CEST)
Message-ID: <44F2A08A.5060008@alvestrand.no>
Date: Mon, 28 Aug 2006 09:51:38 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: EAI WG <ima@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Subject: [EAI] IMAP and POP downgrade when SMTP downgrade would have bounced?
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Both the IMAP and POP drafts currently specify something like a 
mechanism for downgrading a stored UTF8SMTP message to ASCII by pointing 
at the -downgrade document.

What is the correct action to take when such a downgrade is attempted, 
and one encounters a case where the -downgrade SMTP gateway would have 
bounced the message?

                            Harald


_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Mon Aug 28 04:37:33 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHcce-0006xX-9l; Mon, 28 Aug 2006 04:37:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GHccd-0006xR-0f
	for ima@ietf.org; Mon, 28 Aug 2006 04:37:31 -0400
Received: from send01.jprs.co.jp ([202.11.17.113])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHccZ-00066r-FO
	for ima@ietf.org; Mon, 28 Aug 2006 04:37:30 -0400
Received: from send01.jprs.co.jp (localhost [127.0.0.1])
	by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id k7S8bCR9003364; 
	Mon, 28 Aug 2006 17:37:12 +0900 (JST)
Received: (from localhost [172.18.4.45])
	by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id
	M2006082817371205173 ; Mon, 28 Aug 2006 17:37:12 +0900
Date: Mon, 28 Aug 2006 17:37:12 +0900 (JST)
Message-Id: <20060828.173712.39178693.fujiwara@jprs.co.jp>
To: harald@alvestrand.no
Subject: Re: [EAI] IMAP and POP downgrade when SMTP downgrade would have
	bounced?
From: fujiwara@jprs.co.jp
In-Reply-To: <44F2A08A.5060008@alvestrand.no>
References: <44F2A08A.5060008@alvestrand.no>
X-Mailer: Mew version 5.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

> From: Harald Alvestrand <harald@alvestrand.no>
> Both the IMAP and POP drafts currently specify something like a 
> mechanism for downgrading a stored UTF8SMTP message to ASCII by pointing 
> at the -downgrade document.

In my understanding, IMAP and POP document refers downgrade-02 section
5 "SMTP DATA/Header Downgrading".

> What is the correct action to take when such a downgrade is attempted, 
> and one encounters a case where the -downgrade SMTP gateway would have 
> bounced the message?

Consider that From: header has a non-ASCII address without an
alternative US-ASCII address case.
After downgrading, original non-ASCII From: header is preserved in
Downgraded: header, but From: header becomes empty.

Return-Path:, To:, CC: header have the same problem.

Empty From: header or without From: header is allowed?

--
Kazunori Fujiwara, JPRS

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Mon Aug 28 04:41:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHcfw-0000DM-U4; Mon, 28 Aug 2006 04:40:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GHcfv-0000DH-IW
	for ima@ietf.org; Mon, 28 Aug 2006 04:40:55 -0400
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHcfu-0006X3-8S
	for ima@ietf.org; Mon, 28 Aug 2006 04:40:55 -0400
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id F06652596F8;
	Mon, 28 Aug 2006 10:38:54 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 19158-04; Mon, 28 Aug 2006 10:38:46 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 57F2725971F;
	Mon, 28 Aug 2006 10:38:45 +0200 (CEST)
Message-ID: <44F2AC0B.8040408@alvestrand.no>
Date: Mon, 28 Aug 2006 01:40:43 -0700
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: fujiwara@jprs.co.jp
Subject: Re: [EAI] IMAP and POP downgrade when SMTP downgrade would have
	bounced?
References: <44F2A08A.5060008@alvestrand.no>
	<20060828.173712.39178693.fujiwara@jprs.co.jp>
In-Reply-To: <20060828.173712.39178693.fujiwara@jprs.co.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

fujiwara@jprs.co.jp wrote:
>> From: Harald Alvestrand <harald@alvestrand.no>
>> Both the IMAP and POP drafts currently specify something like a 
>> mechanism for downgrading a stored UTF8SMTP message to ASCII by pointing 
>> at the -downgrade document.
>>     
>
> In my understanding, IMAP and POP document refers downgrade-02 section
> 5 "SMTP DATA/Header Downgrading".
>
>   
>> What is the correct action to take when such a downgrade is attempted, 
>> and one encounters a case where the -downgrade SMTP gateway would have 
>> bounced the message?
>>     
>
> Consider that From: header has a non-ASCII address without an
> alternative US-ASCII address case.
> After downgrading, original non-ASCII From: header is preserved in
> Downgraded: header, but From: header becomes empty.
>
> Return-Path:, To:, CC: header have the same problem.
>
> Empty From: header or without From: header is allowed?
>   
It is not allowed by RFC 2822.

I had always thought that if you encountered a missing alt-addr in the 
headers, the correct course was to bounce the message, rather than 
deliver a message where "reply" would not work.

I was surprised when I discovered the "remove the address" option in 
-downgrade.

What does the WG think desirable?

                Harald

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Mon Aug 28 10:39:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHiGU-0007Jb-8s; Mon, 28 Aug 2006 10:39:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GHiGT-0007JW-HH
	for ima@ietf.org; Mon, 28 Aug 2006 10:39:01 -0400
Received: from lon-mail-3.gradwell.net ([193.111.201.127])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHiGM-0001GD-Se
	for ima@ietf.org; Mon, 28 Aug 2006 10:39:01 -0400
Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk
	country=GB ident=postmaster^pop3&clerew#man^ac^uk)
	by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id
	44f2fff6.cc5.2ad; Mon, 28 Aug 2006 15:38:46 +0100
	(envelope-sender <chl@clerew.man.ac.uk>)
Received: from clerew.man.ac.uk (localhost [127.0.0.1])
	by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k7SEcgWO006503;
	Mon, 28 Aug 2006 15:38:43 +0100 (BST)
To: "Harald Alvestrand" <harald@alvestrand.no>, fujiwara@jprs.co.jp
Subject: Re: [EAI] IMAP and POP downgrade when SMTP downgrade would have
	bounced?
References: <44F2A08A.5060008@alvestrand.no>
	<20060828.173712.39178693.fujiwara@jprs.co.jp>
	<44F2AC0B.8040408@alvestrand.no>
Message-ID: <op.tez0aqhw6hl8nm@clerew.man.ac.uk>
Date: Mon, 28 Aug 2006 15:38:40 +0100
From: "Charles Lindsey" <chl@clerew.man.ac.uk>
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
In-Reply-To: <44F2AC0B.8040408@alvestrand.no>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

On Mon, 28 Aug 2006 09:40:43 +0100, Harald Alvestrand  
<harald@alvestrand.no> wrote:

> fujiwara@jprs.co.jp wrote:

>> Consider that From: header has a non-ASCII address without an
>> alternative US-ASCII address case.
>> After downgrading, original non-ASCII From: header is preserved in
>> Downgraded: header, but From: header becomes empty.
>>
>> Return-Path:, To:, CC: header have the same problem.
>>
>> Empty From: header or without From: header is allowed?
>>
> It is not allowed by RFC 2822.
>
> I had always thought that if you encountered a missing alt-addr in the  
> headers, the correct course was to bounce the message, rather than  
> deliver a message where "reply" would not work.
>
> I was surprised when I discovered the "remove the address" option in  
> -downgrade.
>
> What does the WG think desirable?

Whilst it might be impossible to deliver some message in UTF-8 form to  
some sites (because it could not be downgraded for some reason), what we  
have here is a case where it apparently _was_ delivered (or otherwise  
arrived in) some POP3 or IMAP box in UTF-8 form. In that case, I see no  
reason why the owner of that box should not process it in ayway he  
chooses, so if he asks to see it downgraded, then he will get whatever our  
downgrade document says. That may not be a valid RFC 2822 message (in  
which case it will fail to get anywhere if the box owner tries to resend  
it). But that is no reason why the box owner should not be shown the  
message. In IMAP, in particular, he may be able to fix the missing From  
line manually, and then resend it. But it would be nice if IMAP had warned  
him that the downgrade had produced a dubious message.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima



From ima-bounces@ietf.org Thu Aug 31 12:21:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GIpIB-00048d-Ge; Thu, 31 Aug 2006 12:21:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GIpI9-00048M-Ja
	for ima@ietf.org; Thu, 31 Aug 2006 12:21:21 -0400
Received: from lon-mail-4.gradwell.net ([193.111.201.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIpI5-0006d5-Og
	for ima@ietf.org; Thu, 31 Aug 2006 12:21:21 -0400
Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk
	country=GB ident=postmaster&pop3^clerew*man#ac&uk)
	by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.231) id
	44f70c7b.146a.3bf for ima@ietf.org; Thu, 31 Aug 2006 17:21:15 +0100
	(envelope-sender <chl@clerew.man.ac.uk>)
Received: from clerew.man.ac.uk (localhost [127.0.0.1])
	by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k7VGLET6008118
	for <ima@ietf.org>; Thu, 31 Aug 2006 17:21:15 +0100 (BST)
Date: Thu, 31 Aug 2006 17:21:12 +0100
To: ima@ietf.org
From: "Charles Lindsey" <chl@clerew.man.ac.uk>
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <op.te5o1m1b6hl8nm@clerew.man.ac.uk>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35
Subject: [EAI] Comments on draft-ietf-eai-utf8headers-01.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>,
	<mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org

Only just got around to looking at this in detail.

1.  Introduction

1.1.  Role of this specification

It needs one more bullet such as:

    o  The capability to use international characters in other headers, but  
only
       as expressly permitted herein, or in future extensions.

    ...  This form is permitted in transmission, if authorized
    by the SMTP extension specified in [EAI-SMTP-extension].

Add "or by other transport mechanisms capable of processing it".

[Note that it would already work just fine in UUCP, though care would be  
needed when gatewaying it into SMTP. It would also work fine in NNTP (I  
have heard suggestions that NNTP could be used for email).]

2.  Background and History

    The traditional format of email messages [RFC2822] only allows ASCII ...

s/only allows/allows only/

    that is connected to the SMTP message transport change described in

s/connected/related/

3.  Terminology

    In this document, header fields are "UTF-8 header" if the bodies of

s/"UTF-8 header"/"UTF-8 headers"/

4.  Pre-requirement

    The use of UTF-8 header fields is dependent on the use of an SMTP
    extension named "UTF8SMTP".

Add "or of similar capabilities in other transports".

s/Though there's nothing bad to use [RFC2047], but it is not
    recommended in this document.
   /Although there is nothing wrong with the continued use of [RFC2047],
    it is not recommended in this document./

5.  Identification of internationalized email

    When a SMTP client tries to send a mail to a SMTP server that does
    not support EAI, ...

s/EAI/UTF8SMTP/ here, and everywhere else in the document.

[The term "EAI" is unlikely to be widely understood (except as the name of  
this WG), or to come into widespread use.]

[I am not too happy with the term "UTF8SMTP" either (since other  
tramsports may use this format, and I would have preferred  
"UTF8-headers"). But that is the term we have agreed so far.]

    ... It is nice to have a mechanism ... to identify whether the
    message is new format ...

s/is new format/is in the new format/

    To be able to do so, sending MUA MUST insert a new header field to
    identify the presence of i18n information (particularly UTF-8
    headers) in the message.  The new header specified as "UTF8SMTP", and
    elements of the header is the version number of i18n email.  The i18n
    header field syntax specified as below:

I think the term "UTFSMTP" was intended to be the name of the new format  
(or the name of the capability agents would need in order to process it).  
So I don't think it is suitable as the name of the new header (I have  
suggested something like "Header-Type"). So I would suggest something more  
like:

    fields =/ header-type ; to anchor it into the syntax of RFC 2822

    header-type     = "Header-Type:" [FWS] content-code [FWS]
                      *( ";" parameter ) CRLF
    content-code    = "UTF8SMTP" / "ASCII" / "Downgraded"

And then you have to give semantics:
    "UTF8SMTP" indicates that the message is in the format defined by this
    document;
    "ASCII" indicates that it is in the format defined by RFC 2822 (and is  
the
    default when this header field is absent); and
    "Downgraded" indicates the same as "ASCII", but also that it was earlier
    downgraded from "UTF8SMTP".

BTW, I notice that you have forbidden comments in this header. Why was  
that?

    parameter       = "Header-Language:" [FWS] Language-List
    Language-List   = Language-Tag [FWS]
                      *("," [FWS] Language-Tag [FWS])

Here you have a choice. If you want to indicate the language by means of a  
<parameter>, then that will not work as you have shown it, because  
<parameter> is defined in RFC 2045 as ammended by RFC 2231, and has some  
[CFWS] hidden inside it (not obviously so, because it was defined in terms  
of RFC 822). So what you have written is not syntactically correct. The  
proper way to do it would be to say

    The only <parameter> defined by this document (others may be defined  
later,
    and SHOULD be ignored) is the header-language parameter, which has
       <attribute> "header-language"
       <value>     any <language-list>, where
    language-list   = Language-Tag *("," Language-Tag)

and then you have to point out that if there is more than one  
Language-Tag, the <value> has to be turned into a <quoted-string> because  
"," is a <tspecial> and cannot, therefore, appear in a <token>.

See section 3.2.8 of draft-ietf-usefor-usefor-09 for the correct way to do  
it (at least, we hope it is the correct way). But it all gets rather  
tedious :-( .

Your alternative is to define a new header field, similar to RFC 3282:

       field =/ Header-Language
       Header-Language = "Header-Language" ":" [CFWS] Language-List
       Language-List = Language-Tag [CFWS]
                          *("," [CFWS] Language-Tag [CFWS])

I think that is probably better, as it sits nicely beside the  
Content-Language header. However, you may still want to retain the  
<parameter>s in the Header-Type, just to allow some space for unforeseen  
needs, but with none defined in this document (we also did that in  
draft-ietf-usefor-usefor-09 in the case of the Archive header field).

    While we can't require ordering of headers, ...  Thus, when a i18n  
email is
    delivered.

s/delivered/generated/

    o  The "UTF8SMTP" header field MUST be inserted, along with Return-
       path, by the final delivery MTA if not presented.

s/if not presented/if not already present/

But there is a problem there. How is the final delivewry agent supposed to  
know? You cannot insist on a MUST if there is no obvious way to implement  
it. Scanning the headers looking for 8bit is not enough in the case of  
multipart and message types, which can contain further headers, possibly  
with 8bit in them, within the <body>.

If this situation arises, then there has already been a protocol error. If  
some subsequent agent knows how to recover from it, then good luck to it.  
But you cannot REQUIRE that behaviour.

    o  Whenever the email need to downgrade, the content-code of the
       "UTF8SMTP" MUST change to "Downgraded", the detail of downgrade
       process will describe in [EAI-downgrading].

s/need to downgrade/is downgraded/
s/will describe/will be described/

    o  If more than one "UTF8SMTP" header is presented, MTA SHOULD simply
       ignore any excess ones.

Again, this would be a protocol error (though possibly recoverable if they  
were the same). But RFC 2822 is careful to state which header fields are  
permitted to occur more than once (and there are only a few). Your  
document should say the same about any new header fields that it  
introduces.

6.  Changes on Message Header Fields

    SMTP client can send header fields in UTF-8 format, if the UTF8SMTP
    extension advertised by SMTP server.

Add "or as permitted by other transport mechanisms".

    For those tokens not referred in this section remains as the original
    definition in RFC 2822.

s/tokens/syntax rules/

6.1.  UTF8 Syntax

    These are taken from FRC 3629, but keep in this document for
    convenient reason.

s/keep/kept/
s/convenient reason/reasons of convenience/

6.2.  Syntax extend from RFC 2822

This section is now much improved, and sets the onus on future extensions  
to specify exactly where UTF-8 will be allowed.

6.3.  Change on addr-spec syntax

    alt-address    =  "{" [CFWS] addr-spec [CFWS] "}"

Several problems there.

It is ambiguous, because "{" and "}" are <utf8-atext>s. s/{/[/ and s/}/]/,  
and it will be OK.

I think you want a [CFWS] before the "{" (or "["). But you don't want  
those {CFWS] inside the "{...}", because the <addr-spec> already allows  
them to occur there.

What has happened to "downgradable" (aka "atomic")? I do not recall that  
we ever decided to do away with it. So I would expect to see:

    alt-address    =  [CFWS] "{" ( addr-spec / "downgradable" ) "}"

       "DISPLAY_NAME" <ASCII@ASCII>
          ; tradition mailbox format

s/tradition/traditional/

6.4.  Trace field syntax

    ... More
    generally, UTF-8 information of any sort MUST NOT appear in Received
    fields, even in comments within those fields.

Did we actually decide that? Chris Newman had a nice scheme for hiding  
"For" fields inside <comment>s.

7.1.  Mailing list header fields

    All mailing list and mail redistribution related header fields may
    need further discuss.

Yes, this needs doing. Wasn't somebody suppoed to be writing a Draft for  
mailing lists? I would have expected all those List-* headers which  
contain URIs (which is most of them) to be allowed to use IRIs instead  
(there is a well-known downgrade to URI available).

7.2.  MIME headers

    MIME header bodies (parameter <value> in [RFC2231]) need to allow
    UTF8 characters in conformance with this specification.

Yes, it is time we were getting on with this. Perhaps something like:

    The syntax of <value>, as defined in RFC 2045, is

    value = token / quoted-string

    In all those headers, such as Content-Type and Content-Dispoaition [and
    maybe our own UTF8SMTP/Header-Type, plus lots of others being defined in
    various other documents], which make use of <value>s within <parameter>s
    as defined in RFC 2045 as modified by RFC 2231, it will now be allowed
    to use <quoted-string>s containing UTF-8 characters (see the revised
    syntax of <qtext> in section 6.2 of this document).

It will then be up to our downgrade document to refer you to RFC 2231 for  
how to downgrade them.


8.  Security Considerations

    In this specification, a user could provide a ASCII alternative
    address for a non-ASCII address.  However, it is possible these two
    address going to different mailbox, or even different person.  This
    might not be the protocol problem, but user's personal choice (or
    administration policy).

s/a ASCII/an ASCII/
s/going to different mailbox, or even different person/
   go to different mailboxes, or even different persons/
s/the protocol problem/a protocol problem/
s/but user's/but the user's/

Also, you need to add something like "or it might be a deliberate attempt  
to deceive or cause confusion". You may be sure that spammers and scammers  
will exploit this loophole to the full :-( .

9.  IANA considerations

    IANA is requested to add the "UTF8SMTP" new header to the registry
    with the entry pointing to this specification for its definition.
    For those headers that modified in this document need to have their
    registrations modified, so as to refer to the specification in
    addition to their current definitions.

No, you need to provide a proper template for every header you have used  
(or even modified). See draft-ietf-usefor-usefor-09 for an example of how  
to do this.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima