CUPID

Consortium for University Printing
and Information Distribution

Protocols and Services (Version 1):

An Architectural Overview

Documents, Printjob Orders, Tasks, and Agents

The basic unit of CUPID functionality is called a Printjob Order, several of which may appear in each CUPID Printjob. Through a Printjob Order, a Publisher may designate all of the operations, features, and options required to produce a final-form document at a specified Printshop, including (for example):

• what document is to be printed (indicated as a selection of subdocuments);

• which Printshop is to do the printing;

• how the printing is to be done, including number of copies, binding, paper color, cover stock, etc.;

• what, if any, pre-printing steps are required, such as estimation, proof-copy creation, color selection, etc.;

• how and to whom the resulting output is to be distributed. This also includes, for example, identification of an Agent acting as the immediate recipient of the document (such as the campus store or the library) as well as distribution lists of ultimate Customers (for example, a list of journal subscribers);

• how payment is to be collected, including Job Accounting (payment to the Printshop for work performed) and Customer Accounting (collected by a designated Agent on behalf of the Publisher, and which may include royalty payments). This is discussed further in Section 7;

• what step(s) may not proceed until some previous step(s) have been explicitly evaluated and certified by some authorized Agent and, for each such case, the identity of the authorized Agent (e.g., the final print run must wait for approval of a proof copy).

A Printjob Order contains a Header (see below) and the following two items (among others):

• a single Document, composed of a designated sequence of Subdocument Files;

• a set of one or more Tasks, called a Task List, where each Task specifies:
  • a CUPID Operation

  • an Object

  • Operation Specifications

  • an Agent

  • a Prerequisite Task List.

  Of the above items, all but the CUPID Operation are optional. That is, a CUPID Task must specify an Operation, and may in addition specify any or all of the other four elements.

The Printjob Order Document is represented as a Publisher-specified sequence of zero or more of the Printjob's Subdocument Files. It is legitimate for a particular Subdocument File to appear in this list more than once. The most likely CUPID Printjob Order will simply request the production of some number of copies of the Document. To support requests involving less than the complete Document (such as for proofing purposes), arbitrary lists of Subdocument Files may also be used as Objects of Operations, as described below.

The CUPID Architecture design allows all lists of Subdocument Files to be represented as sequences of integers. Each integer would be interpreted as the index into the sequence of Subdocument Files in the current Printjob, all of whose Subdocument Files reside on a single Origination Server. This design allows the CUPID Architecture to expand easily by generalizing the definition and use of Subdocument Files. For example, in the next Version of CUPID, Subdocument Files might be redefined to be (optionally) pointers to Subdocuments, rather than the actual contents of the Subdocuments. These pointers might refer to files outside of CUPID, and might also include keys or other access-control information. Such a generalization would facilitate CUPID's inclusion of the "pull model".

The Task List in a CUPID Printjob Order specifies the activities that the Publisher wishes the Printshop to carry out, any sequencing relationships among the activities that the Publisher wishes to impose, and all other details related to these activities. Each Task in the Task List identifies one such activity, called a CUPID Operation. Examples of CUPID Operations include "provide estimate", "print", "prepare proof", and "distribute output". The full set of CUPID Operations is given in the CUPID detailed-design document.

In addition to all of the pre-defined, built-in CUPID Operations, the Architecture allows for application-specific Operations, whose meaning has been separately negotiated by the relevant Parties, but whose semantics are unknown to the CUPID System. These application-specific Operations will be generated and interpreted by a compatible suite of Publisher, Printshop, and Agent Clients that are tailored to a particular application. The purpose of these application-specific Operations is to allow CUPID to transmit Tasks whose meaning is unknown to CUPID; responsibility for validation is left to the application-specific Clients. If, for example, the pre-defined CUPID Operations did not include "fan-fold", a suitably constructed pair of Publisher and Printshop Clients could provide for fan-folding as an application-defined Operation.

Some CUPID Operations require an Object, which is either the Complete Document or else a list of Subdocument Files. Some Operations require (or allow) a set of Operation Specifications (Opspecs), such as deadlines, printing instructions, or a list of recipients for distributed output. Examples:

• Operation: Print Proof
  
  Object: Subdocuments 2 and 5
  Opspecs: [optional; omitted]

• Operation: Print
  
  Object: Document
  Opspecs: 20 copies; stitch left; light-blue legal-size paper; delivery required by November 30, 1992

• Operation: Deliver
  
  Object: Document
  Opspecs: {list of Customer names and addresses}

• Operation: Bill
  
  Opspec: 123456789 (Publisher's account number)

The CUPID detailed-design document indicates which Operations require Objects and which require and allow Opspecs, and also describes the content of all Opspecs.

Some Operations require (or allow) an Agent, which is generally a person or other entity designated either to carry out the Operation or to certify that the Operation has been satisfactorily carried out. Examples:

• Operation: Approve proof
  Agent: John Smith (local Publisher's Rep)

• Operation: Charge customers
  Opspec: $0.20/copy
  Agent: Cornell Campus Store

• Operation: Collect royalty payments
  Opspec: $0.01/copy
  Agent: University of Michigan Library System

For each Operation, the CUPID detailed-design document indicates whether an Agent is required or optional and the relationship of the Agent to the Operation.

So as to allow the Publisher to indicate that certain Operations may not be performed until other Operations have successfully completed, each Task in the Task List may optionally include a Prerequisite Task List (PTL). Impossible sets of PTLs and other PTL-related inconsistencies will be recognized by the Origination Server, causing rejection of the associated Printjob. CUPID will refuse to record a Task as "complete" until all of the Tasks in its PTL have been so recorded.

While PTLs allow the Publisher to impose certain constraints on Task sequencing, the CUPID System itself "knows" that some sets of Operations can only reasonably take place in certain sequences. Thus, for example, if a Task List contains both "prepare proof" and "print" Operations, CUPID will not permit "print" to be marked complete until "prepare proof" has been so marked.

The Printjob Order Header contains a unique CUPID Printjob Order Number (CPJON) which, like the CPJIN, is generated and assigned by the Origination Server at the time the Printjob is submitted. The CPJON is simply the CPJIN suffixed by an integer indicating the index of the Order within the Printjob. As with the CPJIN, it is presumed that all internal CUPID Order-related communication will use the CPJON as key. The Printjob Order Header duplicates the Printjob-identifying information from the Printjob Header (Publisher ID, date and time submitted, job name), and also contains these additional items:

• Printshop ID

• Order Name (used for Publisher identification purposes)

• Scheduling, priority, and/or deadline information

• Authorization codes, if any (i.e., authorization codes defined and known by the Publisher and the Printshop outside of CUPID, by virtue of separate contractual or other arrangements)

• General free-text comments (intended to be seen by all Parties working on this Order)

---

	Developed & Maintained by: webmgr@cni.org	© 2008 Coalition for Networked Information ALL RIGHTS RESERVED.
Any comments, or feedback?		Last Update:   Wednesday, 03 July, 2002 - 04:22 PM - EDT