Keith Moore wrote:
On Sep 1, 2011, at 2:58 AM, Hector wrote:
6. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.
That last sentence is so clear. Maybe the error is not using an
uppercase MUST NOT and NOT REQUIRED in that last sentence. Maybe
software people need logic statements like:
I actually think that the last sentence is overbroad. There are
other defensible reasons to use the 2119 keywords than those enumerated
in the document. And those words can be (and have been) interpreted in
such a way as to compel working groups to fail to make design choices,
and to permit too many alternative choices in implementations.
Keith
Keith, I feel ya.
I once presented a paper at a trade conference presenting the idea of:
Cooperative Competition (COCOMP)
It touch based with the growing industry of competitors trying to work
well around new standards of communications. The issue of alternative
choices in implementations was becoming harder to support, more
complex, etc. Especially on the mail side which was rapidly changing
and each adding their own twist or proprietary feature that added
value to their product lines. COCOMP proposed the central idea that
there are ways to have your cake and eat it as long as we have:
a) A understanding of minimum standard requirements that NO ONE can
twist and turn, and
b) and also offer added value, if you wish, using a standard
method to extend your offerings for implementators to follow,
if they want.
The MUST and the SHOULD|MAYs.
So the issues we see here has always been the case and you can't avoid
them. When you have technology leaders that many follow, you have to
be careful that quite often they offer extensions that only apply to
their product line.
That is what that last sentence pretty much touches base with, its a
great insight of the realities of dealing with different implementators.
I think "Cooperative Competition" is the name of game here. Its why
all the vendors get together, that compete in the market place, but we
hopefully cooperative for a common goal.
RFC2119 needs to focus on establishing the minimum conformance
requirements for a protocol or a suite of protocols yet we need to
understand that not everything is required or need to be imposed
across the board because its not just about one mainstream vendor or
technology leader interest but the entire community interest. I can't
impose my product features on anyone and its not proper for another
vendor to impose its wishes on others. Even if they feel its for the
"Common Goal" not everyone is going to agree its a "All or Nothing"
concept.
--
HLS
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf