Re: My prod at IDN requirements

["Martin J. Duerst" <duerst@w3.org>]

At 10:27 00/01/04 +0100, Harald Tveit Alvestrand wrote:
> At 17:22 04.01.00 +0900, Martin J. Duerst wrote:

> >Do we have to nail down all the rules for what can be a name
> >and what not explicitly, or can we deal with some problems
> >in a more roundabout fashion if we can convince ourselves
> >(and document) that there should be no actual use cases?
> 
> "Leave it to ICANN to police" is a perfectly valid decision.
> We just need to make sure it's an explicit decision.

There are some things that can be left to ICANN easily.
But for one, similar problems may show up on the lower levels
of the hierarchy. Assume a big company that gets a request
from some local subsidiary in some country, and just adds
that blindly, because it has some 'strange' characters in
it and therefore cannot be checked by English-speaking staff.
It may turn out that this person is bad, and smuggles some
bad stuff into the company's DNS. While this cannot be
completely avoided, if we find some simple rules that
can eleminate a lot of the cases for a lot of administrators,
it's probably worth trying.


> >Which then means that if we want case folding for the user, case
> >folding has to be done on the client side. But for the moment, it
> >mainly means that for each such requirement, we have to make clear
> >where it applies (user or server). And probably, most such requirements
> >should at the moment be seen from the user side.
> 
> We're making requirements for something that will eventually create 
> protocol on the wire.

Yes, but that's not the only part of the system.


> We can see this as requirements for the service as 
> seen by the user (in which case it is not relevant *in the requirements* to 
> make the distinction between server side and client side implementation), 
> or we can see this as requirements for the protocol (in which case the 
> distinction does not matter, because the server side behaviour is *all* 
> that is visible on the wire - client side is beyond our control).
> 
> How do we want to progress?

I propose that we collect requirements as we come up with them,
and label them as relating to server, protocol, zone files,
user, client software, registry,... Sorting things out and
labeling them at this stage is important; trying to figure
out how these various requirements can be met by defining
what each of the components does is a later step.


Regards,   Martin.


#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:duerst@w3.org   http://www.w3.org