Protocols and Services (Version 1): An Architectural Overview
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.
These objectives support the Consortium's overall goal of encouraging the
development and deployment of distributed publishing applications that nurture
a shift from the traditional "centralized" publishing model of "print then
distribute" to a decentralized model of "distribute electronically then view."
In this context, "viewing" may occur either at the workstation or in printed
form (CUPID concentrates on the latter), and can embrace the just-in-time
concept of "print on demand." The Consortium endorses such a shift to provide
functional and electronic alternatives to the centralized manufacturing model
and its accompanying costs of distribution and inventory, and to reduce the
delays between information creation and consumption, or between information
requests and production.
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.
Parties to CUPID Services
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:
- - 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.
- 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.
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:
- - 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.
- Networked capability in digital copier technology.
- 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 bases;
- - copyright clearance and royalty agreements;
- - billing and accounting systems.
- Data base search and management tools: directories, catalogs, key word
searching.
- 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)
