[idn] The report from the design team

[Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>]

Hi,
	this is the report of the protocol design team, that was presented at the 
last ietf.

Regards, Marc.

==========================
IETF IDN Protocol Design Team Report
January 12th 2001

Members of the IDN protocol design team looked at the wide variety of 
protocol proposals that have been make to the group. Of them many proposed, 
we found that the solutions envisioned by the documents would cause 
different scenarios for how internationalized domain names would get 
implemented in the Internet. However, we cannot simply put binary 
characters into the current DNS without breaking many protocols and many 
DNS servers. The design team has not looked at all impacts on applications, 
deployment, and users for all proposals.

Three scenarios appear likely:

- Do a long-term, architecturally clean fix that requires upgrades to the 
whole DNS infrastructure
- Change only the applications in the short term, 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 DNS 
infrastructure (two-phase approach)

The long-term solutions proposed so far 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. The 
proposed short-term solutions are based on using ACE in applications. The 
two-phase solutions are a mixture of the two. The design team will later 
produce an analysis comparing the solutions, while this report to the WG 
gives our current view of how the working group might proceed. None of the 
solutions at this point is a comprehensive solution that considers all the 
effects off the changes proposed.

Looking at the past decade of DNS deployment, it is very clear that getting 
the entire DNS infrastructure upgraded will take many years (where "many" 
could be more than ten). The DNS infrastructure 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. Another problem of such a shift is that a user will get different 
results for the same query if the user's initial caching name server 
changes, such as if the user is roaming.

The two-phase solutions require that the applications be updated to handle 
an ACE encoding in case the query using the DNS infrastructure solution 
fails. This means that every application must work correctly with the 
application-only solution, and the infrastructure part of the solution has 
all of the problems listed above. In such a scenario, it is likely that 
only the application-only solution would be implemented unless the 
infrastructure solution had huge advantages not associated with 
internationalizing host names.

The application-only solutions proposed are clearly easier to implement 
than the infrastructure 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. Further, the 
application-only solutions work on the presentation layer, which means that 
they don't even require changes to any applications protocols. The negative 
aspects of the ACE-based solutions include:
- 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.
- The IDN WG must choose an ACE.
- Versioning is harder in ACEs than in other proposals.
- They must continue to use 63-octet maximum for name parts, while other 
proposals could extend the length of the name parts.
- There are probably other ACE-specific implications that we haven't
thought about yet.

Any scenario of going from current names to IDN names will require that all 
applications that use the new names be updated. RFC 2825 lists many 
protocols for which internationalization may be very difficult. In all the 
solutions, applications will need to change the way that they display names 
to, and input names from, users. With the marked two-phase and 
infrastructure solutions, the applications will need to call different 
resolver libraries, and new resolver libraries will be needed on systems 
hosting those applications.

If the IDN WG decides to go with any of the two-phase or the DNS 
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, not in the internationalization community. The DNS-based 
solutions proposed so far have very different effects on the current DNS, 
and the people who work with the DNS are better able to assess the positive 
and negative merits of the changes to the DNS. Regardless of the solution 
chosen by the IDN WG, the DNS community should certainly consider 
internationalizing the DNS resource records that contain free text.

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. 
Years of experience with DNS names has shown that they are used for two 
very different things: in some places they are protocol elements, in others 
they are human readable names better suited to a separate directory service 
than to being co-mingled and confused with protocol elements. The people in 
the directory communities have much more experience than those in the IDN 
WG with designing directories to be helpful to end users who are searching 
for particular information.

Focusing on the negative attributes of each solution, the design team 
considers the "use ACE from the application" solution 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 somewhat of a kludge. We also note that the more architecturally 
desirable infrastructure solutions are extremely costly in terms of new 
protocol work needed and upgraded name servers deployed, and predicting 
when any of the solutions might actually be useful is impossible, making 
them very difficult sell to the Internet community. Fortunately, choosing 
the application-only solution now does not preclude the IETF from later 
choosing any of the infrastructure solutions, and it does give Internet 
users the internationalized host names that they desire fairly quickly.

Because the proposed IDN solution is for the presentation-layer of 
applications, the protocol design team proposes that the IDN WG allow the 
Applications Area to finish the work on the specific protocol proposal. The 
people in the Applications Area are most familiar with the problems 
associated with changing the presentation layer.

The IDN Working Group still has work to do, of course. The nameprep work 
needs to be finished, based on at least one more round of proposals from 
the nameprep design team. Also, the IDN Working Group needs to choose an 
ACE. The protocol design team proposes that a new design team be formed to 
help the Working Group choose an ACE. After that process, any ACE-related 
issues can be addressed in the main ACE document or a companion document.

The protocol design team proposes that the IDN Working Group shuts down 
after the completion of the above work. Many people have expressed interest 
in pursuing a directory-based infrastructure solution that would also 
encompass giving internationalized access to host names, but that work 
involves much more than just internationalization. It should be done in a 
new working group that includes directory people, internationalization 
people, and applications people, and should be chartered after it is clear 
what the parameters of the proposals entail.


The team was:

Dan.Oscarsson@trab.se
ogud@tislabs.com
phoffman@imc.org
tale@nominum.com
sra@hactrn.net

with observers/advisors:
Marc.Blanchet@viagenie.qc.ca
james@seng.cc
klensin@jck.com
alvestrand@cisco.com


Marc Blanchet
Viagénie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca

----------------------------------------------------------
Normos (http://www.normos.org): Internet standards portal:
IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.