E.3 Processing Models

The paper-oriented and protocol-oriented perspectives have very different views on what is likely to happen to an object.

E.3.1 Amount of Processing

PAPER: The model involves a quasi-static object similar to a piece of paper. With pieces of paper, you simply transfer them as a whole, from one storage area to another, or add signatures, date stamps, or similar adjuncts. (Possibly, you might want an extract from a document or seek to combine multiple documents into a summary, but that isn't the common case.)

PROTOCOL: The standard model of a protocol message is as an ephemeral, composite, multilevel object that a source process creates and that a destination process consumes. The source process constructs such a message from information contained in previously received messages, information stored locally, local calculations, and so on. It is normal for complex processing to take place.

E.3.2 Granularity of Processing

PAPER: The paper point of view generally focuses on uniform processing or evaluation of the entire object being specified. There may be an allowance for attachments; if so, they would probably take the form of simple, one-level, self-documenting attachments.

PROTOCOL: Processing is complex and almost always affects different pieces of the message differently. Some pieces may be intended for use only by the destination process and be extensively processed there. Others may be present so that the destination process can, at some point, do minimal processing and forward them in other messages to yet other processes. The object's structure can be computationally rich and have multilevel or recursive aspects. Because messages are processed in context, you can have things like a single signature that covers the combination of some data in the message, some received in previous messages and stored, and some locally calculated data.

E.3.3 Extensibility of Processing

PAPER: Individuals with a paper point of view rarely think of extensibility as a complex problem. They assume that their design, perhaps aided with a simple version scheme, will meet requirements. If they come from an SGML/DTD or similar world of closed private document preparation systems, they may assume that detailed knowledge of new versions or extensions can be easily and synchronously distributed to all participating sites.

PROTOCOL: Individuals with a protocol point of view assume that all protocols will need extension and that it will not be possible to update all implementations at the same time when deploying and/or retiring such extensions, if ever. This problem can prove difficult, but those taking the protocol perspective try to provide the tools needed, such as the following:

• Carefully defined versioning and extension/feature labeling

• The ability to negotiate version and features, where practical, and at least a specification of how parties running different levels or features should interact

• Providing length/delimiting information for all data so that the data can at least be skipped if not understood

• Destination labeling so that a process can tell when it should ignore data except for passing it through to a later player