Keith Moore wrote:
On Aug 31, 2011, at 9:12 AM, Hector wrote:
If SHOULD is read as a MUST IMPLEMENT, and that also
implies MUST USE with no provision to disable then its should of
been a MUST in the first place.
Just because a feature is optional does not mean that it's a
protocol feature... i.e. it doesn't mean that it affects how the
implementation interacts with peers.
Thats the problem with trying generalize SHOULD as single
interpretation for all SHOULDs when it is so highly subjective many times.
I think you are speaking of long term operations where an SHOULD is so
widely adopted, it inherently because a MUST have in all new
implementations. So that vain, sure, eventually the better options
naturally become part of the protocol to the extent the options might
be even remove to simplify things. We also have the opposite where a
SHOULD is implemented but no one users it so eventually, it may be
remove as an option.
SHOULD is IMO most often useful not when specifying how a protocol
acts "on the wire", but when specifying how a protocol needs to be
implemented on a particular platform, where the precise semantics,
API details, etc. naturally differ from one platform to another.
Yeah, but its also very very useful to offering what parts of a
protocol are on and off and let operators decide what they want.
Don't we already do this?
Why even bother with SHOULD, and just use MUST and MAY?
To get people out of the rathole of trying to specify exactly how
everything must work in excruciating detail, in a world where there is
inherently going to be some necessary variation.
I agree, it is the easy way out. But wouldn't it still be a rathole
if SHOULD was still a MUST-IMPLEMENT concept which is why a MUST made
it an rathole in the first place? Too many people didn't like, not
want it nor wish to waste time on a unproven concept. So you make it a
SHOULD or a MAY.
With a MUST-IMPLEMENT view of SHOULD, then SHOULD really isn't
compromise if you have to implement and even more so if no one is
allowed to turn it off.
-1 on RFC2119bis :)
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
