Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2566

Internet Printing Protocol/1.0: Model and Semantics

Pages: 173
Obsoleted by:  2911
Part 1 of 7 – Pages 1 to 22
None   None   Next

ToP   noToC   RFC2566 - Page 1
Network Working Group                                           R. deBry
Request for Comments: 2566                     Utah Valley State College
Category: Experimental                                       T. Hastings
                                                       Xerox Corporation
                                                              R. Herriot
                                                       Xerox Corporation
                                                             S. Isaacson
                                                            Novell, Inc.
                                                               P. Powell
                                                     Astart Technologies
                                                              April 1999


          Internet Printing Protocol/1.0: Model and Semantics

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

IESG Note

   This document defines an Experimental protocol for the Internet
   community.  The IESG expects that a revised version of this protocol
   will be published as Proposed Standard protocol.  The Proposed
   Standard, when published, is expected to change from the protocol
   defined in this memo.  In particular, it is expected that the
   standards-track version of the protocol will incorporate strong
   authentication and privacy features, and that an "ipp:" URL type will
   be defined which supports those security measures.  Other changes to
   the protocol are also possible.  Implementors are warned that future
   versions of this protocol may not interoperate with the version of
   IPP defined in this document, or if they do interoperate, that some
   protocol features may not be available.

   The IESG encourages experimentation with this protocol, especially in
   combination with Transport Layer Security (TLS) [RFC 2246], to help
   determine how TLS may effectively be used as a security layer for
   IPP.
ToP   noToC   RFC2566 - Page 2
Abstract

   This document is one of a set of documents, which together describe
   all aspects of a new Internet Printing Protocol (IPP).  IPP is an
   application level protocol that can be used for distributed printing
   using Internet tools and technologies.  This document describes a
   simplified model consisting of abstract objects, their attributes,
   and their operations that is independent of encoding and transport.
   The model consists of a Printer and a Job object.  A Job optionally
   supports multiple documents.  IPP 1.0 semantics allow end-users and
   operators to query printer capabilities, submit print jobs, inquire
   about the status of print jobs and printers, and cancel print jobs.
   This document also addresses security, internationalization, and
   directory issues.

   The full set of IPP documents includes:

     Design Goals for an Internet Printing Protocol [RFC2567]
     Rationale for the Structure and Model and Protocol for the Internet
        Printing Protocol [RFC2568]
     Internet Printing Protocol/1.0: Model and Semantics (this document)
     Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
     Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
     Mapping between LPD and IPP Protocols [RFC2569]

   The "Design Goals for an Internet Printing Protocol" document takes a
   broad look at distributed printing functionality, and it enumerates
   real-life scenarios that help to clarify the features that need to be
   included in a printing protocol for the Internet.  It identifies
   requirements for three types of users: end users, operators, and
   administrators.  It calls out a subset of end user requirements that
   are satisfied in IPP/1.0.  Operator and administrator requirements
   are out of scope for version 1.0.

   The "Rationale for the Structure and Model and Protocol for the
   Internet Printing Protocol" document describes IPP from a high level
   view, defines a roadmap for the various documents that form the suite
   of IPP specifications, and gives background and rationale for the
   IETF working group's major decisions.

   The "Internet Printing Protocol/1.0: Encoding and Transport" document
   is a formal mapping of the abstract operations and attributes defined
   in the model document onto HTTP/1.1.  It defines the encoding rules
   for a new Internet media type called "application/ipp".

   The "Internet Printing Protocol/1.0: Implementer's Guide" document
   gives insight and advice to implementers of IPP clients and IPP
   objects.  It is intended to help them understand IPP/1.0 and some of
ToP   noToC   RFC2566 - Page 3
   the considerations that may assist them in the design of their client
   and/or IPP object implementations.  For example, a typical order of
   processing requests is given, including error checking.  Motivation
   for some of the specification decisions is also included.

   The "Mapping between LPD and IPP Protocols" document gives some
   advice to implementers of gateways between IPP and LPD (Line Printer
   Daemon) implementations.

Table of Contents

 1. Introduction                                                       8
 1.1   Simplified Printing Model                                       9
 2. IPP Objects                                                       11
 2.1   Printer Object                                                 12
 2.2   Job Object                                                     14
 2.3   Object Relationships                                           14
 2.4   Object Identity                                                15
 3. IPP Operations                                                    18
 3.1   Common Semantics                                               19
  3.1.1   Required Parameters                                         19
  3.1.2   Operation IDs and Request IDs                               20
  3.1.3   Attributes                                                  20
  3.1.4   Character Set and Natural Language Operation Attributes     22
   3.1.4.1  Request Operation Attributes                              22
   3.1.4.2  Response Operation Attributes                             26
  3.1.5   Operation Targets                                           28
  3.1.6   Operation Status Codes and Messages                         29
  3.1.7   Versions                                                    30
  3.1.8   Job Creation Operations                                     32
 3.2   Printer Operations                                             34
  3.2.1   Print-Job Operation                                         34
   3.2.1.1  Print-Job Request                                         34
   3.2.1.2  Print-Job Response                                        38
  3.2.2   Print-URI Operation                                         41
  3.2.3   Validate-Job Operation                                      42
  3.2.4   Create-Job Operation                                        42
  3.2.5   Get-Printer-Attributes Operation                            43
   3.2.5.1  Get-Printer-Attributes Request                            44
   3.2.5.2  Get-Printer-Attributes Response                           46
  3.2.6   Get-Jobs Operation                                          47
   3.2.6.1  Get-Jobs Request                                          47
   3.2.6.2  Get-Jobs Response                                         49
 3.3   Job Operations                                                 50
  3.3.1   Send-Document Operation                                     50
   3.3.1.1  Send-Document Request                                     51
   3.3.1.2  Send-Document Response                                    53
  3.3.2   Send-URI Operation                                          54
ToP   noToC   RFC2566 - Page 4
  3.3.3   Cancel-Job Operation                                        54
   3.3.3.1  Cancel-Job Request                                        54
   3.3.3.2  Cancel-Job Response                                       55
  3.3.4   Get-Job-Attributes Operation                                56
   3.3.4.1  Get-Job-Attributes Request                                57
   3.3.4.2  Get-Job-Attributes Response                               57
 4. Object Attributes                                                 58
 4.1   Attribute Syntaxes                                             59
  4.1.1   'text'                                                      60
   4.1.1.1  'textWithoutLanguage'                                     61
   4.1.1.2  'textWithLanguage'                                        61
  4.1.2   'name'                                                      62
   4.1.2.1  'nameWithoutLanguage'                                     62
   4.1.2.2  'nameWithLanguage'                                        63
   4.1.2.3  Matching 'name' attribute values                          63
  4.1.3   'keyword'                                                   64
  4.1.4   'enum'                                                      65
  4.1.5   'uri'                                                       65
  4.1.6   'uriScheme'                                                 65
  4.1.7   'charset'                                                   66
  4.1.8   'naturalLanguage'                                           67
  4.1.9   'mimeMediaType'                                             67
  4.1.10  'octetString'                                               69
  4.1.11  'boolean'                                                   69
  4.1.12  'integer'                                                   69
  4.1.13  'rangeOfInteger'                                            69
  4.1.14  'dateTime'                                                  69
  4.1.15  'resolution'                                                69
  4.1.16  '1setOf  X'                                                 70
 4.2   Job Template Attributes                                        70
  4.2.1   job-priority (integer(1:100))                               74
  4.2.2   job-hold-until (type3 keyword | name (MAX))                 75
  4.2.3   job-sheets (type3 keyword | name(MAX))                      75
  4.2.4   multiple-document-handling (type2 keyword)                  76
  4.2.5   copies (integer(1:MAX))                                     77
  4.2.6   finishings (1setOf type2 enum)                              78
  4.2.7   page-ranges (1setOf rangeOfInteger (1:MAX))                 79
  4.2.8   sides (type2 keyword)                                       80
  4.2.9   number-up (integer(1:MAX))                                  80
  4.2.10  orientation-requested (type2 enum)                          81
  4.2.11  media (type3 keyword | name(MAX))                           82
  4.2.12  printer-resolution (resolution)                             83
  4.2.13  print-quality (type2 enum)                                  83
 4.3   Job Description Attributes                                     84
  4.3.1   job-uri (uri)                                               85
  4.3.2   job-id (integer(1:MAX))                                     85
  4.3.3   job-printer-uri (uri)                                       86
  4.3.4   job-more-info (uri)                                         86
ToP   noToC   RFC2566 - Page 5
  4.3.5   job-name (name(MAX))                                        86
  4.3.6   job-originating-user-name (name(MAX))                       86
  4.3.7   job-state (type1 enum)                                      87
  4.3.8   job-state-reasons (1setOf  type2 keyword)                   90
  4.3.9   job-state-message (text(MAX))                               92
  4.3.10  number-of-documents (integer(0:MAX))                        93
  4.3.11  output-device-assigned (name(127))                          93
  4.3.12  time-at-creation (integer(0:MAX))                           93
  4.3.13  time-at-processing (integer(0:MAX))                         93
  4.3.14  time-at-completed (integer(0:MAX))                          94
  4.3.15  number-of-intervening-jobs (integer(0:MAX))                 94
  4.3.16  job-message-from-operator (text(127))                       94
  4.3.17  job-k-octets (integer(0:MAX))                               94
  4.3.18  job-impressions (integer(0:MAX))                            95
  4.3.19  job-media-sheets (integer(0:MAX))                           95
  4.3.20  job-k-octets-processed (integer(0:MAX))                     96
  4.3.21  job-impressions-completed (integer(0:MAX))                  96
  4.3.22  job-media-sheets-completed (integer(0:MAX))                 96
  4.3.23  attributes-charset (charset)                                97
  4.3.24  attributes-natural-language (naturalLanguage)               97
 4.4   Printer Description Attributes                                 97
  4.4.1   printer-uri-supported (1setOf uri)                          99
  4.4.2   uri-security-supported (1setOf type2 keyword)              100
  4.4.3   printer-name (name(127))                                   101
  4.4.4   printer-location (text(127))                               101
  4.4.5   printer-info (text(127))                                   101
  4.4.6   printer-more-info (uri)                                    101
  4.4.7   printer-driver-installer (uri)                             102
  4.4.8   printer-make-and-model (text(127))                         102
  4.4.9   printer-more-info-manufacturer (uri)                       102
  4.4.10  printer-state (type1 enum)                                 102
  4.4.11  printer-state-reasons (1setOf type2 keyword)               103
  4.4.12  printer-state-message (text(MAX))                          106
  4.4.13  operations-supported (1setOf type2 enum)                   106
  4.4.14  charset-configured (charset)                               107
  4.4.15  charset-supported (1setOf charset)                         107
  4.4.16  natural-language-configured (naturalLanguage)              107
  4.4.17  generated-natural-language-supported(1setOf naturalLanguage 108
  4.4.18  document-format-default (mimeMediaType)                    108
  4.4.19  document-format-supported (1setOf mimeMediaType)           108
  4.4.20  printer-is-accepting-jobs (boolean)                        109
  4.4.21  queued-job-count (integer(0:MAX))                          109
  4.4.22  printer-message-from-operator (text(127))                  109
  4.4.23  color-supported (boolean)                                  109
  4.4.24  reference-uri-schemes-supported (1setOf uriScheme)         109
  4.4.25  pdl-override-supported (type2 keyword)                     110
  4.4.26  printer-up-time (integer(1:MAX))                           110
  4.4.27  printer-current-time (dateTime)                            111
ToP   noToC   RFC2566 - Page 6
  4.4.28  multiple-operation-time-out (integer(1:MAX))               111
  4.4.29  compression-supported (1setOf type3 keyword)               111
  4.4.30  job-k-octets-supported (rangeOfInteger(0:MAX))             112
  4.4.31  job-impressions-supported (rangeOfInteger(0:MAX))          112
  4.4.32  job-media-sheets-supported (rangeOfInteger(0:MAX))         112
 5. Conformance                                                      112
 5.1   Client Conformance Requirements                               112
 5.2   IPP Object Conformance Requirements                           113
  5.2.1   Objects                                                    113
  5.2.2   Operations                                                 113
  5.2.3   IPP Object Attributes                                      114
  5.2.4   Extensions                                                 114
  5.2.5   Attribute Syntaxes                                         115
 5.3   Charset and Natural Language Requirements                     115
 5.4   Security Conformance Requirements                             115
 6. IANA Considerations (registered and private extensions)          116
 6.1   Typed 'keyword' and 'enum' Extensions                         116
 6.2   Attribute Extensibility                                       119
 6.3   Attribute Syntax Extensibility                                119
 6.4   Operation Extensibility                                       120
 6.5   Attribute Groups                                              120
 6.6   Status Code Extensibility                                     120
 6.7   Registration of MIME types/sub-types for document-formats     121
 6.8   Registration of charsets for use in 'charset' attribute values 121
 7. Internationalization Considerations                              121
 8. Security Considerations                                          125
 8.1   Security Scenarios                                            126
  8.1.1   Client and Server in the Same Security Domain              126
  8.1.2   Client and Server in Different Security Domains            126
  8.1.3   Print by Reference                                         127
 8.2   URIs for SSL3 and non-SSL3 Access                             127
 8.3   The "requesting-user-name" (name(MAX)) Operation Attribute    127
 8.4   Restricted Queries                                            129
 8.5   Queries on jobs submitted using non-IPP protocols             129
 8.6   IPP Security Application Profile for SSL3                     130
 9. References                                                       131
 10. Authors' Addresses                                              134
 11. Formats for IPP Registration Proposals                          136
 11.1  Type2 keyword attribute values registration                   136
 11.2  Type3 keyword attribute values registration                   137
 11.3  Type2 enum attribute values registration                      137
 11.4  Type3 enum attribute values registration                      137
 11.5  Attribute registration                                        138
 11.6  Attribute Syntax registration                                 138
 11.7  Operation registration                                        139
 11.8  Attribute Group registration                                  139
 11.9  Status code registration                                      139
 12. APPENDIX A: Terminology                                         141
ToP   noToC   RFC2566 - Page 7
 12.1  Conformance Terminology                                       141
  12.1.1  NEED NOT                                                   141
 12.2  Model Terminology                                             141
  12.2.1  Keyword                                                    141
  12.2.2  Attributes                                                 141
   12.2.2.1 Attribute Name                                           141
   12.2.2.2 Attribute Group Name                                     142
   12.2.2.3 Attribute Value                                          142
   12.2.2.4 Attribute Syntax                                         142
  12.2.3  Supports                                                   142
  12.2.4  print-stream page                                          144
  12.2.5  impression                                                 144
 13. APPENDIX B:  Status Codes and Suggested Status Code Messages    145
 13.1  Status Codes                                                  146
  13.1.1  Informational                                              146
  13.1.2  Successful Status Codes                                    146
   13.1.2.1 successful-ok (0x0000)                                   146
   13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001) 146
   13.1.2.3 successful-ok-conflicting-attributes (0x0002)            147
  13.1.3  Redirection Status Codes                                   147
  13.1.4  Client Error Status Codes                                  147
   13.1.4.1 client-error-bad-request (0x0400)                        147
   13.1.4.2 client-error-forbidden (0x0401)                          147
   13.1.4.3 client-error-not-authenticated (0x0402)                  148
   13.1.4.4 client-error-not-authorized (0x0403)                     148
   13.1.4.5 client-error-not-possible (0x0404)                       148
   13.1.4.6 client-error-timeout (0x0405)                            148
   13.1.4.7 client-error-not-found (0x0406)                          149
   13.1.4.8 client-error-gone (0x0407)                               149
   13.1.4.9 client-error-request-entity-too-large (0x0408)           149
   13.1.4.10 client-error-request-value-too-long (0x0409)            150
   13.1.4.11 client-error-document-format-not-supported (0x040A)     150
   13.1.4.12 client-error-attributes-or-values-not-supported (0x040B) 150
   13.1.4.13 client-error-uri-scheme-not-supported (0x040C)          151
   13.1.4.14 client-error-charset-not-supported (0x040D)             151
   13.1.4.15 client-error-conflicting-attributes (0x040E)            151
  13.1.5  Server Error Status Codes                                  151
   13.1.5.1 server-error-internal-error (0x0500)                     151
   13.1.5.2 server-error-operation-not-supported (0x0501)            152
   13.1.5.3 server-error-service-unavailable (0x0502)                152
   13.1.5.4 server-error-version-not-supported (0x0503)              152
   13.1.5.5 server-error-device-error (0x0504)                       152
   13.1.5.6 server-error-temporary-error (0x0505)                    153
   13.1.5.7 server-error-not-accepting-jobs (0x0506)                 153
   13.1.5.8 server-error-busy (0x0507)                               153
   13.1.5.9 server-error-job-canceled (0x0508)                       153
 13.2  Status Codes for IPP Operations                               153
 14. APPENDIX C:  "media" keyword values                             155
ToP   noToC   RFC2566 - Page 8
 15. APPENDIX D: Processing IPP Attributes                           160
 15.1  Fidelity                                                      160
 15.2  Page Description Language (PDL) Override                      161
 15.3  Using Job Template Attributes During Document Processing.     163
 16. APPENDIX E: Generic Directory Schema                            166
 17. APPENDIX F: Change History for the Model and Semantics document 168
 18. FULL COPYRIGHT STATEMENT                                        173

1. Introduction

   The Internet Printing Protocol (IPP) is an application level protocol
   that can be used for distributed printing using Internet tools and
   technologies.  IPP version 1.0 (IPP/1.0) focuses only on end user
   functionality.  This document is just one of a suite of documents
   that fully define IPP.  The full set of IPP documents includes:

     Design Goals for an Internet Printing Protocol [RFC2567]
     Rationale for the Structure and Model and Protocol for the Internet
        Printing Protocol [RFC2568]
     Internet Printing Protocol/1.0: Model and Semantics (this document)
     Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
     Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
     Mapping between LPD and IPP Protocols [RFC2569]

   Anyone reading these documents for the first time is strongly
   encouraged to read the IPP documents in the above order.

   This document is laid out as follows:

     - The rest of Section 1 is an introduction to the IPP simplified
       model for distributed printing.
     - Section 2 introduces the object types covered in the model with
       their basic behaviors, attributes, and interactions.
     - Section 3 defines the operations included in IPP/1.0.  IPP
       operations are synchronous, therefore, for each operation, there
       is a both request and a response.
     - Section 4 defines the attributes (and their syntaxes) that are
       used in the model.
     - Sections 5 - 6 summarizes the implementation conformance
       requirements for objects that support the protocol and IANA
       considerations, respectively.
     - Sections 7 - 11 cover the Internationalization and Security
       considerations as well as References, Author contact information,
       and Formats for Registration Proposals.
     - Sections 12 - 14 are appendices that cover Terminology, Status
       Codes and Messages, and "media" keyword values.
ToP   noToC   RFC2566 - Page 9
             Note: This document uses terms such as "attributes",
             "keywords", and "support".  These terms have special
             meaning and are defined in the model terminology section
             12.2.  Capitalized terms, such as MUST, MUST NOT, REQUIRED,
             SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have
             special meaning relating to conformance.  These terms are
             defined in section 12.1 on conformance terminology, most of
             which is taken from RFC 2119 [RFC2119].

     - Section 15 is an appendix that helps to clarify the effects of
       interactions between related attributes and their values.
     - Section 16 is an appendix that enumerates the subset of Printer
       attributes that form a generic directory schema.  These
       attributes are useful when registering a Printer so that a
       client can find the Printer not just by name, but by filtered
       searches as well.
     - Section 17 is an appendix that provides a Change History
       summarizing the clarification and changes that might affect an
       implementation since the June 30, 1998 draft.

1.1 Simplified Printing Model

   In order to achieve its goal of realizing a workable printing
   protocol for the Internet, the Internet Printing Protocol (IPP) is
   based on a simplified printing model that abstracts the many
   components of real world printing solutions.  The Internet is a
   distributed computing environment where requesters of print services
   (clients, applications, printer drivers, etc.) cooperate and interact
   with print service providers.  This model and semantics document
   describes a simple, abstract model for IPP even though the underlying
   configurations may be complex "n-tier" client/server systems.  An
   important simplifying step in the IPP model is to expose only the key
   objects and interfaces required for printing.  The model described in
   this model document does not include features, interfaces, and
   relationships that are beyond the scope of the first version of IPP
   (IPP/1.0).  IPP/1.0 incorporates many of the relevant ideas and
   lessons learned from other specification and development efforts
   [HTPP] [ISO10175] [LDPA] [P1387.4] [PSIS] [RFC1179] [SWP].  IPP is
   heavily influenced by the printing model introduced in the Document
   Printing Application (DPA) [ISO10175] standard.  Although DPA
   specifies both end user and administrative features, IPP version 1.0
   (IPP/1.0) focuses only on end user functionality.

   The IPP/1.0 model encapsulates the important components of
   distributed printing into two object types:

     - Printer (Section 2.1)
     - Job (Section 2.2)
ToP   noToC   RFC2566 - Page 10
   Each object type has an associated set of operations (see section 3)
   and attributes (see section 4).

   It is important, however, to understand that in real system
   implementations (which lie underneath the abstracted IPP/1.0 model),
   there are other components of a print service which are not
   explicitly defined in the IPP/1.0 model. The following figure
   illustrates where IPP/1.0 fits with respect to these other
   components.

                                +--------------+
                                |  Application |
                      o         +. . . . . . . |
                     \|/        |   Spooler    |
                     / \        +. . . . . . . |   +---------+
                   End-User     | Print Driver |---|  File   |
         +-----------+ +-----+  +------+-------+   +----+----+
         |  Browser  | | GUI |         |                |
         +-----+-----+ +--+--+         |                |
               |          |            |                |
               |      +---+------------+---+            |
   N   D   S   |      |      IPP Client    |------------+
   O   I   E   |      +---------+----------+
   T   R   C   |                |
   I   E   U   |
   F   C   R   -------------- Transport ------------------
   I   T   I
   C   O   T                    |         --+
   A   R   Y           +--------+--------+  |
   T   Y               |    IPP Server   |  |
   I                   +--------+--------+  |
   O                            |           |
   N                   +-----------------+  | IPP Printer
                       |  Print Service  |  |
                       +-----------------+  |
                                |         --+
                       +-----------------+
                       | Output Device(s)|
                       +-----------------+

   An IPP Printer object encapsulates the functions normally associated
   with physical output devices along with the spooling, scheduling and
   multiple device management functions often associated with a print
   server. Printer objects are optionally registered as entries in a
   directory where end users find and select them based on some sort of
   filtered and context based searching mechanism (see section 16).  The
   directory is used to store relatively static information about the
   Printer, allowing end users to search for and find Printers that
ToP   noToC   RFC2566 - Page 11
   match their search criteria, for example: name, context, printer
   capabilities, etc.  The more dynamic information, such as state,
   currently loaded and ready media, number of jobs at the Printer,
   errors, warnings, and so forth, is directly associated with the
   Printer object itself rather than with the entry in the directory
   which only represents the Printer object.

   IPP clients implement the IPP protocol on the client side and give
   end users (or programs running on behalf of end users) the ability to
   query Printer objects and submit and manage print jobs.  An IPP
   server is just that part of the Printer object that implements the
   server-side protocol.  The rest of the Printer object implements (or
   gateways into) the application semantics of the print service itself.
   The Printer objects may be embedded in an output device or may be
   implemented on a host on the network that communicates with an output
   device.

   When a job is submitted to the Printer object and the Printer object
   validates the attributes in the submission request, the Printer
   object creates a new Job object.  The end user then interacts with
   this new Job object to query its status and monitor the progress of
   the job.  End users may also cancel the print job by using the Job
   object's Cancel-Job operation.  The notification service is out of
   scope for IPP/1.0, but using such a notification service, the end
   user is able to register for and receive Printer specific and Job
   specific events.  An end user can query the status of Printer objects
   and can follow the progress of Job objects by polling using the Get-
   Printer-Attributes, Get-Jobs, and Get-Job-Attributes operations.

2. IPP Objects

   The IPP/1.0 model introduces objects of type Printer and Job.  Each
   type of object models relevant aspects of a real-world entity such as
   a real printer or real print job.  Each object type is defined as a
   set of possible attributes that may be supported by instances of that
   object type.  For each object (instance), the actual set of supported
   attributes and values describe a specific implementation.  The
   object's attributes and values describe its state, capabilities,
   realizable features, job processing functions, and default behaviors
   and characteristics.  For example, the Printer object type is defined
   as a set of attributes that each Printer object potentially supports.
   In the same manner, the Job object type is defined as a set of
   attributes that are potentially supported by each Job object.

   Each attribute included in the set of attributes defining an object
   type is labeled as:
ToP   noToC   RFC2566 - Page 12
     - "REQUIRED": each object MUST support the attribute.
     - "OPTIONAL": each object MAY support the attribute.

   There is no such similar labeling of attribute values.  However, if
   an implementation supports an attribute, it MUST support at least one
   of the possible values for that attribute.

2.1 Printer Object

   The major component of the IPP/1.0 model is the Printer object.  A
   Printer object implements the server-side of the IPP/1.0 protocol.
   Using the protocol, end users may query the attributes of the Printer
   object and submit print jobs to the Printer object.  The actual
   implementation components behind the Printer abstraction may take on
   different forms and different configurations.  However, the model
   abstraction allows the details of the configuration of real
   components to remain opaque to the end user.  Section 3 describes
   each of the Printer operations in detail.

   The capabilities and state of a Printer object are described by its
   attributes.  Printer attributes are divided into two groups:

     - "job-template" attributes: These attributes describe supported
       job processing capabilities and defaults for the Printer object.
       (See section 4.2)
     - "printer-description" attributes: These attributes describe the
       Printer object's identification, state, location, references to
       other sources of information about the Printer object, etc. (see
       section 4.4)

   Since a Printer object is an abstraction of a generic document output
   device and print service provider, a Printer object could be used to
   represent any real or virtual device with semantics consistent with
   the Printer object, such as a fax device, an imager, or even a CD
   writer.

   Some examples of configurations supporting a Printer object include:

     1) An output device with no spooling capabilities
     2) An output device with a built-in spooler
     3) A print server supporting IPP with one or more associated output
        devices
        3a) The associated output devices may or may not be capable of
          spooling jobs
        3b) The associated output devices may or may not support IPP
ToP   noToC   RFC2566 - Page 13
   The following figures show some examples of how Printer objects can
   be realized on top of various distributed printing configurations.
   The embedded case below represents configurations 1 and 2. The hosted
   and fan-out figures below represent configurations 3a and 3b.

   Legend:

   ##### indicates a Printer object which is
         either embedded in an output device or is
         hosted in a server.  The Printer object
         might or might not be capable of queuing/spooling.

   any   indicates any network protocol or direct
         connect, including IPP


   embedded printer:
                                             output device
                                           +---------------+
    O   +--------+                         |  ###########  |
   /|\  | client |------------IPP------------># Printer #  |
   / \  +--------+                         |  # Object  #  |
                                           |  ###########  |
                                           +---------------+


   hosted printer:
                                           +---------------+
    O   +--------+        ###########      |               |
   /|\  | client |--IPP--># Printer #-any->| output device |
   / \  +--------+        # Object  #      |               |
                          ###########      +---------------+



                                            +---------------+
   fan out:                                 |               |
                                        +-->| output device |
                                    any/    |               |
    O   +--------+      ###########   /     +---------------+
   /|\  | client |-IPP-># Printer #--*
   / \  +--------+      # Object  #   \     +---------------+
                        ########### any\    |               |
                                        +-->| output device |
                                            |               |
                                            +---------------+
ToP   noToC   RFC2566 - Page 14
2.2 Job Object

   A Job object is used to model a print job.  A Job object contains
   documents.  The information required to create a Job object is sent
   in a create request from the end user via an IPP Client to the
   Printer object.  The Printer object validates the create request, and
   if the Printer object accepts the request, the Printer object creates
   the new Job object.  Section 3 describes each of the Job operations
   in detail.

   The characteristics and state of a Job object are described by its
   attributes.  Job attributes are grouped into two groups as follows:

     - "job-template" attributes: These attributes can be supplied by
       the client or end user and include job processing instructions
       which are intended to override any Printer object defaults and/or
       instructions embedded within the document data. (See section 4.2)
     - "job-description" attributes: These attributes describe the Job
       object's identification, state, size, etc. The client supplies
       some of these attributes, and the Printer object generates others.
       (See section 4.3)

   An implementation MUST support at least one document per Job object.
   An implementation MAY support multiple documents per Job object.  A
   document is either:

     - a stream of document data in a format supported by the Printer
       object (typically a Page Description Language - PDL), or
     - a reference to such a stream of document data

   In IPP/1.0, a document is not modeled as an IPP object, therefore it
   has no object identifier or associated attributes.  All job
   processing instructions are modeled as Job object attributes.  These
   attributes are called Job Template attributes and they apply equally
   to all documents within a Job object.

2.3 Object Relationships

   IPP objects have relationships that are maintained persistently along
   with the persistent storage of the object attributes.

   A Printer object can represent either one or more physical output
   devices or a logical device which "processes" jobs but never actually
   uses a physical output device to put marks on paper.  Examples of
   logical devices include a Web page publisher or a gateway into an
   online document archive or repository.  A Printer object contains
   zero or more Job objects.
ToP   noToC   RFC2566 - Page 15
   A Job object is contained by exactly one Printer object, however the
   identical document data associated with a Job object could be sent to
   either the same or a different Printer object.  In this case, a
   second Job object would be created which would be almost identical to
   the first Job object, however it would have new (different) Job
   object identifiers (see section 2.4).

   A Job object is either empty (before any documents have been added)
   or contains one or more documents.  If the contained document is a
   stream of document data, that stream can be contained in only one
   document.  However, there can be identical copies of the stream in
   other documents in the same or different Job objects.  If the
   contained document is just a reference to a stream of document data,
   other documents (in the same or different Job object(s)) may contain
   the same reference.

2.4 Object Identity

   All Printer and Job objects are identified by a Uniform Resource
   Identifier (URI) [RFC2396] so that they can be persistently and
   unambiguously referenced.  The notion of a URI is a useful concept,
   however, until the notion of URI is more stable (i.e., defined more
   completely and deployed more widely), it is expected that the URIs
   used for IPP objects will actually be URLs [RFC2396].  Since every
   URL is a specialized form of a URI, even though the more generic term
   URI is used throughout the rest of this document, its usage is
   intended to cover the more specific notion of URL as well.

   An administrator configures Printer objects to either support or not
   support authentication and/or message privacy using SSL3 [SSL] (the
   mechanism for security configuration is outside the scope of
   IPP/1.0).  In some situations, both types of connections (both
   authenticated and unauthenticated) can be established using a single
   communication channel that has some sort of negotiation mechanism.
   In other situations, multiple communication channels are used, one
   for each type of security configuration.  Section 8 provides a full
   description of all security considerations and configurations.

   If a Printer object supports more than one communication channel,
   some or all of those channels might support and/or require different
   security mechanisms.  In such cases, an administrator could expose
   the simultaneous support for these multiple communication channels as
   multiple URIs for a single Printer object where each URI represents
   one of the communication channels to the Printer object. To support
   this flexibility, the IPP Printer object type defines a multi-valued
   identification attribute called the "printer-uri-supported"
   attribute.  It MUST contain at least one URI.  It MAY contain more
   than one URI.  That is, every Printer object will have at least one
ToP   noToC   RFC2566 - Page 16
   URI that identifies at least one communication channel to the Printer
   object, but it may have more than one URI where each URI identifies a
   different communication channel to the Printer object.  The
   "printer-uri-supported" attribute has a companion attribute, the
   "uri-security-supported" attribute, that has the same cardinality as
   "printer-uri-supported".  The purpose of the "uri-security-supported"
   attribute is to indicate the security mechanisms (if any) used for
   each URI listed in "printer-uri-supported".  These two attributes are
   fully described in sections 4.4.1 and 4.4.2.

   When a job is submitted to the Printer object via a create request,
   the client supplies only a single Printer object URI.  The client
   supplied Printer object URI MUST be one of the values in the
   "printer-uri-supported" Printer attribute.

   Note:  IPP/1.0 does not specify how the client obtains the client
   supplied URI, but it is RECOMMENDED that a Printer object be
   registered as an entry in a directory service.  End-users and
   programs can then interrogate the directory searching for Printers.
   Section 16 defines a generic schema for Printer object entries in the
   directory service and describes how the entry acts as a bridge to the
   actual IPP Printer object.  The entry in the directory that
   represents the IPP Printer object includes the possibly many URIs for
   that Printer object as values in one its attributes.

   When a client submits a create request to the Printer object, the
   Printer object validates the request and creates a new Job object.
   The Printer object assigns the new Job object a URI which is stored
   in the "job-uri" Job attribute.  This URI is then used by clients as
   the target for subsequent Job operations.  The Printer object
   generates a Job URI based on its configured security policy and the
   URI used by the client in the create request.

   For example, consider a Printer object that supports both a
   communication channel secured by the use of SSL3 (using HTTP over
   SSL3 with an "https" schemed URI) and another open communication
   channel that is not secured with SSL3 (using a simple "http" schemed
   URI).  If a client were to submit a job using the secure URI, the
   Printer object would assign the new Job object a secure URI as well.
   If a client were to submit a job using the open-channel URI, the
   Printer would assign the new Job object an open-channel URI.

   In addition, the Printer object also populates the Job object's
   "job-printer-uri" attribute.  This is a reference back to the Printer
   object that created the Job object.  If a client only has access to a
   Job object's "job-uri" identifier, the client can query the Job's
   "job-printer-uri" attribute in order to determine which Printer
   object created the Job object.  If the Printer object supports more
ToP   noToC   RFC2566 - Page 17
   than one URI, the Printer object picks the one URI supplied by the
   client when creating the job to build the value for and to populate
   the Job's "job-printer-uri" attribute.

   Allowing Job objects to have URIs allows for flexibility and
   scalability.  For example, in some implementations, the Printer
   object might create Jobs that are processed in the same local
   environment as the Printer object itself.  In this case, the Job URI
   might just be a composition of the Printer's URI and some unique
   component for the Job object, such as the unique 32-bit positive
   integer mentioned later in this paragraph.  In other implementations,
   the Printer object might be a central clearing-house for validating
   all Job object creation requests, but the Job object itself might be
   created in some environment that is remote from the Printer object.
   In this case, the Job object's URI may have no physical-location
   relationship at all to the Printer object's URI.  Again, the fact
   that Job objects have URIs allows for flexibility and scalability,
   however, many existing printing systems have local models or
   interface constraints that force print jobs to be identified using
   only a 32-bit positive integer rather than an independent URI.  This
   numeric Job ID is only unique within the context of the Printer
   object to which the create request was originally submitted.
   Therefore, in order to allow both types of client access to IPP Job
   objects (either by Job URI or by numeric Job ID), when the Printer
   object successfully processes a create request and creates a new Job
   object, the Printer object MUST generate both a Job URI and a Job ID.
   The Job ID (stored in the "job-id" attribute) only has meaning in the
   context of the Printer object to which the create request was
   originally submitted. This requirement to support both Job URIs and
   Job IDs allows all types of clients to access Printer objects and Job
   objects no matter the local constraints imposed on the client
   implementation.

   In addition to identifiers, Printer objects and Job objects have
   names ("printer-name" and "job-name").  An object name NEED NOT be
   unique across all instances of all objects. A Printer object's name
   is chosen and set by an administrator through some mechanism outside
   the scope of IPP/1.0.  A Job object's name is optionally chosen and
   supplied by the IPP client submitting the job.  If the client does
   not supply a Job object name, the Printer object generates a name for
   the new Job object.  In all cases, the name only has local meaning.

   To summarize:

     - Each Printer object is identified with one or more URIs.  The
       Printer's "printer-uri-supported" attribute contains the URI(s).
ToP   noToC   RFC2566 - Page 18
     - The Printer object's "uri-security-supported" attribute
       identifies the communication channel security protocols that may
       or may not have been configured for the various Printer object
       URIs (e.g., 'ssl3' or 'none').
     - Each Job object is identified with a Job URI.  The Job's "job-uri"
       attribute contains the URI.
     - Each Job object is also identified with Job ID which is a 32-bit,
       positive integer.  The Job's "job-id" attribute contains the Job
       ID.  The Job ID is only unique within the context of the Printer
       object  which created the Job object.
     - Each Job object has a "job-printer-uri" attribute which contains
       the URI of the Printer object that was used to create the Job
       object.  This attribute is used to determine the Printer object
       that created a Job object when given only the URI for the Job
       object.  This linkage is necessary to determine the languages,
       charsets, and operations which are supported on that Job (the
       basis for such support comes from the creating Printer object).
     - Each Printer object has a name (which is not necessarily unique).
       The administrator chooses and sets this name through some
       mechanism outside the scope of IPP/1.0 itself.  The Printer
       object's "printer-name" attribute contains the name.
     - Each Job object has a name (which is not necessarily unique).  The
       client optionally supplies this name in the create request.  If
       the client does not supply this name, the Printer object generates
       a name for the Job object. The Job object's "job-name" attribute
       contains the name.

3. IPP Operations

   IPP objects support operations.  An operation consists of a request
   and a response.  When a client communicates with an IPP object, the
   client issues an operation request to the URI for that object.
   Operation requests and responses have parameters that identify the
   operation.  Operations also have attributes that affect the run-time
   characteristics of the operation (the intended target, localization
   information, etc.).  These operation-specific attributes are called
   operation attributes (as compared to object attributes such as
   Printer object attributes or Job object attributes).  Each request
   carries along with it any operation attributes, object attributes,
   and/or document data required to perform the operation.  Each request
   requires a response from the object.  Each response indicates success
   or failure of the operation with a status code as a response
   parameter.  The response contains any operation attributes, object
   attributes, and/or status messages generated during the execution of
   the operation request.
ToP   noToC   RFC2566 - Page 19
   This section describes the semantics of the IPP operations, both
   requests and responses, in terms of the parameters, attributes, and
   other data associated with each operation.

   The IPP/1.0 Printer operations are:

     Print-Job (section 3.2.1)
     Print-URI (section 3.2.2)
     Validate-Job (section 3.2.3)
     Create-Job (section 3.2.4)
     Get-Printer-Attributes (section 3.2.5)
     Get-Jobs (section 3.2.6)

   The Job operations are:

     Send-Document (section 3.3.1)
     Send-URI (section 3.3.2)
     Cancel-Job (section 3.3.3)
     Get-Job-Attributes (section 3.3.4)

   The Send-Document and Send-URI Job operations are used to add a new
   document to an existing multi-document Job object created using the
   Create-Job operation.

3.1 Common Semantics

   All IPP operations require some common parameters and operation
   attributes.  These common elements and their semantic characteristics
   are defined and described in more detail in the following sections.

3.1.1 Required Parameters

   Every operation request contains the following REQUIRED parameters:

     - a "version-number",
     - an "operation-id",
     - a "request-id", and
     - the attributes that are REQUIRED for that type of request.

   Every operation response contains the following REQUIRED parameters:

     - a "version-number",
     - a "status-code",
     - the "request-id" that was supplied in the corresponding request,
        and
     - the attributes that are REQUIRED for that type of response.
ToP   noToC   RFC2566 - Page 20
   The encoding and transport document [RFC2565] defines special rules
   for the encoding of these parameters.  All other operation elements
   are represented using the more generic encoding rules for attributes
   and groups of attributes.

3.1.2 Operation IDs and Request IDs

   Each IPP operation request includes an identifying "operation-id"
   value.  Valid values are defined in the "operations-supported"
   Printer attribute section (see section 4.4.13).  The client specifies
   which operation is being requested by supplying the correct
   "operation-id" value.

   In addition, every invocation of an operation is identified by a
   "request-id" value. For each request, the client chooses the
   "request-id" which MUST be an integer (possibly unique depending on
   client requirements) in the range from 1 to 2**31 - 1 (inclusive).
   This "request-id" allows clients to manage multiple outstanding
   requests. The receiving IPP object copies all 32-bits of the client-
   supplied "request-id" attribute into the response so that the client
   can match the response with the correct outstanding request, even if
   the "request-id" is out of range.  If the request is terminated
   before the complete "request-id" is received, the IPP object rejects
   the request and returns a response with a "request-id" of 0.

   Note: In some cases, the transport protocol underneath IPP might be a
   connection oriented protocol that would make it impossible for a
   client to receive responses in any order other than the order in
   which the corresponding requests were sent.  In such cases, the
   "request-id" attribute would not be essential for correct protocol
   operation.  However, in other mappings, the operation responses can
   come back in any order.  In these cases, the "request-id" would be
   essential.

3.1.3 Attributes

   Operation requests and responses are both composed of groups of
   attributes and/or document data.  The attributes groups are:

     - Operation Attributes: These attributes are passed in the
       operation and affect the IPP object's behavior while processing
       the operation request and may affect other attributes or groups
       of attributes.  Some operation attributes describe the document
       data associated with the print job and are associated with new
       Job objects, however most operation attributes do not persist
       beyond the life of the operation.  The description of each
       operation attribute includes conformance statements indicating
       which operation attributes are REQUIRED and which are OPTIONAL
ToP   noToC   RFC2566 - Page 21
       for an IPP object to support and which attributes a client MUST
       supply in a request and an IPP object MUST supply in a response.
     - Job Template Attributes: These attributes affect the processing
       of a job.  A client OPTIONALLY supplies Job Template Attributes
       in a create request, and the receiving object MUST be prepared to
       receive all supported attributes.  The Job object can later be
       queried to find out what Job Template attributes were originally
       requested in the create request, and such attributes are returned
       in the response as Job Object Attributes.  The Printer object can
       be queried about its Job Template attributes to find out what
       type of job processing capabilities are supported and/or what the
       default job processing behaviors are, though such attributes are
       returned in the response as Printer Object Attributes.  The
       "ipp-attribute-fidelity" operation attribute affects processing
       of all client-supplied Job Template attributes (see section 15
       for a full description of "ipp-attribute-fidelity" and its
       relationship to other attributes).
     - Job Object Attributes: These attributes are returned in response
       to a query operation directed at a Job object.
     - Printer Object Attributes: These attributes are returned in
       response to a query operation directed at a Printer object.
     - Unsupported Attributes: In a create request, the client supplies
       a set of Operation and Job Template attributes.  If any of these
       attributes or their values is unsupported by the Printer object,
       the Printer object returns the set of unsupported attributes in
       the response.  Section 15 gives a full description of how Job
       Template attributes supplied by the client in a create request
       are processed by the Printer object and how unsupported
       attributes are returned to the client.  Because of extensibility,
       any IPP object might receive a request that contains new or
       unknown attributes or values for which it has no support. In such
       cases, the IPP object processes what it can and returns the
       unsupported attributes in the response.

   Later in this section, each operation is formally defined by
   identifying the allowed and expected groups of attributes for each
   request and response.  The model identifies a specific order for each
   group in each request or response, but the attributes within each
   group may be in any order, unless specified otherwise.

   Each attribute specification includes the attribute's name followed
   by the name of its attribute syntax(es) in parenthesizes.  In
   addition, each 'integer' attribute is followed by the allowed range
   in parentheses, (m:n), for values of that attribute.  Each 'text' or
   'name' attribute is followed by the maximum size in octets in
   parentheses, (size), for values of that attribute. For more details
   on attribute syntax notation, see the descriptions of these
   attributes syntaxes in section 4.1.
ToP   noToC   RFC2566 - Page 22
   Note: Document data included in the operation is not strictly an
   attribute, but it is treated as a special attribute group for
   ordering purposes.  The only operations that support supplying the
   document data within an operation request are Print-Job and Send-
   Document.  There are no operation responses that include document
   data.

   Note: Some operations are REQUIRED for IPP objects to support; the
   others are OPTIONAL (see section 5.2.2).  Therefore, before using an
   OPTIONAL operation, a client SHOULD first use the REQUIRED Get-
   Printer-Attributes operation to query the Printer's "operations-
   supported" attribute in order to determine which OPTIONAL Printer and
   Job operations are actually supported.  The client SHOULD NOT use an
   OPTIONAL operation that is not supported.  When an IPP object
   receives a request to perform an operation it does not support, it
   returns the 'server-error-operation-not-supported' status code (see
   section 13.1.5.2).  An IPP object is non-conformant if it does not
   support a REQUIRED operation.



(page 22 continued on part 2)

Next Section