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?