E.2 Questions of Meaning

Human "meaning" is something that the paper-oriented person considers extraordinarily important but the protocol-oriented person rarely thinks about.

E.2.1 Core Meaning

PAPER: The "meaning" of a document is a deep and interesting human question related to volition. The document should typically include or reference human language policy, warranty, or disclaimer information. At an absolute minimum, it must satisfy a requirement for some sort of semantic labeling. The assumed situation is always a person interpreting the whole "paper" without other context. Thus it is reasonable to consult attorneys during message design so that the documents will hold up in court, require human-readable statements "within the four corners" of the paper, and take other similar steps during document creation.

PROTOCOL: The "meaning" of a protocol message is clear from the protocol specification. This specification frequently defines a protocol message in terms of the state machines of the sender and recipient processes; it may have no significant connection with human volition. Such processes have additional context and the message usually appears meaningful only with that additional context. Adding any human-readable text that is not functionally required is silly. Consulting attorneys in design is a bad idea that complicates the protocol and could tie a design effort in knots. Entities communicating with a protocol have already agreed to that protocol specification. Verbiage to support legal action, if any, should appear in that specification, rather than cluttering up messages.

E.2.2 Adjunct Meaning

Adjuncts are things that can be added or are logically addenda.

PAPER: From a paper point of view, at the top level we have the equivalent of a person looking at a document. As a consequence, adjunct items such as digital signatures, person's names, dates, and so on must be self-documenting as to semantics. Thus a digital signature needs to include, in human-readable form, what that signature means; for example, is the signer a witness, an author, a guarantor, or something else? Similarly, a person's name or a date needs to be accompanied, in human-readable form, by an identification of that person's role or the meaning of the date for example, editor, author, or contributor or date of creation, modification, revocation, or distribution. Furthermore, given the unrestrained scope of what can be documented, during the design process, the programmer faces the risk of trying to enumerate and standardize all possible "semantic tags" for each type of adjunct data. This effort can be a difficult, complex, and essentially infinite task (a rat hole).

PROTOCOL: From a protocol point of view, the protocol specification defines the semantics of the message and every adjunct in it. Thus, if the protocol includes a slot for a digital signature, person's name, a date, or whatever, the party that is to enter that data, the party or parties that are to read it, and its meaning are all predefined. Even if several meanings are possible, a separate enumerated type field can specify which particular meaning applies. There is no reason for such a type field to be human-readable. Only the "meanings" directly relevant to the particular protocol need be considered. Another way to look at this issue is that the "meaning" of each adjunct is promoted to the level of the protocol specification, resulting in simpler adjunct data. The paper-oriented point of view encourages pushing the "meaning" of each adjunct into, and coupling it with, the adjunct.