[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[idn] Protocol design team presentation
- To: firstname.lastname@example.org
- Subject: [idn] Protocol design team presentation
- From: Paul Hoffman / IMC <email@example.com>
- Date: Mon, 11 Dec 2000 13:39:02 -0800
- Delivery-date: Mon, 11 Dec 2000 13:42:12 -0800
- Envelope-to: firstname.lastname@example.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
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)
- 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.
- 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
- 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.
- The two-phase solutions require that the applications be updated to
handle an ACE encoding in case the query using the long-term solution
- 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.
- 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,
- 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
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
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
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
- 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...