LEA Bottom LIne (was Re: IEA Bottom Line)
John; Third, while it would certainly make global interoperability easier, there is no way to prevent people from deciding to use local characters, and maybe even local codings, in local environments. They will do it. That something is technically possible does not mean it useful. In this case of localized (not internationalization at all) email addresses, it is not useful and will not be used widely to be ignored safely. They will believe (probably correctly) that they have good reasons for doing it. Our choices are between * Finding a rational, plausible, global way to let them do it while still preserving global interoperability or Mails with localized addresses do not interoperate globally just beause they use localized addresses that that is a meaningless goal. Fourth, there was, and is, a case to be made that internationalization of domain names is unnecessary and dumb Right. Localized domain names are not useful and not used at all, at least in Japan. Maybe, there are some names registered, as protection purposes, but none are used. Even if there is a few countries where such domain names are used, it proves that the issue is purely local with no international issues and no global interoperability is necessary. You can argue that localized domain names was useful for registries and registareres, as names registered for protection purposes increased their revenues, though I guess, in Japan, that outcome of advertisement fee on various media exceeded income of registration. But, even such argument is not applicable to email names. Masataka Ohta
Re: IEA Bottom Line
--On Monday, 03 November, 2003 14:46 -0500 Jeffrey Altman <[EMAIL PROTECTED]> wrote: John C Klensin wrote: Jeffrey, I think this is an important point. The question is what to do about it. One extreme view is that we should, because of those issues, say "usernames must be confined to simple, IA5, strings because that is the only way to get guaranteed interoperability with all of these things with a single string". I don't think that is going to fly in the areas in which people are really determined to internationalize usernames and email addresses. Nor do I think that those folks are going to accept an encoding that causes user names to look as expected in some contexts and a hard-to-verify form in others -- users won't see it as the same, or common, representation of their names. So, at worst, we should be sure that people understand the tradeoffs, regardless of what i18n system is adopted: localization versus global interoperability, localization versus a single identifier as username, mailbox address, and Kerberos/ SASL/ X.509 certification or credential name. I'll try to work some words to that effect into -02 of my email document so it doesn't get lost. Much more than that we probably can't do, any more than saying "I18n Bad" or "I18n risky" or "I18n less interoperable" is going to prevent anyone who thinks they are needed from deploying _something_ for very long. regards, john John: My primary concern with the i18n issues are those of wire representation leakage at the user interface layer. The IDNA solution has resulted in some nasty implications for the security community because it mandates the leakage of ACE representations of IDNs to the end user when the local system architecture cannot support the appropriate i18n display and input mechanisms. This decision is wonderful for short term interoperability because it allows the existing end-user application infrastructure to be used during the migration process. Yes. I hope that, by the time the IDNA work drew to its end, everyone involved and supporting it understood that implication... even if I was not successful in getting it explicitly into the relevant documents. The problem it causes for the security community is that the primary goal of the authentication process is to mutually authenticate two entities to one another. This usually usually means verifying a name in some fashion. This can either be done by using the name as input to some cryptographic operation (SRP,Kerberos,...) or by associating the name with an information bundle protected by a cryptographic operation (X.509). In either case, we have complicated the situation immensely by moving from a model in which each entity has one unique name to a model in which each entity may have multiple names. Future revisions to the affected protocols can deal with the change in the model, but what of the existing deployments which cannot? I would much rather see an incompatible protocol or architecture which requires a short amount of severe pain than one that compromises the architecture for the lifetime of its future deployment. This is, I think, a fairly persuasive argument for the "no internationalization of email addresses until your infrastructure is upgraded" approach in my draft. It also argues, I think, that the option of having the domain name in a mailbox string in either UTF-8 or punycode should be eliminated, requiring UTF-8 only and that any of the localization variations that start from "@" is an ASCII character too" should be avoided, however regretfully. Of course, as I have been trying to point out, this remains all about tradeoffs -- not only between options, but about where the pain is felt. My hope is that we can analyze those carefully and make good and explicit decisions about them, avoiding any temptations to reach for the snake oil or pixie dust. Future versions of SASL and Kerberos are going to standardize on the use of a normalized form of Unicode represented in UTF-8 as the wire format for strings. X.509 already can support Unicode. If it were possible to insist that only Unicode aware applications could use i18n names then we would see a much more rapid transition to newer protocol implementations across the board. From my perspective, applications should be free to provide their own mechanisms for displaying i18n names when the operation system or windowing system does not support them. However, the wire representations should not be leaked through. The applications should always be requires to convert to Unicode before passing the strings the various protocol libraries. This would allow us to develop the network infrastructure independent of the user interface infrastructure. It is unfortunate that this separation cannot be maintained. Ack. See above. john
Re: IEA Bottom Line
John C Klensin wrote: Jeffrey, I think this is an important point. The question is what to do about it. One extreme view is that we should, because of those issues, say "usernames must be confined to simple, IA5, strings because that is the only way to get guaranteed interoperability with all of these things with a single string". I don't think that is going to fly in the areas in which people are really determined to internationalize usernames and email addresses. Nor do I think that those folks are going to accept an encoding that causes user names to look as expected in some contexts and a hard-to-verify form in others -- users won't see it as the same, or common, representation of their names. So, at worst, we should be sure that people understand the tradeoffs, regardless of what i18n system is adopted: localization versus global interoperability, localization versus a single identifier as username, mailbox address, and Kerberos/ SASL/ X.509 certification or credential name. I'll try to work some words to that effect into -02 of my email document so it doesn't get lost. Much more than that we probably can't do, any more than saying "I18n Bad" or "I18n risky" or "I18n less interoperable" is going to prevent anyone who thinks they are needed from deploying _something_ for very long. regards, john John: My primary concern with the i18n issues are those of wire representation leakage at the user interface layer. The IDNA solution has resulted in some nasty implications for the security community because it mandates the leakage of ACE representations of IDNs to the end user when the local system architecture cannot support the appropriate i18n display and input mechanisms. This decision is wonderful for short term interoperability because it allows the existing end-user application infrastructure to be used during the migration process. The problem it causes for the security community is that the primary goal of the authentication process is to mutually authenticate two entities to one another. This usually usually means verifying a name in some fashion. This can either be done by using the name as input to some cryptographic operation (SRP,Kerberos,...) or by associating the name with an information bundle protected by a cryptographic operation (X.509). In either case, we have complicated the situation immensely by moving from a model in which each entity has one unique name to a model in which each entity may have multiple names. Future revisions to the affected protocols can deal with the change in the model, but what of the existing deployments which cannot? I would much rather see an incompatible protocol or architecture which requires a short amount of severe pain than one that compromises the architecture for the lifetime of its future deployment. Future versions of SASL and Kerberos are going to standardize on the use of a normalized form of Unicode represented in UTF-8 as the wire format for strings. X.509 already can support Unicode. If it were possible to insist that only Unicode aware applications could use i18n names then we would see a much more rapid transition to newer protocol implementations across the board. From my perspective, applications should be free to provide their own mechanisms for displaying i18n names when the operation system or windowing system does not support them. However, the wire representations should not be leaked through. The applications should always be requires to convert to Unicode before passing the strings the various protocol libraries. This would allow us to develop the network infrastructure independent of the user interface infrastructure. It is unfortunate that this separation cannot be maintained. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: IEA Bottom Line
--On Monday, 03 November, 2003 13:24 -0500 Jeffrey Altman <[EMAIL PROTECTED]> wrote: John: Thank you for your continued rationality. I do not have a strong opinion on what the solution to this problem should look like. However, I am concerned about some related problems. Local mail parts are often derived from or are usernames. Administrators like the ability to be able to assign a single name to an end user for the purpose of user identity. It is my hope that whatever conclusion is reached will ensure that the i18n mechanism will allow this single single name to be compatible with existing naming conventions utilized with Kerberos, SASL, X.509, etc. It would I believe detrimental to everyone if the various protocols which must manipulate user identities did not have a common way of representing them. Jeffrey, I think this is an important point. The question is what to do about it. One extreme view is that we should, because of those issues, say "usernames must be confined to simple, IA5, strings because that is the only way to get guaranteed interoperability with all of these things with a single string". I don't think that is going to fly in the areas in which people are really determined to internationalize usernames and email addresses. Nor do I think that those folks are going to accept an encoding that causes user names to look as expected in some contexts and a hard-to-verify form in others -- users won't see it as the same, or common, representation of their names. So, at worst, we should be sure that people understand the tradeoffs, regardless of what i18n system is adopted: localization versus global interoperability, localization versus a single identifier as username, mailbox address, and Kerberos/ SASL/ X.509 certification or credential name. I'll try to work some words to that effect into -02 of my email document so it doesn't get lost. Much more than that we probably can't do, any more than saying "I18n Bad" or "I18n risky" or "I18n less interoperable" is going to prevent anyone who thinks they are needed from deploying _something_ for very long. regards, john
IEA Bottom Line (was: Re: FYI: BOF on Internationalized Email Addresses (IEA))
Folks, I've just spent several hours reading my way through much of through the long and fascinating thread caused by the BOF announcement. I should probably just remain silent, but the traffic causes me to have a few thoughts. Some of them have been mentioned on the list in one form or another, but let me try to draw them together in the hope of separating them from the noise. As a preface, sound bites are a lot of fun, especially among politicians and demagogues. To the extent that our goal is good design and engineering, we need to do serious analysis and try to read and understand serious analysis. I am appalled at the number of postings on this list that seem to indicate people willing to state positions, very strongly, without having read any of the relevant drafts. Whatever is going on in the problem-statement list and WG, that may be a much more severe threat to the IETF's ability to do good work than anything [else] they have gotten fixated on. First, I am strongly committed to interoperability. Without it, much of what makes the network attractive to many of us disappears. We don't then end up at the "500 one-way channels of pointless entertainment" that many of us fear, but every significant step taken away from global interoperability --not just of the bits, but of user-level applications-- costs us some of the properties and potential for an Internet that enables human communications. While me may disagree on many things, including the best way to preserve interoperability, I am convinced that Paul, Adam, and Martin are also committed to that goal. I hope the rest of you are too --I've singled them out only because their names are on documents that represent approaches to the email internationalization problem -- if you aren't, these discussions are pretty pointless. Second, it is clear to me that there is a tradeoff between completely convenient localization and global interoperability. In a completely local environment, I can not only use local characters and character codings, but I don't even need to label them. Identifying the codings in use, or even protocol variants in use, doesn't require international standards -- they are needed only if one wishes to get some (or considerable) localization while preserving some (or, I hope, considerable) global interoperability. Third, while it would certainly make global interoperability easier, there is no way to prevent people from deciding to use local characters, and maybe even local codings, in local environments. They will do it. They will believe (probably correctly) that they have good reasons for doing it. Our choices are between * Finding a rational, plausible, global way to let them do it while still preserving global interoperability or * Not doing that and ending up with a potentially large number of local solutions that won't interoperate or, at best, will require using different protocols for local/ national/ in-language email and for global communication. There is some superficial appeal to the second choice, i.e., to saying "the world will communicate using Roman characters; anyone who wants to do something else will need to use local systems among people who share the relevant language and character sets". But it won't work, as anyone who has been through the age of information-losing gateways among Internet mail/ PROFS/ cc:mail/ MSMail/ X.400/ etc., etc., can attest. Bad idea. Doesn't work well and often works very badly. Assume it is going to be an internationalization standard or a significant drop in interoperability. No other choices. Fourth, there was, and is, a case to be made that internationalization of domain names is unnecessary and dumb because, in that view, domain names are protocol elements that need absolutely maximum interoperability and can be hidden from users. Those who advocated that position lost the argument -- probably as soon as the first user saw the first web URL. But there is no such case to be made for email addresses except, possibly, among those who entertain the fantasy that "The Directory" will take over the Internet. Well, it may be really sad, but that plan has been over for years and years. Hasn't happened and, absent some miracle, isn't going to happen. The argument for why one can't get away without internationalization (or at least localization) of email addresses is in my draft. If you care and haven't done so, go read it. If you are not willing to read that, you probably aren't reading this either. Finally, the difference between the proposal from Paul and Adam and mine hinges on some very fundamental principles about architecture and deployability. One way to oversimplify the difference is that mine is better optimized for fully-internationalized local environments in the short term, and a fully-internationalized world in the
Re: IEA Bottom Line
John: Thank you for your continued rationality. I do not have a strong opinion on what the solution to this problem should look like. However, I am concerned about some related problems. Local mail parts are often derived from or are usernames. Administrators like the ability to be able to assign a single name to an end user for the purpose of user identity. It is my hope that whatever conclusion is reached will ensure that the i18n mechanism will allow this single single name to be compatible with existing naming conventions utilized with Kerberos, SASL, X.509, etc. It would I believe detrimental to everyone if the various protocols which must manipulate user identities did not have a common way of representing them. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
