Subject: Re: [idn] Document Status?

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Mon, 09 Sep 2002 16:02:20 +0200

On 15:04 09/09/02, John C Klensin said:
>--On Monday, 09 September, 2002 13:32 +0200 "JFC (Jefsey)
>Morfin" <[email-masked]> wrote:
> >> 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.
> >
> >> 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:

hmmmm. You assume here a suppor for every possible DN, including the non
registered yet ones. I am a layer above in management; the reason why I
need clear crosslayer wording and analysis.

The only place where the name preparation is of interest for policy
enforcement is when registering the DN: ie accepting a convenient natural
mnemonic (according my polcy rules) for a international string.

So there is no need for any interactive system relations as you describe. I
took the CNAME as a DNS related example to show that a similar neigbhor
situation exist. Sorry if it confused.

But we could only take "ln -s /usr/home /home".
This policy decision (to convert "/usr/home") has been taken and applied
only once. It may be used for years transparently. The function is
technical. The implementation is simple: "ln -s /usr/blabla /blabla" will
not work because the "parameter" "mkdir /usr/blabla" has not been entered
(but it could have been).

This shows that the profile can be easily set-up by TLD, SLD, etc...

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

There is not such a thing as a dynamic enforcement of the policy. The
policy applies at registration. So the DN exists or not. There is no
interference with the DNS. AFNIC says today they do not accept all numeric
DNs. They do not refuse numerics in a name, only all-numeric. This is one
line in the registration name preparation routine "if (atol(name)>0L)
error("all numeric name");

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

I wait for the nameprep document to release the code and I will build my
own registration system quick for my 3LD users registrations and implement
it in my test browser. I can tell you this not a good or bat idea. This is
only a need.

Obviously, I will not use prefixes as an non necessary too large source of
too many problems and limitations (except as hidden SLDs).
jfc

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 09 Sep 2002 16:34:10 +0200

On 01:40 09/09/02, Ted Hardie said:
>For those who are helping registries understand the impact of all of this,
>it may be useful to repeat this mantra at frequent intervals, so that they
>understand that their restrictions, desires, and preferred
>mappings simply do not exist at the protocol level.  Any attempts to
>restrict, to establish mappings or otherwise satisfy their desires should
>not rely on protocol action

which protocol? there are only "text processing" functions.
you mean that these functions are universal. True.
you also mean that here the application of these functions is universal.
True, but IMHO this is WG mission creep. This comes from the use of a
prefix which is only a suggestion.

RFC 920: every host will be in the domain ".arpa".
IDNA: every IDNA will be of the "he iesg--xxxx" format.

This creates a left to right hierarchy in the domain name space,
conflicting with the right to left one. This new hiearchy is related to a
first function. So this is a functional hirearchy. Who will manage it, how,
will it be recursive when new functions will be added? And most important
point "which one has the lead"?

I cannot see any of these problems in my parallel domain scripting scheme,
which only consists in hiding upper level labels including "--"?
jfc