Subject: Re: 2119bis

From: Alan Barrett <[email-masked]>
Date: Sat, 3 Sep 2011 09:20:27 +0200

On Tue, 30 Aug 2011, Martin Sustrik wrote:
>For an implementor it's often pretty hard to decide whether to 
>implement functionality marked as SHOULD given that he has zero 
>context and no idea whether the reason he has for not implementing the 
>feature is at all in line with RFC authors' intentions.

It's really simple.  If an interoperability problem arises
from your failure to implement a SHOULD, then it's your fault.

--apb (Alan Barrett)

---

From: Hector <[email-masked]>
Date: Sat, 03 Sep 2011 06:40:29 -0400

> from your failure to implement a SHOULD, then it's your fault.

Even when dealing with backward compatibility requirements when the 
author adds a SHOULD in spec v2.0 that was never there before in spec 
v1.0?

It is not just about the implementor not supporting a new v2.0 SHOULD 
option, but there could be v1.0 implementator that isn't going to use 
these feature and will never happen - the same repercussions as if the 
v2.0 implementator choose to not implement it or turn it on.

You can't break down if an implementator don't know, doesn't implement 
or implements but it is turned off.

Maybe we need a NO-FAULT-SHOULD keyword?  :-)

--
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 3 Sep 2011 22:21:41 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan Barrett
> Sent: Saturday, September 03, 2011 12:20 AM
> To: IETF Discussion
> Subject: Re: 2119bis
> 

+1, and very well said.

---

From: Martin Rex <[email-masked]>
Date: Wed, 7 Sep 2011 05:52:34 +0200 (MEST)

> > feature is at all in line with RFC authors' intentions.

The likelyhood of a SHOULD getting implemented is directly related
to its implementation complexity.  There are extremely complex protocols
(such as PKIX/rfc5280) where implementing all SHOULDs is economically
infeasible for many implementations (there are even some MUSTs in the
spec that are regularly ignored--and one can hardly blame implementations
for it).

> from your failure to implement a SHOULD, then it's your fault.

Hardly.  A protocol spec ought to be architected so that two implementations
of only the MUST requirements will still be interoperable, otherwise
it is calling for troubles.  A should requirement for a communications
protocol means that the _other_ end must sensibly (which in many cases
implies "gracefully") deal with peers that do not implement SHOULDs.

-Martin