Common Facilities RFP6 Submission · Common Facilities RFP6 Submission Print Facility Xerox Corporation Novell, Inc. ICL High Performance Systems Digital Equipment Corporation January

Common Facilities RFP6Submission

Print Facility

Xerox CorporationNovell, Inc.ICL High Performance SystemsDigital Equipment Corporation

January 19, 1998OMG PTC Document orbos/98-01-05

Copyright 1998 Xerox CorporationCopyright 1998 Novell IncorporatedCopyright 1998 ICL High Performance SystemsCopyright 1998 Digital Equipment Corporation

The companies listed above hereby grant a royalty-free license to the ObjectManagement Group, Inc. (OMG) for worldwide distribution of thisdocument or any derivative works thereof, so long as the OMG reproducesthe copyright notices and the below paragraphs on all distributed copies.

The material in this document is submitted to the OMG for evaluationpurposes only. Submission of this document does not represent acommitment to implement any portion of this specification in the productsof the above said companies.

While the information in this publication is believed to be accurate, thecompanies listed above make no warranty of any kind with regard to thismaterial. The companies listed above shall not be liable for errors containedherein, or for incidental or consequential damages in connection with thefurnishing, performance or use of this material. The information contained inthis document is subject to change without notice.

This document contains information which is protected by copyright. AllRights Reserved. No part of this work covered by copyright here on may bereproduced or used in any form or by any means — graphic, electronic, ormechanical, including photocopying, recording, taping, or informationstorage and retrieval systems — without the permission of the copyrightowners. All copies of this document must include the copyright and otherinformation contained on this page.

The copyright owners grant the OMG permission to reproduce and use theinformation contained in this document. The copyright owners grant alimited waiver of the copyright on this document to members of the ObjectManagement Group so that they can each reproduce up to 50 copies of thisdocument for their internal use as part of the OMG evaluation process.

RESTRICTED RIGHTS LEGEND. Use, duplication, or disclosure bygovernment is subject to restrictions set forth in subdivision (c) (1) (ii) of theRight in Technical Data and Computer Software Clause at DFARS252.227.7013.

All trademarks acknowledged.

Contacts:Jeddy Bernard Van-Si NguyenXerox Corporation Xerox Corporation100 Willowbrook Drive 800 Phillips RoadFairport, NY 14450 MS [email protected] Webster, NY 14580+1 716 264 6923 vansi [email protected]

+1 716 422-3797

Richard Herbert Shriram RevankarICL High Performance Systems Xerox CorporationWenlock Way, 800 Phillips RoadWest Gorton, MS 105-50CManchester Webster, NY 14580M12 5DR [email protected] +1 716 265 [email protected]+44 161 223 1301

Scott Isaacson Rudolf RiessNovell, Inc. Digital Equipment Corporation122 East 1700 South, M/S PRV-D-111 15 Hersam StProvo, UT 84606-6194 Stoneham, MA [email protected] [email protected]+1 801 429 7366 +1 617 279 3260

Paul MurrayBoeing CompanyP.O. Box 3707MS 7L-20Seattle, WA [email protected]+1 425 865 5861

CF-RFP6 Submission - Print Facility orbos/98-01-05 January 19, 1998 i

Table of Contents

1. PRINT REQUIREMENTS OVERVIEW.................................................................................................................1

1.1. PRINTING SUBSYSTEM CAPABILITIES .....................................................................................................................21.1.1. Job Planning and Scheduling .......................................................................................................................31.1.2. Document Preparation..................................................................................................................................31.1.3. Document Decomposition.............................................................................................................................41.1.4. Marking.........................................................................................................................................................41.1.5. Finishing .......................................................................................................................................................41.1.6. Packaging .....................................................................................................................................................4

1.2. SUPPORTING SUBSYSTEM CAPABILITIES ................................................................................................................51.2.1. Resource Acquisition ....................................................................................................................................51.2.2. Monitoring ....................................................................................................................................................51.2.3. Configuration................................................................................................................................................51.2.4. Accounting ....................................................................................................................................................61.2.5. Logging .........................................................................................................................................................61.2.6. Error Recovery..............................................................................................................................................61.2.7. System Administration ..................................................................................................................................61.2.8. Diagnostics ...................................................................................................................................................7

1.3. SYSTEM REQUIREMENTS........................................................................................................................................71.3.1. Interactions ...................................................................................................................................................71.3.2. Scalability .....................................................................................................................................................81.3.3. Service Negotiation.......................................................................................................................................81.3.4. Security .........................................................................................................................................................81.3.5. Globalization and Localization.....................................................................................................................91.3.6. Batch Processing and Spooling ....................................................................................................................91.3.7. Performance and Reliability .........................................................................................................................91.3.8. Document Types............................................................................................................................................9

1.4. BUSINESS CONTEXT...............................................................................................................................................91.5. THE FACILITY CLIENT VIEW ................................................................................................................................10

1.5.1. Print Facility Interface ...............................................................................................................................10

2. PRINT FACILITY ARCHITECTURE ..................................................................................................................11

2.1. CONCEPTUAL ARCHITECTURE.............................................................................................................................112.2. CORBA OBJECT MODEL.....................................................................................................................................13

2.2.1. DocService Object ......................................................................................................................................162.2.2. Interaction Management Objects................................................................................................................16

2.3. ATTRIBUTE SCHEMA............................................................................................................................................252.3.1. Meta Attributes............................................................................................................................................252.3.2. Service Interaction Attributes .....................................................................................................................262.3.3. Generic Attributes.......................................................................................................................................262.3.4. Service-Specific Attributes ..........................................................................................................................26

2.4. EXTERNALIZATION FORMAT — SIL.....................................................................................................................272.4.1. SIL Syntax ...................................................................................................................................................272.4.2. SIL Semantics..............................................................................................................................................31

2.5. EXAMPLE OPERATIONAL SCENARIO.....................................................................................................................322.6. FACILITY SERVICES MODEL.................................................................................................................................33

2.6.1. Document Model.........................................................................................................................................342.6.2. Job and Device Model ................................................................................................................................362.6.3. Capability Model ........................................................................................................................................37

3. OBJECT IDL SEMANTICS....................................................................................................................................41

ii CF-RFP6 Submission - Print Facility orbos/98-01-05 January 19, 1998

3.1. CFDOCSERVICETYPES MODULE .........................................................................................................................413.2. CFDOCSERVICE MODULE DATA TYPES...............................................................................................................433.3. INTERACTION.......................................................................................................................................................463.4. DSITERATOR.......................................................................................................................................................473.5. REQUESTINFO......................................................................................................................................................473.6. QUERYINFO.........................................................................................................................................................493.7. REPORTINFO........................................................................................................................................................513.8. DOCSERVICE .......................................................................................................................................................533.9. URISTREAMFACTORY..........................................................................................................................................55

4. ATTRIBUTE SEMANTICS.....................................................................................................................................57

4.1. ATTRIBUTE DATA TYPES.....................................................................................................................................594.2. META ATTRIBUTES..............................................................................................................................................64

4.2.1. facility-description Context.........................................................................................................................654.2.2. service-description Context.........................................................................................................................684.2.3. document-description Context ....................................................................................................................704.2.4. attribute-description Context ......................................................................................................................724.2.5. constraint-description Context....................................................................................................................75

4.3. SERVICE INTERACTION ATTRIBUTES....................................................................................................................764.3.1. interaction-id...............................................................................................................................................764.3.2. originator ....................................................................................................................................................774.3.3. originator-natural-language.......................................................................................................................774.3.4. originator-charset .......................................................................................................................................774.3.5. interactor.....................................................................................................................................................774.3.6. response-to..................................................................................................................................................774.3.7. interaction-priority......................................................................................................................................784.3.8. interaction-timestamp .................................................................................................................................78

4.4. GENERIC ATTRIBUTES..........................................................................................................................................784.4.1. job-control-operation..................................................................................................................................784.4.2. device-control-operation.............................................................................................................................804.4.3. input-documents..........................................................................................................................................814.4.4. output-documents........................................................................................................................................814.4.5. invocation-condition ...................................................................................................................................814.4.6. job-name .....................................................................................................................................................814.4.7. job-priority..................................................................................................................................................824.4.8. job-hold-until ..............................................................................................................................................824.4.9. notify-events ................................................................................................................................................834.4.10. notify-addresses ..........................................................................................................................................834.4.11. notify-mechanisms.......................................................................................................................................844.4.12. job-originating-user-name..........................................................................................................................844.4.13. job-originating-host ....................................................................................................................................844.4.14. user natural-language.................................................................................................................................844.4.15. user-charset.................................................................................................................................................854.4.16. job-URI .......................................................................................................................................................854.4.17. job-state.......................................................................................................................................................854.4.18. job-state-reasons.........................................................................................................................................884.4.19. job-state-message........................................................................................................................................914.4.20. job-submission-time ....................................................................................................................................914.4.21. job-started-processing-time ........................................................................................................................914.4.22. job-completion-time ....................................................................................................................................914.4.23. number-of-intervening-jobs ........................................................................................................................914.4.24. job-message-from-operator.........................................................................................................................924.4.25. device-URI ..................................................................................................................................................924.4.26. device-name ................................................................................................................................................924.4.27. device-location............................................................................................................................................924.4.28. device-description .......................................................................................................................................93

CF-RFP6 Submission - Print Facility orbos/98-01-05 January 19, 1998 iii

4.4.29. device-more-info-site ..................................................................................................................................934.4.30. device-driver-installer.................................................................................................................................934.4.31. device-make-and-model ..............................................................................................................................934.4.32. device-more-info-manf................................................................................................................................944.4.33. device-state .................................................................................................................................................944.4.34. device-state-reasons....................................................................................................................................954.4.35. device-state-message...................................................................................................................................984.4.36. queued-job-count ........................................................................................................................................984.4.37. provider-state..............................................................................................................................................984.4.38. service-is-accepting-jobs ............................................................................................................................984.4.39. service-message-from-the-operator ............................................................................................................99

4.5. DOCUMENT ATTRIBUTES.....................................................................................................................................994.5.1. document-name (name)...............................................................................................................................994.5.2. document-content (octetstring) ...................................................................................................................994.5.3. document-URI (uri)...................................................................................................................................1004.5.4. document-format (mimeMediaType).........................................................................................................100

Figures and Tables

Figure 1. An example of a print facility implementation configuration ................................................................................2Figure 2. Document preparation stage ..................................................................................................................................3Figure 3. Print facility conceptual architecture ...................................................................................................................12Figure 5. Interface object model .........................................................................................................................................14Figure 6. Interaction information model .............................................................................................................................17Figure 7. Information structure of a general request interaction (boxes indicate information objects) ...............................18Figure 8. An example of the information structure of a request for IPP printing................................................................19Figure 9. Information structure of a general query interaction............................................................................................20Figure 10. An example query of JobStatus in IPP Print Service.........................................................................................20Figure 11. Information structure of a general report interaction .........................................................................................21Figure 12. ‘Attribute schema’ of the Print Facility .............................................................................................................24Figure 13. Job submission scenario ....................................................................................................................................32Figure 14. Document model schematic...............................................................................................................................34Figure 15. Document assembly graph, where document components may be shared and disassembled as desired. This

specification can support all classes of printing facilities. ..........................................................................................36Figure 16. Capability representation structure for the print facility ....................................................................................38Figure 17. Sample configuration of a customer network environment................................................................................39Figure 18. Normal job state transition ................................................................................................................................88

Table 1. The SIL data type syntax...................................................................................................................................30Table 2. Extensibility classes for DSKeyword data types..............................................................................................57Table 3. Attribute data types......................................................................................................................................59

iv CF-RFP6 Submission - Print Facility orbos/98-01-05 January 19, 1998

Purpose and Organization

This document is a proposed standard for a set of Interface Definition Language (IDL)-based Print Facilityservice interfaces. The specification is intended to support the OMG’s central mission to enable distributedintegrated applications, and its primary goal of spawning object-based software components that are reusable,portable and interoperable in distributed, heterogeneous environments.

This specification is organized into the following sections and appendices.

• Section 1 — Print Requirements Overview• Section 2 — Print Facility Architecture• Section 3 — Object IDL Semantics• Section 4 — Attribute Semantics• Appendix A — Glossary• Appendix B — References• Appendix C — CFPF IDL Module• Appendix D — Mapping to IETF IPP

Section 1 provides a high-level discussion of the requirements for a Common Facilities Print Facility as setforth in RFP6. Sections 2, 3, and 4 provide models of the Print Facility that meet the requirements of RFP6.

CF-RFP6 Submission - Print Facility orbos/98-01-05 January 19, 1998 v

Typographical and Illustration Conventions

The following conventions will be used for the remainder of this document.

Typographical Conventions The type styles shown below are used to distinguish programming statements from ordinary Englishand to aid in the readability of programming statements.

OMG Interface Definition Language

Language and syntax elements 10 pt. Courier

IDL declarators and operation identifiers

Programmer-meaningful names, separated byunderscores, all lower case

10 pt. Courier

attribute MyFooTypemy_foo_declarator;orvoid my_foo_operation();

Job/Document Attribute Names

Printing facility attribute names

Programmer-meaningful names, separated byhyphens, all lower case

10 pt. Courier

job-media-sheets-completed

Externalization Format

Externalized-format EBNF syntax (SIL) 10 pt. Times New Roman Italic Bold

Externalized-format (SIL) examples 10 pt. Arial

Illustration Conventions

Object structure diagrams will follow simplified OMT diagramming conventions.

CF-RFP6 Submission - Print Facility orbos/98-01-05 January 19, 1998 1

1.Print Requirements Overview

The print facility is a typical horizontal capability needed by most businessapplications. It is one element of a coordinated set of facilities and standardsneeded to satisfy the printing requirements of the distributed office. Afacility is an entity that facilitates access to and integration of multipleservices. A service, in turn, is a named encapsulation of a collection ofcapabilities such as printing and conversion. A print facility must handleprinting requirements in environments ranging from a single desktop toproduction publishing on many printers.

The print facility proposed in this document supports the OMG vision offreely interoperating, reusable and portable software objects spread acrossthe distributed enterprise that reduce development times, maintenance costs,and program complexity; and enhance capability.

To meet the expanding requirements of the printing industry, the functionalscope and technical boundaries of a print facility must be flexible. Externalpressures are impacting print facility boundaries on the front and back ends.

On the front end, printing systems are being pushed to capture and printdocuments in their native formats. On the back end, printing systems arebeing given an ever-expanding selection of the finishing, packaging, anddistribution options.

In this dynamic environment, a stable model of a print facility is anaddressable entity that provides a growing variety of document handlingcapabilities associated with document transformation (such as printing anelectronic document on paper). Although not required, a print facilityimplementation may handle indirect tasks such as document conversion anddocument assembly, besides tasks directly associated with printing such asdecomposition (preparation for printing), marking (putting the image onpaper), and finishing (collation, binding, etc.).

The proposed print facility must be flexible enough to offer owners theability to configure it to their own needs. Those needs may range from theprinting of a single copy of a print-ready document, to printing multiplecopies of large documents with demanding assembly and finishingrequirements.

Figure 1 illustrates how a print facility interface might be positioned within aprint facility implementation. In the example, the print facility is configuredto support multiple services which together provide the print servicecapability. The print facility client implementation may be catering to ahuman user, or it may be an automated system that uses the print facility forextended capabilities. Therefore, dedicated clients or drivers can’t beassumed in the print facility design. The print facility design should makethe print facility a peer among a collection of automated systems (DirectoryServices, Scanning Facility, etc.).

1

2 CF-RFP6 Submission - Print Facility orbos/98-01-05 January 19, 1998

Facility Client

Print Facility

SupportApplication

TransparentPrint Facility

Data Acquisition

ApplicationPDL

Generator

Facility Spooler

InteractionManagement

Job/PrinterEvents

RequestSubmission Interaction

Management

Job Planning &Scheduling

DocumentPreparation

DocumentDecomposition

Printer

Marking FinishingSE

RV

ICE

OR

CH

ES

TR

AT

ION

InteractionBuilder

InteractionBuilder

Figure 1. An example of a print facility implementation configuration

In the above configuration, the set of tasks carried out by the print facilitysubsystems may appear to the print facility client either as a singlemonolithic capability, or as a collection of integrated but stand-alonecapabilities. In the next few sections, we describe the characteristics of eachof these subsystems.

1.1. Printing Subsystem Capabilities

The basic architecture of a print facility implementation must keep theevolution of individual subsystems from impacting the operation of others.The print facility architecture should allow facility clients to request actionsof the system, effectively hiding individual subsystem interactions; or, ifneeded, allow facility clients to request actions from individual print facilitysubsystems, including:

• Job Planning and Scheduling

• Document Preparation

• Document Decomposition

• Marking

• Finishing

• Packaging

Each of these may exist as separate, optional capabilities within a printfacility.

1


1.1.1. Job Planning and Scheduling

Planning and scheduling are critical for optimizing the performance of aprint facility implementation in a dynamic environment. Typically, clientsrequesting print facility capabilities are insulated from the details of theinternal architecture and processes initiated in response to requests. Printfacility requests amount to specifications for the desired output documents.

A sophisticated system will be able to reconfigure itself to deliver thedesired results in the shortest time possible, while minimizing costs. Becauseprint facility implementations may handle several requests simultaneously,managing control flow topology is essential to ensure that jobs are handledaccording to priority, with minimal operator intervention. The output of thejob planning and scheduling subsystem shall be a “scheduled job” for a printfacility implementation.

1.1.2. Document Preparation

An essential task of document preparation is to transform the document intoa data stream compatible with the document decomposer (a subsystem thataccepts the electronic document and formats it for the print engine). Becausethe document preparation subsystem receives the incoming document, itimpacts the connectivity of the system (i.e., the degree to which the systemcan operate in an open environment). Connectivity is improved if thedocument preparation subsystem can accept documents in their nativeformats, (i.e., from word processing, publishing and other applications).

Besides accepting and converting the incoming document, the documentpreparation subsystem will sometimes have to support other pre-presscapabilities such as electronic document assembly. To support these pre-press capabilities, the print facility must execute a specified collection oftasks. The relationships of input and output documents, pre-press tasks andattribute specifications are illustrated in Figure 2.

Document Preparation

Input DocumentApplication-specific format

Output DocumentFormat readable bythe decomposer

Pre-Press Tasksand AttributeSpecification

Figure 2. Document preparation stage

1


1.1.3. Document Decomposition

Document decomposition is the process of interpreting an electronicrepresentation of a document and producing a simpler format to drive theprint engine, or marker. Typically, the document is submitted to thedecomposer in a page description language (PDL), and the decompositionprocess converts it to raster format.

The conversion process can vary in complexity depending upon thecomplexity of the job. For black-and-white documents this may be as simpleas converting the document in to a matrix of white and black dots, whereeach dot is represented by a single binary digit (1 or 0).

Conversion of color images is on the other end of the complexity spectrum.Because color images combine cyan, magenta, yellow and black dots to givethe illusion of full color, each dot must be represented by several binarydigits instead of a single digit. In addition, color image processing oftenincludes several additional steps such as anti-aliasing, overlaying, andtrapping.

1.1.4. Marking

Marking is the process of recording the image on the media (for example,applying toner to paper). As explained earlier, the document decompositionsubsystem prepares the document for the print engine, and typically submitsit as an electronic representation of the raster image. If it is marking on hardcopy (non-electronic media such as paper or film), the appropriate formcould be a completely serialized tree, with “pages” being the finestgranularity of the document components.

However, the print facility design should be easily extendible to supportmarking of electronic media such as CD-ROM. In this case, the documentneed not be completely serialized, and the granularity of components may befiner than a page.

1.1.5. Finishing

Following the marking subsystem, finishing subsystems bring the documentto a convenient, human-usable form. For paper documents, finishing tasksinclude collation, stapling, binding, folding, punching, etc.

1.1.6. Packaging

Packaging prepares the finished document for follow-on tasks such asdistribution and delivery. For example, if a piece of software on a CD-ROMis being shipped with documentation, packaging may include shrink-wrapping the CD-ROM and the books together, and applying shipping labelsand postage.

1


1.2. Supporting Subsystem Capabilities

Besides the capabilities that may be visible to a client, a printing facilitymay provide access to a collection of supporting subsystems. Thesesubsystems may not be visible externally, but they make the print facility auseful network peer, or a good network citizen. Such subsystem capabilitiesmay include:

• Resource acquisition • Monitoring• Configuration • Accounting• Logging • Error recovery• System administration • Diagnostics

1.2.1. Resource Acquisition

Some printing systems will require a resource acquisition subsystem toensure that jobs submitted from distributed clients will be handled in themost efficient way possible, while satisfying the needs of system users.Resources that may need to be controlled and acquired include media, fonts,print engines, collators, and finishers.

1.2.2. Monitoring

A print facility should be able to monitor job status, supported device status,and subsystem status. Both notification and query mechanisms should besupported, so that an external entity, such as a print facility client, is allowedto choose the appropriate method.

1.2.3. Configuration

Configuration subsystems allow installers and administrators to set operatingparameters. Some systems will run for their entire life cycle as configured atinstallation; operating parameters on other systems will be reset frequentlyto handle an ever-changing variety of complex print jobs. The selection ofthese alternative device settings may be directed by the scheduling andplanning subsystem.

1


1.2.4. Accounting

Accounting is a useful and sometimes necessary support subsystem in manyenvironments. Accounting subsystems may be used to track costs andsystem usage, and for billing. Traditionally, accounting subsystems in printfacilities have tracked media usage.

However, it is likely that accounting subsystems will be asked to do more inthe future. For example, if a document submitted by an end-user is not print-ready and requires special processing, the facility owner may bill the end-user for the necessary document preparation tasks in addition to thetraditional media-based charges. Therefore, accounting needs to be client-neutral, and its output should be usable not only by billing clients, but alsoby the systems management clients that are tracking process performanceand evaluating productivity improvement.

1.2.5. Logging

Logging is used for error recovery, diagnostics, system tracking, record-keeping and other subsystems. To be effective, the system should log theactivity of individual supported subsystems, and log its own interactions andsubsystem orchestrations.

1.2.6. Error Recovery

Recovery is the set of actions taken to restore a system to normal operationafter a system failure or other major problem. The print facility shouldrecover gracefully from all problems, preferably without intervention by theclient (human or automated) requesting it. This leads to some specificrequirements:

1. Once a request has been accepted by the print facility (that is, it becomesa job), the subsystem must retain enough information so the job canresume after an interruption.

2. Device faults or other non-job-specific problems should be brought to theattention of the operators (who may or may not of submitted the job, andmay or may be in direct contact the user that submitted the job).

3. The print facility should be able to deal with failures in other externalsystems (for example, name service and resource acquisition) and tocontinue its work after such systems have been restored.

1.2.7. System Administration

The administrator may need to define the capabilities of each systeminstallation. There should be a way to factor out common capabilities so thatsystem installations may share them.

1


1.2.8. Diagnostics

A print facility should be able to diagnose its problems to the appropriatelevel of granularity. That level of granularity often depends on theenvironment the print facility is installed in. The print facility should be ableto detect broad, facility-wide problems, as well as failures in individualsubsystems. Ideally, all the diagnostic operations should be settable so thatuniform remote diagnosis of all services can be performed.

These functional and service requirements, combined with the businesscontext the facility must operate in, impart strong system-level requirementson the facility. Some of these system-level requirements are describedbriefly in the next section.

1.3. System Requirements

The understanding of system requirements is essential for the developmentof an effective architecture. Requirements for the Print Facility areilluminated in this subsection and form the basis for the contexts andattributes described in Sections 2 through 4.

1.3.1. Interactions

All interactions, including facility job submissions, event notifications, andcontrol operations, should be available in archivable form.

This strategy enables the following design goals to be met:

1. Rapid integration of heterogeneous facilities

2. Effective strategic management of services and systems through analysisof archived interactions

3. Recovery of interaction information in the event of a system fault

4. Platform independence

5. Reusability of previously formed interactions

6. The use of popular Web/Internet protocols to establish rapid integration.

Interactions that can be easily stored on popular repositories, such as filesystems, provide exceptional levels of protocol independence tocommunicate information between two interacting system entities.

Interactions should minimize the changes to the Print Facility’s client-programmable interfaces as individual system components, features, andcapabilities evolve. In other words, the interactions should be designed tomake the interfaces stable.

1


1.3.2. Scalability

The printing service spans a large spectrum of printers. The features andfunctionality of these printers scale from very simple personal printers tohighly complex commercial print facilities that handle dynamic documentcomposition and mass customization. The print facility must be scaleable inorder to support the full capabilities of all print systems.

Scalability impacts interface design, defined attribute design, andstandardization and management of the defined attributes. To provide themaximum degree of scalability, the print facility should support non-standard print services, as well as print services that support standards suchas DPA and IPP [Ref 7].

1.3.3. Service Negotiation

Because entities other than dedicated clients will need to communicate withthe print facility, the ability to discover and negotiate with the print facilityis highly desirable. The print facility must readily expose its capabilities andprovide easy access to them. Furthermore, the exposed capabilitiesdescription should be self-contained and complete enough to enable anegotiating entity to automatically construct an optimal print facility request.

The interfaces that enable negotiation and discovery should be simple and,preferably, be similar to the request submission and notification interfaces.This will enable rapid integration by requiring only lightweight gatewaysbetween the print facility and other third-party systems.

1.3.4. Security

Security is of prime importance. Users, their roles, and their levels of accessto secured documents must be authenticated. Likewise, the integrity ofaccounting data must be protected. Interactors with the Print Facility mayassume various roles including user, administrator, operator, etc., and thefacility should recognize the those roles and enable the appropriate level ofsecurity.

The following are some additional common print system securityrequirements

1. Print by reference — Secure the ability for the facility to acquire theinformation objects that are referenced within a print facility request.

2. Intellectual property rights — Protected documents have property rightswhich the print facility must honor.

3. Secure printing — An operator should be allowed to intervene andauthorize individual print facility requests.

1


1.3.5. Globalization and Localization

The print facility should fully support localized interactions with a requesterin addition to supporting a variety of globalization and localizationcapabilities. This will impact the internal representation of a job.

1.3.6. Batch Processing and Spooling

In some business environments, a Print Facility may not provide dedicatedservice to one client. Therefore, batch processing, and spooling of printfacility requests, is required.

1.3.7. Performance and Reliability

The desire to constantly improve performance and reliability drive alldesigns towards perfection. A popular way to enhance performance is tobundle communication-intensive entities within a single module. Therefore,a Print Facility should not drive or limit any packaging decisions.

1.3.8. Document Types

Documents are becoming richer and more complex. A facility must supporta large class of document types, especially color, stream and segmenteddocuments. A print facility should enable acquisition and processing of thesedocuments.

1.4. Business Context

Implementations of the print facility interfaces are intended to operate in thefollowing environments:

1. Production Printing — high-volume, mainframe-based printing

2. Departmental Printing — medium-speed office printing support

3. Printing Shops — medium- to high-speed printing shop support

4. Desktop Printing — medium speed printing for a small user groups

5. Small Office, Home Office (SOHO) printing — medium- to low-speedprinting

6. Mobile Printing — low-speed, portable PC support

In a business environment, a facilities owner may use different vendors fordocument services. The print facility should easily integrate into such anenvironment. Therefore, the infrastructure of the facility should be flexible,and the print facility should be able to integrate with other facilities.

1


1.5. The Facility Client View

Both the Print Facility interface and the attribute models have been designedto ensure that the print facility scales easily between a simple monolithic,single-capability, client view of printing, and a more sophisticated view withmultiple, stand-alone subsystems.

1.5.1. Print Facility Interface

Application programmers have easy access to the rudimentary features of thePrint Facility, as well as to the more sophisticated features.

Print Facility interfaces may be conveniently configuredto deactivate advanced features and capabilities.

Interactions may be required not only in archivable form, but in a variety ofhuman-readable and/or machine-readable formats. (Archivability is theability to be stored in a variety of storage systems.)

The print facility interface must support externalizationof interaction objects. (Externalization is the ability toserialize in standard encoding.)


2. Print Facility Architecture

The purpose of this section is to present the major Print Facility architecturalcomponents, including those for which CORBA IDL interfaces exist. Thearchitecture was developed in response to the requirements stated inSection 1.

2.1. Conceptual Architecture

DocService

CapabilityModel

Job Model

DocumentModel

DeviceModel

Externalization Service & FormatCollection Service

Communication Protocols

Attribute Schema

Interaction

12

3

4

5

Facility Services Model

Figure 3 illustrates the Print Facility conceptual architecture. The shadedareas represent the facility’s CORBA objects, which form the basis of theCORBA object model in Section 0. The attribute schema is the heart of theproposed architecture and the Printing Facility is heavily relies on it. Theattribute schema provides a sound semantic abstraction of a large class ofprinting and printing related services and their management. We haveproposed primarily two interfaces, namely, DocService and Interaction thatfacilitate access and manipulation of the attribute schema in a simple conciseway. In the figure, this relationship is indicated by the adjacency ofInteraction and DocService entities with the Attribute Schema. Two CORBAservices, namely, the Externalization Service and Collection services areused in the design of the interfaces. The Externalization Format is used forencoding the Interactions. We propose Service Interaction Language (SIL) asone such format. We do not make any assumptions about theCommunication Protocols. We assume that any established communicationprotocol will suffice. Of the two primary objects, only the DocService dealswith the communication, and its implementation may use appropriatecommunication adapters, if needed.

2


DocService

CapabilityModel

Job Model

DocumentModel

DeviceModel

Externalization Service & FormatCollection Service

Communication Protocols

Attribute Schema

Interaction

12

3

4

5

Facility Services Model

Figure 3. Print facility conceptual architecture

A brief description of each element of the conceptual architecture and itsinterrelationship with other elements is given below.

1. DocService: The Print Facility is built on a peer-to-peer, asynchronous,messaging communications model. (A facility is an entity that facilitatesaccess and integration of multiple services. A service is a namedencapsulation of a collection of capabilities such as printing andconversion.) Each communicating peer is represented by the DocServiceCORBA object type. This object uses communication protocols such asIIOP, HTTP, etc. to interact with its peers. The object uses theexternalization service and a predefined externalization format tocommunicate the interactions. Furthermore, this object also needs tounderstand overall attribute schema in order to execute peer-requestedactions. Details of this object are in Section 0.

2. Communication Protocols: This standard does not prescribe anyparticular communication protocol. However, it is designed so that avendor or a customer may quickly adapt the service to be fully functionalon a network with any standard protocol such as IIOP, HTTP, etc. Thisease of adaptation is possible because no service semantics are associatedwith the way an interaction is communicated; each interaction carries itsintent in a structured, parameterized form. This standard provides nofurther details on communication protocols.

3. Externalization Service & Format and Collection Service: TheCORBA Externalization Service is used to enable reliable heterogeneouscommunication, and to enable facility vendors to choose theexternalization format that best fits their needs. This service consists ofthree principal CORBA objects:

• Streamable• StreamIO• Stream

CORBA Collection service is used for management of collections. Primarilythe Iterator interface is used from the collection service.

2


The Interaction object inherits the Streamable interface from theExternalization service in order to provide it with the requiredinternalization and externalization operations. Details of theExternalization Service are in an OMG standard document. It alsoprovides three iterators that inherit the iterator from the Collectionservice.

This standard recommends a simple externalization format called the ServiceInteraction Language (SIL). A powerful and highly extensibleexternalization format, SIL can encode both simple, single-servicerequests and complex multiple-service requests and their compositions.We describe this format in Section 0.

1. Interaction : An Interaction is an unambiguously serializable object thatencodes the intent of interactions as a predefined set of attributes withcontextual groupings. The interaction is unambiguously serializablebecause the collection of attributes within it are structured intopredefined contexts, whose relationships and semantics are either fixedby the semantics of the interaction type or encoded by the attributes.Therefore, an interaction is self-explanatory, and is independentlyunderstood by a recipient. There are three specializations of interactions:RequestInfo, QueryInfo and ReportInfo.

• A RequestInfo interaction carries a request for action. Theinteractions for submitting, modifying, pausing or resuming a job or adevice, changing the attributes or priority of a job, etc. are consideredrequests.

• A QueryInfo interaction enables a facility client to obtain job ordevice status and facility capability descriptions, as well as enablingjob submission negotiations.

• A ReportInfo is used by the facility for one way communication ofsolicited information such as a response to a request or queryincluding logging, notification messages, etc.

Details of the interaction object and types of interactions are in Section 0.

5. Attribute Schema: As shown in Figure 3, the attribute schemaestablishes the Facility Service Model that includes this standard’s Job,Document, Capability and Device Models. All interactions adhere to andrely on these models to communicate the interactor’s intent. The FacilityService Model is described in Section 0, as are the Job, Document, andCapability Models.

2.2. CORBA Object Model

The relationships between CORBA objects relevant to this specification aredescribed in Figure 4. The CORBA objects, Iterator and Streamable areshaded to distinguish them from the proposed objects.

2


Streamable

DocServiceFactory

DSIterator

InteractionDocServiceuses

URIStreamFactoryuses uses

RequestInfoFactory RequestInfoFactory RequestInfoFactory

RequestInfo ReportInfo QueryInfo

Iterator

Figure 4. Interface object model

The following object interfaces are defined within this standard:

• DocService: Provides a submission interface for streamed attribute-based queries, requests, and reporting interactions between printingfacilities.

• Interaction: The base class for three specializations, namely,RequestInfo, QueryInfo and ReportInfo. It manages the currentoperating contexts for its specializations.

• RequestInfo: Manages the information necessary for creation andmodification of a service request.

• RequestInfoFactory: Creates RequestInfo, given an operationalcontext in the form of a ReportInfo.

• QueryInfo: Manages Information necessary for creation andmodification of a query.

• QueryInfoFactory: Creates QueryInfo, given an operationalcontext in the form of a ReportInfo.

• ReportInfo: Manages information necessary for creation andmodification of a report.

• ReportInfoFactory: Creates ReportInfo, given an operationalcontext in the form of a ReportInfo.

• DocServiceFactory: Creates and recovers DocService objects.

• URIStreamFactory: Creates and encapsulates service and targetresources specified by Universal Resource Identifier (URI)parameters.

2


• DSIterator : Specialization of the Iterator. New methods allowchecking the existence of an element and retrieval of an element in astring form.

2


Interaction

request

*

query

context

*

report

*

*

*

service descriptiondoc_obj

attribute

aggregate

*

**

*

Main Context Main Context Aux. Context Main Context

Figure 5. Interaction information model

In a typical operation, a facility client creates an appropriate interactionobject using the corresponding factory, and populates the object withrelevant contexts, attribute and value aggregations. The client thencommunicates the externalized interaction to the facility using theDocService object. The facility is a peer entity, and it receives theexternalized string through its DocService object and reconstructs theinteraction object by internalizing it. Since the semantics of the interactionare fully encoded in the Interaction Object, the facility then acts according tothe information contained in the Interaction. The components needed tocarry out the actions requested in the interaction are not specified in thisstandard. They are implementation-specific components, and must beprovided by the print facility implementers.

To enable a truly distributed, peer-to-peer, interaction-based model, it isnecessary to make an interaction self-explanatory; that is, all the necessarystate information is referenced. This is achieved by ensuring that allinteractions have unique interaction-ids. Interactions may contain references(in the form of attribute values) to relevant previous interactions andimplementation-specific entities such as jobs, devices and services.

2


2.2.2.1. Types of Interaction

There are three types of interactions: query, request and report. These threetypes of interactions are managed by three different specialization of theInteraction object, namely, RequestInfo, QueryInfo, and ReportInfo. Allpeer-to-peer communications are achieved through these three interactiontypes.

1. A request interaction carries a request for action. The interactions forsubmitting, modifying, pausing or resuming a job or a device, changingthe attributes or priority of a job, etc. are requests. The maincharacteristic of a request is that, if a request is accepted by a DocServiceobject, it may result in an externally observable internal state change. Forexample, if the “cancel job” request is accepted, the cancellation of thatjob can be observed externally. All requests require a correspondingreport to the interactor of the request.

A request is structured to unambiguously express all possible requestinteractions between a facility client and the facility. An example of thestructure of a request is shown in Figure 6.

Request Interaction

InteractionIdentifiers & References

ServiceContext

ProcessingInstructions

DocumentContext

DocumentDescriptions

1

11

1

0 ..* 0 ..*

0 ..*0 ..*

1 1

Indicates containsrelationship

Figure 6. Information structure of a general request interaction(boxes indicate information objects)

As shown in Figure 6, a request interaction contains:

• the interaction information, which is encoded by a group ofattributes called the interaction attributes

• the reference information, which is encoded mostly by a group ofattributes called the generic attributes

• a collection of named, specific service contexts that containprocessing instructions expressed as an aggregation of attributes

• and a collection of documents to be processed, again described as acollection of document attributes.

2


2. A query is similar to a request in that it carries a request for action;however, its execution does not produce an externally observable internalstate change. Queries include interactions that enable getting the status,getting capability descriptions, negotiating a job submission, etc.

Figure 8 shows the structure of a general query. While request and reporthave a single context space, the query has two context spaces. For thepurposes of this document, they are called the main context space and theauxiliary context space. The main context space carries the queryinformation, and the auxiliary context space carries the optional jobinformation. This auxiliary information is useful when job submissionfeatures, functionality, cost and time need to be negotiated. For example,if a client wants to know how much it will cost to execute a particular setof services, the job specification is provided in the auxiliary contextspace, and the attribute corresponding to the cost is placed in anappropriate context inside the main context space.

Auxiliary Context Space

ServiceContexts



DocumentContexts

Main Context Space

ServiceContexts

QueryAttributes

Query Interaction


0 ..* 0 ..* 0 ..*

0 ..* 0 ..* 0 ..*1

1

1

11

0..11

1

1 1

11


Figure 8. Information structure of a general query interaction

A typical query is simple, without any entities in the auxiliary context space.Figure 9 shows a schematic representation of a query that obtains the jobstatus from an IPP Print service.

Main Context Space

IPP PrintService

JobUri, JobStatusAttributes

Query Interaction


Figure 9. An example query of JobStatus in IPP Print Service

2


In a query interaction, all attributes with specified values are used foridentifying the specific entity that is being queried. All attributes thathave no value or a NULL value indicate the requested information. A no-value attribute is a request for maximum information on the entityrepresented by the attribute. An attribute with NULL value is a requestfor the value of the attribute at the time of the request. In the example ofFigure 9, the JobUri attribute identifies the specific job through anassigned value. The JobStatus attribute would not have any value.

2. Unlike request and query, a report does not contain a request for action.Instead, it is a one-way communication of information; it does not requirea response. It is used to communicate solicited notifications, responses torequests and queries, and to support interactions for logging andaccounting. The information structure of a report interaction is similar tothe structure of a request interaction, and is shown in Figure 10.

Report Interaction


ServiceContext


DocumentContext


1

11

1

0 ..* 0 ..*

0 ..*0 ..*

1 1


Figure 10. Information structure of a general report interaction

2.2.2.2. Interaction Contexts

An Interaction context consists of a context type and a context name. Thecontext types provide the general semantics of the attribute aggregates, andthe context-names provide the specific semantics. For example, in Figure 9,the context-type ‘service’ provides the general execution semantics to theaggregations, and the context-name IPP-Print provides the specific printservice execution semantics.

The following four context-types are standardized in this specification:

1. service: This context-type primarily distinguishes attribute aggregatesassociated with the Print Facility’s distinct, externally visible subsystemcapabilities. In this specification, we call them Print Facility Services, orsimply services.

For example, the pair <service IPP-Printing> may identify the collectionof capabilities that make up the simple Printing Service. The collection ofattributes that are defined in this context are simple Printing attributes,defined in the standard.

2


2. doc_obj: This context type describes electronic document attributeaggregates. The context name associated with this context type identifiesa specific collection of attributes. Although the standard does not specifycontext names, a vendor or customer may standardize these names toestablish reliable interoperability.

For example, the <doc_obj editable_document> context indicates thatthe referenced document editable, and that it has a predefined collectionof attributes that are useful for document editing. Such a document can beinput only to those services that understand the attribute collection. Thecollection of attributes is completely customizable; that is, a customer orvendor may formulate a customized set of attributes and assign a specificcontext name for that collection.

3. description — This context-type is primarily used as a capabilitiesdescription for a report interaction in response to a query. It may also beused as an information aggregation within other context types. Thisindicates that the attribute aggregates in this context have no execution ordata semantics. The capabilities description of a facility is a goodexample of a description. For example, the <descriptionfacility_description> context identifies a group of attributes that describea facility’s high-level capabilities. The following description contexts arespecified as standards in this document:

• facility_description

• service_description

• attribute_description

• constraint_description

• document_description

A detailed specification of these contexts is given in Section 0.

1. global: This context type is primarily used for global interactioninformation. All attributes that may belong to a global context are placedat the interaction level above the scope of the specific service, doc_obj ordescription context. There are no context names associated with thiscontext type.

2


2.2.2.3. Attribute Aggregates

Attribute aggregates are a named, addressable collection of attributescontained in the interaction contexts. The semantics of these collectionsdepend on the interaction context type in which they are being used.

1. In a doc_obj context type, an attribute aggregate represents anaddressable collection of document attributes. These attributescharacterize the document. They may reference the document content, ormay contain the content of a document as an attribute value. The‘requested’ services use these collections to acquire and processdocument inputs, or to generate specified outputs. This collection isusually referred to by the generic attributes InputDocument andOutputDocument.

2. Within a service context type, an attribute aggregate represents anaddressable service invocation specification. Therefore, there areassociated execution semantics. An aggregation in the service context canbe viewed as the ‘processing instruction’ for the service named by thecontext name. Not all attributes need to be specified for execution of aservice. All unspecified attributes are considered to be set to their systemor site default values, depending on the site policy.

3. Within a description context-type, an attribute aggregate represents anaddressable collection of support information attributes.

2.2.2.4. Overview of the Attribute Schema

The attribute schema (see Section 0, note #5) is the foundation of the facilitymodel specified in this document. While traditional standards identify thescope of features and functionality to be supported, this document proposesthat features and functionality need to be flexibly defined by other standards,coalitions and customers. To include multiple collections of attributes ofpossibly customized services within a standardized protocol, a generalattribute schema is defined.

In this schema, attributes are categorized by their relationship to multiplecollections of attributes. Some categories of attributes are standardized forinteroperation and management of discovery, negotiation, execution andmonitoring of services. Other attribute categories are opaque to the facility,and must be defined by the facility implementers or vendors.

Figure 11 shows the attribute categories, along with a few examples ofattributes.

2


2.3. Attribute Schema

In Section 0 we briefly introduced the attribute schema. This section detailsthe categories of attributes and lists the standardized attributes. Descriptionsof individual attributes are in Section 0.

2.3.1. Meta Attributes

Meta attributes are commonly understood by all document service facilities,including the print facility. These attributes describe a facility’s capabilitiesin terms of supported services, attributes, and values, and the variousconstraints and relationships among them. The information encoded throughthese attributes is complete enough that a remote requester accessing thiscapability description may automatically infer and generate the desiredservice request. There are five attribute contexts within the meta attributeschema, each with several associated attributes. The attribute contexts (boldtype) are listed below along with their associated attributes.

facility description — context constraint description -— context• facility-name • independent-attributes• supported-document-services • dependent-attributes• supported-infrastructure-services • dependency• accessible-external-services • supported-interaction-attributes

service description — context attribute description — context

• service-type-name • description-type-name• supported-service-specific-

attributes• attribute-name

• supported-generic-attributes • attribute-data-type• supported-input-documents • value-class• supported-output-documents • supported-values• supported-job-states • default-value• invocation-constraint • ready-values

document description — context • not-ready-values• document-type-name • on-order-values• supported-layout-attributes • on-order-values• supported-structure-attributes • special-order-values

• attribute-constraints

2


2.3.2. Service Interaction Attributes

A service interaction attribute instance describes an interaction. Theinteraction may be a request, a query or a report. In any interaction, it isnecessary to obtain information to understand the source of the interaction,the ID of the interaction, the intent of the interaction, whether or not it is apositive or negative response, and more. This information is required foreffective job management and long-term system performance analysis andmanagement. The service interaction attributes are:

• interaction-id • interactor• originator • response-to• originator-natural-language • interaction-priority• originator-charset • interaction-time stamp

2.3.3. Generic Attributes

Generic attributes are service-neutral, and are commonly understood by allthe services. These attributes encode system management functions such asjob control and management, system administration, diagnostics, job qualityand guarantees, input and output management, and support servicespecification. The generic attributes are:

• job-control-operation • device-URI• device-control-operation • device-name• input-documents • device-location• output-documents • device-description• invocation-condition • device-more-info-site• job-name • device-driver-installer• job-priority • device-make-and-model• job-hold-until • device-more-manufacturer-info• job-URI • device-state• job-originating-user-name • device-state-reasons• job-originating-host • device-state-message• job-natural-language • job-completion-time• job-state • number-of-intervening-jobs• job-charset • job-message-from-operator• job-state-message • queued-job-count• job-submission-time • service-is-accepting-jobs• job-started-processing-time • service-message-from-the-

operator

2.3.4. Service-Specific Attributes

Attributes that specify a service’s features and functionalities are calledservice-specific attributes. This standard does not specify service-specificattributes. In the Printing context, detailed standards, such as DPA [Ref 1]are an excellent source of these attributes. The facility interface design fullysupports those services.

2


2.4. Externalization Format — SIL

An externalization format (see Section 0, item #3) must be able tounambiguously represent the information content of all interactions betweentwo peer facilities. In addition, the format must support standard encodingand internationalization of at least the values. It should also make it easy toprepare the information for presentation to the user.

Another major requirement is that the language be simple enough to enablelightweight implementations (i.e., with small and simple parsers) forexternalization. This requirement not only addresses the performance aspect,but also the ease with which non-CORBA facilities can be integrated withthe proposed Print Facility. The recommended Service Interaction Language(SIL) meets these requirements.

2.4.1. SIL Syntax

The Service Interaction Language (SIL) description uses the symbolsdefined in the International Reference Version (IRV) standard of theinternational standard ISO/IEC 646: 1991 (US ASCII). The SIL is defined asfollows using the OMG IDL EBNF [Ref 6].

1. {Interaction, request, report, query, template, c_type, invocation,attribute, type, name, value, status, status_id, description, identifier} arethe non-terminals (all non-terminals are shown in bold-italic fonts).

2. IRV of ISO/IEC 646 (1991) are the terminals.

2


3. Productions:

interaction ::= request | report | query

request ::= template | “< SIL” version encoding interaction_id> attribute* template

</SIL>report ::= “<! SIL” version encoding interaction_id “>”

attribute* “<!>” template “</!> < /SIL>”query ::= “<? SIL” version encoding interaction_id “>”

attribute* “<?>” template “</?>” template “</SIL>”

template ::= { “ [” c_type name “ ]” aggregation* “end” status} *

c_type ::= “doc_obj” | “service” | “description”

aggregation ::= [“ default” | name ] “ {“ attribute*

“ }” [status]attribute ::= [ "*" ] type name [=|= value|= value{,

value} *]; [status ]version ::= ASCII string

encoding ::= “ASCII” | “UNICODE” | “LATIN-1” | “UTF8”interaction_id ::= ASCII string

status ::= status_id [“ {“ description “}” ]status_id ::= identifier ∈ { set of predefined status tokens }description ::= stringname ::= identifier ∈ {set of case-insensitive tokens }type ::= identifier ∈ {set of predefined type case-insensitive names}

value ::= stringof { type} | “< EMBED” encoding “>” bit stream“</EMBED>”

bit stream ::= stream of bits encoded in the specified encoding with startand end markers as defined by the data type. The non-terminal stringidentifiers, and some value strings, are syntactically described assequences of characters without the delimiters.

The expression ‘stringof{}’ indicates that the attribute value is expressed asa string whose syntax is defined by the attribute’s data type. In addition tothe differences in syntax between query, request and response, there aredistinctly different semantics associated with three interactions.

4. Comments: The ‘#’ character marks the start of a comment, and acarriage return, line feed or vertical space character marks the end of acomment. A comment may be placed anywhere in the interaction.

comment ::= “#” string of type encoding CR NL FF VTAB

2


5. Terminals: The following eight productions provide syntactic primitivesfor SIL in ASCII encoding. (Note: quote marks “ ” are not placed forconvenience. All regular font characters are terminals in the followingproductions.)

digit: 0 1 2 3 4 5 6 7 8 9

letter: A B C D E F G H I J K L M N O P Q R S T U V W

X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z

punctuation: ‘ ` ~ + - . / > < _ : @

white-space:1 CR NL FF SP BSP TAB VTAB

escape-char:2 \/ \\ \” \n \r \t \v \b \f

delimiter: { } [ ] ( ) , ; = # ^ | & ! ? * % $

identifier: (digit letter punctuation)+

quoted-string: “(digit letter punctuationdelimiter white-spaceescape-char)*”

unquoted-string:3(digit letter punctuation \delimiter \white-spaceescape-char)+

6. SIL has five classes of tokens: operators, separators, identifiers, reservedwords and constants.

• operators: * , = (There are a few unused delimiters that can beused to extend the number of operators to extend the language.)

• separators: delimiter

• identifiers: identifier

• constants: quoted_string, unquoted_string

7. Data type syntax: These define the values’ linearization. All values mustbe SIL constants as defined in the previous item (item 6).

1 CR: carriage return, NL: new line, FF: form feed, SP: space, BSP: back space, TAB: horizontal tabular space, VTAB:

vertical tabular space2

Escape Yields Escape Yields Escape Yields\\ \ \r carriage return \v vertical tab\/ / \” ” \b back space\n new line \t horizontal tab \f form feed

3 \delimiter: yields the corresponding delimiter, and \white-space: yields the corresponding white-space characters.

2


Table 1. The SIL data type syntaxData Type Syntax Constraintsstring quoted-string unquoted-string Length may be constrained. If a length-restricted system

receives a string longer than its limit, then it shall truncatethe string to its limit.

integer (ε + -)digit+ Integer of a value between -232 and 231-1.Boolean TRUE FALSE Boolean values are expressed in letters; case is ignored.ref_collection unquoted-string The unquoted-string must match a context name used in

the interaction.ref_invocation unquoted-string:unquoted-string This pair of strings must match the <context-name

aggregate-name> pair.ref_attribute unquoted-string:unquoted-string:

unquoted-stringThese three strings must match the tuple <context-nameaggregate-name attribute-name>.

real (ε + -) (digit*.digit+ digit+.digit*) No exponential representation. Value range and resolutionis device dependent.

time-stamp digit digit digit digit / digit digit / digitdigit / digit digit / digit digit / digit digit

year/month/day/hour/minute/second: a valid string withoutany blank spaces. The unoccupied digit is replaced by the‘0.’

time digit digit : digit digit (AM PM HRS) hour:minute am or pm or 24-hour formatnatural digit+ Value is between 0 and 232-1.int-array ( integer / )+ Integers are separated by ‘/’.string-array ( unquoted-string /)+ Use \/ to escape the ‘/’s within an unquoted string.constraint-expression logical expression of (ref_invocation |

ref_attribute | ref_collection): (value |status) and language constants.

8. Scoping: An Interaction includes contexts, aggregations, attributes andtheir status or values. Scoping not only provides an elegant solution to theproblem of describing a complex service request, but also enables parallelindependent or synchronous processing of multiple service elements.

Three blocks of scope controls exist:

• Interaction level: marked by begin and end of the encoding string

• Context level: marked by ‘]’ and ‘end’

• Aggregation level: marked by ‘{’ and ‘}’

All attributes are strictly local within an aggregation; that is, attributes ortheir values are invisible outside the block in which they occur.

A block cannot have more than one occurrence of a named sub-block.That is:

• An interaction cannot have more than one context with the samecontext name

• A context cannot have more than one aggregation with the samename

• An attribute name cannot be used more than once within anaggregation.

2


2.4.2. SIL Semantics

The SIL semantics parallel the semantics described by the interaction objectdescribed in Section 0. A request describes the collection of services thatneed to be invoked, and the interrelationships of the service invocations. Theservice request streams are generated in accordance with the above BNF,and are communicated to a service provider by either “push” or “pull”mechanisms.

The facility deciphers the service request by internalizing the stream andidentifying the names of the services, the specified attributes, and the valuesfor the services. A provider can then verify whether or not the request isactionable. If it is, the provider responds affirmatively by submitting a reportstream after creating an instance with the appropriate attributes. Everyrequest recipient must respond with an appropriate report.

A report stream carries some solicited or response information to itsrecipient. For example, ‘notification,’ ‘acknowledgment,’ etc. are carried inreport streams. The semantics of the report stream does not require aresponse.

A query may encode two sets of service-attribute collections. The first setspecifies the form of the response, and the second set specifies a coordinatedset of tasks. The first set is enclosed between the <?> </?> symbols andspecifies the form of response. This maps to the interaction object’s maincontext space (see Figure 8). If the values of a set of attributes are desired,those attributes are noted within the appropriate scope. The scope is set bythe service name.

The second set of service attribute collections, immediately following thefirst set, specifies a collection of coordinated tasks to execute. This maps tothe auxiliary context space described in the interaction object (see Figure8).The semantics of the query interaction require an affirmative responsefrom the provider if it can execute the tasks, along with constant values forthe attributes in the enclosed box indicating the conditions under which thetasks can be executed. The provider may simply provide the default valuesfor the attributes enclosed by <?> </?>, if they are not restricted. If the taskis not executable, then the response report should be negative. The semanticsof the query requires the provider to respond with a report.

The c-types, “service”, “doc_obj” and “description,” indicate the contextcategory, and the name string immediately following the s-type declarationprovides the precise context for processing the attributes declared under thatcontext. The c-type maps to the interaction object’s context types.

The “service” c-type uses execution semantics; that is, invocations under thatcontext are a call to execute the named service using the specified attributevalues, and using default values for the unspecified attributes. The name ofthe service being requested follows the service token.

2


The following steps illustrate the job submission scenario from a PrintFacility clients point of view.

1. The client application creates a CORBA Interaction object within theclient address space using a local Interaction Object Factory.

2. The client application uses the Interaction object interface to open a printservice context and an attribute aggregate.

3. The client application adds appropriate print job attributes to the attributeaggregate using the interaction object interface.

4. The client application submits the request interaction using the PrintFacility object interface, setting the interaction style parameter toref_pull, the format parameter to “SIL” and the i_ref parameter to thestring-format object reference for the request interaction object. Theformat parameter specifies the SIL format (discussed in Section 0 of thisdocument) as the external format.

5. The client application returns from the submit operation invocation withno exception raised.

6. At a later time, the Print Facility will create an interaction objectcontaining the report information and use it to invoke the submitoperation on the Print Facility CORBA object, implemented by the clientapplication.

7. The client application internalizes the corresponding interaction stream toan interaction object.

8. The client application determines that the interaction type is report byusing the interaction object interface and processes the printer and jobstatus information contained within.

While other format values are possible, the only externalization formatspecified here is “SIL.”

2.6. Facility Services Model

The Facility Services Model provides the computational view that a clientmay use to discover, access and monitor the services provided by thefacility. A print facility interface must be capable of supporting all of theservices that might be required for the presentation of document data on amedia. The actual services supported on a particular print facilityimplementation vary according to the implementation owner’s or business’needs. These services include scheduling, document preparation, documentdecomposition, marking, finishing, and packaging.

This standard proposes a generalized attribute schema (see Section 0) thatsupports the Facility Services Model. All services are invoked using a set ofattributes.

However, to reliably orchestrate the entire spectrum of print jobs, it isnecessary to model documents, jobs, devices and facility capabilities.

2


Because this document specifies only the print facility interface, thesemodels provide recommendations for the flexible design of a print facilityimplementation. These models also provide the foundation for consistentusage of attributes standardized in this specification.

In the context of the proposed attribute schema, the Document, Job, Deviceand Capability Models provide the facility’s service model. These modelsare described in the next three sections.

2.6.1. Document Model

Documents are the primary means for sharing information, and can bedefined as collections of information. Figure 13 illustrates a complexmultimedia document that contains text, line drawings, photographs, videoand audio, along with a set of construction rules for document structure. Theproposed document model recognizes industry trends towards component-based documents that are constructed at the time of need from reusableinformation objects and/or from database data. The model is derived directlyfrom the document model proposed by the New Document Alliance (NDA),an industry consortium.4

D ocum ent

A cquisition C onstr uction Pr esentation

D ocument M odelI nfor m ation O bj ects C onstr uction R ules

Audio

Video

W eather in theW ester n Plainshas contr ibuted toan expectionalcr op of pumpkinsthis year .A dequate r aincom bined withwar mth and a

Text

Pictorial

Graphics

Cost

Pumpkins

rain

50403020100 100 200

R ule - n

R ule - 2

R ule - 1

C onstr uction R ules

Information ObjectHarvest

Cost

Pum pkins

rain

50

403020

100 100 200

Weathethe WePlains contributto expectiocrop of

combwithwarmta balansun, hasallowedmaxi

W eather inthe W ester nPlains hascontr ibutedto anexpectionalcr op ofpumpkinsthis year .A dequater ain

com binedwithwar mth anda balance ofsun, hasallow edm axim umgr owth ofthis year s'pr oduction.

Cost

Pumpkins

rain

50403020100 100 200

H arvest N ews

Figure 13. Document model schematic

4 New Document Alliance (NDA) Technical Framework Document, April 1996.

2


The finished document is created when a set of construction and presentationprocesses is applied to a document framework (container) and its constituentinformation objects. The document becomes complete only at the time ofpresentation, before this time it is a disembodied set of components.Artifacts created by the construction process may be used as informationobjects in the construction of new documents; that is, information objectscan be reused, or used for a different purpose.

The rapid adoption of document representations that support the applicationof externally specified layout and composition rules (such as SGML, HTML,and, to a lesser degree, Adobe PDF) have accelerated the trend towardspersonalized documents constructed at the time of need from reusableinformation objects.

2.6.1.1. Document Assembly

The Print Facility interface must be able to assemble a document that isacquired or addressable as a collection information objects, as shown inFigure 13. The facility class of the printer determines the richness of itsspecification flexibility. High-end printers may provide highly flexiblespecifications, while low-end desktop printers may handle only single-component documents. The proposed print facility supports a wide range ofspecifications.

Traditionally, assembly trees have been proposed as a rich way to specifydocument assembly. The root of the tree represents the assembled document, andeach sub-node of the tree represents a component of the document. Sheetsare the atomic components of the document.

The assembly tree is not a convenient representation when:

• sub-components need to be merged on a page

• a components need to be split

• an assembled document component needs to be shared by twohigher-level assemblers.

In order to have a natural representation for such a task, we make use ofdocument references for document components (at all stages) and the printand finish sub-services.

Figure 14 is an example of a document assembly graph where documentassembly and disassembly processes are accommodated, and an intermediatedocument component is shared. This type of assembly can be completelyspecified by the IDL-based service request mechanism.

2


ASSEMBLY TASK-1

ASSEMBLY TASK-2

DISASSEMBLY TASK-1

ASSEMBLY TASK-3

ASSEMBLY TASK-4

ASSEMBLY TASK-5

INTERMEDIATEDOCUMENT

COMPONENTSINPUT DOCUMENTCOMPONENTS

INTERMEDIATEDOCUMENT

COMPONENTS

ASSEMBLEDOUTPUT DOCUMENT

Figure 14. Document assembly graph, where document components may be shared anddisassembled as desired. This specification can support all classes of printing facilities.

2.6.1.2. Document Attributes

The described document model is fully supported in the Print Facilityinterface specified in Section 0. As described in the Interaction Objectsection (0), all documents are separated from processing instructions, and aredescribed by an aggregation of attributes that completely specify thedocument characteristics. All processing instructions reference the documentattribute aggregation for both input and output documents.

Because the design and specification of document attributes is the task of acoalition of major document repository vendors such as DMA, this printfacility standard does not specify the document attributes. However, it doesstandardize the meta attributes that describe the categories of supporteddocument attributes (see Section 0).

2.6.2. Job and Device Model

A job is a planned and scheduled instantiation of a service request acceptedby the facility. This instance is identified by the generic attribute “JobURI,”and it is uniquely identifiable given the facility, service and that JobURI.

This architecture enables distributed scheduling and job control, becausepeer-to-peer interactions for the specification and execution of jobs areallowed.

2


The scope of the job execution may be limited to the supported servicewithin the print facility, or it may span several document service facilities.Therefore, a job in general is a graph that may be generated after theplanning stage, or it may be directly specified by the requester.

At any node in the job graph, during the execution of the graph, a requestermay access the status through a query using the JobURI, or involved servicefacilities may directly notify the requester of the requested events. Similarly,operations can be requested on devices through a set of device attributes.These attributes are listed under generic attributes (Section 0).

A provider may internally have an object defined for a job, according to aspecific internal system decomposition. However, details of such designdecisions are not visible to a requester.

2.6.3. Capability Model

The print facility interface’s capability model describes the facility’s currentcapabilities to a requester. It is assumed that a requester has been pre-codedto process the attribute of a service, as declared by the provider-standardattributes. However, at any facility instance, some values may not besupported, or some features may be constrained or enhanced by theidiosyncrasies of a site-specific configuration.

On-line access to a facility’s capabilities is useful for building requests thatcan maximize the available features. Capabilities access is also useful for theprogrammatic integration of systems. If the facility’s capabilities descriptionis modeled so that automated inferences can be derived flexibly andextensibly, automated composition of services can be achieved throughsmart requesters. The proposed capability representation enables thederivation of automated inferences, provided the requesters and providersuse a standard set of meta attributes.

Figure 15 illustrates the structure of the capability representation for a printfacility. It is a general structure, applicable to any document service facility.

2


Print Facility

Services (e.g.)Interaction

Job Model

ExternalServices

ConvertionMarking

FinishingPrint Service

Attributes (e.g.)

attribute-n

Constraints

Connectivity

Generic Attr. Meta AttributesMeta Attributes

Generic Attr.

Connectivity

Figure 15. Capability representation structure for the print facility

The capability model permits flexible exposure of either a single printservice or a collection of services, including traditional printing.

Meta attributes are key to a facility’s capability representation. They expressthe interrelationships among services and attributes, and identify site-specific limitations of a service.

A facility may automatically generate a capability representation at startup,or a system administrator may set it to represent the current systemconfiguration. This insulates requesters, and the rest of the system, fromchanges to the print facility. If the facility is designed internally toreconfigure itself, a system administrator may configure the system bychanging the facility’s capability description.


3.Object IDL Semantics

The IDL interface semantics are described in detail below for each of themodule data types, attributes and operations. The data types for theCFDocServiceTypes module is included for completeness, however thereader should refer to the chapter on attribute semantics for a completedescription of these types.

The following IDL defines the necessary object service definition files thatmust be included. The comments indicate compilers with which this IDL hasbeen successfully compiled.

// IDL code compiles with : // Iona Orbix Version v2.2 IDL compiler. // BAE Object Broker V3.0 // Visigenic Visibroker for Java 3.0 #prefix “omg.org” #include <orb.idl> #include <Stream.idl> #include <Externalization.idl> #include <Collection.idl>

3.1. CFDocServiceTypes Module

The following CORBA data types are defined to support base line documentservices attribute values. Please see the chapter on “Attribute Semantics” forfurther information. Specialized attribute data types may be added to supportparticular services by adding them in a corresponding data types module(e.g. CFFaxServiceTypes).

module CFDocServiceTypes{ typedef string DSText; typedef string<1023> DSText1023; typedef string<63> DSNaturalLanguage; struct DSTextWithLanguage { DSNaturalLanguage override_lang; DSText text; }; struct DSTextWithLanguage1023 { DSNaturalLanguage override_lang; DSText1023 text; }; typedef string<255> DSName; struct DSNameWithLanguage

4


{ DSNaturalLanguage override_lang; DSName name; }; typedef string<255> DSKeyword; typedef unsigned long DSEnum; typedef string DSUri; typedef string<1023> DSUri1023; typedef string<63> DSUriScheme; typedef string<63> DSCharSet; typedef sequence<octet> DSOctetString; typedef sequence<octet,1023> DSOctetString1023; typedef boolean DSBoolean; typedef unsigned long DSInteger; struct DSRangeOfInteger { DSInteger min; DSInteger max; }; struct DSDateTime { DSInteger year; DSInteger month; DSInteger day; DSInteger hour; DSInteger minutes; DSInteger seconds; }; struct DSRefInvocation { DSKeyword context_name; DSKeyword invocation_name; }; enum DSEnumValueClass { enumerated, range, referenced, grammar }; enum DSLogicalExpression { and, or, not }; struct DSConstraintExpression { DSRefInvocation constraint1;

4


DSRefInvocation constraint2; DSLogicalExpression expr; }; typedef any DSAny; enum DSEnumDependency { activate, deactivate, setdefault, ignore }; struct DSReferenced { DSName ref1; DSName ref2; };

};

3.2. CFDocService Module Data Types

The following CORBA data types are defined for the CFDocService module.

interface Interaction; interface RequestInfo; interface QueryInfo; interface ReportInfo; interface DocService;

The following InfoContext enumeration type is used within Interactionoperation parameters to distinguish between the three Interaction contexttypes that are supported in this standard. See Section 0 for details on thesemantics of these context types. When the InfoContext is not known, theds_none option may be used.

enum InfoContext { ds_none, ds_doc_obj, ds_service, ds_description };

The following Preference enumeration is used to indicate the CFDocServiceclient’s preference as to whether an Interaction Attribute must be applied bythe CFDocService implementation.

enum Preference { ds_compulsory,

4


ds_noncompulsory, ds_not_applicable };

The following semantics are observed:

• ds_compulsory: set by the client; means the InteractionAttribute must be applied by the CFDocService implementationor else the job will be rejected.

• ds_noncompulsory: set by the client; means the InteractionAttribute need not be applied by the CFDocServiceimplementation if unavailable. The job may not be rejected.

• ds_not_applicable: set by the client; means preferences are notused by this CFDocService implementation.

The following Status enumeration is used by a CFDocServiceimplementation to indicate the run-time status of each Interaction element(Interactions, Interaction Contexts, Attribute Aggregations and Attributes).

enum Status { ds_ignored, ds_overwritten, ds_error, ds_completed, ds_aborted, ds_processing, ds_initiated, ds_canceled, ds_unknown };

The CFDocService implementation sets the status to this value:

• ds_ignored: when it has ignored an Interaction element.

• ds_overwritten: when it has overwritten an Interaction elementwith its own value.

• ds_error: when an error occurred while processing anInteraction element.

• ds_completed: when it has finished processing an Interactionelement.

• ds_aborted: when it has aborted processing an Interactionelement.

• ds_processing: when it is currently processing an Interactionelement.

4


• ds_initiated: when it begins processing an Interaction element.

• ds_canceled: when it cancels processing an Interaction element.

• pf_unknown: when it cannot determine the status of anInteraction element.

The following data types are the standard data types for getting settingiterator element data for (respectively) the Context Iterator, the AggregationIterator and the Attribute Iterator. The Attribute value iterator data types aredefined by the DocServiceDataTypes module.

struct CData {InfoContext c_type; string c_name; string c_status; string c_sinfo;};

The c_type field contains the context type, the c_name field contains thename of the context, the c_status contains the status of the context and thec_sinfo field contains additional information provided by the server aboutthe context status (in ascii form).

struct AggData { string agg_name; string agg_status; string agg_sinfo; };

The agg_name field contains the name of the aggregation, the agg_statuscontains the status of the aggregation and the agg_sinfo field containsadditional information provided by the server about the aggregation status(in ascii form).

struct AttrData { string att_type; string att_name; Preference att_pref; Status att_stat; string att_sinfo; };

The attr_name field contains the name of the attribute, the attr_statuscontains the status of the attribute and the attr_sinfo field contains additionalinformation provided by the server about the attribute status (in ascii form).

The following enum allows the programmer to differentiate between themain and auxiliary contexts when building a QueryInfo object.

enum ContextSwitch { main, auxiliary };

The TransferStyle enum allows the programmer to indicate that theInteraction object will be (ds_pull) created by the client, passed by referenceand pulled over by the server; or (2) created by the server, a reference towhich is passes back to the client allowing the client to then add data to theInteraction.

enum TransferStyle { ds_push, ds_pull };

The TransferType allows the programmer to specify a CORBA objectreference or a URI reference is to used to pass an Interaction. The third

4


option (only supported in the ds_push TransferStyle) indicates that the valueof the Interaction is passed to the server in the form of a string.

enum TransferType { ds_obj, ds_uri, ds_val };

The following CORBA unions allow the programmer to select between thethree available TransferType selections for each type of Interactionsupported by this service.

union RequestInfoRef switch(TransferType) { case ds_obj: RequestInfo or; case ds_uri: string urir; case ds_val: string val; }; union QueryInfoRef switch(TransferType) { case ds_obj: QueryInfo or; case ds_uri: string urir; case ds_val: string val; }; union ReportInfoRef switch(TransferType) { case ds_obj: ReportInfo or; case ds_uri: string urir; case ds_val: string val; };

typedef sequence<ReportInfoRef> ReportInfoRefList;

3.3. Interaction

The Interaction interface serves as the base interface class for theRequestInfo, QueryInfo and ReportInfo classes.

The known_name operation returns “TRUE” if either the c_name (contextname) or the attr_name (attribute name) is supported by the Interactionimplementation. If the attr_name is left an empty string, only the c_name ischecked.

The known_val operation returns “TRUE” if the encoding and decodingalgorithm for the attr_type (attribute type) is known by the Interactionimplementation.

interface Interaction : CosStream::Streamable

4


{ boolean known_name(in string c_name, in string attr_name); boolean known_val(in string attr_type); };

3.4. DSIterator

The DSIterator inherits from the CosCollection::Iterator class and adds twooperations: exists and get_element_string.

The exists operation returns “TRUE” if an information element with theoffered name exists in the corresponding collection.

The get_element_string returns the string value (as an out parameter)for thecurrent element of the iterator. The operation returns “FALSE” if the stringvalue is not available.

interface DSIterator : CosCollection::Iterator { boolean exists(in string name); boolean get_element_string(out string val); };

The create operation of the DSIteratorFactory returns a DSIterator. Facilityimplementors may add features to this factory interface since clients do notexplicitly create these objects.

interface DSIteratorFactory { DSIterator create(); };

3.5. RequestInfo

The RequestInfo object is used to create an Interaction that is going to beused to ask the server to do some work on behalf of the client. It can beexternalized to a stream via the Streamable interface from which Interactioninherits.

interface RequestInfo : Interaction { exception UnSupported {};

GetCIterator returns an iterator for the collection of contexts that currentlyexist in the RequestInfo data. If only c_type (context type) is given then thecurrent context is the first context of this type. If a c_name is also given,

4


then the current context is the named context if it exists and the first contextif it does not. An UnSupported exception is raised if a context type orcontext name is specified that the Interaction implementation does notsupport.

/*Context Management*/ DSIterator GetCIterator( in InfoContext c_type, in string c_name)raises (UnSupported);

GetAggIterator returns an iterator for the collection of named attributeaggregations that currently exist in the RequestInfo data. If only c_name(context name) is given then the current aggregation in this context is thecurrent Iterator element. If an agg_name is also given, then the currentaggregation is the named aggregation (if it exists) and the first aggregation ifit does not. An UnSupported exception is raised if a context name isspecified that the Interaction implementation does not support.

/*Aggregation Management*/ DSIterator GetAggIterator( in string c_name, in string agg_name)raises (UnSupported);

GetAttrIterator returns an iterator for the collection of named attributes thatcurrently exist in the named context and named aggregation of theRequestInfo data. If only c_name (context name) and agg_name(aggregation name) are given then the first attribute in this aggregation is thecurrent Iterator element. If an att_name (attribute name) is also given, thenthe current attribute is the named attribute (if it exists) and the first attributeif it does not. An UnSupported exception is raised if an attribute name isspecified that the Interaction implementation does not support.

/*Attribute Management*/ DSIterator GetAttrIterator( in string c_name, in string agg_name, in string att_name)raises (UnSupported);

GetValIterator returns an iterator for the collection of attributes values thatcurrently exist in the named attribute, named aggregation, and namedcontext of the RequestInfo data. All fields are required in this operation. AnUnSupported exception is raised if the named attribute is not supported bythe Interaction implementation.

/*Value Management*/ DSIterator GetValIterator( in boolean str_encoding, in string c_name, in string agg_name,

4


in string att_name)raises (UnSupported); };

The following interface is the construction interface for an RequestInfoobject implementation. The create operation returns a RequestInfo interfaceand takes five parameters for which the following semantics apply:

• uuid: a stringified universal unique identifier for the RequestInfobeing created.

• ReportInfoRef: is a reference to an object describing thecapabilities of the service to which the RequesInfo Interactionwill be sent.

• format: indicates the format in which the RequestInfo data willpresent itself to a DocService implementation throughinternalization and externalization.

• version: indicates version number for the format in which theRequestInfo data will present itself to a DocServiceimplementation.

• encoding: indicates the encoding (such as “ascii” and “utf8”)that the RequestInfo data will present itself to a DocServiceimplementation.

interface RequestInfoFactory { RequestInfo create( in string uuid, in ReportInfoRef ref, in string format, in string version, in string encoding); };

3.6. QueryInfo

The QueryInfo object is used to create an Interaction that is going to be usedto ask the server what capabilities it has or what state it is in. It can beexternalized to a stream via the Streamable interface from which Interactioninherits.

interface QueryInfo : Interaction {

GetCIterator returns an iterator for the collection of contexts that currentlyexist in the QueryInfo data. If only c_type (context type) is given then thecurrent context is the first context of this type. If a c_name is also given,

4


then the current context is the named context if it exists and the first contextif it does not. A ContextSwitch parameter allows the programmer to selectbetween the main and auxiliary query contexts.

/*Context Management*/ DSIterator GetCIterator( in ContextSwitch cs, in InfoContext c_type, in string c_name);

GetAggIterator returns an iterator for the collection of named attributeaggregations that currently exist in the QueryInfo data. If only c_name(context name) is given then the current aggregation in this context is thecurrent Iterator element. If an agg_name is also given, then the currentaggregation is the named aggregation (if it exists) and the first aggregation ifit does not. A ContextSwitch parameter allows the programmer to selectbetween the main and auxiliary query contexts.

/*Aggregation Management*/ DSIterator GetAggIterator( in ContextSwitch cs, in string c_name, in string agg_name);

GetAttrIterator returns an iterator for the collection of named attributes thatcurrently exist in the named context and named aggregation of theQueryInfo data. If only c_name (context name) and agg_name (aggregationname) are given then the first attribute in this aggregation is the currentIterator element. If an att_name (attribute name) is also given, then thecurrent attribute is the named attribute (if it exists) and the first attribute if itdoes not. A ContextSwitch parameter allows the programmer to selectbetween the main and auxiliary query contexts.

/*Attribute Management*/ DSIterator GetAttrIterator( in ContextSwitch cs, in string c_name, in string agg_name, in string att_name);

GetValIterator returns an iterator for the collection of attributes values thatcurrently exist in the named attribute, named aggregation, and namedcontext of the QueryInfo data. All fields are required in this operation. AContextSwitch parameter allows the programmer to select between the mainand auxiliary query contexts.

/*Value Management*/

4


DSIterator GetValIterator( in ContextSwitch cs, in boolean str_encoding, in string c_name, in string agg_name, in string att_name); };

The following interface is the construction interface for an QueryInfo objectimplementation. The create operation returns a QueryInfo interface andtakes five parameters for which the following semantics apply:

• uuid: a stringified universal unique identifier for the QueryInfobeing created.

• QueryInfoRef: is a reference to an object describing thecapabilities of the service to which the QueryInfo Interactionwill be sent.

• format: indicates the format in which the QueryInfo data willpresent itself to a DocService implementation throughinternalization and externalization.

• version: indicates version number for the format in which theQueryInfo data will present itself to a DocServiceimplementation.

• encoding: indicates the encoding (such as “ascii” and “utf8”)that the QueryInfo data will present itself to a DocServiceimplementation.

interface QueryInfoFactory { QueryInfo create( in string uuid, in string format, in string version, in string encoding); };

3.7. ReportInfo

The ReportInfo object is used to create an Interaction that is going to be usedto deliver server information to the client. It can be externalized to a streamvia the Streamable interface from which Interaction inherits.

interface ReportInfo : Interaction {

4


GetCIterator returns an iterator for the collection of contexts that currentlyexist in the ReportInfo data. If only c_type (context type) is given then thecurrent context is the first context of this type. If a c_name is also given,then the current context is the named context if it exists and the first contextif it does not.

/*Context Management*/ DSIterator GetCIterator( in InfoContext c_type, in string c_name);

GetAggIterator returns an iterator for the collection of named attributeaggregations that currently exist in the ReportInfo data. If only c_name(context name) is given then the current aggregation in this context is thecurrent Iterator element. If an agg_name is also given, then the currentaggregation is the named aggregation (if it exists) and the first aggregation ifit does not.

/*Aggregation Management*/ DSIterator GetAggIterator( in string c_name, in string agg_name);

GetAttrIterator returns an iterator for the collection of named attributes thatcurrently exist in the named context and named aggregation of theReportInfo data. If only c_name (context name) and agg_name (aggregationname) are given then the first attribute in this aggregation is the currentIterator element. If an att_name (attribute name) is also given, then thecurrent attribute is the named attribute (if it exists) and the first attribute if itdoes not.

/*Attribute Management*/ DSIterator GetAttrIterator( in string c_name, in string agg_name, in string att_name);

GetValIterator returns an iterator for the collection of attributes values thatcurrently exist in the named attribute, named aggregation, and namedcontext of the ReportInfo data. All fields are required in this operation.

/*Value Management*/ DSIterator GetValIterator( in boolean str_encoding, in string c_name, in string agg_name,

4


in string att_name); }; The following interface is the construction interface for an ReportInfo objectimplementation. The create operation returns a ReportInfo interface andtakes five parameters for which the following semantics apply:

• uuid: a stringified universal unique identifier for the ReportInfobeing created.

• ReportInfoRef: is a reference to an object describing thecapabilities of the service to which the ReportInfo Interactionwill be sent.

• format: indicates the format in which the ReportInfo data willpresent itself to a DocService implementation throughinternalization and externalization.

• version: indicates version number for the format in which theReportInfo data will present itself to a DocServiceimplementation.

• encoding: indicates the encoding (such as “ascii” and “utf8”)that the ReportInfo data will present itself to a DocServiceimplementation.

interface ReportInfoFactory { ReportInfo create( in string uuid, in string format, in string version, in string encoding); };

3.8. DocService

The DocService interface must be supported by all participants in thecommunications network for the peer-to-peer model of operation. In theclient/server model of operation, only the server must support theDocService interface.

In the peer-to-peer model of operation, the client need only support thereport operation.

interface DocService { Four possible levels of exceptions are returned from a DocService interfacein response to the receipt of an Interaction.

4


The ContentError exception indicates that the DocService implementationhas had a problem with some specific contexts, attributes or values in theInteraction data. The offending elements are returned within the body of theexception in the form or a reference to a ReportInfo object.

exception TransferStyleNotSupported { }; exception TransferTypeNotSupported { }; exception TransferFormatNotSupported { }; exception ContentError { ReportInfoRef ref;};

All DocService operations require style and format parameters. Theseparameters qualify the usage for the associated Interaction parameter.

As discussed previously, the style parameter indicates a “pull” or “push”Interaction object transfer.

The request operation represents a client requesting that a server do work onits behalf, it takes a RequestInfoRef Interaction as a parameter.

void request(in TransferStyle style, in string format, inout RequestInfoRef ref) raises (TransferStyleNotSupported, TransferTypeNotSupported, TransferFormatNotSupported, ContentError);

The query operation represents a client requesting the capabilities or state ofa server, it takes a QueryInfoRef Interaction as a parameter.

void query(in TransferStyle style, in string format, inout QueryInfoRef ref) raises (TransferStyleNotSupported, TransferTypeNotSupported, TransferFormatNotSupported, ContentError);

The report operation represents a server offering a client information aboutits capabilities or state, it takes a ReportInfoRef Interaction as a parameter

void report(in TransferStyle style, in string format, inout ReportInfoRef ref) raises (TransferStyleNotSupported, TransferTypeNotSupported, TransferFormatNotSupported, ContentError);

4


The poll operation represents a client requesting of the server, using aQueryInfo object, preformated information about the server capabilities (inresponse to a client Query) or state (either solicited or unsolicited).

void poll(in TransferStyle style, in string format, inout QueryInfoRef qref, out ReportInfoRefList rrefs) raises (TransferStyleNotSupported, TransferTypeNotSupported, TransferFormatNotSupported, ContentError);

}; The following interface is the construction interface for a DocService objectimplementation:

interface DocServiceFactory { DocService create(in CFDocServiceTypes::DSUri recover_data, in CFDocServiceTypes::DSUri config_data); };

The create operation returns a DocService interface; it uses two parametersfor which the following semantics apply:

• recover_data: contains a string-format URI identifier forDocService recovery data in case of a non-recoverable fault.

• configuration: a string-format URI for Interaction data containing acapability description of the desired DocService configuration.

3.9. UriStreamFactory

The UriStreamFactory interface has one create operation which returns aCosExternalization::Stream.

interface PFUriStreamFactory{ exception InvalidUri {};

CosExternalization::Stream create( in CFDocServiceTypes::DSUri pf_uri) raises( InvalidUri);};

The create operation takes a URI as a parameter and uses it tointernalize/externalize object data. The create operation may raise anInvalidUri exception if any problem is encountered that prevents access tothe resource addressed by the specified URI.

4


4.

4


Attribute Semantics

This section specifies job and service attribute instances. The followingconventions are used.

1. Each sub-section heading gives the keyword name of the attributedescribed in the sub-section. That keyword attribute name is the value ofthe attribute_name field in the IDL definition of PFAttribute .Following in the header in parenthesis, is the English name of the datatype of the attribute (e.g., integer, name, text, keyword).

2. A table in each attribute description specifies the following informationabout the attribute: Data Type, Additional Constraints, Preference,and Set by. The description of each column in each attribute tablefollows:

a. Data Type — The “Data Type” column in each attribute tablecorresponds to the attribute_data_type field in the IDL definition ofDSAttribute . The table entry and IDL field contains the formal OMGIDL Data Type, e.g., DSInteger, DSName, DSText, DSKeyword.For the DSKeyword data type, there are four possible extensibilityclasses indicated in parentheses as listed in Table 2.

Table 2. Extensibility classes for DSKeyword data types

ExtensibilityClass

Description

(type 1) The standard must be revised to add a new name. Privatenames are not allowed.

(type 2) Implementers can, at any time, add new values by proposingthem to the PWG for registration (or an IANA-appointedregistry advisor after the PWG is no longer certified). Thevalues are reviewed for approval and the IANA keeps theregistry. Implementers can support private values(unregistered) with a suitable distinguishing prefix, such asxxx, where xxx is the company name registered with IANAfor use in domain names.

(type 3) Implementers can, at any time, add new values by submittinga registration request directly to IANA. A PWG or IANA-appointed registry advisor review is not required.Implementers can support private (unregistered) names with asuitable distinguishing prefix, such as xxx, where xxx is thecompany name registered with IANA for use in domainnames.

(type 4) System administrators can, at any time, add new installation-defined names to a local system. Care should be taken by theadministrator to see that keywords do not conflict with otherkeywords defined by the standard or as defined by theimplementing product.

4


4.1. Attribute Data Types

Table 3 specifies the attribute data types. The SIL data types are largelytaken from the IPP attribute syntax names. The Print Facility IDL data typenames are formed by capitalizing the first letter and pre-pending DS. TheDescription column includes a length or size constraint. The Comments fieldfurther describes the semantics of the data type.

In the data types defined below, the types with length constraints have thesame constraints as IPP. When there are two types, one constrained and oneunconstrained, the constrained type has the length in octets appended to thename. When there is only one type, the constraint is not included in thename.

All character-coded data types are in the current coded character set for theinteraction, which may be US-ASCII, ISO 8859-1, ISO 10646 (Unicode),UTF-8, etc., as specified by the “originator-charset” interaction attribute.

Table 3. Attribute data types

SIL / IDLAttribute Data Type Description Comments

text / DSText A sequence ofcharacters;length: unconstrained;characters: any

For free-form, human-readable text intended forhuman consumption. Maybe in any coded characterset as specified for theinteraction, including ISO10646 (Unicode), whichhas embedded NUL (0x0)octets.

text1023 / DSText Same as ‘text’ with theconstraint of 1023octets maximum

For free-form, human-readable text intended forhuman consumption. Maybe in any coded characterset as specified for theinteraction.

naturalLanguage /DSNaturalLanguage

A standard Latin letteridentifier for the naturallanguage and,optionally, a country.For OMGPF, themaximum length is 63octets.

The values for this syntaxtype are taken from RFC1766 [26].

Examples: ‘en’ forEnglish, ‘en-us’ for U.S.English, ‘fr’ for French,‘de’ for German.

4




textWithLanguage /DSTextWithLanguage

A structure consistingof a ‘naturalLanguage’override field and a‘text’ field.

The 'naturalLanguage' fieldoverrides the naturallanguage of the request orresponse. Any attribute oftype ‘text’ shall also be oftype ‘textWithLanguage’.

TextWithLanguage1023/DSTextWithLanguage

A structure consistingof a ‘naturalLanguage’override field and a‘text1023’ field.

The ‘naturalLanguage’ fieldoverrides the naturallanguage of the request orresponse. Any attribute oftype ‘text1023’ shall alsobe of type‘textWithLanguage1023’.

name / DSName A sequence ofcharacters;length: 1 to 255;characters: any

For referencing some objectvia a user-friendly string,such as a Printer name, adocument name, a username, or a host name. Mayinclude the SPACEcharacter. May be in anycoded character set asspecified for the interaction.

Note: The protocol mayneed to provide means toquote the SPACE characterif the protocol uses SPACEfor other purposes.

NameWithLanguage /DSNameWithLanguage

A structure consistingof a ‘naturalLanguage’override field and a‘name’ field.

The ‘naturalLanguage’ fieldoverrides the naturallanguage of the request orresponse. Any attribute oftype ‘name’ shall also be oftype ‘nameWithLanguage’.

4




keyword / DSKeyword A sequence of Latincharacters;length: 1 to 255;characters: Latin letters(A-Z, a-z), digits,period (“.”), hyphen (“-”), underscore (“_”).

The first character mustbe a lower case letter.

For private(unregistered) keywordextensions,implementers shoulduse keywords with asuitable distinguishingprefix, such as “xxx-”where xxx is the(lowercase) fullyqualified companyname registered withIANA for use indomain names[RFC1035]. Forexample, if thecompany XYZ Corp.had obtained thedomain name“XYZ.com”, then aprivate keyword ‘abc’would be: ‘'xyz.com-abc’.

For semantic identifiers ofentities in the abstractprotocol (specified in thisdocument). These entitiescan be attribute names orvalues of attributes.

When a keyword is used torepresent an attribute (itsname), it must be uniquewithin the full scope of theobjects and attributes.When a keyword is used torepresent a value of anattribute, it must be uniquejust within the scope of thatattribute. That is, a keywordcan not be used for twodifferent values of the sameattribute to mean twodifferent semantic ideas.However, the samekeyword can be used acrosstwo or more attributes,representing differentsemantic ideas for eachattribute.

4




enum / DSEnum An enumerated integervalue that is in therange from -2**31 to2**31 - 1.

Each value has anassociated keyword name.Each attribute (whosesyntax is enum) enumeratesthe values that are definedfor the attribute. The enumtype is used for attributesfor which there are enumvalues assigned by otherstandards, such as SNMPMIBs. Enums are not usedfor attributes to which thesystem administrator mayassign values.

Values in the range 2**30to 2**31 - 1 are reservedfor private or experimentaluse. Implementers arewarned that use of suchvalues may conflict withother implementations.Implementers areencouraged to requestregistration of enum valuesfollowing the procedures inSection 0.

uri / DSUri A sequence ofcharacters as defined inRFC 1738 and RFC1808.

Universal ResourceIdentifier

uri1023 / DSUri1023 Same as ‘uri,’ with asize constraint of 1023octets.

Universal ResourceIdentifier

uriScheme /DSUriScheme

A sequence ofcharacters representingthe URI scheme. ForOMGPF, the maximumlength is 63 octets.

These include ‘http’ forHTTP schemed URIs (e.g.,http://...), and ‘ftp’ for FTPschemed URIs (e.g.,ftp://...).

naturalLanguage /DSNaturalLanguage

A standard Latin letteridentifier for the naturallanguage and,optionally, a country.For PF, the maximumlength is 63 octets.


Examples: ‘en’ for English,‘en-us’ for U.S. English,‘fr’ for french, ‘de’ forGerman.

4




charSet / DSCharset A standard Latin letteridentifier foridentifying acharacterset. For PF, themaximum length is 63octets.


Examples: ‘us-ascii’, ‘iso-8859-1’, ‘iso-10646-ucs-2’,‘utf-8’.

mimeMediaType /DSMimeMediaType

A standard Latin letteridentifier for theInternet Media Typethat identifies adocument format

The values for this syntaxtype are taken from RFC2046 as registered withIANA. Some types permita charset parameter thatindicates the codedcharacter set of thedocument data.

Examples: ‘text/html’,‘text/plain’, ‘text/plain;charset=us-ascii’,‘text/plain; charset=iso-8859-1’,‘application/postscript’,‘application/vnd.hp-PCL’.

octetString /DSOctetString

A sequence of octets Used for opaque data, suchas the document-content.

OctetString1023 /DSOctetString1023

Same as ‘octetString’with a size constraint ofa maximum of 1023octets

Used for opaque data, suchas encrypted passwords,etc.

boolean / DSBoolean Two values of ‘true’and ‘false’

Like a keyword set, butthere are only two values.

Note: An application mightuse a checkbox for such avalue.

integer / DSInteger An integer value that isin the range from-2**31 to 2**31 - 1

Each attribute specifies therange constraint explicitly.

rangeOfInteger /DSRangeOfInteger

An ordered pair ofintegers that defines aninclusive range ofinteger values

The first integer specifiesthe lower bound and thesecond specifies the upperbound.

dateTime / DSDateTime A standard, fixed-length representation ofdate and time asdefined in RFC 1514[32] and RFC 1903[33]

For PF, the 11 octet form,not the 8 octet form, shallbe used.

4




refInvocation /DSRefInvocation

A reference to a namedset of attributes. Thereference consists oftwo fields: a contextname and an invocationname that refers toattributes by theiraggregation name.

Used by attributes to referto other attributes.

enumValueClass /DSEnumValueClass

The value class of anattribute

Standardized values:‘enumerated’, ‘range’,‘referenced’, and‘grammar’.

constraintExpression /DSConstraintExpression

A logical expression ofreferences toconstraints. Eachconstraint isrepresented as arefInvocation.

Used to control if and whenan invocation is to beexecuted.

any / DSAny Any of the above datatypes

Used where any data type isallowed.

4.2. Meta Attributes

This section specifies the meta attributes. Meta attributes are attributes thatexpress relationships about other attributes. The order of specification of themeta attributes follows the order in which attributes are listed in Section 0.

4


4.2.1. facility-description Context

This context specifies the capabilities of the facility instance as set by thefacility administrator. The value of this context is a capability descriptionwhich is itself a single set of meta attributes that represents the capabilitiesof a facility instance. The remainder of the meta attributes described in thissection are used in this capability description of a facility instance. Some ofthese meta attributes in turn refer to other meta attributes.

The value of a “facility-description ” context may contain the followingattributes:

• “facility-name” (strongly recommended so that requesters cansubmit requests)

• “supported-document-services”

• “supported-infrastructure-services”

• “accessible-external-services”

• “supported-interaction-attributes”

These attributes are specified in the immediately following sub-sections.

Example: Consider the print facility instance defined by the systemadministrator and named ‘Paul’s Print Shop’. The value of the “facility-description” attribute might contain the following attributes:

1. “facility-name” = ‘Paul’s Print Shop’

2. “supported-document-services” =

3. “supported-infrastructure-services” =

4. “accessible-external-services” =

5. “supported-job-states” =

6. “supported-interaction-attributes” =

NOTE — When this attribute is streamed in SIL format, it is representedinside square brackets followed by one set of attributes surrounded by onepair of {} and ending with a single “end,” as shown in the followingexample.

[description facility-description]{name facility-name = “west-printer”;refinvocation supported-document-services = service-

description:s1;}end

4


4.2.1.1. facility-nameField: Data Type Add. Constraints Preference

TypeSet by

Value: name none N/A Administrator

This attribute specifies a name for the facility instance set by the facilityadministrator. The administrator should specify a facility name that isunique within the domain in which the facility is intended to be used.

4.2.1.2. supported-document-servicesField: Data Type Add. Constraints Preference

TypeSet by

Value: refInvocation multi-valued N/A Administrator,Facility

This attribute specifies the document service(s) supported by the facilityinstance set by the facility administrator. Each value of this attribute is areference to a service description context that describes the capabilities ofeach document service that makes up this facility instance.

NOTE — Typically, an administrator will define one or more servicedescription capabilities for each type of printing, scanning, faxing, anddocument distribution service. The administrator may define one or moreservice descriptions for printing as a whole, or may break up printing intosub-service capability descriptions, such as marking, finishing, etc. Then theadministrator will define each facility instance capability description asreferencing the service descriptions by setting the value of the “supported-document-services” attribute to a reference to each service description.

NOTE — Because a facility instance description references one or moreservice descriptions, many facility instance descriptions may share a servicedescription, easing the burden of the system administrator wishing tomaintain many facility instances over time that have the same capabilities.

4


4.2.1.3. supported-infrastructure-servicesField: Data Type Add. Constraints Preference

TypeSet by


This attribute specifies the infrastructure service(s) supported by the facilityinstance set by the facility administrator. Each value of this attribute is areference to an infrastructure description of the capabilities of eachinfrastructure service that make up this facility instance.

NOTE — Typically, an administrator will define one or more infrastructuredescription capabilities for each type of service (e.g., notification, security,RPC, monitoring, accounting, logging, etc.). Then the administrator willdefine each facility instance capability description as referencing the servicedescriptions by setting the value of the “supported-infrastructure-services” attribute to a reference to each infrastructure description.

NOTE — Because a facility instance description references one or moreinfrastructure descriptions, many facility instance descriptions may share aninfrastructure description, easing the burden of the system administratorwishing to maintain many facility instances over time that have the samecapabilities.

4.2.1.4. accessible-external-servicesField: Data Type Add. Constraints Preference

TypeSet by


This attribute specifies the external service(s) accessible by the requesterthrough the facility instance set by the facility administrator. Externalservices include notification, security, accounting, etc. Each value of thisattribute is a reference to an accessible description of the capabilities ofeach accessible external service that this facility instance uses.

4


4.2.1.5. supported-interaction-attributesField: Data Type Add. Constraints Preference

TypeSet by

Value: refInvocation See values below N/A Administrator,Facility

This attribute specifies the supported interaction attribute names for thefacility instance set by the facility administrator. Each value of this attributeis a reference to an attribute description of the capabilities of eachinteraction attribute that make up this facility instance.

The standard interaction attributes are:

• “interaction-id”

• “originator”

• “originator-natural-language”

• “originator-charset”

• “interactor”

• “response-to”

4.2.2. service-description Context

This context specifies the capabilities of the service instance as set by thefacility administrator. The value of this context is a capability descriptionthat is itself a single set of meta attributes representing the capabilities of aservice instance. The remainder of the meta attributes described in thissection are used in this capability description of a service instance. Some ofthese meta attributes in turn refer to other meta attributes.

The values of a “service-description” context may contain the followingattributes:

• “service-type-name”

• “supported-service-specific-attributes”

• “supported-generic-attribute”

• “supported-input-document”

• “supported-output-document”

• “supported-job-states”

• “invocation-constraints”

These attributes are specified in the next sub-sections.

4


NOTE — Because a “facility-description” attribute points by reference to aservice description instance, multiple facility-descriptions may share thesame service description instance. When the administrator defines servicedescription instance that are shared by multiple facility descriptioninstances, the service description instance becomes more of anadministratively defined type.

4.2.2.1. service-type-name Field: Data Type Add. Constraints Preference

Type Set by

Value: keyword See values below N/A Administrator,Facility

This attribute specifies a service type name for the service instance set bythe facility administrator. This standard does not define a set of standardvalues.

4.2.2.2. supported-service-specific-attributes Field: Data Type Add. Constraints Preference

Type Set by


This attribute specifies a set of service-specific attributes that are supportedby the service instance set by the facility administrator. Each value of thisattribute is a reference to an attribute description of the capabilities of eachattribute that make up this service instance.

4.2.2.3. supported-generic-attributes Field: Data Type Add. Constraints Preference

Type Set by


This attribute specifies a set of generic attributes that are supported by theservice instance set by the facility administrator. Each value of this attributeis a reference to an attribute description of the capabilities of each attributethat make up this service instance.

4.2.2.4. supported-input-documents Field: Data Type Add. Constraints Preference

Type Set by

Value: refInvocation multi-value N/A Administrator,Facility

This attribute specifies the input document(s) supported by the serviceinstance set by the facility administrator. Each value of this attribute is areference to a document description of the capabilities of each inputdocument that make up this service instance.

4


4.2.2.5. supported-output-documents Field: Data Type Add. Constraints Preference

Type Set by


This attribute specifies the input document(s) supported by the serviceinstance set by the facility administrator. Each value of this attribute is areference to a document description of the capabilities of each outputdocument making up the service instance.

4.2.2.6. supported-job-states Field: Data Type Add. Constraints Preference

Type Set by

Value: enumtype 2

See values of thegeneric “job-state” attribute

N/A Administrator,Facility

This attribute specifies the supported job states for the facility instance setby the service; that is, the supported values of the “job-state” attribute.

4.2.2.7. invocation-constraint Field: Data Type Add.

Constraints PreferenceType

Set by

Value: constraintExpression multi-valued N/A Administrator,Facility

This attribute specifies a set of attribute constraints for the service instanceset by the facility administrator. The generic attribute invocation-conditionis set by the user while requesting a service. However, the value of thatattribute must satisfy the constraint set by this attribute in the service’scapability description.

4.2.3. document-description Context

This context specifies the capabilities of the document instance for thefacility instance as set by the facility administrator. The value of this contextis a document description which is itself a single set of meta attributesrepresenting the capabilities of a document instance.

The values of an “document-description” context may include thefollowing attributes:

• “document-type-name”

• “supported-structure-attributes”

• “supported-layout-attributes”

These attributes are described in the next sub-sections.

4


4.2.3.1. document-type-name Field: Data Type Add. Constraints Preference

Type Set by


This attribute specifies a type name for the document description instancethat is set by the facility administrator. Some example values are:

• ‘printable ’ — a final-form document that is print ready, typically ina page description language (PDL) representation such asPostScript™ or PCL.

• ‘editable’ — a revisable-form document that needs to be runthrough a decomposition process (interpreted) such as a wordprocessor.

• ‘markable’ — a document in raster bitmap form such as TIFF.

An example set of attribute aggregates that support each of the abovedocument type are given in Appendix C. The document repository vendorsand other standards vendors usually standardize these attributes.

4.2.3.2. supported-structure-attributes Field: Data Type Add. Constraints Preference

Type Set by


This attribute specifies the set of structure attributes of the documentinstance. This is set by the facility administrator.

Examples of structure document attributes include: “document-name” and“document-format.”

4.2.3.3. supported-layout-attributes Field: Data Type Add. Constraints Preference

Type Set by


This attribute specifies the set of layout attributes of the document instance.This is set by the facility administrator.

4


4.2.4. attribute-description Context

This context specifies the capabilities of the attribute instance as set by thefacility administrator. The value of this context is an attribute descriptionwhich is itself a single set of meta attributes that represents the constraints ofa service instance.

The values of an “attribute-description ” context may include the followingattributes:

• “description-type-name”

• “attribute-name”

• “attribute-data-type”

• “value-class”

• “supported-values”

• “default-value”

• “ready-values”

• “not-ready-values”

• “on-order-values”

• “special-order-values”

• “attribute-constraints”

These attributes are described in the next sub-sections.

4.2.4.1. description-type-name Field: Data Type Add. Constraints Preference

Type Set by


This attribute specifies a type name for the description instance set by thefacility administrator.

Standard values are:

• ‘facility-description’

• ‘service-description’

• ‘document-description’

• ‘attribute-description’

• ‘constraint-description’

4


4.2.4.2. attribute-name Field: Data Type Add. Constraints Preference

Type Set by

Value: name none N/A Administrator,Facility

This attribute specifies a name for the attribute instance set by the facilityadministrator.

4.2.4.3. attribute-data-type Field: Data Type Add. Constraints Preference

Type Set by

Value: keyword none N/A Administrator,Facility

This attribute specifies the data type for the attribute instance that is set bythe facility administrator.

4.2.4.4. value-class Field: Data Type Add. Constraints Preference

Type Set by

Value: keyword none N/A Administrator,Facility

This attribute specifies the name of the value class for the attribute instanceset by the facility administrator. A value class is a list of keyword values thatare allowed to be used together in one or more attributes.

4.2.4.5. supported-values Field: Data Type Add. Constraints Preference

Type Set by

Value: any multi-valued N/A Administrator,Facility

This attribute specifies a set of values that is supported for the attributeinstance set by the facility administrator.

4.2.4.6. default-value Field: Data Type Add. Constraints Preference

Type Set by

Value: any none N/A Administrator,Facility

This attribute specifies a default value for the attribute instance set by thefacility administrator.

4


4.2.4.7. ready-values Field: Data Type Add. Constraints Preference

Type Set by


This attribute specifies the subset of the “supported-values” that may beused without human intervention for the attribute instance set by the facilityadministrator.

4.2.4.8. not-ready-values Field: Data Type Add. Constraints Preference

Type Set by


This attribute specifies the subset of the “supported-values” that requirehuman intervention for the attribute instance set by the facility administrator.

4.2.4.9. on-order-values Field: Data Type Add. Constraints Preference

Type Set by


This attribute specifies the subset of the “supported-values” that are onorder for the attribute instance set by the facility administrator.

4.2.4.10. special-order-values Field: Data Type Add. Constraints Preference

Type Set by


This attribute specifies the subset of the “supported-values” that requirespecial ordering for the attribute instance set by the facility administrator.

4.2.4.11. attribute-constraints Field: Data Type Add.

Constraints PreferenceType

Set by

Value: constraintExpression multi-valued N/A Administrator,Facility

This attribute specifies the constraints for the attribute instance set by thefacility administrator. Each value of this attribute is a reference to anattribute constraint description specifying the cross-attribute valueconstraints for this service instance.

4


4.2.5. constraint-description Context

This context specifies the cross-attribute value constraint for the serviceinstance as set by the facility administrator. The value of this context is anattribute constraint description which is itself a single set of metaattributes representing the constraints of a service instance.

The values of a “constraint-description” context may include the followingattributes:

• “independent-attributes”

• “dependent-attributes

• “dependency”

These attributes are described in the next three sub-sections.

4.2.5.1. independent-attributes Field: Data Type Add. Constraints Preference

Type Set by

Value: keyword multi-valued N/A Administrator,Facility

This attribute specifies a set of attribute names that affect the values of other(dependent) attributes.

4.2.5.2. dependent-attributes Field: Data Type Add. Constraints Preference

Type Set by

Value: keyword multi-valued N/A Administrator,Facility

This attribute specifies a set of attribute names whose values are affected bythe values of other (independent) attributes. If a dependent attribute isspecified with values in this attribute capability instance, then only thosevalues are dependent on the independent attribute.

4


4.2.5.3. dependency Field: Data Type Add. Constraints Preference

Type Set by

Value: keyword see values below N/A Administrator,Facility

This attribute specifies a type of dependency for the attribute instance set bythe facility administrator.

The standard values are:

• ‘deactivate’ — deactivate; do not accept a request for the dependentattribute(s) whenever the independent attribute is specified by arequester. If the dependent attribute is specified in the same attributecapability description, then only those values are deactivated whenthe requester supplied the independent attribute.

• ‘activate’ — dependent attribute values are a function ofindependent values. This function can be identified throughenumeration.

• ‘set-default’ — default values of the dependent attribute may not bevalid, hence different default values may have to be substitutedwhen the requester specifies the independent attribute.

4.3. Service Interaction Attributes

Because the OMG is an asynchronous peer-to-peer protocol, each requestand response is treated as a separate interaction between an “interactioninitiator” and an “interaction recipient.” The Service Interaction attributesprovide information that describe each discrete interaction between eachpeer.

4.3.1. interaction-id

Field: Data Type Add. Constraints Preference Type Set by

Value: name required N/A requester

This attribute specifies an identifier of this interaction that is uniquelyunderstandable to the interaction initiator (interactor). The interactionrecipient of this interaction shall return this value as the value of the“response-to” attribute in a future Response interaction.

4


4.3.2. originator


Value: name none N/A requester

This attribute specifies a system-identifiable name token for the originatingcomputational or human entity that instructed the interactor to make theinteraction.

4.3.3. originator-natural-language


Value: naturalLanguage none N/A requester

The natural-language of the originating end user of the Facility-Client thatperformed the interaction.

4.3.4. originator-charset


Value: charset none N/A requester

The coded character set of the originating end user of the Facility-Client thatperformed the interaction.

4.3.5. interactor



A system-identifiable name token that communicates the current interaction.If there are no intermediate facilities that interact on behalf of the originator,the value of this attribute is the same as the originator.

4.3.6. response-to



The value of this attribute is the “interaction-id” of the interaction for theresponse to the current interaction. If the current interaction is not aresponse, then this attribute shall have no value. In the SIL stream, this no-value line would be “DSName response-to ,” or the entire attributewould be omitted.

4


4.3.7. interaction-priority


Value: keyword none N/A requester

A system-understandable priority value for the current interaction. Thevalues it supports are also supported by the generic attribute ‘job-priority’that are supported by the applicable subsystems.

NOTE:—The ‘interaction-priority’ attribute is for the interaction, not thejob. See the ‘job-priority’ generic attribute.

4.3.8. interaction-timestamp


Value: dateTime none N/A requester

This attribute specifies the date and time of day when the construction of theinteraction is completed.

4.4. Generic Attributes

4.4.1. job-control-operation

Field: Data Type Add. Constraints Preference Set by

Value: keyword (type 2)

See values below compulsory/non-compulsory

User, Facility

This attribute identifies the operation being performed by this interaction ona job.

Either this attribute or the “device-control-operation” attribute shall bepresent in a Request, but not both. If neither are present, the “job-control-operation” with a value of ‘CreateJob’ shall be assumed.

Standard values for job control operations are:

• ‘CreateJob’ — The requester begins the creation of a job object byspecifying input parameters that initialize a job and any number ofthe following job component objects: document, document-service-instructions (DSI), and submitted-resource, such as adownloaded font or logo.

• ‘AddJobComponents’ — The requester adds one or more jobcomponents by specifying input parameters that initialize thefollowing job component objects: document, document-service-instructions (DSI), work , and submitted-resource, such as adownloaded font or logo.

4


• ‘CloseJob’ — The requester indicates that the job and its documents(and all its contained jobs and their documents) are completelyspecified.

• ‘ModifyJob ’ — The requester can modify a job before or after thejob has been completely specified.

• ‘HoldJob’ — The requester can prevent a job from being processedor being further processed until a requester issues a ReleaseJoboperation.

• ‘ReleaseJob’ — The requester can indicate that a job is to become acandidate for processing or further processing.

• ‘CancelJob’ — The requester can stop a job from being processedor further processed until a requester issues a ResubmitJoboperation to start a copy of the job at the beginning.

• ‘GetJobAttributes’ — The requester can obtain the values ofrequested attributes of the requested job and other contained objects,such as DSI and document objects.

• ‘ProcessJobNext’ — The requester can request that a job beprocessed immediately after the current job completes.

• ‘ProcessJobNow’ — The requester can request that a job beprocessed immediately, thereby interrupting the current job beingprocessed.

• ‘ResubmitJob’ — The requester can start a new instance of a jobthat is initialized from the identified job. The requester can supplynew values for the new job for the job-service-name-requested andjob-account-name input parameters. The job-service object instancemay be supported by the same or a different service provider.

• ‘DeleteJob’ — The system operator can clean up a job after somemishap. Normally, the system operator will not need to use theDeleteJob operation.

• ‘DeleteJobComponent’ — The requester can delete any jobcomponents.

4


4.4.2. device-control-operation




User, Facility

This attribute identifies the operation being performed by this interaction ona device.

Standard values for device control operations are:

• ‘CleanDevice’ — The operator can remove all jobs from thespecified device.

• ‘CreateDevice’ — The system administrator can create a device andset its attributes to the specified values.

• ‘DeleteDevice’ — The system administrator can delete devices.

• ‘DisableDevice’ — The system operator can disable the acceptanceof new jobs (CreateJob, ResubmitJob, or PromoteJobNowoperations) on the specified device. A service provider shallcontinue to accept other operations for a disabled device. Any jobthat had previously been submitted to a service provider that is nowdisabled shall be unaffected. Any currently processing job on adevice that is disabled shall continue processing to completion.

• ‘EnableDevice’ — The system operator can enable the acceptanceof new jobs (CreateJob, ResubmitJob, or PromoteJobNowoperations) on the specified device. Any jobs that had beensubmitted previously to a device shall continue unaffected.

• ‘PauseDevice’ — The system operator can pause a device.

• ‘ResumeDevice’ — The system operator can resume a pauseddevice.

• ‘SetDevice’ — The system administrator can set attribute values ofa specified device.

• ‘ShutdownDevice’ — The system operator can shut down aspecified or physical device.

• ‘StartupDevice’ — The system operator can start up a specifieddevice.

4


4.4.3. input-documents

Field: Data Type Add. Constraints PreferenceType

Set by

Value: refInvocation multi-valued N/A requester

This attribute identifies the document(s) that are to be consumed as input bythe job. Each value of this attribute is a reference to an attribute aggregationin a specific document context characterized by the context-type doc_obj.

4.4.4. output-documents

Field: Data Type Add. Constraints PreferenceType

Set by

Value: refInvocation multi-valued N/A requester

This attribute identifies the document(s) that are to be produced as output bythe job. Each value of this attribute is a reference to an attribute aggregationin a specific document context characterized by the context-type doc_obj.

4.4.5. invocation-condition

Field: Data Type Add.Constraints

PreferenceType

Set by

Value: constraintExpression None N/A requester

This attribute identifies the condition under which the invocation is valid.The value of this attribute is a logical expression of references to constraintswhich must be satisfied in order for the invocation to be performed. Theactual constraints are expressed in the form of attribute aggregations underconstraint_description context.

4.4.6. job-name


Value: name none compulsory/non-compulsory

User, Facility

This attribute defines the name of the job in more user friendly terms thanthe job-URI.

If “job-name” is not supplied in the Create-Job Request, the facility, oncreation of the job, shall generate a name which is the name of the firstdocument in the job. This name comes from the “document-name” attributeor “document-URI” attribute ,depending on which attribute is supplied in theCreate-Job Request for the first document. If the “job-name” is supplied inthe Create-Job Request, the facility uses its value as the name of the createdjob.

4


4.4.7. job-priority


Value: integer 1..100 compulsory/non-compulsory

User, Facility

This attribute specifies a priority for scheduling the job. The facility thatemploys a priority-based scheduling algorithm use this attribute. A highervalue specifies a higher priority. The value “1” indicates the lowest possiblepriority (a job which a priority-based scheduling algorithm shall pass over infavor of higher priority jobs). The value 100 is indicates the highest possiblepriority. Priority is expected to be evenly or “normally” distributed acrossthis range. Among those jobs that are ready to print, a service provider shallprocess all jobs with a priority value of n before printing those with apriority value of n-1 for all n. The mapping of vendor-defined priority overthis range is implementation-specific.

4.4.8. job-hold-until




User, Facility

This job attribute specifies the named time period during which the print jobshall become a candidate for printing.

Standard values for named time periods are:

• ‘no-hold’ — immediately, if there are not other reasons to hold thejob.

• ‘day-time’

• ‘evening’

• ‘night’

• ‘weekend’ — Saturday or Sunday

• ‘second-shift’

• ‘third-shift’ (after midnight)

An administrator shall associate allowable print times with a named timeperiod. An administrator is encouraged to pick names that suggest the typeof time period.

4


If the value of this attribute specifies a time period that is in the future, theservice provider shall add the ‘job-hold-until-specified’ value to the job’s“job-state-reasons” attribute and shall not schedule the print job for printinguntil the specified time period arrives. When the specified time periodarrives, the service provider shall remove the ‘job-hold-until-specified’value from the job’s “job-state-reason attribute” and, if no other reasonsremain, shall consider the job as a candidate for processing.

If this job attribute value has the named value “‘no-hold’”, or the time periodhas already started , the job shall be a candidate for processing immediately.

4.4.9. notify-events


Value: keyword multi-valued N/A requester

This attribute is multi-valued and lists all the events for which a notificationneeds to be sent to the addresses listed by notify-addresses attribute. Thefollowing values are defined

• all — send notification for all events

• none — do not send notification

• job-completion — notify after job completion

• job-canceled — notify if the job is canceled either by the requesteror by a super user

• job-aborted — notify if the system aborts the job without anyexternal intervention

• job-problems — notify with appropriate message if requesterintervention is needed to solve the problem

• device-problems — notify if there is a problem with the device

4.4.10. notify-addresses


Value: string multi-valued N/A requester

The addresses to which the notification has to be sent if the events thatsatisfy the notification events attribute occur. Default address is consideredto be the ‘interactor.’

4


4.4.11. notify-mechanisms


Value: keyword See values below,multi-valued

N/A requester

Specify the mechanism to be used for notification of the events. Thefollowing values are defined.

• notification-service — using the report operation of the notificationaddress facilities

• e-mail — send email with notification message

• hard-copy — print hard copy on the addressed printers

• fax — send fax to notification addresses

4.4.12. job-originating-user-name


Value: name none NA Facility

This attribute specifies the user name of the person submitting the print job.The service provider shall set this attribute to the most authenticated namethat it can obtain from the protocol over which the operation was receivedfrom the client.

4.4.13. job-originating-host


Value: name none NA Facility

4.4.14. user natural-language


Preference Set by

Value: naturalLanguage none NA Facility

This attribute identifies the natural-language of the job (i.e., the country andlanguage) used by attributes of type ‘text’ and ‘name’. The service providersets this attribute to the most authenticated value it can obtain from theprotocol over which the Print operation was received from the client.

The service provider shall use this attribute to determine the natural-language for attributes of type ‘text’ and ‘name’ in responses, includingnotification messages that it sends.

4


4.4.15. user-charset


Value: charset) none NA Facility

This attribute identifies the coded character set of the job used by attributesof type ‘text’ and ‘name’. The service provider sets this attribute to the mostauthenticated value it can obtain from the protocol over which the Printoperation was received from the client.

The service provider shall use this attribute to determine the natural-language for attributes of type ‘text’ and ‘name’ in responses, includingnotification messages that it sends.

4.4.16. job-URI


Value: uri none NA Facility

This attribute contains the URI for the job.

The service provider, on receipt of a new job, shall generate a URI whichidentifies the job on the service provider. The service provider shall returnthe value of the URI job attribute as part of the PrintResult in the Printoperation. The precise format of a job URI shall be implementation-dependent.

4.4.17. job-state


Value: enum (type 1)

See values below NA Facility

This attribute identifies the current state of the job.

The service provider may provide additional information about each statevalue by supplying one or more values of the job’s companion “job-state-reasons” attribute, depending on the implementation. While the job statescannot be added to without impacting deployed clients that take actions uponreceiving job state values, it is the intent that additional “job-state-reasons”values can be defined without impacting such deployed clients. In otherwords, the “job-state-reasons” attribute is intended to be extensible.

4


Standard values are:

• unknown — The job state is not known, or its state is indeterminate.

• pending — The job is a candidate to start processing, but is not yetprocessing.

• pending-held — The job is not a candidate for processing for anynumber of reasons, and will resume pending as soon as the reasonsare no longer present. The job’s “job-state-reason” attribute shallindicate why the job is no longer a candidate for processing.

• processing —Either:

1. the job is using, or is attempting to use, one or more documenttransforms which include (1) purely software processes that areinterpreting a PDL, and (2) hardware devices that are interpretinga PDL, making marks on a medium, and/or performing finishing,such as stapling,

OR

2. the server has made the job ready for printing, but the outputdevice is not yet printing it, either because the job hasn’t reachedthe output device, or the job is queued in the output device orsome other spooler, waiting to be printed. When the job is in the‘processing’ state, the entire job state includes the detailed statusrepresented in the service provider’s “device-state,” “device-state-reasons,” and “device-state-message” attributes.Implementations may include additional values in the job’s “job-state-reasons” attribute to indicate the progress of the job, such asadding the ‘job-printing’ value to indicate when the output deviceis actually making marks on paper. Most service providers won’tbother with this nuance.

• processing-stopped —The job has stopped while processing for anynumber of reasons and will continue processing as soon as thereasons are no longer present. The job’s “job-state-reason” attributeshall indicate why the job has stopped processing. If the outputdevice is stopped, the ‘device-stopped’ value shall be included in thejob’s “job-state-reasons” attribute. When the output device isstopped, the device usually indicates its condition in human-readableform locally at the device. A client can obtain more complete devicestatus remotely by querying the service provider’s “device-state-reasons” attribute.

4


• canceled —The job has been canceled by a Cancel-Job operationand has completed terminating and all job status attributes havereached their final values for the job. While the service provider iscanceling the job, the job remains in its current state, but the job's“job-state-reasons” attribute should contain the ‘processing-to-stop-point’ value and one of the ‘canceled-by-user,’ ‘canceled-by-operator,’ or ‘canceled-at-device’ value. When the job moves to the‘canceled’ state, the ‘processing-to-stop-point’ value, if present,shall be removed, but the ‘canceled-by-xxx,’ if present, shall remain.

• aborted —The job has been aborted by the system, usually whilethe job was in the ‘processing’ state; the service provider hascompleted aborting the job, and all job status attributes have reachedtheir final values for the job. While the service provider is abortingthe job, the job remains in its current state, but the job's “job-state-reasons” attribute should contain the ‘processing-to-stop-point’ and‘aborted-by-system’ values. When the job moves to the ‘aborted’state, the ‘processing-to-stop-point’ value, if present, shall beremoved, but the ‘aborted-by-system’ value, if present, shall remain.

• completed —The job has completed successfully, with warnings orerrors, all of the job media sheets have been properly stacked in theappropriate output tray or bin, and all job status attributes havereached their final values for the job. The job’s “job-state-reasons”attribute should contain one of: ‘completed-successfully,’‘completed-with-warnings,’ or ‘completed-with-errors.’

The length of time that jobs remain in the ‘canceled,’ ‘aborted,’ and‘completed’ states depends on implementation.

Figure 17 shows the normal job state transitions. Other transitions areunlikely, but are not forbidden.

4


Figure 17. Normal job state transition

Normally a job progresses only from left to right through three states.

The service providers need only support those states which are appropriatefor the particular implementation.

4.4.18. job-state-reasons



Multi-valued See values below

NA Facility

This attribute identifies the reason, or reasons, that the job is in the state thatit is in (e.g., ‘pending,’ ‘processing,’ ‘completed,’ etc.). The service providershall indicate the particular reason(s) by setting the value of the job’s “job-state-reasons” attribute.

The following standard values are defined for use with the job statesindicated as applicable.

NOTE — For ease of understanding, the order of the reasons is presented inthe normal order of job state progression:

• none — Mandatory. There are no reasons for the job’s current state.Applicable job states: ‘pending,’ ‘processing,’ ‘aborted.’

• job-incoming — Mandatory. The PrintJob or CreateJob operationhas been accepted by the service provider, but the service provider iswaiting for additional SendDocument operations and/or the transferof the remainder of the job or document data. Applicable job states:‘pending-held.’

Pending

Processing

Pending-Stopped Processing-Stopped

Canceled

Aborted

Completed

4


• submission-interrupted — Optional. The job was not completelysubmitted for some unforeseen reason, such as: (1) the serviceprovider crashed before the job was closed by the client, (2) theservice provider or the document transfer method crashed in somenon-recoverable way before the document data was entirelytransferred to the service provider, (3) the client crashed or failed toclose the job before the time-out period.

• job-outgoing — Optional. The service provider is transmitting thejob to the output device. Applicable job states: ‘pending.’

• job-hold-until-specified — Conditionally mandatory. Mandatory ifthe “job-hold-until” job attribute is implemented. The value of thejob’s “job-hold-until” attribute has specified a time period that hasnot yet arrived, so that the service provider shall not consider the jobas a candidate for processing. Applicable job states: ‘pending-held.’

• job-hold-until-resources-are-ready — Optional. At least one ofthe resources needed by the job, such as media, fonts, resourceobjects, etc., is not ready on any of the physical devices for whichthe job is a candidate. Usually such a condition is detected while thejob is in the ‘pending’ state. If a job starts processing and encountersa resource that is not ready, there are two possible implementations:

1. the device is stopped and no jobs can run until the resource(s) aremade ready, in which case the service provider shall keep the jobin the ‘processing’ state and shall add the ‘device-stopped’reason to the job’s “job-state-reasons” attribute (not the ‘job-hold-until-resources-are-ready’ value), OR

2. another job is found to use the device while the current job goesback to waiting for its turn and for the resources to be madeready, in which case the service provider shall change the job’s“job-state” attribute to ‘pending’ and add the ‘job-hold-until-resources-are-ready’ value to the job’s “job-state-reasons”attribute.

Applicable job states: ‘pending-held.’

• device-stopped-partly — Optional. This reason appears in all jobsin the ‘pending’ state when the value of the service provider’s“device-state-reasons” attribute contains the value ‘stopped-partly.’Applicable job states: ‘pending.’

• device-stopped — Mandatory. The output device is stopped. Thisreason appears in all jobs in the ‘pending’ and ‘processing’ stateswhen the value of the service provider’s “device-state” attribute is‘stopped.’ Applicable job states: ‘pending-held,’ ‘processing-stopped.’

• job-queued — Optional. Job is in the ‘processing’ state, but morespecifically, the printer has queued the document data.

4


• job-transforming — Optional. Job is in the ‘processing’ state, butmore specifically, the printer is interpreting document data andproducing another electronic representation.

• job-printing — Optional. The output device is marking media. Thisvalue is useful for printers which spend a great deal of timeprocessing when no marking is happening and then want to showthat marking is now happening. Applicable job states: ‘processing,’‘processing-stopped.’

• job-cancelled-by-user — Level 2 mandatory. The job was canceledby the user using the CancelJob request. Applicable job states:‘canceled.’

• job-cancelled-by-operator — Level 2 mandatory. The job wascanceled by the operator using the CancelJob request. Applicablejob states: ‘canceled.’

• job-canceled-at-device — Optional. The job was canceled by anunidentified local user (a user at a console at the device).

• aborted-by-system — Optional. The job (1) is in the process ofbeing aborted, (2) has been aborted by the system and placed in the‘aborted’ state, or (3) has been aborted by the system and placed inthe ‘pending-held’ state, so that a user or operator can manually trythe job again.

• processing-to-stop-point — Optional. The requester has issued aCancel-job operation or the printer object has aborted the job, but isstill performing some actions on the job until a specified stop pointoccurs or job termination/cleanup is completed.

This reason is recommended to be used in conjunction with the‘processing’ job state to indicate that the printer object is stillperforming some actions on the job while the job remains in the‘processing’ state. After all the job's job description attributes havestopped incrementing, the printer object moves the job from the‘processing’ state to the ‘canceled’ or ‘aborted’ job states.

• service-off-line — Optional. The printer is off-line and notaccepting any jobs. All ‘pending’ jobs are put into the ‘pending-held’ state. This situation could be true if the service’s or documenttransform’s input is impaired or broken.

• logfile-pending — Optional. The job’s logfile is pending filetransfer. Applicable job states: ‘canceled,’ ‘aborted,’ and‘completed.’

• logfile-transferring —Optional. The job’s logfile is beingtransferred. job states: ‘canceled,’ ‘aborted,’ and ‘completed.’

4


• job-completed-successfully —Mandatory. The job completedsuccessfully. Applicable job states: ‘completed.’

• job-completed-with-warnings —Mandatory. The job completedwith warnings. Applicable job states: ‘completed.’

• job-completed-with-errors —Mandatory. The job completed witherrors (and possibly warnings too). Applicable job states:‘completed.’

4.4.19. job-state-message


Value: text none NA Facility

This attributes specifies supplemental information about the job state inhuman readable text. It shall be set by the service provider.

4.4.20. job-submission-time


Value: dateTime none NA Facility

This attribute indicates the date and time of day when the job was firstcreated.

4.4.21. job-started-processing-time


Value: dateTime none N/A Facility

This attribute indicates the date and time of day that the job first startedprocessing.

4.4.22. job-completion-time


Value: dateTime none NA Facility

This attribute indicates the date and time of day when the job completed.

4.4.23. number-of-intervening-jobs


Value: integer none NA Facility

This attribute indicates the number of jobs that precede this job in thecurrent scheduled order. For efficiency, it is only necessary to calculate thisvalue when an operation is performed requesting this attribute.

4


NOTE — This attribute is necessary in case an end user requests only theirown jobs, and those jobs are interspersed in the waiting list with other jobs.A relative position indicator is needed to separate the jobs of the requesterfrom other jobs that cannot be identified in the response because of sitesecurity restrictions.

4.4.24. job-message-from-operator



This attribute provides a message from an operator, system administrator or“intelligent” process to indicate to the end user the reasons for modificationor other management action taken on a job.

4.4.25. device-URI


Value: uri none NA Administrator

This attribute contains the URI for the device. An administrator shalldetermine a device’s URI and shall set this attribute to that URI. The preciseformat of a device URI shall be implementation-dependent.

4.4.26. device-name


Value: name none NA Administrator

This attribute contains the name of the device. It is a name that is more userfriendly than the device-URI. An administrator shall determine a device’sname and shall set this attribute to that name. This name may be the last partof the device’s URI or it may be unrelated. In non-US-English natural-languages, a name may contain characters that are not allowed in a URI.

4.4.27. device-location


Value: text none NA Administrator

This attribute identifies the location of this device.

4


4.4.28. device-description



This attribute provides descriptive information about a device. This couldinclude things like: “This device can be used for printing colortransparencies for HR presentations,” or “Out of courtesy for others, pleaseprint only small (1-5 page) jobs at this device,” or even “This device is goingaway on July 1, 1998; please find a new device.”

4.4.29. device-more-info-site



This attribute contains a URI used to obtain more information about thisspecific device. The information obtained from this URI is intended for enduser consumption. Features outside the scope of job submission protocol canbe accessed from this URI. The information is intended to be specific to thisdevice instance and site services (e.g., job pricing, services offered, end userassistance). The manufacturer may initially populate this attribute.

4.4.30. device-driver-installer



This attribute contains a URI to use to locate the driver installer for thisdevice. This attribute is intended for consumption by automata. Themechanics of print driver installation is outside the scope of thisspecification. The manufacturer may initially populate this attribute.

4.4.31. device-make-and-model



This attribute identifies the make and model of the device.

4


• stopped — If a device receives a job (whose required resources areready) while in this state, such a job shall transit into the pendingstate immediately. Such a job shall transit into the processing stateonly after some human fixes the problem that stopped the device andafter jobs ahead of it complete printing. The device-state-reasonsattribute shall contain at least one reason (e.g. paper-jam) whichprevents it from either processing the current job or transiting apending job to the processing state. Note that, if a device controlsmore than one output device, the above definition implies that adevice is stopped only if all output devices are stopped.

NOTE — When a device controls more than one output device, it istempting to define “stopped” as when a sufficient number of output devicesare stopped and leave it to an implementation to define the sufficientnumber. But such a rule complicates the definition of stopped andprocessing. For example, with this alternate definition of stopped, a job canmove from idle to processing without human intervention, even though thedevice is stopped.

4.4.34. device-state-reasons



multi-valued See values below

NA Facility

This attribute supplies additional detail about the device’s state.

Each value shall have a prefix (first word) to indicate its level of severity.The three levels are:

• ‘report’ : (least severe) An implementation may choose to omit someor all reports. Some reports specify finer granularity about the devicestate; others serve as a precursor to a warning. A report shall containnothing that could affect the printed output.

• ‘warning’ : it has the prefix of “warning-”. An implementation maychoose to omit some or all warnings. Warnings serve as a precursorto an error. A warning shall contain nothing that prevents a job fromcompleting, though in some cases the output may be of lowerquality.

• ‘error’ : (most severe) it has no prefix (since most implementationswill only indicate errors).

An implementation shall include all errors. If this attribute contains one ormore errors, the device shall be in the stopped state.

If a device controls more than one output device, each value of this attributeshall apply to one more of the output devices. An error on one output devicethat does not stop the device as a whole appears as a warning in the device’sdevice-state-reasons attribute. Such a device’s device-state value may bestopped, even with no device-state-reasons that are errors.

4


The following standard values are defined:

• media-needed — A tray has run out of media.

• media-jam — The device has a media jam.

• paused — Someone has paused the device. In this state, a deviceshall not produce printed output, but it shall perform otheroperations requested by a client. If a device had been printing a jobwhen the device was paused, the device shall resume printing thatjob when the device is no longer paused and leave no evidence in theprinted output of such a pause.

• shutdown — Someone has removed a device from service, and it maybe powered down or physically removed. In this state, a device shallnot produce printed output, and unless the device is realized by a printserver that is still active, the device shall perform no other operationsrequested by a client, including returning this value. If a device hadbeen printing a job when it was shut down, the device need not resumeprinting that job when the device is no longer shut down. If the deviceresumes printing such a job, it may leave evidence in the printedoutput of such a shutdown; e.g., the part printed before the shutdownmay be printed a second time after the shutdown.

• connecting-to-device — The server has scheduled a job on thedevice and is in the process of connecting to a shared network outputdevice (and might not be able to actually start printing the job for anarbitrarily long time depending on the usage of the output device byother servers on the network).

• timed-out — The server was able to connect to the output device (oris always connected), but was unable to get a response from theoutput device in the time specified by the device’s device-timeout-period attribute.

• stopping — The device will be stopping in a while and will changeits reason to device-stopped. This reason is a non-critical, even for adevice with a single output device. When an output-device ceasesaccepting jobs, the device will have this state while the outputdevice completes printing.

• stopped-partly — When a device controls more than one outputdevice, this reason indicates that one or more output devices arestopped. If the reason is a report, fewer than half of the outputdevices are stopped. If the reason is a warning, fewer than all of theoutput devices are stopped.

• toner-low — The device is low on toner.

• marker-supply-low — The device is low on marker supply (ink,paint, etc.).

4


• spool-area-full — The limit of persistent storage allocated forspooling has been reached.

• cover-open — One or more covers on the device are open.

• interlock-open — One or more interlock devices on the printer areunlocked.

• door-open — One or more doors on the device are open.

• input-tray-missing — One or more input trays are not in the device.

• media-low — At least one input tray is low on media.

• media-empty — At least one input tray is empty.

• output-tray-missing — One or more output trays are not in the device.

• output-area-almost-full — One or more output areas are almostfull (e.g., tray, stacker, collator).

• output-area-full — One or more output areas are full. (e.g., tray,stacker, collator)

• marker-supply-low — The device is low on at least one markersupply (e.g., toner, ink, ribbon).

• marker-supply-empty — The device is out of at least one markersupply (e.g., toner, ink, ribbon).

• marker-waste-almost-full — The device marker supply wastereceptacle is almost full.

• marker-waste-full — The device marker supply waste receptacle is full.

• fuser-over-temp — The fuser temperature is above normal.

• fuser-under-temp — The fuser temperature is below normal.

• opc-near-eol — The optical photo conductor is near end of life.

• opc-life-over — The optical photo conductor is no longer functioning.

• developer-low — The device is low on developer.

• developer-empty — The device is out of developer.

• interpreter-resource-unavailable — An interpreter resource isunavailable (i.e., font, form).

4


4.4.35. device-state-message



This attribute specifies additional information about the device state inhuman-readable text, and it shall be set by the device (or the Administrator).When a device returns the value of this attribute to a client, the device shalllocalize the value of this attribute to be in the natural-language of the user,as specified by the Get-Attributes or Get-Jobs operation.

4.4.36. queued-job-count


Value: integer none NA Facility

This attribute contains a count of the number of jobs that are either pendingand/or processing, and shall be set by the device.

4.4.37. provider-state


Value: keyword See values below N/A facility

This attribute value can be queried for the value set by the facility to indicateits state. The defined values are:

• idle — facility is ready and accepts service requests, but has none toprocess at the moment.

• ready — facility is ready and accepts service requests, and isprocessing some now.

• busy — facility is able to only to accept query and report operations.None of the requests are serviced temporarily.

• down — requests are not serviced for an indefinite period.

4.4.38. service-is-accepting-jobs


Value: boolean none NA Administrator

This attribute determines whether the service is currently accepting jobs. Ifthe value is true, the service is accepting jobs. If the value is false, theservice is currently rejecting any jobs submitted to it.

NOTE — This value is independent of the device state and device-state-reasonsbecause its value does not affect the current job; rather, it affects future jobs. Thisattribute may cause the device to reject jobs when the device-state is idle ,or itmay cause the device to accepts jobs when the device-state is stopped.

4


4.4.39. service-message-from-the-operator



This attribute provides a message from an operator, system administrator or“intelligent” process to indicate to the end user information or status of theservice (i.e., why it is unavailable or when it is expected to be available).

4.5. Document Attributes

This section specifies the attributes that are associated with a document.These may come from a document repository or may be supplied by therequester.

4.5.1. document-name (name)


Value: name none NA requester

This attribute contains the name of the document used by the client toinitially identify the document.

4.5.2. document-content (octetstring)


Value: octetstring none NA requester

This attribute contains the document content when the requester supplies thedocument by value in the submission request. . When a requester prints byreference, the requester includes the "document-URI" attribute and nodocument content, therefore, this attribute shall be absent.

4


4.5.3. document-URI (uri)


Value: uri none NA requester

A reference to the contents of the document when the requester is supplyingthe document by reference.

If the requester supplies the document by value in the submission request,this attribute is just a comment.

4.5.4. document-format (mimeMediaType)


Preference Set by

Value: mimeMediaType registerredwith IANA

NA requester

This attribute identifies the document format of this document using one ofthe MIME media types registered by IANA.

Appendices


Appendix B — References

[1] ISO/IEC 10175-1 and 10175-2, (1996), Document Printing Application (DPA)

[2] IEEE POSIX 1387.4, System Administration: Part 4: Printing Interfaces, Draft (1994)or later

[3] X/Open Printing System Interoperability Specification (PSIS), Version 5.0 (1995) orlater

[4] IETF RFC 1759 Printer Management Information Base - MIB, (1995)

[5] New Document Alliance (NDA) Technical Framework, April 1997

[6] IDL Reference Manual,, Chapter 3, Common Object Request Broker Architecture andSpecification (CORBA), Revision 2. New York: John Wiley, August 1995b.

[7] IPP Protocol Specification, January 9, 1998,ftp://ftp.pwg.org/pub/pwg/IPP/ne_PRO/ipp-pro-980109.doc

Appendices


Appendix C —IDL Module

// IDL mode compiles with :// Iona Orbix Version v2.2 IDL compiler.// BAE Object Broker V3.0// Visigenic Visibroker for Java 3.0

#prefix “omg.org”#include <orb.idl>#include <Stream.idl>#include <Externalization.idl>#include <Collection.idl>

/* In the next module defines baseline attribute types */module CFDocServiceTypes{

typedef string DSText;typedef string<1023> DSText1023;

typedef string<63> DSNaturalLanguage;

struct DSTextWithLanguage{

DSNaturalLanguage override_lang;DSText text;

};

struct DSTextWithLanguage1023{

DSNaturalLanguage override_lang;DSText1023 text;

};

typedef string<255> DSName;

struct DSNameWithLanguage{

DSNaturalLanguage override_lang;DSName name;

};

typedef string<255> DSKeyword;typedef unsigned long DSEnum;typedef string DSUri;typedef string<1023> DSUri1023;typedef string<63> DSUriScheme;typedef string<63> DSCharSet;typedef sequence<octet> DSOctetString;typedef sequence<octet,1023> DSOctetString1023;typedef boolean DSBoolean;typedef unsigned long DSInteger;

struct DSRangeOfInteger{

DSInteger min;

Appendices


DSInteger max;};

struct DSDateTime{

DSInteger year;DSInteger month;DSInteger day;DSInteger hour;DSInteger minutes;DSInteger seconds;

};

struct DSRefInvocation{

DSKeyword context_name;DSKeyword invocation_name;

};

enum DSEnumValueClass{

enumerated, range,

referenced,grammar

};

enum DSLogicalExpression{

and,or,not

};

struct DSConstraintExpression{

DSRefInvocation constraint1;DSRefInvocation constraint2;DSLogicalExpression expr;

};

typedef any DSAny;

enum DSEnumDependency{

activate,deactivate,setdefault,ignore

};

struct DSReferenced{

DSName ref1;DSName ref2;

Appendices


};

};

module CFDocService{interface Interaction;

interface RequestInfo;interface QueryInfo;interface ReportInfo;

interface DocService;

enum InfoContext {ds_none,ds_doc_obj,ds_service,ds_description

};

enum Preference {ds_compulsory,ds_noncompulsory,ds_not_applicable

};

enum Status {ds_ignored,ds_overwritten,ds_error,ds_completed,ds_aborted,ds_processing,ds_initiated,ds_canceled,ds_unknown

};

struct CData {InfoContext c_type; string c_name; string c_status; string c_sinfo;};struct AggData { string agg_name; string agg_status; string agg_sinfo; };struct AttrData { string att_type; string att_name; Preference att_pref;

Status att_stat; string att_sinfo; };

enum ContextSwitch { main, auxiliary };

enum TransferStyle { ds_push, ds_pull };enum TransferType { ds_obj, ds_uri, ds_val };

union RequestInfoRef switch(TransferType) {case ds_obj:

RequestInfo or;case ds_uri:

string urir;case ds_val:

string val;};

union QueryInfoRef switch(TransferType) {

Appendices


case ds_obj:QueryInfo or;

case ds_uri:string urir;

case ds_val:string val;

};

union ReportInfoRef switch(TransferType) {case ds_obj:

ReportInfo or;case ds_uri:

string urir;case ds_val:

string val;};

typedef sequence<ReportInfoRef> ReportInfoRefList;

interface Interaction : CosStream::Streamable{

boolean known_name(in string c_name,in string attr_name);

boolean known_val(in string attr_type);};

interface DSIterator : CosCollection::Iterator {

boolean exists(in string name);boolean get_element_string(out string val);

};

interface DSIteratorFactory{

DSIterator create();};

interface RequestInfo : Interaction{

exception UnSupported {};

/*Context Management*/DSIterator GetCIterator(

in InfoContext c_type,in string c_name)raises (UnSupported);

/*Aggregation Management*/DSIterator GetAggIterator(

in string c_name,in string agg_name)raises (UnSupported);

/*Attribute Management*/DSIterator GetAttrIterator(

in string c_name,

Appendices


in string agg_name,in string att_name)raises (UnSupported);

/*Value Management*/DSIterator GetValIterator(

in boolean str_encoding,in string c_name,in string agg_name,in string att_name)raises (UnSupported);

};

interface RequestInfoFactory{

RequestInfo create( in string uuid,in ReportInfoRef ref,in string format,in string version,in string encoding);

};

interface QueryInfo : Interaction{


in ContextSwitch cs,in InfoContext c_type,in string c_name);


in ContextSwitch cs,in string c_name,in string agg_name);


in ContextSwitch cs,in string c_name,in string agg_name,in string att_name);


in ContextSwitch cs,in boolean str_encoding,in string c_name,in string agg_name,in string att_name);

};

interface QueryInfoFactory{

QueryInfo create( in string uuid,in string format,in string version,in string encoding);

Appendices


};

interface ReportInfo : Interaction{


in InfoContext c_type,in string c_name);


in string c_name,in string agg_name);


in string c_name,in string agg_name,in string att_name);


in boolean str_encoding,in string c_name,in string agg_name,in string att_name);

};

interface ReportInfoFactory{

ReportInfo create( in string uuid,in string format,in string version,in string encoding);

};

interface DocService{

exception TransferStyleNotSupported { };exception TransferTypeNotSupported { };exception TransferFormatNotSupported { };exception ContentError { ReportInfoRef ref;};

void request(in TransferStyle style,in string format,inout RequestInfoRef ref)raises (TransferStyleNotSupported,

TransferTypeNotSupported,TransferFormatNotSupported,ContentError);

void query(in TransferStyle style,in string format,inout QueryInfoRef ref)raises (TransferStyleNotSupported,

Appendices



void report(in TransferStyle style,in string format,inout ReportInfoRef ref)raises (TransferStyleNotSupported,


void poll(in TransferStyle style,in string format,inout QueryInfoRef qref,out ReportInfoRefList rrefs)raises (TransferStyleNotSupported,


};

interface DocServiceFactory{

DocService create(in CFDocServiceTypes::DSUri recover_data,in CFDocServiceTypes::DSUri config_data);

};

interface PFUriStreamFactory { exception InvalidUri {};

CosExternalization::Stream create( in CFDocServiceTypes::DSUri pf_uri) raises( InvalidUri); };};

Appendices


Appendix D — Mapping To IETF IPP

This appendix lists all of the IPP attributes and indicates the corresponding PF attribute, if any. Each IPP JobTemplate attribute is really three attributes:

1. “xxx” — attribute of the job object. These are supplied by the requesterin the request and stored on the Job object by the facility.

2. “xxx-default” — attribute of the printer: default value for the job whensubmitting to that printer

3. “xxx-supported” — attribute of the printer: supported values for the jobwhen submitting to that printer, conditioned by the document-formatvalue.

Operation attributes are supplied by the requester to control that operation.

IPP Attribute PF equivalent in body of PFspec

JOB TEMPLATE ATTRIBUTES:job-priority (integer(1:100 )) job-priorityjob-hold-until (type4 keyword | name) job-hold-untiljob-sheets (type4 keyword | name)multiple-document-handling (type2 keyword)copies (integer(1: 2** 31 - 1))finishings (1setOf type2 enum)page-ranges (rangeOfInteger)sides (type2 keyword)number-up (type2 keyword)media (type4 keyword)printer-resolution (resolution)print-quality(type2 enum)

OPERATION ATTRIBUTES:request-id (integer(1 : 2**31 - 1) interaction-idprinter-uri (uri) device-URIattributes-charset (charset) originator-charsetattributes-natural-language (naturalLanguage) originator-natural-languagerequesting-user-name (name) originatorjob-name (name) job-nameipp-attribute-fidelity (boolean) attribute.attribute_preference_typ

edocument-name (name) document-namedocument-uri (uri) document-URIdocument-format (mimeMediaType) document-formatdocument-natural-language (naturalLanguage)compression (type3 keyword)job-k-octets (integer(0 : 2** 31 - 1))job-impressions (integer(0 : 2** 31 - 1))job-media-sheets (integer(0 : 2** 31 - 1))

Appendices


JOB DESCRIPTION ATTRIBUTES

job-uri (uri) job-URIjob-id (integer(1: 2**31 - 1)job-more-info (uri)job-name (name) job-namejob-originating-user-name (name) job-originating-user-namejob-state (type1 enum) job-statejob-state-reasons (1setOf type2 keyword) job-state-reasonsjob-state-message (text) job-state-messagenumber-of-documents (0: 2**31 - 1)containing-printer-uri (uri)output-device-assigned (name)time-at-creation (integer) job-submission-timetime-at-processing (integer) job-started-processing-timetime-at-completed (integer) job-completion-timenumber-of-intervening-jobs (integer(0 : 2** 31 - 1)) number-of-intervening-jobsjob-message-from-operator (text) job-message-from-operatorcompression (type3 keyword)job-k-octets (integer(0: 2**31 - 1))job-impressions (integer(0: 2**31 - 1))job-k-octets-processed (integer(0: 2**31 - 1))job-k-octets-processed (integer(0 : 2** 31 - 1))job-impressions-completed (integer(0 : 2** 31 - 1))job-media-sheets-completed (integer(0 : 2** 31 - 1))attributes-charset (charset) job-charsetattributes-natural-language (naturalLanguage) job-natural-language

PRINTER DESCRIPTION ATTRIBUTES

printer-uri (uri) device-URIprinter-name (name) device-nameprinter-location (text) device-locationprinter-info (text) device-descriptionprinter-more-info (uri) device-more-info-siteprinter-driver-installer (uri) device-driver-installerprinter-make-and-model (text) device-make-and-modelprinter-more-info-manufacturer (uri) device-more-info-manfprinter-state (type1 enum) device-stateprinter-state-reasons (1setOf type2 keyword) device-state-reasonsprinter-state-message (text) device-state-messagecharset-configured (charset)natural-language-configured (naturalLanguage)printer-is-accepting-jobs (boolean) service-is-accepting-jobsqueued-job-count (integer(0 : 2** 31 - 1)) queued-job-countprinter-message-from-operator (text) service-message-from-the-

operatorpdl-override (type2 keyword)printer-up-time (integer(1:MAX))printer-current-time (dateTime)multiple-operation-time-out (integer(1: 2**31 - 1))

Appendices


Printer attributes indicate job default value:job-priority-default (integer(1:1 )) job-priorityjob-hold-until-default (type4 keyword) job-hold-untiljob-sheets-default (type4 keyword)multiple-document-handling-default (type keyword)copies-default (integer(1: ** 1 - 1))finishings-default (1setOf type enum)page-range-default (1setOf rangeOfInteger)sides-default (type keyword)number-up-default (type keyword)media-default (type4 keyword)printer-resolution-default (resolution)print-quality-default (type enum)document-format-default (mimeMediaType)

Printer attributes indicate supported value:job-priority-supported (1setOf integer(1:1 ))job-hold-until-supported (1setOf type4 keyword)job-sheets-supported (1setOf type4 keyword)multiple-document-handling-supported (1setOf typekeyword)copies-supported (1setOf integer(1: 2** 31 - 1))finishings-supported (1setOf type enum)page-ranges (1setOf rangeOfInteger)sides-supported (1setOf type keyword)number-up-supported (1setOf type keyword)media-supported (1setOf type4 keyword)printer-resolution-supported (1setOf resolution)print-quality-supported (1setOf type enum)operations-supported (1setOf type2 enum)charset-supported (1setOf charset)generated-natural-languages-supported (1setOfnaturalLanguage)document-format-supported (1setOfmimeMediaType)color-supported (boolean)reference-uri-schemes-supported (1setOf uriScheme)compression-supported (1setOf type keyword)job-k-octets-supported (1setOf integer(0 : 2** 31 -1))job-impressions-supported (1setOf integer(0 : 2** 31- 1))job-media-sheets-supported (1setOf integer(0 : 2**31 - 1))