INTERNET-DRAFT Roger deBry
IBM Corporation
T. Hastings
Xerox Corporation
R. Herriot
Sun Microsystems
Scott Isaacson
Novell, Inc.
November 1996
Internet Printing Protocol - IPP/1.0
draft-isaacson-ipp-info-00.txt
Expires May 27, 1997
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 Internet-Draft specifies an Internet Printing
Protocol (IPP) that is intended to be version 1.0. This
protocol is heavily influence by the semantic operations
and attributes defined in ISO/IEC 10175 Document Printing
Application (DPA) parts 1 and 3. It also incorporates
some of the implementation and interoperability lessons
deBry, Hastings, Herriot, Isaacson [Page 1]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
learned from other printing related standards such as
POSIX System Administration - Part 4 (POSIX 1378.4) and
X/Open A Printing System Interoperability
Specification (PSIS).
IPP is defined as a set of abstract data types and
operations. The operations are implemented using a simple
request and response mechanism built on top of HTTP. The
abstract data types are encoded as simple ASCII text
strings.
The IPP protocol covers only end user operations on basic
print service objects. Authentication is realized by
mechanisms outside the scope of the protocol, but the
protocol does introduce some access control functionality
so that only authorized end users are allowed to submit
print jobs to printers whose implementation and site
policy support access control. Also, the Cancel Job
operation requires some authentication so that jobs can
only be canceled by the end user who submitted the job.
Extended monitoring and management is possible through
other protocols such as the SNMP Printer MIB. In the
areas where there are no existing standards, some
proposed and emerging standards are being worked
(management, security, etc.). As these services become
more stable, this document (and hence the protocol) can
be updated to reflect the integration and relationships
with these other standards.
Table of Contents
1. Introduction 5
2. Distributed Printing 6
2.1 Generic Print System Components 6
2.2 IPP Components 7
3. IPP Objects 7
3.1 Printer 7
3.2 Job 9
3.3 Job Template 10
3.4 Object Relationships 10
3.5 Object Identity 10
4. Naming 11
4.1 Directory Services 12
4.2 Directory Entry Schema 12
4.2.1 Name 13
4.2.2 Description 13
4.2.3 Location 13
4.2.4 Maximum Print Quality 14
deBry, Hastings, Herriot, Isaacson [Page 2]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
4.2.5 Cost 14
4.2.6 Resolution 14
4.2.7 Color Supported 14
4.2.8 Fonts Supported 14
4.2.9 Maximum Speed 14
4.2.10 Device Id 14
4.2.11 Make and Model 15
4.2.12 Marker Type 15
4.2.13 Document Formats Supported 15
4.2.14 Sides Supported 15
4.2.15 Finishings Supported 16
4.3 Directory Entries Using LDAP 16
5. IPP Operations 17
5.1 HTTP Overview 18
5.2 IPP Operation Encoding 18
5.2.1 HTTP Request-Header Fields 19
5.2.2 HTTP Response-Header Fields 20
5.3 The Print Job 20
5.3.1 Print Job Object Header 21
5.3.2 Document Header 21
5.3.3 Document-Content Header 21
5.3.4 Job Attributes 22
5.3.5 Document Attributes 22
5.4 Operation Semantics 22
5.4.1 Print Operation 23
5.4.2 Cancel Job Operation 24
5.4.3 Get Attributes Operation 25
5.4.4 Get Jobs Operation 26
6. Object Attributes 27
6.1 Attribute Syntaxes 27
6.2 Job Attributes 30
6.2.1 Job Informational Attributes (Set by a Client/End
User) 31
6.2.2 Job Informational Attributes (Set by a Printer)31
6.2.3 Job Status Attributes (Set by Printer) 32
6.2.4 Job Sheet Attributes (Set by Client/End User) 38
6.2.5 Notification Attributes (Set by a Client/End
User) 38
6.2.6 Job Scheduling Attributes (Set by Client/End
User) 40
6.2.7 Job Production Attributes (Set by Client/End
User) 42
6.2.8 Attributes for Conversion of Text and HTML Files
(Set by Client/End User) 54
6.2.9 Job Resource Attributes (Set by the program that
produces or senses the PDL) 56
6.2.10 Number of Documents (Set by Printer) 59
6.2.11 Document Data (Set by a Client/End User) 60
deBry, Hastings, Herriot, Isaacson [Page 3]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
6.3 Operation Attributes (Set by Client) 61
6.3.1 operation-locale (type3Locale) 61
6.3.2 operation-notification-address (url) 62
6.3.3 operation-user-name (name) 62
6.3.4 operation-host-name (name) 62
6.4 Printer Attributes (Set by the Administrator) 62
6.4.1 printer-name (name) 63
6.4.2 printer-location (string) 63
6.4.3 printer-model (string) 63
6.4.4 printer-type (type2Enum) 63
6.4.5 printer-state (type1Enum) 64
6.4.6 printer-state-message (string) 66
6.4.7 message (string) 66
6.4.8 printer-job-templates (1#urlDefault) 66
6.4.9 locale (type3Locale) 66
6.4.10 notification-events (1#type2Enum) 66
6.4.11 notification-addresses (1#url) 67
6.4.12 end-user-acl (1#name) 67
6.4.13 maximum-printer-speed (positiveIntegerUnits) 67
6.4.14 fonts-substitutions (1#stringPair) 68
6.4.15 fonts-supported (1#stringState) 68
6.4.16 media-supported (1#nameState) 68
6.4.17 document-formats-supported (1#type2FormatState)68
6.4.18 numbers-up-supported (1#type3EnumState) 69
6.4.19 finishings-supported (1#type2EnumState) 69
6.4.20 sides-supported (1#type2EnumState) 69
6.4.21 print-qualities-supported (1#type2EnumState) 69
6.4.22 printer-resolutions-supported
(1#positiveIntegerCrossState) 70
6.4.23 code-sets-supported (1#type3EnumState) 70
6.4.24 off-peak-times-supported (1#type3EnumState) 70
6.4.25 events-supported (1#type2EnumState) 70
6.4.26 locales-supported (1#type3LocaleState) 71
6.4.27 job-sheets-supported (1#type3EnumState) 71
6.4.28 maximum-copies (positiveInteger) 71
6.4.29 maximum-job-octets (positiveInteger) 72
6.4.30 maximum-impressions (positiveInteger) 72
6.4.31 maximum-media-sheets (positiveInteger) 72
6.4.32 maximum-job-retention-period (deltaTime) 72
6.4.33 maximum-end-user-priority (type1Enum) 72
6.4.34 queued-job-count (cardinal) 73
6.4.35 scheduling-algorithm (type3Enum) 73
6.5 Job Templates 73
6.6 Conformance 73
7. Security Considerations 74
8. References 74
9. Author's Address 75
10. Appendix A: Sample IPP Operations 78
deBry, Hastings, Herriot, Isaacson [Page 4]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
10.1 Querying the printer 78
10.2 Print Operation - with print data included 79
10.3 Print Operation - with no data included 79
10.4 Querying the state of the job 80
10.5 Canceling a Job 80
10.6 Listing jobs on a Printer 81
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, which describes
a distributed printing service. DPA identifies the end
user and administrative roles associated with a
distributed printing service, and defines the set of
operations supported by the service. This IPP
specification (version 1.0) deals only with the end user
role. These ideas and concepts, when unified with other
Internet protocols and services, realize a distributed
print service for the Internet.
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.
deBry, Hastings, Herriot, Isaacson [Page 5]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
2. Distributed Printing
This document assumes 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 this protocol is
that the only object the requester of the print service
ever sees is a "printer". It is important, however, to
understand that in a real system, other components of a
print service exist.
2.1 Generic Print System Components
Every distributed print service, including those using
the Internet Printing Protocol, includes elements from
the following list.
- End Users: End Users are humans (or agents or
applications who work on behalf of a human) who submit
print jobs.
- Print clients: Print clients are computer network
nodes with which humans interact in order to manipulate
the distributed print service. A print client uses some
protocol to invoke print service operations on another
node. Each operation has arguments and results
associated with it. The print client provides arguments
which add information about the operation requested,
and receives results which describe the status and
outcome of the operation.
- Print servers: Print servers may be embedded in an
output device or implemented in a separate system which
is associated with an output device. The print server
receives requests from the print client and sends back
results which describe the status and outcome of the
operation requested. A print server normally provides
queuing, job management, and device management
functions.
- Queues: Print jobs may be queued or stored on a spool
prior to printing. This allows a print service provider
to accept one or more print jobs while the printer (or
printers) is busy processing another job. Queues, if
present, may be implemented in the client, in the
deBry, Hastings, Herriot, Isaacson [Page 6]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
server, in the output device, or in some combination of
the three.
- 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.
2.2 IPP Components
The print model defined by the Internet Printing Protocol
simplifies the user's view of the system components
described in the previous section by encapsulating the
important elements of the system into five simple
objects:
- End Users (no specific object definition via
attributes)
- Clients (no specific object definition via attributes)
- Printers (section 6.4)
- Print Jobs (section 6.2)
- Job Templates (section 6.5)
Clients use the following operations:
- Print (section 5.4.1)
- Cancel Job (section 5.4.2)
- Get Attributes (section 5.4.3)
- Get Jobs (section 5.4.4)
3. IPP Objects
This section describes the IPP objects.
3.1 Printer
One of the most significant objects in the IPP model is
the Printer. To the end user, the Printer object
represents the functionality of the actual output device
along with the queuing, job management, and device
deBry, Hastings, Herriot, Isaacson [Page 7]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
management functions often associated with a print
server. An IPP Printer object implements the Internet
Printing Protocol. 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 state of the Printer, 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.
In addition, a Printer is an abstraction for any document
Output Device. This means that a Printer could be used
to represent any real or virtual device which can support
the Printer operations and interfaces. For example, a
Printer could be used to front end a fax-out device, any
kind of imager, or even a CD writer.
Some examples of configurations containing IPP Printer
object include:
- An output device, with no spooling capabilities,
supporting IPP
- An output device, with a built-in spooler, supporting
IPP
-
-
- A print server with one or more associated output
devices with the print server supporting IPP.
- The associated output devices may or may not be
capable of spooling jobs
- The associated output devices may or may not support
IPP
See the following figures for some examples on how to
view IPP Printer objects on top of other printing system
models:
deBry, Hastings, Herriot, Isaacson [Page 8]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
Legend:
##### indicates an IPP Printer object which is
either embedded in an output device or is
hosted in a server. An IPP 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. However, there are no separate
document objects. The impact of this is that there are
deBry, Hastings, Herriot, Isaacson [Page 9]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
no attributes that pertain to one document in a job but
not to others, except for a single attribute that
specifies the document data, its location, and its
format. Note: In future versions, documents may become
separate objects with attributes whose scope and
application are different from the corresponding job
attributes.
Job attributes are broken up into the following groups:
- Job Informational (sections 6.2.1, 6.2.2)
- Job Status (section 6.2.3)
- Job Sheet (section 6.2.4)
- Notification (section 6.2.5)
- Job Scheduling (section 6.2.6)
- Job Production (section 6.2.7)
- Conversion of Text Files (section 6.2.8)
- Job Resources (section 6.2.9)
- Number of Documents (section 6.2.10)
- Document Attributes (6.2.11)
3.3 Job Template
A Job Template object is used to model job defaults. A
Job Template is essentially a set of job attributes that
initialize a newly created job object.
Issue: The notion of Job Template needs more work.
3.4 Object Relationships
Instances of objects within the system have relationships
which must be maintained persistently along with the
persistent storage of the objects themselves. A Printer
can contain zero or more Job objects. Therefore, a job
object is contained in exactly one Printer object. A Job
object contains one or more Documents.
A Printer object is associated with zero or more Job
Template objects.
3.5 Object Identity
All instances of all objects have an identifier attribute
that makes them unique so that they can be unambiguously
referenced.
deBry, Hastings, Herriot, Isaacson [Page 10]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
The following objects have the following mandatory
identifier attributes:
Object Identifier Containing
Object
Printer printer-name None
Job job-identifier Printer
Job job-template- None
Template name
4. Naming
Clients identify Printer objects by using an HTTP type
URL. For example, a URL for a Printer object named
"printer-1" whose network node's domain name is
"some.domain.com", might look like:
http://some.domain.com/printer-1
In this case, the URL identifies the use of the HTTP
protocol. The Printer is located at the node identified
by the DNS name "some.domain.com" and "printer-1" is the
name of the Printer.
Another example is the following URL:
http://1.2.3.4:nnn/printer-2
In this case, the URL identifies the use of the HTTP
protocol. The Printer is located at the node identified
by the IP address of "1.2.3.4" using port nnn for the
HTTP server, and "printer-2" is the name of the Printer.
(The actual value of nnn is to be assigned by IANA as
part of this standards project).
It is not necessary to expose the Job Template objects
that might be associated with a given printer as separate
objects. They can be exposed in two ways through URL
naming.
- The Job Template can be hidden from the end user by a
URL that represents just the Job Template name (but
does not expose the Printer object name) as the two
URLS
1)
http://some.domain.com/two-sided-printer, and
2)
http://some.domain.com/draft-printer.
deBry, Hastings, Herriot, Isaacson [Page 11]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
These look like two different Printers , but underneath
they represent the same Printer object, but that
Printer object has two associated Job Templates and
each is exposed through a different URL for the same
Printer object. Each one of the Job Templates specified
by a URL would contain a different Job Template default
attribute set. One Job Template would contain the
defaults for two-sides printing and the other would
contain the defaults for draft printing.
- The Job Template can be exposed along with the name of
the Printer object directly in the URL as in:
1)
http://some.domain.com/hr-printer/resumes
2)
http://some.domain.com/hr-printer/1040forms
In this case there are "resumes" and "1040forms" Job
Templates associated with the "hr-printer" Printer.
This specification establishes, through IANA, a new well
known port, port nnn, for the use of IPP over HTTP. The
purpose of this new well known port would be to
distinguish printing from non-printing content. While any
acceptable HTTP content could be inter-mixed over HTTP
well known port 80, only IPP printing would be acceptable
on port nnn.
4.1 Directory Services
IPP does not require any specific directory service.
However, this specification does define a generic schema
that can be used for any specific instance of a directory
service. That is, some of the attributes from the
Printer object are called out as attributes that may be
added to a directory entry which represents that Printer.
This allows directory users to find and locate IPP
Printers by either a simple name look up or by some
filtered attribute search.
4.2 Directory Entry Schema
The following attributes define the generic directory
entry schema. All directories entries for IPP Printers
in all types of directories should support at least these
attributes.
deBry, Hastings, Herriot, Isaacson [Page 12]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
Issue: The use of "objective" attributes vs. "subjective"
attributes still needs to be resolved. For example, for
Maximum Print Quality is it better to have values like
"high", "medium", "low" or to have explicit, quantified,
measurable values? Some of the issues are: end users
don't often know what explicit objective values are or
what they really mean and they want to depend on an
administrator to define what is "high" quality printing
and what is "low" quality, especially since today's
objective values that equate to "high" are tomorrow's
objective values that equate to "medium". On the other
hand, some end users demand the control and power
explicit values can give them when they do filtered
searching. For example, they know and appreciate the
difference between 20 ppm printers and 23 ppm printers.
Issue: We must specify which attributes are "mandatory"
and which are "optional". LDAP uses the terms "must" and
"may" to identify attributes that "must" appear and
attributes that "may" appear in a given entry in the
directory.
4.2.1 Name
This directory attribute is the printers name. It is a
URL so it contains sufficient information to not only
name, but to address the printer using IPP as well.
4.2.2 Description
This directory attribute is a free form string that can
contain any site-specific descriptive information about
this printer.
4.2.3 Location
This directory attribute is a free form string that can
contain any site specific location information.
In order for filtered searches to be more effective, a
given site may use some regular structuring within the
string values such as "SITE:USA-San
Jose,BUILDING:A1,FLOOR:2,ROOM:555" or "department5-
2ndFloor-A5-IndianHills-Chicago-IL-USA".
deBry, Hastings, Herriot, Isaacson [Page 13]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
4.2.4 Maximum Print Quality
This directory attribute indicates a somewhat subjective
evaluation of the overall printing quality. The syntax
and values shall be the same as for the print-quality Job
attribute.
4.2.5 Cost
This directory attribute indicates a somewhat subjective
evaluation of the overall cost of printing at this
printer: "high", "medium", or "low".
4.2.6 Resolution
This directory attribute is the maximum resolution of the
Printer in dpi.
The syntax and semantics shall be the same as for the
printer-resolution-select job attribute.
4.2.7 Color Supported
This directory attribute specifies whether the Printer
supports color and, if so, what type. The values are a
type2Enum (see section 6). Standard values are: "none",
"highlight", "three color (CMY)", "four color (CMYK)",
"monochromatic".
4.2.8 Fonts Supported
This directory attribute takes on a list of fonts that
are supported by the printer. The syntax and values
shall be the same as for the fonts-used job attribute..
4.2.9 Maximum Speed
This directory attribute is the maximum speed of the
printer ppm, ipm, spm, lpm, or cps. The syntax and
values shall be the same as for the maximum-printer-speed
Printer attribute.
4.2.10 Device Id
This directory attribute can be used for automatic driver
download, database access, or other automatic
configuration tasks. It might be used to generate a
deBry, Hastings, Herriot, Isaacson [Page 14]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
platform specific id such as the Windows Plug-and-Play
id.
Issue: Is this the IEEE 1284-1994 device id, the Object
Identifier as used in the Host Resource MIB hrDeviceId
object, or some other identifier?
4.2.11 Make and Model
This directory attribute is a simple text string defined
by the manufacturer that contains some reference to the
make and model of the entity being represented to the
end-user by this Printer object. The syntax shall be:
vendor-name "/" model-name
where the vendor-name is the same as that registered with
IANA for use in domain names.
For example: "vendor-x/super-duper-printer".
4.2.12 Marker Type
This directory attribute is the printing mechanism of the
print device: electrophotographic-laser, inkjet-aqueous,
thermal-transfer, etc. The syntax and values shall be
the same as for the printer-types Printer attribute,
except the value of the Marker Type directory attribute
shall be single-valued
4.2.13 Document Formats Supported
This directory attribute is a list of all of the document
formats that the printer and/or its interpreter(s)
support. The syntax and values shall be the same as for
the document-format Job attribute.
4.2.14 Sides Supported
This directory attribute specifies the capabilities of
the Printer for marking on sides of the medium. The
syntax and values shall be the same as the sides Job
attribute.
deBry, Hastings, Herriot, Isaacson [Page 15]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
4.2.15 Finishings Supported
This directory attribute identifies the finishing
operations supported by the Printer. The syntax and
values shall be the same as the finishing job attribute.
4.3 Directory Entries Using LDAP
To allow directory users to locate an IPP Printer, a
corresponding entry must be defined within a directory.
This section describes how this is done using the
Lightweight Directory Access Protocol (LDAP).
The LDAP directory entry includes the name of the entry
and the attributes as defined in "4.2 Directory Entry
Schema". The following is an example of how to define a
directory entry for a Printer object using LDAP. It is
given to assist the reader's understanding of this
specification.
To create a Printer object directory entry using LDAP:
1. An administrator uses a program to create an entry for
the Printer object on a directory server that supports
LDAP. The administrator defines the Distinguished Name
(dn) and the default subjective attributes for the
Printer object directory entry.
Issue: Should the administrator also define default
objective attributes or wait for the Printer object
itself to initialize these attributes?
2. The Printer object invokes the ldap_open API to open a
connection to the directory server:
Example: ld=ldap_open ("dir.host.name", LDAP_PORT)
where ld is the connection handle for subsequent LDAP
APIs.
3. The Printer object invokes an ldap "bind" API to
authenticate with the directory server.
Example: ldap_simple_bind_s (ld, dn, NULL) (which does a
simple authentication without a password).
4. The Printer object invokes the ldap_modify or
ldap_modify_s API to define the objective attributes for
deBry, Hastings, Herriot, Isaacson [Page 16]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
the Printer object entry as identified by its
Distinguished Name (dn).
Example: ldap_modify_s (ld, dn, mods) (where mods is a
NULL-terminated array of objective attributes and values
to add or modify in the directory entry)
5. The Printer object invokes the ldap_unbind API to
close the connection to the directory server.
Example: ldap_unbind (ld)
When one or more objective attributes are modified for a
Printer object, the Printer object repeats steps 2-5 to
update the modified objective attributes in its directory
entry.
To locate a Printer object entry using LDAP, a program
can use the ldap_search or ldap_search APIs or a user can
specify an LDAP URL.
For example, to locate all Printer objects that support
duplex, a user can specify URL:
ldap:///dir.host.name???(&(objectClass=printer)
(sides-supported=2-sided-long-edge))
Issue: Is it allowed to filter the search based on the
object class itself, in this case the object class of
Printer? We need to define this new object class. How
do we do this? One proposal is to subclass the device
class defined in X.500:
printer OBJECT-CLASS ::= {
SUBCLASS OF {device}
MUST CONTAIN {<list of mandatory attributes>}
MAY CONTAIN {<list of optional attributes>}
5. IPP Operations
This section introduces the IPP operations. Since IPP
specifies the use of HTTP as the underlying communication
protocol, the mapping of IPP operations on top of HTTP
methods is also shown.
deBry, Hastings, Herriot, Isaacson [Page 17]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
5.1 HTTP Overview
IPP is based on the existing HTTP standard. IPP is a
lightweight application-level protocol designed with the
Internet in mind. It is a generic, stateless, object-
oriented protocol which can be used for any task through
extension of its request methods (commands).
HTTP allows an open-ended set of methods to be used to
indicate the purpose of a request. It builds on the
discipline of reference provided by the Uniform Resource
Location (URL) and message formats similar to those used
by Internet Mail and the Multipurpose Internet Mail
Extensions (MIME).
HTTP is based on a request-response paradigm. A
requesting program (a client) establishes a connection
with a receiving program (a server) and sends a request
to the server in the form of a request method, a URL, and
protocol version, followed by a MIME-like message
containing request modifiers, client information, and
possibly print data. The server responds with a status
line, including its protocol version, and a success or
failure code, followed by a MIME-like message containing
server information, entity meta-information, and possibly
some content.
Current practice requires that the connection be
established by the client prior to each request and
closed by the server after sending the response. Both
clients and servers shall be capable of handling cases
where either party closes the connection prematurely, due
to user action, automated time out, or program failure.
5.2 IPP Operation Encoding
IPP messages consist of requests from client to server
and responses from server to client.
IPP MESSAGE = Request | Response
Requests and responses use the generic message format of
RFC 822 for transferring entities. Both messages may
include optional header fields and an entity body. The
entity body is separated from the headers by a null line
(a line with nothing preceding the CRLF).
Request = Request-line
deBry, Hastings, Herriot, Isaacson [Page 18]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
* (General-Header
| Request-Header
| Entity-Header)
CRLF
[ Entity-Body ]
Response = Status-line
* (General-Header
| Request-Header
| Entity-Header)
CRLF
[ Entity-Body ]
All IPP headers conform to the syntax
IPP-Header = field-name ":" [field-value] CRLF.
IPP/1.0 defines the octet sequence CRLF as the end-of-
line marker for all protocol elements except the entity-
body.
Note that HTTP 1.1 defines a slightly different syntax,
allowing for dynamically generated messages to be
transmitted. This would be required for cases such as PC
driver generated Print Operations. HTTP 1.1 defines a
message header which specifies a transfer encoding called
"chunks".
IPP messages are contained within HTTP methods. The HTTP
POST method is used for the Print operation and the
Cancel Job operation. The HTTP GET method is used for
the Get Attributes operation and the Get Jobs operation
(section 5.4).
5.2.1 HTTP Request-Header Fields
HTTP request header fields allow the client to pass
additional information about the request, and about the
client itself, to the server. All header fields are
optional and when used it is assumed that IPP would use
these headers in a standard way. IPP requests will be
completely encapsulated within the entity body of an HTTP
request. The HTTP Entity-Header has the form
HTTP-Entity-Header = Content-Encoding
| Content-Length
| Content-Type
deBry, Hastings, Herriot, Isaacson [Page 19]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
| extension-header
The Content-Length field must always be a valid length,
This means that for any Print Operations based on HTTP
1.0, the entire content must be generated before this
header can be built. HTTP 1.1 provides the notion of
"chunks" which will allow the content to be generated
dynamically as the data is sent.
Content-Type will always be "Application/IPP".
5.2.1.1 IPP Request-Line
The first line of the entity body in an IPP operation is
the IPP Request-Line. The Request-Line defines the
Operation and the IPP Version.
IPP-Request-Line = Operation-token IPP/1.0 CRLF
Operation-token = Print | Cancel-Job |
Get-Attributes | Get-Jobs
5.2.2 HTTP Response-Header Fields
HTTP response fields allow the server to pass additional
information about the response back to the client. IPP
will use these headers in a standard way. IPP responses
will be completely encapsulated within the entity body of
an HTTP response.
5.2.2.1 IPP Status-Line
The first line of the entity body in an IPP response is
the IPP Status-Line. The status-line consists of a
protocol version followed by a numeric status-code and an
associated text message.
IPP-Status-Line = IPP/1.0 Status-Code Reason-Phrase
CRLF
5.3 The Print Job
In section 5.4.1, the Print Operation is described. In
order to understand that operation better, we first
present the notion of a Print Job. The entity body of a
print operation request will contain a Print Job, as
deBry, Hastings, Herriot, Isaacson [Page 20]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
defined below. The headers defined here are IPP headers,
but follow the same syntax as the basic HTTP headers.
Print-Job = Print-Job-Object-Header ;section (5.3.1)
[Job-Attributes] ;section (5.3.4)
*(Documents)
Document = Document-Header ;section (5.3.2)
[Document-attributes] ;section (5.3.5)
[Content-Header ;section (5.3.3)
content]
5.3.1 Print Job Object Header
Print-Job-Object Header = Content-Encoding
| Content-Length
| Content-Type
| extension-header
Content-Type is always "IPP Print Object". Other header
fields are as defined for HTTP 1.0.
5.3.2 Document Header
The document header allows the insertion of multiple
documents within a job. At this point only a limited
number of document attributes are defined. However, this
structure allows the addition of other attributes which
can be specified on a document boundary.
Document-Header = Content-Encoding
| Content-Length
| Content-Type
| extension-header
Content type is always "IPP Document". Other header
fields are as defined in HTTP 1.0.
5.3.3 Document-Content Header
The document-content-header provides additional meta-
information about the document. The document content
header is an optional field and would not be present if
the document was pointed to by a document URL attribute.
It is composed of a number of document header fields as
follows:
deBry, Hastings, Herriot, Isaacson [Page 21]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
Document-Content-Header = Content-Encoding
| Content-Length
| Content-Type
| extension-header
Content-Type is defined as :
Content-Type = Data-Stream-Format "/" Version
Thus, for example, if the document to be printed was a
Postscript Level 2 document, the Content-Type would be
specified as:
Content-Type: Postscript/2.0
Other header fields are as defined by HTTP 1.0.
5.3.4 Job Attributes
Job attributes are defined in section 6.2. Attributes
will always be sent as
Job-Attribute = Attr-name ":" Attr-value CRLF
Attr-value = 1#Value
In the above example, "1#Value" means one or more ","
separated values.
5.3.5 Document Attributes
Document attributes are defined in section 6.2.11. The
syntax for a document attribute is
Document-Attribute = Attr-Name ":" Attr-Value CRLF
Attr-Value = 1#Value
In the above example, "1#Value" means one or more ","
separated values.
5.4 Operation Semantics
In this section the four IPP operations are described in
terms of their contents and semantics.
deBry, Hastings, Herriot, Isaacson [Page 22]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
5.4.1 Print Operation
When an end user submits a job, the client submits a
Print Request and receives a Print Response.
Note that the Printer name is not needed since it is the
target of the entire operation. A Print Job contains the
information needed by the Printer object to print a
document or set of documents. When the print operation
is invoked, the Entity-Body in the HTTP request includes
an IPP Print Job. The concrete syntax of the Print Job is
defined in section 5.3.
Each Printer object has an associated Job Template object
assigned by the Administrator. When accepting a Print
operation, the Printer shall use the corresponding value
of an attribute from the Printer's Job Template as the
default value for any job attribute that the submitting
client omits from the Print operation.
If neither the client nor the Printer's Job Template
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.
5.4.1.1 Print Request
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 6.2
Attributes
Requested A set of attributes without values in
Attributes whose values the requester is
interested.
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.
5.4.1.2 Print Response
The following abstract data types are part of the Print
Response:
deBry, Hastings, Herriot, Isaacson [Page 23]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
Job- A URL Used for all other operations on
Identifier this Job.
Job Status Current-job-state
Printer State Printer-state
Result The requested attributes with their
Attributes current values, if the requester
supplied any Requested Attributes
Message Optional message
Errors Optional Error Information
5.4.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 Object. 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-originator Job
attribute) can cancel the job.
The Cancel HTTP request will be sent to the URL
identifying the job to be canceled.
5.4.2.1 Cancel-Job Request
The following abstract data types are part of the Cancel
Job Request:
Message Optional message to the operator.
job- The number (cardinal) of minutes that
retention- that job is to be retained after the job
period has been canceled. This parameter
updates the value of the job-retention-
period that may have been submitted by
the submitter in the Print operation.
deBry, Hastings, Herriot, Isaacson [Page 24]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
5.4.2.2 Cancel-Job Response
The following abstract data types are part of the Cancel
Job Response:
Job Status Optional Job status information
Errors Optional Error Information
5.4.3 Get Attributes Operation
This operation allows an end-user to obtain information
from the Print object concerning jobs, printers, and
print queues, based on ISO 10175. The entity-body of the
Get Attributes operation contains the set of attributes
that the requester is interested in. The requester
should not supply values in the Requested Attributes
input parameter; the Printer shall ignore the values of
any supplied by the requester. The attribute list is
returned in the response with the appropriate attribute
values filled in. If no attribute list is supplied, then
all attributes defined for that object are returned.
5.4.3.1 Get-Attributes Request
The following abstract data types are part of the Get
Attributes Request:
Selector Job-Identifier (URL) or
Printer URL or
Job Template URL
Requested A set of attributes without values in
Attributes whose values the requester is
interested
5.4.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
Attributes
deBry, Hastings, Herriot, Isaacson [Page 25]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
Errors Optional error information
5.4.4 Get Jobs Operation
This operation allows a client to retrieve a list of
print jobs belonging to the target Printer object. A list
of attributes the client is interested in seeing may be
appended to the request. If no attributes are asked for
the default set of job-name and total-job-octets is
returned for each job along with the job-identifier. Jobs
will be returned in the order in which they are scheduled
to print.
5.4.4.1 Get-Jobs Request
The following abstract data types are part of the Get
Jobs Request:
selector Indicates which jobs the requester
seeks. The values are type2Enum (see
section 6). Standard values are: "
all-jobs" - including completed jobs
"pending" - all jobs which are pending
and processing
"my-jobs" - my jobs that are pending or
processing
Requested A set of attributes without values in
Attributes whose values the requester is
interested.
5.4.4.2 Get-Jobs Response
The following abstract data types are part of the Get
Jobs Response:
Jobs A list of Job URLs is returned. The list
is in "scheduled" order. The job-
deBry, Hastings, Herriot, Isaacson [Page 26]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
identifier attribute shall be returned
as the first attribute of each job to
mark the beginning of the set of
attributes for the next job.
Result In addition to the job-identifier
Attributes attribute which is always returned,
either the Requested Attributes are
returned or the following attributes by
default, if the requester did not supply
any Requested Attributes: job-total-
octets and number-of-intervening-job.
This last 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.
Errors Optional Error Information
6. Object Attributes
This section describes the attributes, syntaxes, and
values that are part of IPP. The sections below show the
objects and their associated attributes which are
included within the scope of this protocol. The text in
these sections has been heavily influenced by the ISO/IEC
10175 DPA (Final, June 1996).
6.1 Attribute Syntaxes
The syntax for attribute values is specified using the
notation of RFC 822.
The special syntax State is used to form other syntaxes
for xxx-supported attributes of the Printer object that
indicate job attributes that the Printer supports. Such
support may include operator intervention, delivery of an
order that the provider has previously placed, or may
require that the provider place a special order. The
syntax for State is itself a type2Enum. The standard
values are: [":not-ready" / ":on-order" / ":special-
order"]
deBry, Hastings, Herriot, Isaacson [Page 27]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
An attribute value with an empty State means that the
indicated value is ready to be used without human
intervention.
An attribute value with a ":not-ready" State means that
operator intervention is required.
An attribute value with a ":on-order" State means that
the provider has placed an order for the indicated value
and that the operator must wait until the resource is
delivered before the job can be printed. However, an
end-user may submit a job that requires such a resource
and the Printer shall accept such a job.
An attribute value with a ":special-order" State means
that the provider shall make a special order for the
resource, when a job is submitted that needs such a
resource. However, an end-user may submit a job that
requires such a resource and the Printer shall accept
such a job.
For example, the media-supported printer attribute might
contain the following values:
media-supported = na-letter-white, na-letter-
transparent,
b:not-ready
Meaning that na-letter-white and na-letter-transparent
are loaded into the two trays of the output device and
that b is supported, but requires the operator to change
the trays.
The sections below reference the following syntax items:
string arbitrary ASCII strings, no
control characters, except
<SPACE>.
StringPair string ":" string
stringState string State
name arbitrary ASCII strings, no
control characters, and no
<SPACE> characters.
Url Universal Resource Locator
dateTime date and time in RFC 822
format
deltaTime [hours ":"] minutes
cardinal 0 .. n represented as ASCII
deBry, Hastings, Herriot, Isaacson [Page 28]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
digits
type1Enum standard names, must revise
the IPP standard to add a new
name. No private names are
allowed.
type2Enum standard names, but an
implementor 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 approvoal..
IANA keeps the registry.
Implementors can support
private (un-registered) with
a suitable distinguishing
prefix, such as -xxx- where
xxx is the company name
registered with IANA for use
in domain names.
Type3Enum standard names, but an
implementor can add new
values by submitting a
registration request directly
to IANA, no PWG or IANA-
appointed registry advisor
review is required.
Implementors 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.
type2EnumState type2Enum State
type3EnumState type3Enum State
boolean tokens: yes, y, true, or t
and no, n, false, or f.
positiveInteger 1 .. n represented as ASCII
digits
positiveIntegerCross positiveInteger [ "x"
positiveInteger ]
positiveIntegerCrossS positiveIntegerCross State
tate
positiveIntegerRange positiveInteger ":"
deBry, Hastings, Herriot, Isaacson [Page 29]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
positiveInteger
positiveIntegerUnits positiveInteger units
positiveIntegerState positiveInteger State
units "ppm" | ipm
" " | "spm" | "cps"
| "lpm"
type3Locale type3Country ":"
type3Language ":"
type3CodeSet
type3Country type3Enum - Standard values
are the two-character country
codes from ISO 639.
type3Language type3Enum - Standard values
are the two-character
language codes from ISO 3166.
type3CodeSet type3Enum - Standard values
are from the IANA Code Set
registry.
type2Format name [ "/" version ]
version name
type3LocaleState type3Locale State
Also, the following conventions (from RFC 822) are used:
"1#" in front of a means one or more values
data syntax separated by ",".
NOTE - For consistency, no Job (or Job Template) or
Printer attribute has the syntax # meaning zero or more
values separated by ",". Instead, a distinguished value,
such as "none", is used to indicate no value. For the
Printer Object, the omission of the attribute entirely,
is also used to indicate no value. In all such cases for
the Printer object where a conforming implementation may
omit the attribute all together, an explicit sentence
indicates the meaning of the Printer attribute when the
attribute is unspecified.
6.2 Job Attributes
A job object contains a set of job attributes and one or
more documents. A client shall create a job and send it
to a server using the Print operation. When accepting a
Print operation, the Printer shall use the corresponding
value of an attribute from the Printer's Job Template as
the default value for any job attribute that the
submitting client omits from the Print operation.
deBry, Hastings, Herriot, Isaacson [Page 30]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
A client may use a job template associated with the
selected printer in order to initialize the job. To do
so, the client uses the Get-Attributes operation to get
the URLs of the Printer's Job Templates. Then the client
may get the default attributes from the Printer's default
Job Template in order to initialize a display to the end-
user with the Printer's defaults. See the printer-job-
templates Printer attribute. However, a client need not
access the Job Template in order to issue a Print
operation; the client can depend on the Printer to supply
the default job object attribute values as part of the
Print operation.
Each section heading below contains the name of an
attribute and its syntax in parentheses using the rules
of RFC 822.
6.2.1 Job Informational Attributes (Set by a Client/End
User)
The client may specify these attributes in the Print
operation to provide information to identify a print-job.
The client may also specify these attributes in the
operations: Get-Attributes, and Get-Jobs.
6.2.1.1 job-name (string)
This attribute supplies a human readable string for
naming the print-job.
This attribute is intended to be printed on a start
sheet, returned in a Get-Jobs result, or used in
notification messages.
If the client does not specify this attribute, a Printer
shall set it to the value of the document-name attribute
of the first document in the job.
6.2.2 Job Informational Attributes (Set by a Printer)
The Print shall add all of these attributes to a job to
provide information to identify a print-job.
The client may specify these attributes in the
operations: Get-Attributes and Get-Jobs, but not in
Print.
deBry, Hastings, Herriot, Isaacson [Page 31]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
6.2.2.1 job-identifier (url)
This attribute provides the job-identifier for this job
on the Printer. The Printer shall generate a job-
identifier value as a URL.
The value of the job-identifier attribute shall be
returned by the Printer as part of the PrintResult in the
Print operation.
6.2.2.2 job-originator (name)
This attribute specifies the 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 client. The operation-user-name attribute is
intended to be a source of the most authentic name.
6.2.2.3 job-originating-host (name)
This attribute identifies the originating host of the
job. The Printer shall set this attribute to the value of
the operation-host-name which is intended to be the most
authentic host name of the client.
6.2.2.4 job-locale (type3Locale)
This attribute identifies the locale of the job, i.e, the
country, language, and coded character set. The Printer
sets this attribute from the value of the operation-
locale.
The Printer shall use this attribute to determine the
locale for notification messages that it sends.
Issue: Is there a more standard syntax for locale?
6.2.3 Job Status Attributes (Set by Printer)
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.
deBry, Hastings, Herriot, Isaacson [Page 32]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
The client may specify job-status attributes in: Get-
Attributes and Get-Jobs, but not Print.
6.2.3.1 current-job-state (type1Enum)
This attribute identifies the current state of the job.
Standard values are:
Unknown The job state is not known, or is
indeterminate.
held The job is waiting to be released for
scheduling for any number of reasons
as specified by the value of the job's
job-state-reasons attribute.
pending The job is waiting to start processing
on a printer.
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.
paused The job has been paused
Interrupte The job has been interrupted by some
d intervening job, and shall resume
processing automatically once the
intervening job has completed.
deBry, Hastings, Herriot, Isaacson [Page 33]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
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.
Retained The job is being retained at the
server as a result of the job's job-
retention-period being non-zero. 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.
deBry, Hastings, Herriot, Isaacson [Page 34]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
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,
AND the job's:
(1) job-retention-period was zero
or has expired, or
(2) job-discard-time has arrived.
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.
6.2.3.2 output-device-assigned (name)
This attribute identifies the Output Device to which the
Printer has assigned this job.
If an Output Device implements a Printer, the Printer
need not set this attribute.
deBry, Hastings, Herriot, Isaacson [Page 35]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
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
users can determine the Output Device on which the job
was printed.
6.2.3.3 submission-time (dateTime)
This attribute indicates the 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.
6.2.3.4 number-of-intervening-jobs (cardinal)
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.
6.2.3.5 job-message-from-operator (string)
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.
6.2.3.6 completion-time (dateTime)
This attribute indicates the 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 [Page 36]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
6.2.3.7 job-state-reasons (1#type2Enum)
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.
The following standard values are defined:
none There are not reasons associated
with the job's current state.
documents-needed The complete job has been
accepted by the server, but the
server is waiting for its files
to be transferred before the job
can be scheduled to be printed.
job-hold-set The value of the job's job-hold
attribute is TRUE.
job-print-after- The value of the job's job-print-
specified after or print-off-peak
attributes have specified a time
specification that has not yet
occurred.
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.
deBry, Hastings, Herriot, Isaacson [Page 37]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
6.2.3.8 impressions-completed (cardinal)
This attribute contains the number of impressions that
the Printer has completed printing. If the Printer
cannot report this number, the Printer leaves this
attribute unspecified.
6.2.3.9 media-sheets-completed (cardinal)
This attribute contains the number of media-sheets that
the Printer has completed printing. If the Printer
cannot report this number, the Printer leaves this
attribute unspecified.
6.2.4 Job Sheet Attributes (Set by Client/End User)
The client shall specify these attributes to control the
printing of job sheets.
The client may also specify job sheet attributes in: Get-
Attributes and Get-Jobs.
6.2.4.1 job-sheets (type3Enum)
This attribute determines what type of job-sheets the
Printer shall print with the job.
The standard values are: none, and default-sheet.
The value "none" means that the Printer shall print no
job sheets. The value "default-sheet" means that the
Printer shall print the job sheets defined by an
administrator. 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.
NOTE - The effect of this attribute on jobs and documents
is controlled by the files-are-one-document and files-
are-interleaved job attributes.
6.2.5 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.
deBry, Hastings, Herriot, Isaacson [Page 38]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
The client may also specify notification attributes in:
Get-Attributes and Get-Jobs.
6.2.5.1 notification-events (1#type2Enum)
This attribute specifies the events about which the end
user want to be notified.
Standard values are: none, job-completion, job-problems
and printer-problems.
If this attribute contains the event none, 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. If the none
value and other values are supplied, the Printer shall
ignore the none value.
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 or is
cancelled by the end-user or the operator.
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, has a problem while this job is
waiting to print or printing. Problems include: paper jam
and out-of-paper.
6.2.5.2 notification-address (url)
This address specifies both the address and mechanism for
delivery of notification events to the client. The client
specifies this attribute in the operation-notification-
address attribute which the Printer in turn uses to set
this attribute.
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 or when
certain other events occur, such as Cancel-Job.
deBry, Hastings, Herriot, Isaacson [Page 39]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
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.
6.2.6 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.
The client may also specify these attributes in: Get-
Attributes and Get-Jobs.
6.2.6.1 job-priority (type1Enum)
This attribute specifies a priority for scheduling the
print-job. Printers that employ a priority-based
scheduling algorithm use this attribute.
There are three standard values: high, default, and low.
Among those jobs that are ready to print, a Printer shall
print all such jobs with a high priority before printing
those with a default or low priority, and a Printer shall
print all such jobs with a default priority before
printing those with a low priority.
If the client does not specify this attribute, the
Printer assumes that the end user places no constraints
concerning priority on the scheduling of the print-job,
and it has a priority value of default.
An operator can modify a job to have any priority. An
end-user is restricted by the value of the maximum-end-
user-priority Printer attribute.
6.2.6.2 job-print-after (dateTime)
This attribute specifies the calendar date and time of
day after which the print-job shall become a candidate
for printing.
If the value of this attribute is in the future, the
Printer shall set the value of the job's current-job-
state to held and add the job-print-after-specified value
to the job's job-state-reasons attribute and shall not
schedule the print-job for printing until the specified
date and time has passed. When the specified date and
deBry, Hastings, Herriot, Isaacson [Page 40]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
time arrives, the Printer shall remove the job-print-
after-specified value from the job's job-state-reason
attribute and, if no other reasons remain, shall change
the job's current-job-state to pending so that the job
becomes a candidate for being scheduled to print.
If this attribute is unspecified or the value is in the
past, the job shall be a candidate for scheduling
immediately.
6.2.6.3 job-print-off-peak (type3Enum)
This attribute specifies the off-peak period during which
the print-job shall become a candidate for printing.
Standard values are: "evening", "night", "weekend",
"second-shift", "third-shift".
If this attribute is specified, it contains a value with
which an administrator has associated allowable print
times. An administrator is encouraged to pick names that
suggest the type of off-peak period.
If the value of this attribute is in the future, the
Printer shall set the value of the job's current-job-
state to held and add the job-print-after-specified value
to the job's job-state-reasons attribute and shall not
schedule the print-job for printing until the specified
date and time has passed. When the specified date and
time arrives, the Printer shall remove the job-print-
after-specified value from the job's job-state-reason
attribute and, if no other reasons remain, shall change
the job's current-job-state to pending so that the job
becomes a candidate for being scheduled to print.
If this attribute is unspecified, the job shall be a
candidate for scheduling immediately.
6.2.6.4 job-retention-period (deltaTime)
The retention time is expressed in hours and minutes,
e.g. 6:00 (6 hours), or 20 (20 minutes).
This attribute specifies the minimum period of time
following the completion of job processing and printing
that the server shall keep job attributes and document
data. The Printer may keep these attributes and data
deBry, Hastings, Herriot, Isaacson [Page 41]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
longer than the value of the job-retention-period
attribute.
NOTE - the requester may change this job attribute using
the input parameter to the Cancel-Job operation.
6.2.7 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.
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.
Job Production and Resource Attributes each address a
similar set of features but they have different uses.
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
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 resource 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 resource attributes to a
job.
For example, a job production attribute medium-select
with the value of "letter" requests that a job be printed
on letter paper, but gives no information about what
resources the job needs. For example, a job resource
attribute media-used with the values of "letter" and
"ledger" tell a Printer that the job needs letter and
deBry, Hastings, Herriot, Isaacson [Page 42]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
ledger paper, but gives no information about which pages
use each medium.
The client may also specify job production-instruction
attributes in: Get-Attributes and GetJobs.
6.2.7.1 medium-select (type2Enum)
This 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.
Standard values are (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
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
deBry, Hastings, Herriot, Isaacson [Page 43]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
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
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
deBry, Hastings, Herriot, Isaacson [Page 44]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
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
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
deBry, Hastings, Herriot, Isaacson [Page 45]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
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
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
deBry, Hastings, Herriot, Isaacson [Page 46]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
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
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
deBry, Hastings, Herriot, Isaacson [Page 47]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
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)
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
deBry, Hastings, Herriot, Isaacson [Page 48]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
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
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
deBry, Hastings, Herriot, Isaacson [Page 49]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
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
6.2.7.2 finishing (type2Enum)
This attribute identifies the finishing operation that
the Printer should apply to each copy of the printed
document.
NOTE - The effect of this atttribute on jobs and
documents is controlled by the files-are-one-document and
files-are-interleaved job attributes.
Standard values for this attribute are:
none Perform no finishing.
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- This indicates that one or more
bottom- staples should be placed on the
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.
deBry, Hastings, Herriot, Isaacson [Page 50]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
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.
bind This indicates that a binding is to
be applied to the document; the
type and placement of the binding
is site-defined.
6.2.7.3 number-up (type3Enum)
This attribute specifies the number of source page-images
to impose upon a single side of an instance of a selected
medium.
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".
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.
deBry, Hastings, Herriot, Isaacson [Page 51]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
6.2.7.4 sides (type2Enum)
This attribute specifies how source page-images are to be
imposed upon the sides of an instance of a selected
medium.
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
for the reader as if for binding on the short edge. This
imposition is sometimes called "tumble" or "head-to-toe".
Issue: How does sides interact with portrait vs.
landscape and reverse-landscape documents?
6.2.7.5 copies (positiveInteger)
This attribute specifies the number of copies of the job
to be printed. If this attribute is unspecified by both
the client and the Printer's Job Template, its default
value shall be 1.
NOTE - The effect of this atttribute on jobs and
documents is controlled by the files-are-one-document and
files-are-interleaved job attributes.
6.2.7.6 printer-resolution-select (positiveIntegerCross)
This attribute specifies the resolution that the Printer
should use.
The syntax allows a single integer to specify the
resolution or a pair of integers to specify the
resolution when the x and y dimensions differ. When two
deBry, Hastings, Herriot, Isaacson [Page 52]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
integers are specified, the first is in the x direction,
ie., 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.
6.2.7.7 print-quality (type2Enum)
This attribute specifies the print quality that the
Printer should use.
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
6.2.7.8 page-select (positiveIntegerRange)
This attribute specifies the pages in the document that
the Printer shall use. This attribute is unlikely to be
useful for jobs with more than one document or in Job
Templates. If this attribute is unspecified, then the
Printer shall print all pages in a document.
6.2.7.9 files-are-one-document (boolean)
This 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.
If the files for the job are a and b and this attribute
is true, 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, .... The
attribute files-are-interleaved is ignored.
If the files for the job are a and b and this attribute
is false or unspecified by both the client and the
Printer's Job Template, then each file is treated as a
single document for finishing operations. Also, a client
may specify that a slip sheet be between files a and b.
If more than one copy is made, and the attribute files-
are-interleaved false or unspecified, the ordering is a,
a, b, b, .... If more than one copy is made, and the
deBry, Hastings, Herriot, Isaacson [Page 53]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
attribute files-are-interleaved true, the ordering is a,
b, a, b, ....
6.2.7.10 files-are-interleaved (boolean)
This attribute is used in conjunction with files-are-one-
document (q.v.).
6.2.8 Attributes for Conversion of Text and HTML Files (Set
by Client/End User)
The client shall specify these attributes to control
formatting for text documents or HTML documents.
A client need not specify these attributes for other
types of documents, such as PostScript or PCL.
6.2.8.1 width (cardinalUnits)
This attribute specifies the media width for the document
in characters.
6.2.8.2 length (cardinalUnits)
This attribute specifies the media length for the
document in characters.
6.2.8.3 left-margin (cardinalUnits
This attribute specifies the left-margin for the document
in characters.
6.2.8.4 right-margin (cardinalUnits)
This attribute specifies the right-margin for the
document in characters.
6.2.8.5 top-margin (cardinalUnits)
This attribute specifies the top-margin for the document
in lines.
6.2.8.6 bottom-margin (cardinalUnits)
This attribute specifies the bottom-margin for the
document in lines.
deBry, Hastings, Herriot, Isaacson [Page 54]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
6.2.8.7 repeated-tab-stops (cardinalUnits)
This attribute specifies the tab stops for the document
in characters.
6.2.8.8 header-text (string)
This attribute specifies the header text for the
document.
6.2.8.9 footer-text (string)
This attribute specifies the footer text for the
document.
6.2.8.10 number-pages (boolean)
This attribute specifies that the pages should be
numbered in the document.
6.2.8.11 default-font (string)
This attribute specifies the font to use for all text in
the document.
6.2.8.12 font-size (cardinalUnits)
This attribute specifies the font-size in points for text
in the document. The value of this attribute affects the
size of the other text attributes.
If this attribute is omitted and the Printer's default
Job Template does not contain this attribute, the Printer
shall assume a value of 10. A value of 10 with a fixed
pitch font, shall produce 12 characters per inch in the
horizontal direction and with 6 lines per inch in the
vertical direction.
6.2.8.13 default-code-set (type3Enum)
This attribute specifies the code-set in which the
document is encoded.
6.2.8.14 content-orientation (type2Enum)
This attribute specifies the orientation of the document.
The standard values are:
deBry, Hastings, Herriot, Isaacson [Page 55]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
portrait The page orientation such that the
sides are longer than the top when
the page is held in the intended
human reading orientation
landscape The page orientation such that the
sides are shorter than the top when
the page is held in the intended
human readable orientation.
Landscape is defined to be a
rotation of the page by +90 degrees
with respect to the medium (i.e.
anti-clockwise) from the portrait
orientation
NOTE - The +90 direction was chosen
because simple finishing on the long
edge is the same edge whether
portrait or landscape
reverse- The page orientation defined to be a
portrait rotation of 180 degrees with respect
to portrait
reverse- The page orientation defined to be a
landscape rotation of 180 degrees with respect
to landscape. Landscape is defined
to be a rotation of the page by -90
degrees with respect to the medium
(i.e. clockwise) from the portrait
orientation
NOTE - Reverse-landscape was added
because some applications rotate
landscape -90 degrees from portrait,
rather than +90 degrees.
6.2.9 Job Resource Attributes (Set by the program that
produces or senses the PDL)
A program (described below) shall add these attributes,
which describe the resources needed to print the job.
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.
The client/end user shall not specify these attributes.
Instead, it is the duty of the program that translates
deBry, Hastings, Herriot, Isaacson [Page 56]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
the document to the printer's PDL (or analyzes it) to add
these attributes and their values to the job. 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.
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
are ready, ie., are available to the Printer and/or
output device without human intervention.
These attributes may be unspecified if the translation
program fails to provides such values, or if no
translation occurs (e.g. the document is a PostScript
document.
Note: The Printer does not use these attributes during
the actual printing of a document.
Note: these attributes allow more than one value wherever
it is possible for a job to specify more than one value
of the corresponding job attribute, possibly by embedded
instructions.
The client may specify these attributes in: Get-
Attributes and Get-Jobs.
See the section on job production attributes for an
explanation of how the job resource attributes differ
from the job production attributes.
6.2.9.1 document-formats-used (1#type2Format)
This attribute identifies the document formats needed to
print the document(s) in this job.
deBry, Hastings, Herriot, Isaacson [Page 57]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
A format consists of two elements, a name and a version.
The latter element is optional.
The syntax is for type2Format:
name [ "/" version ]
Examples include: PostScript, PostScript/2.0 and PCL/5e
Note: The version component is optional.
The names shall be registered with IANA as "printer
languages" following the procedures established by the
Printer MIB (currently proposed as an ITEF standard by
RFC 1759).
6.2.9.2 fonts-used (1#string)
This attribute identifies the font resources used in the
document(s) in the job.
6.2.9.3 code-sets-used (1#type3Enum)
This attribute identifies the code-sets used in the
document(s) in the Job. This attribute is relevant only
for files that are not in ASCII, such as text files and
possibly PCL files. PostScript files are always ASCII.
Normally there is at most 1 code-set.
Standard values are defined in the section specifying the
default-code-set attribute.
6.2.9.4 media-used (1#type2Enum)
This attribute identifies the media, media-sizes, input-
trays or electronic forms needed to print the document(s)
in the job.
Standard values for this attribute are defined in the
section specifying the medium-select attribute.
6.2.9.5 sides-used (type2Enum)
This attribute specifies whether a job needs 1-sided, 2-
sided-long-edge, or 2-sided-short-edge printing.
Standard values for this attribute are defined in the
section specifying the sides Job attribute.
deBry, Hastings, Herriot, Isaacson [Page 58]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
6.2.9.6 print-quality-used (type2Enum)
This attribute specifies what print quality the job
needs.
Standard values for this attribute are defined in the
section specifying the print-quality attribute.
6.2.9.7 finishing-used (type2Enum)
This attribute specifies what finishing the job needs.
Standard values for this attribute are defined in the
section specifying the finishing attribute.
6.2.9.8 printer-resolution-used (positiveIntegerCrossState)
This attribute specifies what resolution the job needs.
The interpretation of the values for this attribute are
defined in the section on printer-resolution-select Job
attribute.
6.2.9.9 total-job-octets (positiveInteger)
This attribute specifies the total size of the job in
octets. This attribute is the first of three that a
translation program can use to specify the size of a job.
6.2.9.10 job-impression-count (positiveInteger)
This attribute specifies the total size of the job in
impressions.
6.2.9.11 job-media-sheet-count (positiveInteger)
This attribute specifies the total size of the job in
media-sheets.
6.2.10 Number of Documents (Set by Printer)
This group contains a single attribute which specifies
the number of documents in the job.
The Printer sets the value of this attribute depending on
the number of documents that the client supplies in the
Print operation. The client shall not specify this
deBry, Hastings, Herriot, Isaacson [Page 59]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
attribute (directly) in Print, but may specify this
attribute in: Get-Attributes and Get-Jobs.
6.2.10.1 number-of-documents (positiveInteger)
This attribute specifies the number of documents in the
job. Each document shall contain its own set of document
content attributes described below.
6.2.11 Document Data (Set by a Client/End User)
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.
6.2.11.1 document-format (type2Format)
This attribute identifies the document format of this
document.
If the client does not specify this attribute, then the
Printer shall attempt to determine the format in order to
decide if the document data needs to be translated. The
version component is optional.
6.2.11.2 document-name (string)
This attribute contains the name of the document used by
the client to initially identify the document.
6.2.11.3 document-URL (url)
This attribute contains the URL of the document if the
client specified the document with a URL.
deBry, Hastings, Herriot, Isaacson [Page 60]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
If this attribute is specified, then document-content
shall be unspecified.
6.2.11.4 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.
6.3 Operation Attributes (Set by Client)
NOTE: These attributes have just been introduced and
they are not as stable as the attributes in the other
sections. Some work is still needed to show the
relationship between these attributes, job attributes,
printer attributes, and authentication and authorization.
The client shall set these attributes and associate them
with an operation rather than an object.
It is intended that a client program rather than an end-
user has control over the setting of these values so that
they cannot be easily forged.
6.3.1 operation-locale (type3Locale)
This attribute identifies the locale of the client. The
Printer uses this attribute to determine the locale of
(1) messages in the result of the operation, (2) in
errors returned by the operation or (3) notification
events sent to the submitter.
The standard values are defined in the section on the
job-locale attribute.
If an operation does not specify this attribute, the
Printer shall assume that the operation has the same
locale as the Printer.
deBry, Hastings, Herriot, Isaacson [Page 61]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
6.3.2 operation-notification-address (url)
This attribute specifies both the address and mechanism
for delivery of events. 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 APPEND method is used to add HTML
formatted events to the end of the specified HTML file.
6.3.3 operation-user-name (name)
This attribute identifies the most authenticated end-user
name that the client can supply. This name identifies the
end-user performing the operation.
This value shall be set by the system rather than the
end-user in order to minimize the chance of forgery.
6.3.4 operation-host-name (name)
This attribute identifies the most authenticated host
name that the client can supply. This name identifies the
host from which the operation comes.
This value shall be set by the system rather than the
end-user in order to minimize the chance of forgery.
6.4 Printer 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
deBry, Hastings, Herriot, Isaacson [Page 62]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
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.
6.4.1 printer-name (name)
This attribute uniquely identifies the printer on its
host.
6.4.2 printer-location (string)
This attribute identifies the location of this printer.
6.4.3 printer-model (string)
This attribute identifies the make and model of the
printer.
6.4.4 printer-type (type2Enum)
This attribute identifies the marking technology of the
printer.
The standard values for this attribute are the
descriptive names specified by ISO DPA which have
corresponding enum symbolic and numeric values assigned
by the Printer MIB (RFC 1759).. These standard values
are:
deBry, Hastings, Herriot, Isaacson [Page 63]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
other Other than the standard
values
unknown Unknown printer type
electrophotographic electrophotographic LED
-LED
electrophotographic electrophotographic laser
-laser
electrophotographic other electrophotographic
-other
impact-moving-head- 9-pin impact moving head
dot-matrix-9-pin dot matrix
impact-moving-head- 24-pin impact moving head
dot-matrix-24-pin dot matrix
impact-moving-head- neither 9-pin nor 24-pin
dot-matrix-other moving head dot matrix
impact-moving-head- fully formed impact moving
fully-formed head
impact-band impact band
impact-other impact other
inkjet-aqueous aqueous inkjet
inkjet-solid solid inkjet
inkjet-other other inkjet
pen pen
thermal-transfer thermal transfer
thermal-sensitive thermal sensitive
thermal-diffusion thermal diffusion
thermal-other other thermal
electro-erosion electro-erosion
electro-static electro-static
photographic- photographic microfiche
microfiche
photographic- photographic imagesetter
imagesetter
photographic-other other photographic
ion-deposition ion deposition
E-beam E-beam
typesetter typesetter
6.4.5 printer-state (type1Enum)
This attribute identifies the current state of the
printer and shall be set by the Printer. The protocol
support all values for printer states, however a Printer
shall only generate the printer states which are
appropriate for the particular implementation.
The following standard values are defined:
deBry, Hastings, Herriot, Isaacson [Page 64]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
unknown The printer state is not known, or is
indeterminate, or is not returned by
the operation
idle The printer is ready to accept jobs,
but none have been scheduled on it.
printing The printer is currently printing a
job
needs- The printer needs human attention (no
attention special skills required). This state
typically includes adding paper,
clearing a jam, changing the medium,
etc.
paused The operator has (temporarily) paused
the printer, by means outside the
scope of IPP V1.0.
shutdown The printer has been taken out of
service, (for a long time), whether
for repairs or others reasons. The
printer's message generic attribute
may be used to record a reason and
estimated time for return to service
job-start- The currently processing job was
wait started with the job-start-wait
attribute set, and is awaiting
operator intervention or time-out.
job-end- The currently processing job was
wait started with the job-end-wait
attribute set, and is awaiting
operator intervention or time-out.
job- The currently processing job was
password- started with the job-password
wait attribute set, and is awaiting the
operator or user to enter the
password supplied by the job-password
attribute.
needs-key- The printer needs the attention of a
operator key operator. Key operator functions
are printer-specific, but typically
include adding toner or developer, or
attending to a hardware fault.
connecting- The server has scheduled a job on the
to-printer printer and is in the process of
connecting to a shared network
printer (and may not be able to
actually start printing the job for
an arbitrarily long time depending on
the usage of the printer by other
servers).
deBry, Hastings, Herriot, Isaacson [Page 65]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
timed-out The server was able to connect to the
printer (or is always connected), but
was unable to get a response from the
printer in the time specified by the
printer's printer-timeout-period
attribute.
6.4.6 printer-state-message (string)
This attributes specifies a message that gives further
information about the current printer state and shall be
set by the Printer.
6.4.7 message (string)
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.
6.4.8 printer-job-templates (1#urlDefault)
This attribute identifies the URL of each of the Job
Templates that this Printer is associated with and the
one Job Template this Printer uses as its default for
supply job attributes that the client omits. There shall
be only one value with the default qualifier. Other
Printers can be associated with the same Job Templates.
The syntax is:
url [ ":" default ]
6.4.9 locale (type3Locale)
This attribute specifies the locale that the Printer
operates in.
The standard values are defined in the section on the
job-locale attribute.
6.4.10 notification-events (1#type2Enum)
This attribute specifies the events on whose occurrence
the Printer should notify those addresses specified by
the notification-addresses attribute.
deBry, Hastings, Herriot, Isaacson [Page 66]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
If the attribute is unspecified, the Printer does not
perform notification, though the Printer still checks the
job's notification-events attribute.
In this attribute, job-problem and printer-problem have
the same meaning.
The standard values are defined in the section on the
job's notification-events attribute.
NOTE - This attribute is intended to notify operators,
not end-users.
6.4.11 notification-addresses (1#url)
This attribute specifies the method and addresses to
which the Printer should send messages when events
specified by the notification-events attribute occur.
If the attribute is unspecified, the Printer does not
perform notification, though the Printer still checks the
job's notification-events attribute.
NOTE - This attribute is intended to notify operators,
not end-users.
6.4.12 end-user-acl (1#name)
This attribute specifies the end users who are allowed to
print on the Printer.
If the attribute is unspecified, the Printer allows
anyone to print.
6.4.13 maximum-printer-speed (positiveIntegerUnits)
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 minute. A
job cannot control a Printer's speed, but a Printer
Browser can use printer speed as a criteria.
The standard units are a type2Enum and are: ppm, ipm,
spm, lpm, cps.
deBry, Hastings, Herriot, Isaacson [Page 67]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
6.4.14 fonts-substitutions (1#stringPair)
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.
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.
6.4.15 fonts-supported (1#stringState)
This attribute identifies the font resources supported by
this printer and indicates the state of readiness for
each font.
The standard names are defined in the section on default-
font.
Each item in the list contains the pair consisting of a
font name and a state indicating the font's readiness
state.
6.4.16 media-supported (1#nameState)
This attribute identifies the media, media-sizes, input
trays, and electronic forms supported by this printer,
and indicates the state of readiness for each medium
resource.
The standard names are defined in the section on the
section on the medium-select.
Standard states are: not-ready, on-order, and special-
order. The omission of a state shall indicate that the
medium is ready, i.e., can be used without human
intervention..
6.4.17 document-formats-supported (1#type2FormatState)
This attribute identifies the document-formats, including
the document-format-versions, supported by the Printer.
This set includes both the formats that are native to the
Printer and those formats that the Printer can translate
to one that is native to the Printer. From the client's
deBry, Hastings, Herriot, Isaacson [Page 68]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
point of view, this set contains all formats in which
documents can be submitted to this Printer.
Proprietary document format identifiers, and versions are
assigned by the owners of those formats.
The state of readiness for each format is also included,
though all formats should normally always be ready.
6.4.18 numbers-up-supported (1#type3EnumState)
This attribute identifies 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.
6.4.19 finishings-supported (1#type2EnumState)
This attribute identifies the finishing operations
supported by this Printer and states of readiness for
each finishing.
The standard finishing objects are defined in the section
on the finishing Job attribute.
6.4.20 sides-supported (1#type2EnumState)
This attribute indicates the values of the sides
attribute supported by this printer and the states of
readiness of each value.
The standard values are defined in the section on the
sides attribute.
6.4.21 print-qualities-supported (1#type2EnumState)
This attribute 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.
deBry, Hastings, Herriot, Isaacson [Page 69]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
6.4.22 printer-resolutions-supported
(1#positiveIntegerCrossState)
This attribute 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 syntax is discussed in the section on the printer-
resolution-select attribute.
6.4.23 code-sets-supported (1#type3EnumState)
This attribute indicates the values of the default-code-
set attribute supported by this printer and the states of
readiness for each code-set.
The standard values are defined in the default-code-set
attribute.
6.4.24 off-peak-times-supported (1#type3EnumState)
This attribute indicates the values of the job-print-off-
peak attribute supported by this printer and the states
of readiness for each value.
If this attribute is unspecified, then the Printer has no
off-peak periods.
The standard values are defined in the section on the
job-print-off-peak Job attribute.
Note: this document does not define how an administrator
associates the off-peak names with actual time periods.
6.4.25 events-supported (1#type2EnumState)
This attribute indicates the values of the job and
printer notification-events attribute supported by this
Printer and the states of readiness for each value.
If this attribute is unspecified, then the Printer does
not support notification.
deBry, Hastings, Herriot, Isaacson [Page 70]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
The standard values are defined in the section on the
notification-events attribute.
6.4.26 locales-supported (1#type3LocaleState)
This attribute indicates the values of the job-locale
attribute supported by this Printer and the states of
readiness for each value.
The standard values are defined in the section on the
job-locale attribute.
6.4.27 job-sheets-supported (1#type3EnumState)
This attribute 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 this attribute.
The client specifies that there are no job sheets by
using the value "none" as the value of the job-sheets
attribute.
If the job-sheets attribute is not specified or contains
a value which the Printer does not support, then the
server shall select from among the values of this
attribute. The server shall not select the value "none"
unless it is the only value specified for the job-sheets-
supported attribute.
NOTE - When the client supplies a value other than
"none", it is preferable for the server to produce some
job jobsheet, even if not the desired one, rather than
produce none at all or reject the job.
6.4.28 maximum-copies (positiveInteger)
This attribute indicates the maximum number of copies of
a document that can be rendered by this printer in a
single print-job.
If the attribute is unspecified, there is no limit on the
maximum number of copies for this Printer.
deBry, Hastings, Herriot, Isaacson [Page 71]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
6.4.29 maximum-job-octets (positiveInteger)
This attribute indicates that the Printer shall accept a
job only if its size in octets is less that the value
specified by this attribute.
If the attribute is unspecified, there is no limit on the
size of a job in octets.
6.4.30 maximum-impressions (positiveInteger)
This attribute indicates that the Printer shall accept a
job only if its size in impression is less that the value
specified by this attribute.
If the attribute is unspecified, there is no limit on the
size of a job in impressions.
6.4.31 maximum-media-sheets (positiveInteger)
This attribute indicates that the Printer shall accept a
job only if its size in media-sheets is less that the
value specified by this attribute.
If the attribute is unspecified, there is no limit on the
size of a job in media-sheets.
6.4.32 maximum-job-retention-period (deltaTime)
This attribute indicates that when the Printer accepts a
job, the retention period must not exceed the value of
this attribute. Otherwise, the Printer sets the job's
retention-period to the value of this attribute.
If this attribute is unspecified, then the Printer places
no limit on the retention time.
6.4.33 maximum-end-user-priority (type1Enum)
This attribute indicates that when the Printer accepts a
job, the job-priority must not exceed the value of this
attribute. Otherwise, the Printer sets the job's job-
priority to the value of this attribute.
If this attribute is unspecified, then the Printer places
no limit on the job-priority.
deBry, Hastings, Herriot, Isaacson [Page 72]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
The standard values are defined in the section on the
job-priority attribute.
6.4.34 queued-job-count (cardinal)
This attribute contains a count of the number of jobs
that are either pending and/or processing and shall be
set by the Printer.
6.4.35 scheduling-algorithm (type3Enum)
This attribute indicates the current scheduling algorithm
for this Printer. Standard values are: "none",
"smallest-job-first", "time-received".
6.5 Job Templates
The attributes for a Job Template can be any of the Job
object attributes defined in the sections:
Job Sheet Attributes
Notification Attributes
Job Scheduling Attributes
(except job-print-after)
Job Production Attributes
(except page-select)
Attributes for Conversion of Text and HTML Files
6.6 Conformance
A conforming implementation shall implement all
operations, objects and attributes defined in this
document.
Also, for the core set of attributes listed in this
specification, 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
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.
deBry, Hastings, Herriot, Isaacson [Page 73]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
IPP is explicitly designed to be extensible. Additional
attributes can be proposed to be registered by going
through the type 2 enum 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.
7. Security Considerations
This protocol does not identify any new authentication
mechanisms. The authentication mechanisms built into HTTP
(such as SSL and SHTTP) are recommended.
This protocol does define a simple authorization
mechanism by introducing the "end-user-acl" attribute as
part of the Printer object. This ACL attribute is a
multi-valued list of all of the authenticated names of
end-users. This protocol does not specify what the
domain is for names in this ACL attribute.
Issue: Will it always be possible for a Printer to
obtain a meaningful authenticated name that the Printer
can match against the end-user-acl, or will some other
mechanism be necessary, such as a password?
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.
deBry, Hastings, Herriot, Isaacson [Page 74]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 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.
[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
deBry, Hastings, Herriot, Isaacson [Page 75]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
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
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 Ferrel - Canon
Hiro 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
deBry, Hastings, Herriot, Isaacson [Page 76]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
Jim Walker - Dazel
Jeff Copeland - QMS
Chuck Adams - Tektronix
deBry, Hastings, Herriot, Isaacson [Page 77]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
10. Appendix A: Sample IPP Operations
The following examples illustrate typical flows using the
IPP protocol. In these examples, the IPP Printer object
named "printer-1" is located at the node identified by
the DNS name "some.domain.com". A Job Template has been
defined for printer-1 which establishes the print
defaults.
For brevity in the following flows, none of the HTTP
headers are shown. CRLF sequences are not shown.
10.1 Querying the printer
Client some.domain.com
------------------------------------------------->
Post http://some.domain.com/printer-1 http/1.0
Get-Attributes IPP/1.0
printer-state :
sides-supported :
media-supported :
document-formats-supported :
<-------------------------------------------------
http/1.0 201 "Created" (a response)
IPP/1.0 xxx "attribute list returned"
printer-state : idle
sides-supported : 1-sided
media-supported : iso-a4-white, iso-b4-white
document-formats-supported : Postscript/2.0
deBry, Hastings, Herriot, Isaacson [Page 78]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
10.2 Print Operation - with print data included
Client some.domain.com
------------------------------------------------->
Post http://some.domain.com/printer-1 http/1.0
Print IPP/1.0
Print-Job-Object Header
job-name : My Job
medium : iso-a4-white
notification-events : Job-completion
notification-address : joe@pc.domain.com
Document Header
document-name : Letter to Mom
Document-Content Header (content type =
Postscript/2.0)
<Document in Postscript level 2 format>
<-------------------------------------------------
http/1.0 200 "accepted"
IPP/1.0 xxx "print job accepted and queued"
job-identifier : some.domain.com/printer-1/0037
current-job-state : pending
printer-state : needs-sttention
10.3 Print Operation - with no data included
Client some.domain.com
------------------------------------------------->
Post http://some.domain.com/printer-1 http/1.0
Print IPP/1.0
Print-Job-Object Header
job-name : My Job
medium : iso-a4-white
notification-events : Job-completion
notification-address : joe@some.domain.com
Document Header
document-name : Letter to Mom
document-URL : joe@pc.domain.com/Docs/To-mom.ps
<------------------------------------------------
http/1.0 200 "accepted"
IPP/1.0 xxx "print job accepted and queued"
job-identifier : some.domain.com/printer-1/0037
current-job-state : pending
printer-state : processing
deBry, Hastings, Herriot, Isaacson [Page 79]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
10.4 Querying the state of the job
In this example, no attributes are specified, so all job
attributes are returned.
Client some.domain.com
------------------------------------------------->
Post http://some.domain.com/printer-1/0037 http/1.0
Get-Attributes IPP/1.0
<------------------------------------------------
http/1.0 201 "Created" (a response)
IPP/1.0 xxx "atribute list returned"
job-Name : My Job
job-Originator : Joe@some.domain.com
job-originating-host : pc.domain.com
notification-address : joe@pc.domain.com
job-locale : xx:xx:xx
current-job-status : printing
submission-time : 1996 Nov 22 1214
media-sheets-completed : 2
10.5 Canceling a Job
Client some.domain.com
------------------------------------------------->
Post: http://some.domain.com/printer-1/0037
Cancel-Job IPP/1.0
<----------------------------------------------
http/1.0 200 "okay"
Current-job-state : terminating
deBry, Hastings, Herriot, Isaacson [Page 80]
Expires May 27, 1997
INTERNET-DRAFT IPP/1.0 November 1996
10.6 Listing jobs on a Printer
List jobs on printer-1, only return job sizes. Jobs are
returned in the order they are scheduled for printing. A
Job-identifier attribute precedes the attributes returned
for each job to delimit job boundaries.
Client some.domain.com
------------------------------------------------->
Post http/1.0 some.domain.com/printer-1
Get-Jobs IPP/1.0
total-job-octets :
<-------------------------------------------------
http/1.0 201 "Created" (a response)
IPP/1.0 xxx "created an attribute list"
job-identifier : 0033
total-job-octets : 4567
job-identifier : 0034
total-job-octets : 12345
job-identifier : 0035
total-job-octets : 12356
deBry, Hastings, Herriot, Isaacson [Page 81]
Expires May 27, 1997