Re: My prod at IDN requirements

[Harald Tveit Alvestrand <Harald@Alvestrand.no>]

At 17:22 04.01.00 +0900, Martin J. Duerst wrote:

> > How could we express this requirement?
> > Yes, I'm worried that someone will register <ASCII C> <Greek Omicron>
> > <ASCII M>.
>
>Who would want to register this? If put anywhere in print,
>what would be the chance that somebody types it in correctly?

Anyone who is interested in creating confusion could be interested in this.
Seems my mind has been tainted by association with the cyberpirates.......:-(


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


> > I was thinking of the server's deciding whether 2 names match or not in
> > this case. And that (by the requirement for consistency) should not be
> > locale dependent.
>
>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. 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?

                         Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
Harald.Alvestrand@edb.maxware.no