CUPID

Consortium for University Printing
and Information Distribution

Protocols and Services (Version 1):

An Architectural Overview

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 Section 7).

• 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 maps CUPID Printshop IDs into the DNS (Domain Name System) name of the Notification Server on which the Printshop's Printshop 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 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 (Section 4), 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.

---

	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