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

[Patrik Fältström <paf@cisco.com>]

--On 01-10-30 21.39 -0800 Yves Arrouye <yves@realnames.com> wrote:

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

Oh, sorry. Absolutely. You are 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)?

You are talking about the registration process? To be honest....I don't
care. I think this is up to the policy a registry has.

My personal take (note, personal) is that the following steps have to be
taken before a newly assigned codepoint is registered in any zone:

- A new version of stringprep is registered with the new codepoint and
  also mapping
- The registry make a decision to use this new version of nameprep,
  and change communication methods with registrars so it is possible
  to in some way pass the domain name to the registry
- The registrars accept domain names from registrants which use the new
  codepoint

My point is that I see it being an "opt-in" system for every registry (as
in zone administrator) to make a decision on what version (if any) of
stringprep is accepted, and given such a decision, the ability to enter new
strings goes down the chain towards the registrant.

> 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 ;)

As I said above, it is out of scope (1) forcing a registry adopting a
specific registry and (2) forcing a registrar to be able to accept domain
names via specific communication channels. Yes, many registrars use "the
web", but far from all. In some cases, paper is used which give much
different problems. What about "voice over the phone"?

The way I see it, this is how registrars can compete with each other. And I
say this in a positive manner.

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

Ok. I understand where the text is unclear. What I am talking about is a
query, yes. The idea is that the application which is generating/sending
the query is doing the stringprep, has the old version, and reject the
codepoint. So the codepoint is not even sent to the server (which _DO_
understand the new codepoint).

Of course, _any_ application which see a domain name and understand
nameprep can do nameprep, and (a) pass on unassigned codepoints and (b)
pass/map/reject codepoints it understand.

The important thing is that nothing unassigned end up in the zonefile.
Reason for this is that if someone register a domainname with U+20000
before that codepoint is added to Unicode, users will end up in trouble at
the point in time when the codepoint is added, and mapped to something
different.

So, the policy the registry has is the most important.

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

Yes, I think he understand.

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

I don't know either.

Let's see when we have some new text on the table. We agree it should be
changed so it is more clear.

   paf