At 15:29 +0900 2012/01/09, Martin Sustrik wrote:
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?
Two problems here: 1) The scope of the IETF has nothing to do with
the original question of "what is a protocol?" For that you will
have to consult the rules of the IETF.
2) The specifications of UDP, SCTP, etc provide the full and
complete specification of their messages. So you must be defining
something else, or you are proposing modifications to these
protocols, so you should be working with their groups. In the case
of UDP, I highly doubt this.
Sounds to me that you are working with the very old phone company
"beads-on-a-string" model rather than the more modern layered model.
But then that seems to be fairly prevalent in the IETF.
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.
This makes no sense whatsoever. UDP and SCTP messages change the
state (not much in the case of UDP) of their protocol machines, etc.
If what you say is true, i.e. doesn't require any additional data to
be passed on the wire, then I can guarantee that your "business
messaging" does nothing.
UDP and SCTP messages are consumed by those protocols machines.
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.
These are local matters unless feedback is used. In which case there
is a protocol. Having worked through these issues years ago, it
sound to me like you don't have a clear picture of the model.
Take care,
John Day
Martin
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf