Certainly agree with your sentiment here. If using the term "design
goals" works and allows progress to be made then I'm all for that.
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 first
stab at writing "design goals" that try to capture the kinds of
compromise that seem appropriate. (I still hesitate to use the word
"requirements" because I've too often seen that word be a hinderance
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".