Re: 2119bis
2011-08-30 10:45:07
On Aug 30, 2011, at 11:38 AM, Marc Petit-Huguenin wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/30/2011 07:58 AM, Keith Moore wrote:
On Aug 30, 2011, at 10:54 AM, Marc Petit-Huguenin wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/30/2011 07:35 AM, Keith Moore wrote:
On Aug 30, 2011, at 10:14 AM, Marc Petit-Huguenin wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/30/2011 06:54 AM, Keith Moore wrote:
I think you're overgeneralizing. My experience is that judicious use of
SHOULD seems to make both protocols and protocol specifications simpler;
trying to nail everything down makes them more complex.
But using SHOULD does not make the implementation less complex, it simply
decreases the complexity for the *author* and increases the probability
that two
independent implementations will have interoperability problems.
To the extent that SHOULD is causing interoperability problems, it may be
that some authors are misusing SHOULD. But it's not an inherent problem
with SHOULD.
As an implementer, I would ban all SHOULD/SHOULD NOT/RECOMMENDED/NOT
RECOMMENDED.
I'm an implementor also, and I've found SHOULD to be very helpful.
Yes, it is very helpful in convincing one's PHB that one does not have to
implement something, or in convincing another company to reactivate a
feature
during interop tests because one did not bother to implement it.
Rather than vaguely attacking SHOULD, maybe it would be more illuminating to
cite specific examples?
It is difficult because of a mix of NDAs, employment confidentiality
agreements
and desire to not single out individuals. I'll send you an example in a
private
email.
I look forward to seeing it.
But in general I get the impression that people are attacking SHOULD because of
specific problems rather than general problems. Since I find SHOULD very
useful, to me it makes more sense to try to outline cases where SHOULD is
problematic, and provide advice for those cases, than to try to get rid of it
or change what it means.
e.g. For the specific case of optional features that must be negotiated, I
don't think that SHOULD is the problem. Rather I think that optional features
are too common. That's not to say that optional features and feature
negotiation are never useful, particularly when extending a protocol that is
already well-established in the field. But if making features optional is seen
by WGs as a way to avoid making hard decisions about what is required to
interoperate, that really is a problem. It just doesn't have anything to do
with SHOULD.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: 2119bis, (continued)
- Re: 2119bis, Mark Nottingham
- Re: 2119bis, Keith Moore
- Re: 2119bis, HLS
- Re: 2119bis, Eric Burger
- Re: 2119bis, Keith Moore
- Re: 2119bis, Marc Petit-Huguenin
- Re: 2119bis, Keith Moore
- Re: 2119bis, Marc Petit-Huguenin
- Re: 2119bis, Keith Moore
- Re: 2119bis, Marc Petit-Huguenin
- Re: 2119bis,
Keith Moore <=
- Re: 2119bis, Eric Burger
- Re: 2119bis, Keith Moore
- Re: 2119bis, Marc Petit-Huguenin
- Re: 2119bis, Keith Moore
- Re: 2119bis, Marc Petit-Huguenin
- Re: 2119bis, Eric Burger
- Re: 2119bis, HLS
- Re: 2119bis, Keith Moore
- Re: 2119bis, Eric Burger
- RE: 2119bis, Murray S. Kucherawy
|
|
|