[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Matching and comparison
- To: firstname.lastname@example.org
- Subject: RE: Matching and comparison
- From: Andrew Draper <ADRAPER@altera.com>
- Date: Tue, 18 Jan 2000 03:08:16 -0800
- Cc: "'Paul Hoffman / IMC'" <email@example.com>
- Delivery-date: Tue, 18 Jan 2000 03:05:15 -0800
- Envelope-to: firstname.lastname@example.org
> From: Paul Hoffman / IMC [mailto:email@example.com]
> 2.3 Matching and comparsion
> I think you are trying to mandate case-insensitivity here. That's good
> in theory and bad in practice for international characters. There are
> examples of letters whose case conversion are different for different
> written languages. If we want to require case-insensitivity, we
> have to point to a single conversion table for all characters.
Not in all cases. Hopefully this isn't getting into too much detail:
The canonicalisation algorithm used in all DNS servers MUST be identical (it
might be null). This is required so that the answer from a caching or slave
server will be essentially the same as the answer from the master server for
the zone. Contradicting this will break the DNS in all sorts of vague and
hard to diagnose ways. [There are ways to get round this, but they are
mostly to nasty to contemplate]
However, installing different canonicalisation algorithms in resolvers will
not have such a catastrophic result. Yes, my resolver will behave
differently to your resolver, but I can edit the settings which control this
(ie it is clearly my mistake).
> On the other hand, similar glyphs given different codespace on a
> character set should be treated differently.
> "Treated differently" is vague. It will get more vague if you allow
> multiple character sets that have the "same" characters in them. I
> suggest that the above be rewritten as "Canonicalization of characters
> must follow precise and predictable rules."
Agree. I didn't understand the previous sentence either.
> If a canonicalisation algorithm is proposed, the algorithm must be
> easily upgradable as new languages/writing systems are added.
> I disagree. We can't have a moving target for canonicalization. It must
> be fixed *before* any internationalization of the DNS occurs.
Only canonicalisation in servers must be fixed. Canonicalisation in
resolvers can be updated if new characters are added to the character set(s)
used in the protocol.