[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] Adding "optional" characters in draft-ietf-idn-nameprep



> I believe DNS means Domain Name System and not DictioNary System.  So there
> really should be no attempts at determining the semantics of a name or
> character for that matter.  

nobody is talking about determining the semantics of a name.
rather we are talking about how to make IDNs such that they can be
transcribed (from viewed text, voice, or memory) with minimal
chance for transcription errors.

> I suggest that we follow the Unicode specifications and let their experts
> guide us along.  

Unicode doesn't completely solve the problem, nor can it.  it's not
a problem of how to represent characters (that part is largely solved),
it's a problem of their being more than one way to transcribe a name
in many languages.

> The DNS could evolve as the Unicode standard evolve as
> well... there is no problem with that at all.  

if the processing has to be done at the client end, it is a problem.
(it's also a problem if it has to be done at the server end, but it's
easier to upgrade the servers than the clients)

> In the mean time, that is why David and I proposed to incorporate 
> different encoding schemes into the DNS because we believe that 
> with these come well established mechanisms for local use.  

what is "local"?  users of a service often have little or no geographic
or topological proximity to the service itself.  you can't expect 
clients to know about the encoding scheme used by a particular server.

again, the problem isn't the ability to represent characters - unicode
solves that well enough.  there's no need for a variety of character 
encodings on the wire.  (though it might be useful to allow them in 
zone files that people edit with text editors)

> The character restrictions that were in place for the original DNS have
> created problems for migration into multilingual names and we are well aware
> of it.  Today as we design the next generation system, we must keep in mind
> that no characters should be ignored or rejected by the name server purely
> because it contains restricted characters.  Rather the DNS should decide by
> transversing the hierarchy to determine the existence of a domain.

nobody is talking about having the IDN protocol restrict what characters
appear - the restrictions should occur at other levels.

however that does not imply that IDN should allow arbitrary representation 
of any particular character (when there's a clear need for having a canonical
form), nor that IDN should provide for arbitrary encoding schemes.  (there's 
no good reason to do this, it's simply bad engineering and a waste of 
resources)

Keith