From ima-bounces@ietf.org Mon Jul 03 05:43:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxKyA-00012a-6o; Mon, 03 Jul 2006 05:43:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FxKy9-00012O-1y
	for ima@ietf.org; Mon, 03 Jul 2006 05:43:53 -0400
Received: from twnic.net.tw ([211.72.210.250])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxKy7-0001s0-1c
	for ima@ietf.org; Mon, 03 Jul 2006 05:43:53 -0400
Received: from [211.72.211.93] (pc093.twnic.net.tw [211.72.211.93])
	(authenticated bits=0)
	by twnic.net.tw (8.13.6/8.13.5) with ESMTP id k639hct2029030;
	Mon, 3 Jul 2006 17:43:39 +0800
Message-ID: <44A8E8FD.4040705@twnic.net.tw>
Date: Mon, 03 Jul 2006 17:53:01 +0800
From: Jeff Yeh <jeff@twnic.net.tw>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Charles Lindsey <chl@clerew.man.ac.uk>
Subject: Re: [EAI] Comments on draft--eai-utf8headers-00
References: <op.tbys2fmn6hl8nm@clerew.man.ac.uk>
In-Reply-To: <op.tbys2fmn6hl8nm@clerew.man.ac.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44
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

Thank you for your precious comment.
I will fix the editorial change.
And some response below.

Jeff

Charles Lindsey wrote:
>    Sending MUAs that follow this protocol MUST create all header fields
>    encoded in UTF-8.  No other direct encodings are allowed.
>
> I don't see why stuff encoded by RFC 2047 should not be allowed. Not 
> particularly sensible if UTF8 is available, but you might, for 
> example, be replying to a message which already had RFC 2047 in its 
> Subject, and the easiest thing to do is just stick "Re:" on the front 
> of it (or maybe not even that).
Here we said "direct encoding" is some local encoding like Big5.
And I agree there's no bad for using RFC 2047. But, why use 2047 stuff 
if it can handle UTF8 natively?
FWIW, it will be good to have pure UTF8 mail environment in the future.
I'll put some note about RFC 2047 on this section.
>
> 5.  Identification of internationalized email
>
>    i-Email: 1.0
>
>    [Note in draft: There should be more useful information can be place
>    in the new header field. ]
>
> Yes indeed. I have suggested the following syntax:
>
>    header-content = "Header-Content:" [CFWS] content-code [CFWS]
>                         *( ";" parameter ) CRLF
> {point out that <parameter> brings some more [CFWS] with it)
>    content-code = "Utf8smtp" / "ASCII" / "Downgraded"
> which really needs to be followed by
>       Header-Language = "Header-Language" ":" [CFWS] Language-List
>       Language-List = Language-Tag [CFWS]
>                          *("," [CFWS] Language-Tag [CFWS])
> based in RFC 3282.
Good idea. Will put in next version.

>
> Of course, the following would need to be changed to suit. But there 
> are also some other issues:
>
>    o  The "i-Email" header field MUST be inserted by the originating
>       MUA.
>    o  The "i-Email" header field MUST be inserted, along with Return-
>       path, by the final delivery MTA if not presented.
>
> But how will the final delivery MTA know whether it is needed?
>
>    o  The "i-Email" header field, if present, MUST be removed as part of
>       any downgrading process that eliminates the UTF-8 header
>       information.
>    o  MTAs MAY check for duplicates of the "i-Email" header field and
>       eliminate all but one of them.  However, if a receiving MUA
>       encounters more than one of these headers, it SHOULD simply ignore
>       any excess ones.
>
> I think it is usually a bad idea for intermediate MTAs to try to 
> "correct" perceived mistakes in messages passing through them. If the 
> mistake is bad enough to break the system, then bounce it; othersise 
> pass it on. Experience with News suggested that systems which tried to 
> "correct" errors usually introduced more errors than they removed :-( .
In general case, MTA send what they got. Since sending MUA put the new 
header on when sending EAI messages.
However, if we like to make sure the new header is present.  Then this 
kind of process can not be avoided.
Recently we (TWNIC) are trying to implement a testbed of EAI. We found 
that we still have to look over all the possible place for UTF8, 
punycode and RFC 2047 stuff. I'm not that sure if this header is very 
much useful.
> 6.2.  Syntax extend from RFC 2822
>
> It's nice to see you adopted the syntax I suggested. Unfortunately, I 
> have spotted some problems :-( .
>
>    unstructured =  1*( [FWS] utext ) [FWS]
>
> Yes, that is the rule as it would be for Netnews. For email, it can be 
> empty. So:
>
>    unstructured =  *( [FWS] utext ) [FWS]
>
>
>    atext        =  ALPHA / DIGIT /
>                    "!" / "#" /     ; Any character except
>                    "$" / "%" /     ; controls, SP, and specials.
>                    "&" / "'" /     ; Used for atoms
>                    "*" / "+" /
>                    "-" / "/" /
>                    "=" / "?" /
>                    "^" / "_" /
>                    "`" / "{" /
>                    "|" / "}" /
>                    "~" /
>                    UTF8-xtra-char
>
> Here we have a problem, because that introduces Utf8 in atoms and 
> dot-atoms, which is fine for addrs-specs (where we waant it), but also 
> allows them in Message-ID and Received headers (where we most 
> certainly don't want it).
>
> There are two ways out of this:
> 1. use <strict-atom> etc for Message-ID and Received.
> 2. define a special <utf8-atom> etc for addr-spec.
>
> I leave it to you which to do, but I can see some benefit in using 
> approach #2, since we are going to tinker with the syntax of addr-spec 
> anyway, in order to include <alt-address> and "atomic".
Thank you precious information.  I'll try to do that in next version.
>
>    alt-separator  =  [FWS] "," [FWS]
>
> candidates for this are ",". ":" and "|", where "|" would require a 
> special syntax in place of <addr-spec> within <angle-addr> (though it 
> wold be OK within <alt-address>). I preter "|" over ":" and ":" over 
> "," (there are already too many other uses of "," within address-lists 
> and mailbox lists).
Yes, indeed. We found that "," leads more complexity on the mailbox 
parsing. And also "|" leads some potential confuse to pipe, some mail 
account are directly pipe to some shell script. The ":" is the separator 
of header name and header body, also possible to raise more complexity 
on parsing.  So, we are thinking about using "{", "}" to represent 
alt-address/atomic information. This will look like,
    "DISPLAY-NAME" <UTF8@UTF8 { ASCII@ASCII }>
This is obviously  better for programmers to parse the parameter, but 
I'm not sure if there's other limitation on "{" and "}".
>
> 7.  Additional issue
>
> I think you need to deal with the MIME headers here. In particular, 
> <value> (as used in <parameter>s) needs to allow Utf8 within it (with 
> RFC 2231 as the downgrade mechanism). <Token>s (being identifiers) 
> ahould, of course, remain in ASCII.
I don't quite get this problem. If a header value encoded with MIME, 
then it should be ASCII. Or I read your words wrong, please advice.
>
> 7.1.  Mailing list header fields
>
>    All mailing list and mail redistribution related header fields may
>    need further investigation.
>
> I agree. RFC 2369 and RFC 2919 are the relevants specs. RFC 2369 uses 
> URIs for everything, and these would naturally become IRIs (RFC 3987), 
> which already have a well-defined downgrade to URIs. I see that RFC 
> 2919 makes use of <phrase> and <dot-atom-tsxt> (so we need to decide 
> which kind of <dot-atom-text> that would be).
>    Because UTF-8 often requires several octets to encode a single
>    character, internationalized local parts may cause mail addresses to
>    become longer.  Then may possibly make it harder to keep lines in a
>    header under 78 octets.  Lines that are longer than 78 octets (which
>    is a SHOULD specification, not a MUST specification, in RFC 2822)
>    could possibly cause mail user agents to fail in ways that affect
>    security.
>
> I think you want to make it clear that the '78' limit is to be 
> expressed in characters, not in octets, since its purpose is to make 
> the text fit within the commonly used 80-character-wide windows. OTOH, 
> the '998' limit is definitely in octets, since it is related to the 
> size of buffers that implementors need to provide.
>
> There is a further security consideration which can arise if the utf8- 
> and alt- addresses point to totally different people. I am not sure 
> what sort of scam could make use of that, but spammers are, in 
> general, most skilled at exploiting any possible loophole, so I think 
> it needs to be mentioned.
Agree.
>
>
> 9.  IANA considerations
>
> All new headers that you invent need to be registered with IANA, in 
> accordance with RFC 3864. And any headers that you modify need to have 
> their registrations modified, so as to refer to your specification in 
> addition to their current definitions.
Will add in next version..


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



From ima-bounces@ietf.org Mon Jul 03 07:47:32 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxMtm-0002ew-Ad; Mon, 03 Jul 2006 07:47:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FxMtl-0002er-Gg
	for ima@ietf.org; Mon, 03 Jul 2006 07:47:29 -0400
Received: from [159.226.7.146] (helo=cnnic.cn)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxMte-0003uz-Qc
	for ima@ietf.org; Mon, 03 Jul 2006 07:47:29 -0400
Received: (eyou send program); Mon, 03 Jul 2006 19:46:43 +0800
Message-ID: <351927203.26040@cnnic.cn>
X-EYOUMAIL-SMTPAUTH: lee@cnnic.cn
Received: from unknown (HELO [159.226.203.118]) (127.0.0.1)
	by 127.0.0.1 with SMTP; Mon, 03 Jul 2006 19:46:43 +0800
Message-ID: <44A903A7.1010109@cnnic.cn>
Date: Mon, 03 Jul 2006 19:46:47 +0800
From: Xiaodong Lee <lee@cnnic.cn>
Organization: CNNIC
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Harald Alvestrand <harald@alvestrand.no>
Subject: Re: [EAI] List of EAI internet-drafts, as of today
References: <351651927.15925@cnnic.cn>
In-Reply-To: <351651927.15925@cnnic.cn>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: "ima@ietf.org" <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

hi,Authors,

Please prepare an presentation for your draft in Montreal meeting.

Regards!

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



Harald Alvestrand wrote:
> I believe the flurry of I-D announcements has largely subsided, so 
> it's likely that we have all the documents we will have before Montreal.
> The current list is:
>
> May 12 10:01 draft-ietf-eai-smtpext-00.txt
> May 31 11:32 draft-ietf-eai-imap-utf8-00.txt
> Jun  5 11:34 draft-ietf-eai-utf8headers-00.txt
> Jun 22 11:58 draft-ietf-eai-mailinglist-00.txt
> Jun 26 12:43 draft-ietf-eai-framework-01.txt
> Jun 28 12:54 draft-ietf-eai-pop-00.txt
> Jun 29 06:58 draft-ietf-eai-scenarios-01.txt
> Jun 29 07:54 draft-ietf-eai-downgrade-01.txt
>
> Happy reviewing!
>
>
>
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www1.ietf.org/mailman/listinfo/ima
>

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



From ima-bounces@ietf.org Mon Jul 03 09:47:30 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxOlt-0003q2-Pf; Mon, 03 Jul 2006 09:47:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FxOls-0003px-Us
	for ima@ietf.org; Mon, 03 Jul 2006 09:47:28 -0400
Received: from lon-mail-1.gradwell.net ([193.111.201.125])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxOlq-0005N8-5K
	for ima@ietf.org; Mon, 03 Jul 2006 09:47:28 -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.225) id
	44a91feb.10c9b.143c for ima@ietf.org; Mon,  3 Jul 2006 14:47:23 +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.4+Sun/8.13.4) with ESMTP id k63Dgldo009887
	for <ima@ietf.org>; Mon, 3 Jul 2006 14:42:48 +0100 (BST)
To: ima@ietf.org
Subject: Re: [EAI] Comments on draft--eai-utf8headers-00
References: <op.tbys2fmn6hl8nm@clerew.man.ac.uk>
	<44A8E8FD.4040705@twnic.net.tw>
Message-ID: <op.tb38dle76hl8nm@clerew.man.ac.uk>
Date: Mon, 03 Jul 2006 14:42:47 +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: <44A8E8FD.4040705@twnic.net.tw>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
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, 03 Jul 2006 10:53:01 +0100, Jeff Yeh <jeff@twnic.net.tw> wrote:

> Charles Lindsey wrote:
>>    Sending MUAs that follow this protocol MUST create all header fields
>>    encoded in UTF-8.  No other direct encodings are allowed.
>>
>> I don't see why stuff encoded by RFC 2047 should not be allowed. Not  
>> particularly sensible if UTF8 is available, but you might, for example,  
>> be replying to a message which already had RFC 2047 in its Subject, and  
>> the easiest thing to do is just stick "Re:" on the front of it (or  
>> maybe not even that).
> Here we said "direct encoding" is some local encoding like Big5.
> And I agree there's no bad for using RFC 2047. But, why use 2047 stuff  
> if it can handle UTF8 natively?

Ah! I had missed the significance of that word "direct". Sure, it would be  
stupid to use RFC 2047 when UTF-8 is available, but since when did people  
not do stupid things? They might be very attached to Big 5 :-).


>> I think it is usually a bad idea for intermediate MTAs to try to  
>> "correct" perceived mistakes in messages passing through them. If the  
>> mistake is bad enough to break the system, then bounce it; othersise  
>> pass it on. Experience with News suggested that systems which tried to  
>> "correct" errors usually introduced more errors than they removed :-( .
> In general case, MTA send what they got. Since sending MUA put the new  
> header on when sending EAI messages.

There is a general prohibition of multiple copies on the same header in  
RFC 2822, except for a very few exceptions (e.g. Keywords:). That should  
be maintained, but if some poor implementation breaks it, then it is  
better to leave it alone rather than to try to guess which was the "extra"  
one.

>> 6.2.  Syntax extend from RFC 2822
>>

>>    alt-separator  =  [FWS] "," [FWS]

> Yes, indeed. We found that "," leads more complexity on the mailbox  
> parsing. And also "|" leads some potential confuse to pipe, some mail  
> account are directly pipe to some shell script. The ":" is the separator  
> of header name and header body, also possible to raise more complexity  
> on parsing.  So, we are thinking about using "{", "}" to represent  
> alt-address/atomic information. This will look like,
>     "DISPLAY-NAME" <UTF8@UTF8 { ASCII@ASCII }>

Yes, I like that.


>> 7.  Additional issue
>>
>> I think you need to deal with the MIME headers here. In particular,  
>> <value> (as used in <parameter>s) needs to allow Utf8 within it (with  
>> RFC 2231 as the downgrade mechanism). <Token>s (being identifiers)  
>> ahould, of course, remain in ASCII.
> I don't quite get this problem. If a header value encoded with MIME,  
> then it should be ASCII. Or I read your words wrong, please advice.

The most obvious example is

    Content-Disposition: attachment; filename="some utf8 name"

but there could be others. Currently, you can encode these things  
according to RFC 2231 (which is a mess, but would still be needed for the  
downgrade).

-- 
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 Jul 04 03:46:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxfcV-0002xO-AS; Tue, 04 Jul 2006 03:46:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FxfcU-0002ww-Tp
	for ima@ietf.org; Tue, 04 Jul 2006 03:46:54 -0400
Received: from twnic.net.tw ([211.72.210.250])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxfah-00053R-B3
	for ima@ietf.org; Tue, 04 Jul 2006 03:45:07 -0400
Received: from [211.72.211.92] (pc092.twnic.net.tw [211.72.211.92])
	(authenticated bits=0)
	by twnic.net.tw (8.13.6/8.13.5) with ESMTP id k647iuiL015344
	for <ima@ietf.org>; Tue, 4 Jul 2006 15:44:58 +0800
Message-ID: <44AA1EAA.60500@twnic.net.tw>
Date: Tue, 04 Jul 2006 15:54:18 +0800
From: Jeff Yeh <jeff@twnic.net.tw>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: ima@ietf.org
References: <op.tbys2fmn6hl8nm@clerew.man.ac.uk>	<44A8E8FD.4040705@twnic.net.tw>
	<op.tb38dle76hl8nm@clerew.man.ac.uk>
In-Reply-To: <op.tb38dle76hl8nm@clerew.man.ac.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by twnic.net.tw id
	k647iuiL015344
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Subject: [EAI] alt-separator on utf8header
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 was discussed on previous thread=20
http://www1.ietf.org/mail-archive/web/ima/current/msg00432.html. But I'd=20
like to here other people's opinion.

In the utf8header document right now, we use ',' as the alt-separator.=20
TWNIC is recently working on EAI testbed implementation.We found that=20
"," leads more complexity on the mailbox parsing. And also "|" leads=20
some potential confuse to pipe, some mail account are directly pipe to=20
some shell script. The ":" is the separator of header name and header=20
body, also possible to raise more complexity on parsing. So, we are=20
thinking about using "{", "}" to represent alt-address/atomic=20
information. This will look like,
- "DISPLAY-NAME" <UTF8@UTF8 {ASCII@ASCII}> #EAI with ALT-ADDRESS
- "DISPLAY-NAME" <UTF8@UTF8 {ATOMIC}> #EAI with ATOMIC option
There are a few benefit I can see:
o not in RFC 2822 section 3.2.1 "specials" token
o making no confuse
o easier for program parsing
o can also be used in mailing list

There is another thing we though about, we use SMTP extension and new=20
parameter on SMTP protocol.
That looks like (SMTP protocol):
MAIL FROM: <=E8=91=89=E5=A3=AB=E8=B1=AA@=E5=8F=B0=E7=B6=B2=E4=B8=AD=E5=BF=
=83.tw> EAI-PARAMETER=3Djeff@twnic.net.tw
This is pretty much different to mail headers (2822 header). And make=20
the whole EAI solution more complex to implement due to various=20
representation of "addr-spec".
What if we use:
MAIL FORM: <=E8=91=89=E5=A3=AB=E8=B1=AA@=E5=8F=B0=E7=B6=B2=E4=B8=AD=E5=BF=
=83.tw {jeff@twnic.net.tw}>
We had try this on our testing server, works good.

I put some example after for your reference.
http://eai2.twnic.tw/smtp.png SMTP
http://eai2.twnic.tw/eai-downgrade-oe.jpg Outlook Express
http://eai2.twnic.tw/eai-downgrade-owm.png Openwebmail Display Style
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dbegin of example=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

Return-Path: <abelyang@twnic.net.tw>
Received: from eai1.twnic.tw (eai1.twnic.tw [211.72.210.249])
	by twnic.net.tw (8.13.6/8.13.5) with ESMTP id k646kT8a012789
	(version=3DTLSv1/SSLv3 cipher=3DDHE-RSA-AES256-SHA bits=3D256 verify=3DN=
O);
	Tue, 4 Jul 2006 14:46:29 +0800
Received: (from smmsp@localhost)
        by eai1.twnic.tw (8.13.6/8.13.6) id k646kTNK025669;
        Tue, 4 Jul 2006 14:46:29 +0800
Message-Id: <200607040646.k646kTNK025669@eai1.twnic.tw>
Received: from eai2.twnic.tw (log.twnic.net.tw [211.72.210.251])
	by eai1.twnic.tw (envelope-sender <abelyang@twnic.net.tw>) (MIMEDefang) =
with ESMTP id k646kLjH025667
	Tue, 04 Jul 2006 14:46:29 +0800 (CST)
Date: Tue, 04 Jul 2006 14:46:21 +0800
Downgraded: From:
	=3D?UTF8?B?IualiuemjuiRhiIgPOaliuemjuiRhkBlYWkxLnR3bmljLnR3IHthYmVseWFuZ
	0B0d25pYy5uZXQudHd9Pg=3D=3D?=3D
From: =3D?UTF8?B?IualiuemjuiRhiIg?=3D <iesg--q5vy06ah6h@eai1.twnic.tw>
Downgraded: To:
	=3D?UTF8?B?IuioseS5g+aWhyBFQUk9YXRvbWljIiA86Kix5LmD5paHQOWPsOe2suS4reW/g
	y50dyB7YXRvbWljfT4sICLokYnlo6vosaogRUFJPWF0b21pYyIgPOiRieWjq+ixqkDlj7D
	ntrLkuK3lv4MudHcge2F0b21pY30+LCAi6JGJ5aOr6LGqIEVBST1BTFQiIDzokYnlo6vos
	apA5Y+w57ay5Lit5b+DLnR3IHthYmVseWFuZ0Bkb3duZ3JhZGUudHduaWMudHd9PiwgIum
	Zs+eOieiQsSBFQUktUGFyYW1ldGVyPUFMVCIgPOiRieWjq+ixqkDlj7DntrLkuK3lv4Mud
	Hcge2VyaW5AdHduaWMubmV0LnR3fT4=3D?=3D
To: =3D?UTF8?B?IuioseS5g+aWhyBFQUk9YXRvbWljIiA=3D?=3D <iesg--1iq008cq3z@x=
n--fiq43lrrlz83a.tw>,
        =3D?UTF8?B?ICLokYnlo6vosaogRUFJPWF0b21pYyIg?=3D <iesg--zqs122hodf=
@xn--fiq43lrrlz83a.tw>,
        =3D?UTF8?B?ICLokYnlo6vosaogRUFJPUFMVCIg?=3D <iesg--zqs122hodf@xn-=
-fiq43lrrlz83a.tw>,
        =3D?UTF8?B?ICLpmbPnjonokLEgRUFJLVBhcmFtZXRlcj1BTFQiIA=3D=3D?=3D <=
iesg--zqs122hodf@xn--fiq43lrrlz83a.tw>
Subject: EAI Downgrade Testing Tue, 04 Jul 2006 14:46:21 +0800
MIME-Version: 1.0
Content-type: text/plain; charset=3Dutf-8
Content-transfer-encoding: 8bit
i-Email: 1.0

ABC
=E9=80=99=E8=A3=8F=E6=98=AF UTF8 =E7=B7=A8=E7=A2=BC,=E5=8F=AF=E4=BB=A5=E6=
=AD=A3=E5=B8=B8=E7=9C=8B=E8=A6=8B=E5=97=8E ?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dend of example=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Please provide your precious comment.

Best

Jeff Yeh
- TWNIC


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



From ima-bounces@ietf.org Tue Jul 04 07:58:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxjXg-0003I9-0T; Tue, 04 Jul 2006 07:58:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FxjXe-0003I4-Ma
	for ima@ietf.org; Tue, 04 Jul 2006 07:58:10 -0400
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxjXa-0001o7-9E
	for ima@ietf.org; Tue, 04 Jul 2006 07:58:10 -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-1.csi.cam.ac.uk ([131.111.8.51]:54420)
	by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25)
	with esmtpa (EXTERNAL:fanf2) id 1FxjXH-0004DF-1k (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 04 Jul 2006 12:57:47 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1FxjXC-0007k0-Fx (Exim 4.53)
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 04 Jul 2006 12:57:42 +0100
Date: Tue, 4 Jul 2006 12:57:42 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Jeff Yeh <jeff@twnic.net.tw>
Subject: Re: [EAI] alt-separator on utf8header
In-Reply-To: <44AA1EAA.60500@twnic.net.tw>
Message-ID: <Pine.LNX.4.64.0607041250090.4888@hermes-1.csi.cam.ac.uk>
References: <op.tbys2fmn6hl8nm@clerew.man.ac.uk>
	<44A8E8FD.4040705@twnic.net.tw>
	<op.tb38dle76hl8nm@clerew.man.ac.uk> <44AA1EAA.60500@twnic.net.tw>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED;
	BOUNDARY="1870869256-1188843716-1152014254=:4888"
Content-ID: <Pine.LNX.4.64.0607041257400.4888@hermes-1.csi.cam.ac.uk>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
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 message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1870869256-1188843716-1152014254=:4888
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <Pine.LNX.4.64.0607041257401.4888@hermes-1.csi.cam.ac.uk>

On Tue, 4 Jul 2006, Jeff Yeh wrote:
>
> In the utf8header document right now, we use ',' as the alt-separator.
> TWNIC is recently working on EAI testbed implementation. We found that
> "," leads more complexity on the mailbox parsing. And also "|" leads
> some potential confuse to pipe, some mail account are directly pipe to
> some shell script. The ":" is the separator of header name and header
> body, also possible to raise more complexity on parsing.

: is also used in header field bodies, in addres groups (which are
outside addr-specs) and in source routes (inside addr-specs). 822
parsing is already quite complicated :-)

> So, we are thinking about using "{", "}" to represent
> alt-address/atomic information. This will look like,
> - "DISPLAY-NAME" <UTF8@UTF8 {ASCII@ASCII}> #EAI with ALT-ADDRESS
> - "DISPLAY-NAME" <UTF8@UTF8 {ATOMIC}> #EAI with ATOMIC option
> There are a few benefit I can see:
> o not in RFC 2822 section 3.2.1 "specials" token

I think this is not a benefit, because the whole point of the special
characters is that they are used for this kind of thing! Non-special
characters are supposed to have no special syntactic meaning.

> MAIL FROM: <=E8=91=89=E5=A3=AB=E8=B1=AA@=E5=8F=B0=E7=B6=B2=E4=B8=AD=E5=BF=
=83.tw> EAI-PARAMETER=3Djeff@twnic.net.tw
> This is pretty much different to mail headers (2822 header). And make the
> whole EAI solution more complex to implement due to various representatio=
n of
> "addr-spec".
> What if we use:
> MAIL FORM: <=E8=91=89=E5=A3=AB=E8=B1=AA@=E5=8F=B0=E7=B6=B2=E4=B8=AD=E5=BF=
=83.tw {jeff@twnic.net.tw}>
> We had try this on our testing server, works good.

I've already said that I support using the same addr-spec syntax at both
the 821 and 822 levels.

Tony.
--=20
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
THAMES DOVER WIGHT PORTLAND PLYMOUTH: VARIABLE BECOMING WESTERLY 3 OR 4.
SHOWERS. MODERATE OCCASIONALLY POOR, WITH FOG PATCHES.
--1870869256-1188843716-1152014254=:4888
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

--1870869256-1188843716-1152014254=:4888--




From ima-bounces@ietf.org Tue Jul 04 12:21:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fxne7-0002a1-8J; Tue, 04 Jul 2006 12:21:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxne6-0002Zt-G1
	for ima@ietf.org; Tue, 04 Jul 2006 12:21:06 -0400
Received: from lon-mail-3.gradwell.net ([193.111.201.127])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxne3-0001Cm-Lk
	for ima@ietf.org; Tue, 04 Jul 2006 12:21:06 -0400
Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk
	country=GB)
	by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.225) id
	44aa9563.df83.1f2 for ima@ietf.org; Tue,  4 Jul 2006 17:20:51 +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.4+Sun/8.13.4) with ESMTP id k64DLa7k008166
	for <ima@ietf.org>; Tue, 4 Jul 2006 14:21:37 +0100 (BST)
To: ima@ietf.org
Subject: Re: [EAI] alt-separator on utf8header
References: <op.tbys2fmn6hl8nm@clerew.man.ac.uk>
	<44A8E8FD.4040705@twnic.net.tw>
	<op.tb38dle76hl8nm@clerew.man.ac.uk> <44AA1EAA.60500@twnic.net.tw>
Message-ID: <op.tb512ak56hl8nm@clerew.man.ac.uk>
Date: Tue, 04 Jul 2006 14:21:36 +0100
From: "Charles Lindsey" <chl@clerew.man.ac.uk>
Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
In-Reply-To: <44AA1EAA.60500@twnic.net.tw>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
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, 04 Jul 2006 08:54:18 +0100, Jeff Yeh <jeff@twnic.net.tw> wrote:


> - "DISPLAY-NAME" <UTF8@UTF8 {ASCII@ASCII}> #EAI with ALT-ADDRESS
> - "DISPLAY-NAME" <UTF8@UTF8 {ATOMIC}> #EAI with ATOMIC option
> There are a few benefit I can see:
> o not in RFC 2822 section 3.2.1 "specials" token
> o making no confuse
> o easier for program parsing
> o can also be used in mailing list

And you can add to that:

   o doesn't need any [FWS] around it to make it stand out (like '|' might  
have done).

> What if we use:
> MAIL FORM: <葉士豪@台網中心.tw {jeff@twnic.net.tw}>

Much to my surprise, my MUA rendered those chinese characters (at double  
width). The only problem was that the '@' in the middle got lost (looked  
just like another chinese character) :-( .

> We had try this on our testing server, works good.

I think the only problem with this is that it breaks the current RFC 2821  
syntax for parameters to commands. So you will have to fight John on that  
one.

-- 
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 Jul 04 12:23:48 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fxngi-0003Q3-6Z; Tue, 04 Jul 2006 12:23:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxngh-0003PV-6t
	for ima@ietf.org; Tue, 04 Jul 2006 12:23:47 -0400
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxngc-0001h6-Tm
	for ima@ietf.org; Tue, 04 Jul 2006 12:23:47 -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-1.csi.cam.ac.uk ([131.111.8.51]:41924)
	by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25)
	with esmtpa (EXTERNAL:fanf2) id 1FxngK-0000JF-03 (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 04 Jul 2006 17:23:24 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1FxngJ-0000ZC-Vb (Exim 4.53)
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 04 Jul 2006 17:23:23 +0100
Date: Tue, 4 Jul 2006 17:23:23 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Charles Lindsey <chl@clerew.man.ac.uk>
Subject: Re: [EAI] alt-separator on utf8header
In-Reply-To: <op.tb512ak56hl8nm@clerew.man.ac.uk>
Message-ID: <Pine.LNX.4.64.0607041722510.4888@hermes-1.csi.cam.ac.uk>
References: <op.tbys2fmn6hl8nm@clerew.man.ac.uk>
	<44A8E8FD.4040705@twnic.net.tw>
	<op.tb38dle76hl8nm@clerew.man.ac.uk> <44AA1EAA.60500@twnic.net.tw>
	<op.tb512ak56hl8nm@clerew.man.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
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, 4 Jul 2006, Charles Lindsey wrote:
>
> I think the only problem with this is that it breaks the current RFC 2821
> syntax for parameters to commands. So you will have to fight John on that one.

And IMAs don't?!

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
DOVER WIGHT PORTLAND PLYMOUTH: VARIABLE BECOMING SOUTHWEST 3 OR 4. THUNDERY
SHOWERS. MODERATE OR GOOD WITH FOG PATCHES IN PLYMOUTH.

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



From ima-bounces@ietf.org Tue Jul 04 16:48:24 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fxrog-00017P-Ud; Tue, 04 Jul 2006 16:48:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxrof-00017K-Dd
	for ima@ietf.org; Tue, 04 Jul 2006 16:48:17 -0400
Received: from lon-mail-3.gradwell.net ([193.111.201.127])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxroc-0002Mk-Sr
	for ima@ietf.org; Tue, 04 Jul 2006 16:48:17 -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.225) id
	44aad402.1113.129; Tue,  4 Jul 2006 21:48:02 +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.4+Sun/8.13.4) with ESMTP id k64GjYuW018485;
	Tue, 4 Jul 2006 17:45:35 +0100 (BST)
To: "Tony Finch" <dot@dotat.at>
Subject: Re: [EAI] alt-separator on utf8header
References: <op.tbys2fmn6hl8nm@clerew.man.ac.uk>
	<44A8E8FD.4040705@twnic.net.tw>
	<op.tb38dle76hl8nm@clerew.man.ac.uk> <44AA1EAA.60500@twnic.net.tw>
	<op.tb512ak56hl8nm@clerew.man.ac.uk>
	<Pine.LNX.4.64.0607041722510.4888@hermes-1.csi.cam.ac.uk>
Message-ID: <op.tb6bh7mj6hl8nm@clerew.man.ac.uk>
Date: Tue, 04 Jul 2006 17:45:33 +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.0607041722510.4888@hermes-1.csi.cam.ac.uk>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
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, 04 Jul 2006 17:23:23 +0100, Tony Finch <dot@dotat.at> wrote:

> On Tue, 4 Jul 2006, Charles Lindsey wrote:
>>
>> I think the only problem with this is that it breaks the current RFC  
>> 2821
>> syntax for parameters to commands. So you will have to fight John on  
>> that one.
>
> And IMAs don't?!

Not in the same way. The present proposal still fits within the basic  
syntax of RFC 2821 commands (just widens the character set a little). John  
tends to be a little protective of RFC 2821 (quite naturally :-).

I would have no problem with the change, but then I am not particularly au  
fait with the finer points of 2821.

-- 
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 Jul 04 17:24:32 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxsNj-0006AN-DX; Tue, 04 Jul 2006 17:24:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FxsNh-0006AI-VM
	for ima@ietf.org; Tue, 04 Jul 2006 17:24:29 -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 1FxsNg-0004Kw-Jk
	for ima@ietf.org; Tue, 04 Jul 2006 17:24:29 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1FxsNf-000Kzr-MB; Tue, 04 Jul 2006 17:24:27 -0400
Date: Tue, 04 Jul 2006 17:24:26 -0400
From: John C Klensin <klensin@jck.com>
To: Tony Finch <dot@dotat.at>
Subject: Re: [EAI] IMA representation in envelope and header
Message-ID: <6079D0974D4BCFA41A0142D6@p3.JCK.COM>
In-Reply-To: <Pine.LNX.4.64.0606261535150.4888@hermes-1.csi.cam.ac.uk>
References: <Pine.LNX.4.64.0606261535150.4888@hermes-1.csi.cam.ac
 .uk>
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: 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 Monday, 26 June, 2006 15:42 +0100 Tony Finch <dot@dotat.at>
wrote:

> draft-klensin-emailaddr-i18n-03 says:
> 
>    4.  If internationalization is to be plausible, it is
> critical that        addressing information be represented in
> essentially the same way        in the message envelope (i.e.,
> the SMTP command structure) and        the message body (i.e.,
> both message headers and, where feasible,        message
> text).  Different encodings in different places,
> especially ones that are copied  back and forth, will make both
>        mail system maintainers and operators and end users
> very unhappy.
> 
> We currently have the beginnings of a syntax for i14ed
> addresses with downgrade information in the message header,
> which is different from the representation in the message
> envelope. I suggest that the forward-path and reverse-path
> parts of MAIL and RCPT commands should include the downgrade
> information using essentially the same syntax as in the message
> header, instead of separating it into extension parameters.

Tony,

This may or may not be a good idea -- see note to be posted in a
few minutes -- but don't cite draft-klensin-emailadder-i18n as
justification.  First, it has been replaced by other drafts, is
not on the WGs agenda or authoritative in any other way.
Second, most or all of the changes made since it was posted were
made for a reason.  And finally, and most important, that
section refers to encoding and not the syntax in which it is
embedded.   If one were using some sort of ACE or hexification
in the envelope but UTF-8 in the headers, that would violate the
principle as stated.  Doing something different in terms of
syntax in the headers than the envelope does not: those syntaxes
differ already, with address list in headers and separate RCPT
commands in envelope, with required pointed brackets in the
envelope and optional ones in the headers, etc.

    john


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



From ima-bounces@ietf.org Tue Jul 04 17:36:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxsZi-0007Kv-Ed; Tue, 04 Jul 2006 17:36:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FxsZh-0007Ka-B5
	for ima@ietf.org; Tue, 04 Jul 2006 17:36:53 -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 1FxsZf-00059F-UI
	for ima@ietf.org; Tue, 04 Jul 2006 17:36:53 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1FxsZe-000L3J-Ad; Tue, 04 Jul 2006 17:36:50 -0400
Date: Tue, 04 Jul 2006 17:36:49 -0400
From: John C Klensin <klensin@jck.com>
To: Charles Lindsey <chl@clerew.man.ac.uk>, Tony Finch <dot@dotat.at>
Subject: Re: [EAI] alt-separator on utf8header
Message-ID: <9279CDD8146DA5E7C2FB9E44@p3.JCK.COM>
In-Reply-To: <op.tb6bh7mj6hl8nm@clerew.man.ac.uk>
References: <op.tbys2fmn6hl8nm@clerew.man.ac.uk>
	<44A8E8FD.4040705@twnic.net.tw>
	<op.tb38dle76hl8nm@clerew.man.ac.uk>
	<44AA1EAA.60500@twnic.net.tw>	<op.tb512ak56hl8nm@clerew.man.ac.uk>
	<Pine.LNX.4.64.0607041722510.4888@hermes-1.csi.cam.ac.uk>
	<op.tb6bh7mj6hl8nm@clerew.man.ac.uk>
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: f607d15ccc2bc4eaf3ade8ffa8af02a0
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 Tuesday, 04 July, 2006 17:45 +0100 Charles Lindsey
<chl@clerew.man.ac.uk> wrote:

> On Tue, 04 Jul 2006 17:23:23 +0100, Tony Finch <dot@dotat.at>
> wrote:
> 
>> On Tue, 4 Jul 2006, Charles Lindsey wrote:
>>> 
>>> I think the only problem with this is that it breaks the
>>> current RFC   2821
>>> syntax for parameters to commands. So you will have to fight
>>> John on   that one.
>> 
>> And IMAs don't?!
> 
> Not in the same way. The present proposal still fits within
> the basic  syntax of RFC 2821 commands (just widens the
> character set a little). John  tends to be a little protective
> of RFC 2821 (quite naturally :-).
> 
> I would have no problem with the change, but then I am not
> particularly au  fait with the finer points of 2821.

I am really less protective of 2821 than I am about the edge
conditions encountered with existing systems and parsers.  2821
is deliberately very specific about the possible syntax of
extensions in order to permit implementations to lexically
analyze/ tokenize SMTP commands without (prior to) establishing
state via whatever options have been offered or accepted.  Note,
in this regard, that several (at least) SMTP-receiver
implementations provide code support for options whose
availability in operation depends on configuration options.  One
can even imagine offering some options to some SMTP-senders and
not others.

Depending on how much implementations take advantage of these
flexibilities built into 2821, this could turn out to be a very
significant change.

In that regard, note that a "never downgrade, bounce if needed"
implementation of our work requires no parser changes if the
alternative address/ atomic info is in parameters.  Depending on
how SMTPext is written, it might not even need to recognize the
parameters themselves (although I'd recommend against that and
recognizing them is fairly trivial).  By contrast, tampering
with what appears between the <...> requires parser changes even
if one does not intend to use the information.

And, FWIW, one of my personal goals in this is to make/ keep it
as simple as possible to support i18n addressing in existing
MTAs that are otherwise 8bit-clean.  Requiring parser changes in
all cases doesn't facilitate that.

So, yes, I'm not happy about the idea.  But only a small
fraction of my unhappiness involves defending 2821.

     john


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



From ima-bounces@ietf.org Tue Jul 04 19:07:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fxtyv-0006wF-GW; Tue, 04 Jul 2006 19:07:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxtyv-0006vv-0G
	for ima@ietf.org; Tue, 04 Jul 2006 19:07:01 -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 1Fxtyt-0005rw-46
	for ima@ietf.org; Tue, 04 Jul 2006 19:07:00 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1Fxtyr-000LNs-S4; Tue, 04 Jul 2006 19:06:58 -0400
Date: Tue, 04 Jul 2006 19:06:56 -0400
From: John C Klensin <klensin@jck.com>
To: Charles Lindsey <chl@clerew.man.ac.uk>, ima@ietf.org
Subject: ATOMIC and downgrading (was: Re: [EAI] Comments on
	draft-ietf-eai-downgrading.00)
Message-ID: <12E0F02D97361FD7DEED87B0@p3.JCK.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: 0.0 (/)
X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd
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

Sorry for the delay but a few comments on this general situation
(I have omitted significant material, indicating  either that I
agree with you or have nothing to add at this point.)

--On Thursday, 15 June, 2006 21:55 +0100 Charles Lindsey
<chl@clerew.man.ac.uk> wrote:

>      Downgrading mechanism for Internationalized eMail Address
> (IMA)
>...

>     In this document, an address is "all-ASCII" if every
> character in the
>     address is in the ASCII character repertoire [ASCII]; an
> address is
>     "non-ASCII" if any character is not in the ASCII character
>     repertoire.  The term "all-ASCII" is also applied to other
> protocol
>     elements when the distinction is important, with
> "non-ASCII" or
>     "internationalized" as its opposite.
> 
> s/ASCII/US-ASCII/ in two places.

For convenience of reading and understanding, I'd think this
should be changed only in the citation and reference.  Sloppy
writing aside, ASCII really is the "American Standard Code for
Information Interchange".   With apologies to my Canadian and
Mexican colleagues (CSCII?  MSCII?) and those further south, the
term is unambiguous and "US-ASCII" is hard to read and causes,
rather than reduces, confusion.

> 4.  SMTP Downgrading
>...
  
>     If downgrading is expected, mail sender MUA MUST append
> ALT-ADDR or
>     ATOMIC option to all IMA envelope addresses to denote
> alternative US-
>     ASCII address when sending mail.
> 
> No, I don't think that is right. There is no "MUST" about it.
> If you
> want your message to get through without bouncing, then you
> would be
> *well-advised* to ensure that an ALT-ADDRESS was provided or
> ATOMIC was specified.

Concur, although I think even that language may need further
tuning... see below.

> I found the next few paragraphs rather confusing. It needs to
> be made
> clear exactly what addresses are to be passed on in the MAIL
> FROM and
> RCPT TO in all the possible circumstances. I found what
> Yangwoo Ko wrote
> on June 4th rather helpful in clarifying the situation, and
> from what he
> said I derived the following chart:
> 
> 
>             ALT-ADDRESS available
>                Y            N
>          ---------------------------
>          |            |            |
>         Y|  use ALT-  | do ACE     |
>          |  ADDRESS   | conversion |
>          |            |            |
> ATOMIC  |-------------------------|
>          |            | downgrade  |
>         N|  use ALT-  | not        |
>          |  ADDRESS   | possible   |
>          |            | (bounce)   |
>          ---------------------------
> 
> which shows that ATOMIC is meaningless if an ALT-ADDRESS is
> provided,
> and also that "ATOMIC" would be better called something like
> "DOWNGRADABLE", as Yangwoo Ko suggested.

This is also a strong argument for simply prohibiting the
specification of both ATOMIC and ALT-ADDRESS.  One or the other
or neither, but not both.    I believe that we concluded during
the interim meeting that SMTPext and Framework should be
modified to reflect that view, so this may be an historical
artifact.

> Anyway, I would you include a chart like that, and then
> explain how to
> use the ALT-ADDRESS, and how to do ACE-conversion.

>     Alternative US-ASCII address generation algorithms are
> below:
>     domain-part: Punycode/IDNA [RFC3490]
>     local-part: Punycode[RFC3492] without normalization.
> Prefix MUST be
>        assigned by IANA (which is not "xn--").

These two don't work.  Even without normalization, punycode
would cause case folding, which has traditionally been
prohibited in email.  Adam Costello proposed a way around that
some time ago but, if we are going to use it, we are going to
need to do considerably more documentation and specfication than
saying "Punycode without normalization".

> Well that doesn't seem right, but when I looked into RFCs
> 3490, 3491 and
> 3492 I found such a can of worms that I need to look into it
> more
> deeply, so I shall deal with that in a separate message.

I assume the above describes some of the worms you found.

>     MTA replaces IMA with specified or generated alternative
> US-ASCII
>     address.  Then appends replaced information with
> IMA-Downgraded-From
>     and IMA-Downgraded-To header in mail header (outgoing SMTP
> DATA).
>        IMA-Downgraded-From: <IMA> <US-ASCII>
>        IMA-Downgraded-To: <IMA> <US-ASCII>
> 
> It is not clear to me how this is supposed to work. How am I
> to know
> whether it was the MAIL FROM: or one of the (many) RCPT TO:
> commands
> that was downgraded? Surely that needs to be indicated in
> those headers
> somewhere. OTOH, I am not yet convinced that we actually needs
> those headers at all.

Yes to both.   I also believe that, for _any_ new header, the
document must include an analysis of what the risks are if some
or all of those headers are dropped in transit.

>...

> 5.  SMTP DATA/Header downgrading
> 
> Actually, this section has not much to do with SMTP, since it
> might be
> called upon in all sorts of other parts of various protocols
> (including
> other transports). Yes, I agree that the common case will be
> when
> dealing with the DATA command in SMTP.
> 
> 
>     In this section, four methods for SMTP DATA/Header
> downgrading is
>     proposed.  Working group should select one.
> 
>     o  No header downgrading
>     o  Encapsulating whole SMTP DATA
>     o  Translating each header
>     o  Encapsulating each header
> 
> I think it is pretty clear that the WG is going to select #3,
> with maybe a little bit of #4 in special situations.

It is not yet clear to me, actually.  I hope there is some
specific discussion on this topic in Montreal.

In particular, I am waiting for someone to do the analysis for
what "translating" headers does to protocols and specifications
that rely on digital signatures over some or all headers, such
as DKIM.

>     Trace headers: Received headers which contains IMA MUST be
> target of        downgrading.

> I have no problem with that (for comments anyway), but John
> doesn't seem to like it :-( .

John is still trying to figure out how to get around the
absolute prohibition on modifying earlier trace fields, which is
there for a reason and after much sad experience.  One way is to
decide that any system that does downgrading is actually a
gateway.  That has other implications, of course.

> 5.2.  Downgrading with MIME encapsulation
> 
>     This downgrade method requires new MIME 'Content-Type:'
> which express
>     EAI(Email Address Internationalization).  This document
> assumes
>     'Content-Type: Message/EAI' existence.
> 
> It would need to be a Content-Type which really ensured that
> the whole
> messages was encoded (message/rfc822 would certainly not be
> good
> enough). There is an application/news-transmission already
> defined which
> does exactly the right thing.

How does "application/news-transmission" handle the multiple
encoding prohibition?  Also, forgive my ignorance, but in what
standards-track document is it defined?  (If we are to use it
here, it will have to be a normative reference and, if we are to
have problems in that area, we had best start sorting out the
issues).  I've been assuming that we were going to need
something more like

   multipart/message-eai
      message/converted-eai-headers
      multipart/mixed    or  text/...  or .../...

> However, I do not like this method, since it may cause all
> sorts of
> problems on arrival, and also it splits the Received headers
> into two
> separate places, separating those which were inserted before
> the
> downgrade from those which were inserted after (so it breaks
> RFC 2821 anyway).

yep.  From my point of view, that is yet another reason to avoid
putting any UTF-8 material into Received headers.  If none
exists, then the Received headers can be left alone (at the top
of the external headers) and used to document the downgrading,
while everything else goes into the converted/ encapsulated
headers.

> 6.  Implementation consideration
> 
> 6.1.  MUA
> 
>     MUA MAY encode UTF-8 in Subject header with the same
> encoding of body
>     part while downgrading.
> 
> I am not sure I like that. Has it been discussed already?

No, it has not been discussed, at least while I was paying
attention.

>     4.  If MDA detects that SMTP recipient address is
> downgraded IMA,
>         then MDA MUST decode IMA and perform the same
> processing as if it
>         were IMA.  MDA MAY normalize or canonicalize
> local-part before
>         processing it.
> 
> s/downgraded/ACE-downgraded/ (because if it was ALT-ADDRESS
> downgraded
> you cannot do this - it is essentially the same as case #2
> above). And
> the MUST is probably too strong.

There is not really a guarantee that the ACE encoding is
accurately reversable  (and anything involving canonicalization,
normalization, case-folding, etc., certainly will not be).

    john



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



From ima-bounces@ietf.org Wed Jul 05 06:19:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fy4Tm-0008Uh-I1; Wed, 05 Jul 2006 06:19:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy4Tk-0008Uc-JG
	for ima@ietf.org; Wed, 05 Jul 2006 06:19:32 -0400
Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy4Tg-0004o0-9d
	for ima@ietf.org; Wed, 05 Jul 2006 06:19:32 -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-1.csi.cam.ac.uk ([131.111.8.51]:54109)
	by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25)
	with esmtpa (EXTERNAL:fanf2) id 1Fy4Ta-0000Lj-Tt (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Wed, 05 Jul 2006 11:19:22 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1Fy4Ta-0003Fu-5p (Exim 4.53)
	(return-path <fanf2@hermes.cam.ac.uk>); Wed, 05 Jul 2006 11:19:22 +0100
Date: Wed, 5 Jul 2006 11:19:22 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: John C Klensin <klensin@jck.com>
Subject: Re: [EAI] alt-separator on utf8header
In-Reply-To: <9279CDD8146DA5E7C2FB9E44@p3.JCK.COM>
Message-ID: <Pine.LNX.4.64.0607051109490.4888@hermes-1.csi.cam.ac.uk>
References: <op.tbys2fmn6hl8nm@clerew.man.ac.uk>
	<44A8E8FD.4040705@twnic.net.tw>
	<op.tb38dle76hl8nm@clerew.man.ac.uk> <44AA1EAA.60500@twnic.net.tw>
	<op.tb512ak56hl8nm@clerew.man.ac.uk>
	<Pine.LNX.4.64.0607041722510.4888@hermes-1.csi.cam.ac.uk>
	<op.tb6bh7mj6hl8nm@clerew.man.ac.uk>
	<9279CDD8146DA5E7C2FB9E44@p3.JCK.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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

On Tue, 4 Jul 2006, John C Klensin wrote:
>
> And, FWIW, one of my personal goals in this is to make/ keep it as
> simple as possible to support i18n addressing in existing MTAs that are
> otherwise 8bit-clean.  Requiring parser changes in all cases doesn't
> facilitate that.

I don't think you can avoid parser changes, because MTAs will have to be
modified to allow top-bit-set characters in forward and reverse paths.
They will in any case have to have modified 2822 parsers so that they can
implement header checks and fix-ups, for message submission mode as well
as for downgrading.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FAIR ISLE: SOUTH OR SOUTHEAST 3 OR 4, OCCASIONALLY 5 LATER. RAIN OR SHOWERS
LATER. MODERATE OR GOOD, WITH FOG PATCHES.

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



From ima-bounces@ietf.org Wed Jul 05 06:46:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fy4th-0007Ff-C7; Wed, 05 Jul 2006 06:46:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy4tf-0007Cc-D6
	for ima@ietf.org; Wed, 05 Jul 2006 06:46:19 -0400
Received: from lon-mail-4.gradwell.net ([193.111.201.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy4tc-0008PZ-FQ
	for ima@ietf.org; Wed, 05 Jul 2006 06:46:19 -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.225) id
	44ab9876.101e2.75f for ima@ietf.org; Wed,  5 Jul 2006 11:46:14 +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 k65AkABR019741
	for <ima@ietf.org>; Wed, 5 Jul 2006 11:46:11 +0100 (BST)
Date: Wed, 05 Jul 2006 11:46:10 +0100
To: ima@ietf.org
Subject: Re: ATOMIC and downgrading (was: Re: [EAI] Comments on
	draft-ietf-eai-downgrading.00)
References: <12E0F02D97361FD7DEED87B0@p3.JCK.COM>
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.tb7pi80g6hl8nm@clerew.man.ac.uk>
In-Reply-To: <12E0F02D97361FD7DEED87B0@p3.JCK.COM>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
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, 05 Jul 2006 00:06:56 +0100, John C Klensin <klensin@jck.com> wrote:

> --On Thursday, 15 June, 2006 21:55 +0100 Charles Lindsey
> <chl@clerew.man.ac.uk> wrote:

>> s/ASCII/US-ASCII/ in two places.
>
> For convenience of reading and understanding, I'd think this
> should be changed only in the citation and reference.  Sloppy
> writing aside, ASCII really is the "American Standard Code for
> Information Interchange".

I am sure I remember reading some RFC which declared that IETF policy was  
to use US-ASCII rather than ASCII in all official documents. But I have  
not managed to locate it (beyond a mention in RFC 1700, which is not the  
one I had in mind). But for sure somebody in Montreal will know.

>
>> 4.  SMTP Downgrading


>>        IMA-Downgraded-From: <IMA> <US-ASCII>
>>        IMA-Downgraded-To: <IMA> <US-ASCII>
>>

> Yes to both.   I also believe that, for _any_ new header, the
> document must include an analysis of what the risks are if some
> or all of those headers are dropped in transit.

It shouldn't happen, but if it does then we should arrange that the worst  
that happens is that some information gets lost (e.g. the history of what  
some pre-downgraded header looked like). Jeff's recent example was fine.

>> 5.  SMTP DATA/Header downgrading

> In particular, I am waiting for someone to do the analysis for
> what "translating" headers does to protocols and specifications
> that rely on digital signatures over some or all headers, such
> as DKIM.

Undoubtedly some of those protocols are going to break, and there is not  
much we can do about it. OTOH, signing mechanisms CAN be invented which  
will survive downgrading, but they need to employ a pretty aggressive  
canonicalization. I wrote such a proposal once  
(http://www.imc.org/ietf-usefor/drafts/draft-lindsey-usefor-signed-01.txt).
>
>>     Trace headers: Received headers which contains IMA MUST be
>> target of        downgrading.
>
>> I have no problem with that (for comments anyway), but John
>> doesn't seem to like it :-( .
>
> John is still trying to figure out how to get around the
> absolute prohibition on modifying earlier trace fields, which is
> there for a reason and after much sad experience.  One way is to
> decide that any system that does downgrading is actually a
> gateway.  That has other implications, of course.

If the only place where UTF-8 is allowed in within the comments within  
Received headers, then you simply say that they MUST always be  
RFC2047-encoded (even when generated by a UTF8SMTP-compliant agent). Then  
there is never any need to change them en route.

OTOH, I still do not see what harm would come from allowing this simple  
downgrade en route.
>
>> 5.2.  Downgrading with MIME encapsulation

> How does "application/news-transmission" handle the multiple
> encoding prohibition?  Also, forgive my ignorance, but in what
> standards-track document is it defined?  (If we are to use it
> here, it will have to be a normative reference and, if we are to
> have problems in that area, we had best start sorting out the
> issues).  I've been assuming that we were going to need
> something more like

It simply wraps the whole 8bit object up in one bundle (without regard to  
its internal structure), and then applies a CTE (Q-P or Base64) to it. So  
it is totally foolproof - not that I am actually recommending it other  
than as a proof-of-concept. It is already registered with IANA (bt Henry  
Spencer), and the upcoming USEPRO (part of the USEFOR effort) will simply  
confirm its existing definition (well, with a couple of irrelevant extra  
options).
>
>    multipart/message-eai
>       message/converted-eai-headers
>       multipart/mixed    or  text/...  or .../...

No, that is all far too complicated. All that needs to be done is to state  
that message/rfc822 objects can contain Utf8smtp headers (provided they  
include the "Header-Content: UTF8SMTP" or whatever). And provided that  
agents which need to downgrade watch out for this situation and apply the  
downgrade to the message/rfc822 as well (or bounce if they cannot be  
bothered). Actually, if they don't, the message will still get through  
unless it encounters a non-8BITMIME MTA en route, and there are very few  
of those left around these days.

>> 6.  Implementation consideration
>>

>>     4.  If MDA detects that SMTP recipient address is
>> downgraded IMA,
>>         then MDA MUST decode IMA and perform the same
>> processing as if it
>>         were IMA.  MDA MAY normalize or canonicalize
>> local-part before
>>         processing it.
>>
>> s/downgraded/ACE-downgraded/ (because if it was ALT-ADDRESS
>> downgraded...
>
> There is not really a guarantee that the ACE encoding is
> accurately reversable  (and anything involving canonicalization,
> normalization, case-folding, etc., certainly will not be).

I think it essential that we define ACE encoding to be fully reversible.  
Tricky, perhaps, but not impossible.

-- 
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 Jul 05 09:01:32 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fy70S-0004Fw-9N; Wed, 05 Jul 2006 09:01:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy70R-0004Fr-8r
	for ima@ietf.org; Wed, 05 Jul 2006 09:01:27 -0400
Received: from 206-169-26-130.static.twtelecom.net ([206.169.26.130]
	helo=mail.optistreams.net) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fy70P-0003yU-Sl for ima@ietf.org; Wed, 05 Jul 2006 09:01:27 -0400
In-Reply-To: <op.tb7pi80g6hl8nm@clerew.man.ac.uk>
References: <12E0F02D97361FD7DEED87B0@p3.JCK.COM>
	<op.tb7pi80g6hl8nm@clerew.man.ac.uk>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <d8b1c8feaf270b32bd4d90c4fb9cb1e0@guppylake.com>
Content-Transfer-Encoding: 7bit
From: Nathaniel Borenstein <nsb@guppylake.com>
Subject: What is ASCII? (was Re: ATOMIC and downgrading (was: Re: [EAI]
	Comments on draft-ietf-eai-downgrading.00))
Date: Wed, 5 Jul 2006 09:00:38 -0400
To: "Charles Lindsey" <chl@clerew.man.ac.uk>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
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 Jul 5, 2006, at 6:46 AM, Charles Lindsey wrote:

> I am sure I remember reading some RFC which declared that IETF policy 
> was to use US-ASCII rather than ASCII in all official documents. But I 
> have not managed to locate it (beyond a mention in RFC 1700, which is 
> not the one I had in mind). But for sure somebody in Montreal will 
> know.

I believe the reason we used "US-ASCII" in MIME was that there was a 
long-standing (and tedious) dispute about "what is ASCII?" having to do 
with stuff like dollar sign vs currency symbols and some other minutae. 
  We chose a parameter value of "US-ASCII" so that, without taking sides 
in that particular holy war, we would leave no room for doubt about 
which version of ASCII was being referred to.

It is possible that enough people have died by now that one can now 
safely use "ASCII" to refer to, um, the thing most of us think of as 
ASCII.  But I wouldn't bet on it.   -- Nathaniel


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



From ima-bounces@ietf.org Wed Jul 05 09:45:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fy7hJ-0003Db-Qw; Wed, 05 Jul 2006 09:45:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy7hJ-0003DW-CT
	for ima@ietf.org; Wed, 05 Jul 2006 09:45:45 -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 1Fy7hI-0001Lt-21
	for ima@ietf.org; Wed, 05 Jul 2006 09:45:45 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1Fy7h5-000Oe3-Rs; Wed, 05 Jul 2006 09:45:32 -0400
Date: Wed, 05 Jul 2006 09:45:31 -0400
From: John C Klensin <klensin@jck.com>
To: Nathaniel Borenstein <nsb@guppylake.com>,
	Charles Lindsey <chl@clerew.man.ac.uk>
Subject: Re: What is ASCII? (was Re: ATOMIC and downgrading (was:
	Re: [EAI]	Comments on draft-ietf-eai-downgrading.00))
Message-ID: <3491998B080C33E62BC81CF0@p3.JCK.COM>
In-Reply-To: <d8b1c8feaf270b32bd4d90c4fb9cb1e0@guppylake.com>
References: <12E0F02D97361FD7DEED87B0@p3.JCK.COM>
	<op.tb7pi80g6hl8nm@clerew.man.ac.uk>
	<d8b1c8feaf270b32bd4d90c4fb9cb1e0@guppylake.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: 0.0 (/)
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



--On Wednesday, 05 July, 2006 09:00 -0400 Nathaniel Borenstein
<nsb@guppylake.com> wrote:

> On Jul 5, 2006, at 6:46 AM, Charles Lindsey wrote:
> 
>> I am sure I remember reading some RFC which declared that
>> IETF policy  was to use US-ASCII rather than ASCII in all
>> official documents. But I  have not managed to locate it
>> (beyond a mention in RFC 1700, which is  not the one I had in
>> mind). But for sure somebody in Montreal will  know.
> 
> I believe the reason we used "US-ASCII" in MIME was that there
> was a long-standing (and tedious) dispute about "what is
> ASCII?" having to do with stuff like dollar sign vs currency
> symbols and some other minutae.   We chose a parameter value
> of "US-ASCII" so that, without taking sides in that particular
> holy war, we would leave no room for doubt about which version
> of ASCII was being referred to.
> 
> It is possible that enough people have died by now that one
> can now safely use "ASCII" to refer to, um, the thing most of
> us think of as ASCII.  But I wouldn't bet on it.   -- Nathaniel

And that is why, in running text (this is not a parameter which
one could argue needs to be precise and self-referencing), I
suggest using "ASCII", which is clear, and then using
"[US-ASCII]" as the citation anchor.

    john


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



From ima-bounces@ietf.org Wed Jul 05 16:27:06 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyDxe-0005gX-Ar; Wed, 05 Jul 2006 16:27:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FyDxd-0005gR-AP
	for ima@ietf.org; Wed, 05 Jul 2006 16:27:01 -0400
Received: from 206-169-26-130.static.twtelecom.net ([206.169.26.130]
	helo=mail.optistreams.net) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyDxb-0001iX-UX for ima@ietf.org; Wed, 05 Jul 2006 16:27:01 -0400
In-Reply-To: <3491998B080C33E62BC81CF0@p3.JCK.COM>
References: <12E0F02D97361FD7DEED87B0@p3.JCK.COM>
	<op.tb7pi80g6hl8nm@clerew.man.ac.uk>
	<d8b1c8feaf270b32bd4d90c4fb9cb1e0@guppylake.com>
	<3491998B080C33E62BC81CF0@p3.JCK.COM>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <23fa2a9acd528892404912ac4c7baddc@guppylake.com>
Content-Transfer-Encoding: 7bit
From: Nathaniel Borenstein <nsb@guppylake.com>
Subject: Re: What is ASCII? (was Re: ATOMIC and downgrading (was: Re:
	[EAI]	Comments on draft-ietf-eai-downgrading.00))
Date: Wed, 5 Jul 2006 16:17:46 -0400
To: John C Klensin <klensin@jck.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
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

On Jul 5, 2006, at 9:45 AM, John C Klensin wrote:

> And that is why, in running text (this is not a parameter which
> one could argue needs to be precise and self-referencing), I
> suggest using "ASCII", which is clear, and then using
> "[US-ASCII]" as the citation anchor.

Lest there be any misunderstanding... I agree.  -- Nathaniel


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



From ima-bounces@ietf.org Sun Jul 09 09:27:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FzZK1-0006JK-Op; Sun, 09 Jul 2006 09:27:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FzZK0-0006JF-U4
	for ima@ietf.org; Sun, 09 Jul 2006 09:27:40 -0400
Received: from [159.226.7.146] (helo=cnnic.cn)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FzZJv-0002p9-Tt
	for ima@ietf.org; Sun, 09 Jul 2006 09:27:40 -0400
Received: (eyou send program); Sun, 09 Jul 2006 21:27:25 +0800
Message-ID: <352451645.25364@cnnic.cn>
X-EYOUMAIL-SMTPAUTH: lee@cnnic.cn
Received: from unknown (HELO [132.219.23.231]) (127.0.0.1)
	by 127.0.0.1 with SMTP; Sun, 09 Jul 2006 21:27:25 +0800
Message-ID: <44B1043A.8010706@cnnic.cn>
Date: Sun, 09 Jul 2006 21:27:22 +0800
From: Xiaodong Lee <lee@cnnic.cn>
Organization: CNNIC
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
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: 856eb5f76e7a34990d1d457d8e8e5b7f
Subject: [EAI] about the agenda
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,

I have upload the agenda, please check:
http://www3.ietf.org/proceedings/06jul/agenda/eai.txt

The time for draft review is reduce to 5 minutes maximum, to leave more
time for outstanding issues discussion.

Every reporter, please check the agenda and send your presentations to me.

Regards!

-- 
-- 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 Jul 10 11:20:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FzxYx-0002qM-54; Mon, 10 Jul 2006 11:20:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxYv-0002j7-8o
	for ima@ietf.org; Mon, 10 Jul 2006 11:20:41 -0400
Received: from brmea-mail-2.sun.com ([192.18.98.43])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzxYs-0004dQ-El
	for ima@ietf.org; Mon, 10 Jul 2006 11:20:41 -0400
Received: from fe-amer-01.sun.com ([192.18.108.175])
	by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	k6AFKbPo018591
	for <ima@ietf.org>; Mon, 10 Jul 2006 09:20:38 -0600 (MDT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
	(Sun Java System Messaging Server 6.2-4.02 (built Sep  9 2005))
	id <0J2700G01187GJ00@mail-amer.sun.com>
	(original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon,
	10 Jul 2006 09:20:37 -0600 (MDT)
Received: from [10.0.1.3]
	(216-165-225-246.championbroadband.com [216.165.225.246])
	by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built
	Sep 9
	2005)) with ESMTPSA id <0J2700LFR1AAH510@mail-amer.sun.com>; Mon,
	10 Jul 2006 09:20:37 -0600 (MDT)
Date: Mon, 10 Jul 2006 08:20:38 -0700
From: Chris Newman <Chris.Newman@Sun.COM>
Subject: Re: [EAI] Comments on draft--eai-pop-00
In-reply-to: <op.tbyvh1u56hl8nm@clerew.man.ac.uk>
To: Charles Lindsey <chl@clerew.man.ac.uk>, ima@ietf.org
Message-id: <F0F7E0C4DC06BB5931CAEBC9@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.6 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <op.tbyvh1u56hl8nm@clerew.man.ac.uk>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
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

Charles Lindsey wrote on 6/30/06 17:16 +0100:
> 3.  UTF8 Capability
>
>     ... The retrieved message MUST still be textual
>     and otherwise formatted according to RFC 2822 [RFC2822] and MIME
>     [RFC2045].
>              ^
>            as extended by [utf8headers]

This change seems redundant to me given I mentioned that reference in the first 
sentence of the section.

> 5.  Up-Conversion Server Requirements
>
> It is interesting that you have chosen to include up-conversion at the POP
> level, since I had always assumed this would be a function of the MUA  (they
> are already in the business of up-converting RFC 2047 stuff, and  even RFC
> 2231 stuff if they are doing a proper job). Moreover, MUAs which  take good
> 'ol mbox format as their input will still need to know how to  up-convert.
>
>     The following charsets MUST be supported for up-conversion of MIME
>     header encoding [RFC2047]: UTF-8, US-ASCII, ISO-8859-1, ISO-8859-2,
>     ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7,
>     ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-14, and ISO-8859-15.
>     Other widely deployed MIME charsets SHOULD be supported.
>
> Why do you want to support the ISO-8859-*? We are primarily concerned with
> UTF-8 here, so I would have thought the others were no more than SHOULD.

MIME mail agents are required to support those charsets per RFC 2049.  If our 
goal is to migrate towards a UTF-8 only mode of operation, then we need to 
up-convert the mandatory charsets to UTF-8.  And it's best to do it at the 
final delivery agent or POP server where it's more likely to be done correctly. 
Mail user agents have a long history of implementing RFC 2047 in a 
non-interoperable fashion, so the more we can do to prevent them from ever 
seeing it, the better.

What makes me excited about EAI is that we can deprecate most use of RFC 2047 
which will actually improve interoperability, so I consider that an important 
secondary goal of the EAI effort.

>     ... and MAY/SHOULD support various other headers {to be discussed},
> including things previously downgraded by RFC 2231.

So if I understand your comment correctly, you want to upgrade the following 
text:

>     While this specification does not require it, server implementations
>     are encouraged to up-convert all MIME body headers, and particularly
>     the deprecated (and misused) name parameter [RFC1341] on Content-Type
>     and the Content-Disposition [RFC2183] filename parameter.  These may
>     be encoded using the standard MIME parameter encoding [RFC2231]
>     mechanism, or via non-standard use of MIME header encoding [RFC2047]
>     in quoted strings.

to a "SHOULD"?

FWIW, I was uncomfortable telling POP servers they SHOULD implement a MIME 
parser.  While I consider a MIME parser a very simple and lightweight piece of 
code (that took me less than a day to write), that attitude is not shared by 
other implementers.  How do other people feel about this?

>     Servers are also encouraged to up-convert the headers on embedded
>     message/rfc822 body parts [TBD-ref].  Servers MAY convert the charset
>     on MIME body parts to UTF-8, and MAY remove quoted-printable or
>     base64 encodings as long as the resulting text complies with the
>     requirements of the 8-bit content-transfer-encoding [RFC2045].
>
> I am pleased to see that someone else is interested in those MIME body
> headers and message/rfc822 headers. All we need now is to get them  included
> in the 'downgrade' document :-) .

The downgrade document is certainly incomplete until it discusses these issues.

                - Chris


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



From ima-bounces@ietf.org Mon Jul 10 11:43:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FzxvG-0007g4-R5; Mon, 10 Jul 2006 11:43:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxvF-0007ff-HP
	for ima@ietf.org; Mon, 10 Jul 2006 11:43:45 -0400
Received: from brmea-mail-4.sun.com ([192.18.98.36])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzxv9-0006I6-HF
	for ima@ietf.org; Mon, 10 Jul 2006 11:43:45 -0400
Received: from fe-amer-01.sun.com ([192.18.108.175])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	k6AFhd8G006831
	for <ima@ietf.org>; Mon, 10 Jul 2006 09:43:39 -0600 (MDT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
	(Sun Java System Messaging Server 6.2-4.02 (built Sep  9 2005))
	id <0J2700K0124VL600@mail-amer.sun.com>
	(original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon,
	10 Jul 2006 09:43:39 -0600 (MDT)
Received: from [10.0.1.3]
	(216-165-225-246.championbroadband.com [216.165.225.246])
	by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built
	Sep 9
	2005)) with ESMTPSA id <0J2700LQ52COH510@mail-amer.sun.com>; Mon,
	10 Jul 2006 09:43:38 -0600 (MDT)
Date: Mon, 10 Jul 2006 08:43:41 -0700
From: Chris Newman <Chris.Newman@Sun.COM>
Subject: Re: [EAI] about the agenda
In-reply-to: <44B1043A.8010706@cnnic.cn>
To: lee@cnnic.cn, ima@ietf.org
Message-id: <B9EC21614FE13E83F3BB8083@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.6 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <44B1043A.8010706@cnnic.cn>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
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

I won't be leading the POP draft discussion as I'll be participating by Jabber 
only.  Perhaps one of the co-chairs can lead the discussion.

Major changes in this EAI POP draft:
  * add a LANG command to negotiate error text language
  * add TOP8 command

Open issues:
 * The decision on how to handle UTF-8 in Received headers may impact
   the up-conversion requirements section.
 * Need a reference for up-conversion of message/rfc822 body part.
 * Should we make POP up-convert requirements match the IMAP up-convert
   requirements?  It would be nice for consistency.  If we did so, we're saying
   a POP server SHOULD include a MIME parser to up-convert the MIME headers.
   While I personally support such a change, I feel the issue needs explicit
   WG rough consensus.

                - Chris

Xiaodong Lee wrote on 7/9/06 21:27 +0800:

> Dear All,
>
> I have upload the agenda, please check:
> http://www3.ietf.org/proceedings/06jul/agenda/eai.txt
>
> The time for draft review is reduce to 5 minutes maximum, to leave more
> time for outstanding issues discussion.
>
> Every reporter, please check the agenda and send your presentations to me.
>
> Regards!
>
> --
> -- 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
>





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



From ima-bounces@ietf.org Mon Jul 10 14:21:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G00Nb-0007jP-Uw; Mon, 10 Jul 2006 14:21:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G00Na-0007eD-E0
	for ima@ietf.org; Mon, 10 Jul 2006 14:21:10 -0400
Received: from sniper.icu.ac.kr ([210.107.128.51])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G00NY-0004QE-Ot
	for ima@ietf.org; Mon, 10 Jul 2006 14:21:10 -0400
Received: (snipe 4095 invoked by uid 0); 11 Jul 2006 02:24:25 +0900
Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.593315
	secs); 
Received: from unknown (HELO ?132.219.4.247?) (Z5??own@132.219.4.247)
	by unknown with SMTP; 11 Jul 2006 02:24:25 +0900
X-RCPTTO: ima@ietf.org
Message-ID: <44B29A8B.8080907@icu.ac.kr>
Date: Tue, 11 Jul 2006 03:20:59 +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
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Subject: [EAI] Two issues of EAI drafts
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 EAI DT members,

After reading I-Ds, I came up with a few issues that need to
be addressed soon.

(1) String preparation

We are using Stringprep with Nameprep profile IDNA while
POP draft proposes to use SASLprep profile. In addition,
John mentioned this morning that we are going to have more
stable normalization table soon.

Is it better to have same preparation rules for both local and
domain part? If yes, what should be that preparation rule?

(2) Association of an I18N email address and its ALT-address

For sender-based operations (e.g. spam protection based on
sender information), an I18N email address needs to be handled
as if it is "equivalent" to its ALT-address.

What do we mean by "equivalent"? How can be enforce such
an equivalence?

Regards


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



From ima-bounces@ietf.org Mon Jul 10 14:32:31 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G00YY-0005zZ-Py; Mon, 10 Jul 2006 14:32:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G00YX-0005v8-CC
	for ima@ietf.org; Mon, 10 Jul 2006 14:32:29 -0400
Received: from lon-mail-4.gradwell.net ([193.111.201.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G00YU-0006ii-Ol
	for ima@ietf.org; Mon, 10 Jul 2006 14:32:29 -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.226) id
	44b29d39.1863e.16a for ima@ietf.org; Mon, 10 Jul 2006 19:32:25 +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 k6AIWMNl004424
	for <ima@ietf.org>; Mon, 10 Jul 2006 19:32:23 +0100 (BST)
Subject: Fwd: Re: [EAI] Comments on draft--eai-pop-00
References: <op.tbyvh1u56hl8nm@clerew.man.ac.uk>
	<F0F7E0C4DC06BB5931CAEBC9@446E7922C82D299DB29D899F>
Message-ID: <op.tchkf72b6hl8nm@clerew.man.ac.uk>
To: "ima@ietf.org" <ima@ietf.org>
Date: Mon, 10 Jul 2006 19:32:21 +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: <F0F7E0C4DC06BB5931CAEBC9@446E7922C82D299DB29D899F>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
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



------- Forwarded message -------
From: "Chris Newman" <Chris.Newman@Sun.COM>
To: "Charles Lindsey" <chl@clerew.man.ac.uk>, ima@ietf.org
Subject: Re: [EAI] Comments on draft--eai-pop-00
Date: Mon, 10 Jul 2006 16:20:38 +0100

Charles Lindsey wrote on 6/30/06 17:16 +0100:
>> 3.  UTF8 Capability
>>
>>     ... The retrieved message MUST still be textual
>>     and otherwise formatted according to RFC 2822 [RFC2822] and MIME
>>     [RFC2045].
>>              ^
>>            as extended by [utf8headers]

> This change seems redundant to me given I mentioned that reference in  
> the first
> sentence of the section.

Yes, but somebody will read that wording as undoing the good you did  
earlier. Taken on its own, and taken too literally, it could be  
misunderstood. All it needs is an "as extended" inserted at an appropriate  
place.

>> 5.  Up-Conversion Server Requirements

>> Why do you want to support the ISO-8859-*? We are primarily concerned  
>> with
>> UTF-8 here, so I would have thought the others were no more than SHOULD.

> MIME mail agents are required to support those charsets per RFC 2049.

OK, point taken.

> Mail user agents have a long history of implementing RFC 2047 in a
> non-interoperable fashion, so the more we can do to prevent them from  
> ever
> seeing it, the better.

And are POP3 agents notably better?>



>     ... and MAY/SHOULD support various other headers {to be discussed},
> including things previously downgraded by RFC 2231.

> So if I understand your comment correctly, you want to upgrade the  
> following
> text:

>     While this specification does not require it, server implementations
>     are encouraged to up-convert all MIME body headers, and particularly
>     the deprecated (and misused) name parameter [RFC1341] on Content-Type
>     and the Content-Disposition [RFC2183] filename parameter.  These may
>     be encoded using the standard MIME parameter encoding [RFC2231]
>     mechanism, or via non-standard use of MIME header encoding [RFC2047]
>     in quoted strings.

> to a "SHOULD"?

Yes, that would help, though I would not want to give any comfort to those  
who try to use RFC 2047 where RFC 2231 ouught to have been used. Also, if  
we prescribe the use of IRIs in the List-* headers (with the obvious  
diwngrade), do we want to be encourgaging the upgrading of URIs to IRIs in  
appropriate cases?

> FWIW, I was uncomfortable telling POP servers they SHOULD implement a  
> MIME
> parser.  While I consider a MIME parser a very simple and lightweight  
> piece of
> code (that took me less than a day to write), that attitude is not  
> shared by
> other implementers.  How do other people feel about this?

If you are going to do it, then do it properly. Maybe that is a way to get  
UTF8smtp up and running without waiting for MUAs to be fully upgraded, but  
OTOH I suspect all those MUAs are going to need upgrading in any case -  
indeed they should already be parsing such MIME as comes their way. The  
chief problem with current MUAs, I suspect, is that although they display  
MIME stuff as received, they are mush less likely to construct correct  
MIME for stuff they generate :-( .

-- 
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 Mon Jul 10 15:15:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G01Ds-0001FT-Pn; Mon, 10 Jul 2006 15:15:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G01Dr-0001FO-SZ
	for ima@ietf.org; Mon, 10 Jul 2006 15:15:11 -0400
Received: from send01.jprs.co.jp ([202.11.17.113])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G01Dm-0001fC-7x
	for ima@ietf.org; Mon, 10 Jul 2006 15:15:11 -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 k6AJF4R9017198
	for <ima@ietf.org>; Tue, 11 Jul 2006 04:15:04 +0900 (JST)
Received: (from localhost [172.18.4.45])
	by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id
	M2006071104150305653
	for <ima@ietf.org>; Tue, 11 Jul 2006 04:15:03 +0900
Date: Tue, 11 Jul 2006 04:15:03 +0900 (JST)
Message-Id: <20060711.041503.83604161.fujiwara@jprs.co.jp>
To: ima@ietf.org
From: fujiwara@jprs.co.jp
X-Mailer: Mew version 5.0.54 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: 1ac7cc0a4cd376402b85bc1961a86ac2
Subject: [EAI] downgrade I-D presentation
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 prepared my presentation file for downgrading I-D.
It includes a lots of examples, senario evaluation.

I put it on file server and please read before.

  http://dnslab.jp/tmp/draft-ietf-eai-downgrade-01.pdf

Tomorrow, I will explain overview and header conversion only.

Regards,

--
Kazunori Fujiwara, JPRS


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



From ima-bounces@ietf.org Mon Jul 10 15:43:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G01f5-00066D-Vg; Mon, 10 Jul 2006 15:43:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G01f5-00065y-5D
	for ima@ietf.org; Mon, 10 Jul 2006 15:43:19 -0400
Received: from [159.226.7.146] (helo=cnnic.cn)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G01f3-00034E-Bk
	for ima@ietf.org; Mon, 10 Jul 2006 15:43:19 -0400
Received: (eyou send program); Tue, 11 Jul 2006 03:42:49 +0800
Message-ID: <352560569.20838@cnnic.cn>
X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn
Received: from unknown (HELO yaojk) (127.0.0.1)
	by 127.0.0.1 with SMTP; Tue, 11 Jul 2006 03:42:49 +0800
Message-ID: <002501c6a459$0a7df7b0$f311db84@YaoJK>
From: "Yao Jiankang" <yaojk@cnnic.cn>
To: "Yangwoo Ko" <newcat@icu.ac.kr>,
	<ima@ietf.org>
References: <352555671.18965@cnnic.cn>
Subject: Re: [EAI] Two issues of EAI drafts
Date: Tue, 11 Jul 2006 03:42:47 +0800
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.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
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


----- Original Message ----- 
From: "Yangwoo Ko" <newcat@icu.ac.kr>
To: <ima@ietf.org>
Sent: Tuesday, July 11, 2006 2:20 AM
Subject: [EAI] Two issues of EAI drafts


>
> Dear EAI DT members,
>
> After reading I-Ds, I came up with a few issues that need to
> be addressed soon.
>
> (1) String preparation
>
> We are using Stringprep with Nameprep profile IDNA while
> POP draft proposes to use SASLprep profile. In addition,
> John mentioned this morning that we are going to have more
> stable normalization table soon.
>
> Is it better to have same preparation rules for both local and
> domain part? If yes, what should be that preparation rule?


according to last IETF EAI interim meeting, we are supposed to have another
document(maybe named with EAI operation guideline ) which describes and
specifies the above issues.


>
> (2) Association of an I18N email address and its ALT-address
>
> For sender-based operations (e.g. spam protection based on
> sender information), an I18N email address needs to be handled
> as if it is "equivalent" to its ALT-address.
>
> What do we mean by "equivalent"? How can be enforce such
> an equivalence?

is it ok that to be understood as the "alias" address?

for example, UTF-8userA@IDNexample.com; ASCIIuserB@ASCIIexample.com;
it means that these two email accounts point to the same account. It is
better that these issues also be inclued in  the "EAI operation guideline"
document.


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


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



From ima-bounces@ietf.org Mon Jul 10 16:16:12 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G02Au-0004QE-Jp; Mon, 10 Jul 2006 16:16:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G02At-0004Pw-20
	for ima@ietf.org; Mon, 10 Jul 2006 16:16:11 -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 1G02Aq-0005Yj-NM
	for ima@ietf.org; Mon, 10 Jul 2006 16:16:11 -0400
Received: from [127.0.0.1] (helo=localhost)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1G02Aq-0001aJ-7j; Mon, 10 Jul 2006 16:16:08 -0400
Date: Mon, 10 Jul 2006 16:16:07 -0400
From: John C Klensin <klensin@jck.com>
To: Yangwoo Ko <newcat@icu.ac.kr>, ima@ietf.org
Subject: Re: [EAI] Two issues of EAI drafts
Message-ID: <B0EECD99016E2CBA649A0A4A@as-s2n.ietf66.org>
In-Reply-To: <44B29A8B.8080907@icu.ac.kr>
References: <44B29A8B.8080907@icu.ac.kr>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
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 Tuesday, July 11, 2006 03:20 +0900 Yangwoo Ko 
<newcat@icu.ac.kr> wrote:

>
> Dear EAI DT members,
>
> After reading I-Ds, I came up with a few issues that need to
> be addressed soon.
>
> (1) String preparation
>
> We are using Stringprep with Nameprep profile IDNA while
> POP draft proposes to use SASLprep profile. In addition,
> John mentioned this morning that we are going to have more
> stable normalization table soon.
>
> Is it better to have same preparation rules for both local and
> domain part? If yes, what should be that preparation rule?

Whether it is better or not is not interesting.  It is not 
possible.  IDNA requires a particular profile, one that in 
particular performs case-folding for non-ASCII characters where 
that is relevant.   The left side requires a profile that 
preserves case if the general norms of RFC 821 -> RFC 2821 are 
to be followed.

> (2) Association of an I18N email address and its ALT-address
>
> For sender-based operations (e.g. spam protection based on
> sender information), an I18N email address needs to be handled
> as if it is "equivalent" to its ALT-address.
>
> What do we mean by "equivalent"? How can be enforce such
> an equivalence?

I do not believe that is going to be possible in the general 
case and the statement may not be true... although it is nice to 
wish for.

     john


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



From ima-bounces@ietf.org Mon Jul 10 18:44:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G04U8-0001I0-Jc; Mon, 10 Jul 2006 18:44:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G04U7-0001Hs-KG
	for ima@ietf.org; Mon, 10 Jul 2006 18:44:11 -0400
Received: from [159.226.7.146] (helo=cnnic.cn)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G04U2-0006Qn-UA
	for ima@ietf.org; Mon, 10 Jul 2006 18:44:11 -0400
Received: (eyou send program); Tue, 11 Jul 2006 06:43:55 +0800
Message-ID: <352571435.19606@cnnic.cn>
X-EYOUMAIL-SMTPAUTH: lee@cnnic.cn
Received: from unknown (HELO [132.219.10.235]) (127.0.0.1)
	by 127.0.0.1 with SMTP; Tue, 11 Jul 2006 06:43:55 +0800
Message-ID: <44B2D82D.10907@cnnic.cn>
Date: Tue, 11 Jul 2006 06:43:57 +0800
From: Xiaodong Lee <lee@cnnic.cn>
Organization: CNNIC
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: "ima@ietf.org" <ima@ietf.org>
Subject: Re: [EAI] about the agenda
References: <352451676.22169@cnnic.cn>
In-Reply-To: <352451676.22169@cnnic.cn>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: 
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,

The agenda is updated with some suggestions from others, please check it.

Just remind sending your presentation out please.

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



Xiaodong Lee wrote:
> Dear All,
>
> I have upload the agenda, please check:
> http://www3.ietf.org/proceedings/06jul/agenda/eai.txt
>
> The time for draft review is reduce to 5 minutes maximum, to leave more
> time for outstanding issues discussion.
>
> Every reporter, please check the agenda and send your presentations to me.
>
> Regards!
>
>   

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



From ima-bounces@ietf.org Mon Jul 10 22:21:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G07s7-0008VO-1E; Mon, 10 Jul 2006 22:21:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G07s6-0008VJ-0h
	for ima@ietf.org; Mon, 10 Jul 2006 22:21:10 -0400
Received: from twnic.net.tw ([211.72.210.250])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G07s2-0001eZ-1L
	for ima@ietf.org; Mon, 10 Jul 2006 22:21:09 -0400
Received: from aabbeell (pc093.twnic.net.tw [211.72.211.93])
	by twnic.net.tw (8.13.6/8.13.5) with SMTP id k6B2KvNg013750;
	Tue, 11 Jul 2006 10:20:58 +0800
Message-ID: <00d801c6a490$ae32d290$c7d348d3@aabbeell>
From: "abel" <abelyang@twnic.net.tw>
To: "Chris Newman" <Chris.Newman@Sun.COM>,
	"Charles Lindsey" <chl@clerew.man.ac.uk>, <ima@ietf.org>
References: <op.tbyvh1u56hl8nm@clerew.man.ac.uk>
	<F0F7E0C4DC06BB5931CAEBC9@446E7922C82D299DB29D899F>
Subject: Re: [EAI] Comments on draft--eai-pop-00
Date: Tue, 11 Jul 2006 10:21:11 +0800
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.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
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

> FWIW, I was uncomfortable telling POP servers they SHOULD implement a MIME
> parser.  While I consider a MIME parser a very simple and lightweight
piece of
> code (that took me less than a day to write), that attitude is not shared
by
> other implementers.  How do other people feel about this?
>
I had some different idea when I implement  our EAI trial ,
when the POP3 client login UTF8-name (pass UTF8-name) , POP3 service 'RETR
command' returns MUA a EAI mail content,
if  MUA login as US-ASCII name , POP3 returns mail as Downgraded (downward
compatibility for current MUA).
The US-ASCII name can be MIME or Punycode , and the name point to same UTF8
mailbox,
Considering and supporting current MUA is benefits

Regards

Abel







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



From ima-bounces@ietf.org Tue Jul 11 08:29:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0HMv-0000Lo-DH; Tue, 11 Jul 2006 08:29:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0HMt-0000LV-4z
	for ima@ietf.org; Tue, 11 Jul 2006 08:29:35 -0400
Received: from send01.jprs.co.jp ([202.11.17.113])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0HMr-0001Yb-JJ
	for ima@ietf.org; Tue, 11 Jul 2006 08:29:35 -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 k6BCTWR9028622
	for <ima@ietf.org>; Tue, 11 Jul 2006 21:29:32 +0900 (JST)
Received: (from localhost [172.18.4.45])
	by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id
	M2006071121293111653
	for <ima@ietf.org>; Tue, 11 Jul 2006 21:29:31 +0900
Date: Tue, 11 Jul 2006 21:29:31 +0900 (JST)
Message-Id: <20060711.212931.124069938.fujiwara@jprs.co.jp>
To: ima@ietf.org
Subject: Re: [EAI] downgrade I-D presentation
From: fujiwara@jprs.co.jp
In-Reply-To: <20060711.041503.83604161.fujiwara@jprs.co.jp>
References: <20060711.041503.83604161.fujiwara@jprs.co.jp>
X-Mailer: Mew version 5.0.54 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: 8abaac9e10c826e8252866cbe6766464
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 updated presentation file.

- trivial changes
- added header conversion upgrading example slides in detail.

I put the newer version in same place. Please reload.
  http://dnslab.jp/tmp/draft-ietf-eai-downgrade-01.pdf

--
Kazunori Fujiwara, JPRS

> From: fujiwara@jprs.co.jp
> I prepared my presentation file for downgrading I-D.
> It includes a lots of examples, senario evaluation.
> 
> I put it on file server and please read before.
> 
>   http://dnslab.jp/tmp/draft-ietf-eai-downgrade-01.pdf
> 
> Tomorrow, I will explain overview and header conversion only.
> 
> Regards,
> 
> --
> Kazunori Fujiwara, JPRS
> 
> 
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www1.ietf.org/mailman/listinfo/ima
> 

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



From ima-bounces@ietf.org Tue Jul 11 10:12:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0Iyr-0007W9-1L; Tue, 11 Jul 2006 10:12:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Iyp-0007Uz-Tu
	for ima@ietf.org; Tue, 11 Jul 2006 10:12:51 -0400
Received: from brmea-mail-1.sun.com ([192.18.98.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Iyo-0003K8-2z
	for ima@ietf.org; Tue, 11 Jul 2006 10:12:51 -0400
Received: from fe-amer-01.sun.com ([192.18.108.175])
	by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	k6BECnRN027859
	for <ima@ietf.org>; Tue, 11 Jul 2006 08:12:49 -0600 (MDT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
	(Sun Java System Messaging Server 6.2-4.02 (built Sep  9 2005))
	id <0J2800G01SOYCQ00@mail-amer.sun.com>
	(original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Tue,
	11 Jul 2006 08:12:49 -0600 (MDT)
Received: from [10.0.1.3]
	(216-165-225-246.championbroadband.com [216.165.225.246])
	by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built
	Sep 9
	2005)) with ESMTPSA id <0J28008OFSTA6810@mail-amer.sun.com>; Tue,
	11 Jul 2006 08:12:49 -0600 (MDT)
Date: Tue, 11 Jul 2006 07:12:52 -0700
From: Chris Newman <Chris.Newman@Sun.COM>
Subject: Re: [EAI] Comments on draft--eai-pop-00
In-reply-to: <00d801c6a490$ae32d290$c7d348d3@aabbeell>
To: abel <abelyang@twnic.net.tw>, Charles Lindsey <chl@clerew.man.ac.uk>,
	ima@ietf.org
Message-id: <51624A4117461717F0828FF8@[10.0.1.3]>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.6 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <op.tbyvh1u56hl8nm@clerew.man.ac.uk>
	<F0F7E0C4DC06BB5931CAEBC9@446E7922C82D299DB29D899F>
	<00d801c6a490$ae32d290$c7d348d3@aabbeell>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
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

Overloading the semantics of the user name to determine whether the protocol is 
eai-aware is an ugly kludge and doesn't work in general because people with 
ascii-only names will want to use EAI and the POP AUTH command already permits 
UTF-8 user names in non-EAI POP.

An alternative proposal where we add a "UTF8 ON" command to POP3 which switches 
the existing POP3 commands to 8BIT mode is worth considering.  It has the 
advantage of potentially fewer changes to POP clients, but the disadvantage of 
being a hard modal switch in the protocol so it's less flexible than the 
current proposal and more likely to be implemented incorrectly.  I'm certainly 
open to a debate contrasting an explicit modal switch command to the parallel 
command approach.

                - Chris

abel wrote on 7/11/06 10:21 +0800:
> I had some different idea when I implement  our EAI trial ,
> when the POP3 client login UTF8-name (pass UTF8-name) , POP3 service 'RETR
> command' returns MUA a EAI mail content,
> if  MUA login as US-ASCII name , POP3 returns mail as Downgraded (downward
> compatibility for current MUA).
> The US-ASCII name can be MIME or Punycode , and the name point to same UTF8
> mailbox,
> Considering and supporting current MUA is benefits


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



From ima-bounces@ietf.org Tue Jul 11 10:28:41 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0JE9-0003NT-L8; Tue, 11 Jul 2006 10:28:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0JE8-0003Mu-AA
	for ima@ietf.org; Tue, 11 Jul 2006 10:28:40 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0JE5-0001rl-UM
	for ima@ietf.org; Tue, 11 Jul 2006 10:28:40 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6BESXH0021412
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Jul 2006 07:28:34 -0700
Received: from [142.131.134.210] (vpn-10-50-16-83.qualcomm.com [10.50.16.83])
	by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k6BESS5j006080; Tue, 11 Jul 2006 07:28:29 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300003c0d964bd011b@[142.131.134.210]>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Tue, 11 Jul 2006 07:23:05 -0700
To: "abel" <abelyang@twnic.net.tw>, "Chris Newman" <Chris.Newman@sun.com>,
	"Charles Lindsey" <chl@clerew.man.ac.uk>, <ima@ietf.org>
From: Randall Gellens <rg+ietf@qualcomm.com>
Subject: Re: [EAI] Comments on draft--eai-pop-00
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
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 10:21 AM +0800 7/11/06, abel wrote:

>   > FWIW, I was uncomfortable telling POP servers they SHOULD implement a MIME
>>  parser.  While I consider a MIME parser a very simple and lightweight
>  piece of
>>  code (that took me less than a day to write), that attitude is not shared
>  by
>>  other implementers.  How do other people feel about this?
>>
>  I had some different idea when I implement  our EAI trial ,
>  when the POP3 client login UTF8-name (pass UTF8-name) , POP3 service 'RETR
>  command' returns MUA a EAI mail content,
>  if  MUA login as US-ASCII name , POP3 returns mail as Downgraded (downward
>  compatibility for current MUA).
>  The US-ASCII name can be MIME or Punycode , and the name point to same UTF8
>  mailbox,
>  Considering and supporting current MUA is benefits

I apologize, but I am a bit confused: the text you quoted is Chris 
asking about the burden of implementing a MIME parser, but your reply 
seems to propose an alternative to the use of new commands in place 
of RETR/TOP.  In regards to this proposal, I'd prefer Chris' approach 
of new commands to make things explicit, rather than having it be 
implicit based on the login name.

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



From ima-bounces@ietf.org Tue Jul 11 13:32:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0M5l-0007Z9-1e; Tue, 11 Jul 2006 13:32:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0M5k-0007Yp-2l
	for ima@ietf.org; Tue, 11 Jul 2006 13:32:12 -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 1G0Hwl-0004gG-Sm
	for ima@ietf.org; Tue, 11 Jul 2006 09:06:39 -0400
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0Hoc-0005JW-6J
	for ima@ietf.org; Tue, 11 Jul 2006 08:58:16 -0400
Received: from [127.0.0.1] (helo=localhost)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1G0HoW-0005SS-6s; Tue, 11 Jul 2006 08:58:08 -0400
Date: Tue, 11 Jul 2006 08:58:06 -0400
From: John C Klensin <klensin@jck.com>
To: lee@cnnic.cn
Message-ID: <16568C9788CB90094C1FE028@as-s2n.ietf66.org>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="==========50A8682F14D71D2CEB36=========="
X-Spam-Score: -0.7 (/)
X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c
Cc: ima@ietf.org
Subject: [EAI] Slides for framework and scenarios
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

--==========50A8682F14D71D2CEB36==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Slides attached.
Yes, I suffer from a bad attitude toward presentations

    john


--==========50A8682F14D71D2CEB36==========
Content-Type: application/pdf; name="ietf66-eai-klensin.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ietf66-eai-klensin.pdf"; size=9883

JVBERi0xLjQNJeLjz9MNCjkgMCBvYmogPDwvTGluZWFyaXplZCAxL0wgOTg4My9PIDExL0UgNDk5
NC9OIDIvVCA5NjU3L0ggWyA1MTYgMTc2XT4+DWVuZG9iag0gICAgICAgICAgICAgICAgICAgICAg
DQp4cmVmDQo5IDExDQowMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA2OTIgMDAwMDAgbg0KMDAw
MDAwMDc2OSAwMDAwMCBuDQowMDAwMDAwODk4IDAwMDAwIG4NCjAwMDAwMDEwMDggMDAwMDAgbg0K
MDAwMDAwMTQ4NSAwMDAwMCBuDQowMDAwMDAxNTE5IDAwMDAwIG4NCjAwMDAwMDE3NDAgMDAwMDAg
bg0KMDAwMDAwMTgxNiAwMDAwMCBuDQowMDAwMDAyMzI1IDAwMDAwIG4NCjAwMDAwMDA1MTYgMDAw
MDAgbg0KdHJhaWxlcg0KPDwvU2l6ZSAyMC9QcmV2IDk2NDcvUm9vdCAxMCAwIFIvSW5mbyA4IDAg
Ui9JRFs8QTUwNjlCOTYyNTU1MzgxRjlCMzU1NjM1NDAzNUZEQkI+PDI1MkIxQTQ1RjkxQzQyNEY5
NzEyNjVENUUzNjU2NTNEPl0+Pg0Kc3RhcnR4cmVmDQowDQolJUVPRg0KICAgICAgICAgICAgICAg
IA0KMTkgMCBvYmo8PC9MZW5ndGggOTIvRmlsdGVyL0ZsYXRlRGVjb2RlL0kgMTA2L0wgOTAvUyA1
Mz4+c3RyZWFtDQp42mJgYGBmYGAKBJP9DDwMCMADFGNmYGHgWHBfgWELA8OjPQwMDQwcQA4S4IBi
BgYlBh7WDz7SGxi4N2jJ7vIGCbEwMIgmAmkmILaAKFThBNKMQPwNIMAA6F4Mvg0KZW5kc3RyZWFt
DWVuZG9iag0xMCAwIG9iajw8L01ldGFkYXRhIDcgMCBSL1BhZ2VzIDYgMCBSL1R5cGUvQ2F0YWxv
Zy9QYWdlTGFiZWxzIDQgMCBSPj4NZW5kb2JqDTExIDAgb2JqPDwvQ3JvcEJveFswIDAgNjEyIDc5
Ml0vUGFyZW50IDYgMCBSL0NvbnRlbnRzIDE3IDAgUi9Sb3RhdGUgOTAvTWVkaWFCb3hbMCAwIDYx
MiA3OTJdL1Jlc291cmNlcyAxMiAwIFIvVHlwZS9QYWdlPj4NZW5kb2JqDTEyIDAgb2JqPDwvQ29s
b3JTcGFjZTw8L0NzNiAxNCAwIFI+Pi9Gb250PDwvVFQyIDEzIDAgUj4+L1Byb2NTZXRbL1BERi9U
ZXh0XS9FeHRHU3RhdGU8PC9HUzEgMTYgMCBSPj4+Pg1lbmRvYmoNMTMgMCBvYmo8PC9TdWJ0eXBl
L1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDE1IDAgUi9MYXN0Q2hhciAxNDkvV2lkdGhzWzI3OCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMjc4IDMzMyAyNzggMjc4IDU1NiA1NTYgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgNjY3IDAgNzIyIDcyMiA2NjcgNjExIDc3OCAwIDI3OCAwIDY2NyA1
NTYgODMzIDAgMCA2NjcgMCA3MjIgNjY3IDYxMSAwIDAgOTQ0IDAgMCAwIDAgMCAwIDAgMCAwIDU1
NiA1NTYgNTAwIDU1NiA1NTYgMjc4IDU1NiA1NTYgMjIyIDIyMiA1MDAgMjIyIDgzMyA1NTYgNTU2
IDU1NiAwIDMzMyA1MDAgMjc4IDU1NiA1MDAgNzIyIDUwMCA1MDAgNTAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAzNTBdL0Jhc2VGb250L0FyaWFs
TVQvRmlyc3RDaGFyIDMyL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRv
YmoNMTQgMCBvYmpbL0lDQ0Jhc2VkIDE4IDAgUl0NZW5kb2JqDTE1IDAgb2JqPDwvU3RlbVYgODgv
Rm9udE5hbWUvQXJpYWxNVC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA0MDAvRmxhZ3Mg
MzIvRGVzY2VudCAtMjExL0ZvbnRCQm94Wy02NjUgLTMyNSAyMDAwIDEwMDZdL0FzY2VudCA5MDUv
Rm9udEZhbWlseShBcmlhbCkvQ2FwSGVpZ2h0IDcxOC9YSGVpZ2h0IDUxNS9UeXBlL0ZvbnREZXNj
cmlwdG9yL0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNMTYgMCBvYmo8PC9PUE0gMS9PUCBmYWxzZS9v
cCBmYWxzZS9UeXBlL0V4dEdTdGF0ZS9TQSBmYWxzZS9TTSAwLjAyPj4NZW5kb2JqDTE3IDAgb2Jq
PDwvTGVuZ3RoIDQ0MC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIl8ks+K2zAQxu9+ijnK
sFYkW/GfY5vNhrQNhEbQw9KDYstbdW0JZJls+h5930pO62y6sMigYdD85vtmvFgNOdQD0OkMtY4W
mwOFpyHKcvDfkhEoUgJWRm30kUcLzlP/kLcRAZbhqoTkchGgtAxBWi5xlQPv/YtwApNgQggDXvsc
P0XowYpenox9jvlPn8roBLpcHlTluGBQVDidOMm1/BH9jhNWMZyjJiaYIStalyjp2kQKlbT/uAmh
2L24+Dv/5PkJxSyrgN//RaUBNVNPVypDH2L/mKKmkQ3Upu+ldgOIoxkd7Df7Ozgsdtvd+g4uZFwy
lgU8rcpX/GxyGiI62RW6gfvP2x04AwdZj1a5M6yMHlQjrXDKR2EQyZV3IzefcbdqS/Q1DjVoQohO
/fKinbS90qYzT2cIfZWuuzG4+U9xSkh5bbEMLdDr2taa3u9OamGVGaAx9RiGgd8ILWjAzKIKtAqi
CmS0U3qUwbOzon4G435IO4OGN7shN+YKtA+r8Bs2R3Hszv4PFI2XZSx828AXMThYia6Do/Qp+f4+
inmAy2kfWr442K75QzCz5tEfAQYAyF3KFAoNCmVuZHN0cmVhbQ1lbmRvYmoNMTggMCBvYmo8PC9M
ZW5ndGggMjU3NS9GaWx0ZXIvRmxhdGVEZWNvZGUvTiAzL0FsdGVybmF0ZS9EZXZpY2VSR0I+PnN0
cmVhbQ0KSImclnlUU3cWx39vyZ6QlbDDYw1bgLAGkDVsYZEdBFEISQgBEkJI2AVBRAUURUSEqpUy
1m10Rk9FnS6uY60O1n3q0gP1MOroOLQW146dFzhHnU5nptPvH+/3Ofd37+/d3733nfMAoCelqrXV
MAsAjdagz0qMxRYVFGKkCQADCiACEQAyea0uLTshB+CSxkuwWtwJ/IueXgeQab0iTMrAMPD/iS3X
6Q0AQBk4ByiUtXKcO3GuqjfoTPYZnHmllSaGURPr8QRxtjSxap6953zmOdrECo1WgbMpZ51CozDx
aZxX1xmVOCOpOHfVqZX1OF/F2aXKqFHj/NwUq1HKagFA6Sa7QSkvx9kPZ7o+J0uC8wIAyHTVO1z6
DhuUDQbTpSTVuka9WlVuwNzlHpgoNFSMJSnrq5QGgzBDJq+U6RWYpFqjk2kbAZi/85w4ptpieJGD
RaHBwUJ/H9E7hfqvm79Qpt7O05PMuZ5B/AtvbT/nVz0KgHgWr836t7bSLQCMrwTA8uZbm8v7ADDx
vh2++M59+KZ5KTcYdGG+vvX19T5qpdzHVNA3+p8Ov0DvvM/HdNyb8mBxyjKZscqAmeomr66qNuqx
Wp1MrsSEPx3iXx3483l4ZynLlHqlFo/Iw6dMrVXh7dYq1AZ1tRZTa/9TE39l2E80P9e4uGOvAa/Y
B7Au8gDytwsA5dIAUrQN34He9C2Vkgcy8DXf4d783M8J+vdT4T7To1atmouTZOVgcqO+bn7P9FkC
AqACJuABK2APnIE7EAJ/EALCQTSIB8kgHeSAArAUyEE50AA9qActoB10gR6wHmwCw2A7GAO7wX5w
EIyDj8EJ8EdwHnwJroFbYBJMg4dgBjwFryAIIkEMiAtZQQ6QK+QF+UNiKBKKh1KhLKgAKoFUkBYy
Qi3QCqgH6oeGoR3Qbuj30FHoBHQOugR9BU1BD6DvoJcwAtNhHmwHu8G+sBiOgVPgHHgJrIJr4Ca4
E14HD8Gj8D74MHwCPg9fgyfhh/AsAhAawkccESEiRiRIOlKIlCF6pBXpRgaRUWQ/cgw5i1xBJpFH
yAuUiHJRDBWi4WgSmovK0Rq0Fe1Fh9Fd6GH0NHoFnUJn0NcEBsGW4EUII0gJiwgqQj2hizBI2En4
iHCGcI0wTXhKJBL5RAExhJhELCBWEJuJvcStxAPE48RLxLvEWRKJZEXyIkWQ0kkykoHURdpC2kf6
jHSZNE16TqaRHcj+5ARyIVlL7iAPkveQPyVfJt8jv6KwKK6UMEo6RUFppPRRxijHKBcp05RXVDZV
QI2g5lArqO3UIep+6hnqbeoTGo3mRAulZdLUtOW0IdrvaJ/Tpmgv6By6J11CL6Ib6evoH9KP07+i
P2EwGG6MaEYhw8BYx9jNOMX4mvHcjGvmYyY1U5i1mY2YHTa7bPaYSWG6MmOYS5lNzEHmIeZF5iMW
heXGkrBkrFbWCOso6wZrls1li9jpbA27l72HfY59n0PiuHHiOQpOJ+cDzinOXS7CdeZKuHLuCu4Y
9wx3mkfkCXhSXgWvh/db3gRvxpxjHmieZ95gPmL+ifkkH+G78aX8Kn4f/yD/Ov+lhZ1FjIXSYo3F
fovLFs8sbSyjLZWW3ZYHLK9ZvrTCrOKtKq02WI1b3bFGrT2tM63rrbdZn7F+ZMOzCbeR23TbHLS5
aQvbetpm2TbbfmB7wXbWzt4u0U5nt8XulN0je759tH2F/YD9p/YPHLgOkQ5qhwGHzxz+ipljMVgV
NoSdxmYcbR2THI2OOxwnHF85CZxynTqcDjjdcaY6i53LnAecTzrPuDi4pLm0uOx1uelKcRW7lrtu
dj3r+sxN4Jbvtspt3O2+wFIgFTQJ9gpuuzPco9xr3Efdr3oQPcQelR5bPb70hD2DPMs9RzwvesFe
wV5qr61el7wJ3qHeWu9R7xtCujBGWCfcK5zy4fuk+nT4jPs89nXxLfTd4HvW97VfkF+V35jfLRFH
lCzqEB0Tfefv6S/3H/G/GsAISAhoCzgS8G2gV6AycFvgn4O4QWlBq4JOBv0jOCRYH7w/+EGIS0hJ
yHshN8Q8cYa4V/x5KCE0NrQt9OPQF2HBYYawg2F/DxeGV4bvCb+/QLBAuWBswd0IpwhZxI6IyUgs
siTy/cjJKMcoWdRo1DfRztGK6J3R92I8Yipi9sU8jvWL1cd+FPtMEiZZJjkeh8QlxnXHTcRz4nPj
h+O/TnBKUCXsTZhJDEpsTjyeREhKSdqQdENqJ5VLd0tnkkOSlyWfTqGnZKcMp3yT6pmqTz2WBqcl
p21Mu73QdaF24Xg6SJemb0y/kyHIqMn4QyYxMyNzJPMvWaKslqyz2dzs4uw92U9zYnP6cm7luuca
c0/mMfOK8nbnPcuPy+/Pn1zku2jZovMF1gXqgiOFpMK8wp2Fs4vjF29aPF0UVNRVdH2JYEnDknNL
rZdWLf2kmFksKz5UQijJL9lT8oMsXTYqmy2Vlr5XOiOXyDfLHyqiFQOKB8oIZb/yXllEWX/ZfVWE
aqPqQXlU+WD5I7VEPaz+tiKpYnvFs8r0yg8rf6zKrzqgIWtKNEe1HG2l9nS1fXVD9SWdl65LN1kT
VrOpZkafot9ZC9UuqT1i4OE/UxeM7saVxqm6yLqRuuf1efWHGtgN2oYLjZ6NaxrvNSU0/aYZbZY3
n2xxbGlvmVoWs2xHK9Ra2nqyzbmts216eeLyXe3U9sr2P3X4dfR3fL8if8WxTrvO5Z13Vyau3Ntl
1qXvurEqfNX21ehq9eqJNQFrtqx53a3o/qLHr2ew54deee8Xa0Vrh9b+uK5s3URfcN+29cT12vXX
N0Rt2NXP7m/qv7sxbePhAWyge+D7TcWbzg0GDm7fTN1s3Dw5lPpPAKQBW/6YuJkkmZCZ/JpomtWb
QpuvnByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adu
p+CoUqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0
nLUTtYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hj
wl/C28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQ
OdC60TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i
3ynfr+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7Zzu
KO6070DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26
/kv+3P9t//8CDAD3hPP7Cg0KZW5kc3RyZWFtDWVuZG9iag0xIDAgb2JqPDwvQ3JvcEJveFswIDAg
NjEyIDc5Ml0vUGFyZW50IDYgMCBSL0NvbnRlbnRzIDMgMCBSL1JvdGF0ZSA5MC9NZWRpYUJveFsw
IDAgNjEyIDc5Ml0vUmVzb3VyY2VzIDIgMCBSL1R5cGUvUGFnZT4+DWVuZG9iag0yIDAgb2JqPDwv
Q29sb3JTcGFjZTw8L0NzNiAxNCAwIFI+Pi9Gb250PDwvVFQyIDEzIDAgUj4+L1Byb2NTZXRbL1BE
Ri9UZXh0XS9FeHRHU3RhdGU8PC9HUzEgMTYgMCBSPj4+Pg1lbmRvYmoNMyAwIG9iajw8L0xlbmd0
aCAzNTIvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJdJHPbsMgDMbveQofiVQoJDRNrvuj
aTuu3KYdKHFaqpZMga7bg+x9B8m6rofJSLYs+8f3wfzWV2A8iDG8cdn8YSVg47OygngWksOy4DBg
1mU3KpsrVcRB1WUcZMmaGuiUOAhRp6JoasZrUIc4kSIxOeOcL0CZ2FOnjKwMOj3Y3udqF1ulGEFT
iqCmYksJy4YVVeLQcV2m9RfylVPZSFaRNudMkkF3gVoMHUVtqT9zKRcsfIT8VT1FPhVMlg2oux9U
mUT8ohbkMY99QVp0wXYWPZz0pwfr4LS1Zgthix5hYrFayjIBRVOPxAuQ+Dc0cd/oYHsXIXa/hzXC
0WML2rWJA0b7yJ9sR0rB01OddVXJIgl92jL9Ow7YsjRKL9de+RifZCrFlaWKPCdLFcHOOjxEX34G
62MA14etdRs46F0/zMBbZxD22of/7P0RNn3dATFEwqjrXmXfAgwA5rOUBQoNCmVuZHN0cmVhbQ1l
bmRvYmoNNCAwIG9iajw8L051bXNbMCA1IDAgUl0+Pg1lbmRvYmoNNSAwIG9iajw8L1MvRD4+DWVu
ZG9iag02IDAgb2JqPDwvQ291bnQgMi9UeXBlL1BhZ2VzL0tpZHNbMTEgMCBSIDEgMCBSXT4+DWVu
ZG9iag03IDAgb2JqPDwvU3VidHlwZS9YTUwvTGVuZ3RoIDM1NjMvVHlwZS9NZXRhZGF0YT4+c3Ry
ZWFtDQo8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/
Pgo8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSIzLjEtNzAxIj4K
ICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1z
eW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAg
ICAgeG1sbnM6cGRmPSJodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvIj4KICAgICAgICAgPHBk
ZjpQcm9kdWNlcj5BY3JvYmF0IERpc3RpbGxlciA3LjAuNSAoV2luZG93cyk8L3BkZjpQcm9kdWNl
cj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFi
b3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnhhcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w
LyI+CiAgICAgICAgIDx4YXA6Q3JlYXRvclRvb2w+UFNjcmlwdDUuZGxsIFZlcnNpb24gNS4yLjI8
L3hhcDpDcmVhdG9yVG9vbD4KICAgICAgICAgPHhhcDpNb2RpZnlEYXRlPjIwMDYtMDctMTFUMDg6
NTc6MTEtMDQ6MDA8L3hhcDpNb2RpZnlEYXRlPgogICAgICAgICA8eGFwOkNyZWF0ZURhdGU+MjAw
Ni0wNy0xMVQwODo1NzoxMS0wNDowMDwveGFwOkNyZWF0ZURhdGU+CiAgICAgIDwvcmRmOkRlc2Ny
aXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4
bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iPgogICAgICAgICA8ZGM6
Zm9ybWF0PmFwcGxpY2F0aW9uL3BkZjwvZGM6Zm9ybWF0PgogICAgICAgICA8ZGM6dGl0bGU+CiAg
ICAgICAgICAgIDxyZGY6QWx0PgogICAgICAgICAgICAgICA8cmRmOmxpIHhtbDpsYW5nPSJ4LWRl
ZmF1bHQiPk1pY3Jvc29mdCBQb3dlclBvaW50IC0gaWV0ZjY2LWVhaS1rbGVuc2luLnBwdDwvcmRm
OmxpPgogICAgICAgICAgICA8L3JkZjpBbHQ+CiAgICAgICAgIDwvZGM6dGl0bGU+CiAgICAgICAg
IDxkYzpjcmVhdG9yPgogICAgICAgICAgICA8cmRmOlNlcT4KICAgICAgICAgICAgICAgPHJkZjps
aT5Kb2huIEtsZW5zaW48L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6U2VxPgogICAgICAgICA8
L2RjOmNyZWF0b3I+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0
aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp4YXBNTT0iaHR0cDovL25zLmFkb2Jl
LmNvbS94YXAvMS4wL21tLyI+CiAgICAgICAgIDx4YXBNTTpEb2N1bWVudElEPnV1aWQ6ZWU1ZTBh
Y2ItMDNhZS00ZmIzLWFmODItZTJhZDBmOWIwZjViPC94YXBNTTpEb2N1bWVudElEPgogICAgICAg
ICA8eGFwTU06SW5zdGFuY2VJRD51dWlkOjg2MDNhNjM1LTU0YTQtNDJmYS1iM2FhLWM4NDMyNWY0
MjY4MTwveGFwTU06SW5zdGFuY2VJRD4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRm
OlJERj4KPC94OnhtcG1ldGE+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg
ICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0idyI/Pg0KZW5kc3RyZWFtDWVuZG9iag04IDAg
b2JqPDwvQ3JlYXRpb25EYXRlKEQ6MjAwNjA3MTEwODU3MTEtMDQnMDAnKS9BdXRob3IoSm9obiBL
bGVuc2luKS9DcmVhdG9yKFBTY3JpcHQ1LmRsbCBWZXJzaW9uIDUuMi4yKS9Qcm9kdWNlcihBY3Jv
YmF0IERpc3RpbGxlciA3LjAuNSBcKFdpbmRvd3NcKSkvTW9kRGF0ZShEOjIwMDYwNzExMDg1NzEx
LTA0JzAwJykvVGl0bGUoTWljcm9zb2Z0IFBvd2VyUG9pbnQgLSBpZXRmNjYtZWFpLWtsZW5zaW4u
cHB0KT4+DWVuZG9iag14cmVmDQowIDkNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwNDk5NCAw
MDAwMCBuDQowMDAwMDA1MTIwIDAwMDAwIG4NCjAwMDAwMDUyMjkgMDAwMDAgbg0KMDAwMDAwNTY0
OSAwMDAwMCBuDQowMDAwMDA1NjgyIDAwMDAwIG4NCjAwMDAwMDU3MDUgMDAwMDAgbg0KMDAwMDAw
NTc2MiAwMDAwMCBuDQowMDAwMDA5NDAxIDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgOT4+DQpz
dGFydHhyZWYNCjExNg0KJSVFT0YNCg==

--==========50A8682F14D71D2CEB36==========
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

--==========50A8682F14D71D2CEB36==========--





From ima-bounces@ietf.org Tue Jul 11 13:56:49 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0MTY-00021N-OD; Tue, 11 Jul 2006 13:56:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0MTX-00021I-Fj
	for ima@ietf.org; Tue, 11 Jul 2006 13:56:47 -0400
Received: from mail02.afilias.info ([69.46.107.12] helo=mail00.afilias.info)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0MTW-0006SP-5w
	for ima@ietf.org; Tue, 11 Jul 2006 13:56:47 -0400
Received: from edmontr3 (h0ca7-net84db.lab.risq.net [132.219.12.167] (may be
	forged)) (authenticated bits=0)
	by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id k6BHubES016543
	for <ima@ietf.org>; Tue, 11 Jul 2006 13:56:40 -0400
Message-ID: <011201c6a513$5636a020$b30110ac@edmontr3>
From: "Edmon Chung" <edmon@afilias.info>
To: <ima@ietf.org>
Date: Tue, 11 Jul 2006 13:54:08 -0400
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Virus-Scanned: ClamAV 0.88/1591/Mon Jul 10 15:41:02 2006 on
	mail00.afilias.info
X-Virus-Status: Clean
X-Spam-Status: No, score=2.5 required=5.0 tests=MAY_BE_FORGED,
	MIME_BASE64_TEXT autolearn=no version=3.1.1
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on mail00.afilias.info
X-Envelope-To: <ima@ietf.org>
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Subject: [EAI] ATOMIC or not
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>
Content-Type: multipart/mixed; boundary="===============1134611133=="
Errors-To: ima-bounces@ietf.org

--===============1134611133==
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

DQpEdXJpbmcgdGhlIHNlc3Npb24gdG9kYXkgaW4gTW9udHJlYWwsIGEgZGlzY3Vzc2lvbiB3YXMg
cmFpc2VkIGFib3V0IHRoZSB1c2Ugb2YgdGhlIEFUT01JQyBwYXJhbWV0ZXIuICBUaGlzIHdhcyBi
cm91Z2h0IHVwIGR1cmluZyB0aGUgZGlzY3Vzc2lvbiBvZiB0aGUgY29uc29saWRhdGlvbiBvZiB1
c2luZyBvbmUgaW5zdGVhZCBvZiAyIHBhcmFtZXRlcnMgaW4gdGhlIFNNVFAgZXh0ZW5zaW9uLCBh
cyB3ZWxsIGFzIHRoZSBzeW50YXggb2Ygd2hldGhlciBzdWNoIGEgcGFyYW1ldGVyIHNob3VsZCBi
ZSB3aXRoaW4gdGhlIHJlZ3VsYXIgYWRkcmVzcyBhbmdsZWQgYnJhY2tldHMgIjw+IiBvciBvdXRz
aWRlLiAgQSBzdWdnZXN0aW9uIHdhcyBtYWRlIHRvIGVsaW1pbmF0ZSB0aGUgdXNlIG9mIHRoZSBB
VE9NSUMgaWRlbnRpZmljYXRpb24gY29tcGxldGVseSBhbmQgYSBjb25zZW5zdXMgd2FzIHNvdWdo
dCwgd2hpY2ggc2hvd2VkIHN1cHBvcnQgaW4gdGhlIHJvb20uICBIb3dldmVyLCBpdCBvY2N1cnJl
ZCB0byBtZSB0aGF0IG1hbnkgaW4gdGhlIHJvb20gd2FzIGEgYml0IGNvbmZ1c2VkIGFib3V0IHdo
YXQgd2FzIGJlaW5nIGRlY2lkZWQuICBUaGlzIGlzIGV4ZW1wbGlmaWVkIEkgdGhpbmsgYnkgdGhl
IGNvbnRpbnVlZCBkaXNjdXNzaW9uIGFib3V0IGhhdmluZyBhbiBBVE9NSUMgInRyYW5zZm9ybWVk
IiBmb3JtYXQgb2YgYW4gaW50ZXJuYXRpb25hbGl6ZWQgZW1haWwgYWRkcmVzcyBpbiB0aGUgc3Vi
c2VxdWVudCBkcmFmdCBkaXNjdXNzaW9ucyBieSB0aGUgcmVzcGVjdGl2ZSBhdXRob3JzLg0KDQpC
ZWNhdXNlIGFsbW9zdCBhbGwgb2YgdGhlIGN1cnJlbnQgZHJhZnRzIGluY2x1ZGUgdGhlIGNvbmNl
cHQgb2YgaGF2aW5nIGFuIEFUT01JQyBwYXJhbWV0ZXIsIEkgdGhpbmsgaXQgaXMgcHJ1ZGVudCB0
aGF0IHdlIGhhdmUgYSBtb3JlIGluZGVwdGggZGlzY3Vzc2lvbiBvbiB0aGUgc3ViamVjdC4NCg0K
QmVmb3JlIGp1bXBpbmcgdG8gdGhlIGRpc2N1c3Npb24sIGl0IGlzIHVzZWZ1bCBJIHRoaW5rIHRv
IHBvaW50IG91dCB0aGF0IChhdCBsZWFzdCBhcyBmYXIgYXMgbXkgdW5kZXJzdGFuZGluZyBnb2Vz
KSB0aGUgdXNlIG9mIEFUT01JQyBwcmVzdW1lcyB0aGF0IGluIGNvbmp1bmN0aW9uIHRoZXJlIGlz
IGEgZ2VuZXJhbGx5IGtub3duIGFsZ29yaXRobSB0aGF0IGNhbiBiZSB1c2VkIHRvIHRyYW5zZm9y
bSAoImRvd25ncmFkZSIgb3IgInVwZ3JhZGUiKSBhbiBpbnRlcm5hdGlvbmFsaXplZCBlbWFpbCBh
ZGRyZXNzLiAgVGhlcmVmb3JlLCBpZiBhbiBpbnRlcm5hdGlvbmFsaXplZCBlbWFpbCBhZGRyZXNz
IGNhbiBiZSBzdWNoICJ0cmFuc2Zvcm1lZCIsIHRoZW4gdGhlIEFUT01JQyBiaXQgY2FuIGJlIHNl
dC4gIFRoaXMgd2lsbCBhbGxvdyBtYWlsIHNlcnZlcnMgdG8gZG93bmdyYWRlL3VwZ3JhZGUgYW4g
YWRkcmVzcyB3aGVuIG5lZWRlZC4NCg0KRnJvbSBib3RoIHRoZSBIZWFkZXJzIGRvY3VtZW50IGFz
IHdlbGwgYXMgdGhlIERvd25ncmFkZSBkb2N1bWVudCwgaXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUg
QVRPTUlDICJmbGFnIiBtYXkgYmUgdXNlZnVsLiAgVGhlIHByZXNlbnRhdGlvbiBmcm9tIE5haSBX
ZW4gKFRXTklDKSwgZXNwZWNpYWxseSBoaXMgdHJpYWwvZGVtbyBkaXNjdXNzaW9uLCBhbHNvIHNl
ZW0gdG8gc3VnZ2VzdCB0aGF0IGhhdmluZyB0aGUgQVRPTUlDIChtb3JlIGltcG9ydGFudGx5IHRo
ZSBhbGdvcml0aG0gZm9yIHRyYW5zZm9ybWluZyB0byBhIGRvd25ncmFkZWQgZm9ybWF0KSBmdW5j
dGlvbmFsaXR5IG1heWJlIHZlcnkgdXNlZnVsLg0KDQpUaGUgYXJndW1lbnQgcHV0IGZvcnRoIGFn
YWluc3QgaGF2aW5nIEFUT01JQyB3YXMgY2xlYXI6IHRoZSBzZW5kZXIgY291bGQgYWx3YXlzIHVz
ZSBhIHBhcnRpY3VsYXIgYWxnb3JpdGhtIHRvIHByb3ZpZGUgYW4gYWx0LWFkZHJlc3MgYW5kIHRo
ZXJlZm9yZSwgc2ltcGx5IGhhdmluZyBhbiBvcHRpb24gdG8gYW5ub3VuY2UgYW4gYWx0LWFkZHJl
c3MgaXMgZ29vZCBlbm91Z2guDQoNClRoZSBhcmd1bWVudCBmb3IgaGF2aW5nIHRoZSBBVE9NSUMg
d2FzIG5vdCB0aGF0IGNsZWFyIChwZXJoYXBzIG90aGVycyBjYW4gYWRkKS4gIEluIG15IG1pbmQs
IEkgdGhpbmsgdGhlIHVzZWZ1bG5lc3Mgb2YgaGF2aW5nIHRoZSBBVE9NSUMgZmxhZyBpcyBub3Qg
b25seSB0aGF0IGl0IGFsbG93cyBhIG1vcmUgY29uY2lzZSB3YXkgb2Ygc2VuZGluZy9zdG9yaW5n
IGRvd25ncmFkZSBkYXRhLCBpdCBpcyBtdWNoIGJldHRlciBmb3IgdHJhbnNwb3J0YWJpbGl0eSBh
bmQgcGFzc2luZyBhcm91bmQuICBCZWNhdXNlIG1haWwgaXMgcGFzc2VkIGFyb3VuZCBzaWdpbmlm
aWNhbnRseSwgdGhpcyBpcyBhbiBpbXBvcnRhbnQgY29uc2lkZXJhdGlvbiBpbiBteSBtaW5kLiAg
V2hhdCBoYWQgTk9UIGJlZW4gZGlzY3Vzc2VkIGluIHRoZSBjdXJyZW50IHNldCBvZiBkcmFmdHMg
aXMgd2hldGhlciBhbiAiYWx0LWFkZHJlc3MiIGNhbiBzdXJ2aXZlIG1vcmUgdGhhbiBvbmUgc2Vy
aWVzIG9mIHRyYW5zcG9ydC4gIEkuZS4sIGlmIEkgaGF2ZSBvYnRhaW5lZCBhbiBhbHQtYWRkcmVz
cyBmcm9tIGEgcGFydGljdWxhciBpbnRlcm5hdGlvbmFsaXplZCBlbWFpbCBhZGRyZXNzIGJlZm9y
ZSwgY2FuIEkgdXNlIGl0IGFnYWluIGluIHRoZSBmdXR1cmU/Li4uIFdpdGggQVRPTUlDLCB0aGlz
IGNhbiBiZSBzYWZlbHkgYXNzdW1lZC4gIFdpdGggYWx0LWFkZHJlc3MsIHRoaXMgY2Fubm90IGJl
IGFzc3VtZWQuICBXaXRob3V0IHRoZSBhYmlsaXR5IG9mIHVzaW5nIGRvd25ncmFkZSBpbmZvcm1h
dGlvbiwgZG93bmdyYWRlIG1heSBpbiBpdHNlbGYgYmVjb21lIG11Y2ggbGVzcyB1c2VmdWwsIGJl
Y2F1c2Ugd2hlbiBkb3duZ3JhZGUgaXMgbW9zdCBuZWVkZWQsIG9mdGVuIHRoZSBkb3duZ3JhZGUg
aW5mb3JtYXRpb24gd291bGQgbm90IGJlIGF2YWlsYWJsZS4gIEV2ZW4gaWYgSSBoYXZlIG9idGFp
bmVkIGFuIGFsdC1hZGRyZXNzIGJlZm9yZSBJIGNhbm5vdCBhc3N1bWUgdGhhdCBJIGNhbiB1c2Ug
aXQgYWdhaW4gKG9yIGNhbiBJPykuLi4gYnV0IHdpdGggQVRPTUlDLCBJIGNhbiBhc3N1bWUgdGhh
dCB0aGUgZG93bmdyYWRlIGlzIGFwcGxpY2FibGUgaW4gdGhlIGZ1dHVyZS4gIEFuIE1VQSBvciBh
biBNVEEgY291bGQgdGhlcmVmb3JlIHN0b3JlIHRoZXNlIGluZm9ybWF0aW9uIGZvciBtZWFuaW5n
ZnVsIHJldXNlLg0KDQpUaGUgcHJvYmxlbSBvdmVyYWxsIG9mIGNvdXJzZSBpcyB0aGF0IChpZiBt
eSBhc3N1bXB0aW9uIGVhcmxpZXIgd2FzIGNvcnJlY3QpLCBhbmQgaWYgd2Uga2VlcCBBVE9NSUMs
IHdlIHdpbGwgbmVlZCB0byBkZWZpbmUgYSBrbm93biBhbGdvcml0aG0gZm9yIHRyYW5zZm9ybWlu
ZyBhbiBhZGRyZXNzLg0KDQpBbnl3YXksIGFuIGltcG9ydGFudCBwb2ludCBpcywgYXQgbGVhc3Qg
Zm9yIG15c2VsZiwgSSBhbSBub3QgcmVhZHkgdG8gY29tcGxldGVseSBlbGltaW5hdGUgQVRPTUlD
IHlldCB1bnRpbCB0aGVyZSBpcyBmdXJ0aGVyIHRob3VnaHQgb24gdGhlIGlzc3VlcyBhdCBzdGFr
ZS4gIEkgc3VzcGVjdCB0aGVyZSBhcmUgb3RoZXJzIHRoYXQgc2hhcmUgbXkgY29uY2Vybi4uLiBh
bmQgbW9yZSB0aGF0IGFyZSBqdXN0IGdlbmVyYWxseSBjb25mdXNlZCBiZWNhdXNlIG9mIHRoZSBu
dW1iZXIgb2YgaW5jb25zaXN0ZW5jaWVzIGJldHdlZW4gdGhlIGN1cnJlbnQgc2V0IG9mIGRyYWZ0
cy4uLiBQZXJoYXBzIGlmIGFuZCB3aGVuIHRoZSBkcmFmdHMgYXJlIG1vcmUgY29uc2lzdGVudCwg
dGhlIHVzZWZ1bG5lc3MgKG9yIHVzZWxlc3NuZXNzKSBvZiB0aGUgQVRPTUlDIHBhcmFtZXRlci9v
cHRpb24gY2FuIGJlIGJldHRlciBldmFsdWF0ZWQuLi4NCg0KRWRtb24NCg0KDQo=




--===============1134611133==
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

--===============1134611133==--



From ima-bounces@ietf.org Tue Jul 11 14:14:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0Mkw-0007Bp-VM; Tue, 11 Jul 2006 14:14:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Mkv-0007AH-Qh
	for ima@ietf.org; Tue, 11 Jul 2006 14:14:45 -0400
Received: from [159.226.7.146] (helo=cnnic.cn)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0Mkv-0002PC-3h
	for ima@ietf.org; Tue, 11 Jul 2006 14:14:45 -0400
Received: (eyou send program); Wed, 12 Jul 2006 02:14:33 +0800
Message-ID: <352641673.20417@cnnic.cn>
X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn
Received: from unknown (HELO yaojk) (127.0.0.1)
	by 127.0.0.1 with SMTP; Wed, 12 Jul 2006 02:14:33 +0800
Message-ID: <009a01c6a515$e148d1e0$f311db84@YaoJK>
From: "Yao Jiankang" <yaojk@cnnic.cn>
To: "Edmon Chung" <edmon@afilias.info>,
	<ima@ietf.org>
References: <352640609.21083@cnnic.cn>
Subject: Re: [EAI] ATOMIC or not
Date: Wed, 12 Jul 2006 02:14:33 +0800
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.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
X-Spam-Score: 0.5 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
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

according to my understanding in the meeting, it seems that we have a rough
consensus about removing the "atomic" parameter although some still prefer
atomic. Yes, If someone still prefer atomic and do some algorithmic
transformation from UTF-8 address to ASCII address, in operation guideline
document, we may suggest some  algorithmic transformation method to
transform the UTF-8 address to ASCII address as the alt-address if some one
perfer transformation address as the alt-address instead of another ascii
address.

Yao Jiankang



----- Original Message ----- 
From: "Edmon Chung" <edmon@afilias.info>
To: <ima@ietf.org>
Sent: Wednesday, July 12, 2006 1:54 AM
Subject: [EAI] ATOMIC or not


>
> During the session today in Montreal, a discussion was raised about the
use of the ATOMIC parameter.  This was brought up during the discussion of
the consolidation of using one instead of 2 parameters in the SMTP
extension, as well as the syntax of whether such a parameter should be
within the regular address angled brackets "<>" or outside.  A suggestion
was made to eliminate the use of the ATOMIC identification completely and a
consensus was sought, which showed support in the room.  However, it
occurred to me that many in the room was a bit confused about what was being
decided.  This is exemplified I think by the continued discussion about
having an ATOMIC "transformed" format of an internationalized email address
in the subsequent draft discussions by the respective authors.
>
> Because almost all of the current drafts include the concept of having an
ATOMIC parameter, I think it is prudent that we have a more indepth
discussion on the subject.
>
> Before jumping to the discussion, it is useful I think to point out that
(at least as far as my understanding goes) the use of ATOMIC presumes that
in conjunction there is a generally known algorithm that can be used to
transform ("downgrade" or "upgrade") an internationalized email address.
Therefore, if an internationalized email address can be such "transformed",
then the ATOMIC bit can be set.  This will allow mail servers to
downgrade/upgrade an address when needed.
>
> From both the Headers document as well as the Downgrade document, it seems
to me that the ATOMIC "flag" may be useful.  The presentation from Nai Wen
(TWNIC), especially his trial/demo discussion, also seem to suggest that
having the ATOMIC (more importantly the algorithm for transforming to a
downgraded format) functionality maybe very useful.
>
> The argument put forth against having ATOMIC was clear: the sender could
always use a particular algorithm to provide an alt-address and therefore,
simply having an option to announce an alt-address is good enough.
>
> The argument for having the ATOMIC was not that clear (perhaps others can
add).  In my mind, I think the usefulness of having the ATOMIC flag is not
only that it allows a more concise way of sending/storing downgrade data, it
is much better for transportability and passing around.  Because mail is
passed around siginificantly, this is an important consideration in my mind.
What had NOT been discussed in the current set of drafts is whether an
"alt-address" can survive more than one series of transport.  I.e., if I
have obtained an alt-address from a particular internationalized email
address before, can I use it again in the future?... With ATOMIC, this can
be safely assumed.  With alt-address, this cannot be assumed.  Without the
ability of using downgrade information, downgrade may in itself become much
less useful, because when downgrade is most needed, often the downgrade
information would not be available.  Even if I have obtained an alt-address
before I cannot assume that I can use it again (or can I?)... but with
ATOMIC, I can assume that the downgrade is applicable in the future.  An MUA
or an MTA could therefore store these information for meaningful reuse.
>
> The problem overall of course is that (if my assumption earlier was
correct), and if we keep ATOMIC, we will need to define a known algorithm
for transforming an address.
>
> Anyway, an important point is, at least for myself, I am not ready to
completely eliminate ATOMIC yet until there is further thought on the issues
at stake.  I suspect there are others that share my concern... and more that
are just generally confused because of the number of inconsistencies between
the current set of drafts... Perhaps if and when the drafts are more
consistent, the usefulness (or uselessness) of the ATOMIC parameter/option
can be better evaluated...
>
> Edmon
>
>
>


----------------------------------------------------------------------------
----


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


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



From ima-bounces@ietf.org Tue Jul 11 14:40:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0NA3-0002AC-Kz; Tue, 11 Jul 2006 14:40:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0NA2-0002A7-TN
	for ima@ietf.org; Tue, 11 Jul 2006 14:40:42 -0400
Received: from twnic.net.tw ([211.72.210.250])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0NA1-0003BL-QL
	for ima@ietf.org; Tue, 11 Jul 2006 14:40:42 -0400
Received: from [211.72.211.90] (pc090.twnic.net.tw [211.72.211.90])
	(authenticated bits=0)
	by twnic.net.tw (8.13.6/8.13.5) with ESMTP id k6BIeQEr021606;
	Wed, 12 Jul 2006 02:40:29 +0800
Message-ID: <44B3F09C.3090107@twnic.net.tw>
Date: Wed, 12 Jul 2006 02:40:28 +0800
From: Nai-Wen Hsu <snw@twnic.net.tw>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: zh-tw, en-us, en
MIME-Version: 1.0
To: Edmon Chung <edmon@afilias.info>
Subject: Re: [EAI] ATOMIC or not
References: <011201c6a513$5636a020$b30110ac@edmontr3>
In-Reply-To: <011201c6a513$5636a020$b30110ac@edmontr3>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f
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>
Content-Type: multipart/mixed; boundary="===============0048370248=="
Errors-To: ima-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0048370248==
Content-Type: multipart/alternative;
	boundary="------------010207060709000908080508"

This is a multi-part message in MIME format.
--------------010207060709000908080508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Although the trial system very depend on the ATOMIC flag to transform=20
the utf8 email address to downgraded format, but I think it is ok to=20
remove ATOMIC flag, because MUA can transform to downgraded fromat and=20
put it into alt-address before sending out the mail.

Nai-Wen Hsu

Edmon Chung :

>During the session today in Montreal, a discussion was raised about the =
use of the ATOMIC parameter.  This was brought up during the discussion o=
f the consolidation of using one instead of 2 parameters in the SMTP exte=
nsion, as well as the syntax of whether such a parameter should be within=
 the regular address angled brackets "<>" or outside.  A suggestion was m=
ade to eliminate the use of the ATOMIC identification completely and a co=
nsensus was sought, which showed support in the room.  However, it occurr=
ed to me that many in the room was a bit confused about what was being de=
cided.  This is exemplified I think by the continued discussion about hav=
ing an ATOMIC "transformed" format of an internationalized email address =
in the subsequent draft discussions by the respective authors.
>
>Because almost all of the current drafts include the concept of having a=
n ATOMIC parameter, I think it is prudent that we have a more indepth dis=
cussion on the subject.
>
>Before jumping to the discussion, it is useful I think to point out that=
 (at least as far as my understanding goes) the use of ATOMIC presumes th=
at in conjunction there is a generally known algorithm that can be used t=
o transform ("downgrade" or "upgrade") an internationalized email address=
=2E  Therefore, if an internationalized email address can be such "transf=
ormed", then the ATOMIC bit can be set.  This will allow mail servers to =
downgrade/upgrade an address when needed.
>
>From both the Headers document as well as the Downgrade document, it see=
ms to me that the ATOMIC "flag" may be useful.  The presentation from Nai=
 Wen (TWNIC), especially his trial/demo discussion, also seem to suggest =
that having the ATOMIC (more importantly the algorithm for transforming t=
o a downgraded format) functionality maybe very useful.
>
>The argument put forth against having ATOMIC was clear: the sender could=
 always use a particular algorithm to provide an alt-address and therefor=
e, simply having an option to announce an alt-address is good enough.
>
>The argument for having the ATOMIC was not that clear (perhaps others ca=
n add).  In my mind, I think the usefulness of having the ATOMIC flag is =
not only that it allows a more concise way of sending/storing downgrade d=
ata, it is much better for transportability and passing around.  Because =
mail is passed around siginificantly, this is an important consideration =
in my mind.  What had NOT been discussed in the current set of drafts is =
whether an "alt-address" can survive more than one series of transport.  =
I.e., if I have obtained an alt-address from a particular internationaliz=
ed email address before, can I use it again in the future?... With ATOMIC=
, this can be safely assumed.  With alt-address, this cannot be assumed. =
 Without the ability of using downgrade information, downgrade may in its=
elf become much less useful, because when downgrade is most needed, often=
 the downgrade information would not be available.  Even if I have obtain=
ed an alt-address before I cannot assume that I can use it again (or can =
I?)... but with ATOMIC, I can assume that the downgrade is applicable in =
the future.  An MUA or an MTA could therefore store these information for=
 meaningful reuse.
>
>The problem overall of course is that (if my assumption earlier was corr=
ect), and if we keep ATOMIC, we will need to define a known algorithm for=
 transforming an address.
>
>Anyway, an important point is, at least for myself, I am not ready to co=
mpletely eliminate ATOMIC yet until there is further thought on the issue=
s at stake.  I suspect there are others that share my concern... and more=
 that are just generally confused because of the number of inconsistencie=
s between the current set of drafts... Perhaps if and when the drafts are=
 more consistent, the usefulness (or uselessness) of the ATOMIC parameter=
/option can be better evaluated...
>
>Edmon
>
>
> =20
>
>------------------------------------------------------------------------=

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


--------------010207060709000908080508
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Although the trial system very depend on the ATOMIC flag to transform
the utf8 email address to downgraded format, but I think it is ok to
remove ATOMIC flag, because MUA can transform to downgraded fromat and
put it into alt-address before sending out the mail.<br>
<br>
Nai-Wen Hsu<br>
<br>
Edmon Chung :
<blockquote cite="mid011201c6a513$5636a020$b30110ac@edmontr3"
 type="cite">
  <pre wrap="">During the session today in Montreal, a discussion was raised about the use of the ATOMIC parameter.  This was brought up during the discussion of the consolidation of using one instead of 2 parameters in the SMTP extension, as well as the syntax of whether such a parameter should be within the regular address angled brackets "&lt;&gt;" or outside.  A suggestion was made to eliminate the use of the ATOMIC identification completely and a consensus was sought, which showed support in the room.  However, it occurred to me that many in the room was a bit confused about what was being decided.  This is exemplified I think by the continued discussion about having an ATOMIC "transformed" format of an internationalized email address in the subsequent draft discussions by the respective authors.

Because almost all of the current drafts include the concept of having an ATOMIC parameter, I think it is prudent that we have a more indepth discussion on the subject.

Before jumping to the discussion, it is useful I think to point out that (at least as far as my understanding goes) the use of ATOMIC presumes that in conjunction there is a generally known algorithm that can be used to transform ("downgrade" or "upgrade") an internationalized email address.  Therefore, if an internationalized email address can be such "transformed", then the ATOMIC bit can be set.  This will allow mail servers to downgrade/upgrade an address when needed.

>From both the Headers document as well as the Downgrade document, it seems to me that the ATOMIC "flag" may be useful.  The presentation from Nai Wen (TWNIC), especially his trial/demo discussion, also seem to suggest that having the ATOMIC (more importantly the algorithm for transforming to a downgraded format) functionality maybe very useful.

The argument put forth against having ATOMIC was clear: the sender could always use a particular algorithm to provide an alt-address and therefore, simply having an option to announce an alt-address is good enough.

The argument for having the ATOMIC was not that clear (perhaps others can add).  In my mind, I think the usefulness of having the ATOMIC flag is not only that it allows a more concise way of sending/storing downgrade data, it is much better for transportability and passing around.  Because mail is passed around siginificantly, this is an important consideration in my mind.  What had NOT been discussed in the current set of drafts is whether an "alt-address" can survive more than one series of transport.  I.e., if I have obtained an alt-address from a particular internationalized email address before, can I use it again in the future?... With ATOMIC, this can be safely assumed.  With alt-address, this cannot be assumed.  Without the ability of using downgrade information, downgrade may in itself become much less useful, because when downgrade is most needed, often the downgrade information would not be available.  Even if I have obtained an alt-address before I cannot assume 
that I can use it again (or can I?)... but with ATOMIC, I can assume that the downgrade is applicable in the future.  An MUA or an MTA could therefore store these information for meaningful reuse.

The problem overall of course is that (if my assumption earlier was correct), and if we keep ATOMIC, we will need to define a known algorithm for transforming an address.

Anyway, an important point is, at least for myself, I am not ready to completely eliminate ATOMIC yet until there is further thought on the issues at stake.  I suspect there are others that share my concern... and more that are just generally confused because of the number of inconsistencies between the current set of drafts... Perhaps if and when the drafts are more consistent, the usefulness (or uselessness) of the ATOMIC parameter/option can be better evaluated...

Edmon


  </pre>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
IMA mailing list
<a class="moz-txt-link-abbreviated" href="mailto:IMA@ietf.org">IMA@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/ima">https://www1.ietf.org/mailman/listinfo/ima</a>
  </pre>
</blockquote>
<br>
</body>
</html>

--------------010207060709000908080508--


--===============0048370248==
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

--===============0048370248==--




From ima-bounces@ietf.org Tue Jul 11 14:46:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0NFo-0002WE-8E; Tue, 11 Jul 2006 14:46:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0NFn-0002W9-FO
	for ima@ietf.org; Tue, 11 Jul 2006 14:46:39 -0400
Received: from sniper.icu.ac.kr ([210.107.128.51])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0NFk-0003uC-Nk
	for ima@ietf.org; Tue, 11 Jul 2006 14:46:39 -0400
Received: (snipe 8145 invoked by uid 0); 12 Jul 2006 02:49:54 +0900
Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.514796
	secs); 
Received: from unknown (HELO ?132.219.4.247?) (ZU??own@132.219.4.247)
	by unknown with SMTP; 12 Jul 2006 02:49:53 +0900
X-RCPTTO: edmon@afilias.info,
	ima@ietf.org
Message-ID: <44B3F203.2090907@icu.ac.kr>
Date: Wed, 12 Jul 2006 03:46:27 +0900
From: Yangwoo Ko <newcat@icu.ac.kr>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Edmon Chung <edmon@afilias.info>
Subject: Re: [EAI] ATOMIC or not
References: <011201c6a513$5636a020$b30110ac@edmontr3>
In-Reply-To: <011201c6a513$5636a020$b30110ac@edmontr3>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
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


Edmon Chung wrote:
> During the session today in Montreal, a discussion was raised about
> the use of the ATOMIC parameter.  This was brought up during the
> discussion of the consolidation of using one instead of 2 parameters
> in the SMTP extension, as well as the syntax of whether such a
> parameter should be within the regular address angled brackets "<>" or
> outside.  A suggestion was made to eliminate the use of the ATOMIC
> identification completely and a consensus was sought, which showed
> support in the room.  However, it occurred to me that many in the room
> was a bit confused about what was being decided.  This is exemplified
> I think by the continued discussion about having an ATOMIC
> "transformed" format of an internationalized email address in the
> subsequent draft discussions by the respective authors.
> 
> Because almost all of the current drafts include the concept of having
> an ATOMIC parameter, I think it is prudent that we have a more indepth
> discussion on the subject.
> 
> Before jumping to the discussion, it is useful I think to point out
> that (at least as far as my understanding goes) the use of ATOMIC
> presumes that in conjunction there is a generally known algorithm that
> can be used to transform ("downgrade" or "upgrade") an
> internationalized email address.  Therefore, if an internationalized
> email address can be such "transformed", then the ATOMIC bit can be
> set.  This will allow mail servers to downgrade/upgrade an address
> when needed.
> 
> From both the Headers document as well as the Downgrade document, it
> seems to me that the ATOMIC "flag" may be useful.  The presentation
> from Nai Wen (TWNIC), especially his trial/demo discussion, also seem
> to suggest that having the ATOMIC (more importantly the algorithm for
> transforming to a downgraded format) functionality maybe very useful.
> 
> The argument put forth against having ATOMIC was clear: the sender
> could always use a particular algorithm to provide an alt-address and
> therefore, simply having an option to announce an alt-address is good
> enough.
> 
> The argument for having the ATOMIC was not that clear (perhaps others
> can add).  In my mind, I think the usefulness of having the ATOMIC
> flag is not only that it allows a more concise way of sending/storing
> downgrade data, it is much better for transportability and passing
> around.  Because mail is passed around siginificantly, this is an
> important consideration in my mind.  What had NOT been discussed in
> the current set of drafts is whether an "alt-address" can survive more
> than one series of transport.  I.e., if I have obtained an alt-address
> from a particular internationalized email address before, can I use it
> again in the future?... With ATOMIC, this can be safely assumed.  With
> alt-address, this cannot be assumed.  Without the ability of using
> downgrade information, downgrade may in itself become much less
> useful, because when downgrade is most needed, often the downgrade
> information would not be available.  Even if I have obtained an
> alt-address before I cannot assume that I can use it again (or can
> I?)... but with ATOMIC, I can assume that the downgrade is applicable
> in the future.  An MUA or an MTA could therefore store these
> information for meaningful reuse.

We can provide an ALT-ADDR of an i18n email address because the holder
of the address gave that information. And this is same for ATOMIC.

Association of of an ALT-ADDR and an i18n address can be broken in the
future. And, once again, so is ATMOCity of an address. However the
latter is far less probably than the former.

> 
> The problem overall of course is that (if my assumption earlier was
> correct), and if we keep ATOMIC, we will need to define a known
> algorithm for transforming an address.

Even though we remove ATOMIC as an element of protocol specification,
we can still reuse the concept as a part of email address management
practice supported by MUAs.

> 
> Anyway, an important point is, at least for myself, I am not ready to
> completely eliminate ATOMIC yet until there is further thought on the
> issues at stake.  I suspect there are others that share my concern...
> and more that are just generally confused because of the number of
> inconsistencies between the current set of drafts... Perhaps if and
> when the drafts are more consistent, the usefulness (or uselessness)
> of the ATOMIC parameter/option can be better evaluated...
>
> 
> Edmon
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www1.ietf.org/mailman/listinfo/ima


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



From ima-bounces@ietf.org Tue Jul 11 16:36:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0OyM-00079Q-C5; Tue, 11 Jul 2006 16:36:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0OyL-00079B-HJ
	for ima@ietf.org; Tue, 11 Jul 2006 16:36: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 1G0OyL-0000hf-Fn
	for ima@ietf.org; Tue, 11 Jul 2006 16:36:45 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0OmD-0003qB-9x
	for ima@ietf.org; Tue, 11 Jul 2006 16:24:15 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6BKNli5015240
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Jul 2006 13:23:48 -0700
Received: from [142.131.134.210] (vpn-10-50-16-148.qualcomm.com [10.50.16.148])
	by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6BKNjFG023810; 
	Tue, 11 Jul 2006 13:23:46 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p0630000bc0d9b50c344b@[142.131.134.210]>
In-Reply-To: <011201c6a513$5636a020$b30110ac@edmontr3>
References: <011201c6a513$5636a020$b30110ac@edmontr3>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Tue, 11 Jul 2006 13:19:06 -0700
To: "Edmon Chung" <edmon@afilias.info>, <ima@ietf.org>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [EAI] ATOMIC or not
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac
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 1:54 PM -0400 7/11/06, Edmon Chung wrote:

>  During the session today in Montreal, a discussion was raised about 
> the use of the ATOMIC parameter.  This was brought up during the 
> discussion of the consolidation of using one instead of 2 
> parameters in the SMTP extension, as well as the syntax of whether 
> such a parameter should be within the regular address angled 
> brackets "<>" or outside.  A suggestion was made to eliminate the 
> use of the ATOMIC identification completely and a consensus was 
> sought, which showed support in the room.  However, it occurred to 
> me that many in the room was a bit confused about what was being 
> decided.

I'd like to clarify the proposal was to eliminate ATOMIC by combining 
it with ALT-ADDRESS.  More details in-line.

>   This is exemplified I think by the continued discussion about 
> having an ATOMIC "transformed" format of an internationalized email 
> address in the subsequent draft discussions by the respective 
> authors.
>
>  Because almost all of the current drafts include the concept of 
> having an ATOMIC parameter, I think it is prudent that we have a 
> more indepth discussion on the subject.
>
>  Before jumping to the discussion, it is useful I think to point out 
> that (at least as far as my understanding goes) the use of ATOMIC 
> presumes that in conjunction there is a generally known algorithm 
> that can be used to transform ("downgrade" or "upgrade") an 
> internationalized email address.

The proposal does not alter the presence of this algorithm, it only 
alters who uses it and when in the chain.

>    Therefore, if an internationalized email address can be such 
> "transformed", then the ATOMIC bit can be set.  This will allow 
> mail servers to downgrade/upgrade an address when needed.

The proposal is that, rather than carry around the ATOMIC flag and no 
ALT-ADDRESS, just go ahead and use the algorithm on atomic addresses 
for which no other alternative address is available.

Here are the cases:
	1: client knows a good alternate address.

	2: client does not have a good alternate address, but it knows 
the address is transform-safe ("atomic")

	3: client does not have a good alternate address, and does not 
know if the address is transform-safe ("atomic")

So, here is the behavior:

	1: client knows a good alternate address.  It supplies it in ALT-ADDRESS.

	2: client does not have a good alternate address, but it knows 
the address is transform-safe ("atomic").  It performs the 
transformation and supplies this transformed address in ALT-ADDRESS.

	3: client does not have a good alternate address, and does not 
know if the address is transform-safe ("atomic").  It does not supply 
ALT-ADDRESS.


>
>>From both the Headers document as well as the Downgrade document, 
>> it seems to me that the ATOMIC "flag" may be useful.  The 
>> presentation from Nai Wen (TWNIC), especially his trial/demo 
>> discussion, also seem to suggest that having the ATOMIC (more 
>> importantly the algorithm for transforming to a downgraded format) 
>> functionality maybe very useful.

I agree that the more important aspect is the algorithm for doing the 
transformation (in a reversible way).  Passing around the ATOMIC flag 
seems much less useful, to me, as it only makes the SMTP chain more 
complex, without adding any extra benefit that I can see.

>  The argument put forth against having ATOMIC was clear: the sender 
> could always use a particular algorithm to provide an alt-address 
> and therefore, simply having an option to announce an alt-address 
> is good enough.

The sender uses the same algorithm that ATOMIC would permit.  The 
question is simply where this algorithm is performed: at some 
arbitrary point in the SMTP chain, or only at the start?

>  The argument for having the ATOMIC was not that clear (perhaps 
> others can add).  In my mind, I think the usefulness of having the 
> ATOMIC flag is not only that it allows a more concise way of 
> sending/storing downgrade data, it is much better for 
> transportability and passing around.

More concise because it is shorter than ALT-ADDRESS?  Or more concise 
in some other way?

>   Because mail is passed around siginificantly, this is an important 
> consideration in my mind.

In what way?  For server storage of in-transport mail?

>    What had NOT been discussed in the current set of drafts is 
> whether an "alt-address" can survive more than one series of 
> transport.  I.e., if I have obtained an alt-address from a 
> particular internationalized email address before, can I use it 
> again in the future?... With ATOMIC, this can be safely assumed. 
> With alt-address, this cannot be assumed.

The proposal does nothing to change this -- it only discusses where 
the transformation is done in a particular message's path through 
SMTP.  It's the same transformation.

>    Without the ability of using downgrade information, downgrade may 
> in itself become much less useful, because when downgrade is most 
> needed, often the downgrade information would not be available. 
> Even if I have obtained an alt-address before I cannot assume that 
> I can use it again (or can I?)... but with ATOMIC, I can assume 
> that the downgrade is applicable in the future.  An MUA or an MTA 
> could therefore store these information for meaningful reuse.

This suggestion of re-using transformed addresses is not part of the proposal.

>
>  The problem overall of course is that (if my assumption earlier was 
> correct), and if we keep ATOMIC, we will need to define a known 
> algorithm for transforming an address.

Go ahead and define the algorithm, but we don't need the specific 
ATOMIC parameter to do so.

>
>  Anyway, an important point is, at least for myself, I am not ready 
> to completely eliminate ATOMIC yet until there is further thought 
> on the issues at stake.  I suspect there are others that share my 
> concern... and more that are just generally confused because of the 
> number of inconsistencies between the current set of drafts... 
> Perhaps if and when the drafts are more consistent, the usefulness 
> (or uselessness) of the ATOMIC parameter/option can be better 
> evaluated...


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
In politics stupididty is not a handicap.
      --Napoleon

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



From ima-bounces@ietf.org Tue Jul 11 17:20:31 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0Peg-0003u6-1Q; Tue, 11 Jul 2006 17:20:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Pee-0003ti-G7
	for ima@ietf.org; Tue, 11 Jul 2006 17:20:28 -0400
Received: from mail02.afilias.info ([69.46.107.12] helo=mail00.afilias.info)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Ped-0004ot-86
	for ima@ietf.org; Tue, 11 Jul 2006 17:20:28 -0400
Received: from edmontr3 (h18bc-net84db.lab.risq.net [132.219.24.188] (may be
	forged)) (authenticated bits=0)
	by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id k6BLKDQ1029089
	for <ima@ietf.org>; Tue, 11 Jul 2006 17:20:19 -0400
Message-ID: <020101c6a52f$ca3f2660$b30110ac@edmontr3>
From: "Edmon Chung" <edmon@afilias.info>
To: <ima@ietf.org>
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
Subject: Re: [EAI] ATOMIC or not
Date: Tue, 11 Jul 2006 17:19:04 -0400
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Virus-Scanned: ClamAV 0.88/1591/Mon Jul 10 15:41:02 2006 on
	mail00.afilias.info
X-Virus-Status: Clean
X-Spam-Status: No, score=2.5 required=5.0 tests=MAY_BE_FORGED,
	MIME_BASE64_TEXT autolearn=no version=3.1.1
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on mail00.afilias.info
X-Envelope-To: <ima@ietf.org>
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
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>
Content-Type: multipart/mixed; boundary="===============1956811078=="
Errors-To: ima-bounces@ietf.org

--===============1956811078==
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

PiBTbywgaGVyZSBpcyB0aGUgYmVoYXZpb3I6DQo+IA0KPiAxOiBjbGllbnQga25vd3MgYSBnb29k
IGFsdGVybmF0ZSBhZGRyZXNzLiAgSXQgc3VwcGxpZXMgaXQgaW4gQUxULUFERFJFU1MuDQo+IA0K
PiAyOiBjbGllbnQgZG9lcyBub3QgaGF2ZSBhIGdvb2QgYWx0ZXJuYXRlIGFkZHJlc3MsIGJ1dCBp
dCBrbm93cyANCj4gdGhlIGFkZHJlc3MgaXMgdHJhbnNmb3JtLXNhZmUgKCJhdG9taWMiKS4gIEl0
IHBlcmZvcm1zIHRoZSANCj4gdHJhbnNmb3JtYXRpb24gYW5kIHN1cHBsaWVzIHRoaXMgdHJhbnNm
b3JtZWQgYWRkcmVzcyBpbiBBTFQtQUREUkVTUy4NCj4gDQo+IDM6IGNsaWVudCBkb2VzIG5vdCBo
YXZlIGEgZ29vZCBhbHRlcm5hdGUgYWRkcmVzcywgYW5kIGRvZXMgbm90IA0KPiBrbm93IGlmIHRo
ZSBhZGRyZXNzIGlzIHRyYW5zZm9ybS1zYWZlICgiYXRvbWljIikuICBJdCBkb2VzIG5vdCBzdXBw
bHkgDQo+IEFMVC1BRERSRVNTLg0KDQpJIHRoaW5rIHRoaXMgaXMgY2xlYXIuICBUaGUgcXVlc3Rp
b24gcGVyaGFwcyBmcm9tIHRoaXMgaXMgZG8gd2UgbWFrZSB0aGUgYWJvdmUgYSByZXF1aXJlbWVu
dD8gT3IgdGhlIGNsaWVudCBjYW4gYWx3YXlzIGRlY2lkZSB0aGF0IGl0IGRvZXMgbm90IGtub3cg
ZXZlbiBpZiBpdCBkb2VzPw0KDQo+IEluIHdoYXQgd2F5PyAgRm9yIHNlcnZlciBzdG9yYWdlIG9m
IGluLXRyYW5zcG9ydCBtYWlsPw0KDQpJIGNhbiBpbWFnaW5lIGEgZGlmZmVyZW50IHdheSBvZiBz
dG9yaW5nIHRoZSBBVE9NSUMgaW5mb3JtYXRpb24gc28gdGhhdCBpdCBjb3VsZCBiZSB1c2VmdWwg
KGUuZy4gZm9yIGNvbnRhY3QgbGlzdCBrZXB0IGJ5IGFuIE1VQSkuDQoNCj4gVGhpcyBzdWdnZXN0
aW9uIG9mIHJlLXVzaW5nIHRyYW5zZm9ybWVkIGFkZHJlc3NlcyBpcyBub3QgcGFydCBvZiB0aGUg
cHJvcG9zYWwuDQoNClllcyBhbmQgTm8uICBJZiB0cmFuc2Zvcm1lZCBhZGRyZXNzZXMgYXJlIE5F
VkVSICJyZXVzZWQiIHRoZW4gYSByZWNpcGllbnQgY2Fubm90IHJlcGx5IHVzaW5nIGl0Li4uIHRo
ZSBzY2VuYXJpb3MgZGVzY3JpYmUgdGhlIHJlcXVpcmVtZW50IGZvciBhYmlsaXR5IHRvIHJlcGx5
LiAgU28gdGhlcmUgeW91IGFyZSBzdGlsbCBkcmF3aW5nIGEgbGluZS4uLiBpcyBpdCAicmV1c2Vk
IiBmb3IgdGhlICJzYW1lIiBtZXNzYWdlIGluIGl0cyByZXBseSBvbmx5Py4uLiBjYW4gSSB1c2Ug
dGhlIHRyYW5zZm9ybWVkIGFkZHJlc3MgYWdhaW4gYXQgc29tZSBvdGhlciB0aW1lPyAgQW5vdGhl
ciBxdWVzdGlvbiBmb2xsb3dpbmcgZnJvbSB0aGF0IG1heWJlLi4uIGhvdyBsb25nIG1pZ2h0IGFu
IGFsdC1hZGRyZXNzIGJlICJ2YWxpZCI/ICBPciBzaG91bGQgYW4gTVVBL01UQSBhc3N1bWUgdGhh
dCBhbiBhbHQtYWRkcmVzcyBpcyBhbHdheXMgInZhbGlkIj8NCg0KPiBHbyBhaGVhZCBhbmQgZGVm
aW5lIHRoZSBhbGdvcml0aG0sIGJ1dCB3ZSBkb24ndCBuZWVkIHRoZSBzcGVjaWZpYyANCj4gQVRP
TUlDIHBhcmFtZXRlciB0byBkbyBzby4NCg0KVGhlcmUgaXMgbm8gcmVhc29uIHRvIGhhdmUgYSBn
ZW5lcmFsICJzdGFuZGFyZCIgYWxnb3JpdGhtIHdpdGhvdXQgdGhlIEFUT01JQyBwYXJhbWV0ZXIu
ICBEaWZmZXJlbnQgdHJhbnNmb3JtYXRpb24gbWVjaGFuaXNtcyBtYXkgYmUgdXNlZC4NCg0KRWRt
b24NCg==




--===============1956811078==
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

--===============1956811078==--



From ima-bounces@ietf.org Tue Jul 11 17:31:29 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0PpJ-0000wI-AP; Tue, 11 Jul 2006 17:31:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0PpI-0000wD-UT
	for ima@ietf.org; Tue, 11 Jul 2006 17:31:28 -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 1G0OyL-0000h1-A2
	for ima@ietf.org; Tue, 11 Jul 2006 16:36:45 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0OmD-0003qC-9x
	for ima@ietf.org; Tue, 11 Jul 2006 16:24:17 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6BKNnfa015244
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Jul 2006 13:23:50 -0700
Received: from [142.131.134.210] (vpn-10-50-16-148.qualcomm.com [10.50.16.148])
	by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6BKNjFI023810; 
	Tue, 11 Jul 2006 13:23:48 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p0630000cc0d9b878019a@[142.131.134.210]>
In-Reply-To: <44B3F09C.3090107@twnic.net.tw>
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<44B3F09C.3090107@twnic.net.tw>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Tue, 11 Jul 2006 13:20:32 -0700
To: Nai-Wen Hsu <snw@twnic.net.tw>, Edmon Chung <edmon@afilias.info>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [EAI] ATOMIC or not
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
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

At 2:40 AM +0800 7/12/06, Nai-Wen Hsu wrote:

>   I think it is ok to remove ATOMIC flag, because MUA can transform 
> to downgraded fromat and put it into alt-address before sending out 
> the mail.

This is exactly the proposal.  Thank you for stating it so clearly.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Demagogue: One who preaches doctrines he knows to be untrue to men he
knows to be idiots.                                    --H.L. Mencken

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



From ima-bounces@ietf.org Tue Jul 11 19:24:06 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0RaC-0006Au-T9; Tue, 11 Jul 2006 19:24:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0RaC-0006Ap-Bg
	for ima@ietf.org; Tue, 11 Jul 2006 19:24:00 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0RaA-00069N-0X
	for ima@ietf.org; Tue, 11 Jul 2006 19:24:00 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6BNNj6b011501
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Jul 2006 16:23:46 -0700
Received: from [142.131.134.210] (vpn-10-50-0-114.qualcomm.com [10.50.0.114])
	by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k6BNNgVP002150; Tue, 11 Jul 2006 16:23:44 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300012c0d9e269fecb@[142.131.134.210]>
In-Reply-To: <020101c6a52f$ca3f2660$b30110ac@edmontr3>
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
	<020101c6a52f$ca3f2660$b30110ac@edmontr3>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Tue, 11 Jul 2006 16:23:28 -0700
To: "Edmon Chung" <edmon@afilias.info>, <ima@ietf.org>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [EAI] ATOMIC or not
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
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 5:19 PM -0400 7/11/06, Edmon Chung wrote:

>   > So, here is the behavior:
>>
>>  1: client knows a good alternate address.  It supplies it in ALT-ADDRESS.
>>
>>  2: client does not have a good alternate address, but it knows
>>  the address is transform-safe ("atomic").  It performs the
>>  transformation and supplies this transformed address in ALT-ADDRESS.
>>
>>  3: client does not have a good alternate address, and does not
>>  know if the address is transform-safe ("atomic").  It does not supply
>>  ALT-ADDRESS.
>
>  I think this is clear.  The question perhaps from this is do we 
> make the above a requirement? Or the client can always decide that 
> it does not know even if it does?

I'd suggest it is better to allow a client to act as if it doesn't 
know that an address is atomic, as the result (that the message is 
bounced if it can't be delivered as-is) may be the most desirable 
outcome in many cases.

>
>>  In what way?  For server storage of in-transport mail?
>
>  I can imagine a different way of storing the ATOMIC information so 
> that it could be useful (e.g. for contact list kept by an MUA).

It seems to me that for any cases where storing ATOMIC would be 
useful, storing the transformed address would be equally as useful.

>   > Go ahead and define the algorithm, but we don't need the specific
>>  ATOMIC parameter to do so.
>
>  There is no reason to have a general "standard" algorithm without 
> the ATOMIC parameter.  Different transformation mechanisms may be 
> used.

I'm sorry, but I don't follow.  Can you explain more?  If different 
transformation algorithms are used, then how can the resulting 
transformed address be expected to succeed (be accepted by the 
recipient server and delivered to the same user as the UTF8 address)?

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The attention span of a computer is only as long as its electrical cord.

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



From ima-bounces@ietf.org Wed Jul 12 05:33:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0b61-0006Us-Rk; Wed, 12 Jul 2006 05:33:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0b60-0006Un-Pb
	for ima@ietf.org; Wed, 12 Jul 2006 05:33:28 -0400
Received: from lon-mail-3.gradwell.net ([193.111.201.127])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0b5x-0002YS-QC
	for ima@ietf.org; Wed, 12 Jul 2006 05:33:28 -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.227) id
	44b4c14e.9dd7.fe for ima@ietf.org; Wed, 12 Jul 2006 10:30:54 +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 k6C9Up4c004380
	for <ima@ietf.org>; Wed, 12 Jul 2006 10:30:52 +0100 (BST)
To: "ima@ietf.org" <ima@ietf.org>
Subject: Re: [EAI] ATOMIC or not
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
Message-ID: <op.tckkpoh16hl8nm@clerew.man.ac.uk>
Date: Wed, 12 Jul 2006 10:30:50 +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: <p0630000bc0d9b50c344b@[142.131.134.210]>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
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, 11 Jul 2006 21:19:06 +0100, Randall Gellens <randy@qualcomm.com>  
wrote:

> At 1:54 PM -0400 7/11/06, Edmon Chung wrote:

> The proposal does not alter the presence of this algorithm, it only  
> alters who uses it and when in the chain.
>
>>    Therefore, if an internationalized email address can be such  
>> "transformed", then the ATOMIC bit can be set.  This will allow mail  
>> servers to downgrade/upgrade an address when needed.
>
> The proposal is that, rather than carry around the ATOMIC flag and no  
> ALT-ADDRESS, just go ahead and use the algorithm on atomic addresses for  
> which no other alternative address is available.

That is not my understanding. It would be much simpler if all addresses  
were presumed to be "Atomic" *unless* an explicit Alt-Address was  
provided. But for that to work, we need an agreed downgrading algorithm  
that is perfectly reversible. In that case, if the downgraded address made  
no sense at the receiving end (and especially if it could be reliably  
detected as having been downgraded, e.g. by starting with 'xn--' or  
whatever), then the receiving end just reverses the downgrade, at which  
point the address should now make sense again (because it was as if there  
never had been any downgrade).

I do not like systems which expect the client to provide the ACEd address  
in the Alt-Address regardless. Most people using UTF8smtp will be  
communicating only with other people doing the same, and do not want to  
see unintelligible (to them) Alt-Addresses.
>
> Here are the cases:
> 	1: client knows a good alternate address.
>
> 	2: client does not have a good alternate address, but it knows the  
> address is transform-safe ("atomic")

In my world, all addresses are 'transfer-safe' (because the ACE is always  
reversible). If that can be assumed, then all remaining problems go away.

-- 
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 Jul 12 13:14:07 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0iHh-0005oA-O0; Wed, 12 Jul 2006 13:14:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0IFK-0007qO-2e
	for ima@ietf.org; Tue, 11 Jul 2006 09:25:50 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0IFI-00067g-NW
	for ima@ietf.org; Tue, 11 Jul 2006 09:25:50 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6BDPYDR011882
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Jul 2006 06:25:35 -0700
Received: from [142.131.134.210] (vpn-10-50-16-83.qualcomm.com [10.50.16.83])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k6BDPWki016394; Tue, 11 Jul 2006 06:25:33 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300000c0d9560f9094@[142.131.134.210]>
In-Reply-To: <F0F7E0C4DC06BB5931CAEBC9@446E7922C82D299DB29D899F>
References: <op.tbyvh1u56hl8nm@clerew.man.ac.uk>
	<F0F7E0C4DC06BB5931CAEBC9@446E7922C82D299DB29D899F>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Tue, 11 Jul 2006 06:21:28 -0700
To: Chris Newman <Chris.Newman@sun.com>,
	Charles Lindsey <chl@clerew.man.ac.uk>, ima@ietf.org
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [EAI] Comments on draft--eai-pop-00
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
X-Mailman-Approved-At: Wed, 12 Jul 2006 13:14:00 -0400
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 8:20 AM -0700 7/10/06, Chris Newman wrote:

>  FWIW, I was uncomfortable telling POP servers they SHOULD implement 
> a MIME parser.  While I consider a MIME parser a very simple and 
> lightweight piece of code (that took me less than a day to write), 
> that attitude is not shared by other implementers.  How do other 
> people feel about this?

Well, Qpopper has a MIME parser (as part of it's so-called 
mime-mangling support).
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Never ask two questions in a business letter.  The reply will
discuss the one you are least interested in and say nothing about
the other.

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

From ima-bounces@ietf.org Wed Jul 12 13:14:07 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0iHh-0005oG-Rx; Wed, 12 Jul 2006 13:14:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0IJC-0001T4-N7
	for ima@ietf.org; Tue, 11 Jul 2006 09:29:50 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0IJB-0006Tl-Bf
	for ima@ietf.org; Tue, 11 Jul 2006 09:29:50 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6BDTXQb012256
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Jul 2006 06:29:33 -0700
Received: from [142.131.134.210] (vpn-10-50-16-83.qualcomm.com [10.50.16.83])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k6BDTU8W017221; Tue, 11 Jul 2006 06:29:31 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300001c0d956d2be21@[142.131.134.210]>
In-Reply-To: <00d801c6a490$ae32d290$c7d348d3@aabbeell>
References: <op.tbyvh1u56hl8nm@clerew.man.ac.uk>
	<F0F7E0C4DC06BB5931CAEBC9@446E7922C82D299DB29D899F>
	<00d801c6a490$ae32d290$c7d348d3@aabbeell>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Tue, 11 Jul 2006 06:26:29 -0700
To: "abel" <abelyang@twnic.net.tw>, "Chris Newman" <Chris.Newman@sun.com>,
	"Charles Lindsey" <chl@clerew.man.ac.uk>, <ima@ietf.org>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [EAI] Comments on draft--eai-pop-00
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
X-Mailman-Approved-At: Wed, 12 Jul 2006 13:14:00 -0400
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 10:21 AM +0800 7/11/06, abel wrote:

>   > FWIW, I was uncomfortable telling POP servers they SHOULD implement a MIME
>>  parser.  While I consider a MIME parser a very simple and lightweight
>  piece of
>>  code (that took me less than a day to write), that attitude is not shared
>  by
>>  other implementers.  How do other people feel about this?
>>
>  I had some different idea when I implement  our EAI trial ,
>  when the POP3 client login UTF8-name (pass UTF8-name) , POP3 service 'RETR
>  command' returns MUA a EAI mail content,
>  if  MUA login as US-ASCII name , POP3 returns mail as Downgraded (downward
>  compatibility for current MUA).
>  The US-ASCII name can be MIME or Punycode , and the name point to same UTF8
>  mailbox,
>  Considering and supporting current MUA is benefits

I apologize, but I am a bit confused: the text you quoted is Chris 
asking about the burden of implementing a MIME parser, but your reply 
seems to propose an alternative to the use of new commands in place 
of RETR/TOP.  In regards to this proposal, I'd prefer Chris' approach 
of new commands to make things explicit, rather than having it be 
implicit based on the login name.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Any smoothly functioning technology will be
indistinguishable from a rigged demo.  --Isaac Asimov

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





From ima-bounces@ietf.org Wed Jul 12 13:14:07 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0iHh-0005oA-O0; Wed, 12 Jul 2006 13:14:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0IFK-0007qO-2e
	for ima@ietf.org; Tue, 11 Jul 2006 09:25:50 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0IFI-00067g-NW
	for ima@ietf.org; Tue, 11 Jul 2006 09:25:50 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6BDPYDR011882
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Jul 2006 06:25:35 -0700
Received: from [142.131.134.210] (vpn-10-50-16-83.qualcomm.com [10.50.16.83])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k6BDPWki016394; Tue, 11 Jul 2006 06:25:33 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300000c0d9560f9094@[142.131.134.210]>
In-Reply-To: <F0F7E0C4DC06BB5931CAEBC9@446E7922C82D299DB29D899F>
References: <op.tbyvh1u56hl8nm@clerew.man.ac.uk>
	<F0F7E0C4DC06BB5931CAEBC9@446E7922C82D299DB29D899F>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Tue, 11 Jul 2006 06:21:28 -0700
To: Chris Newman <Chris.Newman@sun.com>,
	Charles Lindsey <chl@clerew.man.ac.uk>, ima@ietf.org
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [EAI] Comments on draft--eai-pop-00
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
X-Mailman-Approved-At: Wed, 12 Jul 2006 13:14:00 -0400
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 8:20 AM -0700 7/10/06, Chris Newman wrote:

>  FWIW, I was uncomfortable telling POP servers they SHOULD implement 
> a MIME parser.  While I consider a MIME parser a very simple and 
> lightweight piece of code (that took me less than a day to write), 
> that attitude is not shared by other implementers.  How do other 
> people feel about this?

Well, Qpopper has a MIME parser (as part of it's so-called 
mime-mangling support).
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Never ask two questions in a business letter.  The reply will
discuss the one you are least interested in and say nothing about
the other.

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

From ima-bounces@ietf.org Wed Jul 12 13:14:07 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0iHh-0005oG-Rx; Wed, 12 Jul 2006 13:14:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0IJC-0001T4-N7
	for ima@ietf.org; Tue, 11 Jul 2006 09:29:50 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0IJB-0006Tl-Bf
	for ima@ietf.org; Tue, 11 Jul 2006 09:29:50 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6BDTXQb012256
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Jul 2006 06:29:33 -0700
Received: from [142.131.134.210] (vpn-10-50-16-83.qualcomm.com [10.50.16.83])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k6BDTU8W017221; Tue, 11 Jul 2006 06:29:31 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300001c0d956d2be21@[142.131.134.210]>
In-Reply-To: <00d801c6a490$ae32d290$c7d348d3@aabbeell>
References: <op.tbyvh1u56hl8nm@clerew.man.ac.uk>
	<F0F7E0C4DC06BB5931CAEBC9@446E7922C82D299DB29D899F>
	<00d801c6a490$ae32d290$c7d348d3@aabbeell>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Tue, 11 Jul 2006 06:26:29 -0700
To: "abel" <abelyang@twnic.net.tw>, "Chris Newman" <Chris.Newman@sun.com>,
	"Charles Lindsey" <chl@clerew.man.ac.uk>, <ima@ietf.org>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [EAI] Comments on draft--eai-pop-00
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
X-Mailman-Approved-At: Wed, 12 Jul 2006 13:14:00 -0400
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 10:21 AM +0800 7/11/06, abel wrote:

>   > FWIW, I was uncomfortable telling POP servers they SHOULD implement a MIME
>>  parser.  While I consider a MIME parser a very simple and lightweight
>  piece of
>>  code (that took me less than a day to write), that attitude is not shared
>  by
>>  other implementers.  How do other people feel about this?
>>
>  I had some different idea when I implement  our EAI trial ,
>  when the POP3 client login UTF8-name (pass UTF8-name) , POP3 service 'RETR
>  command' returns MUA a EAI mail content,
>  if  MUA login as US-ASCII name , POP3 returns mail as Downgraded (downward
>  compatibility for current MUA).
>  The US-ASCII name can be MIME or Punycode , and the name point to same UTF8
>  mailbox,
>  Considering and supporting current MUA is benefits

I apologize, but I am a bit confused: the text you quoted is Chris 
asking about the burden of implementing a MIME parser, but your reply 
seems to propose an alternative to the use of new commands in place 
of RETR/TOP.  In regards to this proposal, I'd prefer Chris' approach 
of new commands to make things explicit, rather than having it be 
implicit based on the login name.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Any smoothly functioning technology will be
indistinguishable from a rigged demo.  --Isaac Asimov

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





From ima-bounces@ietf.org Wed Jul 12 15:16:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0kBd-0006B9-9i; Wed, 12 Jul 2006 15:15:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0k2Z-0002FA-TU
	for ima@ietf.org; Wed, 12 Jul 2006 15:06:31 -0400
Received: from maila.microsoft.com ([131.107.1.7] helo=mail2.microsoft.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0k2X-0001e2-JQ
	for ima@ietf.org; Wed, 12 Jul 2006 15:06:31 -0400
Received: from mailout6.microsoft.com ([157.54.69.150]) by mail2.microsoft.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 12 Jul 2006 12:06:28 -0700
Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by
	mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 12 Jul 2006 12:06:28 -0700
Received: from WINSE-MSG-01.segroup.winse.corp.microsoft.com ([157.54.6.40])
	by tuk-hub-03.redmond.corp.microsoft.com with Microsoft
	SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 12:06:26 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 12 Jul 2006 12:06:51 -0700
Message-ID: <F7585EDDB1D8E84DA6FFF188C8F9A3760DF80CDC@winse-msg-01.segroup.winse.corp.microsoft.com>
In-Reply-To: <E1G0h8N-0006v5-8o@megatron.ietf.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ATOMIC or not
thread-index: AcalzEikYUb5C37aR/exV5O8jAFXTAAGFizg
References: <E1G0h8N-0006v5-8o@megatron.ietf.org>
From: "Shawn Steele" <Shawn.Steele@microsoft.com>
To: <ima@ietf.org>
X-OriginalArrivalTime: 12 Jul 2006 19:06:26.0688 (UTC)
	FILETIME=[4648E000:01C6A5E6]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
X-Mailman-Approved-At: Wed, 12 Jul 2006 15:15:52 -0400
Subject: [EAI] RE: ATOMIC or not
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

It seems to me that ALT-ADDR is more interesting than ATOMIC, and some
ATOMIC conversion could be done by a server to provide an ALT-ADDR if
necessary.

I could easily see some mail systems aliasing simple ASCII addresses to
an internationalized address (or the other way around) in a fashion that
may not necessarily be algorithmic.  For example, some systems could
provide transliterated ASCII addresses for their native
internationalized address.  Even for Latin, I'd expect that many people
would probably prefer just dropping accents than mangling their name
with some xn-- gobbledygook.  Any mechanism for ALT-ADDR should be
allowed so long as its understood by their mail server.

I'm curious though, if a system doesn't understand an internationalized
address, how is it going to know about an ALT-ADDR (or any other
mechanism?)  The usefulness seems to be that I could try to send to an
internationalized address, and if that fails I could try the ALT-ADDR
(assuming I'm a new mail transport that understands them.)  In that case
an algorithmic mapping like ACE isn't required.

It also seems likely that if ALT-ADDR is required at some stage that the
internationalized address would then either be lost or mangled.

- Shawn

SDE, Windows Globalization
Microsoft


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



From ima-bounces@ietf.org Wed Jul 12 16:38:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0lU0-0002g0-Uc; Wed, 12 Jul 2006 16:38:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0lTz-0002fr-V5
	for ima@ietf.org; Wed, 12 Jul 2006 16:38:56 -0400
Received: from mail02.afilias.info ([69.46.107.12] helo=mail00.afilias.info)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0lTy-0005Ni-Ms
	for ima@ietf.org; Wed, 12 Jul 2006 16:38:55 -0400
Received: from edmontr3 (vgateway.afilias.info [207.219.45.62])
	(authenticated bits=0)
	by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id k6CKcgrk017240
	for <ima@ietf.org>; Wed, 12 Jul 2006 16:38:47 -0400
Message-ID: <036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>
From: "Edmon Chung" <edmon@afilias.info>
To: <ima@ietf.org>
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
	<020101c6a52f$ca3f2660$b30110ac@edmontr3>
	<p06300012c0d9e269fecb@[142.131.134.210]>
Subject: Re: [EAI] ATOMIC or not
Date: Wed, 12 Jul 2006 16:38:35 -0400
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Virus-Scanned: ClamAV 0.88/1594/Wed Jul 12 11:04:34 2006 on
	mail00.afilias.info
X-Virus-Status: Clean
X-Spam-Status: No, score=0.1 required=5.0 tests=ALL_TRUSTED, MIME_BASE64_TEXT 
	autolearn=ham version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on mail00.afilias.info
X-Envelope-To: <ima@ietf.org>
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
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>
Content-Type: multipart/mixed; boundary="===============1296513144=="
Errors-To: ima-bounces@ietf.org

--===============1296513144==
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

Pj4+ICBJbiB3aGF0IHdheT8gIEZvciBzZXJ2ZXIgc3RvcmFnZSBvZiBpbi10cmFuc3BvcnQgbWFp
bD8NCj4+DQo+PiAgSSBjYW4gaW1hZ2luZSBhIGRpZmZlcmVudCB3YXkgb2Ygc3RvcmluZyB0aGUg
QVRPTUlDIGluZm9ybWF0aW9uIHNvIA0KPj4gdGhhdCBpdCBjb3VsZCBiZSB1c2VmdWwgKGUuZy4g
Zm9yIGNvbnRhY3QgbGlzdCBrZXB0IGJ5IGFuIE1VQSkuDQo+IA0KPiBJdCBzZWVtcyB0byBtZSB0
aGF0IGZvciBhbnkgY2FzZXMgd2hlcmUgc3RvcmluZyBBVE9NSUMgd291bGQgYmUgDQo+IHVzZWZ1
bCwgc3RvcmluZyB0aGUgdHJhbnNmb3JtZWQgYWRkcmVzcyB3b3VsZCBiZSBlcXVhbGx5IGFzIHVz
ZWZ1bC4NCg0KTm90IHRydWUuICBJZiBhbiBhZGRyZXNzIGlzIGRlc2lnbmF0ZWQgYXMgQVRPTUlD
LCB0aGVuIEkgd291bGQgc3RvcmUgdGhhdCBpbmZvcm1hdGlvbiBjYXVzZSBJIGtub3cgdGhhdCBp
dCBjb3VsZCBiZSB1c2VkIGluIHRoZSBmdXR1cmUuICBJZiBhbiBhbHQtYWRkcmVzcyBpcyBwcm92
aWRlZCwgdGhlbiBJIHdvdWxkIHByb2JhYmx5IGhhdmUgdG8gZGlzY2FyZCBpdCBjYXVzZSBJIGNh
bm5vdCBkZXRlcm1pbmUgd2hldGhlciBJIGNhbiB1c2UgdGhhdCBzYW1lIGFsdC1hZGRyIGluIHRo
ZSBmdXR1cmUuDQoNCj4gDQo+PiAgID4gR28gYWhlYWQgYW5kIGRlZmluZSB0aGUgYWxnb3JpdGht
LCBidXQgd2UgZG9uJ3QgbmVlZCB0aGUgc3BlY2lmaWMNCj4+PiAgQVRPTUlDIHBhcmFtZXRlciB0
byBkbyBzby4NCj4+DQo+PiAgVGhlcmUgaXMgbm8gcmVhc29uIHRvIGhhdmUgYSBnZW5lcmFsICJz
dGFuZGFyZCIgYWxnb3JpdGhtIHdpdGhvdXQgDQo+PiB0aGUgQVRPTUlDIHBhcmFtZXRlci4gIERp
ZmZlcmVudCB0cmFuc2Zvcm1hdGlvbiBtZWNoYW5pc21zIG1heSBiZSANCj4+IHVzZWQuDQo+IA0K
PiBJJ20gc29ycnksIGJ1dCBJIGRvbid0IGZvbGxvdy4gIENhbiB5b3UgZXhwbGFpbiBtb3JlPyAg
SWYgZGlmZmVyZW50IA0KPiB0cmFuc2Zvcm1hdGlvbiBhbGdvcml0aG1zIGFyZSB1c2VkLCB0aGVu
IGhvdyBjYW4gdGhlIHJlc3VsdGluZyANCj4gdHJhbnNmb3JtZWQgYWRkcmVzcyBiZSBleHBlY3Rl
ZCB0byBzdWNjZWVkIChiZSBhY2NlcHRlZCBieSB0aGUgDQo+IHJlY2lwaWVudCBzZXJ2ZXIgYW5k
IGRlbGl2ZXJlZCB0byB0aGUgc2FtZSB1c2VyIGFzIHRoZSBVVEY4IGFkZHJlc3MpPw0KDQpXaXRo
b3V0IEFUT01JQywgeW91IGNhbm5vdCBhc3N1bWUgYW55IEFMVC1BRERSRVNTIGNhbiBiZSB0cmFu
c2Zvcm1lZCBiYWNrIHRvIHRoZSBVVEY4IGFkZHJlc3MuICBJZiB0aGVyZSBpcyBubyB3YXkgdG8g
ZGVzaWduYXRlIHRoYXQgYW4gYWRkcmVzcyBpcyBBVE9NSUMsIHRoZW4gb25lIGNhbiBvbmx5IGRy
YXcgdGhlIHJlbGF0aW9uIGJldHdlZW4gdGhlIFVURjggYWRkcmVzcyBhbmQgdGhlIEFMVC1BRERS
RVNTIGZvciB0aGUgcGFydGljdWxhciB0cmFuc3BvcnQgYXQgaGFuZC4NCg0KRWRtb24NCg0K




--===============1296513144==
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

--===============1296513144==--



From ima-bounces@ietf.org Wed Jul 12 16:45:02 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0lZu-0005tj-QE; Wed, 12 Jul 2006 16:45:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0lZt-0005tT-VE
	for ima@ietf.org; Wed, 12 Jul 2006 16:45:01 -0400
Received: from mail02.afilias.info ([69.46.107.12] helo=mail00.afilias.info)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0lZs-0007KA-Ma
	for ima@ietf.org; Wed, 12 Jul 2006 16:45:01 -0400
Received: from edmontr3 (vgateway.afilias.info [207.219.45.62])
	(authenticated bits=0)
	by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id k6CKirs5018899
	for <ima@ietf.org>; Wed, 12 Jul 2006 16:44:54 -0400
Message-ID: <037601c6a5f4$07a0f4b0$b30110ac@edmontr3>
From: "Edmon Chung" <edmon@afilias.info>
To: <ima@ietf.org>
References: <011201c6a513$5636a020$b30110ac@edmontr3><p0630000bc0d9b50c344b@[142.131.134.210]>
	<op.tckkpoh16hl8nm@clerew.man.ac.uk>
Subject: Re: [EAI] ATOMIC or not
Date: Wed, 12 Jul 2006 16:44:44 -0400
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Virus-Scanned: ClamAV 0.88/1594/Wed Jul 12 11:04:34 2006 on
	mail00.afilias.info
X-Virus-Status: Clean
X-Spam-Status: No, score=0.1 required=5.0 tests=ALL_TRUSTED, MIME_BASE64_TEXT 
	autolearn=ham version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on mail00.afilias.info
X-Envelope-To: <ima@ietf.org>
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
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>
Content-Type: multipart/mixed; boundary="===============0719498750=="
Errors-To: ima-bounces@ietf.org

--===============0719498750==
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

DQo+IFRoYXQgaXMgbm90IG15IHVuZGVyc3RhbmRpbmcuIEl0IHdvdWxkIGJlIG11Y2ggc2ltcGxl
ciBpZiBhbGwgYWRkcmVzc2VzICANCj4gd2VyZSBwcmVzdW1lZCB0byBiZSAiQXRvbWljIiAqdW5s
ZXNzKiBhbiBleHBsaWNpdCBBbHQtQWRkcmVzcyB3YXMgIA0KDQpUaGF0IGlzIEkgdGhpbmsgdGhl
IGNvbmZ1c2lvbi4gIFRoYXQgaXMgTk9UIHRoZSBjYXNlIGJhc2VkIG9uIHRoZSBjdXJyZW50IHNw
ZWNpZmljYXRpb25zLiAgSWYgYW4gYWRkcmVzcyBpcyBOT1QgZGVzaWduYXRlZCBhcyBBVE9NSUMs
IGl0IGlzIGFzc3VtZWQgaXQgQ0FOTk9UIGJlIHRyYW5zZm9ybWVkIGludG8gYW55ICJBQ0UiIGFk
ZHJlc3MuDQoNCj4gcHJvdmlkZWQuIEJ1dCBmb3IgdGhhdCB0byB3b3JrLCB3ZSBuZWVkIGFuIGFn
cmVlZCBkb3duZ3JhZGluZyBhbGdvcml0aG0gIA0KPiB0aGF0IGlzIHBlcmZlY3RseSByZXZlcnNp
YmxlLiBJbiB0aGF0IGNhc2UsIGlmIHRoZSBkb3duZ3JhZGVkIGFkZHJlc3MgbWFkZSAgDQo+IG5v
IHNlbnNlIGF0IHRoZSByZWNlaXZpbmcgZW5kIChhbmQgZXNwZWNpYWxseSBpZiBpdCBjb3VsZCBi
ZSByZWxpYWJseSAgDQo+IGRldGVjdGVkIGFzIGhhdmluZyBiZWVuIGRvd25ncmFkZWQsIGUuZy4g
Ynkgc3RhcnRpbmcgd2l0aCAneG4tLScgb3IgIA0KPiB3aGF0ZXZlciksIHRoZW4gdGhlIHJlY2Vp
dmluZyBlbmQganVzdCByZXZlcnNlcyB0aGUgZG93bmdyYWRlLCBhdCB3aGljaCAgDQoNCkRlZmlu
aXRlbHkgbm90IHhuLS0sIDotUC4uLg0KDQo+IHBvaW50IHRoZSBhZGRyZXNzIHNob3VsZCBub3cg
bWFrZSBzZW5zZSBhZ2FpbiAoYmVjYXVzZSBpdCB3YXMgYXMgaWYgdGhlcmUgIA0KPiBuZXZlciBo
YWQgYmVlbiBhbnkgZG93bmdyYWRlKS4NCg0KQWdhaW4sIGFzIG1lbnRpb25lZCwgdGhhdCBpcyBu
b3QgY3VycmVudGx5IHRoZSBjYXNlLiAgSWYgYW4gYWRkcmVzcyBpcyBOT1QgZGVzaWduYXRlZCBh
cyBBVE9NSUMsIHdlIENBTk5PVCBkb3duZ3JhZGUgKG9yIGZvciB0aGF0IG1hdHRlciB1cGdyYWRl
KSBpdC4NCg0KPiANCj4gSSBkbyBub3QgbGlrZSBzeXN0ZW1zIHdoaWNoIGV4cGVjdCB0aGUgY2xp
ZW50IHRvIHByb3ZpZGUgdGhlIEFDRWQgYWRkcmVzcyAgDQo+IGluIHRoZSBBbHQtQWRkcmVzcyBy
ZWdhcmRsZXNzLiBNb3N0IHBlb3BsZSB1c2luZyBVVEY4c210cCB3aWxsIGJlICANCj4gY29tbXVu
aWNhdGluZyBvbmx5IHdpdGggb3RoZXIgcGVvcGxlIGRvaW5nIHRoZSBzYW1lLCBhbmQgZG8gbm90
IHdhbnQgdG8gIA0KPiBzZWUgdW5pbnRlbGxpZ2libGUgKHRvIHRoZW0pIEFsdC1BZGRyZXNzZXMu
DQoNCkFMVC1BRERSRVNTIGRvZXMgTk9UIGhhdmUgdG8gYmUgdW5pdGVsbGlnaWJsZSBhZGRyZXNz
ZXMgKG9uZSByZWFzb24gSSBsaWtlIGFsdC1hZGRyZXNzKSwgdGhleSBjb3VsZCBiZSBqdXN0IHlv
dXIgdHJhZGl0aW9uYWwgZW1haWwgYWRkcmVzcy4gIFdoZXJlYXMgc3RhdGluZyAiQVRPTUlDIiBh
bGxvd3MgdGhlIHRyYW5zcG9ydCB0byBiZSBjbGVhbmVyIGFzIHlvdSBtZW50aW9uZWQsIGFuZCB0
byBkZXNpZ25hdGUgdGhhdCBpdCBjYW4gYmUgdHJhbnNmb3JtZWQgaW50byBhbiBBQ0UgYWRkcmVz
cy4NCg0KIA0KPiBJbiBteSB3b3JsZCwgYWxsIGFkZHJlc3NlcyBhcmUgJ3RyYW5zZmVyLXNhZmUn
IChiZWNhdXNlIHRoZSBBQ0UgaXMgYWx3YXlzICANCj4gcmV2ZXJzaWJsZSkuIElmIHRoYXQgY2Fu
IGJlIGFzc3VtZWQsIHRoZW4gYWxsIHJlbWFpbmluZyBwcm9ibGVtcyBnbyBhd2F5Lg0KDQoNClRo
YXQgaXMgbm90IHRoZSBhc3N1bXB0aW9uIG9mIHRoZSBjdXJyZW50IHNldCBvZiBkcmFmdHMuLi4g
aWYgdGhhdCBpcyB3aGF0IHdlIHdhbnQsIHRoZW4gd2UgbmVlZCB0byBtYWtlIHNvbWUgY2hhbmdl
cy4uLg0KDQpFZG1vbg==




--===============0719498750==
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

--===============0719498750==--



From ima-bounces@ietf.org Wed Jul 12 17:20:24 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0m85-00024j-4A; Wed, 12 Jul 2006 17:20:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0m84-00022C-0K
	for ima@ietf.org; Wed, 12 Jul 2006 17:20:20 -0400
Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0m81-0004z2-NK
	for ima@ietf.org; Wed, 12 Jul 2006 17:20:19 -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-1.csi.cam.ac.uk ([131.111.8.51]:55218)
	by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G0m7x-00056q-5h (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Wed, 12 Jul 2006 22:20:13 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1G0m7x-0001UT-MX (Exim 4.53)
	(return-path <fanf2@hermes.cam.ac.uk>); Wed, 12 Jul 2006 22:20:13 +0100
Date: Wed, 12 Jul 2006 22:20:13 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Edmon Chung <edmon@afilias.info>
Subject: Re: [EAI] ATOMIC or not
In-Reply-To: <036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>
Message-ID: <Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
	<020101c6a52f$ca3f2660$b30110ac@edmontr3>
	<p06300012c0d9e269fecb@[142.131.134.210]>
	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
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 Wed, 12 Jul 2006, Edmon Chung wrote:
>
> If an address is designated as ATOMIC, then I would store that
> information cause I know that it could be used in the future.  If an
> alt-address is provided, then I would probably have to discard it cause
> I cannot determine whether I can use that same alt-addr in the future.

If you can't trust the alt-address then surely you can't trust the utf8
address either. Or in other words, I don't think this kind of operational
stability issue is relevant. You can always verify that the alt-address is
the algorithmically-downgraded form of the utf8 address by doing the
downgrade and comparing.

I'm seriously worried about the user-interface implications of non-atomic
addresses.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
HEBRIDES BAILEY: WEST OR SOUTHWEST 5 TO 7, OCCASIONALLY GALE 8 AT FIRST,
DECREASING 3 OR 4. SHOWERS AT FIRST. MAINLY GOOD.

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



From ima-bounces@ietf.org Wed Jul 12 19:05:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0nlz-0005H6-KF; Wed, 12 Jul 2006 19:05:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0nly-0005Gw-H4
	for ima@ietf.org; Wed, 12 Jul 2006 19:05:38 -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 1G0nly-0003PU-Eu
	for ima@ietf.org; Wed, 12 Jul 2006 19:05:38 -0400
Received: from smtp.onekingwest.com ([24.244.240.219])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0nlw-00009r-Ts
	for ima@ietf.org; Wed, 12 Jul 2006 19:05:38 -0400
Received: from png3-5.pngxnet.com ([24.244.240.254])
	by smtp.onekingwest.com (8.13.6/8.13.6) with ESMTP id k6CN5Qxt032534
	for <ima@ietf.org>; Wed, 12 Jul 2006 19:05:26 -0400
Received: from edmontr3 ([10.255.255.86])
	by png3-5.pngxnet.com (8.12.4/8.12.4) with ESMTP id k6CN5JPd012468
	for <ima@ietf.org>; Wed, 12 Jul 2006 19:05:25 -0400
Message-ID: <03c201c6a607$a68936b0$b30110ac@edmontr3>
From: "Edmon Chung" <edmon@afilias.info>
To: <ima@ietf.org>
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
	<020101c6a52f$ca3f2660$b30110ac@edmontr3>
	<p06300012c0d9e269fecb@[142.131.134.210]>
	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>
	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>
Subject: Re: [EAI] ATOMIC or not
Date: Wed, 12 Jul 2006 19:04:03 -0400
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Virus-Scanned: ClamAV version 0.88.2,
	clamav-milter version 0.88.2 on localhost
X-Virus-Status: Clean
X-Spam-Status: No, score=-0.8 required=10.0 tests=BAYES_00, MIME_BASE64_BLANKS,
	MIME_BASE64_TEXT autolearn=no version=3.0.6
X-Spam-Checker-Version: SpamAssassin 3.0.6 (2005-12-07) on 
	smtp.onekingwest.com
X-Spam-Score: 1.4 (+)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
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>
Content-Type: multipart/mixed; boundary="===============0171121391=="
Errors-To: ima-bounces@ietf.org

--===============0171121391==
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlRvbnkgRmluY2giIDxkb3RA
ZG90YXQuYXQ+DQo+PiBJZiBhbiBhZGRyZXNzIGlzIGRlc2lnbmF0ZWQgYXMgQVRPTUlDLCB0aGVu
IEkgd291bGQgc3RvcmUgdGhhdA0KPj4gaW5mb3JtYXRpb24gY2F1c2UgSSBrbm93IHRoYXQgaXQg
Y291bGQgYmUgdXNlZCBpbiB0aGUgZnV0dXJlLiAgSWYgYW4NCj4+IGFsdC1hZGRyZXNzIGlzIHBy
b3ZpZGVkLCB0aGVuIEkgd291bGQgcHJvYmFibHkgaGF2ZSB0byBkaXNjYXJkIGl0IGNhdXNlDQo+
PiBJIGNhbm5vdCBkZXRlcm1pbmUgd2hldGhlciBJIGNhbiB1c2UgdGhhdCBzYW1lIGFsdC1hZGRy
IGluIHRoZSBmdXR1cmUuDQo+IA0KPiBJZiB5b3UgY2FuJ3QgdHJ1c3QgdGhlIGFsdC1hZGRyZXNz
IHRoZW4gc3VyZWx5IHlvdSBjYW4ndCB0cnVzdCB0aGUgdXRmOA0KPiBhZGRyZXNzIGVpdGhlci4g
T3IgaW4gb3RoZXIgd29yZHMsIEkgZG9uJ3QgdGhpbmsgdGhpcyBraW5kIG9mIG9wZXJhdGlvbmFs
DQo+IHN0YWJpbGl0eSBpc3N1ZSBpcyByZWxldmFudC4gWW91IGNhbiBhbHdheXMgdmVyaWZ5IHRo
YXQgdGhlIGFsdC1hZGRyZXNzIGlzDQo+IHRoZSBhbGdvcml0aG1pY2FsbHktZG93bmdyYWRlZCBm
b3JtIG9mIHRoZSB1dGY4IGFkZHJlc3MgYnkgZG9pbmcgdGhlDQo+IGRvd25ncmFkZSBhbmQgY29t
cGFyaW5nLg0KDQpBTFQtQUREUkVTUyBpcyBub3QgdGhlIHNhbWUgYXMgQVRPTUlDLiAgQUxULUFE
RFJFU1MgY2FuIGJlIGFueSBBU0NJSSBhZGRyZXNzLiAgRS5nLiAiPGNoaW5lc2VOYW1lPkBkb21h
aW4udGxkIiBjYW4gaGF2ZSBhbiBBTFQtQUREUj0iYWJjQGRlZi5vcmciIChub3RlIG5vdCBldmVu
IHRoZSBkb21haW4gbmVlZHMgdG8gbWF0Y2gpLiAgVGhhdCBpcyB3aHkgdGhlIGFsdC1hZGRyZXNz
IGNhbm5vdCBiZSBhICJzdGFibGUiIGdsdWUgdG8gdGhlIFVURjggYWRkcmVzcy4gIFRoZSBVVEY4
IGFkZHJlc3MgY2FuIGJlIGZ1bGx5IHRydXN0ZWQgc28gY2FuIGFuIEFUT01JQyBhZGRyZXNzICh3
ZWxsIHVubGVzcyB0aGUgc3RhbmRhcmQgdHJhbnNmb3JtYXRpb24gYWxnb3JpdGhtIGlzIGNoYW5n
ZWQuLi4gYnV0IHRoYXQgd291bGQgYmUgYSBkaWZmZXJlbnQgaXNzdWUuLi4gbW9yZSBvbiB2ZXJz
aW9uaW5nKS4NCg0KPiANCj4gSSdtIHNlcmlvdXNseSB3b3JyaWVkIGFib3V0IHRoZSB1c2VyLWlu
dGVyZmFjZSBpbXBsaWNhdGlvbnMgb2Ygbm9uLWF0b21pYw0KPiBhZGRyZXNzZXMuDQoNCldlbGwg
d2l0aG91dCB0aGUgQVRPTUlDIHBhcmFtZXRlciBhdCBhbGwgdGhlcmUgaXMgbm8gd2F5IHRvIHNh
eSB0aGF0IGFuIGFkZHJlc3MgaXMgYXRvbWljLi4uIGFuZCBiYXNlZCBvbiB0aGUgY3VycmVudCBz
ZXQgb2Ygc3BlY2lmaWNhdGlvbnMsIE5vbi1hdG9taWMgaXMgdGhlIGRlZmF1bHQuDQoNCkVkbW9u




--===============0171121391==
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

--===============0171121391==--



From ima-bounces@ietf.org Wed Jul 12 20:01:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0oeM-00056r-Ph; Wed, 12 Jul 2006 20:01:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0oeL-00056Y-Lv
	for ima@ietf.org; Wed, 12 Jul 2006 20:01:49 -0400
Received: from mail.globalsuite.net ([69.46.103.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0oeK-0005GI-6s
	for ima@ietf.org; Wed, 12 Jul 2006 20:01:49 -0400
Received: from [172.17.100.74] (unknown [207.134.107.2])
	by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 99556169;
	Wed, 12 Jul 2006 18:01:46 -0600 (MDT)
Message-ID: <44B58D61.80709@icu.ac.kr>
Date: Thu, 13 Jul 2006 09:01:37 +0900
From: Yangwoo Ko <newcat@icu.ac.kr>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Edmon Chung <edmon@afilias.info>
Subject: Re: [EAI] ATOMIC or not
References: <011201c6a513$5636a020$b30110ac@edmontr3>	<p0630000bc0d9b50c344b@[142.131.134.210]>	<020101c6a52f$ca3f2660$b30110ac@edmontr3>	<p06300012c0d9e269fecb@[142.131.134.210]>	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>
	<03c201c6a607$a68936b0$b30110ac@edmontr3>
In-Reply-To: <03c201c6a607$a68936b0$b30110ac@edmontr3>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
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

Edmon Chung wrote:
> ----- Original Message ----- 
> From: "Tony Finch" <dot@dotat.at>
>>> If an address is designated as ATOMIC, then I would store that
>>> information cause I know that it could be used in the future.  If an
>>> alt-address is provided, then I would probably have to discard it cause
>>> I cannot determine whether I can use that same alt-addr in the future.
>> If you can't trust the alt-address then surely you can't trust the utf8
>> address either. Or in other words, I don't think this kind of operational
>> stability issue is relevant. You can always verify that the alt-address is
>> the algorithmically-downgraded form of the utf8 address by doing the
>> downgrade and comparing.
> 
> ALT-ADDRESS is not the same as ATOMIC.  ALT-ADDRESS can be any ASCII 
 > address.  E.g. "<chineseName>@domain.tld" can have
 > an ALT-ADDR="abc@def.org" (note not even the domain needs to match).
 > That is why the alt-address cannot be a "stable" glue to the UTF8
 > address.  The UTF8 address can be fully trusted so can an ATOMIC
 > address (well unless the standard transformation algorithm is
 > changed... but that would be a different issue... more on versioning).

No. As I argued in the previous mail, ATOMIC is just a little bit
more stable than ALT-ADDR. First of all, a sender may claim that a
given address is ATOMIC even though it is not. Second, association
of an ATOMIC address with its corresponding converted all-ASCII
address can never be enforced by protocols. This is just part of
administration that can be violated in so many ways.

> 
>> I'm seriously worried about the user-interface implications of non-atomic
>> addresses.
> 
> Well without the ATOMIC parameter at all there is no way to say that an address is atomic... and based on the current set of specifications, Non-atomic is the default.
> 
> Edmon
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www1.ietf.org/mailman/listinfo/ima


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



From ima-bounces@ietf.org Thu Jul 13 03:24:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0vYo-0008Iu-AV; Thu, 13 Jul 2006 03:24:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0vYn-0008Ip-1p
	for ima@ietf.org; Thu, 13 Jul 2006 03:24:33 -0400
Received: from proof.pobox.com ([207.106.133.28])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0vYl-00053U-Qg
	for ima@ietf.org; Thu, 13 Jul 2006 03:24:33 -0400
Received: from proof (localhost [127.0.0.1])
	by proof.pobox.com (Postfix) with ESMTP id 68518247E5;
	Thu, 13 Jul 2006 03:24:31 -0400 (EDT)
Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82])
	by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 03080632B5;
	Thu, 13 Jul 2006 03:24:29 -0400 (EDT)
Date: Thu, 13 Jul 2006 00:24:28 -0700
From: Bill McQuillan <McQuilWP@pobox.com>
X-Priority: 4 (Low)
Message-ID: <622321037.20060713002428@pobox.com>
To: IMA Discussion <ima@ietf.org>
Subject: Re: [EAI] ATOMIC or not
In-Reply-To: <44B58D61.80709@icu.ac.kr>
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
	<020101c6a52f$ca3f2660$b30110ac@edmontr3>
	<p06300012c0d9e269fecb@[142.131.134.210]>
	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>
	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>
	<03c201c6a607$a68936b0$b30110ac@edmontr3> <44B58D61.80709@icu.ac.kr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.2 (+)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
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 feel I need to delurk here just to point out what I am increasingly
seeing as a problem. I believe that several people on this list are
alluding to this in the latest exchange of messages.

The "alt-addr" mechanism seems to be becoming more and more an immense
administrative nightmare!

If I recall, it was proposed as a solution to the problem of "non-atomic"
addresses. (I hate that term!) That is, addresses that cannot be
transformed into an RFC2822-safe format for some reason. I do not feel that
this was explored extensively in the WG. (Admittedly, I was not at any
face-to-face meetings.)

If there existed a transformation that was guaranteed reversible and did
not apply to already RFC2822 compliant addresses or the ASCII portions of
the local parts, I have to agree with Charles Lindsey that many, many
problems would go away.

Note that any address that is currently parsed by the sender or recipient
must already be RFC2822 compliant and therfore would not be transformed.
Also, commonly known format of addresses like "-owner", "+folder", etc. use
acceptable ASCII chars ("-", "+") which should not be transformed by a
reasonable ACE and therfore should be parsed as expected. The only entity
that needs to know how to interpret the parsed portion of local parts is
presumably a final delivery agent that has been enhanced to accept UTF8
local parts and could easily be expected to be able to undo the ACE.

As a strawman, here is an ACE that follows these requirements (though
perhaps a little verbosely!):

If any character of a local part is not an allowed RFC2822-compliant
character, then the entire local part is preceded by a flag string such as
"ima--" and each such non-conpliant character is replaced in the local part
by "=XX" enough times to express each octet of the UTF8 encoding of the
character, where XX is the HEX expression of an octet. Any character that
*is* valid in an RFC2822 local part SHOULD NOT be transformed.

Let the brickbats fly!

-- 
Bill McQuillan <McQuilWP@pobox.com>


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



From ima-bounces@ietf.org Thu Jul 13 11:47:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G13Ox-0004ia-8B; Thu, 13 Jul 2006 11:46:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G13Ow-0004iK-IZ
	for ima@ietf.org; Thu, 13 Jul 2006 11:46:54 -0400
Received: from lon-mail-3.gradwell.net ([193.111.201.127])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G13Ot-0003RB-UC
	for ima@ietf.org; Thu, 13 Jul 2006 11:46:54 -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.227) id
	44b66ae9.549e.60 for ima@ietf.org; Thu, 13 Jul 2006 16:46:49 +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 k6DFkjv7018415
	for <ima@ietf.org>; Thu, 13 Jul 2006 16:46:46 +0100 (BST)
To: "IMA Discussion" <ima@ietf.org>
Subject: Re: [EAI] ATOMIC or not
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
	<020101c6a52f$ca3f2660$b30110ac@edmontr3>
	<p06300012c0d9e269fecb@[142.131.134.210]>
	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>
	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>
	<03c201c6a607$a68936b0$b30110ac@edmontr3>
	<44B58D61.80709@icu.ac.kr> <622321037.20060713002428@pobox.com>
Message-ID: <op.tcmwr5f06hl8nm@clerew.man.ac.uk>
Date: Thu, 13 Jul 2006 16:46:43 +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: <622321037.20060713002428@pobox.com>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
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 Thu, 13 Jul 2006 08:24:28 +0100, Bill McQuillan <McQuilWP@pobox.com>  
wrote:

> I feel I need to delurk here just to point out what I am increasingly
> seeing as a problem. I believe that several people on this list are
> alluding to this in the latest exchange of messages.
>
> The "alt-addr" mechanism seems to be becoming more and more an immense
> administrative nightmare!

It should not be. It should only be put there by the original author (or  
by some software configured with his approval - but remember that it can  
also turn up in a Reply-To address). I says "If this message (or replies  
to it) cannot be delivered to the UTF-8smtp address,l then I am happy for  
them to be delivered to this ascii@ascii address instead". Don't read any  
mor into it than that. Maybe the alt-address goes to the same destination.  
Maybe it goes to some agency which will translate the message and send it  
on. Maybe it goes to dev-null. You don't know - all you do know is that is  
what the original author had instructed.
>

> If there existed a transformation that was guaranteed reversible and did
> not apply to already RFC2822 compliant addresses or the ASCII portions of
> the local parts, I have to agree with Charles Lindsey that many, many
> problems would go away.

I believe it is possible to make an ACE that is guaranteed reversible.  
Since this latest thread started, I have been looking into Punycode again.  
But it is indeed full of worms, and I want to be sure I really understand  
them all before I report on them. But indications are that it can be made  
to work.

-- 
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 Jul 13 12:31:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G146G-0002Qh-9z; Thu, 13 Jul 2006 12:31:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G146F-0002QS-8K
	for ima@ietf.org; Thu, 13 Jul 2006 12:31:39 -0400
Received: from m6f195e42.tmodns.net ([66.94.25.111]
	helo=svcstatl07.hotspot.t-mobile.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G146E-0005WP-0R
	for ima@ietf.org; Thu, 13 Jul 2006 12:31:39 -0400
Received: from edmontr3 (204.9.242.10.in-addr.arpa [10.242.9.204])
	by svcstatl07.hotspot.t-mobile.com (8.12.10+Sun/8.12.10) with ESMTP id
	k6DGVVLZ006751
	for <ima@ietf.org>; Thu, 13 Jul 2006 12:31:36 -0400 (EDT)
Message-ID: <054e01c6a699$cd261530$b30110ac@edmontr3>
From: "Edmon Chung" <edmon@afilias.info>
To: <ima@ietf.org>
References: <011201c6a513$5636a020$b30110ac@edmontr3><p0630000bc0d9b50c344b@[142.131.134.210]><020101c6a52f$ca3f2660$b30110ac@edmontr3><p06300012c0d9e269fecb@[142.131.134.210]><036e01c6a5f3$2cb3ba90$b30110ac@edmontr3><Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk><03c201c6a607$a68936b0$b30110ac@edmontr3><44B58D61.80709@icu.ac.kr>
	<622321037.20060713002428@pobox.com>
	<op.tcmwr5f06hl8nm@clerew.man.ac.uk>
Subject: Re: [EAI] ATOMIC or not
Date: Thu, 13 Jul 2006 12:31:01 -0400
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlx=0
	adultscore=0 adjust=0 reason=mlx engine=3.1.0-0606280001
	definitions=main-0607130001
X-Spam-Score: 1.0 (+)
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>
Content-Type: multipart/mixed; boundary="===============1410317237=="
Errors-To: ima-bounces@ietf.org

--===============1410317237==
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNoYXJsZXMgTGluZHNleSIg
PGNobEBjbGVyZXcubWFuLmFjLnVrPg0KPj4gSWYgdGhlcmUgZXhpc3RlZCBhIHRyYW5zZm9ybWF0
aW9uIHRoYXQgd2FzIGd1YXJhbnRlZWQgcmV2ZXJzaWJsZSBhbmQgZGlkDQo+PiBub3QgYXBwbHkg
dG8gYWxyZWFkeSBSRkMyODIyIGNvbXBsaWFudCBhZGRyZXNzZXMgb3IgdGhlIEFTQ0lJIHBvcnRp
b25zIG9mDQo+PiB0aGUgbG9jYWwgcGFydHMsIEkgaGF2ZSB0byBhZ3JlZSB3aXRoIENoYXJsZXMg
TGluZHNleSB0aGF0IG1hbnksIG1hbnkNCj4+IHByb2JsZW1zIHdvdWxkIGdvIGF3YXkuDQo+IA0K
PiBJIGJlbGlldmUgaXQgaXMgcG9zc2libGUgdG8gbWFrZSBhbiBBQ0UgdGhhdCBpcyBndWFyYW50
ZWVkIHJldmVyc2libGUuICANCj4gU2luY2UgdGhpcyBsYXRlc3QgdGhyZWFkIHN0YXJ0ZWQsIEkg
aGF2ZSBiZWVuIGxvb2tpbmcgaW50byBQdW55Y29kZSBhZ2Fpbi4gIA0KPiBCdXQgaXQgaXMgaW5k
ZWVkIGZ1bGwgb2Ygd29ybXMsIGFuZCBJIHdhbnQgdG8gYmUgc3VyZSBJIHJlYWxseSB1bmRlcnN0
YW5kICANCj4gdGhlbSBhbGwgYmVmb3JlIEkgcmVwb3J0IG9uIHRoZW0uIEJ1dCBpbmRpY2F0aW9u
cyBhcmUgdGhhdCBpdCBjYW4gYmUgbWFkZSAgDQo+IHRvIHdvcmsuDQoNCk9uZSB0aGluZyB0aGF0
IElETiBoYWQgdG8gZG8gd2FzIHRvIHRyeSBpdHMgYmVzdCB0byBhdm9pZCAiY29uZmxpY3Rpbmci
IHdpdGggZXhpc3RpbmcgbmFtZXMgYWdhaW5zdCB0aGUgImNvbnZlcnRlZCBmb3JtIi4gICJYTi0t
IiBwcmVmaXggd2FzIGZpbmFsbHkgY2hvc2VuLCBhbmQgd2UgaGF2ZSBzbyBmYXIgbm90IGhlYXJk
IGFueSBpc3N1ZSBmcm9tIHByZXZpb3VzbHkgZXhpc3RpbmcgZG9tYWluIHRoYXQgc3RhcnRlZCB3
aXRoICJ4bi0tIiB0aGF0IGlzIG5vdyBhZmZlY3RlZC4NCg0KRm9yIG1haWwgdXNlcm5hbWUgaXQg
bWlnaHQgYmUgbXVjaCBoYXJkZXIgYXMgdGhlcmUgZXhpc3RzIG1hbnkgZm9ybXMgb2YgImVuY29k
ZWQiIHVzZXJuYW1lcyBhbG9uZyB3aXRoIG11Y2ggbW9yZSAidXNlcm5hbWVzIiBpbiBnZW5lcmFs
LCBlc3BlY2lhbGx5IHdoZW4gdGhlICJjb252ZXJ0ZWQgZm9ybSIgbXVzdCBhbHNvIGJlIGNvbXBs
aWFudCB3aXRoIGV4aXN0aW5nIHJ1bGVzLiAgTm90IHNheWluZyBpdCBpcyBpbXBvc3NpYmxlLCBq
dXN0IG5lZWQgdG8gaGF2ZSB0aGF0IGluIG1pbmQgaWYgd2UgZGVjaWRlIGF0IGFsbCB0byBnbyBk
b3duIHRoZSBwYXRoIG9mIGRlc2lnbmluZyBzb21ldGhpbmcgZm9yIGl0Lg0KDQpUaGUgcXVlc3Rp
b25zIHN0aWxsIHJlbWFpbnMgKGF0IGxlYXN0IGZvciB0aGlzIHRocmVhZC9leGVyY2lzZSk6DQox
LiBEbyB3ZSB3YW50IGEgcGFyYW1ldGVyIGZvciBkZXNpZ25hdGluZyBBVE9NSUMgb3Igbm90Pw0K
Mi4gSWYgbm90LCBpcyBBVE9NSUMgdGhlIGRlZmF1bHQ/IG9yIE5vbi1BVE9NSUMgdGhlIGRlZmF1
bHQ/DQozLiBJZiBub24tQVRPTUlDIGlzIHRoZSBkZWZhdWx0LCB0aGVyZSBpcyBubyBwb2ludCBj
cmVhdGluZyB0aGUgImd1YXJhbnRlZWQgcmV2ZXJzaWJlIEFDRSIuLi4gaXMgdGhlcmU/ICBSZWFz
b24gYmVpbmcgdGhhdCBnaXZlbiBhIFVURjggYWRkcmVzcyBhbmQgdGhhdCBpdCBpcyBub24tQVRP
TUlDLCB3ZSBjYW5ub3QgdGhlbiB0cnkgdG8gdHJhbnNmb3JtIGl0IGludG8gQUNFIGZvciBkb3du
Z3JhZGUgYW5kIGV4cGVjdCBpdCB0byB3b3JrIGFueXdheS4NCjQuIE9SIGlzIGl0IHRoYXQgaWYg
YSAiZ3VhcmFudGVlZCByZXZlcnNpYmxlIEFDRSBpcyBkZWZpbmVkLCBub24tQVRPTUlDIGl0c2Vs
ZiBpcyBuby1sb25nZXIgInZhbGlkIiwgaS5lLiB0aGV5IGFyZSBtdXR1YWxseSBleGNsdXNpdmUg
KG5vbi1hdG9taWMgdnMuIGd1YXJhbnRlZWQgcmV2ZXJzaWJsZSBBQ0UpPw0KNS4gQXQgd2hpY2gg
cG9pbnQuLi4gdGhlbiBpcyBhbHQtYWRkcmVzcyBuZWVkZWQgYXQgYWxsPyAgU2hvdWxkIGl0IGJl
IG91dCBvZiBzY29wZSBhbmQgbGVmdCBmb3Igb3RoZXIgZXh0ZW5zaW9ucyB0byBwcm92aWRlIGFu
IGFsaWFzIG9mIGFuIGVtYWlsIGFkZHJlc3MgKHJlZ2FyZGxlc3Mgb2YgRUFJIG9yIG5vdCwgZm9y
IGFueSBhZGRyZXNzIGZpZWxkKT8uLi4gdGhpcyBxdWVzdGlvbiBtYXliZSBnb2luZyB0byBmYXIu
Li4gYnV0IG5ldmVydGhlbGVzcyA6LVAgIChwZXJzb25hbGx5IEkgbGlrZSBoYXZpbmcgdGhlIGZs
ZXhpYmlsaXR5IG9mIGhhdmluZyBhbiBhbHQtYWRkciBpbiB0aGlzIGNvbnRleHQgdGhvdWdoLi4u
IHRoYXQgZG9lc250IG1lYW4gaXQgaXMgIm5lY2Vzc2FyeSIpDQoNCg0KRWRtb24NCg0KDQoNCg==




--===============1410317237==
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

--===============1410317237==--



From ima-bounces@ietf.org Thu Jul 13 13:29:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G14zt-0002JJ-KH; Thu, 13 Jul 2006 13:29:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G14zr-0002Ey-As
	for ima@ietf.org; Thu, 13 Jul 2006 13:29:07 -0400
Received: from mail.globalsuite.net ([69.46.103.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G14zq-0000Ew-Sa
	for ima@ietf.org; Thu, 13 Jul 2006 13:29:07 -0400
Received: from [172.17.100.74] (unknown [207.134.107.2])
	by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 32D74327;
	Thu, 13 Jul 2006 11:29:04 -0600 (MDT)
Message-ID: <44B682DB.8090504@icu.ac.kr>
Date: Fri, 14 Jul 2006 02:28:59 +0900
From: Yangwoo Ko <newcat@icu.ac.kr>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Edmon Chung <edmon@afilias.info>
Subject: Re: [EAI] ATOMIC or not
References: <011201c6a513$5636a020$b30110ac@edmontr3><p0630000bc0d9b50c344b@[142.131.134.210]><020101c6a52f$ca3f2660$b30110ac@edmontr3><p06300012c0d9e269fecb@[142.131.134.210]><036e01c6a5f3$2cb3ba90$b30110ac@edmontr3><Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk><03c201c6a607$a68936b0$b30110ac@edmontr3><44B58D61.80709@icu.ac.kr>	<622321037.20060713002428@pobox.com>	<op.tcmwr5f06hl8nm@clerew.man.ac.uk>
	<054e01c6a699$cd261530$b30110ac@edmontr3>
In-Reply-To: <054e01c6a699$cd261530$b30110ac@edmontr3>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
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

Edmon Chung wrote:
> ----- Original Message ----- 
> From: "Charles Lindsey" <chl@clerew.man.ac.uk>
>>> If there existed a transformation that was guaranteed reversible and did
>>> not apply to already RFC2822 compliant addresses or the ASCII portions of
>>> the local parts, I have to agree with Charles Lindsey that many, many
>>> problems would go away.
>> I believe it is possible to make an ACE that is guaranteed reversible.  
>> Since this latest thread started, I have been looking into Punycode again.  
>> But it is indeed full of worms, and I want to be sure I really understand  
>> them all before I report on them. But indications are that it can be made  
>> to work.
> 
> One thing that IDN had to do was to try its best to avoid "conflicting" with existing names against the "converted form".  "XN--" prefix was finally chosen, and we have so far not heard any issue from previously existing domain that started with "xn--" that is now affected.
> 
> For mail username it might be much harder as there exists many forms of "encoded" usernames along with much more "usernames" in general, especially when the "converted form" must also be compliant with existing rules.  Not saying it is impossible, just need to have that in mind if we decide at all to go down the path of designing something for it.
> 
> The questions still remains (at least for this thread/exercise):
> 1. Do we want a parameter for designating ATOMIC or not?
> 2. If not, is ATOMIC the default? or Non-ATOMIC the default?

Let's ask the same question to email addresses used today?
Which one is default? Well, my answer is none. Except the
final delivery, we do not assume anything about the nature
of local part. I want that the same thing is true for i18n
email addresses.

However, if we want to attach such information, we may choose
either ATOMIC or non-ATOMIC as default. When introducing
ATOMIC, we assumed that non-ATOMIC is default.

> 3. If non-ATOMIC is the default, there is no point creating the "guaranteed reversibe ACE"... is there?  

I cannot follow your logic here.

 >Reason being that given a UTF8 address and that it is non-ATOMIC, we 
cannot then try to transform it into ACE for downgrade and expect it to 
work anyway.

Yes.

> 4. OR is it that if a "guaranteed reversible ACE is defined, non-ATOMIC itself is no-longer "valid", i.e. they are mutually exclusive (non-atomic vs. guaranteed reversible ACE)?

This is related to when such a conversion is made. For
example, as is done in IDNA if it is always clear when
to convert (and revert back) and we use only the
converted on-the-wire, then maybe we don't care whether
given addresses are ATOMIC or not. But unfortunately,
this is not the case.

> 5. At which point... then is alt-address needed at all?  Should it be out of scope and left for other extensions to provide an alias of an email address (regardless of EAI or not, for any address field)?... this question maybe going to far... but nevertheless :-P  (personally I like having the flexibility of having an alt-addr in this context though... that doesnt mean it is "necessary")

ALT-ADDR will be a lot more useful when we want to
send mails though mailing list. For one-to-one (or
one-to-few) communications, sender/recipients are
controlled by sender explicitly, the sender can be
wise enough to choose i18n addresses or all-ASCII
addresses so that the mail can be delivered as
wanted. In addition, even though there are error
in delivery, the sender can react upon them. (E.g.
sending the same mail with all-ASCII addresses.)
ALT-ADDR can be helpful to reduce the number of
these (probably manual) reactions.

On the other hand, senders are usually helpless
who are there on a given mailing list.

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


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



From ima-bounces@ietf.org Thu Jul 13 14:43:12 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G169Q-0005kW-FF; Thu, 13 Jul 2006 14:43:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G169O-0005kE-VR
	for ima@ietf.org; Thu, 13 Jul 2006 14:43:02 -0400
Received: from maila.microsoft.com ([131.107.1.7] helo=mail2.microsoft.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G169M-0006vJ-LJ
	for ima@ietf.org; Thu, 13 Jul 2006 14:43:02 -0400
Received: from mailout6.microsoft.com ([157.54.69.150]) by mail2.microsoft.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 13 Jul 2006 11:43:00 -0700
Received: from tuk-hub-01.redmond.corp.microsoft.com ([157.54.70.27]) by
	mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 13 Jul 2006 11:42:59 -0700
Received: from WINSE-MSG-01.segroup.winse.corp.microsoft.com ([157.54.6.40])
	by tuk-hub-01.redmond.corp.microsoft.com with Microsoft
	SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 11:42:59 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 13 Jul 2006 11:41:00 -0700
Message-ID: <F7585EDDB1D8E84DA6FFF188C8F9A3760DF81290@winse-msg-01.segroup.winse.corp.microsoft.com>
In-Reply-To: <E1G0vYo-0008Iz-DB@megatron.ietf.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ATOMIC or not
thread-index: AcamTWVMCg3qS2BZRoWTr4IJ6zwn+AAXCDAw
References: <E1G0vYo-0008Iz-DB@megatron.ietf.org>
From: "Shawn Steele" <Shawn.Steele@microsoft.com>
To: <ima@ietf.org>
X-OriginalArrivalTime: 13 Jul 2006 18:42:59.0684 (UTC)
	FILETIME=[2A0EDA40:01C6A6AC]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Subject: [EAI] RE: ATOMIC or not
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


> Not true.  If an address is designated as ATOMIC, then I would store
that information cause I know
> that it could be used in the future.  If an alt-address is provided,
then I would probably have to
> discard it cause I cannot determine whether I can use that same
alt-addr in the future.

As was mentioned, you can't trust any address anyway

> The "alt-addr" mechanism seems to be becoming more and more an immense
> administrative nightmare!

Perhaps, but I'd like to point out that most mail servers already
support alternate addresses.  For example, I'm
Shawn.Steele@microsoft.com or shawnste@microsoft.com  Neither is really
very guaranteed, I could change then on a whim. =20

What existing protocols don't really give us is a way for me to tell you
that I have multiple addresses.  I could easily see my Chinese coworkers
getting a third alias when IMA becomes common, regardless of the status
of alt-address.  A Chinese address would work well for some people, but
I would still find a latin address to be more usable.  This isn't a
technical limitation, but a human one.  In this case I'd imagine that a
business card would probably have the Chinese and Latin transliterated
addresses.

What doesn't currently exist is a way to exchange backup-addresses,
which is what the draft does with alt-address.  Presumably mail clients
that were IMA aware would capture both addresses to use as appropriate.

- Shawn

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



From ima-bounces@ietf.org Thu Jul 13 16:18:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G17db-000880-Dh; Thu, 13 Jul 2006 16:18:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G17da-00085P-Pt
	for ima@ietf.org; Thu, 13 Jul 2006 16:18:18 -0400
Received: from mail126.messagelabs.com ([216.82.250.99])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G17dZ-0005ez-Cn
	for ima@ietf.org; Thu, 13 Jul 2006 16:18:18 -0400
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-15.tower-126.messagelabs.com!1152821896!13094584!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 14002 invoked from network); 13 Jul 2006 20:18:16 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4)
	by server-15.tower-126.messagelabs.com with SMTP;
	13 Jul 2006 20:18:16 -0000
Received: from [135.210.40.171] (unknown[135.210.40.171](misconfigured sender))
	by maillennium.att.com (mailgw1) with ESMTP
	id <20060713201815gw1003jp60e> (Authid: tony);
	Thu, 13 Jul 2006 20:18:15 +0000
Message-ID: <44B6AA85.2040601@att.com>
Date: Thu, 13 Jul 2006 16:18:13 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Edmon Chung <edmon@afilias.info>
Subject: Re: [EAI] ATOMIC or not
References: <011201c6a513$5636a020$b30110ac@edmontr3>	<p0630000bc0d9b50c344b@[142.131.134.210]>	<020101c6a52f$ca3f2660$b30110ac@edmontr3>	<p06300012c0d9e269fecb@[142.131.134.210]>	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>
	<03c201c6a607$a68936b0$b30110ac@edmontr3>
In-Reply-To: <03c201c6a607$a68936b0$b30110ac@edmontr3>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
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

Let's separate out the current ATOMIC implementation and the ATOMIC
concept. The ATOMIC concept says that the i18n localpart can be safely
downgraded to the downgradable ACE form. That's it.

During the EAI meeting, when people said to get rid of ATOMIC in SMTP,
my understanding is that they were saying to get rid of the SMTP ATOMIC
parameter. They were *not* saying anything about getting rid of the
ATOMIC concept.

If we want to support the ATOMIC concept, no matter how we do it, the
sender needs to know if any given i18n localpart is ATOMIC. This doesn't
necessarily mean that all intermediate hops in message transmission also
needs to know it.

Orthogonal to this concept is that of an alternate ascii-compatible
address that would be used if the i18n localpart cannot be used.

The ATOMIC information provides a way to indicate that the downgradable
ACE form of the i18n address can be used as the alternate address.

The single bit of knowledge about whether an i18n localpart is ATOMIC
can be used and passed in several ways. The current specs call for the
MUA to do the following processing:

mua:	if i18n address is ATOMIC
mua:		pass i18n address and info saying address is ATOMIC
mua:	else if there is an alternate ACE address
mua:		pass i18n address and alternate ACE address
mua:	else
mua:		pass i18n address

When an MTA hits another MTA that is not i18n compatible, it must do the
following processing:

mta:	if address is ATOMIC
mta:		downgrade message headers and body
mta:		convert i18n address to ACE
mta:		use converted address
mta:	else if there is an alternate ACE address
mta:		downgrade message headers and body
mta:		use alternate address
mta:	else
mta:		bounce the message

Consider the following alternative where the MUA uses the knowledge that
the i18n address is ATOMIC and uses that knowledge up front to set the
alternate address.

mua:	if i18n address is ATOMIC
mua:		pass i18n address and generated ACE address as alternate
mua:	else if there is an alternate ACE address
mua:		pass i18n address and alternate ACE address
mua:	else
mua:		pass i18n address

Now look at how much simpler the MTA becomes:

mta:	if there is an alternate ACE address
mta:		downgrade message headers and body
mta:		use alternate address
mta:	else
mta:		bounce the message		

During the EAI meeting, when people said to get rid of ATOMIC in SMTP,
my understanding is that they were saying to get rid of the SMTP ATOMIC
parameter, but not the ATOMIC concept.

	Tony Hansen
	tony@att.com

Edmon Chung wrote:
> ----- Original Message ----- 
> From: "Tony Finch" <dot@dotat.at>
>>> If an address is designated as ATOMIC, then I would store that
>>> information cause I know that it could be used in the future.  If an
>>> alt-address is provided, then I would probably have to discard it cause
>>> I cannot determine whether I can use that same alt-addr in the future.
>> If you can't trust the alt-address then surely you can't trust the utf8
>> address either. Or in other words, I don't think this kind of operational
>> stability issue is relevant. You can always verify that the alt-address is
>> the algorithmically-downgraded form of the utf8 address by doing the
>> downgrade and comparing.
> 
> ALT-ADDRESS is not the same as ATOMIC.  ALT-ADDRESS can be any ASCII address.  E.g. "<chineseName>@domain.tld" can have an ALT-ADDR="abc@def.org" (note not even the domain needs to match).  That is why the alt-address cannot be a "stable" glue to the UTF8 address.  The UTF8 address can be fully trusted so can an ATOMIC address (well unless the standard transformation algorithm is changed... but that would be a different issue... more on versioning).
> 
>> I'm seriously worried about the user-interface implications of non-atomic
>> addresses.
> 
> Well without the ATOMIC parameter at all there is no way to say that an address is atomic... and based on the current set of specifications, Non-atomic is the default.
> 
> Edmon
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www1.ietf.org/mailman/listinfo/ima

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



From ima-bounces@ietf.org Fri Jul 14 07:25:31 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G1LnP-0008Rr-0f; Fri, 14 Jul 2006 07:25:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G1LnO-0008RO-Ge
	for ima@ietf.org; Fri, 14 Jul 2006 07:25:22 -0400
Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1LnK-0001JQ-7K
	for ima@ietf.org; Fri, 14 Jul 2006 07:25:22 -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-1.csi.cam.ac.uk ([131.111.8.51]:45743)
	by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G1LnE-0003Da-4v (Exim 4.54) for
	ima@ietf.org
	(return-path <fanf2@hermes.cam.ac.uk>); Fri, 14 Jul 2006 12:25:13 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk)
	with local-esmtp id 1G1LnE-0000nC-Fb (Exim 4.53) for ima@ietf.org
	(return-path <fanf2@hermes.cam.ac.uk>); Fri, 14 Jul 2006 12:25:12 +0100
Date: Fri, 14 Jul 2006 12:25:12 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: ima@ietf.org
Message-ID: <Pine.LNX.4.64.0607141218320.14969@hermes-1.csi.cam.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Subject: [EAI] Downgrading ascii@utf8
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 I have an address with an ASCII-only local part and a UTF-8 domain
part, with no alternate address and no "atomic" ACE-downgradable flag, is
it OK for me to downgrade it by punycoding the domain part?

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FAEROES SOUTHEAST ICELAND: WEST 5 OR 6 BACKING SOUTH 5 TO 7, OCCASIONALLY 4
FOR A TIME IN FAEROES. SHOWERS AT FIRST, RAIN LATER IN SOUTHEAST ICELAND.
MODERATE OR GOOD.

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



From ima-bounces@ietf.org Fri Jul 14 09:47:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G1O0x-0001pk-3N; Fri, 14 Jul 2006 09:47:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G1O0w-0001pV-36
	for ima@ietf.org; Fri, 14 Jul 2006 09:47:30 -0400
Received: from nz-out-0102.google.com ([64.233.162.198])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1O0r-0007yb-IY
	for ima@ietf.org; Fri, 14 Jul 2006 09:47:30 -0400
Received: by nz-out-0102.google.com with SMTP id o37so247407nzf
	for <ima@ietf.org>; Fri, 14 Jul 2006 06:47:25 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:reply-to:to:references:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole:from;
	b=Yr4ns65lmO/fc0Lv2Oo9sxHPNycsq+C5GnrRttpuAiMcs5CFqjpRrgvXJx4avrrWGy3K5exjSLV2JyX8nQB3XnfEkMunabKcvrs/kFvWVrCURd9EwN1aAGVe/NBe8/asX248EATwWvMaQoNpKGBdNvlsUzPhQeL1G3gKbtJGFHg=
Received: by 10.65.205.11 with SMTP id h11mr1275190qbq;
	Fri, 14 Jul 2006 06:47:25 -0700 (PDT)
Received: from edmontr3 ( [219.76.150.236])
	by mx.gmail.com with ESMTP id e11sm1643711qbc.2006.07.14.06.47.21;
	Fri, 14 Jul 2006 06:47:24 -0700 (PDT)
Message-ID: <05e101c6a74c$093fd850$b30110ac@edmontr3>
To: <ima@ietf.org>
References: <Pine.LNX.4.64.0607141218320.14969@hermes-1.csi.cam.ac.uk>
Subject: Re: [EAI] Downgrading ascii@utf8
Date: Fri, 14 Jul 2006 09:46:44 -0400
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
From: Edmon Chung <edmonchung@gmail.com>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Edmon Chung <edmon@afilias.info>
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>
Content-Type: multipart/mixed; boundary="===============1470334904=="
Errors-To: ima-bounces@ietf.org

--===============1470334904==
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

QXMgZmFyIGFzIEkgdW5kZXJzdGFuZCB0aGF0IGlzIHllcy4NCkJlY2F1c2UgdGhhdCBpcyBhIG1h
dHRlciBvZiBJRE4gc3BlY2lmaWNhdGlvbnMgd2hlcmUgaXQgc2F5cyBwdW55Y29kZSBtdXN0IGJl
IHVzZWQgaW4gYWxsIG5vbi1JRE4tYXdhcmUgZG9tYWluIHNsb3RzLCB3aGljaCB0aGlzIHdvdWxk
IGJlIG9uZS4NCkVkbW9uDQoNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJv
bTogIlRvbnkgRmluY2giIDxkb3RAZG90YXQuYXQ+DQpUbzogPGltYUBpZXRmLm9yZz4NClNlbnQ6
IEZyaWRheSwgSnVseSAxNCwgMjAwNiA3OjI1IEFNDQpTdWJqZWN0OiBbRUFJXSBEb3duZ3JhZGlu
ZyBhc2NpaUB1dGY4DQoNCg0KPiBJZiBJIGhhdmUgYW4gYWRkcmVzcyB3aXRoIGFuIEFTQ0lJLW9u
bHkgbG9jYWwgcGFydCBhbmQgYSBVVEYtOCBkb21haW4NCj4gcGFydCwgd2l0aCBubyBhbHRlcm5h
dGUgYWRkcmVzcyBhbmQgbm8gImF0b21pYyIgQUNFLWRvd25ncmFkYWJsZSBmbGFnLCBpcw0KPiBp
dCBPSyBmb3IgbWUgdG8gZG93bmdyYWRlIGl0IGJ5IHB1bnljb2RpbmcgdGhlIGRvbWFpbiBwYXJ0
Pw0KPiANCj4gVG9ueS4NCj4gLS0gDQo+IGYuYS5uLmZpbmNoICA8ZG90QGRvdGF0LmF0PiAgaHR0
cDovL2RvdGF0LmF0Lw0KPiBGQUVST0VTIFNPVVRIRUFTVCBJQ0VMQU5EOiBXRVNUIDUgT1IgNiBC
QUNLSU5HIFNPVVRIIDUgVE8gNywgT0NDQVNJT05BTExZIDQNCj4gRk9SIEEgVElNRSBJTiBGQUVS
T0VTLiBTSE9XRVJTIEFUIEZJUlNULCBSQUlOIExBVEVSIElOIFNPVVRIRUFTVCBJQ0VMQU5ELg0K
PiBNT0RFUkFURSBPUiBHT09ELg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4gSU1BIG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0Zi5vcmcNCj4g
aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1hDQo+IA0KPg==



--===============1470334904==
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

--===============1470334904==--



From ima-bounces@ietf.org Fri Jul 14 13:28:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G1RSP-0004vC-HQ; Fri, 14 Jul 2006 13:28:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G1RSO-0004v7-4n
	for ima@ietf.org; Fri, 14 Jul 2006 13:28:04 -0400
Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1RSL-0008DX-Rj
	for ima@ietf.org; Fri, 14 Jul 2006 13:28:04 -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-1.csi.cam.ac.uk ([131.111.8.51]:39060)
	by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G1RSI-0000Jw-Tz (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Fri, 14 Jul 2006 18:27:58 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1G1RSI-0001QQ-7p (Exim 4.53)
	(return-path <fanf2@hermes.cam.ac.uk>); Fri, 14 Jul 2006 18:27:58 +0100
Date: Fri, 14 Jul 2006 18:27:58 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Edmon Chung <edmonchung@gmail.com>
Subject: Re: [EAI] Downgrading ascii@utf8
In-Reply-To: <05e101c6a74c$093fd850$b30110ac@edmontr3>
Message-ID: <Pine.LNX.4.64.0607141826310.14969@hermes-1.csi.cam.ac.uk>
References: <Pine.LNX.4.64.0607141218320.14969@hermes-1.csi.cam.ac.uk>
	<05e101c6a74c$093fd850$b30110ac@edmontr3>
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 Fri, 14 Jul 2006, Edmon Chung wrote:
>
> > If I have an address with an ASCII-only local part and a UTF-8 domain
> > part, with no alternate address and no "atomic" ACE-downgradable flag, is
> > it OK for me to downgrade it by punycoding the domain part?

> As far as I understand that is yes. Because that is a matter of IDN
> specifications where it says punycode must be used in all non-IDN-aware
> domain slots, which this would be one.

Good :-)

I think the documents should be clearer that the downgrade restrictions
apply to the use of UTF8 in the local part only.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
LANDS END TO ST DAVIDS HEAD INCLUDING THE BRISTOL CHANNEL: EAST OR NORTHEAST 3
OR 4, OCCASIONALLY 5. FAIR. GOOD. SLIGHT TO MODERATE.

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



From ima-bounces@ietf.org Fri Jul 14 22:35:08 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G1ZzY-0005mc-S1; Fri, 14 Jul 2006 22:34:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G1ZzX-0005ji-Sx
	for ima@ietf.org; Fri, 14 Jul 2006 22:34:51 -0400
Received: from py-out-1112.google.com ([64.233.166.177])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1ZzV-0007u5-6X
	for ima@ietf.org; Fri, 14 Jul 2006 22:34:51 -0400
Received: by py-out-1112.google.com with SMTP id m51so856619pye
	for <ima@ietf.org>; Fri, 14 Jul 2006 19:34:15 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:reply-to:to:references:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole:from;
	b=OyssKC8wh5NTcjqw6XHUMLKY3b4dodALdQK5D9wyJQDwCBtIJjShie0Z2LLkgW3oQz24m/063f9Noodpx9QlReSFjMar/ARKU4t5PVWPJ+yjBkilK7yemVo7roozBsktPJ8BXOWOl8F7ULLN2meAK2eeQLRTRPtFCNe/7gAZgcg=
Received: by 10.35.93.1 with SMTP id v1mr323501pyl;
	Fri, 14 Jul 2006 19:34:15 -0700 (PDT)
Received: from edmontr3 ( [219.76.150.213])
	by mx.gmail.com with ESMTP id i70sm1169081pye.2006.07.14.19.34.09;
	Fri, 14 Jul 2006 19:34:15 -0700 (PDT)
Message-ID: <066901c6a7b7$26e121a0$b30110ac@edmontr3>
To: <ima@ietf.org>
References: <011201c6a513$5636a020$b30110ac@edmontr3>	<p0630000bc0d9b50c344b@[142.131.134.210]>	<020101c6a52f$ca3f2660$b30110ac@edmontr3>	<p06300012c0d9e269fecb@[142.131.134.210]>	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>
	<03c201c6a607$a68936b0$b30110ac@edmontr3>
	<44B6AA85.2040601@att.com>
Subject: Re: [EAI] ATOMIC or not
Date: Fri, 14 Jul 2006 22:32:58 -0400
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
From: Edmon Chung <edmonchung@gmail.com>
X-Spam-Score: 2.4 (++)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Edmon Chung <edmon@afilias.info>
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>
Content-Type: multipart/mixed; boundary="===============1733595408=="
Errors-To: ima-bounces@ietf.org

--===============1733595408==
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

SSB1bmRlcnN0YW5kIHlvdXIgYW5hbHlzaXMgYW5kIHRoZSBhcHByb2FjaCBzdWdnZXN0ZWQuICBO
b3Qgc2F5aW5nIGl0IGRvZXMgbm90IHdvcmsuLi4NCg0KSG93ZXZlciwgbXkgcG9pbnQgaXMgaWYg
IkFUT01JQyIgYXMgYSBwYXJhbWV0ZXIgaXMgbmV2ZXIgdHJhbnNwb3J0ZWQsIHRoZW4gdGhlcmUg
aXMgbm8gbmVlZCBmb3IgYSBzdGFuZGFyZGl6ZWQgd2F5IHRvIGNyZWF0ZSBhbiBBQ0UgcmVwcmVz
ZW50YXRpb24gb2YgYSBVVDggYWRkcmVzcy4gIEJlY2F1c2UgZWFjaCBNVUEgY2FuIHVzZSBhbnkg
bWV0aG9kIG9mIHRyYW5zZm9ybWF0aW9uIHRvIGFuIGFsdC1hZGRyZXNzIHRoZXkgd2FudCBhbmQg
dGhlIHByb3RvY29sIHdvdWxkIHN0aWxsIGZ1bmN0aW9uIHdpdGhvdXQgYW55IHByb2JsZW0uICBC
ZWNhdXNlIGluIG5vIHBsYWNlIHdvdWxkIHRoZSBpbmZyYXN0cnVjdHVyZSBhdHRlbXB0IHRvIHVw
L2Rvd24tY29udmVydCB0aGUgYWRkcmVzcy4NCg0KQWxzbywgaXQgd2lsbCBtZWFuIHRoYXQgdGhl
cmUgaXMgbm8gd2F5IGkgY2FuIG9idGFpbiBhIHJlbGF0aXZlbHkgc3RhYmxlIEFTQ0lJLXJlcHJl
c2VudGF0aW9uL2VxdWl2YWxlbnQgb2YgYW4gYWRkcmVzcy4gIEluIHRoYXQgY2FzZSwgd2hlbiBJ
IHJlLWluaXRpYXRlIGFuIGVtYWlsIHRvIGEgVVRGOCBhZGRyZXNzIEkgd291bGQgb25seSBiZSBh
YmxlIHRvIHVzZSB0aGUgVVRGOCBhZGRyZXNzIGFuZCBjYW5ub3QgYXNzdW1lIHRoYXQgdGhlIGFs
dC1hZGRyZXNzIGlzIHN0aWxsIHZhbGlkICh1bmxlc3Mgd2Ugc3BlY2lmeSB0aGF0IGluIHRoZSBz
dGFuZGFyZHMpLiAgVGhpcyBjcmVhdGVzIGFkZGl0aW9uYWwgaXNzdWUgZm9yIHNpdHVhdGlvbnMg
b2YgMy1wYXJ0eSBjb21tdW5pY2F0aW9ucyAoc2NlbmFyaW8gMi41IGluIHNjZW5hcmlvcyBkb2M6
IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZWFpLXNjZW5h
cmlvcy0wMS50eHQpLg0KDQpUbyBpbGx1c3RyYXRlIG15IHBvaW50Og0KDQpMZXRzIHNheSB0aGVy
ZSBhcmUgMyBwYXJ0aWVzOiBFQUl1c2VyMSwgRUFJdXNlcjIgYW5kIEFTQ0lJdXNlckENCg0KSUYg
YW4gQVRPTUlDIHBhcmFtZXRlciBjYW4gYmUgcGFzc2VkIGFsbG9uZzoNCg0KTGV0cyBzYXkgRUFJ
dXNlcjEgc2VuZHMgdG8gRUFJdXNlcjIgYW5kIHRoZSBwYXRoIGlzIGZ1bGx5IEVBSS1hd2FyZSwg
YW5kIHRoYXQgdGhlIEFUT01JQyBwYXJhbWV0ZXIgaXMgcGFzc2VkIGFsb25nLiAgRUFJdXNlcjIg
Y2FuIG5vdyBzdG9yZSB0aGUgaW5mb3JtYXRpb24NCg0KVEhFTiwgRUFJdXNlcjIgYWZ0ZXIgYSBm
ZXcgd2Vla3MgaXMgaW50ZXJlc3RlZCB0byBzZW5kIGVtYWlsIHRvIEVBSXVzZXIxIGFuZCBBU0NJ
SXVzZXJBIHRvZ2V0aGVyLiAgVGhlIHRyYW5zcG9ydCBFQUl1c2VyMi0+RUFJdXNlcjEgY2FuIGNv
bnRpbnVlIHRvIHVzZSBVVEY4U01UUCwgYW5kIGZvciBFQUl1c2VyMi0+QVNDSUl1c2VyQSwgYSBk
b3duZ3JhZGUgY2FuIGhhcHBlbiBieSBjb252ZXJ0aW5nIHRvIEFDRSBhZGRyZXNzIGJhc2VkIG9u
IHRoZSBBVE9NSUMgaW5mb3JtYXRpb24uICBNYWlsIGNhbiBiZSBzZW50IHN1Y2Nlc3NmdWxseS4N
Cg0KSUYgaG93ZXZlciBBVE9NSUMgcGFyYW1ldGVyIGNhbm5vdCBiZSBwYXNzZWQgYWxvbmc6DQoN
CldoZW4gRUFJdXNlcjEgc2VuZHMgdG8gRUFJdXNlcjIsIGV2ZW4gaWYgaXQgcHJvdmlkZWQgdGhl
IEFMVC1BRERSRVNTIChubyBtYXR0ZXIgd2hldGhlciBpdCB3YXMgY29udmVydGVkIHVzaW5nIGFu
IGFsZ29yaXRobSwgYmVjYXVzZSB3aXRob3V0IHRoZSBBVE9NSUMgaW5mb3JtYXRpb24gd2UgY2Fu
bm90IGFzc3VtZSBpdCBpcykNCg0KV0hFTiBFQUl1c2VyIGFmdGVyIGEgZmV3IHdlZWtzIHRyaWVz
IHRvIGluaXRpYXRlIGFuIGVtYWlsIHRvIEVBSXVzZXIxIGFuZCBBU0NJSXVzZXJBIHRvZ2V0aGVy
LCBpdCB3aWxsIG5vdCBiZSBhYmxlIHRvIHN1Y2Nlc3NmdWxseSBzZW5kIHRvIEFTQ0lJdXNlckEg
YmVjYXVzZSB0aGUgaGVhZGVyIGRvd25ncmFkZSBjb3VsZCBub3QgaGFwcGVuIGZvciB0aGUgZmll
bGQgY29udGFpbmluZyBFQUl1c2VyMSdzIGFkZHJlc3MuDQoNCkVkbW9uDQoNCg0KDQoNCi0tLS0t
IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiVG9ueSBIYW5zZW4iIDx0b255QGF0dC5j
b20+DQpUbzogIkVkbW9uIENodW5nIiA8ZWRtb25AYWZpbGlhcy5pbmZvPg0KQ2M6IDxpbWFAaWV0
Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgSnVseSAxMywgMjAwNiA0OjE4IFBNDQpTdWJqZWN0OiBS
ZTogW0VBSV0gQVRPTUlDIG9yIG5vdA0KDQoNCj4gTGV0J3Mgc2VwYXJhdGUgb3V0IHRoZSBjdXJy
ZW50IEFUT01JQyBpbXBsZW1lbnRhdGlvbiBhbmQgdGhlIEFUT01JQw0KPiBjb25jZXB0LiBUaGUg
QVRPTUlDIGNvbmNlcHQgc2F5cyB0aGF0IHRoZSBpMThuIGxvY2FscGFydCBjYW4gYmUgc2FmZWx5
DQo+IGRvd25ncmFkZWQgdG8gdGhlIGRvd25ncmFkYWJsZSBBQ0UgZm9ybS4gVGhhdCdzIGl0Lg0K
PiANCj4gRHVyaW5nIHRoZSBFQUkgbWVldGluZywgd2hlbiBwZW9wbGUgc2FpZCB0byBnZXQgcmlk
IG9mIEFUT01JQyBpbiBTTVRQLA0KPiBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhleSB3ZXJl
IHNheWluZyB0byBnZXQgcmlkIG9mIHRoZSBTTVRQIEFUT01JQw0KPiBwYXJhbWV0ZXIuIFRoZXkg
d2VyZSAqbm90KiBzYXlpbmcgYW55dGhpbmcgYWJvdXQgZ2V0dGluZyByaWQgb2YgdGhlDQo+IEFU
T01JQyBjb25jZXB0Lg0KPiANCj4gSWYgd2Ugd2FudCB0byBzdXBwb3J0IHRoZSBBVE9NSUMgY29u
Y2VwdCwgbm8gbWF0dGVyIGhvdyB3ZSBkbyBpdCwgdGhlDQo+IHNlbmRlciBuZWVkcyB0byBrbm93
IGlmIGFueSBnaXZlbiBpMThuIGxvY2FscGFydCBpcyBBVE9NSUMuIFRoaXMgZG9lc24ndA0KPiBu
ZWNlc3NhcmlseSBtZWFuIHRoYXQgYWxsIGludGVybWVkaWF0ZSBob3BzIGluIG1lc3NhZ2UgdHJh
bnNtaXNzaW9uIGFsc28NCj4gbmVlZHMgdG8ga25vdyBpdC4NCj4gDQo+IE9ydGhvZ29uYWwgdG8g
dGhpcyBjb25jZXB0IGlzIHRoYXQgb2YgYW4gYWx0ZXJuYXRlIGFzY2lpLWNvbXBhdGlibGUNCj4g
YWRkcmVzcyB0aGF0IHdvdWxkIGJlIHVzZWQgaWYgdGhlIGkxOG4gbG9jYWxwYXJ0IGNhbm5vdCBi
ZSB1c2VkLg0KPiANCj4gVGhlIEFUT01JQyBpbmZvcm1hdGlvbiBwcm92aWRlcyBhIHdheSB0byBp
bmRpY2F0ZSB0aGF0IHRoZSBkb3duZ3JhZGFibGUNCj4gQUNFIGZvcm0gb2YgdGhlIGkxOG4gYWRk
cmVzcyBjYW4gYmUgdXNlZCBhcyB0aGUgYWx0ZXJuYXRlIGFkZHJlc3MuDQo+IA0KPiBUaGUgc2lu
Z2xlIGJpdCBvZiBrbm93bGVkZ2UgYWJvdXQgd2hldGhlciBhbiBpMThuIGxvY2FscGFydCBpcyBB
VE9NSUMNCj4gY2FuIGJlIHVzZWQgYW5kIHBhc3NlZCBpbiBzZXZlcmFsIHdheXMuIFRoZSBjdXJy
ZW50IHNwZWNzIGNhbGwgZm9yIHRoZQ0KPiBNVUEgdG8gZG8gdGhlIGZvbGxvd2luZyBwcm9jZXNz
aW5nOg0KPiANCj4gbXVhOiBpZiBpMThuIGFkZHJlc3MgaXMgQVRPTUlDDQo+IG11YTogcGFzcyBp
MThuIGFkZHJlc3MgYW5kIGluZm8gc2F5aW5nIGFkZHJlc3MgaXMgQVRPTUlDDQo+IG11YTogZWxz
ZSBpZiB0aGVyZSBpcyBhbiBhbHRlcm5hdGUgQUNFIGFkZHJlc3MNCj4gbXVhOiBwYXNzIGkxOG4g
YWRkcmVzcyBhbmQgYWx0ZXJuYXRlIEFDRSBhZGRyZXNzDQo+IG11YTogZWxzZQ0KPiBtdWE6IHBh
c3MgaTE4biBhZGRyZXNzDQo+IA0KPiBXaGVuIGFuIE1UQSBoaXRzIGFub3RoZXIgTVRBIHRoYXQg
aXMgbm90IGkxOG4gY29tcGF0aWJsZSwgaXQgbXVzdCBkbyB0aGUNCj4gZm9sbG93aW5nIHByb2Nl
c3Npbmc6DQo+IA0KPiBtdGE6IGlmIGFkZHJlc3MgaXMgQVRPTUlDDQo+IG10YTogZG93bmdyYWRl
IG1lc3NhZ2UgaGVhZGVycyBhbmQgYm9keQ0KPiBtdGE6IGNvbnZlcnQgaTE4biBhZGRyZXNzIHRv
IEFDRQ0KPiBtdGE6IHVzZSBjb252ZXJ0ZWQgYWRkcmVzcw0KPiBtdGE6IGVsc2UgaWYgdGhlcmUg
aXMgYW4gYWx0ZXJuYXRlIEFDRSBhZGRyZXNzDQo+IG10YTogZG93bmdyYWRlIG1lc3NhZ2UgaGVh
ZGVycyBhbmQgYm9keQ0KPiBtdGE6IHVzZSBhbHRlcm5hdGUgYWRkcmVzcw0KPiBtdGE6IGVsc2UN
Cj4gbXRhOiBib3VuY2UgdGhlIG1lc3NhZ2UNCj4gDQo+IENvbnNpZGVyIHRoZSBmb2xsb3dpbmcg
YWx0ZXJuYXRpdmUgd2hlcmUgdGhlIE1VQSB1c2VzIHRoZSBrbm93bGVkZ2UgdGhhdA0KPiB0aGUg
aTE4biBhZGRyZXNzIGlzIEFUT01JQyBhbmQgdXNlcyB0aGF0IGtub3dsZWRnZSB1cCBmcm9udCB0
byBzZXQgdGhlDQo+IGFsdGVybmF0ZSBhZGRyZXNzLg0KPiANCj4gbXVhOiBpZiBpMThuIGFkZHJl
c3MgaXMgQVRPTUlDDQo+IG11YTogcGFzcyBpMThuIGFkZHJlc3MgYW5kIGdlbmVyYXRlZCBBQ0Ug
YWRkcmVzcyBhcyBhbHRlcm5hdGUNCj4gbXVhOiBlbHNlIGlmIHRoZXJlIGlzIGFuIGFsdGVybmF0
ZSBBQ0UgYWRkcmVzcw0KPiBtdWE6IHBhc3MgaTE4biBhZGRyZXNzIGFuZCBhbHRlcm5hdGUgQUNF
IGFkZHJlc3MNCj4gbXVhOiBlbHNlDQo+IG11YTogcGFzcyBpMThuIGFkZHJlc3MNCj4gDQo+IE5v
dyBsb29rIGF0IGhvdyBtdWNoIHNpbXBsZXIgdGhlIE1UQSBiZWNvbWVzOg0KPiANCj4gbXRhOiBp
ZiB0aGVyZSBpcyBhbiBhbHRlcm5hdGUgQUNFIGFkZHJlc3MNCj4gbXRhOiBkb3duZ3JhZGUgbWVz
c2FnZSBoZWFkZXJzIGFuZCBib2R5DQo+IG10YTogdXNlIGFsdGVybmF0ZSBhZGRyZXNzDQo+IG10
YTogZWxzZQ0KPiBtdGE6IGJvdW5jZSB0aGUgbWVzc2FnZSANCj4gDQo+IER1cmluZyB0aGUgRUFJ
IG1lZXRpbmcsIHdoZW4gcGVvcGxlIHNhaWQgdG8gZ2V0IHJpZCBvZiBBVE9NSUMgaW4gU01UUCwN
Cj4gbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZXkgd2VyZSBzYXlpbmcgdG8gZ2V0IHJpZCBv
ZiB0aGUgU01UUCBBVE9NSUMNCj4gcGFyYW1ldGVyLCBidXQgbm90IHRoZSBBVE9NSUMgY29uY2Vw
dC4NCj4gDQo+IFRvbnkgSGFuc2VuDQo+IHRvbnlAYXR0LmNvbQ0KPiANCj4gRWRtb24gQ2h1bmcg
d3JvdGU6DQo+PiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPj4gRnJvbTogIlRvbnkg
RmluY2giIDxkb3RAZG90YXQuYXQ+DQo+Pj4+IElmIGFuIGFkZHJlc3MgaXMgZGVzaWduYXRlZCBh
cyBBVE9NSUMsIHRoZW4gSSB3b3VsZCBzdG9yZSB0aGF0DQo+Pj4+IGluZm9ybWF0aW9uIGNhdXNl
IEkga25vdyB0aGF0IGl0IGNvdWxkIGJlIHVzZWQgaW4gdGhlIGZ1dHVyZS4gIElmIGFuDQo+Pj4+
IGFsdC1hZGRyZXNzIGlzIHByb3ZpZGVkLCB0aGVuIEkgd291bGQgcHJvYmFibHkgaGF2ZSB0byBk
aXNjYXJkIGl0IGNhdXNlDQo+Pj4+IEkgY2Fubm90IGRldGVybWluZSB3aGV0aGVyIEkgY2FuIHVz
ZSB0aGF0IHNhbWUgYWx0LWFkZHIgaW4gdGhlIGZ1dHVyZS4NCj4+PiBJZiB5b3UgY2FuJ3QgdHJ1
c3QgdGhlIGFsdC1hZGRyZXNzIHRoZW4gc3VyZWx5IHlvdSBjYW4ndCB0cnVzdCB0aGUgdXRmOA0K
Pj4+IGFkZHJlc3MgZWl0aGVyLiBPciBpbiBvdGhlciB3b3JkcywgSSBkb24ndCB0aGluayB0aGlz
IGtpbmQgb2Ygb3BlcmF0aW9uYWwNCj4+PiBzdGFiaWxpdHkgaXNzdWUgaXMgcmVsZXZhbnQuIFlv
dSBjYW4gYWx3YXlzIHZlcmlmeSB0aGF0IHRoZSBhbHQtYWRkcmVzcyBpcw0KPj4+IHRoZSBhbGdv
cml0aG1pY2FsbHktZG93bmdyYWRlZCBmb3JtIG9mIHRoZSB1dGY4IGFkZHJlc3MgYnkgZG9pbmcg
dGhlDQo+Pj4gZG93bmdyYWRlIGFuZCBjb21wYXJpbmcuDQo+PiANCj4+IEFMVC1BRERSRVNTIGlz
IG5vdCB0aGUgc2FtZSBhcyBBVE9NSUMuICBBTFQtQUREUkVTUyBjYW4gYmUgYW55IEFTQ0lJIGFk
ZHJlc3MuICBFLmcuICI8Y2hpbmVzZU5hbWU+QGRvbWFpbi50bGQiIGNhbiBoYXZlIGFuIEFMVC1B
RERSPSJhYmNAZGVmLm9yZyIgKG5vdGUgbm90IGV2ZW4gdGhlIGRvbWFpbiBuZWVkcyB0byBtYXRj
aCkuICBUaGF0IGlzIHdoeSB0aGUgYWx0LWFkZHJlc3MgY2Fubm90IGJlIGEgInN0YWJsZSIgZ2x1
ZSB0byB0aGUgVVRGOCBhZGRyZXNzLiAgVGhlIFVURjggYWRkcmVzcyBjYW4gYmUgZnVsbHkgdHJ1
c3RlZCBzbyBjYW4gYW4gQVRPTUlDIGFkZHJlc3MgKHdlbGwgdW5sZXNzIHRoZSBzdGFuZGFyZCB0
cmFuc2Zvcm1hdGlvbiBhbGdvcml0aG0gaXMgY2hhbmdlZC4uLiBidXQgdGhhdCB3b3VsZCBiZSBh
IGRpZmZlcmVudCBpc3N1ZS4uLiBtb3JlIG9uIHZlcnNpb25pbmcpLg0KPj4gDQo+Pj4gSSdtIHNl
cmlvdXNseSB3b3JyaWVkIGFib3V0IHRoZSB1c2VyLWludGVyZmFjZSBpbXBsaWNhdGlvbnMgb2Yg
bm9uLWF0b21pYw0KPj4+IGFkZHJlc3Nlcy4NCj4+IA0KPj4gV2VsbCB3aXRob3V0IHRoZSBBVE9N
SUMgcGFyYW1ldGVyIGF0IGFsbCB0aGVyZSBpcyBubyB3YXkgdG8gc2F5IHRoYXQgYW4gYWRkcmVz
cyBpcyBhdG9taWMuLi4gYW5kIGJhc2VkIG9uIHRoZSBjdXJyZW50IHNldCBvZiBzcGVjaWZpY2F0
aW9ucywgTm9uLWF0b21pYyBpcyB0aGUgZGVmYXVsdC4NCj4+IA0KPj4gRWRtb24NCj4+IA0KPj4g
DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj4+IElNQSBtYWlsaW5nIGxpc3QNCj4+IElNQUBpZXRmLm9y
Zw0KPj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1hDQo+IA0KPg==



--===============1733595408==
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

--===============1733595408==--



From ima-bounces@ietf.org Sat Jul 15 15:42:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G1q1x-0007VK-Qk; Sat, 15 Jul 2006 15:42:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G1q1w-0007VF-8w
	for ima@ietf.org; Sat, 15 Jul 2006 15:42:24 -0400
Received: from lon-mail-1.gradwell.net ([193.111.201.125])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1q1t-00067Q-QN
	for ima@ietf.org; Sat, 15 Jul 2006 15:42: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.226) id
	44b9451b.7097.1628 for ima@ietf.org; Sat, 15 Jul 2006 20:42: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 k6FJgFNj022676
	for <ima@ietf.org>; Sat, 15 Jul 2006 20:42:17 +0100 (BST)
To: ima@ietf.org
Subject: Re: ***SPAM-3*** Re: [EAI] ATOMIC or not
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
	<020101c6a52f$ca3f2660$b30110ac@edmontr3>
	<p06300012c0d9e269fecb@[142.131.134.210]>
	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>
	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>
	<03c201c6a607$a68936b0$b30110ac@edmontr3>
	<44B6AA85.2040601@att.com>
	<066901c6a7b7$26e121a0$b30110ac@edmontr3>
Message-ID: <op.tcqw0pff6hl8nm@clerew.man.ac.uk>
Date: Sat, 15 Jul 2006 20:42:15 +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: <066901c6a7b7$26e121a0$b30110ac@edmontr3>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
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 Sat, 15 Jul 2006 03:32:58 +0100, Edmon Chung <edmonchung@gmail.com>  
wrote:

> However, my point is if "ATOMIC" as a parameter is never transported,  
> then there is no need for a standardized way to create an ACE  
> representation of a UT8 address.  Because each MUA can use any method of  
> transformation to an alt-address they want and the protocol would still  
> function without any problem.  Because in no place would the  
> infrastructure attempt to up/down-convert the address.

Hold on a minute! Suppose, as you say, no atomic parameter is transported.  
If you make such a rule, then you also have to rule whether the behaviour  
then becomes what used to be "atomic=y" or whether it becomes what used to  
be "atomic=n".

I think those of us who are suggesting that the atomic parameter is not  
needed are assuming that behaviour would then become what you get now with  
"atomic=y". In that case, you very much do require a standardised  
downgrade method, and it is essential that it be a reversible method.

OTOH, you seem to be assuming the exact opposite - that the new behaviour  
would correspond to the old "atomic=n", and that leads to all sorts of  
unacceptable consequences, as you have demonstrated.

-- 
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 Sat Jul 15 23:04:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G1wvY-0007iR-Cf; Sat, 15 Jul 2006 23:04:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G1wvX-0007iL-01
	for ima@ietf.org; Sat, 15 Jul 2006 23:04:15 -0400
Received: from sniper.icu.ac.kr ([210.107.128.51])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G1wvT-0007Hr-Op
	for ima@ietf.org; Sat, 15 Jul 2006 23:04:14 -0400
Received: (snipe 17923 invoked by uid 0); 16 Jul 2006 12:04:11 +0900
Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.058245
	secs); 
Received: from unknown (HELO ?218.36.241.167?) (ZEL?own@218.36.241.167)
	by unknown with SMTP; 16 Jul 2006 12:04:11 +0900
X-RCPTTO: edmon@afilias.info,
	ima@ietf.org
Message-ID: <44B9ACA7.2030402@icu.ac.kr>
Date: Sun, 16 Jul 2006 12:04:07 +0900
From: Yangwoo Ko <newcat@icu.ac.kr>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Edmon Chung <edmon@afilias.info>
Subject: Re: [EAI] ATOMIC or not
References: <011201c6a513$5636a020$b30110ac@edmontr3>	<p0630000bc0d9b50c344b@[142.131.134.210]>	<020101c6a52f$ca3f2660$b30110ac@edmontr3>	<p06300012c0d9e269fecb@[142.131.134.210]>	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>	<03c201c6a607$a68936b0$b30110ac@edmontr3>	<44B6AA85.2040601@att.com>
	<066901c6a7b7$26e121a0$b30110ac@edmontr3>
In-Reply-To: <066901c6a7b7$26e121a0$b30110ac@edmontr3>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba
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


Dear Edmon,

I agree with you that having ATOMIC as a flag is not
equivalent to transporting algorithmically encoded
all-ASCII address in an ALT-ADDR slot if;

* we fail to find almost-perfect "in-band" signaling
for EAI suchas "xn--" in IDNA

* and hence it is not safe-to-upgrade

Is this your point?

Regards

Edmon Chung wrote:
> I understand your analysis and the approach suggested.  Not saying it does not work...
> 
> However, my point is if "ATOMIC" as a parameter is never transported, then there is no need for a standardized way to create an ACE representation of a UT8 address.  Because each MUA can use any method of transformation to an alt-address they want and the protocol would still function without any problem.  Because in no place would the infrastructure attempt to up/down-convert the address.
> 
> Also, it will mean that there is no way i can obtain a relatively stable ASCII-representation/equivalent of an address.  In that case, when I re-initiate an email to a UTF8 address I would only be able to use the UTF8 address and cannot assume that the alt-address is still valid (unless we specify that in the standards).  This creates additional issue for situations of 3-party communications (scenario 2.5 in scenarios doc: http://www.ietf.org/internet-drafts/draft-ietf-eai-scenarios-01.txt).
> 
> To illustrate my point:
> 
> Lets say there are 3 parties: EAIuser1, EAIuser2 and ASCIIuserA
> 
> IF an ATOMIC parameter can be passed allong:
> 
> Lets say EAIuser1 sends to EAIuser2 and the path is fully EAI-aware, and that the ATOMIC parameter is passed along.  EAIuser2 can now store the information
> 
> THEN, EAIuser2 after a few weeks is interested to send email to EAIuser1 and ASCIIuserA together.  The transport EAIuser2->EAIuser1 can continue to use UTF8SMTP, and for EAIuser2->ASCIIuserA, a downgrade can happen by converting to ACE address based on the ATOMIC information.  Mail can be sent successfully.
> 
> IF however ATOMIC parameter cannot be passed along:
> 
> When EAIuser1 sends to EAIuser2, even if it provided the ALT-ADDRESS (no matter whether it was converted using an algorithm, because without the ATOMIC information we cannot assume it is)
> 
> WHEN EAIuser after a few weeks tries to initiate an email to EAIuser1 and ASCIIuserA together, it will not be able to successfully send to ASCIIuserA because the header downgrade could not happen for the field containing EAIuser1's address.
> 
> Edmon
> 
> 
> 
> 
> ----- Original Message ----- 
> From: "Tony Hansen" <tony@att.com>
> To: "Edmon Chung" <edmon@afilias.info>
> Cc: <ima@ietf.org>
> Sent: Thursday, July 13, 2006 4:18 PM
> Subject: Re: [EAI] ATOMIC or not
> 
> 
>> Let's separate out the current ATOMIC implementation and the ATOMIC
>> concept. The ATOMIC concept says that the i18n localpart can be safely
>> downgraded to the downgradable ACE form. That's it.
>>
>> During the EAI meeting, when people said to get rid of ATOMIC in SMTP,
>> my understanding is that they were saying to get rid of the SMTP ATOMIC
>> parameter. They were *not* saying anything about getting rid of the
>> ATOMIC concept.
>>
>> If we want to support the ATOMIC concept, no matter how we do it, the
>> sender needs to know if any given i18n localpart is ATOMIC. This doesn't
>> necessarily mean that all intermediate hops in message transmission also
>> needs to know it.
>>
>> Orthogonal to this concept is that of an alternate ascii-compatible
>> address that would be used if the i18n localpart cannot be used.
>>
>> The ATOMIC information provides a way to indicate that the downgradable
>> ACE form of the i18n address can be used as the alternate address.
>>
>> The single bit of knowledge about whether an i18n localpart is ATOMIC
>> can be used and passed in several ways. The current specs call for the
>> MUA to do the following processing:
>>
>> mua: if i18n address is ATOMIC
>> mua: pass i18n address and info saying address is ATOMIC
>> mua: else if there is an alternate ACE address
>> mua: pass i18n address and alternate ACE address
>> mua: else
>> mua: pass i18n address
>>
>> When an MTA hits another MTA that is not i18n compatible, it must do the
>> following processing:
>>
>> mta: if address is ATOMIC
>> mta: downgrade message headers and body
>> mta: convert i18n address to ACE
>> mta: use converted address
>> mta: else if there is an alternate ACE address
>> mta: downgrade message headers and body
>> mta: use alternate address
>> mta: else
>> mta: bounce the message
>>
>> Consider the following alternative where the MUA uses the knowledge that
>> the i18n address is ATOMIC and uses that knowledge up front to set the
>> alternate address.
>>
>> mua: if i18n address is ATOMIC
>> mua: pass i18n address and generated ACE address as alternate
>> mua: else if there is an alternate ACE address
>> mua: pass i18n address and alternate ACE address
>> mua: else
>> mua: pass i18n address
>>
>> Now look at how much simpler the MTA becomes:
>>
>> mta: if there is an alternate ACE address
>> mta: downgrade message headers and body
>> mta: use alternate address
>> mta: else
>> mta: bounce the message 
>>
>> During the EAI meeting, when people said to get rid of ATOMIC in SMTP,
>> my understanding is that they were saying to get rid of the SMTP ATOMIC
>> parameter, but not the ATOMIC concept.
>>
>> Tony Hansen
>> tony@att.com
>>
>> Edmon Chung wrote:
>>> ----- Original Message ----- 
>>> From: "Tony Finch" <dot@dotat.at>
>>>>> If an address is designated as ATOMIC, then I would store that
>>>>> information cause I know that it could be used in the future.  If an
>>>>> alt-address is provided, then I would probably have to discard it cause
>>>>> I cannot determine whether I can use that same alt-addr in the future.
>>>> If you can't trust the alt-address then surely you can't trust the utf8
>>>> address either. Or in other words, I don't think this kind of operational
>>>> stability issue is relevant. You can always verify that the alt-address is
>>>> the algorithmically-downgraded form of the utf8 address by doing the
>>>> downgrade and comparing.
>>> ALT-ADDRESS is not the same as ATOMIC.  ALT-ADDRESS can be any ASCII address.  E.g. "<chineseName>@domain.tld" can have an ALT-ADDR="abc@def.org" (note not even the domain needs to match).  That is why the alt-address cannot be a "stable" glue to the UTF8 address.  The UTF8 address can be fully trusted so can an ATOMIC address (well unless the standard transformation algorithm is changed... but that would be a different issue... more on versioning).
>>>
>>>> I'm seriously worried about the user-interface implications of non-atomic
>>>> addresses.
>>> Well without the ATOMIC parameter at all there is no way to say that an address is atomic... and based on the current set of specifications, Non-atomic is the default.
>>>
>>> Edmon
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> IMA mailing list
>>> IMA@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ima
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www1.ietf.org/mailman/listinfo/ima


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



From ima-bounces@ietf.org Sat Jul 15 23:26:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G1xHM-0004u8-6q; Sat, 15 Jul 2006 23:26:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G1xHK-0004s0-RW
	for ima@ietf.org; Sat, 15 Jul 2006 23:26:46 -0400
Received: from py-out-1112.google.com ([64.233.166.177])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1xHK-0008Fy-5E
	for ima@ietf.org; Sat, 15 Jul 2006 23:26:46 -0400
Received: by py-out-1112.google.com with SMTP id m51so1059912pye
	for <ima@ietf.org>; Sat, 15 Jul 2006 20:26:45 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:reply-to:to:references:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole:from;
	b=bUzhtNxcExjxI9ge6ceoU/GxyZN8upqJye90zn5S1wWg9Wn/cedwZCuy+Ie58nILvhu8QtyouoautWhYGighzfeQotVA7SkjlPSEHYVJs9dOdAUn4VXApT/5BoN3+GykYabfhercoYblpRDFISpUXm7ueAdm67RDw2WyDx8Z308=
Received: by 10.35.111.14 with SMTP id o14mr1849397pym;
	Sat, 15 Jul 2006 20:26:45 -0700 (PDT)
Received: from edmontr3 ( [203.198.249.184])
	by mx.gmail.com with ESMTP id f19sm129633pyf.2006.07.15.20.26.43;
	Sat, 15 Jul 2006 20:26:45 -0700 (PDT)
Message-ID: <06e601c6a887$a815a540$b30110ac@edmontr3>
To: <ima@ietf.org>
References: <011201c6a513$5636a020$b30110ac@edmontr3>	<p0630000bc0d9b50c344b@[142.131.134.210]>	<020101c6a52f$ca3f2660$b30110ac@edmontr3>	<p06300012c0d9e269fecb@[142.131.134.210]>	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>	<03c201c6a607$a68936b0$b30110ac@edmontr3>	<44B6AA85.2040601@att.com>
	<066901c6a7b7$26e121a0$b30110ac@edmontr3>
	<44B9ACA7.2030402@icu.ac.kr>
Subject: Re: [EAI] ATOMIC or not
Date: Sat, 15 Jul 2006 23:26:18 -0400
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
From: Edmon Chung <edmonchung@gmail.com>
X-Spam-Score: 2.4 (++)
X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Edmon Chung <edmon@afilias.info>
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>
Content-Type: multipart/mixed; boundary="===============0335457484=="
Errors-To: ima-bounces@ietf.org

--===============0335457484==
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

TXkgbWFpbiBwb2ludHMgYXJlIEkgdGhpbms6DQoNCjEuIGlmIHdlIHdhbnQgdG8gaGF2ZSBhIHN0
YW5kYXJkIEFDRSB0cmFuc2Zvcm1hdGlvbiBmb3IgbG9jYWwgcGFydCwgdGhlbiB3ZSBzaG91bGQg
a2VlcCB0aGUgQVRPTUlDIHBhcmFtZXRlciAob3Igc29tZSB3aGF5IHRvIGNvbnZleSB0aGF0IG1l
c3NhZ2UpIHNvIHRoYXQgd2UgY2FuIGFjdHVhbGx5IG1ha2UgdXNlIG9mIHRoZSBzdGFuZGFyZCBh
bGdvcml0aG0gdG8gYXNzaXN0IGluIHRyYW5zcG9ydCB0byBBU0NJSSBvbmx5IHVzZXJzLg0KDQoy
LiBpZiB3ZSBkZWNpZGUgbm90IHRvIHRyYW5zcG9ydCB0aGUgQVRPTUlDIHBhcmFtZXRlciBzb21l
IHdheSAoaW5jbHVkaW5nIHNwZWNpZnlpbmcgaXQgYXMgZGVmYXVsdCksIHRoZW4gdGhlcmUgaXMg
bm8gcG9pbnQgaGF2aW5nIGEgc3RhbmRhcmQgQUNFIHRyYW5zZm9ybWF0aW9uLCBiZWNhdXNlIGV2
ZXJ5b25lIGNhbiBoYXZlIHRoZWlyIG93biBtZWNoYW5pc20gYW5kIGl0IHdvdWxkIHdvcmsgdGhl
IHNhbWUuDQoNCjMuIEkgYmVsaWV2ZSB0aGVyZSBtYXkgYmUgc29tZSBiZW5lZml0IHRvIGhhdmUg
YSBzdGFuZGFyZCBBQ0UgdHJhbnNmb3JtYXRpb24sIGJ1dCBhbSBub3Qgc3VyZS4gIEkgdGhpbmsg
d2UgbmVlZCBmdXJ0aGVyIGV4cGxvcmF0aW9uLCBhIGNvdXBsZSBvZiBwZW9wbGUgaGF2ZSBhbHJl
YWR5IHN1Z2dlc3RlZCB0aGF0IHRoZXJlIG1heSBiZSBwb3NzaWJpbGl0eSB0byBkZXNpZ24gYSBz
dGFuZGFyZCB0d28td2F5IGNvbnZlcnRpYmxlIEFDRSBmb3IgbG9jYWwgcGFydC4uLiBzbyBwZXJo
YXBzIGlmIHdlIGhlYXIgbW9yZSB0aGVyZS4uLg0KDQo0LiBUaGVyZWZvcmUgSSB0aGluayBpdCBt
YXkgYmUgcHJlbWF0dXJlIHRvIHdyaXRlIG9mZiB0aGUgYXRvbWljIHBhcmFtZXRlci4NCg0KRWRt
b24NCg0KDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJZYW5nd29v
IEtvIiA8bmV3Y2F0QGljdS5hYy5rcj4NClRvOiAiRWRtb24gQ2h1bmciIDxlZG1vbkBhZmlsaWFz
LmluZm8+DQpDYzogPGltYUBpZXRmLm9yZz4NClNlbnQ6IFNhdHVyZGF5LCBKdWx5IDE1LCAyMDA2
IDExOjA0IFBNDQpTdWJqZWN0OiBSZTogW0VBSV0gQVRPTUlDIG9yIG5vdA0KDQoNCj4gDQo+IERl
YXIgRWRtb24sDQo+IA0KPiBJIGFncmVlIHdpdGggeW91IHRoYXQgaGF2aW5nIEFUT01JQyBhcyBh
IGZsYWcgaXMgbm90DQo+IGVxdWl2YWxlbnQgdG8gdHJhbnNwb3J0aW5nIGFsZ29yaXRobWljYWxs
eSBlbmNvZGVkDQo+IGFsbC1BU0NJSSBhZGRyZXNzIGluIGFuIEFMVC1BRERSIHNsb3QgaWY7DQo+
IA0KPiAqIHdlIGZhaWwgdG8gZmluZCBhbG1vc3QtcGVyZmVjdCAiaW4tYmFuZCIgc2lnbmFsaW5n
DQo+IGZvciBFQUkgc3VjaGFzICJ4bi0tIiBpbiBJRE5BDQo+IA0KPiAqIGFuZCBoZW5jZSBpdCBp
cyBub3Qgc2FmZS10by11cGdyYWRlDQo+IA0KPiBJcyB0aGlzIHlvdXIgcG9pbnQ/DQo+IA0KPiBS
ZWdhcmRzDQo+IA0KPiBFZG1vbiBDaHVuZyB3cm90ZToNCj4+IEkgdW5kZXJzdGFuZCB5b3VyIGFu
YWx5c2lzIGFuZCB0aGUgYXBwcm9hY2ggc3VnZ2VzdGVkLiAgTm90IHNheWluZyBpdCBkb2VzIG5v
dCB3b3JrLi4uDQo+PiANCj4+IEhvd2V2ZXIsIG15IHBvaW50IGlzIGlmICJBVE9NSUMiIGFzIGEg
cGFyYW1ldGVyIGlzIG5ldmVyIHRyYW5zcG9ydGVkLCB0aGVuIHRoZXJlIGlzIG5vIG5lZWQgZm9y
IGEgc3RhbmRhcmRpemVkIHdheSB0byBjcmVhdGUgYW4gQUNFIHJlcHJlc2VudGF0aW9uIG9mIGEg
VVQ4IGFkZHJlc3MuICBCZWNhdXNlIGVhY2ggTVVBIGNhbiB1c2UgYW55IG1ldGhvZCBvZiB0cmFu
c2Zvcm1hdGlvbiB0byBhbiBhbHQtYWRkcmVzcyB0aGV5IHdhbnQgYW5kIHRoZSBwcm90b2NvbCB3
b3VsZCBzdGlsbCBmdW5jdGlvbiB3aXRob3V0IGFueSBwcm9ibGVtLiAgQmVjYXVzZSBpbiBubyBw
bGFjZSB3b3VsZCB0aGUgaW5mcmFzdHJ1Y3R1cmUgYXR0ZW1wdCB0byB1cC9kb3duLWNvbnZlcnQg
dGhlIGFkZHJlc3MuDQo+PiANCj4+IEFsc28sIGl0IHdpbGwgbWVhbiB0aGF0IHRoZXJlIGlzIG5v
IHdheSBpIGNhbiBvYnRhaW4gYSByZWxhdGl2ZWx5IHN0YWJsZSBBU0NJSS1yZXByZXNlbnRhdGlv
bi9lcXVpdmFsZW50IG9mIGFuIGFkZHJlc3MuICBJbiB0aGF0IGNhc2UsIHdoZW4gSSByZS1pbml0
aWF0ZSBhbiBlbWFpbCB0byBhIFVURjggYWRkcmVzcyBJIHdvdWxkIG9ubHkgYmUgYWJsZSB0byB1
c2UgdGhlIFVURjggYWRkcmVzcyBhbmQgY2Fubm90IGFzc3VtZSB0aGF0IHRoZSBhbHQtYWRkcmVz
cyBpcyBzdGlsbCB2YWxpZCAodW5sZXNzIHdlIHNwZWNpZnkgdGhhdCBpbiB0aGUgc3RhbmRhcmRz
KS4gIFRoaXMgY3JlYXRlcyBhZGRpdGlvbmFsIGlzc3VlIGZvciBzaXR1YXRpb25zIG9mIDMtcGFy
dHkgY29tbXVuaWNhdGlvbnMgKHNjZW5hcmlvIDIuNSBpbiBzY2VuYXJpb3MgZG9jOiBodHRwOi8v
d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWVhaS1zY2VuYXJpb3MtMDEu
dHh0KS4NCj4+IA0KPj4gVG8gaWxsdXN0cmF0ZSBteSBwb2ludDoNCj4+IA0KPj4gTGV0cyBzYXkg
dGhlcmUgYXJlIDMgcGFydGllczogRUFJdXNlcjEsIEVBSXVzZXIyIGFuZCBBU0NJSXVzZXJBDQo+
PiANCj4+IElGIGFuIEFUT01JQyBwYXJhbWV0ZXIgY2FuIGJlIHBhc3NlZCBhbGxvbmc6DQo+PiAN
Cj4+IExldHMgc2F5IEVBSXVzZXIxIHNlbmRzIHRvIEVBSXVzZXIyIGFuZCB0aGUgcGF0aCBpcyBm
dWxseSBFQUktYXdhcmUsIGFuZCB0aGF0IHRoZSBBVE9NSUMgcGFyYW1ldGVyIGlzIHBhc3NlZCBh
bG9uZy4gIEVBSXVzZXIyIGNhbiBub3cgc3RvcmUgdGhlIGluZm9ybWF0aW9uDQo+PiANCj4+IFRI
RU4sIEVBSXVzZXIyIGFmdGVyIGEgZmV3IHdlZWtzIGlzIGludGVyZXN0ZWQgdG8gc2VuZCBlbWFp
bCB0byBFQUl1c2VyMSBhbmQgQVNDSUl1c2VyQSB0b2dldGhlci4gIFRoZSB0cmFuc3BvcnQgRUFJ
dXNlcjItPkVBSXVzZXIxIGNhbiBjb250aW51ZSB0byB1c2UgVVRGOFNNVFAsIGFuZCBmb3IgRUFJ
dXNlcjItPkFTQ0lJdXNlckEsIGEgZG93bmdyYWRlIGNhbiBoYXBwZW4gYnkgY29udmVydGluZyB0
byBBQ0UgYWRkcmVzcyBiYXNlZCBvbiB0aGUgQVRPTUlDIGluZm9ybWF0aW9uLiAgTWFpbCBjYW4g
YmUgc2VudCBzdWNjZXNzZnVsbHkuDQo+PiANCj4+IElGIGhvd2V2ZXIgQVRPTUlDIHBhcmFtZXRl
ciBjYW5ub3QgYmUgcGFzc2VkIGFsb25nOg0KPj4gDQo+PiBXaGVuIEVBSXVzZXIxIHNlbmRzIHRv
IEVBSXVzZXIyLCBldmVuIGlmIGl0IHByb3ZpZGVkIHRoZSBBTFQtQUREUkVTUyAobm8gbWF0dGVy
IHdoZXRoZXIgaXQgd2FzIGNvbnZlcnRlZCB1c2luZyBhbiBhbGdvcml0aG0sIGJlY2F1c2Ugd2l0
aG91dCB0aGUgQVRPTUlDIGluZm9ybWF0aW9uIHdlIGNhbm5vdCBhc3N1bWUgaXQgaXMpDQo+PiAN
Cj4+IFdIRU4gRUFJdXNlciBhZnRlciBhIGZldyB3ZWVrcyB0cmllcyB0byBpbml0aWF0ZSBhbiBl
bWFpbCB0byBFQUl1c2VyMSBhbmQgQVNDSUl1c2VyQSB0b2dldGhlciwgaXQgd2lsbCBub3QgYmUg
YWJsZSB0byBzdWNjZXNzZnVsbHkgc2VuZCB0byBBU0NJSXVzZXJBIGJlY2F1c2UgdGhlIGhlYWRl
ciBkb3duZ3JhZGUgY291bGQgbm90IGhhcHBlbiBmb3IgdGhlIGZpZWxkIGNvbnRhaW5pbmcgRUFJ
dXNlcjEncyBhZGRyZXNzLg0KPj4gDQo+PiBFZG1vbg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiAt
LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPj4gRnJvbTogIlRvbnkgSGFuc2VuIiA8dG9u
eUBhdHQuY29tPg0KPj4gVG86ICJFZG1vbiBDaHVuZyIgPGVkbW9uQGFmaWxpYXMuaW5mbz4NCj4+
IENjOiA8aW1hQGlldGYub3JnPg0KPj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTMsIDIwMDYgNDox
OCBQTQ0KPj4gU3ViamVjdDogUmU6IFtFQUldIEFUT01JQyBvciBub3QNCj4+IA0KPj4gDQo+Pj4g
TGV0J3Mgc2VwYXJhdGUgb3V0IHRoZSBjdXJyZW50IEFUT01JQyBpbXBsZW1lbnRhdGlvbiBhbmQg
dGhlIEFUT01JQw0KPj4+IGNvbmNlcHQuIFRoZSBBVE9NSUMgY29uY2VwdCBzYXlzIHRoYXQgdGhl
IGkxOG4gbG9jYWxwYXJ0IGNhbiBiZSBzYWZlbHkNCj4+PiBkb3duZ3JhZGVkIHRvIHRoZSBkb3du
Z3JhZGFibGUgQUNFIGZvcm0uIFRoYXQncyBpdC4NCj4+Pg0KPj4+IER1cmluZyB0aGUgRUFJIG1l
ZXRpbmcsIHdoZW4gcGVvcGxlIHNhaWQgdG8gZ2V0IHJpZCBvZiBBVE9NSUMgaW4gU01UUCwNCj4+
PiBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhleSB3ZXJlIHNheWluZyB0byBnZXQgcmlkIG9m
IHRoZSBTTVRQIEFUT01JQw0KPj4+IHBhcmFtZXRlci4gVGhleSB3ZXJlICpub3QqIHNheWluZyBh
bnl0aGluZyBhYm91dCBnZXR0aW5nIHJpZCBvZiB0aGUNCj4+PiBBVE9NSUMgY29uY2VwdC4NCj4+
Pg0KPj4+IElmIHdlIHdhbnQgdG8gc3VwcG9ydCB0aGUgQVRPTUlDIGNvbmNlcHQsIG5vIG1hdHRl
ciBob3cgd2UgZG8gaXQsIHRoZQ0KPj4+IHNlbmRlciBuZWVkcyB0byBrbm93IGlmIGFueSBnaXZl
biBpMThuIGxvY2FscGFydCBpcyBBVE9NSUMuIFRoaXMgZG9lc24ndA0KPj4+IG5lY2Vzc2FyaWx5
IG1lYW4gdGhhdCBhbGwgaW50ZXJtZWRpYXRlIGhvcHMgaW4gbWVzc2FnZSB0cmFuc21pc3Npb24g
YWxzbw0KPj4+IG5lZWRzIHRvIGtub3cgaXQuDQo+Pj4NCj4+PiBPcnRob2dvbmFsIHRvIHRoaXMg
Y29uY2VwdCBpcyB0aGF0IG9mIGFuIGFsdGVybmF0ZSBhc2NpaS1jb21wYXRpYmxlDQo+Pj4gYWRk
cmVzcyB0aGF0IHdvdWxkIGJlIHVzZWQgaWYgdGhlIGkxOG4gbG9jYWxwYXJ0IGNhbm5vdCBiZSB1
c2VkLg0KPj4+DQo+Pj4gVGhlIEFUT01JQyBpbmZvcm1hdGlvbiBwcm92aWRlcyBhIHdheSB0byBp
bmRpY2F0ZSB0aGF0IHRoZSBkb3duZ3JhZGFibGUNCj4+PiBBQ0UgZm9ybSBvZiB0aGUgaTE4biBh
ZGRyZXNzIGNhbiBiZSB1c2VkIGFzIHRoZSBhbHRlcm5hdGUgYWRkcmVzcy4NCj4+Pg0KPj4+IFRo
ZSBzaW5nbGUgYml0IG9mIGtub3dsZWRnZSBhYm91dCB3aGV0aGVyIGFuIGkxOG4gbG9jYWxwYXJ0
IGlzIEFUT01JQw0KPj4+IGNhbiBiZSB1c2VkIGFuZCBwYXNzZWQgaW4gc2V2ZXJhbCB3YXlzLiBU
aGUgY3VycmVudCBzcGVjcyBjYWxsIGZvciB0aGUNCj4+PiBNVUEgdG8gZG8gdGhlIGZvbGxvd2lu
ZyBwcm9jZXNzaW5nOg0KPj4+DQo+Pj4gbXVhOiBpZiBpMThuIGFkZHJlc3MgaXMgQVRPTUlDDQo+
Pj4gbXVhOiBwYXNzIGkxOG4gYWRkcmVzcyBhbmQgaW5mbyBzYXlpbmcgYWRkcmVzcyBpcyBBVE9N
SUMNCj4+PiBtdWE6IGVsc2UgaWYgdGhlcmUgaXMgYW4gYWx0ZXJuYXRlIEFDRSBhZGRyZXNzDQo+
Pj4gbXVhOiBwYXNzIGkxOG4gYWRkcmVzcyBhbmQgYWx0ZXJuYXRlIEFDRSBhZGRyZXNzDQo+Pj4g
bXVhOiBlbHNlDQo+Pj4gbXVhOiBwYXNzIGkxOG4gYWRkcmVzcw0KPj4+DQo+Pj4gV2hlbiBhbiBN
VEEgaGl0cyBhbm90aGVyIE1UQSB0aGF0IGlzIG5vdCBpMThuIGNvbXBhdGlibGUsIGl0IG11c3Qg
ZG8gdGhlDQo+Pj4gZm9sbG93aW5nIHByb2Nlc3Npbmc6DQo+Pj4NCj4+PiBtdGE6IGlmIGFkZHJl
c3MgaXMgQVRPTUlDDQo+Pj4gbXRhOiBkb3duZ3JhZGUgbWVzc2FnZSBoZWFkZXJzIGFuZCBib2R5
DQo+Pj4gbXRhOiBjb252ZXJ0IGkxOG4gYWRkcmVzcyB0byBBQ0UNCj4+PiBtdGE6IHVzZSBjb252
ZXJ0ZWQgYWRkcmVzcw0KPj4+IG10YTogZWxzZSBpZiB0aGVyZSBpcyBhbiBhbHRlcm5hdGUgQUNF
IGFkZHJlc3MNCj4+PiBtdGE6IGRvd25ncmFkZSBtZXNzYWdlIGhlYWRlcnMgYW5kIGJvZHkNCj4+
PiBtdGE6IHVzZSBhbHRlcm5hdGUgYWRkcmVzcw0KPj4+IG10YTogZWxzZQ0KPj4+IG10YTogYm91
bmNlIHRoZSBtZXNzYWdlDQo+Pj4NCj4+PiBDb25zaWRlciB0aGUgZm9sbG93aW5nIGFsdGVybmF0
aXZlIHdoZXJlIHRoZSBNVUEgdXNlcyB0aGUga25vd2xlZGdlIHRoYXQNCj4+PiB0aGUgaTE4biBh
ZGRyZXNzIGlzIEFUT01JQyBhbmQgdXNlcyB0aGF0IGtub3dsZWRnZSB1cCBmcm9udCB0byBzZXQg
dGhlDQo+Pj4gYWx0ZXJuYXRlIGFkZHJlc3MuDQo+Pj4NCj4+PiBtdWE6IGlmIGkxOG4gYWRkcmVz
cyBpcyBBVE9NSUMNCj4+PiBtdWE6IHBhc3MgaTE4biBhZGRyZXNzIGFuZCBnZW5lcmF0ZWQgQUNF
IGFkZHJlc3MgYXMgYWx0ZXJuYXRlDQo+Pj4gbXVhOiBlbHNlIGlmIHRoZXJlIGlzIGFuIGFsdGVy
bmF0ZSBBQ0UgYWRkcmVzcw0KPj4+IG11YTogcGFzcyBpMThuIGFkZHJlc3MgYW5kIGFsdGVybmF0
ZSBBQ0UgYWRkcmVzcw0KPj4+IG11YTogZWxzZQ0KPj4+IG11YTogcGFzcyBpMThuIGFkZHJlc3MN
Cj4+Pg0KPj4+IE5vdyBsb29rIGF0IGhvdyBtdWNoIHNpbXBsZXIgdGhlIE1UQSBiZWNvbWVzOg0K
Pj4+DQo+Pj4gbXRhOiBpZiB0aGVyZSBpcyBhbiBhbHRlcm5hdGUgQUNFIGFkZHJlc3MNCj4+PiBt
dGE6IGRvd25ncmFkZSBtZXNzYWdlIGhlYWRlcnMgYW5kIGJvZHkNCj4+PiBtdGE6IHVzZSBhbHRl
cm5hdGUgYWRkcmVzcw0KPj4+IG10YTogZWxzZQ0KPj4+IG10YTogYm91bmNlIHRoZSBtZXNzYWdl
IA0KPj4+DQo+Pj4gRHVyaW5nIHRoZSBFQUkgbWVldGluZywgd2hlbiBwZW9wbGUgc2FpZCB0byBn
ZXQgcmlkIG9mIEFUT01JQyBpbiBTTVRQLA0KPj4+IG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0
aGV5IHdlcmUgc2F5aW5nIHRvIGdldCByaWQgb2YgdGhlIFNNVFAgQVRPTUlDDQo+Pj4gcGFyYW1l
dGVyLCBidXQgbm90IHRoZSBBVE9NSUMgY29uY2VwdC4NCj4+Pg0KPj4+IFRvbnkgSGFuc2VuDQo+
Pj4gdG9ueUBhdHQuY29tDQo+Pj4NCj4+PiBFZG1vbiBDaHVuZyB3cm90ZToNCj4+Pj4gLS0tLS0g
T3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCj4+Pj4gRnJvbTogIlRvbnkgRmluY2giIDxkb3RAZG90
YXQuYXQ+DQo+Pj4+Pj4gSWYgYW4gYWRkcmVzcyBpcyBkZXNpZ25hdGVkIGFzIEFUT01JQywgdGhl
biBJIHdvdWxkIHN0b3JlIHRoYXQNCj4+Pj4+PiBpbmZvcm1hdGlvbiBjYXVzZSBJIGtub3cgdGhh
dCBpdCBjb3VsZCBiZSB1c2VkIGluIHRoZSBmdXR1cmUuICBJZiBhbg0KPj4+Pj4+IGFsdC1hZGRy
ZXNzIGlzIHByb3ZpZGVkLCB0aGVuIEkgd291bGQgcHJvYmFibHkgaGF2ZSB0byBkaXNjYXJkIGl0
IGNhdXNlDQo+Pj4+Pj4gSSBjYW5ub3QgZGV0ZXJtaW5lIHdoZXRoZXIgSSBjYW4gdXNlIHRoYXQg
c2FtZSBhbHQtYWRkciBpbiB0aGUgZnV0dXJlLg0KPj4+Pj4gSWYgeW91IGNhbid0IHRydXN0IHRo
ZSBhbHQtYWRkcmVzcyB0aGVuIHN1cmVseSB5b3UgY2FuJ3QgdHJ1c3QgdGhlIHV0ZjgNCj4+Pj4+
IGFkZHJlc3MgZWl0aGVyLiBPciBpbiBvdGhlciB3b3JkcywgSSBkb24ndCB0aGluayB0aGlzIGtp
bmQgb2Ygb3BlcmF0aW9uYWwNCj4+Pj4+IHN0YWJpbGl0eSBpc3N1ZSBpcyByZWxldmFudC4gWW91
IGNhbiBhbHdheXMgdmVyaWZ5IHRoYXQgdGhlIGFsdC1hZGRyZXNzIGlzDQo+Pj4+PiB0aGUgYWxn
b3JpdGhtaWNhbGx5LWRvd25ncmFkZWQgZm9ybSBvZiB0aGUgdXRmOCBhZGRyZXNzIGJ5IGRvaW5n
IHRoZQ0KPj4+Pj4gZG93bmdyYWRlIGFuZCBjb21wYXJpbmcuDQo+Pj4+IEFMVC1BRERSRVNTIGlz
IG5vdCB0aGUgc2FtZSBhcyBBVE9NSUMuICBBTFQtQUREUkVTUyBjYW4gYmUgYW55IEFTQ0lJIGFk
ZHJlc3MuICBFLmcuICI8Y2hpbmVzZU5hbWU+QGRvbWFpbi50bGQiIGNhbiBoYXZlIGFuIEFMVC1B
RERSPSJhYmNAZGVmLm9yZyIgKG5vdGUgbm90IGV2ZW4gdGhlIGRvbWFpbiBuZWVkcyB0byBtYXRj
aCkuICBUaGF0IGlzIHdoeSB0aGUgYWx0LWFkZHJlc3MgY2Fubm90IGJlIGEgInN0YWJsZSIgZ2x1
ZSB0byB0aGUgVVRGOCBhZGRyZXNzLiAgVGhlIFVURjggYWRkcmVzcyBjYW4gYmUgZnVsbHkgdHJ1
c3RlZCBzbyBjYW4gYW4gQVRPTUlDIGFkZHJlc3MgKHdlbGwgdW5sZXNzIHRoZSBzdGFuZGFyZCB0
cmFuc2Zvcm1hdGlvbiBhbGdvcml0aG0gaXMgY2hhbmdlZC4uLiBidXQgdGhhdCB3b3VsZCBiZSBh
IGRpZmZlcmVudCBpc3N1ZS4uLiBtb3JlIG9uIHZlcnNpb25pbmcpLg0KPj4+Pg0KPj4+Pj4gSSdt
IHNlcmlvdXNseSB3b3JyaWVkIGFib3V0IHRoZSB1c2VyLWludGVyZmFjZSBpbXBsaWNhdGlvbnMg
b2Ygbm9uLWF0b21pYw0KPj4+Pj4gYWRkcmVzc2VzLg0KPj4+PiBXZWxsIHdpdGhvdXQgdGhlIEFU
T01JQyBwYXJhbWV0ZXIgYXQgYWxsIHRoZXJlIGlzIG5vIHdheSB0byBzYXkgdGhhdCBhbiBhZGRy
ZXNzIGlzIGF0b21pYy4uLiBhbmQgYmFzZWQgb24gdGhlIGN1cnJlbnQgc2V0IG9mIHNwZWNpZmlj
YXRpb25zLCBOb24tYXRvbWljIGlzIHRoZSBkZWZhdWx0Lg0KPj4+Pg0KPj4+PiBFZG1vbg0KPj4+
Pg0KPj4+Pg0KPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gSU1BIG1haWxpbmcgbGlzdA0K
Pj4+PiBJTUFAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vaW1hDQo+Pj4NCj4+IA0KPj4gDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IA0KPj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IElNQSBtYWls
aW5nIGxpc3QNCj4+IElNQUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vaW1hDQo+IA0KPg==



--===============0335457484==
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

--===============0335457484==--



From ima-bounces@ietf.org Sun Jul 16 01:22:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G1z5K-0002eG-6r; Sun, 16 Jul 2006 01:22:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G1z5I-0002eB-71
	for ima@ietf.org; Sun, 16 Jul 2006 01:22:28 -0400
Received: from proof.pobox.com ([207.106.133.28])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1z5F-0004Dw-OD
	for ima@ietf.org; Sun, 16 Jul 2006 01:22:27 -0400
Received: from proof (localhost [127.0.0.1])
	by proof.pobox.com (Postfix) with ESMTP id E5FDC29A8C;
	Sun, 16 Jul 2006 01:22:18 -0400 (EDT)
Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82])
	by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 7F5196257C;
	Sun, 16 Jul 2006 01:22:17 -0400 (EDT)
Date: Sat, 15 Jul 2006 22:22:11 -0700
From: Bill McQuillan <McQuilWP@pobox.com>
X-Priority: 3 (Normal)
Message-ID: <1268539184.20060715222211@pobox.com>
To: IMA Discussion <ima@ietf.org>
Subject: Re: [EAI] ATOMIC or not
In-Reply-To: <06e601c6a887$a815a540$b30110ac@edmontr3>
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
	<020101c6a52f$ca3f2660$b30110ac@edmontr3>
	<p06300012c0d9e269fecb@[142.131.134.210]>
	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>
	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>
	<03c201c6a607$a68936b0$b30110ac@edmontr3> <44B6AA85.2040601@att.com>
	<066901c6a7b7$26e121a0$b30110ac@edmontr3> <44B9ACA7.2030402@icu.ac.kr>
	<06e601c6a887$a815a540$b30110ac@edmontr3>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
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 Sat, 2006-07-15, Edmon Chung wrote:

> 4. Therefore I think it may be premature to write off the atomic parameter.

Let me say it one more time!

LET'S GET RID OF BOTH ALT-ADDR AND ATOMIC.

If there is a guaranteed reversable Local Part ACE which can be recognized
by some sort of flag (like xn-- in IDN) then why is there a need for
anything else?

It has been claimed that there are local parts that an ACE would corrupt,
but I currently do NOT believe that there is enough evidence for this.
Especially if the Local Part ACE only affects portions of a Local Part that
actually are UTF-8 characters. Thus no existing 2821/2 compliant Local
Parts would be changed and we could make recommendations for the creation
of Local Parts in the future that would avoid such corruption.

The problem that I see with Atomic and Alt-Addr is that the data structure
of an email address would be changed to either have a new flag (in the case
of Atomic) or another entire text string (in the case of Alt Addr). Either
of these new data types would need to be handled by everything on the
internet that knows about email addresses. Places such as: 2821bis and
2822bis address fields (obviously), Address books (storage and user
presentation), email addresses used as login id's on many web pages.

Many of these places would need to be enhanced to use this new i18n email
address data type before anyone could be confident in changing to such an
address. On the other hand, if all email addresses can be stored in a form
that is technically allowed by the existing standards merely by prefixing
the "downgraded" version of the address with a flag string, a new i18n
email address can be used as soon as the user's MDA and MUA are enhanced.
The ACEd version may need to be entered manually by some correspondents,
but the final delivery agent is the only one that needs to reverse and
understand the "downgrading".

Now, I know that there is a "rule" that the Local Part is entirely under
the control of the addressee, but it seems to me that reserving a very
unlikely prefix string is a small price to pay for the simplification that
it would bring.

-- 
Bill McQuillan <McQuilWP@pobox.com>


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



From ima-bounces@ietf.org Sun Jul 16 09:54:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G274u-0006Cg-Kw; Sun, 16 Jul 2006 09:54:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G274s-0006Cb-Kf
	for ima@ietf.org; Sun, 16 Jul 2006 09:54:34 -0400
Received: from lon-mail-1.gradwell.net ([193.111.201.125])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G274p-0007p1-Hq
	for ima@ietf.org; Sun, 16 Jul 2006 09:54:34 -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.226) id
	44ba4514.8b2b.35e5 for ima@ietf.org; Sun, 16 Jul 2006 14:54:28 +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 k6GDsPJQ024296
	for <ima@ietf.org>; Sun, 16 Jul 2006 14:54:26 +0100 (BST)
Date: Sun, 16 Jul 2006 14:54:24 +0100
To: ima@ietf.org
From: "Charles Lindsey" <chl@clerew.man.ac.uk>
Content-Type: multipart/mixed; boundary=----------EDFrsLJYXzCRYqmgNDIw9l
MIME-Version: 1.0
Message-ID: <op.tcsbkyto6hl8nm@clerew.man.ac.uk>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f45ea05559815d24dd3d462564224830
Subject: [EAI] The Worms of Punycode
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

------------EDFrsLJYXzCRYqmgNDIw9l
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Worm #1
-------

Punycode is defined in RFC 3492. I would describe it as a triumph of  
ingenuity over common sense. Moreover, RFC 3492 is incredibly badly  
written (essentially, it describes the protocol bottom-up, which means you  
cannot begin to understand the significance of any of its many concepts  
until you have already worked out what they all do without the slightest  
idea of what each is trying to achieve). But there it is.

Firstly, it is NOT an encoding algorithm. It is essentially a compression  
algorithm which just happens to produce an output composed entirely of  
ASCII (or, to be more precise, of <atext>s). The output consists, in  
essence, of
    a) The genuine ASCII characters extracted out of the input;
    b) a delimiter '-';
    c) a sequence of integers.
The integers are apparently represented in Base 36 (so each 'digit' can be  
represented by one of 26 letters - case insensitive -  plus 10 decimal  
digits); except that on further examination you discover that the base  
changes with each digit that is output (though it always lies between 1  
and 36).

Worm #2
-------

The algorithm is normatively defined using a pseudocode, but there is also  
a model implementation in C set out in Appendix C, which purports to  
achieve the effects defined by the pseudocode. But the model omits some  
features (checks) defined by the pseudocode which are provably  
unnecessary, but OTOH it also introduces some additional "features" not  
present in the pseudocode. It will be necessary for us to understand  
exactly what those "features" do and do not do in order to describe how  
the algorithm is to be used for <local-part>s in UTF8smtp.

Worm #3
-------

The algorithm was designed to work in an environment where the input had  
already been preprocessed, e.g. by Nameprep. Nameprep, which disallows  
various inadmissable Unicode Codepoints, and does case folding (to  
lowercase AIUI) for those alphabets (including ASCII) in which "case" is a  
meaningful concept. So not only would Nameprep change "Example" to  
"example", but it would also change "�xample" to "�xample". It may be the  
case that if you can assume the input has been pre-processed (by whatever  
*-prep is in use) some further checks can be omitted from the model  
implementation.

But as regards case folding, it needs to be recogised that RFC 3492 is  
written in the expectation that cases will have been folded, and hence it  
contains remarks (non-normative) which are misleading unless you  
appreciate where it is coming from.

In fact, the normative algorithm defined by the pseudocode is completely  
blind to case (and hence is in fact perfectly suited to our purpose). Not  
so the model implementation (and one expects that many implementors are  
going to use that model implementation without necessarily understanding  
it). The model implementation is indeed aware of "case" - it's those  
afforementioned "features", and therefore it is necessary to understand  
how to turn them "off".

Worm #4
-------

In fact, the model implementation is only aware of case in ASCII  
characters. Thus it knows that "E" and "e" are two versions of the same  
letter, but it is totally unaware that "�" and "�" are related in any way.  
So the first bit of good news is that those two will be correctly  
translated into Punycode whatever happens (and the only reason this does  
not confuse the present IDNA (which is case insensitive) is that the  
preprocessing by Nameprep will have already got rid of any "�").

Now, if you translate "�xample" into Punycode, there are many legitimate  
ways of doing it using the model implementation:

original	Punycode	case_flags
--------	--------	----------
�xample	xample-9ua	0000000
		xAmPlE-9ua	0010101
		xAmPlE-9uA	1010101
		XAMPLE-9uA	1111111

Here, the "case_flags" are a bit-vector provided as a parameter to  
punycode-encode. It causes the bit of the output corresponding to each  
character to be rendered in uppper or lower case (even within the integer  
sequence that encodes the non-ASCII characters).

Now if you are using "�xample" as part of a domain name, then it does not  
matter which of those outputs you get (DNS doesn't care), but obviously  
choosing 'all-zeroes' or 'all-ones' are the only sensible options. BUT, it  
you are so minded (and you can rely that the case of letters in domain  
names will not get changed en route, which is not 100% certain), then you  
can run a covert channel alongside your email carrying (in this example) 7  
bits of information (and punycode-decode in the model implementation will  
kindly hand your bit-vector back to you at the far end). You *might* even  
use these bit-vectors to encde the original (pre-Nameprep) case of your  
domain name, so that you could restore it to its former glory (this seems  
to be what the writers of RFC 3492 had in mind, as outlined in Appendix A  
- they even took the trouble to frig the basic parameters of the algorithm  
so that it could be guaranteed that the final "digit" of each integer in  
the sequence would be a letter rather than a digit).

Now that all looks like Good Clean Fun, but it is, of course, totally  
irrelevant for our purpose which is to convey <local-part>s with their  
cases intact. And for that, you MUST NOT provide any bit-vectors. Just set  
the relevant parameter of punycode_[en,de]code to NULL (which is NOT the  
same as 'all-zeroes') and none of that nonsense will happen (as indeed it  
would never have happened in the first place if you had just read the  
normative pseudocode which says, quite plainly, "copy [the basic code  
points] to the output in order, followed by a delimiter if ...". No  
mention at all of case folding during the "copy".

Conclusion: the underlying Punycode algorithm will copy case-sensitively  
perfectly satisfactorily (even using their model implementation)  
*in*spite* of the attempts by the authors of RFC 3492 to confuse you into  
believing otherwise -:( .

Worm #5
-------

Punycode may fail. Obviously, if given invalid input, or an insufficient  
buffer to contain its output, that is fair enough. But it can also run  
into an overflow (and the model implementation carefully checks for this).  
In IDNA, the longest component of a domain name can have only 63  
characters; moreover the range of Unicode Codepoints is (0..10FFFF). With  
those restrictions, you can show that overflow will never happen if you do  
your arithmetic with 26-bit unsigned arithmetic (well, that's what they  
say, but from their formula I make it 27-bits).

What is the longest allowed <local-part>? Well, assuming you do not use a  
<quoted-string> with folded whitespace inside it, it is determined by the  
overall 998 byte limit on a header line (less a bit for the header name, a  
domain name, and other bits and pieces). So it turns out that it can be  
done in 31 unsigned bits. Or to put it another way, if you can do 32-bit  
unsigned arithmetic (and most machines these days can), you could have a  
<local-part> 3600 characters long. I think that will suffice :-) .





Worm #6
-------

We have to indicate that Punycode has been applied. In IDNA, this is done  
by prefixing it with 'xn--'. We are agreed that we need a different prefix  
for <local-part>s.

We are proposing an experimental protocol, which we hope people will start  
to implement pretty soon (indeed, it has already started). Therefore, I  
think we should choose our prefix *now*, and not rely on the RFC Editor to  
consult an oracle such as the New York Stock Exchange.

It needs to be similar to the IDNA prefix, so that it will be immediately  
recognizable for what it is. I therefore propose 'yn--' - it is evidently  
similar, and 'y' is a pretty obvious progression from 'x', so if you can  
remember the one, you should have no difficulty in remembering the other.

The IDNA prefix was chosen because it could not possibly be a legal domain  
name. We do not have that assurance, so if 'yn--xample-9ua' is seen as a  
<local part>, how you you know that it was not a genuine ASCII  
<local-part>?

You don't, but then how did you know that someone who provided the Subject

     Subject: =?iso-8859-1?Q?=C9xample?=

didn't actually mean exactly that? You don't, but its a pretty safe bet  
that he didn't, and I think it is a pretty safe bet that 'yn--xample-9ua'  
was not intended to be taken as literally that. But then, the delivery  
agent can always try to look it up in its  
address-list/-algorith/-whatever, and if it finds it is genuine, then good  
luck to it!

And on top of that, if there is a header such as

     Header-Content: downgraded

present, then that would give a further clue. I think this is a risk we  
just have to take.

Worm #7
-------

The syntax of <local-part> is

     dot-atom / quoted-string

(assuming we can ignore the obs-local-part). In UTF8smtp, both the  
<dot-atom> and the <quoted-string> can have UTF8 in them (but you still  
need to use a <quoted-string> if there are any (ASCII) <specials> in  
there. What comes out after Punycoding must still be a syntactically  
correct <local-part>, but this time according to strict RFC 2822. So if  
you start with

     "�xample avec une SP"@�xample.com

and just apply Punycode blindly, you will get

     yn--"xample avec une SP"-b2b@xn--xample-9ua.com

But now you do not have a syntactically correct RFC 2822 <local-part>.

So the ACE rule must be

     If the (UTF8smtp) <local-part> is a <quoted-string>, remove the  
initial and final DQOTEs and convert what remains using Punycode (without  
any bit-vector and with prefix 'yn--'), then enclose the result of that  
within DQUOTEs; if it was originally a <dot-atom>, then simply convert it.

So that example would come out  as

     "yn--xample avec une SP-9vb"xample avec une SP-9vb

Worm #8

If you convert something that is already pure ASCII, it is *not* a nullop.  
For example, the Punycode of 'ABCD' is 'ABCD-' (or 'yn--ABCD-' after  
prefixing). So the rule also needs to instruct you not to appy the ACE to  
something that is already pure ASCII.


For people who want to experiment further, I have attached two C program  
texts. 'rfc3492.c' is just the model implementation taken direct from  
Appendix C, but without the "wrapper" at the end for testing it.  
'tounicode.c' is a program which #includes the first one.

Set yout locale to use whatever charset you fancy (UTF8 or whatever). Call  
'tounicode' and give it strings (one on each line) in your charset. It  
will convert them to UTF-32 and print out the Codepoints, followed by the  
representation in Punycode. After that, it decodes the Punycode, and  
prints it out again as Codepoints and in your original charset. It ought  
to print out finally exactly what you input originally.

-- 
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
------------EDFrsLJYXzCRYqmgNDIw9l
Content-Disposition: attachment; filename=rfc3492.c
Content-Type: application/octet-stream; name=rfc3492.c
Content-Transfer-Encoding: Base64

LyoKcHVueWNvZGUuYyBmcm9tIFJGQyAzNDkyCmh0dHA6Ly93d3cubmljZW1pY2Uu
bmV0L2lkbi8KQWRhbSBNLiBDb3N0ZWxsbwpodHRwOi8vd3d3Lm5pY2VtaWNlLm5l
dC9hbWMvCgpUaGlzIGlzIEFOU0kgQyBjb2RlIChDODkpIGltcGxlbWVudGluZyBQ
dW55Y29kZSAoUkZDIDM0OTIpLgoKKi8KCgovKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLwovKiBQdWJs
aWMgaW50ZXJmYWNlICh3b3VsZCBub3JtYWxseSBnbyBpbiBpdHMgb3duIC5oIGZp
bGUpOiAqLwoKI2luY2x1ZGUgPGxpbWl0cy5oPgoKZW51bSBwdW55Y29kZV9zdGF0
dXMgewogIHB1bnljb2RlX3N1Y2Nlc3MsCiAgcHVueWNvZGVfYmFkX2lucHV0LCAg
IC8qIElucHV0IGlzIGludmFsaWQuICAgICAgICAgICAgICAgICAgICAgICAqLwog
IHB1bnljb2RlX2JpZ19vdXRwdXQsICAvKiBPdXRwdXQgd291bGQgZXhjZWVkIHRo
ZSBzcGFjZSBwcm92aWRlZC4gKi8KICBwdW55Y29kZV9vdmVyZmxvdyAgICAgLyog
SW5wdXQgbmVlZHMgd2lkZXIgaW50ZWdlcnMgdG8gcHJvY2Vzcy4gICovCn07Cgoj
aWYgVUlOVF9NQVggPj0gKDEgPDwgMjYpIC0gMQp0eXBlZGVmIHVuc2lnbmVkIGlu
dCBwdW55Y29kZV91aW50OwojZWxzZQp0eXBlZGVmIHVuc2lnbmVkIGxvbmcgcHVu
eWNvZGVfdWludDsKI2VuZGlmCgplbnVtIHB1bnljb2RlX3N0YXR1cyBwdW55Y29k
ZV9lbmNvZGUoCiAgcHVueWNvZGVfdWludCBpbnB1dF9sZW5ndGgsCiAgY29uc3Qg
cHVueWNvZGVfdWludCBpbnB1dFtdLAogIGNvbnN0IHVuc2lnbmVkIGNoYXIgY2Fz
ZV9mbGFnc1tdLAogIHB1bnljb2RlX3VpbnQgKm91dHB1dF9sZW5ndGgsCiAgY2hh
ciBvdXRwdXRbXSApOwoKICAgIC8qIHB1bnljb2RlX2VuY29kZSgpIGNvbnZlcnRz
IFVuaWNvZGUgdG8gUHVueWNvZGUuICBUaGUgaW5wdXQgICAgICovCiAgICAvKiBp
cyByZXByZXNlbnRlZCBhcyBhbiBhcnJheSBvZiBVbmljb2RlIGNvZGUgcG9pbnRz
IChub3QgY29kZSAgICAqLwogICAgLyogdW5pdHM7IHN1cnJvZ2F0ZSBwYWlycyBh
cmUgbm90IGFsbG93ZWQpLCBhbmQgdGhlIG91dHB1dCAgICAgICAgKi8KICAgIC8q
IHdpbGwgYmUgcmVwcmVzZW50ZWQgYXMgYW4gYXJyYXkgb2YgQVNDSUkgY29kZSBw
b2ludHMuICBUaGUgICAgICovCiAgICAvKiBvdXRwdXQgc3RyaW5nIGlzICpub3Qq
IG51bGwtdGVybWluYXRlZDsgaXQgd2lsbCBjb250YWluICAgICAgICAqLwogICAg
LyogemVyb3MgaWYgYW5kIG9ubHkgaWYgdGhlIGlucHV0IGNvbnRhaW5zIHplcm9z
LiAgKE9mIGNvdXJzZSAgICAgKi8KICAgIC8qIHRoZSBjYWxsZXIgY2FuIGxlYXZl
IHJvb20gZm9yIGEgdGVybWluYXRvciBhbmQgYWRkIG9uZSBpZiAgICAgICovCiAg
ICAvKiBuZWVkZWQuKSAgVGhlIGlucHV0X2xlbmd0aCBpcyB0aGUgbnVtYmVyIG9m
IGNvZGUgcG9pbnRzIGluICAgICAqLwogICAgLyogdGhlIGlucHV0LiAgVGhlIG91
dHB1dF9sZW5ndGggaXMgYW4gaW4vb3V0IGFyZ3VtZW50OiB0aGUgICAgICAgKi8K
ICAgIC8qIGNhbGxlciBwYXNzZXMgaW4gdGhlIG1heGltdW0gbnVtYmVyIG9mIGNv
ZGUgcG9pbnRzIHRoYXQgaXQgICAgICovCiAgICAvKiBjYW4gcmVjZWl2ZSwgYW5k
IG9uIHN1Y2Nlc3NmdWwgcmV0dXJuIGl0IHdpbGwgY29udGFpbiB0aGUgICAgICAq
LwogICAgLyogbnVtYmVyIG9mIGNvZGUgcG9pbnRzIGFjdHVhbGx5IG91dHB1dC4g
IFRoZSBjYXNlX2ZsYWdzIGFycmF5ICAgKi8KICAgIC8qIGhvbGRzIGlucHV0X2xl
bmd0aCBib29sZWFuIHZhbHVlcywgd2hlcmUgbm9uemVybyBzdWdnZXN0cyB0aGF0
ICovCiAgICAvKiB0aGUgY29ycmVzcG9uZGluZyBVbmljb2RlIGNoYXJhY3RlciBi
ZSBmb3JjZWQgdG8gdXBwZXJjYXNlICAgICAqLwogICAgLyogYWZ0ZXIgYmVpbmcg
ZGVjb2RlZCAoaWYgcG9zc2libGUpLCBhbmQgemVybyBzdWdnZXN0cyB0aGF0ICAg
ICAgKi8KICAgIC8qIGl0IGJlIGZvcmNlZCB0byBsb3dlcmNhc2UgKGlmIHBvc3Np
YmxlKS4gIEFTQ0lJIGNvZGUgcG9pbnRzICAgICovCiAgICAvKiBhcmUgZW5jb2Rl
ZCBsaXRlcmFsbHksIGV4Y2VwdCB0aGF0IEFTQ0lJIGxldHRlcnMgYXJlIGZvcmNl
ZCAgICAqLwogICAgLyogdG8gdXBwZXJjYXNlIG9yIGxvd2VyY2FzZSBhY2NvcmRp
bmcgdG8gdGhlIGNvcnJlc3BvbmRpbmcgICAgICAgKi8KICAgIC8qIHVwcGVyY2Fz
ZSBmbGFncy4gIElmIGNhc2VfZmxhZ3MgaXMgYSBudWxsIHBvaW50ZXIgdGhlbiBB
U0NJSSAgICovCiAgICAvKiBsZXR0ZXJzIGFyZSBsZWZ0IGFzIHRoZXkgYXJlLCBh
bmQgb3RoZXIgY29kZSBwb2ludHMgYXJlICAgICAgICAqLwogICAgLyogdHJlYXRl
ZCBhcyBpZiB0aGVpciB1cHBlcmNhc2UgZmxhZ3Mgd2VyZSB6ZXJvLiAgVGhlIHJl
dHVybiAgICAgKi8KICAgIC8qIHZhbHVlIGNhbiBiZSBhbnkgb2YgdGhlIHB1bnlj
b2RlX3N0YXR1cyB2YWx1ZXMgZGVmaW5lZCBhYm92ZSAgICovCiAgICAvKiBleGNl
cHQgcHVueWNvZGVfYmFkX2lucHV0OyBpZiBub3QgcHVueWNvZGVfc3VjY2Vzcywg
dGhlbiAgICAgICAqLwogICAgLyogb3V0cHV0X3NpemUgYW5kIG91dHB1dCBtaWdo
dCBjb250YWluIGdhcmJhZ2UuICAgICAgICAgICAgICAgICAgKi8KCmVudW0gcHVu
eWNvZGVfc3RhdHVzIHB1bnljb2RlX2RlY29kZSgKICBwdW55Y29kZV91aW50IGlu
cHV0X2xlbmd0aCwKICBjb25zdCBjaGFyIGlucHV0W10sCiAgcHVueWNvZGVfdWlu
dCAqb3V0cHV0X2xlbmd0aCwKICBwdW55Y29kZV91aW50IG91dHB1dFtdLAogIHVu
c2lnbmVkIGNoYXIgY2FzZV9mbGFnc1tdICk7CgogICAgLyogcHVueWNvZGVfZGVj
b2RlKCkgY29udmVydHMgUHVueWNvZGUgdG8gVW5pY29kZS4gIFRoZSBpbnB1dCBp
cyAgKi8KICAgIC8qIHJlcHJlc2VudGVkIGFzIGFuIGFycmF5IG9mIEFTQ0lJIGNv
ZGUgcG9pbnRzLCBhbmQgdGhlIG91dHB1dCAgICovCiAgICAvKiB3aWxsIGJlIHJl
cHJlc2VudGVkIGFzIGFuIGFycmF5IG9mIFVuaWNvZGUgY29kZSBwb2ludHMuICBU
aGUgICAqLwogICAgLyogaW5wdXRfbGVuZ3RoIGlzIHRoZSBudW1iZXIgb2YgY29k
ZSBwb2ludHMgaW4gdGhlIGlucHV0LiAgVGhlICAgKi8KICAgIC8qIG91dHB1dF9s
ZW5ndGggaXMgYW4gaW4vb3V0IGFyZ3VtZW50OiB0aGUgY2FsbGVyIHBhc3NlcyBp
biAgICAgICovCiAgICAvKiB0aGUgbWF4aW11bSBudW1iZXIgb2YgY29kZSBwb2lu
dHMgdGhhdCBpdCBjYW4gcmVjZWl2ZSwgYW5kICAgICAqLwogICAgLyogb24gc3Vj
Y2Vzc2Z1bCByZXR1cm4gaXQgd2lsbCBjb250YWluIHRoZSBhY3R1YWwgbnVtYmVy
IG9mICAgICAgKi8KICAgIC8qIGNvZGUgcG9pbnRzIG91dHB1dC4gIFRoZSBjYXNl
X2ZsYWdzIGFycmF5IG5lZWRzIHJvb20gZm9yIGF0ICAgICovCiAgICAvKiBsZWFz
dCBvdXRwdXRfbGVuZ3RoIHZhbHVlcywgb3IgaXQgY2FuIGJlIGEgbnVsbCBwb2lu
dGVyIGlmIHRoZSAqLwogICAgLyogY2FzZSBpbmZvcm1hdGlvbiBpcyBub3QgbmVl
ZGVkLiAgQSBub256ZXJvIGZsYWcgc3VnZ2VzdHMgdGhhdCAgKi8KICAgIC8qIHRo
ZSBjb3JyZXNwb25kaW5nIFVuaWNvZGUgY2hhcmFjdGVyIGJlIGZvcmNlZCB0byB1
cHBlcmNhc2UgICAgICovCiAgICAvKiBieSB0aGUgY2FsbGVyIChpZiBwb3NzaWJs
ZSksIHdoaWxlIHplcm8gc3VnZ2VzdHMgdGhhdCBpdCBiZSAgICAqLwogICAgLyog
Zm9yY2VkIHRvIGxvd2VyY2FzZSAoaWYgcG9zc2libGUpLiAgQVNDSUkgY29kZSBw
b2ludHMgYXJlICAgICAgKi8KICAgIC8qIG91dHB1dCBhbHJlYWR5IGluIHRoZSBw
cm9wZXIgY2FzZSwgYnV0IHRoZWlyIGZsYWdzIHdpbGwgYmUgc2V0ICovCiAgICAv
KiBhcHByb3ByaWF0ZWx5IHNvIHRoYXQgYXBwbHlpbmcgdGhlIGZsYWdzIHdvdWxk
IGJlIGhhcm1sZXNzLiAgICAqLwogICAgLyogVGhlIHJldHVybiB2YWx1ZSBjYW4g
YmUgYW55IG9mIHRoZSBwdW55Y29kZV9zdGF0dXMgdmFsdWVzICAgICAgKi8KICAg
IC8qIGRlZmluZWQgYWJvdmU7IGlmIG5vdCBwdW55Y29kZV9zdWNjZXNzLCB0aGVu
IG91dHB1dF9sZW5ndGgsICAgICovCiAgICAvKiBvdXRwdXQsIGFuZCBjYXNlX2Zs
YWdzIG1pZ2h0IGNvbnRhaW4gZ2FyYmFnZS4gIE9uIHN1Y2Nlc3MsIHRoZSAqLwog
ICAgLyogZGVjb2RlciB3aWxsIG5ldmVyIG5lZWQgdG8gd3JpdGUgYW4gb3V0cHV0
X2xlbmd0aCBncmVhdGVyIHRoYW4gKi8KICAgIC8qIGlucHV0X2xlbmd0aCwgYmVj
YXVzZSBvZiBob3cgdGhlIGVuY29kaW5nIGlzIGRlZmluZWQuICAgICAgICAgICov
CgovKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKi8KLyogSW1wbGVtZW50YXRpb24gKHdvdWxkIG5vcm1hbGx5
IGdvIGluIGl0cyBvd24gLmMgZmlsZSk6ICovCgojaW5jbHVkZSA8c3RyaW5nLmg+
Ci8qKiogQm9vdHN0cmluZyBwYXJhbWV0ZXJzIGZvciBQdW55Y29kZSAqKiovCgpl
bnVtIHsgYmFzZSA9IDM2LCB0bWluID0gMSwgdG1heCA9IDI2LCBza2V3ID0gMzgs
IGRhbXAgPSA3MDAsCiAgICAgICBpbml0aWFsX2JpYXMgPSA3MiwgaW5pdGlhbF9u
ID0gMHg4MCwgZGVsaW1pdGVyID0gMHgyRCB9OwoKLyogYmFzaWMoY3ApIHRlc3Rz
IHdoZXRoZXIgY3AgaXMgYSBiYXNpYyBjb2RlIHBvaW50OiAqLwojZGVmaW5lIGJh
c2ljKGNwKSAoKHB1bnljb2RlX3VpbnQpKGNwKSA8IDB4ODApCgovKiBkZWxpbShj
cCkgdGVzdHMgd2hldGhlciBjcCBpcyBhIGRlbGltaXRlcjogKi8KI2RlZmluZSBk
ZWxpbShjcCkgKChjcCkgPT0gZGVsaW1pdGVyKQoKLyogZGVjb2RlX2RpZ2l0KGNw
KSByZXR1cm5zIHRoZSBudW1lcmljIHZhbHVlIG9mIGEgYmFzaWMgY29kZSAqLwov
KiBwb2ludCAoZm9yIHVzZSBpbiByZXByZXNlbnRpbmcgaW50ZWdlcnMpIGluIHRo
ZSByYW5nZSAwIHRvICovCi8qIGJhc2UtMSwgb3IgYmFzZSBpZiBjcCBpcyBkb2Vz
IG5vdCByZXByZXNlbnQgYSB2YWx1ZS4gICAgICAgKi8KCnN0YXRpYyBwdW55Y29k
ZV91aW50IGRlY29kZV9kaWdpdChwdW55Y29kZV91aW50IGNwKQp7CiAgcmV0dXJu
ICBjcCAtIDQ4IDwgMTAgPyBjcCAtIDIyIDogIGNwIC0gNjUgPCAyNiA/IGNwIC0g
NjUgOgogICAgICAgICAgY3AgLSA5NyA8IDI2ID8gY3AgLSA5NyA6ICBiYXNlOwp9
CgovKiBlbmNvZGVfZGlnaXQoZCxmbGFnKSByZXR1cm5zIHRoZSBiYXNpYyBjb2Rl
IHBvaW50IHdob3NlIHZhbHVlICAgICAgKi8KLyogKHdoZW4gdXNlZCBmb3IgcmVw
cmVzZW50aW5nIGludGVnZXJzKSBpcyBkLCB3aGljaCBuZWVkcyB0byBiZSBpbiAg
ICovCi8qIHRoZSByYW5nZSAwIHRvIGJhc2UtMS4gIFRoZSBsb3dlcmNhc2UgZm9y
bSBpcyB1c2VkIHVubGVzcyBmbGFnIGlzICAqLwovKiBub256ZXJvLCBpbiB3aGlj
aCBjYXNlIHRoZSB1cHBlcmNhc2UgZm9ybSBpcyB1c2VkLiAgVGhlIGJlaGF2aW9y
ICAgKi8KLyogaXMgdW5kZWZpbmVkIGlmIGZsYWcgaXMgbm9uemVybyBhbmQgZGln
aXQgZCBoYXMgbm8gdXBwZXJjYXNlIGZvcm0uICovCgpzdGF0aWMgY2hhciBlbmNv
ZGVfZGlnaXQocHVueWNvZGVfdWludCBkLCBpbnQgZmxhZykKewogIHJldHVybiBk
ICsgMjIgKyA3NSAqIChkIDwgMjYpIC0gKChmbGFnICE9IDApIDw8IDUpOwogIC8q
ICAwLi4yNSBtYXAgdG8gQVNDSUkgYS4ueiBvciBBLi5aICovCiAgLyogMjYuLjM1
IG1hcCB0byBBU0NJSSAwLi45ICAgICAgICAgKi8KfQoKLyogZmxhZ2dlZChiY3Ap
IHRlc3RzIHdoZXRoZXIgYSBiYXNpYyBjb2RlIHBvaW50IGlzIGZsYWdnZWQgKi8K
LyogKHVwcGVyY2FzZSkuICBUaGUgYmVoYXZpb3IgaXMgdW5kZWZpbmVkIGlmIGJj
cCBpcyBub3QgYSAgKi8KLyogYmFzaWMgY29kZSBwb2ludC4gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KCiNkZWZpbmUgZmxhZ2dlZChi
Y3ApICgocHVueWNvZGVfdWludCkoYmNwKSAtIDY1IDwgMjYpCgovKiBlbmNvZGVf
YmFzaWMoYmNwLGZsYWcpIGZvcmNlcyBhIGJhc2ljIGNvZGUgcG9pbnQgdG8gbG93
ZXJjYXNlICovCi8qIGlmIGZsYWcgaXMgemVybywgdXBwZXJjYXNlIGlmIGZsYWcg
aXMgbm9uemVybywgYW5kIHJldHVybnMgICAgKi8KLyogdGhlIHJlc3VsdGluZyBj
b2RlIHBvaW50LiAgVGhlIGNvZGUgcG9pbnQgaXMgdW5jaGFuZ2VkIGlmIGl0ICAq
LwovKiBpcyBjYXNlbGVzcy4gIFRoZSBiZWhhdmlvciBpcyB1bmRlZmluZWQgaWYg
YmNwIGlzIG5vdCBhIGJhc2ljICovCi8qIGNvZGUgcG9pbnQuICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KCnN0YXRp
YyBjaGFyIGVuY29kZV9iYXNpYyhwdW55Y29kZV91aW50IGJjcCwgaW50IGZsYWcp
CnsKICBiY3AgLT0gKGJjcCAtIDk3IDwgMjYpIDw8IDU7CiAgcmV0dXJuIGJjcCAr
ICgoIWZsYWcgJiYgKGJjcCAtIDY1IDwgMjYpKSA8PCA1KTsKfQoKLyoqKiBQbGF0
Zm9ybS1zcGVjaWZpYyBjb25zdGFudHMgKioqLwoKLyogbWF4aW50IGlzIHRoZSBt
YXhpbXVtIHZhbHVlIG9mIGEgcHVueWNvZGVfdWludCB2YXJpYWJsZTogKi8Kc3Rh
dGljIGNvbnN0IHB1bnljb2RlX3VpbnQgbWF4aW50ID0gLTE7Ci8qIEJlY2F1c2Ug
bWF4aW50IGlzIHVuc2lnbmVkLCAtMSBiZWNvbWVzIHRoZSBtYXhpbXVtIHZhbHVl
LiAqLwoKLyoqKiBCaWFzIGFkYXB0YXRpb24gZnVuY3Rpb24gKioqLwoKc3RhdGlj
IHB1bnljb2RlX3VpbnQgYWRhcHQoCiAgcHVueWNvZGVfdWludCBkZWx0YSwgcHVu
eWNvZGVfdWludCBudW1wb2ludHMsIGludCBmaXJzdHRpbWUgKQp7CiAgcHVueWNv
ZGVfdWludCBrOwoKICBkZWx0YSA9IGZpcnN0dGltZSA/IGRlbHRhIC8gZGFtcCA6
IGRlbHRhID4+IDE7CiAgLyogZGVsdGEgPj4gMSBpcyBhIGZhc3RlciB3YXkgb2Yg
ZG9pbmcgZGVsdGEgLyAyICovCiAgZGVsdGEgKz0gZGVsdGEgLyBudW1wb2ludHM7
CgogIGZvciAoayA9IDA7ICBkZWx0YSA+ICgoYmFzZSAtIHRtaW4pICogdG1heCkg
LyAyOyAgayArPSBiYXNlKSB7CiAgICBkZWx0YSAvPSBiYXNlIC0gdG1pbjsKICB9
CgogIHJldHVybiBrICsgKGJhc2UgLSB0bWluICsgMSkgKiBkZWx0YSAvIChkZWx0
YSArIHNrZXcpOwp9CgovKioqIE1haW4gZW5jb2RlIGZ1bmN0aW9uICoqKi8KCmVu
dW0gcHVueWNvZGVfc3RhdHVzIHB1bnljb2RlX2VuY29kZSgKICBwdW55Y29kZV91
aW50IGlucHV0X2xlbmd0aCwKICBjb25zdCBwdW55Y29kZV91aW50IGlucHV0W10s
CiAgY29uc3QgdW5zaWduZWQgY2hhciBjYXNlX2ZsYWdzW10sCiAgcHVueWNvZGVf
dWludCAqb3V0cHV0X2xlbmd0aCwKICBjaGFyIG91dHB1dFtdICkKewogIHB1bnlj
b2RlX3VpbnQgbiwgZGVsdGEsIGgsIGIsIG91dCwgbWF4X291dCwgYmlhcywgaiwg
bSwgcSwgaywgdDsKCiAgLyogSW5pdGlhbGl6ZSB0aGUgc3RhdGU6ICovCgogIG4g
PSBpbml0aWFsX247CiAgZGVsdGEgPSBvdXQgPSAwOwogIG1heF9vdXQgPSAqb3V0
cHV0X2xlbmd0aDsKICBiaWFzID0gaW5pdGlhbF9iaWFzOwoKICAvKiBIYW5kbGUg
dGhlIGJhc2ljIGNvZGUgcG9pbnRzOiAqLwogIGZvciAoaiA9IDA7ICBqIDwgaW5w
dXRfbGVuZ3RoOyAgKytqKSB7CiAgICBpZiAoYmFzaWMoaW5wdXRbal0pKSB7CiAg
ICAgIGlmIChtYXhfb3V0IC0gb3V0IDwgMikgcmV0dXJuIHB1bnljb2RlX2JpZ19v
dXRwdXQ7CiAgICAgIG91dHB1dFtvdXQrK10gPQogICAgICAgIGNhc2VfZmxhZ3Mg
PyAgZW5jb2RlX2Jhc2ljKGlucHV0W2pdLCBjYXNlX2ZsYWdzW2pdKSA6IGlucHV0
W2pdOwogICAgfQogICAgLyogZWxzZSBpZiAoaW5wdXRbal0gPCBuKSByZXR1cm4g
cHVueWNvZGVfYmFkX2lucHV0OyAqLwogICAgLyogKG5vdCBuZWVkZWQgZm9yIFB1
bnljb2RlIHdpdGggdW5zaWduZWQgY29kZSBwb2ludHMpICovCiAgfQoKICBoID0g
YiA9IG91dDsKCiAgLyogaCBpcyB0aGUgbnVtYmVyIG9mIGNvZGUgcG9pbnRzIHRo
YXQgaGF2ZSBiZWVuIGhhbmRsZWQsIGIgaXMgdGhlICAqLwogIC8qIG51bWJlciBv
ZiBiYXNpYyBjb2RlIHBvaW50cywgYW5kIG91dCBpcyB0aGUgbnVtYmVyIG9mIGNo
YXJhY3RlcnMgKi8KICAvKiB0aGF0IGhhdmUgYmVlbiBvdXRwdXQuICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICovCgogIGlmIChiID4g
MCkgb3V0cHV0W291dCsrXSA9IGRlbGltaXRlcjsKCiAgLyogTWFpbiBlbmNvZGlu
ZyBsb29wOiAqLwoKICB3aGlsZSAoaCA8IGlucHV0X2xlbmd0aCkgewogICAgLyog
QWxsIG5vbi1iYXNpYyBjb2RlIHBvaW50cyA8IG4gaGF2ZSBiZWVuICAgICAqLwog
ICAgLyogaGFuZGxlZCBhbHJlYWR5LiAgRmluZCB0aGUgbmV4dCBsYXJnZXIgb25l
OiAqLwoKICAgIGZvciAobSA9IG1heGludCwgaiA9IDA7ICBqIDwgaW5wdXRfbGVu
Z3RoOyAgKytqKSB7CiAgICAgIC8qIGlmIChiYXNpYyhpbnB1dFtqXSkpIGNvbnRp
bnVlOyAqLwogICAgICAvKiAobm90IG5lZWRlZCBmb3IgUHVueWNvZGUpICovCiAg
ICAgIGlmIChpbnB1dFtqXSA+PSBuICYmIGlucHV0W2pdIDwgbSkgbSA9IGlucHV0
W2pdOwogICAgfQoKICAgIC8qIEluY3JlYXNlIGRlbHRhIGVub3VnaCB0byBhZHZh
bmNlIHRoZSBkZWNvZGVyJ3MgICAgKi8KICAgIC8qIDxuLGk+IHN0YXRlIHRvIDxt
LDA+LCBidXQgZ3VhcmQgYWdhaW5zdCBvdmVyZmxvdzogKi8KCiAgICBpZiAobSAt
IG4gPiAobWF4aW50IC0gZGVsdGEpIC8gKGggKyAxKSkgcmV0dXJuIHB1bnljb2Rl
X292ZXJmbG93OwogICAgZGVsdGEgKz0gKG0gLSBuKSAqIChoICsgMSk7CiAgICBu
ID0gbTsKCiAgICBmb3IgKGogPSAwOyAgaiA8IGlucHV0X2xlbmd0aDsgICsraikg
ewogICAgICAvKiBQdW55Y29kZSBkb2VzIG5vdCBuZWVkIHRvIGNoZWNrIHdoZXRo
ZXIgaW5wdXRbal0gaXMgYmFzaWM6ICovCiAgICAgIGlmIChpbnB1dFtqXSA8IG4g
LyogfHwgYmFzaWMoaW5wdXRbal0pICovICkgewogICAgICAgIGlmICgrK2RlbHRh
ID09IDApIHJldHVybiBwdW55Y29kZV9vdmVyZmxvdzsKICAgICAgfQoKICAgICAg
aWYgKGlucHV0W2pdID09IG4pIHsKICAgICAgICAvKiBSZXByZXNlbnQgZGVsdGEg
YXMgYSBnZW5lcmFsaXplZCB2YXJpYWJsZS1sZW5ndGggaW50ZWdlcjogKi8KCiAg
ICAgICAgZm9yIChxID0gZGVsdGEsIGsgPSBiYXNlOyAgOyAgayArPSBiYXNlKSB7
CiAgICAgICAgICBpZiAob3V0ID49IG1heF9vdXQpIHJldHVybiBwdW55Y29kZV9i
aWdfb3V0cHV0OwogICAgICAgICAgdCA9IGsgPD0gYmlhcyAvKiArIHRtaW4gKi8g
PyB0bWluIDogICAgIC8qICt0bWluIG5vdCBuZWVkZWQgKi8KICAgICAgICAgICAg
ICBrID49IGJpYXMgKyB0bWF4ID8gdG1heCA6IGsgLSBiaWFzOwogICAgICAgICAg
aWYgKHEgPCB0KSBicmVhazsKICAgICAgICAgIG91dHB1dFtvdXQrK10gPSBlbmNv
ZGVfZGlnaXQodCArIChxIC0gdCkgJSAoYmFzZSAtIHQpLCAwKTsKICAgICAgICAg
IHEgPSAocSAtIHQpIC8gKGJhc2UgLSB0KTsKICAgICAgICB9CgogICAgICAgIG91
dHB1dFtvdXQrK10gPSBlbmNvZGVfZGlnaXQocSwgY2FzZV9mbGFncyAmJiBjYXNl
X2ZsYWdzW2pdKTsKICAgICAgICBiaWFzID0gYWRhcHQoZGVsdGEsIGggKyAxLCBo
ID09IGIpOwogICAgICAgIGRlbHRhID0gMDsKICAgICAgICArK2g7CiAgICAgIH0K
ICAgIH0KCiAgICArK2RlbHRhLCArK247CiAgfQoKICAqb3V0cHV0X2xlbmd0aCA9
IG91dDsKICByZXR1cm4gcHVueWNvZGVfc3VjY2VzczsKfQoKLyoqKiBNYWluIGRl
Y29kZSBmdW5jdGlvbiAqKiovCgplbnVtIHB1bnljb2RlX3N0YXR1cyBwdW55Y29k
ZV9kZWNvZGUoCiAgcHVueWNvZGVfdWludCBpbnB1dF9sZW5ndGgsCiAgY29uc3Qg
Y2hhciBpbnB1dFtdLAogIHB1bnljb2RlX3VpbnQgKm91dHB1dF9sZW5ndGgsCiAg
cHVueWNvZGVfdWludCBvdXRwdXRbXSwKICB1bnNpZ25lZCBjaGFyIGNhc2VfZmxh
Z3NbXSApCnsKICBwdW55Y29kZV91aW50IG4sIG91dCwgaSwgbWF4X291dCwgYmlh
cywKICAgICAgICAgICAgICAgICBiLCBqLCBpbiwgb2xkaSwgdywgaywgZGlnaXQs
IHQ7CgogIC8qIEluaXRpYWxpemUgdGhlIHN0YXRlOiAqLwoKICBuID0gaW5pdGlh
bF9uOwogIG91dCA9IGkgPSAwOwogIG1heF9vdXQgPSAqb3V0cHV0X2xlbmd0aDsK
ICBiaWFzID0gaW5pdGlhbF9iaWFzOwoKICAvKiBIYW5kbGUgdGhlIGJhc2ljIGNv
ZGUgcG9pbnRzOiAgTGV0IGIgYmUgdGhlIG51bWJlciBvZiBpbnB1dCBjb2RlICov
CiAgLyogcG9pbnRzIGJlZm9yZSB0aGUgbGFzdCBkZWxpbWl0ZXIsIG9yIDAgaWYg
dGhlcmUgaXMgbm9uZSwgdGhlbiAgICAqLwogIC8qIGNvcHkgdGhlIGZpcnN0IGIg
Y29kZSBwb2ludHMgdG8gdGhlIG91dHB1dC4gICAgICAgICAgICAgICAgICAgICAg
Ki8KCiAgZm9yIChiID0gaiA9IDA7ICBqIDwgaW5wdXRfbGVuZ3RoOyAgKytqKSBp
ZiAoZGVsaW0oaW5wdXRbal0pKSBiID0gajsKICBpZiAoYiA+IG1heF9vdXQpIHJl
dHVybiBwdW55Y29kZV9iaWdfb3V0cHV0OwoKICBmb3IgKGogPSAwOyAgaiA8IGI7
ICArK2opIHsKICAgIGlmIChjYXNlX2ZsYWdzKSBjYXNlX2ZsYWdzW291dF0gPSBm
bGFnZ2VkKGlucHV0W2pdKTsKICAgIGlmICghYmFzaWMoaW5wdXRbal0pKSByZXR1
cm4gcHVueWNvZGVfYmFkX2lucHV0OwogICAgb3V0cHV0W291dCsrXSA9IGlucHV0
W2pdOwogIH0KCiAgLyogTWFpbiBkZWNvZGluZyBsb29wOiAgU3RhcnQganVzdCBh
ZnRlciB0aGUgbGFzdCBkZWxpbWl0ZXIgaWYgYW55ICAqLwogIC8qIGJhc2ljIGNv
ZGUgcG9pbnRzIHdlcmUgY29waWVkOyBzdGFydCBhdCB0aGUgYmVnaW5uaW5nIG90
aGVyd2lzZS4gKi8KCiAgZm9yIChpbiA9IGIgPiAwID8gYiArIDEgOiAwOyAgaW4g
PCBpbnB1dF9sZW5ndGg7ICArK291dCkgewoKICAgIC8qIGluIGlzIHRoZSBpbmRl
eCBvZiB0aGUgbmV4dCBjaGFyYWN0ZXIgdG8gYmUgY29uc3VtZWQsIGFuZCAqLwog
ICAgLyogb3V0IGlzIHRoZSBudW1iZXIgb2YgY29kZSBwb2ludHMgaW4gdGhlIG91
dHB1dCBhcnJheS4gICAgICovCgogICAgLyogRGVjb2RlIGEgZ2VuZXJhbGl6ZWQg
dmFyaWFibGUtbGVuZ3RoIGludGVnZXIgaW50byBkZWx0YSwgICovCiAgICAvKiB3
aGljaCBnZXRzIGFkZGVkIHRvIGkuICBUaGUgb3ZlcmZsb3cgY2hlY2tpbmcgaXMg
ZWFzaWVyICAgKi8KICAgIC8qIGlmIHdlIGluY3JlYXNlIGkgYXMgd2UgZ28sIHRo
ZW4gc3VidHJhY3Qgb2ZmIGl0cyBzdGFydGluZyAqLwogICAgLyogdmFsdWUgYXQg
dGhlIGVuZCB0byBvYnRhaW4gZGVsdGEuICAgICAgICAgICAgICAgICAgICAgICAg
ICovCgogICAgZm9yIChvbGRpID0gaSwgdyA9IDEsIGsgPSBiYXNlOyAgOyAgayAr
PSBiYXNlKSB7CiAgICAgIGlmIChpbiA+PSBpbnB1dF9sZW5ndGgpIHJldHVybiBw
dW55Y29kZV9iYWRfaW5wdXQ7CiAgICAgIGRpZ2l0ID0gZGVjb2RlX2RpZ2l0KGlu
cHV0W2luKytdKTsKICAgICAgaWYgKGRpZ2l0ID49IGJhc2UpIHJldHVybiBwdW55
Y29kZV9iYWRfaW5wdXQ7CiAgICAgIGlmIChkaWdpdCA+IChtYXhpbnQgLSBpKSAv
IHcpIHJldHVybiBwdW55Y29kZV9vdmVyZmxvdzsKICAgICAgaSArPSBkaWdpdCAq
IHc7CiAgICAgIHQgPSBrIDw9IGJpYXMgLyogKyB0bWluICovID8gdG1pbiA6ICAg
ICAvKiArdG1pbiBub3QgbmVlZGVkICovCiAgICAgICAgICBrID49IGJpYXMgKyB0
bWF4ID8gdG1heCA6IGsgLSBiaWFzOwogICAgICBpZiAoZGlnaXQgPCB0KSBicmVh
azsKICAgICAgaWYgKHcgPiBtYXhpbnQgLyAoYmFzZSAtIHQpKSByZXR1cm4gcHVu
eWNvZGVfb3ZlcmZsb3c7CiAgICAgIHcgKj0gKGJhc2UgLSB0KTsKICAgIH0KCiAg
ICBiaWFzID0gYWRhcHQoaSAtIG9sZGksIG91dCArIDEsIG9sZGkgPT0gMCk7Cgog
ICAgLyogaSB3YXMgc3VwcG9zZWQgdG8gd3JhcCBhcm91bmQgZnJvbSBvdXQrMSB0
byAwLCAgICovCiAgICAvKiBpbmNyZW1lbnRpbmcgbiBlYWNoIHRpbWUsIHNvIHdl
J2xsIGZpeCB0aGF0IG5vdzogKi8KCiAgICBpZiAoaSAvIChvdXQgKyAxKSA+IG1h
eGludCAtIG4pIHJldHVybiBwdW55Y29kZV9vdmVyZmxvdzsKICAgIG4gKz0gaSAv
IChvdXQgKyAxKTsKICAgIGkgJT0gKG91dCArIDEpOwoKICAgIC8qIEluc2VydCBu
IGF0IHBvc2l0aW9uIGkgb2YgdGhlIG91dHB1dDogKi8KCiAgICAvKiBub3QgbmVl
ZGVkIGZvciBQdW55Y29kZTogKi8KICAgIC8qIGlmIChkZWNvZGVfZGlnaXQobikg
PD0gYmFzZSkgcmV0dXJuIHB1bnljb2RlX2ludmFsaWRfaW5wdXQ7ICovCiAgICBp
ZiAob3V0ID49IG1heF9vdXQpIHJldHVybiBwdW55Y29kZV9iaWdfb3V0cHV0OwoK
ICAgIGlmIChjYXNlX2ZsYWdzKSB7CiAgICAgIG1lbW1vdmUoY2FzZV9mbGFncyAr
IGkgKyAxLCBjYXNlX2ZsYWdzICsgaSwgb3V0IC0gaSk7CiAgICAgIC8qIENhc2Ug
b2YgbGFzdCBjaGFyYWN0ZXIgZGV0ZXJtaW5lcyB1cHBlcmNhc2UgZmxhZzogKi8K
ICAgICAgY2FzZV9mbGFnc1tpXSA9IGZsYWdnZWQoaW5wdXRbaW4gLSAxXSk7CiAg
ICB9CgogICAgbWVtbW92ZShvdXRwdXQgKyBpICsgMSwgb3V0cHV0ICsgaSwgKG91
dCAtIGkpICogc2l6ZW9mICpvdXRwdXQpOwogICAgb3V0cHV0W2krK10gPSBuOwog
IH0KCiAgKm91dHB1dF9sZW5ndGggPSBvdXQ7CiAgcmV0dXJuIHB1bnljb2RlX3N1
Y2Nlc3M7Cn0KCg==

------------EDFrsLJYXzCRYqmgNDIw9l
Content-Disposition: attachment; filename=tounicode.c
Content-Type: application/octet-stream; name=tounicode.c
Content-Transfer-Encoding: Base64

I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxsYW5naW5mby5oPgojaW5jbHVk
ZSA8bG9jYWxlLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPGljb252
Lmg+CiNpbmNsdWRlIDxlcnJuby5oPgoKLyoKICogcmZjMzQ5Mi5jIGlzIGNvbnNp
c3RzIG9mIEFwcGVuZGl4IEMgb2YgUkZDIDM0OTIsIGV4Y2x1ZGluZyB0aGUgJ1dy
YXBwZXIgZm9yCiAqIHRlc3RpbmcnCiAqLwojaW5jbHVkZSAicmZjMzQ5Mi5jIgoK
dm9pZAptYWluKCkKewojZGVmaW5lIEJVRlNJWkUgMjU2CgljaGFyICpsY19jdHlw
ZTsKCWljb252X3QgY2QsIGRjOwoJY2hhciBpYnVmW0JVRlNJWkVdLCBwYnVmW0JV
RlNJWkVdOwoJcHVueWNvZGVfdWludCBvYnVmW0JVRlNJWkVdOwoJY29uc3QgY2hh
ciAqaWJ1ZnA7CgljaGFyICpvYnVmcDsKCXB1bnljb2RlX3VpbnQgc3osIGlubGVm
dCwgb3V0bGVmdCwgaW5sZW4sIG91dGxlbjsKCWludCBidWZ1c2VkLCBpOwoJaW50
ICoqdWJ1ZiA9IChpbnQqKikmb2J1ZjsKCWNoYXIgKmluY29kZSwqb3V0Y29kZT0i
VVRGLTMyIjsKCWVudW0gcHVueWNvZGVfc3RhdHVzIHN0YXR1czsKCglpZiAoKGxj
X2N0eXBlID0gZ2V0ZW52KCJMQ19DVFlQRSIpKSA9PSBOVUxMKQoJCWxjX2N0eXBl
ID0gZ2V0ZW52KCJMQU5HIik7CglmcHJpbnRmKHN0ZGVyciwgImxvY2FsZSAlc1xu
Iiwgc2V0bG9jYWxlKExDX0NUWVBFLCBsY19jdHlwZSkpOwoJaW5jb2RlID0gbmxf
bGFuZ2luZm8oQ09ERVNFVCk7CglmcHJpbnRmKHN0ZGVyciwgIiVzIHRvICVzXG4i
LCBpbmNvZGUsIG91dGNvZGUpOwoJY2QgPSBpY29udl9vcGVuKG91dGNvZGUsIGlu
Y29kZSk7CglpZiAoY2QgPT0gKGljb252X3QpLTEpIHsKICAgICAgICAgICAgIC8q
CiAgICAgICAgICAgICAgKiBpY29udl9vcGVuIGZhaWxlZAogICAgICAgICAgICAg
ICovCgkJKHZvaWQpIGZwcmludGYoc3RkZXJyLAoJCQkgICAgICAiaWNvbnZfb3Bl
biglcywgJXMpIGZhaWxlZFxuIiwgb3V0Y29kZSwgaW5jb2RlKTsKCQlwZXJyb3Io
IiIpOwoJCWV4aXQgKC0xKTsKCX0KCWRjID0gaWNvbnZfb3BlbihpbmNvZGUsIG91
dGNvZGUpOwoJaWYgKGRjID09IChpY29udl90KS0xKSB7CiAgICAgICAgICAgICAv
KgogICAgICAgICAgICAgICogaWNvbnZfb3BlbiBmYWlsZWQKICAgICAgICAgICAg
ICAqLwoJCSh2b2lkKSBmcHJpbnRmKHN0ZGVyciwKCQkJICAgICAgImljb252X29w
ZW4oJXMsICVzKSBmYWlsZWRcbiIsIG91dGNvZGUsIGluY29kZSk7CgkJcGVycm9y
KCIiKTsKCQlleGl0ICgtMSk7Cgl9CglpYnVmcCA9ICJcbiI7IGlubGVmdCA9IDE7
IG9idWZwID0gKGNoYXIgKikmb2J1ZlswXTsgb3V0bGVmdCA9IEJVRlNJWkU7Cglz
eiA9IGljb252KGNkLCAmaWJ1ZnAsICZpbmxlZnQsICZvYnVmcCwgJm91dGxlZnQp
OwoJCS8qIGJlY2F1c2UgaWNvbnYgbGlrZXMgdG8gZ2VuZXJhdGUgYSBVK0ZFRkYg
MXN0IGNhbGwgKi8KCXdoaWxlICgoYnVmdXNlZCA9IHJlYWQoMCxpYnVmLEJVRlNJ
WkUpKSkgewoJCWlidWZbYnVmdXNlZC0xXSA9IE5VTEw7CgkJaWJ1ZnAgPSAmaWJ1
ZlswXTsKCQlpbmxlZnQgPSBidWZ1c2VkLTE7CgkJb2J1ZnAgPSAoY2hhciAqKSZv
YnVmWzBdOwoJCW91dGxlZnQgPSBCVUZTSVpFOwoJCXN6ID0gaWNvbnYoY2QsICZp
YnVmcCwgJmlubGVmdCwgJm9idWZwLCAmb3V0bGVmdCk7CgkJaWYgKHN6PT0oc2l6
ZV90KS0xKSB7CgkJCXBlcnJvcigiIik7CgkJCWV4aXQoLTEpOwoJCX0KCQlvdXRs
ZW4gPSAoQlVGU0laRS1vdXRsZWZ0KS80OwoJCWZvciAoaT0wOyBpPG91dGxlbjsg
aSsrKSB7CgkJCXByaW50ZigiVSslMDR4XG4iLCBvYnVmW2ldKTsKCQl9CgoJCS8q
IGVuY29kZSBpdCBpbnRvIHB1bnlvZGUgKi8KCgkJaW5sZW4gPSBCVUZTSVpFLTE7
CgkJc3RhdHVzID0gcHVueWNvZGVfZW5jb2RlKG91dGxlbiwgb2J1ZiwgTlVMTCwg
JmlubGVuLCBwYnVmKTsKCQlzd2l0Y2ggKHN0YXR1cykgewoJCQljYXNlIHB1bnlj
b2RlX2JhZF9pbnB1dDoKCQkJCWZwcmludGYoc3RkZXJyLCAiQ0FOJ1QgSEFQUEVO
XG4iKTsKCQkJCWV4aXQoLTEpIDs7CgkJCWNhc2UgcHVueWNvZGVfYmlnX291dHB1
dDoKCQkJCWZwcmludGYoc3RkZXJyLCAiT3V0IGJ1ZmZlciB0b28gc21hbGxcbiIp
OwoJCQkJZXhpdCgtMSkgOzsKCQkJY2FzZSBwdW55Y29kZV9vdmVyZmxvdzoKCQkJ
CWZwcmludGYoc3RkZXJyLCAiUHVueWNvZGUgT3ZlcmZsb3dcbiIpOwoJCQkJZXhp
dCgtMSkgOzsKCQkJY2FzZSBwdW55Y29kZV9zdWNjZXNzOiA7OwoJCX0KCQlwYnVm
W2lubGVuXSA9IE5VTEw7CgkJcHJpbnRmKCJcbiVzXG5cbiIsIHBidWYpOwoKCQkv
KiBub3cgY29udmVydCBpdCBiYWNrIGFnYWluICovCgoJCW91dGxlbiA9IEJVRlNJ
WkUtMTsKCQlzdGF0dXMgPSBwdW55Y29kZV9kZWNvZGUoc3RybGVuKHBidWYpLCBw
YnVmLCAmb3V0bGVuLCBvYnVmLCBOVUxMKTsKCQlzd2l0Y2ggKHN0YXR1cykgewoJ
CQljYXNlIHB1bnljb2RlX2JhZF9pbnB1dDoKCQkJCWZwcmludGYoc3RkZXJyLCAi
SW52YWxpZCBwdW55Y29kZSBzdHJpbmdcbiIpOwoJCQkJZXhpdCgtMSkgOzsKCQkJ
Y2FzZSBwdW55Y29kZV9iaWdfb3V0cHV0OgoJCQkJZnByaW50ZihzdGRlcnIsICJP
dXQgYnVmZmVyIHRvbyBzbWFsbFxuIik7CgkJCQlleGl0KC0xKSA7OwoJCQljYXNl
IHB1bnljb2RlX292ZXJmbG93OgoJCQkJZnByaW50ZihzdGRlcnIsICJQdW55Y29k
ZSBPdmVyZmxvd1xuIik7CgkJCQlleGl0KC0xKSA7OwoJCQljYXNlIHB1bnljb2Rl
X3N1Y2Nlc3M6IDs7CgkJfQoJCWZvciAoaT0wOyBpPG91dGxlbjsgaSsrKSB7CgkJ
CXByaW50ZigiVSslMDR4XG4iLCBvYnVmW2ldKTsKCQl9CgoJCS8qIGFuZCBwdXQg
aXQgYmFjayBpbnRvIG91ciBsb2NhbGUgKi8KCgkJaW5sZWZ0ID0gQlVGU0laRS0x
OwoJCWlidWZwID0gKGNoYXIgKikmb2J1ZlswXTsgb2J1ZnAgPSAmaWJ1ZlswXTsK
CQlzeiA9IGljb252KGRjLCAmaWJ1ZnAsICZvdXRsZW4sICZvYnVmcCwgJmlubGVm
dCk7CgkJaWJ1ZltpbmxlZnRdID0gTlVMTDsKCQlwcmludGYoIlxuJXNcblxuIiwg
aWJ1Zik7Cgl9Cn0K
------------EDFrsLJYXzCRYqmgNDIw9l
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

------------EDFrsLJYXzCRYqmgNDIw9l--





From ima-bounces@ietf.org Sun Jul 16 10:18:37 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G27S7-0007wL-4O; Sun, 16 Jul 2006 10:18:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G27S5-0007vc-6V
	for ima@ietf.org; Sun, 16 Jul 2006 10:18:33 -0400
Received: from lon-mail-1.gradwell.net ([193.111.201.125])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G27Ex-00007Y-W8
	for ima@ietf.org; Sun, 16 Jul 2006 10:05: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-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.226) id
	44ba478a.58f2.2fff for ima@ietf.org; Sun, 16 Jul 2006 15:04:58 +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 k6GE4unB024927
	for <ima@ietf.org>; Sun, 16 Jul 2006 15:04:57 +0100 (BST)
Date: Sun, 16 Jul 2006 15:04:55 +0100
To: "ima@ietf.org" <ima@ietf.org>
Subject: Re: [EAI] ATOMIC or not
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
	<020101c6a52f$ca3f2660$b30110ac@edmontr3>
	<p06300012c0d9e269fecb@[142.131.134.210]>
	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>
	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>
	<03c201c6a607$a68936b0$b30110ac@edmontr3>
	<44B6AA85.2040601@att.com>
	<066901c6a7b7$26e121a0$b30110ac@edmontr3>
	<44B9ACA7.2030402@icu.ac.kr>
	<06e601c6a887$a815a540$b30110ac@edmontr3>
	<1268539184.20060715222211@pobox.com>
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.tcsb2hr76hl8nm@clerew.man.ac.uk>
In-Reply-To: <1268539184.20060715222211@pobox.com>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
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 Sun, 16 Jul 2006 06:22:11 +0100, Bill McQuillan <McQuilWP@pobox.com>  
wrote:

> On Sat, 2006-07-15, Edmon Chung wrote:
>
>> 4. Therefore I think it may be premature to write off the atomic  
>> parameter.
>
> Let me say it one more time!
>
> LET'S GET RID OF BOTH ALT-ADDR AND ATOMIC.
>
> If there is a guaranteed reversable Local Part ACE which can be  
> recognized
> by some sort of flag (like xn-- in IDN) then why is there a need for
> anything else?

Because, for the man without UTF8smtp who wants to send mail to you, your  
ACEd address is bloody incomprehensible. A random collection of characters  
that you will have trouble even copying down onto a piece of paper without  
error, and which you will certainly never carry in your head.

The whole point of current email addresses is that, to a speaker of the  
relevant language, they appear to be meaningful and memorable. The whole  
purpose of this endeavour is to extend that happy state to those whose  
language cannot be expressed decently in ASCII. Now you are asking us to  
accept a system which puts the ASCII speaker in a worse state than the  
non-ASCII people used to be in. And you call that progress?

-- 
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 Jul 16 20:20:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G2Gqw-0003PM-LP; Sun, 16 Jul 2006 20:20:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Gqv-0003PH-6Z
	for ima@ietf.org; Sun, 16 Jul 2006 20:20:49 -0400
Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2Gqs-0005q3-T6
	for ima@ietf.org; Sun, 16 Jul 2006 20:20:49 -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-1.csi.cam.ac.uk ([131.111.8.51]:43233)
	by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G2Gqn-00046G-4A (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 17 Jul 2006 01:20:41 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1G2Gqn-000593-8O (Exim 4.53)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 17 Jul 2006 01:20:41 +0100
Date: Mon, 17 Jul 2006 01:20:41 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Edmon Chung <edmon@afilias.info>
Subject: Re: [EAI] ATOMIC or not
In-Reply-To: <066901c6a7b7$26e121a0$b30110ac@edmontr3>
Message-ID: <Pine.LNX.4.64.0607170116490.15380@hermes-1.csi.cam.ac.uk>
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
	<020101c6a52f$ca3f2660$b30110ac@edmontr3>
	<p06300012c0d9e269fecb@[142.131.134.210]>
	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>
	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>
	<03c201c6a607$a68936b0$b30110ac@edmontr3> <44B6AA85.2040601@att.com>
	<066901c6a7b7$26e121a0$b30110ac@edmontr3>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
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 Fri, 14 Jul 2006, Edmon Chung wrote:
>
> However, my point is if "ATOMIC" as a parameter is never transported,
> then there is no need for a standardized way to create an ACE
> representation of a UT8 address.  Because each MUA can use any method of
> transformation to an alt-address they want and the protocol would still
> function without any problem.  Because in no place would the
> infrastructure attempt to up/down-convert the address.

That isn't true: the down-conversion happens at the MUA when it creates
the alt-address and the up-conversion happens in the MDA when it delivers
the message. These two have to agree on the algorithm, so it must be
standardized.

> When EAIuser1 sends to EAIuser2, even if it provided the ALT-ADDRESS (no
> matter whether it was converted using an algorithm, because without the
> ATOMIC information we cannot assume it is)
>
> WHEN EAIuser after a few weeks tries to initiate an email to EAIuser1
> and ASCIIuserA together, it will not be able to successfully send to
> ASCIIuserA because the header downgrade could not happen for the field
> containing EAIuser1's address.

Why not? EAIuser2 has EAIuser1's alt-address.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
DOVER WIGHT PORTLAND PLYMOUTH BISCAY: NORTHEASTERLY 4 OR 5, BECOMING VARIABLE
3 AT TIMES. FAIR. MODERATE OR GOOD.

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



From ima-bounces@ietf.org Sun Jul 16 20:38:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G2H8M-00040u-Va; Sun, 16 Jul 2006 20:38:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G2H8K-00040p-W9
	for ima@ietf.org; Sun, 16 Jul 2006 20:38:48 -0400
Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2H8J-00076n-Js
	for ima@ietf.org; Sun, 16 Jul 2006 20:38:48 -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-1.csi.cam.ac.uk ([131.111.8.51]:43873)
	by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G2H8G-0003Pg-Uw (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 17 Jul 2006 01:38:44 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1G2H8G-0006Vj-HD (Exim 4.53)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 17 Jul 2006 01:38:44 +0100
Date: Mon, 17 Jul 2006 01:38:44 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Charles Lindsey <chl@clerew.man.ac.uk>
Subject: Re: [EAI] ATOMIC or not
In-Reply-To: <op.tcsb2hr76hl8nm@clerew.man.ac.uk>
Message-ID: <Pine.LNX.4.64.0607170123140.15380@hermes-1.csi.cam.ac.uk>
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
	<020101c6a52f$ca3f2660$b30110ac@edmontr3>
	<p06300012c0d9e269fecb@[142.131.134.210]>
	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>
	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>
	<03c201c6a607$a68936b0$b30110ac@edmontr3> <44B6AA85.2040601@att.com>
	<066901c6a7b7$26e121a0$b30110ac@edmontr3> <44B9ACA7.2030402@icu.ac.kr>
	<06e601c6a887$a815a540$b30110ac@edmontr3>
	<1268539184.20060715222211@pobox.com>
	<op.tcsb2hr76hl8nm@clerew.man.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
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

On Sun, 16 Jul 2006, Charles Lindsey wrote:
> On Sun, 16 Jul 2006 06:22:11 +0100, Bill McQuillan <McQuilWP@pobox.com> wrote:
> >
> > LET'S GET RID OF BOTH ALT-ADDR AND ATOMIC.

I mostly agree. I particularly agree about the bad impact on non-email
protocols.

> > If there is a guaranteed reversable Local Part ACE which can be
> > recognized by some sort of flag (like xn-- in IDN) then why is there a
> > need for anything else?
>
> Because, for the man without UTF8smtp who wants to send mail to you,
> your ACEd address is bloody incomprehensible.

People already have informal ways of using multiple email addresses, and
these will continue to be sufficient for an ascii user sending to a utf8
user's alt-address, without protocol extensions.

Elegant downgrading of email from a utf8 user to an ascii user is more
interesting, but downgrading to an elegant alt-address can be entirely
handled at the 822 level. The 821 downgrade can be purely algorithmic.
(This would also solve the problem of representing the alt-addresses and
downgradability flags of other email addresses in the envelope, such as
ORCPT parameters.)

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
SOLE: NORTHEASTERLY 3 OR 4. FAIR. MODERATE OR GOOD, WITH FOG PATCHES AT FIRST.

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



From ima-bounces@ietf.org Mon Jul 17 05:08:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G2P5Q-0000HX-Bc; Mon, 17 Jul 2006 05:08:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G2FKk-0003BF-NT
	for ima@ietf.org; Sun, 16 Jul 2006 18:43:30 -0400
Received: from c-24-19-162-247.hsd1.wa.comcast.net ([24.19.162.247]
	helo=nicemice.net) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G2FKi-0002cG-Sc for ima@ietf.org; Sun, 16 Jul 2006 18:43:30 -0400
Received: from amc by nicemice.net with local (Exim 4.61)
	(envelope-from <return.amc+0+@nicemice.net>)
	id 1G2FKf-00062k-VD; Sun, 16 Jul 2006 15:43:25 -0700
Date: Sun, 16 Jul 2006 22:43:25 +0000
From: "Adam M. Costello" <ima.amc+0+@nicemice.net.RemoveThisWord>
To: Charles Lindsey <chl@clerew.man.ac.uk>
Subject: Re: [EAI] The Worms of Punycode
Message-ID: <20060716224325.GA19977@nicemice.net>
References: <op.tcsbkyto6hl8nm@clerew.man.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <op.tcsbkyto6hl8nm@clerew.man.ac.uk>
User-Agent: Mutt/1.5.11+cvs20060403
X-Spam-Score: 0.2 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
X-Mailman-Approved-At: Mon, 17 Jul 2006 05:08:19 -0400
Cc: ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ima@ietf.org
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 haven't been following this mailing list (too busy with other things),
but the word Punycode in the subject line caught my eye.

Charles Lindsey <chl@clerew.man.ac.uk> wrote:

> RFC 3492 is incredibly badly written (essentially, it describes the
> protocol bottom-up, which means you cannot begin to understand the
> significance of any of its many concepts until you have already worked
> out what they all do without the slightest idea of what each is trying
> to achieve).

Sorry, I guess I'm better at precision than clarity.  I would be glad
to discuss the algorithm, the pseudocode, the C code, and ways to
improve the document.  There was a draft-costello-rfc3492bis-02, which
is still available (minus the RFC boilerplate) here:

http://www.nicemice.net/idn/

Follow the link to the "slightly clarified version".  The clarifications
really are slight, but suggestions for more are welcome.

> Firstly, it is NOT an encoding algorithm.  It is essentially a
> compression algorithm which just happens to produce an output composed
> entirely of ASCII (or, to be more precise, of <atext>s).

The second statement is correct, but I don't see how it implies the
first.  Would you claim that Huffman coding is not an encoding?

> The algorithm is normatively defined using a pseudocode, but there is
> also a model implementation in C set out in Appendix C, which purports
> to achieve the effects defined by the pseudocode. But the model omits
> some features (checks) defined by the pseudocode which are provably
> unnecessary,

The pseudocode puts {braces} around checks that might not be needed,
and the C code puts /* comment delimiters */ around the corresponding
checks.

By the way, the C code in the slightly clarified draft has a cleaner
interface (inspired by GNU libidn) and slightly clearer comments.

> but OTOH it also introduces some additional "features" not present in
> the pseudocode.

Yes, the case_flags.  If you pass in NULL for case_flags, the C code
will behave exactly like the pseudocode.  The case_flags are an
implementation of the mixed-case annotation described in appendix A.

> The algorithm was designed to work in an environment where the input
> had already been preprocessed, e.g. by Nameprep.

It was designed to be more general than that. "Although the only
restriction Punycode imposes on the input integers is that they be
nonnegative,these parameters are especially designed to work well with
Unicode [UNICODE] code points".  The input doesn't have to be Nameprep'd
or even valid Unicode, and you'll still get it back unscathed.

> But as regards case folding, it needs to be recognised that RFC 3492
> is written in the expectation that cases will have been folded, and
> hence it contains remarks (non-normative) which are misleading unless
> you appreciate where it is coming from.

Please tell me which remarks are misleading; I'd like to clarify them.

> In fact, the normative algorithm defined by the pseudocode is
> completely blind to case (and hence is in fact perfectly suited to
> our purpose). Not so the model implementation (and one expects that
> many implementors are going to use that model implementation without
> necessarily understanding it). The model implementation is indeed
> aware of "case" - it's those afforementioned "features", and therefore
> it is necessary to understand how to turn them "off".

The only added feature is mixed-case annotation (from appendix A), which
can be turned off by passing NULL for case_flags.  I've added a todo
item to clarify that in the comments in the C code.

> In fact, the model implementation is only aware of case in ASCII
> characters. Thus it knows that "E" and "e" are two versions of the
> same letter, but it is totally unaware that "�" and "�" are related
> in any way.  So the first bit of good news is that those two will
> be correctly translated into Punycode whatever happens (and the
> only reason this does not confuse the present IDNA (which is case
> insensitive) is that the preprocessing by Nameprep will have already
> got rid of any "�").

Yes, in IDNA, case insensitivity is handled entirely by Nameprep, not by
Punycode.

> Conclusion: the underlying Punycode algorithm will copy               
> case-sensitively perfectly satisfactorily (even using their model     
> implementation)                                                       

Right.  I designed Punycode to work for case-sensitive text,
case-insensitive text, and case-insensitive case-preserving text.  IDNA
cares only about the second category (although it could be extended to
use the third).  The mixed-case annotation is applicable only to the
third category.

> *in*spite* of the attempts by the authors of RFC 3492 to confuse you
> into believing otherwise -:( .

Sorry for the confusion.  How could this be made clearer?

> In IDNA, the longest component of a domain name can have only
> 63 characters; moreover the range of Unicode Codepoints is
> (0..10FFFF). With those restrictions, you can show that overflow
> will never happen if you do your arithmetic with 26-bit unsigned
> arithmetic (well, that's what they say, but from their formula I make
> it 27-bits).

You probably didn't take into account that 4 of the 63 bytes are
consumed by the ACE prefix, so an ACE label cannot represent more than
59 code points.

(0x10FFFF - 128) * (59 + 1) = 66838980
                    1 << 26 = 67108864

> We have to indicate that Punycode has been applied. In IDNA, this
> is done by prefixing it with 'xn--'. We are agreed that we need a
> different prefix for <local-part>s.

Yes, if you don't apply Nameprep, then you definitely need a different
prefix.  Even if you did apply Nameprep, you might still want to use
a different prefix (think about what happens when domain names are
embedded in local parts, or when email addresses are embedded in domain
labels).

> The IDNA prefix was chosen because it could not possibly be a legal
> domain name.

All we knew was that it did not exist in the second level under the
gTLDs.  We had no assurance for the ccTLDs, nor for the gTLDs at any
levels below the second.

AMC

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



From ima-bounces@ietf.org Mon Jul 17 15:15:08 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G2YYW-0000qc-Of; Mon, 17 Jul 2006 15:15:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G2YYV-0000qW-Op
	for ima@ietf.org; Mon, 17 Jul 2006 15:14:59 -0400
Received: from mail02.afilias.info ([69.46.107.12] helo=mail00.afilias.info)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2YYU-0006xW-FT
	for ima@ietf.org; Mon, 17 Jul 2006 15:14:59 -0400
Received: from edmontr3 (cm222-166-211-169.hkcable.com.hk [222.166.211.169])
	(authenticated bits=0)
	by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id k6HJEdTc002617
	for <ima@ietf.org>; Mon, 17 Jul 2006 15:14:49 -0400
Message-ID: <089a01c6a9d5$42fd1bd0$b30110ac@edmontr3>
From: "Edmon Chung" <edmon@afilias.info>
To: <ima@ietf.org>
Date: Mon, 17 Jul 2006 15:11:53 -0400
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Virus-Scanned: ClamAV 0.88/1600/Sat Jul 15 11:03:46 2006 on
	mail00.afilias.info
X-Virus-Status: Clean
X-Spam-Status: No, score=3.5 required=5.0 tests=MIME_BASE64_TEXT,
	RCVD_IN_SORBS_DUL autolearn=no version=3.1.1
X-Spam-Level: ***
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on mail00.afilias.info
X-Envelope-To: <ima@ietf.org>
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Subject: [EAI] adjusting framework?...
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>
Content-Type: multipart/mixed; boundary="===============1312051516=="
Errors-To: ima-bounces@ietf.org

--===============1312051516==
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

SXQgc2VlbXMgbGlrZSB0aGVyZSBpcyBpbnRlcmVzdCBwZXJoYXBzIGZvciBsb29raW5nIGF0IGFk
anVzdGluZyB0aGUgZnJhbWV3b3JrIG9yIGFwcHJvYWNoIGFyY2hpdGVjdHVyZS4uLiBoZXJlIGlz
IGEgdmVyeSBicmllZiBzdW1tYXJ5IG9mIHdoYXQgSSB0aGluayBJIGFtIGhlYXJpbmcgKG9uIFNN
VFAgb25seSBmb3Igbm93KToNCg0KRUFJLWF3YXJlIE1UQS9NVUEgLS1zZW5kLXRvLS0+IEVBSS1h
d2FyZSBNVEENCi0gZW52ZWxvcGU6IFVURjggYWRkcmVzc2VzDQotIGhlYWRlcnM6IFVURjggaGVh
ZGVycw0KDQpFQUktYXdhcmUgTVRBL01VQSAtLXNlbmQtdG8tLT4gbm9uLUVBSS1hd2FyZSBNVEEN
Ci0gZW52ZWxvcGU6IEVBSS1BQ0UgYWRkcmVzc2VzDQotIGhlYWRlcnM6IHJld3JpdGUgd2l0aCBF
QUktQUNFIGFuZCBNSU1FDQotIGVuY2Fwc3VsYXRlZCBkb3duZ3JhZGUgaW5mbyBpbiBuZXcgTUlN
RSBjb250ZW50IHR5cGUNCg0KKGFzIGNvbXBhcmlzb24sIGFuIG91dGxpbmUgb2YgdGhlIGN1cnJl
bnQgZnJhbWV3b3JrIGFzIEkgdW5kZXJzdGFuZCBpdCBpcyBpbmNsdWRlZCBmdXJ0aGVyIGJlbG93
KQ0KSW4gdGhlIGFib3ZlLCBuZWl0aGVyIEFUT01JQyBvciBBTFQtQUREUkVTUyBpcyByZXF1aXJl
ZC4gIEhvd2V2ZXIgaXQgYXNzdW1lcyB0aGF0IHRoZXJlIGlzIGdvaW5nIHRvIGJlIGEgc3RhbmRh
cmQgdW5pdmVyc2FsbHkgcmV2ZXJzaWJsZSBFQUktQUNFLiAgQW4gImltcHJvdmVtZW50IiB3aXRo
IHRoaXMgZnJvbSB0aGUgY3VycmVudCBmcmFtZXdvcmsgaXMgdGhhdCB0aGUgcHJvdG9jb2wgZG9l
cyBub3QgY3JlYXRlIGEgc2NlbmFyaW8gd2hlcmVieSB0aGUgZXhpc3RlbmNlL3VzZSBvZiBhbiBp
MThuZW1haWwgYWRkcmVzcyBjYXVzZXMgYSBmYWlsdXJlL2JvdW5jZSBiYWNrICh3aGVyZWFzIHRo
ZSBjdXJyZW50IGZyYW1ld29yayBkb2VzIC0tPiBpLmUuIHdoZW4gZG93bmdyYWRlIGluZm8gaXMg
bm90IGF2YWlsYWJsZS4uLiBpLmUuIHdoZW4gbmVpdGhlciBBVE9NSUMgb3IgQUxULUFERFJFU1Mg
aW5mbyBpcyBhdmFpbGFibGUpLg0KDQoNCkkgaG93ZXZlciBhY3R1YWxseSBsaWtlIHRoZSBBTFQt
QUREUkVTUyBmZWF0dXJlIHRob3VnaC4uLiBzbyBpZiBwb3NzaWJsZSBJIHdvdWxkIHByb3Bvc2Ug
dGhlIGZvbGxvd2luZzoNCg0KRUFJLWF3YXJlIE1UQSAtLXNlbmQtdG8tLT4gRUFJLWF3YXJlIE1U
QQ0KLSBlbnZlbG9wZTogVVRGOCBhZGRyZXNzZXMgV0lUSCBPUFRJT05BTCBwYXJhbWV0ZXIgdG8g
c3BlY2lmeSBBTFQtQUREUkVTUw0KLSBoZWFkZXJzOiBVVEY4IGhlYWRlcnMgV0lUSCBPUFRJT05B
TCBwYXJhbWV0ZXIgdG8gc3BlY2lmeSBBTFQtQUREUkVTUw0KDQpFQUktYXdhcmUgTVRBIC0tc2Vu
ZC10by0tPiBub24tRUFJLWF3YXJlIE1UQQ0KSUYgYWx0LWFkZHJlc3MgaW5mbyBpcyBhdmFpbGFi
bGUsIFRIRU46DQotIGVudmVsb3BlOiBBTFQtQUREUkVTUw0KLSBoZWFkZXJzOiByZXdyaXRlIHdp
dGggQUxULUFERFJFU1MgYW5kIE1JTUUNCi0gZW5jYXBzdWxhdGVkIGRvd25ncmFkZSBpbmZvIGlu
IG5ldyBNSU1FIGNvbnRlbnQgdHlwZQ0KRUxTRToNCi0gZW52ZWxvcGU6IEVBSS1BQ0UgYWRkcmVz
cw0KLSBoZWFkZXJzOiByZXdyaXRlIHdpdGggRUFJLUFDRSBhbmQgTUlNRSBhZGRyZXNzZXMNCi0g
ZW5jYXBzdWxhdGVkIGRvd25ncmFkZSBpbmZvIGluIG5ldyBNSU1FIGNvbnRlbnQgdHlwZQ0KDQpU
aGlzIGFwcHJvYWNoIGFsc28gYXNzdW1lcyB0aGF0IGEgc3RhbmRhcmQgdW5pdmVyc2FsbHkgcmV2
ZXJzaWJsZSBFQUktQUNFIGlzIGRlc2lnbmVkLg0KDQpUaGUgYmlnIHF1ZXN0aW9uIGhvd2V2ZXIg
aXMgd2hvIHdpbGwgZGVzaWduIHRoaXMgRUFJLUFDRT8gIEEgZmV3IGhhdmUgc3RhdGVkIGl0IHNo
b3VsZCBiZSBwb3NzaWJsZSwgYWxzbyB0aGVyZSB3ZXJlIHNvbWUgd2hvIHdlcmUgc3VzcGljb3Vz
IHRoYXQgaXQgY291bGQgYmUgZG9uZS4uLg0KDQoNCkVkbW9uDQoNCg0KDQoNClBTLiAgSnVzdCBm
b3IgY29tcGFyaXNvbiwgdGhlIGZvbGxvd2luZyBpcyB3aGF0IEkgdW5kZXJzdGFuZCB0aGUgZXhp
c3RpbmcgZnJhbWV3b3JrIHRvIGJlOg0KDQpFQUktYXdhcmUgTVRBL01VQSAtLXNlbmQtdG8tLT4g
RUFJLWF3YXJlIE1UQQ0KLSBlbnZlbG9wZTogVVRGOCBhZGRyZXNzZXMgd2l0aCBPUFRJT05BTCBw
YXJhbWV0ZXIgZm9yIHNwZWNpZnlpbmc6IEFUT01JQyBvciBBTFQtQUREUkVTUw0KLSBoZWFkZXJz
OiBVVEY4IGhlYWRlcnMgd2l0aCBPUFRJT05BTCBwYXJhbWV0ZXIgZm9yIHNwZWNpZnlpbmc6IEFU
T01JQyBvciBBTFQtQUREUkVTUw0KDQpFQUktYXdhcmUgTVRBL01VQSAtLXNlbmQtdG8tLT4gbm9u
LUVBSS1hd2FyZSBNVEENCklGIEFUTU9JQyA9IHllcywgVEhFTjoNCi0gZW52ZWxvcGU6IEVBSS1B
Q0UgYWRkcmVzcw0KLSBoZWFkZXJzOiByZXdyaXRlIHdpdGggRUFJLUFDRSBhbmQgTUlNRSBhZGRy
ZXNzZXMNCi0gZW5jYXBzdWxhdGVkIGRvd25ncmFkZSBpbmZvIGluIG5ldyBNSU1FIGNvbnRlbnQg
dHlwZQ0KRUxTRSBJRiBhbHQtYWRkcmVzcyBpbmZvIGlzIGF2YWlsYWJsZSwgVEhFTjoNCi0gZW52
ZWxvcGU6IEFMVC1BRERSRVNTDQotIGhlYWRlcnM6IHJld3JpdGUgd2l0aCBBTFQtQUREUkVTUyBh
bmQgTUlNRQ0KLSBlbmNhcHN1bGF0ZWQgZG93bmdyYWRlIGluZm8gaW4gbmV3IE1JTUUgY29udGVu
dCB0eXBlDQpFTFNFOg0KLSBib3VuY2UgbWFpbCAvIHNlbmQgZmFpbHVyZSAoZG93bmdyYWRlIGNh
bm5vdCBiZSBwZXJmb3JtZWQpDQoNCg0KRHVyaW5nIHRoZSBNb250cmVhbCBtZWV0aW5nLCB0aGUg
Zm9sbG93aW5nIHdhcyBlc3NlbnRpYWxseSBzdWdnZXN0ZWQ6DQoNCkVBSS1hd2FyZSBNVEEvTVVB
IC0tc2VuZC10by0tPiBFQUktYXdhcmUgTVRBDQotIGVudmVsb3BlOiBVVEY4IGFkZHJlc3NlcyB3
aXRoIE9QVElPTkFMIHBhcmFtZXRlciB0byBzcGVjaWZ5IEFMVC1BRERSRVNTDQotIGhlYWRlcnM6
IFVURjggaGVhZGVycyB3aXRoIE9QVElPTkFMIHBhcmFtZXRlciB0byBzcGVjaWZ5IEFMVC1BRERS
RVNTDQoNCkVBSS1hd2FyZSBNVEEvTVVBIC0tc2VuZC10by0tPiBub24tRUFJLWF3YXJlIE1UQQ0K
SUYgYWx0LWFkZHJlc3MgaW5mbyBpcyBhdmFpbGFibGUsIFRIRU46DQotIGVudmVsb3BlOiBBTFQt
QUREUkVTUw0KLSBoZWFkZXJzOiByZXdyaXRlIHdpdGggQUxULUFERFJFU1MgYW5kIE1JTUUNCi0g
ZW5jYXBzdWxhdGVkIGRvd25ncmFkZSBpbmZvIGluIG5ldyBNSU1FIGNvbnRlbnQgdHlwZQ0KRUxT
RToNCi0gYm91bmNlIG1haWwgLyBzZW5kIGZhaWx1cmUgKGRvd25ncmFkZSBjYW5ub3QgYmUgcGVy
Zm9ybWVkKQ0KDQo=




--===============1312051516==
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

--===============1312051516==--



From ima-bounces@ietf.org Mon Jul 17 16:49:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G2a2E-0006Pl-M7; Mon, 17 Jul 2006 16:49:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G2a2D-0006Pg-1A
	for ima@ietf.org; Mon, 17 Jul 2006 16:49:45 -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 1G2a2B-0001db-Fv
	for ima@ietf.org; Mon, 17 Jul 2006 16:49:45 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34) id 1G2a26-000MbD-Ug
	for ima@ietf.org; Mon, 17 Jul 2006 16:49:39 -0400
Date: Mon, 17 Jul 2006 16:49:37 -0400
From: John C Klensin <klensin@jck.com>
To: ima@ietf.org
Message-ID: <ABB9194807A82B5A510776A7@p3.JCK.COM>
In-Reply-To: <06e601c6a887$a815a540$b30110ac@edmontr3>
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
	<020101c6a52f$ca3f2660$b30110ac@edmontr3>
	<p06300012c0d9e269fecb@[142.131.134.210]>
	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>
	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>
	<03c201c6a607$a68936b0$b30110ac@edmontr3>
	<44B6AA85.2040601@att.com>
	<066901c6a7b7$26e121a0$b30110ac@edmontr3>
	<44B9ACA7.2030402@icu.ac.kr>
	<06e601c6a887$a815a540$b30110ac@edmontr3>
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: bdc523f9a54890b8a30dd6fd53d5d024
Subject: [EAI] Downgrading addresses and the scope of this WG
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.

My apologies -- I was busy enough with other things during the
balance of the IETF meeting that I could sometimes follow this
thread, but not step in.    It seems to me, after reading the
thread,   that two topics are being discussed:

(1) Whether there is an algorithmic mechanism by which any
local-part can be encoded.  If there is -- and some postings in
this thread assume it is -- then any address can be downgraded
using that algorithm and indicating parameters are not needed.
That issue has been debated at length.  It is discussed in
draft-klensin-ima-constraints-00.txt, which is deliberately not
a WG document (but does need upgrading), was discussed when the
WG charter was reviewed, and was discussed extensively before
that.   The summary of the answer is that no such encoding is
possible without violating the "no one interprets addresses
before the delivery MTA" rule and, in some cases, without loss
of information.   There is a bit more flexibility in that
direction when the encoding and decoding are done my MTAs than
in a model that, for many people, seems to follow logically,
which is to do everything in the MUAs, abandoning the notion of
non-ASCII addresses on the wire entirely.  

The reasons for avoiding those approaches from a human interface
and readability standpoint have been discussed by others.  The
technical one is that it cannot be done without loss of
functionality and, for some MTA designs, making this model much
more difficult to implement than it needs to be.   In addition,
it is out of scope: the WG was carefully chartered to follow a
particular approach through to see if it was feasible, including
targeting Experimental documents and implementations, than to
explore the entire possible space of i18n solutions.

Those who are interested in one of the other approaches in that
space are welcome to get organized and propose it.   If it is
simpler and works for as broad a range of cases without
unacceptable constraints, unacceptable assumptions, or
unacceptably bad behavior when older systems (MUAs or MTAs) are
encountered, I assume it will prevail.   But it is not in scope
to try to transform this work into one of those approaches.


(2) View ATOMIC simply as a matter of specifying, presumably
between the originating MUA and submission server, a particular
transformation that would yield only an ALT-ADDRESS in SMTP
transport.   In that model --which is what I heard proposed at
the meeting-- there would be only two cases on the wire:

	(i) ALT-ADDRESS would be specified so that, if a
	downgrade-requiring situation were encountered, the
	ALT-ADDRESS would be substituted as usual.
	
	(ii) ALT-ADDRESS would not be specified.  If a
	downgrade-requiring situation is encountered, the
	message bounces.

In that model, "ATOMIC" (which is probably mis-named for this
case) would be an assertion to the submission MTA that it knew
how to make up an ALT-ADDRESS and place it into the envelope and
should do so.  That strikes me as potentially very useful for
the reverse path address(es), i.e., on the MAIL command and
possibly less so for the forward-pointing addresses.  In the
latter case, the submission MTA probably really doesn't know
what transformation to apply, but that is the case for ATOMIC as
defined in the current documents as well.  And, of course, if
the submission MTA does not take on that role, then there is no
way to specify an ASCII address  in the originating MUA other
than in something that maps directly to ALT-ADDRESS.

There seemed to be considerable support for the second view in
last week's discussion although I'm not sure I consider it
strong enough to be definitive (independent of the need for
ratification on the mailing list).   But I hope we can focus our
discussion on it and not get distracted by various "just convert
local-parts to some agreed-upon ACE always or whenever they
might be needed" approaches.

      john


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



From ima-bounces@ietf.org Tue Jul 18 13:59:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G2trB-0003OF-60; Tue, 18 Jul 2006 13:59:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G2tr9-0003O8-Nz
	for ima@ietf.org; Tue, 18 Jul 2006 13:59: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 1G2tr7-00022J-AT
	for ima@ietf.org; Tue, 18 Jul 2006 13:59: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-1.csi.cam.ac.uk ([131.111.8.51]:46638)
	by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G2tr4-0001JC-Ty (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 18 Jul 2006 18:59:34 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1G2tr4-0000pl-7l (Exim 4.53)
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 18 Jul 2006 18:59:34 +0100
Date: Tue, 18 Jul 2006 18:59:34 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: John C Klensin <klensin@jck.com>
Subject: Re: [EAI] Downgrading addresses and the scope of this WG
In-Reply-To: <ABB9194807A82B5A510776A7@p3.JCK.COM>
Message-ID: <Pine.LNX.4.64.0607181747010.14969@hermes-1.csi.cam.ac.uk>
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
	<020101c6a52f$ca3f2660$b30110ac@edmontr3>
	<p06300012c0d9e269fecb@[142.131.134.210]>
	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>
	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>
	<03c201c6a607$a68936b0$b30110ac@edmontr3> <44B6AA85.2040601@att.com>
	<066901c6a7b7$26e121a0$b30110ac@edmontr3> <44B9ACA7.2030402@icu.ac.kr>
	<06e601c6a887$a815a540$b30110ac@edmontr3>
	<ABB9194807A82B5A510776A7@p3.JCK.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
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, 17 Jul 2006, John C Klensin wrote:
>
> (1) Whether there is an algorithmic mechanism by which any local-part
> can be encoded. [...] The summary of the answer is that no such encoding
> is possible without violating the "no one interprets addresses before
> the delivery MTA" rule and, in some cases, without loss of information.

It's wrong to say that making all UTF8 addresses algorithmically
downgradable breaks the opacity rule to the same extent as MUA-only IMA.

We can add only one global requirement for local parts which applies only
to UTF8 local parts, which is that they may be downgraded to ASCII
algorithmically. ASCII local parts (downgraded or not) will remain opaque
to everything other than their domain's email agents. In particular,
only the message delivery infrastructure of the domain will ever do the
reverse mapping (not even the users's MUA). The new requirement only
applies to the new kind of local part that the new specifications are
introducing. Existing stuff is not affected.

It isn't clear to me whether the WG is specifying a system that allows
reversible downgrading, such that a UTF8 user can email another UTF8 user
through non-EAI infrastructure. The charter does not seem to include
upgrading but some of the documents discuss it: e.g. -downgrade says an
MUA MUST upgrade downgraded messages. Is this upgrading limited to
replacing MIME encoding with UTF8, or does it include recovery of the
downgraded UTF8 addresses? If the latter, the WG is effectively on a path
towards an MUA-only IMA solution.

With the former (limited) upgrading, it is only capable of matching
impedance between an ASCII sender and a UTF8 recipient, since
upgraded-downgraded UTF8-to-UTF8 email loses information. It's OK to lose
information when downgrading a message from a UTF8 user to an ASCII user
because the lost information (the UTF8 email address) is of no use to the
ASCII user. I see no problem with this.

> (2) View ATOMIC simply as a matter of specifying, presumably
> between the originating MUA and submission server, a particular
> transformation that would yield only an ALT-ADDRESS in SMTP
> transport.

The motivation for getting rid of the ATOMIC option is to simplify the
SMTP extension. If we get rid of it entirely, the ACE-downgradable flag
would be only for the MUA's information, so that it can derive an
alt-address for use when submitting the message over SMTP.

I see no point in keeping the atomic flag for submission only, because
that makes things more complicated, not less!

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
HUMBER THAMES: EAST OR NORTHEAST 4 OR 5, OCCASIONALLY 6 IN THAMES. FAIR.
MODERATE OR GOOD.

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



From ima-bounces@ietf.org Wed Jul 19 05:56:56 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G38nQ-0008DK-8k; Wed, 19 Jul 2006 05:56:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G38nO-0008DF-Kw
	for ima@ietf.org; Wed, 19 Jul 2006 05:56:46 -0400
Received: from lon-mail-3.gradwell.net ([193.111.201.127])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G38nL-0006Et-R5
	for ima@ietf.org; Wed, 19 Jul 2006 05:56:46 -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.227) id
	44be01d6.cfab.1a2; Wed, 19 Jul 2006 10:56:38 +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 k6J9uXnN005045;
	Wed, 19 Jul 2006 10:56:36 +0100 (BST)
To: "Tony Finch" <dot@dotat.at>, "John C Klensin" <klensin@jck.com>
Subject: Re: [EAI] Downgrading addresses and the scope of this WG
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
	<020101c6a52f$ca3f2660$b30110ac@edmontr3>
	<p06300012c0d9e269fecb@[142.131.134.210]>
	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>
	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>
	<03c201c6a607$a68936b0$b30110ac@edmontr3>
	<44B6AA85.2040601@att.com>
	<066901c6a7b7$26e121a0$b30110ac@edmontr3>
	<44B9ACA7.2030402@icu.ac.kr>
	<06e601c6a887$a815a540$b30110ac@edmontr3>
	<ABB9194807A82B5A510776A7@p3.JCK.COM>
	<Pine.LNX.4.64.0607181747010.14969@hermes-1.csi.cam.ac.uk>
Message-ID: <op.tcxkkicm6hl8nm@clerew.man.ac.uk>
Date: Wed, 19 Jul 2006 10:56:32 +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.0607181747010.14969@hermes-1.csi.cam.ac.uk>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
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, 18 Jul 2006 18:59:34 +0100, Tony Finch <dot@dotat.at> wrote:


> It isn't clear to me whether the WG is specifying a system that allows
> reversible downgrading, such that a UTF8 user can email another UTF8 user
> through non-EAI infrastructure.

I think that was one of the scenarios that was regarded as less important  
than the others, though nobody will object if people implement things so  
that it works.

In that case, the final delivery agent may have to upgrade an ACEd address  
(supposing the ACEd form makes no sense to it). If it makes sense after  
upgrading, then it can go ahead with final delivery. If not, or if it  
cannot be bothered to try the upgrade, then it will bounce. But all that  
was already true in the case where an Atomic parameter had been provided,  
so it is hardly new. But I think all other upgrading should be left to the  
MUA, or maybe to the POP3 or IMAP agent.

> Is this upgrading limited to
> replacing MIME encoding with UTF8, or does it include recovery of the
> downgraded UTF8 addresses? If the latter, the WG is effectively on a path
> towards an MUA-only IMA solution.

Not quite, because you still need a UTF8smtp-capable MTA. Yes, there may  
be a way of using our system for MUA-only IMA in particular situations,  
but the whole idea was to make life much simpler for EAI to EAI  
communications (which will be the bulk of the traffic and will just use  
UTF-8 in headers without further thought). But of course most of out  
discussions have been about ameliorating the 5% of traffic where non-EAI  
agents (including senders and recipients) are involved. But don't let that  
tail wag the whole dog.


> The motivation for getting rid of the ATOMIC option is to simplify the
> SMTP extension. If we get rid of it entirely, the ACE-downgradable flag
> would be only for the MUA's information, so that it can derive an
> alt-address for use when submitting the message over SMTP.

Well I hope I have now shown that a fully reversible ACE using Punycode is  
feasible, provided some care is taken. So that reduces the need for an  
explicit ATOMIC option.
>
> I see no point in keeping the atomic flag for submission only, because
> that makes things more complicated, not less!

Please (I have asked this before) can someone provide a realistic example  
where it would be necessary to use "Atomic=no"? Especially if the ACE was  
fully rebersible.

-- 
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 Jul 19 06:42:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G39Vb-0004x6-I5; Wed, 19 Jul 2006 06:42:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G39Va-0004tG-SU
	for ima@ietf.org; Wed, 19 Jul 2006 06:42:26 -0400
Received: from sniper.icu.ac.kr ([210.107.128.51])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G39VY-0006d9-Vk
	for ima@ietf.org; Wed, 19 Jul 2006 06:42:26 -0400
Received: (snipe 32759 invoked by uid 0); 19 Jul 2006 19:42:27 +0900
Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.020499
	secs); 
Received: from unknown (HELO ?220.69.185.49?) (Z???own@220.69.185.49)
	by unknown with SMTP; 19 Jul 2006 19:42:27 +0900
X-RCPTTO: chl@clerew.man.ac.uk, dot@dotat.at, klensin@jck.com, ima@ietf.org
Message-ID: <44BE0C8E.5030909@icu.ac.kr>
Date: Wed, 19 Jul 2006 19:42:22 +0900
From: Yangwoo Ko <newcat@icu.ac.kr>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Charles Lindsey <chl@clerew.man.ac.uk>
Subject: Re: [EAI] Downgrading addresses and the scope of this WG
References: <011201c6a513$5636a020$b30110ac@edmontr3>	<p0630000bc0d9b50c344b@[142.131.134.210]>	<020101c6a52f$ca3f2660$b30110ac@edmontr3>	<p06300012c0d9e269fecb@[142.131.134.210]>	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>	<03c201c6a607$a68936b0$b30110ac@edmontr3>	<44B6AA85.2040601@att.com>	<066901c6a7b7$26e121a0$b30110ac@edmontr3>	<44B9ACA7.2030402@icu.ac.kr>	<06e601c6a887$a815a540$b30110ac@edmontr3>	<ABB9194807A82B5A510776A7@p3.JCK.COM>	<Pine.LNX.4.64.0607181747010.14969@hermes-1.csi.cam.ac.uk>
	<op.tcxkkicm6hl8nm@clerew.man.ac.uk>
In-Reply-To: <op.tcxkkicm6hl8nm@clerew.man.ac.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
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


Charles Lindsey wrote:
> (snip)
>> The motivation for getting rid of the ATOMIC option is to simplify the
>> SMTP extension. If we get rid of it entirely, the ACE-downgradable flag
>> would be only for the MUA's information, so that it can derive an
>> alt-address for use when submitting the message over SMTP.
> 
> Well I hope I have now shown that a fully reversible ACE using Punycode 
> is feasible, provided some care is taken. So that reduces the need for 
> an explicit ATOMIC option.

People seem to feel the size of needed care quite differently. If that
"some" is not that big and the implementation of the care in code and
in practice is technically feasible even with mixture of EAI-unaware
components, we may end up with an MUA-only solution discussed at IMAA
mailing list some time ago. Even though this is the case, the pursue
of that solution is clearly out of EAI WG's scope.

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



From ima-bounces@ietf.org Wed Jul 19 07:36:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3ALg-0006of-A3; Wed, 19 Jul 2006 07:36:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ALf-0006oa-UI
	for ima@ietf.org; Wed, 19 Jul 2006 07:36:15 -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 1G3ALf-00036W-0T
	for ima@ietf.org; Wed, 19 Jul 2006 07:36:15 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1G3ALX-000764-5n; Wed, 19 Jul 2006 07:36:07 -0400
Date: Wed, 19 Jul 2006 07:36:06 -0400
From: John C Klensin <klensin@jck.com>
To: Charles Lindsey <chl@clerew.man.ac.uk>, Tony Finch <dot@dotat.at>
Subject: Re: [EAI] Downgrading addresses and the scope of this WG
Message-ID: <789BA04D8FA4A98850B87CBA@p3.JCK.COM>
In-Reply-To: <op.tcxkkicm6hl8nm@clerew.man.ac.uk>
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
	<020101c6a52f$ca3f2660$b30110ac@edmontr3>
	<p06300012c0d9e269fecb@[142.131.134.210]>
	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>
	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>
	<03c201c6a607$a68936b0$b30110ac@edmontr3>
	<44B6AA85.2040601@att.com>
	<066901c6a7b7$26e121a0$b30110ac@edmontr3>
	<44B9ACA7.2030402@icu.ac.kr>
	<06e601c6a887$a815a540$b30110ac@edmontr3>
	<ABB9194807A82B5A510776A7@p3.JCK.COM>
	<Pine.LNX.4.64.0607181747010.14969@hermes-1.csi.cam.ac.uk>
	<op.tcxkkicm6hl8nm@clerew.man.ac.uk>
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: 6640e3bbe8a4d70c4469bcdcbbf0921d
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 Wednesday, 19 July, 2006 10:56 +0100 Charles Lindsey
<chl@clerew.man.ac.uk> wrote:

> On Tue, 18 Jul 2006 18:59:34 +0100, Tony Finch <dot@dotat.at>
> wrote:
> 
> 
>> It isn't clear to me whether the WG is specifying a system
>> that allows reversible downgrading, such that a UTF8 user can
>> email another UTF8 user through non-EAI infrastructure.
> 
> I think that was one of the scenarios that was regarded as
> less important  than the others, though nobody will object if
> people implement things so  that it works.

It was not viewed as "less important".  It was viewed as
unfeasible unless...

	(1) We restrict the range of address formats and uses of
	addresses that were possible in non-ASCII local parts to
	be considerably narrower than those in ASCII local
	parts.  Proposals for such reductions include (i) no
	embedded information at all, (ii) embedded information
	that is separated by standardized delimiters that are
	enumerated by the standard and don't change (probably
	ASCII-only) ones, (iii) embedded information that either
	depends on a list of ASCII delimiters (as in (ii)) or
	that uses a lexical method to identify the delimiters.
	Information embedded using non-delimiter characters or
	subfield lengths known to the receiving system would be
	prohibited by all methods that have been identified.
	
	(2) We impose a de facto restriction on receiving MTA
	implementations that required that they decode the
	transfer encoding of addresses before taking any other
	actions to analyse or process addresses.  Doing things
	this way would be easy and natural for some now-valid
	MTA implementations; it would require completely
	redesigning and reimplementing others in order for them
	to conform.
	
	(3) We require that all implementations support
	upgrading (to UTF-8 addresses) as well as downgrading
	(from UTF-8 addresses to the transport, all-ASCII,
	form), rather than UTF-8 passthrough on a model similar
	to the 8BITMIME model.
	
	(4) We accept the possibility (actually, the certainty),
	that the transport-encoded addresses will leak into
	user-visible contexts.

	(5) We ignore the possibility, nay likelihood, that any
	lexical, in-band, mechanism we devise for encoding an
	address local part will be treated as a valid address in
	some systems.  If a user sends out a UTF-8 address that
	is known to work, and gets back a 550 "no such mailbox"
	code because the address was encoded and no appropriate
	decoder (or alias) existed, he or she is likely to be
	very unhappy... with us.

Now, if our goal was to do something quickly in order to claim
that we had done _something_, those restrictions and
requirements might be plausible.  I suggest that cannot be our
goal: it almost certainly would lead to our having to do a
second design and implementation (or to having someone else do
it) to gain user acceptance.   In particular, each of the
restrictions above should be considered a showstopper:

(1) Effectively makes email with non-ACII local parts a
second-class facility, without the range of capabilities
available in mail with ASCII-only addresses.  I don't consider
that acceptable from a technical standpoint and it would
certainly not be acceptable, long-term, from a cultural or
political one.   Note that since many systems route mail (or
determine how and where they are placed in message stores) based
on information encoded in addresses, getting the MTA out of the
act entirely (as we did with MIME if 7bit transport was used) is
not feasible without even more serious restrictions.

(2) and (3) make the functionality significantly harder to
implement and deploy in practice.  If our goal is rapid
implementation and deployment of conforming and interoperable
implementations, then it is in our interest to keep the
practical implementation costs as low as possible.   We know
that, for a number of significant MTAs that are 8bit clean,
implementation of the basic SMTP extension mechanism with UTF-8
addresses consists largely of disabling existing checks and
restrictions when the option is present.  Turning the
implementation requirement into "complete restructuring" for
even a few implementations is not in our interest unless it is
absolutely necessary, nor is turning downgrade models that
inevitably will require dealing with edge cases in sensitive
code from an option into a requirement.

And (4) and (5) will not be user-acceptable and will just lead
to demands for another approach.  We have already seen problems
with IDNs in which users, expecting to see their own scripts,
have seen punycode instead and objected.  The problem in terms
of user perceptions with email addresses is _much_ worse and,
because of the differences between email model (in which sender
and receiver are basically peers that may not be connected to
each other and that may have different naming conventions) and
the DNS model (in which the registry operator deposits a string
in a database that is queried by the resolver) make it much more
difficult to intelligently report the causes of problems to
users.

>...
> Not quite, because you still need a UTF8smtp-capable MTA. Yes,
> there may  be a way of using our system for MUA-only IMA in
> particular situations,  but the whole idea was to make life
> much simpler for EAI to EAI  communications (which will be the
> bulk of the traffic and will just use  UTF-8 in headers
> without further thought). But of course most of out
> discussions have been about ameliorating the 5% of traffic
> where non-EAI  agents (including senders and recipients) are
> involved. But don't let that  tail wag the whole dog.

I think this is key.  It is also important to remember that the
percentage of cases in which EAI messages will encounter non-EAI
agents will drop over time due to both increasing support for
EAI and entirely predictable user behavior in the presence of
downgrading or bouncing.  Building and carrying around a complex
and expensive arrangement in order to optimize for those cases,
an arrangement that we will need to keep in place even after it
has become unnecessary, is just bad systems engineering.

> Well I hope I have now shown that a fully reversible ACE using
> Punycode is  feasible, provided some care is taken. So that
> reduces the need for an  explicit ATOMIC option.

You have demonstrated no such thing, at least in the absence of
the above restrictions.

regards,
    john


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



From ima-bounces@ietf.org Wed Jul 19 14:08:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3GTf-0005Ij-Ch; Wed, 19 Jul 2006 14:08:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3GTe-0005Ie-GJ
	for ima@ietf.org; Wed, 19 Jul 2006 14:08:54 -0400
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3GTc-0003uO-24
	for ima@ietf.org; Wed, 19 Jul 2006 14:08: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-1.csi.cam.ac.uk ([131.111.8.51]:49759)
	by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G3GTV-0006Ng-2N (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Wed, 19 Jul 2006 19:08:45 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1G3GTV-0004nf-LX (Exim 4.53)
	(return-path <fanf2@hermes.cam.ac.uk>); Wed, 19 Jul 2006 19:08:45 +0100
Date: Wed, 19 Jul 2006 19:08:45 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: John C Klensin <klensin@jck.com>
Subject: Re: [EAI] Downgrading addresses and the scope of this WG
In-Reply-To: <789BA04D8FA4A98850B87CBA@p3.JCK.COM>
Message-ID: <Pine.LNX.4.64.0607191840140.14969@hermes-1.csi.cam.ac.uk>
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
	<020101c6a52f$ca3f2660$b30110ac@edmontr3>
	<p06300012c0d9e269fecb@[142.131.134.210]>
	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>
	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>
	<03c201c6a607$a68936b0$b30110ac@edmontr3> <44B6AA85.2040601@att.com>
	<066901c6a7b7$26e121a0$b30110ac@edmontr3> <44B9ACA7.2030402@icu.ac.kr>
	<06e601c6a887$a815a540$b30110ac@edmontr3>
	<ABB9194807A82B5A510776A7@p3.JCK.COM>
	<Pine.LNX.4.64.0607181747010.14969@hermes-1.csi.cam.ac.uk>
	<op.tcxkkicm6hl8nm@clerew.man.ac.uk>
	<789BA04D8FA4A98850B87CBA@p3.JCK.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
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 Wed, 19 Jul 2006, John C Klensin wrote:
>On Wed, 19 Jul 2006, Charles Lindsey wrote:
>>On Tue, 18 Jul 2006, Tony Finch wrote:
>>>
>>> It isn't clear to me whether the WG is specifying a system
>>> that allows reversible downgrading, such that a UTF8 user can
>>> email another UTF8 user through non-EAI infrastructure.
>>
>> I think that was one of the scenarios that was regarded as
>> less important  than the others, though nobody will object if
>> people implement things so  that it works.
>
> It was not viewed as "less important".  It was viewed as
> unfeasible unless...
>
> 	(4) We accept the possibility (actually, the certainty),
> 	that the transport-encoded addresses will leak into
> 	user-visible contexts.

This will happen if any algorithmic downgrading is part of the spec.

> 	(5) We ignore the possibility, nay likelihood, that any
> 	lexical, in-band, mechanism we devise for encoding an
> 	address local part will be treated as a valid address in
> 	some systems.  If a user sends out a UTF-8 address that
> 	is known to work, and gets back a 550 "no such mailbox"
> 	code because the address was encoded and no appropriate
> 	decoder (or alias) existed, he or she is likely to be
> 	very unhappy... with us.

This will happen if downgradability is optional.

> In particular, each of the restrictions above should be considered a
> showstopper [...]

Though 4 and 5 are consequences of the current plans.

Your "constraints" document talked a lot about punycoded domains but it
mostly seemed to be arguing that they provided a useful work-around for
untypable or unreadable IDNs, for people who can cope with latin letters
as a lowest common denominator. So I'm not sure it's a total disaster. In
any case, if encoded addresses only appear when exchanging email with
ascii users, and if users can specify a readable alt-address to be used in
preference, then this problem is much smaller.

I agree with your points 1 and 3. I would like some concrete examples of 2:
MTAs that have an architecture which makes decoding ACE local parts to
UTF8 impossible without huge amounts of work.

> It is also important to remember that the percentage of cases in which
> EAI messages will encounter non-EAI agents will drop over time due to
> both increasing support for EAI and entirely predictable user behavior
> in the presence of downgrading or bouncing.  Building and carrying
> around a complex and expensive arrangement in order to optimize for
> those cases, an arrangement that we will need to keep in place even
> after it has become unnecessary, is just bad systems engineering.

You are never going to be able to dispense with downgrade support, if
ESMTP deployment is any indicator. So I think the backwards compatibility
parts of the spec should be as simple as possible. They also need to be
simple enough that your average user can understand them, and if the new
feature is going to be deployable it must not screw up everyone's address
book, directory, browser mailto: handling, etc. etc.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
RATTRAY HEAD TO BERWICK ON TWEED: SOUTHEAST 3 OR 4, OCCASIONALLY 5 AT FIRST.
THUNDERY RAIN OR SHOWERS LATER VISIBILITY: MODERATE OR POOR WITH FOG PATCHES
SEA STATE: SLIGHT

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



From ima-bounces@ietf.org Wed Jul 19 14:54:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3HC5-0001Bx-N1; Wed, 19 Jul 2006 14:54:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3HC5-0001Bs-8d
	for ima@ietf.org; Wed, 19 Jul 2006 14:54:49 -0400
Received: from lon-mail-4.gradwell.net ([193.111.201.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3HC2-0001Vd-Hb
	for ima@ietf.org; Wed, 19 Jul 2006 14:54:49 -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.227) id
	44be7ff4.df9e.224c for ima@ietf.org; Wed, 19 Jul 2006 19:54:44 +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 k6JIsg0q008829
	for <ima@ietf.org>; Wed, 19 Jul 2006 19:54:43 +0100 (BST)
To: ima@ietf.org
Subject: Re: [EAI] Downgrading addresses and the scope of this WG
References: <011201c6a513$5636a020$b30110ac@edmontr3>
	<p0630000bc0d9b50c344b@[142.131.134.210]>
	<020101c6a52f$ca3f2660$b30110ac@edmontr3>
	<p06300012c0d9e269fecb@[142.131.134.210]>
	<036e01c6a5f3$2cb3ba90$b30110ac@edmontr3>
	<Pine.LNX.4.64.0607122213460.15380@hermes-1.csi.cam.ac.uk>
	<03c201c6a607$a68936b0$b30110ac@edmontr3>
	<44B6AA85.2040601@att.com>
	<066901c6a7b7$26e121a0$b30110ac@edmontr3>
	<44B9ACA7.2030402@icu.ac.kr>
	<06e601c6a887$a815a540$b30110ac@edmontr3>
	<ABB9194807A82B5A510776A7@p3.JCK.COM>
	<Pine.LNX.4.64.0607181747010.14969@hermes-1.csi.cam.ac.uk>
	<op.tcxkkicm6hl8nm@clerew.man.ac.uk>
	<789BA04D8FA4A98850B87CBA@p3.JCK.COM>
Message-ID: <op.tcx9hfkw6hl8nm@clerew.man.ac.uk>
Date: Wed, 19 Jul 2006 19:54:41 +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: <789BA04D8FA4A98850B87CBA@p3.JCK.COM>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
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, 19 Jul 2006 12:36:06 +0100, John C Klensin <klensin@jck.com> wrote:

> --On Wednesday, 19 July, 2006 10:56 +0100 Charles Lindsey
> <chl@clerew.man.ac.uk> wrote:

>> I think that was one of the scenarios that was regarded as
>> less important  than the others, though nobody will object if
>> people implement things so  that it works.
>
> It was not viewed as "less important".  It was viewed as
> unfeasible unless...
>
> 	(1) We restrict the range of address formats and uses of
> 	addresses that were possible in non-ASCII local parts to
> 	be considerably narrower than those in ASCII local
> 	parts.  Proposals for such reductions include (i) no
> 	embedded information at all, (ii) embedded information
> 	that is separated by standardized delimiters that are
> 	enumerated by the standard and don't change (probably
> 	ASCII-only) ones, (iii) embedded information that either
> 	depends on a list of ASCII delimiters (as in (ii)) or
> 	that uses a lexical method to identify the delimiters.
> 	Information embedded using non-delimiter characters or
> 	subfield lengths known to the receiving system would be
> 	prohibited by all methods that have been identified.

I totally fail to see the need for any such restrictions as you have  
suggested. Please give examples to illustrate the preceived problems.
> 	
> 	(2) We impose a de facto restriction on receiving MTA
> 	implementations that required that they decode the
> 	transfer encoding of addresses before taking any other
> 	actions to analyse or process addresses.  Doing things
> 	this way would be easy and natural for some now-valid
> 	MTA implementations; it would require completely
> 	redesigning and reimplementing others in order for them
> 	to conform.

They have, as always, the choice of decoding or of bouncing. Bearing in  
mind that it is an EAI-compliant final delivery agent that we are talking  
about, so presumably those are going to accept UTF8-local-parts. No such  
agents exist at the present time, so anyone contemplating providing one  
would do well to start from an existing system into which the decoding  
could easily be incorporated. Clearly, such agents must arrange that any  
local-part starting with "yn--" can never be a valid ASCII local-part in  
their system, but that does not seem an onerous burden.

But if they choose not to implement the upgrade for whatever reason, then  
they must instruct their users to publish Alt-Addresses. Or hey! Maybe  
they instruct their users to include "Atomic=n" (in whatever notation we  
provide), in which case you have possibly found at last a valid need for  
the "Atomic" parameter (though I don't find it a very convincing one).
> 	
> 	(3) We require that all implementations support
> 	upgrading (to UTF-8 addresses) as well as downgrading
> 	(from UTF-8 addresses to the transport, all-ASCII,
> 	form), rather than UTF-8 passthrough on a model similar
> 	to the 8BITMIME model.

We require no such thing (though we might strongly encourage it).
> 	
> 	(4) We accept the possibility (actually, the certainty),
> 	that the transport-encoded addresses will leak into
> 	user-visible contexts.

Yes, that is inevitable. But not a show stopper.
>
> 	(5) We ignore the possibility, nay likelihood, that any
> 	lexical, in-band, mechanism we devise for encoding an
> 	address local part will be treated as a valid address in
> 	some systems.  If a user sends out a UTF-8 address that
> 	is known to work, and gets back a 550 "no such mailbox"
> 	code because the address was encoded and no appropriate
> 	decoder (or alias) existed, he or she is likely to be
> 	very unhappy... with us.

No, he should be unhappy with his addressee for not giving him an  
Alt-Address, or for subscribing to a service with a less-than-optimal  
implementation. Or he should be unhappy with his own provider for routing  
the message through non-complient systems. Indeed, it is only likely to  
happen where one or other of the endpoints is unable to choose the  
intermediate agents (because one of them is inside some unforgiving  
firewall). But the solution is known, and market forces will soon ensure  
that it is applied where it is needed - no further need for action on our  
part.

> (2) and (3) make the functionality significantly harder to
> implement and deploy in practice.  If our goal is rapid
> implementation and deployment of conforming and interoperable
> implementations, then it is in our interest to keep the
> practical implementation costs as low as possible.

The main goal is to provide communication in a natural manner between  
speakers of the same language. Maybe 5% of all communications will have  
one end-point that is non-compliant. I would suppose that less than 0.5%  
would involve compliant end-points with non-compliant agents between. That  
could be a good argument for giving low priority to fixing that scenario,  
but it is not an argument for refusing to provide any mechanism at all.



> I think this is key.  It is also important to remember that the
> percentage of cases in which EAI messages will encounter non-EAI
> agents will drop over time due to both increasing support for
> EAI and entirely predictable user behavior in the presence of
> downgrading or bouncing.

Exactly. Once users begin to see it working, Market Forces will do the  
rest.

>> Well I hope I have now shown that a fully reversible ACE using
>> Punycode is  feasible, provided some care is taken. So that
>> reduces the need for an  explicit ATOMIC option.
>
> You have demonstrated no such thing, at least in the absence of
> the above restrictions.

I have demonstrated that Punycode, as defined, will take care of the  
encoding and decoding of any UTF-8 text (<3600 characters) in a reversible  
manner. Those using the model implementation (which goes beyind the strict  
definition of the algorithm) need to be warned of certain pitfalls. There  
is a need to specify some preprocessing (SASL-prep has been suggested, and  
is fine by me). So what have I not demonstrated?

-- 
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 Jul 19 16:46:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3Ivc-0003r3-PA; Wed, 19 Jul 2006 16:45:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Ivb-0003e4-6E
	for ima@ietf.org; Wed, 19 Jul 2006 16:45:55 -0400
Received: from mail120.messagelabs.com ([216.82.250.83])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3IvZ-0003qZ-Qp
	for ima@ietf.org; Wed, 19 Jul 2006 16:45:55 -0400
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-7.tower-120.messagelabs.com!1153341952!11129312!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 13699 invoked from network); 19 Jul 2006 20:45:52 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4)
	by server-7.tower-120.messagelabs.com with SMTP;
	19 Jul 2006 20:45:52 -0000
Received: from [135.210.78.6] (unknown[135.210.78.6](misconfigured sender))
	by maillennium.att.com (mailgw1) with ESMTP
	id <20060719204551gw1003jotte> (Authid: tony);
	Wed, 19 Jul 2006 20:45:52 +0000
Message-ID: <44BE99FF.5030104@att.com>
Date: Wed, 19 Jul 2006 16:45:51 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: ima@ietf.org
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Subject: [EAI] changing name of ATOMIC?
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 comment was made, sort of in passing, in a few other posts by other
people, but I think it's worth a thread of its own.

Can the concept ATOMIC be renamed to be something else, say
DOWNGRADEABLE? This question is irrespective of whether it's implemented
within the MUA or passed as an SMTP parameter.

The idea is that the i18n email address is allowed to be converted into
an ACE form.

Now consider the word "atomic". American Heritage defines it like this:

    1. Of or relating to an atom or atoms.
    2. Of or employing nuclear energy: an atomic submarine; atomic
       weapons.
    3. Very small; infinitesimal.

The closest definition seems to be 3, but it seems to be backward. If an
address *is* downgradeable, then it's not indivisible.

The name ATOMIC just doesn't grab me the same way or seem to imply the
same thing. Wouldn't DOWNGRADEABLE be a better name for this concept?

	Tony Hansen
	tony@att.com

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



From ima-bounces@ietf.org Wed Jul 19 18:57:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3KyO-0007Pq-JQ; Wed, 19 Jul 2006 18:56:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3KyN-0007Pl-Jz
	for ima@ietf.org; Wed, 19 Jul 2006 18:56:55 -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 1G3KyL-0001cn-7Q
	for ima@ietf.org; Wed, 19 Jul 2006 18:56:55 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1G3KyK-000ApS-Hy; Wed, 19 Jul 2006 18:56:52 -0400
Date: Wed, 19 Jul 2006 18:56:51 -0400
From: John C Klensin <klensin@jck.com>
To: Tony Hansen <tony@att.com>, ima@ietf.org
Subject: Re: [EAI] changing name of ATOMIC?
Message-ID: <11B3A11B70F6BED68B02823D@p3.JCK.COM>
In-Reply-To: <44BE99FF.5030104@att.com>
References: <44BE99FF.5030104@att.com>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
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 Wednesday, 19 July, 2006 16:45 -0400 Tony Hansen
<tony@att.com> wrote:

> This comment was made, sort of in passing, in a few other
> posts by other people, but I think it's worth a thread of its
> own.
>=20
> Can the concept ATOMIC be renamed to be something else, say
> DOWNGRADEABLE? This question is irrespective of whether it's
> implemented within the MUA or passed as an SMTP parameter.
>=20
> The idea is that the i18n email address is allowed to be
> converted into an ACE form.
>=20
> Now consider the word "atomic". American Heritage defines it
> like this:
>=20
>     1. Of or relating to an atom or atoms.
>     2. Of or employing nuclear energy: an atomic submarine;
> atomic        weapons.
>     3. Very small; infinitesimal.
>=20
> The closest definition seems to be 3, but it seems to be
> backward. If an address *is* downgradeable, then it's not
> indivisible.
>=20
> The name ATOMIC just doesn't grab me the same way or seem to
> imply the same thing. Wouldn't DOWNGRADEABLE be a better name
> for this concept?

I still hope to get rid of it, but agree that DOWNGRADEABLE
might be a better choice. =20

That said, "atomic" has a well-known definition in computer
science (and most good dictionaries), which is "indivisible"
(that is the derivation of at least the first of the definitions
you give, with the second presumably deriving from the first).
E.g., the Merriam-Webster Unabridged definition includes

		4 : being ultimate, logically simple, unanalyzable, or
		noncompound either actually or taken as such within a
		given universe of discourse **this is red* may be
		considered an atomic proposition*;  specifically   :
		without sentential connectives and variables =E2=80=94
		compare MONADIC

(Sorry, no time right now to key in the similar, but better, OED
definition.)

The term was chosen too quickly but precisely to convey the
flavor of having an address that did not contain subaddresses or
other sorts of components... hence one that could be subjected
to an ACE or similar encoding without risk of having internal
information that would be hidden at the wrong times.

    john


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



From ima-bounces@ietf.org Thu Jul 20 00:33:07 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3QDe-0004bt-6b; Thu, 20 Jul 2006 00:33:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3QDc-0004bW-1o
	for ima@ietf.org; Thu, 20 Jul 2006 00:33:00 -0400
Received: from mail126.messagelabs.com ([216.82.250.99])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3QDa-00046Z-Ns
	for ima@ietf.org; Thu, 20 Jul 2006 00:33:00 -0400
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-11.tower-126.messagelabs.com!1153369977!9804917!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 17204 invoked from network); 20 Jul 2006 04:32:57 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4)
	by server-11.tower-126.messagelabs.com with SMTP;
	20 Jul 2006 04:32:57 -0000
Received: from [135.210.96.159] (unknown[135.210.96.159](misconfigured sender))
	by maillennium.att.com (mailgw1) with ESMTP
	id <20060720043256gw1003jo1re> (Authid: tony);
	Thu, 20 Jul 2006 04:32:57 +0000
Message-ID: <44BF0777.5030009@att.com>
Date: Thu, 20 Jul 2006 00:32:55 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: ima@ietf.org
Subject: Re: [EAI] changing name of ATOMIC?
References: <44BE99FF.5030104@att.com> <11B3A11B70F6BED68B02823D@p3.JCK.COM>
In-Reply-To: <11B3A11B70F6BED68B02823D@p3.JCK.COM>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
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

Hmmm, from draft-ietf-eai-smtpext-00.txt:

	The "ATOMIC" has one of two values: y or n.  The parameter
	"ATOMIC" is designed to assert whether the address is atomic,
	which means that the primary address(IMA) can be safely
	transformed or converted to the respect ASCII email address via
	ACE (ASCII Compatible Encoding) if the value is 'y' or not if
	the value is 'n'.

I don't get what you describe below at all from there. That is, there
are some unstated assumptions that lie in the words "safely
transformed". One is the indivisibility you mention; another is that
there is going to be one true ACE conversion that can be applied. This
is all further evidence that the term ATOMIC would be better named
something else.

	Tony Hansen
	tony@att.com

John C Klensin wrote:
> 
> --On Wednesday, 19 July, 2006 16:45 -0400 Tony Hansen
> <tony@att.com> wrote:
> 
>> Can the concept ATOMIC be renamed to be something else, say
>> DOWNGRADEABLE? This question is irrespective of whether it's
>> implemented within the MUA or passed as an SMTP parameter.
>>
>> The idea is that the i18n email address is allowed to be
>> converted into an ACE form.
>> ...
> 
> I still hope to get rid of it, but agree that DOWNGRADEABLE
> might be a better choice.  
> ...
> 
> The term was chosen too quickly but precisely to convey the
> flavor of having an address that did not contain subaddresses or
> other sorts of components... hence one that could be subjected
> to an ACE or similar encoding without risk of having internal
> information that would be hidden at the wrong times.

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



From ima-bounces@ietf.org Thu Jul 20 03:00:41 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3SWO-0007NS-D7; Thu, 20 Jul 2006 03:00:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3SWN-0007LW-2G
	for ima@ietf.org; Thu, 20 Jul 2006 03:00:31 -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 1G3SWL-0001zV-Li
	for ima@ietf.org; Thu, 20 Jul 2006 03:00:31 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1G3SWK-000D6T-S4; Thu, 20 Jul 2006 03:00:29 -0400
Date: Thu, 20 Jul 2006 03:00:28 -0400
From: John C Klensin <klensin@jck.com>
To: Tony Hansen <tony@att.com>, ima@ietf.org
Subject: Re: [EAI] changing name of ATOMIC?
Message-ID: <BA075597C5AAC51473EA992F@p3.JCK.COM>
In-Reply-To: <44BF0777.5030009@att.com>
References: <44BE99FF.5030104@att.com>
	<11B3A11B70F6BED68B02823D@p3.JCK.COM> <44BF0777.5030009@att.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: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
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

As I tried to say, I was trying to explain the choice of term,
not to defend it -- the term was chosen very quickly and was not
expected to last even as long as it has.   A change seems
entirely in order.

    john


--On Thursday, 20 July, 2006 00:32 -0400 Tony Hansen
<tony@att.com> wrote:

> Hmmm, from draft-ietf-eai-smtpext-00.txt:
> 
> 	The "ATOMIC" has one of two values: y or n.  The parameter
> 	"ATOMIC" is designed to assert whether the address is atomic,
> 	which means that the primary address(IMA) can be safely
> 	transformed or converted to the respect ASCII email address
> via 	ACE (ASCII Compatible Encoding) if the value is 'y' or
> not if 	the value is 'n'.
> 
> I don't get what you describe below at all from there. That
> is, there are some unstated assumptions that lie in the words
> "safely transformed". One is the indivisibility you mention;
> another is that there is going to be one true ACE conversion
> that can be applied. This is all further evidence that the
> term ATOMIC would be better named something else.
> 
> 	Tony Hansen
> 	tony@att.com
> 
> John C Klensin wrote:
>> 
>> --On Wednesday, 19 July, 2006 16:45 -0400 Tony Hansen
>> <tony@att.com> wrote:
>> 
>>> Can the concept ATOMIC be renamed to be something else, say
>>> DOWNGRADEABLE? This question is irrespective of whether it's
>>> implemented within the MUA or passed as an SMTP parameter.
>>> 
>>> The idea is that the i18n email address is allowed to be
>>> converted into an ACE form.
>>> ...
>> 
>> I still hope to get rid of it, but agree that DOWNGRADEABLE
>> might be a better choice.  
>> ...
>> 
>> The term was chosen too quickly but precisely to convey the
>> flavor of having an address that did not contain subaddresses
>> or other sorts of components... hence one that could be
>> subjected to an ACE or similar encoding without risk of
>> having internal information that would be hidden at the wrong
>> times.
> 
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www1.ietf.org/mailman/listinfo/ima





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



From ima-bounces@ietf.org Thu Jul 20 06:54:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3WAy-00039S-3J; Thu, 20 Jul 2006 06:54:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3WAv-000386-Ip
	for ima@ietf.org; Thu, 20 Jul 2006 06:54:37 -0400
Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3W3r-0004Tk-Jr
	for ima@ietf.org; Thu, 20 Jul 2006 06:47:23 -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-1.csi.cam.ac.uk ([131.111.8.51]:32977)
	by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G3W3m-0005IV-TW (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Thu, 20 Jul 2006 11:47:14 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1G3W3m-0003Ef-3T (Exim 4.53)
	(return-path <fanf2@hermes.cam.ac.uk>); Thu, 20 Jul 2006 11:47:14 +0100
Date: Thu, 20 Jul 2006 11:47:14 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Tony Hansen <tony@att.com>
Subject: Re: [EAI] changing name of ATOMIC?
In-Reply-To: <44BE99FF.5030104@att.com>
Message-ID: <Pine.LNX.4.64.0607201146580.2935@hermes-1.csi.cam.ac.uk>
References: <44BE99FF.5030104@att.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
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 Wed, 19 Jul 2006, Tony Hansen wrote:
>
> Can the concept ATOMIC be renamed to be something else, say
> DOWNGRADEABLE?

+1

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FITZROY SOLE: SOUTHERLY 3 OR 4, BUT WESTERLY AT FIRST IN WEST, INCREASING 5 TO
7 LATER IN WEST. SHOWERS. MODERATE OR GOOD, WITH FOG PATCHES AT FIRST.

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



From ima-bounces@ietf.org Thu Jul 20 07:15:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3WVK-00081C-I0; Thu, 20 Jul 2006 07:15:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3WVH-000808-P4
	for ima@ietf.org; Thu, 20 Jul 2006 07:15:39 -0400
Received: from lon-mail-4.gradwell.net ([193.111.201.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3WK5-0007Wu-15
	for ima@ietf.org; Thu, 20 Jul 2006 07:04:07 -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
	44bf6322.c91f.143 for ima@ietf.org; Thu, 20 Jul 2006 12:04:02 +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 k6KB3t1v006657
	for <ima@ietf.org>; Thu, 20 Jul 2006 12:03:56 +0100 (BST)
To: "ima@ietf.org" <ima@ietf.org>
Subject: Re: [EAI] changing name of ATOMIC?
References: <44BE99FF.5030104@att.com> <11B3A11B70F6BED68B02823D@p3.JCK.COM>
Message-ID: <op.tczicsm16hl8nm@clerew.man.ac.uk>
Date: Thu, 20 Jul 2006 12:03:54 +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: <11B3A11B70F6BED68B02823D@p3.JCK.COM>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
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, 19 Jul 2006 23:56:51 +0100, John C Klensin <klensin@jck.com> wrote:


> I still hope to get rid of it, but agree that DOWNGRADEABLE
> might be a better choice.

I agree, assuming we need to retain the concept (though, as a matter of  
spelling, I don't think it needs that "E" in it - but I haven't the time  
to consult Fowler just at the moment).

> The term was chosen too quickly but precisely to convey the
> flavor of having an address that did not contain subaddresses or
> other sorts of components... hence one that could be subjected
> to an ACE or similar encoding without risk of having internal
> information that would be hidden at the wrong times.

Yes, but that is not the right interpretation anyway. Even if it contains  
subaddresses and other forms of internal structure, that is not  
necessarily a bar to downgrading.

Essentially, a site whose addresses are permitted to include the keyword  
DOWNGRADABLE (with whatever notation we provide for expressing that) is  
saying, in effect

"Yes, even though we parse our incoming local-parts looking for all sorts  
of local structure, and we can recognize such structure in both ASCII and  
UTF8 local-parts, we have also set things up so that we can even figure  
out the structure of an ACEd UTF8 local-part."

[Upgrading is the obvious way to "figure it out", but the site is welcome  
to do it anyway it likes].

So I would expect that the only sites which might insist on  
"NON-DOWNGRADEABLE" in their addresses would be those whose  
implementations could not, as John suggested, easily be hacked to do the  
upgrading. Are there any other situations when "NON-DOWNGRADEABLE" might  
be required?

-- 
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 Jul 20 12:16:07 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3bBx-0004c5-Eq; Thu, 20 Jul 2006 12:16:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3bBw-0004Yz-33
	for ima@ietf.org; Thu, 20 Jul 2006 12:16:00 -0400
Received: from proof.pobox.com ([207.106.133.28])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3bBu-0001sn-T3
	for ima@ietf.org; Thu, 20 Jul 2006 12:16:00 -0400
Received: from proof (localhost [127.0.0.1])
	by proof.pobox.com (Postfix) with ESMTP id 6F71129D4E;
	Thu, 20 Jul 2006 12:15:58 -0400 (EDT)
Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82])
	by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 06537666B2;
	Thu, 20 Jul 2006 12:15:56 -0400 (EDT)
Date: Thu, 20 Jul 2006 09:15:52 -0700
From: Bill McQuillan <McQuilWP@pobox.com>
X-Priority: 3 (Normal)
Message-ID: <137465039.20060720091552@pobox.com>
To: IMA Discussion <ima@ietf.org>
Subject: Re: [EAI] changing name of ATOMIC?
In-Reply-To: <op.tczicsm16hl8nm@clerew.man.ac.uk>
References: <44BE99FF.5030104@att.com> <11B3A11B70F6BED68B02823D@p3.JCK.COM>
	<op.tczicsm16hl8nm@clerew.man.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
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 Thu, 2006-07-20, Charles Lindsey wrote:
> So I would expect that the only sites which might insist on  
> "NON-DOWNGRADEABLE" in their addresses would be those whose  
> implementations could not, as John suggested, easily be hacked to do the
> upgrading. Are there any other situations when "NON-DOWNGRADEABLE" might
> be required?

A difficulty with using punycoding for our ACE is that a transformation
such as: "add -owner to a mailing list name to get to a human" is done by
senders rather than final delivery agents and I'm not sure what the effect
of punycode's sticking the "special" stuff on the end will do to this
ability. That is why the strawman ACE I threw out earlier maintained
character order throughout the transformation.

Unfortunately, now that I think about it, if a local part needs to be
modified by the sender and that makes it NON-DOWNGRADABLE, then an second
ALT-ADDR will be needed for the modified address as well as the one for the
unmodified one!

-- 
Bill McQuillan <McQuilWP@pobox.com>


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



From ima-bounces@ietf.org Thu Jul 20 12:22:48 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3bIU-0002TZ-Fk; Thu, 20 Jul 2006 12:22:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3bIT-0002St-48
	for ima@ietf.org; Thu, 20 Jul 2006 12:22:45 -0400
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3bIO-00025P-PL
	for ima@ietf.org; Thu, 20 Jul 2006 12:22:45 -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-1.csi.cam.ac.uk ([131.111.8.51]:60668)
	by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G3bI8-0002iV-2g (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Thu, 20 Jul 2006 17:22:24 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1G3bI8-0002n4-Or (Exim 4.53)
	(return-path <fanf2@hermes.cam.ac.uk>); Thu, 20 Jul 2006 17:22:24 +0100
Date: Thu, 20 Jul 2006 17:22:24 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Bill McQuillan <McQuilWP@pobox.com>
Subject: Re: [EAI] changing name of ATOMIC?
In-Reply-To: <137465039.20060720091552@pobox.com>
Message-ID: <Pine.LNX.4.64.0607201719380.11517@hermes-1.csi.cam.ac.uk>
References: <44BE99FF.5030104@att.com> <11B3A11B70F6BED68B02823D@p3.JCK.COM>
	<op.tczicsm16hl8nm@clerew.man.ac.uk>
	<137465039.20060720091552@pobox.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: IMA Discussion <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 Thu, 20 Jul 2006, Bill McQuillan wrote:
>
> A difficulty with using punycoding for our ACE is that a transformation
> such as: "add -owner to a mailing list name to get to a human" is done by
> senders rather than final delivery agents and I'm not sure what the effect
> of punycode's sticking the "special" stuff on the end will do to this
> ability.

Downgrading will not happen in this situation because it's UTF8-to-UTF8.

The more interesting question is how an ASCII user could reach the owner
of a UTF8 mailing list given the list's downgraded submission address.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
HUMBER THAMES DOVER: SOUTH OR SOUTHWEST 4 OR 5, BECOMING VARIABLE 3. SHOWERS
THEN FAIR. MODERATE OCCASIONALLY POOR, WITH FOG PATCHES IN DOVER.

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



From ima-bounces@ietf.org Thu Jul 20 12:37:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3bX6-0004x1-MG; Thu, 20 Jul 2006 12:37:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3bX4-0004ww-Td
	for ima@ietf.org; Thu, 20 Jul 2006 12:37:50 -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 1G3bX3-0002Uk-Kw
	for ima@ietf.org; Thu, 20 Jul 2006 12:37:50 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1G3bX3-000Gn6-3L; Thu, 20 Jul 2006 12:37:49 -0400
Date: Thu, 20 Jul 2006 12:37:48 -0400
From: John C Klensin <klensin@jck.com>
To: Bill McQuillan <McQuilWP@pobox.com>, IMA Discussion <ima@ietf.org>
Message-ID: <A49D88A485579DE38620B4FE@p3.JCK.COM>
In-Reply-To: <137465039.20060720091552@pobox.com>
References: <44BE99FF.5030104@att.com> <11B3A11B70F6BED68B02823D@p3.JCK.COM>
	<op.tczicsm16hl8nm@clerew.man.ac.uk>
	<137465039.20060720091552@pobox.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: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: 
Subject: [EAI] Two ALT-ADDRs?? (was: Re: changing name of ATOMIC?)
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 Thursday, 20 July, 2006 09:15 -0700 Bill McQuillan
<McQuilWP@pobox.com> wrote:

> Unfortunately, now that I think about it, if a local part
> needs to be modified by the sender and that makes it
> NON-DOWNGRADABLE, then an second ALT-ADDR will be needed for
> the modified address as well as the one for the unmodified one!

I am not sure I understand this comment.

Unless we are getting confused about terminology, senders don't
modify addresses, they supply them. 

Since ALT-ADDRESSes are required to be all-ASCII, substitution
of one of them yields something that does not need further
downgrading.

What am I missing?

    john


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



From ima-bounces@ietf.org Thu Jul 20 19:53:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3iKo-0008R8-8r; Thu, 20 Jul 2006 19:53:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3iKf-0008HU-8n
	for ima@ietf.org; Thu, 20 Jul 2006 19:53:29 -0400
Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3hY0-0003mD-7W
	for ima@ietf.org; Thu, 20 Jul 2006 19:03:14 -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-1.csi.cam.ac.uk ([131.111.8.51]:44587)
	by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G3hXp-0003eM-Vd (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Fri, 21 Jul 2006 00:03:01 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1G3hXp-0003QL-Ms (Exim 4.53)
	(return-path <fanf2@hermes.cam.ac.uk>); Fri, 21 Jul 2006 00:03:01 +0100
Date: Fri, 21 Jul 2006 00:03:01 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: John C Klensin <klensin@jck.com>
Subject: Re: [EAI] Two ALT-ADDRs?? (was: Re: changing name of ATOMIC?)
In-Reply-To: <A49D88A485579DE38620B4FE@p3.JCK.COM>
Message-ID: <Pine.LNX.4.64.0607210002010.14969@hermes-1.csi.cam.ac.uk>
References: <44BE99FF.5030104@att.com> <11B3A11B70F6BED68B02823D@p3.JCK.COM>
	<op.tczicsm16hl8nm@clerew.man.ac.uk>
	<137465039.20060720091552@pobox.com>
	<A49D88A485579DE38620B4FE@p3.JCK.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: IMA Discussion <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 Thu, 20 Jul 2006, John C Klensin wrote:
>
> Unless we are getting confused about terminology, senders don't
> modify addresses, they supply them.

They do if they are expecting a standard convention for constructing
addresses, such as adding -owner to ima@ietf.org to get ima-owner@ietf.org.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
THAMES DOVER WIGHT PORTLAND PLYMOUTH: SOUTHWESTERLY 3 OR 4, OCCASIONALLY 5 IN
THAMES AND DOVER, BECOMING VARIABLE 3. SHOWERS LATER. MODERATE OCCASIONALLY
POOR, WITH FOG PATCHES.

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



From ima-bounces@ietf.org Thu Jul 20 19:55:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3iMo-0000tl-UJ; Thu, 20 Jul 2006 19:55:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3iMn-0000tg-D7
	for ima@ietf.org; Thu, 20 Jul 2006 19:55:41 -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 1G3iMm-0006pu-39
	for ima@ietf.org; Thu, 20 Jul 2006 19:55:41 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1G3iMe-000KwJ-P0; Thu, 20 Jul 2006 19:55:32 -0400
Date: Thu, 20 Jul 2006 19:55:32 -0400
From: John C Klensin <klensin@jck.com>
To: Tony Finch <dot@dotat.at>
Subject: Re: [EAI] Two ALT-ADDRs?? (was: Re: changing name of
 ATOMIC?)
Message-ID: <7B0949BB4809179A9C058089@p3.JCK.COM>
In-Reply-To: <Pine.LNX.4.64.0607210002010.14969@hermes-1.csi.cam.ac.uk>
References: <44BE99FF.5030104@att.com> <11B3A11B70F6BED68B02823D@p3.JCK.COM>
	<op.tczicsm16hl8nm@clerew.man.ac.uk>
	<137465039.20060720091552@pobox.com>
	<A49D88A485579DE38620B4FE@p3.JCK.COM>
	<Pine.LNX.4.64.0607210002010.14969@hermes-1.csi.cam.ac.uk>
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: 97adf591118a232206bdb5a27b217034
Cc: IMA Discussion <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 Friday, 21 July, 2006 00:03 +0100 Tony Finch <dot@dotat.at>
wrote:

> On Thu, 20 Jul 2006, John C Klensin wrote:
>> 
>> Unless we are getting confused about terminology, senders
>> don't modify addresses, they supply them.
> 
> They do if they are expecting a standard convention for
> constructing addresses, such as adding -owner to ima@ietf.org
> to get ima-owner@ietf.org.

But there has never been a Standard (large "S") convention.
There have only been a series of conventions.  E.g., for the
role you are describing and list foo, I have seen, in the
local-part,
   owner-foo
   foo-owner
   foo-request
at least.

That problem is one of the reasons the list-xxx headers were
adopted.  They make the relevant addresses explicit, rather than
relying on conventions that are often not followed.

Let's not try to make this problem even more difficult than it
is.

    john




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



From ima-bounces@ietf.org Fri Jul 21 13:27:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3ymf-00073i-7l; Fri, 21 Jul 2006 13:27:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3yln-0006M9-Ga
	for ima@ietf.org; Fri, 21 Jul 2006 13:26:35 -0400
Received: from sokol.elan.net ([216.151.192.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ye0-0000dx-Oy
	for ima@ietf.org; Fri, 21 Jul 2006 13:18:34 -0400
Received: from sokol.elan.net (sokol [127.0.0.1])
	by sokol.elan.net (8.13.1/8.13.1) with ESMTP id k6LHIOdn016919
	for <ima@ietf.org>; Fri, 21 Jul 2006 10:18:25 -0700
Received: from localhost (william@localhost)
	by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id k6LHIObW016916
	for <ima@ietf.org>; Fri, 21 Jul 2006 10:18:24 -0700
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
Date: Fri, 21 Jul 2006 10:18:24 -0700 (PDT)
From: "william(at)elan.net" <william@elan.net>
To: ima@ietf.org
Message-ID: <Pine.LNX.4.62.0607211004500.11416@sokol.elan.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Subject: [EAI] ORCPT / RFC3461
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 brought this up on the meeting briefly and it was recommended to take 
this to the mail list (did not have time to write until now). The issue
is that current EAI drafts appear to overlook issues that may arise for
when using ORCPT extension (to RCPT keyword) as specified in RFC3461
(and 1891 before it).

More specifically ORCPT specified email address of "original recipient"
so that the sender could receive appropriate delivery notification
(both non-deliveries and those to be used with message tracking).
That address as specified write now has typical ASCII format (called
rfc822 address-type) and so you need to address this and specify how
(or if or when) UTF address can be passed with this keyword extension.
I suspect there will have to be used and registered new UTF8 address-
type for use with internationalized addresses.

-- 
William Leibzon
Elan Networks
william@elan.net

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



From ima-bounces@ietf.org Sat Jul 22 15:27:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G4N86-0008Nz-58; Sat, 22 Jul 2006 15:27:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G4N84-0008Nu-F7
	for ima@ietf.org; Sat, 22 Jul 2006 15:27:12 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4N83-0008AD-1g
	for ima@ietf.org; Sat, 22 Jul 2006 15: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;
	Sat, 22 Jul 2006 20:22:08 +0100
Message-ID: <44C27ABE.5000704@isode.com>
Date: Sat, 22 Jul 2006 20:21:34 +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: "william(at)elan.net" <william@elan.net>
Subject: Re: [EAI] ORCPT / RFC3461
References: <Pine.LNX.4.62.0607211004500.11416@sokol.elan.net>
In-Reply-To: <Pine.LNX.4.62.0607211004500.11416@sokol.elan.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
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

william(at)elan.net wrote:

> I've brought this up on the meeting briefly and it was recommended to 
> take this to the mail list (did not have time to write until now). The 
> issue
> is that current EAI drafts appear to overlook issues that may arise for
> when using ORCPT extension (to RCPT keyword) as specified in RFC3461
> (and 1891 before it).

Indeed. I was trying to raise this issue before.

> More specifically ORCPT specified email address of "original recipient"
> so that the sender could receive appropriate delivery notification
> (both non-deliveries and those to be used with message tracking).
> That address as specified write now has typical ASCII format (called
> rfc822 address-type) and so you need to address this and specify how
> (or if or when) UTF address can be passed with this keyword extension.
> I suspect there will have to be used and registered new UTF8 address-
> type for use with internationalized addresses.



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



From ima-bounces@ietf.org Sun Jul 23 22:47:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G4qTL-00020A-LC; Sun, 23 Jul 2006 22:47:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G4qTK-000205-C3
	for ima@ietf.org; Sun, 23 Jul 2006 22:47:06 -0400
Received: from sniper.icu.ac.kr ([210.107.128.51])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G4qTH-00078C-F3
	for ima@ietf.org; Sun, 23 Jul 2006 22:47:06 -0400
Received: (snipe 32682 invoked by uid 0); 24 Jul 2006 11:47:00 +0900
Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.098699
	secs); 
Received: from unknown (HELO ?220.69.185.36?) (Z???own@220.69.185.36)
	by unknown with SMTP; 24 Jul 2006 11:47:00 +0900
X-RCPTTO: alexey.melnikov@isode.com,
	william@elan.net,
	ima@ietf.org
Message-ID: <44C43499.7080107@icu.ac.kr>
Date: Mon, 24 Jul 2006 11:46:49 +0900
From: Yangwoo Ko <newcat@icu.ac.kr>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [EAI] ORCPT / RFC3461
References: <Pine.LNX.4.62.0607211004500.11416@sokol.elan.net>
	<44C27ABE.5000704@isode.com>
In-Reply-To: <44C27ABE.5000704@isode.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
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


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

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

More suggestions are welcome.

Alexey Melnikov wrote:
> 
> william(at)elan.net wrote:
> 
>> I've brought this up on the meeting briefly and it was recommended to 
>> take this to the mail list (did not have time to write until now). The 
>> issue
>> is that current EAI drafts appear to overlook issues that may arise for
>> when using ORCPT extension (to RCPT keyword) as specified in RFC3461
>> (and 1891 before it).
> 
> Indeed. I was trying to raise this issue before.
> 
>> More specifically ORCPT specified email address of "original recipient"
>> so that the sender could receive appropriate delivery notification
>> (both non-deliveries and those to be used with message tracking).
>> That address as specified write now has typical ASCII format (called
>> rfc822 address-type) and so you need to address this and specify how
>> (or if or when) UTF address can be passed with this keyword extension.
>> I suspect there will have to be used and registered new UTF8 address-
>> type for use with internationalized addresses.
> 
> 
> 
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www1.ietf.org/mailman/listinfo/ima
> 
> 


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



From ima-bounces@ietf.org Tue Jul 25 05:44:29 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5JSh-0007Sb-TR; Tue, 25 Jul 2006 05:44:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5JSg-0007SV-2b
	for ima@ietf.org; Tue, 25 Jul 2006 05:44:22 -0400
Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5JSb-00084f-PI
	for ima@ietf.org; Tue, 25 Jul 2006 05:44:22 -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-1.csi.cam.ac.uk ([131.111.8.51]:46233)
	by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G5JST-0002fn-Pf (Exim 4.54) for
	ima@ietf.org
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 25 Jul 2006 10:44:09 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk)
	with local-esmtp id 1G5JST-0000kK-RE (Exim 4.53) for ima@ietf.org
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 25 Jul 2006 10:44:09 +0100
Date: Tue, 25 Jul 2006 10:44:09 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: ima@ietf.org
Message-ID: <Pine.LNX.4.64.0607251043450.2580@hermes-1.csi.cam.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.2 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Subject: [EAI] downgrade annotations and RCPT TO
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

As I understand it, the rough consensus of the group is that email between
two UTF8 users should go through UTF8 infrastructure, and downgrading is
only used when a UTF8 user is emailing an ASCII user.

This implies that downgrade information (ATOM^H^H^H^H DOWNGRADABLE and
ALT_ADDRESS) on RCPT commands is not necessary.

This has the consequence that it is a configuration error to have a
non-UTF8-capable MTA agent in the transmission path between two UTF8
users, and if one is encountered the message must be bounced.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FISHER NORTH GERMAN BIGHT: WEST VEERING NORTHWEST 4 OR 5, OCCASIONALLY 6 IN
NORTHEAST FISHER. FAIR. MODERATE BECOMING GOOD.

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



From ima-bounces@ietf.org Tue Jul 25 06:39:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5KKB-0003Vb-Ct; Tue, 25 Jul 2006 06:39:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5KKA-0003VW-RI
	for ima@ietf.org; Tue, 25 Jul 2006 06:39:38 -0400
Received: from [159.226.7.146] (helo=cnnic.cn)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G5KK7-0006AA-So
	for ima@ietf.org; Tue, 25 Jul 2006 06:39:38 -0400
Received: (eyou send program); Tue, 25 Jul 2006 18:39:23 +0800
Message-ID: <353823963.20414@cnnic.cn>
X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn
Received: from unknown (HELO cnnicyaojk) (159.226.6.18)
	by 159.226.7.146 with SMTP; Tue, 25 Jul 2006 18:39:23 +0800
Message-ID: <00bc01c6afd6$7e320fb0$1206e29f@cnnicyaojk>
From: "YAO Jiankang" <yaojk@cnnic.cn>
To: "Tony Finch" <dot@dotat.at>
References: <353820675.17656@cnnic.cn>
Subject: Re: [EAI] downgrade annotations and RCPT TO
Date: Tue, 25 Jul 2006 18:38:39 +0800
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
X-Spam-Score: 1.0 (+)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
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>
Content-Type: multipart/mixed; boundary="===============0356681232=="
Errors-To: ima-bounces@ietf.org

--===============0356681232==
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

dXRmOC1jYXBhYmlsaXR5IHNlcnZlciBBLS0tPm5vbi11dGY4LWNhcGFiaWxpdHkgc2VydmVyIEIg
KG1heSByZWxheSBzZXJ2ZXIpLS0tPnV0ZjgtY2FwYWJpbGl0eSBzZXJ2ZXIgQw0KDQppZiB0aGUg
YWJvdmUgc2l0dWF0aW9uIGlzIGVuY291bnRlcmVkLCBBIG1heSBjb25uZWN0IEIgZmlyc3QgdGhy
b3VnaCBETlMgTVggbG9va3VwDQoNCkEgc2VuZHMgQiB3aXRoIGVobG8tLT5BIGZpbmRzIG5vIEVB
SSBrZXl3b3JkIGluIHRoZSByZXNwb25zZSBtZXNzYWdlLS0+QSB3aWxsIHVzZSBSQ1BUIFRPIDxh
bHQtYWRkcmVzcz4gaW4gdGhlIGZvbGxvd2luZyBvcGVyYXRpb25zLiBzbyBhbHQtYWRkcmVzcyB3
aWxsIGJlIHVzZWQgaW4gcmNwdCB0by4NCg0KDQpZYW8gSmlhbmthbmcgDQoNCi0tLS0tIE9yaWdp
bmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiVG9ueSBGaW5jaCIgPGRvdEBkb3RhdC5hdD4NClRv
OiA8aW1hQGlldGYub3JnPg0KU2VudDogVHVlc2RheSwgSnVseSAyNSwgMjAwNiA1OjQ0IFBNDQpT
dWJqZWN0OiBbRUFJXSBkb3duZ3JhZGUgYW5ub3RhdGlvbnMgYW5kIFJDUFQgVE8NCg0KDQo+IEFz
IEkgdW5kZXJzdGFuZCBpdCwgdGhlIHJvdWdoIGNvbnNlbnN1cyBvZiB0aGUgZ3JvdXAgaXMgdGhh
dCBlbWFpbCBiZXR3ZWVuDQo+IHR3byBVVEY4IHVzZXJzIHNob3VsZCBnbyB0aHJvdWdoIFVURjgg
aW5mcmFzdHJ1Y3R1cmUsIGFuZCBkb3duZ3JhZGluZyBpcw0KPiBvbmx5IHVzZWQgd2hlbiBhIFVU
RjggdXNlciBpcyBlbWFpbGluZyBhbiBBU0NJSSB1c2VyLg0KPiANCj4gVGhpcyBpbXBsaWVzIHRo
YXQgZG93bmdyYWRlIGluZm9ybWF0aW9uIChBVE9NXkheSF5IXkggRE9XTkdSQURBQkxFIGFuZA0K
PiBBTFRfQUREUkVTUykgb24gUkNQVCBjb21tYW5kcyBpcyBub3QgbmVjZXNzYXJ5Lg0KDQpub3Qg
dHJ1ZS4NCg0KPiANCj4gVGhpcyBoYXMgdGhlIGNvbnNlcXVlbmNlIHRoYXQgaXQgaXMgYSBjb25m
aWd1cmF0aW9uIGVycm9yIHRvIGhhdmUgYQ0KPiBub24tVVRGOC1jYXBhYmxlIE1UQSBhZ2VudCBp
biB0aGUgdHJhbnNtaXNzaW9uIHBhdGggYmV0d2VlbiB0d28gVVRGOA0KPiB1c2VycywgYW5kIGlm
IG9uZSBpcyBlbmNvdW50ZXJlZCB0aGUgbWVzc2FnZSBtdXN0IGJlIGJvdW5jZWQuDQo+IA0KDQpt
YXkgbm90IGJlIGJvdW5jZWQuDQoNCg0KPiBUb255Lg0KPiAtLSANCj4gZi5hLm4uZmluY2ggIDxk
b3RAZG90YXQuYXQ+ICBodHRwOi8vZG90YXQuYXQvDQo+IEZJU0hFUiBOT1JUSCBHRVJNQU4gQklH
SFQ6IFdFU1QgVkVFUklORyBOT1JUSFdFU1QgNCBPUiA1LCBPQ0NBU0lPTkFMTFkgNiBJTg0KPiBO
T1JUSEVBU1QgRklTSEVSLiBGQUlSLiBNT0RFUkFURSBCRUNPTUlORyBHT09ELg0KPiANCj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSU1BIG1haWxp
bmcgbGlzdA0KPiBJTUFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vaW1hDQo+IA==




--===============0356681232==
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

--===============0356681232==--



From ima-bounces@ietf.org Tue Jul 25 06:58:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5Kc7-0001Vy-2G; Tue, 25 Jul 2006 06:58:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Kc6-0001Vt-GM
	for ima@ietf.org; Tue, 25 Jul 2006 06:58:10 -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 1G5Kc2-0007rB-W8
	for ima@ietf.org; Tue, 25 Jul 2006 06:58:10 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1G5Kby-000B7c-A8; Tue, 25 Jul 2006 06:58:02 -0400
Date: Tue, 25 Jul 2006 06:58:01 -0400
From: John C Klensin <klensin@jck.com>
To: YAO Jiankang <yaojk@cnnic.cn>, Tony Finch <dot@dotat.at>
Subject: Re: [EAI] downgrade annotations and RCPT TO
Message-ID: <6B02C220FBC757B3CE16D5AD@p3.JCK.COM>
In-Reply-To: <353823963.20414@cnnic.cn>,
	<00bc01c6afd6$7e320fb0$1206e29f@cnnicyaojk>
References: <353820675.17656@cnnic.cn> <353823963.20414@cnnic.cn>,
	<00bc01c6afd6$7e320fb0$1206e29f@cnnicyaojk>
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: f66b12316365a3fe519e75911daf28a8
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 Tuesday, 25 July, 2006 18:38 +0800 YAO Jiankang
<yaojk@cnnic.cn> wrote:

> utf8-capability server A--->non-utf8-capability server B (may
> relay server)--->utf8-capability server C
> 
> if the above situation is encountered, A may connect B first
> through DNS MX lookup

Sure.  However, this is precisely the "configuration error"
pointed to below.  It is in general stupid for the management of
"C", which supports and cares about utf-8 addresses, to
configure an MX backup or relay that does not support that
capability.  If we had a case in which no one who was
UTF-8-address-capable ever configured a lower-preference MX that
did not have that capability, then the case reduces to the
direct connnection (no relay) one and there would be no need for
a downgrade-on-the-wire capability at all: either A (presumably
the submission server) would get the rejection (absence of
authorizing keyword) on connection to C or would be able to send
without problems or C would be reluctant to advertise
UTF-8-based addresses.

There are some edge cases.  In particular, if C believes that
downgrading is widely supported (rather than having messages
bounce) and especially if it also believes that upgrading works
without loss of information, it might be tempted to configure a
low-capability MX relay to provide backup, get around an
incapable firewall, or out of general sloth or indifference.
But each of those cases can be turned into an argument that
downgrading capability is actually harmful in that it will
discourage full deployment of EAI facilities on the only basis
that will really work... radiating outward from sites that
believe the capability is important.

   john

> 
> A sends B with ehlo-->A finds no EAI keyword in the response
> message-->A will use RCPT TO <alt-address> in the following
> operations. so alt-address will be used in rcpt to.
> 
> 
> Yao Jiankang 
> 
> ----- Original Message ----- 
> From: "Tony Finch" <dot@dotat.at>
> To: <ima@ietf.org>
> Sent: Tuesday, July 25, 2006 5:44 PM
> Subject: [EAI] downgrade annotations and RCPT TO
> 
> 
>> As I understand it, the rough consensus of the group is that
>> email between two UTF8 users should go through UTF8
>> infrastructure, and downgrading is only used when a UTF8 user
>> is emailing an ASCII user.
>> 
>> This implies that downgrade information (ATOM^H^H^H^H
>> DOWNGRADABLE and ALT_ADDRESS) on RCPT commands is not
>> necessary.
> 
> not true.
> 
>> 
>> This has the consequence that it is a configuration error to
>> have a non-UTF8-capable MTA agent in the transmission path
>> between two UTF8 users, and if one is encountered the message
>> must be bounced.
>> 
> 
> may not be bounced.
> 
> 
>> Tony.
>> -- 
>> f.a.n.finch  <dot@dotat.at>  http://dotat.at/
>> FISHER NORTH GERMAN BIGHT: WEST VEERING NORTHWEST 4 OR 5,
>> OCCASIONALLY 6 IN NORTHEAST FISHER. FAIR. MODERATE BECOMING
>> GOOD.
>> 
>> _______________________________________________
>> IMA mailing list
>> IMA@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ima





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



From ima-bounces@ietf.org Tue Jul 25 07:09:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5Kmu-0006Ni-GF; Tue, 25 Jul 2006 07:09:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Kmt-0006Nc-FP
	for ima@ietf.org; Tue, 25 Jul 2006 07:09:19 -0400
Received: from lon-mail-1.gradwell.net ([193.111.201.125])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Kmq-00011T-QD
	for ima@ietf.org; Tue, 25 Jul 2006 07:09:19 -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.231) id
	44c5fbca.1445.163; Tue, 25 Jul 2006 12:08:58 +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 k6PB8qtX003269;
	Tue, 25 Jul 2006 12:08:54 +0100 (BST)
Date: Tue, 25 Jul 2006 12:08:51 +0100
To: "Tony Finch" <dot@dotat.at>, "John C Klensin" <klensin@jck.com>
Subject: Re: [EAI] Two ALT-ADDRs?? (was: Re: changing name of ATOMIC?)
References: <44BE99FF.5030104@att.com> <11B3A11B70F6BED68B02823D@p3.JCK.COM>
	<op.tczicsm16hl8nm@clerew.man.ac.uk>
	<137465039.20060720091552@pobox.com>
	<A49D88A485579DE38620B4FE@p3.JCK.COM>
	<Pine.LNX.4.64.0607210002010.14969@hermes-1.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.tc8rw1ud6hl8nm@clerew.man.ac.uk>
In-Reply-To: <Pine.LNX.4.64.0607210002010.14969@hermes-1.csi.cam.ac.uk>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: IMA Discussion <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, 21 Jul 2006 00:03:01 +0100, Tony Finch <dot@dotat.at> wrote:

> On Thu, 20 Jul 2006, John C Klensin wrote:
>>
>> Unless we are getting confused about terminology, senders don't
>> modify addresses, they supply them.
>
> They do if they are expecting a standard convention for constructing
> addresses, such as adding -owner to ima@ietf.org to get  
> ima-owner@ietf.org.

But I still do not see the problem. Surely the 'sender' is sufficiently  
close to the 'author@ (i.e. they are usually at the same site, and are  
dealing with the mail _before_ is has been submitted, i.e. _before_ is  
starts its first SMTP hop) that the 'author' and 'sender' can sort out  
between them whether the '-owner' is added to a UTF8 or ASCII version of  
the address, after which it may get downgraded when it is offered to the  
first MTA (or by some later MTA).

A more interesting question is the one raised regarding the ASCII man who  
has the downgraded address of the list, and wants to contact its owner. I  
usupect that is a problem for the mailing list administrator to worry  
about, and maybe it should receive some attention in out  
mailing-list-document, which I gather someone is writing.

-- 
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 Jul 25 07:10:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5Kna-00072E-T6; Tue, 25 Jul 2006 07:10:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5KnZ-00071z-9N
	for ima@ietf.org; Tue, 25 Jul 2006 07:10:01 -0400
Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5KnX-00017P-Sb
	for ima@ietf.org; Tue, 25 Jul 2006 07:10: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-1.csi.cam.ac.uk ([131.111.8.51]:46273)
	by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G5KnJ-00038f-5H (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 25 Jul 2006 12:09:45 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1G5KnJ-0003ZE-Iy (Exim 4.53)
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 25 Jul 2006 12:09:45 +0100
Date: Tue, 25 Jul 2006 12:09:45 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: John C Klensin <klensin@jck.com>
Subject: Re: [EAI] downgrade annotations and RCPT TO
In-Reply-To: <6B02C220FBC757B3CE16D5AD@p3.JCK.COM>
Message-ID: <Pine.LNX.4.64.0607251206520.2580@hermes-1.csi.cam.ac.uk>
References: <353820675.17656@cnnic.cn> <353823963.20414@cnnic.cn>,
	<00bc01c6afd6$7e320fb0$1206e29f@cnnicyaojk>
	<6B02C220FBC757B3CE16D5AD@p3.JCK.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 Tue, 25 Jul 2006, John C Klensin wrote:
>
> There are some edge cases.  In particular, if C believes that
> downgrading is widely supported (rather than having messages
> bounce) and especially if it also believes that upgrading works
> without loss of information, it might be tempted to configure a
> low-capability MX relay to provide backup, get around an
> incapable firewall, or out of general sloth or indifference.

I was trying to argue that the current consensus (that email between UTF8
users must use entirely UTF8 infrastructure) implies that we should remove
the RCPT command downgrade extensions so that this kind of configuration
simply will not work (or will be unreliable).

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
THE MULL OF GALLOWAY TO MULL OF KINTYRE INCLUDING THE FIRTH OF CLYDE AND THE
NORTH CHANNEL: VARIABLE 2 TO 4. MAINLY FAIR, BUT RISK OF A SHOWER. MODERATE OR
GOOD. SLIGHT OR SMOOTH.

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



From ima-bounces@ietf.org Tue Jul 25 07:22:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5L05-0003Nf-1e; Tue, 25 Jul 2006 07:22:57 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5L03-0003Na-W8
	for ima@ietf.org; Tue, 25 Jul 2006 07:22:56 -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 1G5L02-0002eJ-Lz
	for ima@ietf.org; Tue, 25 Jul 2006 07:22:55 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1G5Kzz-000BHC-2K; Tue, 25 Jul 2006 07:22:51 -0400
Date: Tue, 25 Jul 2006 07:22:50 -0400
From: John C Klensin <klensin@jck.com>
To: Tony Finch <dot@dotat.at>
Subject: Re: [EAI] downgrade annotations and RCPT TO
Message-ID: <67136B104B77E9C398A16CD1@p3.JCK.COM>
In-Reply-To: <Pine.LNX.4.64.0607251206520.2580@hermes-1.csi.cam.ac.uk>
References: <353820675.17656@cnnic.cn> <353823963.20414@cnnic.cn>,
	<00bc01c6afd6$7e320fb0$1206e29f@cnnicyaojk>
	<6B02C220FBC757B3CE16D5AD@p3.JCK.COM>
	<Pine.LNX.4.64.0607251206520.2580@hermes-1.csi.cam.ac.uk>
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: 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



--On Tuesday, 25 July, 2006 12:09 +0100 Tony Finch
<dot@dotat.at> wrote:

> On Tue, 25 Jul 2006, John C Klensin wrote:
>> 
>> There are some edge cases.  In particular, if C believes that
>> downgrading is widely supported (rather than having messages
>> bounce) and especially if it also believes that upgrading
>> works without loss of information, it might be tempted to
>> configure a low-capability MX relay to provide backup, get
>> around an incapable firewall, or out of general sloth or
>> indifference.
> 
> I was trying to argue that the current consensus (that email
> between UTF8 users must use entirely UTF8 infrastructure)
> implies that we should remove the RCPT command downgrade
> extensions so that this kind of configuration simply will not
> work (or will be unreliable).

That is equivalent, unless I misunderstand you, to removing
downgrade capability.  I am not yet ready to go on record as
believing that is the best solution.

      john


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



From ima-bounces@ietf.org Tue Jul 25 07:29:16 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5L6C-0005KR-El; Tue, 25 Jul 2006 07:29:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5L6B-0005KM-8c
	for ima@ietf.org; Tue, 25 Jul 2006 07:29:15 -0400
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5L69-0003LE-VD
	for ima@ietf.org; Tue, 25 Jul 2006 07:29:15 -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-1.csi.cam.ac.uk ([131.111.8.51]:46279)
	by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G5L63-00050A-1U (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 25 Jul 2006 12:29:07 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1G5L63-0004DG-DZ (Exim 4.53)
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 25 Jul 2006 12:29:07 +0100
Date: Tue, 25 Jul 2006 12:29:07 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: John C Klensin <klensin@jck.com>
Subject: Re: [EAI] downgrade annotations and RCPT TO
In-Reply-To: <67136B104B77E9C398A16CD1@p3.JCK.COM>
Message-ID: <Pine.LNX.4.64.0607251224090.2580@hermes-1.csi.cam.ac.uk>
References: <353820675.17656@cnnic.cn> <353823963.20414@cnnic.cn>,
	<00bc01c6afd6$7e320fb0$1206e29f@cnnicyaojk>
	<6B02C220FBC757B3CE16D5AD@p3.JCK.COM>
	<Pine.LNX.4.64.0607251206520.2580@hermes-1.csi.cam.ac.uk>
	<67136B104B77E9C398A16CD1@p3.JCK.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
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, 25 Jul 2006, John C Klensin wrote:
> On Tuesday, 25 July, 2006 12:09 +0100 Tony Finch wrote:
> >
> > I was trying to argue that the current consensus (that email
> > between UTF8 users must use entirely UTF8 infrastructure)
> > implies that we should remove the RCPT command downgrade
> > extensions so that this kind of configuration simply will not
> > work (or will be unreliable).
>
> That is equivalent, unless I misunderstand you, to removing
> downgrade capability.  I am not yet ready to go on record as
> believing that is the best solution.

No: there would still be downgrade information on the MAIL FROM command
and in the message header. Downgrading is only necessary when sending
email from a UTF8 user to ASCII users, in which case MAIL FROM needs
downgrading but not RCPT TO. For UTF8 recipients the message will go
through entirely UTF8 infrastructure so again the RCPT TO downgrade
information is redundant.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
SHANNON ROCKALL: CYCLONIC 3 OR 4, OCCASIONALLY 5 AT FIRST. SHOWERS. MODERATE
OR GOOD.

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



From ima-bounces@ietf.org Tue Jul 25 07:40:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5LHT-0001Ew-4p; Tue, 25 Jul 2006 07:40:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5LHS-0001Er-HV
	for ima@ietf.org; Tue, 25 Jul 2006 07:40:54 -0400
Received: from lon-mail-1.gradwell.net ([193.111.201.125])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5LHQ-0003zg-S3
	for ima@ietf.org; Tue, 25 Jul 2006 07:40:54 -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.231) id
	44c6033b.5c98.240; Tue, 25 Jul 2006 12:40:43 +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 k6PBecVe005674;
	Tue, 25 Jul 2006 12:40:38 +0100 (BST)
To: "John C Klensin" <klensin@jck.com>, "YAO Jiankang" <yaojk@cnnic.cn>,
	"Tony Finch" <dot@dotat.at>
Subject: Re: [EAI] downgrade annotations and RCPT TO
References: <353820675.17656@cnnic.cn> <353823963.20414@cnnic.cn>
	<00bc01c6afd6$7e320fb0$1206e29f@cnnicyaojk>
	<6B02C220FBC757B3CE16D5AD@p3.JCK.COM>
Message-ID: <op.tc8tdzjd6hl8nm@clerew.man.ac.uk>
Date: Tue, 25 Jul 2006 12:40: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: <6B02C220FBC757B3CE16D5AD@p3.JCK.COM>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
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, 25 Jul 2006 11:58:01 +0100, John C Klensin <klensin@jck.com> wrote:

> There are some edge cases.  In particular, if C believes that
> downgrading is widely supported (rather than having messages
> bounce) and especially if it also believes that upgrading works
> without loss of information, it might be tempted to configure a
> low-capability MX relay to provide backup, get around an
> incapable firewall, or out of general sloth or indifference.
> But each of those cases can be turned into an argument that
> downgrading capability is actually harmful in that it will
> discourage full deployment of EAI facilities on the only basis
> that will really work... radiating outward from sites that
> believe the capability is important.

All that is true, and probably implies a poor configuration choice (except  
perhaps for the firewall case which may be totally impenetrable other than  
by ASCII). But we can be sure that such poor configurations _will_ happen,  
and we can't stop them. So we may as well let them work and not try to  
forbid them (obviously, our documents will point out that sensible  
configuration is much better).

But we don't want the situation where a message destined for an ASCII-only  
site gets through, but one addressed for a UTF-8 addrtess which follows  
the same route fails. That is just biting off your nose to spite your face.

-- 
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 Jul 25 07:54:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5LUm-0006w6-FA; Tue, 25 Jul 2006 07:54:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5LUk-0006w1-Lx
	for ima@ietf.org; Tue, 25 Jul 2006 07:54:38 -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 1G5LUj-0005nI-7r
	for ima@ietf.org; Tue, 25 Jul 2006 07:54:38 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1G5LUc-000BV3-51; Tue, 25 Jul 2006 07:54:30 -0400
Date: Tue, 25 Jul 2006 07:54:29 -0400
From: John C Klensin <klensin@jck.com>
To: Charles Lindsey <chl@clerew.man.ac.uk>, YAO Jiankang <yaojk@cnnic.cn>,
	Tony Finch <dot@dotat.at>
Subject: Re: [EAI] downgrade annotations and RCPT TO
Message-ID: <B951B4B0656AE44C756FBBA3@p3.JCK.COM>
In-Reply-To: <op.tc8tdzjd6hl8nm@clerew.man.ac.uk>
References: <353820675.17656@cnnic.cn> <353823963.20414@cnnic.cn>
	<00bc01c6afd6$7e320fb0$1206e29f@cnnicyaojk>
	<6B02C220FBC757B3CE16D5AD@p3.JCK.COM>
	<op.tc8tdzjd6hl8nm@clerew.man.ac.uk>
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: f4c2cf0bccc868e4cc88dace71fb3f44
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 Tuesday, 25 July, 2006 12:40 +0100 Charles Lindsey
<chl@clerew.man.ac.uk> wrote:

> On Tue, 25 Jul 2006 11:58:01 +0100, John C Klensin
> <klensin@jck.com> wrote:
> 
>> There are some edge cases.  In particular, if C believes that
>> downgrading is widely supported (rather than having messages
>> bounce) and especially if it also believes that upgrading
>> works without loss of information, it might be tempted to
>> configure a low-capability MX relay to provide backup, get
>> around an incapable firewall, or out of general sloth or
>> indifference. But each of those cases can be turned into an
>> argument that downgrading capability is actually harmful in
>> that it will discourage full deployment of EAI facilities on
>> the only basis that will really work... radiating outward
>> from sites that believe the capability is important.
> 
> All that is true, and probably implies a poor configuration
> choice (except  perhaps for the firewall case which may be
> totally impenetrable other than  by ASCII). But we can be sure
> that such poor configurations _will_ happen,  and we can't
> stop them. So we may as well let them work and not try to
> forbid them (obviously, our documents will point out that
> sensible  configuration is much better).
> 
> But we don't want the situation where a message destined for
> an ASCII-only  site gets through, but one addressed for a
> UTF-8 addrtess which follows  the same route fails. That is
> just biting off your nose to spite your face.

To make the problem clear, I am going to play devils advocate
below -- I am not necessarily convinced of all of it.

Charles, if there were just a matter of "let them work", I would
certainly agree with you.   But the issues associated with
downgrading comprise virtually all of the issues that make this 
effort complex.  It is not an accident that our discussions
about parameter formats, location of addresses in and out of
brackets, trick headers, and so on all relate to downgrading.
Most of the downgrade variants also imply burdens --for
recognition of options, headers, or header parameters-- on
fully-upgraded systems and will continue to impose those
requirements even after all, or virtually all, of the Internet
has been upgraded.  

If poor configurations happen (and I agree that they will) and
result in bouncing, then there will be complaints and incentives
to get them fixed.   If they 'just work', then there will be no
incentive to get them fixed and they may not even be noticed.
It is not clear that is the best tradeoff: perhaps poor
configurations should have obvious negative consequences so they
can be identified and corrected.

    john


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



From ima-bounces@ietf.org Tue Jul 25 08:27:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5M0k-0001or-Cx; Tue, 25 Jul 2006 08:27:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5M0i-0001om-Qx
	for ima@ietf.org; Tue, 25 Jul 2006 08:27:40 -0400
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5M0e-0001Nx-HQ
	for ima@ietf.org; Tue, 25 Jul 2006 08:27:40 -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-1.csi.cam.ac.uk ([131.111.8.51]:46308)
	by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G5M0O-0008Ew-1f (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 25 Jul 2006 13:27:20 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1G5M0O-00066e-BI (Exim 4.53)
	(return-path <fanf2@hermes.cam.ac.uk>); Tue, 25 Jul 2006 13:27:20 +0100
Date: Tue, 25 Jul 2006 13:27:20 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: John C Klensin <klensin@jck.com>
Subject: Re: [EAI] downgrade annotations and RCPT TO
In-Reply-To: <B951B4B0656AE44C756FBBA3@p3.JCK.COM>
Message-ID: <Pine.LNX.4.64.0607251316080.2580@hermes-1.csi.cam.ac.uk>
References: <353820675.17656@cnnic.cn> <353823963.20414@cnnic.cn>
	<00bc01c6afd6$7e320fb0$1206e29f@cnnicyaojk>
	<6B02C220FBC757B3CE16D5AD@p3.JCK.COM>
	<op.tc8tdzjd6hl8nm@clerew.man.ac.uk>
	<B951B4B0656AE44C756FBBA3@p3.JCK.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: Tony Finch <dot@dotat.at>, 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

On Tue, 25 Jul 2006, John C Klensin wrote:
>
> If poor configurations happen (and I agree that they will) and
> result in bouncing, then there will be complaints and incentives
> to get them fixed.   If they 'just work', then there will be no
> incentive to get them fixed and they may not even be noticed.

I agree.

The effect of allowing downgrading in the UTF8-to-UTF8 path will be, for
example, I send you a UTF8 message which gets downgraded; you reply to the
downgraded ASCII address, and the subsequent conversation ends up using
ASCII addresses instead of UTF8 addresses. This is contrary to the
requirements in the scenarios document.

I also anticipate that unexpected downgrading will be difficult for the
average postmaster to debug, moreso than a bounce with a clear error
message.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
SHANNON ROCKALL: CYCLONIC 3 OR 4, OCCASIONALLY 5 AT FIRST. SHOWERS. MODERATE
OR GOOD.

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



From ima-bounces@ietf.org Wed Jul 26 16:47:37 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5qHv-0004Zg-Mk; Wed, 26 Jul 2006 16:47:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5qHu-0004Zb-It
	for ima@ietf.org; Wed, 26 Jul 2006 16:47:26 -0400
Received: from lon-mail-1.gradwell.net ([193.111.201.125])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5qHr-0002ac-Ub
	for ima@ietf.org; Wed, 26 Jul 2006 16:47:26 -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.231) id
	44c7d4d8.106be.919; Wed, 26 Jul 2006 21:47:20 +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 k6QKlI36022889;
	Wed, 26 Jul 2006 21:47:19 +0100 (BST)
To: "Tony Finch" <dot@dotat.at>, "John C Klensin" <klensin@jck.com>
Subject: Re: [EAI] downgrade annotations and RCPT TO
References: <353820675.17656@cnnic.cn> <353823963.20414@cnnic.cn>
	<00bc01c6afd6$7e320fb0$1206e29f@cnnicyaojk>
	<6B02C220FBC757B3CE16D5AD@p3.JCK.COM>
	<Pine.LNX.4.64.0607251206520.2580@hermes-1.csi.cam.ac.uk>
Message-ID: <op.tdbdc3l66hl8nm@clerew.man.ac.uk>
Date: Wed, 26 Jul 2006 21:47:17 +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.0607251206520.2580@hermes-1.csi.cam.ac.uk>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
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, 25 Jul 2006 12:09:45 +0100, Tony Finch <dot@dotat.at> wrote:

> On Tue, 25 Jul 2006, John C Klensin wrote:
>>
>> There are some edge cases.  In particular, if C believes that
>> downgrading is widely supported (rather than having messages
>> bounce) and especially if it also believes that upgrading works
>> without loss of information, it might be tempted to configure a
>> low-capability MX relay to provide backup, get around an
>> incapable firewall, or out of general sloth or indifference.
>
> I was trying to argue that the current consensus (that email between UTF8
> users must use entirely UTF8 infrastructure) implies that we should  
> remove
> the RCPT command downgrade extensions so that this kind of configuration
> simply will not work (or will be unreliable).

But does "must" mean "MUST"? You point out that this same downgrade is  
needed for MAIL FROM, and it is certainly needed if the recipient is  
genuinely ASCII-only. So you woould be giving the appearance of a rather  
arbitrary rule.

Moreover, all these issues of whether to downgrade, and whether we need to  
specify (or imply) Atomic actually turn out to be more important in the  
case of From/MAIL FROM/Reply-To. You can probably ensure that your mail  
addressed to a UTF-8 recipient follows a "sensible" (UTF-8-capable) route.  
But you cannot assume the same when your recipient replies to you.

Moreover, there is still the case of a UTF-capable recipient sitting  
behind an ASCII firewall. Consider the case of an American Company whose  
top management insists that all company mail passes through its firewall  
in Denver (top management is renowned for giving orders that have no basis  
in the technical realities :-( ). And top management easily forgets that  
they have offices in China, Taiwan and Korea which might want to  
comminucate with each other. A stupid scenario, but stupider things have  
happened.

-- 
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 Jul 26 16:53:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5qO5-00007B-UV; Wed, 26 Jul 2006 16:53:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5qO5-000076-4T
	for ima@ietf.org; Wed, 26 Jul 2006 16:53:49 -0400
Received: from lon-mail-1.gradwell.net ([193.111.201.125])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5qO3-0003H8-JA
	for ima@ietf.org; Wed, 26 Jul 2006 16:53:48 -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.231) id
	44c7d65a.10724.91b for ima@ietf.org; Wed, 26 Jul 2006 21:53: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 k6QKrjiI023286
	for <ima@ietf.org>; Wed, 26 Jul 2006 21:53:45 +0100 (BST)
To: "ima@ietf.org" <ima@ietf.org>
Subject: Re: [EAI] downgrade annotations and RCPT TO
References: <353820675.17656@cnnic.cn> <353823963.20414@cnnic.cn>
	<00bc01c6afd6$7e320fb0$1206e29f@cnnicyaojk>
	<6B02C220FBC757B3CE16D5AD@p3.JCK.COM>
	<op.tc8tdzjd6hl8nm@clerew.man.ac.uk>
	<B951B4B0656AE44C756FBBA3@p3.JCK.COM>
Message-ID: <op.tdbdnudj6hl8nm@clerew.man.ac.uk>
Date: Wed, 26 Jul 2006 21:53:44 +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: <B951B4B0656AE44C756FBBA3@p3.JCK.COM>
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 Tue, 25 Jul 2006 12:54:29 +0100, John C Klensin <klensin@jck.com> wrote:

> To make the problem clear, I am going to play devils advocate
> below -- I am not necessarily convinced of all of it.
>
> Charles, if there were just a matter of "let them work", I would
> certainly agree with you.   But the issues associated with
> downgrading comprise virtually all of the issues that make this
> effort complex.  It is not an accident that our discussions
> about parameter formats, location of addresses in and out of
> brackets, trick headers, and so on all relate to downgrading.
> Most of the downgrade variants also imply burdens --for
> recognition of options, headers, or header parameters-- on
> fully-upgraded systems and will continue to impose those
> requirements even after all, or virtually all, of the Internet
> has been upgraded.

Yes, but once UTF-8 capability has become the norm, newly written software  
will tend to bounce rather than downgrade.

How much current software actually bothers to downgrade to 7bit it it  
finds the following site does not do 8BITMIME?
>
> If poor configurations happen (and I agree that they will) and
> result in bouncing, then there will be complaints and incentives
> to get them fixed.   If they 'just work', then there will be no
> incentive to get them fixed and they may not even be noticed.

If they are "not even noticed", then they are working correctly (including  
upgrading at the proper moment). They ain't broke, and all that ...

-- 
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 Jul 26 17:16:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5qjl-0006NR-Ee; Wed, 26 Jul 2006 17:16:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5qjk-0006NL-8x
	for ima@ietf.org; Wed, 26 Jul 2006 17:16:12 -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 1G5qjj-0000u9-Iv
	for ima@ietf.org; Wed, 26 Jul 2006 17:16:12 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1G5qji-000OaA-Gv; Wed, 26 Jul 2006 17:16:10 -0400
Date: Wed, 26 Jul 2006 17:16:09 -0400
From: John C Klensin <klensin@jck.com>
To: Charles Lindsey <chl@clerew.man.ac.uk>, ima@ietf.org
Subject: Re: [EAI] downgrade annotations and RCPT TO
Message-ID: <6C967B3CBFC911E69489F818@p3.JCK.COM>
In-Reply-To: <op.tdbdnudj6hl8nm@clerew.man.ac.uk>
References: <353820675.17656@cnnic.cn> <353823963.20414@cnnic.cn>
	<00bc01c6afd6$7e320fb0$1206e29f@cnnicyaojk>
	<6B02C220FBC757B3CE16D5AD@p3.JCK.COM>
	<op.tc8tdzjd6hl8nm@clerew.man.ac.uk>
	<B951B4B0656AE44C756FBBA3@p3.JCK.COM>
	<op.tdbdnudj6hl8nm@clerew.man.ac.uk>
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: b22590c27682ace61775ee7b453b40d3
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 Wednesday, 26 July, 2006 21:53 +0100 Charles Lindsey
<chl@clerew.man.ac.uk> wrote:

> On Tue, 25 Jul 2006 12:54:29 +0100, John C Klensin
> <klensin@jck.com> wrote:
> 
>> To make the problem clear, I am going to play devils advocate
>> below -- I am not necessarily convinced of all of it.
>> 
>> Charles, if there were just a matter of "let them work", I
>> would certainly agree with you.   But the issues associated
>> with downgrading comprise virtually all of the issues that
>> make this effort complex.  It is not an accident that our
>> discussions about parameter formats, location of addresses in
>> and out of brackets, trick headers, and so on all relate to
>> downgrading. Most of the downgrade variants also imply
>> burdens --for recognition of options, headers, or header
>> parameters-- on fully-upgraded systems and will continue to
>> impose those requirements even after all, or virtually all,
>> of the Internet has been upgraded.
> 
> Yes, but once UTF-8 capability has become the norm, newly
> written software  will tend to bounce rather than downgrade.

Exactly.  And earlier software will carry around code paths that
no one is using, which we have repeatedly proven is not a good
thing... since such paths become opportunities for subtle bugs
and security exploits.

> How much current software actually bothers to downgrade to
> 7bit it it  finds the following site does not do 8BITMIME?

Not a whole lot, except for packages that implemented
downgrading early-on (see above).  But "does not bother"
comprises two cases.  One is that the message is bounced, and
the other is that the absence of 8BITMIME is just ignored and
the message forwarded.  The latter still causes problems if the
path actually is not 8bit clean.  But 8BITMIME is so widely
implemented at this point that it is actually hard to find
non-artificial cases in which the option is not offered and the
question is relevant.

And that is exactly the reason I'm wondering how much trouble it
is worth going to in order to provide and support downgrading.

>> If poor configurations happen (and I agree that they will) and
>> result in bouncing, then there will be complaints and
>> incentives to get them fixed.   If they 'just work', then
>> there will be no incentive to get them fixed and they may not
>> even be noticed.
> 
> If they are "not even noticed", then they are working
> correctly (including  upgrading at the proper moment). They
> ain't broke, and all that ...

Not necessarily.  The notion that upgrading will need to occur,
ever, depends on a series of target-site configuration decisions
that I find hard to predict.   For example, in many systems, if
a primary UTF-8 address and an alternate ASCII address are
supported, the most efficient way to support both may not be
tricky "upgrade" 
code but a simple system alias.  But that implies, as others
have pointed out, that replies will use the ASCII address path
and there will be no effective use of UTF-8 addressing until the
entire path is upgraded.   That isn't broken, but it also isn't
what we are trying to get accomplished.

>From your other message...

> But does "must" mean "MUST"? You point out that this same
> downgrade is  needed for MAIL FROM, and it is certainly needed
> if the recipient is  genuinely ASCII-only. So you woould be
> giving the appearance of a rather  arbitrary rule.

I don't know what makes the rule arbitrary.   I think it is
clear that, whether downgrading exists and is supported or not,
there are going to be some rough edges when UTF-8-capable
systems, relays, and users communicate with ASCII-only systems,
relays, and users.  Our job, it seems to me, is to sort through
those cases and balance the pain level associated with those
rough edges with the pain level associated with softening or
eliminating them, keeping in mind where we want to end up.  I
believe that the latter involves carrying around as little
legacy clutter as possible from the transition period... and
making that transition period as short as is sensibly possible.


> Moreover, all these issues of whether to downgrade, and
> whether we need to  specify (or imply) Atomic actually turn
> out to be more important in the  case of From/MAIL
> FROM/Reply-To. You can probably ensure that your mail
> addressed to a UTF-8 recipient follows a "sensible"
> (UTF-8-capable) route.  But you cannot assume the same when
> your recipient replies to you.

I [now] think that is probably correct.

> Moreover, there is still the case of a UTF-capable recipient
> sitting  behind an ASCII firewall. Consider the case of an
> American Company whose  top management insists that all
> company mail passes through its firewall  in Denver (top
> management is renowned for giving orders that have no basis
> in the technical realities :-( ). And top management easily
> forgets that  they have offices in China, Taiwan and Korea
> which might want to  comminucate with each other. A stupid
> scenario, but stupider things have  happened.

Yes, but, in the general case, this has no solution.  Said top
management is as likely to insist that everyone in the company
use the same (UTF-8-incapable) MUA or that everyone use
centrally-assigned ASCII addresses all the time so that the
management (or its data auditors) can easily determine the
recipient or sender of any message.  None of this prevents
anyone from communicating with anyone else; it just prevents
them from using non-ASCII addresses or UTF-8 headers.   We can't
solve the problem.  If anything, we probably help to get it
solved by providing as little support for "try to work around
your stupid management" as possible so that the need to permit
people in branch offices to communicate with addresses in their
own scripts hits the bottom line as clearly as possible.

      john




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



From ima-bounces@ietf.org Wed Jul 26 18:47:35 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5sAA-0000np-FX; Wed, 26 Jul 2006 18:47:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5sA8-0000na-Oa
	for ima@ietf.org; Wed, 26 Jul 2006 18:47:32 -0400
Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5sA6-0000B3-Ay
	for ima@ietf.org; Wed, 26 Jul 2006 18:47:32 -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]:34496)
	by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G5sA2-00017l-4b (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Wed, 26 Jul 2006 23:47:26 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1G5sA2-0000n2-Co (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Wed, 26 Jul 2006 23:47:26 +0100
Date: Wed, 26 Jul 2006 23:47:26 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: John C Klensin <klensin@jck.com>
Subject: Re: [EAI] downgrade annotations and RCPT TO
In-Reply-To: <6C967B3CBFC911E69489F818@p3.JCK.COM>
Message-ID: <Pine.LNX.4.64.0607262335330.28712@hermes-2.csi.cam.ac.uk>
References: <353820675.17656@cnnic.cn> <353823963.20414@cnnic.cn>
	<00bc01c6afd6$7e320fb0$1206e29f@cnnicyaojk>
	<6B02C220FBC757B3CE16D5AD@p3.JCK.COM>
	<op.tc8tdzjd6hl8nm@clerew.man.ac.uk>
	<B951B4B0656AE44C756FBBA3@p3.JCK.COM>
	<op.tdbdnudj6hl8nm@clerew.man.ac.uk>
	<6C967B3CBFC911E69489F818@p3.JCK.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
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

On Wed, 26 Jul 2006, John C Klensin wrote:
> --On Wednesday, 26 July, 2006 21:53 +0100 Charles Lindsey
> <chl@clerew.man.ac.uk> wrote:
> >
> > How much current software actually bothers to downgrade to
> > 7bit it it  finds the following site does not do 8BITMIME?
>
> Not a whole lot, except for packages that implemented
> downgrading early-on (see above).

Sendmail does.

> But 8BITMIME is so widely implemented at this point that it is actually
> hard to find non-artificial cases in which the option is not offered and
> the question is relevant.

Dumb application-level proxy firewalls are the example I see most
frequently :-(

> And that is exactly the reason I'm wondering how much trouble it
> is worth going to in order to provide and support downgrading.

Without downgrading you'll never get a critical mass of users.

> > Moreover, all these issues of whether to downgrade, and whether we
> > need to specify (or imply) Atomic actually turn out to be more
> > important in the case of From/MAIL FROM/Reply-To. You can probably
> > ensure that your mail addressed to a UTF-8 recipient follows a
> > "sensible" (UTF-8-capable) route.  But you cannot assume the same when
> > your recipient replies to you.
>
> I [now] think that is probably correct.

I agree. However in this thread I wanted to concentrate on recipient
addresses and to point out that we can significantly simplify the SMTP
extension if we follow some decisions through to their logical
conclusions.

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 Jul 26 22:07:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5vHQ-0003HC-1Y; Wed, 26 Jul 2006 22:07:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5vHP-0003De-36; Wed, 26 Jul 2006 22:07:15 -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 1G5pqw-0005RM-Rj; Wed, 26 Jul 2006 16:19:34 -0400
Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129]
	helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1G5pOM-0008FK-JX; Wed, 26 Jul 2006 15:50:06 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10])
	by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6QJo1p0006453
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Jul 2006 19:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1G5pOL-0001Jz-TU; Wed, 26 Jul 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: <E1G5pOL-0001Jz-TU@stiedprstage1.ietf.org>
Date: Wed, 26 Jul 2006 15:50:01 -0400
X-Spam-Score: -5.9 (-----)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Cc: ima@ietf.org
Subject: [EAI] I-D ACTION:draft-ietf-eai-smtpext-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		: SMTP extension for internationalized email address
	Author(s)	: J. Yao, W. Mao
	Filename	: draft-ietf-eai-smtpext-01.txt
	Pages		: 15
	Date		: 2006-7-26
	
Internationalized email address includes two parts, the local part
and the domain part.  The way email addresses are used by protocols
are different from the way domain names are used.  The most critical
difference is that emails are delivered through a chain of peering
clients and servers while domain names are resolved by name servers
by looking up their own tables.  In addition to this, email transport
protocols SMTP and ESMTP provide a negotiation mechanism through
which clients can make decisions for further processing.  So
internationalized email address is different from the
internationalized domain name (IDN).  It can be solved by exploiting
the negotiation mechanism while IDN can not use the negotiation
mechanism.  So internationalized email address SHOULD be solved in
the mail transport-level using the negotiation mechanism, which is an
architecturally desirable approach.  This document specifies the use
of SMTP extension for internationalized email address delivery.  It
also mentions the backward compatible mechanism for downgrade
procedure, as specified in an associated specification.  The protocol
proposed here is MTA-level solution which is feasible,
architecturally more elegant, and not as difficult to deploy in
relevant communities.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-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-smtpext-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-smtpext-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-7-26132809.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID: <2006-7-26132809.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 Jul 27 12:59:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G69CM-0006HX-2H; Thu, 27 Jul 2006 12:58:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G69CL-0006HO-Cd
	for ima@ietf.org; Thu, 27 Jul 2006 12:58:57 -0400
Received: from lon-mail-3.gradwell.net ([193.111.201.127])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G69CI-00007a-QU
	for ima@ietf.org; Thu, 27 Jul 2006 12:58:57 -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.231) id
	44c8f0a8.12ec7.10a; Thu, 27 Jul 2006 17:58:16 +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 k6RGwCKB029612;
	Thu, 27 Jul 2006 17:58:14 +0100 (BST)
To: "Tony Finch" <dot@dotat.at>, "John C Klensin" <klensin@jck.com>
Subject: Re: [EAI] downgrade annotations and RCPT TO
References: <353820675.17656@cnnic.cn> <353823963.20414@cnnic.cn>
	<00bc01c6afd6$7e320fb0$1206e29f@cnnicyaojk>
	<6B02C220FBC757B3CE16D5AD@p3.JCK.COM>
	<op.tc8tdzjd6hl8nm@clerew.man.ac.uk>
	<B951B4B0656AE44C756FBBA3@p3.JCK.COM>
	<op.tdbdnudj6hl8nm@clerew.man.ac.uk>
	<6C967B3CBFC911E69489F818@p3.JCK.COM>
	<Pine.LNX.4.64.0607262335330.28712@hermes-2.csi.cam.ac.uk>
Message-ID: <op.tdcxe92c6hl8nm@clerew.man.ac.uk>
Date: Thu, 27 Jul 2006 17:58:11 +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.0607262335330.28712@hermes-2.csi.cam.ac.uk>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
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 Wed, 26 Jul 2006 23:47:26 +0100, Tony Finch <dot@dotat.at> wrote:

> On Wed, 26 Jul 2006, John C Klensin wrote:
>
>> And that is exactly the reason I'm wondering how much trouble it
>> is worth going to in order to provide and support downgrading.
>
> Without downgrading you'll never get a critical mass of users.

Yes, I think that is the real reason to have it, and to have it work.  
Hopefully, when it is seen to work, adoption of UTF8smtp will become more  
common, and then downgrading will become unnecessary. Then there will be  
lots of downgrading code not being used, for people to exploit, as John  
said. But I think that is inevitable, and a price we have to pay.
>
>> > Moreover, all these issues of whether to downgrade, and whether we
>> > need to specify (or imply) Atomic actually turn out to be more
>> > important in the case of From/MAIL FROM/Reply-To....
>>
>> I [now] think that is probably correct.
>
> I agree. However in this thread I wanted to concentrate on recipient
> addresses and to point out that we can significantly simplify the SMTP
> extension if we follow some decisions through to their logical
> conclusions.

Once the downgrade code is in the server, and being used for Reply-To and  
for genuine ASCII-only recipients, then you may as well let it be used  
wherever the next hop is ASCII-only (which should be rare - stupid  
management firewalls maybe), but not worth the trouble of switching off or  
forbidding in in that case.

Whether Atomic is or is not needed as part of the downgrade process is an  
orthogonal issue AFAICS.

-- 
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 Fri Jul 28 07:27:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G6QUg-00027X-UH; Fri, 28 Jul 2006 07:27:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G6QUf-00027P-NO
	for ima@ietf.org; Fri, 28 Jul 2006 07:27:01 -0400
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6QUe-0006MT-DY
	for ima@ietf.org; Fri, 28 Jul 2006 07:27:01 -0400
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 90E152596CD
	for <ima@ietf.org>; Fri, 28 Jul 2006 13:25:24 +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 19601-10 for <ima@ietf.org>;
	Fri, 28 Jul 2006 13:25:18 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id E30572596CE
	for <ima@ietf.org>; Fri, 28 Jul 2006 13:25:17 +0200 (CEST)
Message-ID: <44C9F47D.9070809@alvestrand.no>
Date: Fri, 28 Jul 2006 04:26:53 -0700
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: "ima@ietf.org" <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.5 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Subject: [EAI] RCPT TO and ALT-ADDRESS - do we have a consensus?
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

It seems reasonably clear to me that:

- when an UTF8SMTP user sends to an ASCII address, he doesn't need to 
include ALT-ADDR on the RCPT TO - the address is already ASCII.

- when an UTF8SMTP user sends to an UTF8SMTP address, and all the MTAs 
in between are UTF8SMTP, there is no need for an ALT-ADDR on the RCPT TO 
- the message will not be downgraded.

So there are two cases (that I can see) where ALT-ADDR on RCPT TO may be 
useful:

- when an UTF8SMTP user sends to an UTF8SMTP address, and there is a 
non-UTF8SMTP MTA on the path

- when an UTF8SMTP user sends to what he thinks is an UTF8SMTP address, 
but the recipient, for reasons of his own, has decided that he wants the 
mail delivered to an ASCII address

If we remove ALT-ADDR from RCPT TO, we have made the last two cases 
impossible to support - but we have made both the specification and the 
deployment of it simpler.

I have seen a number of messages indicating that this might be OK.

So I'd like to check what people think if forced to choose between 
alternatives:

A - RCPT TO supports the ALT-ADDR parameter
B - RCPT TO does not support the ALT-ADDR parameter

Possible responses would be "A", "B", or "I don't have enough 
information to decide yet"....

                              Harald




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



From ima-bounces@ietf.org Fri Jul 28 11:40:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G6URS-0000IQ-N2; Fri, 28 Jul 2006 11:39:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G6URR-0000I2-4h
	for ima@ietf.org; Fri, 28 Jul 2006 11:39:57 -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 1G6URR-0008Ct-1K
	for ima@ietf.org; Fri, 28 Jul 2006 11:39:57 -0400
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G6URP-0007n0-19
	for ima@ietf.org; Fri, 28 Jul 2006 11:39:56 -0400
Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96])
	by ns3.neustar.com (Postfix) with ESMTP id C36A1175CD
	for <ima@ietf.org>; Fri, 28 Jul 2006 15:39:24 +0000 (GMT)
Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by
	stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 28 Jul 2006 11:39:24 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [EAI] RCPT TO and ALT-ADDRESS - do we have a consensus?
Date: Fri, 28 Jul 2006 11:39:22 -0400
Message-ID: <24EAE5D4448B9D4592C6D234CBEBD59707531E46@stntexch03.cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [EAI] RCPT TO and ALT-ADDRESS - do we have a consensus?
Thread-Index: AcayOMwDjNyJJyBmRHCkyZUMxKQy+QAFL2PQ
From: "Tan, William" <William.Tan@neustar.biz>
To: <ima@ietf.org>
X-OriginalArrivalTime: 28 Jul 2006 15:39:24.0448 (UTC)
	FILETIME=[00A97A00:01C6B25C]
X-Spam-Score: -5.9 (-----)
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>
Content-Type: multipart/mixed; boundary="===============1800418513=="
Errors-To: ima-bounces@ietf.org

--===============1800418513==
Content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

SGkgbGlzdCwNCg0KSSBkb24ndCBrbm93IHdoaWNoIGlzIHdvcnNlLCB0ZWxsaW5nIHBlb3BsZSB0
aGF0Og0KDQpBLiBIZXJlJ3MgbXkgaW50ZXJuYXRpb25hbGl6ZWQgZW1haWwgYWRkcmVzcy4gSWYg
eW91ciBlbWFpbCBjbGllbnQgc3VwcG9ydHMgSUVBIHlvdSBjYW4gc2VuZCBtZSBhbiBlbWFpbCB0
byB0aGUgSUVBIGJ1dCBiZSBzdXJlIHRvIGFsc28gaW5jbHVkZSBteSByZWd1bGFyIEFTQ0lJIGFk
ZHJlc3MgaW4gdGhlIEFMVC1BRERSIGZpZWxkLg0KDQpPciANCg0KQi4gSGVyZSdzIG15IGludGVy
bmF0aW9uYWxpemVkIGVtYWlsIGFkZHJlc3MuIFRyeSBzZW5kaW5nIG1lIGFuIGVtYWlsIHdpdGgg
aXQuIElmIHlvdSBnZXQgYW4gZXJyb3IgdXBvbiBtZXNzYWdlIHN1Ym1pc3Npb24gb3IgYSBib3Vu
Y2UsIHJlc2VuZCB0byBteSByZWd1bGFyIEFTQ0lJIGFkZHJlc3MuDQoNClRoZSBsYXR0ZXIgb3B0
aW9uIG1heSB3b3JrIHNvbWV0aW1lcyBidXQgY291bGQgYWxzbyBmYWlsIGF0IG90aGVyIHRpbWVz
IChlLmcuIGEgcHJpbWFyeSBNWCB0aGF0IHN1cHBvcnRzIFVURjhTTVRQIGJ1dCBzZWNvbmRhcnkg
TVggZG9lcyBub3QpLg0KDQpTbywgSSdkIHBpY2sgdGhlICJJIGRvbid0IGhhdmUgZW5vdWdoIGlu
Zm9ybWF0aW9uIHRvIGRlY2lkZSB5ZXQiIG9wdGlvbi4NCg0Kd2lsLg0KDQo+IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEhhcmFsZCBBbHZlc3RyYW5kIFttYWlsdG86aGFyYWxk
QGFsdmVzdHJhbmQubm9dDQo+IFNlbnQ6IEZyaWRheSwgSnVseSAyOCwgMjAwNiA5OjI3IFBNDQo+
IFRvOiBpbWFAaWV0Zi5vcmcNCj4gU3ViamVjdDogW0VBSV0gUkNQVCBUTyBhbmQgQUxULUFERFJF
U1MgLSBkbyB3ZSBoYXZlIGEgY29uc2Vuc3VzPw0KPiANCj4gSXQgc2VlbXMgcmVhc29uYWJseSBj
bGVhciB0byBtZSB0aGF0Og0KPiANCj4gLSB3aGVuIGFuIFVURjhTTVRQIHVzZXIgc2VuZHMgdG8g
YW4gQVNDSUkgYWRkcmVzcywgaGUgZG9lc24ndCBuZWVkIHRvDQo+IGluY2x1ZGUgQUxULUFERFIg
b24gdGhlIFJDUFQgVE8gLSB0aGUgYWRkcmVzcyBpcyBhbHJlYWR5IEFTQ0lJLg0KPiANCj4gLSB3
aGVuIGFuIFVURjhTTVRQIHVzZXIgc2VuZHMgdG8gYW4gVVRGOFNNVFAgYWRkcmVzcywgYW5kIGFs
bCB0aGUgTVRBcw0KPiBpbiBiZXR3ZWVuIGFyZSBVVEY4U01UUCwgdGhlcmUgaXMgbm8gbmVlZCBm
b3IgYW4gQUxULUFERFIgb24gdGhlIFJDUFQgVE8NCj4gLSB0aGUgbWVzc2FnZSB3aWxsIG5vdCBi
ZSBkb3duZ3JhZGVkLg0KPiANCj4gU28gdGhlcmUgYXJlIHR3byBjYXNlcyAodGhhdCBJIGNhbiBz
ZWUpIHdoZXJlIEFMVC1BRERSIG9uIFJDUFQgVE8gbWF5IGJlDQo+IHVzZWZ1bDoNCj4gDQo+IC0g
d2hlbiBhbiBVVEY4U01UUCB1c2VyIHNlbmRzIHRvIGFuIFVURjhTTVRQIGFkZHJlc3MsIGFuZCB0
aGVyZSBpcyBhDQo+IG5vbi1VVEY4U01UUCBNVEEgb24gdGhlIHBhdGgNCj4gDQo+IC0gd2hlbiBh
biBVVEY4U01UUCB1c2VyIHNlbmRzIHRvIHdoYXQgaGUgdGhpbmtzIGlzIGFuIFVURjhTTVRQIGFk
ZHJlc3MsDQo+IGJ1dCB0aGUgcmVjaXBpZW50LCBmb3IgcmVhc29ucyBvZiBoaXMgb3duLCBoYXMg
ZGVjaWRlZCB0aGF0IGhlIHdhbnRzIHRoZQ0KPiBtYWlsIGRlbGl2ZXJlZCB0byBhbiBBU0NJSSBh
ZGRyZXNzDQo+IA0KPiBJZiB3ZSByZW1vdmUgQUxULUFERFIgZnJvbSBSQ1BUIFRPLCB3ZSBoYXZl
IG1hZGUgdGhlIGxhc3QgdHdvIGNhc2VzDQo+IGltcG9zc2libGUgdG8gc3VwcG9ydCAtIGJ1dCB3
ZSBoYXZlIG1hZGUgYm90aCB0aGUgc3BlY2lmaWNhdGlvbiBhbmQgdGhlDQo+IGRlcGxveW1lbnQg
b2YgaXQgc2ltcGxlci4NCj4gDQo+IEkgaGF2ZSBzZWVuIGEgbnVtYmVyIG9mIG1lc3NhZ2VzIGlu
ZGljYXRpbmcgdGhhdCB0aGlzIG1pZ2h0IGJlIE9LLg0KPiANCj4gU28gSSdkIGxpa2UgdG8gY2hl
Y2sgd2hhdCBwZW9wbGUgdGhpbmsgaWYgZm9yY2VkIHRvIGNob29zZSBiZXR3ZWVuDQo+IGFsdGVy
bmF0aXZlczoNCj4gDQo+IEEgLSBSQ1BUIFRPIHN1cHBvcnRzIHRoZSBBTFQtQUREUiBwYXJhbWV0
ZXINCj4gQiAtIFJDUFQgVE8gZG9lcyBub3Qgc3VwcG9ydCB0aGUgQUxULUFERFIgcGFyYW1ldGVy
DQo+IA0KPiBQb3NzaWJsZSByZXNwb25zZXMgd291bGQgYmUgIkEiLCAiQiIsIG9yICJJIGRvbid0
IGhhdmUgZW5vdWdoDQo+IGluZm9ybWF0aW9uIHRvIGRlY2lkZSB5ZXQiLi4uLg0KPiANCj4gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgSGFyYWxkDQo+IA0KPiANCj4gDQo+IA0KPiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJTUEgbWFpbGlu
ZyBsaXN0DQo+IElNQUBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9pbWENCg==


--===============1800418513==
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

--===============1800418513==--



From ima-bounces@ietf.org Sun Jul 30 08:07:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7A4a-0000w5-PC; Sun, 30 Jul 2006 08:07:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7A4Z-0000w0-DI
	for ima@ietf.org; Sun, 30 Jul 2006 08:07:07 -0400
Received: from lon-mail-4.gradwell.net ([193.111.201.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7A4W-0007lF-Ma
	for ima@ietf.org; Sun, 30 Jul 2006 08:07:07 -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
	44cca0e5.1596.145 for ima@ietf.org; Sun, 30 Jul 2006 13:07:01 +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 k6UC6ufb026456
	for <ima@ietf.org>; Sun, 30 Jul 2006 13:06:56 +0100 (BST)
Received: (from chl@localhost)
	by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id k6UC6u9L026453;
	Sun, 30 Jul 2006 13:06:56 +0100 (BST)
To: "ima@ietf.org" <ima@ietf.org>
Subject: Re: [EAI] RCPT TO and ALT-ADDRESS - do we have a consensus?
References: <44C9F47D.9070809@alvestrand.no>
Message-ID: <op.tdhufcbd6hl8nm@clerew.man.ac.uk>
Date: Sun, 30 Jul 2006 09:41:26 +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: <44C9F47D.9070809@alvestrand.no>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
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, 28 Jul 2006 12:26:53 +0100, Harald Alvestrand  
<harald@alvestrand.no> wrote:

> It seems reasonably clear to me that:
>

> So there are two cases (that I can see) where ALT-ADDR on RCPT TO may be  
> useful:
>
> - when an UTF8SMTP user sends to an UTF8SMTP address, and there is a  
> non-UTF8SMTP MTA on the path
>
> - when an UTF8SMTP user sends to what he thinks is an UTF8SMTP address,  
> but the recipient, for reasons of his own, has decided that he wants the  
> mail delivered to an ASCII address

There is also the case where the UTF8SMTP user has both kinds of address  
(so that he may be reached from anywhere) and has published both in a  
mailto:URL, or in a Reply-To, or wherever else. The man who wishes to mail  
him (and is maybe not sure which to use, or does not understand the  
distinction) just copies the (double) address that he sees, or clicks on  
the mailto, or hits Reply.
>
> If we remove ALT-ADDR from RCPT TO, we have made the last two cases  
> impossible to support - but we have made both the specification and the  
> deployment of it simpler.

> A - RCPT TO supports the ALT-ADDR parameter
> B - RCPT TO does not support the ALT-ADDR parameter

I still prefer A, until persuaded otherwise.

Presumably the full mechanism is still needed for Mail From, and hearders  
such as From and Reply-To. So you might as well provide it all round.

-- 
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 Jul 30 08:08:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7A6F-0001bU-BN; Sun, 30 Jul 2006 08:08:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7A6E-0001bP-16
	for ima@ietf.org; Sun, 30 Jul 2006 08:08:50 -0400
Received: from lon-mail-4.gradwell.net ([193.111.201.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7A6C-0007n4-FE
	for ima@ietf.org; Sun, 30 Jul 2006 08:08:49 -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
	44cca14f.2085.20e for ima@ietf.org; Sun, 30 Jul 2006 13:08: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 k6UC8gUY026568
	for <ima@ietf.org>; Sun, 30 Jul 2006 13:08:42 +0100 (BST)
Received: (from chl@localhost)
	by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id k6UC8gHO026567;
	Sun, 30 Jul 2006 13:08:42 +0100 (BST)
To: ima@ietf.org
Subject: Re: [EAI] RCPT TO and ALT-ADDRESS - do we have a consensus?
References: <24EAE5D4448B9D4592C6D234CBEBD59707531E46@stntexch03.cis.neustar.com>
Message-ID: <op.tdhuqilc6hl8nm@clerew.man.ac.uk>
Date: Sun, 30 Jul 2006 09:48:08 +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: <24EAE5D4448B9D4592C6D234CBEBD59707531E46@stntexch03.cis.neustar.com>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
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, 28 Jul 2006 16:39:22 +0100, Tan, William <William.Tan@neustar.biz>  
wrote:

> Hi list,
>
> I don't know which is worse, telling people that:
>
> A. Here's my internationalized email address. If your email client  
> supports IEA you can send me an email to the IEA but be sure to also  
> include my regular ASCII address in the ALT-ADDR field.

I think what the man is most likely to do is to say "my email address is
     <utf8@utf8:ascii@ascii>"
or maybe
     "<utf8@utf8:atomic>"
(assuming that ':' is the separator we have not fixed on yet). And he will  
expect the man to figure it out or, more likely, to paste it into his MUA  
and let his MUA figure it out.

-- 
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 Jul 30 18:59:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7KG0-0004Pm-Mo; Sun, 30 Jul 2006 18:59:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7KFz-0004Ph-9W
	for ima@ietf.org; Sun, 30 Jul 2006 18:59:35 -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 1G7KFx-0007F0-V3
	for ima@ietf.org; Sun, 30 Jul 2006 18:59:35 -0400
Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34)
	id 1G7KFv-00045c-HG; Sun, 30 Jul 2006 18:59:32 -0400
Date: Sun, 30 Jul 2006 18:50:03 -0400
From: John C Klensin <klensin@jck.com>
To: Charles Lindsey <chl@clerew.man.ac.uk>, ima@ietf.org
Subject: Re: [EAI] RCPT TO and ALT-ADDRESS - do we have a
 consensus?
Message-ID: <DBD9F5CFAA8B973BC1AEEEE8@7AD4D3FB4841A5E367CCF211>
In-Reply-To: <op.tdhuqilc6hl8nm@clerew.man.ac.uk>
References: <24EAE5D4448B9D4592C6D234CBEBD59707531E46@stntexch03.c
	is.neustar.com> <op.tdhuqilc6hl8nm@clerew.man.ac.uk>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
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 Sunday, July 30, 2006 9:48 AM +0100 Charles Lindsey 
<chl@clerew.man.ac.uk> wrote:

> On Fri, 28 Jul 2006 16:39:22 +0100, Tan, William
> <William.Tan@neustar.biz>  wrote:
>
>> Hi list,
>>
>> I don't know which is worse, telling people that:
>>
>> A. Here's my internationalized email address. If your email
>> client   supports IEA you can send me an email to the IEA but
>> be sure to also   include my regular ASCII address in the
>> ALT-ADDR field.
>
> I think what the man is most likely to do is to say "my email
> address is
>      <utf8@utf8:ascii@ascii>"
> or maybe
>      "<utf8@utf8:atomic>"
> (assuming that ':' is the separator we have not fixed on yet).
> And he will  expect the man to figure it out or, more likely,
> to paste it into his MUA  and let his MUA figure it out.

But each of these approaches causes its own problems, starting 
with not being acceptable to a system that doesn't understand 
any of these conventions -- the precise one that downgrading is 
intended to help.

FWIW, the syntax <string1@string2:string3@string4> has been 
historically accepted by some MTAs, in the interest of 
robustness, as equivalent to 
<@string1,@string2:string3@string4>.  Now, we could say "they 
are broken, or too permissive, and so don't count", but that 
doesn't seem wise to me.

     john





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



From ima-bounces@ietf.org Sun Jul 30 18:59:41 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7KG5-0004RM-R1; Sun, 30 Jul 2006 18:59:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7KG4-0004RH-Lw
	for ima@ietf.org; Sun, 30 Jul 2006 18:59:40 -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 1G7KG3-0007FE-95
	for ima@ietf.org; Sun, 30 Jul 2006 18:59:40 -0400
Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34)
	id 1G7KG1-00045c-I8; Sun, 30 Jul 2006 18:59:38 -0400
Date: Sun, 30 Jul 2006 18:44:46 -0400
From: John C Klensin <klensin@jck.com>
To: "Tan, William" <William.Tan@neustar.biz>, ima@ietf.org
Subject: RE: [EAI] RCPT TO and ALT-ADDRESS - do we have a
 consensus?
Message-ID: <6209C9A2688E7CE0C644F271@7AD4D3FB4841A5E367CCF211>
In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD59707531E46@stntexch03.cis.neustar.com>
References: <24EAE5D4448B9D4592C6D234CBEBD59707531E46@stntexch03.
	cis.neustar.com>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
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 Friday, July 28, 2006 11:39 AM -0400 "Tan, William" 
<William.Tan@neustar.biz> wrote:

> Hi list,
>
> I don't know which is worse, telling people that:
>
> A. Here's my internationalized email address. If your email
> client supports IEA you can send me an email to the IEA but be
> sure to also include my regular ASCII address in the ALT-ADDR
> field.
>
> Or
>
> B. Here's my internationalized email address. Try sending me
> an email with it. If you get an error upon message submission
> or a bounce, resend to my regular ASCII address.
>
> The latter option may work sometimes but could also fail at
> other times (e.g. a primary MX that supports UTF8SMTP but
> secondary MX does not).

See the earlier discussion about configuration choices. 
However, I'd suggest that there is a "C":

        Here is my internationalized email address.  It should
        work, but, if something should go wrong and the message
        bounce back to you, here is a different address that you
        can use instead.

Now, observe two things about that statement.  The first is that 
similar things are done today, even when all of the relevant 
addresses are all-ASCII.  Web sites often ask for alternate 
addresses in case the main one is undeliverable, people with 
particularly aggressive anti-spam or other policy filters 
(especially ones that are not under their control) sometimes 
supply alternate addresses, people give out alternate phone 
numbers, and so on.   The second is that, as stated, downgrading 
is done, if necessary, by the sender and not by some automated 
conversion process in the middle of the network.  Those more 
formalized in-network processes may be more convenient if we can 
get them to work well and reliably but we should keep in mind 
that, ultimately, they are just substitutes for a "tell the 
sender what to do if something doesn't work" mechanism.

> So, I'd pick the "I don't have enough information to decide
> yet" option.

I'm undecided too, but, as complexity gets layered on complexity 
in an effort to resolve this, I'm gradually shifting (although 
I'd like to see downgrading work and my mind is definitely not 
made up).

      john


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



From ima-bounces@ietf.org Mon Jul 31 02:03:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7Qsb-0004Ru-C5; Mon, 31 Jul 2006 02:03:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Qsa-0004Pz-FH
	for ima@ietf.org; Mon, 31 Jul 2006 02:03:52 -0400
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7QsY-0007Xq-IJ
	for ima@ietf.org; Mon, 31 Jul 2006 02:03:52 -0400
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 44C362580CF;
	Mon, 31 Jul 2006 08:02:12 +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 31872-02; Mon, 31 Jul 2006 08:02:07 +0200 (CEST)
Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162])
	by eikenes.alvestrand.no (Postfix) with ESMTP id A5B122580CC;
	Mon, 31 Jul 2006 08:02:07 +0200 (CEST)
Message-ID: <44CD9D3C.5020800@alvestrand.no>
Date: Mon, 31 Jul 2006 08:03:40 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Charles Lindsey <chl@clerew.man.ac.uk>
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>
In-Reply-To: <op.tdhuqilc6hl8nm@clerew.man.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.5 (/)
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

Charles Lindsey wrote:
> On Fri, 28 Jul 2006 16:39:22 +0100, Tan, William 
> <William.Tan@neustar.biz> wrote:
>
>> Hi list,
>>
>> I don't know which is worse, telling people that:
>>
>> A. Here's my internationalized email address. If your email client 
>> supports IEA you can send me an email to the IEA but be sure to also 
>> include my regular ASCII address in the ALT-ADDR field.
>
> I think what the man is most likely to do is to say "my email address is
>     <utf8@utf8:ascii@ascii>"
> or maybe
>     "<utf8@utf8:atomic>"
> (assuming that ':' is the separator we have not fixed on yet). And he 
> will expect the man to figure it out or, more likely, to paste it into 
> his MUA and let his MUA figure it out. 
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.
If that decision is upheld (and reflected in our work on mailto: and so 
on), what you mention above won't happen.

                   Harald


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



From ima-bounces@ietf.org Mon Jul 31 06:11:32 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7UkC-00040x-Ku; Mon, 31 Jul 2006 06:11:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7UkA-00040s-Rq
	for ima@ietf.org; Mon, 31 Jul 2006 06:11:26 -0400
Received: from lon-mail-4.gradwell.net ([193.111.201.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Uk8-0005w6-9Z
	for ima@ietf.org; Mon, 31 Jul 2006 06:11:26 -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
	44cdd74a.fc21.1ed7 for ima@ietf.org; Mon, 31 Jul 2006 11:11:22 +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 k6VABK3v001695
	for <ima@ietf.org>; Mon, 31 Jul 2006 11:11:21 +0100 (BST)
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>
Message-ID: <op.tdjs86gu6hl8nm@clerew.man.ac.uk>
Date: Mon, 31 Jul 2006 11:11:20 +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: <44CD9D3C.5020800@alvestrand.no>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
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 07:03:40 +0100, Harald Alvestrand  
<harald@alvestrand.no> wrote:

> Charles Lindsey wrote:

>>     <utf8@utf8:ascii@ascii>"
>> or maybe
>>     "<utf8@utf8:atomic>"

> 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.

Well that has not been reported to this List. What else was decided at  
Montreal that we have not been told about?

And more to the point, what notation has been put in its place?

We are agreed that a man may need to have alternative utf8 and ASCII  
addresses. What is he supposed to put in his From/Reply-To in order to  
inform his correspondents how to get back to him?

> If that decision is upheld (and reflected in our work on mailto: and so  
> on), what you mention above won't happen.

And yes, we are going to need some notation in a revised mailto to convey  
this same information.

-- 
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 Mon Jul 31 14:35:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7cbb-00069y-0b; Mon, 31 Jul 2006 14:35:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7cbZ-00069t-NK
	for ima@ietf.org; Mon, 31 Jul 2006 14:35:05 -0400
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7cbX-0004gu-DY
	for ima@ietf.org; Mon, 31 Jul 2006 14:35:05 -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]:60786)
	by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G7cbO-0003Mx-2W (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 31 Jul 2006 19:34:54 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1G7cbE-0007Cj-LE (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 31 Jul 2006 19:34:44 +0100
Date: Mon, 31 Jul 2006 19:34:44 +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: <44C9F47D.9070809@alvestrand.no>
Message-ID: <Pine.LNX.4.64.0607311929420.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.2 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
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

On Fri, 28 Jul 2006, Harald Alvestrand wrote:
>
> So there are two cases (that I can see) where ALT-ADDR on RCPT TO may be
> useful:
>
> - when an UTF8SMTP user sends to an UTF8SMTP address, and there is a
> non-UTF8SMTP MTA on the path

Allowing downgrading of UTF8-to-UTF8 email would be a change to the WG's
basic framework.

> - when an UTF8SMTP user sends to what he thinks is an UTF8SMTP address, but
> the recipient, for reasons of his own, has decided that he wants the mail
> delivered to an ASCII address

I presume you have forwarding in mind here. ALT-ADDRESS is not necessary
in the forwarding case because the ASCII address is provided by the
forwarder not the sender.

> B - RCPT TO does not support the ALT-ADDR parameter

+1 (and not the DOWNGRADABLE parameter either)

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 Jul 31 14:41:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7chq-0008JB-Ir; Mon, 31 Jul 2006 14:41:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7chp-0008Ix-JV
	for ima@ietf.org; Mon, 31 Jul 2006 14:41:33 -0400
Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7chn-0005HC-Dx
	for ima@ietf.org; Mon, 31 Jul 2006 14:41:33 -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]:34035)
	by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G7chi-0007ex-Vj (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 31 Jul 2006 19:41:26 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1G7chi-0007k9-Pj (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 31 Jul 2006 19:41:26 +0100
Date: Mon, 31 Jul 2006 19:41:26 +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: <44CD9D3C.5020800@alvestrand.no>
Message-ID: <Pine.LNX.4.64.0607311936290.2500@hermes-2.csi.cam.ac.uk>
References: <24EAE5D4448B9D4592C6D234CBEBD59707531E46@stntexch03.cis.neustar.com>
	<op.tdhuqilc6hl8nm@clerew.man.ac.uk> <44CD9D3C.5020800@alvestrand.no>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
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

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.

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 Jul 31 20:43:24 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7iLu-000058-2l; Mon, 31 Jul 2006 20:43:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7iLs-000053-Ir
	for ima@ietf.org; Mon, 31 Jul 2006 20:43:16 -0400
Received: from [159.226.7.146] (helo=cnnic.cn)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7iLq-0007W1-S6
	for ima@ietf.org; Mon, 31 Jul 2006 20:43:16 -0400
Received: (eyou send program); Tue, 01 Aug 2006 08:43:02 +0800
Message-ID: <354392982.23282@cnnic.cn>
X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn
Received: from unknown (HELO cnnick0mevtm48) (127.0.0.1)
	by 127.0.0.1 with SMTP; Tue, 01 Aug 2006 08:43:02 +0800
Message-ID: <002601c6b503$b139ea90$f1cbe29f@cnnick0mevtm48>
From: "Yao Jiankang" <yaojk@cnnic.cn>
To: <ima@ietf.org>
Date: Tue, 1 Aug 2006 08:43:42 +0800
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.2 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: eludom@gmail.com
Subject: [EAI] Fw: Observatoins on
	http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-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>
Content-Type: multipart/mixed; boundary="===============0098230642=="
Errors-To: ima-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0098230642==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0021_01C6B546.980D3B60"

This is a multi-part message in MIME format.

------=_NextPart_000_0021_01C6B546.980D3B60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

Zm9yd2FyZGVkIGlzIGZyb20gZWx1ZG9tQGdtYWlsLmNvbSwgd2hvIG1heSBzZW5kIHRoZSBtZXNz
YWdlIHRvIHdyb25nIG1haWwgYWRkcmVzcyAobWFpQGlldGYub3JnKS4gc2hvdWxkIGJlIGltYUBp
ZXRmLm9yZw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogR2VvcmdlIEpv
bmVzIA0KVG86IG1hb0Bjbm5pYy5jbiA7IHlhb2prQGNubmljLmNuIA0KQ2M6IG1haUBpZXRmLm9y
ZyANClNlbnQ6IE1vbmRheSwgSnVseSAzMSwgMjAwNiA4OjUyIFBNDQpTdWJqZWN0OiBPYnNlcnZh
dG9pbnMgb24gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1l
YWktc210cGV4dC0wMS50eHQNCg0KDQo+IFNvIGludGVybmF0aW9uYWxpemVkIGVtYWlsIGFkZHJl
c3MgU0hPVUxEIGJlIHNvbHZlZCBpbj4gICB0aGUgbWFpbCB0cmFuc3BvcnQtbGV2ZWwgdXNpbmcg
dGhlIG5lZ290aWF0aW9uIG1lY2hhbmlzbSwgd2hpY2ggaXMgYW4+ICAgYXJjaGl0ZWN0dXJhbGx5
IGRlc2lyYWJsZSBhcHByb2FjaC5KdXN0IGFuIG9ic2VydmF0aW9uLiAgIFRoaXMgYXNzdW1lcyBs
b3cgbGF0ZW5jeSBlbmQtdG8tZW5kIGNvbm5lY3Rpdml0eSBvZiB0aGUNCm1haWwgdHJhbnBvcnQu
ICBUaGVyZSBhcmUgc2lnbmlmaWNhbnQgY2FzZXMgaW4gdGhlIHBhc3QgKGUuZy4gVVVDUCkgYW5k
IHNvbWVwb3NzaWJseSBzaWduaWZpY2FudCBmdXR1cmUgY2FzZXMgKHNlZSB0aGUgRFROUkcpIHdo
ZXJlIHRoaXMgbWF5IG5vdCBiZSB0aGVjYXNlIChMT05HIHJvdW5kIHRyaXAgdGltZXMsIG9uZSB3
YXkgb3IgdW5yZWxpYWJsZSBsaW5rcyksIGV0Yy4NClRoZXNlIG1heSBiZSBvdXQgb2Ygc2NvcGUs
IGJ1dCB5b3UgbWlnaHQgd2FudCB0byBtYWtlIHRoZSBhc3N1bXB0b2luIGV4cGxpY2l0Li0tLUdl
b3JnZSBKb25lcw==

------=_NextPart_000_0021_01C6B546.980D3B60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M
IDYuMDAuMjgwMC4xMTA2IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE
Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMw
Nzsgc2l6ZT0yPmZvcndhcmRlZCBpcyBmcm9tIDxBIA0KaHJlZj0ibWFpbHRvOmVsdWRvbUBnbWFp
bC5jb20iPmVsdWRvbUBnbWFpbC5jb208L0E+LCB3aG8gbWF5IHNlbmQgdGhlIG1lc3NhZ2UgdG8g
DQp3cm9uZyBtYWlsIGFkZHJlc3MgKDxBIGhyZWY9Im1haWx0bzptYWlAaWV0Zi5vcmciPm1haUBp
ZXRmLm9yZzwvQT4pLiBzaG91bGQgYmUgDQppbWFAaWV0Zi5vcmc8L0ZPTlQ+PC9ESVY+DQo8RElW
PjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0K
PERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPi0tLS0tIE9yaWdpbmFsIE1l
c3NhZ2UgLS0tLS0gDQo8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBmb250LWNvbG9y
OiBibGFjayI+PEI+RnJvbTo8L0I+IDxBIA0KdGl0bGU9ZWx1ZG9tQGdtYWlsLmNvbSBocmVmPSJt
YWlsdG86ZWx1ZG9tQGdtYWlsLmNvbSI+R2VvcmdlIEpvbmVzPC9BPiA8L0RJVj4NCjxESVY+PEI+
VG86PC9CPiA8QSB0aXRsZT1tYW9AY25uaWMuY24gDQpocmVmPSJtYWlsdG86bWFvQGNubmljLmNu
Ij5tYW9AY25uaWMuY248L0E+IDsgPEEgdGl0bGU9eWFvamtAY25uaWMuY24gDQpocmVmPSJtYWls
dG86eWFvamtAY25uaWMuY24iPnlhb2prQGNubmljLmNuPC9BPiA8L0RJVj4NCjxESVY+PEI+Q2M6
PC9CPiA8QSB0aXRsZT1tYWlAaWV0Zi5vcmcgDQpocmVmPSJtYWlsdG86bWFpQGlldGYub3JnIj5t
YWlAaWV0Zi5vcmc8L0E+IDwvRElWPg0KPERJVj48Qj5TZW50OjwvQj4gTW9uZGF5LCBKdWx5IDMx
LCAyMDA2IDg6NTIgUE08L0RJVj4NCjxESVY+PEI+U3ViamVjdDo8L0I+IE9ic2VydmF0b2lucyBv
biA8QSANCmhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWll
dGYtZWFpLXNtdHBleHQtMDEudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1pZXRmLWVhaS1zbXRwZXh0LTAxLnR4dDwvQT48L0RJVj48L0RJVj4NCjxESVY+PEJS
PjwvRElWPjxQUkU+Jmd0OyBTbyBpbnRlcm5hdGlvbmFsaXplZCBlbWFpbCBhZGRyZXNzIFNIT1VM
RCBiZSBzb2x2ZWQgaW48QlI+Jmd0OyAgIHRoZSBtYWlsIHRyYW5zcG9ydC1sZXZlbCB1c2luZyB0
aGUgbmVnb3RpYXRpb24gbWVjaGFuaXNtLCB3aGljaCBpcyBhbjxCUj4mZ3Q7ICAgYXJjaGl0ZWN0
dXJhbGx5IGRlc2lyYWJsZSBhcHByb2FjaC48QlI+PEJSPkp1c3QgYW4gb2JzZXJ2YXRpb24uICAg
VGhpcyBhc3N1bWVzIGxvdyBsYXRlbmN5IGVuZC10by1lbmQgY29ubmVjdGl2aXR5IG9mIHRoZQ0K
PEJSPm1haWwgdHJhbnBvcnQuICBUaGVyZSBhcmUgc2lnbmlmaWNhbnQgY2FzZXMgaW4gdGhlIHBh
c3QgKGUuZy4gVVVDUCkgYW5kIHNvbWU8QlI+cG9zc2libHkgc2lnbmlmaWNhbnQgZnV0dXJlIGNh
c2VzIChzZWUgdGhlIERUTlJHKSB3aGVyZSB0aGlzIG1heSBub3QgYmUgdGhlPEJSPmNhc2UgKExP
Tkcgcm91bmQgdHJpcCB0aW1lcywgb25lIHdheSBvciB1bnJlbGlhYmxlIGxpbmtzKSwgZXRjLg0K
PEJSPjxCUj5UaGVzZSBtYXkgYmUgb3V0IG9mIHNjb3BlLCBidXQgeW91IG1pZ2h0IHdhbnQgdG8g
bWFrZSB0aGUgYXNzdW1wdG9pbiBleHBsaWNpdC48QlI+PEJSPi0tLUdlb3JnZSBKb25lczxCUj48
L1BSRT48L0JPRFk+PC9IVE1MPg0K

------=_NextPart_000_0021_01C6B546.980D3B60--



--===============0098230642==
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

--===============0098230642==--





From ima-bounces@ietf.org Mon Jul 31 20:53:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7iVy-00056f-Q9; Mon, 31 Jul 2006 20:53:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7iVx-00056a-T5
	for ima@ietf.org; Mon, 31 Jul 2006 20:53:41 -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 1G7iVw-0008Fr-GU
	for ima@ietf.org; Mon, 31 Jul 2006 20:53:41 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1G7iVv-000Bbe-2o; Mon, 31 Jul 2006 20:53:39 -0400
Date: Mon, 31 Jul 2006 20:53:38 -0400
From: John C Klensin <klensin@jck.com>
To: Yao Jiankang <yaojk@cnnic.cn>, ima@ietf.org
Subject: Re: [EAI] Fw: Observatoins
	on	http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-01.t xt
Message-ID: <1146DFEE25399CE6AD724F55@scan.jck.com>
In-Reply-To: <354392982.23282@cnnic.cn>,
	<002601c6b503$b139ea90$f1cbe29f@cnnick0mevtm48>
References: <354392982.23282@cnnic.cn>,
	<002601c6b503$b139ea90$f1cbe29f@cnnick0mevtm48>
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: 50a516d93fd399dc60588708fd9a3002
Cc: eludom@gmail.com
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, 01 August, 2006 08:43 +0800 Yao Jiankang
<yaojk@cnnic.cn> wrote:

> forwarded is from eludom@gmail.com, who may send the message
> to wrong mail address (mai@ietf.org). should be ima@ietf.org
> 
> ----- Original Message ----- 
> From: George Jones 
> To: mao@cnnic.cn ; yaojk@cnnic.cn 
> Cc: mai@ietf.org 
> Sent: Monday, July 31, 2006 8:52 PM
> Subject: Observatoins on
> http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-01.
> txt
> 
> 
>> So internationalized email address SHOULD be solved in>   the
>> mail transport-level using the negotiation mechanism, which
>> is an>   architecturally desirable approach.Just an
>> observation.   This assumes low latency end-to-end
>> connectivity of the
> mail tranport.  There are significant cases in the past (e.g.
> UUCP) and somepossibly significant future cases (see the
> DTNRG) where this may not be thecase (LONG round trip times,
> one way or unreliable links), etc. These may be out of scope,
> but you might want to make the assumptoin explicit.---George
> Jones

George,

As far as I know, we have made no such assumption.  Indeed,
things might be a bit easier if we made the assumption that the
sending (or submission) SMTP was directly connected to the
destination one, even with high latency.   But this is designed
to work in the classic, hop-by-hop relay model of email and as
robustly as anything else that model supports (including cases
of store and forward transport with per-hop connections being
made less often than daily... been there, done that, made the
systems work).

So, if you find someplace where we have made a low latency
end-to-end assumption, (i) I would be really surprised and (ii)
you should tell us so it can be fixed.

regards,
    john


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