[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Re: I-D ACTION:draft-ietf-idn-requirements-06.txt
- To: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
- Subject: Re: [idn] Re: I-D ACTION:draft-ietf-idn-requirements-06.txt
- From: John C Klensin <klensin@jck.com>
- Date: Sat, 12 May 2001 13:23:18 -0400
- Cc: idn@ops.ietf.org
- Delivery-date: Sat, 12 May 2001 10:24:10 -0700
- Envelope-to: idn-data@psg.com
--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