Well, let me reiterate (maybe with more acceptable language) what
I was saying. I don't want this thought to be disregarded
because I've stepped on the wrong buzzword!
I'm just making the observation that our solar debris of our
"wish list" seems to have more than one concentration of mass.
Perhaps it needs to coalesce into two or more planets instead of
just one. This too, it would seem to me, would be a viable
conclusion in the end... especially if the two or three planets
knew how to cooperate according to a common framework.
From: David W Morgan [mailto:dwmorgan(_at_)ntlworld(_dot_)com]
Sent: Saturday, February 21, 2004 10:57
To: 'Hadmut Danisch'; 'Keith Moore'
Cc: mail-ng(_at_)mail(_dot_)imc(_dot_)org; Chris Bonatti
Subject: RE: Email or Something Else
Certainly agree with your sentiment here. If using the term
"design goals" works and allows progress to be made then I'm all
My original point was that many of the discussions were
identifying "design goals" or issues that did not necessarily fit
in with a future mail system, although all valid in their own
right. The point Chris made still seems to be valid. However,
it could be rephrased
"Grouping together design goals that would be associated with
common application. In addition, there could be a set of design
goals for an underlying transport mechanism".
From: Hadmut Danisch [mailto:hadmut(_at_)danisch(_dot_)de]
Sent: 21 February 2004 15:38
To: Keith Moore
Cc: David W Morgan; mail-ng(_at_)mail(_dot_)imc(_dot_)org
Subject: Re: Email or Something Else
On Sat, Feb 21, 2004 at 10:25:38AM -0500, Keith Moore wrote:
ambitious, or too peripheral. However by grouping the wishes
to see how they apparently conflict we might be able to take a
stab at writing "design goals" that try to capture the kinds of
compromise that seem appropriate. (I still hesitate to use the
"requirements" because I've too often seen that word be a
that kind of compromise.)
"Design goals" is a very good wording. If we find "requirements",
everyone else will argue to have different "requirements" or that
our "requirements" were wrong. In contrast, "design goals" are
"our" goals and that's what we would use to design a protocol.
Much less potential of conflict with other opinions. Much better.
So let's use "design goals" instead of "requirements".