[idn] Protocol design team presentation

[Paul Hoffman / IMC <phoffman@imc.org>]

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...