At 08:10 01-09-2011, Pete Resnick wrote:
Peter's document makes a change to 2119 that nobody has mentioned
yet, and I think it is the one that is causing most of the strife in
this discussion.
[snip]
Peter's document uses the words "conform" and "conformance". They
appear nowhere in RFC 2119. RFC 2119 was not coming up with a
vocabulary for things that MUST be done if one is to conform to a
specification. It came up with terms for things that MUST be done to
interoperate. Or SHOULD be done (with a pretty specific meaning of
"SHOULD"). Or MAY be done.
Agreed.
Section 6 of RFC 2119 offers some guidance about the use of key
word. IETF RFCs are written so that implementations can
interoperate. The change in Peter's document was noticed. It is
premature to take a shot at the document.
If you think that the presence of SHOULD means that you don't have
to implement a particular thing in a document, you're wrong. SHOULD
means that "may exist valid reasons in particular circumstances to
ignore a particular item, but the full implications must be
understood and carefully weighed before choosing a different
course." That is, if you don't do what is in the statement marked by
"SHOULD", there is a good chance you will fail to do something that
is "required for interoperation" or to engage in "behavior which has
potential for causing harm" unless you understand the implications.
People will attempt to justify anything if they have a reason to do
so. If you are feeling lazy, that's a valid reason not to implement
a "should". If you believe that "should" is optional, that's also a
reason to ignore it. As you are the implementer, whatever you say
goes. If your implementation does not interoperate because you have
not fully understood the implications of your decision, what can I say.
You might have a contract with someone who requires you to implement
all MUSTs (or SHOULDs unless you provide an explanation of why you
didn't). That's up to them. But the IETF ought not be in the
business of conformance requirements.
Yes.
At 08:51 01-09-2011, John C Klensin wrote:
This is right, but it is also close to (and hugely clarifies) my
earlier comment about the difference between 2119 language
(about interoperability requirements) and 1122/1123 language
(very much about conformance). A careful reading of the
introductions to those documents should make this clear. For
[snip]
talks about interoperation, but is actually a conformance
statement -- what one must do and conform to in order to meet an
interoperability goal.
I'll quote extracts of a "historical" RFC and leave it to the reader
to decide whether to conform or not:
"These documents are intended to provide guidance for vendors,
implementors, and users of Internet communication software. They
represent the consensus of a large body of technical experience and
wisdom, contributed by the members of the Internet research and
vendor communities."
"A good-faith implementation of the protocols that was produced after
careful reading of the RFC's and with some interaction with the
Internet technical community, and that followed good communications
software engineering practices, should differ from the requirements
of this document in only minor ways. Thus, in many cases, the
"requirements" in this RFC are already stated or implied in the
standard protocol documents, so that their inclusion here is, in a
sense, redundant. However, they were included because some past
implementation has made the wrong choice, causing problems of
interoperability, performance, and/or robustness."
'An implementation is not compliant if it fails to satisfy one
or more of the MUST requirements for the protocols it
implements. An implementation that satisfies all the MUST and
all the SHOULD requirements for its protocols is said to be
"unconditionally compliant"; one that satisfies all the MUST
requirements but not all the SHOULD requirements for its
protocols is said to be "conditionally compliant".'
That RFC also mentions the Robustness Principle:
"Be liberal in what you accept, and conservative in what
you send"
Between you are me, "no one has ever seriously claimed that being
liberal in what is accepted requires being stupid". :-)
Perhaps we should be saying something like "in a Technical
Specification, 2119-like language maps onto interoperability
conditions; in a Applicability Statement, the same language maps
onto conformance requirements". Unfortunately, we often mix the
two types of specifications together in single documents, so
such a provision would add, rather than reduce, confusion.
The old wording for an Applicability Statement was:
"An Applicability Statement specifies how, and under what circumstances, one
or more TSs may be applied to support a particular Internet capability."
It's easier than using the word "conformance".
The 2119bis discussion seems to be about what is required, what is
recommended, what is elective, what is for limited use and what is
not recommended.
The Internet Engineering Terrorist Force will report any sightings of
pachyderms and white elephants.
Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf