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

Re: [idn] requirements-07



Once again, we (Zita & myself) are not "authors" but rather "editors" of
this document. We did not come up with these requirements but rather
taking comments from the Working Group across our discussion since Nov
99 and piece them together.

If you want to track the source, you should not be looking for us. Look
for the one who made this comments OR you can find it by going thru the
archives http://www.i-d-n.net/ yourself.

ps: The reason for the slowness to response to your editorial is because
I have an filter which put emails from brunner@nic-naa.net in the same
folder as Jeff Williams. You can consider it as /dev/null for all intent
and purposes.

-James Seng

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <brunner@nic-naa.net>
To: "James Seng/Personal" <James@seng.cc>
Cc: <idn@ops.ietf.org>; <brunner@nic-naa.net>
Sent: Wednesday, May 23, 2001 11:53 AM
Subject: Re: [idn] requirements-07


> > 2. Remove requirement [30] and renumber [31] to [30].
>
> Without ever identifying who thought that zone-specific semantics MUST
> be useful? Without ever identifying what use cases were offered for or
> against such an apparently authorless assertion? Without a requirement
> that zone-specific semantics MUST NOT be useful?
>
> How ... creative.
>
> Co-author and co-chair Seng asked me for alternate text. I responded
> that without knowing why [30] ever came into being in the first place,
> alternate text could not be the best course of action. Now, as if this
> is "better" than the last botch (substituting "MAY" for "MUST"), all
> requirement relative to semantic scope (and consistency or its lack)
> has been removed.
>
> There is something above peculiar in the process this WG is thrashing
> under.
>
> I'd like the authors of the document to respond to substantive
queries,
> not fumble serial text botches. I want to know why [30] was ever in,
as
> why it could be out is a much simpler question, though not necessarily
> with only one answer.
>
> Eric
>