Subject: RE: [idn] Document Status?

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 08 Sep 2002 17:53:42 +0200

Dear Scott,
This problem concerns permitted names. From a decision not from a technical 
specification point of view. It would call for a mechanism to enforce such 
permissions as part of the name preparation [you could want to forbid 
registration of Chinese words in a French registry, the same as the all 
numeric domain names requests are parsed and denied by AFNIC].

Do you want to forbide natural names using American four letter words 
sequences in their international version. U+0CD3 U+0CD8 (what ever it may 
mean?) is an interesting string... and a case for UDRP. Will registries 
forbid registrations in international format? ie iesg--xxxxxx. On which 
grounds? The process is no part of the DNS and no prefix IANA management, 
recursion, etc.. is proposed.

jfc

(if anyone think my wording is not "correct", let him phrase that simple 
basic question accurately in the proposed document wording: I was unable to 
do it, sorry).

On 22:30 07/09/02, Hollenbeck, Scott said:

> > >The only text I recall which has some bearing on this is:
> > >   It is expected that some name-handling bodies, such as large
> > >   zone administrators and groups of affiliated zone administrators,
> > >...
> > >I don't see how registries limiting the set of Unicode code points
> > >that can be used in a part of the name space has any
> > negative impact on
> > >interoperability; registries limit the types of names for
> > various policy
> > >reasons already (such as only allowing registered companies in some
> >
> > I am hoping that I am misunderstanding what you have just
> > written, Erik.
> >
> > You are suggesting that the set of valid characters -- leaf
> > characters?  intermediate node characters? -- will depend
> > upon the portion
> > of the DNS tree that the name is under?  This is a
> > fundamental change to
> > the DNS.
> >
> > Since you disagree, please cite an existing example of such a
> > dependency,
> > on place in the tree, in the current DNS.
>
>Jumping in...
>
>There are some domain name registries that prohibit certain combinations of
>characters in the name spaces they administer.  The administrator of the .us
>ccTLD, for example, prohibits use of the seven "dirty words" described by
>the US FCC and George Carlin.  While this isn't a restriction on the set of
>valid characters, it _is_ a restriction on how they may be combined.  I read
>Erik's note to mean that registries may well prohibit certain Unicode code
>points or combinations of code points for various policy or legal reasons,
>and I'd agree with that assessment.
>
>Please correct me if my interpretation is wrong, Erik.
>
>-Scott-
>
>
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.385 / Virus Database: 217 - Release Date: 04/09/02

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 9 Sep 2002 00:49:03 +0000

"JFC (Jefsey) Morfin" <[email-masked]> wrote:

> This problem concerns permitted names.  From a decision not from a
> technical specification. it calls for a mechanism to enforce such
> permissions as part of the name preparation

The primary purpose of Nameprep is to allow names to be compared and
reproduced in a sane manner.  Nameprep prohibits a few characters, not
for policy reasons, but merely because they would make names very hard
to compare and reproduce.  Nameprep is technical, not policy.

If registries want to impose policies about which names they will
and will not register, that's fine, but please don't call it name
preparation.  Nameprep is something that every IDNA-conformant
application must be able to do.  The policies used by a particular
registry to restrict the names appearing in that registry do not need
to be known by every IDNA-conformant application, they only need to be
known by that registry and its registrants.

> Forbiding natural names using four letter words sequenecs in their
> international version is more complex. This will make U+0CD3 U+0CD8
> (what ever it may mean?) an interesting string... and a case for UDRP.

It took me a couple minutes to figure out what this was talking about.
For those still wondering:  The Punycode encoding of U+0CD3 U+0CD8 is
"fuck".  (In this particular case, those code points are unassigned, so
IESG--fuck is not in fact an ACE label at all.  But IESG--i-fuckyou is a
valid ACE label.)

If registries want to forbid certain words in both ACE forms and non-ACE
forms, they are welcome to do so.  Occasionally an innocent non-ACE
form will be forbidden because it's ACE form coincidentally contains a
forbidden word.

Whether an ACE form can infringe a trademark is something for the courts
to decide, not us.

> Will registries forbid registrations in international format? ie
> iesg--xxxxxx. (if anyone think my wording is not correct, let him
> phrase that simple basic question accurately in the proposed document
> wording: I was unable to do it, sorry).

I'm not sure what you're asking.  Let's take the IESG--world example.
That is an ACE label.  It is equivalent to U+53DF U+53E0 U+53D9.  A
registry could allow both, or forbid both, but it can't allow one and
forbid the other, because they are equivalent.  No matter which one you
register, you get both, and an IDNA-conformant application will display
them both the same way, as U+53DF U+53E0 U+53D9.

If you're worried about someone registering a label that an
IDNA-conformant application would display as "IESG--world", and you're
thinking that maybe registries ought to forbid such things, you can
stop worrying, because no such thing exists, so there's nothing for
registries to forbid.  IDNA-conformant applications display the output
of ToUnicode, and it's simply impossible for ToUnicode to output
"IESG--world".

AMC

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 09 Sep 2002 13:32:45 +0200

On 02:49 09/09/02, Adam M. Costello said:
>to compare and reproduce.

This is a decision of this WG for the reason you quote. The reason why a 
Registry would want to prohibit more characters ou string sequences would 
include (among others) the very same reason, in their own opinion.

>Nameprep is technical, not policy.

True. An this is why nameprep should technically support policy decisions 
under the form of parameters. When I say that ftp1.jefsey.com is a CNAME it 
is policy decision. To read and support CNAME is a technical feature 
documented by the DNS RFCs.

>application must be able to do.

Absolutely. And only an IDNA-conformant parameter description (or command 
language?) can provide a consistent support in the way to impose those 
policies. You do not add a something to the DNS to support "ALIAS", 
"MIRROR" etc.. you use the DNS CNAME feature.

jfc

---

From: John C Klensin <[email-masked]>
Date: Mon, 09 Sep 2002 09:04:07 -0400

--On Monday, 09 September, 2002 13:32 +0200 "JFC (Jefsey)
Morfin" <[email-masked]> wrote:

> True. An this is why nameprep should technically support
> policy decisions under the form of parameters. When I say that
> ftp1.jefsey.com is a CNAME it is policy decision. To read and
> support CNAME is a technical feature documented by the DNS
> RFCs.
> 
>> If registries want to impose policies about which names they
>> will and will not register, that's fine, but please don't
>> call it name preparation.  Nameprep is something that every
>> IDNA-conformant application must be able to do.
> 
> Absolutely. And only an IDNA-conformant parameter description
> (or command language?) can provide a consistent support in the
> way to impose those policies. You do not add a something to
> the DNS to support "ALIAS", "MIRROR" etc.. you use the DNS
> CNAME feature.

Jefsey, let's assume that we wanted to be able to express these
policy decisions as parameters to nameprep.  There are many
reasons to not do that, but let's ignore them for the moment.
Now we have another choice to make, which is how a client
figures out which policies are in effect.   As far as I know,
there are only two ways to do that:

(i) Something out of band, similar to ISO "profiles".  But
out-of-band profiles have turned out to be an interoperability
disaster: we both conform to a standard, but we can't
interoperate unless we both support the same (or compatible)
sets of features and I don't have any regular way to figure out
what feature set the server wants.   Sometimes these things can
be negotiated, but that pretty much requires a virtual circuit
connection arrangement, and the DNS protocols goes to great
lengths to avoid needing those on query-response setups.

(ii) Some way to query the (authoritative?) server to determine
the policy.  That implies that we need a language/data structure
for expressing policies, and a place to put the information on a
per-zone (not just per-TLD, as pointed out in my, and Ted
Hardie's, earlier notes).  That "place" has to have
accessibility, reliability, and performance properties at least
as good as the DNS (with its secondary and caching mechanisms).
Even then, we get ourselves into a "two transactions per label"
situation (one to fetch policy and one to do the query)
situation for IDNs. And, if the policy statement is a table of
acceptable or prohibited characters, we are going to have
problems with the dreaded UDP packet-size limit.

So I just don't see it, even if it were strategically a good
idea.

regards,
      john

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 9 Sep 2002 23:30:35 +0000

"JFC (Jefsey) Morfin" <[email-masked]> wrote:

> True.  And this is why nameprep should technically support policy
> decisions under the form of parameters.

I can see that Nameprep and policy restrictions *could* be integrated
into a single framework using parameters, but I don't see why they
*should* be.  We'd have to complicate the Stringprep/Nameprep model
to accomodate a wider variety of filtering techniques (and we'd
probably still fail to accomodate everything that the registries want
to do), and we'd have to distinguish between the standard parameters
that all clients must know and use to check syntactic validity,
versus the private parameters that registries use internally to check
admissibility.

While we need a standard for which labels are syntactically valid, I
see no need for any standardized algorithm for testing which labels
are admissible into a given registry.  Obviously syntactically invalid
labels are inadmissible for all registries, but each registry can use
any algorithm it likes to make additional labels inadmissible.  That
algorithm may or may not bear any relation to Stringprep/Nameprep, and I
don't see why the IETF should care.

Notice that the current DNS standards do not define any mechanisms for
checking labels for admissibility, and yet registries can (and do)
perform their own checks if they want.  I don't see why this model
should change with the introduction of IDNA.

AMC

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 10 Sep 2002 04:54:54 +0200

>should change with the introduction of IDNA.

My point was that you introduced filters into nameprep to inforce you own 
options.
So the proper logical place - since there is no other analysis - is to put 
every filter there.
But you are totally right, NICs can enter the algorithm they want.
And this filtering of the requests (not of the extsing names) occurs only 
at registration time.
jfc