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 longer term (where "fully-internationalized" contemplates an environment in which English is just another language). The Paul/Adam proposal is much better optimized for environments in which a user who wants or needs non-ASCII characters is isolated in a mostly-ASCII environment. And it involves tampering with far few pieces that, in my few, we cannot pretend to ignore.
Is it possible to focus on those differences, and on the question of what the best way is to accomplish internationalization _given_ that it is an issue we need to deal with, rather than spending energy debating whether the users involved really should want it?
thanks john
