Re: Making RFC2119 key language easier to Protocol Readers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]