[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No Subject
<ietf-idna@mail.apps.ietf.org>, <idn@ops.ietf.org>
Subject: Re: [idn] LDAPv3 and IDN
Sender: owner-idn@ops.ietf.org
Precedence: bulk
> Personally I'm certain I'm interested in certainty between one element
of
the
> first class, and one element of the second class (transition), as a
minimum.
> I don't agree that its a Bad Thing, in theory or in practice. I'm open
on
the
> issue of equivalency between elements of the third class, and with one
of
the
> first or second.
I take it that "certainty", as you mention above, essentially refers to
"equivalence" between elements of the first class (i.e. ACE) and
elements of
the second (i.e. another CES of 10646).
This I fully support -- which is the issue I was trying to bring up in
the
first place. Imagine if there are two objects, one with "dn:
IDC=中国,IDC=com"
and one with "dn: dc=dq--w8wpt27a,dc=com", ceteris paribus. If
dq--w8wpt27a.com is the ACE representation of 中国.com, should there
even be
two separate objects in the first place, given all that differs between
the
two objects is the distinguished name?
All in all, I believe that planning for inclusion of UTF-8 in protocol
elements might be a reasonble task.
However, I think that UTF-8 being present in protocol elements _as a
separate category_ with a _separate schema_ is a Bad Thing. After all,
IDNs
are also domain names and shouldn't be categorized differently.
(This message is encoded in UTF-8 for posterity)
regards,
maynard