draft-ietf-ipp-model-00.txt   draft-ietf-ipp-model-01.txt 
INTERNET-DRAFT R. deBry INTERNET-DRAFT
R. deBry
IBM Corporation IBM Corporation
T. Hastings T. Hastings
Xerox Corporation Xerox Corporation
R. Herriot R. Herriot
Sun Microsystems Sun Microsystems
S. Isaacson S. Isaacson
Novell, Inc. Novell, Inc.
P. Powell P. Powell
San Diego State University San Diego State University
March 26, 1997 June 3, 1997
Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Model and Semantics
draft-ietf-ipp-model-00.txt draft-ietf-ipp-model-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are This document is an Internet-Draft. Internet-Drafts are working
working documents of the Internet Engineering Task Force documents of the Internet Engineering Task Force (IETF), its areas, and
(IETF), its areas, and its working groups. Note that its working groups. Note that other groups may also distribute working
other groups may also distribute working documents as documents as Internet-Drafts.
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum Internet-Drafts are draft documents valid for a maximum of six months
of six months and may be updated, replaced, or obsoleted and may be updated, replaced, or obsoleted by other documents at any
by other documents at any time. It is inappropriate to time. It is inappropriate to use Internet-Drafts as reference material
use Internet-Drafts as reference material or to cite them or to cite them other than as "work in progress".
other than as "work in progress."
To learn the current status of any Internet-Draft, please To learn the current status of any Internet-Draft, please check the
check the "1id-abstracts.txt" listing contained in the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Internet-Drafts Shadow Directories on ftp.is.co.za Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US ftp.isi.edu (US West Coast).
West Coast).
Abstract Abstract
This document is one of a set of documents which together This document is one of a set of documents, which together describe all
describe all aspects of a new Internet Printing Protocol aspects of a new Internet Printing Protocol (IPP). IPP is an
(IPP). IPP is an application level protocol that can be application level protocol that can be used for distributed printing
used for distributed printing on the Internet. The using Internet tools and technology. The protocol is heavily influenced
protocol is heavily influenced by the printing model by the printing model introduced in the Document Printing Application
introduced in the Document Printing Application (ISO/IEC (ISO/IEC 10175 DPA) standard. Although DPA specifies both end user and
10175 DPA) standard. Although DPA specifies the both end administrative features, IPP version 1.0 is focused only on end user
user and administrative features, IPP version 1.0 functionality.
(v1.0)is focused only on end user functionality.
draft-ietf-ipp-model-00.txt, expires September 26, 1997
The full set of IPP documents includes: The full set of IPP documents includes:
June 3, 1997, Expires December 3, 1997
Internet Printing Protocol: Requirements Internet Printing Protocol: Requirements
Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Model and Semantics
Internet Printing Protocol/1.0: Security Internet Printing Protocol/1.0: Security
Internet Printing Protocol/1.0: Protocol Specification Internet Printing Protocol/1.0: Protocol Specification
Internet Printing Protocol/1.0: Directory Schema Internet Printing Protocol/1.0: Directory Schema
The requirements document takes a broad look at The requirements document takes a broad look at distributed printing
distributed printing functionality, and it enumerates functionality, and it enumerates real-life scenarios that help to
real-life scenarios which help to clarify the features clarify the features that need to be included in a printing protocol for
that need to be included in a printing protocol for the the Internet. It identifies requirements for three types of users: end
Internet. It identifies requirements for three types of users, operators, and administrators. The requirements document calls
users: end users, operators, and administrators. The out a subset of end user requirements that must be satisfied in the
requirements document calls out a subset of end user first version of IPP. Operator and administrator requirements are out
requirements which must be satisfied in the first version of scope for v1.0. The model and semantics document describes a
of IPP. Operator and administrator requirements are out simplified model with abstract objects, their attributes, and their
of scope for v1.0. The model and semantics document operations. The model introduces a Printer object and a Job object. The
describes a simplified model with abstract objects, their Job object supports multiple documents per job. The security document
attributes, and their operations. The model introduces a covers potential threats and proposed counters to those threats. The
Printer object and a Job object. The Job object supports protocol specification is formal document which incorporates the ideas
multiple documents per job. The security document covers in all the other documents into a concrete mapping using clearly defined
potential threats and proposed counters to those threats. data representations and transport protocol mappings that real
The protocol specification is formal document which implementers can use to develop interoperable client and server side
incorporates the ideas in all the other documents into a components. Finally, the directory schema document shows a generic
concrete mapping using clearly defined data schema for directory service entries that represent instances of IPP
representations and transport protocol mappings that real Printers.
implementers can use to develop interoperable client and
server side components. Finally, the directory schema
document shows a generic schema for directory service
entries that represent instances of IPP Printers.
This document is the "Internet Printing Protocol/1.0: This document is the "Internet Printing Protocol/1.0: Model and
Model and Semantics" document. Semantics" document.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 June 3, 1997, Expires December 3, 1997
Table of Contents Table of Contents
1. Introduction............................................7 1. 6
Introduction..........................................................7
2. Terminology........................................................7
2.1 Conformance Terminology........................................8
2.1.1 MUST......................................................8
2.1.2 MUST NOT..................................................8
2.1.3 SHOULD....................................................8
2.1.4 SHOULD NOT................................................8
2.1.5 MAY.......................................................8
2.1.6 CONDITIONALLY MANDATORY...................................8
2.1.7 NEED NOT..................................................9
2.2 Model Terminology..............................................9
2.2.1 Keyword...................................................9
2.2.2 Attributes................................................9
2.2.3 Attribute Name............................................9
2.2.4 Group Name................................................9
2.2.5 Attribute Value..........................................10
2.2.6 Attribute Syntax.........................................10
2.2.7 Implements...............................................10
2.2.8 Supports.................................................10
3. Simplified Printing Model.........................................11
4. IPP Objects.......................................................13
4.1 Printer Object................................................13
4.2 Job Object....................................................15
4.3 Document Object...............................................16
4.4 Object Relationships..........................................17
4.5 Object Attributes.............................................17
4.5.1 Job Template Attribute Overview..........................17
4.5.2 The "best-effort" Job Attribute Overview.................18
4.6 Object Identity...............................................19
5. IPP Operations....................................................19
5.1 Operation Semantics...........................................20
5.1.1 Print-Job Operation......................................20
5.1.1.1 Print-Job Request...................................20
5.1.1.2 Print-Job Response..................................22
5.1.2 Create-Job Operation.....................................23
5.1.2.1 Create-Job Request..................................23
5.1.2.2 Create Job Response.................................24
5.1.3 Send-Document Operation..................................25
5.1.3.1 Send-Document Request...............................25
5.1.3.2 Send-Document Response..............................25
5.1.4 Cancel Job Operation.....................................26
5.1.4.1 Cancel-Job Request..................................26
5.1.4.2 Cancel-Job Response.................................26
5.1.5 Get-Attributes Operation.................................26
5.1.5.1 Get-Attributes Request..............................27
1.1 Conformance ..........................................8 June 3, 1997, Expires December 3, 1997
1.1.1 Client Considerations .............................9 5.1.5.2 Get-Attributes Response.............................28
1.1.2 Server Considerations .............................9 5.1.6 Get-Jobs Operation.......................................29
5.1.6.1 Get-Jobs Request....................................29
5.1.6.2 Get-Jobs Response...................................30
5.2 Operation Status and Messages.................................31
5.3 Status Codes (type2 keyword)..................................31
6. Object Attributes.................................................31
6.1 Attribute Syntaxes............................................32
6.1.1 Attribute Extensibility..................................35
6.2 Job Template Attributes.......................................36
6.2.1 job-name (name)..........................................41
6.2.2 job-sheets (type4 keyword)...............................42
6.2.3 notification-events (1setOf type2 keyword)...............42
6.2.4 notification-addresses (1setOf uri)......................42
6.2.5 job-priority (integer(1:100))............................43
6.2.6 job-hold-until (type4 keyword)...........................43
6.2.7 multiple-documents-are (type2 keyword)...................44
6.2.8 best-effort (type2 keyword)..............................44
6.2.9 media (type4 keyword)....................................45
6.2.10 number-up (type3 keyword)...............................46
6.2.11 sides (type2 keyword)...................................46
6.2.12 printer-resolution (type2 keyword)......................47
6.2.13 print-quality (type2 keyword)...........................47
6.2.14 copies (integer(1:2**31 - 1))...........................48
6.2.15 finishings (1setOf type2 keyword).......................48
6.2.16 compression (type3 keyword).............................48
6.2.17 job-k-octets (integer(0:2**31 - 1)).....................48
6.2.18 job-impressions (integer(0:2**31 - 1))..................49
6.2.19 job- media-sheets (integer(0:2**31 - 1))................49
6.3 Job Attributes................................................49
6.3.1 Job Template Attributes..................................49
6.3.2 Job Description Attributes...............................49
6.3.2.1 job-URI (uri).......................................51
6.3.2.2 job-originating-user (name).........................51
6.3.2.3 job-originating-host (name).........................51
6.3.2.4 user-locale (type3 keyword).........................51
6.3.2.5 job-state (type1 keyword)...........................51
6.3.2.6 job-state-reasons (1setOf type2 keyword)...........55
6.3.2.7 job-state-message (text)............................58
6.3.2.8 output-device-assigned (uri)........................58
6.3.2.9 time-since-submission (milliseconds)................58
6.3.2.10 time-since-processing (milliseconds)...............58
6.3.2.11 number-of-intervening-jobs (integer(0:2**31 - 1))..58
6.3.2.12 job-message-from-operator (text)...................59
6.3.2.13 time-since-completion (milliseconds)...............59
6.3.2.14 job-k-octets-completed (integer(0:2**31 - 1))......59
6.3.2.15 job-impressions-completed (integer(0:2**31 - 1))..59
6.3.2.16 job-media-sheets-completed (integer(0:2**31 - 1))..59
2. Simplified Printing Model..............................10 June 3, 1997, Expires December 3, 1997
6.4 Document Attributes...........................................59
6.4.1 document-name(name, Mandatory)...........................60
6.4.2 document-format (type2 keyword)..........................60
6.4.3 document-URI (uri).......................................61
6.5 Printer Attributes............................................61
6.5.1 Printer Job Template Attributes..........................61
6.5.2 Printer Description Attributes..........................61
6.5.2.1 printer-URI (uri)...................................63
6.5.2.2 printer-name (name).................................63
6.5.2.3 printer-location (text).............................63
6.5.2.4 printer-description (text)..........................63
6.5.2.5 printer-more-info-site (uri)........................64
6.5.2.6 printer-driver-installer (uri)......................64
6.5.2.7 printer-make-and-model (text).......................64
6.5.2.8 maximum-printer-speed (integerUnits)................64
6.5.2.9 printer-more-info-manf (uri)........................64
6.5.2.10 printer-state (type1 keyword)......................65
6.5.2.11 printer-state-reasons (1setOf type2 keyword).......67
6.5.2.12 printer-is-accepting-jobs (boolean)................69
6.5.2.13 printer-state-message (text).......................69
6.5.2.14 queued-job-count (integer(0:2**31 - 1))............70
6.5.2.15 printer-message-from-the-operator (text)...........70
6.5.2.16 printer-locale (locale)............................70
6.5.2.17 printer-locales-supported (1setOf locale)..........70
7. Conformance.......................................................70
7.1 Conditionally Mandatory.......................................70
7.2 Client Conformance Requirements...............................71
7.3 Printer Object Conformance Requirements.......................71
7.3.1 Objects..................................................71
7.3.2 Operations...............................................71
7.3.3 Attributes...............................................72
7.3.4 Default Value............................................72
7.3.5 Availability.............................................73
7.3.6 Printer extensions.......................................73
7.3.7 Attribute Syntaxes.......................................73
7.4 Security Conformance Requirements.............................73
8. IANA Considerations, Registered Extensions, Private Extensions....73
9. Security Considerations...........................................74
10. References.......................................................74
11. Author's Address.................................................75
12.77
Change History.......................................................78
12.1 Changes made to version 970512, dated 12-May-1997 to make
version 970603, dated 03-June-1997...............................78
12.2 Changes made to version 970509, dated 9-May-1997 to make version
970512, dated 12-May-1997.........................................78
12.3 Changes made to version 2.2, dated 5-May-1997 to make version
970509, dated 9-May-1997..........................................79
3. IPP Objects............................................14 June 3, 1997, Expires December 3, 1997
12.4 Changes made to version 2.1, dated 24-April-1997 to make version
2.2, dated 5-May-1997.............................................79
12.5 Changes made to version 2.0, dated 26-March-1997 to make version
2.1, dated 22-April-1997..........................................79
12.6 Changes made to version 1.8, dated 24-March-1997 to make version
2.0, dated 26-March-1997..........................................79
12.7 Changes made to version 1.7, dated 24-Mar-1997 to make version
1.8, dated 24-March-1997..........................................79
12.8 Changes made to version 1.6, dated 12-Mar-1997 to make version
1.7, dated 24-March-1997..........................................80
12.9 Changes made to version 1.5, dated 11-Mar-1997 to make version
1.6, dated 12-March-1997..........................................80
12.10 Changes made to version 1.4, dated 27-Feb-1997 to make version
1.5, dated 9-March-1997...........................................82
3.1 Printer .............................................14 1.
3.2 Job .................................................17 June 3, 1997, Expires December 3, 1997
Introduction
3.3 Document Object .....................................18 The Internet Printing Protocol (IPP) is an application level protocol
that can be used for distributed printing on the Internet. The protocol
is heavily influenced by the printing model introduced in the Document
Printing Application (ISO/IEC 10175 DPA) standard. Although DPA
identifies both end user and administrative features, the first version
of IPP is focused only on end user functionality.
3.4 Object Relationships ................................19 Section 2. Terminology introduces the terminology used within this
document.
3.5 Object Attributes ...................................19 Section 0 introduces the simplified IPP model. The IPP model is made
simple by exposing only the objects, attributes, and operations that are
essential for end user access and control of the print subsystem. When
future versions of IPP include features which satisfy operator and
administrator requirements, the model can be extended to support the
appropriate objects, attributes, and operations.
3.6 Object Identity .....................................21 Section 0 introduces the full semantics of the Printer, Job, and
Document objects in the IPP model. It covers how instances of these
objects are identified, named, and related to each other.
4. IPP Operations.........................................22 Section 0 covers the operations that are part of the IPP model. These
operations include: the Create-Job, Send-Document, Print-Job, Cancel,
Get-Attributes, and Get-Jobs operations.
4.1 Introduction ........................................22 Section 0 describes the attributes, their syntaxes, and semantics which
are part of the IPP model. Each object's attributes are described, and
the attributes are grouped into logical groups to help clarify their
relationships and meaning. These groups are also used to simplify
queries that request multiple attributes.
4.2 Operation Semantics .................................23 Section 7. Conformance is a review of conformance issues and clarifies
4.2.1 Print Operation ..................................23 requirements that apply to client side and server side implementations.
4.2.1.1 Print Request ................................24
4.2.1.2 Print Response ...............................25
4.2.2 Cancel Job Operation .............................25
4.2.2.1 Cancel-Job Request ...........................26
4.2.2.2 Cancel-Job Response ..........................26
4.2.3 Get Attributes Operation .........................26
4.2.3.1 Get-Attributes Request .......................27
4.2.3.2 Get-Attributes Response ......................27
4.2.4 Get Jobs Operation ...............................28
4.2.4.1 Get-Jobs Request .............................28
4.2.4.2 Get-Jobs Response ............................29
draft-ietf-ipp-model-00.txt, expires September 26, 1997 Sections 8. IANA Considerations, Registered Extensions, Private
5. Object Attributes......................................30 Extensions-11. Author's Address cover extensibility, security, technical
references, and author information.
5.1 Attribute Syntaxes ..................................30 2. Terminology
5.1.1 Attribute Extensibility ..........................34
5.1.2 Relationship of Job and Printer Attributes .......36
5.1.3 Attribute Value Tags .............................38
5.1.3.1 Tagged Printer Attributes ....................38
5.1.3.2 Tagged Job Attributes ........................39
5.2 Job Template (job-template) Attributes ..............39 This specification uses the terminology defined in this section.
5.2.1 Job Sheet Attributes (Set by Client/End User) ....40
5.2.1.1 job-sheets (type4 keyword) ...................40
5.2.2 Job Notification (job-notification) Attributes (Set
by a Client/End User) ..................................41
5.2.2.1 notification-events (setOf type2 keyword) ....41
5.2.2.2 notification-addresses (setOf url) ...........42
5.2.3 Job Scheduling (job-scheduling) Attributes (Set by
Client/End User) .......................................43
5.2.3.1 job-priority (integer(1:100)) ................43
5.2.3.2 job-hold-until (type4 keyword) ...............44
5.2.4 Job Production (job-production) Attributes (Set by
Client/End User) .......................................45
5.2.4.1 multiple-documents-are (type1 keyword) .......47
5.2.4.2 best-effort (type2 keyword) ..................48
5.2.5 Document Production (document-production)
Attributes (Set by Client/End User) ....................49
5.2.5.1 medium (setOf type2 keyword) .................49
5.2.5.2 number-up (type3Enum) ........................57
5.2.5.3 sides (type2 keyword) ........................58
5.2.5.4 printer-resolution (type2 keyword) ...........59
5.2.5.5 print-quality (type2 keyword) ................60
5.2.5.6 copies (integer(1:2**31 - 1)) ................61
5.2.5.7 finishing (setOf type2 keyword) ..............61
5.2.5.8 compression (type2 keyword) ..................63
5.2.6 Document Format Attributes (Set by Client/End User)63
5.2.6.1 document-format (type2 keyword) ..............63
5.2.7 Job Size (job-size) Attributes (Set by Client and
Printer) ...............................................68
5.2.7.1 job-k-octets (integer(0:2**31 - 1)) ..........69
5.2.7.2 job-impressions (integer(0:2**31 - 1)) .......70
5.2.7.3 job-media-sheets (integer(0:2**31 - 1)) ......70
5.2.8 Number of Documents (Set by Printer) .............71
5.2.8.1 number-of-documents (integer(1:2**31 - 1)) ...71
5.3 Job Attributes Set by the Printer ...................71 June 3, 1997, Expires December 3, 1997
5.3.1 Job Identification (job-identification) Attributes 2.1 Conformance Terminology
(Set by the Printer) ...................................71
5.3.1.1 job-URL (url) ................................71
draft-ietf-ipp-model-00.txt, expires September 26, 1997 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
5.3.2 Job Owner (job-owner) Attributes (Set by a Printer)72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
5.3.2.1 job-originating-user (name) ..................72 document are to be interpreted as described in RFC 2119 [25].
5.3.2.2 job-originating-host (name) ..................72
5.3.2.3 user-locale (type3 keyword) ..................72
5.3.2.4 job-name (name) ..............................73
5.3.3 Job Status (job status) Attributes (Set by Printer)73
5.3.3.1 job-state (type1 keyword) ....................73
5.3.3.2 job-state-reasons (setOf type2 keyword) .....76
5.3.3.3 job-state-as-text (text) .....................78
5.3.3.4 output-device-assigned (url) .................78
5.3.3.5 submission-time (dateTime) ...................79
5.3.3.6 number-of-intervening-jobs (integer(0:2**31 -
1)) ..................................................79
5.3.3.7 job-message-from-operator (text) .............79
5.3.3.8 completion-time (dateTime) ...................79
5.4 Document Attributes .................................80 2.1.1 MUST
5.4.1 Document Data (document-data) Attributes (Set by a
Client/End User) .......................................80
5.4.1.1 document-name (name) .........................80
5.4.1.2 document-URL (url) ...........................80
5.4.1.3 document-content (octetString) ...............81
5.5 Printer Description (printer-description) Attributes81 This word, or the terms "REQUIRED", "SHALL" or "MANDATORY", mean that
5.5.1 Printer Identification (printer-identification the definition is an absolute requirement of the specification.
Attributes (Set by the Administrator) ..................81
5.5.1.1 printer-URL (url) ............................81
5.5.1.2 printer-name (name) ..........................81
5.5.2 Printer Description Attributes (Set by the
Administrator) .........................................82
5.5.2.1 printer-location (text) ......................82
5.5.2.2 printer-description (text) ...................83
5.5.2.3 printer-more-info-site (url) .................83
5.5.2.4 printer-driver-installer (url) ..............83
5.5.3 Printer Description Attributes (Set by the
Manufacturer) ..........................................83
5.5.3.1 printer-make-and-model (text) ................83
5.5.3.2 maximum-printer-speed (integerUnits) .........83
5.5.3.3 printer-more-info-manf (url) .................84
5.6 Printer Status (printer-status)Attributes ...........84 2.1.2 MUST NOT
5.6.1 Printer Status Attributes (Set by the Printer) ...84
5.6.1.1 printer-state (type1 keywordEnum) ............84
5.6.1.2 printer-state-reasons (setOf type2 keyword) ..86
5.6.1.3 printer-is-accepting-jobs (boolean) ..........89
5.6.1.4 printer-state-as-text (text) .................89
5.6.1.5 queued-job-count (integer(0:2**31 - 1)) ......90
draft-ietf-ipp-model-00.txt, expires September 26, 1997 This phrase, or the phrase "SHALL NOT", mean that the definition is an
5.6.2 Printer Status Attributes (Set by the absolute prohibition of the specification.
Administrator) .........................................90
5.6.2.1 printer-message-from-the-operator (text) .....90
5.7 Printer Behavior (printer-behavior) Attributes ......90 2.1.3 SHOULD
5.7.1 Printer Behavior Attributes (set by the
Administrator) .........................................90
5.7.1.1 printer-locale (locale) ......................90
5.7.1.2 fonts-substitutions (setOf setOf font) .......90
5.7.1.3 scheduling-algorithm (type3 keyword) .........91
5.7.1.4 printer-fonts (setOf font) ...................91
6. IANA Considerations....................................91 This word, or the adjective "RECOMMENDED", mean that there may exist
valid reasons in particular circumstances to ignore a particular item,
but the full implications must be understood and carefully weighed
before choosing a different course.
7. Security Considerations................................92 2.1.4 SHOULD NOT
8. References.............................................92 This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist
valid reasons in particular circumstances when the particular behavior
is acceptable or even useful, but the full implications should be
understood and the case carefully weighed before implementing any
behavior described with this label.
9. Author's Address.......................................93 2.1.5 MAY
draft-ietf-ipp-model-00.txt, expires September 26, 1997 This word, or the adjective "OPTIONAL", mean that an item is truly
1. Introduction optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that it
enhances the product while another vendor may omit the same item. An
implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does include
the option, though perhaps with reduced functionality. In the same vein
an implementation which does include a particular option MUST be
prepared to interoperate with another implementation which does not
include the option (except, of course, for the feature the option
provides.)
The Internet Printing Protocol (IPP) is an application 2.1.6 CONDITIONALLY MANDATORY
level protocol that can be used for distributed printing
on the Internet. The protocol is heavily influenced by
the printing model introduced in the Document Printing
Application (ISO/IEC 10175 DPA) standard. Although DPA
identifies both end user and administrative features, the
first version of IPP is focused only on the end user
functionality.
Section 2 is a comparison between the new IPP model and a June 3, 1997, Expires December 3, 1997
generic description of the various solutions and This term means that an item MUST be implemented in a conforming
architectures that exist in today's distributed printing implementation if the item corresponds to a feature or behavior that the
products. This section shows a high level mapping implementation is capable of realizing. It is also true, that a
between the complex set of inter-dependent distributed conforming implementation NEED NOT implement the items that correspond
printing components and the IPP model. This new IPP to features or behaviors that the implmentation is not capable of
model simplifies the back-end implementations by exposing realizing.
only the objects, attributes, and operations that are
essential for end user access and control of the print
subsystem. When future versions of IPP include operator
and administrator requirements, the model can be extended
to support the appropriate objects, attributes, and
operations.
Section 3 introduces the full semantics of the new 2.1.7 NEED NOT
Printer, Job, and Document objects in the IPP model. It
covers how instances of these objects are identified,
named, and related to each other.
Section 4 covers the operations which are part of the IPP The verb "NEED NOT" indicates an action that the subject of the sentence
model. These operations include: the Print, Cancel, Get does not have to implement in order to claim conformance to the
Attributes, and Get Jobs operations. The Print and Get standard. The verb "NEED NOT" is used instead of "MAY NOT" since "MAY
Jobs operations are performed by a Printer. The Get NOT" sounds like a prohibition.
Attributes operation is performed by either a Printer or
a Job. A Cancel Job operation is performed on a Job
object.
Section 5 describes the attributes, their syntaxes, and 2.2 Model Terminology
semantics which are part of the IPP model. Each object's
attributes are described, and the attributes are grouped
into logical groups to help clarify their relationships
and meaning.
Sections 6-9 cover security, technical references, and 2.2.1 Keyword
author contact information.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 Keywords are used within this document as identifiers of semantic
1.1 Conformance entities within the abstract model. These entities are often attribute
names, attribute values, attribute syntaxes, and attribute groups. In
this document, a keyword is a sequence of characters (length of 1 to
255) which consists of the following ASCII characters: letters, digits,
hyphen ("-"), and underscore ("_"). A keyword MUST start with a letter.
In the actual protocol, these keywords will be represented using an
appropriate protocol encoding (strings, enumerated values, constants,
operation codes, identifiers, etc.).
This specification uses the verbs: "shall", "should", 2.2.2 Attributes
"may", and "need not" to specify conformance requirements
as follows:
- "shall": indicates an action that the subject of the An attribute is an item of information consisting of an attribute name
sentence must implement in order to claim conformance to and attribute value(s) using a specific syntax for that attribute. All
this specification attributes are defined in section 6. Object Attributes. Attributes
are identified as being "MANDATORY", "CONDITIONALLY MANDATORY", or
"OPTIONAL".
- "may": indicates an action that the subject of the 2.2.3 Attribute Name
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 Each attribute is uniquely identified in this document by its attribute
the sentence does not have to implement in order to claim name which is a keyword. The keyword attribute name is given in the
conformance to this specification. The verb "need not" section header describing that attribute. In running text in this
is used instead of "may not", since "may not" sounds like document, attribute names are indicated inside double quotation marks
a prohibition. (").
- "should": indicates an action that is recommended for 2.2.4 Group Name
the subject of the sentence to implement, but is not
required, in order to claim conformance to this
specification.
A conforming implementation shall implement all Related attributes are grouped into named groups. The name of the group
operations and objects defined in this document. is a keyword. It can be used wherever an attribute name is used in
Attributes are conditionally mandatory. This means that June 3, 1997, Expires December 3, 1997
an implementation need not include an attribute if the place of naming all the attributes in the group explicitly. Attribute
attribute controls a feature that the implementation does groups are defined in section 6. Object Attributes.
not support. For example, a printer that can only print
on one side need not implement the "sides" attribute. A
printer that does not support any of the finishing
attribute values, need not implement the "finishing"
attribute. An implementation that does not allow for
non-ready supported values in addition to ready values,
need not implement a full set of possibly supported
values. A printer with only a single input tray with
only one media type in that tray need not implement the
"media" attribute.
Some of the attributes include values which are 2.2.5 Attribute Value
extensible. The set of attributes themselves are also
extensible. Therefor, an IPP implementation (either
client or server) shall support these extensions. Some
implementations may choose to ignore private extensions,
draft-ietf-ipp-model-00.txt, expires September 26, 1997 Each attribute shall have one or more values. Attribute values shall be
others my be able to support these values. On the client represented in the syntax type specified for that attribute. In running
side, this might mean displaying the values to the end text in this document, attribute values are indicated inside single
user via some extensible user interface mechanism. On quotation marks ('), whether their syntax types are keyword, integer,
the server side, it might mean actually performing the text, etc.
semantic action implied by the new value. In either
case, the operation shall not fail because either the
client or server does not understand extended values or
attributes.
IPP allows for variations on attributes using a mechanism 2.2.6 Attribute Syntax
called "attribute tags" or "adornments" (see section
5.1.3). Clients can supply attributes with tags that
represent variations on the normal (unadorned) attribute
semantics. Servers can also respond with tagged
attribute information. Tags are most applicable and
useful in more sophisticated implementations. Therefor,
all adornment tags are optional for conforming
implementations. This allows for interoperability since
the behavior of implementations which can not support the
semantics of the adornment tags is consistent with the
behavior implied by the absence of all tags.
1.1.1 Client Considerations Each attribute is defined using an explicit syntax. In this document,
each syntax type is defined as a keyword with specific meaning. The
protocol specification document [23] shall indicate the actual
representation for each syntax type that shall be used for the actual
protocol. Attribute syntaxes are defined in section 6.1 Attribute
Syntaxes.
IPP clients shall support all operations, objects, and 2.2.7 Implements
attributes as defined in this document. However, there
is no conformance requirements placed on the user
interfaces provided by IPP clients or their applications.
For example, one application might not allow an end user
to submit multiple documents per job, while another does.
One application might first query a Printer object in
order to supply a graphical user interface (GUI) dialogue
box with current supported and default values whereas a
different application might not. A conforming client may
choose to ignore any adornment tags it does not
understand.
1.1.2 Server Considerations By definition, an attribute is implemented if, in response to a query
for that attribute, an implementation responds with both the attribute
and a current value (or values) for that attribute. . A conforming
implementation SHALL implement all MANDATORY attributes and it SHALL
implement all CONDITIONALLY MANDATORY attributes whose possible values
correspond to the behaviors that the implementation is capable of
realizing.
It is not required that a conforming server support all 2.2.8 Supports
(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
draft-ietf-ipp-model-00.txt, expires September 26, 1997 By definition, a job processing behavior or selectable feature is
recognize the attribute and those values that are supported by Printer only if that Printer implements the corresponding
supported, and shall be able to respond to a query about "supported" attribute populated with the value representing that
which values that printer does, in fact, support. A behavior or feature. A given implementation may exhibit a behavior that
conforming server shall ignore any adornment tags it does corresponds to the value of some supported attribute, but if the
not understand. implementation, when queried for that attribute, doesn't respond with
the supported attribute populated with that specific value, then as far
as IPP is concerned, that Printer does not support that feature.
Section 6. Object Attributes describes all of the Printer object's
supported attributes. Most of the Printer object's supported attributes
are OPTIONAL or CONDITIONALLY MANDATORY, therefore conformance to IPP
does not mandate that all implementations support all possible value
representing all possible job processing behaviors and features.
2. Simplified Printing Model June 3, 1997, Expires December 3, 1997
For example, if a given instance of a Printer supports only certain
document formats, then that Printer SHALL implement the "document-
format-supported" attribute and that attribute SHALL be populated with a
set of values, possibly only one, taken from the entire set of possible
values defined in this model document. This implemented set of values
represent the Printer's set of supported document formats. Another
example is the "finishings-supported" attribute. If a Printer is not
physically capable of stapling (there is no stapler in the output device
itself), the "finishings-supported" attribute MUST NOT be implemented
with the value of 'staple'. Note: The supported attributes are set
(populated) by some administrative process or automatic sensing
mechanism which is outside the scope of IPP.
In order to a achieve its goal of realizing a workable 3. Simplified Printing Model
printing protocol for the Internet, IPP is based on a
simplified printing model which abstracts the many (often
complex) real world printing solutions. Many of these
include features, interfaces, and relationships that are
beyond the scope of IPP. IPP has to run in a distributed
computing environment where requesters of print services
(clients, applications, PC drivers, etc.) cooperate and
interact with print service providers. Although the
underlying configuration may be a complex n-tier
client/server system, an important simplifying step in
the IPP model is to expose only the key objects and
interfaces. The IPP model encapsulates the important
elements into three simple objects:
Printer (section 3.1) In order to a achieve its goal of realizing a workable printing protocol
Job (section 3.2) for the Internet, IPP is based on a simplified printing model which
Document (section 3.3) abstracts the many (often complex) components of real world printing
solutions. Many of these systems include features, interfaces, and
relationships that are beyond the scope of IPP. IPP has to run in a
distributed computing environment where requesters of print services
(clients, applications, PC drivers, etc.) cooperate and interact with
print service providers. Although the underlying configuration may be a
complex n-tier client/server system, an important simplifying step in
the IPP model is to expose only the key objects and interfaces required
for printing. The IPP model encapsulates these important elements into
three simple objects:
Each of these objects has a set of operations associated Printer (Section 0)
with it. These include: Job (Section 0)
Document (Section 0)
Printer: Each of these objects has a set of operations associated with it. These
Print (section 4.2.1) include:
Get Attributes (section 4.2.3)
Get Jobs (section 4.2.4)
Job object
Get Attributes (section 4.2.3)
Cancel Job (section 4.2.2)
There are no operations defined for a Document object. Printer:
All document information is accessed through a Job object Create-Job (Section 0)
and its operations. Print-Job (Section ???)
Get-Attributes (Section 0)
Get-Jobs (Section 0)
Job
Send-Document(section ???)
Get-Attributes (Section 0)
Cancel Job (Section 0)
It is important, however, to understand that in real June 3, 1997, Expires December 3, 1997
system implementations (which lie underneath the There are no operations defined for a Document object. All document
abstracted IPP model), there are other components of a information is accessed through a Job object and its operations.
print service which are not explicitly modeled in the IPP
model. These components allow for additional operator
draft-ietf-ipp-model-00.txt, expires September 26, 1997 It is important, however, to understand that in real system
and administrator functionality. These components are implementations (which lie underneath the abstracted IPP model), there
illustrated in the following figure: are other components of a print service which are not explicitly defined
in the IPP model. The following figure illustrates where IPP fits with
respect to these other components.
+--------------+ +--------------+
| Application | | Application |
+------+-------+ o +. . . . . . . |
|
o +..............+
\|/ | Spooler | \|/ | Spooler |
/ \ +..............+ / \ +. . . . . . . | +---------+
End-User | End-User | Print Driver |---| File |
+-----------+ +-----+ +..............+ Existing +-----------+ +-----+ +------+-------+ +----+----+
| Browser | | GUI | | Print Driver | Print | Browser | | GUI | | |
+-----+-----+ +--+--+ +..............+ Client +-----+-----+ +--+--+ | |
| | | | | | | |
| +---+------------+---+ +----+----+ | +---+------------+---+ |
N D S | | IPP Client |<--| Gateway | N D S | | IPP Client |------------+
O I E | +---------+----------+ +---------+ O I E | +---------+----------+
T R C | | T R C | |
I E U | I E U |
F C R -------------- Transport -------- F C R -------------- Transport ------------------
I T I I T I
C O T | --+ C O T | --+
A R Y +--------+--------+ | A R Y +--------+--------+ |
T Y | IPP Server | | T Y | IPP Server | |
I +--------+--------+ | I +--------+--------+ |
O | | O | |
N +.................+ | IPP Printer N +.................+ | IPP Printer
| Print Service | | | Print Service | |
+.................+ | +.................+ |
| | | |
Output Device(s) | Output Device(s) |
--+ --+
This figure shows that the abstraction of a Printer IPP Printers encapsulate the functions normally associated with physical
object not only supports the functionality of the actual output devices along with the spooling, scheduling and multiple device
output device but additionally supports (where management functions associated with a print server. Printers may be
implementation configuration requires) the spooling, registered as entries in a directory where end users find and select
scheduling, and multiple output device management them based on some sort of filtered and context based searching. The
functions often associated with a print server. directory is used to store relatively static information about the
In the IPP model, users take on the role of end users,
operators, or administrators based on authentication and
authorization mechanisms provided through the security
service(s). Printers are registered as entries in the
directory. End users find and select Printers based on
some sort of filtered and context based searching using
draft-ietf-ipp-model-00.txt, expires September 26, 1997
the directory. The directory is used to store relatively
static information about the Printer. This allows end
users to search for and find Printers that match their
search criteria (name, context, printer capabilities,
etc.) All information about the Printer, both static and
dynamic information, can be accessed directly from the
Printer itself. The more dynamic information associated
with a Printer includes state, currently loaded and ready
media, number of jobs, errors, warnings, etc. Once an
end user selects a Printer, the end user interacts with
that Printer in order to determine status and
capabilities of the Printer and then submits jobs to the
Printer. When a job is submitted to the Printer, a Job
object is created. The end user then interacts with this
new Job to query its status and monitor the progress of
the job. End users may also cancel the Job. The end
user is able to register to receive certain events which
are then routed using the notification service(s).
It should be obvious, that not all existing or even
future print subsystems conform to this model directly.
The IPP model however, can be overlaid on top of any of
these products and architectures. How does this IPP model
fit on top of these systems? In order to answer that
question we must first consider a generic model that
allows us to describe the many different features and
components of these various systems.
Consider the figure above. Each distributed print
service product will include elements from the following
list:
End Users: End Users are humans who submit print jobs.
End users will issue IPP operation requests and receive
IPP operation responses through an end user interface.
GUI: A Graphical End User Interface developed
specifically for interacting with an IPP Client.
Browser: A World-Wide-Web Browser. IPP conforming systems
will support access to print functions using standard
Web Browsers.
Applications: Application software which produces printer
output and submits it for printing. Some applications
generate printer page description languages directly,
while others depend on operating system components, such
as a Print Driver, to do so.
draft-ietf-ipp-model-00.txt, expires September 26, 1997
Spooler: A system component which stores print jobs prior
to submitting them for printing. On the client side, a
spooler allows the application to run asynchronously from
the actual transmission and print operation. On the
server side, a spooler allows the server to receive and
store multiple jobs while printing. Spoolers are optional
components.
Print Driver: In some desktop operating systems, such as
Windows, Print Drivers are used by the operating system
to generate the actual PDL for a given device from an
internal, device independent presentation format. This
keeps the applications themselves from having to worry
about generating device specific data streams for each
possible output device. Print Drivers do not exist in all
environments.
IPP clients: IPP clients are computer network nodes with
which humans, though a GUI or a command line, or programs
interact in order to manipulate the distributed print
service. An IPP client uses the IPP protocol to invoke
IPP operations on another node. Each operation has
arguments and results associated with it. The IPP client
provides arguments which add information about the
operation requested, and receives results which describe
the status and outcome of the operation.
Gateway: Gateways provide a mechanism for supporting the
clients of existing print services, such as LPR. A
gateway transforms the protocol of an existing client
into IPP and vice-versa.
Transport: The transport system and protocol used to
carry IPP messages across the network. IPP assumes a
reliable transport protocol.
Notification Services: Notification services in the
network provide a means for asynchronously communicating
events such as completion of a print job back to an end-
user. These notification services are used by IPP but are
not included natively in the IPP protocol. Example would
be include e-mail, HTTP POSTs, or any other similar
service.
Directory Services: Directory services in the network
provide a means where IPP Printers can be advertised by
registering with the directory. Although not mandatory
in an IPP conforming system, the use of a directory
draft-ietf-ipp-model-00.txt, expires September 26, 1997
service is suggested in order to provide printer location
services to end users. A generic directory schema for IPP
Printers is described in "Internet Printing Protocol/1.0:
Directory Schema".
Security: The IPP protocol itself does not contain any
unique security mechanisms, but rather it depends upon
existing security systems, such as Secure Sockets Layer
(SSL) to provide authentication, privacy and message
integrity.
IPP Server: An IPP Printer object is an abstraction of
some print service provider. An Printer, by definition,
supports the IPP protocol. The component that implements
the protocol on behalf of the Printer is called an IPP
Server. In real configurations, an IPP Server may be a
component of a print server or an output device.
Print Service: Print Services may be embedded in an
output device or implemented in a separate system which
is associated with an output device. The print service
receives requests from the IPP client, performs the
requested operation, and sends back results which
describe the status and outcome of the operation
requested. A print service normally provides queuing,
job management, and device management functions.
Output Devices: Output devices interpret the print data June 3, 1997, Expires December 3, 1997
and generate some form of output. In the case of a laser Printer, allowing end users to search for and find Printers that match
printer, for example, this normally means rasterizing the their search criteria (name, context, printer capabilities, etc.)
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 IPP clients implement the IPP protocol on the client side and give end
include all of the elements described here, and the users or programs the ability to query an IPP Printer and submit and
physical packaging of elements is up to the manage their print jobs. An IPP server is just that part of the IPP
implementation. For example, an output device may include Printer that implements the protocol. The rest of the IPP Printer
a queue or a print server may include a rasterizer. implements the application semantics of the print service itself. All
information about the Printer, both static and dynamic information, can
be accessed directly from the Printer itself. The more dynamic
information associated with a Printer includes state, currently loaded
and ready media, number of jobs on the Printer, errors, warnings, etc..
When a job is submitted to the Printer, a Job object is created. The
end user then interacts with this new Job to query its status and
monitor the progress of the job. End users may also cancel the Job.
The end user is able to register to receive certain events which are
then routed using the notification service(s).
3. IPP Objects 4. IPP Objects
3.1 Printer 4.1 Printer Object
A major component of the IPP model is the Printer object. A major component of the IPP model is the Printer object.
To the end user, the Printer object is an abstraction of
draft-ietf-ipp-model-00.txt, expires September 26, 1997 The capabilities and state of an IPP Printer are described by its
not only the functionality typically associated with an attributes. Printer attributes are defined in the following categories:
actual output device, but also the abstraction
additionally supports (where necessary) the spooling,
scheduling, and multiple output device management
functions often associated with a print server.
The capabilities and state of an IPP Printer are
described by its attributes. Printer attributes are
defined in the following categories:
Job Template Attributes (section 5.2) Job Template Attributes (section 6.5.1 Printer Job Template
Printer Description Attributes (section 5.5) Attributes)
Printer Status Attributes (section 5.6) Printer Description Attributes (section 6.5.2 Printer Description
Printer Behavior attributes (section 5.7) Attributes)
Operations which can be invoked on a printer include: Operations which are invoked on a printer include:
Print (section 4.2.1) Create-Job (section 0)
Get Attributes (section 4.2.3) Print-Job (section ???)
Get Jobs (section 4.2.4) Get-Attributes (section 0)
Get-Jobs (section 0)
An instance of a Printer object implements IPP. Using An instance of a Printer object implements IPP. Using the protocol, end
the protocol, end users may query the attributes of the users may query the attributes of the Printer, submit jobs to the
Printer, submit jobs to the Printer, determine subsequent Printer, determine subsequent states of submitted and queued jobs, and
states of submitted and queued jobs, and cancel their own cancel their own print jobs. The realization of a Printer object may
print jobs. The realization of a Printer object may take take on different forms for any given configuration of real components.
on different forms for any given configuration of real However, the details of the configuration of real components must be
components. However, the details of the configuration of transparent to the end user.
real components must be transparent to the end user.
Since a Printer object is an abstraction of a generic June 3, 1997, Expires December 3, 1997
document output device, an IPP Printer object could be Since a Printer object is an abstraction of a generic document output
used to represent any real or virtual device with device or print service provider, an IPP Printer object could be used to
semantics consistent with the Printer object. For represent any real or virtual device with semantics consistent with the
example, an instance of a Printer object could be used Printer object. For example, an instance of a Printer object could be
to front end a fax-out device, any kind of imager, or used to front end a fax-out device, any kind of imager, or even a CD
even a CD writer. writer.
Some examples of configurations supporting a Printer Some examples of configurations supporting a Printer object include:
object include:
1) An output device, with no spooling capabilities 1) An output device, with no spooling capabilities
2) An output device, with a built-in spooler 2) An output device, with a built-in spooler
3) A print server supporting IPP with one or more 3) A print server supporting IPP with one or more associated output
associated devices
output devices 3a) The associated output devices might or might not be capable of
3a) The associated output devices may or may not be spooling jobs
capable 3b) The associated output devices might or might not support IPP
draft-ietf-ipp-model-00.txt, expires September 26, 1997
of spooling jobs
3b) The associated output devices may or may not
support IPP
See the following figures for some examples on how to See the following figures for some examples on how to view Printer
view Printer objects on top of other printing system objects on top of several print system configurations. The embedded
configurations. The embedded case represents case below represents configurations 1 and 2. The hosted and fan-out
configurations 1 and 2. Configuration number 3 is figures below represent configuration 3.
represented by the hosted and fan-out figures below.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 June 3, 1997, Expires December 3, 1997
Legend: Legend:
##### indicates a Printer object which is ##### indicates a Printer object which is
either embedded in an output device or is either embedded in an output device or is
hosted in a server. A Printer object hosted in a server. The implementation
may or may not queue/spool. might or might not be capable of queuing/spooling.
any indicates any network protocol or direct any indicates any network protocol or direct
connect, including IPP connect, including IPP
embedded printer: embedded printer:
output device output device
+---------------+ +---------------+
O +--------+ | ########### | O +--------+ | ########### |
/|\ | client |------------IPP------------># Printer # | /|\ | client |------------IPP------------># Printer # |
/ \ +--------+ | ########### | / \ +--------+ | # Object # |
| ########### |
+---------------+ +---------------+
hosted printer: hosted printer:
+---------------+ +---------------+
O +--------+ ########### | | O +--------+ ########### | |
/|\ | client |--IPP--># Printer #-any->| output device | /|\ | client |--IPP--># Printer #-any->| output device |
/ \ +--------+ ########### | | / \ +--------+ # Object # | |
+---------------+ ########### +---------------+
+---------------+ +---------------+
fan out: | | fan out: | |
+-->| output device | +-->| output device |
any/ | | any/ | |
O +--------+ ########### / +---------------+ O +--------+ ########### / +---------------+
/|\ | client |-IPP-># Printer #-* /|\ | client |-IPP-># Printer #--*
/ \ +--------+ ########### \ +---------------+ / \ +--------+ # Object # \ +---------------+
any\ | | ########### any\ | |
+-->| output device | +-->| output device |
| | | |
+---------------+ +---------------+
3.2 Job 4.2 Job Object
A Job object is used to model a job. A job can contain A Job object is used to model a job. A job can contain one or more
one or more documents. The information required to documents. The information required to create a Job object is sent in a
create a Job object is sent in a Print operation from the create request from the end user via an IPP client to a Printer. A
end user via a client implementation to a Printer. The
draft-ietf-ipp-model-00.txt, expires September 26, 1997 June 3, 1997, Expires December 3, 1997
Printer may perform some validation checks to verify that create request can be either a Create-Job Request or a Print-Job
the job may indeed be processed. For example, the Print Request. The Printer may perform some validation checks to verify that
operation may request that the documents within the job the job may indeed be processed. For example, the create request may
be printed duplex (on both sides of the media). However, specify that the documents within the job are to be printed duplex (on
the Printer may not support such a feature. Once the both sides of the media). However, the Printer might not support such a
Printer validates the submitted information, a Job object feature. Once the Printer validates the submitted information, a Job
is created. The instance of the Job object is object is created. The instance of the Job object is initialized with
initialized with information from the Print request along information from the create request. If a Create-Job operation is used
with default information from the Printer. This document to create the Job object, subsequent Send-Document operations are used
defines rules which define which pieces of information to transfer the document data from the client to the IPP Printer.
override other pieces of information and what to do in
the event of conflicts between what is possible and what This model specification defines rules for what MUST be done when:
is requested.
- optional attributes are missing
- there are conflicts between what is supported and what is
requested
- there are conflicts between what the client requests via external
attributes in the IPP operation and what the client requests in
embedded instructions in the document page description language
(PDL).
Job attributes are broken up into the following groups: Job attributes are broken up into the following groups:
Job Template Attributes optionally supplied by the Job Template Attributes (optionally supplied by the client/end user,
client/end user section 6.3.1 Job Template Attributes
Job Sheet Attributes (section 5.2.1) Job Description Attributes (set by the Printer, section 6.3.2 Job
Job Notification Attributes (section 5.2.2) Description Attributes)
Job Scheduling Attributes (section 5.2.3)
Job Production Attributes (section 5.2.4)
Document Production Attributes (section 5.2.5)
Document Format Attributes (section 5.2.6)
Job Template Attributes set by Client and Printer
Job Size Attributes (section 5.2.7)
Job Template Attributes set by the Printer
Number of Documents Attribute (section 5.2.8)
Job Attributes set by the Printer
Job Identification Attributes (section 5.3.1)
Job Owner Attributes (section 5.3.2)
Job Status Attributes (section 5.3.3)
The following operations can be invoked on Jobs: The following operations can be invoked on Jobs:
Send-Document(section 5.1.3 Send-Document Operation)
Cancel Job (section 0)
Get-Attributes (section 0)
Cancel Job (section 4.2.2) 4.3 Document Object
Get Attributes (section 4.2.3)
3.3 Document Object
Documents consist of printable data and attributes which Documents consist of printable data and attributes that describe the
describe the data to be printed. In this version of the data to be printed. In this version of the protocol only the attributes
protocol only the document format attribute may be in section 6.4 Document Attributes are defined for individual
defined for individual documents. documents. Documents are sent in a Send-Document operation or in a
Print-Job operation.
Document attributes include: Document attributes include:
Document Attributes (section 5.4) Document Attributes (section 0)
draft-ietf-ipp-model-00.txt, expires September 26, 1997
Currently no operations are defined on documents. Currently no operations are defined on documents.
3.4 Object Relationships June 3, 1997, Expires December 3, 1997
4.4 Object Relationships
Instances of objects within the system have relationships
which must be maintained persistently along with the
persistent storage of the object attributes. A Printer
can represent one or more output devices. An output
device can be represented by one or more Printer objects.
A Printer can contain zero or more Job objects. A Job
object is contained in exactly one Printer object. A Job
object contains one or more Documents. If the Document
is simply a reference to some print data stream, the
reference may be used in multiple documents in the same
Job or even in different Jobs. If the Document is not
just a reference, but an actual stream of print data, it
shall only be contained in one Document.
3.5 Object Attributes
Each object type is defined by a set of attributes that Instances of objects within the system have relationships that must be
support and describe the realization of each instance of maintained persistently along with the persistent storage of the object
an object. That is, a Printer object is defined as attributes. A Printer can represent one or more output devices. An
specific set of attributes that are associated with each output device can be represented by at most one Printer object. A
instance of a Printer object. In the same manner, a Job Printer can contain zero or more Job objects. A Job object is contained
object is defined by defining the set of attributes that in exactly one Printer object. A Job object contains one or more
will be associated with each instance of a Job object. Documents. If the Document is simply a reference to some print data
These attributes are defined in section 5 of this stream, the reference may be used in multiple documents in the same Job
document. Some attributes apply to only a Job object. or even in different Jobs. If the Document is not just a reference, but
Some apply to only a Printer object. an actual stream of print data, it shall only be contained in one
Document, although there can be copies of it in other Documents.
In addition, there are some attributes that are shared 4.5 Object Attributes
between both Printer objects and Job objects. These
attributes are defined in section 5.2. They are called
Job Template attributes. When one of these attributes is
part of a Job object, it specifies some end user job
processing instruction. It describes "what is wanted" by
the end user. When the attribute is part of a Printer
object, it specifies what the printer is capable of . It
describes "what is supported" by this instance of a
Printer. Also, as a Printer attribute, , the attribute
may have an optional default value which shall be used
for Jobs which do not supply an attribute value . This
default value describes "what will happen" if not
supplied in the by the end user in the Print Request.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 Each object type is defined by a set of attributes which describe the
For example, one such Job Template attribute is the "job- realization of each instance of an object. That is, a Printer object is
priority" attribute. When this attribute is part of a defined as set of attributes that are associated with each instance of a
Printer object, its value us a range of job priority Printer object. In the same manner, a Job object is defined by defining
values. This range indicates what job priorities are the set of attributes that are associated with each instance of a Job
supported at this Printer. It may also have a default object. Some attributes are OPTIONAL, some are MANDATORY, and some are
value that determines what the job priority will be if CONDITIONALLY MANDATORY (see section 2). Object attributes are defined
not supplied in the Print Request. When the "job- in section 0 of this document.
priority" attribute is included with the Print Request,
it specifies the desired job priority for this job. If
the request does not include the job-priority attribute,
the Printer creates the Job object using the default
value from Printer attribute. If the Print Request does
supply a job priority value, the Printer must validate
the user supplied job priority; perhaps the end user is
requesting a job priority which is higher that what is
allowed by the Printer. If the value in the print request
is within the range of supported values, the request is
accepted and the Job object is created using the value
supplied by the end user. In this case, the Printer's
default value is not used. If the value supplied in the
request is outside the range of supported values, the
request is rejected.
Section 5.1 also introduces the notion of adornments on 4.5.1 Job Template Attribute Overview
attribute values in order to handle some nuances
associated with values of certain Job and Printer
attributes. These adornments are tags that are
associated with specific values in the attribute. For
example, in a Printer object, one of the attributes is
the medium attribute. A set of values in this attribute
implies that the Printer is capable of printing jobs on
those media types. However, there may be a distinction
between a supported value that is "ready" and another
that is "not-ready". This semantic information can be
passed between the Printer and interested clients by
using an "availability" tag which identifies each value
as either being ready or not ready (even though they are
all supported).
Two important attributes that need to be mentioned here Attributes that a client may optionally include in a create request are
are the "multiple-documents-are" attribute and the "best- called Job Template attributes. These are described in detail in
effort" attribute. section 0. The Printer object has associated attributes which define
supported and default values for the Printer.
The "multiple-documents-are attribute" is relevant only - When a Job Template attribute is supplied by a client in a create
if a job consists of two or more documents. It controls request, the attribute and its value describe the desired job
finishing operations, job-sheet placement, and the order processing behavior.
of documents when the copies attribute is specified. The
end user uses this attribute in a Print Request to
draft-ietf-ipp-model-00.txt, expires September 26, 1997 - The Printer object's supported attribute describes what behaviors
control whether multiple documents in the job are are possible.
intended to be finished or copied separately or as one
job. The values for this attribute are: "single-
document", "separate-documents-uncollated-copies", or
"separate-documents-collated-copies".
The "best-effort" attribute determines what to do if - The Printer object's default value attribute describes what will be
there is a conflict between what a client requests and done when no other job processing information is supplied by the
what a Printer is capable of . Values for this attribute client.
are: "substitute-as-needed" and "do-not-substitute". If
the value for this attribute in a Print Request is
"substitute-as-needed" then the end user desires the job
be printed using substitutions by the Printer where
needed in order to resolve conflicts. If the value is
"do-not-substitute", then the end user desires that the
job should not be processed unless every attribute value
can be completely satisfied as specified. It is not
expected that this attribute is used much. Many clients
will submit a job with no attributes, and the Printer
will use default values. Other clients will submit a job
via a GUI which limits the attribute values to only those
which are supported. A value of "substitute-as-needed:
is useful in the GUI context only if an end user expects
the job to be moved to another Printer and prefers a sub-
optimal result to nothing at all. Also, an end user may
be printing a pre-formatted document where it is not
obvious that the client supplied attributes conflict with
what is in the print data itself or even if the printer
can satisfy the instructions already embedded in the pre-
formatted document. This "best-effort" attribute is most
useful in the case where an end user uses a command line
interface to blindly request attributes that may not be
supported.
3.6 Object Identity June 3, 1997, Expires December 3, 1997
4.5.2 The "best-effort" Job Attribute Overview
All instances of Printer and Job objects have an A client supplies Job Template attributes to affect the rendering,
identifier attribute whose value is globally unique so production and finishing of the documents in the job. Similar types of
that they can persistently and unambiguously referenced. instructions may also be contained in the document to be printed, that
The IPP model requires that these values be URLs as is, within the Page Description Language (PDL) of the document data. If
defined by RFC 1738 and RFC 1808. In addition to an there is a conflict between the value of one of these IPP Job Template
identifier attribute, instances of Printer and Job attributes, and a corresponding instruction in the document (either
objects may have a name. An object name need not be implicit or explicit), it is desirable that the value of the attribute
unique across all instances of all objects. The Printer shall take precedence over the document instruction. Until companies
name is chosen and set by an administrator. The Job name that supply interpreters for PDLs, such as PostScript and PCL allow a
is created by the Printer using the name of the forst way to external attributes (such as IPP attributes) to take precedence
document in the job. In all cases, the name only has over internal job production instructions, a Printer might not be able
to implement the semantics that IPP attributes override (take on a
higher precedence) the embedded PDL instructions. Therefore, IPP
introduces a special Job Template attribute named "best-effort". This
attribute gives the end user some ability to influence, or at least
understand, how a particular Printer implementation handles these
conflicts.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 This attribute takes on the following values:
local meaning, and is not constrained to be globally
unique.
To summarize, each instance of Printer and Job objects - 'shall-honor-ipp-attributes': If a Printer supports this value and
will have two identifying attributes: a client requests this value, the Printer guarantees that all IPP
attribute values take precedence over embedded instructions in the
job data (the PDL of the job's documents).
- 'should-honor-ipp-attributes': If a Printer supports this value,
and a client requests this value, the Printer should try to make
sure that IPP attribute values take precedence over embedded PDL
instructions, however there is no guarantee
- xxx-URL: The globally unique locator for this object ISSUE: Should these be 'shall-honor-attribute-precedence' and 'should-
instance honor-attribute-prcedence'?
- xxx-name: The non-globally unique name for this object A Printer SHALL implement the "best-effort-supported" attribute. Notice
instance that since 'should-honor-ipp-attributes' does not offer any type of
guarantee, a Printer may not do a very "good" job of implementing the
semantics of "should", but it would still be a conforming
implementation.
Document objects only have names, no identifiers. The If there is ever a conflict between what a Printer supports and what an
"document-name" attribute is used to store the name of IPP client requests, the Printer shall reject the print request. A
the Document. This name is just of interest within the client should query the printer to find out what is supported before
context of a Job. It need not be globally unique. making a request. This ensures that all requested attribute values are
supported.
ISSUE: Do Documents need identifiers? ISSUE: Should this be called "effort-level" rather than "best-effort"?
4. IPP Operations June 3, 1997, Expires December 3, 1997
4.6 Object Identity
4.1 Introduction All instances of Printer and Job objects have an identifier attribute
whose value is globally unique so that they can persistently and
unambiguously referenced. The IPP model requires that these values be
URIs as defined by RFC 1738 and RFC 1808. In addition to an identifier
attribute, instances of Printer and Job objects may have a name. An
object name need not be unique across all instances of all objects.
The Printer name is chosen and set by an administrator. The Job name is
created by the Printer using the name of the first document in the job.
In all cases, the name only has local meaning, and is not constrained to
be globally unique.
Printers and Jobs each have a set of operations To summarize, each instance of Printer and Job objects will have two
associated with it. End users, or programs invoke, these identifying attributes:
operations through interactions with an IPP client. The
operations are:
For a Printer object: - "xxx-URI": The globally unique identifier for this object instance
Print (section 4.2.1) - "xxx-name": The non-globally unique name for this object instance
Get Attributes (section 4.2.3)
Get Jobs (section 4.2.4)
For a Job object: Document objects only have names, no identifiers. The "document-name"
Cancel Job (section 4.2.2) attribute is used to store the name of the Document. This name is just
Get Attributes (section 4.2.3). of interest within the context of a Job. It need not be globally
unique.
IPP objects are identified by URLs. When a client If Documents are printed by reference, they are identified by URIs.
communicates with a remote IPP object, it sends an
operation request to the URL for that object. Each
request carries along with it the parameters and data
required to perform the specified operation. Each
request requires a response from the object indicating
success or failure of the operation including response
data and/or error messages. Details of the IPP protocol
draft-ietf-ipp-model-00.txt, expires September 26, 1997 5. IPP Operations
are contained in "Internet Printing Protocol: Protocol
Specification."
It is assumed that URLs for IPP Printers are available to Jobs and Printers each have a set of associated operations. End users or
end users or programs who wish to invoke Printer programs invoke these operations using an IPP client. The operations
operations. Although not mandatory, it is recommended are:
that Printers be registered in a directory service which
end users and programs can interrogate. "Internet
Printing Protocol: Directory Schema" defines the
attributes to be associated with an Printer entry in a
directory service.
ISSUE: We need to add "implementation notes." These are For a Printer object:
helpful hints of how to map these abstract concepts to Create-Job (section 0)
real development efforts. Does it go here? Print-Job (section ???)
Get-Attributes (section 0)
Get-Jobs (section 0).
4.2 Operation Semantics For a Job object:
Send-Document (section ??)
Cancel-Job (section 0)
Get-Attributes (section 0)
In this section, the four IPP operations are described in IPP Job and Printer objects are identified by URIs. When a client
terms of their contents and semantics. communicates with a remote IPP object, it sends an operation request to
the URI for that object. Each request carries along with it the input
parameters and data required to perform the specified operation. Each
request requires a response from the object indicating success or
4.2.1 Print Operation June 3, 1997, Expires December 3, 1997
failure of the operation including response data and/or error messages.
The representation and encoding of the IPP protocol are contained in
"Internet Printing Protocol: Protocol Specification."[23]
When an end user desires to submit a print job, the It is assumed that URIs for IPP Printers are available to end users or
client sends a Print Request and receives a Print programs that wish to invoke Printer operations. Although NOT
Response. The information in a Print Request along with MANDATORY, it is RECOMMENDED that Printers be registered in a directory
any default information associated with the Printer is service which end users and programs can interrogate. "Internet Printing
sufficient to create a Job object. An instance of a Job Protocol: Directory Schema"[24] defines the attributes to be associated
object contains all the information needed by the Printer with a Printer entry in a directory service.
to print one or more documents as a print job.
When a Printer receives a Print Request, it either 5.1 Operation Semantics
accepts or rejects the request. The Printer accepts the
Print Request and creates a Job object if it is able to
accept each attribute in the request, and it rejects the
request and does not create a Job object if it rejects
any attribute in the request. There are five cases to
consider with respect to each attribute.
- The client supplies an attribute value and it is among In this section, the IPP operations are described in terms of their
the values supported by the Printer: The job attribute is contents and semantics including both the request and the response.
accepted.
- The client supplies an attribute value but the In order to create a new Job object, a client MAY use one of two
attribute is syntactically bad: The Printer rejects the operations: either the Create-Job operation or the Print-Job operation.
job. If the client wants to create a Job with only a single Document, the
client MAY use the Print-Job operation or a Create-Job operation
followed by a single Send-Document operation. For performance reasons,
the client SHOULD use the Print-Job operation for all single Document
Jobs. If the client wants to create a Job with more than one Document,
the client SHALL use the Create-Job operation followed by as many Send-
Document operations as needed (on Document per Send-Document operation).
The Print-Job operation is a convenience operation for creating a Job
with only one Document. Throughout this model specification, the term
create request is used to refer to either a Create-Job Request or a
Print-Job Request.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 5.1.1 Print-Job Operation
- The client supplies an attribute value and a) the
attribute value is not among the values supported by the
Printer, or b) the printer does not specify the
attribute: The job attribute is accepted only if the
best-effort attribute is set to substitute-as-needed
which allows the Printer to perform a best effort at
processing the job rather than rejecting the job. If
the job attribute is accepted, the Printer sets the value
of the attribute to a reasonable value, which may be the
Printer's default value if it is specified.
- The client does not supply a value, but the Printer When an end user desires to submit a print job with only one document,
does: The attribute is accepted and when the Printer the client sends a Print-Job Request to a Printer and receives a Print-
creates a Job object, the Printer uses its default value. Job Response from that Printer. The information in a Print-Job Request
If Printer is able to inspect the PDL and determine the (along with any default information associated with the Printer) is
value of the embedded attribute, it sets the value of the sufficient for the Printer to create a Job object and then process that
attribute to the embedded value and adorns it with the Job.
embedded tag.
- Neither the client supplies an attribute value nor does 5.1.1.1 Print-Job Request
the Printer define a default value: The print request is
accepted, the Printer creates the Job object using
defaults as defined in this specification.
Issue: Can a Job object be created without some of the The following elements are part of the Print-Job Request:
attributes, then as the Printer processes the Job, there
is some default behavior as described either in this
document or a supplied on an implementation defined
basis. That is, if neither the client nor the Printer's
default supplies a value for a job attribute, then the
output device shall supply its own default value for that
job attribute, if necessary, in order to produce output.
4.2.1.1 Print Request Job Template Attributes:
An optional set of Job Template attributes as defined in section
6.2 Job Template Attributes. If the client supplies no Job
Template attributes in the Create-Job Request, the Printer uses its
default value attributes when processing the job.
ISSUE: The client initially submits the request to a June 3, 1997, Expires December 3, 1997
Printer URL. If a client submits a job in fragments, the Document Content
initial submission returns a Job URL to which the client The client either supplies the raw document data or a URI reference
submits subsequent fragments. to the data but not both.
The following abstract data types are part of the Print The simplest Print-Job Request consists of just the Document Content and
Request: nothing else. This means that the Printer SHALL create a new Job object
with no Job Template attributes and a single contained Document.
Job and A set of Job object and Document When a Printer receives a Print-Job Request, the Printer SHALL either
Document attributes as defined in section 5.2. accept or reject the request. The Printer SHALL accept the Print-Job
Attributes This section may be empty. If so, Request and SHALL create a Job object if it is able to accept all
Printer defaults are used. attributes in the request. The Printer SHALL reject the request and
SHALL NOT create a Job object if the Printer rejects any attribute in
the request. There are six cases to consider with respect to each Job
and Document attributes:
draft-ietf-ipp-model-00.txt, expires September 26, 1997 1. The client supplies a Job Template attribute named "xxx" and the
Document Document content is optional and shall value supplied by the client is among the values supported by the
Contents not be included when a URL is provided Printer (i.e., is among the values of the Printer's "xxx-supported"
in the document-URL attribute which attribute): The "xxx" Job Template attribute is accepted. If the
points to the content. "best-effort-supported" attribute contains the value 'shall-honor-
ipp-attributes' the Printer SHALL guarantee the behavior
represented by the value in the "xxx" attribute (i.e., the IPP
attribute has precedence over any other embedded job instruction).
If the value of the "best-effort-supported" is 'should-honor-ipp-
attributes' then the Printer SHOULD try to realize the behavior
requested by the client, but NEED NOT guarantee the behavior. The
Printer creates the Job object and implements the "xxx" attribute
in the new Job object and uses the value supplied by the client.
The simplest Print Request consists of a document contents 2. The client supplies an attribute value but the attribute is
and nothing else. syntactically bad: The Printer shall reject the job and return the
??? error code.
4.2.1.2 Print Response 3. The client supplies an attribute value and the attribute value is
not among the values supported by the Printer: The Printer SHALL
reject the job and return the 'attribute-unsupported' error code.
The following abstract data types are part of the Print 4. The client supplies an attribute value and the Printer does not
Response: implement the attribute: The attribute is ignored. The Printer
behaves as if the attribute was never supplied by the client in the
Print-Job Request. In the response, the Printer SHALL return the
names of all ignored attributes. The final result of the Job is
undefined for an ignored attribute (that is the desired behavior
might or might not be realized).
Job- A URL Used for all other operations on ISSUE: Should the printer just reject the job?
Identifier this Job.
Job Status All job attributes belonging to the job-
status group. The value of each
attribute shall be from a snapshot taken
sometime after the time the Printer
receives the print request. Since any
job affecting printer state information
(printer-state-reasons) is reflected in
the job-state and job-state-reasons, it
is sufficient to return only job status
attributes and no printer status
attributes.
Status status information including error June 3, 1997, Expires December 3, 1997
status 5. The client does not supply an attribute, but the Printer
Message optional status message implements the attribute: The attribute is accepted and when the
Printer creates the Job object, the Printer SHALL NOT implement the
attribute in the Job object. When the Printer processes that Job,
the Printer SHOULD attempt to use the behavior implied by the
default value Printer attribute as set at the time of Job
processing (not Job creation). In other words, these rules allow
for a Job object to be created without implementing some of the Job
Template attributes. As the Printer processes the Job, if the
Printer implements a default value attribute for the missing Job
Template attribute, the Printer does its best to realize the
behavior of the default value. If the Printer does not implement
the default value attribute, the results are undefined.
The simplest response consists of the job identifier, Job Note: For each Job Template attribute, this specification REQUIRES
status, and operation status which is either an OK status or that a Printer to implement the CONDITIONALLY MANDATORY attributes.
Error status.
4.2.2 Cancel Job Operation 6. The client does not supply an attribute, and the Printer does not
implement the attribute: The Printer accepts the Job and creates a
Job object. When the Job is processed, the actual behavior
realized with respect to the missing Job Template attribute is
undefined.
This operation allows a user to cancel one specific Print 5.1.1.2 Print-Job Response
Job any time after the print job has been established on
the Printer. Some pages may be printed before a job is
terminated if printing has already started when the
Cancel Job operation is received. Only the end user who
is also the job originator (job-originating-user Job
attribute) can cancel the job.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 The Printer shall return to the client the following output parameters
4.2.2.1 Cancel-Job Request as part of the Print-Job Response:
The client submits the request to a Job URL. Job Identifier:
A URI which the client shall use for all other operations on this
Job
The following abstract data types are part of the Cancel Job Status:
Job Request: The following Job attributes: job-name, job-state, and job-state-
reasons. The value of each attribute shall be from a snapshot
taken sometime after the time the Printer receives the print
request. The "job-state-message" attribute is OPTIONAL.
Message Optional message to the operator. Note: Since any job affecting printer state information is
reflected in the "job-state" and "job-state-reasons" job
attributes, it is sufficient to return only job status attributes
and no printer status attributes at Job creation time.
4.2.2.2 Cancel-Job Response Ignored Attributes:
A list of attribute names which were ignored in the creation of the
Job object.
The following information is part of the Cancel Job June 3, 1997, Expires December 3, 1997
Response: Unsupported Attributes:
A list of attribute names which are unsupported. Any attributes in
this list imply that the Job object was not created.
Status status information including error Bad Attributes:
status A list of attribute names which were syntactically incorrect. Any
Message optional status message attributes in this list imply that the Job object was not created.
4.2.3 Get Attributes Operation Status
Status information including error status
This operation allows an end user to obtain information The simplest response shall consist of the job identifier, the Job
from a Printer or Job object. The operation contains the Status attributes, and an operation status that is either an "ok" status
set of attributes names and/or attribute group names that or an "error" status.
the requester is interested in. A corresponding
attribute list is returned in the response with the
appropriate attribute values filled in for each attribute
(explicitly named or implicitly included in an attribute
group) in the request.
If the request to a Printer does not supply any attribute 5.1.2 Create-Job Operation
names, the Printer shall assume that the client is
implicitly requesting the default groups of "printer-
identification" and "printer-status". If the request to a
Job object does not supply any attribute names, the
Printer shall assume that the client is implicitly
requesting the default groups of "job-identification",
"job-owner", and "job-status".
draft-ietf-ipp-model-00.txt, expires September 26, 1997 When an end user desires to submit a print job, the client sends a
4.2.3.1 Get-Attributes Request Create-Job Request to a Printer and receives a Create-Job Response from
that Printer. The information in a Create-Job Request along with any
default information associated with the Printer is sufficient for the
Printer to create a Job object. An instance of a Job object contains
all the information needed by the Printer to print one or more documents
as a print job. If the client follows the Create-Job operations with as
many Send-Document operations as needed.
The client submits the request to a Job URL or Printer 5.1.2.1 Create-Job Request
URL.
The following abstract data types are part of the Get The following elements are part of the Create-Job Request:
Attributes Request:
Requested A set of attributes without values in Number of Documents:
Attributes whose values the requester is An optional integer value specifying the number of Documents for
interested This is optional. this Job. The document data is transferred in a series of
subsequent Send-Document operations (one document per Send-Document
operation). If this value is not supplied by the client, the
Printer waits to receive an empty Send-Document operation signaling
the end of Documents for this Job. If the client wants to create a
Job with only a single document, the client MAY use the Print-Job
operation. This is a convenience operation for creating a Job with
only one Document. The Print-Job Operation is semantically the
same as a Create-Job operation followed by one Send-Document
operation.
format This is used only when a this request Job Template Attributes:
is sent to a Job and the end user is An optional set of Job Template attributes as defined in section
interested in production attributes. In 6.2 Job Template Attributes. If the client supplies no Job
that case, the client must the format
in the request since the default value
of the formats supported for the
Printer might be "auto-sense", and a
Printer's attributes or attribute
values may differ for each format that
it supports. This request value allows
a client to specify a particular
format.
There shall be a way to specify certain groups of June 3, 1997, Expires December 3, 1997
attributes, and it shall be possible to get more than one Template attributes in the Create-Job Request, the implemented
group. The groups shall be organized in the same way as Printer defaults are used.
this document and shall have the same names as the
sections heads of the groupings. Each section and
subsection contains the group name for the attributes in
that section or subsection.
For Printers and Job the special groups include: The simplest Create-Job Request has no data which means that the Printer
SHALL create a new Job object with no Job Template attributes and the
number of Documents is yet to be determined.
- "none": no attributes of the specified object. NOTE: When a Printer receives a Create-Job Request, the Printer SHALL
none is primarily useful in Get Jobs, but can be either accept or reject the request. The rules for accepting or
used as a ping with Get Attributes. rejecting a Create-Job Request are the same as the rules for
- "all": all attributes of the specified object. accepting or rejecting the Print-Job Request (see section 5.1.1.1
Print-Job Request).
4.2.3.2 Get-Attributes Response 5.1.2.2 Create Job Response
The following abstract data types are part of the Get The Printer shall return to the client the following output parameters
Attributes Response: as part of the Create-Job Response:
Result The requested attributes of the object Job Identifier:
Attributes with their current values, if the A URI which the client shall use for all other operations on this
requester supplied any Requested Job
draft-ietf-ipp-model-00.txt, expires September 26, 1997 Job Status:
Attributes The following Job attributes: job-name, job-state, and job-state-
reasons. The value of each attribute shall be from a snapshot
taken sometime after the time the Printer receives the print
request.
Status status information including error Note: Since any job affecting printer state information is
status reflected in the "job-state" and "job-state-reasons" job
Message optional status message attributes, it is sufficient to return only job status attributes
and no printer status attributes at Job creation time.
A Printer may choose, for security reasons, not to return Ignored Attributes:
all attributes that a client requests. It may even return A list of attribute names which were ignored in the creation of the
none of the requested attributes. In such cases, the Job object.
status returned is the same as if the Printer had
returned all requested attributes. The client cannot tell
by such a response whether the requested attribute was
present or absent on the Printer.
4.2.4 Get Jobs Operation Unsupported Attributes:
A list of attribute names which are unsupported. Any attributes in
this list imply that the Job object was not created.
This operation allows a client to retrieve Printer Bad Attributes:
attributes and a list of print jobs belonging to the A list of attribute names which were syntactically incorrect. Any
target Printer object. A list of Job attributes or attributes in this list imply that the Job object was not created.
attribute groups that the client is interested in seeing
may be included in the request. If the request does not
supply any Printer attributes, the Printer shall assume
that the client is implicitly requesting the default
groups: "printer-identification" and "printer-status". If
the request does not specify any job attributes, the
Printer shall assume the default groups: "job-
identification", "job-status", "job-owner" and "job-
size". The Printer object will be returned first,
followed by the requested jobs in chronological order.
This order is explicitly defined to be: oldest to newest
with regard to completion time, either actual or
expected.
This operation is like Get Attributes, except that Get Status
Jobs can return attributes from more than one object. Status information including error status
4.2.4.1 Get-Jobs Request June 3, 1997, Expires December 3, 1997
The simplest response shall consist of the job identifier, the Job
Status attributes, and an operation status that is either an "ok" status
or an "error" status.
The client submits the request to a Printer URL. 5.1.3 Send-Document Operation
The following abstract data types are part of the Get Once a Job object has been created using a Create-Job operation, a
Jobs Request: client uses the Send-Document operation to transport the documents to be
printed and add them to the named Job object. A document MUST be sent
in a single Send-Document operation.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 5.1.3.1 Send-Document Request
Job Owner This is the user-name. If the value is
non-null, then the requester wants only
those jobs whose job-originating-owner
is the same as the specified user-name.
If the value is null, then the requester
wants all jobs.
Job States A possibly empty set of job state The client submits the request to a Job URI.
values. If the set is not empty,
then the requester wants only those jobs
whose job-state is the same as one of
the specified job state values, If the
set is empty , then the requester wants
all jobs that are pending or printing.
Requested A set of attribute names (without The following abstract data types are part of the Send-Document Request:
Printer values) in whose values the requester is
Attributes interested from the specified Printer
Requested Job A set of attribute names (without Document Attributes:
Attributes values) in whose values the requester is An optional set of Document Description attributes (section 6.4
interested from each of the jobs on the Document Attributes).
specified Printer.
There shall be a way to specify certain groups of Document Content:
attributes, and it shall be possible to get more than one The client either supplies the raw document data or a URI reference
group. The groups are the same as for Get Attributes. to the data but not both.
4.2.4.2 Get-Jobs Response 5.1.3.2 Send-Document Response
The following information is part of the Get Jobs The following abstract data types are part of the Send-Document
Response: Response:
Result The result includes zero or more objects Job Status:
Attributes each with zero or more attributes. The following Job attributes: job-name, job-state, and job-state-
reasons. The value of each attribute shall be from a snapshot
Status status information including error taken sometime after the time the Printer receives the print
status request.
Message optional status message
A Printer may choose, for security reasons, not to return
all attributes that a client requests. It may even return
none of the requested attributes. In such cases, the
status returned is the same as if the Printer had
returned all requested attributes. The client cannot tell
draft-ietf-ipp-model-00.txt, expires September 26, 1997
by such a response whether the requested attribute was
present or absent on the Printer.
5. Object Attributes
This section describes the attributes with their
corresponding syntaxes and values that are part of the
IPP model. The sections below show the objects and their
associated attributes which are included within the scope
of this protocol. Many of these attributes are derived
from other relevant specifications:
ISO/IEC 10175 DPA (Final, June 1996)
RFC 1759 Printer MIB (Proposed Standard, May 1995)
Internet-Draft: Printer MIB (Draft Standard in
progress, December 1996)
Internet-Draft: Job Monitoring MIB (I-D in progress,
March 1997)
Each attribute is uniquely identified in this document
using a "keyword" in the section header describing that
attribute. A keyword is a sequence of characters (length
of 1 to 255) which consists of just letters, digits,
hyphen ("-"), and underscore ("_"). With these
restrictions, there will be a straight forward encoding
of these keywords onto real values in the protocol
specification. Not only are attributes uniquely
identified with keywords, some attributes take on a
syntax which is a set of keywords. This set of keywords
represents the domain of the attribute.
5.1 Attribute Syntaxes
The following table shows the basic syntax types that a
client and server shall be able to handle.
Table 1
Basic Type Description Comments
text a sequence of For free form human
characters: readable text
length: 0 to intended for human
4096 consumption.
draft-ietf-ipp-model-00.txt, expires September 26, 1997
Basic Type Description Comments
characters: any
name a sequence of
characters: some object via a
length: 1 to user-friendly
255 characters: string, such as a
For referencing
any Printer name, a
document name, a
user name, or a
host name. May
include the SPACE
character.
NOTE - The protocol
may need to provide
means to quote the
SPACE character if
the protocol uses
SPACE for other
purposes.
fileName a sequence of For referencing
characters: some file. The
length: 1 to limit is the same
1024 as POSIX and NT.
characters: any
keyword a sequence of For semantic
characters: identifiers of
length: 1 to entities in the
255 characters: abstract protocol
letters, (specified in this
digits, hyphen document). These
("-"), entities can be
underscore attribute names or
("_") values of
attributes, When a
keyword is used to
represent an
attribute (its
name), it must be
unique within the
full scope of IPP
objects and
attributes. When a
keyword is used to
draft-ietf-ipp-model-00.txt, expires September 26, 1997
Basic Type Description Comments
represent a value
of an attribute, it
must be unique just
within the scope of
that attribute.
That is, a keyword
can not be used for
two different
values of the same
attribute to mean
two different
semantic ideas.
However, the same
keyword can be used
across two or more
attributes,
representing
different semantic
ideas for each
attribute.
url a sequence of Universal Resource
characters: as Locator
defined in
rfc1738 and ISSUE: do we keep
rfc1808 URLs abstract here
too and not define
them in terms of
rfcs?
octetString a sequence of Used for opaque
octets data, such as the
document-content.
boolean two values of like an keywordSet,
true and false but there are only
two values. NOTE:
An application
might use a
checkbox for such a
value.
integer an integer each attribute
value that is specifies the range
in the range constraint
from -2**31 to
draft-ietf-ipp-model-00.txt, expires September 26, 1997
Basic Type Description Comments
2**31 - 1 explicitly.
dateTime a value that
holds the date time
and time to the
absolute date and
nearest second.
integerSeconds an integer with a relative time
implicit units
of seconds
integerPoints an integer with for measurment
implicit units
of computer
points, i.e.,
1/72 of an
inch.
integerUnits an integer with an integer value
explicit units expressed in units
ISSUE: we have two
types with implicit
units and one with
explicit units
where the units are
specific for one
attribute printer-
speed.
setOf X 0 or more for sets of values
values of type
X.
1setOf X 1 or more for sets of values
values of type
X.
setWithDefaultOf X 0 or more for sets of values
values of type where one is a
X and a default default value
value of type X
1setWithDefaultOf 1 or more for sets of values
draft-ietf-ipp-model-00.txt, expires September 26, 1997
Basic Type Description Comments
X values of type where one is a
X and a default default value
value of type X
withDefault X an explicit For values which
default value are not restricted
of type X. The but have a default.
set of values
is implicitly
unrestricted.
RangeWithDefaultOf a range of for a range of
X value of type X values, such as
with a default integers, where one
value of type X value is the
default.
OR the below syntax
type instead
integerRangeWithDef an integer for a range of
ault range with a integers where one
default integer value is the
value default.
5.1.1 Attribute Extensibility
This document uses prefixes to the keyword basic syntax
type in order to communicate extra information to the
reader through its name. This extra information need not
be represented in an implementation because it is
unimportant to a client or printer. The table below
describes the prefixes and their meaning
Basic Type Prefix Comments
keyword type1 someone must revise the IPP Note: Since any job affecting printer state information is
standard to add a new name. reflected in the "job-state" and "job-state-reasons" job
No private names are attributes, it is sufficient to return only job status attributes
allowed. and no printer status attributes at Job creation time.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 Ignored Attributes:
Basic Type Prefix Comments A list of attribute names which were ignored in the creation of the
Job object.
keyword type2 implementers can, at any June 3, 1997, Expires December 3, 1997
time, add new values by Unsupported Attributes:
proposing them to the PWG A list of attribute names which are unsupported. Any attributes in
for registration (or an this list imply that the Job object was not created.
IANA-appointed registry
advisor after the PWG is no
longer certified) where they
are reviewed for approval..
IANA keeps the registry.
Implementers can support
private (unregistered) with
a suitable distinguishing
prefix, such as -xxx- where
xxx is the company name
registered with IANA for use
in domain names.
keyword type3 implementers can add new Bad Attributes:
values by submitting a A list of attribute names which were syntactically incorrect. Any
registration request attributes in this list imply that the Job object was not created.
directly to IANA, no PWG or
IANA-appointed registry
advisor review is required.
Implementers can support
private (un-registered)
names with a suitable
distinguishing prefix, such
as -xxx- where xxx is the
company name registered with
IANA for use in domain
names.
keyword type4 an installation defined name Status:
that can be added to a local Status information including error status
system by an administrator.
Care must be taken by the
administrator to see that
keywords do not conflict
with other keywords defined
by the standard or as
defined by the implementing
product. There is no
registration or approval
procedure for type 4
keywords
draft-ietf-ipp-model-00.txt, expires September 26, 1997 5.1.4 Cancel Job Operation
5.1.2 Relationship of Job and Printer Attributes
If a client can supply a Job attribute in a Print This operation allows a user to cancel one specific Print Job any time
Request, there is a corresponding Printer attribute with after the print job has been established on the Printer. Some pages may
the same name. The Printer attribute as a similar syntax be printed before a job is terminated if printing has already started
type, however, the Printer attribute must additionally when the Cancel Job operation is received. Only the end user who is
specify a set of supported values and an optional default also the job originator ("job-originating-user" Job attribute) can
value. The default value is used when creating a new Job cancel the job using IPP 1.0.
object where the client has not supplied a value in the
Print Request. These attributes, which can be in both
Job and Printer objects, are called Job Template
attributes and are fully defined in section 5.2 "Job
Template Attributes". The table below shows the
relationships between the syntax types of Job attributes
and their corresponding Printer attributes. The syntax
type of the Printer object is "constructed" using Job
attribute type. For example, the table shows that if the
basic syntax type of a Job attribute is "text" then the
corresponding Printer attribute will be of type
"withDefault text". Or, if the syntax type of the Job
attribute is "integer", then the corresponding Printer
attribute will be of type "rangeWithDefault of integer".
The essence of what is shown in the table below is
whether a context (Job attribute or Printer attribute)
allows a single value or multiple values.
Name of Job Printer Attribute 5.1.4.1 Cancel-Job Request
syntax type Attribute Syntax
Syntax
text text withDefault text The client submits the request to a Job URI.
name name withDefault name The following abstract data types are part of the Cancel Job Request:
keyword keyword setWithDefaultOf Message:
keyword Optional message to the operator
or
or
setOf
keyword 1setWithDefaultOf
keyword
or
draft-ietf-ipp-model-00.txt, expires September 26, 1997 5.1.4.2 Cancel-Job Response
Name of Job Printer Attribute
syntax type Attribute Syntax
Syntax
1setOfkeywo The following information is part of the Cancel Job Response:
rd
boolean boolean setWithDefaultOf Status:
boolean Status information including error status
url url withDefault url 5.1.5 Get-Attributes Operation
integer integer rangeWithDefaultOf The Get-Attributes operation allows client to obtain information from a
integer Printer or Job object. The client supplies the set of attributes names
and/or attribute group names that the requester is interested in as
operation input parameters. The Printer shall return a corresponding
attribute list in the response with the appropriate attribute values
filled in for each attribute (explicitly named or implicitly included in
an attribute group) that the client supplied in the request.
integerUnits integerUnit rangeWithDefaultOf June 3, 1997, Expires December 3, 1997
s integer, setOf Units 5.1.5.1 Get-Attributes Request
dateTime dateTime not needed because The client shall submit the Get-Attributes request to a Job URI or
there are no job Printer URI.
production attributes
that a client can
supply.
integerSecon integerSeco rangeWithDefaultOf The following input parameters shall be part of the Get-Attributes
ds nds integerSeconds Request:
NOTE: if have Document Format:
integerUnits and no The client shall supply this input parameter only when requesting
integerSeconds, we can attributes of the Printer object. The Printer shall reject this
replace request, if this input parameter is supplied for a Job object.
rangeWithDefaultOf by
integerRangeWithDefaul
t.
setOf X setOf X setWithDefaultOf X This input parameter conditions the Printer attributes and values
that might depend on the document format. The Printer shall return
only (1) those attributes that are implemented and (2) the
attribute values that are supported for the specified document
format. By specifying the document format, the client can
eliminate the attributes that are not implemented and values that
are not supported for the document format that the client has or is
able to generate.
The Printer and the client shall be knowledgeable about If the client omits this input parameter, the effect shall be the
each of the above syntax forms and know how the handle same as if the value of the Printer's document format attribute
the values in a Job attribute and a Printer attribute. were supplied. It is recommended that the client always supply a
value for document-format, since the Printer's default value for
document-format may be 'auto-sense', in which case the returned
attributes and values are for the union of the document formats
that the Printer supports in its 'auto-sense' support."
draft-ietf-ipp-model-00.txt, expires September 26, 1997 Requested Attributes:
5.1.3 Attribute Value Tags An optional set of attribute names (without values) or attribute
group names in whose values the requester is interested. If the
client omits this input parameter, the effect shall be the same as
if the "all" attribute group were supplied.
In order to handle some nuances associated with Job and Attributes may be requested by name or by group name. For Jobs, the
Printer attribute values, attribute values can have tags attribute groups include:
associated with them. The following sections describe
these tags. All tags are optional. Fully conforming
implementations need not support them.
5.1.3.1 Tagged Printer Attributes - 'job-template': the attributes specified in Section 6.3.1 Job
Template Attributes.
- 'job-description': the attributes specified in Section 6.3.2 Job
Description Attributes.
Job Template attribute values in a Printer can have extra For Printers, the attribute groups include:
tags associated with them:
- Availability: Some supported attributes shall have an - 'printer-job-template': the attributes specified in Section 6.5.1
availability value associated with each value. A client Printer Job Template Attributes.
may choose to display values only with certain values of
availability. Standard values are: "ready" and "not-
ready". If an attribute value does not have this tag,
it is by default "ready". "not-ready" means that the
Printer can accept the job, but the Printer cannot
complete the job without some external intervention to
make the value ready.
ISSUE: Should the following availability tags be added June 3, 1997, Expires December 3, 1997
which help to more clearly specify some subtle meanings? - 'printer-description': the attributes specified in Section 6.5.2
These include "virtually-ready" (ready enough for the Printer Description Attributes.
Printer to schedule the job since it the value is
intended to always be ready, media in manual-feed trays
would have this value), "on-order" (not-ready and cannot
be made ready soon, but something is happening), or
"special-order" (not-ready and cannot be made ready soon,
nothing is happening).
- Embedded-only: Some supported production attributes There are also special groups:
have an "embedded-only" tag associated with an attribute
to indicate that the Printer supported this attribute
when it is embedded in the document data, but it does not
support it as an explicit attribute. The attributes that
this tag is attached to varies according to the format
specified in the Get Attributes operation.
- Default Value: Supported attributes can have a default - 'none': no attributes of the specified object. Note: none is
tag associated with the value that is default. If primarily useful in Get-Jobs, but can be used as a "ping" with the
multiple values are tagged with a default value, a client Get-Attributes operation.
shall use the first value that is tagged with default. If - 'all': all attributes of the specified object
no values are tagged, then it assumes the first value in
the supported list is the default value.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 5.1.5.2 Get-Attributes Response
- Scheduling: If a printer uses this value for
scheduling, then it associates this tag to indicate that
it would like the attribute set when the job is
submitted. The attribute can come back with or without
the embedded tag. If an attribute does not have this tag,
then the Printer will not use this attribute for
scheduling.
NOTE: the mostly likely attribute that a Printer would The Printer shall return the following output parameters as part of the
attach this adornment to is the media attribute. Get-Attributes Response:
5.1.3.2 Tagged Job Attributes Result Attributes:
The requested attributes of the object with their current values,
if the requester supplied any Requested Attributes. If the request
did not supply any attribute names, the Printer shall assume that
the client is implicitly requesting the default group of "all" and
shall return all attributes implemented for the specified Job or
Printer object.
Job attribute values set by a client and defined in Unimplemented Attributes:
section 5.2 "Job Template Attributes" can have the A list of attribute names which are unimplemented.
following extra tags associated with them:
- Embedded: If an attribute has this tag, then the Unknown:
attribute value(s) are embedded in the document. The A list of attribute names which are unknown.
printer can use this information for scheduling, but it
shall not use it to modify the document. This attribute
cannot be associated with individual attribute values.
- Default: If a attribute value has this tag, then the Status:
Printer shall ignore the Job attribute, if any, and shall Status information including error status
use the Printer's default value for the attribute.
Issue: Does the following imply too much about using A Printer may choose, for security reasons, not to return all attributes
"fan-in" for multiple default sets for a given output that a client requests. It may even return none of the requested
device? Note: it is the duty of an administrator to attributes. In such cases, the status returned is the same as if the
create a reasonable number of Printers feeding into each Printer had returned all requested attributes. The client cannot tell by
output device to handle user's expected defaults. For such a response whether the requested attribute was present or absent on
example, a Windows client will send a PostScript document the Printer.
with no attributes. For production attributes, a
Printer's defaults must be "as-is". But other clients
may want to force PostScript files to print two-sided.
For those clients, there must be another printer whose
sides default is "2-sided-long-edge".
5.2 Job Template (job-template) Attributes In response to a "Get-Attributes" (or a "Get-Jobs") operation the
following requirements apply to the Printer:
The following attributes can exist in both Jobs and 1. If the client supplies an attribute name in the Requested
Printers. When such an attribute is in a Job object, it Attribute input parameter and that attribute is implemented by the
identifies some desired behavior on this Job by the Printer, the printer shall respond with all current values for that
Printer. When it is in a Printer object, it constrains attribute. If the value of an implemented attribute is unknown for
the values that the corresponding Job attribute can have
draft-ietf-ipp-model-00.txt, expires September 26, 1997 June 3, 1997, Expires December 3, 1997
and it specifies a default value as well. The set of some reason, the Printer shall respond with the attribute name in
values in the Printer object are called the "supported the "unknown attribute list" response parameter.
values".
These attributes form the attribute group called "job- 2. If the client supplies an attribute name in the Requested
template". Attribute input parameter that attributed is not implemented by the
Printer, the Printer shall respond with the attribute name in the
"unimplemented attribute list" response parameter.
The attributes are described below. The part in 3. If the client supplies an attribute group that is implemented by
parenthesis after each attribute name is the name of the the Printer, the Printer shall respond with all current values for
syntax as listed in Table 1 in section 5.1. each implemented attribute in the group. It shall not respond for
unimplemented attributes in the group. If the value of an attribute
is unknown for some reason, the Printer shall respond with the
attribute name in the "unknown attribute list" response parameter.
A client can specify any of the attributes in this group 4. If the client supplies an attribute group keyword that is not
in a Print Request. If a client GUI wishes to present a implemented, the Printer has no means for determining if it is an
user with a list of values to choose from, then the unimplemented attribute or attribute group. In this case, the
client program should perform the Get Attributes Printer assumes that it is an unimplemented attribute and responds
operation to a Printer URL using the group job-template as if it is an unimplemented attribute (the Printer responds with
in order to get the complete list of attributes that a the attribute name in the "unknown attribute list" response
client can specify. Each attribute returned with the job- parameter).
template group shall contain a list of supported values
for the attribute and the Printer's default value.
5.2.1 Job Sheet Attributes (Set by Client/End User) 5.1.6 Get-Jobs Operation
The client shall specify these attributes to control the The Get-Jobs operation allows a client to retrieve Printer attributes
printing of job sheets. and a list of print jobs belonging to the target Printer object. A list
of Job attribute names or attribute group names that the client is
interested in seeing may be included in the request.
There is no group name for these attributes since there This operation is like Get-Attributes, except that Get-Jobs operation
is only one attribute in the group. returns attributes from more than one object.
The client may also specify job sheet attributes in: Get- 5.1.6.1 Get-Jobs Request
Attributes and Get-Jobs.
5.2.1.1 job-sheets (type4 keyword) The client shall submit the Get-Jobs request to a Printer URI.
5.2.1.1.1 As a Job Attribute The following input parameters are part of the Get-Jobs Request:
This job attribute determines what type of job-sheets Job Owner
(banner pages) the Printer shall print with the job. This is the user-name. If the value is non-null, then the
requester wants only those jobs whose job-originating-owner is the
same as the specified user-name. If the value is null, then the
requester wants all jobs.
The standard values are: "none", and "default-sheet". Limit
This is an integer value which indicates a limit to the number of
Jobs returned. The limit is a "stateless limit" in that if the
The value "none" means that end user desires no job sheet June 3, 1997, Expires December 3, 1997
be printed. The value "default-sheet" means that the end limit is n then only the first n jobs are returned in the Get-Jobs
user desires a site specific default sheet defined by and Response; there is no mechanism to allow for the "next" n jobs.
administrator be printed. The limit applies across all Job States requested. For example, if
the limit if 50, and there are 75 jobs in the 'completed' state and
25 in the 'pending state' and the client requests first 'completed
jobs' and then 'pending' jobs, only the first 50 'completed' jobs
are returned. The other 25 'completed' jobs are not returned and
neither are any of the 'pending' jobs returned.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 Job States
5.2.1.1.2 As a Printer Attribute A possibly empty set of job state values. If the set is not empty,
then the requester wants only those jobs whose job-state is the
same as one of the specified job state values. If this operation
parameter has more than one value, the Printer SHALL return the
jobs grouped by state with each group being in the same order as
supplied by the client in this parameter. Within each group, the
jobs are ordered from oldest to newest with respect to completion
time (either actual or expected). For example, if the client
requests all 'pending' and 'completed' jobs, first all jobs in the
'pending' state are returned (ordered from oldest to newest) and
then all jobs in the 'completed' state are returned (ordered from
oldest to newest). If the client request all 'completed' and
'processing' jobs, first all jobs in the 'completed' state are
returned (ordered from oldest to newest) and then all jobs in the
'processing' state are returned (oldest to newest). If the client
does not supply this operation parameter, the value SHALL be
assumed to be (by both the client and the Printer) first 'pending'
and then 'processing'.
This printer attribute identifies the default job-sheet. Requested Job Attributes:
It also identifies the job-sheet values supported by this A optional set of attribute names (without values) or attribute
printer, and the state of readiness for each job-sheet. groups names in whose values the requester is interested from each
of the jobs on the specified Printer. The attribute group names
are the same as for the Get-Attributes operation for the Job
object. If the client omits this input parameter, the effect shall
be the same as if the 'none' attribute group were supplied.
To allow no job sheets, the system administrator shall 5.1.6.2 Get-Jobs Response
include the value none as a value for the supported
values. If the administrator's policy is not to support
none, the Printer shall use the default-sheet value if
the client supplies the none value but also indicates
(through the best-effort attribute) that Printer could
substitute values as needed in order to process the job.
5.2.2 Job Notification (job-notification) Attributes (Set by The Printer shall return the following output parameters as part of the
a Client/End User) Get-Jobs Response:
The client shall specify these attributes to indicate Result Attributes:
events that the client is interested in, along with the The result includes zero or more objects each with zero or more
notification address and method for performing the attributes. Each Job is returned in chronological order. This
notification.
These attributes form the attribute group called "job- June 3, 1997, Expires December 3, 1997
notification". order is explicitly defined to be: oldest to newest with respect to
completion time, either actual or expected.
The client may also specify notification attributes in: If the client did not supply any Job attributes, the Printer shall
Get-Attributes and Get-Jobs. assume that the client is implicitly requesting the 'none' group
(that is no Job attributes are returned, just the Job URI for each
Job).
5.2.2.1 notification-events (setOf type2 keyword) Status
Status information including error status
5.2.2.1.1 As a Job Attribute A Printer may choose, for security reasons, not to return all attributes
that a client requests. It may even return none of the requested
attributes. In such cases, the status returned is the same as if the
Printer had returned all requested attributes. The client cannot tell by
such a response whether the requested attribute was present or absent on
the Printer.
This job attribute specifies the events about which the 5.2 Operation Status and Messages
end user want to be notified.
Standard values within the set are: job-completion, job- The Status code provides information on the results of a request.
canceled, job-problems and printer-problems. The Message provides a short textual description of the Status. The
Status is intended for use by automata and the Message is intended
for the human user. An IPP application (i.e. a browser, GUI, print
driver or gateway) is not required to examine or display the Message.
If this attribute contains the empty set, the Printer 5.3 Status Codes (type2 keyword)
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.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 Each Status is described below, including a description of which
If this attribute contains the value: job-completion, the operation(s) it can follow and any meta-information required in the
Printer shall notify the client when the job containing response.
this attribute completes with or without errors.
If this attribute contains the value: job-canceled, the ISSUE: Keith's doc still need to go here.
Printer shall notify the client when the job containing
this attribute is canceled by the end-user or by the
operator, or aborts before completion.
If this attribute contains the value: job-problems, the 6. Object Attributes
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, This section describes the attributes with their corresponding syntaxes
the Printer shall notify the client when any job, and values that are part of the IPP model. The sections below show the
including this job, is affected by a Printer problem (the objects and their associated attributes which are included within the
printer has moved to the stopped state and there is a scope of this protocol. Many of these attributes are derived from other
reason in the printer-state-reasons attribute) while this relevant specifications:
job is waiting to print or printing. Problems include:
paper jam and out-of-paper.
5.2.2.1.2 As a Printer Attribute - ISO/IEC 10175 DPA (Final, June 1996)
- RFC 1759 Printer MIB (Proposed Standard, May 1995)
- Internet-Draft: Printer MIB (Draft Standard in progress, December
1996)
- Internet-Draft: Job Monitoring MIB (I-D in progress, March 1997)
This printer attribute indicates the default value. It June 3, 1997, Expires December 3, 1997
also indicates the values of the job and printer Each attribute is uniquely identified in this document using a "keyword"
notification-events attribute supported by this Printer in the section header describing that attribute. A keyword is a
and the states of readiness for each value. sequence of characters (length of 1 to 255) which consists of just
letters, digits, hyphen ("-"), and underscore ("_"). With these
restrictions, there will be a straight forward encoding of these
keywords onto real values in the protocol specification. Not only are
attributes uniquely identified with keywords, some attributes take on a
syntax which is a set of keywords. This set of keywords represents the
domain of the attribute.
This document does not specify how or whether an 6.1 Attribute Syntaxes
administrator can configure the information that a
Printer sends with an event when a Printer notifies a
user about the occurrence of an event.
If this attribute is unspecified, then the Printer does The following table shows the basic syntax types that a client and
not support notification. If this attribute is not server shall be able to handle.
contained in an instance of a Printer and the client
supplies the attribute in the Print Request, the
attribute in the Print Request is ignored.
5.2.2.2 notification-addresses (setOf url) Table 1 - Attribute Syntaxes
This address specifies both the address and mechanism for Basic Type Description Comments
delivery of notification events to the client.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 text a sequence of For free form human
The Printer shall use this attribute as the address for characters; readable text
sending messages to a job submitter when an event occurs length: 0 to intended for human
that the end user has registered an interest in. 4095; consumption.
characters: any
If the URL has a "mailto:" scheme, then email is used and name a sequence of For referencing some
the rest of the URL is used as the email address. If the characters; object via a user-
URL has a "http:" scheme, then an HTTP method is used to length: 1 to friendly string,
add HTML formatted events to the end of the specified 255; such as a Printer
HTML file. characters: any name, a document
name, a user name,
or a host name. May
include the SPACE
character.
5.2.2.2.1 As a Job Attribute Note: The protocol
may need to provide
means to quote the
SPACE character if
the protocol uses
SPACE for other
purposes.
This job attribute specifies the method and addresses to fileName a sequence of For referencing some
which the Printer should send messages when events characters; file. The limit is
specified by the notification-events attribute occur. length: 1 to the same as POSIX
1024;
5.2.2.2.2 As a Printer Attribute June 3, 1997, Expires December 3, 1997
Basic Type Description Comments
This Printer attribute's syntax type is "setOf urlScheme" characters: any and NT.
so that an interested client shall know which URL schemes
can be include in the notification-addresses attribute in
the Print Request.
5.2.3 Job Scheduling (job-scheduling) Attributes (Set by keyword a sequence of
Client/End User) characters; identifiers of
length: 1 to entities in the
255; abstract protocol
characters: (specified in this
letters, digits, document). These
hyphen ("-"), entities can be
For semantic
underscore ("_") attribute names or
values of
attributes, When a
keyword is used to
represent an
attribute (its
name), it must be
unique within the
full scope of IPP
objects and
attributes. When a
keyword is used to
represent a value of
an attribute, it
must be unique just
within the scope of
that attribute.
That is, a keyword
can not be used for
two different values
of the same
attribute to mean
two different
semantic ideas.
However, the same
keyword can be used
across two or more
attributes,
representing
different semantic
ideas for each
attribute.
The client shall specify these attributes to provide the uri a sequence of Universal Resource
Printer with information for the scheduling a print-job. characters as Identifier
defined in
rfc1738 and
These attributes form the attribute group called "job- June 3, 1997, Expires December 3, 1997
scheduling". Basic Type Description Comments
The client may also specify these attributes in: Get- rfc1808
Attributes and Get-Jobs.
5.2.3.1 job-priority (integer(1:100)) uriScheme a sequence of "http" for HTTP
characters schemed URIs (e.g.,
representing the http://...). "ftp"
URI Scheme for FTP schemed URIs
(e.g., ftp://...).
5.2.3.1.1 As a Job Attribute locale a standard ISSUE: What standard
identifier for values will be used
language and for locale?
character set
This job attribute specifies a priority for scheduling octetString a sequence of Used for opaque
the print-job. Printers that employ a priority-based octets data, such as the
scheduling algorithm use this attribute. document-content.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 boolean two values of like an keywordSet,
A higher value specifies a higher priority. The value 1 'true' and but there are only
is defined to indicate the lowest possible priority (a 'false' two values. Note: An
job which a priority-based scheduling algorithm shall application might
pass over in favor of higher priority jobs). The value use a checkbox for
100 is defined to indicate the highest possible priority. such a value.
Priority is expected to be evenly or "normally"
distributed across this range. Among those jobs that are
ready to print, a Printer shall print all jobs with a
priority value of n before printing those with a priority
value of n-1 for all n. The mapping of vendor-defined
priority over this range is implementation-specific.
5.2.3.1.2 As a Printer Attribute integer an integer value each attribute
that is in the specifies the range
range from - constraint
2**31 to 2**31 - explicitly.
1
The printer attribute specifies the default priority. It dateTime a value that absolute date and
also specifies the supported range available to end- holds the date time
users. When setting up this attribute, an administrator and time to the
might identify only a subset of the full range which is nearest second.
the range that the end user is authorized to use. There
might be higher or lower priorities (outside the range
defined for end users) available to operators or other
privileged users.
If this attribute is not contained in an instance of a seconds a non-negative a relative time
Printer and the client supplies the attribute in the integer with
Print Request, the attribute in the Print Request is implicit units
ignored. of seconds
5.2.3.2 job-hold-until (type4 keyword) milliseconds a non-negative a relative time
interger with
implicit units
of milliseconds
5.2.3.2.1 As a Job Attribute June 3, 1997, Expires December 3, 1997
Basic Type Description Comments
This job attribute specifies the named time period during integerUnits an integer with an integer value
which the Job print job shall become a candidate for explicit units expressed in units
printing.
Standard values for named time periods are: "no-hold", ISSUE: we have two
"evening", "night", "weekend", "second-shift", "third- types with implicit
shift". An administrator shall associate allowable print units and one with
times with a named time period. An administrator is explicit units where
encouraged to pick names that suggest the type of time the units are
period. specific for one
attribute:
"printer-speed".
If the value of this attribute specifies a time period 1setOf X 1 or more values for sets of values
that is in the future, the Printer shall add the job- of type X.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 rangeOf X a range of value for a range of
hold-until-specified value to the job's job-state-reasons of type X values, such as
attribute and shall not schedule the print-job for integers
printing until the specified time-period arrives. When
the specified time period arrives, the Printer shall
remove the job-hold-until-specified value from the job's
job-state-reason attribute and, if no other reasons
remain, shall consider the job as a candidate for
processing.
If this job attribute value is the named value "no-hold", 6.1.1 Attribute Extensibility
or the time period has already started , the job shall be
a candidate for processing immediately.
5.2.3.2.2 As a Printer Attribute This document uses prefixes to the keyword basic syntax type in order
to communicate extra information to the reader through its name. This
extra information need not be represented in an implementation
because it is unimportant to a client or Printer. The table below
describes the prefixes and their meaning.
This printer attribute indicates the default value. It ISSUE: There are some references to the Printer Working Group (PWG).
also indicates the values of the attribute supported by How do we describe in this document the process for the PWG to
this printer. approve type 2 extensions?
If this attribute is not contained in an instance of a Basic Prefix Comments
Printer and the client supplies the attribute in the Type
Print Request, the attribute in the Print Request is
ignored.
5.2.4 Job Production (job-production) Attributes (Set by keyword type1 someone must revise the IPP standard
Client/End User) to add a new name. No private names
are allowed.
The client shall specify these attributes to affect the keyword type2 implementers can, at any time, add new
rendering, production and finishing of the documents in values by proposing them to the PWG
the job. Similar types of instructions may also be for registration (or an IANA-appointed
contained in the document to be printed. registry advisor after the PWG is no
These attributes form the attribute group called "job- June 3, 1997, Expires December 3, 1997
production". Basic Prefix Comments
Type
If there is a conflict between the value of one of these longer certified) where they are
attributes, and a corresponding instruction in the reviewed for approval. IANA keeps the
document (either implicit or explicit), the value of the registry. Implementers can support
attribute shall take precedence over the document private (unregistered) with a suitable
instruction. distinguishing prefix, such as -xxx-
where xxx is the company name
registered with IANA for use in domain
names.
A job production attribute provides a client with a way keyword type3 implementers can, at any time, add new
to request some feature at print time that may not have values by submitting a registration
been embedded within the document data when the document request directly to IANA, no PWG or
was created. A job production attribute also provides a IANA-appointed registry advisor review
client with a way to override a feature at print time is required. Implementers can support
private (unregistered) names with a
suitable distinguishing prefix, such
as -xxx- where xxx is the company name
registered with IANA for use in domain
names.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 keyword type4 system administrators can, at any
that was embedded within the document data when the time, add new installation-defined
document was created. names to a local system. Care should
be taken by the administrator to see
that keywords do not conflict with
other keywords defined by the standard
or as defined by the implementing
product. There is no registration or
approval procedure for type 4
keywords.
Note: until companies that supply interpreters for PDL's, ISSUE: Since the standard specifies
such as PostScript and PCL allow a way to specify some of the type 4 values, shouldn't
overrides for internal job production instructions, a it be possible to register additional
Printer may not be able to implement these attributes for type 4 values after the standard is
some PDL's. approved?
A job production attribute tells a Printer what features Note: This standard defines keyword values for all of the above types.
the job needs. A program that translates document data to
a Printer's PDL, and/or merges production attributes into
the document data should add job production attributes
to a job, using the "embedded" tag. Such a program may
execute at a number of different points in time:
1. The program produces a final form document and 6.2 Job Template Attributes
stores these resource attributes in a file before the
end-user submits the print job.
2. The program produces a final form document data Job Template attributes describe job processing behavior. Take for
stream when the end-user specifies "Print" to the example, a generic Job Template attribute called "xxx":
application program (e.g., Windows GDI driver).
3. The program running in the context of the Printer or June 3, 1997, Expires December 3, 1997
server translates a revisable or final form document 1. "xxx" is optionally supplied by the client in a create request.
into a PDL that the output device understands. If "xxx" is supplied, the client is specifying that the Printer
will apply a specific job processing behavior to this job while
processing the Job. When "xxx" is not supplied, the client expects
the Printer will apply the default job processing behavior.
For example, a job production attribute medium with the 2. "xxx-supported" is a Printer attribute that describes what is
value of "letter" requests that a job be printed on behaviors are supported by that Printer. "xxx-supported" is a
letter paper, and gives information about what resources CONDITIONALLY MANDATORY attribute which means that the Printer
the job needs. For example, a job production attribute only implements the attribute if it is capable of realizing one or
media with the values of "letter" and "ledger" and the more of the behaviors associated with the attribute and its values.
tag "embedded" tell a Printer that the job needs letter A client can query the Printer and find out what behaviors are
and ledger paper, but gives no information about which supported by inspecting at the values in the "xxx-supported"
pages use each medium_ that information is embedded in attribute.
the document.
A Printer may use these attributes to validate and 3. The Printer also implements a default value attribute named "xxx".
schedule the print-job without interpreting the contents This default value attribute describes what will be done when no
of the document. This provides the opportunity for a other job processing information is supplied by the client (either
Printer to support a broad set of document formats yet explicitly as an IPP attribute in the create request or implicitly
still support fast efficient scheduling and validation of as an embedded instruction within the job data). Along with the
each job. supported attribute, the default value attribute is also
CONDITIONALLY MANDATORY. However, if the Printer implements the
"xxx-supported" attribute, the Printer MUST implement the
corresponding default value attribute and vice versa.
If any of these attributes is unspecified, the Printer 4. The Printer OPTIONALLY implements the "xxx-available" attribute.
shall assume that the all resources required by the This attribute describes a state of readiness for each supported
document of the type specified by the missing attributes attribute. The supported and available attributes have the same
number of attributes and are ordered so that there is a set of
ordered value pairs between the two attributes. The availability
state of a supported attribute value indicates the level of effort
required by the Printer to actually use resource indicated by the
supported value. The following values are used in the "xxx-
available" attributes:
draft-ietf-ipp-model-00.txt, expires September 26, 1997 'ready' - the resource can be used by a Job without human
are ready, i.e., are available to the Printer and/or intervention (the resource is not exhausted)
output device without human intervention. 'not-ready' - the use of the resource requires human intervention
(the resource may be exhausted or not automatically available)
The client may specify these attributes in: Get- Note: The "xxx-available" attribute only applies to the "media" and
Attributes and Get-Jobs. "finishings" attributes.
The client may also specify job production-instruction 5. If a client application wishes to present an end user with a list
attributes in: Get-Attributes and Get-Jobs. For all the of supported and default values from which to choose, the client
attributes in this section, the default behavior if the program should query the supported, default values, and possibly
Printer attribute is unspecified is that the document is the available attributes. The values that the client then sends in
printed with the output-device defaults, possibly the create request will all fall within the supported values at the
overridden by whatever is in the document data, if
anything.
Each attribute which is of type keyword in this section June 3, 1997, Expires December 3, 1997
also has a special value: "ignore" which is useful for a Printer. When querying the Printer, the client MAY enumerate each
file type, such as PostScript, which the Printer may not attribute by name in the Get-Attributes Request, or the client MAY
allow changes to. just name the "printer-job-template" group in order to get the
complete set of supported, default value, and available attributes
which are implemented.
5.2.4.1 multiple-documents-are (type1 keyword) The "job-priority" attribute is an example of a Job Template attribute.
It is an integer in the range from 1 to 100. A client can query the
Printer for the "job-priority-supported" attribute and the "job-
priority" default value attribute. The supported attribute contains a
set of supported priority values (a range). The default value attribute
contains job priority value that will be used for a new job if the
client does not supply one in the create request. If the client does
supply the "job-priority" attribute, the Printer validates the value to
make sure that it falls within the range of supported values. If the
client-supplied value is supported, the Job object is created and the
"job-priority" attribute is populated with that value. The Job object,
when queried, returns the value supplied by the client. If the client
does not supply a "job-priority" value in the create request, the Job
object is created, but no "job-priority" attribute is implemented for
the Job. The client queries the Printer's default value "job-priority"
value to find out at what priority the job will be processed.
5.2.4.1.1 As a Job Attribute The following table summarize the names, relationships, and conformance
requirements for all Job Template attributes. The following general
rules apply to implementation requirements:
This job attribute is relevant only if a job consists of 1. In a create request, all Job Template attributes are OPTIONAL.
two or more documents. It controls finishing operations,
job-sheet placement, and the order of documents when the
copies attribute exceeds 1.
This attribute can have one of three values: single- 2. In a Printer Object, all supported attributes are CONDITIONALLY
document, separate-documents-uncollated-copies, separate- MANDATORY.
documents-collated-copies.
If the files for the job are a and b and this attribute's 3. All Printer default value attributes are CONDITIONALLY MANDATORY.
value is single-document , then files a and b are treated However, if the supported attribute is implemented then the default
as a single document for finishing operations. Also, value attribute MUST be implemented and vice versa.
there will be no slip sheets between files a and b. If
more than one copy is made, the ordering must be a, b, a,
b, ....
If the files for the job are a and b and this attribute's 4. All "available" attributes are OPTIONAL.
value is separate-documents-uncollated-copies, or
separate-documents-collated-copies or unspecified, then
each file is treated as a single document for finishing
operations. Also, a client may specify that a slip sheet
draft-ietf-ipp-model-00.txt, expires September 26, 1997 The table only shows exceptions to the above rules. The first column
be between files a and b. If more than one copy is made, of the table (Job) shows the name and syntax for each Job Template
and the attribute's value is separate-documents-
uncollated-copies or unspecified, the ordering is a, a,
b, b, .... If more than one copy is made, and the
attribute's value is separate-documents-collated-copies,
the ordering is a, b, a, b, ....
5.2.4.1.2 As a Printer Attribute June 3, 1997, Expires December 3, 1997
attribute in the Job object (in the create request, the same name and
syntax is used). The next three columns show the name and syntax for
each Job Template attribute in the Printer object (the default value
attribute, the supported attribute, and the available attribute). A
"No" in the table means the Printer SHALL NOT implement the attribute.
This printer attribute specifies the default value and Job Printer Printer Printer
the supported values. Default Value Supported Available
5.2.4.2 best-effort (type2 keyword) job-name No No No
(name, MAN))
This attribute determines what to do if there is a job-sheets job-sheets job-sheets- No
conflict between what a client requests and what a (type4 keyword) (type4 keyword) supported
Printer is capable of . Values for this attribute are: (1setOf type4
"substitute-as-needed" and "do-not-substitute". keyword)
5.2.4.2.1 As a Job Attribute notificaiton- notification- No
events events events
(1setOf type2 (1setOf type2
notification-
(1setOf type2
keyword) keyword) keyword)
This job attribute specifies the Printer should do if the notification- No notification- No
Printer can not support all other attribute values in addresses addresses-
other Job attributes. If the value is "substitute-as- (1setOf uri) supported
needed" then the end user desires the job to be printed (1setOf uri
using substitutions by the Printer where needed in order scheme)
to resolve conflicts. If the value is do-not-substitute
then the end user desires that the job should not be
processes unless every attribute value can be completely
satisfied. If the client does not supply a value for
this attribute in a print request, the Printer shall
assume that the value is "do-not-substitute."
Note: that best-effort is unlikely to be used much. Many job-priority job-priority job-priority- No
clients will submit a job with no attributes, and the (int) (int) supported
Printer will use default values. Other clients will (rangeOf int)
submit a job via a GUI which limits the attribute values
to those which are supported. Best-effort is useful in
the GUI context only if a user expects the job to be
moved to another printer and prefers a sub-optimal result
to nothing at all. Best-effort is most useful in the case
where an end-user uses a command line interface to
request attributes that may not be supported.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 job-hold-until job-hold-until job-hold-until- No
5.2.4.2.2 As a Printer Attribute (type4 keyword) (type4 keyword) supported
(1setOf type4
keyword)
This printer attribute specifies supported and default multiple- multiple- multiple- No
behavior of the Printer if there is a conflict between documents-are documents-are documents-are-
Job attributes and Printer supported attributes, If the (type2 keyword) (type2 keyword) supported
value is "substitute" then Printer is capable of doing (1setOf type2
some sort of best effort when there is a conflict, If
the value is do-not-substitute then the Printer will
reject all print requests that can not be completely
satisfied. If the Printer object does not instantiate
this attribute, the client shall assume that the value is
do-not-subtitute.
5.2.5 Document Production (document-production) Attributes June 3, 1997, Expires December 3, 1997
(Set by Client/End User) Job Printer Printer Printer
Default Value Supported Available
These attributes are similar to Job Production Attributes keyword)
except that they may also be associated with a document
and override the same attribute associated with the job.
These attributes form the attribute group called best-effort best-effort best-effort- No
"document-production". (type2 keyword) (type2 keyword, supported
MAN) (1setOf type2
keyword, MAN)
5.2.5.1 medium (setOf type2 keyword) media media media-supported media-available
(type4 keyword) (type4 keyword) (1setOf type2 (1setOf avail
keyword) keyword)
5.2.5.1.1 As a Job Attribute number-up number-up number-up-
(type3 keyword) (type3 keyword) supported
(1setOf type3
keyword)
This job attribute identifies the medium that the Printer sides sides sides-supported
shall use for all pages of the document regardless of (type2 keyword) (type2 keyword) (1setOf type2
what media are specified within the document. keyword)
The values for medium include medium-names, medium-sizes, printer- printer- printer-
input-trays and electronic forms so that one attribute resolution resolution resolution-
specifies the media. (type2 keyword) (type2 keyword) supported
(1setOf type2
keyword)
If a printer allows a client to specify a medium-name as print-quality print-quality print-quality -
the value of this attribute, such a medium-name (type2 keyword) (type2 keyword) supported
implicitly selects an input-tray that contains the (1setOf type2
specified medium. keyword)
If a printer allows a client to specify a medium-size as finishings finishings finishings- finishings-
the value of this attribute, such a medium-size (setOf type2 (setOf type2 supported available
implicitly selects a medium-name which in turn implicitly keyword) keyword) (setOf type2 (setOf avail
keyword) keyword)
draft-ietf-ipp-model-00.txt, expires September 26, 1997 copies copies copies-supported No
selects an input-tray that contains the medium with the (int) (int) (rangeOf int)
specified size. If a printer contains two or more medium-
names with the same medium-size, then a printer shall not
include that medium-size in the list of supported values
for this attribute and the printer shall reject jobs that
request such a medium-size.
If a printer allows a client to specify an input-tray as June 3, 1997, Expires December 3, 1997
the value of this attribute, such an input-tray Job Printer Printer Printer
implicitly selects the medium that is in that input-tray Default Value Supported Available
at the time the job prints. This case includes manual-
freed input-trays.
If a printer allows a client to specify an electronic compression compression compression- No
form as the value of this attribute, such an electronic (type3 keyword) (type3 keyword) supported
form implicitly selects a medium-name which in turn (1setOf type3
implicitly selects an input-tray that contains the medium keyword)
specified by the electronic form. The electronic form
also implicitly selects an image that the Printer shall
merge with the data from the document as its prints each
page. When this attribute appears as a job attribute with
the embedded tag, it may contain more than one value and
it shall indicate all media required by the document.
5.2.5.1.2 As a Printer Attribute job-k-octets No job-k-octets-
supported
No
(int)
(rangeOf int)
This printer attribute identifies the default value. It job-impressions No job-impressions- No
also identifies the media, media-sizes, input trays, and (int) supported
electronic forms supported by this printer, and indicates (rangeOf int)
the state of availability for each medium resource.
Standard values are defined(taken from ISO DPA and the job-media-sheets No job-media- No
Printer MIB): (int) sheets-supported
(rangeOf int)
default The default medium for the 6.2.1 job-name (name)
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
draft-ietf-ipp-model-00.txt, expires September 26, 1997 This attribute defines the name of the job. It is a name that is more
iso-a5-white Specifies the ISO A5 white user friendly than the job-URI.
medium
iso-a5-colored Specifies the ISO A5 coloured
medium
iso-b4-white Specifies the ISO B4 white
medium
iso-b4-colored Specifies the ISO B4 coloured
medium
iso-b5-white Specifies the ISO B5 white
medium
iso-b5-colored Specifies the ISO B5 coloured
medium
jis-b4-white Specifies the JIS B4 white
medium
jis-b4-colored Specifies the JIS B4 coloured
medium
jis-b5-white Specifies the JIS B5 white
medium
jis-b5-colored Specifies the JIS B5 coloured
medium
The following standard values are defined for North If "job-name" is not supplied in the in the create request, the Printer,
American media: on creation of the Job, shall generate a name which is the name of the
first document in the job. This name comes from the "document-name"
attribute or "document-URI" attribute depending on which attribute is
supplied in the Create-Job Request for the first document. If "job-
name" is supplied in the Create-Job Request, the Printer uses its value
as the name of the created Job.
na-letter-white Specifies the North American June 3, 1997, Expires December 3, 1997
letter white medium 6.2.2 job-sheets (type4 keyword)
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: This attribute determines which of any banner page(s) shall be printed
with a job.
iso-b4-envelope Specifies the ISO B4 envelope Standard values are:
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
draft-ietf-ipp-model-00.txt, expires September 26, 1997 'none': no job sheet is printed
iso-c5-envelope Specifies the ISO C5 envelope 'standard': a site specific standard job sheet is printed
medium extensions: names the specific job sheet (banner page)
iso-c6-envelope Specifies the ISO C6 envelope
medium
iso-designated- Specifies the ISO Designated
long-envelope Long envelope medium
na-10x13- Specifies the North American
envelope 10x13 envelope medium
na-9x12-envelope Specifies the North American
9x12 envelope medium
monarch-envelope Specifies the Monarch envelope
na-number-10- Specifies the North American
envelope number 10 business envelope
medium
na-7x9-envelope Specifies the North American
7x9 inch envelope
na-9x11-envelope Specifies the North American
9x11 inch envelope
na-10x14- Specifies the North American
envelope 10x14 inch envelope
na-number-9- Specifies the North American
envelope number 9 business envelope
na-6x9-envelope Specifies the North American
6x9 inch envelope
na-10x15- Specifies the North American
envelope 10x15 inch envelope
The following standard values are defined for the less To force no job sheets, the system administrator SHALL set the only
commonly used media (white-only): supported value to 'none'.. To force the use of banner pages, the
supported values shall not include 'none'. If a client requests 'none'
in the create request, the request is rejected.
executive-white Specifies the white executive 6.2.3 notification-events (1setOf type2 keyword)
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
draft-ietf-ipp-model-00.txt, expires September 26, 1997 This attribute specifies the events for which the end user desires some
iso-a6-white Specifies the ISO A6 white sort of notification. The "notification-addresses" attribute is used to
medium describe the destination addresses for these events.
iso-a7-white Specifies the ISO A7 white
medium
iso-a8-white Specifies the ISO A8 white
medium
iso-a9-white Specifies the ISO A9 white
medium
iso-10-white Specifies the ISO A10 white
medium
iso-b0-white Specifies the ISO B0 white
medium
iso-b1-white Specifies the ISO B1 white
medium
iso-b2-white Specifies the ISO B2 white
medium
iso-b3-white Specifies the ISO B3 white
medium
iso-b6-white Specifies the ISO B6 white
medium
iso-b7-white Specifies the ISO B7 white
medium
iso-b8-white Specifies the ISO B8 white
medium
iso-b9-white Specifies the ISO B9 white
medium
iso-b10-white Specifies the ISO B10 white
medium
jis-b0-white Specifies the JIS B0 white
medium
jis-b1-white Specifies the JIS B1 white
medium
jis-b2-white Specifies the JIS B2 white
medium
jis-b3-white Specifies the JIS B3 white
medium
jis-b6-white Specifies the JIS B6 white
medium
jis-b7-white Specifies the JIS B7 white
medium
jis-b8-white Specifies the JIS B8 white
medium
jis-b9-white Specifies the JIS B9 white
medium
jis-b10-white Specifies the JIS B10 white
medium
draft-ietf-ipp-model-00.txt, expires September 26, 1997 Standard values are:
The following standard values are defined for engineering
media:
a Specifies the engineering A 'none': the Printer shall not notify
size medium 'all': the Printer shall notify when any of event occurs.
b Specifies the engineering B 'job-completion': the Printer shall notify when the job containing
size medium this attribute completes with or without errors.
c Specifies the engineering C 'job-canceled': the Printer shall notify when the job containing
size medium this attribute is canceled by the end-user or by the operator, or
d Specifies the engineering D aborts before completion.
size medium 'job-problems': the Printer shall notify when this job has a problem
e Specifies the engineering E while this job is printing. Problems include any of the "job-state-
size medium reasons" or "printer-state-reason" values
'printer-problems': the Printer shall notify when any job, including
this job, is affected by a Printer problem (the printer has moved
to the stopped state and there is a reason in the printer-state-
reasons attribute) while this job is waiting to print or printing.
Problems include any of the "job-state-reasons" or "printer-state-
reason" values
The following standard values are defined for input-trays 6.2.4 notification-addresses (1setOf uri)
(from ISO DPA and the Printer MIB):
top The top input tray in the printer. This attribute describes both where (the address) and how (the mechanism
middle The middle input tray in the printer. for delivery ) notification events are to be delivered. The Printer
bottom The bottom input tray in the printer. shall use this attribute as the set of addresses and methods for sending
envelope The envelope input tray in the messages when an event occurs that the end user (job submitter) has
printer. registered an interest in.
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 June 3, 1997, Expires December 3, 1997
(from ISO DPA): Standard uri scheme values are:
iso-a0 Specifies the ISO A0 size: 841 mm by 'mailto': email is used
1189 mm as defined in ISO 216 'http': an HTTP method is used to add HTML formatted events to the
iso-a1 Specifies the ISO A1 size: 594 mm by 841 end of the specified HTML file.
mm as defined in ISO 216 'ftp': FTP is used to append a record at the end of a specified text
iso-a2 Specifies the ISO A2 size: 420 mm by 594 file.
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
draft-ietf-ipp-model-00.txt, expires September 26, 1997 6.2.5 job-priority (integer(1:100))
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 This attribute specifies a priority for scheduling the print-job. A
1414 mm as defined in ISO 216 higher value specifies a higher priority. The value 1 is defined to
iso-b1 Specifies the ISO B1 size: 707 mm by indicate the lowest possible priority. The value 100 is defined to
1000 mm as defined in ISO 216 indicate the highest possible priority. Priority is expected to be
iso-b2 Specifies the ISO B2 size: 500 mm by 707 evenly or "normally" distributed across this range. Among those jobs
mm as defined in ISO 216 that are ready to print, a Printer shall print all jobs with a priority
iso-b3 Specifies the ISO B3 size: 353 mm by 500 value of n before printing those with a priority value of n-1 for all n.
mm as defined in ISO 216 The mapping of vendor-defined priority over this range is
iso-b4 Specifies the ISO B4 size: 250 mm by 353 implementation-specific.
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 6.2.6 job-hold-until (type4 keyword)
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)
draft-ietf-ipp-model-00.txt, expires September 26, 1997 This job attribute specifies the named time period during which the Job
iso-c3 Specifies the ISO C3 size: 324 mm by print job shall become a candidate for printing.
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 Standard values for named time periods are:
envelope 10x13 size: 10 inches by 13
inches
na-9x12- Specifies the North American
envelope 9x12 size: 9 inches by 12 inches
na-number-10- Specifies the North American
envelope number 10 business envelope
size: 4.125 inches by 9.5 inches
na-7x9- Specifies the North American 7x9
envelope inch envelope size
na-9x11- Specifies the North American
envelope 9x11 inch envelope size
na-10x14- Specifies the North American
envelope 10x14 inch envelope size
na-number-9- Specifies the North American
envelope number 9 business envelope size
na-6x9- Specifies the North American 6x9
envelope envelope size
na-10x15- Specifies the North American
envelope 10x15 envelope size
monarch- Specifies the Monarch envelope
envelope size (3.87 x 7.5 in)
a Specifies the engineering A 'no-hold': immediately, if there are not other reasons to hold the
size: 8.5 inches by 11 job.
inches 'day-time': during the day.
b Specifies the engineering B 'evening': evening
size: 11 inches by 17 'night': night
inches 'weekend': weekend (Saturday or Sunday)
c Specifies the engineering C 'second-shift': second-shift
size: 17 inches by 22 'third-shift': third-shift (after midnight)
inches
d Specifies the engineering D
size: 22 inches by 34
inches
draft-ietf-ipp-model-00.txt, expires September 26, 1997 An administrator shall associate allowable print times with a named time
e Specifies the engineering E period (by means outside IPP 1.0). An administrator is encouraged to
size: 34 inches by 44 pick names that suggest the type of time period.
inches
jis-b0 Specifies the JIS B0 size: 1030mm x If the value of this attribute specifies a time period that is in the
1456mm future, the Printer shall add the 'job-hold-until-specified' value to
jis-b1 Specifies the JIS B1 size: 728mm x the job's "job-state-reasons" attribute and shall not schedule the
1030mm print-job for printing until the specified time-period arrives. When
jis-b2 Specifies the JIS B2 size: 515mm x the specified time period arrives, the Printer shall remove the 'job-
728mm hold-until-specified' value from the job's "job-state-reason attribute"
jis-b3 Specifies the JIS B3 size: 364mm x
515mm
jis-b4 Specifies the JIS B4 size: 257mm x
364mm
jis-b5 Specifies the JIS B5 size: 182mm x
257mm
jis-b6 Specifies the JIS B6 size: 128mm x
182mm
jis-b7 Specifies the JIS B7 size: 91mm x 128mm
jis-b8 Specifies the JIS B8 size: 64mm x 91mm
jis-b9 Specifies the JIS B9 size: 45mm x 64mm
jis-b10 Specifies the JIS B10 size: 32mm x 45mm
5.2.5.2 number-up (type3Enum) June 3, 1997, Expires December 3, 1997
and, if no other reasons remain, shall consider the job as a candidate
for processing.
5.2.5.2.1 As a Job Attribute If this job attribute value is the named value "'no-hold'", or the time
period has already started , the job shall be a candidate for processing
immediately.
This job attribute specifies the number of source page- 6.2.7 multiple-documents-are (type2 keyword)
images to impose upon a single side of an instance of a
selected medium.
5.2.5.2.2 As a Printer Attribute This job attribute is relevant only if a job consists of two or more
documents. It controls finishing operations, job-sheet placement, and
the order of documents when the copies attribute exceeds 1.
This printer attribute identifies the default value and Standard values are:
the number-up values supported by this printer..
The state of readiness for each number-up value is also 'single-document': If the files for the job are a and b, then files a
included, though all number-up conversions should always and b are treated as a single document for finishing operations.
be ready. Also, there will be no slip sheets between files a and b. If more
than one copy is made, the ordering shall be a, b, a, b, ....
'separate-documents-uncollated-copies': If the files for the job are
a and b, then each file is treated as a single document for
finishing operations. Also, a client may specify that a slip sheet
be placed between files a and b. If more than one copy is made,
the ordering shall be a, a, b, b, ....
'separate-documents-collated-copies': If the files for the job are a
and b, then each file is treated as a single document for finishing
operations. Also, a client may specify that a slip sheet be placed
between files a and b. If more than one copy is made, the ordering
shall be a, b, a, b, ....
In general, only certain numeric values are valid for Both of the 'separate-xxx' values force each new document to start on a
this attribute and the value "none", depending upon the new media sheet.
Printer implementation to which the print-request is
directed. Standard values are: "none", "1", "2", "4".
draft-ietf-ipp-model-00.txt, expires September 26, 1997 6.2.8 best-effort (type2 keyword)
This attribute primarily controls the translation,
scaling and rotation of page images, but a site may
choose to add embellishments, such as borders to each
logical page. The value "none" shall not include any
embellishments and shall place one logical page on a
single side of an instance of the selected medium without
any translation, scaling, or rotation.
5.2.5.3 sides (type2 keyword) This attribute determines what to do if there is a conflict between what
a client requests and what a Printer supports.
5.2.5.3.1 As a Job Attribute Standard values for this attribute are:
This job attribute specifies how source page-images are - 'shall-honor-ipp-attributes': If a Printer supports this value and
to be imposed upon the sides of an instance of a selected a client requests this value, the Printer guarantees that all IPP
medium. attribute values take precedence over embedded instructions in the
job data (the PDL of the job's documents).
- 'should-honor-ipp-attributes': If a Printer supports this value,
and a client requests this value, the Printer should try to make
When this attribute appears as a job attribute with the June 3, 1997, Expires December 3, 1997
embedded tag, it may contain more than one value and it sure that IPP attribute values take precedence over embedded PDL
shall indicate all sides operations required by the instructions, however there is no guarantee
document.
5.2.5.3.2 As a Printer Attribute The client supplies Job Template attributes in the create request 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, that is, within the Page Description Language
(PDL) of the document data. If there is a conflict between the value of
one of these attributes, and a corresponding instruction in the document
(either implicit or explicit), it is desireable that the value of the
attribute shall take precedence over the document instruction. Many of
these job template attributes provides a client with a way to request
some feature at print time that might not have been embedded within the
document data when the document was created. Job template 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 PDLs, such
as PostScript and PCL allow a way to specify overrides for internal job
production instructions, a Printer might not be able to implement these
attributes for some PDLs.
This printer attribute indicates the default. It also In order to solve this problem, the IPP Printer implements the MANDATORY
indicates the values of the sides attribute supported by best-effort-supported" attribute. If the value of this attribute is
this printer and the states of readiness of each value. 'shall-honor-ipp-attributes', the implementation MUST guarantee that the
IPP attribute values take precedence over any related job processing
instructions in the PDL Job's document data. This can be done by
modifying the interpreter within the output device itself to understand
IPP attributes, or by mergeing theses Job Template attributes directly
into the document data, or in any other implementation specific manner.
In any case, the semantics of 'shall-honor-ipp-attributes' MUST be
preserved.
The standard values are: 1-sided, 2-sided-long-edge, 2- Note: Since 'should-honor-ipp-attributes' does not offer any type of
sided-short-edge. guarantee, a Printer may not do a very "good" job of implementing the
semantics of "should", but it would still be a conforming
implementation.
1-sided imposes each consecutive source page-image upon This "best-effort" attribute has nothing to do with conflict between
the same side of consecutive media sheets. what a Printer supports and what an IPP client requests. If there is
such a conflict, the Printer shall reject the create request. A client
SHOULD query the printer to find out what is supported before supplying
specific values in a create request.
2-sided-long-edge imposes each consecutive pair of source 6.2.9 media (type4 keyword)
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 This job attribute identifies the medium that the Printer shall use for
source page-image upon front and back sides of all pages of the document regardless of what media are specified within
consecutive media sheets, such that the orientation of the document.
each pair of source-pages on the medium would be correct
draft-ietf-ipp-model-00.txt, expires September 26, 1997 June 3, 1997, Expires December 3, 1997
for the reader as if for binding on the short edge. This The values for medium include medium-names, medium-sizes, input-trays
imposition is sometimes called "tumble" or "head-to-toe". and electronic forms so that one attribute specifies the media. If a
printer allows a client to specify a medium name as the value of this
attribute, such a medium name implicitly selects an input-tray that
contains the specified medium. If a printer allows a client to specify
a medium size as the value of this attribute, such a medium size
implicitly selects a medium name which in turn implicitly selects an
input-tray that contains the medium with the specified size. If a
printer allows a client to specify an input-tray as the value of this
attribute, such an input-tray implicitly selects the medium that is in
that input-tray at the time the job prints. This case includes manual-
freed input-trays. If a printer allows a client to specify an
electronic form as the value of this attribute, such an electronic form
implicitly selects a medium-name which in turn implicitly selects an
input-tray that contains the medium specified by the electronic form.
The electronic form also implicitly selects an image that the Printer
shall merge with the data from the document as its prints each page.
2-sided-long-edge and 2-sided-short-edge work the same Standard values are (taken from ISO DPA and the Printer MIB):
for portrait or landscape. That is, "head-to-toe" is
"tumble" in portrait but "duplex" in landscape. "head-
to-head" also switches between "duplex" and "tumble" when
using portrait and landscape modes.
5.2.5.4 printer-resolution (type2 keyword) default:
iso-a4-white:
...
5.2.5.4.1 As a Job Attribute 6.2.10 number-up (type3 keyword)
This job attribute specifies the resolution that the This job attribute specifies the number of source page-images to impose
Printer should use. upon a single side of an instance of a selected medium.
When this attribute appears as a job attribute with the Standard values are:
embedded tag, it shall indicate the printer resolution
required by the document.
5.2.5.4.2 As a Printer Attribute 'none': The Printer 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.
'one': The Printer shall place one logical page on a single side of
an instance of the selected medium but is allowed to add
embellishments or some sort of translation, scaling, or rotation.
'two':
'four':
This printer attribute indicates the default value. It This attribute primarily controls the translation, scaling and rotation
also indicates the values of the printer-resolution- of page images, but a site may choose to add embellishments, such as
select attribute supported by this printer and their borders to each logical page.
states of readiness.
The state of readiness for each printer resolution is 6.2.11 sides (type2 keyword)
also included, though normally all printer-resolutions
should always be ready.
The values are type2Enums which represent single integers This attribute specifies how source page-images are to be imposed upon
or pair of integers. The latter are to specify the the sides of an instance of a selected medium.
resolution when the x and y dimensions differ. When two
integers are specified, the first is in the x direction,
i.e., in the direction of the shortest dimension of the
medium, so that the value is independent of whether the
printer feeds long edge or short edge first.
June 3, 1997, Expires December 3, 1997
The standard values are: The standard values are:
res-100 'one-sided': imposes each consecutive source page-image upon the same
res-200 side of consecutive media sheets.
res-240 'two-sided-long-edge': imposes each consecutive pair of source page-
res-300 image upon front and back sides of consecutive media sheets, such
that the orientation of each pair of source-pages on the medium
draft-ietf-ipp-model-00.txt, expires September 26, 1997 would be correct for the reader as if for binding on the long edge.
res-600 This imposition is sometimes called "duplex".
res-800 'two-sided-short-edge': imposes each consecutive pair of source page-
res-1200 image upon front and back sides of consecutive media sheets, such
res-1800 that the orientation of each pair of source-pages on the medium
res-100x200 would be correct for the reader as if for binding on the short
res-300x600 edge. This imposition is sometimes called "tumble" or "head-to-
res-600x300 toe".
res-400x800
res-800x400
res-600x1200
res-1200x600
res-1800x600
5.2.5.5 print-quality (type2 keyword)
5.2.5.5.1 As a Job Attribute
This job attribute specifies the print quality that the
Printer should use.
When this attribute appears as a job attribute with the 'two-sided-long-edge' and 'two-sided-short-edge' work the same for
embedded tag, it shall indicate the print-quality portrait or landscape. That is, "head-to-toe" is "tumble" in portrait
required by the document. but "duplex" in landscape. "head-to-head" also switches between
"duplex" and "tumble" when using portrait and landscape modes.
5.2.5.5.2 As a Printer Attribute 6.2.12 printer-resolution (type2 keyword)
This printer attribute indicates the default value. It This job attribute specifies the resolution that the Printer should use.
also indicates the values of the printer-quality
attribute supported by this printer and the states of
readiness for each print-quality value.
The standard values are defined in the printer-quality The values are type2 keywords which represent single integers or pair of
attribute. integers. The latter are to specify the resolution when the x and y
dimensions differ. When two integers are specified, the first is in the
x direction, i.e., in the direction of the shortest dimension of the
medium, so that the value is independent of whether the printer feeds
long edge or short edge first.
The standard values are: The standard values are:
draft Lowest quality available on the normal:
printer res-100:
res-300x300:
normal Normal or intermediate quality on ...
the printer
high Highest quality available on the
printer
draft-ietf-ipp-model-00.txt, expires September 26, 1997 6.2.13 print-quality (type2 keyword)
5.2.5.6 copies (integer(1:2**31 - 1))
5.2.5.6.1 As a Job Attribute This job attribute specifies the print quality that the Printer should
use.
This job attribute specifies the number of copies of the The standard values are:
job to be printed.
NOTE - The effect of this attribute on jobs and documents draft: lowest quality available on the printer
is controlled by the multiple-files-are job attribute.
5.2.5.6.2 As a Printer Attribute June 3, 1997, Expires December 3, 1997
normal: normal or intermediate quality on the printer
high: highest quality available on the printer
This printer attribute indicates the default value. It 6.2.14 copies (integer(1:2**31 - 1))
also specifies the minimum and maximum number of copies
of a document that can be rendered by this printer in a
single print-job.
5.2.5.7 finishing (setOf type2 keyword) This job attribute specifies the number of copies of the job to be
printed. Note: The effect of this attribute on jobs and documents is
controlled by the multiple-files-are job attribute.
5.2.5.7.1 As a Job Attribute 6.2.15 finishings (1setOf type2 keyword)
This job attribute identifies the finishing operation This job attribute identifies the finishing operation that the Printer
that the Printer should apply to each copy of each should apply to each copy of each printed document in the job where the
printed document in the job where the definition of a definition of a copy is controlled by the "multiple-documents-are" Job
copy is controlled by the multiple-documents-are Job
attributes. attributes.
When this attribute appears as a job attribute with the Standard values are:
embedded tag, it may contain more than one value and it
shall indicate all finishing operations required by the
job.
5.2.5.7.2 As a Printer Attribute
This printer attribute identifies the default value. It
also identifies the finishing operations supported by
this Printer and states of availability for each
finishing.
Standard values for this attribute are: none:
staple:
...
none Perform no finishing. 6.2.16 compression (type3 keyword)
draft-ietf-ipp-model-00.txt, expires September 26, 1997 This attribute identifies compression algorithms used for compressed
staple This indicates that staples are to document data.
be used to bind the document. The
exact number and placement of the
staples is site-defined; other
finishing object attributes may be
included to provide this
information.
staple-top- This indicates that one or more
left staples should be placed on the top
left corner of the document
staple- This indicates that one or more
bottom-left staples should be placed on the
bottom left corner of the document
staple-top- This indicates that one or more
right staples should be placed on the top
right corner of the document
staple-
bottom- staples should be placed on the
This indicates that one or more
right bottom right corner of the document
saddle- This indicates that one or more
stitch staples (wire stitches) are to be
used to bind the document along the
middle fold. The exact number and
placement of the stitches is site-
defined.
edge-stitch This indicates that one or more
staples (wire stitches) are to be
used to bind the document along one
edge. The exact number and
placement of the staples is site-
defined.
punch This indicates that holes are
required in the finished document.
The exact number and placement of
the holes is site-defined The
punch specification may be
satisfied (in a site- and
implementation-specific manner)
either by drilling/punching, or by
substituting predrilled media.
cover This value is specified when it is
desired to select a non-printed (or
pre-printed) cover for the
document. This does not supplant
the specification of a printed
cover (on cover stock medium) by
the document itself.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 Standard values for this attribute are:
bind This indicates that a binding is to
be applied to the document; the
type and placement of the binding
is site-defined.
5.2.5.8 compression (type2 keyword) 'none':
'zip':
'tar':
...
This attribute identifies compression algorithms used for 6.2.17 job-k-octets (integer(0:2**31 - 1))
compression document data.
Standard values for this attribute are: zip, tar, ... This Job attribute specifies the total size of the job in K octets,
i.e., in units of 1024 octets. The value shall be rounded up, so that a
job between 1 and 1024 octets shall be indicated as being 1K, 1025 to
2048 shall be 2, etc. This attribute is not intended to be a counter as
in the Job Monitoring MIB; it is intended to be useful routing and
scheduling information if known. The Printer might not be able to
5.2.5.8.1 As a Job Attribute June 3, 1997, Expires December 3, 1997
compute this value (if not supplied by the client in the request) at the
time the Job is created. If not, the Printer may implement this
attribute at any later time as it is able to compute the total size of
the Job.
This job attribute identifies the compression algorithm 6.2.18 job-impressions (integer(0:2**31 - 1))
that has been applied to the document data.
5.2.5.8.2 As a Printer Attribute This job attribute specifies the total size of the job in impressions.
This attribute is not intended to be a counter as in the Job Monitoring
MIB; it is intended to be useful routing and scheduling information if
known. The Printer shall try to compute the value if it is not supplied
in the create request. The Printer might not be able to compute this
value (if not supplied by the client in the request) at the time the Job
is created. If not, the Printer may implement this attribute at any
later time as it is able to compute the total size of the Job.
This printer attribute identifies the default value. It 6.2.19 job- media-sheets (integer(0:2**31 - 1))
also identifies the compression algorithms supported by
this Printer
5.2.6 Document Format Attributes (Set by Client/End User) This job attribute specifies the total size of the job in media-sheets.
This attribute is not intended to be a counter as in the Job Monitoring
MIB; it is intended to be useful routing and scheduling information if
known. The Printer shall try to compute the value if it is not supplied
in the Create-Job Request. The Printer might not be able to compute
this value (if not supplied by the client in the request) at the time
the Job is created. If not, the Printer may implement this attribute at
any later time as it is able to compute the total size of the Job.
There is no group name for these attributes since there 6.3 Job Attributes
is only one attribute in the group.
5.2.6.1 document-format (type2 keyword) The attributes in this section are associated with a Job.
5.2.6.1.1 As a Job Attribute 6.3.1 Job Template Attributes
This job attribute identifies the document format of this The Job Template attributes which apply specifically to a Job object are
document, and may be a per-document attribute. described in section 6.2 Job Template Attributes. These Job specific
attributes form the attribute group called "job-template".
5.2.6.1.2 As a Printer Attribute 6.3.2 Job Description Attributes
This printer attribute indicates default value. It also These attributes form the attribute group called "job-description".
indicates the values of the attribute supported by this
draft-ietf-ipp-model-00.txt, expires September 26, 1997 Attribute Man
printer and the states of readiness for each value. One ?
possible supported and default value is "auto-sense".
The following standard values have been reviewed with the June 3, 1997, Expires December 3, 1997
Printer Working Group and are registered with IANA as job-URI Man
part of the IETF Printer MIB project. The standard value (uri)
assigned by the PWG starts with the four letters: "lang",
in order to follow SNMP ASN.1 rules that all enum symbols
shall start with a lower case letter. The keyword values
in IPP shall be the same as the PWG standard values
registered with IANA with the "lang" removed. The MIB
(integer) value is included here for reference only, the
MIB integer value shall not be used in IPP; the keyword
value shall be used instead:
keyword MIB Description job-originating- Man
Value val user
ue (name)
other 1
PCL 3 PCL. Starting with PCL version 5,
HP-GL/2 is included as part of the
PCL language. PCL and HP-GL/2 are
registered trademarks of Hewlett-
Packard Company.
HPGL 4 Hewlett-Packard Graphics Language.
HP-GL is a registered trademark of
Hewlett-Packard Company.
PJL 5 Peripheral Job Language. Appears
in the data stream between data
intended for a page description
language. Hewlett-Packard Co.
PS 6 PostScript Language (tm)
Postscript - a trademark of Adobe
Systems Incorporated which may be
registered in certain
jurisdictions
IPDS 7 Intelligent Printer Data Stream
Bi-directional print data stream
for documents consisting of data
objects (text, image, graphics,
bar codes), resources (fonts,
overlays) and page, form and
finishing instructions.
Facilitates system level device
control, document tracking and
error recovery throughout the
print process. Pennant Systems,
IBM
draft-ietf-ipp-model-00.txt, expires September 26, 1997 job-originating-
PPDS 8 IBM Personal Printer Data Stream. host
Originally called IBM ASCII, the (name)
name was changed to PPDS when the
Laser Printer was introduced in
1989. Lexmark International, Inc.
EscapeP 9 Epson Corp.
Epson 10
DDIF 11 Digital Document Interchange
Format Digital Equipment Corp.,
Maynard MA
Interpress 12 Xerox Corp.
ISO6429 13 ISO 6429. Control functions for
Coded Character Sets (has ASCII
control characters, plus
additional controls for character
imaging devices.) ISO Standard,
Geneva, Switzerland
LineData 14 line-data: Lines of data as
separate ASCII or EBCDIC records
and containing no control
functions (no CR, LF, HT, FF,
etc.). For use with traditional
line printers. May use CR and/or
LF to delimit lines, instead of
records. See ISO 10175 Document
Printing Application (DPA) ISO
standard, Geneva, Switzerland
MODCA 15 Mixed Object Document Content
Architecture Definitions that
allow the composition,
interchange, and presentation of
final form documents as a
collection of data objects (text,
image, graphics, bar codes),
resources (fonts, overlays) and
page, form and finishing
instructions. Pennant Systems,
IBM
REGIS 16 Remote Graphics Instruction Set,
Digital Equipment Corp., Maynard
MA
SCS 17 SNA Character String Bi-
directional print data stream for
SNA LU-1 mode of communications
IBM
SPDL 18 ISO 10180 Standard Page
Description Language ISO Standard
TEK4014 19 Tektronix Corp.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 user-locale
PDS 20 (type2 keyword)
IGP 21 Printronix Corp.
CodeV 22 Magnum Code-V, Image and printer
control language used to control
impact/dot- matrix printers. QMS,
Inc., Mobile AL
DSCDSE 23 DSC-DSE: Data Stream Compatible
and Emulation Bi-directional print
data stream for non-SNA (DSC) and
SNA LU-3 3270 controller (DSE)
communications IBM
WPS 24 Windows Printing System, Resource
based command/data stream used by
Microsoft At Work Peripherals.
Developed by the Microsoft
Corporation.
LN03 25 Early DEC-PPL3, Digital Equipment
Corp.
CCITT 26
QUIC 27 QUIC (Quality Information Code),
Page Description Language for
laser printers. Included
graphics, printer control
capability and emulation of other
well- known printer . QMS, Inc.
CPAP 28 Common Printer Access Protocol
Digital Equipment Corp
DecPPL 29 Digital ANSI-Compliant Printing
Protocol (DEC-PPL) Digital
Equipment Corp
SimpleText 30 simple-text: character coded data,
including NUL, CR , LF, HT, and FF
control characters. See ISO 10175
Document Printing Application
(DPA) ISO standard, Geneva,
Switzerlan
NPAP 31 Network Printer Alliance Protocol
(NPAP). This protocol has been
superseded by the IEEE 1284.1
TIPSI standard. (ref.
LangTIPSI(49)).
DOC 32 Document Option Commands, Appears
in the data stream between data
intended for a page description .
QMS, Inc
imPress 33 imPRESS, Page description language
originally developed for the
ImageServer line of systems. A
draft-ietf-ipp-model-00.txt, expires September 26, 1997 job-state Man
binary language providing (type1 keyword)
representations for text, simple
graphics (rules, lines, conic
sections), and some large forms
(simple bit-map and CCITT group
3/4 encoded).The language was
intended to be sent over an 8-bit
channel and supported early
document preparation languages
(e.g. TeX and TROFF). QMS, Inc.
Pinwriter 34 24 wire dot matrix printer for
USA, Europe, and Asia except
Japan. More widely used in
Germany, and some Asian countries
than in US. NEC
NPDL 35 Page printer for Japanese market.
NEC
NEC201PL 36 Serial printer language used in
the Japanese market. NEC
Automatic 37 Automatic PDL sensing. Automatic
sensing of the interpreter
language family by the printer
examining the document content.
Which actual interpreter language
families are sensed depends on the
printer implementation.
Pages 38 Page printer Advanced Graphic
Escape Set IBM Japan
LIPS 39 LBP Image Processing System
TIFF 40 Tagged Image File Format (Aldus)
Diagnostic 41 A hex dump of the input to the
interprete
PSPrinter 42 The PostScript Language used for
control (with any PDLs) Adobe
Systems Incorporated
CaPSL 43 Canon Print Systems Language
EXCL 44 Extended Command Language Talaris
Systems Inc
LCDS 45 Line Conditioned Data Stream Xerox
Corporatio
XES 46 Xerox Escape Sequences Xerox
Corporation
PCLXL 47 Printer Control Language.
Extended language features for
printing, and printer control.
Technical reference manual # TBD.
Hewlett-Packard Co.
ART 48 Advanced Rendering Tools (ART).
draft-ietf-ipp-model-00.txt, expires September 26, 1997 job-state-reasons Man
Page Description language (1setOf type2
originally developed for the Laser keyword)
Press printers. Tehnical
reference manual: "ART IV
Reference Manual", No F33M. Fuji
Xerox Co., Ltd.
TIPSI 49 Transport Independent Printer
System Interface (ref. IEEE Std.
1284.1)
Prescribe 50 Page description and printer
control language. It can be
described with ordinary ASCII
characters. Technical reference
manual: "PRESCRIBE II Programming
Manual"
LinePrinte 51 A simple-text character stream
r which supports the control codes
LF, VT, FF and CR plus Centronics
or Dataproducts Vertical Format
Unit (VFU). language is commonly
used on many older model line and
matrix printers.
IDP 52 Imaging Device Protocol Apple
Computer.
XJCL 53 Xerox Corp.
5.2.7 Job Size (job-size) Attributes (Set by Client and job-state-message
Printer) (text)
These attributes form the attribute group called "job- output-device-
size". assigned
(name)
These attribute values all have adornments of either time-since- Man
"total" or "printed" and they indicate the size of a job submission
in various units. A client may set these attributes, but (milliseconds)
not an end-user. The Printer may set these attributes if
the client does not. In both of these cases, the
attribute value has the adornment of "total", which
indicates the client and Printer's best estimate to the
total.
If a value has the adornment of "printed", then the value number-of- Man
shall indicate the current number of octets, impressions intervening-jobs
or media-sheets (depending on the attribute) that have (int)
draft-ietf-ipp-model-00.txt, expires September 26, 1997 job-message-from-
been printed. Only the printer shall be allowed to set a operator
value with the "printed" adornment. (text)
If a value has no adornment, then it implicitly has the time-since- Man
adornment "total". completion
(milliseconds)
The corresponding Printer attributes indicate the range job-k-octets-
of allowed values, but there is no explicit default. If completed
the Job attribute is not specified and the Printer (int)
attribute is specified, the Printer shall either compute
a value for the job attribute or leave it unspecified.
An attribute is accepted if any one of the following
conditions is satisfied: a) the Printer attribute is
unspecified, b) the job attribute is unspecified, c) the
job attribute is within the range specified by the
Printer attribute.
5.2.7.1 job-k-octets (integer(0:2**31 - 1)) June 3, 1997, Expires December 3, 1997
job-impressions-
completed
(int)
This attribute specifies the total size of the job in K job-media-sheets-
octets, i.e., in units of 1024 octets. The value shall completed
be rounded up, so that a job between 1 and 1024 octets (int)
shall be indicated as being 1K, 1025 to 2048 shall be 2,
etc. This attribute is not intended to be a counter as in
the Job Monitoring MIB; it is intended to be useful
routing and scheduling information if known.
5.2.7.1.1 As a Job Attribute 6.3.2.1 job-URI (uri)
This job attribute is set by client on in the Print This attribute contains the URI for the job. The Printer, on receipt of
Request if it is known. It is set by the Printer once a new job, shall generate a URI which identifies the job on the Printer.
the Job object is created if the Printer is able to The Printer, shall return the value of the URI job attribute as part of
calculate this value. the PrintResult in the Print operation. The precise format of a job URI
shall be implementation dependent.
5.2.7.1.2 As a Printer Attribute 6.3.2.2 job-originating-user (name)
This Printer attribute specifies a support range for job This attribute specifies the user name of the person submitting the
sizes. A default value is not applicable for this print job. The Printer shall set this attribute to the most authentic
attribute. name that it can obtain from the protocol over which the operation was
received from the client.
draft-ietf-ipp-model-00.txt, expires September 26, 1997 6.3.2.3 job-originating-host (name)
5.2.7.2 job-impressions (integer(0:2**31 - 1))
This job attribute specifies the total size of the job in This attribute identifies the originating host of the job. The Printer
impressions. This attribute is not intended to be a shall set this attribute to the most authentic host name it can obtain
counter as in the Job Monitoring MIB; it is intended to from the protocol over which the operation was received from the
be useful routing and scheduling information if known. client.
5.2.7.2.1 As a Job Attribute 6.3.2.4 user-locale (type3 keyword)
This job attribute is set by client on in the Print This attribute identifies the locale of the job, i.e, the country,
Request if it is known. It is set by the Printer once language, and coded character set. The Printer sets this attribute to
the Job object is created if the Printer is able to the most authentic value it can obtain from the protocol over which the
calculate this value. Print operation was received from the client.
5.2.7.2.2 As a Printer Attribute The Printer shall use this attribute to determine the locale for
notification messages that it sends.
This Printer attribute specifies a support range for job 6.3.2.5 job-state (type1 keyword)
sizes. A default value is not applicable for this
attribute.
5.2.7.3 job-media-sheets (integer(0:2**31 - 1)) This attribute identifies the current state of the job.
This job attribute specifies the total size of the job in June 3, 1997, Expires December 3, 1997
media-sheets. This attribute is not intended to be a The Printer may provide additional information about each state value by
counter as in the Job Monitoring MIB; it is intended to supplying one or more values of the job's companion "job-state-reasons"
be useful routing and scheduling information if known. attribute depending on implementation. While the job states cannot be
added to without impacting deployed clients that take actions upon
receiving job state values, it is the intent that additional "job-state-
reasons" values can be defined without impacting such deployed clients.
In other words, the "job-state-reasons" attribute is intended to be
extensible.
5.2.7.3.1 As a Job Attribute Standard values are:
This job attribute is set by client on in the Print unknown The job state is not known, or its
Request if it is known. It is set by the Printer once state is indeterminate.
the Job object is created if the Printer is able to pending The job is a candidate to start
calculate this value. processing, but is not yet
processing..
pending- The job is not a candidate for
stopped processing for any number of reasons
and will resume pending as soon as the
reasons are no longer present. The
job's "job-state-reason" attribute
shall indicate why the job is no
longer a candidate for processing.
5.2.7.3.2 As a Printer Attribute June 3, 1997, Expires December 3, 1997
processing Either:
1. the job is using, or is attempting
to use, one or more document
transforms which include (1) purely
software processes that are
interpreting a PDL, and (2) hardware
devices that are interpreting a PDL,
making marks on a medium, and/or
performing finishing, such as stapling
OR