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

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 12 May 2001 10:19:25 -0400

53: s/altho/although

Who cares in a WG requirements draft if a current assumption may not yet
or ever enjoy the celebrated status of the consensus of the IETF community?
We're here to solve a problem _caused_ by some prior consensus, a statement
of work not unique to this WG. Compare, v4 vs v6.

Also, at 49, s/item/protocol/.

496-502 [30]

Just what does a change from MUST to MAY accomplish? This doesn't remove the
(argued) problem of zone-specific semantics. MUST NOT would have accomplished
that. The original motivation for [30] appeares to have been either forgotten
or mislaid, and weakening it isn't the same as removing it, or restating it.

Note to the authors: My query of 30 April is appended.

651: s/<</</.

Cheers,
Eric

------- Forwarded Message

Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>,
   [email-masked], [email-masked]
Subject: [idn] Clarification, draft-ietf-idn-requirements-0?.txt, [30]
Date: Mon, 30 Apr 2001 08:12:46 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]
Precedence: bulk

Authors,

Would you do me the kindness of reminding me who proposed the current text
of General Requirements, item [30]? I'd like to know what use case(s) were
offered to motivate this manditory-to-implement (zone manager definition of
equivalency rules) requirement.

Tia,
Eric

------- End of Forwarded Message

---

From: John C Klensin <[email-masked]>
Date: Sat, 12 May 2001 13:23:18 -0400

--On Saturday, 12 May, 2001 10:19 -0400 Eric Brunner-Williams in
Portland Maine <[email-masked]> wrote:

>...
> 496-502 [30]
> 
> Just what does a change from MUST to MAY accomplish? This
> doesn't remove the (argued) problem of zone-specific
> semantics. MUST NOT would have accomplished that. The original
> motivation for [30] appeares to have been either forgotten or
> mislaid, and weakening it isn't the same as removing it, or
> restating it.

I want to reinforce Eric's point here, but from a slightly
different direction.  Often, especially with application
protocols, we permit "MAY" specifications because we really do
not care whether a feature is supported.  But, with something
like the DNS, interoperability is everything.  To say "MAY" in
the DNS context is to say "maybe someone will do this, maybe
they won't, but, if all of the client, authoritative server,
secondary servers, and any caches don't make the same decision,
things won't work consistently and as expected.   And that is
essentially equivalent to saying "if is ok if we don't have
interoperation in this area".  

I don't see that as acceptable, at least unless there is a clear
default strategy that is required and failures in interworking
with a "may implement" option or variation are so designed so
that the need for, and operation of, the fallback to that
default behavior are clear.

And I do not see [30] as meeting that sort of criteria.

   john

---

From: "James Seng/Personal" <[email-masked]>
Date: Sun, 13 May 2001 09:11:30 +0800

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

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.

-James Seng

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 12 May 2001 22:04:58 -0400

Mr. Seng,

It is not. When the authors respond to my question I'll be in a position to
judge which change to suggest. Mr. Klensin is quite capable of offering yet
another suggestion.

If you would be so kind as to provide a pointer to the versions which had a
conflict with [30] I would appreciate it. I don't have -01 - -04 at hand (if
I ever did), and never would have noticed [30] if momentary circumstances had
not given me pause to think. I trust you don't mean CCS or CES or charset
uniqueness. If you ment the -06 [17], then there is a possible overlap of
requirements with -06 [30]. My longer note to Jony covered this, the use of
"8" (digit) as a alpha-tuple in Algonquin family orthographies, e.g., in the
Canadian Maritimes, Northern New England and Quebec -- W8banakia. Of course
-06 [17] can be read as flatly contradicting -06 [30].

I'm at a loss as to what to make of your sudden politness.

Eric

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 May 2001 01:37:22 -0400

--On Sunday, 13 May, 2001 09:11 +0800 "James Seng/Personal"
<[email-masked]> 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