Hi. This comment is deliberately being submitted a couple of days after the Last Call closes because it does not address any technical issues with the document under consideration. As discussed below, I believe that the current document should be published as Experimental. However, I believe that the general model of the specification raises issues that the community should consider very broadly in the coming months. These issues do not come as a surprise to the WG and were identified there many months ago. The WG concluded that downgrading was important, a decision I support at least to the extent of publishing this document. I strongly support the publication of this document, as written, as Experimental. I believe that further fussing with small details will, by introducing more delays after the core email i18n documents have been published, probably cause more problems than it might solve. However, I encourage the community to monitor and evaluate the use of this specification in the environment of the Internet's actual, running, email systems, not just to accept demonstrations among cooperating and coordinated parties as evidence of a successful experiment. The downgrade model adds a huge amount of complexity to the EAI protocol collection and there appears to be no less complex way to provide in-transit downgrading. I believe the community needs to evaluate the advantages of in-transit downgrading for the casts in which it will apply (there are many for which it will not) against the cost of the complexity (including its cost as a deterrent to EAI implementations) it introduces. It appears to me that a follow-on standards-track EAI specification should probably not include this capability. _Summary_ While I had some small role in the design of the downgrade model and believe it is the best we can do, I have concluded that it is a mistake and that it violates some fundamental principles of protocol design generally and email in particular. Details, including some summary information that will be familiar to anyone who has studied the specification and its relationship to the other EAI documents, appear below. _A Contextual Review of the Downgrading Idea_ Everyone should understand that downgrading introduces (1) New syntax for carrying alternate (all-ASCII) addresses in both SMTP and mail headers. While the SMTP form is probably harmless (the information is carried in a parameter which the server must agree to accept), the header form --the form most likely to leak into other environments-- is likely to cause parsing errors and/or general confusion if seen by non-EAI-aware systems or users. (2) A series of new headers in an attempt to preserve information. Given the existence of systems on the Internet that will strip headers that they do not recognize in the interest of security, these headers may be discarded by some systems that are not upgraded to support them, losing precisely the information that they are intended to preserve. Whether it is likely that such systems will be upgraded without being make fully EAI-competent is an open question whose answer requires a good deal of speculation about implementer behavior. (3) Far more implementation work --at least for an "eight-bit clean" environment-- to support those features than would be needed to convert existing systems to support the other EAI features. More on this below. I do not believe there is any controversy about those three points. The question is whether it is worth it. Downgrading is also not automatically effective. For it to have any hope of working, the user originating the message (or a user-side agent) must obtain and supply alternate (all-ASCII) addresses for every non-ASCII address that appears in the envelope and headers. If there is a non-ASCII address without an associated all-ASCII one, then the message cannot be downgraded at all and must be rejected if it cannot be forwarded along an EAI-conformant path. As with 8BITMIME, a conforming implementation may choose to reject a message if it cannot be forwarded along a conforming path rather than downgrading it. One of the experimental questions is how many implementations will select that less complex option. After trying to analyze the use cases and weigh them against the huge amount of complexity this adds to the email system generally and to EAI in particular, I think the experiment should specifically examine the question of whether that complexity is worth it and, in particular, whether the expectation of implementing may actually retard the deployment of UTF-8 email addresses and structures. Ultimately, an "alternate address" is just that -- an "if this address doesn't work, try that one" mechanism for messages in transit. We have never had that in Internet mail and even the early bright ideas about automatic address correction (represented in the SMTP 251 and 551 "here is the user's real address" codes) have not worked well and might be considered privacy problems today. I'm aware of one mail system that did have automatic address correction: it was not a success and the system has faded away into obscurity. In order to support automatic address correction, we have added headers that may not get through poor-quality relay implementations of SMTP (especially including those associated with firewalls) and added considerable complexity to post-delivery protocols and models to try to restore the original form of the message. At one time or another in the past, we've had several systems that have tried to figure out how to deliver messages in spite of addresses that didn't quite match. They haven't worked well either except when used in connection with a global user/address directory and sending MUAs that communicated directly with that directory, features we certainly can't arrange for Internet mail. I'm also concerned about side-effects and abuse. The alternate address model associates two addresses with no guarantee that they are actually related. The risks associated with that may not be larger than those associated with ordinary insecure email, but, because the transformations are applied in-transit, may make it even easier to trick users in ways that we don't understand yet. It also presents opportunities for spammers, raises issues with digitally-signed messages (including some that are similar to the recent discussion of how multiple header "From:" field values interact with DKIM), etc. We can deal with most of those to at least some degree, but only with more complexity in other places. By contrast, if we abandon an in-transit downgrading protocol, EAI becomes an extremely simple implementation for the transport path. At least some eight-bit-clean implementations merely need to add support for an additional SMTP option and remove restrictions that require ASCII-only addresses. Messages that cannot be delivered as addressed get rejected (at SMTP time if possible), and rejection for an unsupported SMTP option or an undeliverable address are among the easiest to do at SMTP time. That rejection gives the sender the clear indication that the address path didn't work and that some other address or path needs to be found. Even if the messages bounce, there are good odds of things working properly and the sender being notified, especially in the very common case of a direct connection between the Submission and Delivery MTAs. Post-delivery processing, specifically IMAP and POP, still need to worry about UTF8-capable clients with ASCII-only mail stores and vice versa, but even their complexity level goes down. Post-delivery protocols also have an advantage over anything done in transit: the risk of information that they rearrange being deleted is much lower and normally under the same administrative control. I also note that we've got a general design principle that facilities introduced for transition should not cause major clutter after the transition is over. 8BITMIME is like that: with most of the infrastructure converted to handle it, we no longer spend a lot of time worrying about which systems support that form of downgrading and the downgraded forms are standard and needed for other purposes. Systems still have to assert the capability, but that is not a big deal. By contrast, if we introduce the rather unpleasant-looking Personal Name <mailbox@domain <mailbox@domain>> syntax, it will be with us forever, will cause problems when the addresses leak into systems that don't know how to parse it, will confuse users who have become used to the format that we've used for several decades, and so on. Adding another set of headers that can be interpreted accurately unless linked to other headers isn't doing email robustness any favors either -- perhaps worth it if the marginal value it produced was high enough, but I'm just not convinced of that any longer. So, as we carry out the experiment of seeing how "downgrade" works as an experimental protocol in a full Internet email environment, I think we should (i) Try to carefully evaluate whether it actually turns out to be useful in enough real, plausible, cases (not just tests) to be worth all of the complexity and trouble. (ii) Think about whether there are other approaches that would add less complexity to the email system and be more reliable in what I predict will be the common case of having some UTF8-format addresses to a message with alternate addresses and some that don't have those alternates, the mailing list cases, etc. One such approach might involve a protocol for directory services linked to a destination system, one that could give a sending MUA or Submission MTA alternate address information when messages containing the primary address were returned as undeliverable. That would require significant sending MUA and/or Submission MTA work, but that work could be done by those who were motivated without requiring complexity in the broader Internet mail environment. (iii) Think about whether we can appreciably decrease the complexity of a downgrade mechanism if we designed it for the envelope reverse path only, i.e., to be sure that we have a place to send error messages and other MTA-level notifications. The reverse path is the really troubling case that requires some sort of transition strategy because undeliverable notifications cause mail to disappear. But, if we can deal with that case at relatively low complexity, perhaps we should consider the tradeoffs between the complexity of the full downgrade mechanism and a strong recommendation that users include alternate addresses in signature lines for the cases in which "reply to originator" fails (some people do that already, for other reasons, so it isn't exactly an innovation. Again, I think Downgrade should be published as Experimental, both to demonstrate what is required if one is going to have such a facility and to see if it actually works better and more often than I anticipate. But, at this point, I consider it a very poor candidate for standardization and a risk if widely deployed. thanks, john --On Monday, December 22, 2008 16:18 -0800 The IESG <iesg-secretary@xxxxxxxx> wrote: > The IESG has received a request from the Email Address > Internationalization WG (eai) to consider the following > document: > > - 'Downgrading mechanism for Email Address > Internationalization ' <draft-ietf-eai-downgrade-10.txt> as > an Experimental RFC > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send > substantive comments to the ietf@xxxxxxxx mailing lists by > 2009-01-05. >... _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf