On Tue 19/Jun/2012 00:44:25 +0200 Joe Touch wrote:
On 6/18/2012 3:30 AM, Alessandro Vesely wrote:
...
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.
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.
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.
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.
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.
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?