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: