Consortium for University Printing and Information Distribution (CUPID)
ABSTRACT
The Consortium for University Printing and Information Distribution (CUPID) is sponsored by the Coalition for Networked Information (CNI), as an open consortium of Universities, supporting the development of distributed, high quality networked print services.
This document proposes an architectural framework for the initial set of CUPID protocols and services, to support a range of applications. The framework is the basis for detailed functional and programming specifications.
INTRODUCTION
CUPID (Consortium for University Printing and Information Distribution) is an informal and open consortium of universities interested in the distributed printing over the Internet of finished, high-quality production documents.
CUPID is concerned with the support and management at remote sites of most or all of the services performed by the production printshop or central reprographics organization of a college or university. Achieving this objective will depend upon the widespread availability of advanced-function, networked printers such as the Xerox Docutech or the Kodak Lionheart, although distributed applications may also make use of lesser-function networked printers.
CUPID has set itself a primary task of defining a suite of protocols and services that can be used as the core and foundation for a variety of applications (see Figure 1). The objective is not to develop software that can support an entire application. The objective is to extract from these applications that which is common (termed the “Common or Generic CUPID Infrastructure”), so as to avoid duplicate and costly development and to encourage the use of shared and open protocols. Applications developers will be encouraged to make use of these protocols and services. CUPID protocols define the interface between application-specific functions and generic CUPID services.
This document proposes a general architectural framework for the initial set of CUPID protocols and services, to be used as a basis for the further development of detailed functional specifications and programming specifications. Where there can be no confusion in this document, we use the term “CUPID” to mean the Consortium itself or interchangeably the suite of CUPID protocols and services.
CUPID APPLICATIONS
The following are examples of CUPID applications:
- A scholarly journal publisher who wishes to distribute a print journal electronically for local printing by site licensees.
- A textbook publisher who wishes to adopt the same model allowing local printing by campus stores of all or parts of a textbook.
- An author who wishes to distribute his/her monograph directly, bypassing traditional publishing channels.
- A university press that wishes to use electronic channels for distribution of printed material. This could include, for example, the distribution of Harvard Business School case studies.
These and other examples all have common needs, including (a) the network delivery of print-ready electronic documents (b) the authorization of who is to print or distribute finished documents (c) the communication of information as to how the documents are to be printed and distributed, including the steps of proofing and estimating, and (d) the support of certain business functions such as payment for printing services and the specification and collection of royalties or other fees. Other functions that are required include support for security and for conversion of document formats. CUPID aims to provide the protocols and services necessary to support these common functions.
Electronic versus Print, Push versus Pull
Version 1 of CUPID focuses on the electronic distribution of documents that are ultimately intended to be printed, and printed in finished form. The Consortium believes that although an increasing number of documents will be distributed that are primarily intended for electronic viewing at the workstation with printing being an incidental side activity (such as printing a few pages at a local laser printer), the need will remain the need for production printing of many documents where the publisher wants to control the total appearance of the finished product. Nevertheless, many of the features of CUPID protocols and services may also apply to the delivery of electronic documents for viewing at workstations.
Version 1 of CUPID also focuses on the “push” model of operation, in which it is the publisher who initiates a request for production of a document. Subsequent versions of CUPID will also support the “pull” model, sometimes known as “print on demand.” In the pull model, a request is initiated by someone other than a publisher, perhaps a printshop or a customer. The key distinction between push and pull is the relationship between the initiator of a print request and the documents being printed. In the push model, the initiator (the publisher) owns or controls the documents, and presumably has direct access to them. In the pull model, the initiator generally must acquire rights and/or access to the documents via some mechanism defined by the documents’ owner(s). Again, much of the Version 1 CUPID services and protocols will apply equally to both push and pull models, and the architecture is designed to allow reuse of these common elements. See Section 6 for further discussion of how Version 1 can be extended to the pull model.
SUMMARY OF THE CUPID ARCHITECTURE
CUPID defines three types of Parties who interact over the Internet with two types of CUPID Servers. The CUPID Parties are Publishers, who initiate requests for document production; Printshops, which produce and deliver the finished documents; and Agents who, on behalf of Publishers, perform or certify the performance of various actions. The requests for document production include, among other items, the contents of all documents to be printed and are termed CUPID Printjobs.
The CUPID Servers are Printjob Origination Servers (or, for short, Origination Servers), which receive CUPID Printjobs from Publishers and maintain the state of those Printjobs; and Printshop Notification Servers (or Notification Servers), which hold information about one or more Printshops and receive notification of Printjobs submitted for printing at those Printshops.
CUPID Parties communicate with CUPID Servers by means of special CUPID Clients. “Client” is used here as in the phrase “Client/Server Architecture.” The ultimate recipients of CUPID documents, on the other hand, are termed “Customers” in the CUPID Architecture (see Section 2).
CUPID Servers provide a set of generic services which are available to all CUPID applications. These services constitute the Generic CUPID Infrastructure. CUPID Clients, on the other hand, provide Application-Specific Functions, tailored both for the type of Party and for a particular application. Thus, one Publisher might use a Client specially written for the application of printing monthly journals at multiple locations, while another Publisher might use a Client customized for the production of multiple versions of a single publication at a given site. Some Publishers might use both of these Clients, or perhaps a single Client written to handle a variety of applications.
The relationship between CUPID Parties, their Clients, and CUPID Servers is shown in Figure 2.
The remainder of this document describes the CUPID Architecture, including the most important CUPID services, the Parties to these services, and the CUPID Servers that provide the services. It also describes the structure and some of the content of the protocols that will be used to communicate between CUPID Clients and CUPID Servers (CUPID Exterior Protocols) and among the CUPID Servers themselves (CUPID Interior Protocols). This document is not, however, intended as a complete or detailed description of either the CUPID services or protocols. That task is left to the CUPID detailed-design document, which defines all protocols and services at the level necessary to allow independent developers to build CUPID Clients and CUPID Servers that interact with each other in a transparent fashion.
The CUPID Architecture defines three generic Parties directly associated with CUPID services: Publishers, Printshops, and Agents. Different CUPID services are available to each Party.
The names of these three Parties are quite generic in the CUPID context and are used in the broadest possible sense. A Publisher, for example, could be a researcher who wishes to cause a report she has authored to be printed at a number of different universities.
Customers, to whom printed documents are ultimately delivered, are considered to be indirect Parties to CUPID services. The names and addresses, for example, of Customers may be passed to CUPID by the Publisher’s CUPID Client for subsequent use by Agents. This limited recognition of Customers applies only to CUPID Version 1. Subsequent versions may also extend direct services to Customers.
In more detail, the CUPID Parties are:
- Publishers, who use application-specific Clients to create CUPID Printjobs and place them on CUPID Origination Servers. A Publisher is the creator, originator, or owner of the document to be printed and subsequently delivered to Customers. In Version 1, CUPID presumes that the Publisher owns (or has been assigned) any rights required by the Printjob (but see the section below on future extensions)
- Printshops, which print documents on (usually) high-performance production printers attached to printer servers, and perform other activities as specified in Printjobs, including delivery of finished printed documents. The printers and printer servers are not themselves part of CUPID. Instead, Printshops use one or more customized Printshop CUPID Clients to interact with both the generic CUPID Servers and with the local printers and printer servers (see Figure 2). The CUPID Architecture allows Printshop systems to be organized in a variety of ways. A single program, for example, might perform all the Printshop’s CUPID Client functions and also act as the printer server. Alternatively, several programs running on several computers might act as specialized CUPID Clients, communicating with a printer server running on yet another host.
Each CUPID Printshop is associated with a single Notification Server which contains a Printshop Specification Record for that Printshop. A Printshop Specification Record contains a unique CUPID Printshop ID for the Printshop and all relevant information about the Printshop’s capabilities.
The main function of the Printshop Specification Record is to ensure that the Publisher is not requesting services of a Printshop that it cannot provide, or cannot provide at the desired level of quality. The Printshop Specification Record includes such information as which PostScript fonts (if any) are supported by the Printshop, the TRC (Tone Reproduction Curve) characteristics of the Printshop’s printers, and any special production capabilities of the Printshop. For example, a given Printshop might not offer a “heatset binding” option, in which case the Publisher may wish to select a “stapling” option instead.
The Printshop Specification Record also contains any relevant standard pricing information the Printshop wishes to advertise, current lead times for common types of operations, and so forth.
A CUPID Printjob received by an Origination Server specifies one or more Printshops to print a document by indicating the Notification Server that contains the Printshop Specification Record associated with each required Printshop. It does so by specifying the CUPID Printshop ID. This requires that a CUPID Address Map (which could, in future versions of CUPID, be an X.500 directory or some similar database) be maintained at one or more known Internet locations that map CUPID Printshop IDs into the DNS (Domain Name System) name of the Notification Server on which the Printshop’s Specification Record is located. Printshop registration thus consists of two steps: placing a Printshop Specification Record on a CUPID Notification Server and updating the CUPID Address Map. Such registration and indirect addressing allows, for example, a Printshop to relocate to a different Notification Server without rendering obsolete the Publishers’ existing Clients that create Printjobs referring to that Printshop.
- Publishers Agents (or just “Agents”), which are third parties performing requested activities on behalf of a Publisher. Agents are individuals (or individuals acting for institutions) who operate according to specifications within a Printjob, either carrying out designated activities (such as delivering documents or collecting fees) or certifying that other activities have been carried out satisfactorily (such as by approving page proofs). A single Printjob may refer to multiple Agents, specifying which activities are to be performed by which Agents. A given Agent may perform on behalf of several Publishers, and a given Publisher may utilize the services of a variety of Agents.
An Agent for a given activity, for example, could be a campus bookstore distributing documents on behalf of a commercial publisher, or a university press acting on behalf of another university press. An agent could also be an academic department, such as a business school that has entered directly into a contractual relationship with, say, the Harvard Business School for local distribution of Harvard Case Studies. A publisher could be a commercial publisher, a university press, or even an individual faculty member publishing directly across the Internet with the assistance of CUPID.
Conceivably a Publisher’s Agent for a given activity could be the Publisher itself. A Publisher’s Agent could also be the Printshop itself. However, when a Publisher or a Printshop is acting as an Agent, they are acting in a conceptually separate role. It is also conceivable that the Agent and the Customer could be one and the same, but again are considered logically separate for purposes of defining CUPID. In future versions of CUPID, “Agent Specification Records” may be added to the Architecture, analogous to Printshop Specification Records, that “advertise” the capabilities of registered CUPID Agents.
Because the CUPID Architecture provides for authentication of the Parties to a Printjob, all CUPID Parties must be registered within the scope of the authentication system chosen. Registration for purposes of authentication is conceptually distinct from the registration of CUPID Printshops already discussed. The current proposals for Privacy Enhanced Mail, as described in Internet Draft RFC’s 1113-1115, provide a framework for CUPID’s authentication-oriented registration requirements. Independent of any registration(s) required by the CUPID Architecture, it is anticipated that all CUPID Parties–Publishers, Printshops, and Agents–may need to have contractually or otherwise previously defined relationships outside of CUPID.
CUPID Servers
The CUPID Architecture defines two kinds of Servers: Origination Servers and Notification Servers. These terms refer both to the software (in UNIX terms, the daemons) that provides the specified services and to the computers upon which this software is running. A single computer could, of course, operate as both an Origination Server and a Notification Server.
Communication with and among CUPID Servers utilizes a reliable byte-stream protocol such as TCP/IP as a transport mechanism. In a TCP/IP-based implementation, for example, Origination and Notification Servers would operate on separate designated Ports, which would be registered with the Internet Engineering Task Force. As Internet protocols evolve, CUPID will continue to operate on whatever new transport layer emerges. It is also likely that the CUPID Architecture will prove readily implementable on proprietary networks.
Almost all CUPID activity is centered around the Origination Server. CUPID Notification Servers exist solely as a means for CUPID Printshops to register their capabilities and to receive notification of incoming work.
Version 1 of CUPID does not provide for a wide-area directory of CUPID Printshop capabilities other than what can indirectly be obtained through the CUPID Address Map (see section above on parties). Future versions of CUPID may utilize emerging network information services to “advertise” the identities of CUPID Printshops over the Internet. Such a service will allow Publishers to “shop around” for Printshops that provide the facilities required for a particular Printjob at acceptable terms.
CUPID will evolve over time. CUPID protocols, however, will be defined so that Clients and Servers using different levels of the protocols will be able to interoperate to the greatest degree possible.
Communication among CUPID Servers and Clients assumes that the daemons responsible for Origination and Notification Servers are constantly running, but that a particular Client may or may not be operating at any point in time. Server-to-server communication, using CUPID Interior Protocols, is thus straightforward (but see below). For Client-Server communication, using CUPID Exterior Protocols, there are two cases: Client-initiated and Server-initiated. In the case of Client-initiated communication, the Client typically connects to the Server, requests information and/or issues commands, and eventually disconnects. Because the Client can assume the Server is always accessible, no special provisions are needed. On the other hand, when a Server, wishes to initiate communication with a Client (in order, for example, to inform a Publisher that part of a Printjob has completed), it is possible that the relevant Client is not currently running or not connected to CUPID. Such communication needs are managed by associating a CUPID Message Queue with each Printjob. The Message Queue resides on the Origination Server for that Printjob, and accumulates Messages related to the Printjob that are targeted for the Publisher, the Printshop, and any Agents referenced by the Printjob. A Client connecting to a Server may request the accumulated messages for the appropriate Publisher, Printshop, or Agent. Future Versions of CUPID may allow Publishers, Printshops, and Agents to be notified via electronic mail that one or more CUPID messages are waiting.
Although it is assumed that Origination and Notification Servers are constantly running, network interruptions and other instabilities may temporarily disable communication with a given Server. Each Server and Client must therefore be prepared to find that any other Server is inaccessible at any moment. The amount of time allowed for recovery in such situations will be left to developers, along with issues of how such time limits may be configured by CUPID system administrators and users.
CUPID SERVICES
To initiate CUPID activity, the Publisher’s Client creates a CUPID Printjob and places it on a CUPID Origination Server. Each Printjob specifies a series of activities, or tasks to be performed at one or more CUPID Printshops, and also includes the contents of any documents referenced by those Tasks. After placing the Printjob on the Origination Server, the Publisher’s Client will, in general, disconnect from the Server.
For each CUPID Printshop referenced by the Printjob, the Origination Server informs the Printshop’s CUPID Notification Server that a Printjob is ready. The Printshop receives this notification either immediately (if its Client happens to be online to the Notification Server at the time) or when it next connects. In either case, the Printshop then uses its Client(s) to interact with the CUPID Servers to execute the Tasks. The Printshop’s Client retrieves the specified document(s) from the Origination Server and directs the document(s) to the appropriate printer server. The CUPID Architecture neither requires nor prohibits the caching of text, images, or other information at locations other than the Origination Server. This is an implementation consideration. The Architecture does require, however, that any such caching must be invisible to all Clients and must not violate any of CUPID’s security provisions.
Some Tasks are directly performed by the Printshop, and some by an Agent; others are performed by the Printshop and certified by an Agent. As each Task is performed and/or certified, the Printshop or Agent uses its Client to notify the Origination Server what has occurred. The Origination Server maintains a Message Queue for the Printjob, and these Messages are available to the Publisher’s Client when it next connects to CUPID (or, if it remains constantly connected, in real time).
To carry out the process summarized above, CUPID Servers provide the following services (among others):
- Workflow Management Services.. These services begin with interactions between the Publisher’s Client and the CUPID Origination Server (resulting in the creation of a CUPID Printjob on that Server); continue by informing the Notification Server(s) that a Printjob is available; and conclude with the removal of the Printjob and all associated control information from the Origination Server at some defined interval of time following completion of all Printjob Tasks.
CUPID controls the flow of the Printjob in at least the following ways: The Origination Server maintains the status of the Printjob, including indications of which Tasks have been completed. This status can be queried by the Publisher, Printshop, and appropriate Agents, and forms the basis for CUPID to present a list of “next possible tasks” to Printshops and Agents. CUPID also ensures that no Task may be marked as complete until any prerequisite Tasks have been so marked.
Part of CUPID’s Workflow Management Services is a facility by which any of the Parties to a Printjob may send a free-text message to any other Party to that Printjob. An option on each such message is the requirement that all CUPID processing on the Printjob be suspended (at the next reasonable breakpoint) until an answer is received and the Printjob is “released” by the sender of the original message. Such messages may also be used by a Publisher to cancel a Printjob, although it should be noted that CUPID cannot guarantee the response time to such cancellation requests.
Yet another feature of CUPID’s Workflow Management Services is maintaining (on the Origination Server) a log of all activity related to the Printjob, complete with timestamps. This log may be examined by the Publisher (and, to a limited extent, by other Parties) during the progress of the Printjob and may be archived by the Publisher as a permanent audit trail. The log may also be used for system recovery purposes (see System Services below).
- Authentication and Access Control Services. CUPID Servers will have the ability to authenticate the identity of Publishers, Printshops, and Agents. CUPID Servers will also authenticate each other. CUPID limits all Parties and Servers to only those activities each is permitted to carry out.
- Encryption Services. Within CUPID, all Client-Server and Server-Server communications will be end-to-end encrypted, using a suitable public- or private-key system. One particular encryption system will be selected and described in the CUPID detailed-design document. CUPID Origination and Notification Servers will offer the option of storing local information in encrypted form as well. The need for local encryption will depend on whether a particular CUPID Server is under the complete administrative control of the relevant Party or is, instead, a shared system. As a general design goal, CUPID provides the ability to ensure that all information related to the CUPID System–including the contents of all documents–is secure while under CUPID control.
- Validation Services. CUPID ensures that all Server-Server and Client-Server communications conform to CUPID requirements. CUPID also ensures that Printjobs do not request services from Printshops which those Printshops cannot perform (based on the Printshop Specification Records stored on CUPID Notification Servers).
- Document Assembly Services. Publishers are provided the ability to submit documents in parts (called Subdocuments) for assembly into one or more finished products. This facilitates, for example, the submission of a single Printjob to produce a variety of documents which differ among themselves only in their cover text, or the production of “personalized journals” based on customers’ registered areas of interest.
- Image Conversion Services. CUPID provides for the conversion of various document image file formats and compression algorithms to standard CUPID file formats and compression algorithms (see section below on printjobs). This conversion is performed by the Origination Server at the time of Printjob submission. No further conversion or reconversion services are provided by CUPID. This implies that applications that make use of CUPID, or Printshops themselves, are responsible for any further conversion required to print CUPID Documents on a given printer.
- System Services.. CUPID provides for server backup and recovery; audit trails; capacity (local site limits pertaining to a particular Server) control, including local duration and size storage limits placed on the temporary storage of documents and other CUPID files; version control of the CUPID software itself; standards control; and other system administration functions.
CUPID PRINTJOBS
A CUPID Printjob includes (among other things) the following elements:
- An ordered sequence of zero or more Subdocument Files, each of which is a self-contained and printable Subdocument. The case of zero Subdocuments anticipates, for example, a Printjob whose only purpose is to obtain an estimate based on page count and other Printjob specifications that are independent of the contents of the document(s) that will eventually be printed.
The acceptable formats for CUPID Subdocument Files are:
One or more Printjob Orders(also called Orders). Each Order asks that a single CUPID Printshop carry out a set of Tasks, resulting in the printing of a single Document. (Orders, Documents, and Tasks are described in more detail below.) The different Orders in a given Printjob may specify different Printshops and different sets of Tasks. When a complete Printjob has been placed on an Origination Server, CUPID so informs the Notification Servers associated with all of the Printshops referenced by Orders in that Printjob.
- – TIFF, optionally compressed with either CCITT Group 3 or Group 4 (using the recently-adopted IETF image format standard); and
- – PostScript Level 1 or Level 2,
- – For CUPID Version 2, support for SGML-encoded documents may be added.
It is not required that all of the Subdocument Files be of the same format, but each must be in print-ready (rather than make-ready form, and each must be self-contained and self-defining. Additional information about the nature of the File (such as its optimal Tone Reproduction Curve) may optionally be included. In the case of Files in PostScript format, CUPID takes note of the fonts used and verifies (by means of the Printshop Specification Record) that these fonts are, in fact, supported by the target Printshop.
The above two Printjob components are created and placed on the Origination Server by the Publisher’s Client. In addition, the CUPID Origination Server itself creates and maintains Printjob-related information, including:
- Status Information, indicating the progress of the Printjob as a whole, as well as the progress of each Printjob Order;
- A Message Queue, containing messages transported by the CUPID System which are to be delivered to CUPID Clients operated by Publishers, Printshops, and Agents. These messages may be generated by internal CUPID System activity, or may result from interactions with application-specific Clients.
Notification Servers are informed that a Printjob has been submitted only when the Printjob is complete on the Origination Server (in particular, all Subdocument Files must be present) and when all CUPID validity checks and conversions have been successfully performed (including confirming that there is a match between the requested operations and the capabilities at the target Printshop(s)). The Printjob remains on the Origination Server for some amount of time after all Printjob-related activity has been completed (that is, all Printjob Tasks have been completed), although the Publisher may explicitly purge a Printjob or have its retention period extended.
As with all other CUPID Printjob components, the Status Information related to a CUPID Printjob resides on the Origination Server. Status changes are recorded by the Origination Server based on information and commands received from Notification Servers and from CUPID Parties (via their Clients).
A CUPID Printjob also includes a Header, which contains a unique CUPID Printjob Identification Number (CPJIN) which is generated and assigned by the Origination Server at the time the Printjob is submitted. It is presumed that all internal CUPID Printjob-related communication will use the CPJIN as key. The Printjob Header also contains the following items:
- Publisher ID;
- Date and time submitted;
- Job Name, used for Publisher identification purposes, not necessarily the same as the Document title;
- Job Limits (optional), used to extend or reduce the default Printjob retention period on the Origination Server;
- Security Keys (if and as required);
- General free-text comments, intended to be seen by all Parties working on this Printjob.
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 the section below on future extensions;
- 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 predefined, 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 predefined 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 been 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); and
- General free-text comments (intended to be seen by all Parties working on this Order).
FUTURE EXTENSIONS TO PERMISSION AND PAYMENT SERVERS
CUPID Version 1 offers only rudimentary capabilities to support such business functions as granting permissions and payment of royalties. These and related functions are assumed to be performed “out-of-band.” Version 1 does support the transmission of information related to these functions via the appropriate Task definitions, but does not provide any control mechanisms.
Version 1 does lay the necessary groundwork, however, for extensions to support these business functions. As we have noted, extending Version 1 from the “push” model to the “pull model” mostly consists of replacing Subdocument Files located in Printjobs on Origination Servers by pointers to those Subdocument Files wherever they may be located outside of CUPID. However, these pointers could just as well be to “permission servers” that perform gatekeeping functions and in turn contain pointers to the Subdocument Files that they control. They can also point to corresponding “terms and condition servers” that contain business-related information on the payment and other conditions governing the printing of the associated Subdocuments. Finally, in conjunction with information contained in the Printjob Order, they can also point to designated “payment servers” that can cause the specified royalties or other payments to be charged to particular Customer accounts.
These functions are all kept separate to allow for greater generality. For example, one clearinghouse may be able to clear a given set of Subdocuments in a manner defined by its permission server and terms-and-conditions server. The same set of documents could also be cleared by another clearing house through a different permission server and terms-and-conditions-server. The particular payment server defined will normally depend upon both the clearinghouse (which could be the Publisher) and on the particular customer being charged.
It is likely that a server containing Subdocuments can contain pointers to the permission servers that can “clear” those documents.
The precise definitions of and architectural relationships among these server concepts are beyond the scope of this Version 1 overview. However, the foregoing sketch is consistent with Version 1 and the detailed extensions should not be overly complex.
APPENDIX 1
SUMMARY OF CUPID PRINTJOB ELEMENTS
The outline below summarizes the elements of a CUPID printjob. It does not specify the format, sequence, or encoding of those elements. Such issues are left to the CUPID detailed-design document.
In the outline, brackets indicate an optional item. “(s)” indicates an item that may appear 1 or more times (0 or more times if in brackets). “*” indicates an item created and maintained by the CUPID system, rather than by a CUPID party.
Printjob Header [Subdocument File(s)] Status* (includes Status of all Printjob elements) Message Queue* Printjob Order(s) Header [Complete Document] Task(s) Operation [Object] [Opspecs] [Agent] [Prerequisite Task List]
APPENDIX 2
CUPID VISION STATEMENT
What is CUPID ?
In 1990 the Coalition for Networked Information (CNI) was founded by the Association of Research Libraries (ARL), CAUSE and EDUCOM to foster the creation of and access to information resources in networked environments in order to enrich scholarship and enhance intellectual productivity. CNI now has over 150 members, including universities, libraries and technology vendors.
CUPID (Consortium for University Printing and Information Distribution) is a working group of CNI, with members including Harvard, Cornell, Michigan, Princeton, the California State system, Virginia Tech, and Penn State. CUPID members, individually and in collaboration with other universities, libraries, and vendors, are prototyping applications, and developing the architectural framework for CUPID applications.
The Cupid vision
The goal of Cupid is to demonstrate the feasibility of distributed printing at remote sites of finished, high quality production documents. This utility can support a range of functions, including custom text production, personal publishing, networked print on demand services and rare book preservation. For instance, wouldn’t it be nice if…
Custom Text:
- Professor X’s section of English as a Second Language in Harvard’s summer school met for the first time today and conducted a needs assessment in class. Now, at 11 am, Professor X sits down at her workstation to customize her course materials to the class profile. She accesses the ESL database over the University network and browses through sections of interest, scanning on-line sections of a grammar text, associated exercises, and readings from books, magazine and newspaper articles. Using a job ticket pulled down in a screen window, she modifies her earlier grammar selections, adds extra exercises on the use of the subjunctive, and chooses readings to complement class interests. After an hour, satisfied with the materials for the next four weeks, she sends the completed job ticket over the network to the printer at Harvard Copy, with instructions to print and bind 18 copies, with a table of contents, for delivery to the student pick up center by 4 pm.
Distribute then Print:
- Professor Y is teaching a class on business ethics at Alaska State University. From his desktop computer he dials up the Harvard Business School database of cases, searches the catalog of the 7500 titles on-line, and identifies three cases he would like to use. Opening the Cupid job ticket window he orders 50 copies of each case, to be printed and distributed from the ASU bookstore CUPID printer for the start of class in two days.
Rare Book Access:
- A Ph.D. student in San Francisco accesses Cornell University Library on-line catalog. He locates a study published sixty years earlier which is a critical reference for the next chapter of his thesis, due for presentation at the MLA conference next month. The student has neither time nor funds for a trip to Cornell and the book is too fragile for inter-library loan. However, the librarian has a suggestion: the already microfilmed preservation version of the text can be converted to digital form, sent over the Internet to the library at Berkeley and printed and bound there in book facsimile form within 24 hours.
On-Line Journal Articles:
- The most recent issue of a leading science journal has a controversial article on cold fusion, which teaching fellow Z wants to distribute before tomorrow’s lecture in the Dynamics and Energy basic sciences course. The journal has disappeared from the library shelf. From her workstation, she accesses the on-line journal database at MIT, finds the article, and orders 150 copies printed at Harvard Copy for pick up before the 9 am lecture.
Personal Publishing:
- Professor A is editing a Festschrift for the retirement of the department chair. Articles by scholars and former students who now teach at universities worldwide have been circulated for editorial comments over the Internet. The completed volume will be published simultaneously at Harvard, Oxford University, the Sorbonne and St. Petersburg. Professor A assembles the print-ready copy at his desktop, and uses the CUPID application to send it to CUPID printers at each location for distributed publication.
What are the benefits?
The CUPID model promises efficiency and economy in new ways of working with information:
- Lower cost: select and pay for units of text instead of multiple expensive textbooks; potentially cheaper than offset printing.
- High quality: improvement over current class notes assembled from copies.
- Increased productivity: desk-top search, scan, select, assemble and send to print.
- Flexibility: avoid long order lead times; customized texts and class materials for specialized needs; instant adjustment to unexpected class size changes.
- Network access to stored digital information.
Why is CUPID happening now?
CUPID applications are enabled by several current technology developments:
- New digital copier/printers that can:
Networked capability in digital copier technology.
- – accept and store electronic image input;
- – accept and store scanned text or graphics;
- – print at high resolution (up to 600 dpi), or close to off-set printing quality;
- – print at high speed for volume production;
- – collate, finish and bind for single process production.
- Expansion of robust Internet as international connector.
- Proliferation of LAN’s which link desktops to Internet and world-wide networks.
- High end workstations on the desktop.
What else is needed to fulfil the potential of CUPID?
CUPID initiatives also depend on the growth of related technology services:
- On-line
Data base search and management tools: directories, catalogs, key word searching.
- – data bases;
- – copyright clearance and royalty agreements;
- – billing and accounting systems.
- Network standards for information distribution.
How will it work?
The CUPID architecture outlines new Internet engineering standards to define the functional and programming specifications common to CUPID applications:
- Internet-based utility that provides services to enable distributed printing.
- Protocol to send document over network, with job instructions and status information.
- Initial distributed services include: access control; authentication; encryption/decryption; images text conversion; routing; assembly; job status and resource tracking.
- Future services may include: pointers to remote stored documents; end-user desktop assembly of custom documents; print-time merge of component materials; print-time final edit; etc.
Where will CUPID take us?
CUPID is a historic opportunity–The Second Gutenberg Revolution–with the potential to transform traditional modes of publishing.
- Distribute-then-print defines new roles/relations for publishers, bookstores, copy shops, universities and libraries.
- The global scholar: enhanced collaboration and communication
- The author as publisher: individual printing of texts.
- Learning enrichment: the customized text, just-in-time printing.
This paper was prepared for the Coalition for Networked Information by the CUPID Architecture Subcommittee:
Scott Bradner (Harvard)
Robert Cowles (Cornell)
Jim Ferrato (Harvard)
Steve Hall (Harvard)
Tom Head (Virginia Tech)
Ted Hanss (Michigan)
Robert Knight (Princeton)
Clifford Lynch (University of California)
Chair: M. Stuart Lynn (Cornell)
Anne Margulies (Harvard)
Mark Resmer (California State University)
Lawrence Sewell (Virginia Tech)
Carol M. Taylor (Harvard)
Jeff Wooden (Harvard)
Steve Worona (Cornell)