[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Getting back to first principles for requirements



Greetings. I've been following this thread and I must say that it
worries me a bit. It seems like we are thinking of requirements
that are more appropriate for a new protocol than for a change to
a core protocol. That's a Bad Thing, given that we are talking
about the DNS on which everything relies.

I'm also concerned that we are already talking about limitations
that are probably not needed. This is sure to come back and bite
us on the butts after we deploy and people start to think bigger
about what they want for host names.

Let me try to recast the discussion towards the bigger reality.
I've split my view of the requirements into three sections.


Backwards compatibilty

The DNS is essential to the entire Internet, not just to a few
applications. Do the minimum amount of damage to existing protocols on
all layers of the stack. There can be no "flag days" nor a split DNS.

Continue to allow any system anywhere to resolve any domain name.

Continue to retain the property of a single unambiguous representation
for each host name (www.fübár.com must resolve the same for every
user).

Adding internationalization should add no new centralized
administration for the DNS. A domain administrator should be able to
create internationalized names as easily as adding US-ASCII names.


Greatest internationalization

Remember that current host names cover company and organization names,
acronyms, personal names, common phrases, event names, short-lived
catchy titles, and so on. We don't know what people will want to use
the names for in the future, and we have guessed wrong about domain
names many times in the past.

Using an internationalized name should not be any harder than using a
US-ASCII name.

Make as few restrictions as possible on the type of characters that can
be used.

Make no assumptions about where in a host name that
internationalization might appear. In other words, don't differentiate
between any part of a host name. Such restrictions now will likely
block important internationalization efforts in the future.

Do not make cultural restrictions in the protocol. For example,
assuming that a host name would only use a single script would
immediately restrict multinational organizations.


Input and display

Remember that today's domain names are not always typed in on an ASCII
keyboard; they are often hand-written on keyboard-less devices and
spoken aloud. Do not put any more restrictions on how internationalized
characters are entered by a user than are put on US-ASCII characters.

Make it as easy as possible for display devices to show
internationalized domain names. Users often copy things they see on the
screen onto paper, and then re-enter that information later. The
display of internationalized domain names should try to ensure that
this process will result in the correct domain name being entered.



--Paul Hoffman, Director
--Internet Mail Consortium