At 23:38 +0100 2012/01/08, Martin Sustrik wrote:
On 08/01/12 13:00, John Day wrote:
You are also correct that strictly speaking the words "protocol" and
"algorithm" are probably the same.
That is an interesting point.
What I encounter often is the belief that protocol is just
"description of bytes on the wire". People often forget about the
stuff that cannot be seen on the wire (e.g. TCP state machine).
This is clearly not the case and has never been the case.
In fact, "bytes on the wire" is probably the smallest part of a
protocol specification. A protocol specification must specify what
to do with the "bytes on the wire/"
The next time someone suggests that merely ask, what do you do with
the bytes on the wire? Where is that specified? The action to be
taken when a message arrives is all there is.
There was once a group who thought that names of the fields in their
protocol was sufficient to specify what was to be done with them. I
pointed out the them that a legal value of every field in their
protocol was the letter "Z". They objected to this quite
strenuously, but I asked to show me where it said this was not the
case. ;-)
Anyone who says that merely specifying the format of messages (bytes
on the wire, as you say) constitutes a protocol specification is
clearly not competent to be making such pronouncements.
The area I work in has little or no special "bytes on wire" (simple
message-based underlying transport is sufficient) but a lot of
algorithmic stuff. Consequently, it was often dismissed as not being
a protocol.
"has little or no special "bytes on wire" (simple message-based
underlying transport is sufficient)" I have no clue what this phrase
could possibly mean. If you are passing messages, there must be
"bytes on the wire" otherwise, the messages have not been exchanged.
Take care,
John Day
Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf