Hi John, thank you for your reply (i.e. learned alot), so I understand that a RFC standard track may have more than one implementation but same behavior enough not to make an error. Regarding following 2119, I understand most text follow it only when there are normative actions. Regarding implementer claiming following a RFC, but the question of error in process is does the RFC lack communication requirement with the community?
AB On 1/7/13, John Day <jeanj...@comcast.net> wrote: > Strictly speaking, the language of 2119 should be followed wherever > necessary in order for the text to be normative and make it mandatory > that a conforming implementation meets some requirement. Otherwise, > someone could build an implementation and claim it was correct and > possibly cause legal problems. However, in the IETF there is also a > requirement that there be two independent but communicating > implementations for an RFC to standards-track. Correct? > > For all practical purposes, this requirement makes being able to > communicate with one of the existing implementations the formal and > normative definition of the RFC. Any debate over the content of the > RFC text is resolved by what the implementations do. It would seem > to be at the discretion of the authors of the implementations to > determine whether or not any problems that are raised are bugs or not. > > Then it would seem that regardless of whether 2119 is followed, the > RFCs are merely informative guides. > > So while the comments are valid that RFC 2119 should be followed, > they are also irrelevant. > > Given that any natural language description is going to be ambiguous, > this is probably for the best. > > Take care, > John Day > > At 9:41 AM +0100 1/6/13, Abdussalam Baryun wrote: >>Hi Marc Petit-Huguenin , >> >>>I read the responses so far, and what can be said today is that there is >>> 2 >>philosophies, with supporters in both camps. The goal of the IETF is to >> make >>the Internet work better, and I do believe that RFC 2119 is one of the >>fundamental tool to reach this goal, but having two ways to use it does >> not >>help this goal. >> >>I like the approach, and agree with you that we need a solution in >>IETF which still is not solved or ignored by participants fo some >>reasons. However, I agree of a survey or an experiment what ever we >>call it, that makes IETF reflects to the RFC2119 performance on the >>end-user of such product implementation of RFC protocols. I think many >>old participants already have good experience to inform us of some >>reality of IETF standards' end-user production. >> >>AB > >
