RE: [idn] Re: stringprep and unassigned code points

[Yves Arrouye <yves@realnames.com>]

> The _intention_ of the versioning (I am not saying that is what the
> wording
> is) is that the application which first encounters U+20000 must do one of
> these two things:
> 
>  If it has support of the new version of stringprep
>  - Reject the character because it belive it is unassigned
> 
>  If it doesn't have support for new version of stringprep
>  - Map U+20000 -> U+20021

I think you meant the opposite (i.e. reject if not new version, map
otherwise). Right?

> This implies that a user which happen to have support for a new version of
> stringprep can register a domainname which include U+20000 (even though
> U+20021 ends up in the DNS zonefile). This user presents the new
> domainname
> to another user which have an old application.

Is the user required to have the stringprep support, or the registrar's
registration software (or even some other guy's software down the chain)? I
would think the latter. I don't think we want to ask the HTML people for a
new kind of input attribute to specify that the input should be
Stringprepped/Nameprepped just to support the business of name registration
;)

> Now, what happens?
> 
> The goal is (once again, this might not be what the text says) that the
> application which the second user uses, which belive U+20000 is unassigned
> should reject the domainname which this user entered.

No. I don't think so. Remember this section 6 of stringprep, that says that
for queries (which is what I believe you are talking about now) applications
should treat U code points the same as AO? Well U+20000 being U, it will be
passed on, since this second application is making queries.

Anyway, I think Paul understands what I wanted to make sure people would be
aware of. I'm happy with that and ready to dispose of this particular
thread...

> It is basically the same thing as someone else commented, that we in the
> document have to be much more clear about what it means by "the first
> application which encounters the domainname".

That is definitely true! It may also be a can of worms: think multi-tiered
registration systems. Maybe an avenue is to look at the first application
which *needs* to process the string according to a profile in order to be
able to manipulate it. Don't know if that's easier to define...

YA