IMO the important issue in any definition is to include how the IETF defines protocol, this may be find in some RFCs :) The IP is the main protocol, and all protocols in IETF are based on IP and Internet. AB ++++ 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 >> mechanisms. > > 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 its details. 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?