All standards groups that I am aware of have had the same view. This
is not uncommon.
Although, I would point out that the TCP specification nor do most
protocols specifications of this type follow this rule. State
transitions are not visible on the wire. The rules for sliding
window are not described entirely in terms of the behavior seen on
the line, etc.
I have seen specifications that attempted this and the
implementations built from them were very different and did not come
close to interoperating or in some cases of even doing the same thing.
In fact, I remember that we thought the new Telnet spec (1973) was a
paragon of clarity until a new site joined the Net that had not been
part of the commuity and came up with an implementation that bore no
relation to what anyone else had done.
This problem is a lot more subtle than you imagine.
Take care,
John Day
At 4:46 PM -0500 1/7/13, Thomas Narten wrote:
Stewart Bryant <stbryant@xxxxxxxxx> writes:
Indeed an interesting additional question.
My view is that you MUST NOT use RFC2119 language, unless you MUST use
it, for exactly that reason. What is important is "on the wire" (a term
that from experience is very difficult to define) inter-operation, and
implementers need to be free to achieve that though any means that suits
them.
The latter goes without saying. It's one of the "obvious" assumptions
that underlies all IETF protocols. It may not be written down, but its
always been an underlying principle.
E.g., from RFC 1971:
A host maintains a number of data structures and flags related to
autoconfiguration. In the following, we present conceptual variables
and show how they are used to perform autoconfiguration. The specific
variables are used for demonstration purposes only, and an
implementation is not required to have them, so long as its external
behavior is consistent with that described in this document.
Other document (that I've long forgotten) say similar things.
That sort of language was put into specific documents specifically
because some individuals sometimes would raise the concern that a spec
was trying to "restrict" an implementation.
IETF specs have always been about describing external behavior
(i.e. what you can see "on the wire"), and how someone implements
internally to produce the required external behavior is none of the
IETF's business (and never has been).
(Someone earlier on this thread seemed to maybe think the above is not
a given, but it really always has been.)
Thomas