From ima-bounces@ietf.org Thu Jun 01 05:52:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FljrK-00071d-RL; Thu, 01 Jun 2006 05:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FljrI-00071X-MC for ima@ietf.org; Thu, 01 Jun 2006 05:52:52 -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 1FljrH-0004kL-JI for ima@ietf.org; Thu, 01 Jun 2006 05:52:52 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Fljr9-000BAx-I9; Thu, 01 Jun 2006 05:52:44 -0400 Date: Thu, 01 Jun 2006 05:52:41 -0400 From: John C Klensin To: YAO Jiankang Subject: Re: [EAI] Comments on draft-ietf-eai-smtp-00.txt Message-ID: <29261D0C982C2CF39BD8B8E2@JCK-ACR.jck.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.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: Charles Lindsey , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Several comments below. Let's make an agenda item for Beijing on terminology to be used. The decisions are more or less arbitrary, but we need to be consistent. And I, at least, have achieved confusion. --On Thursday, June 01, 2006 11:36 AM +0800 YAO Jiankang wrote: > > ----- Original Message ----- > From: "Charles Lindsey" > To: > Sent: Tuesday, May 30, 2006 2:46 AM > Subject: [EAI] Comments on draft-ietf-eai-00.txt >... >> 6. Servers offering this extension MUST provide support >> for, and announce, the 8BITMIME extension [RFC1652]. >> >> Hmmm! I see that this means you are supposed to include a >> BODY=8BITMIME parameter in your MAIL FROM command if the >> body uses TCE 8bit (highly probable in an EAI message). Do >> agents currently do that in practice? > > can I suggest that where in the fields there use MIME now , > still use MIME in the email message or content. we only update > the fields containing the UET-8 email address to UTF8. I don't understand this response, but I'm not sure I understand Charles's comment, partially because there is no client practice yet. My assumption is that clients or servers supporting EAI MUST be fully-conformant with 8BITMIME. I assume that makes the answer to Charles's question not "supposed to" but "MUST". As far as the transport is concerned, the 2821 headers are just message content so, if they are extended and transmitted in UTF-8 then 8BITMIME must be present. We could, in principle, define these extensions as subsuming 8BITMIME, but it seems to me that would be error-prone and of no particular advantage. Others may disagree; if so, we need to discuss. >> However, there is another possible 8BITMIME problem. Suppose >> your message is a multipart, and suppose one of the headers >> of one of the multiparts contains some UTF-8, e.g. >> Content-Disposition: ... filename="some utf-8 stuff" >> (which surely we want to allow, though it is actually an >> extension to RFC 2045 which needs to be mentioned in the >> utf8headers document). Now this message encounters a server >> which supports neither IEmail nor 8BITMIME. RFC 1652 tells >> you to downgrade to 7bit or else to bounce, so in this case >> the "some utf-8 stuff" needs to be downgraded accordig to RFC >> 2231, and this needs to be mentioned somewhere in our >> drafts. Maybe the downgrade document is the place to do it, >> but I mention it here to make sure it does not get >> forgotten. The downgrade document is the place to do it. This runs into the "no multiple encapsulations" rule and requires very careful consideration. My guess is that the UTF-8 headers doc needs to note that it updates 2045 and that the downgrade one needs to note that it updates 1652... but the differences in how headers are handled might make a case for defining these extensions on their own, rather than by reference to 8BITMIME, despite what I've said above. >... >> An SMTP Client that receives the IMA extension keyword >> MAY transmit a mailbox name as an internationalized >> string in UTF-8 form and MAY >> >> s/receives the IMA extension keyword MAY/receives the IMA >> extension keyword in response to EHLO MAY/ > > ok, will update it. Harmless, but I think unnecessary. The thing that is necessary is a requirement that the keyword MUST NOT be sent unless the extension is advertised, and we have that. >... > .... If the IMA SMTP extension is not offered by >> the Server, the SMTP Client MUST NOT transmit an >> internationalized address and MUST NOT transmit a mail >> body which contains internationalized mail headers >> [IMA-utf8header]. Instead, it MUST either return the >> message to the user as undeliverable or replace it with >> the alternate ASCII address. ..... >> >> Are you trying to cover addresses in both SMTP commands and >> in email headers here? If so, then the words "a mail body" >> are wrong (the body of a message does not include its >> headers, apart from in multiparts as I mentioned earlier). >> So I think you need >> >> s/a mail body/a message/ > > > yes, will use "a message". Still not quite right, because either "message" or "mail body" also contains content. E.g., we have Envelope Headers Body the restriction above applies properly to the first two, but it would be a bad idea to accidentally try to specify how addresses are represented in the message body itself. For example, while the address would not be usable, nothing prohibits .... Header-stuff... Content-type: text/plain; charset=UTF-8 Hi there, my preferred email address is utf-8-stuff@utf-8-stuff.example.com . today, with unextended SMTP (although a CTE would presumably be required) >> but in either case, "it" is too vague, so >> >> s/it/all addresses (both in the envelope and in the message's >> header fields)/ > > will consider it carefully. >> ... If it is replaced, the replacement >> MUST be either the ASCII-only address specified with the >> ALT-ADDRESS parameter or with an address obtained from >> some algorithmic conversions of the primary address that >> conforms to the syntax rules of RFC 2821, which is >> defined in [IMA-downgrading]. >> >> That wording is fine if the client is an earlier >> IEmail-compliant server, but if the the client is the >> originating MUA it doesn't have an ALT-ADDRESS to hand. It >> has to invent one by whatever means (maybe it found one in >> the To: header, maybe it had a table of mappings). > > yes. The more of this sort of thing we can shift into the downgrading document, the better off we will be. It has to cover the material, covering it here as well is just an invitation to inconsistency. See if it is possible to define the syntax and semantics of the parameters but indicate that the information is not needed unless downgrading is necessary; if downgrading is necessary, the downgrade document specifies how they are used. Does that make sense? >> There is a further complication. Suppose a message arrives at >> some intermediate server with one ALT-ADDRESS in its RCPT >> TO: command, and a different one in its To: header. I think >> the only sensible thing to do is to use the one in the RCPT >> TO: command in the ongoing (downgraded) RCPT TO:, and the >> one from the To: header in the ongoing (downgraded) To: >> header. Note that this anomaly is perfectly possible if, for >> example, this is a message being propagated by some mailing >> list expander. > > can we do some specification (address synchronize) in the > utf-8-headers document to avoid such anomaly in the "RCPT To" > and "To: header"? for example, if ALT-ADDRESS is used in "RCPT > To", "To: header" will also use ALT-ADDRESS. Probably not, since the addresses in the RCPT commands need not appear at all in the headers. The usual general guideline probably applies here -- to the extent possible, MTAs pay attention to the envelope only. That makes any ALT-ADDRESS in the headers mostly useful for forming replies at the receiving MUA. >... >> However, you cannot specify Stringprep without stating what >> 'profile' of Stringprep you require. Maybe you can find an >> existing one that suits your need (but not Nameprep, >> because that removes and upper/lowercase distinctions). You >> could easily define your own profile by indicating which of >> the various tables from RFC 3454 were to be applied. I agree >> that local-parts should have _some_ suitable Stringprep >> applied to them. They are essentially 'identifiers' in >> nature, and should at least adhere to WYSIWYG (but note in >> passing that RFC 2822 local-parts already fail Stringprep >> by permitting control characters). WYSIWYG is more or less equivalent to the fax constraint Charles suggested earlier. Because it is in the eye of the beholder, it is basically impossible with Unicode. > > Yes, we should have our own Stringprep for the email local > part. We need to be careful here. First, stringprep, as usually used, specifies treatment of strings, potentially unnormalized ones, so they can be compared. I think we are going to get into bad shape if we permit unnormalized/ uncanonicalized strings at all. See the discussion in draft-klensin-net-utf8, but note that the conventions recommended there are probably not appropriate for these addresses. My guess is that we should stick fairly closely to NFKC, but others probably want to comment on that. And, of course, doing anything with NFKC or NFC gets us into the Unicode versioning mess. I thought we had agreed to prohibit control characters in non-ASCII local parts -- in the past, they have been more trouble than they are worth. If we haven't, we need to discuss it quickly. If we have, then this document must be explicit about it. >> As an aside, I just noticed that John KLensin's utf8 draft >> cannot be expressed as a profile of Stringprep (which is >> actually as it should be, because it is not trying to >> restrict itself to 'identifier's). That is correct and was intentional. >... >> ... If the >> ALT-ADDRESS value is not set by the sender but the value >> of ATOMIC is 'y', the sender SMTP server should apply >> some algorithmic transformation such as punycode to the >> entire local part of IMA; ... >> >> No, from the POV of the server that might be going to >> downgrade the address, the "sender" is actually an SMTP >> "client" (which might be another server, or might be an >> MUA). > > so we change the word "sender" to "email user", is it ok? Please don't try to invent more terminology unless absolutely necessary. I would read "email user" as the human being who interacts with the message-creating MUA, and that is certainly not what is intended in all of the uses in that paragraph. 2821 uses "SMTP client" and "SMTP server" where feasible and reverts to the 821 terminology of "SMTP sender" and "SMTP receiver" when needed for clarity. "sender SMTP server" is pretty close to a contradiction. See above about getting as much of this into the downgrade document as possible. >... john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 01 09:04:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flmqg-0000q7-CR; Thu, 01 Jun 2006 09:04:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flmqe-0000pX-CR for ima@ietf.org; Thu, 01 Jun 2006 09:04:24 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flmq1-0007a7-FV for ima@ietf.org; Thu, 01 Jun 2006 09:03:46 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9345E25973C; Thu, 1 Jun 2006 15:02:51 +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 09178-10; Thu, 1 Jun 2006 15:02:47 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BAD17259738; Thu, 1 Jun 2006 15:02:47 +0200 (CEST) Message-ID: <447EE5AC.3040407@alvestrand.no> Date: Thu, 01 Jun 2006 06:03:40 -0700 From: Harald Alvestrand User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060503) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin Subject: 8BITMIME and BODY=8BITMIME (Re: [EAI] Comments on draft-ietf-eai-smtp-00.txt) References: <29261D0C982C2CF39BD8B8E2@JCK-ACR.jck.com> In-Reply-To: <29261D0C982C2CF39BD8B8E2@JCK-ACR.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Charles Lindsey , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > > Several comments below. Let's make an agenda item for Beijing on > terminology to be used. The decisions are more or less arbitrary, but > we need to be consistent. And I, at least, have achieved confusion. > > > --On Thursday, June 01, 2006 11:36 AM +0800 YAO Jiankang > wrote: > >> >> ----- Original Message ----- >> From: "Charles Lindsey" >> To: >> Sent: Tuesday, May 30, 2006 2:46 AM >> Subject: [EAI] Comments on draft-ietf-eai-00.txt >> ... >> >>> 6. Servers offering this extension MUST provide support >>> for, and announce, the 8BITMIME extension [RFC1652]. >>> >>> Hmmm! I see that this means you are supposed to include a >>> BODY=8BITMIME parameter in your MAIL FROM command if the >>> body uses TCE 8bit (highly probable in an EAI message). Do >>> agents currently do that in practice? >> >> >> can I suggest that where in the fields there use MIME now , >> still use MIME in the email message or content. we only update >> the fields containing the UET-8 email address to UTF8. > > > I don't understand this response, but I'm not sure I understand > Charles's comment, partially because there is no client practice yet. > My assumption is that clients or servers supporting EAI MUST be > fully-conformant with 8BITMIME. I assume that makes the answer to > Charles's question not "supposed to" but "MUST". As far as the > transport is concerned, the 2821 headers are just message content so, > if they are extended and transmitted in UTF-8 then 8BITMIME must be > present. We could, in principle, define these extensions as > subsuming 8BITMIME, but it seems to me that would be error-prone and > of no particular advantage. Others may disagree; if so, we need to > discuss. The relevant quotation from RFC 1652 is: > The value associated with the BODY parameter indicates whether the > content body which will be passed using the DATA command consists of > a MIME message containing some arbitrary octet-aligned material > ("8BITMIME") or is encoded entirely in accordance with [1] ("7BIT"). > > A server which supports the 8-bit MIME transport service extension > shall preserve all bits in each octet passed using the DATA command. > RFC 1652 makes no reference to the concept of "header". _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 01 09:24:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fln9c-0003wQ-V1; Thu, 01 Jun 2006 09:24:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fln9b-0003wL-MV for ima@ietf.org; Thu, 01 Jun 2006 09:23:59 -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 1Fln9a-0000Kz-74 for ima@ietf.org; Thu, 01 Jun 2006 09:23:59 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Fln9V-000C9d-Ia; Thu, 01 Jun 2006 09:23:53 -0400 Date: Thu, 01 Jun 2006 09:23:52 -0400 From: John C Klensin To: Harald Alvestrand Subject: Re: 8BITMIME and BODY=8BITMIME (Re: [EAI] Comments on draft-ietf-eai-smtp-00.txt) Message-ID: In-Reply-To: <447EE5AC.3040407@alvestrand.no> References: <29261D0C982C2CF39BD8B8E2@JCK-ACR.jck.com> <447EE5AC.3040407@alvestrand.no> 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: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Charles Lindsey , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 01 June, 2006 06:03 -0700 Harald Alvestrand wrote: > John C Klensin wrote: > >> >> Several comments below. Let's make an agenda item for >> Beijing on terminology to be used. The decisions are more >> or less arbitrary, but we need to be consistent. And I, at >> least, have achieved confusion. >> >> >> --On Thursday, June 01, 2006 11:36 AM +0800 YAO Jiankang >> wrote: >> >>> >>> ----- Original Message ----- >>> From: "Charles Lindsey" >>> To: >>> Sent: Tuesday, May 30, 2006 2:46 AM >>> Subject: [EAI] Comments on draft-ietf-eai-00.txt >>> ... >>> >>>> 6. Servers offering this extension MUST provide support >>>> for, and announce, the 8BITMIME extension [RFC1652]. >>>> >>>> Hmmm! I see that this means you are supposed to include a >>>> BODY=8BITMIME parameter in your MAIL FROM command if the >>>> body uses TCE 8bit (highly probable in an EAI message). Do >>>> agents currently do that in practice? >>> >>> >>> can I suggest that where in the fields there use MIME now , >>> still use MIME in the email message or content. we only >>> update the fields containing the UET-8 email address to UTF8. >> >> >> I don't understand this response, but I'm not sure I >> understand Charles's comment, partially because there is no >> client practice yet. My assumption is that clients or >> servers supporting EAI MUST be fully-conformant with >> 8BITMIME. I assume that makes the answer to Charles's >> question not "supposed to" but "MUST". As far as the >> transport is concerned, the 2821 headers are just message s/2821/2822/ # writing in the wee hours of the morning. sorry >> content so, if they are extended and transmitted in UTF-8 >> then 8BITMIME must be present. We could, in principle, >> define these extensions as subsuming 8BITMIME, but it seems >> to me that would be error-prone and of no particular >> advantage. Others may disagree; if so, we need to discuss. > > > The relevant quotation from RFC 1652 is: > >> The value associated with the BODY parameter indicates >> whether the content body which will be passed using the >> DATA command consists of a MIME message containing some >> arbitrary octet-aligned material ("8BITMIME") or is >> encoded entirely in accordance with [1] ("7BIT"). >> >> A server which supports the 8-bit MIME transport service >> extension shall preserve all bits in each octet passed >> using the DATA command. >> > RFC 1652 makes no reference to the concept of "header". Understood, but that was one reason why Yao's comment confused me. However, if the downgrading procedure of 8BITMIME is invoked, then the structure of the message is changed, insert CTEs on body parts where appropriate. The ability to do that is why the extension is 8BITMIME, rather than 8BITSTUFF -- the extension is not defined for non-MIME messages. And the design of that downgrade procedure doesn't anticipate non-ASCII header material (counting encoded words as ASCII). But, again, I think all of that should be addressed in the downgrade document -- the discussion in the smtp extension document should be straightforward. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 01 11:37:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpEk-0000oB-3e; Thu, 01 Jun 2006 11:37:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpEj-0000jH-IL for ima@ietf.org; Thu, 01 Jun 2006 11:37:25 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlpEh-0007ra-Uf for ima@ietf.org; Thu, 01 Jun 2006 11:37:25 -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 k51FbMR9016720 for ; Fri, 2 Jun 2006 00:37:22 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2006060200372112704 for ; Fri, 02 Jun 2006 00:37:21 +0900 Date: Fri, 02 Jun 2006 00:37:21 +0900 (JST) Message-Id: <20060602.003721.08326263.fujiwara@jprs.co.jp> To: ima@ietf.org From: fujiwara@jprs.co.jp X-Mailer: Mew version 5.0.53 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: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [EAI] terminology issue X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I need clear terminology definitions. (1) Protocol extension name : EAI or IEmail ? it is used as SMTP extention name, MIME message type name, and protocol name. (2) a name which specifies US-ASCII mail address : US-ASCII address? ascii@ascii (3) a name which specifies internationalized mail address: IMA? (3) does not include (2). utf8@utf8 ascii@utf8 utf8@ascii (4) (2)+(3) : US-ASCII address + IMA : mail address? all mail addresses which are supported by EAI. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 01 15:18:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsgD-0000JN-Px; Thu, 01 Jun 2006 15:18:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsgD-0000JH-3W for ima@ietf.org; Thu, 01 Jun 2006 15:18: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 1FlsgB-0006nj-Ow for ima@ietf.org; Thu, 01 Jun 2006 15:18:01 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FlsgA-000Dft-Rz; Thu, 01 Jun 2006 15:17:59 -0400 Date: Thu, 01 Jun 2006 15:17:57 -0400 From: John C Klensin To: fujiwara@jprs.co.jp, ima@ietf.org Subject: Re: [EAI] terminology issue Message-ID: In-Reply-To: <20060602.003721.08326263.fujiwara@jprs.co.jp> References: <20060602.003721.08326263.fujiwara@jprs.co.jp> 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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 02 June, 2006 00:37 +0900 fujiwara@jprs.co.jp wrote: > I need clear terminology definitions. > > (1) Protocol extension name : EAI or IEmail ? EAI has no mnemonic value in any language. IEmail seems to be the name of products from several companies and is sometimes used as an abbreviation for "Internet email" (as compared to various non-Internet things). I still recommend i18nemail (or i16demail for purists) as minimizing confusion and having some significance. > it is used as SMTP extention name, MIME message type name, > and protocol name. > (2) a name which specifies US-ASCII mail address : US-ASCII > address? > > ascii@ascii No good suggestions. "traditional", "legacy", and variations on "2821-address" come to mind. > (3) a name which specifies internationalized mail address: IMA? > (3) does not include (2). > > utf8@utf8 > ascii@utf8 > utf8@ascii > (4) (2)+(3) : US-ASCII address + IMA : mail address? > all mail addresses which are supported by EAI. I think this would make a good Monday discussion, although I'd be pleased if someone had really good ideas. I do not, but the need to settle on something, and do so very soon, has become clear. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 01 20:47:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flxok-0000TB-4Q; Thu, 01 Jun 2006 20:47:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flxoj-0000T6-6y for ima@ietf.org; Thu, 01 Jun 2006 20:47:09 -0400 Received: from [159.226.7.146] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Flxof-00028q-1L for ima@ietf.org; Thu, 01 Jun 2006 20:47:09 -0400 Received: (eyou send program); Fri, 02 Jun 2006 08:46:51 +0800 Message-ID: <349209211.11086@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; Fri, 02 Jun 2006 08:46:51 +0800 Message-ID: <447F8A84.5030800@cnnic.cn> Date: Fri, 02 Jun 2006 08:47:00 +0800 From: Xiaodong Lee Organization: CNNIC User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: John C Klensin Subject: Re: [EAI] Comments on draft-ietf-eai-smtp-00.txt References: <349155586.30353@cnnic.cn> In-Reply-To: <349155586.30353@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: Charles Lindsey , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Good suggestion, Terminology issues should be considered, and I will update the meeting homepage to add this into agenda. -- -- Xiaodong LEE [The best answer is doing] +86-10-58813020 mailto:lee@cnnic.cn http://www.lixiaodong.cn John C Klensin wrote: > > Several comments below. Let's make an agenda item for Beijing on > terminology to be used. The decisions are more or less arbitrary, but > we need to be consistent. And I, at least, have achieved confusion. > > > --On Thursday, June 01, 2006 11:36 AM +0800 YAO Jiankang > wrote: > >> >> ----- Original Message ----- >> From: "Charles Lindsey" >> To: >> Sent: Tuesday, May 30, 2006 2:46 AM >> Subject: [EAI] Comments on draft-ietf-eai-00.txt >> ... >>> 6. Servers offering this extension MUST provide support >>> for, and announce, the 8BITMIME extension [RFC1652]. >>> >>> Hmmm! I see that this means you are supposed to include a >>> BODY=8BITMIME parameter in your MAIL FROM command if the >>> body uses TCE 8bit (highly probable in an EAI message). Do >>> agents currently do that in practice? >> >> can I suggest that where in the fields there use MIME now , >> still use MIME in the email message or content. we only update >> the fields containing the UET-8 email address to UTF8. > > I don't understand this response, but I'm not sure I understand > Charles's comment, partially because there is no client practice yet. > My assumption is that clients or servers supporting EAI MUST be > fully-conformant with 8BITMIME. I assume that makes the answer to > Charles's question not "supposed to" but "MUST". As far as the > transport is concerned, the 2821 headers are just message content so, > if they are extended and transmitted in UTF-8 then 8BITMIME must be > present. We could, in principle, define these extensions as > subsuming 8BITMIME, but it seems to me that would be error-prone and > of no particular advantage. Others may disagree; if so, we need to > discuss. > >>> However, there is another possible 8BITMIME problem. Suppose >>> your message is a multipart, and suppose one of the headers >>> of one of the multiparts contains some UTF-8, e.g. >>> Content-Disposition: ... filename="some utf-8 stuff" >>> (which surely we want to allow, though it is actually an >>> extension to RFC 2045 which needs to be mentioned in the >>> utf8headers document). Now this message encounters a server >>> which supports neither IEmail nor 8BITMIME. RFC 1652 tells >>> you to downgrade to 7bit or else to bounce, so in this case >>> the "some utf-8 stuff" needs to be downgraded accordig to RFC >>> 2231, and this needs to be mentioned somewhere in our >>> drafts. Maybe the downgrade document is the place to do it, >>> but I mention it here to make sure it does not get >>> forgotten. > > The downgrade document is the place to do it. This runs into the "no > multiple encapsulations" rule and requires very careful > consideration. My guess is that the UTF-8 headers doc needs to note > that it updates 2045 and that the downgrade one needs to note that it > updates 1652... but the differences in how headers are handled might > make a case for defining these extensions on their own, rather than by > reference to 8BITMIME, despite what I've said above. > >> ... >>> An SMTP Client that receives the IMA extension keyword >>> MAY transmit a mailbox name as an internationalized >>> string in UTF-8 form and MAY >>> >>> s/receives the IMA extension keyword MAY/receives the IMA >>> extension keyword in response to EHLO MAY/ >> >> ok, will update it. > > Harmless, but I think unnecessary. The thing that is necessary is a > requirement that the keyword MUST NOT be sent unless the extension is > advertised, and we have that. > >> ... >> .... If the IMA SMTP extension is not offered by >>> the Server, the SMTP Client MUST NOT transmit an >>> internationalized address and MUST NOT transmit a mail >>> body which contains internationalized mail headers >>> [IMA-utf8header]. Instead, it MUST either return the >>> message to the user as undeliverable or replace it with >>> the alternate ASCII address. ..... >>> >>> Are you trying to cover addresses in both SMTP commands and >>> in email headers here? If so, then the words "a mail body" >>> are wrong (the body of a message does not include its >>> headers, apart from in multiparts as I mentioned earlier). >>> So I think you need >>> >>> s/a mail body/a message/ >> >> >> yes, will use "a message". > > Still not quite right, because either "message" or "mail body" also > contains content. E.g., we have > > Envelope > Headers > > Body > > the restriction above applies properly to the first two, but it would > be a bad idea to accidentally try to specify how addresses are > represented in the message body itself. For example, while the > address would not be usable, nothing prohibits > .... > Header-stuff... > Content-type: text/plain; charset=UTF-8 > > Hi there, my preferred email address is > utf-8-stuff@utf-8-stuff.example.com > . > > today, with unextended SMTP (although a CTE would presumably be required) > >>> but in either case, "it" is too vague, so >>> >>> s/it/all addresses (both in the envelope and in the message's >>> header fields)/ >> >> will consider it carefully. > >>> ... If it is replaced, the replacement >>> MUST be either the ASCII-only address specified with the >>> ALT-ADDRESS parameter or with an address obtained from >>> some algorithmic conversions of the primary address that >>> conforms to the syntax rules of RFC 2821, which is >>> defined in [IMA-downgrading]. >>> >>> That wording is fine if the client is an earlier >>> IEmail-compliant server, but if the the client is the >>> originating MUA it doesn't have an ALT-ADDRESS to hand. It >>> has to invent one by whatever means (maybe it found one in >>> the To: header, maybe it had a table of mappings). >> >> yes. > > The more of this sort of thing we can shift into the downgrading > document, the better off we will be. It has to cover the material, > covering it here as well is just an invitation to inconsistency. See > if it is possible to define the syntax and semantics of the parameters > but indicate that the information is not needed unless downgrading is > necessary; if downgrading is necessary, the downgrade document > specifies how they are used. Does that make sense? > >>> There is a further complication. Suppose a message arrives at >>> some intermediate server with one ALT-ADDRESS in its RCPT >>> TO: command, and a different one in its To: header. I think >>> the only sensible thing to do is to use the one in the RCPT >>> TO: command in the ongoing (downgraded) RCPT TO:, and the >>> one from the To: header in the ongoing (downgraded) To: >>> header. Note that this anomaly is perfectly possible if, for >>> example, this is a message being propagated by some mailing >>> list expander. >> >> can we do some specification (address synchronize) in the >> utf-8-headers document to avoid such anomaly in the "RCPT To" >> and "To: header"? for example, if ALT-ADDRESS is used in "RCPT >> To", "To: header" will also use ALT-ADDRESS. > > Probably not, since the addresses in the RCPT commands need not appear > at all in the headers. The usual general guideline probably applies > here -- to the extent possible, MTAs pay attention to the envelope > only. That makes any ALT-ADDRESS in the headers mostly useful for > forming replies at the receiving MUA. > >> ... >>> However, you cannot specify Stringprep without stating what >>> 'profile' of Stringprep you require. Maybe you can find an >>> existing one that suits your need (but not Nameprep, >>> because that removes and upper/lowercase distinctions). You >>> could easily define your own profile by indicating which of >>> the various tables from RFC 3454 were to be applied. I agree >>> that local-parts should have _some_ suitable Stringprep >>> applied to them. They are essentially 'identifiers' in >>> nature, and should at least adhere to WYSIWYG (but note in >>> passing that RFC 2822 local-parts already fail Stringprep >>> by permitting control characters). > > WYSIWYG is more or less equivalent to the fax constraint Charles > suggested earlier. Because it is in the eye of the beholder, it is > basically impossible with Unicode. >> >> Yes, we should have our own Stringprep for the email local >> part. > > We need to be careful here. First, stringprep, as usually used, > specifies treatment of strings, potentially unnormalized ones, so they > can be compared. I think we are going to get into bad shape if we > permit unnormalized/ uncanonicalized strings at all. See the > discussion in draft-klensin-net-utf8, but note that the conventions > recommended there are probably not appropriate for these addresses. > My guess is that we should stick fairly closely to NFKC, but others > probably want to comment on that. And, of course, doing anything with > NFKC or NFC gets us into the Unicode versioning mess. > > I thought we had agreed to prohibit control characters in non-ASCII > local parts -- in the past, they have been more trouble than they are > worth. If we haven't, we need to discuss it quickly. If we have, > then this document must be explicit about it. >>> As an aside, I just noticed that John KLensin's utf8 draft >>> cannot be expressed as a profile of Stringprep (which is >>> actually as it should be, because it is not trying to >>> restrict itself to 'identifier's). > > That is correct and was intentional. >> ... >>> ... If the >>> ALT-ADDRESS value is not set by the sender but the value >>> of ATOMIC is 'y', the sender SMTP server should apply >>> some algorithmic transformation such as punycode to the >>> entire local part of IMA; ... >>> >>> No, from the POV of the server that might be going to >>> downgrade the address, the "sender" is actually an SMTP >>> "client" (which might be another server, or might be an >>> MUA). >> >> so we change the word "sender" to "email user", is it ok? > > Please don't try to invent more terminology unless absolutely > necessary. I would read "email user" as the human being who interacts > with the message-creating MUA, and that is certainly not what is > intended in all of the uses in that paragraph. 2821 uses "SMTP > client" and "SMTP server" where feasible and reverts to the 821 > terminology of "SMTP sender" and "SMTP receiver" when needed for > clarity. "sender SMTP server" is pretty close to a contradiction. > See above about getting as much of this into the downgrade document as > possible. > >> ... > > john > > > _______________________________________________ > 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 Jun 02 04:29:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm52H-0008IX-Tw; Fri, 02 Jun 2006 04:29:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm52G-0008II-Me for ima@ietf.org; Fri, 02 Jun 2006 04:29:36 -0400 Received: from [159.226.7.146] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fm52D-0007DS-JU for ima@ietf.org; Fri, 02 Jun 2006 04:29:36 -0400 Received: (eyou send program); Fri, 02 Jun 2006 16:29:18 +0800 Message-ID: <349236958.31801@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; Fri, 02 Jun 2006 16:29:18 +0800 Message-ID: <447FF6E6.8030307@cnnic.cn> Date: Fri, 02 Jun 2006 16:29:26 +0800 From: Xiaodong Lee Organization: CNNIC User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [EAI] update the meeting homepage X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lee@cnnic.cn List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hi, I have updated the meeting homepage: 1)Add terminologies issue discussion in meeting agenda 2)Add SIP-based conference call support for meeting facilities 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 Fri Jun 02 07:18:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm7fT-0000V6-BZ; Fri, 02 Jun 2006 07:18:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm7fR-0000V1-Hf for ima@ietf.org; Fri, 02 Jun 2006 07:18:13 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm7fO-0001EY-8m for ima@ietf.org; Fri, 02 Jun 2006 07:18:13 -0400 Received: from host81-144-65-239.midband.mdip.bt.net ([81.144.65.239] country=GB) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.218) id 44801e6f.115fb.9c9 for ima@ietf.org; Fri, 2 Jun 2006 12:18:07 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k52A8Fd20415 for ; Fri, 2 Jun 2006 11:08:16 +0100 (BST) Date: Fri, 02 Jun 2006 11:08:10 +0100 To: "ima@ietf.org" Subject: Re: [EAI] Comments on draft-ietf-eai-smtp-00.txt References: <29261D0C982C2CF39BD8B8E2@JCK-ACR.jck.com> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <29261D0C982C2CF39BD8B8E2@JCK-ACR.jck.com> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 01 Jun 2006 10:52:41 +0100, John C Klensin wrote: > --On Thursday, June 01, 2006 11:36 AM +0800 YAO Jiankang > wrote: > >> >> ----- Original Message ----- >> From: "Charles Lindsey" >> To: >> Sent: Tuesday, May 30, 2006 2:46 AM >> Subject: [EAI] Comments on draft-ietf-eai-00.txt >> ... >>> 6. Servers offering this extension MUST provide support >>> for, and announce, the 8BITMIME extension [RFC1652]. >>> >>> Hmmm! I see that this means you are supposed to include a >>> BODY=8BITMIME parameter in your MAIL FROM command if the >>> body uses TCE 8bit (highly probable in an EAI message). Do >>> agents currently do that in practice? > I don't understand this response, but I'm not sure I understand > Charles's comment, partially because there is no client practice yet. > My assumption is that clients or servers supporting EAI MUST be > fully-conformant with 8BITMIME. I assume that makes the answer to > Charles's question not "supposed to" but "MUST". Sure, I had just been reading RFC 1652 and came across that BODY parameter. I was asking whether implementations actually used it in the real world (sure they "MUST", but since when did that stop implementors from taking shortcuts :-( ). Essentially, you check whether the next server does IEmail. If not, then you either bounce or downgrade using whatever ALT-ADDRESS and/or ATOMIC information is available. After that, you check whether it does 8BITMIME and again either bounce or change the CTE according to whatever BODY= information is available. Essentially, that BODY= parameter fulfils the same role as our proposed "this is an IEmail" header - it saves you the bother of checking through the whole thing looking for a bit-8. So it is a MUST as you say. But if might be useful to point out that after you have downgraded in accordance with our smtp draft, you may still need to do a further downgrade as per RFC 1652. >>> However, there is another possible 8BITMIME problem...... > > The downgrade document is the place to do it. Yes, the downgrade document is the place for most of the "messy" stuff. I just wanted to make sure that Content-* headers introduced into the body by multiparts and message/rfc822 did not get overlooked when downgrading, since they too might contain utf-8 and changing the CTE as per RFC 1652 will not fix that. >> ... >> .... If the IMA SMTP extension is not offered by >>> the Server, the SMTP Client MUST NOT transmit an >>> internationalized address and MUST NOT transmit a mail >>> body which contains internationalized mail headers >>> [IMA-utf8header]. Instead, it MUST either return the >>> message to the user as undeliverable or replace it with >>> the alternate ASCII address. ..... >>> >>> s/a mail body/a message/ >> >> >> yes, will use "a message". > > Still not quite right, because either "message" or "mail body" also > contains content. E.g., we have Yes, my main concern was that the mention of "mail body" was misleading. >> can we do some specification (address synchronize) in the >> utf-8-headers document to avoid such anomaly in the "RCPT To" >> and "To: header"? for example, if ALT-ADDRESS is used in "RCPT >> To", "To: header" will also use ALT-ADDRESS. > > Probably not, since the addresses in the RCPT commands need not appear > at all in the headers. The usual general guideline probably applies > here -- to the extent possible, MTAs pay attention to the envelope > only. That makes any ALT-ADDRESS in the headers mostly useful for > forming replies at the receiving MUA. I think we have to assume that the To/From addresses in the headers might differ from those in the envelope, even in situations where we might have expected them to be the same. So you downgrade them independently of each other, using whatever ALT-ADDRESS or ATOMIC each provides + >> Yes, we should have our own Stringprep for the email local >> part. > > We need to be careful here. First, stringprep, as usually used, > specifies treatment of strings, potentially unnormalized ones, so they > can be compared. I think we are going to get into bad shape if we > permit unnormalized/ uncanonicalized strings at all. See the discussion > in draft-klensin-net-utf8, but note that the conventions recommended > there are probably not appropriate for these addresses. My guess is > that we should stick fairly closely to NFKC, but others probably want to > comment on that. And, of course, doing anything with NFKC or NFC gets us > into the Unicode versioning mess. Yes, but when a local-part arrives at its final destination, comparison with some locally stored list of things is the likeliest thing to happen to it. If it is not just a simple comparison, then it may well be examined by some regular expression (or other parsing device). But either way, the task will be much simplified if it can be assumed to be NFKC-compliant, and the way to ensure that is to insist that it conformed to a suitable profile of Stringprep at the place where it was generated. > > I thought we had agreed to prohibit control characters in non-ASCII > local parts -- in the past, they have been more trouble than they are > worth. I am all for prohibiting them. The trouble is that we cannot prohibit them in ASCII local-parts, where they are already allowed. One of the things we had to do in USEFOR was to forbid them in message-ids in Netnews, even though RFC 2822 allows them in Email. >>> As an aside, I just noticed that John KLensin's utf8 draft >>> cannot be expressed as a profile of Stringprep (which is >>> actually as it should be, because it is not trying to >>> restrict itself to 'identifier's). > > That is correct and was intentional. Yes, I understand that. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Jun 02 08:56:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm9CA-00041x-5T; Fri, 02 Jun 2006 08:56:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm9C9-0003zX-EN for ima@ietf.org; Fri, 02 Jun 2006 08:56:05 -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 1Fm9C5-0002dc-49 for ima@ietf.org; Fri, 02 Jun 2006 08:56:05 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Fm9C3-000HlI-NJ; Fri, 02 Jun 2006 08:55:59 -0400 Date: Fri, 02 Jun 2006 08:55:58 -0400 From: John C Klensin To: lee@cnnic.cn, ima@ietf.org Subject: Re: [EAI] update the meeting homepage Message-ID: In-Reply-To: <349236958.31801@cnnic.cn>, <447FF6E6.8030307@cnnic.cn> References: <349236958.31801@cnnic.cn>, <447FF6E6.8030307@cnnic.cn> 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: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 02 June, 2006 16:29 +0800 Xiaodong Lee wrote: > Hi, > > I have updated the meeting homepage: > 1)Add terminologies issue discussion in meeting agenda > 2)Add SIP-based conference call support for meeting facilities Thank you. Two things... (1) I assume that the provision for sending IP addresses is for video conference connections and that there are no blocks to outbound IPSec or SSH tunnels from the meeting site. Correct? (2) The list of documents is not up-to-date. For documents issued since IETF Dallas, pointers to more current versions from the main WG web page (http://www.ietf.org/html.charters/eai-charter.html) For those who might not have picked up the earlier message, the meeting site to which Xiaodong refers is at http://www.asrc.cn/eai.htm See you soon. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jun 04 05:24:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmoqM-0004TK-LI; Sun, 04 Jun 2006 05:24:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmoqL-0004M6-8k for ima@ietf.org; Sun, 04 Jun 2006 05:24:21 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmoqC-00043Z-JM for ima@ietf.org; Sun, 04 Jun 2006 05:24:21 -0400 Received: (snipe 25434 invoked by uid 0); 4 Jun 2006 17:24:04 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.91.12 (Processed in 0.401792 secs); Received: from unknown (HELO ?1.0.0.31?) (Z?9?own@125.98.76.2) by unknown with SMTP; 4 Jun 2006 17:24:04 +0900 X-RCPTTO: ima@ietf.org Message-ID: <44829891.7080609@icu.ac.kr> Date: Sun, 04 Jun 2006 17:23:45 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) 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: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [EAI] A few comments on SMTPEXT-00 I-D X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Dear Jiankang and others, (1) ALT-ADDRESS and ATOMIC should have no relationship. smtpext-00 says: > The value of "ALT-ADDRESS" may be set by sender or be > gotten by using some algorithmic transformation according > to the value of "ATOMIC". The above quote tries to tightly connect ALT-ADDRESS with ATOMIC. But, it is just too complicated. My understanding can be written as: > Alternative address for downgrading can be obtained from > the value of "ALT-ADDRESS" set by sender or can be gotten > by using some algorithmic transformation if the value of > "ATOMIC" is "y". (2) ATOMIC should be clarified a lot more. The rationale behind the idea of automatic conversion is given in section 2.4. However, the following quote potentially widens applicability of ATOMIC. It reads; > the primary address(IMA) can be safely transformed or > converted to the respect ASCII email address via ACE If we stick to this explanation, we can set ATOMIC to "y" even if it is NOT atomic. If there is any way to handle ACE encoded email addresses regardless of their atomicity, we can safely encode them. We have two choices. First, we just stick to the concept atomic. So, even though the final delivery can handle ACE encoded addresses with embedded commands, non atomic addresses should NOT declared as ATOMIC. Second, we extend the coverage that is supported by ATOMIC option. If encoded addresses can be handled by the final delivery correctly, they should be declared as ATOMIC. (In this case, ATOMIC needs to be replaed with better term such as SAFE-TO-DOWNGRADE.) (3) Editorial suggestion (3-1) The last sentence of section 2.2; > If it is replaced, the replacement > MUST be either the ASCII-only address specified with the ALT-ADDRESS > parameter or with an address obtained from some algorithmic > conversions of the primary address that conforms to the syntax rules > of RFC 2821, which is defined in [IMA-downgrading]. "which" in the last line is very confusing. I want that part as a separate sentence. (3-2) Section 2.4 You include too much stuffs that should be covered by downgrade document. I want to leave only rationale part and a very brief usage. Regards _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jun 04 18:11:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn0oM-0000Ax-4z; Sun, 04 Jun 2006 18:11:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn0oK-0000Ar-Pj for ima@ietf.org; Sun, 04 Jun 2006 18:11:04 -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 1Fn0oJ-0007zP-AP for ima@ietf.org; Sun, 04 Jun 2006 18:11:04 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Fn0oI-0005XP-B9; Sun, 04 Jun 2006 18:11:02 -0400 Date: Sun, 04 Jun 2006 18:10:58 -0400 From: John C Klensin To: Yangwoo Ko , ima@ietf.org Subject: Re: [EAI] A few comments on SMTPEXT-00 I-D Message-ID: In-Reply-To: <44829891.7080609@icu.ac.kr> References: <44829891.7080609@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: 5011df3e2a27abcc044eaa15befcaa87 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hi. For whatever it is worth... (i) I agree with Yangwoo's analysis on (1) and (2). (ii) I continue to believe that we need to get these issues worked out and properly and clearly reflected in the downgrade document, then remove all of the specifics from SMTPEXT. In essence, SMTPEXT should contain a minimal explanation about what these parameters are about, identify their syntax, indicate that, if a legacy server is encountered, one must downgrade or bounce, and then defer the explanation of how to downgrade --including what these parameters are about-- to the downgrade document. So I am in strong agreement with YangWoo's last point as well. john --On Sunday, June 04, 2006 17:23 +0900 Yangwoo Ko wrote: > > Dear Jiankang and others, > > (1) ALT-ADDRESS and ATOMIC should have no relationship. > > smtpext-00 says: > > The value of "ALT-ADDRESS" may be set by sender or be > > gotten by using some algorithmic transformation according > > to the value of "ATOMIC". > > The above quote tries to tightly connect ALT-ADDRESS with > ATOMIC. But, it is just too complicated. My understanding > can be written as: > > > Alternative address for downgrading can be obtained from > > the value of "ALT-ADDRESS" set by sender or can be gotten > > by using some algorithmic transformation if the value of > > "ATOMIC" is "y". > > (2) ATOMIC should be clarified a lot more. > > The rationale behind the idea of automatic conversion is > given in section 2.4. However, the following quote > potentially widens applicability of ATOMIC. It reads; > > > the primary address(IMA) can be safely transformed or > > converted to the respect ASCII email address via ACE > > If we stick to this explanation, we can set ATOMIC to "y" > even if it is NOT atomic. If there is any way to handle > ACE encoded email addresses regardless of their atomicity, > we can safely encode them. > > We have two choices. First, we just stick to the concept > atomic. So, even though the final delivery can handle ACE > encoded addresses with embedded commands, non atomic addresses > should NOT declared as ATOMIC. > > Second, we extend the coverage that is supported by ATOMIC > option. If encoded addresses can be handled by the final > delivery correctly, they should be declared as ATOMIC. > (In this case, ATOMIC needs to be replaed with better term > such as SAFE-TO-DOWNGRADE.) > > (3) Editorial suggestion > > (3-1) The last sentence of section 2.2; > > > If it is replaced, the replacement > > MUST be either the ASCII-only address specified with the > ALT-ADDRESS > > parameter or with an address obtained from some algorithmic > > conversions of the primary address that conforms to the > syntax rules > > of RFC 2821, which is defined in [IMA-downgrading]. > > "which" in the last line is very confusing. I want that part > as a > separate sentence. > > (3-2) Section 2.4 > > You include too much stuffs that should be covered by downgrade > document. I want to leave only rationale part and a very brief > usage. > > 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 Sun Jun 04 18:33:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn19i-0007lP-LN; Sun, 04 Jun 2006 18:33:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn19h-0007ii-2c for ima@ietf.org; Sun, 04 Jun 2006 18:33:09 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn19f-0000ok-PT for ima@ietf.org; Sun, 04 Jun 2006 18:33:09 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 399B92596F0; Mon, 5 Jun 2006 00:32:11 +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 23534-07; Mon, 5 Jun 2006 00:32:08 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1DDF52596EC; Mon, 5 Jun 2006 00:32:08 +0200 (CEST) Message-ID: <44835F9F.60509@alvestrand.no> Date: Sun, 04 Jun 2006 15:33:03 -0700 From: Harald Alvestrand User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060503) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin Subject: Re: [EAI] A few comments on SMTPEXT-00 I-D References: <44829891.7080609@icu.ac.kr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > Hi. > > For whatever it is worth... > > (i) I agree with Yangwoo's analysis on (1) and (2). > > (ii) I continue to believe that we need to get these issues worked out > and properly and clearly reflected in the downgrade document, then > remove all of the specifics from SMTPEXT. In essence, SMTPEXT should > contain a minimal explanation about what these parameters are about, > identify their syntax, indicate that, if a legacy server is > encountered, one must downgrade or bounce, and then defer the > explanation of how to downgrade --including what these parameters are > about-- to the downgrade document. So I am in strong agreement with > YangWoo's last point as well. I also agree with Yangwoo's and Klensin's analysis. I hope the interim meeting (which starts in 1.5 hours) can help clarify the dividing line between these two documents. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jun 04 20:47:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn3FP-00015K-Fe; Sun, 04 Jun 2006 20:47:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn3FN-00015F-PQ for ima@ietf.org; Sun, 04 Jun 2006 20:47:09 -0400 Received: from [159.226.7.146] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fn3FL-0007SJ-4C for ima@ietf.org; Sun, 04 Jun 2006 20:47:09 -0400 Received: (eyou send program); Mon, 05 Jun 2006 08:47:01 +0800 Message-ID: <349468421.31949@cnnic.cn> X-EYOUMAIL-SMTPAUTH: lee@cnnic.cn Received: from unknown (HELO [159.226.45.69]) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 05 Jun 2006 08:47:01 +0800 Message-ID: <44837F07.3080900@cnnic.cn> Date: Mon, 05 Jun 2006 08:47:03 +0800 From: Xiaodong Lee Organization: CNNIC User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [EAI] jabber server of the EAI interim meeting is changed X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lee@cnnic.cn List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hi, all, The jabber server has been changed from jabber.asrc.cn to jabber.ietf.org room name is eai. 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 Sun Jun 04 21:29:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn3u3-0005H4-BW; Sun, 04 Jun 2006 21:29:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn3u2-0005Gz-M8 for ima@ietf.org; Sun, 04 Jun 2006 21:29:10 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fn3tx-0002oP-1N for ima@ietf.org; Sun, 04 Jun 2006 21:29:10 -0400 Received: (snipe 441 invoked by uid 0); 5 Jun 2006 10:28:53 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.91.12 (Processed in 0.407933 secs); Received: from unknown (HELO ?159.226.45.77?) (Z???own@159.226.45.77) by unknown with SMTP; 5 Jun 2006 10:28:53 +0900 X-RCPTTO: ima@ietf.org Message-ID: <448388C2.50106@icu.ac.kr> Date: Mon, 05 Jun 2006 10:28:34 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) 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: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [EAI] A few comments on downgrade-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Dear Yoneya, Fujiwara, and others, (1) Section 4. > If downgrading is expected, mail sender MUA MUST append ALT-ADDR or > ATOMIC option ... According to my understanding, under no circumstance, provision of ALT-ADDR/ATOMIC can be a MUST. We may put it such as; Downgrade is made only when mail sender MUA appends .... (2) Again section 4. > Note that when downgrading, not to disclose whole recipient address, > MUA/MTA SHOULD make SMTP connection ... Well, making separate connections is not sufficient to avoid disclosure. You'd better mention that IMA-Downgraded-From/To headers should be at minimum. Regards _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jun 04 21:37:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn42G-0002uc-MU; Sun, 04 Jun 2006 21:37:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn42G-0002uQ-2E for ima@ietf.org; Sun, 04 Jun 2006 21:37:40 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn42E-0004Wc-ER for ima@ietf.org; Sun, 04 Jun 2006 21:37:40 -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 k551baR9007405 for ; Mon, 5 Jun 2006 10:37:36 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2006060510373521666 for ; Mon, 05 Jun 2006 10:37:35 +0900 Date: Mon, 05 Jun 2006 10:37:36 +0900 (JST) Message-Id: <20060605.103736.68044471.fujiwara@jprs.co.jp> To: ima@ietf.org From: fujiwara@jprs.co.jp X-Mailer: Mew version 5.0.53 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [EAI] received header and downgrade memo X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I prepared received header issue and downgrading issue materials. received header: http://member.wide.ad.jp/~fujiwara/received-200606.gby http://member.wide.ad.jp/~fujiwara/received-200606.txt downgrade: http://member.wide.ad.jp/~fujiwara/downgrade-20060605.gby http://member.wide.ad.jp/~fujiwara/downgrade-20060605.pdf -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jun 04 21:42:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn46Y-0003LO-MQ; Sun, 04 Jun 2006 21:42:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn46X-0003LE-RM for ima@ietf.org; Sun, 04 Jun 2006 21:42:05 -0400 Received: from substance.cnnic.cn ([159.226.7.145] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fn46V-00058e-Pf for ima@ietf.org; Sun, 04 Jun 2006 21:42:05 -0400 Received: (eyou send program); Mon, 05 Jun 2006 09:41:55 +0800 Message-ID: <349471715.32353@cnnic.cn> Received: from 127.0.0.1 by mail.cnnic.cn with HTTP; Mon, 05 Jun 2006 09:41:55 +0800 X-WebMAIL-MUA: [127.0.0.1] From: "Yao Jiankang" To: newcat@icu.ac.kr, ima@ietf.org Date: Mon, 05 Jun 2006 09:41:55 +0800 X-Priority: 3 Subject: Re:[EAI] A few comments on downgrade-00 Content-Type: text/plain X-Spam-Score: 1.2 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Yao Jiankang List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org >From: Yangwoo Ko >Reply-To: >To: ima@ietf.org >Subject: [EAI] A few comments on downgrade-00 >Date:Mon, 05 Jun 2006 10:28:34 +0900 > > > Dear Yoneya, Fujiwara, and others, > > (1) Section 4. > > > If downgrading is expected, mail sender MUA MUST append ALT-ADDR or > > ATOMIC option ... > > According to my understanding, under no circumstance, provision > of ALT-ADDR/ATOMIC can be a MUST. We may put it such as; > > Downgrade is made only when mail sender MUA appends .... > Yes, provision of ALT-ADDR/ATOMIC is not a MUST. if these two parameters are not provided, the smtp server should bounce the email message to the original sender if some involved smtp servers can not support IMA. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jun 04 22:45:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn568-0004qx-Im; Sun, 04 Jun 2006 22:45:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn566-0004qk-5s for ima@ietf.org; Sun, 04 Jun 2006 22:45:42 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn564-0002o9-Ss for ima@ietf.org; Sun, 04 Jun 2006 22:45:42 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 979DD2596EB for ; Mon, 5 Jun 2006 04:44:44 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02331-01 for ; Mon, 5 Jun 2006 04:44:41 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 706D82596E3 for ; Mon, 5 Jun 2006 04:44:41 +0200 (CEST) Message-ID: <44839AD1.2080009@alvestrand.no> Date: Sun, 04 Jun 2006 19:45:37 -0700 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [EAI] Suggested additions to -headers- section 6.2 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org The heading of section 6.2 of draft-ietf-eai-utf8headers reads: 6.2. Syntax extend from RFC 2822 The following rules are intended to supersede the corresponding rules in RFC 2822. I suggest that we expand it by adding: This means that all the RFC 2822 constructs that build upon these will permit UTF-8 characters, including comments and quoted strings. <> Note, however, that this does not remove any constraint on the character set of protocol elements; for instance, all the allowed values for timezone in the Date: headers are still expressed in ASCII. The <> is just to catch the attention of people who can think of situations where we need to disallow this feature. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 05 03:26:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn9UA-0007WT-PK; Mon, 05 Jun 2006 03:26:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn9UA-0007UX-0r for ima@ietf.org; Mon, 05 Jun 2006 03:26:50 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn9U8-0006Ri-OU for ima@ietf.org; Mon, 05 Jun 2006 03:26:50 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 294602596F7 for ; Mon, 5 Jun 2006 09:25:52 +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 08447-03 for ; Mon, 5 Jun 2006 09:25:48 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C3BEE2596E4 for ; Mon, 5 Jun 2006 09:25:48 +0200 (CEST) Message-ID: <4483DCB4.4050602@alvestrand.no> Date: Mon, 05 Jun 2006 00:26:44 -0700 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: "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: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [EAI] Note on IMAP draft and "upgrading" X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org The EAI draft on IMAP contains some text that speaks to "upgrading" - converting a message that came into the mailstore in "old-style" RFC 2822 form to something more resembling an EAI-type message. Those who care about upgrading should read that section carefully to check that it says what you think it should say. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 05 03:42:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn9jD-000231-40; Mon, 05 Jun 2006 03:42:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn9jC-00022w-NN for ima@ietf.org; Mon, 05 Jun 2006 03:42:22 -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 1Fn9jB-0000sj-Dj for ima@ietf.org; Mon, 05 Jun 2006 03:42:22 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Fn9jA-0007SG-Oa for ima@ietf.org; Mon, 05 Jun 2006 03:42:21 -0400 Date: Mon, 05 Jun 2006 03:42:17 -0400 From: John C Klensin To: ima@ietf.org Message-ID: 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: 8abaac9e10c826e8252866cbe6766464 Subject: [EAI] New text for SMTPEXT, section 2.5.2 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Section 2.5.2 of eai-smtpext-00 now reads > 2.5.2. Trace Fields > > Internationalized domain names in Received fields must be > transmitted in the punycode form. Addresses in "for" > clauses need further examination and might be treated > differently depending on [IMA- utf8header]. The reasoning > in the introductory portion of [IMA- overview] strongly > suggests that these addresses be in UTF-8 form, rather than > some specialized encoding. As a consequence of discussion at the interim meeting about difficulties associated with having to modify earlier Received fields on downgrade, it should read something like... 2.5.2. Trace Fields Internationalized domain names in Received fields must be transmitted in the punycode form. "For" fields containing internationalized addresses are prohibited, since subsequent downgrading would force violating rules in RFC 2821 prohibiting altering existing Received fields. With these two restrictions, there should be no need for UTF-8 information in Received fields and such information is prohibited to preserve the integrity of those fields. More generally, UTF-8 information of any sort MUST NOT appear in Received fields, even in comments within those fields. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 05 05:55:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnBo5-0008Iz-QY; Mon, 05 Jun 2006 05:55:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnBo4-0008IV-O5 for ima@ietf.org; Mon, 05 Jun 2006 05:55:32 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnBfu-0006c2-GX for ima@ietf.org; Mon, 05 Jun 2006 05:47:08 -0400 Received: from host81-144-66-207.midband.mdip.bt.net ([81.144.66.207] country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.218) id 4483fd98.178b1.87c for ima@ietf.org; Mon, 5 Jun 2006 10:47:04 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (gmrs-tacacs [192.168.0.2]) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k559LXq08853 for ; Mon, 5 Jun 2006 10:21:33 +0100 (BST) 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 k559L0Vk005209 for ; Mon, 5 Jun 2006 10:21:01 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] A few comments on SMTPEXT-00 I-D References: <44829891.7080609@icu.ac.kr> Message-ID: Date: Mon, 05 Jun 2006 10:20:59 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <44829891.7080609@icu.ac.kr> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sun, 04 Jun 2006 09:23:45 +0100, Yangwoo Ko wrote: > Second, we extend the coverage that is supported by ATOMIC > option. If encoded addresses can be handled by the final > delivery correctly, they should be declared as ATOMIC. > (In this case, ATOMIC needs to be replaed with better term > such as SAFE-TO-DOWNGRADE.) I think the word you are looking for is "DOWNGRADABLE". > > (3) Editorial suggestion > > (3-1) The last sentence of section 2.2; > > > If it is replaced, the replacement > > MUST be either the ASCII-only address specified with the ALT-ADDRESS > > parameter or with an address obtained from some algorithmic > > conversions of the primary address that conforms to the syntax rules > > of RFC 2821, which is defined in [IMA-downgrading]. > > "which" in the last line is very confusing. I want that part as a > separate sentence. How about: If it is replaced, the replacement MUST be either the ASCII-only address specified with the ALT-ADDRESS parameter or with an address obtained from some algorithmic conversions, (as defined in [IMA-downgrading]) of the primary address (that conforms to the syntax rules of RFC 2821). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Jun 05 12:13:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHi3-0001PC-UC; Mon, 05 Jun 2006 12:13:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHi2-0001P4-D4 for ima@ietf.org; Mon, 05 Jun 2006 12:13:42 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnHhz-0007wJ-E7 for ima@ietf.org; Mon, 05 Jun 2006 12:13:42 -0400 Received: from host81-144-67-112.midband.mdip.bt.net ([81.144.67.112] country=GB) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.218) id 44845831.2bbf.71 for ima@ietf.org; Mon, 5 Jun 2006 17:13:37 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (gmrs-tacacs [192.168.0.2]) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k55Bunq14753 for ; Mon, 5 Jun 2006 12:56:49 +0100 (BST) 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 k55BuIl5015331 for ; Mon, 5 Jun 2006 12:56:18 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] New text for SMTPEXT, section 2.5.2 References: Message-ID: Date: Mon, 05 Jun 2006 12:56:17 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 05 Jun 2006 08:42:17 +0100, John C Klensin wrote: > 2.5.2. Trace Fields > > Internationalized domain names in Received fields must be > transmitted in the punycode form. "For" fields containing > internationalized addresses are prohibited, since subsequent > downgrading would force violating rules in RFC 2821 > prohibiting altering existing Received fields. With these > two restrictions, there should be no need for UTF-8 > information in Received fields and such information is > prohibited to preserve the integrity of those fields. > More generally, UTF-8 information of any sort MUST NOT > appear in Received fields, even in comments within those > fields. I think you shold adopt Chris Newmsn's suggestion that any For field containing an internationalized addresse should be written inside a comment (For fields are too useful to abandon them entriely). And I see no harm in UTF-8 inside comments (since the downgrade mechanism is clear, and Chris Newman's suggestion requires it). It might be a kinder to use RFC 2047 inside such comments, but I would not make that stronger than a "SHOULD". -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Jun 05 16:39:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLrF-0004mf-IV; Mon, 05 Jun 2006 16:39:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLrC-0004kB-Jd; Mon, 05 Jun 2006 16:39:26 -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 1FnLZV-0002v1-T5; Mon, 05 Jun 2006 16:21:09 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FnLLC-0005XP-QV; Mon, 05 Jun 2006 16:06:24 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k55Jo1mU027132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FnL5N-0002RH-Rl; Mon, 05 Jun 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: Date: Mon, 05 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-utf8headers-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Internationalized Email Headers Author(s) : J. Yeh Filename : draft-ietf-eai-utf8headers-00.txt Pages : 14 Date : 2006-6-5 Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail header fields. This document specifies the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field bodies. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-utf8headers-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-utf8headers-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-utf8headers-00.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-6-5143350.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-utf8headers-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-utf8headers-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-5143350.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 Mon Jun 05 19:19:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnOLg-0000IP-QL; Mon, 05 Jun 2006 19:19:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnOLf-0000IK-6H for ima@ietf.org; Mon, 05 Jun 2006 19:19:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnOLd-00084V-MS for ima@ietf.org; Mon, 05 Jun 2006 19:19:03 -0400 Received: from [10.20.30.249] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k55NIwX1027925 for ; Mon, 5 Jun 2006 16:19:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 5 Jun 2006 16:18:56 -0700 To: ima@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k55NIwX1027925 X-Spam-Score: 1.8 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [EAI] An example IDN for use X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I have registered xn--xample-9ua.com (=E9xample.com). If it is at all=20 useful for any of the EAI documents, such as an example of ml@ml.com,=20 you are free to use it. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 05 20:08:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnP7I-0000Qo-BA; Mon, 05 Jun 2006 20:08:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnP7F-0000QQ-EI for ima@ietf.org; Mon, 05 Jun 2006 20:08:14 -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 1FnP7D-0005kq-19 for ima@ietf.org; Mon, 05 Jun 2006 20:08:13 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FnP7B-000BSi-K0; Mon, 05 Jun 2006 20:08:10 -0400 Date: Mon, 05 Jun 2006 20:08:05 -0400 From: John C Klensin To: Charles Lindsey Subject: Re: [EAI] New text for SMTPEXT, section 2.5.2 Message-ID: <5774825271E14BD2F5745163@as-s2n> In-Reply-To: References: 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: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, June 05, 2006 12:56 +0100 Charles Lindsey wrote: > On Mon, 05 Jun 2006 08:42:17 +0100, John C Klensin > wrote: > > >> 2.5.2. Trace Fields >> >> Internationalized domain names in Received fields must be >> transmitted in the punycode form. "For" fields containing >> internationalized addresses are prohibited, since subsequent >> downgrading would force violating rules in RFC 2821 >> prohibiting altering existing Received fields. With these >> two restrictions, there should be no need for UTF-8 >> information in Received fields and such information is >> prohibited to preserve the integrity of those fields. >> More generally, UTF-8 information of any sort MUST NOT >> appear in Received fields, even in comments within those >> fields. > > I think you shold adopt Chris Newmsn's suggestion that any For > field containing an internationalized addresse should be > written inside a comment (For fields are too useful to > abandon them entriely). > > And I see no harm in UTF-8 inside comments (since the > downgrade mechanism is clear, and Chris Newman's suggestion > requires it). > > It might be a kinder to use RFC 2047 inside such comments, but > I would not make that stronger than a "SHOULD". Charles, there are important historical reasons for not changing the rule that MTAs never earlier Received fields. You may feel that UTF-8 in Received comments are so important that the "no modifications" principle should be overridden, but it certainly is not so obvious as to constitute "no harm". As far as the utility of "for" fields, my recollection was that the topic was discussed during the DRUMS work because of the potential security issues if there were more than one recipient (and even more so if any of the envelope recipients did not appear in the headers). My memory could be wrong, but I believe the decision to retain "for" at all in 2821 (other than as a legacy "MAY") was a compromise between those who thought it was sometimes useful and those who were concerned about the security issues. If that recollection is even partially correct, I infer that there isn't strong community consensus that "for" fields are too useful to abandon. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jun 06 06:22:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnYh8-0005J3-Op; Tue, 06 Jun 2006 06:21:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnYh7-0005Iy-0X for ima@ietf.org; Tue, 06 Jun 2006 06:21:53 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnYh5-000504-6F for ima@ietf.org; Tue, 06 Jun 2006 06:21:52 -0400 Received: from host81-144-67-219.midband.mdip.bt.net ([81.144.67.219] country=GB) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.218) id 4485573a.a43e.11a for ima@ietf.org; Tue, 6 Jun 2006 11:21:46 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (gmrs-tacacs [192.168.0.2]) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k56ABXq08528 for ; Tue, 6 Jun 2006 11:11:34 +0100 (BST) 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 k56AB3nn025208 for ; Tue, 6 Jun 2006 11:11:04 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] New text for SMTPEXT, section 2.5.2 References: <5774825271E14BD2F5745163@as-s2n> Message-ID: Date: Tue, 06 Jun 2006 11:11:02 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <5774825271E14BD2F5745163@as-s2n> 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 06 Jun 2006 01:08:05 +0100, John C Klensin wrote: > Charles, there are important historical reasons for not changing the > rule that MTAs never earlier Received fields. You may feel that UTF-8 > in Received comments are so important that the "no modifications" > principle should be overridden, but it certainly is not so obvious as to > constitute "no harm". Well I have certainly seen suggestions on this list (Chris Newman IIRC) that the principle in question might be relaxed in cases such as this. But the possibility of requiring, in the smtp document, that any UTF-8 in comments within Received headers should be generated in downgraded form (i.e. MUST be encoded as per RFC 2047) would cover the situation whilst still retaining the 'no changes' rule. > > As far as the utility of "for" fields, my recollection was that the > topic was discussed during the DRUMS work because of the potential > security issues if there were more than one recipient (and even more so > if any of the envelope recipients did not appear in the headers). My > memory could be wrong, but I believe the decision to retain "for" at all > in 2821 (other than as a legacy "MAY") was a compromise between those > who thought it was sometimes useful and those who were concerned about > the security issues. If that recollection is even partially correct, I > infer that there isn't strong community consensus that "for" fields are > too useful to abandon. I can only speak for my own experience, which is that I have often found "for" fields to be helpful when poking around in Received headers. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Jun 06 13:09:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnf3T-0008Ho-LN; Tue, 06 Jun 2006 13:09:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnf3S-0008Hi-Kv for ima@ietf.org; Tue, 06 Jun 2006 13:09:22 -0400 Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnf3Q-0001Vu-Ax for ima@ietf.org; Tue, 06 Jun 2006 13:09: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]:47381) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Fnf3J-0007wd-Tb (Exim 4.54) for ima@ietf.org (return-path ); Tue, 06 Jun 2006 18:09:13 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Fnf3J-0007HD-4M (Exim 4.53) for ima@ietf.org (return-path ); Tue, 06 Jun 2006 18:09:13 +0100 Date: Tue, 6 Jun 2006 18:09:13 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ima@ietf.org Subject: Re: [EAI] New text for SMTPEXT, section 2.5.2 In-Reply-To: Message-ID: References: <5774825271E14BD2F5745163@as-s2n> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 6 Jun 2006, Charles Lindsey wrote: > On Tue, 06 Jun 2006 01:08:05 +0100, John C Klensin wrote: > > > > As far as the utility of "for" fields, my recollection was that the > > topic was discussed during the DRUMS work because of the potential > > security issues if there were more than one recipient (and even more > > so if any of the envelope recipients did not appear in the headers). > > My memory could be wrong, but I believe the decision to retain "for" > > at all in 2821 (other than as a legacy "MAY") was a compromise between > > those who thought it was sometimes useful and those who were concerned > > about the security issues. If that recollection is even partially > > correct, I infer that there isn't strong community consensus that > > "for" fields are too useful to abandon. > > I can only speak for my own experience, which is that I have often found > "for" fields to be helpful when poking around in Received headers. Speaking as a postmaster, I agree, because it's usually more convenient than digging the same information out of the logs. My servers also record the return path in a comment in their Received: lines to help with tracing messages through mailing lists; this is also a popular way of passing the return path to content scanners. So I think we need an official way to record utf8 email addresses in Received: lines, even if the "for" field can only appear some of the time. Tony. -- f.a.n.finch http://dotat.at/ ROCKALL: SOUTH BAILEY SOUTH OR SOUTHWEST 4 OR 5 VEERING NORTH 3 OR 4, THEN BECOMING VARIABLE. OCCASIONAL RAIN. MODERATE WITH FOG PATCHES. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 07 14:35:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2sM-00045t-TF; Wed, 07 Jun 2006 14:35:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2sL-000441-R8 for ima@ietf.org; Wed, 07 Jun 2006 14:35: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 1Fo2sG-0006Fs-Iu for ima@ietf.org; Wed, 07 Jun 2006 14:35:29 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Fo2rs-000LX0-Tf; Wed, 07 Jun 2006 14:35:04 -0400 Date: Wed, 07 Jun 2006 14:34:30 -0400 From: John C Klensin To: Chris Newman Subject: Re: [EAI] clarify Received header format Message-ID: <0AEBEB3D3B4CFBADD1D3B792@7AD4D3FB4841A5E367CCF211> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris, I went back and reread this note in the aftermath of the Beijing interim meeting. I think we disagree, but want to make the point of disagreement very clear. I hope that will contribute to a useful discussion that will move us forward. --On Friday, May 05, 2006 16:25 -0700 Chris Newman wrote: > I agree it's absolutely critical to have the UTF-8 address in > the Received header for diagnostic purposes. We have already lost "absolutely critical" in the 2821 space, since 2821 strongly recommends against the use of "for" in the Received field provided by any SMTP receiver implementation that receives more than one RCPT command for the message. That effectively means "never" if there is more than one recipient on the same host at the submission server and "not until forwarding, relaying, and routing get things down to one recipient" at intermediate or delivery servers. (I think the 2821 language is not as clear as it might be, but that was the intent). > But 7-bit > downgrading of Received headers must be as non-destructive and > mechanically simple as possible. Tampering with diagnostic > trace information is very risky (but so is providing > incomplete information). Ok, we agree so far, modulo the above discussion about incomplete information. > I suggest we require 7-bit in all syntactic parts of the > Received headers except for comments where we permit UTF-8. Ok so far. This effectively prohibit "for utf8-address", which is what the working copy of "framework" now says. > On down-conversion, the comments with UTF-8 characters are > 2047 encoded; no other changes to the Received header are > permitted. This permits the UTF-8 address to be carried in > canonical form as a comment in a pure UTF-8 environment, and > the only permitted down-conversion is one that's > non-destructive. > > All domain names in the Received header will be IDN encoded > (but the 8-bit domain should be included in a comment), and > the for clause will contain either the 7-bit alternate address > or the 7-bit down-conversion (with the true UTF-8 address in > the comments). Here we have our first problem: The semantics of the ACE-converted address (under ATOMIC) or the ALT-ADDRESS are "an address to which the sender, presumably on out of band instructions from the recipient, specified that the message be sent if the base utf8-address turns out to be unusable. There is no guarantee that the base address and alternate addresses are the same, or even refer to the same users. If we structure "for" in a way that assumes they are the same user at the same mailbox, we are sending out misleading information. And, IMO, misleading information is even worse than incomplete information. Our second problem relates to where the Received field comes from. I know you don't need this tutorial, but there seems to be enough confusion by others... An MTA that is going to supply a Received field always deals with two messages: (i) The message it receives. Except for the submission MTA, that message always contains existing Received fields. The submission MTA may see a Received field to. Let's call these the "old received fields". (ii) The message it transmits. This message will always contain one or more Received fields supplied by the MTA in question (the "new Received fields") plus the previous, "old" ones. As an aside, if we follow the same principles for downgrading that we do for gateways and used "for" or a comment equivalent (ignoring how to represent it for the moment) there would normally be two "new" Received fields from the downgrading MTA: Received: from previous-MTA-domain by current-MTA-domain at DateTime for UTF8-recipient... and Received: from current-MTA-domain by current-MTA-domain at DateTime for Alternate-recipient... I see no problem at all in the MTA putting comments (with encoded words or otherwise) in the new Received fields it supplies. I am very concerned about its changing any information at all in old Received fields that it receives and is to forward on. To do so risks very serious distortions of what came before, which is why we have prohibited it. If we were to permit this, I think it should be done only with specific annotation in one of the new Received headers about what was changed and why, but it would be better to avoid it. But, if old Received lines contain UTF-8 information, even in comments, your suggestion above requires converting that information into encoded words. That takes us far out on the slipperly slope about changing old Received headers and seems to be to be undesirable without far stronger justification. As an aside, a suggestion was made during the design team meeting in September. It seems to have gotten lost, but it was to document the relationship between a header UTF-8 address and its ASCII replacement during or after downgrading by mapping the UTF-8 header address into part of the display name, e.g.,=20 Red-nosed clown with ALT-ADDRESS equal to bozo@clowns.example.com would become something like (see "aside" below) "Red-nosed clown ( = =3D?iso-8859-1?q?b=3DF3z0?=3D@clowns.example.com )" It still seems to me that would provide the right sort of traceability, in the right place, without distorting any other rules. john Aside: RFC 2047 specifies a preference for character coding based on ISO 8859-NN where possible and, as far as I can tell, that suggestion has not been updated. It is clearly not part of the work of this WG, but it is probably getting near time to update 2047 to express a preference for Unicode and to specify whether that preference is for UTF-8 (i.e., a variable number of octets per character) or, e.g., the equivalent of a U+NNNN encoding. It seems to me that anyone strongly advocating the use of encoded words to solve downgrading problems needs to take on the task of being sure that update to 2047 gets done somehow. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 07 14:35:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2sS-0004AM-0i; Wed, 07 Jun 2006 14:35:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2sQ-00047f-Hj for ima@ietf.org; Wed, 07 Jun 2006 14:35:34 -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 1Fo2sL-0006G5-Ty for ima@ietf.org; Wed, 07 Jun 2006 14:35:34 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Fo2s8-000LX0-8R; Wed, 07 Jun 2006 14:35:19 -0400 Date: Wed, 07 Jun 2006 14:32:43 -0400 From: John C Klensin To: Chris Newman Subject: Re: [EAI] clarify Received header format Message-ID: <33531383050605E7D28D67FA@p3.JCK.COM> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris, I went back and reread this note in the aftermath of the Beijing interim meeting. I think we disagree, but want to make the point of disagreement very clear. I hope that will contribute to a useful discussion that will move us forward. --On Friday, May 05, 2006 16:25 -0700 Chris Newman wrote: > I agree it's absolutely critical to have the UTF-8 address in > the Received header for diagnostic purposes. We have already lost "absolutely critical" in the 2821 space, since 2821 strongly recommends against the use of "for" in the Received field provided by any SMTP receiver implementation that receives more than one RCPT command for the message. That effectively means "never" if there is more than one recipient on the same host at the submission server and "not until forwarding, relaying, and routing get things down to one recipient" at intermediate or delivery servers. (I think the 2821 language is not as clear as it might be, but that was the intent). > But 7-bit > downgrading of Received headers must be as non-destructive and > mechanically simple as possible. Tampering with diagnostic > trace information is very risky (but so is providing > incomplete information). Ok, we agree so far, modulo the above discussion about incomplete information. > I suggest we require 7-bit in all syntactic parts of the > Received headers except for comments where we permit UTF-8. Ok so far. This effectively prohibit "for utf8-address", which is what the working copy of "framework" now says. > On down-conversion, the comments with UTF-8 characters are > 2047 encoded; no other changes to the Received header are > permitted. This permits the UTF-8 address to be carried in > canonical form as a comment in a pure UTF-8 environment, and > the only permitted down-conversion is one that's > non-destructive. > > All domain names in the Received header will be IDN encoded > (but the 8-bit domain should be included in a comment), and > the for clause will contain either the 7-bit alternate address > or the 7-bit down-conversion (with the true UTF-8 address in > the comments). Here we have our first problem: The semantics of the ACE-converted address (under ATOMIC) or the ALT-ADDRESS are "an address to which the sender, presumably on out of band instructions from the recipient, specified that the message be sent if the base utf8-address turns out to be unusable. There is no guarantee that the base address and alternate addresses are the same, or even refer to the same users. If we structure "for" in a way that assumes they are the same user at the same mailbox, we are sending out misleading information. And, IMO, misleading information is even worse than incomplete information. Our second problem relates to where the Received field comes from. I know you don't need this tutorial, but there seems to be enough confusion by others... An MTA that is going to supply a Received field always deals with two messages: (i) The message it receives. Except for the submission MTA, that message always contains existing Received fields. The submission MTA may see a Received field to. Let's call these the "old received fields". (ii) The message it transmits. This message will always contain one or more Received fields supplied by the MTA in question (the "new Received fields") plus the previous, "old" ones. As an aside, if we follow the same principles for downgrading that we do for gateways and used "for" or a comment equivalent (ignoring how to represent it for the moment) there would normally be two "new" Received fields from the downgrading MTA: Received: from previous-MTA-domain by current-MTA-domain at DateTime for UTF8-recipient... and Received: from current-MTA-domain by current-MTA-domain at DateTime for Alternate-recipient... I see no problem at all in the MTA putting comments (with encoded words or otherwise) in the new Received fields it supplies. I am very concerned about its changing any information at all in old Received fields that it receives and is to forward on. To do so risks very serious distortions of what came before, which is why we have prohibited it. If we were to permit this, I think it should be done only with specific annotation in one of the new Received headers about what was changed and why, but it would be better to avoid it. But, if old Received lines contain UTF-8 information, even in comments, your suggestion above requires converting that information into encoded words. That takes us far out on the slipperly slope about changing old Received headers and seems to be to be undesirable without far stronger justification. As an aside, a suggestion was made during the design team meeting in September. It seems to have gotten lost, but it was to document the relationship between a header UTF-8 address and its ASCII replacement during or after downgrading by mapping the UTF-8 header address into part of the display name, e.g.,=20 Red-nosed clown with ALT-ADDRESS equal to bozo@clowns.example.com would become something like (see "aside" below) "Red-nosed clown ( = =3D?iso-8859-1?q?b=3DF3z0?=3D@clowns.example.com )" It still seems to me that would provide the right sort of traceability, in the right place, without distorting any other rules. john Aside: RFC 2047 specifies a preference for character coding based on ISO 8859-NN where possible and, as far as I can tell, that suggestion has not been updated. It is clearly not part of the work of this WG, but it is probably getting near time to update 2047 to express a preference for Unicode and to specify whether that preference is for UTF-8 (i.e., a variable number of octets per character) or, e.g., the equivalent of a U+NNNN encoding. It seems to me that anyone strongly advocating the use of encoded words to solve downgrading problems needs to take on the task of being sure that update to 2047 gets done somehow. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 07 14:40:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2xG-0008Ok-OV; Wed, 07 Jun 2006 14:40:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2xF-0008Of-Nh for ima@ietf.org; Wed, 07 Jun 2006 14:40:33 -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 1Fo2xC-0007Bs-M2 for ima@ietf.org; Wed, 07 Jun 2006 14:40:33 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Fo2x1-000LYf-0y; Wed, 07 Jun 2006 14:40:22 -0400 Date: Wed, 07 Jun 2006 14:39:48 -0400 From: John C Klensin To: Chris Newman Subject: Re: [EAI] clarify Received header format Message-ID: 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: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Sorry... that example should have been "Red-nosed clown ( =?iso-8859-1?q?b=F3z0?=@clowns.example.com )" obviously, I hope. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 07 17:05:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo5DG-0006If-PH; Wed, 07 Jun 2006 17:05:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo5DF-0006Ia-F5 for ima@ietf.org; Wed, 07 Jun 2006 17:05:13 -0400 Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo5DC-0002ZQ-Pq for ima@ietf.org; Wed, 07 Jun 2006 17:05:13 -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]:34865) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1Fo5D6-0004dr-3b (Exim 4.54) for ima@ietf.org (return-path ); Wed, 07 Jun 2006 22:05:04 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Fo5D6-0003fu-2J (Exim 4.53) for ima@ietf.org (return-path ); Wed, 07 Jun 2006 22:05:04 +0100 Date: Wed, 7 Jun 2006 22:05:04 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ima@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [EAI] ALT-ADDRESS and ATOMIC X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Will the rationale for the ALT-ADDRESS and ATOMIC options be included in any of the drafts? (Sorry if it's already there and I have missed it.) Why not just require that downgrading is always possible? This would make both options unnecessary, and I like the idea because it reduces the number of protocol options and I can see some awkward interop and usability problems caused by their existence. I see problems coming from the fact that the correct values for the ALT-ADDRESS and ATOMIC options must be accurately communicated from the recipient to the sender before the message is sent. In the case of a reply, how can senders extract these values from the messages they are replying to? In other cases, I imagine that it might be possible to get the values from some structured electronic medium, such as an internationalized vcard or an ldap directory with an internationalized schema or perhaps an extended form of mailto: URI. In many cases the utf8 address will be cut-and-pasted from a document or manually typed in from paper, and there's not the slightest chance that you can expect users to understand the importance of the IMA metadata or to transcribe it correctly. Furthermore, there's no way that any automatic system in the sender's MUA or MSA can correct a mistake. What happens when there is a mistake? Does bouncing an erroneously downgraded message have the same effect on the sender as bouncing a message because it cannot be downgraded? If a sender's address book mixes up the recipient's alt-address with one of the recipient's unrelated non-utf8 addresses, the incorrect end site may or may not handle the downgraded message sensibly. Note that if all utf8 addresses are downgradeable, then internationalizing email addresses in vcards or LDAP or URIs etc. is relatively simple: the email address is still just a single field (without new IMA metadata); it just has a more relaxed syntax. Tony. -- f.a.n.finch http://dotat.at/ HEBRIDES: SOUTH OR SOUTHWEST 4 OR 5, OCCASIONALLY 6 IN NORTHWEST. RAIN OR DRIZZLE. 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 Jun 07 19:23:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo7Ms-0004zx-4N; Wed, 07 Jun 2006 19:23:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo7Mr-0004zs-IC for ima@ietf.org; Wed, 07 Jun 2006 19:23:17 -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 1Fo7Mq-0002jq-UP for ima@ietf.org; Wed, 07 Jun 2006 19:23:17 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Fo7Mp-000Mnl-Ig; Wed, 07 Jun 2006 19:23:15 -0400 Date: Wed, 07 Jun 2006 19:23:14 -0400 From: John C Klensin To: Tony Finch , ima@ietf.org Subject: Re: [EAI] ALT-ADDRESS and ATOMIC Message-ID: <9FDD9FDAA20DC61420A5D3F7@p3.JCK.COM> In-Reply-To: References: 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: 67c1ea29f88502ef6a32ccec927970f0 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 07 June, 2006 22:05 +0100 Tony Finch wrote: > Will the rationale for the ALT-ADDRESS and ATOMIC options be > included in any of the drafts? (Sorry if it's already there > and I have missed it.) Yes. It is most likely to show up in a non-WG draft that discusses constraints on solutions and systems that are so overconstrained as to make solutions impossible. For a preview, find one of the later versions of draft-klensin-emailaddr-i18n, probably about -03. > Why not just require that downgrading is always possible? This > would make both options unnecessary, and I like the idea > because it reduces the number of protocol options and I can > see some awkward interop and usability problems caused by > their existence. Because, in the most general case, downgrading is simply not possible, at least without imposing unreasonable constraints. The problem, briefly, is that all sorts of things get encoded into email local-parts today and one cannot downgrade addresses on a message without either (i) giving up the ability to do the things those encodings are used for in i18n messages (i.e., restricting their use to ASCII messages or (ii) strongly restricting the order in which message-receiving MTAs do things, i.e., their order of operations. Neither of those options seemed acceptable and, if we want to see deployment without completely rewriting MTAs that are otherwise easy to adapt, wise. > I see problems coming from the fact that the correct values > for the ALT-ADDRESS and ATOMIC options must be accurately > communicated from the recipient to the sender before the > message is sent. In the case of a reply, how can senders > extract these values from the messages they are replying to? The right mechanism(s) for carrying this information is the headers is being worked on now. For a message that has already been downgraded, the recipient should not have a problem. For one that is delivered with the utf8-addresses intact, presumably the recipient won't send the message out via hosts or relays that will require downgrading in the overwhelming number of cases. But the answer is that, in the most general case, what you ask for may not be possible. > In other cases, I imagine that it might be possible to get the > values from some structured electronic medium, such as an > internationalized vcard or an ldap directory with an > internationalized schema or perhaps an extended form of > mailto: URI. In many cases the utf8 address will be > cut-and-pasted from a document or manually typed in from > paper, and there's not the slightest chance that you can > expect users to understand the importance of the IMA metadata > or to transcribe it correctly. Furthermore, there's no way > that any automatic system in the sender's MUA or MSA can > correct a mistake. Right. There are some other cases that are even worse. > What happens when there is a mistake? Does bouncing an > erroneously downgraded message have the same effect on the > sender as bouncing a message because it cannot be downgraded? > If a sender's address book mixes up the recipient's > alt-address with one of the recipient's unrelated non-utf8 > addresses, the incorrect end site may or may not handle the > downgraded message sensibly. > > Note that if all utf8 addresses are downgradeable, then > internationalizing email addresses in vcards or LDAP or URIs > etc. is relatively simple: the email address is still just a > single field (without new IMA metadata); it just has a more > relaxed syntax. Sure. And, no disrepect intended, but if all pigs flew long distances along paths that could be plotted, one could figure out some interesting solutions to hunger problems in some parts of the world. Unfortunately, if one imposes the constraints "all messages must be downgradable and downgrading is always required" then the result is going to be either * No internationalized email addresses or * Severe constraints on the features and characteristics of email that can be used with such addresses And, unfortunately, that choice is quite likely to lead to a third choice: * many local systems for doing email in particular languages and scripts that don't, in general, interoperate with each other A different way to look at this is that, in the current email environment, if you send a message to me and can't spell my name exactly the way I spell it, the message is going to bounce: the mail system doesn't give you any right to expect corrections or adaptation to near-matches, although some systems will do that. If you have a Chinese colleague and try to use her Chinese address, and can't spell the name exactly the way she spells it, you also expect the message to bounce. If you extend that principle to your having to spell the address in the same way that she, and all intermediate systems, spell it, we would be in exactly the same position we would be in if we _never_ downgrade. Efforts are underway to define downgrading so that it can be applied when it is appropriate, when people want to do the work, and when circumstances are right. Some reasonable people believe that, in practice, it won't be used much and things will bounce when messages with i18n information are transmitted between upgraded and un-upgraded systems. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 07 21:58:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo9nQ-0002dl-An; Wed, 07 Jun 2006 21:58:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo9nP-0002dd-2a for ima@ietf.org; Wed, 07 Jun 2006 21:58:51 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fo9nM-0005E6-TJ for ima@ietf.org; Wed, 07 Jun 2006 21:58:51 -0400 Received: (snipe 14958 invoked by uid 0); 8 Jun 2006 10:58:47 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.91.12 (Processed in 0.797868 secs); Received: from unknown (HELO ?220.69.185.11?) (Z???own@220.69.185.11) by unknown with SMTP; 8 Jun 2006 10:58:46 +0900 X-RCPTTO: klensin@jck.com, dot@dotat.at, ima@ietf.org Message-ID: <44878444.1000200@icu.ac.kr> Date: Thu, 08 Jun 2006 10:58:28 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: John C Klensin Subject: Re: [EAI] ALT-ADDRESS and ATOMIC References: <9FDD9FDAA20DC61420A5D3F7@p3.JCK.COM> In-Reply-To: <9FDD9FDAA20DC61420A5D3F7@p3.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin : > > > --On Wednesday, 07 June, 2006 22:05 +0100 Tony Finch > wrote: > >> Will the rationale for the ALT-ADDRESS and ATOMIC options be >> included in any of the drafts? (Sorry if it's already there >> and I have missed it.) > > Yes. It is most likely to show up in a non-WG draft that > discusses constraints on solutions and systems that are so > overconstrained as to make solutions impossible. For a preview, > find one of the later versions of draft-klensin-emailaddr-i18n, > probably about -03. Section 2.4 of eai-smtpext-00 draft includes a little stuff for this as well. > (snip) > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 08 07:16:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoIV7-00046r-1Y; Thu, 08 Jun 2006 07:16:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoIV6-00046m-IJ for ima@ietf.org; Thu, 08 Jun 2006 07:16:32 -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 1FoIV6-00073g-9D for ima@ietf.org; Thu, 08 Jun 2006 07:16:32 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoIV3-0004tE-17 for ima@ietf.org; Thu, 08 Jun 2006 07:16:32 -0400 Received: from host81-144-66-35.midband.mdip.bt.net ([81.144.66.35] country=GB) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.218) id 4488070a.16c94.37 for ima@ietf.org; Thu, 8 Jun 2006 12:16:26 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (gmrs-tacacs [192.168.0.2]) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k589aZq16763 for ; Thu, 8 Jun 2006 10:36:35 +0100 (BST) 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 k589ZxN7005628 for ; Thu, 8 Jun 2006 10:35:59 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] clarify Received header format References: <33531383050605E7D28D67FA@p3.JCK.COM> Message-ID: Date: Thu, 08 Jun 2006 10:35:58 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <33531383050605E7D28D67FA@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: -1.7 (-) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 07 Jun 2006 19:32:43 +0100, John C Klensin wrote: > --On Friday, May 05, 2006 16:25 -0700 Chris Newman > wrote: >> I suggest we require 7-bit in all syntactic parts of the >> Received headers except for comments where we permit UTF-8. > > Ok so far. This effectively prohibit "for utf8-address", which > is what the working copy of "framework" now says. No, it means they must be put into comments in some notation not too unlike the present "for" field. That is what Chris suggested, and is better than omitting them entirely (what then happens in the case of multiple RCPT TOs is then no different from now). Yes, it is unusual for standards to specify notations for what goes in comments, but that might be better than losing the feature entirely - but it would be a "SHOULD" at most. > >> On down-conversion, the comments with UTF-8 characters are >> 2047 encoded; no other changes to the Received header are >> permitted. This permits the UTF-8 address to be carried in >> canonical form as a comment in a pure UTF-8 environment, and >> the only permitted down-conversion is one that's >> non-destructive. Alternatively, you REQUIRE that all comments in Received headers be generated in 2047 encoding in the first place, so further downgrading would ever be necessary. Might make it slightly harder for investigators of anomalies who examine the headers in their "raw" form, but we can live with that. > Received: from previous-MTA-domain by current-MTA-domain > at DateTime for UTF8-recipient... > > and > > Received: from current-MTA-domain by current-MTA-domain > at DateTime for Alternate-recipient... Yes, I like the idea that an MTA MAY add two Received headers: "Here is what I received" "Hers is what I sent on", which would exhibit what it had done (use ALT-ADDRESS or ACEd the original one) in its "for" field. The first one might contain one of Chris's "for field in a comment"s. The second could contain a genuine normal "for" field. > Aside: RFC 2047 specifies a preference for character coding > based on ISO 8859-NN where possible and, as far as I can tell, > that suggestion has not been updated. It is clearly not part of > the work of this WG, but it is probably getting near time to > update 2047 ... RFC 2047 is a can of worms, and it will be a brave man who attempts to update it. But I would think the proper place to do it woud be in some 2822-bis. But in the meantime, wherever we ask in our documents for something to be generated in or downgraded to 2047, we can say that it SHOULD/MUST use utf-8. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Jun 08 07:16:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoIVA-0004Di-7n; Thu, 08 Jun 2006 07:16:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoIV7-00046x-Bn for ima@ietf.org; Thu, 08 Jun 2006 07:16:33 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoIV1-00073Z-OY for ima@ietf.org; Thu, 08 Jun 2006 07:16:33 -0400 Received: from host81-144-66-35.midband.mdip.bt.net ([81.144.66.35] country=GB) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.218) id 44880709.16c94.36 for ima@ietf.org; Thu, 8 Jun 2006 12:16:25 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (gmrs-tacacs [192.168.0.2]) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k589ouq16839 for ; Thu, 8 Jun 2006 10:50:56 +0100 (BST) 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 k589oKQS006565 for ; Thu, 8 Jun 2006 10:50:21 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] ALT-ADDRESS and ATOMIC References: Message-ID: Date: Thu, 08 Jun 2006 10:50:20 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 07 Jun 2006 22:05:04 +0100, Tony Finch wrote: > Why not just require that downgrading is always possible? This would make > both options unnecessary, and I like the idea because it reduces the > number of protocol options and I can see some awkward interop and > usability problems caused by their existence. I never did understand what this was not so, but John keeps assuring us that it is. So please could we have a plausible example of something that would not work without "ATOMIC", and in which even upgrading a previously ACEd local-part would not be good enough. > > I see problems coming from the fact that the correct values for the > ALT-ADDRESS and ATOMIC options must be accurately communicated from the > recipient to the sender before the message is sent. In the case of a > reply, how can senders extract these values from the messages they are > replying to? It is clear to me that ATOMICITY is a property of the mailbox, and therefore must be included syntactically within the interlationalized mailbox somehow. It would then appear automatically in the Reply-To header and in lists of published email addresses and in lists kept by list expanders. It would also pass the telephone and fax tests that way. But I thought we had already agreed to do that. There seems to be agreement that the syntax of an internationalized mailbox may include an ALT-ADDRESS (though it is yet unresolved whether the separator will be ",", "|" or something else). It was also stated that the ATOMIC property would appear in it somewhere, though I never saw any suggested syntax for that. Essentially, ATOMICITY is a property of the local-part, so it should syntactically be associated with that (even having the local-part begin with "ATOMIC would work, but is ugly). Perhaps some other separator than "@", or maybe a double "@@" to signify atomicity? -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Jun 08 08:10:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoJLa-0003Vk-DS; Thu, 08 Jun 2006 08:10:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoJLY-0003Vc-CG for ima@ietf.org; Thu, 08 Jun 2006 08:10:44 -0400 Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoJLX-0004TJ-3Y for ima@ietf.org; Thu, 08 Jun 2006 08:10:44 -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]:43975) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1FoJLT-0003UR-UB (Exim 4.54) (return-path ); Thu, 08 Jun 2006 13:10:39 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FoJLT-0001ND-36 (Exim 4.53) (return-path ); Thu, 08 Jun 2006 13:10:39 +0100 Date: Thu, 8 Jun 2006 13:10:39 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Charles Lindsey Subject: Re: [EAI] clarify Received header format In-Reply-To: Message-ID: References: <33531383050605E7D28D67FA@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@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 8 Jun 2006, Charles Lindsey wrote: > > Yes, I like the idea that an MTA MAY add two Received headers: > "Here is what I received" > "Hers is what I sent on", Isn't the latter completely redundant with the Received: line added by the next hop? Tony. -- f.a.n.finch http://dotat.at/ BISCAY: EAST 4 OR 5, OCCASIONALLY 6 IN NORTH, BECOMING VARIABLE 3 OR 4 IN SOUTHWEST. SHOWERS IN WEST. MODERATE OR GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 08 12:14:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoN9W-0000eK-VK; Thu, 08 Jun 2006 12:14:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoN9V-0000dy-Vu; Thu, 08 Jun 2006 12:14:33 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoN9T-0008Nb-6G; Thu, 08 Jun 2006 12:14:33 -0400 Received: from host81-144-65-3.midband.mdip.bt.net ([81.144.65.3] country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.218) id 44884cc3.a364.372; Thu, 8 Jun 2006 17:13:55 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k58E0kq21572; Thu, 8 Jun 2006 15:00:46 +0100 (BST) To: Internet-Drafts@ietf.org, i-d-announce@ietf.org Subject: Re: [EAI] I-D ACTION:draft-ietf-eai-utf8headers-00.txt References: Message-ID: Date: Thu, 08 Jun 2006 15:00:39 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 05 Jun 2006 20:50:01 +0100, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Email Address Internationalization > Working Group of the IETF. > > Title : Internationalized Email Headers > Author(s) : J. Yeh > Filename : draft-ietf-eai-utf8headers-00.txt > Pages : 14 > Date : 2006-6-5 This does not seem to have actually appeared on the usual download sites yet. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Jun 08 13:30:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoOKW-0002t5-04; Thu, 08 Jun 2006 13:30:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoOKU-0002qg-Os for ima@ietf.org; Thu, 08 Jun 2006 13:29:58 -0400 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoOKS-0000hu-Aw for ima@ietf.org; Thu, 08 Jun 2006 13:29:58 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:60319) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1FoOKJ-0000Gm-1a (Exim 4.54) (return-path ); Thu, 08 Jun 2006 18:29:47 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FoOKJ-0004dL-1g (Exim 4.53) (return-path ); Thu, 08 Jun 2006 18:29:47 +0100 Date: Thu, 8 Jun 2006 18:29:47 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John C Klensin Subject: Re: [EAI] ALT-ADDRESS and ATOMIC In-Reply-To: <9FDD9FDAA20DC61420A5D3F7@p3.JCK.COM> Message-ID: References: <9FDD9FDAA20DC61420A5D3F7@p3.JCK.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 7 Jun 2006, John C Klensin wrote: > > > Why not just require that downgrading is always possible? > > Because, in the most general case, downgrading is simply not possible, > at least without imposing unreasonable constraints. The problem, > briefly, is that all sorts of things get encoded into email local-parts > today and one cannot downgrade addresses on a message without either (i) > giving up the ability to do the things those encodings are used for in > i18n messages (i.e., restricting their use to ASCII messages or (ii) > strongly restricting the order in which message-receiving MTAs do > things, i.e., their order of operations. Neither of those options > seemed acceptable and, if we want to see deployment without completely > rewriting MTAs that are otherwise easy to adapt, wise. I've looked at the longer version of this argument in draft-klensin-emailaddr-i18n-03 and I think I understand the point, but I still don't think the "atomic" flag is necessary. As things are specified at the moment, if I send an 14ed message to your i14ed "atomic" address with no alt-address, and an intermediate MTA is not i14ed, then the message has to be bounced. However, the reason your address is "atomic" is that your system can't handle downgraded addresses correctly, i.e. in the way it would if they were still in their canonical form. So why can't YOUR system just bounce those problem addresses? I suppose your special processing might do something foolish instead of bouncing the message, but in that case it would do something foolish if I sent it ascii-only gibberish, and we've still lost nothing by the absence of ATOMIC. When I sent my previous message I was also skeptical about the utility of alt-addresses, but on further thought I decided there might be an aesthetic argument for attaching them to the various "from" addresses, so that an ascii-only recipient has a non-obfuscated address to reply to. I now see that alt-addresses might also be a work-around for non-"atomic" i14ed addresses (both "from" and "to"), where the special processing of the alt-address would work in cases where it wouldn't for an auto-downgraded address. I remain somewhat doubtful that people will be able to use them effectively. Tony. -- f.a.n.finch http://dotat.at/ FORTIES CROMARTY FORTH TYNE DOGGER: VARIABLE BECOMING SOUTHEAST 3 OR 4, OCCASIONALLY 5 LATER IN CROMARTY. FAIR. MODERATE WITH FOG PATCHES. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 08 23:14:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoXRc-0000cp-8f; Thu, 08 Jun 2006 23:13:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoXRa-0000cj-S2 for ima@ietf.org; Thu, 08 Jun 2006 23:13:54 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoXRZ-0008VP-5x for ima@ietf.org; Thu, 08 Jun 2006 23:13:54 -0400 Received: from host81-144-66-123.midband.mdip.bt.net ([81.144.66.123] country=GB) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.219) id 4488e767.1d6.81a for ima@ietf.org; Fri, 9 Jun 2006 04:13:43 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k58J43q04525 for ; Thu, 8 Jun 2006 20:04:04 +0100 (BST) To: "ima@ietf.org" Subject: Re: [EAI] clarify Received header format References: <33531383050605E7D28D67FA@p3.JCK.COM> Message-ID: Date: Thu, 08 Jun 2006 20:03:52 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 08 Jun 2006 13:10:39 +0100, Tony Finch wrote: > On Thu, 8 Jun 2006, Charles Lindsey wrote: >> >> Yes, I like the idea that an MTA MAY add two Received headers: >> "Here is what I received" >> "Hers is what I sent on", > > Isn't the latter completely redundant with the Received: line added by > the > next hop? Probably, but only if the next hop chooses to insert a "for" field, which not all do. But recording the change somewhere is important, and the agent that made the change is best motivated to do it. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Jun 09 00:39:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoYmo-00075b-NP; Fri, 09 Jun 2006 00:39:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoYmn-00075Q-Qg for ima@ietf.org; Fri, 09 Jun 2006 00:39:53 -0400 Received: from [159.226.7.146] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FoYml-00016w-4U for ima@ietf.org; Fri, 09 Jun 2006 00:39:53 -0400 Received: (eyou send program); Fri, 09 Jun 2006 12:39:37 +0800 Message-ID: <349827977.29149@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; Fri, 09 Jun 2006 12:39:37 +0800 Message-ID: <4488FB94.9040304@cnnic.cn> Date: Fri, 09 Jun 2006 12:39:48 +0800 From: Xiaodong Lee Organization: CNNIC User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ima@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Subject: [EAI] [Fwd: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lee@cnnic.cn List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0115013040==" Errors-To: ima-bounces@ietf.org --===============0115013040== Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear All,

Please meet the cut-off time, if you wanna submit new draft or update draft.

Regards!

xiaodong

-------- Original Message --------
Subject: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada
Date: Fri, 09 Jun 2006 00:00:01 -0400
From: ietf-secretariat@ietf.org
To: ietf-announce@ietf.org 


There are two (2) Internet-Draft cutoff dates for the 66th 
IETF Meeting in Montreal, Quebec, Canada:

June 19th: Cutoff Date for Initial (i.e., version -00) 
Internet-Draft Submissions 

All initial Internet-Drafts (version -00) must be submitted by Monday, 
June 19th at 9:00 AM ET. As always, all initial submissions with a 
filename beginning with "draft-ietf" must be approved by the 
appropriate WG Chair before they can be processed or announced.  The 
Secretariat would appreciate receiving WG Chair approval by Monday, 
June 12th at 9:00 AM ET.

June 26th: Cutoff Date for Revised (i.e., version -01 and higher) 
Internet-Draft Submissions 

All revised Internet-Drafts (version -01 and higher) must be submitted 
by Monday, June 26th at 9:00 AM ET.

Initial and revised Internet-Drafts received after their respective 
cutoff dates will not be made available in the Internet-Drafts 
directory or announced until on or after Monday, July 10th at 9:00 
AM ET, when Internet-Draft posting resumes.  Please do not wait until 
the last minute to submit.

Thank you for your understanding and cooperation. If you have any 
questions or concerns, then please send a message to 
internet-drafts@ietf.org.

The IETF Secretariat

FYI: The Internet-Draft cutoff dates as well as other significant dates
for the 66th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_66.html.

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce



-- 
-- Xiaodong LEE [The best answer is doing]
   +86-10-58813020 
   mailto:lee@cnnic.cn
   http://www.lixiaodong.cn
--===============0115013040== 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 --===============0115013040==-- From ima-bounces@ietf.org Fri Jun 09 04:28:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FocLx-0001TA-27; Fri, 09 Jun 2006 04:28:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FocLw-0001T5-01 for ima@ietf.org; Fri, 09 Jun 2006 04:28:24 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FocLt-0002K0-Tl for ima@ietf.org; Fri, 09 Jun 2006 04:28:23 -0400 Received: (snipe 5424 invoked by uid 0); 9 Jun 2006 17:28:20 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.91.12 (Processed in 0.876521 secs); Received: from unknown (HELO ?220.69.185.11?) (Z???own@220.69.185.11) by unknown with SMTP; 9 Jun 2006 17:28:19 +0900 X-RCPTTO: dot@dotat.at, klensin@jck.com, ima@ietf.org Message-ID: <44893121.4060707@icu.ac.kr> Date: Fri, 09 Jun 2006 17:28:17 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Tony Finch Subject: Re: [EAI] ALT-ADDRESS and ATOMIC References: <9FDD9FDAA20DC61420A5D3F7@p3.JCK.COM> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Tony Finch wrote: > On Wed, 7 Jun 2006, John C Klensin wrote: >>> Why not just require that downgrading is always possible? >> Because, in the most general case, downgrading is simply not possible, >> at least without imposing unreasonable constraints. The problem, >> briefly, is that all sorts of things get encoded into email local-parts >> today and one cannot downgrade addresses on a message without either (i) >> giving up the ability to do the things those encodings are used for in >> i18n messages (i.e., restricting their use to ASCII messages or (ii) >> strongly restricting the order in which message-receiving MTAs do >> things, i.e., their order of operations. Neither of those options >> seemed acceptable and, if we want to see deployment without completely >> rewriting MTAs that are otherwise easy to adapt, wise. > > I've looked at the longer version of this argument in > draft-klensin-emailaddr-i18n-03 and I think I understand the point, > but I still don't think the "atomic" flag is necessary. > > As things are specified at the moment, if I send an 14ed message to your > i14ed "atomic" address with no alt-address, and an intermediate MTA is not > i14ed, then the message has to be bounced. > > However, the reason your address is "atomic" is that your system can't > handle downgraded addresses correctly, i.e. in the way it would if they > were still in their canonical form. So why can't YOUR system just > bounce those problem addresses? > > I suppose your special processing might do something foolish instead of > bouncing the message, but in that case it would do something foolish if I > sent it ascii-only gibberish, and we've still lost nothing by the absence > of ATOMIC. > > When I sent my previous message I was also skeptical about the utility of > alt-addresses, but on further thought I decided there might be an > aesthetic argument for attaching them to the various "from" addresses, so > that an ascii-only recipient has a non-obfuscated address to reply to. I > now see that alt-addresses might also be a work-around for non-"atomic" > i14ed addresses (both "from" and "to"), where the special processing of > the alt-address would work in cases where it wouldn't for an > auto-downgraded address. I remain somewhat doubtful that people will be > able to use them effectively. I am doubtful too. It will be probably impractical to assume that average email users understand why (or why not) their email addresses are ATOMIC. However, on the other side, it seems more probable that some people would not (or could not) accept that they should have alternative Roman-based addresses that are just obfuscated to them. In my environment (i.e. Korea), young generation will stick to use ASCII addresses in most cases, while they use EAI addresses only as a fun or for cultural identification. However, older generation will certainly prefer to use "only" Korean email addresses. It will be a big burden for them to memorize Roman based alternative addresses even though the job is too trivial for the rest. For those people, "always use ATOMIC" can be a quite reasonable option to email client software vendors. Regards _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 09 11:16:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoiiT-0006J5-36; Fri, 09 Jun 2006 11:16:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoiiS-0006Ix-1f for ima@ietf.org; Fri, 09 Jun 2006 11:16:04 -0400 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoiiQ-0003KP-Oi for ima@ietf.org; Fri, 09 Jun 2006 11:16: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]:42141) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Foii1-00085k-OQ (Exim 4.54) (return-path ); Fri, 09 Jun 2006 16:15:37 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Foii1-0002PV-Gn (Exim 4.53) (return-path ); Fri, 09 Jun 2006 16:15:37 +0100 Date: Fri, 9 Jun 2006 16:15:37 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Yangwoo Ko Subject: Re: [EAI] ALT-ADDRESS and ATOMIC In-Reply-To: <44893121.4060707@icu.ac.kr> Message-ID: References: <9FDD9FDAA20DC61420A5D3F7@p3.JCK.COM> <44893121.4060707@icu.ac.kr> 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 9 Jun 2006, Yangwoo Ko wrote: > > However, older generation will certainly prefer to use "only" Korean > email addresses. It will be a big burden for them to memorize Roman > based alternative addresses even though the job is too trivial for the > rest. For those people, "always use ATOMIC" can be a quite reasonable > option to email client software vendors. Wouldn't it be better for them to allow downgrading so that it's possible for them to communicate with the ascii-only world when necessary? They don't have to worry about the details of their gibberish downgraded address. And in any case, isn't the value of the ATOMIC flag a decision for postmasters, not for end-users? And don't we want to allow i14ed communication between i14ed islands via ascii-only relays? e.g. Korean students at my university with i14ed MUAs communicating with their i14ed parents via my ascii-only MTAs? Tony. -- f.a.n.finch http://dotat.at/ BAILEY FAEROES: SOUTH OR SOUTHEAST 4 OR 5, INCREASING 6 AT TIMES. RAIN OR SHOWERS. MODERATE OR GOOD WITH FOG PATCHES. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jun 10 00:15:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fousy-0005vO-TK; Sat, 10 Jun 2006 00:15:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fousx-0005vF-Ku for ima@ietf.org; Sat, 10 Jun 2006 00:15:43 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fousw-0007cT-0g for ima@ietf.org; Sat, 10 Jun 2006 00:15:43 -0400 Received: (snipe 21889 invoked by uid 0); 10 Jun 2006 13:15:31 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.91.12 (Processed in 0.664916 secs); Received: from unknown (HELO ?10.0.0.2?) (Z???own@203.236.3.241) by unknown with SMTP; 10 Jun 2006 13:15:31 +0900 X-RCPTTO: dot@dotat.at, ima@ietf.org Message-ID: <448A4762.3020608@icu.ac.kr> Date: Sat, 10 Jun 2006 13:15:30 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Tony Finch Subject: Re: [EAI] ALT-ADDRESS and ATOMIC References: <9FDD9FDAA20DC61420A5D3F7@p3.JCK.COM> <44893121.4060707@icu.ac.kr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Tony Finch wrote: > On Fri, 9 Jun 2006, Yangwoo Ko wrote: >> However, older generation will ermiecertainly prefer to use "only" Korean >> email addresses. It will be a big burden for them to memorize Roman >> based alternative addresses even though the job is too trivial for the >> rest. For those people, "always use ATOMIC" can be a quite reasonable >> option to email client software vendors. > > Wouldn't it be better for them to allow downgrading so that it's possible > for them to communicate with the ascii-only world when necessary? They > don't have to worry about the details of their gibberish downgraded > address. > > And in any case, isn't the value of the ATOMIC flag a decision for > postmasters, not for end-users? > > And don't we want to allow i14ed communication between i14ed islands via > ascii-only relays? e.g. Korean students at my university with i14ed MUAs > communicating with their i14ed parents via my ascii-only MTAs? > > Tony. We seem to agree what we want to accomplish with this EAI effort. That is to allow local part have non ASCII while not breaking down the existing email world in the perspective of not only postmasters but also users. The only (the only one? I hope so.) discrepancy is raised when we are searching the right trade-off point between smooth integration with the existing world and ease of user learning. If we design that non ASCII addresses should be always "safe to downgrade", then users don't need to care about possible downgrading along the path. On the other hand, some of us (including me) believe that the above restriction (i.e. always donwgradable non ASCII) is harmful in the long run. I don't believe that any one of the above two is definitely better than the other. I hope that the distinction and pros/cons of the two could be clarified through the WG process and experiments. Regards _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jun 10 04:39:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foz0L-00006f-Ks; Sat, 10 Jun 2006 04:39:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foz0K-00006a-MX for ima@ietf.org; Sat, 10 Jun 2006 04:39:36 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foz0J-0004gL-7z for ima@ietf.org; Sat, 10 Jun 2006 04:39:36 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B53542596F6; Sat, 10 Jun 2006 10:38:34 +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 17842-01; Sat, 10 Jun 2006 10:38:31 +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 008E82596F4; Sat, 10 Jun 2006 10:38:30 +0200 (CEST) Message-ID: <448A8540.4010804@alvestrand.no> Date: Sat, 10 Jun 2006 10:39:28 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Yangwoo Ko Subject: Re: [EAI] ALT-ADDRESS and ATOMIC References: <9FDD9FDAA20DC61420A5D3F7@p3.JCK.COM> <44893121.4060707@icu.ac.kr> <448A4762.3020608@icu.ac.kr> In-Reply-To: <448A4762.3020608@icu.ac.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Tony Finch , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Yangwoo Ko wrote: > > We seem to agree what we want to accomplish with this EAI effort. That > is to allow local part have non ASCII while not breaking down the > existing email world in the perspective of not only postmasters but > also users. > > The only (the only one? I hope so.) discrepancy is raised when we > are searching the right trade-off point between smooth integration with > the existing world and ease of user learning. I think there are other reasons why downgrading may not always be desirable. One important issue we have not discussed yet is the "signed mail" problem - a digital signature will not verify after a downgrade (the workarounds for this are likely impossible in practice). One way of handling that issue MAY be to find a way in which the sender can indicate that if downgrading is required for delivery, he wants the message bounced, so that he can generate a (signed) ASCII version instead of the UTF8SMTP version. > > If we design that non ASCII addresses should be always "safe to > downgrade", then users don't need to care about possible downgrading > along the path. > > On the other hand, some of us (including me) believe that the above > restriction (i.e. always donwgradable non ASCII) is harmful in the long > run. > > I don't believe that any one of the above two is definitely better than > the other. I hope that the distinction and pros/cons of the two could > be clarified through the WG process and experiments. If we give the users control of this, users may show us the way. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jun 10 23:16:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpGQm-0003TK-8P; Sat, 10 Jun 2006 23:16:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpGQk-0003TF-Ua for ima@ietf.org; Sat, 10 Jun 2006 23:16:02 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpGQj-0007gn-3B for ima@ietf.org; Sat, 10 Jun 2006 23:16:02 -0400 Received: from host81-144-67-33.midband.mdip.bt.net ([81.144.67.33] country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.219) id 448b8aee.17e0c.521 for ima@ietf.org; Sun, 11 Jun 2006 04:15:58 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (gmrs-tacacs [192.168.0.2]) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k5AJL8q26715 for ; Sat, 10 Jun 2006 20:21:09 +0100 (BST) 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 k5AJKT2h024091 for ; Sat, 10 Jun 2006 20:20:30 +0100 (BST) To: "ima@ietf.org" Subject: Re: [EAI] ALT-ADDRESS and ATOMIC References: <9FDD9FDAA20DC61420A5D3F7@p3.JCK.COM> <44893121.4060707@icu.ac.kr> <448A4762.3020608@icu.ac.kr> <448A8540.4010804@alvestrand.no> Message-ID: Date: Sat, 10 Jun 2006 20:20:27 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <448A8540.4010804@alvestrand.no> 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, 10 Jun 2006 09:39:28 +0100, Harald Alvestrand wrote: > One important issue we have not discussed yet is the "signed mail" > problem - a digital signature will not verify after a downgrade (the > workarounds for this are likely impossible in practice). > One way of handling that issue MAY be to find a way in which the sender > can indicate that if downgrading is required for delivery, he wants the > message bounced, so that he can generate a (signed) ASCII version > instead of the UTF8SMTP version. If the sender indicates that his I??n address is Non-Atomic, and declines to provide an Alt-Address, then that effect will be achieved. In any case, even if headers are included within the digital signature (and signing just the body is sufficient for many purposes) it should be possible to arrange that the To: header is excluded from the Signature - the From is the important one to sign, and the sender can arrange for an aascii address in there. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Jun 12 15:00:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpreU-0004qw-1A; Mon, 12 Jun 2006 15:00:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpreT-0004pr-1v for ima@ietf.org; Mon, 12 Jun 2006 15:00:41 -0400 Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpreR-0008Es-OQ for ima@ietf.org; Mon, 12 Jun 2006 15:00:41 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:56118) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1FpreH-0004zB-3s (Exim 4.54) (return-path ); Mon, 12 Jun 2006 20:00:29 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FpreG-0001lY-VP (Exim 4.53) (return-path ); Mon, 12 Jun 2006 20:00:28 +0100 Date: Mon, 12 Jun 2006 20:00:28 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Yangwoo Ko Subject: Re: [EAI] ALT-ADDRESS and ATOMIC In-Reply-To: <448A4762.3020608@icu.ac.kr> Message-ID: References: <9FDD9FDAA20DC61420A5D3F7@p3.JCK.COM> <44893121.4060707@icu.ac.kr> <448A4762.3020608@icu.ac.kr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, 10 Jun 2006, Yangwoo Ko wrote: > > On the other hand, some of us (including me) believe that the above > restriction (i.e. always donwgradable non ASCII) is harmful in the long > run. I'm worried that the additional complexity is damaging in the long run, because it affects everything that handles email addresses, including user interfaces and non-email protocols that incidentally handle email addresses, because they all have to be extended to deal with the new metadata. Furthermore, the complexity seems to be designed to support shoddy implementations of i14ed email that can't even reliably detect a downgrade error. The signature problem is not specific to i18n: it already exists for 8BITMIME and BINARYMIME. There are a few answers: the relevant signature standards could require ascii-armoured messages, but that's undesirable because we'd like to move towards 8 bit email; or downgradability could be a per-message attribute rather than a per-address attribute - which makes sense since many of the downgrading problems only relate to the message data. Tony. -- f.a.n.finch http://dotat.at/ LUNDY FASTNET IRISH SEA: SOUTH OR SOUTHWEST 4 OR 5, OCCASIONALLY 6 AT FIRST IN IRISH SEA, VEERING WEST 3 OR 4. SHOWERS AT FIRST. GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jun 14 10:19:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWDa-0006d2-JG; Wed, 14 Jun 2006 10:19:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWDZ-0006cw-NS for ima@ietf.org; Wed, 14 Jun 2006 10:19:37 -0400 Received: from [159.226.7.146] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FqWDW-0002Cd-1l for ima@ietf.org; Wed, 14 Jun 2006 10:19:37 -0400 Received: (eyou send program); Wed, 14 Jun 2006 22:18:27 +0800 Message-ID: <350294707.16087@cnnic.cn> X-EYOUMAIL-SMTPAUTH: lee@cnnic.cn Received: from unknown (HELO [61.51.200.22]) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 14 Jun 2006 22:18:27 +0800 Message-ID: <44901AB9.6070204@cnnic.cn> Date: Wed, 14 Jun 2006 22:18:33 +0800 From: Xiaodong Lee Organization: CNNIC User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ima@ietf.org Content-Type: multipart/mixed; boundary="------------060503050005070208070801" X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Subject: [EAI] Minutes about EAI Interim Meeting in Beijing X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lee@cnnic.cn List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --------------060503050005070208070801 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Dear All, Please refer to the minutes, and notify question 23 specially. ( The attachment is the TXT version of the minutes) Every author/editor, please update your draft and submit it on time, if you want update your draft from 00 to 01. Regards! ******************************* EAI WG Interim Meeting Minutes ******************************* The interim meeting of the EAI WG was held at Meeting Room 510 of CNNIC in Beijing, China on June 6, 2006. 11 people attended in person, 2 people attended by sip-based conference, 3 people attended by video conference, 1 people attended by video/audio IM. The minutes record the issues that were discussed, and the conclusions that the people present came to. These decisions need to be verified with the mailing list. The agenda consisted of: *Current drafts reviews *Implementations and testing plans *Terminologies issues *Open issues Current Drafts Review For framework document: 1.All the drafts should be checked for consistency with the WG charter. One piece of coordination between documents is that all terminology needs to move to the framework docment. 2.Issues related to interaction with security protocols, such as DKIM/PGP/SMIME should be considered in the framework document. For scenarios document 3.There are still some scenarios that we may consider in the document. These include scenarios that involve communication between two EAI-compliant users connected via an infrastructure with one or more non-EAI-compatible elements. There was no consensus on whether these scenarios are necessary to support. For utf8headers document 4.In this document, ALT-ADDR and ATOMIC are mutually exclusive. Most attendees agreed that ALT-ADDR and ATOMIC should be exclusive. 5.Section 6.2. needs to be changed to say that protocol fields in RFC2821 are not affected. For more information, Harald has sent a comments to ima@ietf.org with the title" [EAI] Suggested additions to -headers- section 6.2 " 6.It is better that the editor can put some utf8header examples in the document. Because the current ASCII ID formt cannot support utf-8, the editor may submit a PDF version of his draft in addition to the ASCII one. For smtpext document 7.Some profiles such as SASLprep may be used in the local part of the email address, but we should start out by being permissive, discover what the problems are and forbid that while doing implementaion experiences. There was considerable uncertainty on how much the EAI specification should try to police the content of the local part. 8.Using the below form defined in rfc2821 to define the mail and rcpt commends may not work. MAIL FROM: [SP ] RCPT TO: [ SP ] The reason is that the "mail-parameters" and "rcpt-parameters" are formally defined to only use ASCII characters. We may use the following definition: MAIL FROM: [SP ] RCPT TO: [ SP ] where EAI-parameter may be alt-addr or atomic according to the value of the EAI-parameter for example, if MAIL FROM: alt-addr=AsciiUser@example.com, it means that the EAI-parameter is alt-address because the value is an email address; if MAIL FROM: EAI-parameter=y, it means that the EAI-parameter is atomic because the value is 'y' or 'n'; 9.The smtpext document will just give some outline of the usages of the parameters of alt-addr and atomic, the detailed specification should be pointed to the downgrade document. For downgrade document 10.Header encapsulation has some problems with section 2.5 of scenario doc. The only downgrade mechanism that is compatible with section 2.5 of the scenario doc is that described in section 5.3 of the downgrade document, and this will be the one selected for future work. 11.We have identified some problems with the approach described in section 5.3 of the downgrade document, but it still seems like the most promising approach. 12.The editor will update downgrade document to incorporate current utf-8headers documents 13.The approach of the section 5.3 needs more detail information. 14.Some RFC2821 related things in the downgrade document should be moved to the smtpext document. For IMAP/POP documents 15.The IMAP document mentions the upgrading. Those who care about upgrading should read that section carefully to check that it says what you think it should say. For the mailing list document 16.Edmon from Affilias volunteers to write the mailing list documents Implementation and testing plan 17.CNNIC will implement the prototype of EAI based on qmail and has a demo in the next IETF meeing 18.TWNIC will implement the prototype of EAI based on sendmail and has a demo in the next IETF meeing 19.Fujiwara from JPRS will update some MUA software to allow utf-8 based email address. 20.Yangwoo Ko, Fujiwara, Delphij from sina.com and Li Boda from sohu.com will help some implementation and test. 21.In the 67th IETF meeting, we should have a workable system based on webmail. Terminologies issues 22.Question: Is it ok to Work Group to Change mailing list ima@ietf.org into eai@ietf.org? Answer: Most of attendees do not agree that the change is needed, but nobody objects to let eai@ietf.org be an alias of ima@ietf.org. 23.Terminologies Option : In the past, multiple short names have been used for this effort: EAI, I-email , i18nemail, utf8email, emailing, IMX, IMAE, utf8smtp, ismtp. The WG needs to decide on one; in the absence of compelling technical arguments for one or the other, the meeting decided to take a straw poll to get a decision to present to the mailing list. In the first round, the result is (the number of supporters in the bracket) Utf8smtp(4), i18nemail(4), utf8email(1), IMX(1), IMAE(1), ismtp In the second round voting for the two favor: Utf8smtp, i18nemail. the result is Utf8smtp(5), i18nemail(3) The WG meeting recommends that "UTF8SMTP" should be used for this technology, but the final decision should go to the mailing list. 24.Terminology for various types of Email address ascii@ascii means the pure ascii email address Non-ascii email address means that there is at least a non-ascii character in the email address, including the below 3 categories: Non-ascii@Non-ascii ascii@Non-ascii Non-ascii@ascii If alt-address is specified by the sender, it should be named as the sender-specified ascii address; If the email address is generated from a non-ASCII address by some algorithmic function, it should be named as the algorithmic ascii address Open issues: 25.Things that should be considered but we still don't know the answer. 1)When and how much useful downgrading will be. 2)Range of characters permitted in addresses and whether/how normalized 26.If an alt-address is specified and must be used in downgrading, but the host at the alt-address domain advertizes the SMTP extension, the alt-address MUST still be used, but the UTF8 headers SHOULD NOT be downgraded. 27.The meeting discussed which additional documents to the ones listed in the current WG charter were needed. The most important one was thought to be Operational guidelines --which includes suggestions to SMTP delivery site maintainers as to how to create names -- they become very important if we avoid most or all canonicalization and preparation specifications in SMTP but dump that problem on delivery system decisions about naming. That clearly interacts with the SASLPrep (or whatever) issues The meeting was closed at 17:35 [GMT+8:00]. -- -- Xiaodong LEE [The best answer is doing] +86-10-58813020 mailto:lee@cnnic.cn http://www.lixiaodong.cn --------------060503050005070208070801 Content-Type: text/plain; name="EaiWgInterim_minutes.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="EaiWgInterim_minutes.txt" RUFJIFdHIEludGVyaW0gTWVldGluZyBNaW51dGVzDQoNClRoZSBpbnRlcmltIG1lZXRpbmcg b2YgdGhlIEVBSSBXRyB3YXMgaGVsZCBhdCBNZWV0aW5nIFJvb20gNTEwIG9mIENOTklDIGlu IEJlaWppbmcsIENoaW5hIG9uIEp1bmUgNiwgMjAwNi4NCjExIHBlb3BsZSBhdHRlbmRlZCBp biBwZXJzb24sIDIgcGVvcGxlIGF0dGVuZGVkIGJ5IHNpcC1iYXNlZCBjb25mZXJlbmNlLCAz IHBlb3BsZSBhdHRlbmRlZCBieSB2aWRlbyBjb25mZXJlbmNlLCAxIHBlb3BsZSBhdHRlbmRl ZCBieSB2aWRlby9hdWRpbyBJTS4NCg0KVGhlIG1pbnV0ZXMgcmVjb3JkIHRoZSBpc3N1ZXMg dGhhdCB3ZXJlIGRpc2N1c3NlZCwgYW5kIHRoZSBjb25jbHVzaW9ucyB0aGF0IHRoZSBwZW9w bGUgcHJlc2VudCBjYW1lIHRvLiBUaGVzZSBkZWNpc2lvbnMgbmVlZCB0byBiZSB2ZXJpZmll ZCB3aXRoIHRoZSBtYWlsaW5nIGxpc3QuDQpUaGUgYWdlbmRhIGNvbnNpc3RlZCBvZjogDQoq Q3VycmVudCBkcmFmdHMgcmV2aWV3cw0KKkltcGxlbWVudGF0aW9ucyBhbmQgdGVzdGluZyBw bGFucw0KKlRlcm1pbm9sb2dpZXMgaXNzdWVzDQoqT3BlbiBpc3N1ZXMNCg0KQ3VycmVudCBE cmFmdHMgUmV2aWV3DQpGb3IgZnJhbWV3b3JrIGRvY3VtZW50Og0KMS5BbGwgdGhlIGRyYWZ0 cyBzaG91bGQgYmUgY2hlY2tlZCBmb3IgY29uc2lzdGVuY3kgd2l0aCB0aGUgV0cgY2hhcnRl ci4gT25lIHBpZWNlIG9mIGNvb3JkaW5hdGlvbiBiZXR3ZWVuIGRvY3VtZW50cyBpcyB0aGF0 IGFsbCB0ZXJtaW5vbG9neSBuZWVkcyB0byBtb3ZlIHRvIHRoZSBmcmFtZXdvcmsgZG9jbWVu dC4NCjIuSXNzdWVzIHJlbGF0ZWQgdG8gaW50ZXJhY3Rpb24gd2l0aCBzZWN1cml0eSBwcm90 b2NvbHMsIHN1Y2ggYXMgREtJTS9QR1AvU01JTUUgc2hvdWxkIGJlIGNvbnNpZGVyZWQgaW4g dGhlIGZyYW1ld29yayBkb2N1bWVudC4NCkZvciBzY2VuYXJpb3MgZG9jdW1lbnQNCjMuVGhl cmUgYXJlIHN0aWxsIHNvbWUgc2NlbmFyaW9zIHRoYXQgd2UgbWF5IGNvbnNpZGVyIGluIHRo ZSBkb2N1bWVudC4gVGhlc2UgaW5jbHVkZSBzY2VuYXJpb3MgdGhhdCBpbnZvbHZlIGNvbW11 bmljYXRpb24gYmV0d2VlbiB0d28gRUFJLWNvbXBsaWFudCB1c2VycyBjb25uZWN0ZWQgdmlh IGFuIGluZnJhc3RydWN0dXJlIHdpdGggb25lIG9yIG1vcmUgbm9uLUVBSS1jb21wYXRpYmxl IGVsZW1lbnRzLiBUaGVyZSB3YXMgbm8gY29uc2Vuc3VzIG9uIHdoZXRoZXIgdGhlc2Ugc2Nl bmFyaW9zIGFyZSBuZWNlc3NhcnkgdG8gc3VwcG9ydC4NCg0KRm9yIHV0ZjhoZWFkZXJzIGRv Y3VtZW50DQo0LkluIHRoaXMgZG9jdW1lbnQsIEFMVC1BRERSIGFuZCBBVE9NSUMgYXJlIG11 dHVhbGx5IGV4Y2x1c2l2ZS4gTW9zdCBhdHRlbmRlZXMgYWdyZWVkIHRoYXQgQUxULUFERFIg YW5kIEFUT01JQyBzaG91bGQgYmUgZXhjbHVzaXZlLg0KNS5TZWN0aW9uIDYuMi4gbmVlZHMg dG8gYmUgY2hhbmdlZCB0byBzYXkgdGhhdCBwcm90b2NvbCBmaWVsZHMgaW4gUkZDMjgyMSBh cmUgbm90IGFmZmVjdGVkLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgSGFyYWxkIGhhcyBzZW50 IGEgY29tbWVudHMgdG8gaW1hQGlldGYub3JnIHdpdGggdGhlIHRpdGxlIiBbRUFJXSBTdWdn ZXN0ZWQgYWRkaXRpb25zIHRvIC1oZWFkZXJzLSBzZWN0aW9uIDYuMiAiDQo2Lkl0IGlzIGJl dHRlciB0aGF0IHRoZSBlZGl0b3IgY2FuIHB1dCBzb21lIHV0ZjhoZWFkZXIgZXhhbXBsZXMg aW4gdGhlIGRvY3VtZW50LiBCZWNhdXNlIHRoZSAgY3VycmVudCBBU0NJSSBJRCBmb3JtdCBj YW5ub3Qgc3VwcG9ydCB1dGYtOCwgdGhlIGVkaXRvciBtYXkgc3VibWl0IGEgUERGIHZlcnNp b24gb2YgaGlzIGRyYWZ0IGluIGFkZGl0aW9uIHRvIHRoZSBBU0NJSSBvbmUuDQoNCkZvciBz bXRwZXh0IGRvY3VtZW50DQo3LlNvbWUgcHJvZmlsZXMgc3VjaCBhcyBTQVNMcHJlcCBtYXkg YmUgdXNlZCBpbiB0aGUgbG9jYWwgcGFydCBvZiB0aGUgZW1haWwgYWRkcmVzcywgYnV0IHdl IHNob3VsZCBzdGFydCBvdXQgYnkgYmVpbmcgcGVybWlzc2l2ZSwgZGlzY292ZXIgd2hhdCB0 aGUgcHJvYmxlbXMgYXJlIGFuZCBmb3JiaWQgdGhhdCB3aGlsZSBkb2luZyBpbXBsZW1lbnRh aW9uIGV4cGVyaWVuY2VzLiBUaGVyZSB3YXMgY29uc2lkZXJhYmxlIHVuY2VydGFpbnR5IG9u IGhvdyBtdWNoIHRoZSBFQUkgc3BlY2lmaWNhdGlvbiBzaG91bGQgdHJ5IHRvIHBvbGljZSB0 aGUgY29udGVudCBvZiB0aGUgbG9jYWwgcGFydC4NCjguVXNpbmcgdGhlIGJlbG93IGZvcm0g ZGVmaW5lZCBpbiByZmMyODIxIHRvIGRlZmluZSB0aGUgbWFpbCBhbmQgcmNwdCBjb21tZW5k cyBtYXkgbm90IHdvcmsuDQogICAgIE1BSUwgRlJPTTo8cmV2ZXJzZS1wYXRoPiBbU1AgPG1h aWwtcGFyYW1ldGVycz4gXSA8Q1JMRj4gICAgDQogICAgIFJDUFQgVE86PGZvcndhcmQtcGF0 aD4gWyBTUCA8cmNwdC1wYXJhbWV0ZXJzPiBdIDxDUkxGPg0KVGhlIHJlYXNvbiBpcyB0aGF0 IHRoZSAibWFpbC1wYXJhbWV0ZXJzIiBhbmQgInJjcHQtcGFyYW1ldGVycyIgYXJlIGZvcm1h bGx5IGRlZmluZWQgdG8gb25seSB1c2UgQVNDSUkgY2hhcmFjdGVycy4NCldlIG1heSB1c2Ug dGhlIGZvbGxvd2luZyBkZWZpbml0aW9uOg0KTUFJTCBGUk9NOjxyZXZlcnNlLXBhdGg+IFtT UCA8RUFJLXBhcmFtZXRlcj4gXSA8Q1JMRj4gICANCiAgICAgICBSQ1BUIFRPOjxmb3J3YXJk LXBhdGg+IFsgU1AgPEVBSS1wYXJhbWV0ZXI+IF0gPENSTEY+DQp3aGVyZSBFQUktcGFyYW1l dGVyIG1heSBiZSBhbHQtYWRkciBvciBhdG9taWMgYWNjb3JkaW5nIHRvIHRoZSB2YWx1ZSBv ZiB0aGUgRUFJLXBhcmFtZXRlcg0KZm9yIGV4YW1wbGUsIA0KaWYgTUFJTCBGUk9NOjx1dGYt OFVzZXJASUROPiBhbHQtYWRkcj1Bc2NpaVVzZXJAZXhhbXBsZS5jb20sIGl0IG1lYW5zIHRo YXQgdGhlIEVBSS1wYXJhbWV0ZXIgaXMgYWx0LWFkZHJlc3MgYmVjYXVzZSB0aGUgdmFsdWUg aXMgYW4gZW1haWwgYWRkcmVzczsgDQppZiBNQUlMIEZST006PHV0Zi04VXNlckBJRE4+IEVB SS1wYXJhbWV0ZXI9eSwgaXQgbWVhbnMgdGhhdCB0aGUgRUFJLXBhcmFtZXRlciBpcyBhdG9t aWMgYmVjYXVzZSB0aGUgdmFsdWUgaXMgJ3knIG9yICduJzsNCjkuVGhlIHNtdHBleHQgZG9j dW1lbnQgd2lsbCBqdXN0IGdpdmUgc29tZSBvdXRsaW5lIG9mIHRoZSB1c2FnZXMgb2YgdGhl IHBhcmFtZXRlcnMgb2YgYWx0LWFkZHIgYW5kIGF0b21pYywgdGhlIGRldGFpbGVkIHNwZWNp ZmljYXRpb24gc2hvdWxkIGJlIHBvaW50ZWQgdG8gdGhlIGRvd25ncmFkZSBkb2N1bWVudC4g DQoNCkZvciBkb3duZ3JhZGUgZG9jdW1lbnQNCjEwLkhlYWRlciBlbmNhcHN1bGF0aW9uIGhh cyBzb21lIHByb2JsZW1zIHdpdGggc2VjdGlvbiAyLjUgb2Ygc2NlbmFyaW8gZG9jLiBUaGUg b25seSBkb3duZ3JhZGUgbWVjaGFuaXNtIHRoYXQgaXMgY29tcGF0aWJsZSB3aXRoIHNlY3Rp b24gMi41IG9mIHRoZSBzY2VuYXJpbyBkb2MgaXMgdGhhdCBkZXNjcmliZWQgaW4gc2VjdGlv biA1LjMgb2YgdGhlIGRvd25ncmFkZSBkb2N1bWVudCwgYW5kIHRoaXMgd2lsbCBiZSB0aGUg b25lIHNlbGVjdGVkIGZvciBmdXR1cmUgd29yay4NCjExLldlIGhhdmUgaWRlbnRpZmllZCBz b21lIHByb2JsZW1zIHdpdGggdGhlIGFwcHJvYWNoIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDUu MyBvZiB0aGUgZG93bmdyYWRlIGRvY3VtZW50LCBidXQgaXQgc3RpbGwgc2VlbXMgbGlrZSB0 aGUgbW9zdCBwcm9taXNpbmcgYXBwcm9hY2guDQoxMi5UaGUgZWRpdG9yIHdpbGwgdXBkYXRl IGRvd25ncmFkZSBkb2N1bWVudCB0byBpbmNvcnBvcmF0ZSBjdXJyZW50IHV0Zi04aGVhZGVy cyBkb2N1bWVudHMNCjEzLlRoZSBhcHByb2FjaCBvZiB0aGUgc2VjdGlvbiA1LjMgbmVlZHMg bW9yZSBkZXRhaWwgaW5mb3JtYXRpb24uDQoxNC5Tb21lIFJGQzI4MjEgcmVsYXRlZCB0aGlu Z3MgaW4gdGhlIGRvd25ncmFkZSBkb2N1bWVudCBzaG91bGQgYmUgbW92ZWQgdG8gdGhlIHNt dHBleHQgZG9jdW1lbnQuDQpGb3IgSU1BUC9QT1AgZG9jdW1lbnRzDQoxNS5UaGUgSU1BUCBk b2N1bWVudCBtZW50aW9ucyB0aGUgdXBncmFkaW5nLiBUaG9zZSB3aG8gY2FyZSBhYm91dCB1 cGdyYWRpbmcgc2hvdWxkIHJlYWQgdGhhdCBzZWN0aW9uIGNhcmVmdWxseSB0byBjaGVjayB0 aGF0IGl0IHNheXMgd2hhdCB5b3UgdGhpbmsgaXQgc2hvdWxkIHNheS4NCkZvciB0aGUgbWFp bGluZyBsaXN0IGRvY3VtZW50DQoxNi5FZG1vbiBmcm9tIEFmZmlsaWFzIHZvbHVudGVlcnMg dG8gd3JpdGUgdGhlIG1haWxpbmcgbGlzdCBkb2N1bWVudHMNCkltcGxlbWVudGF0aW9uIGFu ZCB0ZXN0aW5nIHBsYW4NCjE3LkNOTklDIHdpbGwgaW1wbGVtZW50IHRoZSBwcm90b3R5cGUg b2YgRUFJIGJhc2VkIG9uIHFtYWlsIGFuZCBoYXMgYSBkZW1vIGluIHRoZSBuZXh0IElFVEYg bWVlaW5nDQoxOC5UV05JQyB3aWxsIGltcGxlbWVudCB0aGUgcHJvdG90eXBlIG9mIEVBSSBi YXNlZCBvbiBzZW5kbWFpbCBhbmQgaGFzIGEgZGVtbyBpbiB0aGUgbmV4dCBJRVRGIG1lZWlu Zw0KMTkuRnVqaXdhcmEgZnJvbSBKUFJTIHdpbGwgdXBkYXRlIHNvbWUgTVVBIHNvZnR3YXJl IHRvIGFsbG93IHV0Zi04IGJhc2VkIGVtYWlsIGFkZHJlc3MuDQoyMC5ZYW5nd29vIEtvLCBG dWppd2FyYSwgRGVscGhpaiBmcm9tIHNpbmEuY29tIGFuZCBMaSBCb2RhIGZyb20gc29odS5j b20gd2lsbCBoZWxwIHNvbWUgaW1wbGVtZW50YXRpb24gYW5kIHRlc3QuIA0KMjEuSW4gdGhl IDY3dGggSUVURiBtZWV0aW5nLCB3ZSBzaG91bGQgaGF2ZSBhIHdvcmthYmxlIHN5c3RlbSBi YXNlZCBvbiB3ZWJtYWlsLg0KDQpUZXJtaW5vbG9naWVzIGlzc3Vlcw0KMjIuUXVlc3Rpb246 IElzIGl0IG9rIHRvIFdvcmsgR3JvdXAgdG8gQ2hhbmdlIG1haWxpbmcgbGlzdCBpbWFAaWV0 Zi5vcmcgaW50byBlYWlAaWV0Zi5vcmc/IA0KQW5zd2VyOiBNb3N0IG9mIGF0dGVuZGVlcyBk byBub3QgYWdyZWUgdGhhdCB0aGUgY2hhbmdlIGlzIG5lZWRlZCwgYnV0IG5vYm9keSBvYmpl Y3RzIHRvIGxldCBlYWlAaWV0Zi5vcmcgYmUgYW4gYWxpYXMgb2YgaW1hQGlldGYub3JnLg0K MjMuVGVybWlub2xvZ2llcyBPcHRpb24gOiBJbiB0aGUgcGFzdCwgbXVsdGlwbGUgc2hvcnQg bmFtZXMgaGF2ZSBiZWVuIHVzZWQgZm9yIHRoaXMgZWZmb3J0OiBFQUksIEktZW1haWwgLCBp MThuZW1haWwsIHV0ZjhlbWFpbCwgZW1haWxpbmcsIElNWCwgSU1BRSwgdXRmOHNtdHAsIGlz bXRwLiBUaGUgV0cgbmVlZHMgdG8gZGVjaWRlIG9uIG9uZTsgaW4gdGhlIGFic2VuY2Ugb2Yg Y29tcGVsbGluZyB0ZWNobmljYWwgYXJndW1lbnRzIGZvciBvbmUgb3IgdGhlIG90aGVyLCB0 aGUgbWVldGluZyBkZWNpZGVkIHRvIHRha2UgYSBzdHJhdyBwb2xsIHRvIGdldCBhIGRlY2lz aW9uIHRvIHByZXNlbnQgdG8gdGhlIG1haWxpbmcgbGlzdC4NCkluIHRoZSBmaXJzdCByb3Vu ZCwgdGhlIHJlc3VsdCBpcyAodGhlIG51bWJlciBvZiBzdXBwb3J0ZXJzIGluIHRoZSBicmFj a2V0KQ0KVXRmOHNtdHAoNCksIGkxOG5lbWFpbCg0KSwgdXRmOGVtYWlsKDEpLCAgSU1YKDEp LCBJTUFFKDEpLCBpc210cA0KSW4gdGhlIHNlY29uZCByb3VuZCB2b3RpbmcgZm9yIHRoZSB0 d28gZmF2b3I6IFV0ZjhzbXRwLCBpMThuZW1haWwuIHRoZSByZXN1bHQgaXMgDQpVdGY4c210 cCg1KSwgaTE4bmVtYWlsKDMpDQogICAgVGhlIFdHIG1lZXRpbmcgcmVjb21tZW5kcyB0aGF0 ICJVVEY4U01UUCIgc2hvdWxkIGJlIHVzZWQgZm9yIHRoaXMgdGVjaG5vbG9neSwgYnV0IHRo ZSBmaW5hbCBkZWNpc2lvbiBzaG91bGQgZ28gdG8gdGhlIG1haWxpbmcgbGlzdC4NCjI0LlRl cm1pbm9sb2d5IGZvciB2YXJpb3VzIHR5cGVzIG9mIEVtYWlsIGFkZHJlc3MNCmFzY2lpQGFz Y2lpIG1lYW5zIHRoZSBwdXJlIGFzY2lpIGVtYWlsIGFkZHJlc3MNCk5vbi1hc2NpaSBlbWFp bCBhZGRyZXNzIG1lYW5zIHRoYXQgdGhlcmUgaXMgYXQgbGVhc3QgYSBub24tYXNjaWkgY2hh cmFjdGVyIGluIHRoZSBlbWFpbCBhZGRyZXNzLCBpbmNsdWRpbmcgdGhlIGJlbG93IDMgY2F0 ZWdvcmllczoNCk5vbi1hc2NpaUBOb24tYXNjaWkNCmFzY2lpQE5vbi1hc2NpaQ0KTm9uLWFz Y2lpQGFzY2lpIA0KSWYgYWx0LWFkZHJlc3MgaXMgc3BlY2lmaWVkIGJ5IHRoZSBzZW5kZXIs IGl0IHNob3VsZCBiZSBuYW1lZCBhcyB0aGUgc2VuZGVyLXNwZWNpZmllZCBhc2NpaSBhZGRy ZXNzOw0KSWYgdGhlIGVtYWlsIGFkZHJlc3MgaXMgZ2VuZXJhdGVkIGZyb20gYSBub24tQVND SUkgYWRkcmVzcyBieSBzb21lIGFsZ29yaXRobWljIGZ1bmN0aW9uLCBpdCBzaG91bGQgYmUg bmFtZWQgYXMgdGhlIGFsZ29yaXRobWljIGFzY2lpIGFkZHJlc3MNCg0KT3BlbiBpc3N1ZXM6 DQoyNS5UaGluZ3MgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJlZCBidXQgd2Ugc3RpbGwgZG9u J3Qga25vdyB0aGUgYW5zd2VyLiANCjEpV2hlbiBhbmQgaG93IG11Y2ggdXNlZnVsIGRvd25n cmFkaW5nIHdpbGwgYmUuDQoyKVJhbmdlIG9mIGNoYXJhY3RlcnMgcGVybWl0dGVkIGluIGFk ZHJlc3NlcyBhbmQgd2hldGhlci9ob3cgbm9ybWFsaXplZA0KMjYuSWYgYW4gYWx0LWFkZHJl c3MgaXMgc3BlY2lmaWVkIGFuZCBtdXN0IGJlIHVzZWQgaW4gZG93bmdyYWRpbmcsIGJ1dCB0 aGUgaG9zdCBhdCB0aGUgYWx0LWFkZHJlc3MgZG9tYWluIGFkdmVydGl6ZXMgdGhlIFNNVFAg ZXh0ZW5zaW9uLCB0aGUgYWx0LWFkZHJlc3MgTVVTVCBzdGlsbCBiZSB1c2VkLCBidXQgdGhl IFVURjggaGVhZGVycyBTSE9VTEQgTk9UIGJlIGRvd25ncmFkZWQuDQoyNy5UaGUgbWVldGlu ZyBkaXNjdXNzZWQgd2hpY2ggYWRkaXRpb25hbCBkb2N1bWVudHMgdG8gdGhlIG9uZXMgbGlz dGVkIGluIHRoZSBjdXJyZW50IFdHIGNoYXJ0ZXIgd2VyZSBuZWVkZWQuDQpUaGUgbW9zdCBp bXBvcnRhbnQgb25lIHdhcyB0aG91Z2h0IHRvIGJlIE9wZXJhdGlvbmFsIGd1aWRlbGluZXMg LS13aGljaCBpbmNsdWRlcyBzdWdnZXN0aW9ucyB0byBTTVRQIGRlbGl2ZXJ5IHNpdGUgbWFp bnRhaW5lcnMgYXMgdG8gaG93IHRvIGNyZWF0ZSBuYW1lcyAtLSB0aGV5IGJlY29tZSB2ZXJ5 IGltcG9ydGFudCBpZiB3ZSBhdm9pZCBtb3N0IG9yIGFsbCBjYW5vbmljYWxpemF0aW9uIGFu ZCBwcmVwYXJhdGlvbiBzcGVjaWZpY2F0aW9ucyBpbiBTTVRQIGJ1dCBkdW1wIHRoYXQgcHJv YmxlbSBvbiBkZWxpdmVyeSBzeXN0ZW0gZGVjaXNpb25zIGFib3V0IG5hbWluZy4gVGhhdCBj bGVhcmx5IGludGVyYWN0cyB3aXRoIHRoZSBTQVNMUHJlcCAob3Igd2hhdGV2ZXIpIGlzc3Vl cyANCg0KVGhlIG1lZXRpbmcgd2FzIGNsb3NlZCBhdCAxNzozNSBbR01UKzg6MDBdLg0KDQo= --------------060503050005070208070801 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 --------------060503050005070208070801-- From ima-bounces@ietf.org Wed Jun 14 12:06:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXtJ-00082B-PF; Wed, 14 Jun 2006 12:06:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXtI-000826-7E for ima@ietf.org; Wed, 14 Jun 2006 12:06:48 -0400 Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXtF-0000gf-Qb for ima@ietf.org; Wed, 14 Jun 2006 12:06: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]:34241) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1FqXsv-0003kg-3i (Exim 4.54) for ima@ietf.org (return-path ); Wed, 14 Jun 2006 17:06:25 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FqXsu-0000ox-O3 (Exim 4.53) for ima@ietf.org (return-path ); Wed, 14 Jun 2006 17:06:24 +0100 Date: Wed, 14 Jun 2006 17:06:24 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ima@ietf.org Subject: Re: [EAI] Minutes about EAI Interim Meeting in Beijing In-Reply-To: <350294707.16087@cnnic.cn> Message-ID: References: <350294707.16087@cnnic.cn> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > EAI WG Interim Meeting Minutes > ******************************* > > 3.There are still some scenarios that we may consider in the document. > These include scenarios that involve communication between two > EAI-compliant users connected via an infrastructure with one or more > non-EAI-compatible elements. There was no consensus on whether these > scenarios are necessary to support. If this is *not* required, then the alt-address and atomic parameters are not needed on RCPT commands. There are three scenarios: (1) All recipients are i14ed. No downgrading required. (2) The message is only sent to ascii recipient(s). Only the return path needs to be downgraded. (3) The message is sent to a mixture of recipients. When the message gets to a point where downgrading is required (for transmission to one or more ascii recipients), the i14ed recipients do not need to be downgraded because they will not appear in the next hop's envelope, so again only the return path needs to be upgraded. In (2) and (3), addresses in the message header will need to be downgraded, but that can only be done using information in the header because the envelope will not in general have all the information required. > 4.In this document, ALT-ADDR and ATOMIC are mutually exclusive. Most > attendees agreed that ALT-ADDR and ATOMIC should be exclusive. Why not pass the "atomic" flag around in the form of a pre-downgraded alt-address? This reduces the number of options that are required and eliminates the need for a global local-part downgrading algorithm - i.e. it would preserve the localness of local parts. Tony. -- f.a.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT: NORTHEAST 4 OR 5, OCCASIONALLY 6 AT FIRST. THUNDERY SHOWERS. MODERATE OR GOOD, BECOMING POOR AT TIMES. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 15 05:57:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqob8-0007u8-FY; Thu, 15 Jun 2006 05:57:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqob7-0007s7-Hf for ima@ietf.org; Thu, 15 Jun 2006 05:57:09 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqob6-0008R4-3N for ima@ietf.org; Thu, 15 Jun 2006 05:57:09 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 482B82596F6; Thu, 15 Jun 2006 11:56:04 +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 32453-04; Thu, 15 Jun 2006 11:55:25 +0200 (CEST) Received: from [172.28.60.169] (unknown [62.92.16.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id DAC192596DF; Thu, 15 Jun 2006 11:55:24 +0200 (CEST) Message-ID: <44912ECE.6070600@alvestrand.no> Date: Thu, 15 Jun 2006 11:56:30 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Tony Finch Subject: Re: [EAI] Minutes about EAI Interim Meeting in Beijing References: <350294707.16087@cnnic.cn> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Tony Finch wrote: >> EAI WG Interim Meeting Minutes >> ******************************* >> >> 3.There are still some scenarios that we may consider in the document. >> These include scenarios that involve communication between two >> EAI-compliant users connected via an infrastructure with one or more >> non-EAI-compatible elements. There was no consensus on whether these >> scenarios are necessary to support. >> > > If this is *not* required, then the alt-address and atomic parameters are > not needed on RCPT commands. There are three scenarios: > > (1) All recipients are i14ed. No downgrading required. > Scenarios document, section 2.1 and 2.2 > (2) The message is only sent to ascii recipient(s). Only the return path > needs to be downgraded. > Scenarios document, section 2.4 > (3) The message is sent to a mixture of recipients. When the message gets > to a point where downgrading is required (for transmission to one or more > ascii recipients), the i14ed recipients do not need to be downgraded > because they will not appear in the next hop's envelope, so again only > the return path needs to be upgraded. > Scenarios document, section 2.5. The sender's address may need to be downgraded. > In (2) and (3), addresses in the message header will need to be > downgraded, but that can only be done using information in the header > because the envelope will not in general have all the information > required. > Agreed. > >> 4.In this document, ALT-ADDR and ATOMIC are mutually exclusive. Most >> attendees agreed that ALT-ADDR and ATOMIC should be exclusive. >> > > Why not pass the "atomic" flag around in the form of a pre-downgraded > alt-address? This reduces the number of options that are required and > eliminates the need for a global local-part downgrading algorithm - > i.e. it would preserve the localness of local parts. isn't that the same as requiring that the alt-address be present always? _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 15 06:20:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqoxc-0003ko-En; Thu, 15 Jun 2006 06:20:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqoxb-0003kj-Jj for ima@ietf.org; Thu, 15 Jun 2006 06:20:23 -0400 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqoxZ-0002p3-9s for ima@ietf.org; Thu, 15 Jun 2006 06:20: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]:34652) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1FqoxD-0007Zd-22 (Exim 4.54) (return-path ); Thu, 15 Jun 2006 11:19:59 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FqoxD-00059Z-IZ (Exim 4.53) (return-path ); Thu, 15 Jun 2006 11:19:59 +0100 Date: Thu, 15 Jun 2006 11:19:59 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Harald Alvestrand Subject: Re: [EAI] Minutes about EAI Interim Meeting in Beijing In-Reply-To: <44912ECE.6070600@alvestrand.no> Message-ID: References: <350294707.16087@cnnic.cn> <44912ECE.6070600@alvestrand.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Tony Finch , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 15 Jun 2006, Harald Alvestrand wrote: > Tony Finch wrote: > > > > > > If this is *not* required, then the alt-address and atomic parameters are > > not needed on RCPT commands. There are three scenarios: [snip] > > Scenarios document, [...] Indeed. I was attempting to make points that aren't already covered there. > The sender's address may need to be downgraded. Er yes, that's what I meant - typo! > > Why not pass the "atomic" flag around in the form of a pre-downgraded > > alt-address? This reduces the number of options that are required and > > eliminates the need for a global local-part downgrading algorithm - > > i.e. it would preserve the localness of local parts. > > isn't that the same as requiring that the alt-address be present always? A missing sender alt-address would indicate an un-downgradable message. Tony. -- f.a.n.finch http://dotat.at/ BAILEY: FAEROES SOUTHEAST ICELAND SOUTH VEERING SOUTHWEST 5 OR 6, INCREASING 7 FOR A TIME. OCCASIONAL RAIN OR DRIZZLE. MODERATE OR GOOD, BECOMING POOR AT TIMES. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 15 07:14:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqpoJ-0002JH-Qz; Thu, 15 Jun 2006 07:14:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqpoI-0002J5-KH for ima@ietf.org; Thu, 15 Jun 2006 07:14:50 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqpoF-0007zf-TT for ima@ietf.org; Thu, 15 Jun 2006 07:14:50 -0400 Received: from host81-144-65-76.midband.mdip.bt.net ([81.144.65.76] country=GB) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.222) id 44914120.fc86.1a3 for ima@ietf.org; Thu, 15 Jun 2006 12:14:40 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (gmrs-tacacs [192.168.0.2]) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k5F9hoq01345 for ; Thu, 15 Jun 2006 10:43:50 +0100 (BST) 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 k5F9U0Qj007905 for ; Thu, 15 Jun 2006 10:30:00 +0100 (BST) Date: Thu, 15 Jun 2006 10:30:00 +0100 From: "Charles Lindsey" To: ima@ietf.org Subject: Re: [EAI] Minutes about EAI Interim Meeting in Beijing References: <350294707.16087@cnnic.cn> Message-ID: In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 14 Jun 2006 17:06:24 +0100, Tony Finch wrote: >> 4.In this document, ALT-ADDR and ATOMIC are mutually exclusive. Most >> attendees agreed that ALT-ADDR and ATOMIC should be exclusive. > > Why not pass the "atomic" flag around in the form of a pre-downgraded > alt-address? This reduces the number of options that are required and > eliminates the need for a global local-part downgrading algorithm - > i.e. it would preserve the localness of local parts. > Yes, that's the obvious way to do it when you think about it, especially as it avoids the yet-unsolved problem of how to indicate ATOMICITY in the syntax of a mailbox. Even if we manage to incorporate the ALT_ADDRESS in that syntax (and means to do that using a ",", "|" or somesuch as a separator have beed discussed), there will still remain the problem of revising the mailto URL so that it can specify both the UTF8 and ALT addresses. And hacking the mailto URL to indicate ATOMICITY would be even uglier. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Jun 15 10:18:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqsgG-0004e2-F8; Thu, 15 Jun 2006 10:18:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqsgF-0004dx-4x for ima@ietf.org; Thu, 15 Jun 2006 10:18:43 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqsgD-0002RV-R1 for ima@ietf.org; Thu, 15 Jun 2006 10:18:43 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 81B422596DF; Thu, 15 Jun 2006 16:17:37 +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 06290-02; Thu, 15 Jun 2006 16:17:34 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E95072596DC; Thu, 15 Jun 2006 16:17:33 +0200 (CEST) Message-ID: <44916C3D.5090505@alvestrand.no> Date: Thu, 15 Jun 2006 07:18:37 -0700 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Charles Lindsey Subject: Re: [EAI] Minutes about EAI Interim Meeting in Beijing References: <350294707.16087@cnnic.cn> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > On Wed, 14 Jun 2006 17:06:24 +0100, Tony Finch wrote: > >>> 4.In this document, ALT-ADDR and ATOMIC are mutually exclusive. Most >>> attendees agreed that ALT-ADDR and ATOMIC should be exclusive. >> >> Why not pass the "atomic" flag around in the form of a pre-downgraded >> alt-address? This reduces the number of options that are required and >> eliminates the need for a global local-part downgrading algorithm - >> i.e. it would preserve the localness of local parts. >> > Yes, that's the obvious way to do it when you think about it, > especially as it avoids the yet-unsolved problem of how to indicate > ATOMICITY in the syntax of a mailbox. > > Even if we manage to incorporate the ALT_ADDRESS in that syntax (and > means to do that using a ",", "|" or somesuch as a separator have beed > discussed), there will still remain the problem of revising the mailto > URL so that it can specify both the UTF8 and ALT addresses. And > hacking the mailto URL to indicate ATOMICITY would be even uglier. I saw one proposal that went or - not much uglier; you can tell the 2 apart by the absence of the @-sign. I don't like the term "atomic" all that much, but that's another issue, and not that important. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 15 11:58:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquEn-0003qH-UG; Thu, 15 Jun 2006 11:58:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquEm-0003qB-HY for ima@ietf.org; Thu, 15 Jun 2006 11:58:28 -0400 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FquEj-0005DV-8B for ima@ietf.org; Thu, 15 Jun 2006 11:58:28 -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]:57313) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1FquEc-0007hv-05 (Exim 4.54) (return-path ); Thu, 15 Jun 2006 16:58:18 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FquEa-0004Fs-TB (Exim 4.53) (return-path ); Thu, 15 Jun 2006 16:58:16 +0100 Date: Thu, 15 Jun 2006 16:58:16 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Harald Alvestrand Subject: Re: [EAI] Minutes about EAI Interim Meeting in Beijing In-Reply-To: <44916C3D.5090505@alvestrand.no> Message-ID: References: <350294707.16087@cnnic.cn> <44916C3D.5090505@alvestrand.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Charles Lindsey , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 15 Jun 2006, Harald Alvestrand wrote: > I saw one proposal that went or - > not much uglier; you can tell the 2 apart by the absence of the @-sign. draft-ietf-eai-utf8headers-00 currently specifies "," as the separator within the angle-addr. I'm not sure this is an entirely wise choice given the existing meaning of "," and the way broken software mangles message headers. > I don't like the term "atomic" all that much, but that's another issue, and > not that important. "ACE-downgrade" would be a better term. Tony. -- f.a.n.finch http://dotat.at/ ARDNAMURCHAN POINT TO CAPE WRATH INCLUDING THE OUTER HEBRIDES: SOUTH OR SOUTHWEST 3 OR 4, OCCASIONALLY 5 IN THE NORTH. RAIN AT TIMES. MODERATE OR GOOD, OCCASIONALLY POOR, MAINLY IN THE NORTH. SLIGHT OR MODERATE, OCCASIONALLY ROUGH WEST OF THE OUTER HEBRIDES. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 16 14:13:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIp2-0007UT-7n; Fri, 16 Jun 2006 14:13:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIp0-0007UG-EE for ima@ietf.org; Fri, 16 Jun 2006 14:13:30 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrIox-0007PR-IV for ima@ietf.org; Fri, 16 Jun 2006 14:13:30 -0400 Received: from host81-144-65-135.midband.mdip.bt.net ([81.144.65.135] country=GB) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.222) id 4492f4c0.b42e.7ce; Fri, 16 Jun 2006 19:13:20 +0100 (envelope-sender ) Received: (from chl@localhost) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) id k5GI2UR18806; Fri, 16 Jun 2006 19:02:30 +0100 (BST) 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 k5FGiBFM006541; Thu, 15 Jun 2006 17:44:12 +0100 (BST) To: "Tony Finch" , "Harald Alvestrand" Subject: Re: [EAI] Minutes about EAI Interim Meeting in Beijing References: <350294707.16087@cnnic.cn> <44916C3D.5090505@alvestrand.no> Message-ID: Date: Thu, 15 Jun 2006 17:44:11 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 15 Jun 2006 16:58:16 +0100, Tony Finch wrote: > On Thu, 15 Jun 2006, Harald Alvestrand wrote: > >> I saw one proposal that went or >> - >> not much uglier; you can tell the 2 apart by the absence of the @-sign. Yes, that would be a reasonable notation. One could put either "atomic" in there, or the actual ACE-ed address, with the same meaning. > > draft-ietf-eai-utf8headers-00 currently specifies "," as the separator > within the angle-addr. I'm not sure this is an entirely wise choice given > the existing meaning of "," and the way broken software mangles message > headers. Yes, I would much prefer "|". I have already pointed out that it is unambiguous and parsable provided the syntax of the ALT-ADDRESS is restricted to the RFC 2821 address syntrax, rather than the full from RFC 2822. > >> I don't like the term "atomic" all that much, but that's another issue, >> and >> not that important. > > "ACE-downgrade" would be a better term. "downgradable"? -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Jun 16 14:13:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIp2-0007UT-7n; Fri, 16 Jun 2006 14:13:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIp0-0007UG-EE for ima@ietf.org; Fri, 16 Jun 2006 14:13:30 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrIox-0007PR-IV for ima@ietf.org; Fri, 16 Jun 2006 14:13:30 -0400 Received: from host81-144-65-135.midband.mdip.bt.net ([81.144.65.135] country=GB) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.222) id 4492f4c0.b42e.7ce; Fri, 16 Jun 2006 19:13:20 +0100 (envelope-sender ) Received: (from chl@localhost) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) id k5GI2UR18806; Fri, 16 Jun 2006 19:02:30 +0100 (BST) 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 k5FGiBFM006541; Thu, 15 Jun 2006 17:44:12 +0100 (BST) To: "Tony Finch" , "Harald Alvestrand" Subject: Re: [EAI] Minutes about EAI Interim Meeting in Beijing References: <350294707.16087@cnnic.cn> <44916C3D.5090505@alvestrand.no> Message-ID: Date: Thu, 15 Jun 2006 17:44:11 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 15 Jun 2006 16:58:16 +0100, Tony Finch wrote: > On Thu, 15 Jun 2006, Harald Alvestrand wrote: > >> I saw one proposal that went or >> - >> not much uglier; you can tell the 2 apart by the absence of the @-sign. Yes, that would be a reasonable notation. One could put either "atomic" in there, or the actual ACE-ed address, with the same meaning. > > draft-ietf-eai-utf8headers-00 currently specifies "," as the separator > within the angle-addr. I'm not sure this is an entirely wise choice given > the existing meaning of "," and the way broken software mangles message > headers. Yes, I would much prefer "|". I have already pointed out that it is unambiguous and parsable provided the syntax of the ALT-ADDRESS is restricted to the RFC 2821 address syntrax, rather than the full from RFC 2822. > >> I don't like the term "atomic" all that much, but that's another issue, >> and >> not that important. > > "ACE-downgrade" would be a better term. "downgradable"? -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Jun 16 14:13:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIp2-0007UZ-BE; Fri, 16 Jun 2006 14:13:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIp0-0007UM-Pf for ima@ietf.org; Fri, 16 Jun 2006 14:13:30 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrIox-0007PU-IV for ima@ietf.org; Fri, 16 Jun 2006 14:13:30 -0400 Received: from host81-144-65-135.midband.mdip.bt.net ([81.144.65.135] country=GB) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.222) id 4492f4c4.b42e.7d0 for ima@ietf.org; Fri, 16 Jun 2006 19:13:24 +0100 (envelope-sender ) Received: (from chl@localhost) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) id k5GI2pl18824; Fri, 16 Jun 2006 19:02:51 +0100 (BST) 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 k5FKt9lN022719 for ; Thu, 15 Jun 2006 21:55:09 +0100 (BST) To: "ima@ietf.org" Date: Thu, 15 Jun 2006 21:55:07 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Subject: [EAI] Comments on draft-ietf-eai-downgrading.00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Downgrading mechanism for Internationalized eMail Address (IMA) s/IMA/EAI (or whatever)/ in lots of places. Abstract Traditional mail system handles only US-ASCII characters in SMTP envelope and mail headers. ..... There are lots of places where you have used the singular where the plural would be better. E.g. s/system/systems/ and s/envelope/envelopes/. Generally speaking, if a word is in the singular it needs to have an article ("the" or "a") in front of it. I would suggest you have it checked by a native English speaker (or you can contact me offline). I won't go into all the cases here, but it does need attending to at some point. 1. Introduction .... Not only SMTP envelope, but also UTF-8 in mail headers MUST be converted to US-ASCII. Also, "body part headers", which occur in MIME multiparts and message/rfc822, need to be converted. 2. Terminology The final ("delivery") MTA stores Mail messages in a "message store" or resends messages where the receiver has assigned. In this document, this function is called Mail Delivery Agent(MDA). Traditionally, the IETF has steered clear of the interface between the final MTA and the MDA, because there is presumed to be no "wire" between them. However, they are often completely separate pieces of software, and a single MTA might send the message to one of several MDAs, according to the . So, even if the MTA advertised IEmail, some of those MDAs might still be ASCII-only. So the MTA needs to be aware of which those might be, so that it can still downgrade or bounce the message (even if it has already accepted in in IEmail form). So there needs to be some interface between MTAs and MDAs for sorting this out. Whether the WG wants to specify such an interface in detail is another matter - probably not - but it needs to be aware of the problem, and to have some model in mind of how such a thing would function. Possibly the overview document is the place to discuss this, but it might also need some mention here. 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. 3. Downgrade Requirements 3.1. Timing and conditions of downgrading o Conditions: SMTP client detects that UTF-8 is included in SMTP envelope or mail headers. or in "body part headers". Checking for the presence of the I18Mail header (for Header-Content header, or whatever we call it) should be sufficient. 3.2. Requirements 2. Upgrading must be performed at minimized place such as final destination like recipient MUA. I think the proper thing to say is that upgrading MUST NOT take place until the message reaches someplace where it is legitimate to examine the , and that means the destination MTA at the earliest. Even then, it SHOULD ONLY be the that is upgraded (if necessary) in order to derermine which MDA to give it to. The MDA MAY upgrade it (should be under user control), but ideally it should be left to the MUA after the MDA has finally passed it over. 4. SMTP Downgrading I think you need to point out that this section only applies if the transport method is SMTP (or one of its relations such as LMTP). If some different transport (e.g. UUCP) is used, then similar changes _may_ be needed but are not specified here. OTOH, your section 5 on header downgrading is likely to be needed even if other transports are used. 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. 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. 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--"). 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. 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-Downgraded-To: 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 in" 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. 3. Downgrade Requirements 3.1. Timing and conditions of downgrading o Conditions: SMTP client detects that UTF-8 is included in SMTP envelope or mail headers. or in "body part headers". Checking for the presence of the I18Mail header (for Header-Content header, or whatever we call it) should be sufficient. 3.2. Requirements 2. Upgrading must be performed at minimized place such as final destination like recipient MUA. I think the proper thing to say is that upgrading MUST NOT take place until the message reaches someplace where it is legitimate to examine the , and that means the destination MTA at the earliest. Even then, it SHOULD ONLY be the that is upgraded (if necessary) in order to derermine which MDA to give it to. The MDA MAY upgrade it (should be under user control), but ideally it should be left to the MUA after the MDA has finally passed it over. 4. SMTP Downgrading I think you need to point out that this section only applies if the transport method is SMTP (or one of its relations such as LMTP). If some different transport (e.g. UUCP) is used, then similar changes _may_ be needed but are not specified here. OTOH, your section 5 on header downgrading is likely to be needed even if other transports are used. 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. 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. 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--"). 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. 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-Downgraded-To: 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. Downgraded envelope to is parsed only in MDA and delivered to final mailbox. Actually, I don't think anyone cares whether some intermediate agent parses the domain part (in IDNA) of an envelope address. But parsing the local-part of such an address is a definite No-No until you get to the final MTA. So maybe s/envelope/local-part/ in there. 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. 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 :-( . 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. 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). 5.3. Header conversion Each header has its own downgrading method. Basically, MIME encoding of RFC 2047. Recipient/Sender addresses and Received headers which may contain IMA need special processing. I think we need to be careful to cover every possible header here, including all the headers already defined in all sorts of standards, plus all the ones which are going to be defined in future standards. I think the first thing it to separate them into 'structured' and 'unstructured' headers. That actually gives you three cases to consider: 1. Known strutured headers. As so defined in RFC 2822, all the MIME standards, maybe the List-* standards, and possibly others. So either you need to give a list of all the RFCs, or else a complete list of headers. There is a general rule how to downgrade comments and phrases in these headers (using RFC 2047). After that, some of them will be "UTF-8 forbidden" (the utf8headers document should say which), so no further downgrade will be needed. For the rest, you can give explicit rules for dealing with addr-specs MIME-style parameters (use RFC 2231) IRIs Received (possibly) and so on 2. Known unstructured headers. Again, as defined in RFC 2822 and other places. The Subject header is the best known example, but there are others (some, such as Organization and Summary not defined in mail standards at all, but still widely used). You should also say that any header whose name begins with "X-" is to be considerd unstructured. The downgrade method is, of course, straightforward RFC 2047. 3. Structured state unknown. These are the real problem. People have been inventing new email headers at the rate of half-a-dozen a year for as long as anyone can remember, and there is no reason to suppose it is going to stop. Anyone inventing such a header in future is welcome to state whether it is structured, and if so whether utf-8 is to be allowed within it. He can even proposes an explicit downgrade method for his new header, and people mighdicated in those headers somewhere. OTOH, I am not yet convinced that we actually needs those headers at all. Downgraded envelope to is parsed only in MDA and delivered to final mailbox. Actually, I don't think anyone cares whether some intermediate agent parses the domain part (in IDNA) of an envelope address. But parsing the local-part of such an address is a definite No-No until you get to the final MTA. So maybe s/envelope/local-part/ in there. 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. 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 :-( . 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. 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). 5.3. Header conversion Each header has its own downgrading method. Basically, MIME encoding of RFC 2047. Recipient/Sender addresses and Received headers which may contain IMA need special processing. I think we need to be careful to cover every possible header here, including all the headers already defined in all sorts of standards, plus all the ones which are going to be defined in future standards. I think the first thing it to separate them into 'structured' and 'unstructured' headers. That actually gives you three cases to consider: 1. Known strutured headers. As so defined in RFC 2822, all the MIME standards, maybe the List-* standards, and possibly others. So either you need to give a list of all the RFCs, or else a complete list of headers. There is a general rule how to downgrade comments and phrases in these headers (using RFC 2047). After that, some of them will be "UTF-8 forbidden" (the utf8headers document should say which), so no further downgrade will be needed. For the rest, you can give explicit rules for dealing with addr-specs MIME-style parameters (use RFC 2231) IRIs Received (possibly) and so on 2. Known unstructured headers. Again, as defined in RFC 2822 and other places. The Subject header is the best known example, but there are others (some, such as Organization and Summary not defined in mail standards at all, but still widely used). You should also say that any header whose name begins with "X-" is to be considerd unstructured. The downgrade method is, of course, straightforward RFC 2047. 3. Structured state unknown. These are the real problem. People have been inventing new email headers at the rate of half-a-dozen a year for as long as anyone can remember, and there is no reason to suppose it is going to stop. Anyone inventing such a header in future is welcome to state whether it is structured, and if so whether utf-8 is to be allowed within it. He can even proposes an explicit downgrade method for his new header, and people might even implement his method. The problem is that, once people have implemented our new protocol, they are not going to rewrite their software every time someone brings out a new header (maybe with new downgrade rules). This is exactly the problem that RFC 2047 ran into, because it assumes that, as soon as a new standard specifies a new header, all the MIME software in the world will immediately and magically "know" whether this new header is unstructured or not and use (or not use) RFC 2047 encoding within it accordingly. The result has been that all sorts of implementations for 2047 encoding of headers where they should not be doing it, and vice versa. So let us try to avoid that trap. I therefore propose a "generic" downgrade method, to be used on all headers whose state is unknown: Downgraded: Header-Name: {RFC encoded form of original header body} (just like your section 5.4, in fact). This is always safe; it works whether the header in question is structured or unstructured; it is easily upgraded; and it will do no harm whatsoever SO LONG AS that header plays no part in the transport process (which is likely to be the case - most new headers are for human consumption, or for use by specific gateways, etc). The only snag is that it might not always suit the intention of the author of the new header (who might have preferred you to use his own specially devised downgrade). Tough! He will just have to define his new protocol so that it can get around the use of this generic downgrade by MTAs that were written long before he came on the scene. As to the specific rules we need for addr-specs in presently known headers, I think we know how we intend to do it. I would suggest repeating the table I gave earlier showing how to deal with various combinations of ALT-ADDRESS and ATOMIC, and after that the details are very similar to the envelope procedures. I have mentioned IRIs as a special case, because all the headers which currently have URIs in them are surely going to be upgraded to use IRIs before long (indeed, we could include such changes in our utf8headers document if we so decided). Moreover, there is already a defined way to downgrade an IRI to a URI, so we may as well use it. And finally, the downgrade process should include instructions to remove/modify/whatever the I18MAIL header (or whatever it gets called - I still prefer the Header-Content header that I mentioned a week or so back, and which would need to be modified to shown that downgrading had taken place). And finally finally there is still the matter of downgrading "body part headers", as I mentioned earlier. 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? IMA compliant MUA MUST decode downgraded mail and MUST show IMA on display. s/decode downgraded/upgrade/ But I am not sure this is really a MUST (is any interoperability broken?). SHOULD by all means. 6.2. MDA Requirements 1. MDA MUST NOT convert downgraded header to UTF-8. Why not? Indeed, the new imap draft proposes to do just that (under user's control, of course). 2. Record Return-Path header in ACE form. This might not be possible (the MAIL FROM: may have been downgraded to an ALT-ADDRESS en route, and all trace of the UTF8 form of it may have been lost). 3. Perform downgrading for each Storage/Back-end-Process. If and only if MDA knows MUA is IMA compliant, then no downgrading is performed. What is this for? I assume this is a compliant MDA. Or did you mean _up_grading? 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 st even implement his method. The problem is that, once people have implemented our new protocol, they are not going to rewrite their software every time someone brings out a new header (maybe with new downgrade rules). This is exactly the problem that RFC 2047 ran into, because it assumes that, as soon as a new standard specifies a new header, all the MIME software in the world will immediately and magically "know" whether this new header is unstructured or not and use (or not use) RFC 2047 encoding within it accordingly. The result has been that all sorts of implementations for 2047 encoding of headers where they should not be doing it, and vice versa. So let us try to avoid that trap. I therefore propose a "generic" downgrade method, to be used on all headers whose state is unknown: Downgraded: Header-Name: {RFC encoded form of original header body} (just like your section 5.4, in fact). This is always safe; it works whether the header in question is structured or unstructured; it is easily upgraded; and it will do no harm whatsoever SO LONG AS that header plays no part in the transport process (which is likely to be the case - most new headers are for human consumption, or for use by specific gateways, etc). The only snag is that it might not always suit the intention of the author of the new header (who might have preferred you to use his own specially devised downgrade). Tough! He will just have to define his new protocol so that it can get around the use of this generic downgrade by MTAs that were written long before he came on the scene. As to the specific rules we need for addr-specs in presently known headers, I think we know how we intend to do it. I would suggest repeating the table I gave earlier showing how to deal with various combinations of ALT-ADDRESS and ATOMIC, and after that the details are very similar to the envelope procedures. I have mentioned IRIs as a special case, because all the headers which currently have URIs in them are surely going to be upgraded to use IRIs before long (indeed, we could include such changes in our utf8headers document if we so decided). Moreover, there is already a defined way to downgrade an IRI to a URI, so we may as well use it. And finally, the downgrade process should include instructions to remove/modify/whatever the I18MAIL header (or whatever it gets called - I still prefer the Header-Content header that I mentioned a week or so back, and which would need to be modified to shown that downgrading had taken place). And finally finally there is still the matter of downgrading "body part headers", as I mentioned earlier. 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? IMA compliant MUA MUST decode downgraded mail and MUST show IMA on display. s/decode downgraded/upgrade/ But I am not sure this is really a MUST (is any interoperability broken?). SHOULD by all means. 6.2. MDA Requirements 1. MDA MUST NOT convert downgraded header to UTF-8. Why not? Indeed, the new imap draft proposes to do just that (under user's control, of course). 2. Record Return-Path header in ACE form. This might not be possible (the MAIL FROM: may have been downgraded to an ALT-ADDRESS en route, and all trace of the UTF8 form of it may have been lost). 3. Perform downgrading for each Storage/Back-end-Process. If and only if MDA knows MUA is IMA compliant, then no downgrading is performed. What is this for? I assume this is a compliant MDA. Or did you mean _up_grading? 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. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Jun 16 17:46:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrM9U-0004ZO-OO; Fri, 16 Jun 2006 17:46:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrM9U-0004ZI-4q for ima@ietf.org; Fri, 16 Jun 2006 17:46:52 -0400 Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrM9S-00067J-RO for ima@ietf.org; Fri, 16 Jun 2006 17:46:52 -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]:49484) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1FrM9P-0008RG-Td (Exim 4.54) (return-path ); Fri, 16 Jun 2006 22:46:47 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FrM9O-00063L-3y (Exim 4.53) (return-path ); Fri, 16 Jun 2006 22:46:46 +0100 Date: Fri, 16 Jun 2006 22:46:46 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Charles Lindsey Subject: Re: [EAI] Minutes about EAI Interim Meeting in Beijing In-Reply-To: Message-ID: References: <350294707.16087@cnnic.cn> <44916C3D.5090505@alvestrand.no> 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 15 Jun 2006, Charles Lindsey wrote: > On Thu, 15 Jun 2006 16:58:16 +0100, Tony Finch wrote: > > > > draft-ietf-eai-utf8headers-00 currently specifies "," as the separator > > within the angle-addr. I'm not sure this is an entirely wise choice given > > the existing meaning of "," and the way broken software mangles message > > headers. > > Yes, I would much prefer "|". I have already pointed out that it is > unambiguous and parsable provided the syntax of the ALT-ADDRESS is restricted > to the RFC 2821 address syntrax, rather than the full from RFC > 2822. That would be a departure from past practice because syntactically significant characters in email addresses are currently not members of the atext set, whereas "|" is. I think ":" is a plausible choice. The difference between a source path and an IMA is then indicated by the presence of the local part before the "@" before the ":". (I'm avoiding ";" because Outlook's non-822 message format uses it instead of ",".) Tony. -- f.a.n.finch http://dotat.at/ FITZROY: NORTH OR NORTHEAST 4 OR 5, BUT VARIABLE 3 OR 4 IN NORTH. MAINLY FAIR. MODERATE WITH FOG PATCHES. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 19 05:53:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsGRL-0003P4-NJ; Mon, 19 Jun 2006 05:53:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsGRK-0003Mr-Bt for ima@ietf.org; Mon, 19 Jun 2006 05:53:02 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsGRH-0006IH-GS for ima@ietf.org; Mon, 19 Jun 2006 05:53:02 -0400 Received: from host81-144-65-173.midband.mdip.bt.net ([81.144.65.173] country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.222) id 449673f8.115a9.296 for ima@ietf.org; Mon, 19 Jun 2006 10:52:56 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (gmrs-tacacs [192.168.0.2]) by oclerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k5IGXE100530 for ; Sun, 18 Jun 2006 17:33:14 +0100 (BST) 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 k5HJrWpd014995 for ; Sat, 17 Jun 2006 20:53:33 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] Minutes about EAI Interim Meeting in Beijing References: <350294707.16087@cnnic.cn> <44916C3D.5090505@alvestrand.no> Message-ID: Date: Sat, 17 Jun 2006 20:53:31 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 16 Jun 2006 22:46:46 +0100, Tony Finch wrote: > On Thu, 15 Jun 2006, Charles Lindsey wrote: >> Yes, I would much prefer "|". I have already pointed out that it is >> unambiguous and parsable provided the syntax of the ALT-ADDRESS is >> restricted >> to the RFC 2821 address syntrax, rather than the full from >> RFC >> 2822. > > That would be a departure from past practice because syntactically > significant characters in email addresses are currently not members of > the > atext set, whereas "|" is. Indeed, but in the real world "|" is never used within a domain name, i.e. after the "@" (at least, not if the message is sent by SMTP, because RFC2821 does not allow it). So if you see then it is clear that the "|" cannot be a part of the domain (even though it is an atext). Hence it can only be the separator after which you expect to find an ALT-ADDRESS. So all we need to do is to specify that utf-8 addresses use something more restrictive than after the "@", and I suggested using the RFC 2821 definition, or something based on it. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Jun 19 07:52:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsIJO-0002aE-Gq; Mon, 19 Jun 2006 07:52:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsIJN-0002a9-7M for ima@ietf.org; Mon, 19 Jun 2006 07:52:57 -0400 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsIJI-0006OX-U0 for ima@ietf.org; Mon, 19 Jun 2006 07:52:57 -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]:34008) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1FsIJ6-000889-1u (Exim 4.54) (return-path ); Mon, 19 Jun 2006 12:52:40 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FsIJ6-0003Yx-9a (Exim 4.53) (return-path ); Mon, 19 Jun 2006 12:52:40 +0100 Date: Mon, 19 Jun 2006 12:52:40 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Charles Lindsey Subject: Re: [EAI] Minutes about EAI Interim Meeting in Beijing In-Reply-To: Message-ID: References: <350294707.16087@cnnic.cn> <44916C3D.5090505@alvestrand.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, 17 Jun 2006, Charles Lindsey wrote: > > Indeed, but in the real world "|" is never used within a domain name, i.e. > after the "@" (at least, not if the message is sent by SMTP, because RFC2821 > does not allow it). I understand that. But the email standards have a history of making metacharacters reserved everywhere, rather than only being reserved where the context allows them to act as a metacharacter. For example, square brackets are only used for domain literals, but they are still not permitted in local parts and display names. On the other hand, perhaps this is an opportunity to relax the syntax so that there are fewer restrictions on which ascii characters are allowed in display names and local parts. If we are going to break the design principles of the current standards, we should at least try to reconstruct them with a coherent design. Tony. -- f.a.n.finch http://dotat.at/ BAILEY: SOUTH 4 BACKING SOUTHEAST 5 TO 7, PERHAPS GALE 8 LATER. RAIN AT TIMES. MODERATE OR GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jun 22 12:13:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRnq-00046H-CO; Thu, 22 Jun 2006 12:13:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRnp-00045t-E9 for ima@ietf.org; Thu, 22 Jun 2006 12:13:09 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtRnn-0006mB-Ry for ima@ietf.org; Thu, 22 Jun 2006 12:13:09 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.222) id 449ac191.74bc.2c5 for ima@ietf.org; Thu, 22 Jun 2006 17:13:05 +0100 (envelope-sender ) 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 k5MFqaL5021041 for ; Thu, 22 Jun 2006 16:52:37 +0100 (BST) To: ima@ietf.org Date: Thu, 22 Jun 2006 16:52:35 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [EAI] Example of body part headers X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I have mentioned this issue several times, but I thought it better to provide an example to illustrate the problem. Here is a message that should be valid under Utf8smtp. Observe that there is no utf8 at all in the headers, but there is plenty of it in the attachments, and some of it is not within the protection of any Content-Transfer-Encoding (see the Content-Disposition in the first attachment, and the From, To and Subject headers in the second attachment). And pardon my French if I have used accute and grave accents in places where they should not be, and if I have got some genders wrong :-( . Let us suppose that this message passes through several MTA, where the first offers full UTF8SMTP, the second does not offer that, but offers 8BITMIME, and the third does not even offer 8BITMIME. The envelope involves no UTF8, but the MAIL FROM: MUST contain a BODY=8BITMIME parameter. Date: Thu, 22 Jun 2006 15:24:33 +0100 (BST) From: ascii@ascii To: another-ascii@another-ascii Subject: Example of utf8 body headers Header-Content: (or whatever we call this header) Utf8smtp (even though there is no utf8 in the headers or envelope) Mime-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=boundary --boundary Content-Disposition: attachment; filename="éxample.txt" Content-Transfer-Encoding: 8bit Content-Type: TEXT/plain; charset=utf-8 Ici un Éxample d'une accent aigue. --boundary Content-Type: MESSAGE/rfc822; Date: Thu, 22 Jun 2006 15:13:10 +0100 From: utf8@éxample.com To: another-utf8@another-utf8 Subject: Éxample_d'une_message/rfc822 Header-Content: Utf8smtp MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Ici un deuxième éxample d'une accent aigue. --boundary-- So what happens? The first MTA is perfectly happy to accept it from the MUA. It then observes that the 2nd MTA does not accept Utf8smtp (and it has been warned by the Header-Content that this is a Utf8smtp message) so it has to consider what downgrades it needs to perform. Now, it it does nothing, it will be forwarding a message that does not conform to existing standards (but if all the subsequent MTAs advertise 8BITMIME, then it would in fact be delivered intact). Suppose it does nothing, and then MTA #2 tries to be deliver it to the non-8BITMIME MTA #3. Read RFC 1652. MTA #2 has the option of bouncing it, or trying to downgrade it (but RFC 1652 gives no clue about downgrade rules - it just tells you to ensure it goes forward as a valid 7bit message). Observe that MTA #2 still sees that BODY=8BITMIME parameter in the MAIL FROM:, so it knows that downgrading is needed. If it is smart enough (are actual 8BITMIME MTAs that smart?) it will observe the multipart mixed and examine the Content-Transfer-Encodings in each multipart. Seeing that they are 8bit, it will do the necessary conversions and change those CTEs to Quoted-Printable. But, not being Utf8smtp-aware, it will do nothing about the utf8 in the Content-Disposition header or the headers of the message/rfc822. So it is clear that it is the responsibility of MTA #1 to deal with those before passing it on to MTA #2 (I already mentioned that in my comments on the downgrade draft). Moreover, it is quite clear how to dongrade those headers (RFC 2231 for the Content-Disposition and RFC 2047 for the rest, so all the downgrade draft needs to do it to draw attention to the need to dongrade those headers. There are also some repercussions for the utf8headers draft. Clearly, it needs to state that it updates RFCs 2045 and 2183 (allowing utf8 in s) and RFC 2046 (allowing Utf8smtp messages within a message/rfc822). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Jun 22 12:13:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRnq-00046N-FZ; Thu, 22 Jun 2006 12:13:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRnp-00045u-EF for ima@ietf.org; Thu, 22 Jun 2006 12:13:09 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtRnn-0006mC-Ry for ima@ietf.org; Thu, 22 Jun 2006 12:13:09 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.222) id 449ac192.74bc.2c6 for ima@ietf.org; Thu, 22 Jun 2006 17:13:06 +0100 (envelope-sender ) 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 k5MBjDBe004332 for ; Thu, 22 Jun 2006 12:45:13 +0100 (BST) Date: Thu, 22 Jun 2006 12:45:12 +0100 To: ima@ietf.org Subject: Re: [EAI] Minutes about EAI Interim Meeting in Beijing References: <44901AB9.6070204@cnnic.cn> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <44901AB9.6070204@cnnic.cn> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 14 Jun 2006 15:18:33 +0100, Xiaodong Lee wrote: > 3.There are still some scenarios that we may consider in the document. We need a scenario where a message/rfc822 object in utf8 form is sent as an attachment. I shall write an example of this. > 6.It is better that the editor can put some utf8header examples in the > document. Because the current ASCII ID formt cannot support utf-8, the > editor may submit a PDF version of his draft in addition to the ASCII > one. I seem to remember a proposal to allow iso-8859-1 in drafts and RFCs. Does anyone know if that was ever agreed? That would be good enough for our purpose (in any case, any examples would need to use some set of characters that most people worldwide would recognise and be able, more or less, to pronounce). So we should stick to examples in French, German, Norwegian and so on which just use Latin letters with assorted accents over them. > > For smtpext document > 7.Some profiles such as SASLprep may be used in the local part of the > email address, but we should start out by being permissive, discover > what the problems are and forbid that while doing implementaion > experiences. There was considerable uncertainty on how much the EAI > specification should try to police the content of the local part. I think it is clear that we need some form of *-prep, and certainly need NFKC. I just had a look though the SASLprep standard (RFC 4013) and it certainly looks about right. Allowing any of the things that it proposes to forbid would certainly make it harder to pass the telephone and fax tests. I propose that we should write SASLprep into our drafts, with a note that it may be reviewed before the final draft in the light of actual experience. My view is that anything we eventually choose will need to be more stringent than SASLprep, rather than less. > 8.Using the below form defined in rfc2821 to define the mail and rcpt > commends may not work. > MAIL FROM: [SP ] > RCPT TO: [ SP ] Surely we just define and (which include the existing <*-path>s, and say that they MUST NOT be used unless the UTF8SMTP capability is advertised. > For IMAP/POP documents > 15.The IMAP document mentions the upgrading. Those who care about > upgrading should read that section carefully to check that it says what > you think it should say. I think upgrading needs a mention in the downgrade document, if only to tell you when _not_ to use it. But it also needs to be made clear what it can be expected to do. Certainly, if you upgrade a downgraded document, you cannot expect to retrieve exactly the original (because the original might have already contained some RFC2-47-encoded stuff, which the upgrade might upgrade for you, and some addresses that were replaced by ALT-ADDRESSES might be irrecoverable). OTOH, we can be more clear about the reverse process. In fact, we should be able to say that for all messages X downgrade(upgrade(X)) == X Is that achievable? > 23.Terminologies Option : In the past, multiple short names have been > used for this effort: EAI, I-email , i18nemail, utf8email, emailing, > IMX, IMAE, utf8smtp, ismtp. The WG needs to decide on one; in the > absence of compelling technical arguments for one or the other, the > meeting decided to take a straw poll to get a decision to present to the > mailing list. I think the problem was that some of the alternatives that have been mentioned, such as I-email, Iemail, I18Nemail, I18email I14Nemail (where did the 14 come from?) are just too similar for anyone to remember which was which, and they are not particularly easy to pronounce, either. So I had already concluded that something with "UTF" in it would be far better. The meeting seems to have agreed with that. > Utf8smtp(4), i18nemail(4), utf8email(1), IMX(1), IMAE(1), ismtp However, we should hope that our lead in using raw UTF8 is going to be followed by other protocols (Netnews is the obvious example, but I am sure there will be others). But it would be nice if all the protocols that followed us could use the same name for the capability that they advertised. That rules out any use of "smtp" or even "email" in the word. > In the second round voting for the two favor: Utf8smtp, i18nemail. the > result is > Utf8smtp(5), i18nemail(3) So I would prefer the first to the second, but my real preference would be for either "Utf8" on its own, or for "Utf8headers". I note that our IMAP draft currently uses "UTF8" (remember that IMAP is also supposed to work for Netnews). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Jun 22 15:51:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtVDB-0000lg-1J; Thu, 22 Jun 2006 15:51:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtVBo-0005uz-63; Thu, 22 Jun 2006 15:50:08 -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 1FtVBo-0004NE-3o; Thu, 22 Jun 2006 15:50:08 -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 1FtVBj-0002Dc-1Q; Thu, 22 Jun 2006 15:50:07 -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 k5MJo2WR027191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtVBi-0006As-MN; Thu, 22 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Jun 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-mailinglist-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 : Mailing Lists and Internationalized Email Addresses Author(s) : E. Chung Filename : draft-ietf-eai-mailinglist-00.txt Pages : 7 Date : 2006-6-22 This document describes considerations for mailing-lists with the introduction of internationalized email addressing capabilities. Different scenarios involving interaction between mailing-lists and internationalized email addresses are examined. Furthermore, mailing-list header fields will be discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-mailinglist-00.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-mailinglist-00.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-mailinglist-00.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-6-22145749.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-mailinglist-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-mailinglist-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22145749.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 Fri Jun 23 09:07:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtlNX-00081c-1C; Fri, 23 Jun 2006 09:07:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtlNW-00080I-OY for ima@ietf.org; Fri, 23 Jun 2006 09:07:18 -0400 Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtlNV-0004Mq-Fc for ima@ietf.org; Fri, 23 Jun 2006 09:07:18 -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]:36991) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1FtlNR-0002nM-UZ (Exim 4.54) (return-path ); Fri, 23 Jun 2006 14:07:13 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FtlNM-0002Va-RU (Exim 4.53) (return-path ); Fri, 23 Jun 2006 14:07:09 +0100 Date: Fri, 23 Jun 2006 14:07:08 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Charles Lindsey Subject: Re: [EAI] Minutes about EAI Interim Meeting in Beijing In-Reply-To: Message-ID: References: <44901AB9.6070204@cnnic.cn> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 22 Jun 2006, Charles Lindsey wrote: > > I seem to remember a proposal to allow iso-8859-1 in drafts and RFCs. Does > anyone know if that was ever agreed? Using non-ASCII Characters in RFCs: draft-hoffman-utf8-rfcs-01.txt (dated December 1, 2005, expires June 4, 2006). Tony. -- f.a.n.finch http://dotat.at/ WHITBY TO THE WASH: WEST OR SOUTHWEST 3 OR 4 BACKING SOUTH LATER TODAY, THEN BECOMING VARIABLE TONIGHT. OCCASIONAL RAIN. MAINLY GOOD. SMOOTH, OCCASIONALLY SLIGHT IN OPEN WATER. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 23 10:24:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftma5-0007um-3F; Fri, 23 Jun 2006 10:24:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftma4-0007uh-Ow for ima@ietf.org; Fri, 23 Jun 2006 10:24:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftma1-0000od-Cm for ima@ietf.org; Fri, 23 Jun 2006 10:24:20 -0400 Received: from [10.20.30.249] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NENwbI003110; Fri, 23 Jun 2006 07:24:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <44901AB9.6070204@cnnic.cn> Date: Fri, 23 Jun 2006 07:23:56 -0700 To: Tony Finch , Charles Lindsey From: Paul Hoffman Subject: Re: [EAI] Minutes about EAI Interim Meeting in Beijing Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 2:07 PM +0100 6/23/06, Tony Finch wrote: >On Thu, 22 Jun 2006, Charles Lindsey wrote: >> >> I seem to remember a proposal to allow iso-8859-1 in drafts and RFCs. Does >> anyone know if that was ever agreed? > >Using non-ASCII Characters in RFCs: draft-hoffman-utf8-rfcs-01.txt >(dated December 1, 2005, expires June 4, 2006). This was not accepted. Internet Drafts and RFCs are still ASCII-only, and will remain so for the foreseeable future. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jun 23 12:35:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtodO-0006Jj-Mt; Fri, 23 Jun 2006 12:35:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtodN-0006Jd-NM for ima@ietf.org; Fri, 23 Jun 2006 12:35: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 1FtodM-0000PU-Dp for ima@ietf.org; Fri, 23 Jun 2006 12:35:53 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FtodL-000DWV-68; Fri, 23 Jun 2006 12:35:51 -0400 Date: Fri, 23 Jun 2006 12:35:50 -0400 From: John C Klensin To: Charles Lindsey , ima@ietf.org Subject: Re: [EAI] Minutes about EAI Interim Meeting in Beijing Message-ID: In-Reply-To: References: <44901AB9.6070204@cnnic.cn> 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: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 22 June, 2006 12:45 +0100 Charles Lindsey wrote: >> 3.There are still some scenarios that we may consider in the >> document. > > We need a scenario where a message/rfc822 object in utf8 form > is sent as an attachment. I shall write an example of this. Charles, As you do this, please remember the "no multiple encodings" rule. I agree that there is a requirement for this (simple forwarding would force it), but it is not straightforward. I haven't had time to write it up, but have come to suspect that the best path might be to design something more like multipart/i18n-message; boundary="foo--" foo-- message/i18n-headers content-transfer-encoding: base64 (if needed) .... foo-- ... message body with whatever content-types and CTE are needed. --foo-- than like a simple message type. I haven't researched, and don't know off the top of my head, whether one could design a message/ subtype to do this instead or resulting to multipart, but you get the general picture. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 26 07:33:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FupLS-0004Xj-SL; Mon, 26 Jun 2006 07:33:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FupLR-0004Xe-EZ for ima@ietf.org; Mon, 26 Jun 2006 07:33:33 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FupLO-0006jr-L1 for ima@ietf.org; Mon, 26 Jun 2006 07:33:33 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.225) id 449fc5fa.1d3.2b1 for ima@ietf.org; Mon, 26 Jun 2006 12:33:14 +0100 (envelope-sender ) 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 k5Q9H4dp014216 for ; Mon, 26 Jun 2006 10:17:04 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] Minutes about EAI Interim Meeting in Beijing References: <44901AB9.6070204@cnnic.cn> Message-ID: Date: Mon, 26 Jun 2006 10:17:03 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 23 Jun 2006 17:35:50 +0100, John C Klensin wrote: > --On Thursday, 22 June, 2006 12:45 +0100 Charles Lindsey > wrote: >> We need a scenario where a message/rfc822 object in utf8 form >> is sent as an attachment. I shall write an example of this. > As you do this, please remember the "no multiple encodings" > rule. Not sure what you mean by the "no multiple encodings" rule. If you mean that a CTE MUST NOT have another CTE hidden inside it, then yes. But my example did not contain that, and neither did my solution. The underlying problem is that when they invented MIME, they arranged for "bodies" to be CT-encoded and for assorted charsets to be used inside them, but they assumed that all "headers" would remain in ASCII for ever. That included the headers (Content-*) that introduced each part of a multipart, and also the email headers of a message/rfc822. That basic assumption is, of course, the one that this WG is now trying to overturn. My example illustrated two separate problems (maybe I would have been better to have given two examples). 1. A Content-Disposition with a utf8 filename parameter (that example needed to be within a multipart to cause the problem). 2. A message/rfc822 for an email message with utf8 headers. The fact that it was in a multipart was purely incidental - the problem would have arisen even if the message/rfc822 has been the sole thing in the body of the email. > I agree that there is a requirement for this (simple > forwarding would force it), but it is not straightforward. I > haven't had time to write it up, but have come to suspect that > the best path might be to design something more like > > multipart/i18n-message; boundary="foo--" > foo-- > message/i18n-headers > content-transfer-encoding: base64 (if needed) > .... > foo-- > ... message body with whatever content-types and CTE are > needed. > --foo-- That seems a complicated way to solve the problem. Existing MUAs know all about message/rfc822, and with no modification beyond what we have already discussed for Utf8smtp, they are going to try to create message/rfc822's with utf8 in their headers. And as far as those MUAs are concerned, it will just work (at both ends). And in a path where every MTA en route supports 8BITMIME (as most do these days), it will just work. So it seems to be better to build on that, and simply to downgrade (or bounce) the message/rfc822 using exactly the same rules as for downgrading the main top-level email. -- 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 Jun 26 10:42:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusI1-0006l2-HO; Mon, 26 Jun 2006 10:42:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusI1-0006jl-89 for ima@ietf.org; Mon, 26 Jun 2006 10:42:13 -0400 Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FusHy-0006TO-Uq for ima@ietf.org; Mon, 26 Jun 2006 10:42:13 -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]:39582) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1FusHs-000734-66 (Exim 4.54) for ima@ietf.org (return-path ); Mon, 26 Jun 2006 15:42:04 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FusHs-0008Dl-Pk (Exim 4.53) for ima@ietf.org (return-path ); Mon, 26 Jun 2006 15:42:04 +0100 Date: Mon, 26 Jun 2006 15:42:04 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ima@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [EAI] IMA representation in envelope and header X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org 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. -- f.a.n.finch http://dotat.at/ NORTH FORELAND TO SELSEY BILL: NORTHEASTERLY 3, OCCASIONALLY 4 OR 5 IN THE EAST, OCCASIONALLY VARIABLE 2 OR 3 IN THE WEST. RAIN OR THUNDERY SHOWERS, DYING OUT OVERNIGHT. MODERATE OR GOOD, OCCASIONALLY POOR DURING DAYTIME. SLIGHT, BUT MODERATE IN THE EAST. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jun 26 18:50:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzuE-0004af-QF; Mon, 26 Jun 2006 18:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuzu6-0004OD-DH; Mon, 26 Jun 2006 18:50:02 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuzu5-0007eA-QY; Mon, 26 Jun 2006 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5QMo1Rx004072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Jun 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fuzu5-0007yu-Gm; Mon, 26 Jun 2006 18: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: Date: Mon, 26 Jun 2006 18:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-framework-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 : Overview and Framework for Internationalized Email Author(s) : J. Klensin, Y. Ko Filename : draft-ietf-eai-framework-01.txt Pages : 19 Date : 2006-6-26 Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications and operational suggestions that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also will include discussion of key assumptions and issues in deploying fully internationalized email. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-framework-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-framework-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-framework-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-6-26154356.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-framework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-26154356.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 Mon Jun 26 21:03:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv1yv-00089c-TT; Mon, 26 Jun 2006 21:03:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv1yv-00089H-DV for ima@ietf.org; Mon, 26 Jun 2006 21:03:09 -0400 Received: from [159.226.7.146] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fv1ys-0006Jb-NB for ima@ietf.org; Mon, 26 Jun 2006 21:03:09 -0400 Received: (eyou send program); Tue, 27 Jun 2006 09:02:57 +0800 Message-ID: <351370177.13687@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; Tue, 27 Jun 2006 09:02:57 +0800 Message-ID: <44A083C6.2060703@cnnic.cn> Date: Tue, 27 Jun 2006 09:03:02 +0800 From: Xiaodong Lee Organization: CNNIC User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [EAI] Preliminary draft agenda at IETF-66 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lee@cnnic.cn List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Dear All, The preliminary draft agenda is as follows, ervery draft will be required to report within 10 minutes,(our session only have two hours). If you think it is not enough, or too long, please tell the chair. Also, if have any comments on agenda, tell chair. ******** Email Address Internationalization Agenda at IETF-66 WG Chairs: Harald Alvestrand Xiaodong Lee 1.Agenda Bashing(Chair, 5 minutes) 1) Comments to agenda 2) Minutes Scribe for meeting 3) Jabber Scriber 2. Documents Status(Chair, 10 minutes) 1) Milestones 2) Documents in WG list 3. Active Drafts Review(80 minutes, 10 minutes for every draft) 1)draft-ietf-eai-framework-00.txt (J. Klensin) http://www.ietf.org/internet-drafts/draft-ietf-eai-framework-00.txt 2) draft-ietf-eai-scenarios-01.txt (not decided) http://www.ietf.org/internet-drafts/draft-ietf-eai-scenarios-01.txt 3) draft-ietf-eai-smtpext-00.txt (J. Yao) http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-00.txt 4)draft-ietf-eai-utf8headers-00.txt (J. Ye) http://www.ietf.org/internet-drafts/draft-ietf-eai-utf8headers-00.txt 5) draft-ietf-eai-imap-utf8-00.txt (P. Resnick) http://www.ietf.org/internet-drafts/draft-ietf-eai-imap-utf8-00.txt 6)draft-ietf-eai-mailinglist-00.txt (Edmon Chung) http://www.ietf.org/internet-drafts/draft-ietf-eai-mailinglist-00.txt 7)draft-ietf-eai-pop-00.txt(Chris Newman)(assume it will be published as WG draft before meeting) http://www.ietf.org/internet-drafts/draft-ietf-eai-pop-00.txt 8)draft-ietf-eai-downgrade-01.txt ( K. Fujiwara) http://www.ietf.org/internet-drafts/draft-ietf-eai-downgrade-01.txt 4. Testing Report (CNNIC&TWNIC, 10 minutes) 5. Other issues(15 minutes) -- -- 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 Wed Jun 28 19:10:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvizr-0008Se-Qq; Wed, 28 Jun 2006 18:59:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvirO-0006DJ-9V; Wed, 28 Jun 2006 18:50:14 -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 1FvirO-0000CT-6Y; Wed, 28 Jun 2006 18:50:14 -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 1FvirC-0000Fb-5e; Wed, 28 Jun 2006 18:50:14 -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 k5SMo11u006578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jun 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvirB-0004mR-Mk; Wed, 28 Jun 2006 18: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: Date: Wed, 28 Jun 2006 18:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-pop-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 : POP3 Support for UTF-8 Author(s) : C. Newman Filename : draft-ietf-eai-pop-00.txt Pages : 16 Date : 2006-6-28 This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, mail addresses, message headers, and protocol-level textual error strings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-pop-00.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-pop-00.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-pop-00.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-6-28155350.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-pop-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-pop-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-28155350.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 Jun 29 10:50:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxqJ-0004vq-4o; Thu, 29 Jun 2006 10:50:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxqE-0004u4-QE; Thu, 29 Jun 2006 10:50:02 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvxqD-000517-Il; Thu, 29 Jun 2006 10:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5TEo19F032090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jun 2006 14:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvxqD-0008Kg-C0; Thu, 29 Jun 2006 10: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: Date: Thu, 29 Jun 2006 10:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-scenarios-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 : UTF-8 Mail: Scenarios Author(s) : H. Alvestrand Filename : draft-ietf-eai-scenarios-01.txt Pages : 10 Date : 2006-6-29 This document describes some scenarios in which one can imagine internationalized email addresses deployed, and tries to draw some conclusions about what's acceptable and what's not for users in those scenarios. One possible set of extensions that can work in these scenarios is those described in the UTF8MAIL extension documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-scenarios-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-scenarios-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-scenarios-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-6-29095839.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-scenarios-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-scenarios-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-29095839.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 Jun 29 18:09:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw4hV-0000Uy-Pb; Thu, 29 Jun 2006 18:09:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw4hR-0000PD-R6; Thu, 29 Jun 2006 18:09:25 -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 1Fw3F8-0007E7-Gv; Thu, 29 Jun 2006 16:36:06 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fw2lb-00030T-1X; Thu, 29 Jun 2006 16:05:38 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5TJo2jx010149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fw2WX-0003SK-Uh; Thu, 29 Jun 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: Date: Thu, 29 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-downgrade-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Downgrading mechanism for Email Address Internationalization (EAI) Author(s) : Y. Yoneya, K. Fujiwara Filename : draft-ietf-eai-downgrade-01.txt Pages : 15 Date : 2006-6-29 Traditional mail systems handle only US-ASCII characters in SMTP envelope and mail headers. The Email Address Internationalization (EAI) is implemented by allowing UTF-8 characters in SMTP envelope and mail headers. To deliver Non-ASCII mail address through EAI incompliant environment, some sort of converting mechanism (i.e. downgrading) is required. This document describes requirements for downgrading, SMTP session downgrading, header downgrading and implementation consideration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-downgrade-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-downgrade-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-downgrade-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-6-29105541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-downgrade-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-downgrade-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-29105541.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 Fri Jun 30 03:18:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwDGr-0003qR-Vu; Fri, 30 Jun 2006 03:18:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwDGq-0003oD-8T for ima@ietf.org; Fri, 30 Jun 2006 03:18:32 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwDGo-0000bf-VS for ima@ietf.org; Fri, 30 Jun 2006 03:18:32 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D679A25970D for ; Fri, 30 Jun 2006 09:17:15 +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 19711-03 for ; Fri, 30 Jun 2006 09:17:09 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1B2752596F8 for ; Fri, 30 Jun 2006 09:17:09 +0200 (CEST) Message-ID: <44A4D03F.2050409@alvestrand.no> Date: Fri, 30 Jun 2006 00:18:23 -0700 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: "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: cf4fa59384e76e63313391b70cd0dd25 Subject: [EAI] List of EAI internet-drafts, as of today X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org 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 From ima-bounces@ietf.org Fri Jun 30 12:21:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLjq-0000JV-Tt; Fri, 30 Jun 2006 12:21:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLjp-0000JL-KE for ima@ietf.org; Fri, 30 Jun 2006 12:21:01 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwLjm-00035x-V6 for ima@ietf.org; Fri, 30 Jun 2006 12:21:01 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.225) id 44a54f68.146f8.dd for ima@ietf.org; Fri, 30 Jun 2006 17:20:56 +0100 (envelope-sender ) 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 k5UGGeGU024561 for ; Fri, 30 Jun 2006 17:16:40 +0100 (BST) Date: Fri, 30 Jun 2006 17:16:39 +0100 To: ima@ietf.org From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [EAI] Comments on draft--eai-pop-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This seems pretty good. Just a few observations: 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] 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. Up-conversion of MIME header encoding of the following headers MUST also be implemented: Subject, Date (RFC 2822 comments only), Comments, Keywords, Content-Description. ... and MAY/SHOULD support various other headers {to be discussed}, including things previously downgraded by RFC 2231. 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. 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 :-) . -- 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 Jun 30 12:21:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLjr-0000Ja-0Q; Fri, 30 Jun 2006 12:21:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLjp-0000JM-KE for ima@ietf.org; Fri, 30 Jun 2006 12:21:01 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwLjm-00035y-V8 for ima@ietf.org; Fri, 30 Jun 2006 12:21:01 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.225) id 44a54f69.146f8.de for ima@ietf.org; Fri, 30 Jun 2006 17:20:57 +0100 (envelope-sender ) 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 k5UFO6FQ020875 for ; Fri, 30 Jun 2006 16:24:06 +0100 (BST) Date: Fri, 30 Jun 2006 16:24:05 +0100 To: ima@ietf.org From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Subject: [EAI] Comments on draft--eai-utf8headers-00 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org .... This document specifies the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field bodies. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. Not quite. SMTP is not the only transport mechanism that exists (though it is by far the commonest). So messages using this draft could be permitted by any transport mechanism capable of supporting it. So please can we say "... only if authorized for use with the tramsmission mechanism (e.g. by the SMTP extension specified in a companion document)". Or something along those lines, and also at other places where SMTP is mentioned. 1. Introduction 1.1. Role of this specification Please can we have an extra bullet: o The capability to use non-ASCII content in various other headers where it has not hitherto been permitted. {I have in mind particularly s in MIME headers and URLs in various List-* headers, but doubtless others will arise from time to time). 2. Background and History s/more the less/more or less/ ... This protocol specifies UTF-8 as the encoding to represent email header body. s/email header body/email header field bodies/ (RFC 2822 uses the term "header field body" for what I think you mean.) ... These changes affect SMTP clients, SMTP servers, and mail user agents (MUAs). You can add "list expanders" and "gateways to other media" to the list. s/Use this SMTP extension/Use of this SMTP extension/ Those protocols will need to be changed ... s/will/also/ (or s/will/will also/) 3. Terminology s/the bodies of headers/the bodies of those headers/ 4. Pre-requirement The use of UTF-8 header fields is dependent on the use of an SMTP extension named "i-Email". See remarks about SMTP earlier. Also s/i-Email/Utf8smtp/ {or whatever} That protocol is defined in [EAI-SMTP-extension]. If that extension is not supported, UTF-8 header fields MUST NOT be transmitted. s/transmitted/transmitted by SMTP/ 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). 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 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. 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 :-( . 6. Changes on Message Header Fields For those tokens not referred in this section remains as the original definition in RFC 2822. s/tokens/rules/ 6.1. UTF8 Syntax The use of UTF8 characters are defined as following. s/following/follows/ 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 etc for Message-ID and Received. 2. define a special 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 and "atomic". You also need to decide how much, if any, of the obs-syntax needs to be changed. Probably none of it since, because you MUST NOT generate it, a piece of obs-syntax with Utf8 in it should just never happen. stct-addr = stct-local-part "@" stct-domain please s/stct/strict/ throughout ("stct" is just not an obvious abbreviation for "strict"). alt-separator = [FWS] "," [FWS] candidates for this are ",". ":" and "|", where "|" would require a special syntax in place of within (though it wold be OK within ). I preter "|" over ":" and ":" over "," (there are already too many other uses of "," within address-lists and mailbox lists). DISPLAY NAME ; i-Email but no ALT-ADDRESS nor ATOMIC option provided, ; message will bounce if i-Email extension is not supported s/IDNA/UTF8/ (It won't be IDNA until it gets downgraded, if ever) DISPLAY NAME ; i-Email with ATOMIC option provided ; message is good for downgrade s/IDNA/UTF8/ s/for downgrade/for downgrade by ACE/ 7. Additional issue I think you need to deal with the MIME headers here. In particular, (as used in s) needs to allow Utf8 within it (with RFC 2231 as the downgrade mechanism). s (being identifiers) ahould, of course, remain in ASCII. 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 and (so we need to decide which kind of that would be). 8. Security Considerations If a user has a non-ASCII mailbox address and a all-ASCII mailbox ... s/a all/an all/ 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. 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. -- 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