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

From: Yves Arrouye <[email-masked]>
Date: Tue, 30 Oct 2001 21:39:35 -0800

> 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

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 31 Oct 2001 06:58:16 +0100

> I think you meant the opposite (i.e. reject if not new version, map

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

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

> 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