ietf
[Top] [All Lists]

Re: A proposal for a scientific approach to this question [was Re: I'm struggling with 2219 language again]

2013-01-07 20:09:47
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(_at_)cisco(_dot_)com> 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

<Prev in Thread] Current Thread [Next in Thread>