From ima-bounces@ietf.org Mon May 01 09:34:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaYXi-00012Z-VU; Mon, 01 May 2006 09:34:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaYXh-00012P-TZ for ima@ietf.org; Mon, 01 May 2006 09:34:25 -0400 Received: from [159.226.7.146] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FaYXf-0004CJ-18 for ima@ietf.org; Mon, 01 May 2006 09:34:25 -0400 Received: (eyou send program); Mon, 01 May 2006 21:34:14 +0800 Message-ID: <346490454.11140@cnnic.cn> X-EYOUMAIL-SMTPAUTH: lee@cnnic.cn Received: from unknown (HELO [61.51.194.137]) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 01 May 2006 21:34:14 +0800 Message-ID: <44560E5A.5000302@cnnic.cn> Date: Mon, 01 May 2006 21:34:18 +0800 From: "Xiaodong(Sheldon) Lee" Organization: CNNIC User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en 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: ea4ac80f790299f943f0a53be7e1a21a Cc: Lisa Dusseault Subject: [EAI] EAI WG Interim Meeting 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 EAI Working Group plan to hold a interim meeting. The main purpose of this interim meeting is to prompt the process of this working group. The meeting need to get the approval of AD. The intending meeting time is in June 1-2, one day or two days meeting in Beijing. Detailed things will be published later, just send this message to this list, so you can prepare your schedule firstly. Anyone who plans to attend meeting, you can send a message to the WG co-chairs. Affirmatory agenda will be sent later. Regards! xiaodong -- -- [The best answer is doing] +86-10-58813020 http://www.lixiaodong.cn mailto:mail@lixiaodong.cn _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon May 01 13:56:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FacdW-0006eQ-BG; Mon, 01 May 2006 13:56:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FacdV-0006av-7N for ima@ietf.org; Mon, 01 May 2006 13:56:41 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FacdR-00057H-Qj for ima@ietf.org; Mon, 01 May 2006 13:56:41 -0400 Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k41Hub4d009463 for ; Mon, 1 May 2006 11:56:37 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IYL00H01LJ89A00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 01 May 2006 11:56:37 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IYL006SHLUAXU20@mail-amer.sun.com>; Mon, 01 May 2006 11:56:36 -0600 (MDT) Date: Mon, 01 May 2006 10:59:43 -0700 From: Chris Newman Subject: Re: [EAI] help to define Ucharacter and sub-domain by ABNF In-reply-to: To: YAO Jiankang , ima@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <006401c66a71$e35f2530$1206e29f@cnnicyaojk> X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 It occurs to me that "Uatext" might be a better name for the ABNF rule. It's not a general purpose character. - Chris YAO Jiankang, ima@ietf.org wrote on 4/28/06 19:31 -0700: > This ABNF should work: > > Ucharacter = atext / UTF8-2 / UTF8-3 / UTF8-4 > > Where "atext" is defined in RFC 2822 and UTF8-2, UTF8-3, UTF8-4 are defined > in RFC 3629. > > - Chris > > YAO Jiankang wrote on 4/28/06 11:14 +0800: > >> >> Dear all, >> >> Could some kind experts help to refine the below definition of Ucharacter >> and sub-domain by ABNF in the IMA SMTP extension document? >> It seems not easy to find a very good appropriate definition. >> >> thanks a lot. >> >> >> -------------------------------------------------------------------------- >> >> According to the description above, define the syntax of an IMA >> mailbox with ABNF [RFC4234] as >> >> >> Mailbox = Local-part "@" Domain >> >> Local-part = Dot-string / Quoted-string >> ; MAY be case-sensitive >> >> Dot-string = Atom *("." Atom) >> >> Atom = 1*Ucharacter >> Ucharacter = > except ASCII characters that are not permitted in "atext" and >> characters that can not pass Stringprep> >> >> Quoted-string = DQUOTE *qcontent DQUOTE >> >> Domain = (sub-domain 1*("." sub-domain)) / address-literal >> sub-domain = Let-dig [Ldh-str] / >> >> >> >> YAO Jiankang >> Best Regards >> Tel:86-10-58813007 >> Fax:86-10-62559892 >> -------------------------------------------------- >> China Internet Network Information Center (CNNIC) >> 4, South 4th Street, Zhongguancun, >> Haidian district, >> Beijing 100080, China >> POB: Beijing 349, Branch 6 >> http://www.cnnic.cn >> Email: yaojk@cnnic.cn >> healthyao@163.com >> > > > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue May 02 00:25:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FamSR-0004Kg-PL; Tue, 02 May 2006 00:25:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FamSR-0004Kb-0d for ima@ietf.org; Tue, 02 May 2006 00:25:55 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FamSQ-0005Yg-Ev for ima@ietf.org; Tue, 02 May 2006 00:25:54 -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 k424PNRB003139; Tue, 2 May 2006 13:25:30 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2006050213252806334 ; Tue, 02 May 2006 13:25:28 +0900 Date: Tue, 02 May 2006 13:25:28 +0900 (JST) Message-Id: <20060502.132528.41634701.fujiwara@jprs.co.jp> To: harald@alvestrand.no Subject: Re: [EAI] Comments on Downgrading From: fujiwara@jprs.co.jp In-Reply-To: <445079A4.3030401@alvestrand.no> References: <444DE80B.1020808@alvestrand.no> <20060426.223656.26286654.fujiwara@jprs.co.jp> <445079A4.3030401@alvestrand.no> X-Mailer: Mew version 5.0.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 > From: Harald Alvestrand > >>>* Section 3.1: "SMTP client detects UTF-8 is included in SMTP envelope or > >>>mail headers". Haven't we introduced the i18n-header to avoid making this > >>>realtime, unreliable checks? And is it really meant "detects UTF-8" or it > >>>is rather meant "detects 8th bit set"? > >>> > >>> > > > >Considering implementation costs, I want to use detecting 8th bit set > >instead of UTF-8 check. > > > > > The implementation cost for a proper UTF-8 detector is rather small (you > check for the non-presence of the 13 forbidden bytes, and that sequences > are properly formed - all that can be done in a fairly small finite > state machine in one pass, and you still don't have to look at any byte > more than oce), and the cost of accepting ISO 8859-1 into processing > stages that expect properly formatted UTF-8 is that you have to do the > error checking for that condition *everywhere*. > > If we want to have heuristic UTF-8 detection, I think we should > recommend UTF-8 detection, not the 8th bit check. I agree. > But if we go with the flag (i18n-header or otherwise), we have moved > heuristic UTF-8 detection into the realm of "handling nonconformant > data", which our standards leave out a lot of the time anyway. I understand. I will rewrite to delete UTF-8 detection in downgrade draft. UTF-8 detection should be written in smtpext draft, I think. As a result of UTF-8 detection in smtpext (without downgrade), bounce or downgrading occurs. Mail header downgrading refers i18n-header flag. ... Adding received header with IMA requires i18n-mail header manupulation. > > > > > >>There are just-send-8859-1 mailers out there in the wild. > >>UTF-8 can be detected with fair reliability. > >> > >> > > > >Are ISO-8859-1 characters (not in US-ASCII) allowed in mail headers? > > > > > No, they're forbidden. There are mailers that send them anyway. May such mail be bounced? -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue May 02 05:09:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaqtF-0007up-Nc; Tue, 02 May 2006 05:09:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaqtE-0007uk-MW for ima@ietf.org; Tue, 02 May 2006 05:09:52 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaqtD-0000Hd-4q for ima@ietf.org; Tue, 02 May 2006 05:09:52 -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 k4299mR9008391 for ; Tue, 2 May 2006 18:09:49 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2006050218094808925 for ; Tue, 02 May 2006 18:09:48 +0900 Date: Tue, 02 May 2006 18:09:48 +0900 (JST) Message-Id: <20060502.180948.41651497.fujiwara@jprs.co.jp> To: ima@ietf.org From: fujiwara@jprs.co.jp X-Mailer: Mew version 5.0.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [EAI] clarify Received header format 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-yao-ima-smtpext-02.txt section 2.5.2. Trace Fields is ambiguous. 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. This Received header format may be defined in utf8header draft and smtpext draft refer it. Without clear Received header definition, implementation is impossible. In my opinion, addresses in "for" clauses should be IMA itself and should be UTF-8 encoded. And more, I want to record ALT-ADDR, ATOMIC parameter information. "i18n-email: 1.0" header may be added by MTA as a result of adding Received header or IMA-Downgraded-* header. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue May 02 07:17:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FassS-0008Je-BR; Tue, 02 May 2006 07:17:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FassQ-0008JZ-I4 for ima@ietf.org; Tue, 02 May 2006 07:17:10 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FassQ-0005wX-2p for ima@ietf.org; Tue, 02 May 2006 07:17:10 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FassO-000Cux-SS; Tue, 02 May 2006 07:17:09 -0400 Date: Tue, 02 May 2006 07:17:07 -0400 From: John C Klensin To: fujiwara@jprs.co.jp Subject: Re: [EAI] clarify Received header format Message-ID: <7C1A2EE7E2AB49CCC3B4816E@p3.JCK.COM> In-Reply-To: <20060502.180948.41651497.fujiwara@jprs.co.jp> References: <20060502.180948.41651497.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: b7b9551d71acde901886cc48bfc088a6 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 Tuesday, 02 May, 2006 18:09 +0900 fujiwara@jprs.co.jp wrote: > draft-yao-ima-smtpext-02.txt section 2.5.2. Trace Fields is > ambiguous. > > 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. > > This Received header format may be defined in utf8header draft > and smtpext draft refer it. > > Without clear Received header definition, implementation is > impossible. > > In my opinion, addresses in "for" clauses should be IMA itself > and should be UTF-8 encoded. FWIW, this is my fault from a very early draft. I started working through the case analyses (not just my desires) and came to the conclusion that the problem was hard and there was no clear answer. There are clear advantages to having the in-transit MTA insert only pure-ASCII trace fields into the headers. For example, suppose a trace field containing UTF-8 information is to be inserted and we are to require a header field that indicates that UTF-8 information is present. The MTA must perform a header scan to determine whether that UTF-8-indicating header is present and add it if it is not. We generally try to avoid requiring MTAs to perform such header scans -- the historical model says that that, other than submission and delivery MTAs, they don't do it. This is, incidentally, one of several reasons I've been reluctant to agree to the requirement for such a header field -- it does have side-effects. Since we haven't, I think, agreed on the syntax or semantics of that UTF-8-indicating header field yet, I don't know if one is supposed to supply it when the SMTP extension is used at all, even if the headers don't actually contain UTF-8 information. That decision obviously interacts with the discussion above. Since "for" is optional, one possibility would be to carry "for" information in UTF-8 up to the point that downgrade needed to occur, then drop it from all trace fields in which it appears. Of course, that requires changing existing trace fields, something else we prohibit (and turning "downgrading" into even more of a gateway/ protocol converter -like operation). I believe changing "for " into "for " in a _previous_ header to be a bad idea -- the "for" field should reflect, IMO, the address to which that particular MTA thought it was sending, not some later correction. One could, I suppose, replace "for " with "(previous for field deleted in downgrading" without distorting information. But see the rather strong MUST NOT language in 2821 about alterations to existing Received fields; language that is there for reasons based on nasty past experiences. > And more, I want to record ALT-ADDR, ATOMIC parameter > information. Putting this information into a comment is no problem. Doing it as an authoritative subfield raises the usual questions: since the subfield names are not defined in RFC 2821, you would presumably have to remove them, retroactively, since 2821 does not permit them and the result of downgrading must be 2821/2822-compatible. > "i18n-email: 1.0" header may be added by MTA > as a result of adding Received header or IMA-Downgraded-* > header. Yes, see comment about scanning header fields above. I really don't know how to best handle this, although the degree to which "for" has fallen into disfavor for security reasons may give us some hints. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue May 02 14:25:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazZI-0007jy-DD; Tue, 02 May 2006 14:25:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazZF-0007jX-QG for ima@ietf.org; Tue, 02 May 2006 14:25:49 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FazZF-0008Px-DG for ima@ietf.org; Tue, 02 May 2006 14:25:49 -0400 Received: from host81-144-66-240.midband.mdip.bt.net ([81.144.66.240] country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.215) id 4457a42b.5b90.78 for ima@ietf.org; Tue, 2 May 2006 19:25:47 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k42IK1e16934 for ; Tue, 2 May 2006 19:20:01 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] clarify Received header format References: <20060502.180948.41651497.fujiwara@jprs.co.jp> <7C1A2EE7E2AB49CCC3B4816E@p3.JCK.COM> Message-ID: Date: Tue, 02 May 2006 19:20:00 +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: <7C1A2EE7E2AB49CCC3B4816E@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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, 02 May 2006 12:17:07 +0100, John C Klensin wrote: > --On Tuesday, 02 May, 2006 18:09 +0900 fujiwara@jprs.co.jp wrote: >> In my opinion, addresses in "for" clauses should be IMA itself >> and should be UTF-8 encoded. > > FWIW, this is my fault from a very early draft. I started > working through the case analyses (not just my desires) and came > to the conclusion that the problem was hard and there was no > clear answer. There are clear advantages to having the > in-transit MTA insert only pure-ASCII trace fields into the > headers. For example, suppose a trace field containing UTF-8 > information is to be inserted and we are to require a header > field that indicates that UTF-8 information is present. The MTA > must perform a header scan to determine whether that > UTF-8-indicating header is present and add it if it is not. We > generally try to avoid requiring MTAs to perform such header > scans -- the historical model says that that, other than > submission and delivery MTAs, they don't do it. This is, > incidentally, one of several reasons I've been reluctant to > agree to the requirement for such a header field -- it does have > side-effects. I think an intermediate MTA that needs to know whether it is dealing with an extended email or not has a choice. Either it looks for the presence of the UTF-8-indicating header, or it looks for the presence of a bit-8 (or maybe it does a proper UTF-8 test, as we have been discussing). Implementor's choice. However, as regards the Received header it would, in principle, be nice to have it in UTF-8 wherever possible, but there are snags. But I am not sure this is one of them. The case we are considering (possible necessity to insert a UTF-8-indicating header if we have just created a "for clause") will be rare: it only arises if the RCPT address is UTF-8 and the To: header is not (otherwise the UTF-8-indicating header would already be present). Moreover, the "for" clause can safely be left in UTF-8 if we are forwarding to another IMA-compliant MTA, and if we are not, then we shall have to use the alternate (or a downgraded) address, in which case the "for" clause might as well contain the alternate/downgraded address. Tne real problem, of course, is that a Received header with UTF-8 in it will eventually arrive at a non-compliant MTA, and therfore we need to define a means to downgrade Received headers. > Since "for" is optional, one possibility would be to carry "for" > information in UTF-8 up to the point that downgrade needed to > occur, then drop it from all trace fields in which it appears. What is current practice with regard to inserting the "for" clause? If a message passes through a chain of intermediate MTAs, then surely the "for" clause needs to be written only once, except in the case where the envelope address gets altered en route (e.g. by a mail-list expander). -- 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 May 02 14:25:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazZG-0007jn-9B; Tue, 02 May 2006 14:25:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazZF-0007jN-E7 for ima@ietf.org; Tue, 02 May 2006 14:25:49 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FazZC-0008Pp-CE for ima@ietf.org; Tue, 02 May 2006 14:25:49 -0400 Received: from host81-144-66-240.midband.mdip.bt.net ([81.144.66.240] country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.215) id 4457a428.5b90.76 for ima@ietf.org; Tue, 2 May 2006 19:25:44 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k42HEle16594 for ; Tue, 2 May 2006 18:14:47 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] Open issues on the EAI documents References: <444DE7EC.8050807@alvestrand.no> <976F69667025635CBE910437@p3.JCK.COM> Message-ID: Date: Tue, 02 May 2006 18:14:46 +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: <976F69667025635CBE910437@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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, 29 Apr 2006 17:45:12 +0100, John C Klensin wrote: > --------------------------------- >> 822-headers (Yeh document): >> Issue: Dave/Chris: Comma in address fields as an alternative >> to separate parameter? > > Can we initiate some specific discussion on this and get it > settled? My impression was that we had dropped it due to other > interactions, but I could easily be confused. Clearly we need a separator, and clearly nobody particularly likes 'comma' even though it is the only obviously "free" character. May I remind you that I pointed out some time back that '|' (which would look much better as the separator) would not be ambiguous *provided* we could assume that it would not occur in the domain portion of an address (i.e. after the '@'). This is true of any domain allowed by RFC 2821 (though theoretically it might arise in emails transported by other mechanisms - X.400 anybody?). So is it a serious contender for this separator? -- 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 May 02 14:25:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazZG-0007jc-5Z; Tue, 02 May 2006 14:25:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazZF-0007jO-E7 for ima@ietf.org; Tue, 02 May 2006 14:25:49 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FazZC-0008Ps-CE for ima@ietf.org; Tue, 02 May 2006 14:25:49 -0400 Received: from host81-144-66-240.midband.mdip.bt.net ([81.144.66.240] country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.215) id 4457a429.5b90.77 for ima@ietf.org; Tue, 2 May 2006 19:25:45 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k42H0se16520 for ; Tue, 2 May 2006 18:00:55 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] RFC 4409 Message Submission References: <346192808.12365@cnnic.cn> <00c401c66a8c$a2b9a940$1206e29f@cnnicyaojk> Message-ID: Date: Tue, 02 May 2006 18:00:54 +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: <00c401c66a8c$a2b9a940$1206e29f@cnnicyaojk> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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, 28 Apr 2006 07:26:08 +0100, YAO Jiankang wrote: >> Does 'smtpext' document need to describe Submission ? > > SMTP was defined as a message *transfer* protocol, that is, a means > to route (if needed) and deliver finished (complete) messages. Not quite. When SMTP was defined (and even when RFC 2821 was written), "submission" was not regarded as a separate activity, and MUAs submitted their messages direct to SMTP servers on Port 25. Indeed, many MUAs still do that, so out smtpext needs to handle them sensibly (and I think it currently does). > RFC 2476 is to deal with how to sumbit the message to the server. > IMO, no need to describe the issues related with RFC 2476 in 'smtpext' > document ISTM that submission agents (RFC 2476 or whatever has replaced it) therefore have to be able to do at least as much by way of downgrading/bouncing/etc as any other SMTP agent, in which case smtpext is the place to discuss it, as an extension to the RFC 2476(bis?) protocol. That is not to say that we moght not propose some slightly different features for handling messages in submission agents. For example, it might be more reasonable to bounce (rather than downgrade) messages in a submission agent, on the grounds that it is closer to the sender, and therefore easier to send it back to him for him to fix the problem himself. -- 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 May 02 14:25:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazZG-0007jn-9B; Tue, 02 May 2006 14:25:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazZF-0007jN-E7 for ima@ietf.org; Tue, 02 May 2006 14:25:49 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FazZC-0008Pp-CE for ima@ietf.org; Tue, 02 May 2006 14:25:49 -0400 Received: from host81-144-66-240.midband.mdip.bt.net ([81.144.66.240] country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.215) id 4457a428.5b90.76 for ima@ietf.org; Tue, 2 May 2006 19:25:44 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k42HEle16594 for ; Tue, 2 May 2006 18:14:47 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] Open issues on the EAI documents References: <444DE7EC.8050807@alvestrand.no> <976F69667025635CBE910437@p3.JCK.COM> Message-ID: Date: Tue, 02 May 2006 18:14:46 +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: <976F69667025635CBE910437@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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, 29 Apr 2006 17:45:12 +0100, John C Klensin wrote: > --------------------------------- >> 822-headers (Yeh document): >> Issue: Dave/Chris: Comma in address fields as an alternative >> to separate parameter? > > Can we initiate some specific discussion on this and get it > settled? My impression was that we had dropped it due to other > interactions, but I could easily be confused. Clearly we need a separator, and clearly nobody particularly likes 'comma' even though it is the only obviously "free" character. May I remind you that I pointed out some time back that '|' (which would look much better as the separator) would not be ambiguous *provided* we could assume that it would not occur in the domain portion of an address (i.e. after the '@'). This is true of any domain allowed by RFC 2821 (though theoretically it might arise in emails transported by other mechanisms - X.400 anybody?). So is it a serious contender for this separator? -- 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 May 02 14:25:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazZG-0007jc-5Z; Tue, 02 May 2006 14:25:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazZF-0007jO-E7 for ima@ietf.org; Tue, 02 May 2006 14:25:49 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FazZC-0008Ps-CE for ima@ietf.org; Tue, 02 May 2006 14:25:49 -0400 Received: from host81-144-66-240.midband.mdip.bt.net ([81.144.66.240] country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.215) id 4457a429.5b90.77 for ima@ietf.org; Tue, 2 May 2006 19:25:45 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k42H0se16520 for ; Tue, 2 May 2006 18:00:55 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] RFC 4409 Message Submission References: <346192808.12365@cnnic.cn> <00c401c66a8c$a2b9a940$1206e29f@cnnicyaojk> Message-ID: Date: Tue, 02 May 2006 18:00:54 +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: <00c401c66a8c$a2b9a940$1206e29f@cnnicyaojk> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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, 28 Apr 2006 07:26:08 +0100, YAO Jiankang wrote: >> Does 'smtpext' document need to describe Submission ? > > SMTP was defined as a message *transfer* protocol, that is, a means > to route (if needed) and deliver finished (complete) messages. Not quite. When SMTP was defined (and even when RFC 2821 was written), "submission" was not regarded as a separate activity, and MUAs submitted their messages direct to SMTP servers on Port 25. Indeed, many MUAs still do that, so out smtpext needs to handle them sensibly (and I think it currently does). > RFC 2476 is to deal with how to sumbit the message to the server. > IMO, no need to describe the issues related with RFC 2476 in 'smtpext' > document ISTM that submission agents (RFC 2476 or whatever has replaced it) therefore have to be able to do at least as much by way of downgrading/bouncing/etc as any other SMTP agent, in which case smtpext is the place to discuss it, as an extension to the RFC 2476(bis?) protocol. That is not to say that we moght not propose some slightly different features for handling messages in submission agents. For example, it might be more reasonable to bounce (rather than downgrade) messages in a submission agent, on the grounds that it is closer to the sender, and therefore easier to send it back to him for him to fix the problem himself. -- 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 May 02 14:48:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fazuw-0007K3-CL; Tue, 02 May 2006 14:48:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fazuv-0007Jy-Og for ima@ietf.org; Tue, 02 May 2006 14:48:13 -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 1Fazuv-00011q-Dq for ima@ietf.org; Tue, 02 May 2006 14:48:13 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Fazuu-000Dj6-Da; Tue, 02 May 2006 14:48:12 -0400 Date: Tue, 02 May 2006 14:48:11 -0400 From: John C Klensin To: Charles Lindsey , ima@ietf.org Subject: Re: [EAI] RFC 4409 Message Submission Message-ID: <31432EC07A1339F45F935B38@p3.JCK.COM> In-Reply-To: References: <346192808.12365@cnnic.cn> <00c401c66a8c$a2b9a940$1206e29f@cnnicyaojk> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Tuesday, 02 May, 2006 18:00 +0100 Charles Lindsey wrote: >> RFC 2476 is to deal with how to sumbit the message to the >> server. IMO, no need to describe the issues related with RFC >> 2476 in 'smtpext' document > > ISTM that submission agents (RFC 2476 or whatever has replaced > it) therefore have to be able to do at least as much by way > of downgrading/bouncing/etc as any other SMTP agent, in which > case smtpext is the place to discuss it, as an extension to > the RFC 2476(bis?) protocol. > > That is not to say that we moght not propose some slightly > different features for handling messages in submission > agents. For example, it might be more reasonable to bounce > (rather than downgrade) messages in a submission agent, on > the grounds that it is closer to the sender, and therefore > easier to send it back to him for him to fix the problem > himself. The submission agent might also have access to much more information than a typical SMTP relay. I could easily imagine storing a table of i18nAddress <-> ASCII address equivalences in such an agent, especially for backward (sender)-pointer addresses so that the agent could do some downgrading without the need for the user to supply ALT-ADDRESS or ATOMIC (or equivalent) for each i18nAddress. So, yes, I think something that discusses changes to 2476bis (which, as you might guess from the subject line, is 4409) would be in order. I'm not convinced that the topic deserves more than a mention in smtpext and even that mention might be mostly in the framework doc. See my other note on the subject -- comments are very welcome, ideally before YangWoo and I get the next version of the framework doc out (RSN, I hope). john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue May 02 21:54:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb6ZF-0008RQ-GP; Tue, 02 May 2006 21:54:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb6ZD-0008RI-F0 for ima@ietf.org; Tue, 02 May 2006 21:54:15 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb6ZC-0003Vc-UQ for ima@ietf.org; Tue, 02 May 2006 21:54:15 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Fb6ZB-000EPO-IJ; Tue, 02 May 2006 21:54:13 -0400 Date: Tue, 02 May 2006 21:54:12 -0400 From: John C Klensin To: Charles Lindsey , ima@ietf.org Subject: Re: [EAI] clarify Received header format Message-ID: <7CBD5124899C455E33836CA9@p3.JCK.COM> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 Tuesday, 02 May, 2006 19:20 +0100 Charles Lindsey wrote: > On Tue, 02 May 2006 12:17:07 +0100, John C Klensin > wrote: > >> --On Tuesday, 02 May, 2006 18:09 +0900 fujiwara@jprs.co.jp >> wrote: > >>> In my opinion, addresses in "for" clauses should be IMA >>> itself and should be UTF-8 encoded. >> >> FWIW, this is my fault from a very early draft. I started >> working through the case analyses (not just my desires) and >> came to the conclusion that the problem was hard and there >> was no clear answer. There are clear advantages to having the >> in-transit MTA insert only pure-ASCII trace fields into the >> headers. For example, suppose a trace field containing UTF-8 >> information is to be inserted and we are to require a header >> field that indicates that UTF-8 information is present. The >> MTA must perform a header scan to determine whether that >> UTF-8-indicating header is present and add it if it is not. >> We generally try to avoid requiring MTAs to perform such >> header scans -- the historical model says that that, other >> than submission and delivery MTAs, they don't do it. This >> is, incidentally, one of several reasons I've been reluctant >> to agree to the requirement for such a header field -- it >> does have side-effects. > > I think an intermediate MTA that needs to know whether it is > dealing with an extended email or not has a choice. Either it > looks for the presence of the UTF-8-indicating header, or it > looks for the presence of a bit-8 (or maybe it does a proper > UTF-8 test, as we have been discussing). Implementor's choice. > > However, as regards the Received header it would, in > principle, be nice to have it in UTF-8 wherever possible, but > there are snags. But I am not sure this is one of them. The > case we are considering (possible necessity to insert a > UTF-8-indicating header if we have just created a "for > clause") will be rare: it only arises if the RCPT address is > UTF-8 and the To: header is not (otherwise the > UTF-8-indicating header would already be present). Or the MAIL address is UTF-8 and the "From:" header is not, which might occur at least as often. > Moreover, > the "for" clause can safely be left in UTF-8 if we are > forwarding to another IMA-compliant MTA, and if we are not, > then we shall have to use the alternate (or a downgraded) > address, in which case the "for" clause might as well contain > the alternate/downgraded address. > > Tne real problem, of course, is that a Received header with > UTF-8 in it will eventually arrive at a non-compliant MTA, > and therfore we need to define a means to downgrade Received > headers. That is, indeed, the key problem. And downgrading Received headers violates the very explicit 2821 prohibition on messing with prior Received headers, so this is not a step to be taken lightly. >> Since "for" is optional, one possibility would be to carry >> "for" information in UTF-8 up to the point that downgrade >> needed to occur, then drop it from all trace fields in which >> it appears. > > What is current practice with regard to inserting the "for" > clause? If a message passes through a chain of intermediate > MTAs, then surely the "for" clause needs to be written only > once, except in the case where the envelope address gets > altered en route (e.g. by a mail-list expander). The current practice is, more or less, what 2821 specifies. As a crude summary: (i) Insertion of "for" is _always_ optional. (ii) Insertion for "for" is discouraged when there is more than one recipient and strongly discouraged if there are recipients who are not explicitly listed in the headers. Either can be a security problem in terms of giving away too much information; the second will almost certainly be such a problem. (iii) MTAs that insert "for" do so from the envelope information available to them. I don't know of any MTA (although there are probably some out there) that decides to not put a "for" in because one was there in a previous trace header. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed May 03 06:54:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbEzj-0004yI-Vt; Wed, 03 May 2006 06:54:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbEzi-0004yA-EX for ima@ietf.org; Wed, 03 May 2006 06:54:10 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbEzf-0001jY-G9 for ima@ietf.org; Wed, 03 May 2006 06:54:10 -0400 Received: from host81-144-65-80.midband.mdip.bt.net ([81.144.65.80]) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 44588bcd.17fb7.c6 for ima@ietf.org; Wed, 3 May 2006 11:54:05 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k43AfCe26062 for ; Wed, 3 May 2006 11:41:12 +0100 (BST) Date: Wed, 03 May 2006 11:41:11 +0100 To: ima@ietf.org Subject: Re: [EAI] clarify Received header format References: <7CBD5124899C455E33836CA9@p3.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: <7CBD5124899C455E33836CA9@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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, 03 May 2006 02:54:12 +0100, John C Klensin wrote: > --On Tuesday, 02 May, 2006 19:20 +0100 Charles Lindsey > wrote: >> Tne real problem, of course, is that a Received header with >> UTF-8 in it will eventually arrive at a non-compliant MTA, >> and therfore we need to define a means to downgrade Received >> headers. > > That is, indeed, the key problem. And downgrading Received > headers violates the very explicit 2821 prohibition on messing > with prior Received headers, so this is not a step to be taken > lightly. When it comes to downgrading headers, there are broadly two cases to consider: 1. Headers which need to play some part in the protocol. E.g. From/Reply-To, which will be used when generating replies; Content-Type, which will determine how the MUA displays the message; References, Date and Subject, which may be used by the MUA to determine the ordering of messages for presentation (and maybe for filtering). These headers need to be recognizable (and even processible) in their downgraded form by various agents 2. Headers which are primarily for human consumption (usually for troubleshooting purposes). Keywords; the various Resent-*s; X-headers of all sorts; and of course Received. If the human sees one of these in downgraded form, then he may need to have a handy upgrading script to hand (though if he is the ultimate recipient his MUA maye have been kind enough to do the upgrade for him). For this 2nd class, a one-size-fits-all or last-resort downgrading mechanism is quite sufficient. For example, we could invent a new header 'Downgraded:', with syntax (hence use of RFC 2047 to encode any UTF-8 within it would be in order). For any header with no specific downgrade rule of its own, you would simply encapsulate the whole header within a Downgraded: header, using encoded-words as needed. A final MUA might well automatically upgrade it, restoring its original form. So a downgraded Received header would look like: Downgraded: Received: from ... by ... for <=?utf-8?Q?)&"$%&+!?=@example.com> which is easily reconstitutable to its original form. Obviously, encoding "Q" will usually be preferred to encoding "B", especially if the encoded-word includes more of the header than strictly necessary. -- 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 Wed May 03 11:29:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbJIa-0004ZW-20; Wed, 03 May 2006 11:29:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbJIZ-0004ZK-3g for ima@ietf.org; Wed, 03 May 2006 11:29:55 -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 1FbIY6-00031u-RP for ima@ietf.org; Wed, 03 May 2006 10:41:54 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FbIBE-0005cO-9v for ima@ietf.org; Wed, 03 May 2006 10:18:20 -0400 Received: from host81-144-67-242.midband.mdip.bt.net ([81.144.67.242]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 4458bba2.b5b2.a8 for ima@ietf.org; Wed, 3 May 2006 15:18:10 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k43DlCe28455 for ; Wed, 3 May 2006 14:47:12 +0100 (BST) Date: Wed, 03 May 2006 14:47:11 +0100 To: ima@ietf.org Subject: Re: [EAI] help to define Ucharacter and sub-domain by ABNF References: <006401c66a71$e35f2530$1206e29f@cnnicyaojk> 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: <006401c66a71$e35f2530$1206e29f@cnnicyaojk> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 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, 28 Apr 2006 04:14:40 +0100, YAO Jiankang wrote: > Dear all, > Could some kind experts help to refine the below definition of > Ucharacter and sub-domain by ABNF in the IMA SMTP extension document? > It seems not easy to find a very good appropriate definition. Presumably you are asking this with regard to the smtpext document. However, it might be better to establish the syntax for the utf8headers document first. Sometime ago, I promised to dig out the syntactic changes we made in the USEFOR WG at a time when we were considering I18N of headers for Netnews, and particularly for the Newsgroups header. We never went ahead with this (though we might go back to it once this present IMA work is completed). So the following syntax is taken from http://www.imc.org/ietf-usefor/drafts/draft-ietf-usefor-article-09.unpaged, with changes made to accomodate it to the IMA project. It also shows up some syntactic issues that we need to think about. It is not, of course, the only way to go about defining this syntax, but I hope it is of use. UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 [Then you can say that s are further restricted by normalizing them to level NFC, and in other ways as set out in draft-klensin-net-utf8-00.txt] UTF8-2 = %xC2-DF UTF8-tail UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2(UTF8-tail) / %xED %x80-9F UTF8-tail / %xEE-EF 2(UTF8-tail) UTF8-4 = %xF0 %x90-BF 2(UTF8-tail) / %xF1-F7 3(UTF8-tail) [Those three are taken from RFC 3629, so maybe do not need to be repeated] [The next rules are intended to supersede the corresponding rules in RFC 2822 (though we might decide that they should not be given free rein in the obs-syntax)] ctext = NO-WS-CTL / ; all of except %d33-39 / ; SP, HTAB, "(", ")" %d42-91 / ; and "\" %d93-126 / UTF8-xtra-char [That gives you UTF-8 in comments] qtext = NO-WS-CTL / ; all of except %d33 / ; SP, HTAB, "\" and DQUOTE %d35-91 / %d93-126 / UTF8-xtra-char [That gives you UTF-8 in quoted-strings, and hence in phrases. It also gives you UTF-8 on the RHS of parameters as defined in RFC 2045, but this needs to be pointed out as an extension to RFC 2045 (with RFC 2231 used as the downgrade).] text = %d1-9 / ; all UTF-8 characters except %d11-12 / ; US-ASCII NUL, CR and LF %d14-127 / UTF8-xtra-char [That gives you UTF-8 in quoted-pairs] utext = NO-WS-CTL / ; Non white space controls %d33-126 / ; The rest of US-ASCII UTF8-xtra-char unstructured = 1*( [FWS] utext ) [FWS] [So now we have covered all the cases where RFC 2047 is currently used (and will still be used for downgrades)] atext = ALPHA / DIGIT / "!" / "#" / ; Any character except "$" / "%" / ; controls, SP, and specials. "&" / "'" / ; Used for atoms "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / UTF8-xtra-char [That gives you UTF-8 in local-parts (quoted or not) and in domains, but it needs careful examination to see whether we have gone too far] addr-spec = local-part "@" domain local-part = ( dot-atom / quoted-string ) [ atomic ] atomic = ??????????????? [It is quite unclear to me what the syntax of is intended to be, but since it applies to local-parts it seems to belong here. Presumably it MUST be absent unless either the dot-atom or the quoted-string contains some UTF8-xtra-char.] angle-addr = [CFWS] "<" addr-spec [ alt-address ] ">" [CFWS] alt-address = alt-separator strict-addr alt-separator = <"," or "|" or whatewver we decide, possibly with some WSP or FWS around it> [ will be more or less the as currently defined in RFC 2822. The syntax follows - it is extremely tedious, because it has to undo all the changes made to intorduce UTF-8, but here it is, anyway.] strict-addr = strict-local-part "@" strict-domain strict-local-part = strict-dot-atom / strict-quoted-string strict-dot-atom = [CFWS] strict-dot-atom-text [CFWS] strict-dot-atom-text = 1*strict-atext *( "." 1*strict-atext 0 strict-atext = ALPHA / DIGIT / "!" / "#" / ; Any character except "$" / "%" / ; controls, SP, and specials. "&" / "'" / ; Used for atoms "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" strict-quoted-string = [CFWS] DQUOTE *( [FWS] strict-qcontent ) [FWS] DQUOTE [CFWS] strict-qcontent = strict-qtext / strict-quoted-pair strict-qtext = NO-WS-CTL / ; qtext restricted to %d33 / ; US-ASCII %d35-91 / %d93-126 strict-quoted-pair = "\" strict-text strict-text = %d1-9 / ; text restricted to %d11-12 / ; US-ASCII %d14-127 [Here the possibilities divide. If you are going to use "," as the , then you simply say:] strict-domain = strict-dot-atom / domain-literal [The defined by RFC 2822 already allows many things, including most of ASCII, that do not really belong in IP addresses. I hope nobody is suggesting allowing any UTF-8 in there.] [But if you want to use "|" as the , then it would be better to restrict the domains in an alt-address to what RFC 2821 will accept.] strict-domain = (sub-domain 1*("." sub-domain)) / address-literal sub-domain = Let-dig [Ldh-str] address-literal = "[" IPv4-address-literal / IPv6-address-literal / General-address-literal "]" [Though I do not altogether like the from RFC 2821, and I gather that implementors may not actually be following 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 Wed May 03 12:05:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbJrB-0006jm-9C; Wed, 03 May 2006 12:05:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbJr9-0006jh-U0 for ima@ietf.org; Wed, 03 May 2006 12:05:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbIY6-00031u-Tz for ima@ietf.org; Wed, 03 May 2006 10:41:54 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FbIBE-0005cP-9q for ima@ietf.org; Wed, 03 May 2006 10:18:19 -0400 Received: from host81-144-67-242.midband.mdip.bt.net ([81.144.67.242]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 4458bba1.b5b2.a7; Wed, 3 May 2006 15:18:09 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k43EEre28721; Wed, 3 May 2006 15:14:53 +0100 (BST) To: ima@ietf.org Date: Wed, 03 May 2006 15:14: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 Message-ID: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: the.map|@alum.mit.edu Subject: [EAI] First comments on draft-klensin-net-utf8-oo.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 This seems mostly good, as setting the lowest level of what should be allowed to pass over the internet. Naturally, individual protocols may be more restrictive (e.g. by requiring stronger normalization). What is not clear is whether recipient agents can assume, without checking, that what they receive is compliant to this spec (i.e. anything that arrived that was not conformant would result in "garbage in - garbage out". It seems to be the intent of the Unicode people (according to their "early normalization" principle) that such assumptions could be made. For example, do current agents, in general, check for strict conformance with NVT? The other matter is what to do about future versions of Unicode. My suggestion is that it would be better to say that code points classed as "Not assigned" MUST NOT be used. That means "Not assigned" in the version of Unicode that the generator of the text is using, and hence it means that he MUST use the definition of NFC contained in that same version. Since this spec is essentially to be observed by those who _generate_ texts, observance of this rule would be sufficient to prevent un-NFC-normalized texts appearing on the internet even for NFC normalizations not yet invented. This, of course, assumes that the Unicode people do not alter the normalizations for any code point already assigned, but they seem pretty good at avoiding such pitfalls. It would still allow them to invent new normalizations when new code points were assigned. -- 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 Wed May 03 13:52:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbLWk-0002Tw-V8; Wed, 03 May 2006 13:52:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbLWj-0002Tr-Qj for ima@ietf.org; Wed, 03 May 2006 13:52:41 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbLWj-0002Yw-DO for ima@ietf.org; Wed, 03 May 2006 13:52:41 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FbLWe-000G5E-6V; Wed, 03 May 2006 13:52:36 -0400 Date: Wed, 03 May 2006 13:52:35 -0400 From: John C Klensin To: Charles Lindsey , ima@ietf.org Subject: Re: [EAI] First comments on draft-klensin-net-utf8-oo.txt Message-ID: <617FA4967C5A4F8E551B3BE8@p3.JCK.COM> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: the.map@alum.mit.edu 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, 03 May, 2006 15:14 +0100 Charles Lindsey wrote: > This seems mostly good, as setting the lowest level of what > should be allowed to pass over the internet. Well, that is not quite the intent. And it is _not_ a work item for the EAI WG. > Naturally, > individual protocols may be more restrictive (e.g. by > requiring stronger normalization). > > What is not clear is whether recipient agents can assume, > without checking, that what they receive is compliant to this > spec (i.e. anything that arrived that was not conformant > would result in "garbage in - garbage out". It seems to be > the intent of the Unicode people (according to their "early > normalization" principle) that such assumptions could be made. > For example, do current agents, in general, check for strict > conformance with NVT? I think the robustness principle necessarily applies. For protocols that specify this form, recipient agents can rationally assume that they form is in use, but still need to protect themselves against serious violations. I would expect better-quality implementations to go beyond that in what they accept, especially if they are sent trash often enough that market forces drive them in that direction. > The other matter is what to do about future versions of > Unicode. My suggestion is that it would be better to say that > code points classed as "Not assigned" MUST NOT be used. That > means "Not assigned" in the version of Unicode that the > generator of the text is using, and hence it means that he > MUST use the definition of NFC contained in that same version. > Since this spec is essentially to be observed by those who > _generate_ texts, observance of this rule would be sufficient > to prevent un-NFC-normalized texts appearing on the internet > even for NFC normalizations not yet invented. Note that, if UTC never adds another precomposed character to the collection, which they say they have promised to do, then there will never be a new NFC normalization. More broadly, if this specification applies to general-purpose text, rather than something that we can restrict further for good reason within a particular protocol, I think it is plausible to assume that people will send whatever codes they need, for whatever characters they need, from whatever version of Unicode is current (or current enough to contain those characters). Saying "don't do it" will almost certainly be ignored, and we are better off designing under that assumption. > This, of course, assumes that the Unicode people do not alter > the normalizations for any code point already assigned, but > they seem pretty good at avoiding such pitfalls. It would > still allow them to invent new normalizations when new code > points were assigned. See above. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri May 05 09:20:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc0E5-0006XG-39; Fri, 05 May 2006 09:20:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc0E3-0006XB-Sf for ima@ietf.org; Fri, 05 May 2006 09:20:07 -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 1Fc0E3-0003eL-FS for ima@ietf.org; Fri, 05 May 2006 09:20:07 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Fc0Dx-000KZf-NZ; Fri, 05 May 2006 09:20:02 -0400 Date: Fri, 05 May 2006 09:20:00 -0400 From: John C Klensin To: Charles Lindsey , ima@ietf.org Subject: Re: [EAI] First comments on draft-klensin-net-utf8-oo.txt Message-ID: <274D0C7993FB9056D251EF55@p3.JCK.COM> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: the.map@alum.mit.edu 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, 03 May, 2006 15:14 +0100 Charles Lindsey wrote: > This seems mostly good, as setting the lowest level of what > should be allowed to pass over the internet. Well, that is not quite the intent. And it is _not_ a work item for the EAI WG. > Naturally, > individual protocols may be more restrictive (e.g. by > requiring stronger normalization). > > What is not clear is whether recipient agents can assume, > without checking, that what they receive is compliant to this > spec (i.e. anything that arrived that was not conformant > would result in "garbage in - garbage out". It seems to be > the intent of the Unicode people (according to their "early > normalization" principle) that such assumptions could be made. > For example, do current agents, in general, check for strict > conformance with NVT? I think the robustness principle necessarily applies. For protocols that specify this form, recipient agents can rationally assume that they form is in use, but still need to protect themselves against serious violations. I would expect better-quality implementations to go beyond that in what they accept, especially if they are sent trash often enough that market forces drive them in that direction. > The other matter is what to do about future versions of > Unicode. My suggestion is that it would be better to say that > code points classed as "Not assigned" MUST NOT be used. That > means "Not assigned" in the version of Unicode that the > generator of the text is using, and hence it means that he > MUST use the definition of NFC contained in that same version. > Since this spec is essentially to be observed by those who > _generate_ texts, observance of this rule would be sufficient > to prevent un-NFC-normalized texts appearing on the internet > even for NFC normalizations not yet invented. Note that, if UTC never adds another precomposed character to the collection, which they say they have promised to do, then there will never be a new NFC normalization. More broadly, if this specification applies to general-purpose text, rather than something that we can restrict further for good reason within a particular protocol, I think it is plausible to assume that people will send whatever codes they need, for whatever characters they need, from whatever version of Unicode is current (or current enough to contain those characters). Saying "don't do it" will almost certainly be ignored, and we are better off designing under that assumption. > This, of course, assumes that the Unicode people do not alter > the normalizations for any code point already assigned, but > they seem pretty good at avoiding such pitfalls. It would > still allow them to invent new normalizations when new code > points were assigned. See above. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri May 05 19:22:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc9ce-0008W7-9l; Fri, 05 May 2006 19:22:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc9cd-0008W2-Hl for ima@ietf.org; Fri, 05 May 2006 19:22:07 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc9cb-0006rN-LG for ima@ietf.org; Fri, 05 May 2006 19:22:07 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k45NM4SX000266 for ; Fri, 5 May 2006 17:22:04 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IYT00F01FC6OE00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Fri, 05 May 2006 17:22:04 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IYT00A2CFKQSU00@mail-amer.sun.com>; Fri, 05 May 2006 17:22:04 -0600 (MDT) Date: Fri, 05 May 2006 16:25:16 -0700 From: Chris Newman Subject: Re: [EAI] clarify Received header format In-reply-to: <20060502.180948.41651497.fujiwara@jprs.co.jp> To: fujiwara@jprs.co.jp, ima@ietf.org Message-id: <7A0C9327FB198FE371C60436@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <20060502.180948.41651497.fujiwara@jprs.co.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 I agree it's absolutely critical to have the UTF-8 address in the Received header for diagnostic purposes. 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). I suggest we require 7-bit in all syntactic parts of the Received headers except for comments where we permit UTF-8. 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). - Chris fujiwara@jprs.co.jp wrote on 5/2/06 18:09 +0900: > draft-yao-ima-smtpext-02.txt section 2.5.2. Trace Fields is ambiguous. > > 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. > > This Received header format may be defined in utf8header draft and > smtpext draft refer it. > > Without clear Received header definition, implementation is impossible. > > In my opinion, addresses in "for" clauses should be IMA itself and > should be UTF-8 encoded. > > And more, I want to record ALT-ADDR, ATOMIC parameter information. > > "i18n-email: 1.0" header may be added by MTA > as a result of adding Received header or IMA-Downgraded-* header. > > -- > Kazunori Fujiwara, JPRS > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun May 07 07:06:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fch4t-0006Is-6m; Sun, 07 May 2006 07:05:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fch4s-0006Ii-Dj for ima@ietf.org; Sun, 07 May 2006 07:05:30 -0400 Received: from [159.226.7.146] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fch4q-0003D5-Oq for ima@ietf.org; Sun, 07 May 2006 07:05:30 -0400 Received: (eyou send program); Sun, 07 May 2006 19:05:14 +0800 Message-ID: <346999914.16683@cnnic.cn> X-EYOUMAIL-SMTPAUTH: lee@cnnic.cn Received: from unknown (HELO [61.149.91.59]) (127.0.0.1) by 127.0.0.1 with SMTP; Sun, 07 May 2006 19:05:14 +0800 Message-ID: <445DD46B.3030409@cnnic.cn> Date: Sun, 07 May 2006 19:05:15 +0800 From: "Xiaodong(Sheldon) Lee" Organization: CNNIC User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ima@ietf.org, IETF Announcement list Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [EAI] EAI WG Interim Meeting 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 The EAI WG will hold an interim meeting to prompt the working process of the WG. Meeting Time: June 5, 2006( From 9:00 am to 18:00 pm) ( Note: We change the meeting time from June1/2 to June 5 to avoid conflict with other interim meeting) Local Host: China Internet Network Information Center(CNNIC) Meeting Venue: Conference Center of Computer Network Information Center, Chinese Academy of Sciences The 5th floor, Building 2, No.4 South 4th Street, ZhongGuanCun, Beijing, 100080, China Meeting Facilities: 1) The meeting room can support less than 100 persons 2) Wireless internet access will be availabe 3) IP-based Video conference facilities will be available, the address will be announce in one week later. Hotels: 1) Jade Palace Hotel(five star) http://www.jadepalace.com.cn/ (10 minutes to meeting venue by walk) 2) TianHong Plaza Hotel(four star) http://www.tianhongplaza.com/ (15 minutes to meeting venue by walk) If you need the local host to book hotel for you, please send email to me, including your requirement and budget. Proposed Agenda: 1) Drafts review ( Suggest you to read all the published drafts before attending this meeting, including framework, smtpext, utf8headers, downgrade, and etc. ) 2) *Testing plan( more email software developers providers or vendors are welcome to joining) 3) Open issues (TBD) Please add more issues into agenda, if needed. Please send your name to the WG co-chairs, if you plan to attend this interim meeting. And that, if you need invitation letter to get visa, send request to co-chairs, too. Harald Alvestrand & Xiaodong Lee EAI WG co-chairs _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon May 08 02:02:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fcyog-0003uW-Va; Mon, 08 May 2006 02:01:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fcyof-0003uR-Vj for ima@ietf.org; Mon, 08 May 2006 02:01:57 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fcyob-0006Ec-Aj for ima@ietf.org; Mon, 08 May 2006 02:01:57 -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 k4861gR9028129 for ; Mon, 8 May 2006 15:01:43 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2006050815014217012 for ; Mon, 08 May 2006 15:01:42 +0900 Date: Mon, 08 May 2006 15:01:42 +0900 (JST) Message-Id: <20060508.150142.115925723.fujiwara@jprs.co.jp> To: ima@ietf.org From: fujiwara@jprs.co.jp In-Reply-To: <7A0C9327FB198FE371C60436@[10.1.110.5]> References: <20060502.180948.41651497.fujiwara@jprs.co.jp> <7A0C9327FB198FE371C60436@[10.1.110.5]> X-Mailer: Mew version 5.0.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [EAI] downgrading and Received header changing 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'm afraid that downgrading changes Received header. There are three possible header downgrading idea. draft-yoneya-ima-downgrade-01.txt describes 1 and 3. idea 1. Header by header conversion Rewrite all headers to be US-ASCII. Received: from ... by ... for -> Received: from ... by ... for <__RFC2047__(IMA)> idea 2. Header encapsulation define new encapsulated header and replace original header with encapsulated header. Received: from ... by ... for IMA -> IMA-Encapsulated: Received: encapsulate(from ... by ... for IMA) or -> IMA-Encapsulated: Received: from ... by ... for encapsulate(IMA) idea 3. MIME encapsulation generate new MIME part Message/EAI. Received field is preserved in MIME part. RFC 2821 Section 4.4 Trace Information says: An Internet mail program MUST NOT change a Received: line that was previously added to the message header. idea 1: Received header's for clause is modified to be equivalent US-ASCII form, other clauses are visible, Received header line number is preserved. idea 2: Received header information is preserved, Received header line number is initialized to be zero in downgraded header. idea 3: Received header information is preserved, Received header line number is initialized to be zero in downgraded (outer) header. All three may break RFC 2821 Section 4.4. > From: "Charles Lindsey" > On Wed, 03 May 2006 02:54:12 +0100, John C Klensin wrote: > > > --On Tuesday, 02 May, 2006 19:20 +0100 Charles Lindsey > > wrote: > > >> Tne real problem, of course, is that a Received header with > >> UTF-8 in it will eventually arrive at a non-compliant MTA, > >> and therfore we need to define a means to downgrade Received > >> headers. > > > > That is, indeed, the key problem. And downgrading Received > > headers violates the very explicit 2821 prohibition on messing > > with prior Received headers, so this is not a step to be taken > > lightly. > > When it comes to downgrading headers, there are broadly two cases to > consider: > > 1. Headers which need to play some part in the protocol. E.g. > From/Reply-To, which will be used when generating replies; Content-Type, > which will determine how the MUA displays the message; References, Date > and Subject, which may be used by the MUA to determine the ordering of > messages for presentation (and maybe for filtering). These headers need to > be recognizable (and even processible) in their downgraded form by various > agents In my opinion, downgrading is required for not to break existing mail infrastructure and to send messages to final destination if at all possible. Whether recipients can read or not is secondary issue. IMA compliant MUA can decode downgraded message. > 2. Headers which are primarily for human consumption (usually for > troubleshooting purposes). Keywords; the various Resent-*s; X-headers of > all sorts; and of course Received. If the human sees one of these in > downgraded form, then he may need to have a handy upgrading script to hand > (though if he is the ultimate recipient his MUA maye have been kind enough > to do the upgrade for him). > > For this 2nd class, a one-size-fits-all or last-resort downgrading > mechanism is quite sufficient. For example, we could invent a new header > 'Downgraded:', with syntax (hence use of RFC 2047 to encode > any UTF-8 within it would be in order). For any header with no specific > downgrade rule of its own, you would simply encapsulate the whole header > within a Downgraded: header, using encoded-words as needed. A final MUA > might well automatically upgrade it, restoring its original form. > > So a downgraded Received header would look like: > > Downgraded: Received: from ... by ... for > <=?utf-8?Q?)&"$%&+!?=@example.com> > > which is easily reconstitutable to its original form. Obviously, encoding > "Q" will usually be preferred to encoding "B", especially if the > encoded-word includes more of the header than strictly necessary. This header downgrading is useful and may be added to downgrade ID. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon May 08 04:20:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd0y0-0005A4-BW; Mon, 08 May 2006 04:19:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd0vF-0004ZH-F0 for ima@ietf.org; Mon, 08 May 2006 04:16:53 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd0qt-0005ni-H9 for ima@ietf.org; Mon, 08 May 2006 04:12: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 k488C5RB001589; Mon, 8 May 2006 17:12:10 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2006050817121018733 ; Mon, 08 May 2006 17:12:10 +0900 Date: Mon, 08 May 2006 17:12:10 +0900 (JST) Message-Id: <20060508.171210.48512021.fujiwara@jprs.co.jp> To: klensin@jck.com Subject: Re: [EAI] downgrading and Received header changing From: fujiwara@jprs.co.jp In-Reply-To: <9D3FFBFE3C39FB225420B549@[172.30.11.198]> References: <9D3FFBFE3C39FB225420B549@[172.30.11.198]> X-Mailer: Mew version 5.0.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Dear John, > From: John C Klensin > Fujiwara-san, > > If the interim meeting comes together, I hope we can work > through these cases with a whiteboard. I'm planning to participate. > My own -- tentative -- position is that breaking section 4.4 of > 2821 would be a very bad idea, at least if there are > alternatives. That is one of the rules that was established > after long, bad, experience and I'd be hesitant to abandon it. Agree. for example, removing received header (and save it to another place) may break mail loop detection. rewriting "for" clause may be one of possible solutions. > I see at least two alternatives you didn't list. I'm not > proposing either, but we should know they are alternatives. One > is simply to not use "for" when the address is non-ASCII. As I > mentioned in my note to Charles, because of the security issues, > its value may be somewhat overrated. The other possibility is > to decide that, if an i18n "for" is present, the downgrading > system must go into full conversion-gateway mode, encapsulating > the old message (trace headers and all) and putting _only_ the > gateway headers in the outbound message. full conversion-gateway mode may be MIME encapsulation downgrading method, I think. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon May 08 04:47:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd1PD-0007Qw-Q5; Mon, 08 May 2006 04:47:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd1PC-0007Qp-9x for ima@ietf.org; Mon, 08 May 2006 04:47:50 -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 1Fd0Sd-0003mE-PQ for ima@ietf.org; Mon, 08 May 2006 03:47:19 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fd0G1-0001cf-CV for ima@ietf.org; Mon, 08 May 2006 03:34:23 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Fd0G0-0003zk-5q; Mon, 08 May 2006 03:34:16 -0400 Date: Mon, 08 May 2006 03:34:14 -0400 From: John C Klensin To: fujiwara@jprs.co.jp Subject: Re: [EAI] downgrading and Received header changing Message-ID: <9D3FFBFE3C39FB225420B549@[172.30.11.198]> 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.4 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Fujiwara-san, If the interim meeting comes together, I hope we can work through these cases with a whiteboard. My own -- tentative -- position is that breaking section 4.4 of 2821 would be a very bad idea, at least if there are alternatives. That is one of the rules that was established after long, bad, experience and I'd be hesitant to abandon it. I see at least two alternatives you didn't list. I'm not proposing either, but we should know they are alternatives. One is simply to not use "for" when the address is non-ASCII. As I mentioned in my note to Charles, because of the security issues, its value may be somewhat overrated. The other possibility is to decide that, if an i18n "for" is present, the downgrading system must go into full conversion-gateway mode, encapsulating the old message (trace headers and all) and putting _only_ the gateway headers in the outbound message. john --On Monday, May 08, 2006 15:01 +0900 fujiwara@jprs.co.jp wrote: > I'm afraid that downgrading changes Received header. > > There are three possible header downgrading idea. > > draft-yoneya-ima-downgrade-01.txt describes 1 and 3. > > idea 1. Header by header conversion > > Rewrite all headers to be US-ASCII. > > Received: from ... by ... for > -> Received: from ... by ... for <__RFC2047__(IMA)> > > idea 2. Header encapsulation > > define new encapsulated header and replace original header > with encapsulated header. > > Received: from ... by ... for IMA > -> IMA-Encapsulated: Received: encapsulate(from ... by > ... for IMA) or > -> IMA-Encapsulated: Received: from ... by ... for > encapsulate(IMA) > > idea 3. MIME encapsulation > > generate new MIME part Message/EAI. > Received field is preserved in MIME part. > > RFC 2821 Section 4.4 Trace Information says: > An Internet mail program MUST NOT change a Received: line > that was previously added to the message header. > > idea 1: > > Received header's for clause is modified to be equivalent > US-ASCII form, other clauses are visible, Received header > line number is preserved. > > idea 2: > > Received header information is preserved, Received header > line number is initialized to be zero in downgraded > header. > > idea 3: > > Received header information is preserved, Received header > line number is initialized to be zero in downgraded > (outer) header. > > All three may break RFC 2821 Section 4.4. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon May 08 06:38:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd38O-0006w3-CV; Mon, 08 May 2006 06:38:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd38O-0006vy-25 for ima@ietf.org; Mon, 08 May 2006 06:38:36 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd38M-0006d3-Op for ima@ietf.org; Mon, 08 May 2006 06:38:36 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 36F0D259702; Mon, 8 May 2006 12:37:58 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22067-01; Mon, 8 May 2006 12:37:54 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7C7BD2596F7; Mon, 8 May 2006 12:37:54 +0200 (CEST) Message-ID: <445F1FA6.1000308@alvestrand.no> Date: Mon, 08 May 2006 12:38:30 +0200 From: Harald Alvestrand User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051011) X-Accept-Language: en-us, en MIME-Version: 1.0 To: fujiwara@jprs.co.jp Subject: Re: [EAI] downgrading and Received header changing References: <9D3FFBFE3C39FB225420B549@[172.30.11.198]> <20060508.171210.48512021.fujiwara@jprs.co.jp> In-Reply-To: <20060508.171210.48512021.fujiwara@jprs.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 fujiwara@jprs.co.jp wrote: > >> The other possibility is >>to decide that, if an i18n "for" is present, the downgrading >>system must go into full conversion-gateway mode, encapsulating >>the old message (trace headers and all) and putting _only_ the >>gateway headers in the outbound message. >> >> > >full conversion-gateway mode may be MIME encapsulation downgrading >method, I think. > I am still doubtful that a MIME-encapsulated downgrade message will have an acceptable value when it is delivered to an ASCII-only recipient. I'd be hesitant to require encapsulation because of Received: headers. So far, there has been no response to the call for a scenario where the encapsulation is useful/needed for inclusion in the scenarios document. Until that arrives, I can't conclude that the WG has consensus it's needed. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue May 09 02:09:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdLOy-0000Ht-1U; Tue, 09 May 2006 02:08:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdLOx-0000Hj-1N for ima@ietf.org; Tue, 09 May 2006 02:08:55 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdLOs-0004YF-98 for ima@ietf.org; Tue, 09 May 2006 02:08:51 -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 k4968bR9010831; Tue, 9 May 2006 15:08:37 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2006050915083723233 ; Tue, 09 May 2006 15:08:37 +0900 Date: Tue, 09 May 2006 15:08:36 +0900 (JST) Message-Id: <20060509.150836.74747698.fujiwara@jprs.co.jp> To: harald@alvestrand.no Subject: Re: [EAI] downgrading and Received header changing From: fujiwara@jprs.co.jp In-Reply-To: <445F1FA6.1000308@alvestrand.no> References: <9D3FFBFE3C39FB225420B549@[172.30.11.198]> <20060508.171210.48512021.fujiwara@jprs.co.jp> <445F1FA6.1000308@alvestrand.no> X-Mailer: Mew version 5.0.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 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 > From: Harald Alvestrand > >full conversion-gateway mode may be MIME encapsulation downgrading > >method, I think. > > > I am still doubtful that a MIME-encapsulated downgrade message will have > an acceptable value when it is delivered to an ASCII-only recipient. I'd > be hesitant to require encapsulation because of Received: headers. Received header problem exists on both header conversion method and MIME encapsulation method. (problem seriousness is different depending on the methods.) We need to compare downgrading methods on requirements, advantages and disadvantages, permited or not on the previours standards. > So far, there has been no response to the call for a scenario where the > encapsulation is useful/needed for inclusion in the scenarios document. > Until that arrives, I can't conclude that the WG has consensus it's needed. I try to write 'downgrading' scenario with two downgrading methods, and write implementation idea/memo/requirements for each entity. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue May 09 12:59:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdVYZ-0002Mn-0l; Tue, 09 May 2006 12:59:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdVYY-0002KP-M0 for ima@ietf.org; Tue, 09 May 2006 12:59:30 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdVYX-0002hA-3I for ima@ietf.org; Tue, 09 May 2006 12:59:30 -0400 Received: from host81-144-65-66.midband.mdip.bt.net ([81.144.65.66]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.214) id 4460ca6f.69e5.16 for ima@ietf.org; Tue, 9 May 2006 17:59:27 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k49Gt4e21635 for ; Tue, 9 May 2006 17:55:05 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] downgrading and Received header changing References: <9D3FFBFE3C39FB225420B549@[172.30.11.198]> <20060508.171210.48512021.fujiwara@jprs.co.jp> <445F1FA6.1000308@alvestrand.no> <20060509.150836.74747698.fujiwara@jprs.co.jp> Message-ID: Date: Tue, 09 May 2006 17:55: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: <20060509.150836.74747698.fujiwara@jprs.co.jp> User-Agent: Opera M2/8.01 (SunOS, build 1204) 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, 09 May 2006 07:08:36 +0100, wrote: > Received header problem exists on both header conversion method and > MIME encapsulation method. (problem seriousness is different depending > on the methods.) But in either event is it some human reader who is going to have to disentangle it. So for a human, seeing something like Downngraded: Received ..... where otherwise he would have expected Received:, should not be too difficult to decipher (especially if his MUA has kindly translated any RF2047 encoded-words inside it). OTOH, ordinary readers, not particularly interested in inspecting the Received headers, are unlikely to be impressed at receiving a message with no body and the real message as an attachment of type message/rfc2822 (even if it IS displayed inline, which cannot be guaranteed). > > We need to compare downgrading methods on requirements, advantages and > disadvantages, permited or not on the previours standards. > Yes. I think it would be nice to see complete examples using both methods. -- 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 May 09 15:52:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdYFO-00023O-Il; Tue, 09 May 2006 15:51:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdYFN-00022s-80 for ima@ietf.org; Tue, 09 May 2006 15:51:53 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdYFM-0001Lh-FY for ima@ietf.org; Tue, 09 May 2006 15:51:53 -0400 Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k49JppIH018206 for ; Tue, 9 May 2006 13:51:52 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZ000301KE6HZ00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Tue, 09 May 2006 13:51:51 -0600 (MDT) Received: from [10.0.1.2] (216-165-224-133.championbroadband.com [216.165.224.133]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZ000MVPKHU1150@mail-amer.sun.com>; Tue, 09 May 2006 13:51:51 -0600 (MDT) Date: Tue, 09 May 2006 12:54:53 -0700 From: Chris Newman Subject: Re: [EAI] downgrading and Received header changing In-reply-to: <20060508.150142.115925723.fujiwara@jprs.co.jp> To: fujiwara@jprs.co.jp, ima@ietf.org Message-id: <28B83627E2CCBD3531D5721C@[10.0.1.2]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <20060502.180948.41651497.fujiwara@jprs.co.jp> <7A0C9327FB198FE371C60436@[10.1.110.5]> <20060508.150142.115925723.fujiwara@jprs.co.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org fujiwara@jprs.co.jp wrote on 5/8/06 15:01 +0900: > I'm afraid that downgrading changes Received header. > > There are three possible header downgrading idea. > > draft-yoneya-ima-downgrade-01.txt describes 1 and 3. > > idea 1. Header by header conversion > > Rewrite all headers to be US-ASCII. > > Received: from ... by ... for > -> Received: from ... by ... for <__RFC2047__(IMA)> This violates the ABNF of the "for" clause in Received. Thus it's not feasible. > idea 2. Header encapsulation > > define new encapsulated header and replace original header with > encapsulated header. > > Received: from ... by ... for IMA > -> IMA-Encapsulated: Received: encapsulate(from ... by ... for IMA) > or > -> IMA-Encapsulated: Received: from ... by ... for encapsulate(IMA) This is going to break things. Gateways, MUAs and other processing systems are permitted to re-order headers, except for trace headers (Received, Return-path). While we can introduce a new trace header, there's no guarantee order will be preserved by older MTAs and gateways (which goes against the whole point of encapsulation). As a result, I don't consider this option feasible for Received or Return-path. > idea 3. MIME encapsulation > > generate new MIME part Message/EAI. > Received field is preserved in MIME part. This would intrude into the user interface on many systems and thus I consider it not feasible. > All three may break RFC 2821 Section 4.4. What I'm suggesting is something like this: Received: from ... by ... for 7bit-addr@7bit-domain (utf8-addr@utf8-domain) And then grant a very limited exception to 2821 section 4.4 _only_ for 2047 down-conversion of 8-bit comments, so we get: Received: from ... by ... for 7bit-addr@7bit-domain (_RFC_2047_) This preserves the syntax of Received after down-conversion, no ordering problems or intrusion into the UI, and the exception to RFC 2821 section 4.4 should be sufficiently minor and non-destructive to avoid the problems that rule attempts to prevent. Now for cases where there is no 7-bit address, the comment could go after any clause (except date) and say (for utf8-addr@utf8-domain). - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed May 10 07:15:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdmeN-0008MR-PF; Wed, 10 May 2006 07:14:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdmeM-0008MM-6G for ima@ietf.org; Wed, 10 May 2006 07:14:38 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdmeK-0008O5-Id for ima@ietf.org; Wed, 10 May 2006 07:14:38 -0400 Received: from host81-144-65-156.midband.mdip.bt.net ([81.144.65.156] country=GB) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.217) id 4461cb0e.7b1c.59 for ima@ietf.org; Wed, 10 May 2006 12:14:22 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k4A92Le02455 for ; Wed, 10 May 2006 10:02:22 +0100 (BST) To: "ima@ietf.org" Subject: Re: [EAI] downgrading and Received header changing References: <20060502.180948.41651497.fujiwara@jprs.co.jp> <7A0C9327FB198FE371C60436@[10.1.110.5]> <20060508.150142.115925723.fujiwara@jprs.co.jp> <28B83627E2CCBD3531D5721C@[10.0.1.2]> Message-ID: Date: Wed, 10 May 2006 10:02: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: <28B83627E2CCBD3531D5721C@[10.0.1.2]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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, 09 May 2006 20:54:53 +0100, Chris Newman wrote: > fujiwara@jprs.co.jp wrote on 5/8/06 15:01 +0900: >> idea 2. Header encapsulation >> >> define new encapsulated header and replace original header with >> encapsulated header. >> >> Received: from ... by ... for IMA >> -> IMA-Encapsulated: Received: encapsulate(from ... by ... for >> IMA) >> or >> -> IMA-Encapsulated: Received: from ... by ... for >> encapsulate(IMA) > > This is going to break things. Gateways, MUAs and other processing > systems are permitted to re-order headers, except for trace headers > (Received, Return-path). While we can introduce a new trace header, > there's no guarantee order will be preserved by older MTAs and gateways > (which goes against the whole point of encapsulation). As a result, I > don't consider this option feasible for Received or Return-path. But do agents (transport agents in particular) actually do such reordering in practice? Surely all that the usual MTA does is to stick its own Received header at the top without even looking at the rest. In that case, and 'Received's that get downgraded to 'IMA-Encapsulated: Received...' will in fact retain their place in the list, at least during transport. The worst that can happen is that some agent somewhere will filter all the 'Received's to the top, in which case the poor human will have to merge the encapsulated ones back into the list - that is messy, but not impossible and maybe even automizable. I suspect that whatever we do is not going to be perfect, and we shall have to choose the best of a bad bunch. > What I'm suggesting is something like this: > > Received: from ... by ... for 7bit-addr@7bit-domain > (utf8-addr@utf8-domain) Yes, that looks an interesting possibility. Please could we have that added to the other examples that I have asked for. My main concern with it is that it works fione for "for", but can we be sure that UTF-8 will not arise in other (non-comment) components of the Received header? -- 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 Wed May 10 07:56:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdnIa-0007wS-FZ; Wed, 10 May 2006 07:56:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdnIZ-0007wN-FR for ima@ietf.org; Wed, 10 May 2006 07:56:11 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdnIX-0001oJ-Tg for ima@ietf.org; Wed, 10 May 2006 07:56:11 -0400 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id k4ABu2R9028690; Wed, 10 May 2006 20:56:02 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2006051020560132047 ; Wed, 10 May 2006 20:56:01 +0900 Date: Wed, 10 May 2006 20:56:01 +0900 (JST) Message-Id: <20060510.205601.48528611.fujiwara@jprs.co.jp> To: Chris.Newman@Sun.COM Subject: Re: [EAI] downgrading and Received header changing From: fujiwara@jprs.co.jp In-Reply-To: <28B83627E2CCBD3531D5721C@[10.0.1.2]> References: <7A0C9327FB198FE371C60436@[10.1.110.5]> <20060508.150142.115925723.fujiwara@jprs.co.jp> <28B83627E2CCBD3531D5721C@[10.0.1.2]> X-Mailer: Mew version 5.0.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 > From: Chris Newman > What I'm suggesting is something like this: > > Received: from ... by ... for 7bit-addr@7bit-domain (utf8-addr@utf8-domain) Is this 7bit-addr@7bit-domain alternate-ascii-address which is specified by Alt-Addr parameter? (without Alt-Address and with ATOMIC y, alternate-ascii-address is generated by punycode comversion of utf8@utf8.) In my understanding, if "for" clauses has ascii-alternative-address with utf8-address in comment field, the header shows that UTF8 address was used in that SMTP session. > And then grant a very limited exception to 2821 section 4.4 _only_ for 2047 > down-conversion of 8-bit comments, so we get: > > Received: from ... by ... for 7bit-addr@7bit-domain (_RFC_2047_) > > This preserves the syntax of Received after down-conversion, no ordering > problems or intrusion into the UI, and the exception to RFC 2821 section 4.4 > should be sufficiently minor and non-destructive to avoid the problems that > rule attempts to prevent. It's one candidate method. > Now for cases where there is no 7-bit address, the comment could go after any > clause (except date) and say (for utf8-addr@utf8-domain). > > - Chris > -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu May 11 01:07:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe3On-0004yS-3L; Thu, 11 May 2006 01:07:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe3Ol-0004yK-W0 for ima@ietf.org; Thu, 11 May 2006 01:07:39 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe3Ok-0004VF-FI for ima@ietf.org; Thu, 11 May 2006 01:07:39 -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 k4B57JRL004587 for ; Thu, 11 May 2006 14:07:37 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2006051114073602247 for ; Thu, 11 May 2006 14:07:36 +0900 Date: Thu, 11 May 2006 14:07:36 +0900 (JST) Message-Id: <20060511.140736.21926572.fujiwara@jprs.co.jp> To: ima@ietf.org From: fujiwara@jprs.co.jp X-Mailer: Mew version 5.0.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [EAI] Proposed Received header "for" clause encodings 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 Proposed Received header "for" clause encodings There are 4 encoding idea. Terminology: ima: utf8@utf8 ascii-address: ascii mail address (RFC2821) alt-ascii: ascii address which is specified by ALT-ADDR parameter atomic-ascii: ascii address which is converted from ima with punycode and IDNA. (punycode@IDNA) (1) not use "for" when the address is non-ASCII for ascii-address without ima with ima (2) for ima (Alt-Addr + Atomic information) for ascii-address without ima for ima (ALT-ADDR alt-ascii) ima with ALT-ADDR for ima (ATOMIC y) ima with ATOMIC y for ima ima without ALT-ADDR, ATOMIC (3) for ascii-address (ima) for ascii-address without ima for alt-ascii (ima) ima with ALT-ADDR for atomic-ascii (ima) ima without ALT-ADDR, with ATOMIC y for (ima) ima without ALT-ADDR, without ATOMIC (4) for ascii-adress (toascii_conversion of ima) a variation of (3), comment field is always converted to ascii. toascii_conversion method needs more consideration. it is used in (4) and downgrading with header conversion method. RFC2047@IDNA: using RFC2047 before @, IDNA punycode after @ RFC2047: using RFC2047 entire ima pynycode@IDNA: using punycode before @, IDNA punycode after @ -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu May 11 02:18:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe4VS-0006ky-WB; Thu, 11 May 2006 02:18:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe4VR-0006kt-KS for ima@ietf.org; Thu, 11 May 2006 02:18:37 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe4VN-00076F-Ti for ima@ietf.org; Thu, 11 May 2006 02:18:37 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6DBCC2596E7; Thu, 11 May 2006 08:17:55 +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 03205-01; Thu, 11 May 2006 08:17:52 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0F6EA2596DE; Thu, 11 May 2006 08:17:52 +0200 (CEST) Message-ID: <4462D735.9000003@alvestrand.no> Date: Thu, 11 May 2006 08:18:29 +0200 From: Harald Alvestrand User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051011) X-Accept-Language: en-us, en MIME-Version: 1.0 To: fujiwara@jprs.co.jp Subject: Re: [EAI] Proposed Received header "for" clause encodings References: <20060511.140736.21926572.fujiwara@jprs.co.jp> In-Reply-To: <20060511.140736.21926572.fujiwara@jprs.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 A very good presentation of alternatives. I hope we can discuss the tradeoffs more in Beijing. One nit: fujiwara@jprs.co.jp wrote: >(3) for ascii-address (ima) > for ascii-address without ima > for alt-ascii (ima) ima with ALT-ADDR > for atomic-ascii (ima) ima without ALT-ADDR, with ATOMIC y > for (ima) ima without ALT-ADDR, without ATOMIC > > in the last case, I think it has to be "(for ima)" to be syntactically valid - the syntax does not allow a missing address after the "for" keyword. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu May 11 14:49:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGDf-0007Pg-G8; Thu, 11 May 2006 14:49:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGDe-0007PQ-6W for ima@ietf.org; Thu, 11 May 2006 14:49:02 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeGDb-0007bP-MU for ima@ietf.org; Thu, 11 May 2006 14:49:02 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4BImxSX006148 for ; Thu, 11 May 2006 12:48:59 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZ400E016XBW000@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Thu, 11 May 2006 12:48:59 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZ400DC96XJ3Z50@mail-amer.sun.com>; Thu, 11 May 2006 12:48:58 -0600 (MDT) Date: Thu, 11 May 2006 11:52:20 -0700 From: Chris Newman Subject: Re: [EAI] downgrading and Received header changing In-reply-to: <20060510.205601.48528611.fujiwara@jprs.co.jp> To: fujiwara@jprs.co.jp Message-id: <54D675100014B1F6CB5FFBF2@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <7A0C9327FB198FE371C60436@[10.1.110.5]> <20060508.150142.115925723.fujiwara@jprs.co.jp> <28B83627E2CCBD3531D5721C@[10.0.1.2]> <20060510.205601.48528611.fujiwara@jprs.co.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org fujiwara@jprs.co.jp wrote on 5/10/06 20:56 +0900: >> From: Chris Newman >> What I'm suggesting is something like this: >> >> Received: from ... by ... for 7bit-addr@7bit-domain (utf8-addr@utf8-domain) > > Is this 7bit-addr@7bit-domain alternate-ascii-address which is > specified by Alt-Addr parameter? > > (without Alt-Address and with ATOMIC y, alternate-ascii-address is > generated by punycode comversion of utf8@utf8.) Yes. > In my understanding, > if "for" clauses has ascii-alternative-address with utf8-address in > comment field, the header shows that UTF8 address was used in that > SMTP session. Yes. >> And then grant a very limited exception to 2821 section 4.4 _only_ for 2047 >> down-conversion of 8-bit comments, so we get: >> >> Received: from ... by ... for 7bit-addr@7bit-domain (_RFC_2047_) >> >> This preserves the syntax of Received after down-conversion, no ordering >> problems or intrusion into the UI, and the exception to RFC 2821 section 4.4 >> should be sufficiently minor and non-destructive to avoid the problems that >> rule attempts to prevent. > > It's one candidate method. Thanks. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu May 11 14:58:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGNG-0000up-Pp; Thu, 11 May 2006 14:58:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGNF-0000uG-2Z for ima@ietf.org; Thu, 11 May 2006 14:58:57 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeGNE-00085N-Cl for ima@ietf.org; Thu, 11 May 2006 14:58:57 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k4BIwtKe005216 for ; Thu, 11 May 2006 12:58:55 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZ400A017BQMJ00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Thu, 11 May 2006 12:58:55 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZ400BV87E4ZA30@mail-amer.sun.com>; Thu, 11 May 2006 12:58:55 -0600 (MDT) Date: Thu, 11 May 2006 12:02:16 -0700 From: Chris Newman Subject: Re: [EAI] downgrading and Received header changing In-reply-to: To: Charles Lindsey , ima@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <20060502.180948.41651497.fujiwara@jprs.co.jp> <7A0C9327FB198FE371C60436@[10.1.110.5]> <20060508.150142.115925723.fujiwara@jprs.co.jp> <28B83627E2CCBD3531D5721C@[10.0.1.2]> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote on 5/10/06 10:02 +0100: > On Tue, 09 May 2006 20:54:53 +0100, Chris Newman > wrote: > >> fujiwara@jprs.co.jp wrote on 5/8/06 15:01 +0900: > >>> idea 2. Header encapsulation >>> >>> define new encapsulated header and replace original header with >>> encapsulated header. >>> >>> Received: from ... by ... for IMA >>> -> IMA-Encapsulated: Received: encapsulate(from ... by ... for >>> IMA) >>> or >>> -> IMA-Encapsulated: Received: from ... by ... for >>> encapsulate(IMA) >> >> This is going to break things. Gateways, MUAs and other processing >> systems are permitted to re-order headers, except for trace headers >> (Received, Return-path). While we can introduce a new trace header, >> there's no guarantee order will be preserved by older MTAs and gateways >> (which goes against the whole point of encapsulation). As a result, I >> don't consider this option feasible for Received or Return-path. > > But do agents (transport agents in particular) actually do such reordering > in practice? Our MTA did re-ordering all the time. When 2822 came out, I believe we changed it to not re-order by default, but customers in certain countries are very sensitive to the order of the key headers like "date", "subject", "from", "to" and want them re-ordered. Some old clients have problems with headers in the wrong order, so re-ordering has to be done to interoperate with them. We might move trace headers above non-trace headers, as well, but I don't recall. It's certainly a permissible transformation by any MTA that's not pure pass-through as it does not change the defined RFC 2822 semantics of the headers. > Surely all that the usual MTA does is to stick its own Received > header at the top without even looking at the rest. In that case, and > 'Received's that get downgraded to 'IMA-Encapsulated: Received...' will in > fact retain their place in the list, at least during transport. Counting Received headers is one of the mechanisms used for loop detection, so encapsulation would break that as well. > The worst that can happen is that some agent somewhere will filter all the > 'Received's to the top, in which case the poor human will have to merge the > encapsulated ones back into the list - that is messy, but not impossible and > maybe even automizable. Too much complexity for my tastes. > I suspect that whatever we do is not going to be perfect, and we shall have > to choose the best of a bad bunch. > >> What I'm suggesting is something like this: >> >> Received: from ... by ... for 7bit-addr@7bit-domain >> (utf8-addr@utf8-domain) > > Yes, that looks an interesting possibility. Please could we have that added > to the other examples that I have asked for. > > My main concern with it is that it works fione for "for", but can we be sure > that UTF-8 will not arise in other (non-comment) components of the Received > header? If we settle on the UTF-8 comment option, that gives an escape valve for things like the UTF-8 version of an idn-encoded domain name so it should prevent leakage. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri May 12 05:54:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeULc-0000qq-N2; Fri, 12 May 2006 05:54:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeULb-0000pw-C6 for ima@ietf.org; Fri, 12 May 2006 05:54:11 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeULZ-0000aC-S3 for ima@ietf.org; Fri, 12 May 2006 05:54:11 -0400 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id k4C9rrRB022754; Fri, 12 May 2006 18:53:55 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2006051218535411369 ; Fri, 12 May 2006 18:53:54 +0900 Date: Fri, 12 May 2006 18:53:54 +0900 (JST) Message-Id: <20060512.185354.10301107.fujiwara@jprs.co.jp> To: harald@alvestrand.no Subject: Re: [EAI] Proposed Received header "for" clause encodings From: fujiwara@jprs.co.jp In-Reply-To: <4462D735.9000003@alvestrand.no> References: <20060511.140736.21926572.fujiwara@jprs.co.jp> <4462D735.9000003@alvestrand.no> X-Mailer: Mew version 5.0.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 > From: Harald Alvestrand > >(3) for ascii-address (ima) > > for (ima) ima without ALT-ADDR, without ATOMIC > in the last case, I think it has to be "(for ima)" to be syntactically > valid - the syntax does not allow a missing address after the "for" keyword. I understand. "(for ima)" may be ID field's CFWS in the ABNF. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri May 12 05:58:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeUPt-0002x4-CX; Fri, 12 May 2006 05:58:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeUPs-0002wz-Lm for ima@ietf.org; Fri, 12 May 2006 05:58:36 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeUPs-0000ps-56 for ima@ietf.org; Fri, 12 May 2006 05:58:36 -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 k4C9wZR9022804 for ; Fri, 12 May 2006 18:58:35 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2006051218583411395 for ; Fri, 12 May 2006 18:58:34 +0900 Date: Fri, 12 May 2006 18:58:34 +0900 (JST) Message-Id: <20060512.185834.34759081.fujiwara@jprs.co.jp> To: ima@ietf.org From: fujiwara@jprs.co.jp X-Mailer: Mew version 5.0.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [EAI] Received header downgrading for each Received header "for" format 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 Received header downgrading for each Received header "for" format (1) not use "for" when the address is non-ASCII -> not necessary (2) for ima (Alt-Addr + Atomic information) ima after "for" need to be rewritten to ascii. it violates RFC 2821 section 4.4 "Trace Field" very much. it may be rewrited to preserve ima as: "for" punycode(local)@IDNA(host) "(" RFC2047(ima) ALT-ADDR/ATOMIC value ")" ima = local@host (3) for ascii-address (ima) ima is in comment field only. Comment field rewriting to RFC2047 is a violation but it is less than (2). Rewriting result becomes (4). Rewriting cost is less than (2). (4) for ascii-adress (toascii_conversion of ima) -> not necessary In my opinion, (3) or (4) are reasonable. (2) is hard to implement. --------------------------------------------------------------------------- (1) not use "for" when the address is non-ASCII for ascii-address without ima with ima (2) for ima (Alt-Addr + Atomic information) for ascii-address without ima for ima (ALT-ADDR alt-ascii) ima with ALT-ADDR for ima (ATOMIC y) ima with ATOMIC y for ima ima without ALT-ADDR, ATOMIC (3) for ascii-address (ima) for ascii-address without ima for alt-ascii (ima) ima with ALT-ADDR for atomic-ascii (ima) ima without ALT-ADDR, with ATOMIC y (for ima) ima without ALT-ADDR, without ATOMIC (4) for ascii-adress (toascii_conversion of ima) -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri May 12 07:15:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeVbt-0007i2-DL; Fri, 12 May 2006 07:15:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeVbs-0007hx-JH for ima@ietf.org; Fri, 12 May 2006 07:15:04 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeVbq-0004d8-1H for ima@ietf.org; Fri, 12 May 2006 07:15:04 -0400 Received: from host81-144-66-89.midband.mdip.bt.net ([81.144.66.89] country=GB) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.217) id 44646e2f.12f35.6e for ima@ietf.org; Fri, 12 May 2006 12:14:55 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k4CA2ee03858 for ; Fri, 12 May 2006 11:02:40 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] downgrading and Received header changing References: <20060502.180948.41651497.fujiwara@jprs.co.jp> <7A0C9327FB198FE371C60436@[10.1.110.5]> <20060508.150142.115925723.fujiwara@jprs.co.jp> <28B83627E2CCBD3531D5721C@[10.0.1.2]> Message-ID: Date: Fri, 12 May 2006 11:02:38 +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: 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 Thu, 11 May 2006 20:02:16 +0100, Chris Newman wrote: > Charles Lindsey wrote on 5/10/06 10:02 +0100: > > Counting Received headers is one of the mechanisms used for loop > detection, so encapsulation would break that as well. > Yes, that seems a valid point. But surely it would only make the message go round the loop more times, and it would still catch it eventually? Not ideal, but still not an infinite loop. >> Yes, that looks an interesting possibility. Please could we have that >> added >> to the other examples that I have asked for. >> >> My main concern with it is that it works fione for "for", but can we >> be sure >> that UTF-8 will not arise in other (non-comment) components of the >> Received >> header? > > If we settle on the UTF-8 comment option, that gives an escape valve for > things like the UTF-8 version of an idn-encoded domain name so it should > prevent leakage. All right. Now what about the case of the 'From' and 'By' fields of Received? Are these covered? Presumably so, because AIUI there are no local parts in them, so an IDNA downgrade is always possible. -- 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 May 12 15:50:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FedeU-0005Vg-CZ; Fri, 12 May 2006 15:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FedeF-0005NG-Il; Fri, 12 May 2006 15:50:03 -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 1FedeF-0006Tj-GY; Fri, 12 May 2006 15:50:03 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FedeE-0001ph-1L; Fri, 12 May 2006 15:50:03 -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 k4CJo167018161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FedeD-00016O-MC; Fri, 12 May 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: Fri, 12 May 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-scenarios-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 Addresses: Scenarios Author(s) : H. Alvestrand Filename : draft-ietf-eai-scenarios-00.txt Pages : 9 Date : 2006-5-12 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-scenarios-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-scenarios-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-scenarios-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-5-12130224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-scenarios-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-scenarios-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-12130224.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 May 12 15:50:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fedea-0005iH-81; Fri, 12 May 2006 15:50:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FedeI-0005Np-Cf; Fri, 12 May 2006 15:50:06 -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 1FedeI-0006Tx-Aa; Fri, 12 May 2006 15:50:06 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FedeE-0001pZ-0X; Fri, 12 May 2006 15:50:06 -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 k4CJo11I007398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FedeD-00016J-LX; Fri, 12 May 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: Fri, 12 May 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-smtpext-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 : SMTP extension for internationalized email address Author(s) : J. Yao, W. Mao Filename : draft-ietf-eai-smtpext-00.txt Pages : 14 Date : 2006-5-12 Internationalized eMail Address (IMA) includes two parts, the local part and the domain part. The way email addresses are used by protocols are different from the way domain names are used. The most critical difference is that emails are delivered through a chain of peering clients and servers while domain names are resolved by name servers by looking up their own tables. In addition to this, email transport protocols SMTP and ESMTP provide a negotiation mechanism through which clients can make decisions for further processing. So IMA is different from the internationalized domain name (IDN). IMA can be solved by exploiting the negotiation mechanism while IDN can not use the negotiation mechanism. So IMA should be solved in the mail transport-level using the negotiation mechanism, which is an architecturally desirable approach. This document specifies the use of SMTP extension for IMA delivery. It also mentions the backward compatible mechanism for downgrade procedure, as specified in an associated specification. The protocol proposed here is MTA-level solution which is feasible, architecturally more elegant, and not as difficult to deploy in relevant communities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-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-smtpext-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-smtpext-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-5-12130042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-smtpext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-smtpext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-12130042.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 May 12 15:50:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FedeU-0005Vg-CZ; Fri, 12 May 2006 15:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FedeF-0005NG-Il; Fri, 12 May 2006 15:50:03 -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 1FedeF-0006Tj-GY; Fri, 12 May 2006 15:50:03 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FedeE-0001ph-1L; Fri, 12 May 2006 15:50:03 -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 k4CJo167018161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FedeD-00016O-MC; Fri, 12 May 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: Fri, 12 May 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-scenarios-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 Addresses: Scenarios Author(s) : H. Alvestrand Filename : draft-ietf-eai-scenarios-00.txt Pages : 9 Date : 2006-5-12 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-scenarios-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-scenarios-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-scenarios-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-5-12130224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-scenarios-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-scenarios-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-12130224.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 May 12 15:50:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fedea-0005iH-81; Fri, 12 May 2006 15:50:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FedeI-0005Np-Cf; Fri, 12 May 2006 15:50:06 -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 1FedeI-0006Tx-Aa; Fri, 12 May 2006 15:50:06 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FedeE-0001pZ-0X; Fri, 12 May 2006 15:50:06 -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 k4CJo11I007398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FedeD-00016J-LX; Fri, 12 May 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: Fri, 12 May 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-smtpext-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 : SMTP extension for internationalized email address Author(s) : J. Yao, W. Mao Filename : draft-ietf-eai-smtpext-00.txt Pages : 14 Date : 2006-5-12 Internationalized eMail Address (IMA) includes two parts, the local part and the domain part. The way email addresses are used by protocols are different from the way domain names are used. The most critical difference is that emails are delivered through a chain of peering clients and servers while domain names are resolved by name servers by looking up their own tables. In addition to this, email transport protocols SMTP and ESMTP provide a negotiation mechanism through which clients can make decisions for further processing. So IMA is different from the internationalized domain name (IDN). IMA can be solved by exploiting the negotiation mechanism while IDN can not use the negotiation mechanism. So IMA should be solved in the mail transport-level using the negotiation mechanism, which is an architecturally desirable approach. This document specifies the use of SMTP extension for IMA delivery. It also mentions the backward compatible mechanism for downgrade procedure, as specified in an associated specification. The protocol proposed here is MTA-level solution which is feasible, architecturally more elegant, and not as difficult to deploy in relevant communities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-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-smtpext-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-smtpext-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-5-12130042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-smtpext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-smtpext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-12130042.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 May 15 21:14:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffo86-0006Z2-Ie; Mon, 15 May 2006 21:13:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffo85-0006Yx-Np for ima@ietf.org; Mon, 15 May 2006 21:13:41 -0400 Received: from [159.226.7.146] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ffo7x-0007gJ-1l for ima@ietf.org; Mon, 15 May 2006 21:13:41 -0400 Received: (eyou send program); Tue, 16 May 2006 09:13:15 +0800 Message-ID: <347741995.29753@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, 16 May 2006 09:13:15 +0800 Message-ID: <4469272D.3050605@cnnic.cn> Date: Tue, 16 May 2006 09:13:17 +0800 From: "Xiaodong(Sheldon) Lee" Organization: CNNIC User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ima@ietf.org Subject: Re: [EAI] EAI WG Interim Meeting References: <346999981.15248@cnnic.cn> In-Reply-To: <346999981.15248@cnnic.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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, An additional homepage for this meeting has been build, please access http://www.asrc.cn/eai.htm to check the updated information of this meeting. This page will be updated on time. Any questions, please contact co-chairs. Regards! -- -- Xiaodong LEE [The best answer is doing] +86-10-58813020 mailto:lee@cnnic.cn http://www.lixiaodong.cn Xiaodong(Sheldon) Lee wrote: >The EAI WG will hold an interim meeting to prompt the working process of the WG. > >Meeting Time: June 5, 2006( From 9:00 am to 18:00 pm) ( Note: We change the meeting time from June1/2 > to June 5 to avoid conflict with other interim meeting) > >Local Host: China Internet Network Information Center(CNNIC) > >Meeting Venue: Conference Center of Computer Network Information Center, Chinese Academy of Sciences > The 5th floor, Building 2, No.4 South 4th Street, ZhongGuanCun, Beijing, 100080, China > >Meeting Facilities: > 1) The meeting room can support less than 100 persons > 2) Wireless internet access will be availabe > 3) IP-based Video conference facilities will be available, the address will be announce in one > week later. > >Hotels: > 1) Jade Palace Hotel(five star) http://www.jadepalace.com.cn/ (10 minutes to meeting venue by walk) > 2) TianHong Plaza Hotel(four star) http://www.tianhongplaza.com/ (15 minutes to meeting venue by walk) > If you need the local host to book hotel for you, please send email to me, including your requirement > and budget. > >Proposed Agenda: > 1) Drafts review ( Suggest you to read all the published drafts before attending this meeting, > including framework, smtpext, utf8headers, downgrade, and etc. ) > 2) *Testing plan( more email software developers providers or vendors are welcome to joining) > 3) Open issues (TBD) > Please add more issues into agenda, if needed. > >Please send your name to the WG co-chairs, if you plan to attend this interim meeting. And that, if you >need invitation letter to get visa, send request to co-chairs, too. > >Harald Alvestrand & Xiaodong Lee >EAI WG co-chairs > > >_______________________________________________ >IMA mailing list >IMA@ietf.org >https://www1.ietf.org/mailman/listinfo/ima > > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue May 16 11:00:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg11a-00063r-5V; Tue, 16 May 2006 10:59:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg11Q-0005wq-Sa for ima@ietf.org; Tue, 16 May 2006 10:59:40 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg11N-0002e0-FH for ima@ietf.org; Tue, 16 May 2006 10:59:40 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4GExXZR032502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 May 2006 07:59:33 -0700 Received: from [10.0.1.5] (vpn-10-50-16-156.qualcomm.com [10.50.16.156]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4GExTX6007777; Tue, 16 May 2006 07:59:32 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <347741995.29753@cnnic.cn> References: <346999981.15248@cnnic.cn> <347741995.29753@cnnic.cn> Date: Tue, 16 May 2006 07:59:28 -0700 To: lee@cnnic.cn, ima@ietf.org From: Ted Hardie Subject: Re: [EAI] EAI WG Interim Meeting Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 At 9:13 AM +0800 5/16/06, Xiaodong(Sheldon) Lee wrote: >Dear All, > >An additional homepage for this meeting has been build, please access >http://www.asrc.cn/eai.htm to check the updated information of this meeting. > >This page will be updated on time. Any questions, please contact co-chairs. > >Regards! > >-- >-- Xiaodong LEE [The best answer is doing] > +86-10-58813020 > mailto:lee@cnnic.cn > http://www.lixiaodong.cn Dear Xiaodong, Thanks for the information. One question: the information states: Please send your terminal IP address to yaojk@cnnic.cn ,it will be added into the allow list. Even in corporate environments, many of us will have DHCP-provided addresses; would we send a message with the terminal IP when assigned (that is, the day of the meeting?) or should we send a netblock to that address? regards, Ted Hardie > > >Xiaodong(Sheldon) Lee wrote: > >>The EAI WG will hold an interim meeting to prompt the working process of the WG. >> >>Meeting Time: June 5, 2006( From 9:00 am to 18:00 pm) ( Note: We change the meeting time from June1/2 >> to June 5 to avoid conflict with other interim meeting) >> >>Local Host: China Internet Network Information Center(CNNIC) >> >>Meeting Venue: Conference Center of Computer Network Information Center, Chinese Academy of Sciences >> The 5th floor, Building 2, No.4 South 4th Street, ZhongGuanCun, Beijing, 100080, China >> >>Meeting Facilities: >> 1) The meeting room can support less than 100 persons >> 2) Wireless internet access will be availabe >> 3) IP-based Video conference facilities will be available, the address will be announce in one >> week later. >> >>Hotels: >> 1) Jade Palace Hotel(five star) http://www.jadepalace.com.cn/ (10 minutes to meeting venue by walk) >> 2) TianHong Plaza Hotel(four star) http://www.tianhongplaza.com/ (15 minutes to meeting venue by walk) >> If you need the local host to book hotel for you, please send email to me, including your requirement >> and budget. >> >>Proposed Agenda: >> 1) Drafts review ( Suggest you to read all the published drafts before attending this meeting, >> including framework, smtpext, utf8headers, downgrade, and etc. ) >> 2) *Testing plan( more email software developers providers or vendors are welcome to joining) >> 3) Open issues (TBD) >> Please add more issues into agenda, if needed. >> >>Please send your name to the WG co-chairs, if you plan to attend this interim meeting. And that, if you >>need invitation letter to get visa, send request to co-chairs, too. >> >>Harald Alvestrand & Xiaodong Lee >>EAI WG co-chairs >> >> >>_______________________________________________ >>IMA mailing list >>IMA@ietf.org >>https://www1.ietf.org/mailman/listinfo/ima >> >> >> > >_______________________________________________ >IMA mailing list >IMA@ietf.org >https://www1.ietf.org/mailman/listinfo/ima _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed May 17 03:09:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgG9V-0005Mt-5p; Wed, 17 May 2006 03:09:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgG9T-0005La-PI for ima@ietf.org; Wed, 17 May 2006 03:08:59 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgG9P-0005P5-Ds for ima@ietf.org; Wed, 17 May 2006 03:08:59 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ACCF02596E6; Wed, 17 May 2006 09:08:12 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24845-01; Wed, 17 May 2006 09:08:07 +0200 (CEST) Received: from [193.204.92.19] (guest92-19.conf06.garr.it [193.204.92.19]) by eikenes.alvestrand.no (Postfix) with ESMTP id ABF382596E3; Wed, 17 May 2006 09:08:06 +0200 (CEST) Message-ID: <446ACBFF.6060508@alvestrand.no> Date: Wed, 17 May 2006 09:08:47 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Ted Hardie Subject: Re: [EAI] EAI WG Interim Meeting References: <346999981.15248@cnnic.cn> <347741995.29753@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: 8abaac9e10c826e8252866cbe6766464 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 Ted Hardie wrote: > At 9:13 AM +0800 5/16/06, Xiaodong(Sheldon) Lee wrote: > >> Dear All, >> >> An additional homepage for this meeting has been build, please access >> http://www.asrc.cn/eai.htm to check the updated information of this meeting. >> >> This page will be updated on time. Any questions, please contact co-chairs. >> >> Regards! >> >> -- >> -- Xiaodong LEE [The best answer is doing] >> +86-10-58813020 >> mailto:lee@cnnic.cn >> http://www.lixiaodong.cn >> > > Dear Xiaodong, > Thanks for the information. One question: the information states: > > Please send your terminal IP address to yaojk@cnnic.cn ,it will be added into the allow list. > > Even in corporate environments, many of us will have DHCP-provided addresses; would we send a message with the terminal IP when assigned (that is, the day of the meeting?) or should we send a netblock to that address? I think this refers to the IP address of the video conferencing facilities that may be used to connect to the video conferencing facilities at CNNIC; it seems that video conferencing is still an immature technology, so IP addresses (and testing) are necessary :-( Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed May 17 03:52:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgGpU-0003Rj-7z; Wed, 17 May 2006 03:52:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgGpT-0003Re-5Q for ima@ietf.org; Wed, 17 May 2006 03:52:23 -0400 Received: from [159.226.7.146] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FgGpN-0006tR-EX for ima@ietf.org; Wed, 17 May 2006 03:52:23 -0400 Received: (eyou send program); Wed, 17 May 2006 15:51:58 +0800 Message-ID: <347852318.00958@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; Wed, 17 May 2006 15:51:58 +0800 Message-ID: <446AD624.6070705@cnnic.cn> Date: Wed, 17 May 2006 15:52:04 +0800 From: "Xiaodong(Sheldon) Lee" Organization: CNNIC User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Alvestrand Subject: Re: [EAI] EAI WG Interim Meeting References: <346999981.15248@cnnic.cn> <347741995.29753@cnnic.cn> <347849739.32627@cnnic.cn> In-Reply-To: <347849739.32627@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lee@cnnic.cn List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Dear Ted, NetBlock is not supported. Only IP address is feasible. If someone only have DHCP IP address, he has better send the IP address just before the meeting. Xiaodong -- -- Xiaodong LEE [The best answer is doing] +86-10-58813020 mailto:lee@cnnic.cn http://www.lixiaodong.cn Harald Alvestrand wrote: > Ted Hardie wrote: > >> At 9:13 AM +0800 5/16/06, Xiaodong(Sheldon) Lee wrote: >> >> >>> Dear All, >>> >>> An additional homepage for this meeting has been build, please access >>> http://www.asrc.cn/eai.htm to check the updated information of this >>> meeting. >>> >>> This page will be updated on time. Any questions, please contact >>> co-chairs. >>> >>> Regards! >>> >>> -- >>> -- Xiaodong LEE [The best answer is doing] >>> +86-10-58813020 >>> mailto:lee@cnnic.cn >>> http://www.lixiaodong.cn >>> >> >> >> Dear Xiaodong, >> Thanks for the information. One question: the information states: >> >> Please send your terminal IP address to yaojk@cnnic.cn ,it will be >> added into the allow list. >> >> Even in corporate environments, many of us will have >> DHCP-provided addresses; would we send a message with the terminal IP >> when assigned (that is, the day of the meeting?) or should we send a >> netblock to that address? > > I think this refers to the IP address of the video conferencing > facilities that may be used to connect to the video conferencing > facilities at CNNIC; it seems that video conferencing is still an > immature technology, so IP addresses (and testing) are necessary :-( > > Harald > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue May 23 03:58:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiRlf-0000tM-34; Tue, 23 May 2006 03:57:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiRld-0000tH-Tu for ima@ietf.org; Tue, 23 May 2006 03:57:25 -0400 Received: from [159.226.7.146] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FiRlU-0001HR-V8 for ima@ietf.org; Tue, 23 May 2006 03:57:25 -0400 Received: (eyou send program); Tue, 23 May 2006 15:57:04 +0800 Message-ID: <348371024.09535@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.146 with SMTP; Tue, 23 May 2006 15:57:04 +0800 Message-ID: <029c01c67e3e$7684bac0$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: "Harald Alvestrand" References: <348364671.02914@cnnic.cn> <348367975.09485@cnnic.cn> Date: Tue, 23 May 2006 15:56:55 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 1.0 (+) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ima@ietf.org Subject: [EAI] Re: IMA utf8 address initial implementation issues 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: , Content-Type: multipart/mixed; boundary="===============1246525017==" Errors-To: ima-bounces@ietf.org --===============1246525017== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkhhcmFsZCBBbHZlc3RyYW5k IiA8aGFyYWxkQGFsdmVzdHJhbmQubm8+DQpTZW50OiBUdWVzZGF5LCBNYXkgMjMsIDIwMDYgMzow NiBQTQ0KU3ViamVjdDogUmU6IElNQSB1dGY4IGFkZHJlc3MgaW5pdGlhbCBpbXBsZW1lbnRhdGlv biBpc3N1ZXMNCg0KDQo+IFlhbywNCj4gDQo+IHRoaXMgaXMgZXhhY3RseSBhcyBleHBlY3RlZCwg YW5kIGl0IGlzIGdvb2QgdGhhdCB5b3UgdGVzdC4NCj4gcXVlc3Rpb246IGRpZCB5b3UgaW1wbGVt ZW50IGFueSBwYXJ0IG9mIHRoZSBTTVRQIGV4dGVuc2lvbiBsb2dpYz8NCg0KDQpzdGlsbCBub3Qs IHdlIGhvcGUgZmluaXNoZWQgdGhlIGluaXRpYWwgdmVyc2lvbiBiZWZvcmUgbmV4dCBtb250cmVh bCBJRVRGIG1lZXRpbmcuDQoNCj4gDQo+IEhvdyBtYW55IGxpbmVzIG9mIGNvZGUgZGlkIHlvdSBo YXZlIHRvIGNoYW5nZSBpbiB2cG9wbWFpbCB0byBnZXQgaXQgdG8NCj4gYWNjZXB0IHV0Zi04IGNo YXJzPw0KDQp2ZXJ5IHNpbXBsZS4NCm9ubHkgcmVwbGFjZSB0aGUgZnVuY3Rpb24gImlzX3VzZXJu YW1lX3ZhbGlkKCBjaGFyICp1c2VyICkib2YgdnBvcG1haWwuYyB1c2luZyB0aGUgZm9sbG93aW5n IGZ1bmN0aW9uOg0KDQogDQoNCmludCBpc191c2VybmFtZV92YWxpZCggY2hhciAqdXNlciApDQoN CnsNCg0KICB3aGlsZSgqdXNlciAhPSAwICkgew0KDQogICAvKiBpZiAoICgqdXNlciA9PSAzMykg fHwNCg0KICAgICAgICAgKCp1c2VyID09IDM1ICkgfHwNCg0KICAgICAgICAgKCp1c2VyID09IDM2 ICkgfHwNCg0KICAgICAgICAgKCp1c2VyID09IDM4ICkgfHwNCg0KICAgICAgICAgKCp1c2VyID09 IDM5ICkgfHwNCg0KICAgICAgICAgKCp1c2VyID09IDQyICkgfHwgKCp1c2VyID09IDQzKSB8fA0K DQogICAgICAgICAoKnVzZXIgPj0gNDUgJiYgKnVzZXIgPD0gNTcpIHx8DQoNCiAgICAgICAgICgq dXNlciA9PSA2MSApIHx8ICgqdXNlciA9PSA2MyApIHx8DQoNCiAgICAgICAgICgqdXNlciA+PSA2 NSAmJiAqdXNlciA8PSA5MCkgfHwNCg0KICAgICAgICAgKCp1c2VyID49IDk0ICYmICp1c2VyIDw9 IDEyNiApICkgeyovDQoNCiAgICAgICsrdXNlcjsNCg0KICAgLyogfSBlbHNlIHsNCg0KICAgICAg cmV0dXJuKFZBX0lMTEVHQUxfVVNFUk5BTUUpOw0KDQogICAgfSovDQoNCiAgfQ0KDQoNCg0KPiAN Cj4gV2VyZSB0aGVyZSBhbnkgcHJvYmxlbXMgd2l0aCBjb3JydXB0ZWQgdXRmLTggY2hhcnM/DQoN CnNvbWV0aW1lcywgc29tZSB1dGYtOCBjaGFyYWN0ZXJzIGNhbiBub3QgYmUgY29ycmVjdGx5IGRp c3BsYXllZCBieSBzb21lIG1haWwgY2xpZW50IHNvZnR3YXJlLg0KYWN0dWFsbHksaWYgd2UgdXNl IHRoZSBlbWFpbCBjbGllbnQgc29mdHdhcmU6ZXZvbHV0aW9uIChodHRwOi8vd3d3Lmdub21lLm9y Zy9wcm9qZWN0cy9ldm9sdXRpb24vKSwgaWYgd2Ugc2V0IG91dGdvaW5nIG1lc3NhZ2UncyBjaGFy YWN0ZXIgY29kaW5nIGFzIHV0Zi04LCB3ZSBkbyBub3QgbmVlZCBkbyBhbnkgY2hhbmdlcyB0byBx bWFpbCBzb3VyY2UgY29kZSAob25seSBkbyBzb21lIGNoYW5nZXMgdG8gdnBvcG1haWwuYyBpbiB2 cG9wbWFpbCkuICB0aG9zZSB0d28gcW1haWwgU01UUCBzZXJ2ZXJzIGNhbiBleGNoYW5nZSB0aGUg ZW1haWwgbWVzc2FnZSBkaXJlY3RseSB1c2luZyB0aGUgZW1haWwgYWRkcmVzcyBmb3JtYXQgdXRm LThAQXNjaWlEb21haW4uIA0KDQoNCj4gDQo+IEkgdGhpbmsgdGhpcyBjYW4gYmUgdXNlZnVsbHkg c2hhcmVkIHdpdGggdGhlIEVBSSBsaXN0LCBpdCBpcyBnb29kIHRvDQo+IGtub3cgdGhlIHNpemUg b2YgdGhlIGVmZm9ydC4NCj4gDQoNCnRoZSBzaXplIG9mIHRoZSBlZmZvcnQgdG8gY2hhbmdlIHNv bWUgc291cmNlIGNvZGUgdG8gc3VwcG9ydCBFQUkgaXMgbm90IHZlcnkgYmlnLg0KDQpzbyBtYXli ZSBFQUkgcHJvYmxlbSBpcyBub3QgdGhhdCBoYXJkIHRoYW4gd2Ugb3JpZ2luYWxseSBpbWFnZWQu DQoNCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogWUFPIEppYW5rYW5n IA0KDQogIFN1YmplY3Q6IElNQSB1dGY4IGFkZHJlc3MgaW5pdGlhbCBpbXBsZW1lbnRhdGlvbiBp c3N1ZXMNCg0KDQogIERlYXIgYWxsLA0KDQogIFdlIHNldCAyICBlbWFpbCB0ZXN0IHNlcnZlcnMg b24gMiBsaW51eCBtYWNoaW5lcyB1c2luZyB0aGUgb3BlbiBzb3VyY2Ugc29mdHdhcmU6IHVjc3Bp LXRjcC0wLjg4K3FtYWlsMS4wMytteXNxbCt2cG9wbWFpbC4gT25lIHdpdGggdGhlIGRvbWFpbiBu YW1lOiB0ZXN0MS5xbWFpbC5hc3JjLmNuOyB0aGUgb3RoZXIgd2l0aCB0aGUgZG9tYWluIG5hbWU6 IG0xLnFtYWlsLmFzcmMuY24uIFdlIGRvIGEgc2ltcGxlIGNoYW5nZSB0byBtYWtlIHZwb3BtYWls IGFsbG93IHVzaW5nIHRoZSB1dGYtOCBjaGFyYWN0ZXJzLiBub3cgaW4gYm90aCBtYWNoaW5lcywg d2UgY2FuIHVzZSB1dGYtOENoYXJhY3RlcnNAdGVzdDEucW1haWwuYXNyYy5jbiwgdXRmLThDaGFy YWN0ZXJzQG0xLnFtYWlsLmFzcmMuY24gcmVzcGVjdGx5Lg0KICAgIG5vdyB3ZSBjcmVhdGUgdHdv IGVtYWlsIGFkZHJlc3NlcyBiYXNlZCBvbiBjaGluZXNlIGNoYXJhY3J0ZXJzIGJhc2VkIG9uIHV0 Zi04Og0KICAgICAgICAgIFt1dGYtOENoaW5lc2VDaGFyYWN0ZXJzVXNlck5hbWVBXUB0ZXN0MS5x bWFpbC5hc3JjLmNuLCBbdXRmLThDaGluZXNlQ2hhcmFjdGVyc1VzZXJCXUBtMS5xbWFpbC5hc3Jj LmNuDQogICAgICAgICB3ZSBhZGRlZCBhIGZ1bmN0aW9uIGluIHFtYWlsIHdoaWNoIHRyYW5zZm9y bWVkIHRoZSBlbWFpbCBhZGRyZXNzIHRvIHV0Zi04IGZvcm1hdCwgdGhlc2UgdHdvIGVtYWlsIGFk ZHJlc3NlcyBjYW4gc3VjY2Vzc2Z1bGx5IGV4Y2hhbmdlIHRoZSBlbWFpbCBpbmZvcm1hdGlvbi4g aXQgbWVhbnMgdGhhdCBbdXRmLThDaGluZXNlQ2hhcmFjdGVyc1VzZXJOYW1lQV1AdGVzdDEucW1h aWwuYXNyYy5jbiBjYW4gc2VuZCBtZXNzYWdlIHRvICBbdXRmLThDaGluZXNlQ2hhcmFjdGVyc1Vz ZXJCXUBtMS5xbWFpbC5hc3JjLmNuIHdoaWNoIHJlY2VpdmVkIGl0IHN1Y2Nlc3NmdWxseTtbdXRm LThDaGluZXNlQ2hhcmFjdGVyc1VzZXJCXUBtMS5xbWFpbC5hc3JjLmNuIGNhbiBzZW5kIG1lc3Nh Z2UgdG8gW3V0Zi04Q2hpbmVzZUNoYXJhY3RlcnNVc2VyTmFtZUFdQHRlc3QxLnFtYWlsLmFzcmMu Y24gd2hpY2ggcmVjZWl2ZWQgaXQgc3VjY2Vzc2Z1bGx5Lg0KICAgICAgYnV0IHdoZW4gSSBzZW5k IGEgZW1haWwgdG8gaGVhbHRoeWFvQGhvdG1haWwuY29tIHVzaW5nIFt1dGYtOENoaW5lc2VDaGFy YWN0ZXJzVXNlck5hbWVBXUB0ZXN0MS5xbWFpbC5hc3JjLmNuLCBpdCBmYWlsZWQgYW5kIGdvdCBu byByZXNwb25zZSBmcm9tIGhvdG1haWwuY29tIG9yIHRlc3QxLnFtYWlsLmFzcmMuY24uIG1heWJl IHRoaXMgZW1haWwgd2FzIHJlZ2FyZGVkIGFzIHJ1YmJpc2ggYnkgaG90bWFpbC5jb20uDQoNCiAg ICAgc28gZnJvbSB0aGUgYWJvdmUgdGVzdGluZywgdGhlIGNvbmNsdXNpb24gbWF5IGJlOg0KDQog ICAgaWYgYm90aCBzZW5kZXIgYW5kIHJlY2VpdmVyIE1UQSBzdXBwb3J0IElNQSwgdGhhdCBpcyBu byBwcm9ibGVtLg0KICAgIHdoZW4gcmVjZWl2ZXIgTVRBIGRvZXMgbm90IHN1cHBvcnQgSU1BIGhl YWRlcnMgYW5kIHRoZSBzZW5kZXIgc3RpbGwgdXNlIHRoZSBJTUEgaGVhZGVycyBvciBhZGRyZXNz LCB0aGUgZW1haWwgd2lsbCAgYmUgZWFzaWx5IHJlZ2FyZGVkIGFzIHRoZSBydWJiaXNoIGJ5IHJl bGF5IHNlcnZlciBvciByZWNlaXZlciBzZXJ2ZXIuDQogICAgY2FuIHRoaXMgdGVzdCBoZWxwIHRv IGRlc2lnbiBvdXIgdXRmLTggZW1haWwgaGVhZGVyIG9yIGZyYW1ld29yayBvciBhbnl0aGluZyBl bHNlPyANCiAgICAgDQogIFRoYW5rcy4gIA0KDQoNCiAgWUFPIEppYW5rYW5nDQogIEJlc3QgUmVn YXJkcw0KICBUZWw6ODYtMTAtNTg4MTMwMDcNCiAgRmF4Ojg2LTEwLTYyNTU5ODkyDQogIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogIENoaW5hIElu dGVybmV0IE5ldHdvcmsgSW5mb3JtYXRpb24gQ2VudGVyIChDTk5JQykNCiAgNCwgU291dGggNHRo IFN0cmVldCwgWmhvbmdndWFuY3VuLA0KICBIYWlkaWFuIGRpc3RyaWN0LA0KICBCZWlqaW5nIDEw MDA4MCwgQ2hpbmENCiAgUE9COiBCZWlqaW5nIDM0OSwgQnJhbmNoIDYNCiAgaHR0cDovL3d3dy5j bm5pYy5jbg0KICBFbWFpbDogeWFvamtAY25uaWMuY24NCiAgaGVhbHRoeWFvQDE2My5jb20NCg== --===============1246525017== 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 --===============1246525017==-- From ima-bounces@ietf.org Wed May 24 15:50:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FizN0-0004EP-Io; Wed, 24 May 2006 15:50:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FizMp-0004Cc-GK; Wed, 24 May 2006 15:50:03 -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 1FizMp-0003Eq-E5; Wed, 24 May 2006 15:50:03 -0400 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FizMo-0006Cx-1r; Wed, 24 May 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k4OJo1XO001696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FizMn-0004M0-Is; Wed, 24 May 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: Wed, 24 May 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-framework-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 : Overview and Framework for Internationalized Email Author(s) : J. Klensin, Y. Ko Filename : draft-ietf-eai-framework-00.txt Pages : 19 Date : 2006-5-24 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-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-framework-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-framework-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-5-24112725.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-24112725.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 May 26 15:50:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjiK8-0002hg-36; Fri, 26 May 2006 15:50:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjiJv-0002R7-5J; Fri, 26 May 2006 15:50:03 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjiJt-0005L1-Si; Fri, 26 May 2006 15:50:03 -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 k4QJo1et024898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FjiJt-0005fL-MB; Fri, 26 May 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: Fri, 26 May 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-downgrade-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 : Downgrading mechanism for Internationalized eMail Address (IMA) Author(s) : Y. Yoneya, K. Fujiwara Filename : draft-ietf-eai-downgrade-00.txt Pages : 14 Date : 2006-5-26 Traditional mail system handles only US-ASCII characters in SMTP envelope and mail headers. The Internationalized eMail Address (IMA) is implemented by allowing UTF-8 characters in SMTP envelope and mail headers. To deliver IMA through IMA 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-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-downgrade-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-downgrade-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-5-26140154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-downgrade-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-downgrade-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-26140154.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 May 29 23:21:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkumf-0002Me-6Y; Mon, 29 May 2006 23:20:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkumd-0002MV-Rx for ima@ietf.org; Mon, 29 May 2006 23:20:39 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkumV-0004nr-Q8 for ima@ietf.org; Mon, 29 May 2006 23:20:39 -0400 Received: from host81-144-67-222.midband.mdip.bt.net ([81.144.67.222] country=GB) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.218) id 447bb9fd.e519.30b for ima@ietf.org; Tue, 30 May 2006 04:20:29 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k4TIk7806522 for ; Mon, 29 May 2006 19:46:07 +0100 (BST) Date: Mon, 29 May 2006 19:46:01 +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: f2984bf50fb52a9e56055f779793d783 Subject: [EAI] Comments on draft-ietf-eai-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 The draft refers, in many places, to "IMA" (whose definition can only be found in the Abstract). I suspect all these need changing, probably to "EAI", with the term defined somewhere in 1.3. Or maybe to "IEmail", which is to be the EHLO keyword. 2.1. Framework for the Internationalization Extension 3. No parameter values are defined for this EHLO keyword value. In order to permit future (although unanticipated) extensions, the EHLO response MUST NOT contain any parameters for that keyword. If a parameter appears, the SMTP client that is conformant to this version of this specification MUST treat the ESMTP response as if the IMA keyword did not appear. s/IMA/IEmail/ 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? 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. 2.2. The Address Internationalization Service Extension Any domain names that are to be looked up in the DNS MUST be processed into the form as specified in IDNA [RFC3490] by means of the ToASCII() operation unless they are already in that form. Any domain names that are to be compared to local strings SHOULD be s/DNS MUST be processed/DNS MUST first be processed/ 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/ .... 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/ but in either case, "it" is too vague, so s/it/all addresses (both in the envelope and in the message's header fields)/ ... 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). 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. 2.3. Extended Mailbox Address Syntax Where "atext", "qcontent" and "DQUOTE" are defined in [RFC2822], "Let-dig", "Ldh-str" and "address-literal" are defined in [RFC2821] and UTF8-2, UTF8-3 and UTF8-4 are defined in [RFC3629]. The value of "Local-part" should pass Stringprep [RFC3454]; The value of "domain" should be verified with [RFC3490]; If failed, The value of "Local- part" and "domain", the email address can not be regarded as the valid email address. s/should/SHOULD/ 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). 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). 2.4. The ALT-ADDRESS and ATOMIC parameter I was expecting to see some syntax for these, and didn't. I think you have to say that they take the form of s as defined in RFC 2821, where the esmtp-keyword is "ALT-ADDRESS" ("ATOMIC") and the esmtp-value is an address ("yes" or "no"). Also that everything (except in addresses) is case-insensitive. ... The final delivery SMTP server can revert the addresses even though they are as in all ASCII form. s/revert/restore/ s/as/now/ ... 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). s/should/SHOULD/ (or is it MAY?) But you cannot say "such as punycode". You need to specify exactly what transformation is to be used (or more likely point to the downgrade document to specify it). But it certainly won't be punycode, because punycode destroys all case distinctions AIUI, which is not good enough for local parts. The suggested algorithmic transformation is punycode if the value of ALT-ADDRESS is not set by sender and the value of ATOMIC is 'y' when SMTP servers can not support IMA. Since the prefix "xn--" had been used for IDNA, it is better that other prefix such as "bq--" is used for the local part of converted version of the primary address to avoid the potential confusion. No, it must be more than "suggested", as I said above (otherwise the recipient will not be able to understand it). Better to omit this paragraph entirely, and leave it to the downgrade document to worry about prefixes such as "xn--". 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 ... Again, leave all this to the downgrade document. I think we now have some sort of consensus on how to downgrade these, based on Newman's proposal. But the downgrade document is the place to describe this (just as it is the place to describe downgrading of all the other headers). The only respect in which Trace fields are special here is that servers will also be generating them, and then maybe immediately downgraded what they have invented (well, there is an obvious optimization there). 3.2. POP and IMAP I don't think this section really belongs in this document. There will be separate documents in due course. 3.3. Impact to RFC 2476 and many email related RFC Yes, your draft also needs to define which of your extensions apply to RFC 2476 submission agents RFC 3461 delivery status notification (what is actually needed there?) RFC ???? LMTP Essentially, you are extending all these in addition to RFC 2821. There may be others as well. -- 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 May 30 17:23:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlBgi-00045L-NZ; Tue, 30 May 2006 17:23:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlBgh-00045G-E6 for ima@ietf.org; Tue, 30 May 2006 17:23:39 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlBgg-00058T-44 for ima@ietf.org; Tue, 30 May 2006 17:23:39 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9C6AA2596F6 for ; Tue, 30 May 2006 23:22:45 +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 04686-09 for ; Tue, 30 May 2006 23:22:41 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 73FC8259709 for ; Tue, 30 May 2006 23:22:41 +0200 (CEST) Message-ID: <447CB7D5.5080703@alvestrand.no> Date: Tue, 30 May 2006 23:23:33 +0200 From: Harald Alvestrand User-Agent: Mozilla Thunderbird 1.0.6-7.5.20060mdk (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [EAI] Open issues - important ones 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 co-workers, it is now just a few days until our scheduled meeting in Beijing. The discussion on the list has proved that we still do not see face to face on a number of issues, some of the more important being: - The way to detect that I18Mail is in use in a given message: UTF-8 detection, special header, 8-bit detection, declaring messages without the header to be "out of scope" for the WG - The way in which to convey I18Mail information in Received: headers, knowing that requiring a gateway to modify these is likely to be troubling - The use of encapsulation or not in order to gateway messages through non-I18Mail systems - The proper MIME type and encoding to use when forwarding I18Mail messages We have also failed to start so far the discussion on how to deal with DKIM, PGP/MIME and other mail security protocols that require headers of messages to be unmodified. Luckily, we have a new set of internet-drafts to base our discussion on: draft-ietf-eai-downgrade-00 draft-ietf-eai-framework-00 draft-ietf-eai-scenarios-00 draft-ietf-eai-smtpext-00 We hope that they will soon be joined by the promised revised headers, IMAP and POP drafts. Remember to send mail to the chairs telling us if you are coming to Beijing - so far, few people have done so, and we need to know how many people to prepare the logistics for. Also please notify us if you plan to attend by videoconference or teleconference. Talk to you soon! Harald, for the WG chairs _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed May 31 12:15:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlTLr-00086w-DU; Wed, 31 May 2006 12:15:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlTLp-00086r-J9 for ima@ietf.org; Wed, 31 May 2006 12:15:17 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlTLl-0004aZ-TC for ima@ietf.org; Wed, 31 May 2006 12:15:17 -0400 Received: from host81-144-66-196.midband.mdip.bt.net ([81.144.66.196] country=GB) by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.218) id 447dc108.20cb.2835 for ima@ietf.org; Wed, 31 May 2006 17:15:04 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k4VBFv805427 for ; Wed, 31 May 2006 12:15:57 +0100 (BST) Date: Wed, 31 May 2006 10:00:16 +0100 From: "Charles Lindsey" To: "Charles Lindsey" Subject: Re: [EAI] Comments on draft-ietf-eai-smtpext-00 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k4V90P829643 for ; Wed, 31 May 2006 10:00:26 +0100 (BST) References: Message-ID: In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) Resent-To: "ima@ietf.org" Resent-From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Resent-Date: Wed, 31 May 2006 12:15:46 +0100 Resent-Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On Mon, 29 May 2006 19:46:01 +0100, Charles Lindsey wrote: > The draft refers, in many places, to "IMA" (whose definition can only be > found in the Abstract). I suspect all these need changing, probably to > "EAI", with the term defined somewhere in 1.3. Or maybe to "IEmail", > which is to be the EHLO keyword. Oops! My Subject did not make it clear I was referring to draft-ietf-eai-smtpext-00, though it was not hard to guess. Please correct the Subject header in any reply that you make. -- 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 Wed May 31 17:43:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlYTW-0005at-JU; Wed, 31 May 2006 17:43:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlYTU-0005ZI-Ta; Wed, 31 May 2006 17:43: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 1FlXhn-0007rf-Em; Wed, 31 May 2006 16:54:15 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlWic-0004Iu-N2; Wed, 31 May 2006 15:51:05 -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 k4VJo2mU027569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 May 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FlWhe-0003Z7-7n; Wed, 31 May 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: Wed, 31 May 2006 15:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-imap-utf8-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 : IMAP Support for UTF-8 Author(s) : P. Resnick, C. Newman Filename : draft-ietf-eai-imap-utf8-00.txt Pages : 15 Date : 2006-5-31 This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support unencoded international characters in user names, mail addresses and message headers. This is an early draft and intended as a framework for discussion. Please do not deploy implementations of this draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-imap-utf8-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-imap-utf8-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-imap-utf8-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-5-31143211.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-imap-utf8-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-imap-utf8-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-31143211.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 Wed May 31 23:47:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fle9e-0003P5-T9; Wed, 31 May 2006 23:47:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fle8g-0002e0-IV for ima@ietf.org; Wed, 31 May 2006 23:46:26 -0400 Received: from [159.226.7.146] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fldzp-0008MZ-Mu for ima@ietf.org; Wed, 31 May 2006 23:37:21 -0400 Received: (eyou send program); Thu, 01 Jun 2006 11:37:05 +0800 Message-ID: <349133025.15580@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.146 with SMTP; Thu, 01 Jun 2006 11:37:05 +0800 Message-ID: <010f01c6852c$a1c7f810$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: , "Charles Lindsey" References: <348959326.08293@cnnic.cn> Subject: Re: [EAI] Comments on draft-ietf-eai-00.txt Date: Thu, 1 Jun 2006 11:36:56 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 1.0 (+) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 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: , Content-Type: multipart/mixed; boundary="===============1585172246==" Errors-To: ima-bounces@ietf.org --===============1585172246== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNoYXJsZXMgTGluZHNleSIg PGNobEBjbGVyZXcubWFuLmFjLnVrPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5 LCBNYXkgMzAsIDIwMDYgMjo0NiBBTQ0KU3ViamVjdDogW0VBSV0gQ29tbWVudHMgb24gZHJhZnQt aWV0Zi1lYWktMDAudHh0DQoNCg0KPiBUaGUgZHJhZnQgcmVmZXJzLCBpbiBtYW55IHBsYWNlcywg dG8gIklNQSIgKHdob3NlIGRlZmluaXRpb24gY2FuIG9ubHkgYmUgIA0KPiBmb3VuZCBpbiB0aGUg QWJzdHJhY3QpLiBJIHN1c3BlY3QgYWxsIHRoZXNlIG5lZWQgY2hhbmdpbmcsIHByb2JhYmx5IHRv ICANCj4gIkVBSSIsIHdpdGggdGhlIHRlcm0gZGVmaW5lZCBzb21ld2hlcmUgaW4gMS4zLiBPciBt YXliZSB0byAiSUVtYWlsIiwgd2hpY2ggIA0KPiBpcyB0byBiZSB0aGUgRUhMTyBrZXl3b3JkLg0K DQp3ZSB3aWxsIGNvbnNpZGVyIHRvIHVzZSAgIklFbWFpbCIgb3IgICJFQUkiDQoNCg0KPiANCj4g Mi4xLiAgRnJhbWV3b3JrIGZvciB0aGUgSW50ZXJuYXRpb25hbGl6YXRpb24gRXh0ZW5zaW9uDQo+ IA0KPiAgICAgMy4gIE5vIHBhcmFtZXRlciB2YWx1ZXMgYXJlIGRlZmluZWQgZm9yIHRoaXMgRUhM TyBrZXl3b3JkIHZhbHVlLiAgSW4NCj4gICAgICAgICBvcmRlciB0byBwZXJtaXQgZnV0dXJlIChh bHRob3VnaCB1bmFudGljaXBhdGVkKSBleHRlbnNpb25zLCB0aGUNCj4gICAgICAgICBFSExPIHJl c3BvbnNlIE1VU1QgTk9UIGNvbnRhaW4gYW55IHBhcmFtZXRlcnMgZm9yIHRoYXQga2V5d29yZC4N Cj4gICAgICAgICBJZiBhIHBhcmFtZXRlciBhcHBlYXJzLCB0aGUgU01UUCBjbGllbnQgdGhhdCBp cyBjb25mb3JtYW50IHRvDQo+ICAgICAgICAgdGhpcyB2ZXJzaW9uIG9mIHRoaXMgc3BlY2lmaWNh dGlvbiBNVVNUIHRyZWF0IHRoZSBFU01UUCByZXNwb25zZQ0KPiAgICAgICAgIGFzIGlmIHRoZSBJ TUEga2V5d29yZCBkaWQgbm90IGFwcGVhci4NCj4gDQo+IHMvSU1BL0lFbWFpbC8NCg0Kd2lsbCB1 c2UgSUVtYWlsLg0KDQoNCj4gDQo+ICAgICA2LiAgU2VydmVycyBvZmZlcmluZyB0aGlzIGV4dGVu c2lvbiBNVVNUIHByb3ZpZGUgc3VwcG9ydCBmb3IsIGFuZA0KPiAgICAgICAgIGFubm91bmNlLCB0 aGUgOEJJVE1JTUUgZXh0ZW5zaW9uIFtSRkMxNjUyXS4NCj4gDQo+IEhtbW0hIEkgc2VlIHRoYXQg dGhpcyBtZWFucyB5b3UgYXJlIHN1cHBvc2VkIHRvIGluY2x1ZGUgYSBCT0RZPThCSVRNSU1FICAN Cj4gcGFyYW1ldGVyIGluIHlvdXIgTUFJTCBGUk9NIGNvbW1hbmQgaWYgdGhlIGJvZHkgdXNlcyBU Q0UgOGJpdCAoaGlnaGx5ICANCj4gcHJvYmFibGUgaW4gYW4gRUFJIG1lc3NhZ2UpLiBEbyBhZ2Vu dHMgY3VycmVudGx5IGRvIHRoYXQgaW4gcHJhY3RpY2U/DQoNCmNhbiBJIHN1Z2dlc3QgdGhhdCB3 aGVyZSBpbiB0aGUgZmllbGRzIHRoZXJlIHVzZSBNSU1FIG5vdyAsIHN0aWxsIHVzZSBNSU1FIGlu IHRoZSBlbWFpbCBtZXNzYWdlIG9yIGNvbnRlbnQuDQp3ZSBvbmx5IHVwZGF0ZSB0aGUgZmllbGRz IGNvbnRhaW5pbmcgdGhlIFVFVC04IGVtYWlsIGFkZHJlc3MgdG8gVVRGOC4gDQoNCj4gDQo+IEhv d2V2ZXIsIHRoZXJlIGlzIGFub3RoZXIgcG9zc2libGUgOEJJVE1JTUUgcHJvYmxlbS4gU3VwcG9z ZSB5b3VyIG1lc3NhZ2UgIA0KPiBpcyBhIG11bHRpcGFydCwgYW5kIHN1cHBvc2Ugb25lIG9mIHRo ZSBoZWFkZXJzIG9mIG9uZSBvZiB0aGUgbXVsdGlwYXJ0cyAgDQo+IGNvbnRhaW5zIHNvbWUgVVRG LTgsIGUuZy4NCj4gICAgICBDb250ZW50LURpc3Bvc2l0aW9uOiAuLi4gZmlsZW5hbWU9InNvbWUg dXRmLTggc3R1ZmYiDQo+ICh3aGljaCBzdXJlbHkgd2Ugd2FudCB0byBhbGxvdywgdGhvdWdoIGl0 IGlzIGFjdHVhbGx5IGFuIGV4dGVuc2lvbiB0byBSRkMgIA0KPiAyMDQ1IHdoaWNoIG5lZWRzIHRv IGJlIG1lbnRpb25lZCBpbiB0aGUgdXRmOGhlYWRlcnMgZG9jdW1lbnQpLiBOb3cgdGhpcyAgDQo+ IG1lc3NhZ2UgZW5jb3VudGVycyBhIHNlcnZlciB3aGljaCBzdXBwb3J0cyBuZWl0aGVyIElFbWFp bCBub3IgOEJJVE1JTUUuICANCj4gUkZDIDE2NTIgdGVsbHMgeW91IHRvIGRvd25ncmFkZSB0byA3 Yml0IG9yIGVsc2UgdG8gYm91bmNlLCBzbyBpbiB0aGlzIGNhc2UgIA0KPiB0aGUgInNvbWUgdXRm LTggc3R1ZmYiIG5lZWRzIHRvIGJlIGRvd25ncmFkZWQgYWNjb3JkaWcgdG8gUkZDIDIyMzEsIGFu ZCAgDQo+IHRoaXMgbmVlZHMgdG8gYmUgbWVudGlvbmVkIHNvbWV3aGVyZSBpbiBvdXIgZHJhZnRz LiBNYXliZSB0aGUgZG93bmdyYWRlICANCj4gZG9jdW1lbnQgaXMgdGhlIHBsYWNlIHRvIGRvIGl0 LCBidXQgSSBtZW50aW9uIGl0IGhlcmUgdG8gbWFrZSBzdXJlIGl0IGRvZXMgIA0KPiBub3QgZ2V0 IGZvcmdvdHRlbi4NCj4gDQoNCnBscyBzZWUgYWJvdmUuDQoNCj4gDQo+IDIuMi4gIFRoZSBBZGRy ZXNzIEludGVybmF0aW9uYWxpemF0aW9uIFNlcnZpY2UgRXh0ZW5zaW9uDQo+IA0KPiAgICAgQW55 IGRvbWFpbiBuYW1lcyB0aGF0IGFyZSB0byBiZSBsb29rZWQgdXAgaW4gdGhlIEROUyBNVVNUIGJl DQo+ICAgICBwcm9jZXNzZWQgaW50byB0aGUgZm9ybSBhcyBzcGVjaWZpZWQgaW4gSUROQSBbUkZD MzQ5MF0gYnkgbWVhbnMgb2YNCj4gICAgIHRoZSBUb0FTQ0lJKCkgb3BlcmF0aW9uIHVubGVzcyB0 aGV5IGFyZSBhbHJlYWR5IGluIHRoYXQgZm9ybS4gIEFueQ0KPiAgICAgZG9tYWluIG5hbWVzIHRo YXQgYXJlIHRvIGJlIGNvbXBhcmVkIHRvIGxvY2FsIHN0cmluZ3MgU0hPVUxEIGJlDQo+IA0KPiBz L0ROUyBNVVNUIGJlIHByb2Nlc3NlZC9ETlMgTVVTVCBmaXJzdCBiZSBwcm9jZXNzZWQvDQoNCiAg b2ssIHdpbGwgdXBkYXRlIGl0Lg0KDQo+IA0KPiAgICAgQW4gU01UUCBDbGllbnQgdGhhdCByZWNl aXZlcyB0aGUgSU1BIGV4dGVuc2lvbiBrZXl3b3JkIE1BWSB0cmFuc21pdCBhDQo+ICAgICBtYWls Ym94IG5hbWUgYXMgYW4gaW50ZXJuYXRpb25hbGl6ZWQgc3RyaW5nIGluIFVURi04IGZvcm0gYW5k IE1BWQ0KPiANCj4gcy9yZWNlaXZlcyB0aGUgSU1BIGV4dGVuc2lvbiBrZXl3b3JkIE1BWS9yZWNl aXZlcyB0aGUgSU1BIGV4dGVuc2lvbiAgDQo+IGtleXdvcmQgaW4gcmVzcG9uc2UgdG8gRUhMTyBN QVkvDQoNCm9rLCB3aWxsIHVwZGF0ZSBpdC4NCg0KPiANCj4gICAgIC4uLi4gIElmIHRoZSBJTUEg U01UUCBleHRlbnNpb24gaXMgbm90IG9mZmVyZWQgYnkNCj4gICAgIHRoZSBTZXJ2ZXIsIHRoZSBT TVRQIENsaWVudCBNVVNUIE5PVCB0cmFuc21pdCBhbiBpbnRlcm5hdGlvbmFsaXplZA0KPiAgICAg YWRkcmVzcyBhbmQgTVVTVCBOT1QgdHJhbnNtaXQgYSBtYWlsIGJvZHkgd2hpY2ggY29udGFpbnMN Cj4gICAgIGludGVybmF0aW9uYWxpemVkIG1haWwgaGVhZGVycyBbSU1BLXV0ZjhoZWFkZXJdLiAg SW5zdGVhZCwgaXQgTVVTVA0KPiAgICAgZWl0aGVyIHJldHVybiB0aGUgbWVzc2FnZSB0byB0aGUg dXNlciBhcyB1bmRlbGl2ZXJhYmxlIG9yIHJlcGxhY2UgaXQNCj4gICAgIHdpdGggdGhlIGFsdGVy bmF0ZSBBU0NJSSBhZGRyZXNzLiAgLi4uLi4NCj4gDQo+IEFyZSB5b3UgdHJ5aW5nIHRvIGNvdmVy IGFkZHJlc3NlcyBpbiBib3RoIFNNVFAgY29tbWFuZHMgYW5kIGluIGVtYWlsICANCj4gaGVhZGVy cyBoZXJlPyBJZiBzbywgdGhlbiB0aGUgd29yZHMgImEgbWFpbCBib2R5IiBhcmUgd3JvbmcgKHRo ZSBib2R5IG9mIGEgIA0KPiBtZXNzYWdlIGRvZXMgbm90IGluY2x1ZGUgaXRzIGhlYWRlcnMsIGFw YXJ0IGZyb20gaW4gbXVsdGlwYXJ0cyBhcyBJICANCj4gbWVudGlvbmVkIGVhcmxpZXIpLiBTbyBJ IHRoaW5rIHlvdSBuZWVkDQo+IA0KPiBzL2EgbWFpbCBib2R5L2EgbWVzc2FnZS8NCg0KDQp5ZXMs IHdpbGwgdXNlICJhIG1lc3NhZ2UiLg0KDQoNCj4gDQo+IGJ1dCBpbiBlaXRoZXIgY2FzZSwgIml0 IiBpcyB0b28gdmFndWUsIHNvDQo+IA0KPiBzL2l0L2FsbCBhZGRyZXNzZXMgKGJvdGggaW4gdGhl IGVudmVsb3BlIGFuZCBpbiB0aGUgbWVzc2FnZSdzIGhlYWRlciAgDQo+IGZpZWxkcykvDQoNCg0K d2lsbCBjb25zaWRlciBpdCBjYXJlZnVsbHkuDQoNCg0KPiANCj4gICAgIC4uLiBJZiBpdCBpcyBy ZXBsYWNlZCwgdGhlIHJlcGxhY2VtZW50DQo+ICAgICBNVVNUIGJlIGVpdGhlciB0aGUgQVNDSUkt b25seSBhZGRyZXNzIHNwZWNpZmllZCB3aXRoIHRoZSBBTFQtQUREUkVTUw0KPiAgICAgcGFyYW1l dGVyIG9yIHdpdGggYW4gYWRkcmVzcyBvYnRhaW5lZCBmcm9tIHNvbWUgYWxnb3JpdGhtaWMNCj4g ICAgIGNvbnZlcnNpb25zIG9mIHRoZSBwcmltYXJ5IGFkZHJlc3MgdGhhdCBjb25mb3JtcyB0byB0 aGUgc3ludGF4IHJ1bGVzDQo+ICAgICBvZiBSRkMgMjgyMSwgd2hpY2ggaXMgZGVmaW5lZCBpbiBb SU1BLWRvd25ncmFkaW5nXS4NCj4gDQo+IFRoYXQgd29yZGluZyBpcyBmaW5lIGlmIHRoZSBjbGll bnQgaXMgYW4gZWFybGllciBJRW1haWwtY29tcGxpYW50IHNlcnZlciwgIA0KPiBidXQgaWYgdGhl IHRoZSBjbGllbnQgaXMgdGhlIG9yaWdpbmF0aW5nIE1VQSBpdCBkb2Vzbid0IGhhdmUgYW4gIA0K PiBBTFQtQUREUkVTUyB0byBoYW5kLiBJdCBoYXMgdG8gaW52ZW50IG9uZSBieSB3aGF0ZXZlciBt ZWFucyAobWF5YmUgaXQgIA0KPiBmb3VuZCBvbmUgaW4gdGhlIFRvOiBoZWFkZXIsIG1heWJlIGl0 IGhhZCBhIHRhYmxlIG9mIG1hcHBpbmdzKS4NCg0KeWVzLg0KDQo+IA0KPiBUaGVyZSBpcyBhIGZ1 cnRoZXIgY29tcGxpY2F0aW9uLiBTdXBwb3NlIGEgbWVzc2FnZSBhcnJpdmVzIGF0IHNvbWUgIA0K PiBpbnRlcm1lZGlhdGUgc2VydmVyIHdpdGggb25lIEFMVC1BRERSRVNTIGluIGl0cyBSQ1BUIFRP OiBjb21tYW5kLCBhbmQgYSAgDQo+IGRpZmZlcmVudCBvbmUgaW4gaXRzIFRvOiBoZWFkZXIuIEkg dGhpbmsgdGhlIG9ubHkgc2Vuc2libGUgdGhpbmcgdG8gZG8gaXMgIA0KPiB0byB1c2UgdGhlIG9u ZSBpbiB0aGUgUkNQVCBUTzogY29tbWFuZCBpbiB0aGUgb25nb2luZyAoZG93bmdyYWRlZCkgUkNQ VCAgDQo+IFRPOiwgYW5kIHRoZSBvbmUgZnJvbSB0aGUgVG86IGhlYWRlciBpbiB0aGUgb25nb2lu ZyAoZG93bmdyYWRlZCkgVG86ICANCj4gaGVhZGVyLiBOb3RlIHRoYXQgdGhpcyBhbm9tYWx5IGlz IHBlcmZlY3RseSBwb3NzaWJsZSBpZiwgZm9yIGV4YW1wbGUsIHRoaXMgIA0KPiBpcyBhIG1lc3Nh Z2UgYmVpbmcgcHJvcGFnYXRlZCBieSBzb21lIG1haWxpbmcgbGlzdCBleHBhbmRlci4NCg0KY2Fu IHdlIGRvIHNvbWUgc3BlY2lmaWNhdGlvbiAoYWRkcmVzcyBzeW5jaHJvbml6ZSkgaW4gdGhlIHV0 Zi04LWhlYWRlcnMgZG9jdW1lbnQgdG8gYXZvaWQgc3VjaCBhbm9tYWx5IGluIHRoZSAiUkNQVCBU byIgYW5kICJUbzogaGVhZGVyIj8gZm9yIGV4YW1wbGUsIGlmIEFMVC1BRERSRVNTIGlzIHVzZWQg aW4gIlJDUFQgVG8iLCAiVG86IGhlYWRlciIgd2lsbCBhbHNvIHVzZSBBTFQtQUREUkVTUy4gDQoN Cg0KPiANCj4gMi4zLiAgRXh0ZW5kZWQgTWFpbGJveCBBZGRyZXNzIFN5bnRheA0KPiANCj4gICAg IFdoZXJlICJhdGV4dCIsICJxY29udGVudCIgYW5kICJEUVVPVEUiIGFyZSBkZWZpbmVkIGluIFtS RkMyODIyXSwNCj4gICAgICJMZXQtZGlnIiwgIkxkaC1zdHIiIGFuZCAiYWRkcmVzcy1saXRlcmFs IiBhcmUgZGVmaW5lZCBpbiBbUkZDMjgyMV0NCj4gICAgIGFuZCBVVEY4LTIsIFVURjgtMyBhbmQg VVRGOC00IGFyZSBkZWZpbmVkIGluIFtSRkMzNjI5XS4gIFRoZSB2YWx1ZSBvZg0KPiAgICAgIkxv Y2FsLXBhcnQiIHNob3VsZCBwYXNzIFN0cmluZ3ByZXAgW1JGQzM0NTRdOyBUaGUgdmFsdWUgb2Yg ImRvbWFpbiINCj4gICAgIHNob3VsZCBiZSB2ZXJpZmllZCB3aXRoIFtSRkMzNDkwXTsgSWYgZmFp bGVkLCBUaGUgdmFsdWUgb2YgIkxvY2FsLQ0KPiAgICAgcGFydCIgYW5kICJkb21haW4iLCB0aGUg ZW1haWwgYWRkcmVzcyBjYW4gbm90IGJlIHJlZ2FyZGVkIGFzIHRoZQ0KPiAgICAgdmFsaWQgZW1h aWwgYWRkcmVzcy4NCj4gDQo+IHMvc2hvdWxkL1NIT1VMRC8NCg0Kd2lsbCB1c2UgU0hPVUxEDQoN Cj4gDQo+IEhvd2V2ZXIsIHlvdSBjYW5ub3Qgc3BlY2lmeSBTdHJpbmdwcmVwIHdpdGhvdXQgc3Rh dGluZyB3aGF0ICdwcm9maWxlJyBvZiAgDQo+IFN0cmluZ3ByZXAgeW91IHJlcXVpcmUuIE1heWJl IHlvdSBjYW4gZmluZCBhbiBleGlzdGluZyBvbmUgdGhhdCBzdWl0cyB5b3VyICANCj4gbmVlZCAo YnV0IG5vdCBOYW1lcHJlcCwgYmVjYXVzZSB0aGF0IHJlbW92ZXMgYW5kIHVwcGVyL2xvd2VyY2Fz ZSAgDQo+IGRpc3RpbmN0aW9ucykuIFlvdSBjb3VsZCBlYXNpbHkgZGVmaW5lIHlvdXIgb3duIHBy b2ZpbGUgYnkgaW5kaWNhdGluZyAgDQo+IHdoaWNoIG9mIHRoZSB2YXJpb3VzIHRhYmxlcyBmcm9t IFJGQyAzNDU0IHdlcmUgdG8gYmUgYXBwbGllZC4gSSBhZ3JlZSB0aGF0ICANCj4gbG9jYWwtcGFy dHMgc2hvdWxkIGhhdmUgX3NvbWVfIHN1aXRhYmxlIFN0cmluZ3ByZXAgYXBwbGllZCB0byB0aGVt LiBUaGV5ICANCj4gYXJlIGVzc2VudGlhbGx5ICdpZGVudGlmaWVycycgaW4gbmF0dXJlLCBhbmQg c2hvdWxkIGF0IGxlYXN0IGFkaGVyZSB0byAgDQo+IFdZU0lXWUcgKGJ1dCBub3RlIGluIHBhc3Np bmcgdGhhdCBSRkMgMjgyMiBsb2NhbC1wYXJ0cyBhbHJlYWR5IGZhaWwgIA0KPiBTdHJpbmdwcmVw IGJ5IHBlcm1pdHRpbmcgY29udHJvbCBjaGFyYWN0ZXJzKS4NCj4gDQoNClllcywgd2Ugc2hvdWxk IGhhdmUgb3VyIG93biBTdHJpbmdwcmVwIGZvciB0aGUgZW1haWwgbG9jYWwgcGFydC4NCg0KDQo+ IEFzIGFuIGFzaWRlLCBJIGp1c3Qgbm90aWNlZCB0aGF0IEpvaG4gS0xlbnNpbidzIHV0ZjggZHJh ZnQgY2Fubm90IGJlICANCj4gZXhwcmVzc2VkIGFzIGEgcHJvZmlsZSBvZiBTdHJpbmdwcmVwICh3 aGljaCBpcyBhY3R1YWxseSBhcyBpdCBzaG91bGQgYmUsICANCj4gYmVjYXVzZSBpdCBpcyBub3Qg dHJ5aW5nIHRvIHJlc3RyaWN0IGl0c2VsZiB0byAnaWRlbnRpZmllcidzKS4NCj4gDQo+IDIuNC4g IFRoZSBBTFQtQUREUkVTUyBhbmQgQVRPTUlDIHBhcmFtZXRlcg0KPiANCj4gSSB3YXMgZXhwZWN0 aW5nIHRvIHNlZSBzb21lIHN5bnRheCBmb3IgdGhlc2UsIGFuZCBkaWRuJ3QuIEkgdGhpbmsgeW91 IGhhdmUgIA0KPiB0byBzYXkgdGhhdCB0aGV5IHRha2UgdGhlIGZvcm0gb2YgPGVzbXRwLXBhcmFt PnMgYXMgZGVmaW5lZCBpbiBSRkMgMjgyMSwgIA0KPiB3aGVyZSB0aGUgZXNtdHAta2V5d29yZCBp cyAiQUxULUFERFJFU1MiICgiQVRPTUlDIikgYW5kIHRoZSBlc210cC12YWx1ZSBpcyAgDQo+IGFu IGFkZHJlc3MgKCJ5ZXMiIG9yICJubyIpLiBBbHNvIHRoYXQgZXZlcnl0aGluZyAoZXhjZXB0IGlu IGFkZHJlc3NlcykgaXMgIA0KPiBjYXNlLWluc2Vuc2l0aXZlLg0KDQp5ZXMsIHdlIHdpbGwgdXNl IHRoZSBmb3JtIGRlZmluZWQgaW4gcmZjMjgyMS4NCg0KICAgICAgTUFJTCBGUk9NOjxyZXZlcnNl LXBhdGg+IFtTUCA8bWFpbC1wYXJhbWV0ZXJzPiBdIDxDUkxGPg0KICAgICAgUkNQVCBUTzo8Zm9y d2FyZC1wYXRoPiBbIFNQIDxyY3B0LXBhcmFtZXRlcnM+IF0gPENSTEY+DQogICAgICBNYWlsLXBh cmFtZXRlcnMgPSBlc210cC1wYXJhbSAqKFNQIGVzbXRwLXBhcmFtKQ0KICAgICAgUmNwdC1wYXJh bWV0ZXJzID0gZXNtdHAtcGFyYW0gKihTUCBlc210cC1wYXJhbSkNCiAgICAgIGVzbXRwLXBhcmFt ICAgICA9IGVzbXRwLWtleXdvcmQgWyI9IiBlc210cC12YWx1ZV0NCiAgICAgIGVzbXRwLWtleXdv cmQgICA9IChBTFBIQSAvIERJR0lUKSAqKEFMUEhBIC8gRElHSVQgLyAiLSIpDQogICAgICBlc210 cC12YWx1ZSAgICAgPSAxKiglZDMzLTYwIC8gJWQ2Mi0xMjcpDQogICAgICAgICAgICA7IGFueSBD SEFSIGV4Y2x1ZGluZyAiPSIsIFNQLCBhbmQgY29udHJvbCBjaGFyYWN0ZXJzDQoNCiBmb3IgZXhh bXBsZSA6DQogICAgbWFpbCBmcm9tIDogPHV0Zi04Q2hhcmFjdGVyc0FAaWRuYT4gICAgYWx0LWFk ZHJlc3M9eWFvamtAY25uaWMuY24gYXRvbWljPXkNCiAgICByY3B0IHRvOiAgICAgIDx1dGYtOENo YXJhY3RlcnNCQGlkbmE+ICAgIGFsdC1hZGRyZXNzPXVzZXJAZXhhbXBsZS5jbiBhdG9taWM9eSAg ICAgDQoNCnllcywgSSB3aWxsIGVtcGhhc2l6ZSB0aGF0IHRoZSBkZWlmaW5pdG9uIG9mIE1BSUwg RlJPTTo8cmV2ZXJzZS1wYXRoPiBbU1AgPG1haWwtcGFyYW1ldGVycz4gXSA8Q1JMRj4gYW5kICAg ICAgUkNQVCBUTzo8Zm9yd2FyZC1wYXRoPiBbIFNQIDxyY3B0LXBhcmFtZXRlcnM+IF0gPENSTEY+ DQppcyBmcm9tIHJmYzI4MjEuDQoNCg0KDQo+IA0KPiAgICAgLi4uIFRoZSBmaW5hbCBkZWxpdmVy eSBTTVRQIHNlcnZlcg0KPiAgICAgY2FuIHJldmVydCB0aGUgYWRkcmVzc2VzIGV2ZW4gdGhvdWdo IHRoZXkgYXJlIGFzIGluIGFsbCBBU0NJSSBmb3JtLg0KPiANCj4gcy9yZXZlcnQvcmVzdG9yZS8N Cj4gcy9hcy9ub3cvDQoNCndpbGwgdXBkYXRlIGl0Lg0KDQo+IA0KPiAgICAgLi4uIElmIHRoZQ0K PiAgICAgQUxULUFERFJFU1MgdmFsdWUgaXMgbm90IHNldCBieSB0aGUgc2VuZGVyIGJ1dCB0aGUg dmFsdWUgb2YgQVRPTUlDIGlzDQo+ICAgICAneScsIHRoZSBzZW5kZXIgU01UUCBzZXJ2ZXIgc2hv dWxkIGFwcGx5IHNvbWUgYWxnb3JpdGhtaWMNCj4gICAgIHRyYW5zZm9ybWF0aW9uIHN1Y2ggYXMg cHVueWNvZGUgdG8gdGhlIGVudGlyZSBsb2NhbCBwYXJ0IG9mIElNQTsgLi4uDQo+IA0KPiBObywg ZnJvbSB0aGUgUE9WIG9mIHRoZSBzZXJ2ZXIgdGhhdCBtaWdodCBiZSBnb2luZyB0byBkb3duZ3Jh ZGUgdGhlICANCj4gYWRkcmVzcywgdGhlICJzZW5kZXIiIGlzIGFjdHVhbGx5IGFuIFNNVFAgImNs aWVudCIgKHdoaWNoIG1pZ2h0IGJlIGFub3RoZXIgIA0KPiBzZXJ2ZXIsIG9yIG1pZ2h0IGJlIGFu IE1VQSkuDQoNCnNvIHdlIGNoYW5nZSB0aGUgd29yZCAic2VuZGVyIiB0byAiZW1haWwgdXNlciIs IGlzIGl0IG9rPw0KDQo+IA0KPiBzL3Nob3VsZC9TSE9VTEQvIChvciBpcyBpdCBNQVk/KQ0KDQph Y2NvcmRpbmcgdG8gb3VyIGN1cnJlbnQgZGVzaWduIGxvZ2ljLCB3ZSB1c2UgU0hPVUxELg0KDQo+ IA0KPiBCdXQgeW91IGNhbm5vdCBzYXkgInN1Y2ggYXMgcHVueWNvZGUiLiBZb3UgbmVlZCB0byBz cGVjaWZ5IGV4YWN0bHkgd2hhdCAgDQo+IHRyYW5zZm9ybWF0aW9uIGlzIHRvIGJlIHVzZWQgKG9y IG1vcmUgbGlrZWx5IHBvaW50IHRvIHRoZSBkb3duZ3JhZGUgIA0KPiBkb2N1bWVudCB0byBzcGVj aWZ5IGl0KS4gQnV0IGl0IGNlcnRhaW5seSB3b24ndCBiZSBwdW55Y29kZSwgYmVjYXVzZSAgDQo+ IHB1bnljb2RlIGRlc3Ryb3lzIGFsbCBjYXNlIGRpc3RpbmN0aW9ucyBBSVVJLCB3aGljaCBpcyBu b3QgZ29vZCBlbm91Z2ggZm9yICANCj4gbG9jYWwgcGFydHMuDQoNCml0IHNlZW1zIHRoYXQgbm93 IHdlIHN0aWxsIGRvIG5vdCBnZXQgY29uc2Vuc3VzIGFib3V0IHRoaXMgaXNzdWU6IHdoaWNoIHRy YW5zZm9ybWF0aW9uIG1ldGhvZCBpcyB1c2VkLg0Kc28gSSB3aWxsIHBvaW50IHRvIHRoZSBkb3du Z3JhZGUgZG9jdW1lbnQgdG8gc3BlY2lmeSBpdC4NCg0KPiANCj4gICAgIFRoZSBzdWdnZXN0ZWQg YWxnb3JpdGhtaWMgdHJhbnNmb3JtYXRpb24gaXMgcHVueWNvZGUgaWYgdGhlIHZhbHVlIG9mDQo+ ICAgICBBTFQtQUREUkVTUyBpcyBub3Qgc2V0IGJ5IHNlbmRlciBhbmQgdGhlIHZhbHVlIG9mIEFU T01JQyBpcyAneScgd2hlbg0KPiAgICAgU01UUCBzZXJ2ZXJzIGNhbiBub3Qgc3VwcG9ydCBJTUEu ICBTaW5jZSB0aGUgcHJlZml4ICJ4bi0tIiBoYWQgYmVlbg0KPiAgICAgdXNlZCBmb3IgSUROQSwg aXQgaXMgYmV0dGVyIHRoYXQgb3RoZXIgcHJlZml4IHN1Y2ggYXMgImJxLS0iIGlzIHVzZWQNCj4g ICAgIGZvciB0aGUgbG9jYWwgcGFydCBvZiBjb252ZXJ0ZWQgdmVyc2lvbiBvZiB0aGUgcHJpbWFy eSBhZGRyZXNzIHRvDQo+ICAgICBhdm9pZCB0aGUgcG90ZW50aWFsIGNvbmZ1c2lvbi4NCj4gDQo+ IE5vLCBpdCBtdXN0IGJlIG1vcmUgdGhhbiAic3VnZ2VzdGVkIiwgYXMgSSBzYWlkIGFib3ZlIChv dGhlcndpc2UgdGhlICANCj4gcmVjaXBpZW50IHdpbGwgbm90IGJlIGFibGUgdG8gdW5kZXJzdGFu ZCBpdCkuIEJldHRlciB0byBvbWl0IHRoaXMgIA0KPiBwYXJhZ3JhcGggZW50aXJlbHksIGFuZCBs ZWF2ZSBpdCB0byB0aGUgZG93bmdyYWRlIGRvY3VtZW50IHRvIHdvcnJ5IGFib3V0ICANCj4gcHJl Zml4ZXMgc3VjaCBhcyAieG4tLSIuDQoNCkkgd2lsbCBwb2ludCB0byB0aGUgZG93bmdyYWRlIGRv Y3VtZW50IHRvIHNwZWNpZnkgaXQuDQoNCj4gDQo+IDIuNS4yLiAgVHJhY2UgRmllbGRzDQo+IA0K PiAgICAgSW50ZXJuYXRpb25hbGl6ZWQgZG9tYWluIG5hbWVzIGluIFJlY2VpdmVkIGZpZWxkcyBt dXN0IGJlIHRyYW5zbWl0dGVkDQo+ICAgICBpbiB0aGUgcHVueWNvZGUgZm9ybS4gIEFkZHJlc3Nl cyBpbiAiZm9yIiBjbGF1c2VzIG5lZWQgZnVydGhlcg0KPiAgICAgZXhhbWluYXRpb24gLi4uDQo+ IA0KPiBBZ2FpbiwgbGVhdmUgYWxsIHRoaXMgdG8gdGhlIGRvd25ncmFkZSBkb2N1bWVudC4gSSB0 aGluayB3ZSBub3cgaGF2ZSBzb21lICANCj4gc29ydCBvZiBjb25zZW5zdXMgb24gaG93IHRvIGRv d25ncmFkZSB0aGVzZSwgYmFzZWQgb24gTmV3bWFuJ3MgcHJvcG9zYWwuICANCj4gQnV0IHRoZSBk b3duZ3JhZGUgZG9jdW1lbnQgaXMgdGhlIHBsYWNlIHRvIGRlc2NyaWJlIHRoaXMgKGp1c3QgYXMg aXQgaXMgIA0KPiB0aGUgcGxhY2UgdG8gZGVzY3JpYmUgZG93bmdyYWRpbmcgb2YgYWxsIHRoZSBv dGhlciBoZWFkZXJzKS4gVGhlIG9ubHkgIA0KPiByZXNwZWN0IGluIHdoaWNoIFRyYWNlIGZpZWxk cyBhcmUgc3BlY2lhbCBoZXJlIGlzIHRoYXQgc2VydmVycyB3aWxsIGFsc28gIA0KPiBiZSBnZW5l cmF0aW5nIHRoZW0sIGFuZCB0aGVuIG1heWJlIGltbWVkaWF0ZWx5IGRvd25ncmFkZWQgd2hhdCB0 aGV5IGhhdmUgIA0KPiBpbnZlbnRlZCAod2VsbCwgdGhlcmUgaXMgYW4gb2J2aW91cyBvcHRpbWl6 YXRpb24gdGhlcmUpLg0KDQoNCnllcywgd2lsbCBjb25zaWRlciBpdC4NCg0KDQo+IA0KPiAzLjIu ICBQT1AgYW5kIElNQVANCj4gDQo+IEkgZG9uJ3QgdGhpbmsgdGhpcyBzZWN0aW9uIHJlYWxseSBi ZWxvbmdzIGluIHRoaXMgZG9jdW1lbnQuIFRoZXJlIHdpbGwgYmUgIA0KPiBzZXBhcmF0ZSBkb2N1 bWVudHMgaW4gZHVlIGNvdXJzZS4NCg0KeWVzLCB3aWxsIGNvbnNpZGVyIGl0Lg0KDQo+IA0KPiAz LjMuICBJbXBhY3QgdG8gUkZDIDI0NzYgYW5kIG1hbnkgZW1haWwgcmVsYXRlZCBSRkMNCj4gDQo+ IFllcywgeW91ciBkcmFmdCBhbHNvIG5lZWRzIHRvIGRlZmluZSB3aGljaCBvZiB5b3VyIGV4dGVu c2lvbnMgYXBwbHkgdG8NCj4gICAgIFJGQyAyNDc2IHN1Ym1pc3Npb24gYWdlbnRzDQo+ICAgICBS RkMgMzQ2MSBkZWxpdmVyeSBzdGF0dXMgbm90aWZpY2F0aW9uICh3aGF0IGlzIGFjdHVhbGx5IG5l ZWRlZCB0aGVyZT8pDQo+ICAgICBSRkMgPz8/PyBMTVRQDQo+IA0KPiBFc3NlbnRpYWxseSwgeW91 IGFyZSBleHRlbmRpbmcgYWxsIHRoZXNlIGluIGFkZGl0aW9uIHRvIFJGQyAyODIxLiBUaGVyZSAg DQo+IG1heSBiZSBvdGhlcnMgYXMgd2VsbC4NCg0KeWVzLCB3aWxsIGNvbnNpZGVyIGl0Lg0KDQoN CnRoYW5rcyBhIGxvdC4NCllhbyBKaWFua2FuZw0KQ05OSUMNCg0KPiANCj4gLS0gDQo+IENoYXJs ZXMgSC4gTGluZHNleSAtLS0tLS0tLS1BdCBIb21lLCBkb2luZyBteSBvd24gdGhpbmctLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gVGVsOiArNDQgMTYxIDQzNiA2MTMxIEZheDogKzQ0IDE2MSA0 MzYgNjEzMyBXZWI6IGh0dHA6Ly93d3cuY3MubWFuLmFjLnVrL35jaGwNCj4gRW1haWw6IGNobEBj bGVyZXcubWFuLmFjLnVrIFNuYWlsOiA1IENsZXJld29vZCBBdmUsIENIRUFETEUsIFNLOCAzSlUs IFUuSy4NCj4gUEdQOiAyQzE1RjFBOSBGaW5nZXJwcmludDogNzMgNkQgQzIgNTEgOTMgQTAgMDEg RTcgNjUgRTggNjQgN0UgMTQgQTQgQUIgQTUNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1BQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ0KPiA= --===============1585172246== 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 --===============1585172246==--