[SIPForum-techwg] Why we should just say NO to SHOULD
twinters at iol.unh.edu
Wed Feb 11 07:43:47 EST 2009
At the UNH-IOL we have worked with several different organizations
that have dealt with the SHOULD versus MUST in RFCs as part of a logo
The IPv6 Ready Logo is example of a Logo program that follows IETF
standards. The IPv6 Ready Logo program actually has two Phases.
Phase-I is essentially only testing a subset of MUST in the RFCs, but
it essentially it indicates that should you but this device on a
network it will do basic IPv6 without harming the network.
IPv6 Ready Logo Phase-II test every MUST and SHOULD in the RFCs. The
Logo Committee has been very upfront about this strict requirement to
get this logo. At the time IPv6 was not widely deployed and the IPv6
Forum wanted to make sure the logo proved that this devices would work
in any IPv6 environment one might encounter.
A trouble area that we have seen in the past with logos is when the
logo only test some of the SHOULD in a RFC. This leads to heated
discussions about why certain SHOULDs are left in or out. One way
forward is to only test SHOULDs that would effect Interoperability.
I agree with Cullen that this issue needs to have this decided so this
doesn't keep coming up in future discussions.
On Feb 10, 2009, at 10:38 PM, Cullen Jennings wrote:
> SHOULD is harmful to interoperability. If a spec says that a product
> SHOULD do X. The people deploying it assume this means products will
> do X and the people implementing assume they can ignore X. If you want
> things to actually work, go find every SHOULD and change it to a MAY
> or MUST.
> Now the IETF manages to find some weasel room in SHOULD but SIPForum
> wants to have a compliance program and is not going to have any wiggle
> room in this. The compliance program will have to decide if SHOULD
> actually means MAY or MUST. Having that argument now is much easier
> than having it later.
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg
More information about the techwg