Keep in mind only a STD is a "real" standard. A RFC is still only a
recommendation, a guideline. What makes it a "pseudo-standard" is
the # of implementations, how wide spread it is and foremost IMO, how
much embedded it is so that a change has a negative impact. At that
point, an RFC not having a STD status probably doesn't matter any more.
At best, you might be able to sue for malpractice (failing to do what
most experts in field would be doing) in cases where there is provable
harm caused by the neglect to implement a well known practice. But
only maybe getting your money back is realistic. :)
ikael Abrahamsson wrote:
On Sat, 5 Jan 2013, Abdussalam Baryun wrote:
Hi Mikael
Also what it means following things in it that is not RFC2119 language.
It will mean, you should understand me/english/ietf/procedure even if
I don't have to explain, and you need to understand English well even
if you are a great implementor or great programming language speaker.
The problem here is that I want them to pay back some of the money (or
take back the equipment totally and give back all money) for breach of
contract, when I discover that they haven't correctly (as in intention
and interop) implemented the RFC they said they said they were compliant
in supporting.
Ianal, but it feels that it should easier to do this if there are MUST
and SHOULD in there and I asked them to document all deviations from these.
--
HLS