To the IDN list: Marc Blanchet asked me to post this. It is the raw text dump of the PowerPoint presentation that will given in a few hours. This is *not* the report from the design team, it is just the slides that are being presented. This is primarily for those of you following the WG on the MBONE today and for the folks in San Diego that want to read the slides between the Monday and Wednesday meeting. The design team plans to put out a final report soon. IDN Protocol Design Team First Report David Lawrence Nominum Protocol design team overview - Primary task: categorize protocol proposals and make recommendation to WG - Members: David Lawrence, "lafur Gu�mundsson, Dan Oscarsson, Paul Hoffman - Observers/commentators: Marc Blanchet, Harald Alvestrand, John Klensin, Rob Austein, Output of the design team - Report to the mailing list (didn't make it before this meeting, will have it soon afterwards) - Comparison of protocols (David Lawrence) - Possibly other reports or recommendations Categories of protocols, based on expected implementation - Do a long-term, architecturally clean fix that requires upgrades to the whole naming infrastructure - Change only the applications in the short term, and possibly the application protocols, but change none of the DNS infrastructure - Change the applications for short-term gain, but transition in the long term to a cleaner solution that requires upgrades to the whole naming infrastructure (two-phase approach) Big picture - We cannot simply put binary characters into the current DNS without breaking many applications and some DNS servers. - None of the solutions at this point is a comprehensive solution that considers all the effects of the changes proposed. - The design team has not looked at all impacts on applications, deployment, and users for all proposals. Where the solutions fit - Long-term solutions mostly involve changes to the current DNS infrastructure, although there is also a proposal for using a directory layer with internationalized input to find resources. - Short-term solutions are based on using ASCII-compatible encodings (ACEs) in applications. - Two-phase solutions are a mixture of the two. Infrastructure solutions - The long-term proposals require that all DNS servers in a request path be updated before the user can get a correct answer to a query for an internationalized host name. - Different proposals, and different legacy DNS servers, will cause different error messages to get back to the user if their query traverses a server that was not upgraded. - A user can get different results for the same query if the user's initial caching name server changes, such as if the user is roaming. - Maximum breakage of applications. ACE solutions, positive - They are easier to implement than the long-term solutions, but they are not without problems. - The obvious advantage is that updating just applications will go faster than updating applications and the entire naming infrastructure. - They work on the presentation layer, which means that they don't even require changes to any applications protocols. ACE solutions, negative (1) - ASCII-style ugly name leakage in non-updated applications - Non-IDN names that use the ACE prefix or suffix will either be considered illegal or will appear as nonsense characters. - The ACE solutions only internationalize host names, not textual material that appears in some types of DNS records. ACE solutions, negative(2) - The IDN WG must choose an ACE. - Versioning is harder in ACEs than in other proposals. - There are probably other ACE-specific implications that we haven't thought about yet. Two-phase solutions - The two-phase solutions require that the applications be updated to handle an ACE encoding in case the query using the long-term solution fails. - Thus, every application must work correctly with the short-term solution, and the long-term part of the solution has all of the problems listed earlier. - It is likely that only the short-term solution would be implemented unless the long-term solution had other notable advantages. ACE considerations - The ACE must be designed to have one-to-one mapping and versioning. - A disadvantage of ACEs is that they must continue to use 63-octet maximum for name parts, while other proposals could extend the length of the name parts. Changes to applications - All scenarios will require that all applications that use the new names be updated. RFC 2825 lists many protocols for which internationalization may be very difficult. Applications will need to change the way that they display names to, and input names from, users. - With the infrastructure solutions, the applications will need to call different resolver software, and new resolver software will be needed on systems hosting those applications. Go with DNS infrastructure? - If the IDN WG decides to go with any of the DNS-specific infrastructure solutions, the design team thinks that the decision about which of those solutions is chosen should be made by people in the DNS community and the Applications Area with the internationalization community. Go with directory infrastructure? - If the IDN WG decides to go with a directory-based solution, the WG clearly needs to work closely with the directory community to choose both a directory protocol and a schema for interoperability. - There is no successful operational experience in an Internet-wide directory service. Suggestion: go with application-only solution - Focusing on the negative attributes of each solution, the design team considers the short-term "use ACE from the application" to have the least serious problems and the quickest to achieve a reasonable amount of implementation. The design team is not thrilled with the solution, particularly due to its inelegance, and understands that doing anything other than simply using internationalized domain names in the current DNS is a kludge. Looking at costs - We note that the more architecturally desirable infrastructure solutions are very costly in terms of new protocol work needed and upgrading deployed name server. - Predicting when any of the solutions might actually be useful is impossible, making them very difficult to sell to the Internet community. An ACE solution does not prevent an infrastructure solution - Fortunately, choosing the ACE solution now does not preclude the IETF from later choosing an infrastructure solution, and it does give Internet users the internationalized host names that they desire fairly quickly. What's next - Design team finishes its report and sends it to the WG. - Design team finishes the comparison document. - Somebody will study the impacts of the chosen solution more in-depth. - WG decides...
