I think that we need to decide what we are trying to achieve in any given
situation. I have been thinking mostly about DNS but the ideas are probably
more general:
Modifying Soebok's trichotemy, there are different uses that can be made of an
identifier:
0) Random
There is no systematic relationship linking the identifier to the
referent.
Examples: randomly assigned GUIDs, some uses of hash values.
1) Indexical
The identifier describes the means of discovering the referent.
Examples: Telephone numbers, URLs, IP addresses
2) Mnemonic Indexical
An indexical identifier designed to be easily remembered as an
identifier for the referent
Examples: 1-800-FLOWERS, entries in the hosts file
4) Authenticator
An identifier that is designed to establish the authenticity of the
referent
Examples: The CocaCola logo, Nike logo, etc. Digital Signature, hash
values of the referent
It seems to me that a large part of the reason why we get into so many
confusions with I18N is that these different purposes get confused.
For example the DNS is designed to support location (Indexical) and discovery
(Mnemonic Indexical) functions. Performing these functions well is not
compatible with the authenticatior function.
Moreover the direction og the communication is reversed. From the user's point
of view the location/discovery functions are write operations, they supply the
DNS name. From the user's point of view the authentication function is a read
operation.
I believe that we need to separate the location/discovery functionality from
the authentication functionality. Trying to support both functionalities in a
single infrastructure is probably impossible. To support the discovery function
optimally the mapping from identifier to referent must be as loose as possible,
so registration processes must be loose. This is the opposite of what you want
for authentication.
There is no way to absolutely avoid issues with deliberately ambiguous domain
names. Even without I18N a perp intending to attack Bizybank.com can register
security-bizybank.com or bizzybank.com.
In secure letterhead we support the authentication channel through the brand of
the referent, usually an image file. The registration process will by necessity
have to be closely controlled and monitored (an extension of the High
Assurance/Extended Validation process currently under discussion), there will
have to be provision for revocation, etc.
Once it is understood that the location/discovery channel should not be used
for authentication the value of the loose comparator becomes clear. The
Internet should have a 'did you mean' function.
-----Original Message-----
From: Lisa Dusseault [mailto:lisa(_at_)osafoundation(_dot_)org]
Sent: Monday, September 25, 2006 2:08 PM
To: Julian Reschke
Cc: ietf(_at_)ietf(_dot_)org; The IESG
Subject: Re: Comments on draft-dusseault-caldav-15
anddraft-newman-i18n-comparator-14
On Sep 23, 2006, at 2:20 AM, Julian Reschke wrote:
But as a matter of fact, draft-newman-i18n-comparator-14 doesn't
define any collations that would actually solve the Unicode
NF issue,
so it's not really clear how this helps CalDAV (except that it now
uses a framework in which the solution may become available in the
future).
Maybe the set of initial registrations in <http://tools.ietf.org/
html/draft-newman-i18n-comparator-14#section-9> needs to be
extended?
Yes, I agree. That's one of the next steps and why a registry
was created (so we could do it outside the base comparator draft).
Last week Ted & I were discussing whether one could define a
Very Liberal Comparator (VLC) for general use. It would be
handy to have one which matched e with E, é, è É... and
matched o with O, ø, ô, and so on. That would help in
calendar searching use cases, e.g. a user who can't type in
accents (or doesn't know how) wants to find the invitation
from André by searching for "andre". It would probably be
useful in many other cross-language or unknown-language
situations too.
Such a comparator would be most useful for exact and
substring matches; I don't know offhand how it would best do
ordering so it might not be as useful for ordering.
I believe Arnt intends to continue working on this general
problem, for which I'm very grateful, and other contributions
would be most welcome.
Lisa
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf