From ima-bounces@ietf.org Wed Jan 7 08:48:03 2009 Return-Path: X-Original-To: eai-archive-ahk8aHax@lists.ietf.org Delivered-To: ietfarch-eai-archive-ahk8aHax@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 599213A69A6; Wed, 7 Jan 2009 08:48:03 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F3413A69A6 for ; Wed, 7 Jan 2009 08:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlRnOE5BxMU9 for ; Wed, 7 Jan 2009 08:48:01 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 331503A694D for ; Wed, 7 Jan 2009 08:48:01 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1LKbZL-000CO6-8D for ima@ietf.org; Wed, 07 Jan 2009 11:47:47 -0500 Date: Wed, 07 Jan 2009 11:47:43 -0500 From: John C Klensin To: ima@ietf.org Message-ID: <3A7D686AA42A9D33730D7143@PST.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Disposition: inline Subject: [EAI] IETF Last Call comment on downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Hi. Just FYI, I just posted a lengthy note to the IETF list on the downgrade Last Call (deliberately late, as the note indicates). It supports publishing the document as Experimental, but reviews all of the reasons why EAI might be a lot cleaner and simpler with a traditional "either the address is deliverable or it is not" model rather than in-transit downgrading. I didn't cross-post it here because I use different addresses for the two lists. I've said all of this before (although at more length to the design team than the WG); none of it should come as any surprise to anyone who has been following the WG's work. A summary of the suggestion in the note is that * The document should be published as Experimental; if we are going to support in-transit downgrading, it is probably the best that can be done. * During the experiment period, the community should review costs and benefits very carefully, especially wrt interactions with the non-EAI-aware systems with which downgrading is expected to help, leakage of the new address forms to older systems and how the latter react, relative costs of implementation, etc. best new year's wishes to all. best, john _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 9 01:34:24 2009 Return-Path: X-Original-To: eai-archive-ahk8aHax@lists.ietf.org Delivered-To: ietfarch-eai-archive-ahk8aHax@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57CAC3A6969; Fri, 9 Jan 2009 01:34:24 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04083A6969 for ; Fri, 9 Jan 2009 01:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.023 X-Spam-Level: X-Spam-Status: No, score=-0.023 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txy+MN9Yk8BS for ; Fri, 9 Jan 2009 01:34:22 -0800 (PST) Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by core3.amsl.com (Postfix) with ESMTP id 6CAEB3A692F for ; Fri, 9 Jan 2009 01:34:21 -0800 (PST) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id n099Y7oP018712 for ; Fri, 9 Jan 2009 18:34:07 +0900 (JST) Received: from (unknown [133.2.206.133]) by scmse2.scbb.aoyama.ac.jp with smtp id 4f41_a9599934_de30_11dd_a4ee_0019b9e2b3d9; Fri, 09 Jan 2009 18:34:07 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:47648) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 9 Jan 2009 18:26:01 +0900 Message-Id: <6.0.0.20.2.20090109180627.08419370@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 09 Jan 2009 18:09:16 +0900 To: John C Klensin , ima@ietf.org From: Martin Duerst In-Reply-To: <3A7D686AA42A9D33730D7143@PST.jck.com> References: <3A7D686AA42A9D33730D7143@PST.jck.com> Mime-Version: 1.0 Subject: Re: [EAI] IETF Last Call comment on downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Hello John, As far as I'm aware of, all the documents from this WG so far have been published as experimental (or informational for those that don't specify any kind of protocol or format). Are you saying that downgrade should be even more experimental than experimental? Or that you think that while the others should go to proposed in a next round, that shouldn't apply to downgrade? Or what? Regards, Martin. At 01:47 09/01/08, John C Klensin wrote: >Hi. > >Just FYI, I just posted a lengthy note to the IETF list on the >downgrade Last Call (deliberately late, as the note indicates). >It supports publishing the document as Experimental, but reviews >all of the reasons why EAI might be a lot cleaner and simpler >with a traditional "either the address is deliverable or it is >not" model rather than in-transit downgrading. > >I didn't cross-post it here because I use different addresses >for the two lists. > >I've said all of this before (although at more length to the >design team than the WG); none of it should come as any surprise >to anyone who has been following the WG's work. > >A summary of the suggestion in the note is that > >* The document should be published as Experimental; if we are >going to support in-transit downgrading, it is probably the best >that can be done. > >* During the experiment period, the community should review >costs and benefits very carefully, especially wrt interactions >with the non-EAI-aware systems with which downgrading is >expected to help, leakage of the new address forms to older >systems and how the latter react, relative costs of >implementation, etc. > >best new year's wishes to all. > best, > john > >_______________________________________________ >IMA mailing list >IMA@ietf.org >https://www.ietf.org/mailman/listinfo/ima #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 9 01:41:49 2009 Return-Path: X-Original-To: eai-archive-ahk8aHax@lists.ietf.org Delivered-To: ietfarch-eai-archive-ahk8aHax@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1661C3A68CB; Fri, 9 Jan 2009 01:41:49 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0E3E3A68CB for ; Fri, 9 Jan 2009 01:41:47 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.046 X-Spam-Level: ** X-Spam-Status: No, score=2.046 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_23=0.6, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYjs8va1T-At for ; Fri, 9 Jan 2009 01:41:47 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 769923A67BD for ; Fri, 9 Jan 2009 01:41:45 -0800 (PST) Received: (eyou send program); Fri, 09 Jan 2009 17:41:32 +0800 Message-ID: <431494092.01700@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 09 Jan 2009 17:41:32 +0800 Message-ID: <014301c9723e$733b8870$236ff1da@yaojk> From: "YAO Jiankang" To: "John C Klensin" , , "Martin Duerst" References: <3A7D686AA42A9D33730D7143@PST.jck.com> <431493656.10333@cnnic.cn> Date: Fri, 9 Jan 2009 17:41:28 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [EAI] IETF Last Call comment on downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org ----- Original Message ----- From: "Martin Duerst" To: "John C Klensin" ; Sent: Friday, January 09, 2009 5:09 PM Subject: Re: [EAI] IETF Last Call comment on downgrade > Hello John, > > As far as I'm aware of, all the documents from this WG > so far have been published as experimental (or informational > for those that don't specify any kind of protocol or format). > > Are you saying that downgrade should be even more > experimental than experimental? >Or that you think > that while the others should go to proposed in a > next round, that shouldn't apply to downgrade? I think that your second understanding is what John wants to express. > Or what? > > Regards, Martin. > > At 01:47 09/01/08, John C Klensin wrote: >>Hi. >> >>Just FYI, I just posted a lengthy note to the IETF list on the >>downgrade Last Call (deliberately late, as the note indicates). >>It supports publishing the document as Experimental, but reviews >>all of the reasons why EAI might be a lot cleaner and simpler >>with a traditional "either the address is deliverable or it is >>not" model rather than in-transit downgrading. >> >>I didn't cross-post it here because I use different addresses >>for the two lists. >> >>I've said all of this before (although at more length to the >>design team than the WG); none of it should come as any surprise >>to anyone who has been following the WG's work. >> >>A summary of the suggestion in the note is that >> >>* The document should be published as Experimental; if we are >>going to support in-transit downgrading, it is probably the best >>that can be done. >> >>* During the experiment period, the community should review >>costs and benefits very carefully, especially wrt interactions >>with the non-EAI-aware systems with which downgrading is >>expected to help, leakage of the new address forms to older >>systems and how the latter react, relative costs of >>implementation, etc. >> >>best new year's wishes to all. >> best, >> john >> >>_______________________________________________ >>IMA mailing list >>IMA@ietf.org >>https://www.ietf.org/mailman/listinfo/ima > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 9 07:32:33 2009 Return-Path: X-Original-To: eai-archive-ahk8aHax@lists.ietf.org Delivered-To: ietfarch-eai-archive-ahk8aHax@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53B4B3A6A70; Fri, 9 Jan 2009 07:32:33 -0800 (PST) X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FDF93A6A70 for ; Fri, 9 Jan 2009 07:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VmIPfySSUKY for ; Fri, 9 Jan 2009 07:32:31 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 9342F3A6358 for ; Fri, 9 Jan 2009 07:32:30 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1LLJLA-0009ve-Qq; Fri, 09 Jan 2009 10:32:05 -0500 Date: Fri, 09 Jan 2009 10:31:57 -0500 From: John C Klensin To: Martin Duerst , ima@ietf.org Message-ID: In-Reply-To: <6.0.0.20.2.20090109180627.08419370@localhost> References: <3A7D686AA42A9D33730D7143@PST.jck.com> <6.0.0.20.2.20090109180627.08419370@localhost> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [EAI] IETF Last Call comment on downgrade X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --On Friday, January 09, 2009 18:09 +0900 Martin Duerst wrote: > Hello John, Sorry for not being clear. This is really an issue about technical tradeoffs, rather than a procedural one, but I think it is useful to think/talk about it right now in procedural terms.. > As far as I'm aware of, all the documents from this WG > so far have been published as experimental (or informational > for those that don't specify any kind of protocol or format). Yes. I note that documents from an IETF WG are published as Experimental for at least two different reasons: (i) To get a chance to demonstrate that they work, for any values of "work" that may be relevant. The expectation is that once that demonstration completes, the results can be evaluated, the protocols adjusted as needed, and decisions made that would lead to standards-track publication of a revision/update. (ii) To publish them as what, in another SDO, are jokingly referred to as "substandards" --not ready for standardization-- with the expectation that they will never advance further. I certainly believe that the entire EAI package, including downgrade, falls into the first group. > Are you saying that downgrade should be even more > experimental than experimental? Or that you think > that while the others should go to proposed in a > next round, that shouldn't apply to downgrade? > Or what? I take the classification of "experimental" seriously -- as an opportunity to get a specification (or collection of specifications) published in solid, public, form to assist in generating interoperable implementations and testing and evaluating them. I think those evaluations actually ought to occur and that it is a flaw in the IETF procedures that experimental documents do not require a statement about evaluation periods... and an automatic move to Historic if the evaluations are not completed and published within a set period of time. A corollary to that is that I don't believe the second group above should exist at all. However, please note that I have been making both of those suggestions for around 20 years now and have gotten nowhere -- for better or worse, we are stuck with ad hoc arrangements in which some Experimental specifications are evaluated much more carefully than others. What I'm suggesting is that Downgrade --and the EAI suite including Downgrade-- should be evaluated very carefully and that the evaluation should include what I see as a very explicit tradeoff between: (1) With Downgrade in its present form, some messages are going to get through that would not otherwise go through. Some subset of those messages are going to arrive without information loss and the recipient (or agents intermediate between the delivery MTA and the recipient) will be able to deduce and reconstruct the form of the original message. We don't know how many messages that would otherwise be undeliverable will get through as a result of having Downgrade, nor do we know what level of information loss will occur. We also don't know how much the ">" will leak into non-EAI environments (although experience with email predicts "quite a lot", nor what problems such leakage will cause. The answers to those questions are obviously part of the experiment. (2) Without Downgrade in its present form, implementation of EAI becomes easier, perhaps even vastly easier. The ">" syntax disappears, as does the collection of "Downgraded" headers, so we don't need to worry about their effects or about long-term clutter to the protocols or syntax. We don't know whether easier and less complex implementation will lead to more implementations, earlier implementations, or to fewer bugs and interoperability problems than would occur with those full-Downgrade implementations. We also don't know how many implementations will choose the shortcut path -- rejecting messages requiring downgrading rather than going through the downgrade procedure. The answers to those questions may be, and are likely to remain, more speculative than those above, but they are also obviously part of the experiment. That is a more or less classic engineering design tradeoff issue, with one set of advantages being on a somewhat different scale than the other, i.e., putting them on a single scale is hard or impossible without biasing the outcome. It is also typical of such tradeoffs in the real world, because full information is simply not available or likely to become available. We just need to gather what information we can and make a educated guesses. I am suggesting that the tradeoff is important and that those guesses should be as educated, and data-based, as possible. When we got started with the EAI work, our hypothesis was that Downgrading was both necessary and reasonably straightforward. We've learned that it was less straightforward than we expected, that the number of cases in which it could be applied were fewer than expected (e.g., the requirement that all non-ASCII addresses be associated with alternate forms). We also had not seriously considered the mailing list issues, nor anticipated the conclusion we seem to have reached. On the other side of things, we probably have a better understanding of the ways in which the need to downgrade can, and cannot, be controlled by careful and thoughtful system configuration. Give that, the question of "is this particular feature really worth the trouble" is one that we have properly not asked since EAI was chartered. I believe that it is one that we should start asking seriously as soon as Downgrade is approved, with the complexity of that specification and its interactions with the other specifications as part of the data. My note was simply a plea that the community ask it and a heads-up that the question was important. That doesn't make Downgrade any different from any other Experimental spec except that someone has explicitly proposed evaluation criteria other than "implement it and see if it interworks with cooperating implementations". Now, if what you are really asking about is my personal opinion... At this point, I believe we would be better off * without Downgrade as specified * pushing for rapid implementation and deployment of an internationalized email solution that is free of in-transit downgrading and the associated syntax, header, digital signature, etc., issues * concentrating our efforts on address downgrading procedures that could be applied at the endpoints -- the sending MUA or submission MTA and after SMTP final delivery, rather than figuring out how to make in-transit work * getting more specific about the cases in which in-transit downgrading might be needed and how they can best be avoided by careful configuration. Some of those statements argue strongly for revisiting and publishing the Scenarios document, perhaps in the form of an "operational hints" document. But those are just personal beliefs. Worse, they are based on some speculative reasoning. My main interest at this point is a careful and fair experimental and evaluation process that gives us more information about risks and tradeoffs. Does that answer your question? john _______________________________________________ IMA mailing list IMA@ietf.org https://www.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 20 01:00:04 2009 Return-Path: X-Original-To: eai-archive-ahk8aHax@lists.ietf.org Delivered-To: ietfarch-eai-archive-ahk8aHax@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F80A28C124; Tue, 20 Jan 2009 01:00:04 -0800 (PST) X-Original-To: ima@ietf.org Delivered-To: ima@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1C2D63A6BAB; Tue, 20 Jan 2009 01:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090120090002.1C2D63A6BAB@core3.amsl.com> Date: Tue, 20 Jan 2009 01:00:02 -0800 (PST) Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-downgrade-11.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Downgrading mechanism for Email Address Internationalization Author(s) : K. Fujiwara, Y. Yoneya Filename : draft-ietf-eai-downgrade-11.txt Pages : 27 Date : 2009-01-20 Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in SMTP envelope and mail header fields. To avoid rejecting internationalized Email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-downgrade-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-eai-downgrade-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-20005940.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/ima --NextPart--