Re: [idn] Document Status?

[John C Klensin <klensin@jck.com>]

--On Monday, 09 September, 2002 13:32 +0200 "JFC (Jefsey)
Morfin" <jefsey@jefsey.com> 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:

(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