On 15:04 09/09/02, John C Klensin said:
--On Monday, 09 September, 2002 13:32 +0200 "JFC (Jefsey)
Morfin" <jefsey(_at_)jefsey(_dot_)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:
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