CUPID

Consortium for University Printing
and Information Distribution

Protocols and Services (Version 1):

An Architectural Overview

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.

Figure 1: The CUPID Objective

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 de-centralized model of "distribute electronically then view". In this context, "view" may either be at the workstation or in printed form (CUPID concentrates on the latter), and that 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 at providing 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), there 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 that 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 Sections 6 and 7 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.

Figure 2: Schema of CUPID Relationships

---

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