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@xxxxxxxxxxxxxxxxx] > Sent: Monday, September 25, 2006 2:08 PM > To: Julian Reschke > Cc: ietf@xxxxxxxx; 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@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf