ietf
[Top] [All Lists]

Re: Protocol Definition

2012-06-18 17:45:05


On 6/18/2012 3:30 AM, Alessandro Vesely wrote:
...
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.

This is the difference between a behavioral description and a procedural description.

Behavioral treats a system as a "black box", and defines the system as a function and how it transforms its input into its output.

Procedural specifies the particular steps taken inside the box.

Procedural is more specific than behavioral:

        behavioral = any of a number of ways of calculating SQRT
        procedural = one specific algorithm for calculating SQRT

Semantics is a completely different thing - the assignment of "meaning" to symbols. Neither procedural nor behavioral descriptions need to include semantic descriptions.

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 a protocol, state transitions and response messages are specified. Protocols are typically described procedurally, FWIW.

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.

This is like claiming that a protocol is just "bits on the wire", and it is not accurate.

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?

Conduct, intention, and semantics refer to human interpretations of events. Unless a human is part of your protocol stack, they're not relevant.

I agree with AB - these issues aren't relevant to IETF descriptions of protocols.

Joe

<Prev in Thread] Current Thread [Next in Thread>