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

Re: [idn] Re: I-D ACTION:draft-ietf-idn-requirements-06.txt



--On Sunday, 13 May, 2001 09:11 +0800 "James Seng/Personal"
<James@Seng.cc> wrote:

Taking your comments in reverse order...

> ps: [14] and [30] are in conflict. We knew it all the time.
> There is a tag which say it is in conflict from -01 to -04 but
> no one mention it until now.

Well, I mentioned it when I noticed it hadn't been straightened
out by -05, having assumed that it was under consideration.   It
needs to be fixed.  I think, personally, it needs to be fixed by
dropping [30] and any notion of zone-dependent (zone-variant)
resolution from the requirements.  I would be happier with a
requirement that said, more or less "you MUST not even
contemplate that idea", but I'd settle for dropping [30].  

But the WG needs to decide what it wants to do here.  I would
note that some localization-dependent (not
zone-structure-dependent) options/ variations are possible, but
more likely in a search environment (see my note to Adam) than
anything having to do with DNS server operations.   But the
document doesn't say that.

> If changing MUST to MAY is not acceptable, then please kindly
> forward the appropriate wording changes.

>From my point of view, the "appropriate wording change" is to
lose [30] --and any other notion of different things happening
in different zones-- entirely.  Zone-dependent stuff assumes
that one can tie DNS hierarchy to specific languages or
character sets.  That is, obviously, possible in a few cases,
but only at the cost of chaos for multilingual countries, groups
in the relevant countries/ zones who use other languages and
conventions, and overlaying orthogonal semantic structure on the
administrative structure of the DNS -- just can't work in the
general case or the long term, however much some groups might
want it.

If the WG doesn't want to drop [30], then it needs to figure out
how to resolve the conflict/ contradiction in some other way.
Once it does, we can work on text.

    john