Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipp-model-00.txt < prev next >

Wrap

Text File | 1997-03-26 | 226KB | 5,457 lines

INTERNET-DRAFT R. deBry IBM Corporation T. Hastings Xerox Corporation R. Herriot Sun Microsystems S. Isaacson Novell, Inc. P. Powell San Diego State University March 26, 1997 Internet Printing Protocol/1.0: Model and Semantics draft-ietf-ipp-model-00.txt Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard. Although DPA specifies the both end user and administrative features, IPP version 1.0 (v1.0)is focused only on end user functionality. deBry, Hastings, Herriot, Isaacson, Powell [Page 1] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 The full set of IPP documents includes: Internet Printing Protocol: Requirements Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Security Internet Printing Protocol/1.0: Protocol Specification Internet Printing Protocol/1.0: Directory Schema The requirements document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios which help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The requirements document calls out a subset of end user requirements which must be satisfied in the first version of IPP. Operator and administrator requirements are out of scope for v1.0. The model and semantics document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer object and a Job object. The Job object supports multiple documents per job. The security document covers potential threats and proposed counters to those threats. The protocol specification is formal document which incorporates the ideas in all the other documents into a concrete mapping using clearly defined data representations and transport protocol mappings that real implementers can use to develop interoperable client and server side components. Finally, the directory schema document shows a generic schema for directory service entries that represent instances of IPP Printers. This document is the "Internet Printing Protocol/1.0: Model and Semantics" document. deBry, Hastings, Herriot, Isaacson, Powell [Page 2] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 Table of Contents 1. Introduction............................................7 1.1 Conformance ..........................................8 1.1.1 Client Considerations .............................9 1.1.2 Server Considerations .............................9 2. Simplified Printing Model..............................10 3. IPP Objects............................................14 3.1 Printer .............................................14 3.2 Job .................................................17 3.3 Document Object .....................................18 3.4 Object Relationships ................................19 3.5 Object Attributes ...................................19 3.6 Object Identity .....................................21 4. IPP Operations.........................................22 4.1 Introduction ........................................22 4.2 Operation Semantics .................................23 4.2.1 Print Operation ..................................23 4.2.1.1 Print Request ................................24 4.2.1.2 Print Response ...............................25 4.2.2 Cancel Job Operation .............................25 4.2.2.1 Cancel-Job Request ...........................26 4.2.2.2 Cancel-Job Response ..........................26 4.2.3 Get Attributes Operation .........................26 4.2.3.1 Get-Attributes Request .......................27 4.2.3.2 Get-Attributes Response ......................27 4.2.4 Get Jobs Operation ...............................28 4.2.4.1 Get-Jobs Request .............................28 4.2.4.2 Get-Jobs Response ............................29 deBry, Hastings, Herriot, Isaacson, Powell [Page 3] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 5. Object Attributes......................................30 5.1 Attribute Syntaxes ..................................30 5.1.1 Attribute Extensibility ..........................34 5.1.2 Relationship of Job and Printer Attributes .......36 5.1.3 Attribute Value Tags .............................38 5.1.3.1 Tagged Printer Attributes ....................38 5.1.3.2 Tagged Job Attributes ........................39 5.2 Job Template (job-template) Attributes ..............39 5.2.1 Job Sheet Attributes (Set by Client/End User) ....40 5.2.1.1 job-sheets (type4 keyword) ...................40 5.2.2 Job Notification (job-notification) Attributes (Set by a Client/End User) ..................................41 5.2.2.1 notification-events (setOf type2 keyword) ....41 5.2.2.2 notification-addresses (setOf url) ...........42 5.2.3 Job Scheduling (job-scheduling) Attributes (Set by Client/End User) .......................................43 5.2.3.1 job-priority (integer(1:100)) ................43 5.2.3.2 job-hold-until (type4 keyword) ...............44 5.2.4 Job Production (job-production) Attributes (Set by Client/End User) .......................................45 5.2.4.1 multiple-documents-are (type1 keyword) .......47 5.2.4.2 best-effort (type2 keyword) ..................48 5.2.5 Document Production (document-production) Attributes (Set by Client/End User) ....................49 5.2.5.1 medium (setOf type2 keyword) .................49 5.2.5.2 number-up (type3Enum) ........................57 5.2.5.3 sides (type2 keyword) ........................58 5.2.5.4 printer-resolution (type2 keyword) ...........59 5.2.5.5 print-quality (type2 keyword) ................60 5.2.5.6 copies (integer(1:2**31 - 1)) ................61 5.2.5.7 finishing (setOf type2 keyword) ..............61 5.2.5.8 compression (type2 keyword) ..................63 5.2.6 Document Format Attributes (Set by Client/End User)63 5.2.6.1 document-format (type2 keyword) ..............63 5.2.7 Job Size (job-size) Attributes (Set by Client and Printer) ...............................................68 5.2.7.1 job-k-octets (integer(0:2**31 - 1)) ..........69 5.2.7.2 job-impressions (integer(0:2**31 - 1)) .......70 5.2.7.3 job-media-sheets (integer(0:2**31 - 1)) ......70 5.2.8 Number of Documents (Set by Printer) .............71 5.2.8.1 number-of-documents (integer(1:2**31 - 1)) ...71 5.3 Job Attributes Set by the Printer ...................71 5.3.1 Job Identification (job-identification) Attributes (Set by the Printer) ...................................71 5.3.1.1 job-URL (url) ................................71 deBry, Hastings, Herriot, Isaacson, Powell [Page 4] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 5.3.2 Job Owner (job-owner) Attributes (Set by a Printer)72 5.3.2.1 job-originating-user (name) ..................72 5.3.2.2 job-originating-host (name) ..................72 5.3.2.3 user-locale (type3 keyword) ..................72 5.3.2.4 job-name (name) ..............................73 5.3.3 Job Status (job status) Attributes (Set by Printer)73 5.3.3.1 job-state (type1 keyword) ....................73 5.3.3.2 job-state-reasons (setOf type2 keyword) .....76 5.3.3.3 job-state-as-text (text) .....................78 5.3.3.4 output-device-assigned (url) .................78 5.3.3.5 submission-time (dateTime) ...................79 5.3.3.6 number-of-intervening-jobs (integer(0:2**31 - 1)) ..................................................79 5.3.3.7 job-message-from-operator (text) .............79 5.3.3.8 completion-time (dateTime) ...................79 5.4 Document Attributes .................................80 5.4.1 Document Data (document-data) Attributes (Set by a Client/End User) .......................................80 5.4.1.1 document-name (name) .........................80 5.4.1.2 document-URL (url) ...........................80 5.4.1.3 document-content (octetString) ...............81 5.5 Printer Description (printer-description) Attributes81 5.5.1 Printer Identification (printer-identification Attributes (Set by the Administrator) ..................81 5.5.1.1 printer-URL (url) ............................81 5.5.1.2 printer-name (name) ..........................81 5.5.2 Printer Description Attributes (Set by the Administrator) .........................................82 5.5.2.1 printer-location (text) ......................82 5.5.2.2 printer-description (text) ...................83 5.5.2.3 printer-more-info-site (url) .................83 5.5.2.4 printer-driver-installer (url) ..............83 5.5.3 Printer Description Attributes (Set by the Manufacturer) ..........................................83 5.5.3.1 printer-make-and-model (text) ................83 5.5.3.2 maximum-printer-speed (integerUnits) .........83 5.5.3.3 printer-more-info-manf (url) .................84 5.6 Printer Status (printer-status)Attributes ...........84 5.6.1 Printer Status Attributes (Set by the Printer) ...84 5.6.1.1 printer-state (type1 keywordEnum) ............84 5.6.1.2 printer-state-reasons (setOf type2 keyword) ..86 5.6.1.3 printer-is-accepting-jobs (boolean) ..........89 5.6.1.4 printer-state-as-text (text) .................89 5.6.1.5 queued-job-count (integer(0:2**31 - 1)) ......90 deBry, Hastings, Herriot, Isaacson, Powell [Page 5] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 5.6.2 Printer Status Attributes (Set by the Administrator) .........................................90 5.6.2.1 printer-message-from-the-operator (text) .....90 5.7 Printer Behavior (printer-behavior) Attributes ......90 5.7.1 Printer Behavior Attributes (set by the Administrator) .........................................90 5.7.1.1 printer-locale (locale) ......................90 5.7.1.2 fonts-substitutions (setOf setOf font) .......90 5.7.1.3 scheduling-algorithm (type3 keyword) .........91 5.7.1.4 printer-fonts (setOf font) ...................91 6. IANA Considerations....................................91 7. Security Considerations................................92 8. References.............................................92 9. Author's Address.......................................93 deBry, Hastings, Herriot, Isaacson, Powell [Page 6] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 1. Introduction The Internet Printing Protocol (IPP) is an application level protocol that can be used for distributed printing on the Internet. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard. Although DPA identifies both end user and administrative features, the first version of IPP is focused only on the end user functionality. Section 2 is a comparison between the new IPP model and a generic description of the various solutions and architectures that exist in today's distributed printing products. This section shows a high level mapping between the complex set of inter-dependent distributed printing components and the IPP model. This new IPP model simplifies the back-end implementations by exposing only the objects, attributes, and operations that are essential for end user access and control of the print subsystem. When future versions of IPP include operator and administrator requirements, the model can be extended to support the appropriate objects, attributes, and operations. Section 3 introduces the full semantics of the new Printer, Job, and Document objects in the IPP model. It covers how instances of these objects are identified, named, and related to each other. Section 4 covers the operations which are part of the IPP model. These operations include: the Print, Cancel, Get Attributes, and Get Jobs operations. The Print and Get Jobs operations are performed by a Printer. The Get Attributes operation is performed by either a Printer or a Job. A Cancel Job operation is performed on a Job object. Section 5 describes the attributes, their syntaxes, and semantics which are part of the IPP model. Each object's attributes are described, and the attributes are grouped into logical groups to help clarify their relationships and meaning. Sections 6-9 cover security, technical references, and author contact information. deBry, Hastings, Herriot, Isaacson, Powell [Page 7] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 1.1 Conformance This specification uses the verbs: "shall", "should", "may", and "need not" to specify conformance requirements as follows: - "shall": indicates an action that the subject of the sentence must implement in order to claim conformance to this specification - "may": indicates an action that the subject of the sentence does not have to implement in order to claim conformance to this specification, in other words that action is an implementation option - "need not": indicates an action that the subject of the sentence does not have to implement in order to claim conformance to this specification. The verb "need not" is used instead of "may not", since "may not" sounds like a prohibition. - "should": indicates an action that is recommended for the subject of the sentence to implement, but is not required, in order to claim conformance to this specification. A conforming implementation shall implement all operations and objects defined in this document. Attributes are conditionally mandatory. This means that an implementation need not include an attribute if the attribute controls a feature that the implementation does not support. For example, a printer that can only print on one side need not implement the "sides" attribute. A printer that does not support any of the finishing attribute values, need not implement the "finishing" attribute. An implementation that does not allow for non-ready supported values in addition to ready values, need not implement a full set of possibly supported values. A printer with only a single input tray with only one media type in that tray need not implement the "media" attribute. Some of the attributes include values which are extensible. The set of attributes themselves are also extensible. Therefor, an IPP implementation (either client or server) shall support these extensions. Some implementations may choose to ignore private extensions, deBry, Hastings, Herriot, Isaacson, Powell [Page 8] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 others my be able to support these values. On the client side, this might mean displaying the values to the end user via some extensible user interface mechanism. On the server side, it might mean actually performing the semantic action implied by the new value. In either case, the operation shall not fail because either the client or server does not understand extended values or attributes. IPP allows for variations on attributes using a mechanism called "attribute tags" or "adornments" (see section 5.1.3). Clients can supply attributes with tags that represent variations on the normal (unadorned) attribute semantics. Servers can also respond with tagged attribute information. Tags are most applicable and useful in more sophisticated implementations. Therefor, all adornment tags are optional for conforming implementations. This allows for interoperability since the behavior of implementations which can not support the semantics of the adornment tags is consistent with the behavior implied by the absence of all tags. 1.1.1 Client Considerations IPP clients shall support all operations, objects, and attributes as defined in this document. However, there is no conformance requirements placed on the user interfaces provided by IPP clients or their applications. For example, one application might not allow an end user to submit multiple documents per job, while another does. One application might first query a Printer object in order to supply a graphical user interface (GUI) dialogue box with current supported and default values whereas a different application might not. A conforming client may choose to ignore any adornment tags it does not understand. 1.1.2 Server Considerations It is not required that a conforming server support all (standard) values of all supported attributes. For example, it is not required that a printer implement all finishing methods indicated by the standard values. The explicit requirement of the term "supported", with respect to one of the attributes that deal with printer functions or resources, is that the server shall deBry, Hastings, Herriot, Isaacson, Powell [Page 9] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 recognize the attribute and those values that are supported, and shall be able to respond to a query about which values that printer does, in fact, support. A conforming server shall ignore any adornment tags it does not understand. 2. Simplified Printing Model In order to a achieve its goal of realizing a workable printing protocol for the Internet, IPP is based on a simplified printing model which abstracts the many (often complex) real world printing solutions. Many of these include features, interfaces, and relationships that are beyond the scope of IPP. IPP has to run in a distributed computing environment where requesters of print services (clients, applications, PC drivers, etc.) cooperate and interact with print service providers. Although the underlying configuration may be a complex n-tier client/server system, an important simplifying step in the IPP model is to expose only the key objects and interfaces. The IPP model encapsulates the important elements into three simple objects: Printer (section 3.1) Job (section 3.2) Document (section 3.3) Each of these objects has a set of operations associated with it. These include: Printer: Print (section 4.2.1) Get Attributes (section 4.2.3) Get Jobs (section 4.2.4) Job object Get Attributes (section 4.2.3) Cancel Job (section 4.2.2) There are no operations defined for a Document object. All document information is accessed through a Job object and its operations. It is important, however, to understand that in real system implementations (which lie underneath the abstracted IPP model), there are other components of a print service which are not explicitly modeled in the IPP model. These components allow for additional operator deBry, Hastings, Herriot, Isaacson, Powell [Page 10] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 and administrator functionality. These components are illustrated in the following figure: +--------------+ | Application | +------+-------+ | o +..............+ \|/ | Spooler | / \ +..............+ End-User | +-----------+ +-----+ +..............+ Existing | Browser | | GUI | | Print Driver | Print +-----+-----+ +--+--+ +..............+ Client | | | | | +---+------------+---+ +----+----+ N D S | | IPP Client |<--| Gateway | O I E | +---------+----------+ +---------+ T R C | | I E U | F C R -------------- Transport -------- I T I C O T | --+ A R Y +--------+--------+ | T Y | IPP Server | | I +--------+--------+ | O | | N +.................+ | IPP Printer | Print Service | | +.................+ | | | Output Device(s) | --+ This figure shows that the abstraction of a Printer object not only supports the functionality of the actual output device but additionally supports (where implementation configuration requires) the spooling, scheduling, and multiple output device management functions often associated with a print server. In the IPP model, users take on the role of end users, operators, or administrators based on authentication and authorization mechanisms provided through the security service(s). Printers are registered as entries in the directory. End users find and select Printers based on some sort of filtered and context based searching using deBry, Hastings, Herriot, Isaacson, Powell [Page 11] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 the directory. The directory is used to store relatively static information about the Printer. This allows end users to search for and find Printers that match their search criteria (name, context, printer capabilities, etc.) All information about the Printer, both static and dynamic information, can be accessed directly from the Printer itself. The more dynamic information associated with a Printer includes state, currently loaded and ready media, number of jobs, errors, warnings, etc. Once an end user selects a Printer, the end user interacts with that Printer in order to determine status and capabilities of the Printer and then submits jobs to the Printer. When a job is submitted to the Printer, a Job object is created. The end user then interacts with this new Job to query its status and monitor the progress of the job. End users may also cancel the Job. The end user is able to register to receive certain events which are then routed using the notification service(s). It should be obvious, that not all existing or even future print subsystems conform to this model directly. The IPP model however, can be overlaid on top of any of these products and architectures. How does this IPP model fit on top of these systems? In order to answer that question we must first consider a generic model that allows us to describe the many different features and components of these various systems. Consider the figure above. Each distributed print service product will include elements from the following list: End Users: End Users are humans who submit print jobs. End users will issue IPP operation requests and receive IPP operation responses through an end user interface. GUI: A Graphical End User Interface developed specifically for interacting with an IPP Client. Browser: A World-Wide-Web Browser. IPP conforming systems will support access to print functions using standard Web Browsers. Applications: Application software which produces printer output and submits it for printing. Some applications generate printer page description languages directly, while others depend on operating system components, such as a Print Driver, to do so. deBry, Hastings, Herriot, Isaacson, Powell [Page 12] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 Spooler: A system component which stores print jobs prior to submitting them for printing. On the client side, a spooler allows the application to run asynchronously from the actual transmission and print operation. On the server side, a spooler allows the server to receive and store multiple jobs while printing. Spoolers are optional components. Print Driver: In some desktop operating systems, such as Windows, Print Drivers are used by the operating system to generate the actual PDL for a given device from an internal, device independent presentation format. This keeps the applications themselves from having to worry about generating device specific data streams for each possible output device. Print Drivers do not exist in all environments. IPP clients: IPP clients are computer network nodes with which humans, though a GUI or a command line, or programs interact in order to manipulate the distributed print service. An IPP client uses the IPP protocol to invoke IPP operations on another node. Each operation has arguments and results associated with it. The IPP client provides arguments which add information about the operation requested, and receives results which describe the status and outcome of the operation. Gateway: Gateways provide a mechanism for supporting the clients of existing print services, such as LPR. A gateway transforms the protocol of an existing client into IPP and vice-versa. Transport: The transport system and protocol used to carry IPP messages across the network. IPP assumes a reliable transport protocol. Notification Services: Notification services in the network provide a means for asynchronously communicating events such as completion of a print job back to an end- user. These notification services are used by IPP but are not included natively in the IPP protocol. Example would be include e-mail, HTTP POSTs, or any other similar service. Directory Services: Directory services in the network provide a means where IPP Printers can be advertised by registering with the directory. Although not mandatory in an IPP conforming system, the use of a directory deBry, Hastings, Herriot, Isaacson, Powell [Page 13] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 service is suggested in order to provide printer location services to end users. A generic directory schema for IPP Printers is described in "Internet Printing Protocol/1.0: Directory Schema". Security: The IPP protocol itself does not contain any unique security mechanisms, but rather it depends upon existing security systems, such as Secure Sockets Layer (SSL) to provide authentication, privacy and message integrity. IPP Server: An IPP Printer object is an abstraction of some print service provider. An Printer, by definition, supports the IPP protocol. The component that implements the protocol on behalf of the Printer is called an IPP Server. In real configurations, an IPP Server may be a component of a print server or an output device. Print Service: Print Services may be embedded in an output device or implemented in a separate system which is associated with an output device. The print service receives requests from the IPP client, performs the requested operation, and sends back results which describe the status and outcome of the operation requested. A print service normally provides queuing, job management, and device management functions. Output Devices: Output devices interpret the print data and generate some form of output. In the case of a laser printer, for example, this normally means rasterizing the print data and putting the resulting marks on paper. An output device may receive print data directly from a client or through a Print server. A specific implementation of a print service may not include all of the elements described here, and the physical packaging of elements is up to the implementation. For example, an output device may include a queue or a print server may include a rasterizer. 3. IPP Objects 3.1 Printer A major component of the IPP model is the Printer object. To the end user, the Printer object is an abstraction of deBry, Hastings, Herriot, Isaacson, Powell [Page 14] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 not only the functionality typically associated with an actual output device, but also the abstraction additionally supports (where necessary) the spooling, scheduling, and multiple output device management functions often associated with a print server. The capabilities and state of an IPP Printer are described by its attributes. Printer attributes are defined in the following categories: Job Template Attributes (section 5.2) Printer Description Attributes (section 5.5) Printer Status Attributes (section 5.6) Printer Behavior attributes (section 5.7) Operations which can be invoked on a printer include: Print (section 4.2.1) Get Attributes (section 4.2.3) Get Jobs (section 4.2.4) An instance of a Printer object implements IPP. Using the protocol, end users may query the attributes of the Printer, submit jobs to the Printer, determine subsequent states of submitted and queued jobs, and cancel their own print jobs. The realization of a Printer object may take on different forms for any given configuration of real components. However, the details of the configuration of real components must be transparent to the end user. Since a Printer object is an abstraction of a generic document output device, an IPP Printer object could be used to represent any real or virtual device with semantics consistent with the Printer object. For example, an instance of a Printer object could be used to front end a fax-out device, any kind of imager, or even a CD writer. Some examples of configurations supporting a Printer object include: 1) An output device, with no spooling capabilities 2) An output device, with a built-in spooler 3) A print server supporting IPP with one or more associated output devices 3a) The associated output devices may or may not be capable deBry, Hastings, Herriot, Isaacson, Powell [Page 15] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 of spooling jobs 3b) The associated output devices may or may not support IPP See the following figures for some examples on how to view Printer objects on top of other printing system configurations. The embedded case represents configurations 1 and 2. Configuration number 3 is represented by the hosted and fan-out figures below. deBry, Hastings, Herriot, Isaacson, Powell [Page 16] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 Legend: ##### indicates a Printer object which is either embedded in an output device or is hosted in a server. A Printer object may or may not queue/spool. any indicates any network protocol or direct connect, including IPP embedded printer: output device +---------------+ O +--------+ | ########### | /|\ | client |------------IPP------------># Printer # | / \ +--------+ | ########### | +---------------+ hosted printer: +---------------+ O +--------+ ########### | | /|\ | client |--IPP--># Printer #-any->| output device | / \ +--------+ ########### | | +---------------+ +---------------+ fan out: | | +-->| output device | any/ | | O +--------+ ########### / +---------------+ /|\ | client |-IPP-># Printer #-* / \ +--------+ ########### \ +---------------+ any\ | | +-->| output device | | | +---------------+ 3.2 Job A Job object is used to model a job. A job can contain one or more documents. The information required to create a Job object is sent in a Print operation from the end user via a client implementation to a Printer. The deBry, Hastings, Herriot, Isaacson, Powell [Page 17] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 Printer may perform some validation checks to verify that the job may indeed be processed. For example, the Print operation may request that the documents within the job be printed duplex (on both sides of the media). However, the Printer may not support such a feature. Once the Printer validates the submitted information, a Job object is created. The instance of the Job object is initialized with information from the Print request along with default information from the Printer. This document defines rules which define which pieces of information override other pieces of information and what to do in the event of conflicts between what is possible and what is requested. Job attributes are broken up into the following groups: Job Template Attributes optionally supplied by the client/end user Job Sheet Attributes (section 5.2.1) Job Notification Attributes (section 5.2.2) Job Scheduling Attributes (section 5.2.3) Job Production Attributes (section 5.2.4) Document Production Attributes (section 5.2.5) Document Format Attributes (section 5.2.6) Job Template Attributes set by Client and Printer Job Size Attributes (section 5.2.7) Job Template Attributes set by the Printer Number of Documents Attribute (section 5.2.8) Job Attributes set by the Printer Job Identification Attributes (section 5.3.1) Job Owner Attributes (section 5.3.2) Job Status Attributes (section 5.3.3) The following operations can be invoked on Jobs: Cancel Job (section 4.2.2) Get Attributes (section 4.2.3) 3.3 Document Object Documents consist of printable data and attributes which describe the data to be printed. In this version of the protocol only the document format attribute may be defined for individual documents. Document attributes include: Document Attributes (section 5.4) deBry, Hastings, Herriot, Isaacson, Powell [Page 18] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 Currently no operations are defined on documents. 3.4 Object Relationships Instances of objects within the system have relationships which must be maintained persistently along with the persistent storage of the object attributes. A Printer can represent one or more output devices. An output device can be represented by one or more Printer objects. A Printer can contain zero or more Job objects. A Job object is contained in exactly one Printer object. A Job object contains one or more Documents. If the Document is simply a reference to some print data stream, the reference may be used in multiple documents in the same Job or even in different Jobs. If the Document is not just a reference, but an actual stream of print data, it shall only be contained in one Document. 3.5 Object Attributes Each object type is defined by a set of attributes that support and describe the realization of each instance of an object. That is, a Printer object is defined as specific set of attributes that are associated with each instance of a Printer object. In the same manner, a Job object is defined by defining the set of attributes that will be associated with each instance of a Job object. These attributes are defined in section 5 of this document. Some attributes apply to only a Job object. Some apply to only a Printer object. In addition, there are some attributes that are shared between both Printer objects and Job objects. These attributes are defined in section 5.2. They are called Job Template attributes. When one of these attributes is part of a Job object, it specifies some end user job processing instruction. It describes "what is wanted" by the end user. When the attribute is part of a Printer object, it specifies what the printer is capable of . It describes "what is supported" by this instance of a Printer. Also, as a Printer attribute, , the attribute may have an optional default value which shall be used for Jobs which do not supply an attribute value . This default value describes "what will happen" if not supplied in the by the end user in the Print Request. deBry, Hastings, Herriot, Isaacson, Powell [Page 19] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 For example, one such Job Template attribute is the "job- priority" attribute. When this attribute is part of a Printer object, its value us a range of job priority values. This range indicates what job priorities are supported at this Printer. It may also have a default value that determines what the job priority will be if not supplied in the Print Request. When the "job- priority" attribute is included with the Print Request, it specifies the desired job priority for this job. If the request does not include the job-priority attribute, the Printer creates the Job object using the default value from Printer attribute. If the Print Request does supply a job priority value, the Printer must validate the user supplied job priority; perhaps the end user is requesting a job priority which is higher that what is allowed by the Printer. If the value in the print request is within the range of supported values, the request is accepted and the Job object is created using the value supplied by the end user. In this case, the Printer's default value is not used. If the value supplied in the request is outside the range of supported values, the request is rejected. Section 5.1 also introduces the notion of adornments on attribute values in order to handle some nuances associated with values of certain Job and Printer attributes. These adornments are tags that are associated with specific values in the attribute. For example, in a Printer object, one of the attributes is the medium attribute. A set of values in this attribute implies that the Printer is capable of printing jobs on those media types. However, there may be a distinction between a supported value that is "ready" and another that is "not-ready". This semantic information can be passed between the Printer and interested clients by using an "availability" tag which identifies each value as either being ready or not ready (even though they are all supported). Two important attributes that need to be mentioned here are the "multiple-documents-are" attribute and the "best- effort" attribute. The "multiple-documents-are attribute" is relevant only if a job consists of two or more documents. It controls finishing operations, job-sheet placement, and the order of documents when the copies attribute is specified. The end user uses this attribute in a Print Request to deBry, Hastings, Herriot, Isaacson, Powell [Page 20] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 control whether multiple documents in the job are intended to be finished or copied separately or as one job. The values for this attribute are: "single- document", "separate-documents-uncollated-copies", or "separate-documents-collated-copies". The "best-effort" attribute determines what to do if there is a conflict between what a client requests and what a Printer is capable of . Values for this attribute are: "substitute-as-needed" and "do-not-substitute". If the value for this attribute in a Print Request is "substitute-as-needed" then the end user desires the job be printed using substitutions by the Printer where needed in order to resolve conflicts. If the value is "do-not-substitute", then the end user desires that the job should not be processed unless every attribute value can be completely satisfied as specified. It is not expected that this attribute is used much. Many clients will submit a job with no attributes, and the Printer will use default values. Other clients will submit a job via a GUI which limits the attribute values to only those which are supported. A value of "substitute-as-needed: is useful in the GUI context only if an end user expects the job to be moved to another Printer and prefers a sub- optimal result to nothing at all. Also, an end user may be printing a pre-formatted document where it is not obvious that the client supplied attributes conflict with what is in the print data itself or even if the printer can satisfy the instructions already embedded in the pre- formatted document. This "best-effort" attribute is most useful in the case where an end user uses a command line interface to blindly request attributes that may not be supported. 3.6 Object Identity All instances of Printer and Job objects have an identifier attribute whose value is globally unique so that they can persistently and unambiguously referenced. The IPP model requires that these values be URLs as defined by RFC 1738 and RFC 1808. In addition to an identifier attribute, instances of Printer and Job objects may have a name. An object name need not be unique across all instances of all objects. The Printer name is chosen and set by an administrator. The Job name is created by the Printer using the name of the forst document in the job. In all cases, the name only has deBry, Hastings, Herriot, Isaacson, Powell [Page 21] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 local meaning, and is not constrained to be globally unique. To summarize, each instance of Printer and Job objects will have two identifying attributes: - xxx-URL: The globally unique locator for this object instance - xxx-name: The non-globally unique name for this object instance Document objects only have names, no identifiers. The "document-name" attribute is used to store the name of the Document. This name is just of interest within the context of a Job. It need not be globally unique. ISSUE: Do Documents need identifiers? 4. IPP Operations 4.1 Introduction Printers and Jobs each have a set of operations associated with it. End users, or programs invoke, these operations through interactions with an IPP client. The operations are: For a Printer object: Print (section 4.2.1) Get Attributes (section 4.2.3) Get Jobs (section 4.2.4) For a Job object: Cancel Job (section 4.2.2) Get Attributes (section 4.2.3). IPP objects are identified by URLs. When a client communicates with a remote IPP object, it sends an operation request to the URL for that object. Each request carries along with it the parameters and data required to perform the specified operation. Each request requires a response from the object indicating success or failure of the operation including response data and/or error messages. Details of the IPP protocol deBry, Hastings, Herriot, Isaacson, Powell [Page 22] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 are contained in "Internet Printing Protocol: Protocol Specification." It is assumed that URLs for IPP Printers are available to end users or programs who wish to invoke Printer operations. Although not mandatory, it is recommended that Printers be registered in a directory service which end users and programs can interrogate. "Internet Printing Protocol: Directory Schema" defines the attributes to be associated with an Printer entry in a directory service. ISSUE: We need to add "implementation notes." These are helpful hints of how to map these abstract concepts to real development efforts. Does it go here? 4.2 Operation Semantics In this section, the four IPP operations are described in terms of their contents and semantics. 4.2.1 Print Operation When an end user desires to submit a print job, the client sends a Print Request and receives a Print Response. The information in a Print Request along with any default information associated with the Printer is sufficient to create a Job object. An instance of a Job object contains all the information needed by the Printer to print one or more documents as a print job. When a Printer receives a Print Request, it either accepts or rejects the request. The Printer accepts the Print Request and creates a Job object if it is able to accept each attribute in the request, and it rejects the request and does not create a Job object if it rejects any attribute in the request. There are five cases to consider with respect to each attribute. - The client supplies an attribute value and it is among the values supported by the Printer: The job attribute is accepted. - The client supplies an attribute value but the attribute is syntactically bad: The Printer rejects the job. deBry, Hastings, Herriot, Isaacson, Powell [Page 23] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 - The client supplies an attribute value and a) the attribute value is not among the values supported by the Printer, or b) the printer does not specify the attribute: The job attribute is accepted only if the best-effort attribute is set to substitute-as-needed which allows the Printer to perform a best effort at processing the job rather than rejecting the job. If the job attribute is accepted, the Printer sets the value of the attribute to a reasonable value, which may be the Printer's default value if it is specified. - The client does not supply a value, but the Printer does: The attribute is accepted and when the Printer creates a Job object, the Printer uses its default value. If Printer is able to inspect the PDL and determine the value of the embedded attribute, it sets the value of the attribute to the embedded value and adorns it with the embedded tag. - Neither the client supplies an attribute value nor does the Printer define a default value: The print request is accepted, the Printer creates the Job object using defaults as defined in this specification. Issue: Can a Job object be created without some of the attributes, then as the Printer processes the Job, there is some default behavior as described either in this document or a supplied on an implementation defined basis. That is, if neither the client nor the Printer's default supplies a value for a job attribute, then the output device shall supply its own default value for that job attribute, if necessary, in order to produce output. 4.2.1.1 Print Request ISSUE: The client initially submits the request to a Printer URL. If a client submits a job in fragments, the initial submission returns a Job URL to which the client submits subsequent fragments. The following abstract data types are part of the Print Request: Job and A set of Job object and Document Document attributes as defined in section 5.2. Attributes This section may be empty. If so, Printer defaults are used. deBry, Hastings, Herriot, Isaacson, Powell [Page 24] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 Document Document content is optional and shall Contents not be included when a URL is provided in the document-URL attribute which points to the content. The simplest Print Request consists of a document contents and nothing else. 4.2.1.2 Print Response The following abstract data types are part of the Print Response: Job- A URL Used for all other operations on Identifier this Job. Job Status All job attributes belonging to the job- status group. The value of each attribute shall be from a snapshot taken sometime after the time the Printer receives the print request. Since any job affecting printer state information (printer-state-reasons) is reflected in the job-state and job-state-reasons, it is sufficient to return only job status attributes and no printer status attributes. Status status information including error status Message optional status message The simplest response consists of the job identifier, Job status, and operation status which is either an OK status or Error status. 4.2.2 Cancel Job Operation This operation allows a user to cancel one specific Print Job any time after the print job has been established on the Printer. Some pages may be printed before a job is terminated if printing has already started when the Cancel Job operation is received. Only the end user who is also the job originator (job-originating-user Job attribute) can cancel the job. deBry, Hastings, Herriot, Isaacson, Powell [Page 25] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 4.2.2.1 Cancel-Job Request The client submits the request to a Job URL. The following abstract data types are part of the Cancel Job Request: Message Optional message to the operator. 4.2.2.2 Cancel-Job Response The following information is part of the Cancel Job Response: Status status information including error status Message optional status message 4.2.3 Get Attributes Operation This operation allows an end user to obtain information from a Printer or Job object. The operation contains the set of attributes names and/or attribute group names that the requester is interested in. A corresponding attribute list is returned in the response with the appropriate attribute values filled in for each attribute (explicitly named or implicitly included in an attribute group) in the request. If the request to a Printer does not supply any attribute names, the Printer shall assume that the client is implicitly requesting the default groups of "printer- identification" and "printer-status". If the request to a Job object does not supply any attribute names, the Printer shall assume that the client is implicitly requesting the default groups of "job-identification", "job-owner", and "job-status". deBry, Hastings, Herriot, Isaacson, Powell [Page 26] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 4.2.3.1 Get-Attributes Request The client submits the request to a Job URL or Printer URL. The following abstract data types are part of the Get Attributes Request: Requested A set of attributes without values in Attributes whose values the requester is interested This is optional. format This is used only when a this request is sent to a Job and the end user is interested in production attributes. In that case, the client must the format in the request since the default value of the formats supported for the Printer might be "auto-sense", and a Printer's attributes or attribute values may differ for each format that it supports. This request value allows a client to specify a particular format. There shall be a way to specify certain groups of attributes, and it shall be possible to get more than one group. The groups shall be organized in the same way as this document and shall have the same names as the sections heads of the groupings. Each section and subsection contains the group name for the attributes in that section or subsection. For Printers and Job the special groups include: - "none": no attributes of the specified object. NOTE: none is primarily useful in Get Jobs, but can be used as a ping with Get Attributes. - "all": all attributes of the specified object. 4.2.3.2 Get-Attributes Response The following abstract data types are part of the Get Attributes Response: Result The requested attributes of the object Attributes with their current values, if the requester supplied any Requested deBry, Hastings, Herriot, Isaacson, Powell [Page 27] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 Attributes Status status information including error status Message optional status message A Printer may choose, for security reasons, not to return all attributes that a client requests. It may even return none of the requested attributes. In such cases, the status returned is the same as if the Printer had returned all requested attributes. The client cannot tell by such a response whether the requested attribute was present or absent on the Printer. 4.2.4 Get Jobs Operation This operation allows a client to retrieve Printer attributes and a list of print jobs belonging to the target Printer object. A list of Job attributes or attribute groups that the client is interested in seeing may be included in the request. If the request does not supply any Printer attributes, the Printer shall assume that the client is implicitly requesting the default groups: "printer-identification" and "printer-status". If the request does not specify any job attributes, the Printer shall assume the default groups: "job- identification", "job-status", "job-owner" and "job- size". The Printer object will be returned first, followed by the requested jobs in chronological order. This order is explicitly defined to be: oldest to newest with regard to completion time, either actual or expected. This operation is like Get Attributes, except that Get Jobs can return attributes from more than one object. 4.2.4.1 Get-Jobs Request The client submits the request to a Printer URL. The following abstract data types are part of the Get Jobs Request: deBry, Hastings, Herriot, Isaacson, Powell [Page 28] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 Job Owner This is the user-name. If the value is non-null, then the requester wants only those jobs whose job-originating-owner is the same as the specified user-name. If the value is null, then the requester wants all jobs. Job States A possibly empty set of job state values. If the set is not empty, then the requester wants only those jobs whose job-state is the same as one of the specified job state values, If the set is empty , then the requester wants all jobs that are pending or printing. Requested A set of attribute names (without Printer values) in whose values the requester is Attributes interested from the specified Printer Requested Job A set of attribute names (without Attributes values) in whose values the requester is interested from each of the jobs on the specified Printer. There shall be a way to specify certain groups of attributes, and it shall be possible to get more than one group. The groups are the same as for Get Attributes. 4.2.4.2 Get-Jobs Response The following information is part of the Get Jobs Response: Result The result includes zero or more objects Attributes each with zero or more attributes. Status status information including error status Message optional status message A Printer may choose, for security reasons, not to return all attributes that a client requests. It may even return none of the requested attributes. In such cases, the status returned is the same as if the Printer had returned all requested attributes. The client cannot tell deBry, Hastings, Herriot, Isaacson, Powell [Page 29] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 by such a response whether the requested attribute was present or absent on the Printer. 5. Object Attributes This section describes the attributes with their corresponding syntaxes and values that are part of the IPP model. The sections below show the objects and their associated attributes which are included within the scope of this protocol. Many of these attributes are derived from other relevant specifications: ISO/IEC 10175 DPA (Final, June 1996) RFC 1759 Printer MIB (Proposed Standard, May 1995) Internet-Draft: Printer MIB (Draft Standard in progress, December 1996) Internet-Draft: Job Monitoring MIB (I-D in progress, March 1997) Each attribute is uniquely identified in this document using a "keyword" in the section header describing that attribute. A keyword is a sequence of characters (length of 1 to 255) which consists of just letters, digits, hyphen ("-"), and underscore ("_"). With these restrictions, there will be a straight forward encoding of these keywords onto real values in the protocol specification. Not only are attributes uniquely identified with keywords, some attributes take on a syntax which is a set of keywords. This set of keywords represents the domain of the attribute. 5.1 Attribute Syntaxes The following table shows the basic syntax types that a client and server shall be able to handle. Table 1 Basic Type Description Comments text a sequence of For free form human characters: readable text length: 0 to intended for human 4096 consumption. deBry, Hastings, Herriot, Isaacson, Powell [Page 30] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 Basic Type Description Comments characters: any name a sequence of characters: some object via a length: 1 to user-friendly 255 characters: string, such as a For referencing any Printer name, a document name, a user name, or a host name. May include the SPACE character. NOTE - The protocol may need to provide means to quote the SPACE character if the protocol uses SPACE for other purposes. fileName a sequence of For referencing characters: some file. The length: 1 to limit is the same 1024 as POSIX and NT. characters: any keyword a sequence of For semantic characters: identifiers of length: 1 to entities in the 255 characters: abstract protocol letters, (specified in this digits, hyphen document). These ("-"), entities can be underscore attribute names or ("_") values of attributes, When a keyword is used to represent an attribute (its name), it must be unique within the full scope of IPP objects and attributes. When a keyword is used to deBry, Hastings, Herriot, Isaacson, Powell [Page 31] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 Basic Type Description Comments represent a value of an attribute, it must be unique just within the scope of that attribute. That is, a keyword can not be used for two different values of the same attribute to mean two different semantic ideas. However, the same keyword can be used across two or more attributes, representing different semantic ideas for each attribute. url a sequence of Universal Resource characters: as Locator defined in rfc1738 and ISSUE: do we keep rfc1808 URLs abstract here too and not define them in terms of rfcs? octetString a sequence of Used for opaque octets data, such as the document-content. boolean two values of like an keywordSet, true and false but there are only two values. NOTE: An application might use a checkbox for such a value. integer an integer each attribute value that is specifies the range in the range constraint from -2**31 to deBry, Hastings, Herriot, Isaacson, Powell [Page 32] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 Basic Type Description Comments 2**31 - 1 explicitly. dateTime a value that holds the date time and time to the absolute date and nearest second. integerSeconds an integer with a relative time implicit units of seconds integerPoints an integer with for measurment implicit units of computer points, i.e., 1/72 of an inch. integerUnits an integer with an integer value explicit units expressed in units ISSUE: we have two types with implicit units and one with explicit units where the units are specific for one attribute printer- speed. setOf X 0 or more for sets of values values of type X. 1setOf X 1 or more for sets of values values of type X. setWithDefaultOf X 0 or more for sets of values values of type where one is a X and a default default value value of type X 1setWithDefaultOf 1 or more for sets of values deBry, Hastings, Herriot, Isaacson, Powell [Page 33] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 Basic Type Description Comments X values of type where one is a X and a default default value value of type X withDefault X an explicit For values which default value are not restricted of type X. The but have a default. set of values is implicitly unrestricted. RangeWithDefaultOf a range of for a range of X value of type X values, such as with a default integers, where one value of type X value is the default. OR the below syntax type instead integerRangeWithDef an integer for a range of ault range with a integers where one default integer value is the value default. 5.1.1 Attribute Extensibility This document uses prefixes to the keyword basic syntax type in order to communicate extra information to the reader through its name. This extra information need not be represented in an implementation because it is unimportant to a client or printer. The table below describes the prefixes and their meaning Basic Type Prefix Comments keyword type1 someone must revise the IPP standard to add a new name. No private names are allowed. deBry, Hastings, Herriot, Isaacson, Powell [Page 34] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 Basic Type Prefix Comments keyword type2 implementers can, at any time, add new values by proposing them to the PWG for registration (or an IANA-appointed registry advisor after the PWG is no longer certified) where they are reviewed for approval.. IANA keeps the registry. Implementers can support private (unregistered) with a suitable distinguishing prefix, such as -xxx- where xxx is the company name registered with IANA for use in domain names. keyword type3 implementers can add new values by submitting a registration request directly to IANA, no PWG or IANA-appointed registry advisor review is required. Implementers can support private (un-registered) names with a suitable distinguishing prefix, such as -xxx- where xxx is the company name registered with IANA for use in domain names. keyword type4 an installation defined name that can be added to a local system by an administrator. Care must be taken by the administrator to see that keywords do not conflict with other keywords defined by the standard or as defined by the implementing product. There is no registration or approval procedure for type 4 keywords deBry, Hastings, Herriot, Isaacson, Powell [Page 35] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 5.1.2 Relationship of Job and Printer Attributes If a client can supply a Job attribute in a Print Request, there is a corresponding Printer attribute with the same name. The Printer attribute as a similar syntax type, however, the Printer attribute must additionally specify a set of supported values and an optional default value. The default value is used when creating a new Job object where the client has not supplied a value in the Print Request. These attributes, which can be in both Job and Printer objects, are called Job Template attributes and are fully defined in section 5.2 "Job Template Attributes". The table below shows the relationships between the syntax types of Job attributes and their corresponding Printer attributes. The syntax type of the Printer object is "constructed" using Job attribute type. For example, the table shows that if the basic syntax type of a Job attribute is "text" then the corresponding Printer attribute will be of type "withDefault text". Or, if the syntax type of the Job attribute is "integer", then the corresponding Printer attribute will be of type "rangeWithDefault of integer". The essence of what is shown in the table below is whether a context (Job attribute or Printer attribute) allows a single value or multiple values. Name of Job Printer Attribute syntax type Attribute Syntax Syntax text text withDefault text name name withDefault name keyword keyword setWithDefaultOf keyword or or setOf keyword 1setWithDefaultOf keyword or deBry, Hastings, Herriot, Isaacson, Powell [Page 36] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 Name of Job Printer Attribute syntax type Attribute Syntax Syntax 1setOfkeywo rd boolean boolean setWithDefaultOf boolean url url withDefault url integer integer rangeWithDefaultOf integer integerUnits integerUnit rangeWithDefaultOf s integer, setOf Units dateTime dateTime not needed because there are no job production attributes that a client can supply. integerSecon integerSeco rangeWithDefaultOf ds nds integerSeconds NOTE: if have integerUnits and no integerSeconds, we can replace rangeWithDefaultOf by integerRangeWithDefaul t. setOf X setOf X setWithDefaultOf X The Printer and the client shall be knowledgeable about each of the above syntax forms and know how the handle the values in a Job attribute and a Printer attribute. deBry, Hastings, Herriot, Isaacson, Powell [Page 37] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 5.1.3 Attribute Value Tags In order to handle some nuances associated with Job and Printer attribute values, attribute values can have tags associated with them. The following sections describe these tags. All tags are optional. Fully conforming implementations need not support them. 5.1.3.1 Tagged Printer Attributes Job Template attribute values in a Printer can have extra tags associated with them: - Availability: Some supported attributes shall have an availability value associated with each value. A client may choose to display values only with certain values of availability. Standard values are: "ready" and "not- ready". If an attribute value does not have this tag, it is by default "ready". "not-ready" means that the Printer can accept the job, but the Printer cannot complete the job without some external intervention to make the value ready. ISSUE: Should the following availability tags be added which help to more clearly specify some subtle meanings? These include "virtually-ready" (ready enough for the Printer to schedule the job since it the value is intended to always be ready, media in manual-feed trays would have this value), "on-order" (not-ready and cannot be made ready soon, but something is happening), or "special-order" (not-ready and cannot be made ready soon, nothing is happening). - Embedded-only: Some supported production attributes have an "embedded-only" tag associated with an attribute to indicate that the Printer supported this attribute when it is embedded in the document data, but it does not support it as an explicit attribute. The attributes that this tag is attached to varies according to the format specified in the Get Attributes operation. - Default Value: Supported attributes can have a default tag associated with the value that is default. If multiple values are tagged with a default value, a client shall use the first value that is tagged with default. If no values are tagged, then it assumes the first value in the supported list is the default value. deBry, Hastings, Herriot, Isaacson, Powell [Page 38] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 - Scheduling: If a printer uses this value for scheduling, then it associates this tag to indicate that it would like the attribute set when the job is submitted. The attribute can come back with or without the embedded tag. If an attribute does not have this tag, then the Printer will not use this attribute for scheduling. NOTE: the mostly likely attribute that a Printer would attach this adornment to is the media attribute. 5.1.3.2 Tagged Job Attributes Job attribute values set by a client and defined in section 5.2 "Job Template Attributes" can have the following extra tags associated with them: - Embedded: If an attribute has this tag, then the attribute value(s) are embedded in the document. The printer can use this information for scheduling, but it shall not use it to modify the document. This attribute cannot be associated with individual attribute values. - Default: If a attribute value has this tag, then the Printer shall ignore the Job attribute, if any, and shall use the Printer's default value for the attribute. Issue: Does the following imply too much about using "fan-in" for multiple default sets for a given output device? Note: it is the duty of an administrator to create a reasonable number of Printers feeding into each output device to handle user's expected defaults. For example, a Windows client will send a PostScript document with no attributes. For production attributes, a Printer's defaults must be "as-is". But other clients may want to force PostScript files to print two-sided. For those clients, there must be another printer whose sides default is "2-sided-long-edge". 5.2 Job Template (job-template) Attributes The following attributes can exist in both Jobs and Printers. When such an attribute is in a Job object, it identifies some desired behavior on this Job by the Printer. When it is in a Printer object, it constrains the values that the corresponding Job attribute can have deBry, Hastings, Herriot, Isaacson, Powell [Page 39] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 and it specifies a default value as well. The set of values in the Printer object are called the "supported values". These attributes form the attribute group called "job- template". The attributes are described below. The part in parenthesis after each attribute name is the name of the syntax as listed in Table 1 in section 5.1. A client can specify any of the attributes in this group in a Print Request. If a client GUI wishes to present a user with a list of values to choose from, then the client program should perform the Get Attributes operation to a Printer URL using the group job-template in order to get the complete list of attributes that a client can specify. Each attribute returned with the job- template group shall contain a list of supported values for the attribute and the Printer's default value. 5.2.1 Job Sheet Attributes (Set by Client/End User) The client shall specify these attributes to control the printing of job sheets. There is no group name for these attributes since there is only one attribute in the group. The client may also specify job sheet attributes in: Get- Attributes and Get-Jobs. 5.2.1.1 job-sheets (type4 keyword) 5.2.1.1.1 As a Job Attribute This job attribute determines what type of job-sheets (banner pages) the Printer shall print with the job. The standard values are: "none", and "default-sheet". The value "none" means that end user desires no job sheet be printed. The value "default-sheet" means that the end user desires a site specific default sheet defined by and administrator be printed. deBry, Hastings, Herriot, Isaacson, Powell [Page 40] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 5.2.1.1.2 As a Printer Attribute This printer attribute identifies the default job-sheet. It also identifies the job-sheet values supported by this printer, and the state of readiness for each job-sheet. To allow no job sheets, the system administrator shall include the value none as a value for the supported values. If the administrator's policy is not to support none, the Printer shall use the default-sheet value if the client supplies the none value but also indicates (through the best-effort attribute) that Printer could substitute values as needed in order to process the job. 5.2.2 Job Notification (job-notification) Attributes (Set by a Client/End User) The client shall specify these attributes to indicate events that the client is interested in, along with the notification address and method for performing the notification. These attributes form the attribute group called "job- notification". The client may also specify notification attributes in: Get-Attributes and Get-Jobs. 5.2.2.1 notification-events (setOf type2 keyword) 5.2.2.1.1 As a Job Attribute This job attribute specifies the events about which the end user want to be notified. Standard values within the set are: job-completion, job- canceled, job-problems and printer-problems. If this attribute contains the empty set, the Printer shall not notify. This value is useful if an administrator has set up a notification Printer default but the end user does not want notification. deBry, Hastings, Herriot, Isaacson, Powell [Page 41] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 If this attribute contains the value: job-completion, the Printer shall notify the client when the job containing this attribute completes with or without errors. If this attribute contains the value: job-canceled, the Printer shall notify the client when the job containing this attribute is canceled by the end-user or by the operator, or aborts before completion. If this attribute contains the value: job-problems, the Printer shall notify the client when this job has a problem while this job is printing. Problems include: paper jam and out-of-paper. If this attribute contains the value: printer-problems, the Printer shall notify the client when any job, including this job, is affected by a Printer problem (the printer has moved to the stopped state and there is a reason in the printer-state-reasons attribute) while this job is waiting to print or printing. Problems include: paper jam and out-of-paper. 5.2.2.1.2 As a Printer Attribute This printer attribute indicates the default value. It also indicates the values of the job and printer notification-events attribute supported by this Printer and the states of readiness for each value. This document does not specify how or whether an administrator can configure the information that a Printer sends with an event when a Printer notifies a user about the occurrence of an event. If this attribute is unspecified, then the Printer does not support notification. If this attribute is not contained in an instance of a Printer and the client supplies the attribute in the Print Request, the attribute in the Print Request is ignored. 5.2.2.2 notification-addresses (setOf url) This address specifies both the address and mechanism for delivery of notification events to the client. deBry, Hastings, Herriot, Isaacson, Powell [Page 42] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 The Printer shall use this attribute as the address for sending messages to a job submitter when an event occurs that the end user has registered an interest in. If the URL has a "mailto:" scheme, then email is used and the rest of the URL is used as the email address. If the URL has a "http:" scheme, then an HTTP method is used to add HTML formatted events to the end of the specified HTML file. 5.2.2.2.1 As a Job Attribute This job attribute specifies the method and addresses to which the Printer should send messages when events specified by the notification-events attribute occur. 5.2.2.2.2 As a Printer Attribute This Printer attribute's syntax type is "setOf urlScheme" so that an interested client shall know which URL schemes can be include in the notification-addresses attribute in the Print Request. 5.2.3 Job Scheduling (job-scheduling) Attributes (Set by Client/End User) The client shall specify these attributes to provide the Printer with information for the scheduling a print-job. These attributes form the attribute group called "job- scheduling". The client may also specify these attributes in: Get- Attributes and Get-Jobs. 5.2.3.1 job-priority (integer(1:100)) 5.2.3.1.1 As a Job Attribute This job attribute specifies a priority for scheduling the print-job. Printers that employ a priority-based scheduling algorithm use this attribute. deBry, Hastings, Herriot, Isaacson, Powell [Page 43] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 A higher value specifies a higher priority. The value 1 is defined to indicate the lowest possible priority (a job which a priority-based scheduling algorithm shall pass over in favor of higher priority jobs). The value 100 is defined to indicate the highest possible priority. Priority is expected to be evenly or "normally" distributed across this range. Among those jobs that are ready to print, a Printer shall print all jobs with a priority value of n before printing those with a priority value of n-1 for all n. The mapping of vendor-defined priority over this range is implementation-specific. 5.2.3.1.2 As a Printer Attribute The printer attribute specifies the default priority. It also specifies the supported range available to end- users. When setting up this attribute, an administrator might identify only a subset of the full range which is the range that the end user is authorized to use. There might be higher or lower priorities (outside the range defined for end users) available to operators or other privileged users. If this attribute is not contained in an instance of a Printer and the client supplies the attribute in the Print Request, the attribute in the Print Request is ignored. 5.2.3.2 job-hold-until (type4 keyword) 5.2.3.2.1 As a Job Attribute This job attribute specifies the named time period during which the Job print job shall become a candidate for printing. Standard values for named time periods are: "no-hold", "evening", "night", "weekend", "second-shift", "third- shift". An administrator shall associate allowable print times with a named time period. An administrator is encouraged to pick names that suggest the type of time period. If the value of this attribute specifies a time period that is in the future, the Printer shall add the job- deBry, Hastings, Herriot, Isaacson, Powell [Page 44] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 hold-until-specified value to the job's job-state-reasons attribute and shall not schedule the print-job for printing until the specified time-period arrives. When the specified time period arrives, the Printer shall remove the job-hold-until-specified value from the job's job-state-reason attribute and, if no other reasons remain, shall consider the job as a candidate for processing. If this job attribute value is the named value "no-hold", or the time period has already started , the job shall be a candidate for processing immediately. 5.2.3.2.2 As a Printer Attribute This printer attribute indicates the default value. It also indicates the values of the attribute supported by this printer. If this attribute is not contained in an instance of a Printer and the client supplies the attribute in the Print Request, the attribute in the Print Request is ignored. 5.2.4 Job Production (job-production) Attributes (Set by Client/End User) The client shall specify these attributes to affect the rendering, production and finishing of the documents in the job. Similar types of instructions may also be contained in the document to be printed. These attributes form the attribute group called "job- production". If there is a conflict between the value of one of these attributes, and a corresponding instruction in the document (either implicit or explicit), the value of the attribute shall take precedence over the document instruction. A job production attribute provides a client with a way to request some feature at print time that may not have been embedded within the document data when the document was created. A job production attribute also provides a client with a way to override a feature at print time deBry, Hastings, Herriot, Isaacson, Powell [Page 45] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 that was embedded within the document data when the document was created. Note: until companies that supply interpreters for PDL's, such as PostScript and PCL allow a way to specify overrides for internal job production instructions, a Printer may not be able to implement these attributes for some PDL's. A job production attribute tells a Printer what features the job needs. A program that translates document data to a Printer's PDL, and/or merges production attributes into the document data should add job production attributes to a job, using the "embedded" tag. Such a program may execute at a number of different points in time: 1. The program produces a final form document and stores these resource attributes in a file before the end-user submits the print job. 2. The program produces a final form document data stream when the end-user specifies "Print" to the application program (e.g., Windows GDI driver). 3. The program running in the context of the Printer or server translates a revisable or final form document into a PDL that the output device understands. For example, a job production attribute medium with the value of "letter" requests that a job be printed on letter paper, and gives information about what resources the job needs. For example, a job production attribute media with the values of "letter" and "ledger" and the tag "embedded" tell a Printer that the job needs letter and ledger paper, but gives no information about which pages use each medium_ that information is embedded in the document. A Printer may use these attributes to validate and schedule the print-job without interpreting the contents of the document. This provides the opportunity for a Printer to support a broad set of document formats yet still support fast efficient scheduling and validation of each job. If any of these attributes is unspecified, the Printer shall assume that the all resources required by the document of the type specified by the missing attributes deBry, Hastings, Herriot, Isaacson, Powell [Page 46] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 are ready, i.e., are available to the Printer and/or output device without human intervention. The client may specify these attributes in: Get- Attributes and Get-Jobs. The client may also specify job production-instruction attributes in: Get-Attributes and Get-Jobs. For all the attributes in this section, the default behavior if the Printer attribute is unspecified is that the document is printed with the output-device defaults, possibly overridden by whatever is in the document data, if anything. Each attribute which is of type keyword in this section also has a special value: "ignore" which is useful for a file type, such as PostScript, which the Printer may not allow changes to. 5.2.4.1 multiple-documents-are (type1 keyword) 5.2.4.1.1 As a Job Attribute This job attribute is relevant only if a job consists of two or more documents. It controls finishing operations, job-sheet placement, and the order of documents when the copies attribute exceeds 1. This attribute can have one of three values: single- document, separate-documents-uncollated-copies, separate- documents-collated-copies. If the files for the job are a and b and this attribute's value is single-document , then files a and b are treated as a single document for finishing operations. Also, there will be no slip sheets between files a and b. If more than one copy is made, the ordering must be a, b, a, b, .... If the files for the job are a and b and this attribute's value is separate-documents-uncollated-copies, or separate-documents-collated-copies or unspecified, then each file is treated as a single document for finishing operations. Also, a client may specify that a slip sheet deBry, Hastings, Herriot, Isaacson, Powell [Page 47] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 be between files a and b. If more than one copy is made, and the attribute's value is separate-documents- uncollated-copies or unspecified, the ordering is a, a, b, b, .... If more than one copy is made, and the attribute's value is separate-documents-collated-copies, the ordering is a, b, a, b, .... 5.2.4.1.2 As a Printer Attribute This printer attribute specifies the default value and the supported values. 5.2.4.2 best-effort (type2 keyword) This attribute determines what to do if there is a conflict between what a client requests and what a Printer is capable of . Values for this attribute are: "substitute-as-needed" and "do-not-substitute". 5.2.4.2.1 As a Job Attribute This job attribute specifies the Printer should do if the Printer can not support all other attribute values in other Job attributes. If the value is "substitute-as- needed" then the end user desires the job to be printed using substitutions by the Printer where needed in order to resolve conflicts. If the value is do-not-substitute then the end user desires that the job should not be processes unless every attribute value can be completely satisfied. If the client does not supply a value for this attribute in a print request, the Printer shall assume that the value is "do-not-substitute." Note: that best-effort is unlikely to be used much. Many clients will submit a job with no attributes, and the Printer will use default values. Other clients will submit a job via a GUI which limits the attribute values to those which are supported. Best-effort is useful in the GUI context only if a user expects the job to be moved to another printer and prefers a sub-optimal result to nothing at all. Best-effort is most useful in the case where an end-user uses a command line interface to request attributes that may not be supported. deBry, Hastings, Herriot, Isaacson, Powell [Page 48] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 5.2.4.2.2 As a Printer Attribute This printer attribute specifies supported and default behavior of the Printer if there is a conflict between Job attributes and Printer supported attributes, If the value is "substitute" then Printer is capable of doing some sort of best effort when there is a conflict, If the value is do-not-substitute then the Printer will reject all print requests that can not be completely satisfied. If the Printer object does not instantiate this attribute, the client shall assume that the value is do-not-subtitute. 5.2.5 Document Production (document-production) Attributes (Set by Client/End User) These attributes are similar to Job Production Attributes except that they may also be associated with a document and override the same attribute associated with the job. These attributes form the attribute group called "document-production". 5.2.5.1 medium (setOf type2 keyword) 5.2.5.1.1 As a Job Attribute This job attribute identifies the medium that the Printer shall use for all pages of the document regardless of what media are specified within the document. The values for medium include medium-names, medium-sizes, input-trays and electronic forms so that one attribute specifies the media. If a printer allows a client to specify a medium-name as the value of this attribute, such a medium-name implicitly selects an input-tray that contains the specified medium. If a printer allows a client to specify a medium-size as the value of this attribute, such a medium-size implicitly selects a medium-name which in turn implicitly deBry, Hastings, Herriot, Isaacson, Powell [Page 49] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 selects an input-tray that contains the medium with the specified size. If a printer contains two or more medium- names with the same medium-size, then a printer shall not include that medium-size in the list of supported values for this attribute and the printer shall reject jobs that request such a medium-size. If a printer allows a client to specify an input-tray as the value of this attribute, such an input-tray implicitly selects the medium that is in that input-tray at the time the job prints. This case includes manual- freed input-trays. If a printer allows a client to specify an electronic form as the value of this attribute, such an electronic form implicitly selects a medium-name which in turn implicitly selects an input-tray that contains the medium specified by the electronic form. The electronic form also implicitly selects an image that the Printer shall merge with the data from the document as its prints each page. When this attribute appears as a job attribute with the embedded tag, it may contain more than one value and it shall indicate all media required by the document. 5.2.5.1.2 As a Printer Attribute This printer attribute identifies the default value. It also identifies the media, media-sizes, input trays, and electronic forms supported by this printer, and indicates the state of availability for each medium resource. Standard values are defined(taken from ISO DPA and the Printer MIB): default The default medium for the output device iso-a4-white Specifies the ISO A4 white medium iso-a4-colored Specifies the ISO A4 coloured medium iso-a4- Specifies the ISO A4 transparent transparent medium iso-a3-white Specifies the ISO A3 white medium iso-a3-colored Specifies the ISO A3 coloured medium deBry, Hastings, Herriot, Isaacson, Powell [Page 50] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 iso-a5-white Specifies the ISO A5 white medium iso-a5-colored Specifies the ISO A5 coloured medium iso-b4-white Specifies the ISO B4 white medium iso-b4-colored Specifies the ISO B4 coloured medium iso-b5-white Specifies the ISO B5 white medium iso-b5-colored Specifies the ISO B5 coloured medium jis-b4-white Specifies the JIS B4 white medium jis-b4-colored Specifies the JIS B4 coloured medium jis-b5-white Specifies the JIS B5 white medium jis-b5-colored Specifies the JIS B5 coloured medium The following standard values are defined for North American media: na-letter-white Specifies the North American letter white medium na-letter- Specifies the North American colored letter coloured medium na-letter- Specifies the North American transparent letter transparent medium na-legal-white Specifies the North American legal white medium na-legal-colored Specifies the North American legal coloured medium The following standard values are defined for envelopes: iso-b4-envelope Specifies the ISO B4 envelope medium iso-b5-envelope Specifies the ISO B5 envelope medium iso-c3-envelope Specifies the ISO C3 envelope medium iso-c4-envelope Specifies the ISO C4 envelope medium deBry, Hastings, Herriot, Isaacson, Powell [Page 51] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 iso-c5-envelope Specifies the ISO C5 envelope medium iso-c6-envelope Specifies the ISO C6 envelope medium iso-designated- Specifies the ISO Designated long-envelope Long envelope medium na-10x13- Specifies the North American envelope 10x13 envelope medium na-9x12-envelope Specifies the North American 9x12 envelope medium monarch-envelope Specifies the Monarch envelope na-number-10- Specifies the North American envelope number 10 business envelope medium na-7x9-envelope Specifies the North American 7x9 inch envelope na-9x11-envelope Specifies the North American 9x11 inch envelope na-10x14- Specifies the North American envelope 10x14 inch envelope na-number-9- Specifies the North American envelope number 9 business envelope na-6x9-envelope Specifies the North American 6x9 inch envelope na-10x15- Specifies the North American envelope 10x15 inch envelope The following standard values are defined for the less commonly used media (white-only): executive-white Specifies the white executive medium folio-white Specifies the folio white medium invoice-white Specifies the white invoice medium ledger-white Specifies the white ledger medium quarto-white Specified the white quarto medium iso-a0-white Specifies the ISO A0 white medium iso-a1-white Specifies the ISO A1 white medium iso-a2-white Specifies the ISO A2 white medium deBry, Hastings, Herriot, Isaacson, Powell [Page 52] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 iso-a6-white Specifies the ISO A6 white medium iso-a7-white Specifies the ISO A7 white medium iso-a8-white Specifies the ISO A8 white medium iso-a9-white Specifies the ISO A9 white medium iso-10-white Specifies the ISO A10 white medium iso-b0-white Specifies the ISO B0 white medium iso-b1-white Specifies the ISO B1 white medium iso-b2-white Specifies the ISO B2 white medium iso-b3-white Specifies the ISO B3 white medium iso-b6-white Specifies the ISO B6 white medium iso-b7-white Specifies the ISO B7 white medium iso-b8-white Specifies the ISO B8 white medium iso-b9-white Specifies the ISO B9 white medium iso-b10-white Specifies the ISO B10 white medium jis-b0-white Specifies the JIS B0 white medium jis-b1-white Specifies the JIS B1 white medium jis-b2-white Specifies the JIS B2 white medium jis-b3-white Specifies the JIS B3 white medium jis-b6-white Specifies the JIS B6 white medium jis-b7-white Specifies the JIS B7 white medium jis-b8-white Specifies the JIS B8 white medium jis-b9-white Specifies the JIS B9 white medium jis-b10-white Specifies the JIS B10 white medium deBry, Hastings, Herriot, Isaacson, Powell [Page 53] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 The following standard values are defined for engineering media: a Specifies the engineering A size medium b Specifies the engineering B size medium c Specifies the engineering C size medium d Specifies the engineering D size medium e Specifies the engineering E size medium The following standard values are defined for input-trays (from ISO DPA and the Printer MIB): top The top input tray in the printer. middle The middle input tray in the printer. bottom The bottom input tray in the printer. envelope The envelope input tray in the printer. manual The manual feed input tray in the printer. large- The large capacity input tray in the capacity printer. main The main input tray side The side input tray The following standard values are defined for media sizes (from ISO DPA): iso-a0 Specifies the ISO A0 size: 841 mm by 1189 mm as defined in ISO 216 iso-a1 Specifies the ISO A1 size: 594 mm by 841 mm as defined in ISO 216 iso-a2 Specifies the ISO A2 size: 420 mm by 594 mm as defined in ISO 216 iso-a3 Specifies the ISO A3 size: 297 mm by 420 mm as defined in ISO 216 iso-a4 Specifies the ISO A4 size: 210 mm by 297 mm as defined in ISO 216 iso-a5 Specifies the ISO A5 size: 148 mm by 210 mm as defined in ISO 216 iso-a6 Specifies the ISO A6 size: 105 mm by 148 mm as defined in ISO 216 deBry, Hastings, Herriot, Isaacson, Powell [Page 54] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 iso-a7 Specifies the ISO A7 size: 74 mm by 105 mm as defined in ISO 216 iso-a8 Specifies the ISO A8 size: 52 mm by 74 mm as defined in ISO 216 iso-a9 Specifies the ISO A9 size: 37 mm by 52 mm as defined in ISO 216 iso-a10 Specifies the ISO A10 size: 26 mm by 37 mm as defined in ISO 216 iso-b0 Specifies the ISO B0 size: 1000 mm by 1414 mm as defined in ISO 216 iso-b1 Specifies the ISO B1 size: 707 mm by 1000 mm as defined in ISO 216 iso-b2 Specifies the ISO B2 size: 500 mm by 707 mm as defined in ISO 216 iso-b3 Specifies the ISO B3 size: 353 mm by 500 mm as defined in ISO 216 iso-b4 Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 iso-b5 Specifies the ISO B5 size: 176 mm by 250 mm as defined in ISO 216 iso-b6 Specifies the ISO B6 size: 125 mm by 176 mm as defined in ISO 216 iso-b7 Specifies the ISO B7 size: 88 mm by 125 mm as defined in ISO 216 iso-b8 Specifies the ISO B8 size: 62 mm by 88 mm as defined in ISO 216 iso-b9 Specifies the ISO B9 size: 44 mm by 62 mm as defined in ISO 216 iso-b10 Specifies the ISO B10 size: 31 mm by 44 mm as defined in ISO 216 na-letter Specifies the North American letter size: 8.5 inches by 11 inches na-legal Specifies the North American legal size: 8.5 inches by 14 inches executive Specifies the executive size (7.25 X 10.5 in) folio Specifies the folio size (8.5 X 13 in) invoice Specifies the invoice size (5.5 X 8.5 in) ledger Specifies the ledger size (11 X 17 in) quarto Specifies the quarto size (8.5 X 10.83 in) deBry, Hastings, Herriot, Isaacson, Powell [Page 55] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 iso-c3 Specifies the ISO C3 size: 324 mm by 458 mm as defined in ISO 269 iso-c4 Specifies the ISO C4 size: 229 mm by 324 mm as defined in ISO 269 iso-c5 Specifies the ISO C5 size: 162 mm by 229 mm as defined in ISO 269 iso-c6 Specifies the ISO C6 size: 114 mm by 162 mm as defined in ISO 269 iso- Specifies the ISO Designated Long designated size: 110 mm by 220 mm as defined in -long ISO 269 na-10x13- Specifies the North American envelope 10x13 size: 10 inches by 13 inches na-9x12- Specifies the North American envelope 9x12 size: 9 inches by 12 inches na-number-10- Specifies the North American envelope number 10 business envelope size: 4.125 inches by 9.5 inches na-7x9- Specifies the North American 7x9 envelope inch envelope size na-9x11- Specifies the North American envelope 9x11 inch envelope size na-10x14- Specifies the North American envelope 10x14 inch envelope size na-number-9- Specifies the North American envelope number 9 business envelope size na-6x9- Specifies the North American 6x9 envelope envelope size na-10x15- Specifies the North American envelope 10x15 envelope size monarch- Specifies the Monarch envelope envelope size (3.87 x 7.5 in) a Specifies the engineering A size: 8.5 inches by 11 inches b Specifies the engineering B size: 11 inches by 17 inches c Specifies the engineering C size: 17 inches by 22 inches d Specifies the engineering D size: 22 inches by 34 inches deBry, Hastings, Herriot, Isaacson, Powell [Page 56] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 e Specifies the engineering E size: 34 inches by 44 inches jis-b0 Specifies the JIS B0 size: 1030mm x 1456mm jis-b1 Specifies the JIS B1 size: 728mm x 1030mm jis-b2 Specifies the JIS B2 size: 515mm x 728mm jis-b3 Specifies the JIS B3 size: 364mm x 515mm jis-b4 Specifies the JIS B4 size: 257mm x 364mm jis-b5 Specifies the JIS B5 size: 182mm x 257mm jis-b6 Specifies the JIS B6 size: 128mm x 182mm jis-b7 Specifies the JIS B7 size: 91mm x 128mm jis-b8 Specifies the JIS B8 size: 64mm x 91mm jis-b9 Specifies the JIS B9 size: 45mm x 64mm jis-b10 Specifies the JIS B10 size: 32mm x 45mm 5.2.5.2 number-up (type3Enum) 5.2.5.2.1 As a Job Attribute This job attribute specifies the number of source page- images to impose upon a single side of an instance of a selected medium. 5.2.5.2.2 As a Printer Attribute This printer attribute identifies the default value and the number-up values supported by this printer.. The state of readiness for each number-up value is also included, though all number-up conversions should always be ready. In general, only certain numeric values are valid for this attribute and the value "none", depending upon the Printer implementation to which the print-request is directed. Standard values are: "none", "1", "2", "4". deBry, Hastings, Herriot, Isaacson, Powell [Page 57] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 This attribute primarily controls the translation, scaling and rotation of page images, but a site may choose to add embellishments, such as borders to each logical page. The value "none" shall not include any embellishments and shall place one logical page on a single side of an instance of the selected medium without any translation, scaling, or rotation. 5.2.5.3 sides (type2 keyword) 5.2.5.3.1 As a Job Attribute This job attribute specifies how source page-images are to be imposed upon the sides of an instance of a selected medium. When this attribute appears as a job attribute with the embedded tag, it may contain more than one value and it shall indicate all sides operations required by the document. 5.2.5.3.2 As a Printer Attribute This printer attribute indicates the default. It also indicates the values of the sides attribute supported by this printer and the states of readiness of each value. The standard values are: 1-sided, 2-sided-long-edge, 2- sided-short-edge. 1-sided imposes each consecutive source page-image upon the same side of consecutive media sheets. 2-sided-long-edge imposes each consecutive pair of source page-image upon front and back sides of consecutive media sheets, such that the orientation of each pair of source- pages on the medium would be correct for the reader as if for binding on the long edge. This imposition is sometimes called "duplex". 2-sided-short-edge imposes each consecutive pair of source page-image upon front and back sides of consecutive media sheets, such that the orientation of each pair of source-pages on the medium would be correct deBry, Hastings, Herriot, Isaacson, Powell [Page 58] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 for the reader as if for binding on the short edge. This imposition is sometimes called "tumble" or "head-to-toe". 2-sided-long-edge and 2-sided-short-edge work the same for portrait or landscape. That is, "head-to-toe" is "tumble" in portrait but "duplex" in landscape. "head- to-head" also switches between "duplex" and "tumble" when using portrait and landscape modes. 5.2.5.4 printer-resolution (type2 keyword) 5.2.5.4.1 As a Job Attribute This job attribute specifies the resolution that the Printer should use. When this attribute appears as a job attribute with the embedded tag, it shall indicate the printer resolution required by the document. 5.2.5.4.2 As a Printer Attribute This printer attribute indicates the default value. It also indicates the values of the printer-resolution- select attribute supported by this printer and their states of readiness. The state of readiness for each printer resolution is also included, though normally all printer-resolutions should always be ready. The values are type2Enums which represent single integers or pair of integers. The latter are to specify the resolution when the x and y dimensions differ. When two integers are specified, the first is in the x direction, i.e., in the direction of the shortest dimension of the medium, so that the value is independent of whether the printer feeds long edge or short edge first. The standard values are: res-100 res-200 res-240 res-300 deBry, Hastings, Herriot, Isaacson, Powell [Page 59] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 res-600 res-800 res-1200 res-1800 res-100x200 res-300x600 res-600x300 res-400x800 res-800x400 res-600x1200 res-1200x600 res-1800x600 5.2.5.5 print-quality (type2 keyword) 5.2.5.5.1 As a Job Attribute This job attribute specifies the print quality that the Printer should use. When this attribute appears as a job attribute with the embedded tag, it shall indicate the print-quality required by the document. 5.2.5.5.2 As a Printer Attribute This printer attribute indicates the default value. It also indicates the values of the printer-quality attribute supported by this printer and the states of readiness for each print-quality value. The standard values are defined in the printer-quality attribute. The standard values are: draft Lowest quality available on the printer normal Normal or intermediate quality on the printer high Highest quality available on the printer deBry, Hastings, Herriot, Isaacson, Powell [Page 60] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 5.2.5.6 copies (integer(1:2**31 - 1)) 5.2.5.6.1 As a Job Attribute This job attribute specifies the number of copies of the job to be printed. NOTE - The effect of this attribute on jobs and documents is controlled by the multiple-files-are job attribute. 5.2.5.6.2 As a Printer Attribute This printer attribute indicates the default value. It also specifies the minimum and maximum number of copies of a document that can be rendered by this printer in a single print-job. 5.2.5.7 finishing (setOf type2 keyword) 5.2.5.7.1 As a Job Attribute This job attribute identifies the finishing operation that the Printer should apply to each copy of each printed document in the job where the definition of a copy is controlled by the multiple-documents-are Job attributes. When this attribute appears as a job attribute with the embedded tag, it may contain more than one value and it shall indicate all finishing operations required by the job. 5.2.5.7.2 As a Printer Attribute This printer attribute identifies the default value. It also identifies the finishing operations supported by this Printer and states of availability for each finishing. Standard values for this attribute are: none Perform no finishing. deBry, Hastings, Herriot, Isaacson, Powell [Page 61] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 staple This indicates that staples are to be used to bind the document. The exact number and placement of the staples is site-defined; other finishing object attributes may be included to provide this information. staple-top- This indicates that one or more left staples should be placed on the top left corner of the document staple- This indicates that one or more bottom-left staples should be placed on the bottom left corner of the document staple-top- This indicates that one or more right staples should be placed on the top right corner of the document staple- bottom- staples should be placed on the This indicates that one or more right bottom right corner of the document saddle- This indicates that one or more stitch staples (wire stitches) are to be used to bind the document along the middle fold. The exact number and placement of the stitches is site- defined. edge-stitch This indicates that one or more staples (wire stitches) are to be used to bind the document along one edge. The exact number and placement of the staples is site- defined. punch This indicates that holes are required in the finished document. The exact number and placement of the holes is site-defined The punch specification may be satisfied (in a site- and implementation-specific manner) either by drilling/punching, or by substituting predrilled media. cover This value is specified when it is desired to select a non-printed (or pre-printed) cover for the document. This does not supplant the specification of a printed cover (on cover stock medium) by the document itself. deBry, Hastings, Herriot, Isaacson, Powell [Page 62] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 bind This indicates that a binding is to be applied to the document; the type and placement of the binding is site-defined. 5.2.5.8 compression (type2 keyword) This attribute identifies compression algorithms used for compression document data. Standard values for this attribute are: zip, tar, ... 5.2.5.8.1 As a Job Attribute This job attribute identifies the compression algorithm that has been applied to the document data. 5.2.5.8.2 As a Printer Attribute This printer attribute identifies the default value. It also identifies the compression algorithms supported by this Printer 5.2.6 Document Format Attributes (Set by Client/End User) There is no group name for these attributes since there is only one attribute in the group. 5.2.6.1 document-format (type2 keyword) 5.2.6.1.1 As a Job Attribute This job attribute identifies the document format of this document, and may be a per-document attribute. 5.2.6.1.2 As a Printer Attribute This printer attribute indicates default value. It also indicates the values of the attribute supported by this deBry, Hastings, Herriot, Isaacson, Powell [Page 63] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 printer and the states of readiness for each value. One possible supported and default value is "auto-sense". The following standard values have been reviewed with the Printer Working Group and are registered with IANA as part of the IETF Printer MIB project. The standard value assigned by the PWG starts with the four letters: "lang", in order to follow SNMP ASN.1 rules that all enum symbols shall start with a lower case letter. The keyword values in IPP shall be the same as the PWG standard values registered with IANA with the "lang" removed. The MIB (integer) value is included here for reference only, the MIB integer value shall not be used in IPP; the keyword value shall be used instead: keyword MIB Description Value val ue other 1 PCL 3 PCL. Starting with PCL version 5, HP-GL/2 is included as part of the PCL language. PCL and HP-GL/2 are registered trademarks of Hewlett- Packard Company. HPGL 4 Hewlett-Packard Graphics Language. HP-GL is a registered trademark of Hewlett-Packard Company. PJL 5 Peripheral Job Language. Appears in the data stream between data intended for a page description language. Hewlett-Packard Co. PS 6 PostScript Language (tm) Postscript - a trademark of Adobe Systems Incorporated which may be registered in certain jurisdictions IPDS 7 Intelligent Printer Data Stream Bi-directional print data stream for documents consisting of data objects (text, image, graphics, bar codes), resources (fonts, overlays) and page, form and finishing instructions. Facilitates system level device control, document tracking and error recovery throughout the print process. Pennant Systems, IBM deBry, Hastings, Herriot, Isaacson, Powell [Page 64] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 PPDS 8 IBM Personal Printer Data Stream. Originally called IBM ASCII, the name was changed to PPDS when the Laser Printer was introduced in 1989. Lexmark International, Inc. EscapeP 9 Epson Corp. Epson 10 DDIF 11 Digital Document Interchange Format Digital Equipment Corp., Maynard MA Interpress 12 Xerox Corp. ISO6429 13 ISO 6429. Control functions for Coded Character Sets (has ASCII control characters, plus additional controls for character imaging devices.) ISO Standard, Geneva, Switzerland LineData 14 line-data: Lines of data as separate ASCII or EBCDIC records and containing no control functions (no CR, LF, HT, FF, etc.). For use with traditional line printers. May use CR and/or LF to delimit lines, instead of records. See ISO 10175 Document Printing Application (DPA) ISO standard, Geneva, Switzerland MODCA 15 Mixed Object Document Content Architecture Definitions that allow the composition, interchange, and presentation of final form documents as a collection of data objects (text, image, graphics, bar codes), resources (fonts, overlays) and page, form and finishing instructions. Pennant Systems, IBM REGIS 16 Remote Graphics Instruction Set, Digital Equipment Corp., Maynard MA SCS 17 SNA Character String Bi- directional print data stream for SNA LU-1 mode of communications IBM SPDL 18 ISO 10180 Standard Page Description Language ISO Standard TEK4014 19 Tektronix Corp. deBry, Hastings, Herriot, Isaacson, Powell [Page 65] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 PDS 20 IGP 21 Printronix Corp. CodeV 22 Magnum Code-V, Image and printer control language used to control impact/dot- matrix printers. QMS, Inc., Mobile AL DSCDSE 23 DSC-DSE: Data Stream Compatible and Emulation Bi-directional print data stream for non-SNA (DSC) and SNA LU-3 3270 controller (DSE) communications IBM WPS 24 Windows Printing System, Resource based command/data stream used by Microsoft At Work Peripherals. Developed by the Microsoft Corporation. LN03 25 Early DEC-PPL3, Digital Equipment Corp. CCITT 26 QUIC 27 QUIC (Quality Information Code), Page Description Language for laser printers. Included graphics, printer control capability and emulation of other well- known printer . QMS, Inc. CPAP 28 Common Printer Access Protocol Digital Equipment Corp DecPPL 29 Digital ANSI-Compliant Printing Protocol (DEC-PPL) Digital Equipment Corp SimpleText 30 simple-text: character coded data, including NUL, CR , LF, HT, and FF control characters. See ISO 10175 Document Printing Application (DPA) ISO standard, Geneva, Switzerlan NPAP 31 Network Printer Alliance Protocol (NPAP). This protocol has been superseded by the IEEE 1284.1 TIPSI standard. (ref. LangTIPSI(49)). DOC 32 Document Option Commands, Appears in the data stream between data intended for a page description . QMS, Inc imPress 33 imPRESS, Page description language originally developed for the ImageServer line of systems. A deBry, Hastings, Herriot, Isaacson, Powell [Page 66] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 binary language providing representations for text, simple graphics (rules, lines, conic sections), and some large forms (simple bit-map and CCITT group 3/4 encoded).The language was intended to be sent over an 8-bit channel and supported early document preparation languages (e.g. TeX and TROFF). QMS, Inc. Pinwriter 34 24 wire dot matrix printer for USA, Europe, and Asia except Japan. More widely used in Germany, and some Asian countries than in US. NEC NPDL 35 Page printer for Japanese market. NEC NEC201PL 36 Serial printer language used in the Japanese market. NEC Automatic 37 Automatic PDL sensing. Automatic sensing of the interpreter language family by the printer examining the document content. Which actual interpreter language families are sensed depends on the printer implementation. Pages 38 Page printer Advanced Graphic Escape Set IBM Japan LIPS 39 LBP Image Processing System TIFF 40 Tagged Image File Format (Aldus) Diagnostic 41 A hex dump of the input to the interprete PSPrinter 42 The PostScript Language used for control (with any PDLs) Adobe Systems Incorporated CaPSL 43 Canon Print Systems Language EXCL 44 Extended Command Language Talaris Systems Inc LCDS 45 Line Conditioned Data Stream Xerox Corporatio XES 46 Xerox Escape Sequences Xerox Corporation PCLXL 47 Printer Control Language. Extended language features for printing, and printer control. Technical reference manual # TBD. Hewlett-Packard Co. ART 48 Advanced Rendering Tools (ART). deBry, Hastings, Herriot, Isaacson, Powell [Page 67] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 Page Description language originally developed for the Laser Press printers. Tehnical reference manual: "ART IV Reference Manual", No F33M. Fuji Xerox Co., Ltd. TIPSI 49 Transport Independent Printer System Interface (ref. IEEE Std. 1284.1) Prescribe 50 Page description and printer control language. It can be described with ordinary ASCII characters. Technical reference manual: "PRESCRIBE II Programming Manual" LinePrinte 51 A simple-text character stream r which supports the control codes LF, VT, FF and CR plus Centronics or Dataproducts Vertical Format Unit (VFU). language is commonly used on many older model line and matrix printers. IDP 52 Imaging Device Protocol Apple Computer. XJCL 53 Xerox Corp. 5.2.7 Job Size (job-size) Attributes (Set by Client and Printer) These attributes form the attribute group called "job- size". These attribute values all have adornments of either "total" or "printed" and they indicate the size of a job in various units. A client may set these attributes, but not an end-user. The Printer may set these attributes if the client does not. In both of these cases, the attribute value has the adornment of "total", which indicates the client and Printer's best estimate to the total. If a value has the adornment of "printed", then the value shall indicate the current number of octets, impressions or media-sheets (depending on the attribute) that have deBry, Hastings, Herriot, Isaacson, Powell [Page 68] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 been printed. Only the printer shall be allowed to set a value with the "printed" adornment. If a value has no adornment, then it implicitly has the adornment "total". The corresponding Printer attributes indicate the range of allowed values, but there is no explicit default. If the Job attribute is not specified and the Printer attribute is specified, the Printer shall either compute a value for the job attribute or leave it unspecified. An attribute is accepted if any one of the following conditions is satisfied: a) the Printer attribute is unspecified, b) the job attribute is unspecified, c) the job attribute is within the range specified by the Printer attribute. 5.2.7.1 job-k-octets (integer(0:2**31 - 1)) This attribute specifies the total size of the job in K octets, i.e., in units of 1024 octets. The value shall be rounded up, so that a job between 1 and 1024 octets shall be indicated as being 1K, 1025 to 2048 shall be 2, etc. This attribute is not intended to be a counter as in the Job Monitoring MIB; it is intended to be useful routing and scheduling information if known. 5.2.7.1.1 As a Job Attribute This job attribute is set by client on in the Print Request if it is known. It is set by the Printer once the Job object is created if the Printer is able to calculate this value. 5.2.7.1.2 As a Printer Attribute This Printer attribute specifies a support range for job sizes. A default value is not applicable for this attribute. deBry, Hastings, Herriot, Isaacson, Powell [Page 69] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 5.2.7.2 job-impressions (integer(0:2**31 - 1)) This job attribute specifies the total size of the job in impressions. This attribute is not intended to be a counter as in the Job Monitoring MIB; it is intended to be useful routing and scheduling information if known. 5.2.7.2.1 As a Job Attribute This job attribute is set by client on in the Print Request if it is known. It is set by the Printer once the Job object is created if the Printer is able to calculate this value. 5.2.7.2.2 As a Printer Attribute This Printer attribute specifies a support range for job sizes. A default value is not applicable for this attribute. 5.2.7.3 job-media-sheets (integer(0:2**31 - 1)) This job attribute specifies the total size of the job in media-sheets. This attribute is not intended to be a counter as in the Job Monitoring MIB; it is intended to be useful routing and scheduling information if known. 5.2.7.3.1 As a Job Attribute This job attribute is set by client on in the Print Request if it is known. It is set by the Printer once the Job object is created if the Printer is able to calculate this value. 5.2.7.3.2 As a Printer Attribute This Printer attribute specifies a support range for job sizes. A default value is not applicable for this attribute. deBry, Hastings, Herriot, Isaacson, Powell [Page 70] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 5.2.8 Number of Documents (Set by Printer) This group contains a single attribute which specifies the number of documents in the job. This group does not have a name since there is only one attribute in the group. The client need not set this attribute because, the Printer sets the value of this job attribute depending on the number of documents that the client supplies in the Print operation. The client may specify this attribute in: Get-Attributes and Get-Jobs. The printer attribute is set by an implementation and contains the range of values supported. Normally, it is either exactly 1 document or at least 1 document. The printer shall reject a job if the number of documents is not in the range of this attribute. 5.2.8.1 number-of-documents (integer(1:2**31 - 1)) This attribute specifies the number of documents in the job. There are document specific attributes (see section 5.4). 5.3 Job Attributes Set by the Printer These attributes form the attribute group called "job- set-by-printer". The Printer sets the value for each of these job attributes. A client may not set them. 5.3.1 Job Identification (job-identification) Attributes (Set by the Printer) These attributes form the attribute group called "job- identification". 5.3.1.1 job-URL (url) This attribute contains the URL for the job. deBry, Hastings, Herriot, Isaacson, Powell [Page 71] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 The Printer, on receipt of a new job, shall generate a URL which identifies the job on the Printer. The Printer, shall return the value of the URL job attribute as part of the PrintResult in the Print operation. The precise format of a job URL shall be implementation dependent. 5.3.2 Job Owner (job-owner) Attributes (Set by a Printer) The Print shall add all of these attributes to a job to provide information to identify a print-job. These attributes form the attribute group called "job- owner". The client may specify these attributes in the operations: Get-Attributes and Get-Jobs, but not in Print. 5.3.2.1 job-originating-user (name) This attribute specifies the user name of the person submitting the print job. The Printer shall set this attribute to the most authentic name that it can obtain from the protocol over which the operation was received from the client. 5.3.2.2 job-originating-host (name) This attribute identifies the originating host of the job. The Printer shall set this attribute to the most authentic host name it can obtain from the protocol over which the operation was received from the client. 5.3.2.3 user-locale (type3 keyword) This attribute identifies the locale of the job, i.e, the country, language, and coded character set. The Printer sets this attribute the most authentic value it can obtain from the protocol over which the operation was received from the client.. The Printer shall use this attribute to determine the locale for notification messages that it sends. deBry, Hastings, Herriot, Isaacson, Powell [Page 72] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 Issue: Is there a more standard syntax for locale? The standard values are listed under the document-locale attribute. ISSUE: specify the list of valid locales. 5.3.2.4 job-name (name) This attribute contains the name of the job. It is a name that is more user friendly than the job-URL. The Printer, on receipt of the job, shall generate a name which is the name of the first document in the job. This name comes from the document-name or document-URL depending on which attribute is specified. 5.3.3 Job Status (job status) Attributes (Set by Printer) These attributes form the attribute group called "job- status". The Printer shall add these attributes to a job when a client submits a job, and the Printer shall assign appropriate values to each such job-status attribute. The Printer uses these attributes to specify the job status before, during and after the processing of the print-job by the Printer. The client may specify job-status attributes in: Get- Attributes and Get-Jobs, but not Print. 5.3.3.1 job-state (type1 keyword) This attribute identifies the current state of the job. Standard values are: unknown The job state is not known, or is indeterminate. pending The job is waiting to start processing on a printer. Various job-reasons may keep a job from moving to the printing state. deBry, Hastings, Herriot, Isaacson, Powell [Page 73] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 processing The server is processing the job, or has made the job ready for printing, but the output device is not yet printing it, either because the job hasn't reached the output device or because the job is queued in the output device or some other spooler, awaiting the output device to print it. Or The server has completed processing the job and the output device is currently printing the job. That is, an output device is either printing pages of the job, or failing in its attempt to print pages of the job because of some wait state, such as, start-wait, end-wait, needs-attention, etc. The complete job state includes the detailed status represented in the printer's printer-state attribute. As with the printer state, let's let the reason make the distinction as to whether paper is being marked or the printer is just processing. Most printers won't bother with this nuance. terminatin The job has been canceled by a Cancel- g Job request or aborted by the server and is in the process of terminating. The job's job-state-reasons attribute contains the reasons that the job is being terminated. deBry, Hastings, Herriot, Isaacson, Powell [Page 74] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 retained The job is being retained at the server. The job has (1) completed successfully or with warnings or errors, (2) been aborted while printing by the server, or (3) been canceled by the Cancel-Job request before or during processing. The job's job-state-reasons attribute contains the reasons that the job has been retained. While in the retained state, all of the job's document data (and resources, if any) shall be retained by the server; thus a job in the retained state could be reprinted, using some means outside the scope of IPP V1.0. If a given implementation does not support this functionality, there is no need to support this value. deBry, Hastings, Herriot, Isaacson, Powell [Page 75] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 completed The job has: (1) completed successfully or with warnings or errors, (2) been aborted by the server while printing, or (3) been canceled by the Cancel- Job request, For case 1, "completed " only happens when all job media sheets have been properly stacked in the appropriate output tray or bin. The job's job-state-reasons attribute contains the reason(s) that the job has been completed. While in the completed state, a job's document data (and resources if any) need not be retained by the server; thus a job in the completed state could not be reprinted. The length of time that a job may be in this state, before transitioning to unknown, is implementation-dependent. However, servers that implement the completed job-state shall retain, as a minimum, the following attributes for any job in the completed state: job- identifier, job-originator, job-name, current-job-state, output-device- assigned, and job-state-reasons. The IPP protocol supports all values for job states, but Printers need only support those states which are appropriate for the particular implementation. 5.3.3.2 job-state-reasons (setOf type2 keyword) This attribute identifies the reason or reasons that the job is in the state that it is in (e.g., held, terminating, retained, completed, etc.). The printer shall indicate the particular reason(s) by setting the value of the job-state-reasons attribute. ISSUE: Should we change job-incomplete to job-spooling and adde job-queued, job-sent-to-printer and job-held? Job-queued is really the default. Job-held can only be deBry, Hastings, Herriot, Isaacson, Powell [Page 76] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 changed by an operator in an unspecified manner. Should a job move to the printing state when a spooler sends it to a printer or move to the printing state when marking starts. Should it depend on the printer as to whether it announces such nuances. We probably need a state transition diagram. The following standard values are defined: job-incomplete The job has been accepted by the server, but the Printer is waiting for the transfer of the remainder of the job. job-sending-to- Optional. The job is in the output-device pending state but is being transmitted to the output device. job-queued-in- Optional. The job is in the output-device pending state and is queued on the output device. job-printing The job-state is processing, and the printer is marking media. This attribute is optional and useful for printers which spend a great deal of time processing when no marking is happening. printer-stopped The printer is stopped. This reason appears in all jobs in the pending state when the value of the Printer's printer-state attribute is stopped. This reason appears in a job in the processing state when the output- device is stopped. printer-partly- Optional. This reason appears in stopped all jobs in the pending state when the value of the Printer's printer-state-reasons contains the value partly-stopped. job-hold-until- The value of the job's job-hold- specified until attribute has specified a time period that has not yet arrived, so that the Printer shall not consider the job as a candidate for processing. deBry, Hastings, Herriot, Isaacson, Powell [Page 77] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 required- At least one of the resources resources-not- needed by the job, such as media, ready fonts, resource objects, etc., is not ready on any of the physical printer's for which the job is a candidate. successful The job completed successfully. completion completed-with- The job completed with warnings. warnings completed-with- The job completed with errors errors (and possibly warnings too). cancelled-by-user The job was cancelled by the user using the CancelJob request. cancelled-by- The job was cancelled by the operator operator using the CancelJob request. aborted-by-system The job was aborted by the system. logfile-pending The job's logfile is pending file transfer. logfile- The job's logfile is being transferring transferred. 5.3.3.3 job-state-as-text (text) This attributes specifies the job-state and job-state- reasons in human readable text and it shall be set by the Printer. 5.3.3.4 output-device-assigned (url) This attribute identifies the Output Device to which the Printer has assigned this job. It is the printer-URL rather than the printer-name so that the Output-Device is not limited to be near the Printer. If an Output Device implements a Printer, the Printer need not set this attribute. If a Print Server implements a Printer, the value shall be empty until the Printer assigns an Output Device to the job. The value of the job's output-device-assigned attribute shall remain after the job has completed, so that end deBry, Hastings, Herriot, Isaacson, Powell [Page 78] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 users can determine the Output Device on which the job was printed. 5.3.3.5 submission-time (dateTime) This attribute indicates the date and time at which this job was accepted by the Printer. If the Printer does not support the notion of time, the attribute need not be stored as part of the job object. 5.3.3.6 number-of-intervening-jobs (integer(0:2**31 - 1)) This attribute indicates the number of jobs that are "ahead" of this job in the current scheduled order. For efficiency, it is only necessary to calculate this value when an operation if performed that requests this attribute. NOTE - This attribute is necessary since an end user may request just their own jobs and they need some relative position indicator if there are other jobs interspersed in the waiting list which are not returned in the response or cannot be because of site security policy restrictions. 5.3.3.7 job-message-from-operator (text) This attribute provides a message from an operator, system administrator or "intelligent" process to indicate to the end user the reasons for modification or other management action taken on a job. 5.3.3.8 completion-time (dateTime) This attribute indicates the date and time at which this job completed. This time is useful for jobs which are retained after printing. If the Printer does not support the notion of time, the attribute is not stored as part of the Job object. deBry, Hastings, Herriot, Isaacson, Powell [Page 79] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 5.4 Document Attributes 5.4.1 Document Data (document-data) Attributes (Set by a Client/End User) These attributes form the attribute group called "document-data". This group of attributes describes the document data for the job. These attributes also include the document data or reference it. All job attributes in other sections of this document occur only once per job and apply to all documents in a job. The client may specify document-data attributes in Print. The client must specify either the document-URL or document-content in Print. Except for document-content, the client may specify document-data attributes in: Get-Attributes, and Get- Jobs. 5.4.1.1 document-name (name) This attribute contains the name of the document used by the client to initially identify the document. If the client uses a URL, this attribute shall be absent. ISSUE: Do we need to add a document-file-name attribute for files that don't have a URL? 5.4.1.2 document-URL (url) This attribute contains the URL of the document if the client specified the document with a URL. If this attribute is specified, then document-content shall be unspecified. deBry, Hastings, Herriot, Isaacson, Powell [Page 80] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 5.4.1.3 document-content (octetString) This attribute contains the actual contents of the document. If this attribute is specified, then document-URL shall be unspecified. This attribute shall be used during the transmission of the Print operation over a network. A Printer shall save the document data to a file and reference it with the document-URL. A Get-Attribute or Get-Jobs operation shall always find that this attribute is unspecified. 5.5 Printer Description (printer-description) Attributes These attributes form the attribute group called "printer-description". 5.5.1 Printer Identification (printer-identification Attributes (Set by the Administrator) These attributes form the attribute group called "printer-identification". 5.5.1.1 printer-URL (url) This attribute contains the URL for the printer. An administrator shall determine a printer's URL and shall set this attribute to that URL. The precise format of a printer URL shall be implementation dependent. 5.5.1.2 printer-name (name) This attribute contains the name of the printer. It is a name that is more user friendly than the printer-URL. An administrator shall determine a printer's name and shall set this attribute to that name. This name may be the last part of the printer's URL or it may be unrelated. In non-US-English locales, a name may contain characters that are not allowed in a URL. deBry, Hastings, Herriot, Isaacson, Powell [Page 81] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 5.5.2 Printer Description Attributes (Set by the Administrator) A printer object may be realized in either a Print Server or Output Device. Note: How these attribute are set by an Administrator is outside the scope of this specification. A Printer Object in an Output Device contains a set of printer object attributes that represent an Output Device capable of rendering a document in visible form. Examples include electronic and electro-mechanical printers such as laser printers, ink-jet printers, and various kinds of impact printers, but may include other types of output devices such as microfiche imagers and plotters as well. A Printer Object in a Print Server may supply queuing, spooling, and scheduling for an Output device that does not queue or spool. A Print Server, in the most common case, controls exactly one downstream Output Device. The Print Server's Printer object has attributes whose values are the same as those of the Printer object in the downstream Output Device. A Printer Object in a Print Server may contain a set of printer object attributes that are the union of the Printer objects in the downstream Output Devices. This object extends the capabilities of an Output Device. For example, an administrator might define a single Print Server to represent all of the Output Devices of the same type and capability in a single location, associated with a particular server. A end user would normally send a print-job to a Print Server, and allow the Print Server to assign the job to a particular Output Device based on the relative load and availability of the printers under its control, thus providing a load balancing service. However, nothing precludes an administrator from configuring a print system so that an end user can send a print-job directly to an Output Device. The attributes defined in this section provide information about a particular Printer. 5.5.2.1 printer-location (text) This attribute identifies the location of this printer. deBry, Hastings, Herriot, Isaacson, Powell [Page 82] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 5.5.2.2 printer-description (text) This attribute identifies the descriptive information about the this Printer. This could include things like: "This printer can be used for printing color transparencies for HR presentations", or "Out of courtesy for others, please print only small (1-5 page) jobs at this printer", or even "this printer is going away on July 1, 1997, please find a new printer". 5.5.2.3 printer-more-info-site (url) This attribute contains a URL used to obtain more information about this specific printer. The information obtained from this URL is intended for end-user consumption. Features outside the scope of IPP can be accessed from this URL. The information is intended to be specific to this printer instance and site services. (e.g. job pricing, services offered, end user assistance) The manufacturer may initially populate this attribute 5.5.2.4 printer-driver-installer (url) This attribute contains a URL to use to locate the driver installer for this printer. This attribute is intended for consumption by automata. The mechanics of print driver installation is outside the scope of IPP. The manufacturer may initially populate this attribute. 5.5.3 Printer Description Attributes (Set by the Manufacturer) 5.5.3.1 printer-make-and-model (text) This attribute identifies the make and model of the printer. 5.5.3.2 maximum-printer-speed (integerUnits) This attribute indicates the maximum printer speed of the Printer in units of pages per minute, impressions per minute, lines per minute, and characters per second. A deBry, Hastings, Herriot, Isaacson, Powell [Page 83] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 job cannot control a Printer's speed, but a Printer Browser can use printer speed as a criteria. The standard units are a type2 setOf keyword : ppm, ipm, spm, lpm, and cps. These mean pages per minute, impressions per minutes, sides per minutes, lines per minute, and characters-per-second, respectively. 5.5.3.3 printer-more-info-manf (url) This attribute contains a URL used to obtain more information about this type of printer. The information obtained from this URL is intended for end-user consumption. Features outside the scope of IPP can be accessed from this URL. (e.g. latest firmware, upgrades, print drivers, optional features available) The information is intended to be germane to this printer without regard to site specific modifications or services. 5.6 Printer Status (printer-status)Attributes These attributes form the attribute group called "printer-status". 5.6.1 Printer Status Attributes (Set by the Printer) 5.6.1.1 printer-state (type1 keywordEnum) This attribute identifies the current state of the printer. The printer-state reasons attribute augments the printer-state attribute to give more detailed information about the printer state. The protocol shall support all values for printer states. A Printer shall continually keep this attribute set to the value in the table below which most accurately reflects the state of the Printer.. deBry, Hastings, Herriot, Isaacson, Powell [Page 84] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 The following standard values are defined: unknown The Printer state is not known, or is indeterminate. A Printer shall use this state only if it cannot determine its actual state. idle If a Printer receives a job (whose required resources are ready) while in this state, such a job shall transit into the processing state immediately. If the printer-state-reasons attribute contains any reasons, they shall be reasons that would not prevent a job from transiting into the processing state immediately, e.g. is toner-low. NOTE: if a Printer controls more than one output device, the above definition implies that a Printer is idle if at least one output device is idle. processing If a Printer receives a job (whose required resources are ready) while in this state, such a job shall transit into the pending state immediately. Such a job shall transit into the processing state only after jobs ahead of it complete printing. If the printer-state-reasons attribute contains any reasons, they shall be reasons that do not prevent the current job from printing, e.g. toner-low. NOTE: if a Printer controls more than one output device, the above definition implies that a Printer is processing if at least one output device is processing, and none is idle. deBry, Hastings, Herriot, Isaacson, Powell [Page 85] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 stopped If a Printer receives a job (whose required resources are ready) while in this state, such a job shall transit into the pending state immediately. Such a job shall transit into the processing state only after some human fixes the problem that stopped the printer and after jobs ahead of it complete printing. The printer-state-reasons attribute shall contain at least one reason, e.g. paper-jam, which prevents it from either processing the current job or transiting a pending job to the processing state. NOTE: if a Printer controls more than one output device, the above definition implies that a Printer is stopped only if all output devices are stopped. NOTE: in the case where a Printer controls more than one output device, it is tempting to define stopped as when a sufficient number of output devices are stopped and leave it to an implementation to define the sufficient number. But such a rule complicates the definition of stopped and processing. For example, with this alternate definition of stopped, a job can move from idle to processing without human intervention, even though the Printer is stopped. 5.6.1.2 printer-state-reasons (setOf type2 keyword) This attribute supplies additional detail about the printer state. Each value shall have an adornment to indicate its level of severity. The three levels are: report (least severe), warning and error (most severe). - "report": it has the adornment of "report". An implementation may choose to omit some or all reports. Some reports specify finer granularity about the printer state; others serve as a precursor deBry, Hastings, Herriot, Isaacson, Powell [Page 86] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 to a warning. A report shall contain nothing that could affect the printed output. - "warning": it has the adornment of "warning". An implementation may choose to omit some or all warnings. Warnings serve as a precursor to an error. A warning shall contain nothing that prevents a job from completing, though in some cases the output may be of lower quality. - "error": it has no adornment. An implementation shall include all errors. If this attribute contains one or more errors, printer shall be in the stopped state. ISSUE: Toner-low should be a warning because it allows printing to proceed, but in some printers, toner-low may also produce degraded output. Do we want a fourth category, perhaps severe-warning which allows a job to continue printing but with reduced quality? If a Printer controls more than one output device, each value of this attribute shall apply to one more of the output devices. An error on one output device that does not stop the Printer as a whole appears as a warning in the Printer's printer-state-reasons attribute. Such a Printer's printer-state value may be stopped even with no printer-state-reasons that are errors. The following standard values are defined: partly-stopped When a Printer controls more than one output device, this reason indicates that one or more output devices are stopped. If the reason is a report, fewer than half of the output devices are stopped. If the reason is a warning, fewer than all of the output devices are stopped. media-needed A tray has run out of media paper-jam The printer has a paper jam. deBry, Hastings, Herriot, Isaacson, Powell [Page 87] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 paused Someone has paused the Printer. In this state, a Printer shall not produce printed output, but it shall perform other operations requested by a client. If a Printer had been printing a job when the Printer was paused, the Printer shall resume printing that job when the Printer is no longer paused and leave no evidence in the printed output of such a pause . shutdown Someone has removed a Printer from service, and it may be powered down or physical removed. In this state, a Printer shall not produce printed output, and unless the Printer is realized by a print server that is still active, the Printer shall perform no other operations requested by a client, including returning this value. If a Printer had been printing a job when it was shutdown, the Printer need not resume printing that job when the Printer is no longer shutdown. If the Printer resumes printing such a job, it may leave evidence in the printed output of such a shutdown, e.g. the part printed before the shutdown may be printed a second time after the shutdown.. connecting-to- The server has scheduled a job on printer the Printer and is in the process of connecting to a shared network output device (and may not be able to actually start printing the job for an arbitrarily long time depending on the usage of the output device by other servers on the network). deBry, Hastings, Herriot, Isaacson, Powell [Page 88] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 timed-out The server was able to connect to the output device (or is always connected), but was unable to get a response from the output device in the time specified by the printer's printer-timeout-period attribute. stopping The printer will be stopping in a while and will change its reason to printer-stopped. This reason is a non-critical, even for a Printer with a single output device. When an output-device ceases accepting jobs, the Printer will have this state while the output device completes printing. 5.6.1.3 printer-is-accepting-jobs (boolean) This attribute determines whether the printer is currently accepting job. If the value is true, the printer is accepting jobs. If the value is false, the printer is currently rejecting any jobs submitted to it. Note: this value is independent of the printer state and printer-state-reasons because its value does not affect the current job; rather it affects future jobs. This attribute may cause the Printer to reject jobs when the printer-state is idle or it may cause the Printer to accepts jobs when the printer-state is stopped. 5.6.1.4 printer-state-as-text (text) This attributes specifies the printer-state, printer- state-reasons, printer-is-accepting-jobs in human readable text and it shall be set by the Printer. When a Printer returns the value of this attribute to a client, the Printer shall localize the value of this attribute to be in the locale of the user, as specified by the Get Attributes or Get Jobs operation. ISSUE: Give the syntax of this message in English. deBry, Hastings, Herriot, Isaacson, Powell [Page 89] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 5.6.1.5 queued-job-count (integer(0:2**31 - 1)) This attribute contains a count of the number of jobs that are either pending and/or processing and shall be set by the Printer. 5.6.2 Printer Status Attributes (Set by the Administrator) 5.6.2.1 printer-message-from-the-operator (text) This attribute provides a message from an operator, system administrator or "intelligent" process to indicate to the end user information or status of the printer, such as why it is unavailable or when it is expected to be available. 5.7 Printer Behavior (printer-behavior) Attributes These attribute specify the behavior of a printer. These attributes form the attribute group called "printer-behavior". 5.7.1 Printer Behavior Attributes (set by the Administrator) 5.7.1.1 printer-locale (locale) This attribute specifies the locale that the Printer operates in. The standard values are defined in the section on the document-locale attribute. ISSUE: reference the locales. 5.7.1.2 fonts-substitutions (setOf setOf font) This attribute specifies an appropriate substitute for a font that is advertised as supported in the fonts- supported attribute, even though the Printer doesn't actually have the font available. deBry, Hastings, Herriot, Isaacson, Powell [Page 90] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 This attribute consists of a set of font pairs: a font name and the font to use instead. If this attribute is unspecified, the Printer does not perform any font substitutions. 5.7.1.3 scheduling-algorithm (type3 keyword) This attribute indicates the current scheduling algorithm for this Printer. Standard values are: "none", "smallest-job-first", "time- received". 5.7.1.4 printer-fonts (setOf font) This attribute specifies what fonts are available at the Printer or accessible to the Printer. Documents may use these fonts without requiring that the fonts be downloaded with the document data. The standard values are font names. ISSUE: Should the IPP model include all information that is currently contained in printer definition files such as PostScripts printer definition (ppd) files? 6. IANA Considerations IPP is explicitly designed to be extensible. Additional attributes can be proposed to be registered by going through the type 2 or type 3 keyword process which will register their specification after approval with IANA. In addition specific implementation instances may support not only the basic protocol as defined in this specification, but may add vendor-specific private extensions by prefixing attribute-names with their company name registered with IANA for use in domains. See attribute syntax section. However, such private extensions shall not duplicate attribute semantics already in this specification. deBry, Hastings, Herriot, Isaacson, Powell [Page 91] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 7. Security Considerations NOTE: There is another Internet-Draft called "Internet Printing Protocol/1.0: Security." That document is being drafted and reviewed in parallel with this document. Before this document can become a formal RFC, any relevant issues from that document will be rolled into this one. A Printer may choose, for security reasons, not to return all attributes that a client requests. It may even return none of the requested attributes. In such cases, the status returned is the same as if the Printer had returned all requested attributes. The client cannot tell by such a response whether the requested attribute was present or absent on the Printer. 8. References [1] Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. [2] Berners-Lee, T, Fielding, R., and Nielsen, H., "Hypertext Transfer Protocol - HTTP/1.0", RFC 1945, August 1995. [3] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982. [4] Postel, J., "Instructions to RFC Authors", RFC 1543, October 1993. [5] ISO/IEC 10175 Document Printing Application (DPA), Final, June 1996. [6] Herriot, R. (editor), X/Open A Printing System Interoperability Specification (PSIS), August 1995. [7] Kirk, M. (editor), POSIX System Administration - Part 4: Printing Interfaces, POSIX 1387.4 D8, 1994. [8] Borenstein, N., and Freed, N., "MIME (Multi-purpose Internet Mail Extensions) Part One: Mechanism for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September, 1993. deBry, Hastings, Herriot, Isaacson, Powell [Page 92] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 [9] Braden, S., "Requirements for Internet Hosts - Application and Support", RFC 1123, October, 1989, [10] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" RFC 1179, August 1990. [11] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform Resource Locators (URL)", RFC 1738, December, 1994. 9. Author's Address Scott A. Isaacson Novell, Inc. 122 E 1700 S Provo, UT 84606 Phone: 801-861-7366 Fax: 801-861-4025 EMail: scott_isaacson@novell.com Tom Hastings Xerox Corporation 701 S. Aviation Blvd. El Segundo, CA 90245 Phone: 310-333-6413 Fax: 310-333-5514 EMail: hastings@cp10.es.xerox.com Robert Herriot Sun Microsystems Inc. 2550 Garcia Ave., MPK-17 Mountain View, CA 94043 Phone: 415-786-8995 Fax: 415-786-7077 Email: robert.herriot@eng.sun.com Roger deBry HUC/003G IBM Corporation P.O. Box 1900 Boulder, CO 80301-9191 Phone: (303) 924-4080 Fax: (303) 924-9889 Email: debry@vnet.ibm.com deBry, Hastings, Herriot, Isaacson, Powell [Page 93] draft-ietf-ipp-model-00.txt, expires September 26, 1997 INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997 IPP Mailing List: ipp@pwg.org IPP Mailing List Subscription: ipp-request@pwg.org IPP Web Page: http://www.pwg.org/ipp/ Other Participants: Devon Taylor, Novell, Inc. Mike MacKay, Novell, Inc. Peter Zehler, Xerox, Corp. Keith Carter, IBM Corporation Carl-Uno Manros, Xerox, Corp. Don Wright - Lexmark Steve Gebert - IBM Ray Lutz - Cognisys Mabry Dozier - QMS Lee Farrell - Canon Information Systems Hiroyuki Sato - Canon Pat Nogay - IBM Jim Walker - Dazel Jay Martin - Underscore Bill Wagner - DPI Stan McConnell - Xerox Bob Setterbo - Adobe Randy Turner - Sharp Rob Whittle - Novell Ron Bergman - Data Products Lloyd Young - Lexmark Andy Davidson - Tektronix Rick Landau - Digital David Kellerman - Northlake Software David Roach - Unisys Mike Timperman - Lexmark Chris Wellens - Interworking Labs Pete Loya - HP Bob Pentecost - HP Harry Lewis - IBM William Wagner - Digital Products Atsushi Yuki - Kyocera Rob Rhoads - Intel Jeff Barnett - IBM Jim Walker - Dazel Jeff Copeland - QMS Chuck Adams - Tektronix deBry, Hastings, Herriot, Isaacson, Powell [Page 94] draft-ietf-ipp-model-00.txt, expires September 26, 1997