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

["James Seng/Personal" <James@Seng.cc>]

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

----- Original Message -----
From: "John C Klensin" <klensin@jck.com>
To: "Eric Brunner-Williams in Portland Maine" <brunner@nic-naa.net>
Cc: <idn@ops.ietf.org>
Sent: Sunday, May 13, 2001 1:23 AM
Subject: Re: [idn] Re: I-D ACTION:draft-ietf-idn-requirements-06.txt


> --On Saturday, 12 May, 2001 10:19 -0400 Eric Brunner-Williams in
> Portland Maine <brunner@nic-naa.net> 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
>
>
>