On 01/09/2012 01:35 PM, John Day wrote:
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.
Agreed. However, consider following problem: Imagine there's a
specification that doesn't define any new wire formats, only specific
ways to handle existing messages (UDP packets, SCTP messages or
whatever). Is it still eligible to become an IETF protocol?
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.
What I am working on is business messaging (a.k.a. message-oriented
middleware). In lot of cases it works ok with existing message formats
(e.g. UDP packets, PGM APDUs, SCTP messages etc.) and doesn't require
any additional data to be passed on the wire.
What the specification focuses on are things like: If TCP is used to
form a one-to-many message distribution tree, how should we handle TCP
flowcontrol/pushback in such a way that a single slow receiver doesn't
block the whole message distribution tree? Or: How to receive messages
from multiple sources without allowing one sender to starve out the
receiver and thus block the other senders (some form of fair-queueing is
needed)? Etc.
Martin
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf