On 1/7/2013 6:01 PM, John Day wrote:
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.
+1
A protocol *is*:
- the states at the endpoints
- the messages on the wire
- a description of input events (message arrival, upper-layer
interface requests, timer expiration) that indicates
the subsequent change of state and output event
(message departure, upper layer indication,
or timers to set)
(i.e., a Mealy machine, attaching events to arcs)
The "wire" is the second of these, and entirely insufficient as a
protocol spec.
Yes, there are two ways to try to write a protocol spec:
- procedural
defining the above explicitly
- behavioral
defining a protocol only from its external
behavior
The difference between these is easy to see for sort algorithms:
procedural:
quicksort
heapsort
etc.
behavioral:
sort
AFAICT, "on the wire" often implies behavioral equivalence, but it's a
lot more complicated than just the on-wire messages. A behavioral
description of a protocol would treat the protocol as a black box and
explain its behavior under every possible input.
I'll take procedural descriptions of protocols over behavioral any day.
Joe