IMO the important issue in any definition is to include how the IETF
this may be find in some RFCs :)
The IP is the main protocol, and all protocols in IETF are based on IP
On 5 Jan 2012, todd glassey <tglassey at earthlink.net> wrote
On 1/5/2012 6:48 AM, Dave CROCKER wrote:
(One can quibble about the difference between algorithm and
program. An algorithm is a component of a program.
The program is the code-based implementation of the alg?
The distinction is relevant here because a protocol is typically
a complete mechanism rather than being a component of the
I.e. "A complete method of doing something"...
I noticed no disagreement between "method" and "mechanism", at the
time. In retrospect, those two terms might seem to allude to a
different depth of semantic explanations. Rereading that thread, I
find that the same ambiguity holds for algorithm descriptions: one
can give a full description (or coding) of, say, sqrt, without
actually saying that the square of the result will match its argument
up to some rounding error. The specification does not have to relate
the underlying mathematical abstraction.
Protocol specifications, especially when dealing with policies, do not
have to describe the exact meaning of the relevant tokens. To do that
would often look like mandating a state or a reaction, neither of
which is needed to ensure interoperability. In fact, the protocol
just has to ensure that a policy can be transmitted correctly. Many
would rather leave a policy token underspecified than get involved in
In that respect, a protocol is not a complete method. The "upper
layer", where policies and politics are dealt with, seems to be too
fuzzy to be specified. I think this limitation is consistent with the
etymological meaning of the term, that refers to forms of conduct that
don't betray intentions. Is that right?