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