Subject: Re: Protocol Definition

From: Alessandro Vesely <[email-masked]>
Date: Mon, 18 Jun 2012 12:30:58 +0200

On 5 Jan 2012, todd glassey <[email-masked]> 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?

---

From: Joe Touch <[email-masked]>
Date: Mon, 18 Jun 2012 15:44:25 -0700

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

> 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

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

> 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

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 19 Jun 2012 13:19:58 +0200

On Tue 19/Jun/2012 00:44:25 +0200 Joe Touch wrote:
>> one can give a full description (or coding) of, say, sqrt, without
> 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.
> 
> Semantics is a completely different thing - the assignment of
> "meaning" to symbols. Neither procedural nor behavioral descriptions
> need to include semantic descriptions.

We agree that including semantic descriptions is optional.  But what
is better?  For SQRT, I'd hold that a short, crispy reference to the
theoretical background may be useful and wouldn't harm.  For the
general case, I'm not sure.

> In a protocol, state transitions and response messages are specified.

When they're part of the protocol proper, they are specified indeed.
Policy tweaks, however, live in some limbo.  For example, recursion
for DNS, access restrictions for HTTP, ADSP for SMTP.  Specifications
can hardly discuss such topics.  If they do, they get criticized for
interfering with deployment.  In addition, as policies typically
involve subjective considerations, it is quite rare to gather rough
consensus on any specific advice about them.

> Protocols are typically described procedurally, FWIW.

Yes.  And quite often a procedural description is the most accurate
way to reverse engineer the actual meaning of a message.  Policies
don't enjoy such practice.

>> 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.

Well, it is not accurate to assume full knowledge about the policies
and their consequences.  Let me try and express that better below.

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

Besides development, humans typically configure some implementations
of one or more protocols.  That is what makes protocols run, so it has
to be relevant to us.  Hostmasters who carry out that task are skilled
staff.  However, they have to infer the exact meaning of a policy
token by the wording of its definition and/or by trial and error,
neither of which seems to be formally adequate to me.  What am I missing?