INTERNET-DRAFT
         draft-ietf-ipp-model-05.txt
         draft-ietf-ipp-model-06.txt
                                                                       R. deBry
                                                                IBM Corporation
                                                                    T. Hastings
                                                              Xerox Corporation
                                                                     R. Herriot
                                                               Sun Microsystems
                                                                    S. Isaacson
                                                                   Novell, Inc.
                                                                      P. Powell
                                                     San Diego State University
                                                              September 3,
                                                               October 14, 1997

                  Internet Printing Protocol/1.0: Model and Semantics

         Status of this Memo

         This document is an Internet-Draft.  Internet-Drafts are working
         documents of the Internet Engineering Task Force (IETF), its areas,
         and its working groups.  Note that other groups may also distribute
         working documents as Internet-Drafts.

         Internet-Drafts are draft documents valid for a maximum of six months
         and may be updated, replaced, or obsoleted by other documents at any
         time.  It is inappropriate to use Internet-Drafts as reference
         material or to cite them other than as "work in progress".

         To learn the current status of any Internet-Draft, please check the
         "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
         Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
         munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
         ftp.isi.edu (US West Coast).

         Abstract

         This document is one of a set of documents, which together describe
         all aspects of a new Internet Printing Protocol (IPP).  IPP is an
         application level protocol that can be used for distributed printing
         using Internet tools and technology.  The protocol is heavily
         influenced by the printing model introduced in the Document Printing
         Application (ISO/IEC 10175 DPA) (DPA) [ISO10175] standard.  Although DPA specifies both
         end user and administrative features, IPP version 1.0 is focused only
         on end user functionality.

                                 Expires April 14, 1998
         The full set of IPP documents includes:

         deBry, Hastings, Herriot, Isaacson, Powell
                                  Expires March3, 1998

           Requirements for an Internet Printing Protocol: Requirements Protocol [IPP-REQ]
           Internet Printing Protocol/1.0: Model and Semantics
           Internet Printing Protocol/1.0: Security
           Internet Printing Protocol/1.0: Protocol Specification [IPP-PRO]
           Rationale for the Structure and Model and Protocol for the Internet
              Printing Protocol/1.0: Directory Schema Protocol [IPP-RAT]

         The requirements document document, "Requirements for an Internet Printing
         Protocol", 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.  The requirements document calls
         out a subset of end user requirements that MUST be satisfied in the
         first version of IPP.  Operator and administrator requirements are out
         of scope for v1.0. The model This document, "Internet Printing Protocol/1.0:
         Model and semantics
         document Semantics",  describes a simplified model with abstract
         objects, their attributes, and their operations. The model introduces
         a Printer object and a Job object.  The Job object supports multiple
         documents per job.  The security model document covers potential threats also addresses how security,
         internationalization, and proposed
         counters to those threats. directory issues are addressed. The protocol specification
         specification, " Internet Printing Protocol/1.0: Protocol
         Specification", is a formal
         document which incorporates mapping of the ideas abstract operations and
         attributes defined in all the other documents into
         a concrete mapping using clearly defined data representations and
         transport model document onto HTTP/1.1.  The protocol mappings that real implementers can use to develop
         interoperable client and server side components. Finally,
         specification defines the
         directory schema document shows a generic schema encoding rules for directory service
         entries that represent instances of IPP Printers.

         This document is the "Internet Printing Protocol/1.0: Model and
         Semantics" document.

         deBry, Hastings, Herriot, Isaacson, Powell a new Internet media type
         called "application/ipp".

                                 Expires February xx, April 14, 1998
                                   Table of Contents

         1. Simplified Printing Model .......................................7 .......................................8
         2. IPP Objects .....................................................9 ....................................................10
         2.1  Printer Object..................................................9 Object................................................10
         2.2  Job Object.....................................................12 Object....................................................13
         2.3  Document Object................................................12
         2.4  Object Relationships...........................................12
         2.5 Relationships..........................................14
         2.4  Object Identity................................................13 Identity...............................................14
         3. IPP Operations .................................................15
         3.1  General Semantics..............................................16 Semantics.............................................16
         3.1.1     Operation Targets........................................16 Characteristics................................16
         3.1.2     Operation Targets........................................18
         3.1.3     Character Set and Natural Language Operation Attributes..19
         3.1.3.1     Request Operation Attributes ..........................19
         3.1.3.2     Response Operation Attributes .........................20
         3.1.4     Operation Status Codes and Messages......................16
         3.1.3 Messages......................21
         3.1.5     Security Concerns for IPPOperations......................17
         3.1.3.1 IPP Operations.....................22
         3.1.5.1     Authenticated Requester Identity .......................17
         3.1.3.2 ......................22
         3.1.5.2     Restricted Queries .....................................17
         3.1.4     Versions.................................................18
         3.1.5 ....................................23
         3.1.6     Versions.................................................23
         3.1.7     Job Creation Operations..................................18 Operations..................................24
         3.2  Printer Operations.............................................20 Operations............................................26
         3.2.1     Print-Job Operation......................................20 Operation......................................26
         3.2.1.1     Print-Job Request ......................................20 .....................................26
         3.2.1.2     Print-Job Response .....................................22 ....................................28
         3.2.2     Print-URI Operation......................................23 Operation......................................30
         3.2.3     Validate-Job Operation...................................23 Operation...................................31
         3.2.4     Create-Job Operation.....................................23 Operation.....................................31
         3.2.5     Get-Attributes Operation.................................24 Operation.................................31
         3.2.5.1     Get-Attributes Request .................................24 ................................32
         3.2.5.2     Get-Attributes Response ................................25 ...............................33
         3.2.6     Get-Jobs Operation.......................................25 Operation.......................................34
         3.2.6.1     Get-Jobs Request .......................................25 ......................................34
         3.2.6.2     Get-Jobs Response ......................................26 .....................................35
         3.3  Job Operations.................................................27 Operations................................................36
         3.3.1     Send-Document Operation..................................27 Operation..................................37
         3.3.1.1     Send-Document Request ..................................27 .................................37
         3.3.1.2     Send-Document Response .................................28 ................................39
         3.3.2     Send-URI Operation.......................................29 Operation.......................................39
         3.3.3     Cancel Job Operation.....................................29 Operation.....................................39
         3.3.3.1     Cancel-Job Request .....................................29 ....................................40
         3.3.3.2     Cancel-Job Response ....................................29 ...................................40
         3.3.4     Get-Attributes Operation.................................29 Operation.................................41
         3.3.4.1     Get-Attributes Request .................................30 ................................41
         3.3.4.2     Get-Attributes Response ................................30 ...............................41
         4. Object Attributes ..............................................31 ..............................................42
         4.1  Attribute Syntaxes.............................................31 Syntaxes............................................42
         4.1.1     'text'...................................................43

                                 Expires April 14, 1998
         4.1.2     'name'...................................................44
         4.1.3     'keyword'................................................44
         4.1.4     'enum'...................................................45
         4.1.5     'uri'....................................................45
         4.1.6     'uriScheme'..............................................45
         4.1.7     'charSet'................................................46
         4.1.8     'naturalLanguage'........................................46
         4.1.9     'mimeType'...............................................47
         4.1.10    'octetString'............................................48
         4.1.11    'boolean'................................................48
         4.1.12    'integer'................................................48
         4.1.13    'rangeOfInteger'.........................................48
         4.1.14    'dateTime'...............................................48
         4.1.15    'resolution'.............................................48
         4.1.16    '1setOf  X'..............................................49
         4.2  Job Template Attributes........................................33 Attributes.......................................49
         4.2.1     job-sheets (type4 keyword)...............................37 keyword, name).........................53
         4.2.2     notify-events (1setOf type2 keyword).....................38
         4.2.2.1     Event Notification Content .............................38

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         4.2.3     notify-addresses (1setOf uri)............................39
         4.2.4     job-priority (integer(1:100))............................39
         4.2.5 (integer(1:100))............................54
         4.2.3     job-hold-until (type4 keyword)...........................40
         4.2.6 keyword, name).....................55
         4.2.4     multiple-document-handling (type2 keyword)...............40
         4.2.7 keyword)...............56
         4.2.5     media (type4 keyword)....................................41
         4.2.8 keyword, name)..............................57
         4.2.6     number-up (type3 keyword)................................42
         4.2.9 (integer)......................................57
         4.2.7     sides (type2 keyword)....................................42
         4.2.10 keyword)....................................58
         4.2.8     printer-resolution (resoultion)..........................43
         4.2.11 (resolution)..........................59
         4.2.9     print-quality (type2 enum)...............................43
         4.2.12 enum)...............................59
         4.2.10    finishings (1setOf type2 enum)...........................43
         4.2.13 enum)...........................59
         4.2.11    copies (integer(1:2**31 - 1))............................44
         4.2.14    page-range (rangeOf integer).............................44
         4.2.15 1))............................60
         4.2.12    page-ranges (1setOf rangeOfInteger)......................60
         4.2.13    orientation (type2 enum).................................45
         4.2.16 enum).................................61
         4.2.14    document-format (mimeType)...............................45
         4.2.17 (mimeType)...............................61
         4.2.15    compression (type3 keyword)..............................45
         4.2.18 keyword)..............................62
         4.2.16    job-k-octets (integer(0:2**31 - 1))......................46
         4.2.19 1))......................62
         4.2.17    job-impressions (integer(0:2**31 - 1))...................46
         4.2.20 1))...................62
         4.2.18    job-media-sheets (integer(0:2**31 - 1))..................46 1))..................63
         4.3  Job Description Attributes.....................................46 Attributes....................................63
         4.3.1     job-uri (uri)............................................47 (uri)............................................64
         4.3.2     job-id (32bit unsigned integer)..........................48 (integer(1:MAX))..................................65
         4.3.3     job-uri-user (uri).......................................48     job-more-info (uri)......................................65
         4.3.4     job-name (name)..........................................48 (name)..........................................65
         4.3.5     job-originating-user (name)..............................48 (octetString).......................65
         4.3.6     job-originating-host (name)..............................48
         4.3.7     user-human-language (human-language).....................49
         4.3.8     job-state (type1 enum)...................................49
         4.3.9 enum)...................................66
         4.3.7     job-state-reasons (1setOf  type2 keyword)................51
         4.3.10 keyword)................68
         4.3.8     job-state-message (text).................................53
         4.3.11 (text).................................70
         4.3.9     number-of-documents (integer(0:2**31 - 1))...............70
         4.3.10    output-device-assigned (name)............................53 (name)............................71
         4.3.11    time-of-creation (integer)...............................71
         4.3.12    time-since-pending (integer).............................53    time-at-processing (integer).............................71
         4.3.13    time-since-processing (integer)..........................53    time-at-completed (integer)..............................71

                                 Expires April 14, 1998
         4.3.14    time-since-completed (integer)...........................53
         4.3.15    number-of-intervening-jobs (integer(0:2**31 - 1))........53
         4.3.16 1))........71
         4.3.15    job-message-from-operator (text).........................54
         4.3.17 (text).........................71
         4.3.16    job-k-octets-processed (integer(0:2**31 - 1))............54
         4.3.18 1))............72
         4.3.17    job-impressions-completed  (integer(0:2**31 - 1))........54
         4.3.19 1))........72
         4.3.18    job-media-sheets-completed (integer(0:2**31 - 1))........54 1))........72
         4.3.19    attributes-charset (charSet).............................72
         4.3.20    attributes-natural-language (naturalLanguage)............73
         4.4  Document Attributes............................................54
         4.4.1     document-name (name).....................................55
         4.4.2     document-uri (uri).......................................55
         4.5  Printer Description Attributes.................................56
         4.5.1 Attributes................................73
         4.4.1     printer-uri (uri)........................................58
         4.5.2 (uri)........................................75
         4.4.2     printer-name (name)......................................58
         4.5.3 (name)......................................75
         4.4.3     printer-location (text)..................................58
         4.5.4     printer-description (text)...............................58
         4.5.5 (text)..................................75
         4.4.4     printer-info (text)......................................75
         4.4.5     printer-more-info (uri)..................................58
         4.5.6 (uri)..................................75
         4.4.6     printer-driver-installer (uri)...........................59

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         4.5.7 (uri)...........................76
         4.4.7     printer-make-and-model (text)............................59
         4.5.8 (text)............................76
         4.4.8     printer-more-info-manufacturer (uri).....................59
         4.5.9 (uri).....................76
         4.4.9     printer-state (type1 enum)...............................59
         4.5.10 enum)...............................76
         4.4.10    printer-state-reasons (1setOf type2 keyword).............60
         4.5.11 keyword).............77
         4.4.11    printer-state-message (text).............................62
         4.5.12 (text).............................80
         4.4.12    operations-supported (1setOf type2 enum).................62
         4.5.13 operation)..................80
         4.4.13    printer-charset (charSet)................................81
         4.4.14    charsets-supported (1setOf charSet)......................81
         4.4.15    printer-natural-language (naturalLanguage)...............81
         4.4.16    natural-languages-supported (1setOf naturalLanguage).....81
         4.4.17    printer-is-accepting-jobs (boolean)......................63
         4.5.14 (boolean)......................82
         4.4.18    queued-job-count (integer(0:2**31 - 1))..................63
         4.5.15 1))..................82
         4.4.19    printer-message-from-operator (text).....................63
         4.5.16    printer-human-language (human-language)..................63
         4.5.17    printer-human-language-supported (1setOf human-language).63
         4.5.18 (text).....................82
         4.4.20    color-supported (boolean)................................64
         4.5.19 (boolean)................................82
         4.4.21    reference-uri-schemes-supported (1setOf uriScheme).......83
         4.4.22    pdl-override (type2 keyword).............................64
         4.5.20    Security Related Attributes..............................64
         4.5.20.1    message-protection-supported (keyword) .................65
         4.5.20.2    authentication-authorization-supported (keyword) .......65
         4.5.21 keyword).............................83
         4.4.23    security-mechanisms-supported (1setOf keyword)...........83
         4.4.24    printer-up-time (seconds)................................65
         4.5.22 (integer(1:MAX)).........................84
         4.4.25    printer-current-time (dateTime)..........................65 (dateTime)..........................84
         4.4.26    multiple-operation-time-out (integer)....................84
         5. Conformance ....................................................66 ....................................................84
         5.1  Client Conformance Requirements................................66 Requirements...............................85
         5.2  Printer Object Conformance Requirements........................67 Requirements.......................85
         5.2.1     Objects..................................................67     Objects..................................................86
         5.2.2     Operations...............................................67     Operations...............................................86
         5.2.3     Attributes...............................................67     Attributes...............................................86
         5.2.4     Printer extensions.......................................68 extensions.......................................87
         5.2.5     Attribute Syntaxes.......................................68 Syntaxes.......................................87
         5.3  Security Conformance Requirements..............................68 Requirements.............................87
         6. IANA Considerations (registered and private extensions) ........68 ........87
         6.1  Typed Extensions...............................................68 Extensions..............................................88
         6.2  Registration of MIME types/sub-types for document-formats......70 document-formats.....89
         6.3  Attribute Extensibility........................................70 Extensibility.......................................89
         6.4  Attribute Syntax Extensibility.................................70 Extensibility................................89

                                 Expires April 14, 1998
         7. Internationalization Considerations ............................70 ............................89
         8. Security Considerations ........................................71 ........................................91
         8.1  Client and Printer in the Same Security Domain................92
         8.2  Client and Printer in Different Security Domains..............92
         8.3  Print by Reference............................................93
         8.3.1     Unprotected Documents....................................93
         8.3.2     Protected Documents......................................93
         8.4  Common Security Scenarios.....................................93
         8.4.1     No Security..............................................93
         8.4.2     Message Protection During Transmission...................94
         8.4.3     Client Authentication and Authorization..................94
         8.4.4     Mutual Authentication, Authorization and Message Protection
                   94
         8.5  Recommended Security Mechanisms...............................94
         9. References .....................................................71
         10.Author's .....................................................95
         10.Copyright Notice ...............................................99
         11.Author's Address ...............................................73
         11.APPENDIX ...............................................99
         12.APPENDIX A: Terminology ........................................76
         11.1 .......................................102
         12.1 Conformance Terminology........................................76
         11.1.1    MUST.....................................................76
         11.1.2 Terminology......................................102
         12.1.1    MUST....................................................102
         12.1.2    MUST NOT.................................................76
         11.1.3    SHOULD...................................................76
         11.1.4 NOT................................................102
         12.1.3    SHOULD..................................................102
         12.1.4    SHOULD NOT...............................................76
         11.1.5    MAY......................................................76
         11.1.6 NOT..............................................102
         12.1.5    MAY.....................................................102
         12.1.6    NEED NOT.................................................77
         11.2 NOT................................................103
         12.2 Model Terminology..............................................77
         11.2.1    Keyword..................................................77
         11.2.2    Attributes...............................................77
         11.2.2.1 Terminology............................................103
         12.2.1    Keyword.................................................103
         12.2.2    Attributes..............................................103
         12.2.2.1    Attribute Name .........................................77

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         11.2.2.2 .......................................103
         12.2.2.2    Attribute Group Name ...................................78
         11.2.2.3 .................................104
         12.2.2.3    Attribute Value ........................................78
         11.2.2.4 ......................................104
         12.2.2.4    Attribute Syntax .......................................78
         11.2.3    Supports.................................................78
         12.APPENDIX .....................................104
         12.2.3    Supports................................................104
         12.2.4    print-stream page.......................................106
         12.2.5    imposed page............................................106
         13.APPENDIX B:  Status Codes ......................................80
         12.1 .....................................106
         13.1 Status Codes (type2 keyword)...................................80
         12.1.1    Informational............................................81
         12.1.2 Codes.................................................107
         13.1.1    Informational...........................................107
         13.1.2    Successful Status Codes..................................81
         12.1.2.1 Codes.................................107
         13.1.2.1    successful-ok (0x00) ...................................81
         12.1.2.2 (0x0000) ...............................107
         13.1.2.2    successful-ok-ignored-or-substituted-attributes (0x01) .81
         12.1.3 (0x0001)
                     108
         13.1.3    Redirection Status Codes.................................81
         12.1.4 Codes................................108
         13.1.4    Client Error Status Codes................................81
         12.1.4.1 Codes...............................108
         13.1.4.1    client-error-bad-request (0x400) .......................81
         12.1.4.2 (0x0400) ....................108
         13.1.4.2    client-error-forbidden (0x401) .........................82
         12.1.4.3 (0x0401) ......................108
         13.1.4.3    client-error-not-authenticated (0x402) .................82
         12.1.4.4 (0x0402) ..............108
         13.1.4.4    client-error-not-authorized (0x403) ....................82
         12.1.4.5 (0x0403) .................109

                                 Expires April 14, 1998
         13.1.4.5    client-error-not-possible (0x404) ......................82
         12.1.4.6 (0x0404) ...................109
         13.1.4.6    client-error-timeout (0x405) ...........................82
         12.1.4.7 (0x0405) ........................109
         13.1.4.7    client-error-not-found (0x406) .........................83
         12.1.4.8 (0x0406) ......................109
         13.1.4.8    client-error-gone (0x407) ..............................83
         12.1.4.9 (0x0407) ...........................110
         13.1.4.9    client-error-request-entity-too-large (0x408) ..........83
         12.1.4.10 (0x0408) .......110
         13.1.4.10   client-error-request-URI-too-long (0x409) ..............84
         12.1.4.11 (0x0409) ...........110
         13.1.4.11   client-error-unsupported-document-format (0x40A) .......84
         12.1.4.12 (0x040A) ....110
         13.1.4.12   client-error-attribute-not-supported (0x40B) ...........84
         12.1.5 (0x040B) ........111
         13.1.4.13   client-error-uri-scheme-not-supported (0x040C) .......111
         13.1.4.14   client-error-charset-not-supported (0x040D) ..........111
         13.1.4.15   client-error-natural-language-not-supported (0x040E) .111
         13.1.5    Server Error Status Codes................................84
         12.1.5.1 Codes...............................111
         13.1.5.1    server-error-internal- error (0x500) ...................85
         12.1.5.2 (0x0500) ................112
         13.1.5.2    server-error-operation-not-supported (0x501) ...........85
         12.1.5.3 (0x0501) ........112
         13.1.5.3    server-error-service-unavailable (0x502) ...............85
         12.1.5.4 (0x0502) ............112
         13.1.5.4    server-error-version-not-supported (0x503) .............85
         12.1.5.5 (0x0503) ..........112
         13.1.5.5    server-error-device-error (0x504) ......................85
         12.1.5.6 (0x0504) ...................112
         13.1.5.6    server-error-temporary-error (0x505) ...................86
         12.2 (0x0505) ................113
         13.2 Status Keywords Codes for IPP Operations.............................87
         13.APPENDIX C: "document-format" values ...........................87 Operations..............................114
         14.APPENDIX D: C:  "media" keyword values ............................90 ...........................114
         15.APPENDIX E: D: Processing IPP Attributes ..........................95 .........................119
         15.1 Fidelity.......................................................95 Fidelity.....................................................119
         15.2 Page Description Language (PDL) Override.......................97 Override.....................121
         15.3 Suggested Attribute Operation Processing Algorithm.......................98 Algorithm.....................122
         15.4 Using Job Template Attributes During Document Processing.....126
         16.APPENDIX F: Relationship to SNMP MIBs .........................101

         deBry, Hastings, Herriot, Isaacson, Powell E: Generic Directory Schema ..........................127

                                 Expires February xx, April 14, 1998
         1. Simplified Printing Model

         In order to a achieve its goal of realizing a workable printing protocol
         for the Internet, the Internet Printing Protocol (IPP) is based on a
         simplified printing model which 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 does not
         include features, interfaces, and relationships that are beyond the
         scope of IPP/1.0.  IPP [20]. incorporates many of the relevant ideas and
         lessons learned from other specification and development efforts
         [HTPP] [LDPA] [P1387.4] [PSIS] [RFC1179] [SWP].

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

           - Printer (Section 2.1)
           - Job (Section 2.2)
           - Document (Section 2.3)

         Each object type has an associated set of operations (see section 3)
         and attributes (see section 4).

         The terminology used in the remainder of this document is defined in
         Appendix A
         (section 11) .  Terms 12).  In the remainder of this document, terms such as
         "attributes", "keywords", and "supports" have special meaning in this document and are
         defined in the model terminology section.  .  Terms Capitalized terms such as "MANDATORY", "MUST",
         MANDATORY, SHALL, and "OPTIONAL" OPTIONAL have special meaning relating to
         conformance.  These terms are defined in the section on conformance
         terminology, most of which is taken from RFC 2119 [25]. [RFC2119].

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

         deBry, Hastings, Herriot, Isaacson, Powell

                                 Expires February xx, April 14, 1998
                                      +--------------+
                                      |  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 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. IPP Printers 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.  The directory is used
         to store relatively static information about the Printer, allowing end
         users to search for and find Printers that match their search criteria
         (name,
         criteria, for example: name, context, printer capabilities, etc.). etc. (see
         section 16). The more dynamic information is directly associated with a
         the IPP Printer itself.  This information includes state, currently
         loaded and ready media, number of jobs at the Printer, errors,
         warnings, and so forth.

         IPP clients Clients implement the IPP protocol on the client side, and give
         end users (or programs) the ability to query an IPP Printer and submit
         and manage print jobs.  An IPP server is just that part of the IPP

                                 Expires April 14, 1998
         Printer that implements the server-side protocol.  The rest of the IPP

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         Printer implements the application semantics of the print service
         itself.  The IPP Printer may be embedded in an output device or may be
         implemented on a host on the network that communicates with the output
         device.

         When a job is submitted to the Printer object and the Printer object
         validates the
         data 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 print job by using the Job. Job object's Cancel-
         Job operation.  The end user is able to register to receive certain
         events that are then routed using the specified notification
         service(s).

         2. IPP Objects

         The IPP model introduces objects of type Printer, Job, Printer and Document. Job.  Each type
         of object models relevant aspects of a real-world entity such as a
         real printer or print job.  Each object type is defined as a set of
         possible attributes that may be supported by each instance of an object instances of that object
         type.  For each
         object instance, object, the actual set of supported attributes and
         values describe the 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 object type "Printer" Printer is defined as a set of attributes
         that each
         instance of a Printer object might potentially support. supports.  In the same manner,
         the object type "Job" Job is defined as a set of attributes that are
         potentially supported by each instance of a Job object.

         Each attribute included in the set of attributes defining an object
         type is labeled as:

           - "MANDATORY": each object instance MUST SHALL support the attribute.
           - "OPTIONAL": each object instance MAY support OPTIONALLY supports the attribute.

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

         2.1 Printer Object

         A major component of the IPP model is the Printer object.  An instance
         of a object (also called
         the IPP Printer).  A Printer object implements the IPP protocol.
         Using the protocol, end users may query the attributes of the Printer
         and submit Jobs to the Printer (section 3 describes each of the Printer specific
         operations in detail). Printer.  The actual implementation components

                                 Expires April 14, 1998
         behind the Printer abstraction may take on different forms and
         different configurations.  However, the model abstraction allows the
         details of

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998 the configuration of real components to remain transparent opaque to
         the end user. Section 3 describes each of the Printer operations in
         detail.

         The capabilities and state of an IPP a Printer object are described by its
         attributes.  Printer attributes are grouped as follows: into two groups:

           - "job-template" attributes: These attributes (section the describe job
              processing capabilities and defaults for the Printer object. (See
              section 4.2)
           - "printer-description" attributes:  These attributes (section 4.5) 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, an IPP a Printer object could be used to
         represent any real or virtual device with semantics consistent with
         the Printer object, such as a fax-out 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 might or might not be capable
                of spooling jobs
              3b) The associated output devices might or might not support IPP

         See the

         The following figures for show some examples on of how to view IPP Printer objects implemented can be
         realized on top of various print system distributed printing configurations.  The
         embedded case below represents configurations 1 and 2. The hosted and
         fan-out figures below represent configuration 3.

         deBry, Hastings, Herriot, Isaacson, Powell

                                 Expires February xx, April 14, 1998
         Legend:

         ##### indicates a Printer object which is
               either embedded in an output device or is
               hosted in a server.  The implementation
               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 |
                                                  |               |
                                                  +---------------+

         It

         A Printer object is assumed that URIs for identified with a Uniform Resource Identifier
         (URI) [RFC1630].  Often, the URI is a Uniform Resource Locator (URL)
         [RFC1738] [RFC1808]..

                                 Expires April 14, 1998
         Note: The IPP Printers are available to end users or
         programs that wish protocol specification [IPP-PRO] defines a mapping of
         IPP onto HTTP/1.1.  Therefore, all conforming Printer objects SHALL
         support HTTP schemed URIs to interact with identify themselves.  For example, a
         Printer object's URI could be "http://www.some-domain.org/printer-
         one".  A Printer object's URI could not be "ftp://ftp.some-
         domain.org/printer-one".

         IPP does not specify how the Printer.  Although NOT
         MANDATORY, URI is obtained, but it is RECOMMENDED
         that Printers be a Printer object is registered in a directory service which end
         users and programs can interrogate.
         "Internet Printing Protocol: Directory Schema"[24] Section 16 defines the

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         attributes to be associated with a generic
         schema for Printer entry object entries in a the directory service.

         2.2 Job Object

         A Job object is used to model a print job.  A Job can contain one or
         more
         Documents. documents.  The information required to create a Job object is
         sent in a create request from the end user via an IPP client Client to an IPP
         Printer. the
         Printer object.  Section 3 describes each of the Job specific operations in
         detail.

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

           - "job-template" attributes:  These attributes (optionally are optionally
              supplied by the client/end
              user, 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 (set by describe the Printer, Job
              object's identification, state, size, etc. The client does not
              supply values for these attributes, they are set by the Printer
              object.  (See section 4.3)

         2.3 Document Object

         A Document Job object is used to model a document. contains at least one document, but may contain multiple
         documents.  A Document document consists of
         either printable either:

           - a stream of data in a format supported by the Printer object, or
           - a URI reference to printable data  An
         instance of a Document object is a set stream of attributes which describe data in a format supported by the
              Printer

         A document data.  Document Attributes (see section 4.4). Document
         attributes only describe the data to be printed; they do is not include
         any specialized document processing instructions. modeled as an IPP object, therefore it has no object
         identifier or associated attributes.  All job processing instructions
         are at the modeled as Job level and object attributes.  These attributes are called called Job
         Template attributes and they apply equally to all Documents documents within a
         Job.

         2.4

                                 Expires April 14, 1998
         2.3 Object Relationships

         Instances of

         IPP objects within the system have relationships that MUST be maintained persistently
         along with the persistent storage of the object attributes.  An instance of a  A Printer
         object usually represents may represent one or more output devices.  A Printer object may
         represent a logical device which "processes" jobs but never actually
         uses a physical output device to put marks on paper (for example a Web
         page publisher or an interface into an online document archive or
         repository).  A Printer can contain object contains zero or more Job objects.  An instance of a  A
         Job object is contained in by exactly one Printer object, however the
         identical Job document data associated with a Job object could be sent to
         either the same or a different
         Printer. Printer object.  In this case, the a new
         Job object would be an identical, but
         different Jobsince created which would be almost identical to the
         existing Job object, however it each would have a different new (different) Job
         object identifier.  A

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998 Job object contains one or more Documents. documents.  If
         the Document is simply
         a reference to some print data stream, the referenced contained document may be
         used in multiple Documents in the same Job or even in different Jobs,
         though each Document contains its own copy of the reference.  If the
         Document is not just a reference, but an actual stream of print printer-ready data,
         the that stream is
         can be contained in only one Document, although document.  However, there can be copies
         of the same document data stream in other Documents documents in the same or different Jobs.

         2.5 Job objects.
         If the contained document is a reference to a stream of printer-ready
         data, other documents (in the same or different Job object(s)) may
         reference the same stream.

         2.4 Object Identity

         All instances of Printer and Job objects have a URI an identifier so that they can be
         persistently and unambiguously referenced.  The IPP model requires
         that these values identifiers be URIs.  Often, the URI is a URL [RFC1738]
         [RFC1808].

         Allowing Job objects to have URIs as defined by RFC 1738 [11] allows for flexibility and RFC 1808
         [34].
         scalability.  In addition to an identifier, instances of Printers, Jobs, and
         Documents may have a name.  An some implementations, the Printer object name need not 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 unique across
         all instances a composition
         of all objects. The Printer name is chosen the Printer's URI and set by an
         administrator through some mechanism outside the scope of IPP itself.
         If unique component for the client does not supply Job name or a Document name, object.  In
         other implementations, the Printer
         generates object might be a name.  In central clearing-
         house for validating all cases, the name only has local meaning, Job object creation requests, and
         it is not constrained to the Job
         object itself might be unique.

         To summarize:

           - Each created in some environment that is remote from
         the Printer will be uniquely identified with a URI.  The
              Printer's "printer-uri" attribute contains object.  In this case, the Job object's URI may have no
         relationship at all to the Printer object's URI.
           - Each

         However, many existing printing systems have local models or interface
         constraints that force Job will objects to be uniquely identified with using only a 32-
         bit positive integer rather than a URI.  The Job's "job-
              uri" attribute contains the URI.
           - Each Printer has name (which  This numeric Job ID is not necessarily unique).  The
              administrator chooses only
         unique within the context of the Printer object to which the create
         request was originally submitted.  In order to allow both types of
         client access to Jobs (either Job URI or numeric Job ID), when the
         Printer object successfully processes a create request and sets this creates a

                                 Expires April 14, 1998
         new Job, the Printer object SHALL generate both a Job URI and a Job ID
         for the new Job object.  This requirement allows all clients to access
         Printer objects and Job objects no matter the local constraints
         imposed on the client implementation.

         In addition to a unique identifier, Printer objects and Job objects
         may have names.  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 itself.  The Printer's "printer-name"
              attribute contains the name.
           - Each IPP.  A
         Job has object's name (which is not necessarily unique).  The client optionally supplies this name in chosen and supplied by the create request. IPP Client
         submitting the job.  If the client does not supply this a Job object name,
         the Printer object generates a name for the Job. new Job object.  In all
         cases, the name only has local meaning, and it is not constrained to
         be unique.

         To summarize:

           - Each Printer object is uniquely identified with a URI.  The Job's "job-name"
              Printer's "printer-uri" attribute contains the name. URI.
           - Each Document has name (which Job object is not necessarily unique).  The
              client optionally supplies this name in the request which creates
              the Document.  If the client does not supply this name, the
              Printer generates uniquely identified with a name for the Document. URI.  The Document's
              "document-name" Job's
              "job-uri" attribute contains the name.

         Note: If Documents are printed by reference, the corresponding
         Document URI.
           - Each Job object contains a "document-uri" attribute.  The value of
         this attribute is also uniquely identified with a reference to combination of
              the document data URI of the Printer object to be printed; it
         is not which the create request was
              originally submitted along with a Job ID (a 32-bit, positive
              number) that is unique identifier of within the Document object itself.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         Proposal:

         All instances context of Printer objects have a URI so that they can
         persistently and unambiguously referenced. Printer object.
              The IPP model requires
         that these values be URIs as defined by RFC 1738 [11] and RFC 1808.
         All Printer operations are directed to object's "printer-uri" contains the Printer's Printer URI.  All
         instances of  The
              Job objects have an opaque identifier that when used in
         combination with its Printer URI, allow it to be persistently and
         unambiguously referenced.  Instances of Document objects have no
         identifier since they are always created and queried using object's "job-id" attribute contains the numeric Job
         operations; that ID.
           - Each Printer object has a name (which is the model does not define semantics for querying
         the attributes of just one Document within a multi-Document Job.

         In addition to these identifier attributes, instances of Printer, Job, necessarily unique).
              The administrator chooses and Document objects may have a name.  An object sets this name need not be
         unique across all instances through some
              mechanism outside the scope of all objects. IPP itself.  The Printer object's
              "printer-name" attribute contains the name.
           - Each Job object has a name (which is chosen
         and set by an administrator.  A not necessarily unique).
              The client optionally supplies Job and
         Document names this name in the operations that create Jobs and Documents.  If a
         client does not supply a name, the Printer generates a name.  In all
         cases, the name only has local meaning, and it is not in any way
         constrained to be unique.

         To summarize:

           - Each Printer will be uniquely identified with a URI.  The
              Printer's "printer-uri" attribute contains this URI.
           - Each Job will be uniquely identified with a Job ID and a Printer
              URI.  The Job's "job-id" attribute contains the Job ID.  The
              Printer's "printer-uri" attribute contains the Printer's URI.
           - Each Printer has name (which is not necessarily unique).  The
              administrator chooses and sets this name through some mechanism
              outside the scope of IPP itself.  The Printer's "printer-name"
              attribute contains the name.
           - Each Job has name (which is not necessarily unique).  The client
              optionally supplies this name in the create request. request.
              If the client does not supply this name, the Printer object
              generates a name for the Job. Job object. The Job's Job object's "job-name"
              attribute contains the name.
           - Each Document has name (which is not necessarily unique).  The
              client optionally supplies this name in the request that creates
              the Document.  If the client does not supply this name, the
              Printer generates a name for the Document. The Document's
              "document-name" attribute contains the name.

         Note: If Documents are printed by reference, the corresponding
         Document object contains a "document-uri" attribute.  The value of

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         this attribute is a reference to the document data to be printed; it
         is not a unique identifier of the Document object itself.

         3. IPP Operations

         Jobs and Printers each

         IPP objects have a set of associated operations.
         Operations consist  An operation consists of requests a
         request and responses. a response.  When a client communicates with an IPP
         object, it issues an operation request to the URI for that object.  Each request carries along with
         Operations have attributes that supply information about the operation
         itself.  These attributes are called operation attributes (as compared
         to object attributes such as Printer attributes or Job attributes).
         Each request carries along with it any operation attributes and and/or
         document data required by the object to perform the operation.  Each

                                 Expires April 14, 1998
         request requires a response from the object.  Each response indicates
         success or failure of the operation with a status code, and
         may include code.  The response
         contains any operation attributes  and an optional attributes, object attributes, and/or status message.  The
         representation and encoding
         messages generated by the execution of IPP operations is described in
         "Internet Printing Protocol: Protocol Specification" [23]. the operation request.

         This section describes the semantics of the IPP operations operations, both
         requests and responses, in terms of their semantics and
         contents, including both the request attributes and the response for other data
         associated with each operation.

         Note: The Printer IPP protocol specification [IPP-PRO] describes a mapping and
         encoding of IPP operations onto HTTP/1.1 POST commands.  Other
         mappings for IPP operations to additional transport mechanisms are fully defined in section 3.2:
         possible.

         The 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-Attributes (section 3.2.5)
           Get-Jobs (section 3.2.6)

         The Job operations are fully defined in section 3.3: are:

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

         There are no explicit Document operations.  However, there are Job
         operations that are used to create and query Document objects
         contained within a Job object.

         The Send-Document and Send-URI Job operations are used to add a new Document
         document to an existing multi-
         Document Job.  If requested, the Get-Attribute operation used for a multi-document Job also returns any Document object attributes.  If the Job is a
         single Document Job, only a single set of Document attributes is
         returned.  If however, the Job contains multiple Documents, created with the Get-
         Attribute Response contains multiple sets of Document attributes, one
         set for each Document.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         Create-Job operation.

         3.1 General Semantics

         3.1.1 Operation Targets

         All Characteristics

         Each IPP operations operation is defined as both a request and a response.  Both
         requests and responses are directed at an instance composed of an IPP object.  For
         Printer operations, groups of attributes and/or
         document data.  Attributes are grouped into the operation is directed at an IPP Printer using
         its URI.  That is, all Printer operations must somehow contain following groups:

           - Operation Attributes: These are attributes that are only passed
              in the
         target attribute "printer-uri" indicating operation itself, and usually do not persist beyond the target
              life of the operation.
         In the mapping  Operation attributes may also affect
              other attributes or groups of IPP over HTTP, attributes since values in the "printer-uri" attribute is
         actually encoded as
              operation attributes usually affect the "request-URI" component behavior of the HTTP operation.
         In other mappings, the target URI might be encoded using some other
         transport specific mechanism.

         For Job operations, object

                                 Expires April 14, 1998
              that processes the operation is directed at an operation.  All IPP Job using its
         URI.  Like Printer operations, objects that accept IPP
              operation request MUST support all Job operations must somehow contain
         the target attribute "job-uri" indicating the target of operation attributes.  Some
              operation attributes are OPTIONAL for the operation.
         Also, like Printer operations, in client to supply, but
              the mapping of IPP over HTTP, object MUST support the
         "job-uri" attribute is actually encoded as the "request-URI" component
         of by being prepare to
              handle the HTTP operation.  In other mappings, client supplied operation attribute by realizing the target URI might be
         encoded using some other transport specific mechanism.

         Propsal:

         For
              corresponding feature or function.
           - Job operations, the the operation is directed at Template Attributes: These attributes affect the Printer's URI
         and it is accompanied processing
              of a job.  They are OPTIONALLY supplied by a client in a create
              request, and the receiving object MUST be prepared to received
              all supported attributes.  The Job ID .  This allows the IPP Printer
         implementation object can later be queried to
              find out what was originally requested in the correct Job object.  That is, both the
         "printer-uri" attribute and the "job-id" attribute must both be
         supplied as the target of every Job operation.  Like create request.
              The Printer
         operations, in the mapping object can be queried to find out what type of IPP over HTTP, job
              processing capabilities are supported and/or what the "printer-uri"
         attribute is encoded default job
              processing behaviors are.
           - Job Object Attributes: These attributes are returned in the "request-URI" component of the HTTP
         operation.  However, the "job-id" attribute is supplied as an
         operation attribute within the response
              to query operation data itself.  If directed at a Job object.
           - Printer
         receives an IPP operation, it must check Object Attributes: These attributes are returned in
              response to see if the "job-id"
         attribute is included among the operation attributes.  If it is there,
         the a query operation is being directed at a Printer object.
           - Unsupported Attributes: In a create request, the Job identified by the value client supplies
              an optional set of
         "job-id". Job Template attributes.  If it is not there, any of these are
              unsupported by the operation is being directed at Printer object, the Printer itself.

         3.1.2 Operation Status Codes and Messages

         Every operation response object returns a MANDATORY status code and an
         OPTIONAL status message. A status code provides information on
              them in the
         processing of a request.  A status message provides response.  Section 15 gives a short textual full description of how
              Job Template attributes supplied by the status of the operation.  The status code is
         intended for use client in a create
              request are processed by automata the Printer object and how unsupported
              attributes are returned to the status message client.

         Later in this section, each operation is intended for formally defined by
         identifying the human user.  If a response does include allowed and expected groups of attributes for request
         and response.  The model identifies a status message,an IPP
         application is not required to examine specific order for each group in
         each request or display response, but the status message.
         Status codes and suggested corresponding status messages are described

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998 attributes within each group may be
         in any order.

         Note: Document data included in section 12. In most cases, if the status code indicates operation is not strictly an error,
         there are additional attributes in
         attribute, but it is treated as a special attribute group for ordering
         purposes.  The only operations that support supplying the response document
         data within an operation request are Print-Job and Send-Document.
         There are no operations responses that include document data.

         Since some operations are not returned
         in MANDATORY and some are OPTIONAL, a client
         SHOULD first use the successful case.  One such example is MANDATORY Get-Attributes operation to query the group of
         Printer's "operations-supported" attribute before using any
         unsupported
         attributes and values.  This set of attributes is returned in response operation.  A client SHOULD NOT attempt to use an operation
         unsupported operation.  When a Printer object receives a request that includes attributes that are to
         perform an operation it does not
         supported by support, it returns the object.

         3.1.3 Security Concerns for IPPOperations

         3.1.3.1 Authenticated Requester Identity error code
         'server-error-operation-not-supported' (see section 13.1.5.2).

                                 Expires April 14, 1998
         3.1.2 Operation Targets

         All IPP operations are directed at IPP objects.  For Printer
         operations, the operation is layered on top of security services that supply always directed at a Printer object using
         its URI (the "printer-uri" attribute).

         For Job operations, the requester's
         identity.  It operation is assumed that identity supplied by directed at either:

           - the authentication
         service is Job object itself using the most authenticated identity required Job object's URI ("job-uri")
              assigned by a given site's
         configuration and current policy.  It is also assumed that the
         layering allows for a single IPP implementation to be run over a
         consistent interface that supplies Printer object, or
           - the authenticated identity. The
         authentication interface should allow for various modular and
         extensible authentication service implementations without requiring
         changes Printer object to which the IPP implementation.

         Once job was originally submitted
              using the authenticated identity URI of the requester has been supplied to Printer ("printer-uri") in combination with
              and the IPP implementation, 32-bit numeric Job ID ("job-id") assigned by the Printer
              object.

         If the operation is directed at the Job object directly using the implementation uses that identity to
         enforce any authorization policy(ies) that might be in place.  When a Job
         object's URI, the client SHOULD NOT include the redundant "job-id"
         operation attribute.

         Note:  In the mapping of IPP over HTTP/1.1, the object's URI is created,
         actually encoded as the identity "request-URI" field of the requester HTTP POST
         operation. In the case of Printer operations directed at a Printer
         object, the create operation Printer object's "printer-uri" attribute is persistently stored mapped to the
         "request-URI" attribute in the Job's "job-originating-user" attribute.
         This HTTP header. In the case of Job
         operations directed at the Job object, the Job object's "job-uri"
         attribute can be used is mapped to match the requester's identity "request-URI" attribute in the HTTP header.
         In the case of
         subsequent Job operations on directed at the Printer object that Job
         created the Job, the Printer object's "printer-uri" attribute is sent
         in order to enforce the local
         authorization policy(ies), if any.  There are operation status codes
         that allow an implementation to return information back to the
         operation requester about what has been forbidden, not allowed, or not
         authorized.

         For example, a site security policy might be that only HTTP header, and the job owner "job-id" attribute is allowed to cancel a job using sent as an
         operational attribute in the Cancel-Job operation.

         3.1.3.2 Restricted Queries request body. In many other mappings of these IPP operations, a client supplies a list of
         attributes to be returned in the response.  A Printer may be
         configured, for security reasons, not to return all attributes that a
         client requests.  It may even return none of the requested attributes.
         In such cases,
         operations onto some other transport mechanism, the status returned target URI is
         encoded using some other transport specific addressing mechanism.

         The following rules apply to the same as if use of port numbers in URIs that
         identify IPP objects:

           1. If the Printer had
         returned all requested attributes.  The client cannot tell by such a
         response whether protocol scheme for the requested attribute was present or absent on URI allows the
         Printer.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         3.1.4 Versions

         Each operation request carries with it a version number. Each version port number is to be
              explicitly included in the form X.Y where X is the major version number URI string, and Y is
         the minor version number.

         By including a version an explicit port
              number is specified in the client request, it allows published URI, then that port number
              MUST be used by the client (the requester) to identify which version of contact the IPP it is
         interested in using. server.

           2. If the Printer protocol scheme for the URI does not support that version, allow an explicit
              port number specification, then the Printer responds with a status code of  'server-error-version-not-
         supported'.  There is no version negotiation per se.  However, if
         after receiving a version not supported status code from default port number for the Printer,
         there is nothing that prevents a client from trying again with a
         different version number.  For example, a client might
              protocol should be configured
         to support IPP version 3.0, 2.5, 2.0 and 1.0 (hypothetically
         speaking).  A client might first try to speak version 3.0.  If after
         receiving a version not supported, it might successively try version
         2.5, then 2.0, then 1.0.  All implementations MUST support version
         1.0.

         Items that might affect the changing of used.

           3. Consult the major version number
         include any changes appropriate IPP protocol mapping document to
              determine alternate port numbers for the protocol specification itself such as:

           - reordering of ordered specified in
              the server URI.

                                 Expires April 14, 1998
         3.1.3 Character Set and Natural Language Operation Attributes

         Some Job and Printer attributes or attribute sets
           - changes to have values that are text strings and
         names intended for human understanding rather than machine
         understanding (see the 'text' and 'name' attribute syntax of existing attributes
           - changing OPTIONAL to descriptions
         in section 4.1).  The following sections describe two MANDATORY
         attributes for every IPP operation request and vice versa

         Items that might affect response.  These
         attributes are "attributes-charset" and "attributes-natural-language".
         For the changing sake of the minor version number
         include any changes to the model objects brevity in this document, these operation attribute
         descriptions are not repeated with every operation request and attributes
         response, but not the
         protocol specification itself, such as:

           - grouping all extensions not included in a previous version into have a
              new version
           - formally adding in new attribute values
           - changing any of the type1 attributes

         3.1.5 Job Creation Operations

         In order reference back to create a new Job object, a this section instead.

         3.1.3.1 Request Operation Attributes

         The client issues a create request.
         A create request is any one of SHALL supply and the Printer object SHALL support the
         following three MANDATORY operation requests:

           - The Print-Job Request: A attributes in every IPP operation
         request:

           "attributes-charset" (charSet):
              This operation attribute identifies the charset (coded character
              set and encoding method) used by any 'text' and 'name' attributes
              that the client is supplying in this request and that wants to create a Job with
              only a single Document uses the Print-Job operation. .  The Printer
              object SHALL return in this operation allows response.  See Sections
              4.1.1 and 4.1.2 for the client to "push" specification of the document data to 'text' and 'name'
              attribute syntaxes.

              The Printer object SHALL support the 'utf-8' charset [RFC2044]
              and MAY support additional charsets provided that they are
              registered with IANA [IANA-CS].  If the Printer by including object does not
              support the document data in supplied charset value, the Printer object SHALL
              reject the request itself.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           - and return status code 'client-error-charset-
              not-supported'.  The Print-URI Request: A client that wants to create a Job with
              only a single Document where the Printer "pulls" object SHALL indicate the document
              data uses charset(s)
              supported as the Print-URI operation.   In this case, values of the "charsets-supported" Printer
              attribute (see Section 4.4.14), so that the client
              includes only a URI reference to MAY query
              which charset(s) are supported.

              See the document data (not 'charSet' attribute syntax description in Section 4.1.7
              for the
              document data itself).

           - The Create-Job Request:  A client that wants to create a Job with
              multiple Documents uses syntax and semantic interpretation of the Create-Job operation. . values of this
              attribute and for example values.

           "attributes-natural-language" (naturalLanguage):
              This operation is followed by an arbitrary number of Send-Document or
              Send-URI operations (each creating another Document for this
              Job).  The Send-Document operation includes attribute identifies the document data in natural language used by
              any 'text' and 'name' attributes that the request (the client "pushes" the document data is supplying in
              this request.  A Printer SHOULD do its best to respond in the
              printer), and
              same natural language.

                                 Expires April 14, 1998
              There are no MANDATORY natural languages required for the Send-URI operation includes only a URI
              reference Printer
              object to support.  However, the document data in Printer's "natural-language-
              supported" attribute SHALL list the request (the Printer
              "pulls" natural languages supported,
              so that the document data from client MAY query which natural language(s) are
              supported.  For any of the referenced location).  The
              last Send-Document or Send-URI request includes a "last-document"
              attribute set to 'true'  indicating that this is attributes for which the last
              Document Printer
              generates messages, i.e., for this Job.

         Throughout this model specification, the term "create request" is used
         to refer "job-state-message", "printer-
              state-message" attributes ", and Status Messages (see Section
              3.1.4) in operation responses, the Printer object SHALL be able
              to generate messages in any of these three operation requests.

         A Create-Job operation followed by only one Send-Document operation is
         semantically equivalent to a Print-Job operation, however, for
         performance reasons, its supported natural languages.
              If the client SHOULD use the Print-Job operation for
         all single Document Jobs.  Also, Print-Job is requests a MANDATORY operation
         (all implementations MUST support it) whereas Create-Job natural language that is an
         OPTIONAL operation, hence some implemations might not support it.

         Appendix E: Processing IPP Attributes supported,
              the Printer object SHALL return these generated messages in the
              Printer's configured natural language as specified by the
              Printer's "printer-natural-language " attribute" (see Section 15) describes the
         rules
              4.4.15).

              For other Printer 'text' and issues surrounding either 'name' attributes supplied by the acceptance
              operator, system administrator, or rejection of a
         create request.

         At job submission time, manufacturer, i.e., for
              "printer-name" (name), "printer-location" (text), "printer-info"
              (text), and "printer-make-and-model" (text), the Printer does not need object
              is only required to validate the
         document data or support the actual contents configured natural language of
              the URI reference to document
         data (in Printer identified by the case Printer's "printer-natural-language
              " attribute, though support of a Print-URI).  The additional natural languages for
              these attributes is permitted

              If the Printer SHOULD check object does not support the
         syntax of natural language value
              supplied by the URI to make sure that it appears to be a valid URI.
         However, other checks are essentially useless,since they require
         actually parsing and interpreting all of client, the print data, Printer object SHALL either (1)
              reject the request and return status code ' client-error-natural-
              language-not-supported' or in (2) accept the
         case of a URI, checking for availability at Job submission time does
         not guarantee availability at Job processing time. natural language rather
              than returning an error, depending on implementation.  In other words,
         even if the checks were made a Job submission time, they MUST also be
         done later at Job processing time, since at job processing time,
              latter case, the Printer might discover any of object SHALL use the following conditions:

           - additional runtime errors method for
              representing exception natural languages in attribute values as
              described for the document data,
           - some nested document data  is 'text' attribute syntax in an unsupported format,

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           - the URI reference is no longer valid (i.e., the server hosting
              the data might be down), or
           - Section 4.1.1 for
              any other run-time job processing error

         At this point, such 'text' or 'name' attributes that the Printer is unable (1) accepts
              from or (2) returns to return an error status code in a client.

              See the create response, since it had already sent 'naturalLanguage' attribute syntax description in Section
              4.1.8 for the create response
         with a successful status code.  In this case, syntax and semantic interpretation of the Printer, depending
         on values of
              this attribute and for example values.

         3.1.3.2 Response Operation Attributes

         The Printer object SHALL supply and the error, can set client SHALL support the "job-state", "job-state-reasons", or "job-
         state-message"
         following MANDATORY operation attributes to in every IPP operation
         response:

           "attributescharset" (charSet):
              This operation attribute identifies the appropriate value(s) so charset used by any
              'text' and 'name' attributes that later
         queries can report the correct job status.  Also, if Printer object is returning

                                 Expires April 14, 1998
              in this response.  The value in this response SHALL be the client has
         requested notification for 'job-problems', same
              value as the Printer could notify "attributes-charset" operation attribute supplied by
              the client via in the address(es) request.  See "attributes-charset" described in
              Section 3.1.3.1 above.

              If the "notify-addresses" attribute.

         3.2 Printer Operations

         3.2.1 Print-Job Operation

         When an end user desires object supports more than just the 'utf-8'
              charset, the Printer object SHALL be able to submit a print job with only one Document, code convert between
              each of the client uses a Print-Job operation.   A Print-Job operation differs
         from charsets supported on a Print-URI operation highest fidelity possible
              basis in that a Print-Job operation contains the
         document data order to be printed return the 'text' and 'name' attributes in the
              charset requested by the client.  However, some information loss
              MAY occur during the charset conversion depending on the charsets
              involved.  For example, the Printer object may convert from a Print-URI operation only contains a
         reference
              UTF-8 'a' to the document data.  A Validate-Job operation contains no
         data, only a set US-ASCII 'a' (with no loss of Job Template and Document attributes whose values
         can be validated for consistency. information),  from
              an ISO Latin 1 CAPITAL LETTER A Create-Job operation is similar
         as well, however WITH ACUTE ACCENT to US-ASCII 'A'
              (losing the Create-Job Request is used to create accent), or from a multi-
         Document Job.

         3.2.1.1 Print-Job Request

         The following sets of attributes are supplied as UTF-8 Japanese Kanji character to
              some ISO Latin 1 error character indication such as part of '?', decimal
              code equivalent, or to the
         Print-Job Request:

         Operation Attributes

           "job-name" (name): absence of a character, depending on
              implementation.

           "attributes-natural-language" (naturalLanguage):
              This OPTIONAL attribute identifies the client supplied is a MANDATORY Job name.
              If this Template attribute is supplied, its value it used for the "job-
              name" Printer object
              to return.  This attribute of specifies the newly created Job object. If natural language used by
              'text' and 'name' attributes with empty tags in this
              attribute is not response and
              SHALL be the same value as supplied by the client, the Printer generates a
              name to use client in the "job-name" attribute of the newly created Job
              object (see Section 4.3.4).

           "ipp-attribute-fidelity" (boolean):
              This is an OPTIONAL attribute.  If not supplied, request,
              whether the Printer
              assumes the value is 'false'.  The value 'true' indicates object supports that
              total fidelity to client supplied attributes and values is
              required. The value 'false' indicates or not.  Any
              'text' or 'name' values in this response that have a reasonable attempt

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              to print the Job is acceptable.  All implementations support both
              types of job processing.  See section 15 for different
              natural language SHALL have a full description
              of "ipp-attribute-fidelity" and its relationship fully specified natural language
              tag pre-pended to other
              attributes, especially the Printer's "pdl-override" attribute.

           "document-name" (name):
              This OPTIONAL each such attribute identifies value.

              In a subsequent query request (Get-Attributes or Get-Jobs), the client supplied Document
              name.  If this
              Printer object NEED NOT convert any 'text' or 'name' attribute is supplied, its value it used for
              values to the
              "document-name" attribute natural language of the newly created Document object.
              If this attribute requester when it is not supplied by
              different from that specified (and subsequently stored) in the client,
              original create request..  In such cases, the Printer
              optionally generates a name to use in the "document-name" object
              SHALL return an explicit natural language indicator for each such
              attribute of value.  See the newly created Document object (see 'text' attribute syntax description in
              Section 4.4).

              ISSUE: Since this is part 4.1.1.

         3.1.4 Operation Status Codes and Messages

         Every operation response returns a MANDATORY status code and an
         OPTIONAL status message. A status code provides information on the
         processing of a Print-Job that creates only request.  A status message provides a
              single Document, should we
              not allow this attribute?

         Job Template Attributes

              An optional set short textual
         description of Job Template attributes as defined in section
              4.2.  If the client supplies no Job Template attributes in the
              Print-Job Request, the Printer uses the values set in its default
              value attributes at job processing time (not job submission
              time).

         Document Attributes:

              An optional set status of Document Attributes as defined in section 4.4.
              If "document-format" is not supplied, the Printer assumes that the document data operation.  The status code is in a format that this acceptable to the
              Printer.  If
         intended for use by automata and the "document-format" status message is unknown intended for a certain
              document,
         the human user.  If a response does include a status message, an IPP
         client SHALL NOT supply is not required to examine or display the attribute status message,
         however it SHOULD do so in some implementation specific manner.

                                 Expires April 14, 1998
         Section 13 describes the create
              request or status codes and suggests a corresponding
         status message for each status code.  In some cases, if the Send-Document Request.

         Document Content

              The client MUST supply the document data to status
         code indicates an error, there may be processed.

         Note: Since all Print-Job Request additional attributes are OPTIONAL, in the
         simplest Print-Job Request consists of just
         response that are not returned in the Document Content and
         nothing else.  In this case, successful case.  One such
         example is the Printer creates a new Job object and
         stores a generated Job name set of unsupported attributes in the "job-name" attribute. Print-Job response
         (see section 3.2.1.2).

         The Job
         contains status code is a single Document. numeric value that has semantic meaning.  The Printer optionally generates
         status code is similar to a name

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         the Document and stores it in "type2 enum" (see section 4.1 on
         "Attribute Syntaxes") except that values can range only from 0x0000 to
         0xFFFF.

         A client implementation of IPP could convert status code values into
         any localized string that has semantic meaning to the "document-name" attribute. end user.  The
         Printer assumes that object SHALL be able to generate this message in any of the document data is
         natural languages identified by the Printer's "natural-language-
         supported" attribute (see the "attributes-natural-language" operation
         attribute specified in a format supported Section 3.1.3.1).  If the charset requested by
         the
         Printer.  When client in the Printer processes "attributes-charset" operation attribute is not
         supported by the Job, it uses all of its
         default values for Printer object, the missing Job Template attributes.

         3.2.1.2 Print-Job Response

         The Printer object SHALL return to represent
         the client status message, if returned, in the following sets of
         attributes as part of charset specified by the Print-Job Response:

         Operation Attributes

           "job-uri" (uri):
              A URI which
         Printer's "printer-charset" attribute (which the client SHALL use MAY not be
         able to interpret).

         3.1.5 Security Concerns for all other operations on this
              Job.  This is the MANDATORY "job-uri" attribute.

              ISSUE: Can this just be a "Job Status Attribute"?

         Job Status Attributes

           "job-name":
              This IPP Operations

         3.1.5.1 Authenticated Requester Identity

         IPP is layered on top of security services that supply the Job's "job-name" attribute.

           "job-state":
              This requester's
         identity.  It is assumed that the Job's "job-state" attribute. The value of  this
              attribute identity supplied by the
         authentication service is taken from the most authenticated identity required by
         a "snapshot" of given site's configuration and current policy.  It is also assumed
         that the new Job object
              sometime after layering allows for a single IPP implementation to be run
         over a consistent interface that supplies the time authenticated identity.
         The authentication interface should allow for various modular and
         extensible authentication service implementations without requiring
         changes to the Printer receives IPP implementation.

         Once the print request
              until just prior to returning authenticated identity of the response requester has been supplied to
         the client.

           "job-state-reasons":
              This is IPP implementation, the Job's "job-state-reasons" attribute.  The value of
              this attribute is taken from implementation uses that identity to
         enforce any authorization policy(ies) that might be in place.  When a "snapshot" of the new
         Job object
              sometime after is created, the time identity of the Printer receives requester from the print create request
              until just prior to returning the response to the client.

           "job-state-message":
              This
         is persistently stored in the Job's "job-state-message" "job-originating-user" attribute.  Since the "job-
              state-message"
         This attribute is OPTIONAL can be used to match the requester's identity of
         subsequent operations on that Job attribute, itis
              OPTIONALLY included in order to enforce the response.

              Note: Since any printer state information which affects local
         authorization policy(ies), if any. For example, a job's
              state is reflected in one site's policy
         might be that only the "job-state" and "job-state-reasons"
              attributes, it job owner is sufficient allowed to return only these attributes and
              no specific printer cancel a job.  There
         are operation status attributes.

         deBry, Hastings, Herriot, Isaacson, Powell codes that allow an implementation to return

                                 Expires February xx, April 14, 1998
         Unsupported Attributes:

              This is a set
         information back to the operation requester about what has been
         forbidden, not allowed, or not authorized.  The details of attributes and attribute values that
         mechanisms to set up authorization policy(ies) are
              unsupported.  This output parameter is only not part of IPP,
         and must be established via some mechanism outside the scope of IPP.

         3.1.5.2 Restricted Queries

         In many of these IPP operations, a client supplies a list of
         attributes to be returned in the
              response if the status code indicates response.  A Printer may be
         configured, for security reasons, not to return all attributes that there was such an
              error.

         Note: The simplest response consists a
         client requests.  It may even return none of the just the job URI ("job-
         uri") and requested attributes.
         In such cases, the Job Status attributes with a status code of "successful-
         ok".

         3.2.2 Print-URI Operation

         This operation returned is identical to the Print-Job operation (section 3.2.1)
         except that a same as if the Printer had
         returned all requested attributes.  The client supplies cannot tell by such a URI reference to the document data
         using
         response whether the "document-uri" (uri)  operation requested attribute rather than
         including was present or absent on the document data itself.  It
         Printer or Job.

         3.1.6 Versions

         Each operation request carries with it a version number. Each version
         number is up to in the IPP server to
         interpret form "X.Y" where X is the URI major version number and subsequently "pull" Y
         is the document from minor version number. By including a version number in the source
         referenced by the URI string.

         3.2.3 Validate-Job Operation

         This operation is similar to
         client request, it allows the Print-Job operation (section 3.2.1)
         except that a client supplies no document data and (the requester) to identify which
         version of IPP it is interested in using. If the Printer
         allocates no resources (i.e., it does not create
         support that version, the Printer responds with a new Job object).
         This operation is used only to verify capabilities status code of a printer object
         against whatever attributes are supplied by the client in the
         Validate-Job request.
         'server-error-version-not-supported'.

         There is no "job-uri" attribute returned in version negotiation per se. However, if after receiving a
         version not supported status code from the
         Validate-Job Response neither are Printer, there any Job Status attributes
         returned in the response.  The is nothing
         that prevents a client MAY include from trying again with a "document-uri"
         attribute in the request.  In this case, the Printer SHOULD only
         validate the syntax of the URI rather than follow the reference different version
         number. For example, a client might be configured to support IPP
         version 3.0, 2.5, 2.0 and
         validate the contents of the reference. 1.0 (hypothetically speaking). A client
         might first try to speak version 3.0. If all after receiving a version not
         supported, it might successively try version 2.5, then 2.0, and then
         1.0. All implementations MUST support version 1.0.

         There is well, only one version number that covers both IPP Model and the Printer
         returns
         IPP Protocol changes. Thus the status code "successful-ok".  Otherwise, version number MUST change when
         introducing a new version of the Printer
         returns Model document or a set new version of unsupported attributes and
         the appropriate error
         status code.

         3.2.4 Create-Job Operation

         This operation is similar Protocol document.

         Changes to the Print-Job operation (section 3.2.1)
         except that a client supplies no document data major version number indicate structural or any reference syntactic
         changes that make it impossible for older version IPP processors to
         document data in
         correctly parse and interpret the Create-Job request.  This operation is followed
         by one or more Send-Document new or Send-URI operations. changed attributes,
         operations and responses. If the major version number changes, the
         minor version numbers is set to zero. One example that would have
         required a Printer
         object supports change to the Create-Job operation, it MUST also support either major version number would have been adding
         the Send-Document operation or "ipp-attribute-fidelity" attribute if it had not been part of
         version 1.0. Items that might affect the Send-URI operation or both.  Since
         a client can query changing of the Printer's "operations-supported" attribute, a
         client SHOULD NOT attempt to use an unsupported optional operation.

         deBry, Hastings, Herriot, Isaacson, Powell major version

                                 Expires February xx, April 14, 1998
         3.2.5 Get-Attributes Operation

         The Printer Get-Attributes operation allows a client
         number include any changes to obtain
         information from a Printer object. In the operations protocol specification itself such
         as:

           - reordering of ordered attributes in a
         request, or attribute sets
           - changes to the client supplies syntax of existing attributes
           - changing OPTIONAL to MANDATORY and vice versa

         Changes to the set minor version number indicate the addition of new
         features, attributes and attribute names and/or
         attribute group names in values that may not be understood
         by all IPP processors, but which can be ignored if not understood.
         Items that might affect the requester is interested.  In changing of the
         operation attribute in minor version number
         include any changes to the response, model objects and attributes but not the Printer returns
         protocol specification itself, such as:

           - grouping all extensions not included in a
         corresponding attribute set with the appropriate previous version into a
              new version
           - formally adding in new attribute values
         filled in.

         For Printers, the attribute groups include:
           - 'job-template': all changing any of the Job Template type1 attributes that apply

         3.1.7 Job Creation Operations

         In order to "submit a Printer object (the last two columns print job" and create a new Job object, a client
         issues a create request.  A create request is any one of the table in Section
              4.2). following
         three operation requests:

           - 'printer-description': the attributes specified in Section 4.5.

         There is also the special group 'all' which includes all supported
         attributes.

         It is NOT REQUIRED The Print-Job Request: A client that a Printer support all attributes belonging wants to submit a group, however it is MANDATORY that each Printer implementation
         understand all group names.

         3.2.5.1 Get-Attributes Request print job
              with only a single document uses the Print-Job operation. .  The following sets of attributes are part of
              operation allows for the Get-Attributes
         Request when client to "push" the request is directed document data to a
              the Printer object:

           Operation Attributes"requested-attributes" (1setOf keyword) :
              An optional set of attribute names (without values) or attribute
              group names in whose values by including the requester is interested.  If document data in the request itself.

           - The Print-URI Request: A client omits this input parameter, that wants to submit a print job
              with only a single document where the Printer SHALL respond as
              if "pulls" the
              document data uses the Print-URI operation.   In this input parameter had been supplied with case, the
              client includes only a value of 'all'.

           "document-format" (mimeType) :
              This input parameter is useful for determining the set of
              supported attribute values which relate URI reference to the requested document
              format. data (not
              the document data itself).

           - The Printer SHALL return only (1) those attributes Create-Job Request: A client that
              are supported and (2) wants to submit a print job
              with multiple documents uses the attribute values that are supported Create-Job operation. . This
              operation is followed by an arbitrary number of Send-Document or
              Send-URI operations (each creating another document for the specified document format.  By specifying newly
              create Job object).  The Send-Document operation includes the
              document
              format, data in the request (the client can get "pushes" the Printer document
              data to eliminate the
              attributes printer), and values that are not supported for a specific
              document format.  For example, the Send-URI operation includes only a Printer might have multiple
              interpreters
              URI reference to support both 'application/postscript' (for
              PostScript) and 'text/plain' (for text) documents.  However, for
              only one of those interpreters might the document data in the request (the Printer be able
              "pulls" the document data from the referenced location).  The
              last Send-Document or Send-URI request for a given Job object
              includes a "last-document" operation attribute set to
              support "number-up" with values of 'one', 'two', and 'four'.  For

         deBry, Hastings, Herriot, Isaacson, Powell 'true'
              indicating that this is the last document.

                                 Expires February xx, April 14, 1998
         Throughout this model specification, the other interpreter it might be able term "create request" is used
         to refer to any of these three operation requests.

         A Create-Job operation followed by only support "number-
              up" with one Send-Document operation is
         semantically equivalent to a value of 'one'.

              If Print-Job operation, however, for
         performance reasons, the client omits this input parameter, the Printer SHALL
              respond as if SHOULD use the input parameter had been set to Print-Job operation for
         all single Document Jobs.  Also, Print-Job is a MANDATORY operation
         (all implementations MUST support it) whereas Create-Job is an
         OPTIONAL operation, hence some implementations might not support it.

         Section 15 describes the value of rules and issues surrounding the Printer's default value "document-format" attribute were
              supplied.  It processing
         and either the acceptance or rejection of a create request.

         Job submission time is recommended that the point in time when a client always supply issues a
              value for document-format, since create
         request.  The initial state of every Job object is the Printer's default value for
              document-format may be 'langAutomatic', in which case 'pending' or
         'pending-held' state.  Later, the
              returned attributes and values are for Printer object begins processing the union of
         job.  At this point in time, the document
              formats Job object's state moves to
         'processing'.  This is known as job processing time.  There are
         validation checks that must be done at job submission time and others
         that must be performed at job processing time.

         At job submission time and at the time a Validate-Job operation is
         received, the Printer can automatically sense.

              ISSUE: What about MIME types.

         3.2.5.2 Get-Attributes Response

         The Printer returns MUST do the following sets of following:

           1. Process the client supplied attributes as part of using the
         Get-Attributes Response:

         Requested Attributes

              This is rules supplied
              in section 15 and either accept or reject the set request
           2. Validate the syntax of requested attributes and their current values.
              The Printer ignores (does not respond with) support for the scheme of any requested
              attribute which is not supported.

         3.2.6 Get-Jobs Operation

         The Get-Jobs operation allows a client to retrieve
              supplied URI

         At job submission time the list of Jobs
         belonging to the target Printer object.  The client may also supply a
         list of Job attribute names or attribute group names.  These Job
         attributes will be returned SHOULD NOT perform the validation
         checks reserved for each Job that is returned.

         This operation is like Get-Attributes, except that Get-Jobs operation
         returns attributes from possibly more than one object (see job processing time such as:

           1. Validate the
         description document data
           2. Validate the actual contents of attribute groups in section 3.3.4).

         3.2.6.1 Get-Jobs Request

         The any client submits supplied URI (resolve
              the Get-Jobs request reference and follow the link to a Printer URI.

         The following sets of attributes the document data)

         At job submission time, these additional job processing time
         validation checks are part of essentially useless, since they require actually
         parsing and interpreting the Get-Jobs Request:

         Operation Attributes

           "limit" (integer):
              This is an integer value that indicates a limit document data, are not guaranteed to be
         100% accurate, and must yet be done again at job processing time.
         Also, in the number case of
              Jobs returned.  The limit is a "stateless limit" in URI, checking for availability at job
         submission time does not guarantee availability at job processing
         time.   In addition, at job processing time, the Printer object might
         discover any of the following conditions that if were not detectable at
         job submission time:

           - runtime errors in the

         deBry, Hastings, Herriot, Isaacson, Powell document data,

                                 Expires February xx, April 14, 1998
              limit
           - nested document data that is n then only the first n jobs are returned in an unsupported format,
           - the Get-
              Jobs Response; there URI reference is no mechanism to allow for longer valid (i.e., the "next" n
              jobs.  The limit applies across all Job States requested.  For
              example, if server hosting
              the limit document might be down), or
           - any other job processing error

         At job processing time, since the Printer has already responded with a
         successful status code in the response to the create request, if 50, and there are 75 spooled jobs, only the first 50  jobs are returned;
         Printer object detects an error, the other 25 jobs are not
              returned.

           "requested-attributes" (1setOf keyword):
              An optional set of Job attribute names or attribute groups names Printer object in whose values unable to
         inform the requester is interested.  This set end user of
              attributes is returned for each Job that is returned..  The
              attribute group names are the same as for error with an operational status code.   In
         this case, the Get-Attributes
              operation for Printer, depending on the Job object.  If error, can set the client omits this input
              parameter, "job-
         state", "job-state-reasons", or "job-state-message" attributes to the
         appropriate value(s) so that later queries can report the correct job
         status.

         3.2 Printer SHALL respond as if this input parameter
              had been supplied with a value of " 'job-uri'.

         3.2.6.2 Get-Jobs Response

         The Operations

         All Printer returns zero or more Job objects each with zero or more
         attributes.  There is a set operations are directed at Printer objects.  A client MUST
         always supply the "printer-uri" attribute in order to identify the
         correct target of requested attributes for each Job.
         After each Job, there the operation.  In HTTP/1.1 mapping of IPP, this
         attribute is a set not supplied in the body of requested the operation as other
         operation attributes for each
         Document are.  It is supplied in the Job.  For example:

              Job 1
                   Document 1A
              Job 2
                   Document 2A
                   Document 2B
                   Document 2C
              Job 3
                   Document 3A
              Job 4
              Job 5
                   Document 5A
                   Document 5B

         Jobs are returned "request-URI" field
         in the following order: First all active Jobs (Jobs
         in the 'pending', 'processing', 'pending-held', and 'processing-
         stopped' states) are returned oldest to newest (with respect HTTP header.

         3.2.1 Print-Job Operation

         When an end user desires to
         expected completion time).  Next, all completed Jobs (Jobs in submit a print job with only one document
         and the
         'completed', 'aborted', or 'canceled' states) newest to oldest (with
         respect client supplies the document data (rather than just a
         reference to actual completion time).  Jobs that the data), the client uses a Print-Job operation.

         3.2.1.1 Print-Job Request

         The following groups of attributes are in supplied as part of the 'pending-
         held' state SHALL appear in their position Print-
         Job Request:

         Group1: Operation Attributes

           Target:
              The "printer-uri" target for this operation as if they were 'pending'
         (otherwise, a user might be confused by Jobs that move from 'pending-
         held' to 'pending' described in
              section 3.1.2.

           Natural Language and Character Set:
              The "attributes-charset" and "attributes-natural-language"
              attributes as seeming to jump ahead described in section 3.1.3.1.

           "job-name" (name):
              This attribute is OPTIONALLY supplied by the queue). Note:  Jobs
         are returned in client, and it
              contains the following order:

         deBry, Hastings, Herriot, Isaacson, Powell client supplied Job name.  If this attribute is

                                 Expires February xx, April 14, 1998
           First, all active Jobs (Jobs in
              supplied, its value it used for the 'pending', 'processing',
              'pending-held', and 'processing-stopped' states) are returned
              oldest to newest (with respect to expected completion time),
              followed "job-name" attribute of the
              newly created Job object. If this attribute is not supplied by
           Second, all completed Jobs (Jobs in
              the 'completed', 'aborted', or
              'canceled' states) newest to oldest (with respect to actual
              completion time).  Jobs that are in client, the 'pending-held' state
              SHALL appear in their position as if they were 'pending'
              (otherwise, Printer generates a user might be confused by Jobs that move from
              'pending-held' to 'pending' as seeming name to jump ahead use in the
              queue).

         3.3 Job Operations

         The target "job-name"
              attribute of Job operations are Job objects.  Since Job objects are
         identified with both the Printer's URI and the "job-id" attribute, the
         following applies rules apply to all newly created Job operations:

           - The Printer's URI object (see Section 4.3.4).

           "document-name" (name):
              This attribute is encoded at OPTIONALLY supplied by the transport level client, and it
              contains the same as
              all Printer operations
           - The "job-id" attribute is included as an operation attribute for
              all Job operations.
         3.3.1 Send-Document Operation

         Once a Job object has been created using a Create-Job operation
         (returning a "job-uri"), a client directs a Send-Document operation to
         the newly create Job object. supplied document name.  The operation adds a new Document to the
         Job object. An entire document MUST name
              MAY be sent in a single Send-Document
         Request.

         3.3.1.1 Send-Document Request

         The client submits different than the request to a Job URI.

         The following attribute sets are part of the Send-Document Request:

         Operation Attributes:

           "document-name" (name):
              This OPTIONAL attribute identifies name.  Typically, the client supplied Document
              software automatically supplies the document name on behalf of
              the end user by using a file name or an application generated
              name.  If this attribute is supplied, its value it can be used for the
              "document-name" attribute of in a
              manner defined by each implementation.  Examples include: printed
              along with the newly created Document object.
              If this attribute is not supplied Job (banner page, page adornments, etc.), used by
              accounting or resource tracking management tools, or even stored
              along with the client, document as a document level attribute.  IPP/1.0
              does not support the Printer
              optionally generates concept of document level attributes,
              however, a name vendor specific extension to use in IPP/1.0 might support the
              document level attributes.  In this case, the "document-name"
              attribute of could be persistently stored along with the newly created Document document
              and queried using a Get-Attributes operation on the Job object (see Section ??).

           "last-document"
              that includes a request for document level attributes or some
              other private extension mechanism.

           "ipp-attribute-fidelity" (boolean):

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              This attribute is a boolean flag that is set to 'true' if this is the last
              Document for OPTIONALLY supplied by the Job.
         Document Attributes:

              An optional set of Document Attributes as defined in section 4.4. client. If "document-format" is not
              supplied, the Printer object assumes that the document data value is in a format 'false'.  The
              value 'true' indicates that this acceptable total fidelity to the
              Printer.  If the "document-format" is unknown for a certain
              document, the client SHALL NOT supply the attribute in the create
              request or the Send-Document Request.

         Document Content supplied
              attributes and values is required. The client MUST supply the document data value 'false' indicates
              that a reasonable attempt to be processed.

         3.3.1.2 Send-Document Response

         The following sets of attributes are part of print the Send-Document
         Response: Job Status Attributes

           "job-name":
              This is acceptable.  All
              Printer objects MUST support both types of job processing.  See
              section 15  for a full description of "ipp-attribute-fidelity"
              and its relationship to other attributes, especially the Job's "job-name" Printer
              object's "pdl-override" attribute.

           "job-state":

           "document-charset" (charSet):
              This attribute is OPTIONALLY supplied by the Job's "job-state" attribute. The value of client.  A Printer
              object SHALL support this attribute is taken from if it supports a "snapshot" of the new Job object
              sometime after document-
              format that requires a character set to be identified in order to
              unambiguously interpret the time document, such as 'text/plain'.
              There are no particular values required for the Printer receives the print request
              until just prior object to returning
              support.  This attribute specifies the response to the client.

           "job-state-reasons":
              This is the Job's "job-state-reasons" attribute.  The value charset of
              this attribute is taken from the document
              for those document-formats that require a "snapshot" specification of the new Job object
              sometime after the time
              charset in order to image the Printer receives document unambiguously.  If the print request
              until just prior to returning
              value of the response to "document-format" attribute contains a charset
              parameter (see 'mimeType' attribute syntax in Section 4.1.9), the client.

           "job-state-message":
              This is
              client SHALL also supply the Job's "job-state-message" attribute.  Since "document-charset" attribute and its
              value SHALL be the "job-
              state-message" same.

                                 Expires April 14, 1998
           "document-natural-language" (naturalLanguage):
              This attribute is OPTIONAL Job attribute, itis OPTIONALLY included in supplied by the response.

         Unsupported Attributes:

              This is a set of attributes and attribute client.  There are
              no particular values that are
              unsupported. required for the Printer object to
              support.   This output parameter is only returned in attribute specifies the

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              response if natural language of the status code indicates
              document for those document-formats that there was such an
              error.

         3.3.2 Send-URI Operation

         This operation is identical require a specification
              of the natural language in order to image the Send-Document operation (see
         section 3.3.1) except that a document
              unambiguously.

         Group2: Job Template Attributes

              The client OPTIONALLY supplies a URI reference
         ("document-uri" operation attribute) rather than set of Job Template attributes
              as defined in section 4.2. See section 15  for a full description
              of Job Template attributes.

         Group 3: Document Content

              The client MUST supply the document data
         itself.  It is up to the IPP server to interpret be processed.

         Note: The simplest Print-Job Request consists of just the URI Document
         Content and
         subsequently "pull" the document from the source referenced by nothing else.  In this case, the URI
         string.

         3.3.3 Cancel Printer object:

           - creates a new Job Operation

         This operation allows object (the Job object contains a client to cancel single
              document),
           - stores a Print generated Job any time after name in the print job has been submitted to "job-name" attribute,
           - assumes that the Printer.  Since document data is in a supported format, and
           - uses its corresponding default value attributes for missing Job might
         already be printing by the time a Cancel-Job is received, some pages
         may be printed before
              Template attributes and embedded instructions in the job is actually terminated.

         3.3.3.1 Cancel-Job Request document
              data.

         3.2.1.2 Print-Job Response

         The Printer SHALL return to the client submits the request to a Job URI.

         The following attribute sets are of
         attributes as part of the Cancel Job Request: Print-Job Response:

         Group 1: Operation Attributes

           "message" (text):
              Optional message to

           Status Code and Message:
              The response includes the operator

         3.3.3.2 Cancel-Job Response

         There are no MANDATORY status code and an OPTIONAL
              "status-message" (text) operation attribute as described in
              section 3.1.4.

           Natural Language and Character Set:
              The "attributes-charset" and "attributes-natural-language"
              attributes as described in the Cancel section 3.1.3.2.

                                 Expires April 14, 1998
         Group 2: Job Response other than Object Attributes

           "job-uri" (uri):
              The Printer object MUST return the
         Status Code and optional Status Message.  Once a successful response
         has been sent, Job object's MANDATORY  "job-
              uri" attribute.

           "job-id":
              The Printer object MUST return the implementation guarantees that Job object's MANDATORY  "job-
              id" attribute.

           "job-state":
              The Printer object MUST return the Job will
         eventually end up in object's MANDATORY "job-
              state" attribute. The value of this attribute (along with the 'cancelled' state.  If
              value of the implementation next attribute "job-state-reasons") is
         forced to leave the job in taken from a
              "snapshot" of the new Job object at some other state, meaningful point in time
              (implementation defined) between when the "job-state-
         reasons" SHOULD contain Printer object receives
              the 'processing-to-stop-point' value which
         indicates to later queries that although Print-Job Request and when the Printer object returns the
              response.

           "job-state-reasons":
              The Printer object OPTIONALLY returns the  Job may still be
         'processing', object's OPTIONAL
              "job-state-reasons" attribute. If the Printer object supports
              this attribute  then it will eventually end up MUST be returned in the 'cancelled' state, response.  If
              this attribute is not returned in the response, the 'completed' state.

         3.3.4 Get-Attributes Operation

         The Job Get-Attributes operation allows a client to obtain information
         from can
              assume that the "job-state-reasons" attribute is not supported
              and will not be returned in a subsequent Job object and it is almost identical to the Get-Attributes

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         operation for a query.

           "job-state-message":
              The Printer object (see section 3.2.5).  The only
         differences are that OPTIONALLY returns the operation is directed at a Job rather than a object's OPTIONAL
              "job-state-message" attribute. If the Printer and there is no "document-format" operation object supports
              this attribute used
         when querying a Job object.

         For Jobs, then it MUST be returned in the response.  If this
              attribute groups include:

           - 'job-template': all of is not returned in the Job Template attributes response, the client can assume
              that apply to the "job-state-message" attribute is not supported and will
              not be returned in a subsequent Job object (the first column of query.

           "number-of-intervening-jobs":
              The Printer object OPTIONALLY returns the table in Section 4.2).
           - 'job-description': Job object's OPTIONAL
              "number-of-intervening-jobs" attribute.  If the attributes specified Printer object
              supports this attribute then it MUST be returned in Section 4.3.

         There is also the special group 'all' which includes all supported
         attributes.

         There response.
              If this attribute is another special group named 'document-attributes' which
         consists of the Document Attributes described not returned in section 4.4. If the response, the client can
              assume that the "number-of-intervening-jobs" attribute is not
              supported and will not be returned in a subsequent Job object
              query.

              Note: Since any
         Document Attributes are requested, printer state information which affects a job's
              state is reflected in the response contains "job-state" and "job-state-reasons"
              attributes, it is sufficient to return only these attributes and
              no specific printer status attributes.

                                 Expires April 14, 1998
         Group 3: Unsupported Attributes

              This is an OPTIONAL set of attributes.  It is a separate set of Document Job
              Template attributes for each Document in supplied by the Job.

         3.3.4.1 Get-Attributes Request

         The following attribute sets client (in the request) that
              are part of not supported by the Get-Attributes Request
         when Printer object. When the Printer object
              rejects the request is directed to a Job object:

         Operation Attributes:

           "requested-attributes" (1setOf keyword) :
              An optional set because of more than one unsupported
              attribute names (without values) or attribute
              group names in whose values (see section 15), it SHOULD return all of the requester
              unsupported attributes.  Some implementations may choose to only
              return the first unsupported attribute that is interested.  If encountered during
              the
              client omits this attribute, processing of the Printer SHALL respond as if this
              input parameter had been supplied attributes, but that may lead to additional
              requests with a value of 'all'.

         3.3.4.2 Get-Attributes Response

         The implementation returns only one "fixed" attribute from the following response attributes as part set of problem
              attributes.  In the Get-Attributes Response: case where the Printer object accepts the
              request and creates a Job Attributes:

              This is object, the Printer MUST return the set
              of requested unsupported attributes and their current values.
              The implementation ignores (does not respond with) any requested where substitutions were made or the
              attribute which is not supported.

         Document Attributes:

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              This is the set of requested was completely ignored.

              Unsupported attributes and their current values. fall into two categories:

              1. The implementation ignores (does Printer object does not respond with) any requested support the named attribute which is (no
              matter what the value), or
              2. The Printer object does supports the attribute, but not supported.  One set is returned for each
              Document in the Job.

         4. Object Attributes

         This section describes
              particular value supplied by the client (i.e., the Printer does
              not have that value in the attributes with their corresponding
         syntaxes and supported values that are part of
              attribute).

              In the IPP model. The sections below
         show case of an unsupported attribute name, the objects and their associated attributes which are included
         within Printer object
              returns the scope of this protocol.  Many client supplied attribute with a substituted special
              value of these attributes are
         derived from other relevant specifications:

           - ISO/IEC 10175 DPA (Final, June 1996) [5]
           - RFC 1759 Printer MIB (Proposed Standard, May 1995) [1]
           - Internet-Draft: Printer MIB (Draft Standard in progress, July
              1997) [29]
           - Internet-Draft: Job Monitoring MIB (I-D in progress, June 1997)
              [27]

         Each 'unsupported' indicating no support for the attribute is uniquely identified in this document using
              itself. In the case of a
         "keyword" (see section 11.2.1).  The keyword is included in supported attribute with an unsupported
              value, the
         section header describing that Printer object simply returns the client-supplied
              attribute. Not only are attributes
         uniquely identified with keywords, some attributes are defined to have
         a syntax which is a set of keywords.

         4.1 Attribute Syntaxes  This section defines indicates support for the basic syntax types attribute, but no
              support for that a client and server
         SHALL be able to handle.  These are considered to be a set of type2
         enum values. particular value.

         Note: The values are:

           '1'     'text':  a sequence of characters, length: 0 to 4095,  where
                        each character is a member simplest response consists of the ISO 10646 [??] coded
                        character set using just the UTF-8 character encoding scheme
                        [28].. MANDATORY Job
         Attributes and a status code of "successful-ok".

         3.2.2 Print-URI Operation

         This syntax type is used for free form human
                        readable text intended for human consumption.
           '2'     'name':  this operation is identical to the same a "text" Print-Job operation (section 3.2.1)
         except that the sequence
                        of characters is of length 1 to 255  This syntax type
                        is used for referencing some object or entity via a
                        user-friendly string, such as a Printer name, a
                        document name, a user name, or a host name.
           '3'     'keyword': client supplies a sequence of characters, length: 1 URI reference to 255,
                        containing only the characters ASCII lowercase letters
                        ("a" - "z"), ASCII digits ("0" - "9"), hyphen ("-"),
                        dot ("."), and underscore ("_").  The first character

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
                        MUST be an ASCII lowercase letter.  This syntax type is
                        used for enumerating semantic identifiers of entities
                        in document data
         using the abstract protocol (specified in this document).
                        These entities can be "document-uri" (uri) operation attribute names or values of
                        attributes.  When a keyword rather than
         including the document data itself.  It is used up to represent an
                        attribute (its name), it MUST be unique within the full
                        scope of IPP objects and attributes.  When a keyword is
                        used server to represent a value of an attribute, it MUST be
                        unique just within
         interpret the scope of that attribute.  That
                        is, URI and subsequently "pull" the same keyword can not be used for two different
                        values within document from the same attribute to mean two different
                        semantic ideas.  However, source
         referenced by the same keyword can be used
                        across two or more attributes, representing different
                        semantic ideas for each attribute.
           '4'     'enum':  an enumerated integer value URI string.  At job submission time, the Printer
         MUST validate the fact that is in it supports the range
                        from -2**31 to 2**31 - 1.   Each value has an
                        associated keyword name.  Each retrieval method (e.g.,
         http, ftp, etc.) implied by the URI.  If the Printer object supports

                                 Expires April 14, 1998
         this operation, it MUST support the "reference-uri-schemes-supported"
         attribute (whose syntax (see section 4.4.21).

         3.2.3 Validate-Job Operation

         This operation is enum) enumerates similar to the values Print-Job operation (section 3.2.1)
         except that are defined for a client supplies no document data and the
                        attribute.  The enum type Printer
         allocates no resources (i.e., it does not create a new Job object).
         This operation is used for only to verify capabilities of a printer object
         against whatever attributes for
                        which there are enum values assigned supplied by other
                        standards, such as SNMP MIBs.  A number of attribute
                        enum values the client in this specification the
         Validate-Job request.  There are also used for
                        corresponding attributes no Job Object Attributes returned in
         the IETF Validate-Job Response.  If the Printer MIB [1]
                        and supports either the Job Monitoring MIB [27].  Enums are not used
                        for attributes to which Print-
         URI or Send-URI operations, the system administrator may
                        assign values.  Values client MAY include a "document-uri"
         attribute in the range 2**30 to 2**31 - 1
                        are reserved for private or experimental use.
                        Implementers are warned request.  In this case, the Printer MUST validate
         that use of such values may
                        conflict with other implementations.  Implementers are
                        encouraged to request registration of enum values
                        following the procedures in Section 6.
           '5'     'uri':  a sequence of characters as defined in rfc1738 and
                        rfc1808.  This syntax type is used for carrying
                        Universal Resource Identifiers.
           '6'     'uriScheme':  a sequence of characters representing Printer supports the URI
                        Scheme.  These include 'http' for HTTP schemed URIs
                        (e.g., http://...), retrieval method implied by the URI, and 'ftp' for FTP schemed URIs
                        (e.g., ftp://...).
           '7'     'human-language':  a standard identifier
         SHOULD check for human language
                        and optionally a country. validate URI syntax.  The values for this syntax
                        type are taken from RFC 1766 [26].  Independent Printer NEED NOT follow the
         reference and validate the contents of the
                        human language, reference. If all text strings are strings of
                        characters where each character is a member of well,
         the ISO
                        10646 [??] coded character set.  Text strings are
                        encoded using Printer returns the UTF-8 character encoding scheme [28]
           '8'     'octetString:' status code "successful-ok".  Otherwise, the
         Printer returns a sequence set of octets.  This syntax type is
                        used for opaque data, such as unsupported attributes and/or the document-content.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           '9'     'boolean':  two values of 'true' appropriate
         error status code.  If the client supplies the "ipp-attribute-
         fidelity" attribute set to false (or does not supply the attribute at
         all) and 'false'.  This syntax
                        type is like if the Printer object returns a keywordSet, but there are only two
                        values. Note: An application might use "successful-ok-ignored-or-
         substituted-attributes", the Printer object SHOULD return all ignored
         or substituted in the Unsupported Attributes group.  In such a checkbox for
                        an case,
         the Printer object MUST return at least one attribute with this syntax type.
           '10'    'integer': indicating an integer
         unsupported attribute value that or an ignored attribute.

         3.2.4 Create-Job Operation

         This operation is in the range from -
                        2**31 similar to 2**31 - 1.  Each attribute specifies the range
                        constraint explicitly if Print-Job operation (section 3.2.1)
         except that in the range is different from Create-Job request , a client does not supply
         document data (or any reference to document data).  Also, the full range client
         does not supply any of possible integer values (e.g., 0 -
                        100 for the "job-priority" attribute).
           '11'    'dateTime':  a standard, fixed length representation "document-name", "content-charset", or
         "content-natural-language" attributes.  This operation is followed by
         one or more Send-Document or Send-URI operations.  In each of date
                        and time as defined in RFC 1514 [32] and RFC 1903 [33].
           '12'    'resolution':  a special syntax used only these
         operation requests, the client OPTIONALLY supplies the "document-
         name", "content-charset", or "content-natural-language" attributes for "printer-
                        resolution" and "printer-resolution-supported"  It
                        consists of 3 parts:  a cross feed direction resolution
                        (positive integer value),
         each document in the multi-document Job.  If a feed direction resolution
                        (positive integer value) Printer object supports
         the Create-Job operation, it MUST also support the Send-Document
         operation and also MAY support the Send-URI operation.

         3.2.5 Get-Attributes Operation

         The Printer Get-Attributes operation allows a units value.  All these
                        are taken client to obtain
         information from the a Printer MIB [1] suggested values.
           '13'    'mimeType': MIME type values as defined by RFC 2045 [??].
           '14'    '1setOf  X':  1 or more values of type X.  This syntax type
                        is used for multi-valued attributes, whose value is object. In the operations attributes in a
         request, the client supplies the set of values.  Note:  The syntax type attribute names and/or
         attribute group names in which the requester is called
                        "1setOf" to indicate that interested.  In the
         operation attribute in the response, the Printer returns a

                                 Expires April 14, 1998
         corresponding attribute set of with the appropriate attribute values SHALL NOT be
                        empty (a set of size 0).

           '15'    'rangeOf  X':  a range
         filled in.

         For Printers, the possible names of value attribute groups are:

           - 'job-template': all of type X.  This syntax type
                        is used for ordered values (numeric, lexical, etc.)
                        such as integers.

         4.2 Job Template Attributes

         Job Template attributes describe job processing behavior. the Job Template attributes are OPTIONAL (see section 11.2.3 for that apply to
              a description Printer object (the last two columns of support for OPTIONAL attributes).

         Job Template the table in Section
              4.2).
           - 'printer-description': the attributes conform to specified in Section 4.4.

         There is also the following rules.  For each Job
         Template attribute called "foo":

           1. The Printer supports a "foo-supported" attribute special group 'all' that describes
              which job processing behaviors are includes all supported by
         attributes.  Since a Printer.  A client can query the Printer and find out what behaviors are
              supported by inspecting the values of the "foo-supported"
              attribute.

           2. The Printer also supports a default value attribute MAY request specific attributes or named "foo".
              This default value attribute describes what will be done when no
              other job processing information
         groups, there is supplied by the a potential that there is some overlap.  For example,
         if a client

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              (either explicitly as an IPP attribute in requests, 'printer-name', 'printer-description', and
         'all', client is actually requesting the create request or
              implicitly as an embedded instruction within "printer-group, and once by
         inclusion in the job data).
              However, if 'all' group.   In all cases, the Printer supports either SHALL only
         return the "foo" default value attribute or the "foo-supported" attribute, once in the response.

         It is NOT REQUIRED that a Printer MUST support both.

           3. "foo" is also optionally supplied by the client in all attributes belonging to
         a create
              request.  If "foo" is supplied, the client group, however it is specifying MANDATORY that the each Printer SHALL apply thecorresponding job processing behavior implementation
         understand all group names.

         3.2.5.1 Get-Attributes Request

         The following sets of attributes are part of the Get-Attributes
         Request when the request is directed to a Printer object:

         Group 1: Operation Attributes

           Target:
              The "printer-uri" target for this Job while processing operation as described in
              section 3.1.2.

           Natural Language and Character Set:
              The "attributes-charset" and "attributes-natural-language"
              attributes as described in section 3.1.3.1.

           "requested-attributes" (1setOf keyword) :
              The client OPTIONALLY supplies a set of attribute names  and/or
              attribute group names in whose values the Job.  When "foo" requester is not supplied,
              interested.  If the client is specifying that omits this attribute, the Printer apply the default job
              processing behavior.  Since an administrator could change the
              default value after the Job has
              SHALL respond as if this attribute had been submitted (while it is
              waiting to be processed), the default value in affect supplied with a job
              processing time value
              of 'all'.

           "document-format" (mimeType) :
              The client OPTIONALLY supplies this attribute.  This attribute is used
              useful for processing a Job with no client
              supplied attribute.

         If an application wishes Printer to present an end user with a list determine the set of supported attribute
              values from which that relate to choose, the application SHOULD query the Printer for the supported values. requested document format.  The application Printer

                                 Expires April 14, 1998
              SHOULD also
         query the default value attributes. If the application then limits
         selectable values to return only (1) those value attributes that are supported, application
         guarantees supported for
              that format and (2) the attribute values supplied by the client in the  create
         request all fall within the set of that are supported values at for
              the Printer.
         When querying specified document format.  By specifying the Printer, document
              format, the client MAY enumerate each attribute by
         name in can get the Get-Attributes Request, or the client MAY just name the
         "job-template" group in order Printer to get eliminate the complete set supported
              attributes (both and values that are not supported value for a specific
              document format.  For example, a Printer might have multiple
              interpreters to support both 'application/postscript' (for
              PostScript) and default value attributes).

         The "job-priority" attribute is an example 'text/plain' (for text) documents.  However, for
              only one of a Job Template
         attribute.  It is an integer in those interpreters might the range from 1 Printer be able to 100.  A
              support "number-up" with values of '1', '2', and '4'.  For the
              other interpreter it might be able to only support "number-up"
              with a value of '1'.

              If the client can
         query omits this attribute, the Printer for the "job-priority-supported" attribute and SHALL respond as
              if the
         "job-priority" default value attribute.  The supported attribute
         contains had been supplied with a range of supported priority values which is equal value set to or
         smaller than the maximum range of 1 to 100.  The
              Printer object's "document-format-default" default value
         attribute contains the job priority value
              attribute.  It is recommended that will be used for a new
         job if the client does not always supply a
              value for "document-format", since the Printer object's
              "document-format-default" may be 'application/octet-stream', in
              which case the create request.  If returned attributes and values are for the client does supply union
              of the "job-priority" attribute, document formats that the Printer
         validates the value to make sure that it falls within can automatically sense.
              For more details, see the range description of
         supported values.  If the client-supplied value is supported, the Job
         object is created and the "job-priority" 'mimeType' attribute
              syntax in section 4.1.9.

              NOTE:  The "document-format" operation attribute is populated with a fairly
              sophisticated filtering notion that value. is not supported by many
              existing print systems or devices.

         3.2.5.2 Get-Attributes Response

         The Job object, when queried, Printer object returns the value supplied
         by following sets of attributes as part of
         the client.  If Get-Attributes Response:

         Group 1: Operation Attributes

           Status Code and Message:
              The response includes the client does not supply a "job-priority" value MANDATORY status code and an OPTIONAL
              "status-message" (text) operation attribute as described in
              section 3.1.4.

           Natural Language and Character Set:
              The "attributes-charset" and "attributes-natural-language"
              attributes as described in section 3.1.3.2.

         Group 2: Requested Printer Object Attributes

                                 Expires April 14, 1998
              This is the create request, the Job set of requested attributes and their current values.
              The Printer object is created, but no "job-
         priority" ignores (does not respond with) any requested
              attribute which is associated with the Job. not supported.

         3.2.6 Get-Jobs Operation

         The Get-Jobs operation allows a client queries
         the Printer's default value "job-priority" value to find out at what
         priority retrieve the job will be processed.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         The table below summarizes list of Jobs
         belonging to the names and relationships for all Job
         Template attributes. target Printer object.  The first column client may also supply a
         list of the table (labled "Job")
         shows the name and syntax for each Job Template attribute in the Job
         object. names or attribute group names.  These are the Job
         attributes that can optionally will be supplied by
         the client in a create request.   The last two columns (labled
         "Printer: Default Value" and "Printer: Supported Values") shows the
         name and syntax returned for each Job Template that is returned.

         This operation is similar Get-Attributes, except that this Get-Jobs
         operation returns attributes from possibly more than one object (see
         the description of attribute group names in section 3.3.4).

         3.2.6.1 Get-Jobs Request

         The client submits the Get-Jobs request to a Printer object
         (the default value attribute and object.

         The following groupsof attributes are part of the supported values attribute).  A
         "No" Get-Jobs Request:

         Group 1: Operation Attributes

           Target:
              The "printer-uri" target for this operation as described in
              section 3.1.2.

           Natural Language and Character Set:
              The "attributes-charset" and "attributes-natural-language"
              attributes as described in section 3.1.3.1.

           "limit" (integer):
              The client OPTIONALLY supplies this attribute. It is an integer
              value that indicates a limit to the table means number of Job objects
              returned.  The limit is a "stateless limit" in that if the Printer SHALL NOT support value
              supplied by the attribute
         (the attribute client is simply  'n', then only the first 'n' jobs are
              returned in the Get-Jobs Response.  There is no mechanism to
              allow for the next 'm' jobs after the first 'n' jobs.  If the
              client does not applicable). supply this attribute, the Printer object
              responds will all applicable jobs.

           "requested-attributes" (1setOf keyword):
              The second part client OPTIONALLY supplies this attribute. It is a set of Job
              attribute names or attribute groups names in whose values the
         table lists Document level attributes.  Document level
              requester is interested.  This set of attributes have is returned for
              each Job that is returned. The allowed attribute group names are
              the same semantics as those defined in the Get-Attributes operation for Job Template

         deBry, Hastings, Herriot, Isaacson, Powell
              objects. If the client does not supply this attribute, the

                                 Expires February xx, April 14, 1998
           +===================+======================+======================+
           |
              Printer SHALL respond as if the client had supplied values of
              'job-uri' and 'job-id'.

           "which-jobs" (keyword):
              The client OPTIONALLY supplies this attribute. It indicates which
              Jobs should be returned by the Printer object.  The values for
              this attribute are:

              'completed': This includes any Job Attribute     |Printer: Default Value|  Printer: Supported  |
           |                   |   Attribute          |   Values Attribute   |
           +===================+======================+======================+
           | job-sheets        | job-sheets           |job-sheets-supported  |
           | (type4 keyword)   | (type4 keyword) object whose state is
                'completed', 'cancelled', or 'aborted'.
              'not-completed': This includes any Job object whose state is
                   'pending', 'processing', 'processing-stopped', 'pending-
                   held', 'unknown'.

              If the client does not supply the attribute, the Printer object
              SHALL respond as if the client had supplied the value of 'not-
              completed'.

         3.2.6.2 Get-Jobs Response

         The Printer object returns all of the Job objects that match the
         criteria as defined by the attribute values supplied by the client in
         the request.  It is possible that no Job objects are returned since
         there may literally be no Job objects at the Printer, or there may be
         no Job objects that match the criteria supplied by the client.  If the
         client requests any Job attributes at all, there is a set of Job
         Object Attributes returned for each Job object.

         Group 1: Operation Attributes

           Status Code and Message:
              The response includes the MANDATORY status code and an OPTIONAL
              "status-message" (text) operation attribute as described in
              section 3.1.4.

           Natural Language and Character Set:
              The "attributes-charset" and "attributes-natural-language"
              attributes as described in section 3.1.3.2.

         Groups 2 to N: Job Object Attributes

              The Printer object responds with one set of Job Object Attributes
              for each returned Job object.

              For any job submitted in a different natural language than the
              natural language that the client is requesting in the Get-Jobs
              request, the Printer SHALL indicate the submitted natural
              language by returning the "job-natural-language" as the first Job

                                 Expires April 14, 1998
              object attribute, which overrides the "attributes-natural-
              language" operation attribute value being returned by the
              Printer.  If any returned 'text' or 'name' attribute includes an
              exception natural language as described in the 'text' attribute
              syntax (see Section 4.1.1), the exception natural language
              overrides the "job-natural-language" value (for the immediately
              following attribute value only).

         Jobs are returned in the following order:

           - If the client requests all 'completed' Jobs (Jobs in the
              'completed', 'aborted', or 'cancelled' states), then the Jobs are
              returned newest to oldest (with respect to actual completion
              time)
           - If the client requests all 'non-completed' Jobs (Jobs in the
              'pending', 'processing', 'pending-held', 'processing-stopped',
              and 'unknown' states), then Jobs are returned in relative
              chronological order of expected time to complete (based on
              whatever scheduling algorithm is configured for the Printer
              object).

         3.3 Job Operations

         All Job operations are directed at Job objects.  A client MUST always
         supply some means of identifying the Job object in order to identify
         the correct target of the operation.  Since Job objects can be
         identified with either a single Job URI or a combination of a Printer
         URI with a local Job ID, the following rules apply to all Job
         operation requests mapped onto HTTP/1.1:

           -  If the client chooses to identify Job objects with just the Job
              URI, this "job-uri" attribute is not supplied in the body of the
              operation as other operation attributes are.  It is supplied in
              the "request-URI" field in the HTTP header. - If the client
              chooses to identify Job objects with both a Printer URI and a
              local Job ID, the "printer-uri" attribute is not supplied in the
              body of the operation, but it is supplied in the "request-URI"
              field in the HTTP header.  The "job-id" attribute is included as
              an operation attribute.

         Since the Get-Attributes operation can be both a Printer operation and
         a Job operation, if a Printer object receives a Get-Attributes
         request, the Printer object must check for the existence of the "job-
         id" operation attribute.  If present, the operation is intended to be
         a Job operation on the corresponding Job object.  If absent, the
         operation is intended to be a Printer operation.

                                 Expires April 14, 1998
         3.3.1 Send-Document Operation

         A client uses a Create-Job operation to create a multi-document Job
         object that is initially "empty" (contains no documents).  In the
         Create-Job response, the Printer object returns the Job object's URI
         (the "job-uri" attribute) and the Job object's 32-bit identifier (the
         "job-id" attribute).  For each new document that the client desires to
         add, the client uses a Send-Document operation.  Each Send-Document
         Request contains the entire stream of document data for one document.

         Since the Create-Job and the Send-Documents that follow can occur over
         arbitrarily long periods of time, each Printer object must decide how
         long to "wait" for the next Send-Document operation.  The Printer
         object OPTIONALLY supports the "multiple-operation-timeout" attribute.
         This attribute indicates the maximum number of seconds the Printer
         object will wait for the next Send-Document operation.  If the Printer
         object times-out waiting for the next Send-Document operation, the
         Printer object MAY decide on any of the following semantic actions:

           1. Assume that the Job is an invalid job, start the process of
              changing the job state to 'aborted', and clean up all resources
              associated with the Job.  In this case, if another Send-Document
              operation is finally received, the Printer responds with an
              "client-error-not-possible" or "client-error-not-found" depending
              on whether or not the Job object is still around when it finally
              arrives.
           2. Assume that the last Send-Document received was in fact the last
              document (as if the "last-document" flag had been set to 'true'),
              close the Job, and proceed to process it (i.e., move the Job's
              state to 'pending').
           3. Assume that the last Send-Document received was in fact the last
              document, close the Job, but move it to the 'pending-held' to
              allow an operator to determine whether or not to continue
              processing  the Job by moving it back to the 'pending' state.

         Each implementation is free to decide the "best" action to take
         depending on local policy, the value of "ipp-attribute-fidelity",
         and/or any other piece of information available to it.  If the choice
         is to abort the Job, it is possible that the Job may already have been
         processed to the point that some pages have been printed.

         3.3.1.1 Send-Document Request

         The following attribute sets are part of the Send-Document Request:

         Group 1: Operation Attributes

                                 Expires April 14, 1998
           Target:
              Either the "printer-uri" plus "job-id" or "job-uri" target for
              this operation as described in section 3.1.2.

           Natural Language and Character Set:
              The "attributes-charset" and "attributes-natural-language"
              attributes as described in section 3.1.3.1.

           "document-name" (name):
              The client OPTIONALLY supplies this attribute, and it contains
              the client supplied document name.  The document name MAY be
              different than the Job name.  It might be helpful, but NEED NOT
              be unique across multiple documents in the same Job.  Typically,
              the client software automatically supplies the document name on
              behalf of the end user by using a file name or an application
              generated name.  See the description of the "document-name"
              operation attribute in the Print-Job Request (section 3.2.1.1)
              for more information about this attribute.

           "last-document" (boolean):
              The client MUST supply this attribute.  It is a boolean flag that
              is set to 'true' if this is the last document for the Job,
              'false' otherwise.

           "document-charset" (charSet):
              This attribute is OPTIONALLY supplied by the client.  A Printer
              object SHALL support this attribute if it supports a document-
              format that requires a character set to be identified in order to
              unambiguously interpret the document, such as 'text/plain'.
              There are no particular values required for the Printer object to
              support.  This attribute specifies the charset of the document
              for those document-formats that require a specification of the
              charset in order to image the document unambiguously.  If the
              value of the "document-format" attribute contains a charset
              parameter (see 'mimeType' attribute syntax in Section 4.1.9), the
              client SHALL also supply the "document-charset" attribute and its
              value SHALL be the same.

           "document-natural-language" (naturalLanguage):
              This attribute is OPTIONALLY supplied by the client.  There are
              no particular values required for the Printer object to support.
              This attribute specifies the natural language of the document for
              those document-formats that require a specification of the
              natural language in order to image the document unambiguously,
              such as proper glyph selection..

         Group 2: Document Content

                                 Expires April 14, 1998
              The client MUST supply the document data if the "last-document"
              flag is set to 'false'.  However, since a client might not know
              that the previous document sent with a Send-Document operation
              was the last document (i.e., the "last-document" attribute was
              set to 'false'), it is legal to send a Send-Document request with
              no document data where the "last-document" flag is set to 'true'.

         3.3.1.2 Send-Document Response

         The following sets of attributes are part of the Send-Document
         Response:

         Group 1: Operation Attributes

           Status Code and Message:
              The response includes the MANDATORY status code and an OPTIONAL
              "status-message" (text) operation attribute as described in
              section 3.1.4.

           Natural Language and Character Set:
              The "attributes-charset" and "attributes-natural-language"
              attributes as described in section 3.1.3.2.

         Group 2: Job Object Attributes

              This is the same set of attributes as described in the Print-Job
              response (see section 3.2.1.2).

         3.3.2 Send-URI Operation

         This operation is identical to the Send-Document operation (see
         section 3.3.1) except that a client supplies a URI reference
         ("document-uri" operation attribute) rather than the document data
         itself.  If a Printer object supports this operation, clients can use
         both Send-URI or Send-Document operations to add new documents to an
         existing multi-document Job object.

         The Printer object MUST validate the syntax of the supplied URI before
         returning a response.  If the Printer object supports this operation,
         it MUST support the URI types defined under the Print-URI operation
         (see section 3.2.2)

         3.3.3 Cancel Job Operation

         This operation allows a client to cancel a Print Job any time after a
         create job operation..  Since a Job might already be printing by the

                                 Expires April 14, 1998
         time a Cancel-Job is received, some pages may be printed before the
         job is actually terminated.

         3.3.3.1 Cancel-Job Request

         The following groups of attributes are part of the Cancel-Job Request:

         Group 1: Operation Attributes

           Target:
              Either the "printer-uri" plus "job-id" or "job-uri" target for
              this operation as described in section 3.1.2.

           Natural Language and Character Set:
              The "attributes-charset" and "attributes-natural-language"
              attributes as described in section 3.1.3.1.

           "message" (text):
              OPTIONAL message to the operator.  This is not the same as the
              "job-message-from-operator" attribute.  This attribute is used to
              send a message along with the operation request.  It is an
              implementation decision of how or where to display this message
              (if at all).

         3.3.3.2 Cancel-Job Response

         The following sets of attributes are part of the Cancel-Job Response:

         Group 1: Operation Attributes

           Status Code and Message:
              The response includes the MANDATORY status code and an OPTIONAL
              "status-message" (text) operation attribute as described in
              section 3.1.4.

           Natural Language and Character Set:
              The "attributes-charset" and "attributes-natural-language"
              attributes as described in section 3.1.3.2.

         Once a successful response has been sent, the implementation
         guarantees that the Job will eventually end up in the 'cancelled'
         state.  If the implementation is forced to leave the job in the some
         other state, the "job-state-reasons" SHOULD contain the ' processing-
         to-stop-point ' value which indicates to later queries that although
         the Job may still be 'processing', it will eventually end up in the
         'cancelled' state, not the 'completed' state.

                                 Expires April 14, 1998
         3.3.4 Get-Attributes Operation

         The Job Get-Attributes operation allows a client to obtain information
         from a Job object and it is almost identical to the Get-Attributes
         operation for a Printer object (see section 3.2.5).  The only
         differences are that the operation is directed at a Job rather than a
         Printer and there is no "document-format" operation attribute used
         when querying a Job object.

         For Jobs, the attribute groups include:

           - 'job-template': all of the Job Template attributes that apply to
              a Job object (the first column of the table in Section 4.2).
           - 'job-description': the attributes specified in Section 4.3.

         There is also the special group 'all' that includes all supported
         attributes.  If for some reason, the client includes an attribute two
         or more times in the request (e.g., the client supplies values of
         'all', 'job-template', and 'sides' in the "requested-attributes"
         attribute), the Printer SHALL only return one occurrence of the
         attribute in the response.

         3.3.4.1 Get-Attributes Request

         The following groups of attributes are part of the Get-Attributes
         Request when the request is directed at a Job object:

         Group 1: Operation Attributes

           Target:
              Either the "printer-uri" plus "job-id" or "job-uri" target for
              this operation as described in section 3.1.2.

           Natural Language and Character Set:
              The "attributes-charset" and "attributes-natural-language"
              attributes as described in section 3.1.3.1.

           "requested-attributes" (1setOf keyword) :
              An OPTIONAL set of attribute names and/or attribute group names
              in whose values the requester is interested.  If the client omits
              this attribute, the Printer SHALL respond as if this attribute
              had been supplied with a value of 'all'.

         3.3.4.2 Get-Attributes Response

         The Printer object returns the following sets of attributes as part of
         the Get-Attributes Response:

                                 Expires April 14, 1998
         Group 1: Operation Attributes

           Status Code and Message:
              The response includes the MANDATORY status code and an OPTIONAL
              "status-message" (text) operation attribute as described in
              section 3.1.4.

           Natural Language and Character Set:
              The "attributes-charset" and "attributes-natural-language"
              attributes as described in section 3.1.3.2.

         Group 2: Requested Job Object Attributes

              This is the set of requested attributes and their current values.
              The Printer object ignores (does not respond with) any requested
              attribute which is not supported.

         4. 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:

           - Document Printing Application (DPA) [ISODPA]
           - RFC 1759 Printer MIB  [RFC1759]

         Each attribute is uniquely identified in this document using a
         "keyword" (see section 12.2.1).  The keyword is included in the
         section header describing that attribute.  All attributes are uniquely
         identified with a keyword as its name.   In addition, some attributes
         are defined having a syntax that is a set of keywords.

         4.1 Attribute Syntaxes

         This section defines the basic attribute syntax types that a client
         and server SHALL be able to handle.  Each attribute description in
         sections 3 and 4 includes the name of attribute syntax(es) in the
         heading (in parentheses).  A conforming implementation of an attribute
         SHALL include the semantics of the attribute syntax(es) so identified.
         Section 6 describes how the protocol can be extended with new
         attribute syntaxes.

         Most attributes are defined to have a single attribute syntax.
         However, a few attributes (e.g., "job-sheet", "media", "job-hold-
         until") are defined to have several attribute syntaxes, depending on

                                 Expires April 14, 1998
         the value.  Since each value SHALL be tagged as to its attribute
         syntax in the protocol, a single-valued attribute instance may have
         any one of its attribute syntaxes and a multi-valued attribute
         instance may have a mixture of its defined attribute syntaxes.

         The attribute syntaxes are specified in the following sub-sections,
         where the sub-section heading is the name of the attribute syntax
         inside the single quotes:

         4.1.1 'text'

         The 'text' attribute syntax is a sequence of one or more characters
         with a limit of 1 to 4095 octets.  The Printer object SHALL support
         UTF-8 [RFC2044] and MAY support additional charsets provided that they
         are registered with IANA [IANA-CS].  See Section 4.1.7 for the
         specification of the 'charSet' attribute syntax, including restricted
         semantics and examples of charsets.

         If the client needs to pass or the Printer object needs to return a
         'text' attribute in a different natural language than the rest of the
         'text' attributes in the request or response as indicated by the
         "attributes-natural-language" operation attribute (see Section 3.1.3),
         the client or Printer object SHALL immediately precede that attribute
         value with a 'naturalLanguage' attribute value that indicates the
         differing natural language.  Thus the attribute becomes multi-valued
         with two values.  This additional values is called an "exception"
         natural language value.  In a create operation, the Printer object
         SHOULD accept and store an exception natural language value.  If the
         Printer object does not store an exception natural language value, the
         Printer SHALL ignore it and SHALL store the immediately following
         'text' value only.  The Printer SHALL not reject the request no matter
         what value the client supplies as an exception natural language.

         If the attribute is multi-valued (1setOf text), then the exception
         natural language value applies only to the next 'text' value.
         Subsequent values in a multi-valued 'text' attribute in a request or a
         response revert to the natural language of the operation attribute or
         the "job-natural-language" job attribute, if present, in the case of a
         Get-Jobs response.

         Example:  If the client supplies the "attributes-natural-language"
         operation attribute with the value:  'en' indicating English, but the
         values of the "job-name" attribute is in French, the values of the
         normally single-valued "job-name" attribute supplied by the client in
         any request or returned by the Printer object in any response would be
         the following two values, each tagged with the appropriate attribute
         syntax ('naturalLanguage' and 'text') in the protocol:

                                 Expires April 14, 1998
           'fr': exception natural language indicating French with attribute
              syntax 'naturalLanguage'
           'Rapport Mensuel': the job name in French with attribute syntax
              'name'.

         4.1.2 'name'

         The 'name' attribute syntax is the same as 'text', including the
         MANDATORY support of UTF-8 and the exception natural language
         mechanism, except that the sequence of characters is limited so that
         its encoded form is of length 1 to 255 octets.  This syntax type is
         used for user-friendly strings, such as a Printer name, that, for
         humans, are more meaningful than identifiers.

         Note:  Only the 'text' and 'name attribute syntaxes permit the
         exception natural language mechanism.

         Example:  If the client supplies the "attributes-natural-language"
         operation attribute with the value:  'en' indicating English, but the
         "printer-name" attribute is in German, the values of the normally
         single-valued "printer-name" attribute returned by the Printer in any
         operation response would be the following two values, each tagged with
         the appropriate attribute syntax ('naturalLanguage' and 'name') in the
         protocol:

           'de':  exception natural language indicating German with the
              attribute syntax 'naturalLanguage'
           'Farbdrucker':  the Printer name in German with attribute syntax
              'name'

         4.1.3 'keyword'

         The 'keyword' attribute syntax is a sequence of characters, length: 1
         to 255, containing only the US-ASCII [ASCII] encoded values for
         lowercase letters ("a" - "z"), digits ("0" - "9"), hyphen ("-"), dot
         ("."), and underscore ("_").  The first character MUST be a lowercase
         letter.  Furthermore, keywords SHALL be in U.S. English.

         This syntax type is used for enumerating semantic identifiers of
         entities in the abstract protocol, i.e., entities identified in this
         document.  Keywords are used as attribute names or values of
         attributes.  Unlike 'text' and 'name' attribute values, 'keyword'
         values SHALL NOT use the exception natural language mechanism, since
         they SHALL always be US-ASCII and U.S. English.  When accepting
         keywords from users and displaying keywords to users, clients SHOULD
         localize the keywords to the charset and natural language of the user.

                                 Expires April 14, 1998
         In the definition for each attribute of this syntax type, the full set
         of defined keyword values for that attribute are listed.

         When a keyword is used to represent an attribute (its name), it MUST
         be unique within the full scope of all 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, the same
         keyword SHALL not be used for two different values within the same
         attribute to mean two different semantic ideas.  However, the same
         keyword MAY be used across two or more attributes, representing
         different semantic ideas for each attribute. Section 6 describes how
         the protocol can be extended with new keyword values.  Examples of
         attribute name keywords:

           "job-name"
           "attributes-charset "

         4.1.4 'enum'

         The 'enum' attribute syntax is an enumerated integer value that is in
         the range from -2**31 to 2**31 - 1.   Each value has an associated
         'keyword' name.  In the definition for each attribute of this syntax
         type, the full set of possible values for that attribute are listed..
         This syntax type is used for attributes for which there are enum
         values assigned by other standards, such as SNMP MIBs.  A number of
         attribute enum values in this specification are also used for
         corresponding attributes in other standards [RFC1759]..  This syntax
         type is not used for attributes to which the system administrator may
         assign values. Section 6 describes how the protocol can be extended
         with new enum values.  Though this document includes a symbolic name
         for each enum value (in U.S. English), when accepting enum names from
         users and displaying enum names to users, clients SHOULD localize the
         names to the charset and natural language of the user.

         4.1.5 'uri'

         The 'uri' attribute syntax is any valid Uniform Resource Identifier or
         URI [RFC1630].  Most often, URIs are simply Uniform Resource Locators
         or URLs [RFC1738] [RFC1808].

         4.1.6 'uriScheme'

         The 'uriScheme' attribute syntax is a sequence of characters
         representing a URI scheme according to RFC 1738 [RFC1738].  Standard
         values for this syntax type are the following keywords:

           'http':  for HTTP schemed URIs (e.g., "http://...")
           'ftp': for FTP schemed URIs (e.g., "ftp://...")

                                 Expires April 14, 1998
           'mailto': for SMTP schemed URIs (e.g., "mailto:...")
           'file': for file schemed URIs (e.g., "file:...")

         4.1.7 'charSet'

         The 'charSet' attribute syntax is a standard identifier of a coded
         character set and encoding scheme for labeling certain document
         contents and 'text' and 'name' attribute values.  The syntax and
         semantics of this attribute syntax are specified in RFC 2046 [RFC2046]
         and contained in the IANA character-set Registry [IANA-CS] according
         to the IANA procedures [IANA-CSa].  As specified in RFC 2046, the
         values SHALL be case-insensitive and SHALL be in US-ASCII.  When a
         character-set in the IANA registry has more than one name (alias), the
         name labeled as "(preferred MIME name)" SHALL be used.

         Some examples are:

           'utf-8':  ISO 10646 Universal Multiple-Octet Coded Character Set
              (UCS) represented as the UTF-8 [RFC2044] transfer encoding scheme
              in which US-ASCII is a subset charset.  The 'utf-8' charset value
              supplied in the "attributes-charset" operation attribute (see
              Section 3.1.3), which is used to identify the charset of 'text'
              and 'name' attributes, SHALL be restricted to conformance level 2
              of ISO 10646 [ISO10646-1], so that accented letters SHALL NOT be
              represented with non-spacing accents.  This same 'utf-8' value
              supplied in the "document-format" operation attribute (see
              Sections 3.2.1.1 and 3.3.1.1), MAY include level 3 of ISO 10646.
           'US-ASCII':  7-bit American Standard Code for Information
              Interchange (ASCII), ANSI X3.4-1986 [ASCII].  This standard
              defines US-ASCII, but RFC 2045 [46] eliminates most of the
              control characters from conformant usage in MIME and IPP.
           'iso-8859-1':  8-bit One-Byte Coded Character Set, Latin Alphabet
              Nr 1 [ISO8859-1].  This defines a coded character set that is
              used by Latin languages in the Western Hemisphere and Western
              Europe.  US-ASCII is a subset charset.

         Some attribute descriptions MAY place additional requirements on
         charset values that may be used, such as MANDATORY values the MUST be
         supported or additional restrictions, such as requiring that the
         charset have US-ASCII as a subset charset.

         4.1.8 'naturalLanguage'

         The 'naturalLanguage' attribute syntax is a standard identifier for a
         natural language and optionally a country.  The values for this syntax
         type are taken from RFC 1766 [RFC1766].  As specified in RFC 1766, the
         values SHALL be case-insensitive and SHALL be in US-ASCII.  Examples
         include:

                                 Expires April 14, 1998
           'en':  for English
           'en-us': for US English
           'FR': for French
           'de':  for German

         4.1.9 'mimeType'

         The 'mimeType' attribute syntax is the standard defined Internet Media
         Type (sometimes called MIME type) as defined by RFC 2046 [RFC2046] and
         registered according to the procedures of RFC 2048 [RFC2048] for
         identifying a document format.  The value MAY include a charset
         parameter, depending on the specification of the Media Type in the
         IANA Registry [IANA-MT]. Examples:

           'text/html': An HTML document
           'text/plain': A plain text document in US-ASCII (RFC 2046 indicates
              that in the absence of the charset parameter SHALL mean US-ASCII
              rather than simply unspecified) [RFC2046].
           'text/plain; charset=US-ASCII':  A plain text document in US-ASCII
              [52, 56].
           'text/plain; charset=ISO-8859-1':  A plain text document in ISO
              8859-1 (Latin 1) [ISO8859-1].
           'text/plain; charset=utf-8':  A plain text document in ISO 10646
              represented as UTF-8 [RFC2044]
           'text/plain, charset=iso-10646-ucs-2':  A plain text document in
              ISO 10646 represented in two octets (UCS-2) [ISO10646-1]
           'application/postscript':  A PostScript document [RFC2046]
           'application/vnd.hp-PCL':  A PCL document [IANA-MT] (charset escape
              sequence embedded in the document data)
           'application/octet-stream':  Auto-sense - see below

         One special type is 'application/octet-stream'.   If the Printer
         object supports this value, the Printer object or the device SHALL be
         capable of auto-sensing the format of the document data. If the
         Printer object's default value attribute is set to 'application/octet-
         stream' the Printer object not only supports auto-sensing of the
         document format, but will depend on the result of applying its auto-
         sensing algorithm in the case of missing information not supplied by
         the client.  If the client supplies a document format value, the
         Printer SHOULD rely on the supplied attribute, rather than trust its
         auto-sensing algorithm.  To summarize:

           1. If the client does not supply a document format value, the
              Printer MUST rely on its default value setting (which may be
              'application/octet-stream' indicating an auto-sensing mechanism).
           2. If the client supplies a value other than 'application/octet-
              stream', the client is supplying valid information about the
              format of the document data and the Printer object SHOULD trust

                                 Expires April 14, 1998
              the client supplied value more than the outcome of applying an
              automatic format detection mechanism.  For example, the client
              may be requesting the printing of a PostScript file as a
              'text/plain' document.  The Printer object SHOULD print a text
              representation of the PostScript commands rather than interpret
              the stream of PostScript commands and print the result.
           3. If the client supplies a value of 'application/octet-stream',
              the client is indicating that the Printer object SHOULD use its
              auto-sensing mechanism whether auto-sensing is the Printer
              object's default or not.

         4.1.10 'octetString'

         The 'octetString' attribute syntax is a sequence of octets.  This
         syntax type is used for opaque data

         4.1.11 'boolean'

         The 'boolean' attribute syntax is like a keyword with only two values
         'true' and 'false'.

         4.1.12 'integer'

         The 'integer' attribute syntax is an integer value that is in the
         range from -2**31 to 2**31 - 1. Each individual attribute may specify
         the range constraint explicitly if the range is different from the
         full range of possible integer values (e.g., 0 - 100 for the "job-
         priority" attribute), however, the enforcement of that additional
         constraint is up to the IPP objects, not the protocol.

         4.1.13 'rangeOfInteger'

         The 'rangeOfInteger' attribute syntax is an ordered set of two
         integers, the smallest first, followed by the largest.  The pair of
         integers identifies an inclusive range of integer values.

         4.1.14 'dateTime'

         The 'dateTime' attribute syntax is a standard, fixed length
         representation of the "DateAndTime" syntax as defined in RFC 1514
         [RFC1514] and RFC 1903 [RFC1903].  When accepting 'dateTime' values
         from users and displaying 'dateTime' values to users, clients SHOULD
         localize the values to the charset and natural language of the user.

         4.1.15 'resolution'

         The 'resolution' attribute syntax specifies a two-dimensional
         resolution in the indicated units.  It consists of 3 integers: a cross

                                 Expires April 14, 1998
         feed direction resolution (positive integer value), a feed direction
         resolution (positive integer value), and a units value.  The semantics
         of these three components are taken from the Printer MIB [RFC1759]
         suggested values.  That is, the cross feed direction component
         resolution component is the same as the
         prtMarkerAddressabilityXFeedDir object in the Printer MIB, the feed
         direction component resolution component is the same as the
         prtMarkerAddressabilityFeedDir in the Printer MIB, and the units
         component is the same as the prtMarkerAddressabilityUnit object in the
         Printer MIB (namely dots per inch and dots per centimeter).  All three
         values MUST be present even if the first two values are the same.
         Example:  '300', '600', '3' indicates a 300 dpi cross-feed direction
         resolution, a 600 dpi feed direction resolution, since a '3' indicates
         dots per inch.

         4.1.16 '1setOf  X'

         The '1setOf  X' attribute syntax is 1 or more values of attribute
         syntax type X.  This syntax type is used for multi-valued attributes.
         The syntax type is called '1setOf' rather than just 'setOf' as a
         reminder that the set of values SHALL NOT be empty (i.e., a set of
         size 0).  Sets are normally unordered, however each attribute
         description of this type may specify that the values MUST be in a
         certain order for that attribute.

         4.2 Job Template Attributes

         Job Template attributes describe job processing behavior.  Support for
         Job Template attributes by a Printer object is OPTIONAL (see section
         12.2.3 for a description of support for OPTIONAL attributes).  Also,
         clients OPTIONALLY supply Job Template attributes in create requests.

         Job Template attributes conform to the following rules.  For each Job
         Template attribute called "foo":

           1. The Printer object OPTIOINALLY supports a "foo-supported"
              attribute that describes which job processing behaviors are
              supported by that Printer object.  A client can query the Printer
              object to find out what foo-related behaviors are supported by
              inspecting the returned values of the "foo-supported" attribute.

           2. The Printer also OPTIONALLY supports a default value attribute
              named "foo-default". This default value attribute describes what
              will be done when no other job processing information is supplied
              by the client (either explicitly as an IPP attribute in the
              create request or implicitly as an embedded instruction within
              the document data). If the Printer supports either the "foo-

                                 Expires April 14, 1998
              default" default value attribute or the "foo-supported"
              attribute, the Printer MUST support both.

           3. "foo" is OPTIOINALLY supplied by the client in a create request.
              If "foo" is supplied, the client is specifying that the Printer
              SHALL apply the corresponding job processing behavior to this Job
              while processing the Job.  When "foo" is not supplied, the client
              is specifying that the Printer apply the default job processing
              behavior.

              NOTE: Since an administrator MAY change the default value
              attribute after a Job has been submitted but before it has been
              processed, the default value used by the Printer object at job
              processing time may be different that the default value in effect
              at job submission time.

         If an application wishes to present an end user with a list of
         supported values from which to choose, the application SHOULD query
         the Printer for the supported values.  The application SHOULD also
         query the default value attributes. If the application then limits
         selectable values to only those value that are supported, the
         application can guarantee that the values supplied by the client in
         the create request all fall within the set of supported values at the
         Printer.  When querying the Printer, the client MAY enumerate each
         attribute by name in the Get-Attributes Request, or the client MAY
         just name the "job-template" group in order to get the complete set of
         supported attributes (both supported and default attributes).

         The "finishings" attribute is an example of a Job Template attribute.
         It can take on a set of values such as 'staple', 'punch', and/or
         'cover'.  A client can query the Printer object for the "finishings-
         supported" attribute and the "finishings-default" attribute.  The
         supported attribute contains a set of supported values.  The default
         value attribute contains the finishing value(s) that will be used for
         a new Job if the client does not supply a "finishings" attribute in
         the create request.  If the client does supply the "finishings"
         attribute in the create request, the Printer validates the value or
         values to make sure that they are a subset of the supported values.
         If the client-supplied values are all supported, the Job object is
         created with a "finishings" attribute that is populated with the
         values supplied by the client.  Subsequently, when the Job object is
         queried, it returns the values supplied by the client.  If the client
         does not supply a "finishings" attribute in the create request, the
         Job object is created, but no "finishings" attribute is associated
         with the new Job object.  A subsequent query of the Job object will
         return no "finishings" attribute.  In this case, the querying client
         knows that there were was no client supplied "finishings" attribute.
         If the client is interested to know what the default value is that the

                                 Expires April 14, 1998
         Printer will use for the missing attribute, the client can query the
         Printer object's default value "finishings-default" attribute to find
         out how the Job will be finished.

         The table below summarizes the names and relationships for all Job
         Template attributes. The first column of the table (labeled "Job")
         shows the name and syntax for each Job Template attribute in the Job
         object. These are the attributes that can optionally be supplied by
         the client in a create request.   The last two columns (labeled
         "Printer: Default Value" and "Printer: Supported Values") shows the
         name and syntax for each Job Template attribute in the Printer object
         (the default value attribute and the supported values attribute).  A
         "No" in the table means the Printer SHALL NOT support the attribute
         (that is the attribute is simply not applicable).

                                 Expires April 14, 1998
           +===================+======================+======================+
           | Job Attribute     |Printer: Default Value|  Printer: Supported  |
           |                   |   Attribute          |   Values Attribute   |
           +===================+======================+======================+
           | job-sheets        | job-sheets-default   |job-sheets-supported  |
           | (type4 keyword,   | (type4 keyword,      |(1setOf type4 keyword,|
           |    name)          |    name)             |    name)             |
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
         | job-priority      | job-priority-default |job-priority-supported|
           | (integer 1:100)   | (integer 1:100)      |(integer 1:100)       |
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           | job-hold-until    | job-hold-until-      |job-hold-until-       |
           | (type4 keyword,   |  default             | supported            |
           |    name)          |  (type4 keyword,     |(1setOf type4 keyword,|
           |    name)          |    name)             |    name)             |
           +-------------------+----------------------+----------------------+
           |multiple-document- |multiple-document-    |multiple-document-    |
           | handling          | handling-default     |handling-supported    |
           | (type2 keyword)   | (type2 keyword)      |(1setOf type2 keyword)|
           +-------------------+----------------------+----------------------+
           | media             | media-default        | media-supported      |
           | (type4 keyword,   | (type4 keyword,      |(1setOf type4 keyword,|
           |    name)          |    name)             |    name)             |
           |                   |                      |                      |
           |                   |                      | media-ready          |
           |                   |                      |(1setOf type4 keyword,|
           |                   |                      |    name)              |
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           | number-up         | number-up-default    | number-up-supported  |
           | (integer)         | (integer)            |(1setOf integer)      |
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           | sides             | sides-default        | sides-supported      |
           | (type2 keyword)   | (type2 keyword)      |(1setOf type2 keyword)|
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           | printer-resolution| printer-resolution-  | printer-resolution-  |
           | (resolution)      |  default             | supported            |
           |                   | (resolution)         |(1setOf type4 keyword)| resolution)   |
           +-------------------+----------------------+----------------------+
           | print-quality     | print-quality-default| print-quality-       |
           | (type2 enum)      | (type2 enum)         | supported            |
           |                   |                      |(1setOf type2 enum)   |
           +-------------------+----------------------+----------------------+
           | notify-events finishings        | notify-events finishings-default   | notify-events- finishings-supported |

                                 Expires April 14, 1998
           |(1setOf type2 enum)|(1setOf type2 enum)   |(1setOf type2 keyword)| enum)   |
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           | copies            | copies-default       | copies-supported     |
           | (integer: 1:MAX)  | (integer: 1:MAX)     | (integer: 1:MAX)     |
           |                   |                      |                      |
           |                   |                      | collated-copies-     |
           |                   |                      | supported            |
           |                   |                      | (integer: 1:MAX)     |
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           | page-ranges       | No                   | page-ranges-         |
           | (1setOf           |                      | supported (boolean)  |
           |   rangeOfInteger) |                      |                      |
           +-------------------+----------------------+----------------------+
           | orientation       | orientation-default  | orientation-         |
           | (type2 enum)      |  (type2 enum)        | supported            |
           |                   |                      |  (1setOf type2 enum) |
           +-------------------+----------------------+----------------------+
           | document-format   | document-format-     | document-format-     |
           | (mimeType)        |  default             | supported            |
           |                   |  (mimeType)          |(1setOf mimeType)     |
           +-------------------+----------------------+----------------------+
           | compression       | No                   | compression-supported|
           | (type3 keyword)   |                      |(1setOf type2 type3 keyword)|
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           |notify-addresses
           | job-k-octets      | No                   |notify-addresses                   |job-k-octets-supported|
           |
           |(1setOf uri) (integer)         |                      | (rangeOf integer)    |                      |-supported
           |                   |                      |                      |(1setOf uriScheme)                      |
           +-------------------+----------------------+----------------------+
           | job-priority job-              | No                   | job-impressions-     |
           | impressions       |                      | supported            |
           | (integer)         |                      | (rangeOf integer)    |
           +-------------------+----------------------+----------------------+
           | job-media-        | No                   | job-media-sheets-    |
           | sheets            |                      | supported            |
           | (integer)         |                      | (rangeOf integer)    |
           +-------------------+----------------------+----------------------+

         4.2.1 job-sheets (type4 keyword, name)

         This attribute determines which if any banner page(s) SHALL be printed
         with a job.

         Standard values are:

                                 Expires April 14, 1998
           'none': no job sheet is printed
           'standard': one or more site specific standard job sheets are
              printed, e.g. a single start sheet or both start and end sheet is
              printed

         An administrator MAY define additional values using the 'name' or
         'keyword' attribute syntax, depending on implementation.

         Note: The effect of this attribute on jobs with multiple documents is
         controlled by the "multiple-document-handling" job attribute (section
         4.2.4).

         4.2.2 job-priority         |job-priority-supported|
           | (integer 1-100)   | (integer 1-100)      |(rangeOf (integer(1:100))

         This attribute specifies a priority for scheduling the Job. A higher
         value specifies a higher priority. The value 1 indicates the lowest
         possible priority. The value 100 indicates the highest possible
         priority.  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 syntax for the "job-priority-supported" is an integer(1:100).
         This single integer      |
           |                   |                      | 1-100)               |
           +-------------------+----------------------+----------------------+
           | job-hold-until    | value indicates the number of priority levels
         supported.  For example, if the value of "job-priority-supported" is
         '3', then the Printer object supports 3 levels of job priorities
         (let's call them 'high', 'medium', and 'low'). In this case, a client
         MUST assume the following:

           A client supplied value in the range 1-33 is the same as any other
              value in the range 1-33 and any one of those values corresponds
              to the 'low' priority.
           A client supplied value in the range 34-66 is the same as any other
              value in the range 34-66 and any one of those values corresponds
              to the 'medium' priority.
           A client supplied value in the range 67-100 is the same as any
              other value in the range 67-100 and any one of those values
              corresponds to the 'high' priority.

         For another example, if the value of "job-priority-supported" is '10',
         then the Printer object supports 3 levels of job priorities, (let's
         call them 'one', 'two', ..., and 'ten' with 'one' being the lowest
         priority and 'ten' being the highest). In this case, a client MUST
         assume the following:

           A client supplied value in the range 1-10 is the same as any other
              value in the range 1-10 and any one of those values corresponds
              to the 'one' priority.

                                 Expires April 14, 1998
           A client supplied value in the range 11-20 is the same as any other
              value in the range 11-20 and any one of those values corresponds
              to the 'two' priority.
           ...
           A client supplied value in the range 91-100 is the same as any
              other value in the range 91-100 and any one of those values
              corresponds to the 'ten' priority.

         4.2.3 job-hold-until       | job-hold-until-      |
           | (type4 keyword)   | (type4 keyword)      | supported            |
           |                   |                      |(1setOf type4 keyword)|
           +-------------------+----------------------+----------------------+
           |multiple-document- |multiple-document-    |multiple-document-    |
           | handling          | handling             |handling-supported    |
           | (type2 keyword)   | keyword, name)

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

         Standard values for named time periods are:

           'no-hold': immediately, if there are not other reasons to hold the
              job.
           'day-time': during the day.
           'evening': evening
           'night': night
           'weekend': weekend
           'second-shift': second-shift
           'third-shift': third-shift (after midnight)

         An administrator SHALL associate allowable print times with a named
         time period (by means outside IPP 1.0).  An administrator is
         encouraged to pick names that suggest the type of time period. An
         administrator MAY define additional values using the 'name' or
         'keyword' attribute syntax, depending on implementation.

         If the value of this attribute specifies a time period that is in the
         future, the Printer SHALL add the 'job-hold-until-specified' value to
         the job's "job-state-reasons" attribute, move the job to the 'pending-
         held' state, and SHALL NOT schedule the job for printing until the
         specified time-period arrives.  When the specified time period
         arrives, the Printer SHALL remove the 'job-hold-until-specified' value
         from the job's "job-state-reason" attribute and, if no other job
         reasons that keep it in the 'pending-held' state remain, the Printer
         SHALL consider the job as a candidate for processing by moving the job
         to the 'pending' state.

         If this job attribute value is the named value 'no-hold', or specified
         time period is in effect has already started, the job SHALL be a
         candidate for processing immediately.

                                 Expires April 14, 1998
         4.2.4 multiple-document-handling (type2 keyword)      |(1setOf type2 keyword)|
           +-------------------+----------------------+----------------------+
           |

         This job attribute is relevant only if a job consists of two or more
         documents. The attribute controls finishing operations and the
         placement of print-stream pages into imposed pages and onto media
         sheets.  When   the value of the "copies" attribute exceeds 1, it also
         controls the order in which the copies that result from processing the
         documents are produced. For the purposes of this explanations, if "a"
         represents an instance of document data, then the result of processing
         the data in document "a" is a sequence of media sheets represented by
         "a(*)".

         Standard values are:

           'single-document': If a Job object has multiple documents, say the
              document data is called a and b, then the result of processing
              all the document data (a and then b) SHALL be treated as a single
              sequence of media sheets for finishing operations; that is,
              finishing would be performed on the concatenation of the
              seqeunces a(*),b(*).  The Printer SHALL NOT force the data in
              each document instance to be formatted onto a new print-stream
              page, nor to start a new imposed page or a new media             | sheet. If
              more than one copy is made, the ordering of the sets of media                | media-supported      |
           | (type4 keyword)   | (type4 keyword)      |(1setOf type4 keyword)|
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           | number-up         | number-up            | number-up-supported  |
           | (type3 keyword)   | (type3 keyword)      |(1setOf type3 keyword)|
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           | sides             | sides                | sides-supported      |
           | (type2 keyword)   | (type2 keyword)      |(1setOf type2 keyword)|
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           | printer-resolution| printer-resolution   | printer-resolution-  |
           | (type2 enum)      | (type2 enum)         | supported            |
           |                   |                      |(1setOf type2 enum)   |
           +-------------------+----------------------+----------------------+
           | print-quality     | print-quality        | print-quality-       |
           | (type2 enum)      | (type2 enum)         | supported            |
           |                   |                      |(1setOf type2 enum)   |

         deBry, Hastings, Herriot, Isaacson, Powell
              sheets resulting from processing the document data SHALL be a(*),
              b(*), a(*), b(*),...., and the Printer SHALL force each copy to
              start on a new media sheet.
           'separate-documents-uncollated-copies': If a Job object has
              multiple documents, say the document data is called a and b, then
              the result of processing the data in each document instance SHALL
              be treated as a single sequence of media sheets for finishing
              operations; that is, the sets a(*) and b(*) would each be
              finished separately. The Printer SHALL force each copy of the
              result of process the data in a single document to start on a new
              media sheet. If more than one copy is made, the ordering of the
              sets of media sheets resulting from processing the document data
              SHALL be a(*), a(*), b(*), b(*) ....
           'separate-documents-collated-copies': If a Job object has multiple
              documents, say the document data is called a and b, then the
              result of processing the data in each document instance SHALL be
              treated as a single sequence of media sheets for finishing
              operations; that is, the sets a(*) and b(*) would each be
              finished separately. If more than one copy is made, the ordering
              of the sets of media sheets resulting from processing the
              document data SHALL be a(*), b(*), a(*), b(*), ...., and the
              Printer SHALL force each document copy to start on a new sheet .

         'separate-documents-collated-copies' is the same as 'single-document'
         with respect to ordering of pages, but not media sheet generation,

                                 Expires February xx, April 14, 1998
           +-------------------+----------------------+----------------------+
           | finishings        | finishings           | finishings-supported |
           |(1setOf type2 enum)|(1setOf type2 enum)   |(1setOf type2 enum)   |
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           | copies            | copies               | copies-supported     |
           | (integer: 1 - MAX)| (2setOf integer      | (2rangeOf integer    |
           |                   |     1 - MAX)         |     1- MAX)          |
           +-------------------+----------------------+----------------------+
           | page-range        | No                   | page-range-          |
           | (rangeOf integer) |                      | supported (boolean)  |
           |                   |                      |                      |
           +===================+======================+======================+
           |                                                                 |
           |
         since the latter will put the first page of the next document on the
         back side of a sheet if an odd number of pages have been produced so
         far for the job, while the former case always force the next document
         or document copy on to a new sheet.

         4.2.5 media (type4 keyword, name)

         This job attribute identifies the medium that the Printer uses for all
         pages of the Job.

         The values for "media" include medium-names, medium-sizes, input-trays
         and electronic forms so that one attribute specifies the media. If a
         printer allows a client to specify a medium name as the value of this
         attribute, such a medium name implicitly selects an input-tray that
         contains the specified medium.  If a printer allows a client to
         specify a medium size as the value of this attribute, such a medium
         size implicitly selects a medium name that 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-
         feed 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 that 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 document data as its prints each page.

         Standard values are (taken from ISO DPA and the Printer MIB) and are
         listed in section 14. An administrator MAY define additional values
         using the 'name' or 'keyword' attribute syntax, depending on
         implementation.

         There is also an additional attribute named "media-ready" which
         differs from "media-supported" in that legal values only include the
         subset of "media-supported" values that are physically loaded and
         ready for printing with no operator intervention required.

         The relationship of this attribute and the other attributes that
         control document processing is described in section 15.4.

         4.2.6 number-up (integer)

         This job attribute specifies the number of source page-images to
         impose upon a single side of an instance of a selected medium.  For
         example, if the value is

                                 Expires April 14, 1998
           '1': The Printer SHALL place one logical page on a single side of
              an instance of the selected medium (MAY add some sort of
              translation, scaling, or rotation).
           '2': The Printer SHALL place two logical pages on a single side of
              an instance of the selected medium (MAY add some sort of
              translation, scaling, or rotation).
           '4': The Printer SHALL place four logical pages on a single side of
              an instance of the selected medium (MAY add some sort of
              translation, scaling, or rotation).

         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.

         Note: The following effect of this attribute on jobs with multiple documents is
         controlled by the "multiple-document-handling" job attribute (section
         4.2.4) and the relationship of this attribute and the other attributes
         that control document processing is described in section 15.4.

         ISSUE: Steve Z.: should this section be changed to include "print-
         stream page" and "layout page"?? rather than "source page" and
         "logical page"?

         4.2.7 sides (type2 keyword)

         This attribute specifies how source page-images are Document attributes, they    |
           |       have to be imposed upon
         the sides of an instance of a selected medium.

         The standard values are:

           'one-sided': imposes each consecutive source page-image upon the
              same side of consecutive media sheets.
           'two-sided-long-edge': imposes each consecutive pair of source
              page-image upon front and back sides of consecutive media sheets,
              such that the same semantics a Job Template attributes,        |
           |       however they apply to orientation of each Document object rather than    |
           |       at pair of source-pages on the Job level
              medium would be correct for the reader as Job object attributes.                |
           |                                                                 |
           +===================+======================+======================+
           | Document          |Printer: Default Value|  Printer: Supported  |
           | Attribute         |   Attribute          |   Values Attribute   |
           +===================+======================+======================+
           | document-format   | document-format      | document-format-     |
           | (mimeType)        | (mimeType)           | supported            |
           |                   |                      |(1setOf mimeType)     |
           +-------------------+----------------------+----------------------+
           | compression       | No                   | compression-supported|
           | (type3 keyword)   |                      |(1setOf type3 keyword)|
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           | document-k-octets | No                   |job-k-octets-supported|
           | (integer)         |                      | (rangeOf integer)    |
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           | document-         | No                   | job-impressions-     |
           | impressions       |                      | supported            |
           | (integer)         |                      | (rangeOf integer)    |
           +-------------------+----------------------+----------------------+
           | document-media-   | No                   | job-media-sheets-    |
           | sheets            |                      | supported            |
           | (integer)         |                      | (rangeOf integer)    |
           +-------------------+----------------------+----------------------+

         4.2.1 job-sheets (type4 keyword) if for binding on the
              long edge.  This imposition is sometimes called 'duplex' or
              'head-to-head'.
           'two-sided-short-edge': imposes each consecutive pair of source
              page-image upon front and back sides of consecutive media sheets,
              such that the orientation of each pair of source-pages on the
              medium would be correct for the reader as if for binding on the
              short edge.  This imposition is sometimes called 'tumble' or
              'head-to-toe'.

         'two-sided-long-edge', 'two-sided-short-edge', 'tumble', and 'duplex'
         all work the same for portrait or landscape.  However 'head-to-toe' is
         'tumble' in portrait but 'duplex' in landscape.  'head-to-head' also

                                 Expires April 14, 1998
         switches between 'duplex' and 'tumble' when using portrait and
         landscape modes.

         Note: The effect of this attribute on jobs with multiple documents is
         controlled by the "multiple-document-handling" job attribute (section
         4.2.4) and the relationship of this attribute and the other attributes
         that control document processing is described in section 15.4.

         4.2.8  printer-resolution (resolution)

         This attribute determines which if any banner page(s) identifies the resolution that Printer uses for a
         certain Job.

         4.2.9 print-quality (type2 enum)

         This attribute specifies the print quality that the Printer SHALL be use
         for a certain Job.

         The standard values are:

           '3'     'draft': lowest quality available on the printer
           '4'     'normal': normal or intermediate quality on the printer
           '5'     'high': highest quality available on the printer

         4.2.10 finishings (1setOf type2 enum)

         This attribute identifies the finishing operations that the Printer
         uses for each copy of each printed document in a particular Job. For
         Jobs with multiple documents, the "multiple-document-handling"
         attribute determines what constitutes a job.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998 _copy_ for purposes of
         finishing.

         Standard values are:

           '3'     'none':  Perform no job sheet is printed
           'standard': finishing
           '4'     'staple':  Bind the document(s) with one or more site specific standard job sheets staples.
                        The exact number and placement of the staples is site-
                        defined.
           '5'     'punch':  This value indicates that holes are
              printed, e.g. 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 pre-drilled media.
           '6'     '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 single start sheet or both start and end sheet is

                                 Expires April 14, 1998
                        printed

         To force no job sheets, the system administrator SHALL set cover (on cover stock medium) by the
         supported document
                        itself.
           '7'     'bind':  This value indicates that a binding is to be
                        applied to only 'none'.  To force the use of banner pages, document; the
         supported values SHALL not include 'none'.  In this case, if a client
         requests 'none', type and placement of the create request
                        binding is rejected. site-defined."

         Note: The effect of this attribute on jobs with multiple documents is
         controlled by the "multiple-document-handling" job attribute (section
         4.2.6).

         4.2.2 notify-events (1setOf type2 keyword)

         This attribute specifies the events for which
         4.2.4).

         If the end user desires
         some sort client supplies a value of notification.  The "notify-addresses" attribute is used
         to describe the destination addresses for these events.

         Standard values are:

           'none': the Printer SHALL not notify.
           'all': the Printer SHALL notify when 'none' along with any other
         combination of values, it is the events occur.
           'job-completion':  the Printer SHALL notify when same as if only that other
         combination of values had been supplied (that is the job containing
              this 'none' value completes (i.e., enters has
         no effect).

         4.2.11 copies (integer(1:2**31 - 1))

         This attribute specifies the 'completed', 'canceled',
              or 'aborted' state) with or without errors.
           'job-problems': number of copies to be printed.  On many
         devices the Printer SHALL notify when this job has a
              problem (i.e., when supported number of collated copies will be limited by the job leaves
         number of physical output bins on the 'processing' state device, and
              enters may be different
         from the 'processing-stopped' state).
           'job-started-processing': number of uncollated copies which can be supported. The
         "copies-supported" attribute is the Printer SHALL notify when limit on the
              Printer starts processing number of uncollated
         copies supported.  The "collated-copies-supported" attribute is the Job (i.e., when
         limit on the job leaves number of collated copies supported.  The value in the
              'pending' state and enters
         "copies-default" default value attribute applies to either collated or
         uncollated as determined by the 'processing' state).
           'printer-problems': value in the Printer SHALL notify when "multiple-document-
         handling-default" attribute.

         Note: The effect of this job attribute on jobs with multiple documents is
              affected
         controlled by a Printer problem.  This happens when the printer
              enters "multiple-document-handling" job attribute (section
         4.2.4) and the 'stopped' state while relationship of this job attribute and the other attributes
         that control document processing is described in section 15.4.

         4.2.12 page-ranges (1setOf rangeOfInteger)

         This attribute specifies the 'pending',
              'pending-held', 'processing', or 'processing-stopped' state.

           ISSUE: Need to add generic alerts from the Printer MIB.

         4.2.2.1 Event Notification Content

         The content of each event notification is:

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              *time: <US ASCII string representing the absolute time pages of a document which are to be
         printed. In most cases, the event>CRLF
              event: <keyword for exact pages to be printed will be
         generated by a device driver and this attribute would not be required.
         However, when printing an archived document which has already been
         formatted, the event>CRLF
              printer-uri: <Printer's URI>CRLF
              printer-state: <keyword for printer state>CRLF
              *printer-state-reason: <set end user may elect to print just a subset of comma separated keywords>CRLF
              *job-id: <US ASCII string representing the Job Id>CRLF
              *job-state: <keyword for job state>CRLF
              *job-state-reason: <set of comma separated keywords>CRLF
              *message: <US ASCII string>CRLF

         The contents of pages
         contained in the event notification are intended for machine
         consumption more than human consumption, however document. In this case, if page-range = n.m is
         specified, the use of US ASCII
         enables humans first page to retrieve some semantics from be printed will be page n. All subsequent
         pages of the event report
         itself.  Items above marked with document will be printed through and asterisk ('*') are optional.  If
         the implementation does not support any notion of time, then field including page m.

         "page-ranges-supported" is a boolean value indicating whether or not present in
         the notification body.  If printer is capable of supporting the event printing of page ranges.
         This capability may differ from one PDL to another. There is Printer
         related, only the Printer related fields are included. no "page-

                                 Expires April 14, 1998
         ranges-default" attribute.  If the event "page-ranges" attribute is Job related, not
         supplied by the client, all pages of the Job fields SHOULD document will be included.

         4.2.3 notify-addresses (1setOf uri) printed.

         4.2.13 orientation (type2 enum)

         This attribute describes both where (the address) and how (the
         mechanism for delivery ) events are specifies the orientation of the content on the output
         pages to be delivered. The Printer SHALL
         use this attribute printed.  In most cases, the orientation of the content is
         specified within the document format generated by the device driver at
         print time. However, some document formats (such as 'text/plain') do
         not support the set notion of addresses page orientation, and methods for sending
         messages when an event occurs that it is possible to bind
         the end user (job submitter) orientation after the document content has
         registered been generated.  This
         attribute provides an interest in. end user with the means to specify orientation
         for such documents.

         Standard uriScheme values are:

           'mailto': the Printer sends a  text message via email to

           '1'     'portrait':  The content will be imaged across the
              specified email address
           'http': short
                        edge of the Printer sends an HTML formatted message via an HTTP
              POST method to medium.
           '2'     'landscape':  The content will be imaged across the specified URI
           'ftp': long
                        edge of the Printer sends medium.  Landscape is defined to be a text message via an FTP `append' command
                        rotation of the logical page to be imaged by +90
                        degrees with respect to the specified remote file.

         4.2.4 job-priority (integer(1:100))

         This attribute specifies a priority for scheduling medium (i.e. anti-
                        clockwise) from the Job. A higher
         value specifies a higher priority. portrait orientation.  Note:  The value 1 indicates
                        +90 direction was chosen because simple finishing on
                        the lowest
         possible priority. long edge is the same edge whether portrait or
                        landscape
           '3'     'reverse-landscape':  The value 100 indicates content will be imaged across the highest possible
         priority.  Among those jobs that are ready
                        long edge of the medium.  Reverse-landscape is defined
                        to print, a Printer SHALL
         print all jobs with be a priority value rotation of n before printing those the logical page to be imaged by -
                        90 degrees with a
         priority respect to the medium (i.e. clockwise)
                        from the portrait orientation.  Note: The 'reverse-
                        landscape' value of n-1 for all n. was added because some applications
                        rotate landscape -90 degrees from portrait, rather than
                        +90 degrees.

         Note: The mapping effect of vendor-defined
         priority over this range attribute on jobs with multiple documents is implementation-specific.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         4.2.5 job-hold-until (type4 keyword)

         This
         controlled by the "multiple-document-handling" job attribute specifies (section
         4.2.4) and the named time period during which relationship of this attribute and the
         Job print job SHALL become a candidate for printing.

         Standard other attributes
         that control document processing is described in section 15.4.

         4.2.14 document-format (mimeType)

         This attribute identifies the document format of the data to be
         printed.  The standard values for named time periods are:

           'no-hold': immediately, if there this attribute are Internet Media
         types which are sometimes called MIME types.  See the description of
         the 'mimeType' attribute syntax in Section 4.1.9.

                                 Expires April 14, 1998
         4.2.15 compression (type3 keyword)

         This attribute identifies compression algorithms used on compressed
         document data.  The value of this attribute does not other reasons to hold apply the
              job.
           'day-time': during
         encoding of the day.
           'evening': evening
           'night': night
           'weekend': weekend
           'second-shift': second-shift
           'third-shift': third-shift (after midnight)

         An administrator SHALL associate allowable print times with a named
         time period (by means outside IPP 1.0).  An administrator operation itself.

         Standard values are :

           'none': no compression is
         encouraged to pick names that suggest used.
           'deflate':  ZIP public domain inflate/deflate) compression
              technology
           `gzip' GNU zip compression technology described in RFC 1952.
           'compress': UNIX compression technology

         4.2.16 job-k-octets (integer(0:2**31 - 1))

         This attribute specifies the type total size of time period.

         If the value document data in K
         octets, i.e., in units of this attribute specifies a time period that is 1024 octets requested to be  processed in
         the
         future, the Printer SHALL add the 'job-hold-until-specified' job.  The value SHALL be rounded up, so that a job between 1 and
         1024 octets SHALL be indicated as being 1, 1025 to 2048 SHALL be 2,
         etc.

         This value SHALL not include the job's "job-state-reasons" multiplicative factors contributed by
         the number of copies specified by the "copies" attribute, move independent
         of whether the job to device can process multiple copies without making
         multiple passes over the 'pending-
         held' state, document data and SHALL NOT schedule independent of whether the job for printing until
         output is collated or not.  Thus the
         specified time-period arrives.  When value is independent of the specified time period
         arrives,
         implementation.

         Note:  This attribute and the following two attributes ("job-
         impressions" and "job-media-sheets") are not intended to be counters;
         they are intended to be useful routing and scheduling information if
         known. For these three attributes,  the Printer SHALL remove may try to compute the 'job-hold-until-specified'
         value
         from the job's "job-state-reason" attribute and, if no other job
         reasons that keep it is not supplied in the 'pending-held' state remain, create request.  Even if the client
         does supply a value for this attribute in the create request, the
         Printer
         SHALL consider may choose to change the job as value if the Printer is able to
         compute a candidate for processing by moving value which is more accurate than the job client supplied value.
         The Printer may be able to determine the 'pending' state.

         If correct value for this job
         attribute value is the named value 'no-hold', or specified either right at job submission time period is or at any later point in effect has already started ,
         time.  If the job SHALL be a
         candidate for processing immediately.

         4.2.6 multiple-document-handling (type2 keyword)

         This job value of this attribute is relevant only if unknown, the Printer may
         choose to respond with a job consists value of two or more
         documents. It controls finishing operations, and job-sheet placement.
         When '-2' (which signifies "unknown")
         rather than choose to not support the copies attribute exceeds 1, it also controls at all.

         4.2.17 job-impressions (integer(0:2**31 - 1))

         This attribute specifies the order total number of impressions of
         documents..

         Standard values are:

           'single-document': If the files for the
         document(s) being requested by this job are a and b, then files
              a and b SHALL be treated as a single document for finishing
              operations. Also, there SHALL be no slip sheets between files a

         deBry, Hastings, Herriot, Isaacson, Powell to produce.

                                 Expires February xx, April 14, 1998
              and b and the Printer
         This value SHALL NOT force each not include the multiplicative factors contributed by
         the number of copies specified by the "copies" attribute, independent
         of whether the device can process multiple copies without making
         multiple passes over the document to start on a
              new page data and independent of whether the
         output is collated or new media sheet.  If more than one copy not.  Thus the value is made, independent of the
              ordering SHALL
         implementation.

         4.2.18 job-media-sheets (integer(0:2**31 - 1))

         This attribute specifies the total number of media sheets to be a, b, a, b, ....,
         processed for this job.

         Unlike the "job-k-octets" and the Printer "job-impressions" attributes, this
         value SHALL force
              each copy to start on a new sheet.
           'separate-documents-uncollated-copies': If include the multiplicative factors contributes by the files for
         number of copies specified by the job
              are a and b, then each file SHALL be treated as a single document
              for finishing operations. Also, "copies" attribute

         4.3 Job Description Attributes

         The attributes in this section form the attribute group called "job-
         description".  The following table summarizes these attributes.  The
         third column indicates whether the attribute is a client may specify MANDATORY attribute
         that a slip
              sheet MUST be placed between files a and b and the supported by Printer shall force
              each document copy to start on a new sheet. objects.  If more than one
              copy it is made, the ordering SHALL be a, a, b, b, ....
           'separate-documents-collated-copies': If the files for not MANDATORY,
         then it is OPTIONAL.

                                 Expires April 14, 1998
         +----------------------------+----------------------+----------------+
         |      Attribute             |     Syntax           |   MANDATORY?   |
         +----------------------------+----------------------+----------------+
         | job-uri                    | uri                  |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | job-id                     | integer(1:MAX)       |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | job-more-info              | uri                  |                |
         +----------------------------+----------------------+----------------+
         | job-name                   | name                 |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | job-originating-user       | octetString          |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | job-state                  | type1 enum           |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | job-state-reasons          | 1setOf type2 keyword |                |
         +----------------------------+----------------------+----------------+
         | job-state-message          | text                 |                |
         +----------------------------+----------------------+----------------+
         | number-of-documents        | integer              |                |
         +----------------------------+----------------------+----------------+
         | output-device-assigned     | name                 |                |
         +----------------------------+----------------------+----------------+
         | time-of-creation           | integer              |                |
         +----------------------------+----------------------+----------------+
         | time-at-processing         | integer              |                |
         +----------------------------+----------------------+----------------+
         | time-at-completed          | integer              |                |
         +----------------------------+----------------------+----------------+
         | number-of-intervening-jobs | integer              |                |
         +----------------------------+----------------------+----------------+
         | job-message-from-operator  | text                 |                |
         +----------------------------+----------------------+----------------+
         | job-k-octets-processed     | integer              |                |
         +----------------------------+----------------------+----------------+
         | job-impressions-completed  | integer              |                |
         +----------------------------+----------------------+----------------+
         | job-media-sheets-completed | integer              |                |
         +----------------------------+----------------------+----------------+
         | attributes-charset         | charSet              |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | attributes-natural-language| naturalLanguage      |  MANDATORY     |
         +----------------------------+----------------------+----------------+

         4.3.1 job-uri (uri)

                                 Expires April 14, 1998
         This attribute contains the job are
              a and b, then each file SHALL be treated as a single document URI 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, ...., and the Printer
              shall force each document copy to start job.  The Printer, on receipt
         of a new sheet

         4.2.7 media (type4 keyword)

         This job attribute job, generates a URI which identifies the medium new Job on that the
         Printer. The Printer uses for all
         pages returns the value of the Job.

         The values for "media" include medium-names, medium-sizes, input-trays
         and electronic forms so that one "job-uri" attribute specifies the media. If a
         printer allows a client to specify a medium name as the value
         part of this
         attribute, such a medium name implicitly selects an input-tray that
         contains the specified medium.  If a printer allows a client response to
         specify a medium size as the value of this attribute, such a medium
         size implicitly selects a medium name that in turn implicitly selects create request.   This MUST be an input-tray that contains the medium with HTTP
         schemed URI, however the specified size.  If precise format of a
         printer allows Job URI is implementation
         dependent.

         For a client to specify an input-tray as the value description 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-
         feed input-trays.  If a printer allows a client attribute and its relationship to specify an
         electronic form as the value of this
         following "job-id" attribute, such an electronic
         form implicitly selects a medium-name that see the discussion in turn implicitly selects
         an input-tray that section 2.4 on
         "Object Identity".

         4.3.2 job-id (integer(1:MAX))

         This attribute contains the medium specified by ID of the electronic
         form. job.  The electronic form also implicitly selects Printer, on receipt of
         a new job, generates an image that ID which identifies the new Job on that
         Printer. The Printer SHALL merge with returns the data from value of the document "job-id" attribute as its prints each
         page.

         ISSUE: What should we do about "media-ready"?

         Standard values are (taken from ISO DPA and
         part of the Printer MIB) response to a create request.

         For a description of this attribute and are
         listed its relationship to the
         previous "job-uri" attribute, see the discussion in section 14.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         4.2.8 number-up (type3 keyword)

         This job 2.4 on
         "Object Identity".

         4.3.3 job-more-info (uri)

         Similar to "printer-more-info", this attribute specifies contains the number of source page-images to
         impose upon a single side of URI
         referencing some resource with more information about this Job object,
         perhaps an instance HTML page containing information about the Job.

         4.3.4 job-name (name)

         This attribute is the name of the job.  It is a selected medium.

         Standard values are:

           'none': name that is more user
         friendly than the "job-uri" attribute value.  It does not need to be
         unique between Jobs.  The Printer SHALL Job's "job-name" attribute is set to the
         value supplied by the client in the "job-name" operation attribute in
         the create request.   If, however, if the "job-name" operation
         attribute is not include any embellishments and SHALL
              place one logical page on a single side of an instance of supplied by the client in the create request, the
              selected medium without any translation, scaling, or rotation.
           'one': The Printer SHALL place one logical page
         Printer, on a single side of
              an instance creation of the selected medium (MAY add some sort of
              translation, scaling, or rotation).
           'two': The Printer Job, SHALL place two logical pages on generate a single side
              of an instance name. The printer
         SHOULD generate the value of the selected medium (MAY add some sort Job's "job-name" attribute from the
         first of
              translation, scaling, or rotation).
           'four': The Printer SHALL place four logical pages on the following sources that produces a single side
              of an instance of value: 1) the selected medium (MAY add some sort
         "document-URI" attribute of
              translation, scaling, or rotation).

         This the first (or only) document, 2) the
         "document-name" operation attribute primarily controls of the translation, scaling and
         rotation first (or only) document,
         or 3) any other piece of page images, but a site may choose to add embellishments,
         such as borders to each logical page.

         4.2.9 sides (type2 keyword) Job specific information.

         4.3.5 job-originating-user (octetString)

         This attribute specifies how source page-images are to be imposed upon contains the sides of an instance identity of a selected medium. the end user that submitted
         the print job.  The standard values are:

           'one-sided': imposes each consecutive source page-image upon Printer object sets this attribute to the
              same side of consecutive media sheets.
           'two-sided-long-edge': imposes each consecutive pair of source
              page-image upon front and back sides of consecutive media sheets,
              such most

                                 Expires April 14, 1998
         authenticated name that it can obtain from the orientation of each pair authentication service
         over which the IPP operation was received.

         4.3.6 job-state (type1 enum)

         This attribute identifies the current state of source-pages on the
              medium would be correct job.  Even though
         the IPP protocol defines eight values for the reader as if job states, implementations
         only need to support those states which are appropriate for binding on the
              long edge.  This imposition is sometimes called 'duplex'.
           'two-sided-short-edge': imposes each consecutive pair of source
              page-image upon front and back sides of consecutive media sheets,
              such that
         particular implementation.  In other words, a Printer supports only
         those job states implemented by the orientation of each pair of source-pages on output device and available to the
              medium would be correct
         Printer object implementation.

         Standard values are:

           'unknown'(2):  The job state is not known, or its state is
              indeterminate.
           'pending'(3):  The job is a candidate to start processing, but is
              not yet processing.
           'pending-held'(4):  The job is not a candidate for processing for
              any number of reasons but will return to the reader 'pending' state as
              soon as if for binding on the
              short edge.  This imposition reasons are no longer present.  The job's "job-state-
              reason" attribute SHALL indicate why the job is sometimes called 'tumble' no longer a
              candidate for processing.
           'processing'(5):  One or
              'head-to-toe'.

         'two-sided-long-edge', 'two-sided-short-edge', 'tumble', and 'duplex'
         all work more of:
              1.  the same for portrait job is using, or landscape.  However 'head-to-toe' is
         'tumble' in portrait but 'duplex' in landscape.  'head-to-head' also

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         switches between 'duplex' and 'tumble' when using portrait and
         landscape modes.

         4.2.10 printer-resolution (resoultion)

         This attribute identifies the resolution attempting to use, one or more purely
                software processes that Printer uses for are analyzing, creating, or
                interpreting a
         certain Job.

           The value PDL, etc.,
              2.  the job is using, or is attempting to use, one or more
                hardware devices that are interpreting a special type consisting of a pair of integers and PDL, making marks on
                a
              value which specifies medium, and/or performing finishing, such as stapling, etc.,
              3. the units server has made the job ready for printing, but the two integers. The three
              values are output
                device is not yet printing it, either because the same as those specified in job hasn't
                reached the draft-ietf-
              printmib-mib-info-02.txt as prtMarkerAddressabilityFeedDir (the
              resolution in output device or because the feed direction),
              prtMarkerAddressabilityXFeedDir (the resolution job is queued in the cross feed
              direction), and prtMarkerAddressabilityUnit (the units of
                output device or some other spooler, awaiting the
              first two values, namely dots per inch and dots per centimeter).
         4.2.11 print-quality (type2 enum)

         This output
                device to print it.

              Implementations MAY, though they NEED NOT, include additional
              values in the job's "job-state-reasons" attribute specifies to indicate the print quality that
              progress of the Printer uses for a
         certain Job.

         The standard values are:

           '3'     'draft': lowest quality available on job, such as adding the printer
           '4'     'normal': normal or intermediate quality on 'job-printing' value to
              indicate when the printer
           '5'     'high': highest quality available device is actually making marks on a medium.
              When the printer

         4.2.12 finishings (1setOf type2 enum)

         This attribute identifies job is in the finishing operations that 'processing' state, the Printer
         uses for each copy of each printed document in a particular Job. For
         Jobs with multiple documents, entire job state
              includes the "multiple-document-handling"
         attribute determines what constitutes a _copy_ for purposes of
         finishing.

         Standard values are:

           '3'     'none':  Perform no finishing
           '4'     'staple':  Bind detailed status represented in the document(s) with one or more staples.
                        The exact number printer's
              "printer-state", "printer-state-reasons", and placement of "printer-state-
              message" attributes.
              Implementations MAY include additional values in the staples is site-
                        defined.
           '5'     'staple-top-left':  Place one or more staples on job's "job-
              state-reasons" attribute to indicate the top
                        left corner progress of the document(s).
           '6'     'staple-bottom-left':  Place one or more staples on job,
              such as adding the
                        bottom left corner of 'job-printing' value to indicate when the document(s).
           '7'     'staple-top-right':  Place one or more staples
              output device is actually making marks on paper and/or the top
                        right corner of the document(s).

         deBry, Hastings, Herriot, Isaacson, Powell

                                 Expires February xx, April 14, 1998
           '8'     'staple-bottom-right':  Place one or more staples on the
                        bottom right corner of the document(s).
           '9'     'saddle-stitch':  Bind
              'processing-to-stop-point' value to indicate that the document(s) with one server or more
                        staples (wire stitches) along
              device is in the middle fold.  The
                        exact number and placement process of canceling or aborting the stitches is site-
                        defined.
           '10'    'edge-stitch':  Bind the document(s) job.  Most
              implementations won't bother with one or more
                        staples (wire stitches) along one edge. this nuance.
           'processing-stopped'(6):  The exact job has stopped while processing for
              any number and placement of reasons and will return to the staples is site-defined.
           '11'    'punch':  This value indicates that holes are required in 'processing' state
              as soon as the finished document. reasons are no longer present.

              The exact number and placement
                        of job's "job-state-reason" attribute MAY indicate why the holes job
              has stopped processing.  For example, if the output device is site-defined  The punch specification
              stopped, the 'printer-stopped' value MAY be satisfied (in a site- and implementation-
                        specific manner) either by drilling/punching, or by
                        substituting pre-drilled media.
           '12'    'cover':  This value is specified when it is desired to
                        select a non-printed (or pre-printed) cover for included in the
                        document. This does not supplant job's
              "job-state-reasons" attribute.

              Note:  When an output device is stopped, the specification of a
                        printed cover (on cover stock medium) device usually
              indicates its condition in human readable form locally at the
              device.  A client can obtain more complete device status remotely
              by querying the document
                        itself.
           '13'    'bind':  This value indicates that printer's "printer-state", "printer-state-
              reasons" and "printer-state-message" attributes.

           'canceled'(7):  The job has been canceled by a binding is to be
                        applied to Cancel-Job operation
              and the document; Printer has completed canceling the type job  and placement of all job
              status attributes have reached their final values for the
                        binding is site-defined."

         4.2.13 copies (integer(1:2**31 - 1))

         This attribute specifies job.
              While the number of copies to be printed.  On many
         devices Printer is canceling the supported number of collated copies will be limited by job, the
         number of  physical output bins on job's "job-state-
              reasons" attribute SHOULD contain the device, 'processing-to-stop-point'
              value and may be different
         from the number one of uncollated copies which can be supported. Therefore the copies-supported attribute specifies a set of ranges; 'canceled-by-user', 'canceled-by-operator',
              or 'canceled-at-device' value.
           'aborted'(8):  The job has been aborted by the first
         defines system, usually
              while the supported range of values for uncollated copies, job was in the 'processing' or 'processing-stopped'
              state and the
         second Printer has completed aborting the supported range of values for collated printing.  The set
         of default job and all job
              status attributes have reached their final values for copies specify the default number of uncollated
         copies followed by job.
              While the default number of collated copies.

         The effect of this attribute server or device is controlled by aborting the "multiple-documents-
         handling" attribute (section 4.2.6).This job, the job's "job-
              state-reasons" attribute specifies MAY contain the
         number of copies 'processing-to-stop-
              point' and 'aborted-by-system' values.  If supported, the
              'aborted-by-system' value SHALL remain while the job is in the
              'aborted' state.
           'completed'(9):  The job has completed successfully or with
              warnings or errors after processing and all of the job to be printed.

         4.2.14 page-range (rangeOf integer)

         This attribute specifies the pages of a document which are to be
         printed. In most cases, media
              sheets have been successfully stacked in the exact pages to be printed will be
         generated by a device driver and appropriate output
              bin(s).  The job's "job-state-reasons" attribute SHOULD contain
              one of: 'completed-successfully', 'completed-with-warnings', or
              'completed-with-errors' values.

         The final value for this attribute would not SHALL be required.
         However, when printing an archived document which has already been
         formatted, one of: 'completed',
         'canceled', or 'aborted' before the end user may elect to print just a subset of Printer removes the pages
         contained job
         altogether.  The length of time that jobs remain in the document. In this case, if page-range = n.m is

         deBry, Hastings, Herriot, Isaacson, Powell 'canceled',
         'aborted', and 'completed' states depends on implementation.

         The following figure shows the normal job state transitions.

                                 Expires February xx, April 14, 1998
         specified, the first page to be printed will be page n. All subsequent
         pages of the document will be printed through and including page m.

         Page-range supported is
                                                            +----> canceled
                                                           /
             +----> pending --------> processing ---------+------> completed
             |         ^                   ^               \
         --->+         |                   |                +----> aborted
             |         v                   v               /
             +----> pending-held    processing-stopped ---+

         Normally a boolean value indicating whether or job progresses from left to right.  Other state transitions
         are unlikely, but are not forbidden.  Not shown are the
         printer is capable of supporting transitions to
         the printing of page ranges.  This
         capability may differ 'canceled' state from the 'pending', 'pending-held', and
         'processing-stopped' states.

         Jobs reach one PDL to another. The page-range default
         value is always zero (0) of the three terminal states: 'completed', 'canceled',
         or 'aborted', after the jobs have completed all activity, including
         stacking output media, after the jobs have completed all activity, and indicates that
         all pages of job status attributes have reached their final values for the document
         will be printed if a page-range is not specified.

         4.2.15 orientation (type2 enum) job.

         4.3.7 job-state-reasons (1setOf  type2 keyword)

         This attribute specifies provides additional information about the orientation job's current
         state, i.e., information that augments the value of the content on job's "job-
         state" attribute.

         Implementation of these values is OPTIONAL, i.e., a Printer NEED NOT
         implement them, even if (1) the output
         pages to be printed.  In most cases, device supports the orientation of
         functionality represented by the content reason and (2) is
         specified within available to the document format generated by
         Printer object implementation.  These values MAY be used with any job
         state or states for which the device driver at
         print time. However, some document formats (such as "text") do not
         support reason makes sense.  Furthermore, when
         implemented, the notion of page orientation, Printer SHALL return these values when the reason
         applies and it is possible to bind SHALL NOT return them when the
         orientation after reason no longer applies
         whether the document content has been generated.  This value of the Job's "job-state" attribute provides an end user with changed or not.
         When the means to specify orientation Job does not have any reasons for such documents.

         Standard being in its current state,
         the Printer MAY set the value of the Job's "job-state-reasons"
         attribute to 'none'.

         NOTE - While values are:

           '1'     'portrait': The content will cannot be printed across added to the short
                        edge of 'job-state' attribute
         without impacting deployed clients that take actions upon receiving
         "job-state" values, it is the media.
           '2'     'landscape': The content will intent that additional "job-state-
         reasons" values can be printed across the long
                        edge of defined and registered without impacting such
         deployed clients.  In other words, the media.

         4.2.16 document-format (mimeType)

         This "job-state-reasons" attribute defines the document format of the data
         is intended to be printed. extensible.

         The following standard values for this attribute are MIME types.  Since the
         complete list is rather long, the full enumeration defined.  For ease of standard understanding,
         the values
         is found are presented in section 13 APPENDIX C: "document-format" values.

         If the "document-format" is unknown for a certain document, the client
         does not supply the attribute order in which the create request or the Send-
         Document Request.

         4.2.17 compression (type3 keyword)

         This attribute identifies compression algorithms used for compressed
         document data (not the operation data).

         Standard values reasons are : likely
         to occur (if implemented), starting with the 'job-incoming' value:

           'none':  There are no compression is used.
           'zip':ZIP (inflate/deflate) compression technology
           `gzip' GNU zip compression technology described in RFC 1952.

         deBry, Hastings, Herriot, Isaacson, Powell reasons for the job's current state.

                                 Expires February xx, April 14, 1998
           'compress': UNIX compression technology

           ISSUE: Look what HTTP defines.

         4.2.18 job-k-octets (integer(0:2**31 - 1))

         This attribute specifies the total size of the job in K octets, i.e.,
         in units of 1024 octets.
           'job-incoming':  The value SHALL be rounded up, so that a job
         between 1 and 1024 octets SHALL be indicated as being 1, 1025 to 2048
         SHALL be 2, etc.

         Note:  This attribute and the following two attributes ("job-
         impressions" and "job-media-sheets") are not intended to be counters;
         they are intended to be useful routing and scheduling information if
         known. For these three attributes, CreateJob operation has been accepted by the Printer may try to compute
              Printer, but the
         value if it Printer is expecting additional Send-Document
              and/or Send-URI operations and/or is accessing/accepting document
              data.
           'submission-interrupted':  The job was not supplied in completely submitted for
              some unforeseen reason, such as: (1) the create request.  Even if Printer has crashed
              before the client
         does supply a value for this attribute in job was closed by the create request, client, (2) the Printer may choose to change or the value if
              document transfer method has crashed in some non-recoverable way
              before the Printer is able document data was entirely transferred to
         compute a value which is more accurate than the Printer,
              (3) the client supplied value. crashed or failed to close the job before the
              time-out period.
           'job-outgoing':  The Printer may be able is transmitting the job to determine the correct output
              device.
           'job-hold-until-specified':  The value for this of the job's "job-hold-
              until" attribute either right at job submission was specified with a time or at any later point period that is still
              in
         time.  If the value of future.  The job SHALL NOT be a candidate for processing
              until this attribute reason is unknown, the Printer may
         choose removed and there are no other reasons to respond with a value
              hold the job.
           'resources-are-not-ready':  At least one of '-2' (which signifies "unknown")
         rather than choose to not support the attribute at all.

         4.2.19 job-impressions (integer(0:2**31 - 1))

         This attribute specifies resources needed by
              the total number job, such as media, fonts, resource objects, etc., is not
              ready on any of impressions the physical printer's for this job.

         4.2.20 job-media-sheets (integer(0:2**31 - 1)) which the job is a
              candidate.  This attribute specifies condition MAY be detected when the total number of media sheets used by this
         job.

         4.3 Job Description Attributes job is
              accepted, or subsequently while the job is pending or processing,
              depending on implementation.
           'printer-stopped-partly':  The attributes in this section form value of the Printer's "printer-
              state-reasons" attribute group called "job-
         description".  The following table summarizes these attributes. contains the value 'stopped-partly'.
           'printer-stopped':  The
         third column indicates whether value of the Printer's "printer-state"
              attribute is a MANDATORY attribute.
         If it 'stopped'.
           'job-interpreting': Job is not MANDATORY, then it in the 'processing' state, but more
              specifically, the Printer is OPTIONAL.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         +----------------------------+----------------------+----------------+
         |      Attribute             |     Syntax           |   MANDATORY?   |
         +----------------------------+----------------------+----------------+
         | job-uri                    | uri                  |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | job-id                     | 32bit unsigned       |  MANDATORY     |
         |   (this or job-uri)        |                      |                |
         +----------------------------+----------------------+----------------+
         | job-more-info              | uri                  |                |
         +----------------------------+----------------------+----------------+
         | job-name                   | name                 |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | job-originating-user       | name                 |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | job-originating-host       | name                 |                |
         +----------------------------+----------------------+----------------+
         | user-human-language        | human-language       |                |
         +----------------------------+----------------------+----------------+
         | job-state                  | type1 enum           |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | job-state-reasons          | 1setOf type2 keyword |                |
         +----------------------------+----------------------+----------------+
         | job-state-message          | text                 |                |
         +----------------------------+----------------------+----------------+
         | output-device-assigned     | name                 |                |
         +----------------------------+----------------------+----------------+
         | time-at-pending            | seconds              |                |
         +----------------------------+----------------------+----------------+
         | time-at-processing         | seconds              |                |
         +----------------------------+----------------------+----------------+
         | time-at-completed          | seconds              |                |
         +----------------------------+----------------------+----------------+
         | number-of-intervening-jobs | integer              |                |
         +----------------------------+----------------------+----------------+
         | job-message-from-operator  | text                 |                |
         +----------------------------+----------------------+----------------+
         | job-k-octets-processed     | integer              |                |
         +----------------------------+----------------------+----------------+
         | job-impressions-completed  | integer              |                |
         +----------------------------+----------------------+----------------+
         | job-media-sheets-completed | integer              |                |
         +----------------------------+----------------------+----------------+

         4.3.1 job-uri (uri) interpreting the document data.
           'job-queued': Job is in the 'processing' state, but more
              specifically, the Printer has queued the document data.
           'job-transforming': Job is in the 'processing' state, but more
              specifically, the Printer is interpreting document data and
              producing another electronic representation.
           'job-printing':  The output device is marking media. This attribute contains value is
              useful for Printers which spend a great deal of time processing
              (1) when no marking is happening and then want to show that
              marking is now happening or (2) when the URI job is in the process of
              being canceled or aborted while the job remains in the
              'processing' state, but the marking has not yet stopped so that
              impression or sheet counts are still increasing for the job.
           'job-canceled-by-user':  The Printer, on receipt job was canceled by the owner of the
              job using the Cancel-Job request, i.e., by a new job, generates a URI which identifies user whose name is
              the new Job on that
         Printer. The Printer returns same as the value of the "job-uri" attribute job's "job-originating-user"
              attribute, or by some other authorized end-user, such as

         deBry, Hastings, Herriot, Isaacson, Powell a member
              of the job owner's security group.

                                 Expires February xx, April 14, 1998
         part of
           'job-canceled-by-operator':  The job was canceled by the response to operator
              using the Cancel-Job request, i.e., by a create request. user who has been
              authenticated as having operator privileges (whether local or
              remote).
           'job-canceled-at-device':  The precise format of job was canceled by an unidentified
              local user, i.e., a user at a console at the device.
           'aborted-by-system':  The job URI (1) is implementation dependent.

         4.3.2 job-id (32bit unsigned integer)

         This attribute contains in the ID process of being
              aborted, (2) has been aborted by the job.  The Printer, on receipt of
         a new job, generates an ID which identifies system and placed in the new Job on that
         Printer. The Printer returns
              'aborted' state, or (3) has been aborted by the value of system and placed
              in the "job-id" attribute as
         part of 'pending-held' state, so that a user or operator can
              manually try the response to job again.
           'processing-to-stop-point':  The requester has issued a create request.

         ISSUE: job-uri Cancel-job
              operation or job-id?

         4.3.3 job-uri-user (uri)

         Similar to "job-uri", this attribute contains the URI referencing an
         HTML page containing information about Printer object has aborted the Job.

         4.3.4 job-name (name)

         This attribute job, but is still
              performing some actions on the name of the job.  It is job until a name that specified stop point
              occurs or job termination/cleanup is more user
         friendly than the "job-uri" attribute value.  It does not need to be
         unique.  The Job's "job-name" attribute completed.

              This reason is set recommended to the value supplied
         by the client be used in conjunction with the "job-name" operation attribute in
              'processing' job state to indicate that the create
         request.   If, however, if it Printer object is not supplied by
              still performing some actions on the client job while the job remains in
              the
         create request, 'processing' state.  After all the Printer, on creation of job's job description
              attributes have stopped incrementing, the Job, SHALL generate a
         name.  The Printer can generate object moves
              the name using any method convenient job from the 'processing' state to the application. 'canceled' or
              'aborted' job states.

           'service-off-line':  The Printer MAY choose to use the value of the
         "document-name" attribute of is off-line and accepting no jobs.
              All 'pending' jobs are put into the first (or only) Document (or any
         other piece of Job specific information) as a basis for generating a
         Job name.

         ISSUE: There has been some suggestion to add a "job-user-label".  The
         idea for this attribute was to allow a client to supply some
         meaningful label to 'pending-held' state.  This
              situation could be applied to the Job independent of true if the Job URI service's or the Job ID.  However, after reviewing the semantics of "job-name",
         the two sound identical.

         4.3.5 job-originating-user (name) document transform's
              input is impaired or broken.
           'job-completed-successfully':  The job completed successfully.
           'job-completed-with-warnings':  The job completed with warnings.
           'job-completed-with-errors':  The job completed with errors (and
              possibly warnings too).

         4.3.8 job-state-message (text)

         This attribute attributes specifies supplemental information about the user name of the person submitting the
         print job. Job State
         in human readable text. The Printer sets this attribute object SHALL be able to generate
         this message in any of the most authenticated
         name that it can obtain from natural languages identified by the protocol over which
         Printer's "natural-language-supported" attribute (see the "attributes-
         natural-language" operation was
         received from the client.

         4.3.6 job-originating-host (name) attribute specified in Section 3.1.3.1).

         4.3.9 number-of-documents (integer(0:2**31 - 1))

         This attribute identifies indicates the originating host number of documents in the job, i.e, the
         number of Send-Document, Send-URI, Print-Job, or Print-URI operations
         that the job. The Printer
         sets has accepted for this attribute to job, regardless of whether the most authenticated host name it can obtain

         deBry, Hastings, Herriot, Isaacson, Powell
         document data has reached the Printer or not.

                                 Expires February xx, April 14, 1998
         from the protocol over which the operation was received from
         Implementations supporting the
         client.

         4.3.7 user-human-language (human-language) OPTIONAL Create-Job/Send-Document/Send-
         URI operations SHOULD support this attribute.

         4.3.10 output-device-assigned (name)

         This attribute identifies the human language and optionally the
         country of the end user.  The Printer sets this attribute Output Device to the most
         reliable value it can obtain from the protocol over which the Print
         operation was received from the client.

         The Printer uses has
         assigned this attribute to determine the human language it
         SHOULD use for translating ALL text strings that it sends back to job.  If an output device implements an embedded IPP
         Printer, the
         end user.  The Printer has a "human-languages-supported" supported
         values attribute and a "human-language" default value NEED NOT set this attribute.

         ISSUE: This should be  If a Job Template attribute.

         4.3.8 job-state (type1 enum)

         This attribute identifies Print Server
         implements a Printer, the current state of value MAY be empty until the Printer assigns
         an output device to the job.  Even though

         4.3.11 time-of-creation (integer)

         This attribute indicates the IPP protocol defines eight values for job states, implementations
         only need to support those states point in time at which are appropriate for the
         particular implementation. Job object was
         created.  In other words, a Printer supports only
         those job states implemented by the output device and available order to populate this attribute, the Printer object implementation.

         Standard values are:

           'unknown'(2):  The job state is not known, or uses
         the value in its state is
              indeterminate.
           'pending'(3):  The job is a candidate to start processing, but is
              not yet processing.
           'pending-held'(4):  The job is not a candidate for processing for
              any number of reasons but will return to "printer-up-time" attribute at the 'pending' state as
              soon as time the reasons are no longer present.  The job's "job-state-
              reason" Job
         object is created.

         4.3.12 time-at-processing (integer)

         This attribute SHALL indicate why indicates the job is no longer a
              candidate for processing.
           'processing'(5):  Either:
              1. point in time at which the job is using, or is attempting Job object
         began processing.  In order 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
              2. populate this attribute, the server has made Printer
         object uses the job ready for printing, but value in its "printer-up-time" attribute at the
                output device time
         the Job object is not yet printing it, either because moved into the job
                hasn't reached 'processing' state for the output device or because first
         time.

         4.3.13 time-at-completed (integer)

         This attribute indicates the job is queued point in time at which the output device Job object
         completed (or was cancelled or some other spooler, awaiting the
                output device to print it.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         ISSUE:  Suggested change aborted).  In order to (but populate this must be synchronized with JMP)

           'processing'(5): One of:
              1. the job is using, or is attempting to use hardware devices
                that are making marks on a medium, and/or performing
                finishing, such as stapling OR
              2.
         attribute, the job is using, or is attempting to use software processes
                that are analyzing or interpreting a PDL without making marks
                on a medium.
              3. Printer object uses the server has made value in its "printer-up-time"
         attribute at the job ready for printing, but time the output
                device Job object is not yet printing it, either because the job hasn't
                reached moved into the output device 'completed' or because
         'canceled' or 'aborted' state.

         4.3.14 number-of-intervening-jobs (integer(0:2**31 - 1))

         This attribute indicates the number of jobs that are "ahead" of this
         job is queued in the
                output device or some other spooler, awaiting the output
                device relative chronological order of expected time to print it.

              When complete
         (i.e., the job current scheduled order). For efficiency, it is in only
         necessary to calculate this value when an operation is performed that
         requests this attribute.

         4.3.15 job-message-from-operator (text)

         This attribute provides a message from an operator, system
         administrator or "intelligent" process to indicate to the 'processing' state, end user the entire job state
              includes
         reasons for modification or other management action taken on a job.

                                 Expires April 14, 1998
         4.3.16 job-k-octets-processed (integer(0:2**31 - 1))

         This attribute specifies the detailed status represented number of octets processed in the printer's
              "printer-state", "printer-state-reasons", and "printer-state-
              message" attributes.
              Implementations MAY include additional values K octets,
         i.e., in the job's "job-
              state-reasons" attribute units of 1024 octets.  The value SHALL be rounded up, so that
         a job between 1 and 1024 octets SHALL be indicated as being 1, 1025 to indicate
         2048 SHALL be 2, etc.

         For implementations where multiple copies are produced by the progress of
         interpreter with only a single pass over the job,
              such as adding data, the 'job-printing' final value
         SHALL be equal to indicate when the
              output device is actually making marks on paper.  Most
              implementations won't bother with this nuance.

           'processing-stopped'(6):  The job has stopped while processing for
              any number value of reasons and will return to the 'processing' state
              as soon as the reasons "job-k-octets" attribute.  For
         implementations where multiple copies are no longer present.
              The job's "job-state-reason" attribute MAY indicate why produced by the job
              has stopped processing.  For example, if interpreter
         by processing the output device is
              stopped, data for each copy, the 'printer-stopped' final value MAY SHALL be included in the job's
              "job-state-reasons" attribute.
              NOTE - When an output device is stopped, the device usually
              indicates its condition in human readable form locally at a
         multiple of the
              device.  A client can obtain more complete device status remotely
              by querying value of the printer's "printer-state", "printer-state-
              reasons" "job-k-octets" attribute.

         Note: This attribute and "printer-state-message" attributes.
           'canceled'(7):  The job has been canceled by a Cancel-Job operation the following two attributes ("job-
         impressions-completed" and "job-sheets-completed") are intended to be
         counters. That is, if the "job-state" is either (1) in 'processing' or 'processing-
         stopped', this value is intended to contain the process amount of terminating or (2) has
              completed terminating.  The job's "job-state-reasons" attribute
              SHOULD contain either the 'canceled-by-user' or 'canceled-by-
              operator' value.
           'aborted'(8):  The job that
         has been aborted by processed to the system, usually
              while time at which the attributes are requested.
         For any of these three attributes, the Printer may choose to return
         the value '-2' (which represents "unknown") rather than choose to not
         support the attribute at all.

         4.3.17 job-impressions-completed  (integer(0:2**31 - 1))

         This job was in attribute specifies the number of impressions completed for
         the 'processing' or 'processing-stopped'
              state.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           'completed'(9):  The job has so far.  For printing devices, the impressions completed successfully or with
              warnings or errors after processing
         includes interpreting, marking, and all of stacking the job media
              sheets have been successfully stacked output. This
         attribute is intended to be a counter as in the appropriate output
              bin(s).  The job's "job-state-reasons" attribute SHOULD contain
              one of: 'completed-successfully', 'completed-with-warnings', or
              'completed-with-errors' values.

         The Job Monitoring MIB.

         For implementations where multiple copies are produced by the
         interpreter with only a single pass over the data, the final value for this attribute
         SHALL be one of: 'completed',
         'canceled', or 'aborted' before the Printer removes equal to the job
         altogether.  The length value of time that jobs remain in the 'canceled',
         'aborted', and 'completed' states depends on implementation.

         The following figure shows "job-impressions" attribute.  For
         implementations where multiple copies are produced by the normal job state transitions.

                                                             +----> canceled
                                                            /
             +----> pending --------> interpreter
         by processing ---------+------> completed
             |         ^                   ^                \
         --->+         |                   |                 +----> aborted
             |         v                   v                /
             +----> pending-held    processing-stopped ----+

         Normally a job progresses from left to right.  Other state transitions
         are unlikely, but are not forbidden.  Not shown are the transitions to data for each copy, the final value SHALL be a
         multiple of the 'canceled' state from value of the 'pending', 'pending-held', 'processing', "job-impressions" attribute.

         4.3.18 job-media-sheets-completed (integer(0:2**31 - 1))

         This job attribute specifies the media-sheets completed marking and 'processing-stopped' states.

         4.3.9 job-state-reasons (1setOf  type2 keyword)
         stacking for the entire job so far whether those sheets have been
         processed on one side or on both. This attribute provides additional information about is intended to be a
         counter as in the job's current
         state, i.e., information that augments Job Monitoring MIB.

         4.3.19 attributes-charset (charSet)

         This attribute is populated using the value in the client supplied
         "attributes-charset" attribute in the create request.  It identifies

                                 Expires April 14, 1998
         the charset (coded character set and encoding method) used for any Job
         attributes with attribute syntax 'text' and 'name' whether supplied by
         the client and/or returned by the Printer object.  See Section 3.1.3
         for a complete description of the job's "job-
         state" "attributes-charset" operation
         attribute.

         Implementation of these values

         4.3.20 attributes-natural-language (naturalLanguage)

         4.4 This attribute is OPTIONAL, i.e., a Printer NEED NOT
         implement them, even if (1) populated using the output device supports value in the
         functionality represented by client supplied
         "attributes-natural-language" attribute in the reason create request.  It
         identifies the natural language used for any Job attributes with
         attribute syntax 'text' and (2) is available to 'name' whether supplied by the client
         and/or returned by the Printer object implementation.  These values MAY object.  See Section 3.1.3 for a
         complete description of the "attributes-natural-language" operation
         attribute.  See Section 4.1.1 for how an exception natural languages
         may be used with any job
         state or states supplied explicitly for which each 'text' and 'name' attribute value
         that differs from the reason makes sense.  Furthermore, when
         implemented, value identified by the "job-natural-language"
         attribute.Printer Description Attributes

         These attributes form the attribute group called "printer-
         description".  A Printer SHALL return object may be realized in either a print
         server or output device.  Note: How these values when attributes are set by an
         Administrator is outside the reason
         applies scope of this specification.  The
         following table summarizes these attributes, their syntax, and SHALL NOT return them when the reason no longer applies whether the value of the job's "job-state"
         or not they are MANDATORY for a Printer object to support.  If they
         are not MANDATORY, they are OPTIONAL.

                                 Expires April 14, 1998
         +----------------------------+----------------------+----------------+
         |      Attribute             |     Syntax           |   MANDATORY?   |
         +----------------------------+----------------------+----------------+
         | printer-uri                | uri                  |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | printer-name               | name                 |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | printer-location           | text                 |                |
         +----------------------------+----------------------+----------------+
         | printer-info               | text                 |                |
         +----------------------------+----------------------+----------------+
         | printer-more-info          | uri                  |                |
         +----------------------------+----------------------+----------------+
         | printer-driver-installer   | uri                  |                |
         +----------------------------+----------------------+----------------+
         | printer-make-and-model     | text                 |                |
         +----------------------------+----------------------+----------------+
         | printer-more-info-         | uri                  |                |
         | manufacturer               |                      |                |
         +----------------------------+----------------------+----------------+
         | printer-state              | type1 enum           |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | printer-state-reasons      | 1setOf type2 keyword |                |
         +----------------------------+----------------------+----------------+
         | printer-state-message      | text                 |                |
         +----------------------------+----------------------+----------------+
         | operations-supported       | 1setOf operation     |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | printer-charset            | charSet              |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | charsets-supported         | 1setOf charSet       |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | printer-natural-language   | naturalLanguage      |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | natural-languages-supported| 1setOf               |  MANDATORY     |
         |                            |   naturalLanguage    |                |
         +----------------------------+----------------------+----------------+
         | printer-is-accepting-jobs  | boolean              |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | queued-job-count           | integer              |                |
         +----------------------------+----------------------+----------------+
         | printer-message-from-      | text                 |                |
         | operator                   |                      |                |
         +----------------------------+----------------------+----------------+
         | color-supported            | boolean              |                |
         +----------------------------+----------------------+----------------+
         | pdl-override               | type2 keyword        |  MANDATORY     |
         +----------------------------+----------------------+----------------+

                                 Expires April 14, 1998
         | security-mechanisms-       | 1setOf keyword       |                |
         | supported                  |                      |                |
         +----------------------------+----------------------+----------------+
         | printer-up-time            | integer              |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | printer-current-time       | dateTime             |                |
         +----------------------------+----------------------+----------------+
         | multiple-operation-time-out| integer              |                |
         +----------------------------+----------------------+----------------+

         4.4.1 printer-uri (uri)

         This attribute changed or not.
         When contains the job does not have any reasons URI for being in its current state,
         the Printer shall set the value of the job's "job-state-reasons"
         attribute to 'none'.

         NOTE - While values cannot be added to the 'job-state' attribute
         without impacting deployed clients that take actions upon receiving

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         "job-state" values, it is the intent that additional "job-state-
         reasons" values can be defined printer.  An administrator
         determines a printer's URI and registered without impacting such
         deployed clients.  In other words, the "job-state-reasons" sets this attribute
         is intended to be extensible.

         The following standard values are defined:

           'none':  There are no reasons for the job's current state.
           'job-incoming':  The CreateJob operation has been accepted by the
              Printer, but the Printer is expecting additional SendDocument
              operations and/or is accessing/accepting document data.
           'job-outgoing':  The Printer is transmitting the job to the output
              device.
           'job-hold-until-specified-time':  The value of the job's "job-hold-
              until" attribute specifies a time period that is still in the
              future.  The job SHALL NOT URI.  This
         MUST be a candidate for processing until
              this reason is removed and there are no other reasons to hold an HTTP schemed URI, however the
              job.
           'job-hold-until-resources-are -ready':  At least one precise format of the
              resources needed by the job, such as media, fonts, resource
              objects, etc., a printer
         URI is not ready on any of implementation dependent.

         4.4.2 printer-name (name)

         This attribute contains the physical printer's for
              which name of the job printer. It is a candidate. name that is
         more user friendly than the printer-URI. An administrator determines a
         printer's name and sets this attribute to that name. This condition MAY name may be detected
              when the job is accepted, or subsequently while
         the job is
              pending or processing, depending on implementation.
           'printer-stopped-partly':  The value last part of the Printer's "printer-
              state-reasons" printer's URI or it may be unrelated. In non-US-
         English locales, a name may contain characters that are not allowed in
         a URI.

         4.4.3 printer-location (text)

         This attribute contains identifies the value 'stopped-partly'.
           'printer-stopped':  The value location of the Printer's "printer-state" this printer. This could
         include things like: _in Room 123A, second floor of building XYZ_.

         4.4.4 printer-info (text)

         This attribute is 'stopped'.
           'job-printing':  The output device is marking media. identifies the descriptive information about this
         Printer.  This value is
              useful could include things like: "This printer can be used
         for Printers which spend a great deal printing color transparencies for HR presentations", or "Out of time processing
              when no marking
         courtesy for others, please print only small (1-5 page) jobs at this
         printer", or even "This printer is happening and then want going away on July 1, 1997, please
         find a new printer".

         4.4.5 printer-more-info (uri)

         This attribute contains a URI used to obtain more information about
         this specific printer.  For example, this could be an HTTP type URI
         referencing an HTML page accessible to show that marking
              is now happening.
           'job-cancelled-by-user':  The job was cancelled by the user using
              the CancelJob request, i.e., by a user whose name Web Browser.  The information
         obtained from this URI is intended for end user consumption. Features
         outside the same as
              the value scope of the job's "job-originating-user" attribute.
           'job-cancelled-by-operator': IPP can be accessed from this URI.  The
         information is intended to be specific to this printer instance and

                                 Expires April 14, 1998
         site specific services (e.g. job was cancelled by the operator
              using pricing, services offered, end user
         assistance). The device manufacturer may initially populate this
         attribute.

         4.4.6 printer-driver-installer (uri)

         This attribute contains a URI to use to locate the CancelJob request, i.e., driver installer
         for this printer.   This attribute is intended for consumption by a user whose name
         automata. The mechanics of print driver installation is
              different than outside the value
         scope of the job's "job-originating-user"
              attribute.
           'job-completed-successfully':  The job completed successfully.
           'job-completed-with-warnings':  The job completed with warnings.
           'job-completed-with-errors': IPP.  The job completed with errors (and
              possibly warnings too).
           'job-interpreting': Job is in the 'processing' state, but more
              specifically, the Printer is interpreting device manufacturer may initially populate this
         attribute.

         4.4.7 printer-make-and-model (text)

         This attribute identifies the data.
           'job-printing': Job is in make and model of the 'processing' state, but printer.

         4.4.8 printer-more-info-manufacturer (uri)

         This attribute contains a URI used to obtain more
              specifically, the Printer information about
         this type of printer.  The information obtained from this URI is actually printing (making marks on
         intended for end user consumption.  Features outside the media).

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           'job-queued': Job scope of IPP
         can be accessed from this URI (e.g., latest firmware, upgrades, print
         drivers, optional features available).  The information is in the 'processing' state, but more
              specifically, intended to
         be germane to this printer without regard to site specific
         modifications or services. The device manufacturer may initially
         populate this attribute.

         4.4.9 printer-state (type1 enum)

         This attribute identifies the Printer is queuing current state of the data.
           'job-transforming': Job is in printer.  The
         "printer-state reasons" attribute augments the 'processing' state, but "printer-state"
         attribute to give more
              specifically, the Printer is transforming the data.

         ISSUE: Show a partitioning of which "job-state-reasons" are valid or
         expected for each "job-state" value.

         4.3.10 job-state-message (text)

         This attributes specifies supplemental detailed information about the Job State Printer in human readable text.

         4.3.11 output-device-assigned (name)

         This attribute identifies the Output Device
         given printer state.

         A Printer object need only update this attribute before responding to
         an operation which requests the attribute; the Printer has
         assigned object NEED NOT
         update this job.  If an output device implements an embedded IPP
         Printer, the attribute continually.  A Printer NEED NOT set implement all
         values if they are not applicable to a given implementation.

         The following standard values are defined:

           'unknown'(2):  The Printer state is not known, or is indeterminate.
              A Printer SHALL use this attribute. state only if it cannot determine its
              actual state.

           'idle'(3):  If a Print Server
         implements Printer receives a Printer, job (whose required resources
              are ready) while in this state, such a job SHALL transit into the value MAY
              processing state immediately.  If the printer-state-reasons

                                 Expires April 14, 1998
              attribute contains any reasons, they SHALL be empty until reasons that would
              not prevent a job from transiting into the processing state
              immediately, e.g., toner-low. Note: if a Printer assigns
         an controls more
              than one output device to the job.

         4.3.12 time-since-pending (integer)

         This attribute indicates device, the amount of time above definition implies that a
              Printer is idle if at least one output device is idle.

           'processing'(4):  If a Printer receives a job (whose required
              resources are ready) while in milliseconds that has
         passed since the Job was first put this state, such a job SHALL
              transit into the pending state..

         4.3.13 time-since-processing (integer)

         This attribute indicates the amount of time in milliseconds that has
         passed since the Job first entered state immediately. Such a job SHALL
              transit into the processing state.

         4.3.14 time-since-completed (integer)

         This attribute indicates the amount state only after jobs ahead of time in milliseconds that has
         passed since it
              complete.  If the Job was completed.

         4.3.15 number-of-intervening-jobs (integer(0:2**31 - 1))

         This printer-state-reasons attribute indicates the number of jobs contains any
              reasons, they SHALL be reasons that are "ahead" of this
         job in do not prevent the current scheduled order.  For efficiency, it is only
         necessary to calculate this value when an operation is performed that
         requests this attribute.
              job from printing, e.g. toner-low.  Note: This attribute is necessary since an end user may request just
         their own jobs and they need some relative position indicator if there
         are other jobs interspersed in the waiting list which are not returned

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         in the response or cannot be because of site security policy
         restrictions.

         4.3.16 job-message-from-operator (text)

         This attribute provides a message from an operator, system
         administrator or "intelligent" process to indicate to the end user Printer controls
              more than one output device, the
         reasons for modification or other management action taken on above definition implies that a job.

         4.3.17 job-k-octets-processed (integer(0:2**31 - 1))

         This attribute specifies the number of octets completed in K octets,
         i.e.,
              Printer is processing if at least one output device is
              processing, and none is idle.

           'stopped'(5):  If a Printer receives a job (whose required
              resources are ready) while in units of 1024 octets.  The value SHALL be rounded up, so that this state, such a job between 1 and 1024 octets SHALL be indicated as being 1, 1025 to
         2048
              transit into the pending state immediately. Such a job SHALL be 2, etc.

         Note: This attribute and
              transit into the following two attributes ("job-
         impressions-completed" processing state only after some human fixes the
              problem that stopped the printer and "job-sheets-completed") are intended after jobs ahead of it
              complete printing.  The "printer-state-reasons" attribute SHALL
              contain at least one reason, e.g. media-jam, which prevents it
              from either processing the current job or transiting a pending
              job to be
         counters (as described in the Job Monitoring MIB [27]). That is, processing state.

              Note: if a Printer controls more than one output device, the "job-state"
              above definition implies that a Printer is 'processing' or 'processing-stopped', this value stopped only if all
              output devices are stopped.  Also, it is
         intended tempting to contain the amount define
              stopped as when a sufficient number of output devices are stopped
              and leave it to an implementation to define the sufficient
              number.  But such a rule complicates the definition of stopped
              and processing. For example, with this alternate definition of
              stopped, a job that has been processed can move from idle to processing without human
              intervention, even though the time at which Printer is stopped.

         4.4.10 printer-state-reasons (1setOf type2 keyword)

         This attribute supplies additional detail about the attributes are requested.  For any printer's state.

         Each MAY have a suffix to indicate its level of these severity.  The three attributes,
         levels are: report (least severe), warning, and error (most severe).

           - '-report':  This suffix indicates that the Printer reason is a "report".
              An implementation may choose to return omit some or all reports. Some
              reports specify finer granularity about the value '-2'
         (which represents "unknown") rather than choose printer state; others

                                 Expires April 14, 1998
              serve as a precursor to not support a warning. A report SHALL contain nothing
              that could affect the
         attribute at all.

         4.3.18 job-impressions-completed  (integer(0:2**31 printed output.
           - 1)) '-warning': This job attribute specifies suffix indicates that the number of impressions completed. This
         attribute reason is intended to be a counter "warning".
              An implementation may choose to omit some or all warnings.
              Warnings serve as a precursor to an error. A warning SHALL
              contain nothing that prevents a job from completing, though in
              some cases the Job Monitoring MIB.

         4.3.19 job-media-sheets-completed (integer(0:2**31 output may be of lower quality.
           - 1)) '-error': This job attribute specifies suffix indicates that the media-sheets completed. This
         attribute reason is intended to an "error".
              An implementation SHALL include all errors. If this attribute
              contains one or more errors, printer SHALL be a counter as in the Job Monitoring MIB.

         4.4 Document Attributes

         This group of attributes applies to Document objects. stopped
              state.

         If there are
         multiple Documents in a Job, then there the implementation does not add any one of the three suffixes, all
         parties SHALL assume that the reason is an "error".

         If a different set Printer object controls more than one output device, each value
         of this attribute MAY apply to one or more of Document
         attributes associated with Document in the Job.

         When using output devices.  An
         error on one output device that does not stop the Get-Attributes or Get-Jobs operations, Printer object as a
         whole MAY appear as a warning in the group named
         "document-attributes" includes all Printer's "printer-state-reasons
         attribute".  If the "printer-state" for such a Printer has a value of
         'stopped', then there MUST be an error reason among the attributes values in this section,
         including the Document level Job Template attributes (attributes that
         have the same characteristics as Job Template attribute, yet apply to

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         Documents, not Jobs).  These
         "printer-state-reasons" attribute.

         The following standard values are identified defined:

           'other': The printer has detected an error other than one listed in
              this document.
           'unknown': The printer is unable to give additional detail about
              the second part state of the
         table in section 4.2.  Specifically they are:

           "document-format"
           "compression"
           "document-k-octets"
           "document-impressions"
           "document-media-sheets"

         Other Document attributes include:

         +-----------------+-------------+----------------+
         |    Document     |  Syntax     |   MANDATORY?   |
         |    Attribute    |             |                |
         +-----------------+-------------+----------------+
         | document-name   | name        |  NO            |
         +-----------------+-------------+----------------+
         | document-uri    | uri         |  NO            |
         +-----------------+-------------+----------------+

         4.4.1 document-name (name) printer.  This attribute contains the name state reason is semantically
              equivalent to printer-state-reasons without any value.
           'media-needed': A tray has run out of the document. media.
           'media-jam': The name is
         optionally supplied printer has a media jam.
           'paused': Someone has paused the Printer. In this state, a Printer
              SHALL not produce printed output, but it SHALL perform other
              operations requested by a client. If a Printer had been printing
              a job when the client in Printer was paused, the "document-name" operation
         attribute Printer SHALL resume
              printing that job when the Printer is no longer paused and leave
              no evidence in the create request.  If it printed output of such a pause.
           'shutdown': Someone has removed a Printer from service, and it may
              be powered down or physical removed. In this state, a Printer
              SHALL not produce printed output, and unless the Printer is not supplied
              realized by the client
         in the create request, a print server that is still active, the Printer MAY generate
              SHALL perform no other operations requested by a Document name.  The
         "document-name" attribute contains the name whether supplied or
         generated.

         4.4.2 document-uri (uri) client,
              including returning this value. If a "pull" operations is used to create the Document object (such as
         the Print-URI or Send-URI operations which include only Printer had been printing a URI
         reference to
              job when it was shutdown, the document data, Printer need not resume printing
              that job when the document data itself), then
         this "document-uri" attribute contains the URI reference.  This
         attribute Printer is populated from the "document-uri" operation attribute
         supplied by no longer shutdown. If the client Printer
              resumes printing such a job, it may leave evidence in the Print-URI or Send-URI operation.

         If printed

                                 Expires April 14, 1998
              output of such a "push" operation is used to create the Document object (such as shutdown, e.g. the Print-Job or Send-Document operations which include part printed before the document
         data rather than just
              shutdown may be printed a reference to the data) then this "document-
         uri" attribute is not associated with second time after the Document object.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         4.5 Printer Description Attributes

         These attributes form shutdown.
           'connecting-to-device': The server has scheduled a job on the attribute group called "printer-
         description".  A
              Printer object may be realized and is in either the process of connecting to a print
         server or shared network
              output device.  Note: How these attributes are set by device (and might not be able to actually start printing
              the job for an
         Administrator is outside arbitrarily long time depending on the scope usage of this specification.
              the output device by other servers on the network).
           'timed-out': The
         following table summarizes these attributes, their syntax, and whether
         or not they are MANDATORY.  If they are not MANDATORY, they are
         OPTIONAL.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         +----------------------------+----------------------+----------------+
         |      Attribute             |     Syntax           |   MANDATORY?   |
         +----------------------------+----------------------+----------------+
         | printer-uri                | uri                  |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | printer-name               | name                 |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | printer-location           | text                 |                |
         +----------------------------+----------------------+----------------+
         | printer-description        | text                 |                |
         +----------------------------+----------------------+----------------+
         | printer-more-info          | uri                  |                |
         +----------------------------+----------------------+----------------+
         | printer-driver-installer   | uri                  |                |
         +----------------------------+----------------------+----------------+
         | printer-make-and-model     | text                 |                |
         +----------------------------+----------------------+----------------+
         | printer-more-info-         | uri                  |                |
         | manufacturer               |                      |                |
         +----------------------------+----------------------+----------------+
         | printer-state              | type1 enum           |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | printer-state-reasons      | 1setOf type2 keyword |                |
         +----------------------------+----------------------+----------------+
         | printer-state-message      | text                 |                |
         +----------------------------+----------------------+----------------+
         | operations-supported       | 1setOf type2 enum    |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | printer-is-accepting-jobs  | boolean              |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | queued-job-count           | integer              |                |
         +----------------------------+----------------------+----------------+
         | printer-message-from-      | text                 |                |
         | operator                   |                      |                |
         +----------------------------+----------------------+----------------+
         | printer-language           | human-language       |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | printer-language-supported | 1setOf human-language|  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | color-supported            | boolean              |                |
         +----------------------------+----------------------+----------------+
         | pdl-override               | type2 keyword        |                |
         +----------------------------+----------------------+----------------+
         | message-protection-        | keyword              |                |
         | supported                  |                      |                |
         +----------------------------+----------------------+----------------+
         | authentication-author      | keyword              |                |
         | ization-supported          |                      |                |

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         +----------------------------+----------------------+----------------+
         | printer-up-time            | seconds              |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | printer-current-time       | dateTime             |                |
         +----------------------------+----------------------+----------------+

         4.5.1 printer-uri (uri)

         This attribute contains server was able to connect to the URI for output device
              (or is always connected), but was unable to get a response from
              the printer.  An administrator
         determines output device.
           'stopping': The printer will be stopping in a printer's URI while and sets this attribute will change
              its reason to that URI. The
         precise format of a printer URI is implementation dependent.

         4.5.2 printer-name (name) printer-stopped. This attribute contains reason is a non-critical,
              even for a Printer with a single output device. When an output-
              device ceases accepting jobs, the name of Printer will have this reason
              while the printer. It is output device completes printing.
           'stopped-partly': When a name that is Printer controls more user friendly than the printer-URI. An administrator determines a
         printer's name and sets one output
              device, this attribute to reason indicates that name. This name may be one or more output devices are
              stopped. If the last part reason is a report, fewer than half of the printer's URI or it may be unrelated. In non-US-
         English locales, a name may contain characters that output
              devices are not allowed in
         a URI.

         4.5.3 printer-location (text)

         This attribute identifies stopped. If the location of this printer. This could
         include things like: _in Room 123A, second floor reason is a warning, fewer than all
              of building XYZ_.

         4.5.4 printer-description (text)

         This attribute identifies the descriptive information about this
         Printer.  This could include things like: "This printer can be used
         for printing color transparencies for HR presentations", or "Out of
         courtesy for others, please print only small (1-5 page) jobs at this
         printer", output devices are stopped.
           'toner-low': The Printer is low on toner.
           'marker-supply-low': The Printer is low on marker supply (ink,
              paint, etc.).
           'spool-area-full': The limit of persistent storage allocated for
              spooling has been reached.
           'cover-open': One or even "This more covers on the printer is going away open.
           'interlock-open': One or more interlock devices on July 1, 1997, please
         find a new printer".

         4.5.5 printer-more-info (uri)

         This attribute contains a URI used to obtain the printer is
              unlocked.
           'door-open': One or more information about
         this specific doors on the printer are open.
           'input-tray-missing': One or more input trays are not in the
              printer.  For example, this could be an HTTP type URI
         referencing an HTML page accessible to a Web Browser.  The information
         obtained from this URI
           'media-low': At least one input tray is intended for end user consumption. Features
         outside low on media.
           'media-empty': At least one input tray is empty.
           'output-tray-missing': One or more output trays are not in the scope of IPP can be accessed from this URI.
              printer
           'output-area-almost-full': One or more output area is almost full
              (e.g. tray, stacker, collator).
           'output-area-full': One or more output area is full. (e.g. tray,
              stacker, collator)
           'marker-supply-low': The
         information Printer is intended to be specific to this printer instance and
         site specific services low on at least one marker
              supply. (e.g. job pricing, services offered, end user
         assistance).

         deBry, Hastings, Herriot, Isaacson, Powell toner, ink, ribbon)
           'marker-supply-empty: The Printer is out of at least one marker
              supply. (e.g. toner, ink, ribbon)
           'marker-waste-almost-full': The Printer marker supply waste
              receptacle is almost full.
           'marker-waste-full': The Printer marker supply waste receptacle is
              full.
           'fuser-over-temp': The fuser temperature is above normal.

                                 Expires February xx, April 14, 1998
         4.5.6 printer-driver-installer (uri)

         This attribute contains a URI to use to locate the driver installer
         for this printer.   This attribute
           'fuser-under-temp': The fuser temperature is intended for consumption by
         automata. below normal.
           'opc-near-eol': The mechanics of print driver installation optical photo conductor is outside the
         scope near end of IPP. life.
           'opc-life-over': The printer manufacturer may initially populate this
         attribute.

         4.5.7 printer-make-and-model optical photo conductor is no longer
              functioning.
           'developer-low': The Printer is low on developer.
           'developer-empty: The Printer is out of developer.
           'interpreter-resource-unavailable': An interpreter resource is
              unavailable (i.e. font, form)

         4.4.11 printer-state-message (text)

         This attribute identifies specifies the make additional information about the printer
         state and model printer state reasons in human readable text.  The Printer
         object SHALL be able to generate this message in any of the printer.

         4.5.8 printer-more-info-manufacturer (uri) natural
         languages identified by the Printer's "natural-language-supported"
         attribute (see the "attributes-natural-language" operation attribute
         specified in Section 3.1.3.1).

         4.4.12 operations-supported (1setOf operation)

         This attribute contains a URI used to obtain more information about specifies the set of supported operations for this
         Printer.  The syntax of type of printer.  The information obtained from this URI "operation" is
         intended for end user consumption.  Features outside the scope same as "type2
         enum" except that the range of IPP
         can be accessed from this URI (e.g., latest firmware, upgrades, print
         drivers, optional features available).  The information values is intended 0x0000 to
         be germane 0x8FFF.

         The following standard values are defined:

           0x0000  reserved, not used
           0x0001  reserved, not used
           0x0002  Print-Job
           0x0003  Print-URI
           0x0004  Validate-Job
           0x0005  Create-Job
           0x0006  Send-Document
           0x0007  Send-URI
           0x0008  Cancel-Job
           0x000A  Get-Jobs
           0x0009  Get-Attributes
           0x000A-0x3FFF          reserved for future operations
           0x4000-0x8FFF          reserved for private extensions

         This allows for certain vendors to this printer without regard implement private extensions that
         are guaranteed to site specific
         modifications not conflict with future registered extensions.
         However, there is no guarantee that two or services.

         4.5.9 printer-state (type1 enum) more private extensions
         will not conflict.

                                 Expires April 14, 1998
         4.4.13 printer-charset (charSet)

         This MANDATORY attribute identifies the current state of the printer.  The
         "printer-state reasons" attribute augments the "printer-state"
         attribute to give more detailed information about charset that the Printer in the
         given printer state.

         A
         object has been configured to represent 'text' and 'name' Printer SHALL keep this attribute
         attributes that are set in a timely manner to by the operator, system administrator, or
         manufacturer, i.e., for "printer-name" (name), "printer-location"
         (text), "printer-info" (text), and "printer-make-and-model" (text).
         Therefore, the value in of the table below which most accurately reflects "printer-charset" attribute SHALL also be
         among the state values of the Printer. If Printer's "charset-supported" attribute.

         4.4.14 charsets-supported (1setOf charSet)

         This MANDATORY attribute identifies the printer has jobs that are requesting notification set of printer-problems or job-problems, then _timely manner_ means
         continually..  Otherwise, _timely manner_ means whether charsets that the
         Printer
         receives a query for this attribute. A Printer NEED NOT implement all
         values if they are not applicable to a given implementation.

         The following standard values are defined:

           'unknown'(2):  The Printer state is not known, or is indeterminate.
              A object supports in attributes with attribute syntax 'text' and
         'name', i.e., that the Printer object SHALL use this state only if it cannot determine its
              actual state.

           'idle'(3):  If a Printer receives a job (whose required resources
              are ready) while (1) accept in this state, such a job SHALL transit into the
              processing state immediately.  If requests,
         (2) return in responses, and (3) send in notification messages.  At
         least the printer-state-reasons
              attribute contains any reasons, they value 'utf-8' SHALL be reasons that would
              not prevent a job from transiting into the processing state

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              immediately, e.g., toner-low. Note: if present, since a Printer controls object SHALL
         support the UTF-8 [RFC2044] charset.

         If more charsets than one output device, UTF-8 are supported, the above definition implies Printer object SHALL
         perform charset conversion between the charsets as described in
         Section 3.1.3.1.

         4.4.15 printer-natural-language (naturalLanguage)

         This MANDATORY attribute identifies the natural language that a the
         Printer is idle if at least one output device is idle.

           'processing'(4):  If a object has been configured to represent 'text' and 'name'
         Printer receives a job (whose required
              resources attributes that are ready) while set by the operator, system administrator,
         or manufacturer, i.e., for "printer-name" (name), "printer-location"
         (text), "printer-info" (text), and "printer-make-and-model" (text).
         When returning these Printer attributes, the Printer object MAY return
         them in the configured natural language specified by this state, such a job SHALL
              transit into attribute,
         instead of the pending state immediately. Such a job SHALL
              transit into natural language requested by the processing state only after jobs ahead client in the
         "attributes-natural-language" operation attribute.  See Section
         3.1.3.1 for the specification of it
              complete.  If the printer-state-reasons OPTIONAL multiple natural
         language support.  Therefore, the value of the "printer-natural-
         language" attribute contains any
              reasons, they SHALL also be reasons that do not prevent among the current
              job from printing, e.g. toner-low.  Note: if a Printer controls
              more than one output device, values of the above definition implies Printer's
         "natural-language-supported" attribute.

         4.4.16 natural-languages-supported (1setOf naturalLanguage)

         This MANDATORY attribute identifies the natural language(s) that a the
         Printer is processing if at least one output device is
              processing, object supports in attributes with attribute syntax 'text' and none is idle.

           'stopped'(5):  If a
         'name', i.e., that the Printer receives a job (whose required
              resources are ready) while in this state, such a job object SHALL
              transit into (1) accept in requests,
         (2) return in responses, and (3) send in notification messages.  The
         natural language(s) supported depends on implementation and/or
         configuration.

                                 Expires April 14, 1998
         For any of the pending state immediately. Such a job SHALL
              transit into attributes for which the processing state only after some human fixes Printer generates messages,
         i.e., for the
              problem that stopped "job-state-message" and "printer-state-message"
         attributes and Operation Messages (see Section 3.1.4) in operation
         responses, the printer Printer object SHALL be able to generate messages in
         any of its supported natural languages.  See section 3.1.3.1 for the
         specification of 'text' and after jobs ahead 'name' attributes in operation requests
         and responses.

         Note: A Printer object that supports multiple natural languages, often
         has separate catalogs of it
              complete printing.  The "printer-state-reasons" attribute SHALL
              contain at least messages, one reason, e.g. media-jam, which prevents it
              from either processing for each natural language
         supported.

         4.4.17 printer-is-accepting-jobs (boolean)

         This attribute indicates whether the current job or transiting a pending
              job to printer is currently accepting
         job.  If the processing state.

              Note: if a Printer controls more than one output device, value is true, the
              above definition implies that a Printer printer is stopped only if all
              output devices are stopped.  Also, it accepting jobs. If the
         value is tempting false, the printer is currently rejecting any jobs submitted
         to define
              stopped as when a sufficient number it.

         Note: This value is independent of output devices are stopped the printer state and leave printer-
         state-reasons because its value does not affect the current job;
         rather it to an implementation to define affects future jobs. This attribute may cause the sufficient
              number.  But such a rule complicates Printer to
         reject jobs when the definition of stopped
              and processing. For example, with this alternate definition of
              stopped, a job can move from printer-state is idle to processing without human
              intervention, even though or it may cause the Printer
         to accepts jobs when the printer-state is stopped.

         4.5.10 printer-state-reasons (1setOf type2 keyword)

         4.4.18 queued-job-count (integer(0:2**31 - 1))

         This attribute supplies additional detail about contains a count of the printer's state.

         Each MAY have asuffix to indicate its level number of severity.  The three
         levels are: report (least severe), warning, and error (most severe).

           - '-report':  This suffix indicates jobs that the reason are either
         'pending', 'processing', 'pending-held', or 'processing-stopped' and
         is set by the Printer.

         4.4.19 printer-message-from-operator (text)

         This attribute provides a "report".
              An implementation may choose to omit some message from an operator, system
         administrator or all reports. Some
              reports specify finer granularity about "intelligent" process to indicate to the printer state; others
              serve end user
         information or status of the printer, such as a precursor why it is unavailable or
         when it is expected to a warning. A report SHALL contain nothing
              that could affect be available.

         4.4.20 color-supported (boolean)

         This attribute identifies whether the printed output.

         deBry, Hastings, Herriot, Isaacson, Powell Printer is capable of any type
         of color printing at all.  All document instructions having to do with
         color are embedded within the document PDL (none are external IPP
         attributes).

                                 Expires February xx, April 14, 1998
           - '-warning':
         4.4.21 reference-uri-schemes-supported (1setOf uriScheme)

         This suffix indicates that attribute specifies which URI schemes are supported for use in
         the reason is a "warning".
              An implementation may choose to omit some "document-uri" operation attribute of the Print-URI or all warnings.
              Warnings serve as Send-URI
         operation.  If a precursor to Printer object supports these optional operations, it
         MUST support URIs of the following type:

           'http':  The Printer object will perform an error. A warning SHALL
              contain nothing that prevents HTTP/1.1 GET operation
           'ftp':  The Printer object will use an FTP 'get' operation.  If the
              URI does not indicate a job from completing, though name or password in the URI itself, the
              Printer object will use anonymous FTP generating (if prompted)
              some cases password in the output may be form of lower quality.
           - '-error': This suffix indicates that the reason is an "error". .
              An implementation SHALL include all errors. If this Internet mail address.

         The Printer object OPTIONALLY supports other URI schemes (see section
         4.1.6).

         4.4.22 pdl-override (type2 keyword)

         This attribute
              contains one or more errors, printer SHALL be in the stopped
              state.

         If expresses the ability for a particular Printer
         implementation does not add any one of to either attempt to override document data
         instructions with IPP attributes or not.

         This MANDATORY attribute takes on the three suffixes, all
         parties SHALL assume following values:

           - 'attempted': This value indicates that the reason is an "error".

         If a logical Printer controls more than one output device, each value
         of this attribute MAY apply attempts to one or more of
              make sure that IPP attribute values take precedence over embedded
              instructions in the output devices.  An
         error on one output device document data, however there is no guarantee.
           - 'not-attempted': This value indicates that does not stop the logical Printer as a
         whole MAY appear as a warning makes no
              attempt to ensure that IPP attribute values take precedence over
              embedded instructions in the Printer's "printer-state-reasons
         attribute".  The "printer-state" for such a Printer may have print data.

         Section 15 contains a value full description of 'stopped' even though there are how this attribute interacts
         with no "printer-state-reasons"
         values that are "errors".

         The following standard and affects other IPP attributes, especially the "ipp-attribute-
         fidelity" attribute.

         4.4.23 security-mechanisms-supported (1setOf keyword)

         This attribute indicates the security mechanisms supported.  Standard
         values are defined:

           'media-needed': A tray has run out of media.
           'media-jam': The printer has are:

           'tls': Transport Layer Security (TLS)
           'ssl': Secure Sockets Layer (SSL)
           'http-digest': HTTP/1.1 Digest Authentication
           'http-basic': HTTP/1.1 Basic Authentication

                                 Expires April 14, 1998
         4.4.24 printer-up-time (integer(1:MAX))

         This attribute is a media jam.
           'paused': Someone has paused MANDATORY attribute.  It indicates the Printer. In amount of
         time (in seconds) that this instance of this state, a Printer
              SHALL not produce printed output, but it SHALL perform other
              operations requested by a client. If a Printer had implementation
         has been printing up and running.  This value is used to populate the Job
         attributes "time-of-creation", "time-at-processing", and "time-at-
         completed".  These time values are all measured in seconds and all
         have meaning only relative to this attribute, "printer-up-time".  The
         value is a job monotonically increasing value starting from 1 when the
         Printer was paused, the Printer SHALL resume
              printing that job when object is started-up (initialized, booted, etc.).

         If the Printer is no longer paused object goes down at some value 'n', and leave
              no evidence in comes back up,
         the printed output of such a pause.
           'shutdown': Someone implementation MAY:

           1. Know how long it has removed a Printer from service, been down, and it may
              be powered down resume at some value greater
              than 'n', or physical removed.
           2. Restart from 1.

         In this state, a the first case, the Printer
              SHALL SHOULD not produce printed output, tweak any existing related
         Job attributes ("time-of-creation", "time-at-processing", and unless "time-
         at-completed").  In the second case, the Printer is
              realized by object SHOULD be
         reset to 0.  If a print server client queries a time-related Job attribute and
         finds the value to be 0, the client MUST assume that the Job was
         submitted in some life other than the Printer's current life.

         4.4.25 printer-current-time (dateTime)

         This attribute is still active, an OPTIONAL attribute.  It indicates the current
         absolute wall-clock time.  If an implementation supports this
         attribute, then a client could calculate the absolute wall-clock time
         each Job's "time-of-creation", "time-at-processing", and "time-at-
         completed" attributes by using both "printer-up-time" and this
         attribute, "printer-current-time".  If an implementation does not
         support this attribute, a client can only calculate the relative time
         of certain events based on the MANDATORY "printer-up-time" attribute.

         4.4.26 multiple-operation-time-out (integer)

         This attributes identifies how long (in seconds) the Printer object
         waits for additional Send-Document or Send-URI operations to follow a
         still-open multi-document Job object.

         5. Conformance

         This section describes conformance issues and requirements. This
         document introduces model entities such as objects, operations,

                                 Expires April 14, 1998
         attributes, and attribute values.  These conformance sections describe
         the conformance requirements which apply to these model entities.

         5.1 Client Conformance Requirements

         A conforming client SHALL perform no other send operations requested by a client,
              including returning this value. If a Printer had been printing a
              job when it was shutdown, the Printer need not resume printing that job when the Printer is no longer shutdown. If conform to the Printer
              resumes printing such a job, it may leave evidence protocol
         defined in the printed
              output of such _Internet Printing Protocol/1.0: Protocol Specification_
         [IPP-PRO]. For each attribute included in an operation request, a shutdown, e.g. the part printed before the
              shutdown may be printed
         conforming client SHALL send a second time after value whose type and value syntax
         conforms to the shutdown.
           'connecting-to-device': The server has scheduled a job requirement of this document

         Otherwise, there are 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 and is object in the process of connecting order to supply a shared network
              output device (and graphical user
         interface (GUI) dialogue box with supported and default values whereas
         a different implementation might not.  For presentation purposes,
         truncation of long attribute values is not recommended.  A recommended
         approach would be able to actually start printing
              the job for an arbitrarily long time depending on the usage of the output device by other servers on client implementation to allow the network).

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           'timed-out': The server was able user to connect
         scroll through long attribute values.

         When sending a Get-Attributes or create request, an IPP client NEED
         NOT supply any OPTIONAL attributes.

         A client SHALL be able to accept any of the output device
              (or is always connected), but was unable attribute syntaxes defined
         in Section 4.1, including their full range, that may be returned to get it
         in a response from a Printer object.

         A query response may contain attributes and values that the output device.
           'stopping': The printer will be stopping in client
         does not expect.  Therefore, a while client implementation MUST gracefully
         handle such responses and will change
              its reason not refuse to printer-stopped. This reason is a non-critical,
              even for a Printer inter-operate with a single output device. When an output-
              device ceases accepting jobs, the Printer will have this state
              while the output device completes printing.
           'stopped-partly': When a
         conforming Printer controls more than one output
              device, this reason indicates that one or more output devices are
              stopped. If the reason is a report, fewer than half of the output
              devices are stopped. If the reason is a warning, fewer than all
              of the output devices are stopped.
           'toner-low': The Printer is low on toner.
           'marker-supply-low': The Printer is low on marker supply.
           'spool-area-full': The limit of persistent storage allocated for
              spooling has been reached.

         ISSUE: Show a partitioning of which "printer-state-reasons" are valid returning extended registered or expected for each "printer-state" value.

         4.5.11 printer-state-message (text)

         This private
         attributes and/or attribute values that conform to Section 6.  Clients
         may choose to ignore any parameters, attributes, or values that it
         does not understand.

         5.2 Printer Object Conformance Requirements

         This section specifies the additional information about the printer
         state conformance requirements for conforming
         Printer object implementations with respect to objects, operations,
         and printer state reasons attributes.

                                 Expires April 14, 1998
         5.2.1 Objects

         Conforming Printer implementations SHALL implement all of the model
         objects as defined in this specification in human readable text.

         4.5.12 operations-supported (1setOf type2 enum)

         This attribute specifies the set indicated sections:

           Section 2.1 Printer Object
           Section 2.2 Job Object

         5.2.2 Operations

         Conforming Printer implementations SHALL implement all of supported operations for the
         MANDATORY model operations, including mandatory responses, as defined
         in this
         Printer.

         The following standard values are defined:

           0x00    reserved, not used
           0x01 specification in the indicated sections:

           For a Printer object:
              Print-Job
           0x02 (section 3.2.1)                    MANDATORY
              Print-URI
           0x03 (section 3.2.2)                    OPTIONAL
              Validate-Job
           0x04 (section 3.2.3)            MANDATORY
              Create-Job
           0x05    Get-Jobs
           0x06 (section 3.2.4)              OPTIONAL
              Get-Attributes
           0x07 (section 3.2.5)               MANDATORY
              Get-Jobs (section 3.2.6)                MANDATORY

           For a Job object:
              Send-Document
           0x08 (section 3.3.1)           OPTIONAL
              Send-URI
           0x09 (section 3.3.2)                OPTIONAL
              Cancel-Job
           0x0A-0x3FFF       reserved for future operations

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           0x4000-0xFFFF          reserved for private extensions

         In order (section 3.3.3)                   MANDATORY
              Get-Attributes (section 3.3.4)                    MANDATORY

         Conforming Printer implementations SHALL support all operation
         attributes and all values of such attributes, except for IPP to be extensible, this set attributes
         that are collections of operations is defined
         to be a 1setOf  type2 enum (see attributes. The following section 6.1 on
         attributes specifies the support required for a description attributes.

         5.2.3 Attributes

         Conforming Printer implementations SHALL support all of typed
         extensions).  Since the base type is enum, MANDATORY
         attributes, as defined in this specification in the possible full range of
         values is 0x0000-0xFFFF, however indicated
         sections.

         If a special range Printer supports an attribute, it SHALL support only those values
         specified in this document or through the extension mechanism
         described in the next section. It MAY support any non-empty subset of 0x4000-0xFFFF has
         been reserved for private extensions.  This allows for certain vendors
         to implement private
         these values. That is, it SHALL support at least one of the specified
         values and at most all of them.

                                 Expires April 14, 1998
         5.2.4 Printer extensions that are guaranteed to not conflict
         with future

         A conforming Printer may support registered extensions.  However, there is no guarantee
         that two or more private extensions will not conflict.

         4.5.13 printer-is-accepting-jobs (boolean)

         This attribute determines whether the printer is currently accepting
         job.  If and private
         extensions, as long as they meet the value is true, requirements specified in Section
         6.

         A conforming Printer SHALL send responses that conform to the protocol
         defined in _Internet Printing Protocol/1.0: Protocol Specification_
         [IPP-PRO]. For each attribute included in an operation response, a
         conforming printer is accepting jobs. If the SHALL send a value is false, whose type and value syntax
         conforms to the printer is currently rejecting any jobs submitted requirement of this document

         5.2.5 Attribute Syntaxes

         A Printer SHALL be able to it.

         Note: This value is independent accept any of the printer state and printer-
         state-reasons because its value does not affect the current job;
         rather it affects future jobs. This attribute syntaxes
         defined in Section 4.1, including their full range, in any operation
         in which a client may cause the supply attributes.  Furthermore, a Printer SHALL
         return attributes to
         reject jobs when the printer-state is idle or client in operation responses that conform to
         the syntax specified in Section 4.1, including their full range if
         supplied previously by a client.

         5.3 Security Conformance Requirements

         All clients and IPP objects SHALL support the two authentication
         mechanisms for HTTP/1.1 as defined in RFC 2068 [RFC2068] and RFC 2069
         [RFC2069].

         Clients and IPP objects that need mutual authentication and/or
         encryption SHOULD also support a secure connection protocol. For this
         purpose it may cause is the Printer intention to accepts jobs when the printer-state is stopped.

         4.5.14 queued-job-count (integer(0:2**31 - 1))

         This attribute contains a count define standardization of IPP in
         combination with Transport Layer Security (TLS), when the number of jobs that TLS
         specifications are either
         pending and/or processing agreed and is set by on the Printer.

         4.5.15 printer-message-from-operator (text)

         This attribute provides IETF standards track.

         For a message from an operator, system
         administrator or "intelligent" process to indicate to detailed discussion of security considerations, see section 8.

         6. IANA Considerations (registered and private extensions)

         During the end user
         information or status development of this standard, the printer, such as why it is unavailable or
         when it IPP working group
         (working with IANA) will register additional keywords and enums while
         the standard is expected to be available.

         4.5.16 printer-human-language (human-language)

         This attribute specifies in the current human-language that proposed and draft states according to the Printer
         procedures described in this section.  IANA will handle registration
         of additional enums after this standard is operating in.

         4.5.17 printer-human-language-supported (1setOf human-language)

         This attribute specifies approved in cooperation
         with an IANA-appointed registration editor from the supported human languages that IPP working group
         according to the
         Printer operates in.

         deBry, Hastings, Herriot, Isaacson, Powell procedures described in this section.

                                 Expires February xx, April 14, 1998
         4.5.18 color-supported (boolean)
         6.1 Typed Extensions

         This attribute identifies whether document uses prefixes to the Printer is capable of any "keyword" and "enum" basic syntax
         type
         of color printing 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
         list below describes the prefixes and their meaning.

           "type1":  The IPP standard must be revised to add a new keyword or
              a new enum.  No private keywords or enums are allowed.

           "type2":  Implementers can, at all.  All document instructions having any time, add new keyword or enum
              values by proposing the specification to do with
         color are embedded within the document PDL (none are external IPP
         attributes).

         4.5.19 pdl-override (type2 keyword)

         This attribute expresses working group
              for registration (or an IANA-appointed registry advisor after the ability
              IPP working group is no longer certified) where they are reviewed
              for a particular Printer
         implementation to either attempt approval.  IANA keeps the registry and assigned the number
              for enum values

           "type3":  Implementers can, at any time, add new keyword and enum
              values by submitting the complete specification directly to override print data instructions
         with IANA,
              no IPP attributes working group or not.

         This attribute takes on IANA-appointed registry advisor review is
              required. IANA keeps the following values:

           - 'attempted': This value indicates that registry and assigned the Printer attempts to
              make sure that IPP attribute number for
              enum values take precedence over embedded
              instructions in the Print data, however there is no guarantee.
           - 'not-attempted': This value indicates that

           "type4":  Anyone (system administrators, system integrators, site
              managers, etc.) can, at any time, add new installation-defined
              values (keywords or new enum values) to a local system. Care
              SHOULD be taken by the Printer makes not
              attempt implementers to ensure see that IPP attribute values take precedence over
              embedded instructions in keywords do not
              conflict with other keywords defined by the print data.

         This standard or as
              defined by the implementing product. There is a MANDATORY attribute.

         Appendix E: Processing IPP Attributes (see Section 15) contains a full
         description no registration or
              approval procedure for type 4 keywords.

         By definition, each of how this attribute interacts with and affects other IPP
         attributes, especially the "ipp-attribute-fidelity" attribute.

         4.5.20 Security Related Attributes

         The security document [22] describes four common usage scenarios:

           - no security
           - message protection
           - client authentication and authorization
           - mutual authentication, authorization, and message protection

         In types above assert some sort of
         registry or review process in order for extensions to let an end user know what be considered
         valid.  Each higher level (1, 2, 3, 4) tends to expect be decreasingly less
         stringent than the previous level.   Therefore, any typeN value MAY be
         registered using a process for some typeM where M is less than N,
         however such registration is NOT REQUIRED.  For example, a type4 value
         MAY be registered in terms a type 1 manner (by being included in a future
         version of security,
         there are two attributes described below.  Since by definition an end
         user, because of security reasons, might not be allowed to query these
         two attributes, therefore, IPP specification) however it is important NOT REQUIRED.

         This specification defines keyword and enum values for all of the
         above types, including type4 keywords.

         For private (unregistered) keyword extensions, implementers SHOULD use
         keywords with a suitable distinguishing prefix, such as "xxx-" where
         xxx is the (lowercase) fully qualified company name registered with
         IANA for use in domain names [RFC1035].

                                 Expires April 14, 1998
         Note: RFC 1035 [RFC1035] indicates that if these two
         attributes are supported, then they while upper and lower case
         letters are also populated allowed in domain names, no significance is attached to
         the
         directory entry (see [24]).

         These attributes allow for minimal client/server negotiation regarding
         security features.  If the Printer requires the feature, case.  That is, two names with the client
         can decide whether or not same spelling but different
         case are to participate.  If be treated as if identical.  Also, the client does not

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         support labels in a domain
         name must follow the feature, rules for ARPANET host names:  They must start
         with a letter, end with a letter or digit, and have as interior
         characters only letters, digits, and hyphen.  Labels must be 63
         characters or less.  Labels are separated by the Printer requires it, then the client
         knows before hand that such an interaction would fail.

         Standard "." character.

         For private (unregistered) enum extension, implementers SHOULD use
         values for these two attributes include:

           'supported' -  means that in the Printer reserved integer range which is capable 2**30 to 2**31-1.

         6.2 Registration of supporting the
              security feature (somehow), but it MIME types/sub-types for document-formats

         The "document-format" attribute's syntax is does not require the client
              to use it.
           'required' - "mimeType".  This means
         that valid values are Internet media types.  RFC 2045 [RFC2045]
         defines the Printer syntax for valid Internet media types.  Also, IANA is capable of supporting the
              security feature (somehow) and the client is required
         registry for all Internet media types.

         6.3 Attribute Extensibility

         Attribute names are considered to use it.
           'none' - means that the Printer is not capable be set of supporting
              message protection at all.

         Note:  This is a single-valued attribute, not a multi-valued
         attribute, i.e., an implementation can not support 'none' type2 keywords.
         Therefore, new attributes may be registered and
         'required' or any other combination of values.

         4.5.20.1 message-protection-supported (keyword)

         This attribute is used have the same status
         as attributes in this document by following the type2 extension rules.

         6.4 Attribute Syntax Extensibility

         Attribute syntaxes are considered to determine whether or not a printer supports
         or requires message protection (whether it be through encryption or
         some other privacy mechanism).

         4.5.20.2 authentication-authorization-supported (keyword)

         This set of type2 enums.
         Therefore, new attribute is used to determine whether or not a printer supports
         or requires authentication syntaxes may be registered and authorization.

         4.5.21 printer-up-time (seconds)

         This attribute is a MANDATORY attribute.  It indicates have the amount of
         time (in seconds) that same
         status as attribute syntaxes in this instance document by following the type2
         extension rules.

         7. Internationalization Considerations

         Some of this Printer implementation
         has been up and running.  This value is used to populate the Job attributes "time-at-pending", "time-at-processing", and "time-at-
         completed".  These time have values that are all measured in seconds text strings and all
         have meaning only relative to this attribute, "printer-up-time".

         ISSUE: Does this need to be MANDATORY?

         4.5.22 printer-current-time (dateTime)

         This attribute is an OPTIONAL attribute.  It indicates names
         intended for human understanding rather than machine understanding.
         See the current
         absolute wall-clock time.  If an implementation supports this
         attribute, 'text' and 'name' attribute syntaxes in Sections 4.1.1 and
         4.1.2.

         In each operation request, the a client could calculate SHALL identify the absolute wall-clock time charset and
         natural language of the request which affects each Job's "time-at-pending", "time-at-processing", supplied 'text' and "time-at-

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         completed" attributes by using both "printer-up-time"
         'name' attribute value and this
         attribute, "printer-current-time".  If an implementation does not
         support this attribute, a client can only calculate requests the relative time
         of certain events based on charset and natural language
         for attributes returned by the MANDATORY "printer-up-time" attribute.

         5. Conformance

         This section describes conformance issues Printer object in operation responses
         and requirements. This
         document introduces model entities such as objects, operations,
         attributes, notifications as described in Section 3.1.3.1. In addition, the

                                 Expires April 14, 1998
         client MAY separately and individually identify the "exception"
         natural language of a supplied 'text' or 'name' attribute values.  These conformance sections describe using the conformance requirements which apply
         technique described for the 'text' attribute syntax in Section 4.1.1.

         The Printer object SHALL support the UTF-8 [RFC2044] charset in all
         'text' and 'name' attributes supported.  If the Printer object
         supports more than the UTF-8 charset, the Printer object SHALL convert
         between them in order to these model entities.

         5.1 Client Conformance Requirements

         A conforming return the requested charset to the client SHALL send operations that conform
         according to Section 3.1.3.2.  If the protocol
         defined Printer object supports more
         than one natural language, the Printer object SHOULD return 'text' and
         'name' values in _Internet Printing Protocol/1.0: Protocol Specification_
         [23]. the natural language requested for those that are
         generated by the Printer (see Section 3.1.3.1).

         For each parameter or attribute included Printers that support multiple charsets and/or multiple natural
         languages in an operation
         request, a conforming client 'text' and 'name' attributes, different jobs may have
         been submitted in differing charsets and/or natural languages.  All
         responses SHALL send be returned in the charset requested by the client.
         However, the Get-Jobs operation provides for a value whose type and value
         syntax conforms mechanism to identify
         the requirement of this document

         Otherwise, there are no conformance requirements placed on differing natural languages with each job returned.

         The Printer object also has a configured charset and natural language
         attribute that it uses when the user
         interfaces provided by IPP clients requested charset or their applications.  For
         example, one application might natural language
         are not allow an end user to submit
         multiple documents per job, while another does.  One application might
         first supported.  The client can query a the Printer object in order to supply a graphical user
         interface (GUI) dialogue box with
         determine the list of charsets and natural languages supported by the
         Printer object and default what the Printer object's configured values whereas
         a different implementation might not.

         When sending a Get-Attributes or create request, an IPP client need
         not supply any are.
         See the "printer-charset", "charset-supported", "printer-natural-
         language", and "natural-language-supported" Printer description
         attributes.

         A client SHALL

         The 'text' and 'name' attributes specified in this version of this
         document (additional ones will be able registered according to accept any of the attribute syntaxes defined
         procedures in Section 4.1 6) are:

           Operation Attributes:
              job-name (name)
              document-name (name)

           Job Attributes:
              job-name (name)
              job-originating-user (name)
              job-state-message (text)
              job-message-from-operator (text)

           Printer Attributes:
              printer-name (name)
              printer-location (text)

                                 Expires April 14, 1998
              printer-info (text)
              printer-make-and-model (text)
              printer-state-message (text)
              printer-message-from-operator (text)

         8. Security Considerations

         It is required that may the IPP be returned able to it operate within a secure
         environment.  IPP attempts to make use of existing security protocols
         and services, wherever possible. Examples of such services include the
         Digest Access Authentication in HTTP 1.1 [RFC2069] and the Transport
         Layer Security (TLS) services, currently under development in the
         IETF.

         It is difficult to anticipate the security risks that might exist in
         any given IPP environment. For example, if IPP is used within a response from given
         corporation over a Printer

         A query response private network, the risks of exposing document
         data may contain parameters, attributes, and values be low enough that the client does corporation will choose not expect.  Therefore, a to use
         encryption on that data.  However, if the connection between the
         client implementation MUST
         gracefully handle such responses and not refuse the IPP object is over a public network, the client may
         wish to interoperate protect the content of the information during transmission
         through the network with encryption.

         Furthermore, the value of the information being printed may vary from
         one use of the protocol to the next. Printing payroll checks, for
         example, would have a
         conforming Printer that different value than printing public information
         from a file.  In addition, there is returning extended registered always the threat of a virus
         attack.  However, there are no known viruses or private
         attributes and/or attribute values potential for viruses
         that conform to Section 6.  Clients are self-propagated throughout distributed printing environments.
         Therefore, IPP implementations may choose to ignore any parametes, attributes, implement protection
         against printer-damaging print jobs.

         Since the security levels or values that it does
         not understand.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         5.2 Printer Object Conformance Requirements

         This section specifies the conformance requirements for conforming
         Printer object implementations specific threats that any given IPP
         print administrator may be concerned with respect cannot be anticipated, IPP
         MUST be capable of operating with different security mechanisms and
         security policies as required by the individual installation. Security
         policies might vary from very strong, to objects, operations, very weak, to none at all,
         and attributes.

         5.2.1 Objects

         Conforming Printer implementations SHALL implement all corresponding security mechanisms will be required.

         The initial security needs of IPP are derived from two primary
         considerations:

           - First, the model printing environments envisioned for IPP include
              configurations where the client, the Printer, and the document(s)
              to be printed may all exist in different security domains. When
              objects as defined are in this specification different security domains the requirements for

                                 Expires April 14, 1998
              authentication and message protection are much stronger than when
              they are in the indicated sections:

           Section 2.1 Printer Object
           Section 2.2 Job Object
           Section 2.3 Document Object

         5.2.2 Operations

         Conforming Printer implementations SHALL implement all of same domain.

           - Second, the
         MANDATORY model operations, including mandatory responses, as defined
         in this specification in sensitivity and value of the indicated sections:

           For a Printer object:
              Print-Job (section 3.2.1)                    MANDATORY
              Print-URI (section 3.2.2)                    OPTIONAL
              Validate-Job (section 3.2.3)            MANDATORY
              Create-Job (section 3.2.4)              OPTIONAL
              Get-Jobs (section 3.2.6)                MANDATORY
              Get-Attributes (section3.2.5)           MANDATORY content being printed
              will vary. For example, a Job object:
              Send-Document (section 3.3.1)           OPTIONAL
              Send-URI (section 3.3.2)                OPTIONAL
              Cancel-Job (section 3.3.3)                   MANDATORY
              Get-Attributes (section 3.3.4)                    MANDATORY

         Conforming Printer implementations SHALL support all request publicly available document does not
              require the same level of privacy that a payroll document
              requires. There are at least two parties that have an interest in
              the value of the information being printed, the person asking to
              have the information printed and
         response parameters the person who originated the
              information. This brings into the picture the need to worry about
              copyrights and all values protection of such parameters, except the content.

         The following sections describe specific security attacks for
         parameters which IPP
         environments.  Where examples are collections provided they should be considered
         illustrative of attributes. The following section
         on attributes specifies the support required for attributes.

         5.2.3 Attributes

         Conforming Printer implementations SHALL support environment and not an exhaustive set. Not all of the MANDATORY
         attributes, as defined in this specification
         these environments will necessarily be addressed in the indicated
         sections.

         If a initial
         implementations of IPP.

         8.1 Client and Printer supports an attribute, it SHALL support only those values
         specified in this document or through the extension mechanism

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         described in the next section. It MAY support any non-empty subset Same Security Domain

         This environment is typical of
         these values. That is, it SHALL support at least one internal networks where traditional
         office workers print the output of personal productivity applications
         on shared work-group printers, or where batch applications print their
         output on large production printers. Although the specified
         values and at most all identity of them.

         5.2.4 Printer extensions

         A conforming Printer the user
         may support registered extensions and private
         extensions, be trusted in this environment, a user might want to protect the
         content of a document against such attacks as long eavesdropping, replaying
         or tampering.

         8.2 Client and Printer in Different Security Domains

         Examples of this environment include printing a document created by
         the client on a publicly available printer, such as they meet at a commercial
         print shop; or printing a document remotely on a business partner's
         printer. This latter operation is functionally equivalent to sending
         the requirements specified in Section
         6.

         A conforming Printer SHALL send responses that conform document to the protocol
         defined in _Internet business partner as a facsimile. Printing Protocol/1.0: Protocol Specification_
         [23]. For each parameter or attribute included
         sensitive information on a Printer in an operation
         response, a conforming different security domain
         requires strong security measures. In this environment authentication
         of the printer SHALL send a value whose type is required as well as protection against unauthorized
         use of print resources. Since the document crosses security domains,
         protection against eavesdropping and value
         syntax conforms document tampering are also
         required. It will also be important in this environment to protect
         Printers against "spamming" and malicious document content code.

                                 Expires April 14, 1998
         8.3 Print by Reference

         When the requirement of this document

         5.2.5 Attribute Syntaxes

         A Printer SHALL is not stored on the client, printing can be able to accept any of done by
         reference. That is, the attribute syntaxes
         defined in Section 4.1 in any operation in which print request can contain a client may supply
         attributes reference, or parameters.  Furthermore, a Printer SHALL return
         attributes
         pointer, to the document instead of the actual document itself. If the
         client in operation responses that conform physically gets the document before it prints it, then this
         defaults to one of the
         syntax specified in Section 4.1.

         5.3 Security Conformance Requirements

         ISSUE: The "why" and "what" needs previous cases.

         8.3.1 Unprotected Documents

         In many cases, documents to be printed are literally available to
         anyone. Documents, such as this Internet Draft which are stored on
         anonymous FTP sites, are good examples of this. No security mechanisms
         are required to be moved from the Security
         document protect access to this document.  The "how" from these documents.

         8.3.2 Protected Documents

         Clearly, there are cases where the Security nature of a document needs requires that
         access to it be moved to the Protocol Specification document.

         6. IANA Considerations (registered and private extensions)

         During the development of this standard, the IPP working group
         (working with IANA) will register additional keywords and enums while
         the standard is in protected by some authentication and/or authorization
         mechanism, or where the proposed and draft states according right to print the
         procedures described in this section.  IANA will handle registration
         of additional enums after this standard is approved in cooperation
         with an IANA-appointed registration editor from document must be paid for.
         This would be the IPP working group
         according case for sensitive or confidential information, or
         where documents are copyrighted or sold for profit. Unauthorized
         access to the procedures described content is a major concern in this section.

         6.1 Typed Extensions

         This environment. Protection
         against eavesdropping, document uses prefixes to the "keyword" tampering and "enum" basic syntax
         type in order to communicate extra information unauthorized access to
         the reader through
         its name. This extra information need not be represented in an

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         implementation because it document are also concerns if the content is unimportant to a client sensitive.

         8.4 Common Security Scenarios

         As discussed earlier, we cannot anticipate the security levels or Printer.  The
         list below describes the prefixes and their meaning.

           "type1":  The
         specific threats that any given IPP standard must print administrator may be revised
         concerned with.  Security policies might vary from very strong, to add a new keyword or
              a new enum.  No private keywords or enums are allowed.

           "type2":  Implementers can,
         very weak, to none at any time, add new keyword or enum
              values by proposing them all.  In this section we will describe what we
         believe to be four common usage scenarios.

           1) No security at all
           2) Message protection during transmission
           3) Client authentication and authorization
           4) Mutual authentication, authorization, and message protection

         8.4.1 No Security

         If the IPP working group for
              registration (or an IANA-appointed registry advisor after server requires no authorization and the IPP
              working group is client wants no longer certified) where they are reviewed for
              approval.  IANA keeps
         message protection the registry.

           "type3":  Implementers can, at any time, add new keyword client can send the print job, i.e., the job
         content and enum
              values by submitting a registration request directly to IANA, no
              IPP working group or IANA-appointed registry advisor review is
              required.

           "type4":  Anyone (system administrators, system integrators, site
              managers, etc.) can, at the job attributes without invoking any time, add new installation-defined
              values (keywords or new enum values) to a local system. Care
              SHOULD be taken by security
         mechanisms. The printer will print the implementers to see that keywords do not
              conflict with other keywords defined by job for the standard or as
              defined client. Print by the implementing product. There is

                                 Expires April 14, 1998
         reference also works well in this environment as long as no registration or
              approval procedure for type 4 keywords.

         By definition, each of security
         mechanisms are required to access the four documents to be printed.

         8.4.2 Message Protection During Transmission

         There are two types above assert some sort of
         registry or review process in order for extensions to security that could be considered
         valid.  Each higher level (1, 2, 3, 4) tends used to provide message
         protection. These are channel security and object security. In the
         first case, the channel can be decreasingly less
         stringent than the previous level.   Therefore, any typeN value MAY be
         registered made secure using a process for some typeM where M is less than N,
         however such registration is NOT REQUIRED.  For example, a type4 value
         MAY be registered in a type 1 manner (by being included the Transport Layer
         Security (TLS) protocol, currently under development in a future
         version the IETF.  In
         the case of an IPP specification) however it object security, each object is NOT REQUIRED.

         This specification defines keyword encrypted and enum values for all of the
         above types, including type4 keywords.

         For private (unregistered) keyword extensions, implementers SHOULD use
         keywords with sent over
         either a suitable distinguishing prefix, such as "xxx-" where
         xxx is secure or insecure channel.  The recipient has the (lowercase) fully qualified company name registered with
         IANA for use in domain names [30].

         Note: RFC 1035 [30] indicates that while upper
         corresponding key to decrypt the object and lower case letters get the content. Several
         object security mechanisms are allowed currently under study in domain names, no significance is attached to the case.
         That is, two names with IETF.  IPP
         neither mandates the same spelling but different case are to be
         treated as if identical.  Also, use of these object security mechanisms nor does
         it prohibit the labels in use of them.  IPP will define a domain name must
         follow the rules recommended mechanism
         for ARPANET host names:  They must start with a
         letter, end with a letter or digit, channel security, which is deemed more suitable to meet the IPP
         requirements.

         8.4.3 Client Authentication and have as interior characters

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         only letters, digits, Authorization

         This scenario requires client authentication. The authenticated user
         ID may be used for authorization purposes, and hyphen.  Labels must may be 63 characters or
         less.  Labels are separated encrypted by the "." character.

         For private (unregistered) enum extension, implementers SHOULD use
         values in
         lower security layer.  TLS supports both one sided and mutual
         authentication.  IPP does not mandate the reserved integer range (see "enum").

         6.2 Registration use of MIME types/sub-types for document-formats

         The "document-format" attribute's syntax is "mimeType". any specific
         authorization mechanism (see section 3.1.5.1).

         8.4.4 Mutual Authentication, Authorization and Message Protection

         This means
         that valid values are MIME types.  RFC 2045 [??] defines the syntax
         for valid MIME types.  Also, IANA is the registry scenario requires mutual authentication and message protection.
         TLS can be used for this security feature in these configurations.

         8.5 Recommended Security Mechanisms

         IPP requires all MIME types.

         6.3 Attribute Extensibility

         Attribute names are considered to be set of type2 keywords.  In order IPP clients and Printers to be extended, support the same rules as type2 keywords apply.

         6.4 Attribute Syntax Extensibility

         Attribute syntaxes are considered
         authentication features in HTP 1.1 and intends to be set mandate TLS for
         scenarios requiring channel security, once these specifications have
         become stabilized.

         IPP implementations should provide a range of type2 enums.  In order security options to be extended, meet
         the same rules as type2 enums apply.

         7. Internationalization Considerations

         This model describes attributes whose values can be text strings
         intended for human understanding rather than machine understanding.
         These attributes are:

         Printer Attributes:

           printer-name
           printer-location
           printer-description
           printer-make-and-model
           printer-state-message
           printer-message-from-operator

         Job Attributes

           job-name
           job-state-message
           job-message-from-operator

         Document Attributes

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           document-name

         These attributes MUST contain characters for needs of different installations and user populations.  Many of
         the coded character set
         defined in ISO 10646 [??] security services that are enabled at a given site will be done so
         by a site administrator. The mechanisms used to establish these
         services and to define user IDs and be encoded using passwords to the UTF-8 character
         encoding rules [28].  No other coded character sets or encoding rules
         are allowed.

         However, since these strings system are intended for human understanding, the
         strings can be in any human language identifiable with tags
         implementation defined in
         RFC 1766 [??].  A client that queries and outside the above mentioned text
         attributes needs to know what human language is being scope of IPP.

         The security protocol used for these
         text attributes.  A Printer optionally supports by a "human-languages-
         supported" supported values attribute and particular IPP operation will depend
         upon the security services implemented on the Printer, the security

                                 Expires April 14, 1998
         policy established by a "human-language" default
         value attribute.  Since these are optional, if site administrator, and the printer does not
         support these attributes, selection made by
         the client can assume client. This requires that the text strings
         are either US English "en-US" or any other language that is specific right handshake messages be passed
         to a given site.  Whatever invoke the value, selected security  service. These are described in the same value applies to ALL
         text based attributes
         references for a given Printer each security mechanism and its contained Jobs.

         In are normally invoked by the HTTP mapping for IPP/1.0, these
         client. The "security-mechanisms-supported" and "printer-more-info"
         attributes are mapped in can be queried to help the
         HTTP headers that control negotiation of human language between client
         and server.

         8. Security Considerations

         There is another Internet-Draft called "Internet Printing
         Protocol/1.0: Security" [22].  That document is being drafted and
         reviewed end user know what to expect in parallel with this document.  The mapping
         terms of security. These attributes should also appear in the
         directory entry for each Printer.

         Note: When utilizing HTTP/1.1 as a transport for IPP [IPP-PRO], the
         security considerations outlined in HTTP/1.1 apply. When set by an
         administrator, IPP servers MUST generate a 401 (Unauthorized) response
         code to request client authentication and IPP on top clients should correctly
         respond with the proper Authorization header. Both basic
         authentication and digest authentication flavors of
         appropriate security protocols will authentication
         should be described supported. The administrator chooses which type(s) of
         authentication to accept. Digest authentication is a more secure
         method and is always preferred to basic authentication.

         For secure communication (privacy in that document. particular), IPP does not introduce any new, general purpose security mechanisms
         for authentication should be run
         using a secure communications channel. TLS provides secure
         communications channels and encryption.

         A Printer may choose, provides for security reasons, not mutual authentication. The
         secure communications channel must be initiated prior to return all
         attributes that a client requests. It may even return none of running the
         requested attributes. In such cases,
         IPP protocol. There is no mechanism for bootstrapping a secure
         communication channel from within the status returned IPP protocol itself.

         It is possible to combine a secure communication channel with either
         Basic or Digest Authentication.

         For a Printer object that supports only non-secure access, the same
         as if Printer
         object supports only the "printer-uri" attribute.  For a Printer had returned all requested attributes. The client
         cannot tell by such
         object that supports only secure access, the Printer object supports
         only the "printer-tls-uri".  For a response whether Printer object that supports both
         secure and non-secure access, the requested attribute was
         present or absent on Printer object supports both the Printer.
         "printer-uri" and the "printer-tls-uri" attributes.

         9. References

         [1]  Smith, R., Wright, F., Hastings, T., Zilles, S.,

          [ASCII]
              Coded Character Set - 7-bit American Standard Code for
              Information Interchange (ASCII), ANSI X3.4-1986. This standard is
              the specification of the 'US-ASCII' charset.

         [CS-POL]
              H. Alvestrand, "IETF Policy on Character Sets and Gyllenskog,
              J., "Printer MIB", RFC 1759, March 1995.

         [2]  R Fielding, et al, _Hypertext Transfer Languages, work
              in progress <draft-alvestrand-charset-policy-01.txt>, August 29,
              1997.

                                 Expires April 14, 1998
         [HTPP]
              J. Barnett, K. Carter, R. DeBry,  "Initial Draft - Hypertext
              Printing Protocol _ HTTP/1.1_ RFC
              2068, January 1997

         deBry, Hastings, - HTPP/1.0", October 1996,
              ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/ overview.ps.gz

         [IANA-CS]
              IANA Registry of Coded Character Sets:  ftp://ftp.isi.edu/in-
              notes/iana/assignments/character-sets

         [IANA-CSa]
              N. Freed, J. Postel:  IANA CharSet Registration Procedures, Work
              in Progress (draft-freed-charset-reg-02.txt).

         [IANA-MT]
              IANA Registry of Media Types:  ftp://ftp.isi.edu/in-
              notes/iana/assignments/media-types/

         [IPP-PRO]
              Herriot, Isaacson, Powell
                               Expires February xx, 1998
         [3]  Crocker, D., "Standard R. (et al), " Internet Printing Protocol/1.0: Protocol
              Specifications", draft-ipp-pro-03.txt, November, 1997.

         [IPP-RAT]
              Zilles, S., "Rationale for the Structure and Model and Protocol
              for the Format of ARPA Internet Text
              Messages", RFC 822, August 1982.

         [4]  Postel, J., "Instructions to RFC Authors", RFC 1543, October
              1993.

         [5] Printing Protocol", draft-ipp-rat-01.txt,
              November, 1997.

         [IPP-REQ]
              Wright, D., "Requirements for an Internet Printing Protocol",
              draft-ipp-req-01.txt, November, 1997.

         [ISO10646-1]
              ISO/IEC 10646-1:1993, "Information technology -- Universal
              Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture
              and Basic Multilingual Plane, JTC1/SC2."

         [ISO8859-1]
              ISO/IEC 8859-1:1987, "Information technology -- 8-bit One-Byte
              Coded Character Set - Part 1: Latin Alphabet Nr 1", 1987,
              JTC1/SC2.

         [ISODPA]
              ISO/IEC 10175 Document Printing Application (DPA), June 1996.

         [6]  Herriot, R. (editor), X/Open A

          [LDPA]
              T. Hastings,  S. Isaacson,  M. MacKay, C. Manros, D. Taylor, P.
              Zehler,  "LDPA - Lightweight Document Printing System Interoperability
              Specification (PSIS), August 1995.

         [7] Application",
              October 1996,
              ftp://ftp.pwg.org/pub/pwg/ipp/historic/ldpa/ldpa8.pdf.gz

                                 Expires April 14, 1998
         [P1387.4]
              Kirk, M. (editor), POSIX System Administration - Part 4: Printing
              Interfaces, POSIX 1387.4 D8, 1994.

         [8]

         [PSIS]    Herriot, R. (editor), X/Open A Printing System
              Interoperability Specification (PSIS), August 1995.

         [RFC1035]
              P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND
              SPECIFICATION", RFC 1035, November 1987.

         [RFC1179]
              McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" RFC
              1179, August 1990.

         [RFC1514]
              ?, "  ", RFC 1514, ?.

          [RFC1521]
              Borenstein, N., and Freed, N., "MIME (Multi-purpose Internet Mail
              Extensions) Part One: Mechanism for Specifying and Describing the
              Format of Internet Message Bodies", RFC 1521, September, 1993.

         [9]  Braden, S., "Requirements

         [RFC1630]
              T. Berners-Lee, "Universal Resource Identifiers in WWW: A
              Unifying Syntax for Internet Hosts - Application the Expression of Names and
              Support", RFC 1123, October, 1989,

         [10] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" Addresses of
              Objects on the Network as used in the World-Wide Web", RFC
              1179, August 1990.

         [11] 1630,
              June 1994.

         [RFC1738]
              Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform Resource
              Locators (URL)", RFC 1738, December, 1994.

          [20]     Internet Printing Protocol: Requirements

         [21] Internet Printing Protocol/1.0: Model

         [RFC1759]
              Smith, R., Wright, F., Hastings, T., Zilles, S., and Semantics (This
              document)

         [22] Internet Printing Protocol/1.0: Security

         [23] Internet Printing Protocol/1.0: Protocol Specification

         [24] Internet Printing Protocol/1.0: Directory Schema

         [25] S. Bradner, "Key words for use in RFCs to Indicate Requirement
              Levels", Gyllenskog,
              J., "Printer MIB", RFC 2119 , 1759, March 1997

         [26] 1995.

         [RFC1766]
              H. Alvestrand, " Tags for the Identification of Languages", RFC
              1766, March 1995.

         [27] T. Hastings, "Job Monitoring MIB", <draft-ietf-print-mib-
              monitoring-01.txt>, June 1997.

         deBry, Hastings, Herriot, Isaacson, Powell

         [RFC1808]
              ?, "  ", RFC 1808, ?.

         [RFC1825]
              R. Atkinson, "Security Architecture for the Internet Protocol",
              RFC 1825, August 1995

                                 Expires February xx, April 14, 1998
         [28]
         [RFC1903]
              ?, "  ", RFC 1903, ?.

          [RFC2044]
              F. Yergeau, "UTF-8, a transformation format of Unicode and ISO
              10646,
              10646", RFC 2044, October 1996.

         [29] Turner,

         [RFC2068]
              R. "Printer MIB", draft-ietf-printmib-mib-info-02.txt,
              July 8, Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee,
              "Hypertext Transfer Protocol - HTTP/1.1", RFC 2068, January 1997

         [RFC2069]
              J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen,
              E. Sink, L. Stewart, "An Extension to HTTP: Digest Access
              Authentication", RFC-2069, Jan 1997.  This I-D is an update

         [RFC2119]
              S. Bradner, "Key words for use in RFCs to Indicate Requirement
              Levels", RFC 1759, 2119 , March 1995 [1].

         [30] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND
              SPECIFICATION", RFC 1035, November 1987.

         [31] 1997

         [RFC2130]
              ?, "  ", RFC 2130, ?.

         [32] ?, "

          [RFC2045]
              N. Fried, N. Borenstein, ", RFC 1514, ?.

         [33] ?, Multipurpose Internet Mail Extensions
              (MIME) Part One: Format of Internet Message Bodies "  ", RFC 1903, ?.

         [34] ?, "  ", 2045,
              November 1996.

         [RFC2046]
              Multipurpose Internet Mail Extensions (MIME) Part Two: Media
              Types. N. Freed & N. Borenstein. November 1996. (Obsoletes
              RFC1521, RFC1522, RFC1590), RFC 1808, ?. 2046.

         [RFC2048]
              Multipurpose Internet Mail Extension (MIME) Part Four:
              Registration Procedures. N. Freed, J. Klensin & J. Postel.
              November 1996. (Format: TXT=45033 bytes) (Obsoletes RFC1521,
              RFC1522, RFC1590) (Also BCP0013), RFC 2048.

         [RFC2184]
              N. Fried, K. Moore, "MIME Parameter Value and Encoded Word
              Extensions: Character Sets, Languages, and Continuations", RFC
              2184, August 1997

         [SWP]
              P. Moore, B. Jahromi, S. Butler, "Simple Web Printing SWP/1.0",
              May 7, 1997, ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/swp9705.pdf

                                 Expires April 14, 1998
         10. Copyright Notice

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

         This document and translations of it may be copied and furnished to
         others, and derivative works that comment on or otherwise explain it
         or assist in its implementation may be prepared, copied, published and
         distributed, in whole or in part, without restriction of any kind,
         provided that the above copyright notice and this paragraph are
         included on all such copies and derivative works.  However, this
         document itself may not be modified in any way, such as by removing
         the copyright notice or references to the Internet Society or other
         Internet organizations, except as needed for the  purpose of
         developing Internet standards in which case the procedures for
         copyrights defined in the Internet Standards process must be followed,
         or as required to translate it into languages other than English.

         The limited permissions granted above are perpetual and will not be
         revoked by the Internet Society or its successors or assigns.

         This document and the information contained herein is provided on an
         "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
         TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
         NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
         WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
         MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

         11. Author's Address

              Scott A. Isaacson (Editor)
              Novell, Inc.
              122 E 1700 S
              Provo, UT   84606

              Phone: 801-861-7366
              Fax:   801-861-4025
              EMail: scott_isaacson@novell.com

              Tom Hastings
              Xerox Corporation
              701 S. Aviation Blvd.
              El Segundo, CA   90245

                                 Expires April 14, 1998
              Phone: 310-333-6413
              Fax:   310-333-5514
              EMail: hastings@cp10.es.xerox.com

              Robert Herriot
              Sun Microsystems Inc.
              901 San Antonio.Road, MPK-17
              Palo Alto, CA 94303

              Phone: 415-786-8995 (Area code change to 650 in August 1997)
              Fax:  415-786-7077 (Area code change to 650 in August 1997)
              Email: robert.herriot@eng.sun.com

              Roger deBry

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              HUC/003G
              IBM Corporation
              P.O. Box 1900
              Boulder, CO 80301-9191

              Phone: (303) 924-4080
              Fax: (303) 924-9889
              Email: debry@vnet.ibm.com

              Patrick Powell
              San Diego State University
              9475 Chesapeake Dr., Suite D
              San Diego, CA  95123

              Phone: (619) 874-6543
              Fax: (619) 279-8424
              Email: papowell@sdsu.edu

              IPP Mailing List:  ipp@pwg.org
              IPP Mailing List Subscription:  ipp-request@pwg.org
              IPP Web Page:  http://www.pwg.org/ipp/

         Other Participants:

              Chuck Adams - Tektronix
              Jeff Barnett - IBM
              Ron Bergman - Dataproducts Corp.
              Sylvan Butler, HP
              Keith Carter, IBM Corporation
              Jeff Copeland - QMS
              Andy Davidson - Tektronix
              Mabry Dozier - QMS
              Lee Farrell - Canon Information Systems
              Steve Gebert - IBM

                                 Expires April 14, 1998
              Babek Jahromi, Microsoft
              David Kellerman - Northlake Software
              Rick Landau - Digital
              Harry Lewis - IBM
              Pete Loya - HP
              Ray Lutz - Cognisys Mike MacKay, Novell, Inc.
              Carl-Uno Manros, Xerox, Corp.
              Jay Martin - Underscore
              Stan McConnell - Xerox
              Ira McDonald, High North Inc. Paul Moore, Microsoft
              Pat Nogay - IBM
              Bob Pentecost - HP
              Rob Rhoads - Intel

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              Rob Rhoads - Intel
              David Roach - Unisys
              Stuart Rowley, Kyocera
              Hiroyuki Sato - Canon
              Bob Setterbo - Adobe
              Devon Taylor, Novell, Inc.
              Mike Timperman - Lexmark
              Randy Turner - Sharp
              Atsushi Yuki - Kyocera
              Lloyd Young - Lexmark
              Bill Wagner - DPI
              Jim Walker - DAZEL
              Chris Wellens - Interworking Labs
              Rob Whittle - Novell
              Don Wright - Lexmark
              Peter Zehler, Xerox, Corp.

         deBry, Hastings, Herriot, Isaacson, Powell
              Steve Zilles, Adobe

                                 Expires February xx, April 14, 1998
         11.
         12. APPENDIX A: Terminology

         This specification uses the terminology defined in this section.

         11.1

         12.1 Conformance Terminology

         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
         "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and  "OPTIONAL" in this
         document are to be interpreted as described in RFC 2119 [25]. [RFC2119]. The
         sections below reiterate these definitions and include some additional
         ones.

         11.1.1

         12.1.1 MUST

         This word, or the terms "REQUIRED",  "SHALL" or "MANDATORY", means
         that the definition is an absolute requirement of the specification.

         11.1.2

         12.1.2 MUST NOT

         This phrase, or the phrase "SHALL NOT", means that the definition is
         an absolute prohibition of the specification.

         11.1.3

         12.1.3 SHOULD

         This word, or the adjective "RECOMMENDED", means 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.

         11.1.4

         12.1.4 SHOULD NOT

         This phrase, or the phrase "NOT RECOMMENDED" means 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.

         11.1.5

         12.1.5 MAY

         This word, or the adjective "OPTIONAL", means that an item is truly
         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

         deBry, Hastings, Herriot, Isaacson, Powell

                                 Expires February xx, April 14, 1998
         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.)

         11.1.6

         12.1.6 NEED NOT

         The verb "NEED NOT" indicates an action that the subject of the
         sentence does not have to implement in order to claim conformance to
         the standard.  The verb "NEED NOT" is used instead of "MAY NOT" since
         "MAY NOT" sounds like a prohibition.

         11.2

         12.2 Model Terminology

         11.2.1

         12.2.1 Keyword

         Keywords are used within this document as identifiers of semantic
         entities within the abstract model.  Attribute names, some attribute
         values, attribute syntaxes, and attribute group names are represented
         as keywords.  In this document, a keyword is a sequence of characters
         (length of 1 to 255) which consists of the following ASCII characters:
         lower-case letters ("a" - "z"), digits ("0" - "9"), hyphen ("-"),
         period ("."), and underscore ("_").  A keyword starts with a lower-
         case letter.

         11.2.2

         12.2.2 Attributes

         An attribute is an item of information that is associated with an
         instance of an IPP object.  An attribute consists of an attribute name
         and an attribute value(s).  Each attribute has a specific syntax.  All
         attributes are defined in section 4.

         An interesting set of attributes is called

         Job Template Attributes
         (these attributes are described in detail in section 4.2.) 4.2. The client
         optionally supplies Job Template attributes as input parameters in a create request
         (operation requests that create Job objects).  The Printer object has
         associated attributes which define supported and default values for
         the Printer.

         11.2.2.1

         12.2.2.1 Attribute Name

         Each attribute is uniquely identified in this document by its
         attribute name.  An attribute name is a keyword.  The keyword
         attribute name is given in the section header describing that

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         attribute.  In running text in this document, attribute names are
         indicated inside double quotation marks (").

         11.2.2.2 (") where the quotation marks
         are not part of the keyword itself.

                                 Expires April 14, 1998
         12.2.2.2 Attribute Group Name

         Related attributes are grouped into named groups.  The name of the
         group is a keyword.  The group name may be used in an input parameter
         in place of naming all
         the attributes in the group explicitly.  Attribute groups are defined
         in section 3.

         11.2.2.3

         12.2.2.3 Attribute Value

         Each attribute has one or more values.  Attribute values are
         represented in the syntax type specified for that attribute. In
         running text in this document, attribute values are indicated inside
         single quotation marks ('), whether their attribute syntax is keyword,
         integer, text, etc.

         11.2.2.4 where the quotation marks are not part of the
         value itself.

         12.2.2.4 Attribute Syntax

         Each attribute is defined using an explicit syntax type.  In this
         document, each syntax type is defined as a keyword with specific
         meaning.  The protocol specification document [23] [IPP-PRO] indicates the
         actual "on-the-wire" encoding rules for each syntax type. Attribute
         syntax types are defined in section 4.1.

         11.2.3

         12.2.3 Supports

         By definition, an implementation (an instance of an IPP object) a Printer object supports an attribute only if that implementation
         Printer object responds with the corresponding attribute and value populated
         with some value(s) in a response to a query for that attribute.  A given implementation
         Printer object supports an attribute value if the value is one of
         Printer object's "supported values" attributes.  The device behind a
         Printer object  may exhibit a behavior that corresponds to the value of some IPP
         attribute, but if the implementation, Printer object, when queried for that attribute,
         doesn't respond with the supported
         attribute populated with that specific value, attribute, then as far as IPP is concerned,
         that implementation does not support that feature.  If the Printer
         object supports Job Template attribute "foo" then it supports both a
         "foo-default" default value attribute and a "foo-supported" supported
         values attribute.  If the Printer object's "foo-supported" attribute
         is not populated with some value (even if that value is a legal value
         for that attribute), then that Printer object does not support that
         value.

         A conforming implementation SHALL support all MANDATORY attributes.
         However, even for MANDATORY attributes, conformance to IPP does not
         mandate that all implementations support all possible values
         representing all possible job processing behaviors and features.  For
         example, if a given instance of a Printer supports only certain
         document formats, then that Printer responds with the "document-

                                 Expires April 14, 1998
         format-supported" attribute populated with a set of values, possibly
         only one, taken from the entire set of possible values defined for
         that attribute. This limited set of values represents the Printer's
         set of supported document formats.  Supporting an attribute and some
         set of values for that attribute enables IPP end users to be aware of

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         and make use of those features associated with that attribute and
         those values.  If an implementation chooses to not support an
         attribute or some specific value, then IPP end users would have no
         ability to make use of that feature within the context of IPP itself.
         However, due to existing practice and legacy systems which are not IPP
         aware, there might be some other mechanism outside the scope of IPP to
         control or request the "unsupported" feature (such as embedded
         instructions within the print document data itself, for example). itself).

         For example, consider the "finishings-supported" attribute.  If a
         Printer is not physically capable of stapling, the "finishings-
         supported" attribute MUST NOT be populated with the value of 'staple'.
         If a Printer is physically capable of stapling, an implementation MAY
         choose to support the "finishings-supported" attribute and the value
         of 'staple'.  Doing so, would enable end users to be aware of and make
         use of the stapling feature.  Without support for the value 'staple',
         an IPP end user would have no means within the protocol itself to
         request that a Job be stapled.  However an existing print document data
         formatter might be able to request that the document be stapled
         directly within the print document data itself.  In this case, the IPP
         implementation does not "support" stapling, however the end user is
         still able to have some control over the stapling of the completed
         job.

         In order to ease the implementation burden, many IPP attributes are
         OPTIONAL.  Therefore, it is an implementation choice whether or not to

         Even though support OPTIONAL attributes and values, even if those for Job Template attributes and
         values correspond to features and functions that are realizable in the
         implementation. However, it by a Printer object is RECOMMENDED that if an IPP
         implementation
         OPTIONAL, it is RECOMMENDED that if the device behind a Printer object
         is capable of realizing any feature or function that corresponds to an
         IPP attribute and some associated value, then that implementation
         support that IPP attribute and value.

         Note:

         The set of values in any of the supported value attributes is set
         (populated) by some administrative process or automatic sensing
         mechanism that is outside the scope of IPP.  For administrative policy
         and control reasons, an administrator may choose to make only a subset
         of possible values visible to the end user.  In this case, the real
         output device behind the IPP Printer abstraction may be capable of a
         certain feature, however an administrator is specifying that access to
         that feature not flow back to the end user through the IPP protocol.

         deBry, Hastings, Herriot, Isaacson, Powell
         Also, since a Printer object may represent a logical print device (not
         just a physical devices) the actual process for supporting a value is
         undefined and left up to the implementation.  However, if a Printer
         object supports a value, some manual human action may be needed to
         realize the semantic action associated with the value, but no end user

                                 Expires February xx, April 14, 1998
         12.
         action is required.  For example, if one of the values in the
         "finishings-supported" attribute is 'staple', the actual process might
         be an automatic staple action by a physical device controlled by some
         command sent to the device.  Or, the actual process of stapling might
         be a manual action by an operator at an operator attended Printer
         object.  For another example of how supported attributes function,
         consider an system administrator that desire to control all print jobs
         so that no cover sheets are printed in order to conserve paper.  To
         force no job sheets, the system administrator sets the only supported
         value for the "job-sheets-supported" attribute to 'none'. In this
         case, if a client requests anything except 'none', the create request
         is rejected (depending on the value of "ipp-attribute-fidelity" of
         course).  To force the use of banner pages on all jobs, the
         administrator does not include the value 'none' in the "job-sheets-
         supported" attribute.  In this case, if a client requests 'none', the
         create request is rejected (again depending on the value of "ipp-
         attribute-fidelity").

         12.2.4 print-stream page

         A "print-stream page" is a page according to the definition of pages
         in the language used to express the document data.

         12.2.5 imposed page

         An "imposed page" is a page created by placing N print-stream pages
         onto a single media page.

         13. APPENDIX B:  Status Codes

         This section defines status code keywords that are used to provide
         semantic information on the results of an operation request.  Each
         operation response MUST include a status code.  For error type status
         codes, the response MAY also contain a status message that provides a
         short textual description of the status. The status code is intended
         for use by automata, and the status message is intended for the human
         end user.  Since the status message is an OPTIONAL component of the
         operation response, an IPP application (i.e. a browser, GUI, print
         driver or gateway) is NOT REQUIRED to examine or display the status
         message.

         The prefix of the status keyword defines the class of response as
         follows:

           "informational" - Request received, continuing process
           "successful" - The action was successfully received, understood,
              and accepted

                                 Expires April 14, 1998
           "redirection" - Further action must be taken in order to complete
              the request
           "client-error" - The request contains bad syntax or cannot be
              fulfilled
           "server-error" - The server failed to fulfill an apparently valid
              request

         Since IPP status codes are type2 enums, they are extensible.  IPP
         applications are NOT REQUIRED to understand the meaning of all
         registered status codes, though such understanding is obviously
         desirable.  However, applications SHALL understand the class of any
         status code, as indicated by the prefix, and treat any unrecognized
         response as being equivalent to the first status code of that class,
         with the exception that an unrecognized response shall not be cached.
         For example, if an unrecognized status code of "client-error-foo-bar"
         is received by the client, it can safely assume that there was
         something wrong with its request and treat the response as if it had
         received a "client-error-bad-request" status code.  In such cases, IPP
         applications could SHOULD present the OPTIONAL message (if present) to the
         end user since the message is likely to contain human readable
         information which will help to explain the unusual status.

         12.1

         13.1 Status Codes (type2 keyword)

         Each status code is described below. Section 12.2 13.2 contains a table
         that indicates which status codes apply to which operations.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         12.1.1

         13.1.1 Informational

         This class of status code indicates a provisional response and is to
         be used for informational purposes only.

         There are no status codes defined in IPP 1.0 for this class of status
         code.

         12.1.2

         13.1.2 Successful Status Codes

         This class of status code indicates that the client's request was
         successfully received, understood, and accepted.

         12.1.2.1

         13.1.2.1 successful-ok (0x00) (0x0000)

         The request has succeeded.

         12.1.2.2

                                 Expires April 14, 1998
         13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x01) (0x0001)

         The request has succeeded, but since ignoring or substituting of
         values was requested ("ipp-attribute-fidelity" set to 'false' in the
         create request), some attributes were ignored or unsupported values
         were substituted with supported values in order to process the job
         without rejecting it.

         12.1.3

         13.1.3 Redirection Status Codes

         This class of status code indicates that further action needs to be
         taken to fulfill the request.

         There are no status codes defined in IPP 1.0 for this class of status
         code.

         12.1.4

         13.1.4 Client Error Status Codes

         This class of status code is intended for cases in which the client
         seems to have erred.  The server SHOULD return a message containing an
         explanation of the error situation and whether it is a temporary or
         permanent condition.

         12.1.4.1

         13.1.4.1 client-error-bad-request (0x400) (0x0400)

         The request could not be understood by the server due to malformed
         syntax.  The IPP application SHOULD NOT repeat the request without
         modifications.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         12.1.4.2

         13.1.4.2 client-error-forbidden (0x401) (0x0401)

         The server understood the request, but is refusing to fulfill it.
         Additional authentication information or authorization credentials
         will not help and the request SHOULD NOT be repeated.  This status
         code is commonly used when the server does not wish to reveal exactly
         why the request has been refused or when no other response is
         applicable.

         12.1.4.3

         13.1.4.3 client-error-not-authenticated (0x402) (0x0402)

         The request requires user authentication.  The IPP client may repeat
         the request with suitable authentication information. If the request
         already included authentication information, then this status code
         indicates that authorization has been refused for those credentials.
         If this response contains the same challenge as the prior response,
         and the user agent has already attempted authentication at least once,
         then the response message may contain relevant diagnostic information.

                                 Expires April 14, 1998
         This status codes reveals more information than "client-error-
         forbidden".

         12.1.4.4
         forbidden" and "client-error-not-authenticated".

         13.1.4.4 client-error-not-authorized (0x403) (0x0403)

         The requester is not authorized to perform the request.  Additional
         authentication information or authorization credentials will not help
         and the request SHOULD NOT be repeated.  This status code is used when
         the server wishes to reveal that the authentication information is
         understandable, however, the requester is explicitly not authorized to
         perform the request.  This status codes reveals more information than
         "client-error-forbidden".

         12.1.4.5
         "client-error-forbidden" and "client-error-not-authenticated".

         13.1.4.5 client-error-not-possible (0x404) (0x0404)

         This status code is used when the request is for something that can
         not happen.  For example, there might be a request to cancel a job
         that has already been canceled or aborted by the system.  The IPP
         client SHOULD NOT repeat the request.

         12.1.4.6

         13.1.4.6 client-error-timeout (0x405) (0x0405)

         The client did not produce a request within the time that the server
         was prepared to wait.  For example, a client issued a Create-Job
         operation and then, after a long period of time, issued a Send-
         Document operation and this error status code was returned in response
         to the Send-Document request.  The server might have been forced to
         clean up resources that had been held for the waiting additional
         Documents.  The server was forced to close the Job since the client

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         took too long.  The client SHOULD NOT repeat the request without
         modifications.

         12.1.4.7

         13.1.4.7 client-error-not-found (0x406) (0x0406)

         The server has not found anything matching the request URI.  No
         indication is given of whether the condition is temporary or
         permanent.  For example, a client with an old reference to a Job (a
         URI) tries to cancel the Job, however in the mean time the Job might
         have been completed and all record of it at the Printer has been
         deleted.  This status code, 'client-error-not-found' is returned
         indicating that the referenced Job can not be found.  This error
         status code is also used when a client supplies a URI as a reference
         to the document data in either a Print-URI or Send-URI operation
         however the document can not be found.

         In practice, an IPP application should avoid a not found situation by
         first querying and presenting a list of valid Printer URIs and Job
         URIs to the end-user.

         12.1.4.8

                                 Expires April 14, 1998
         13.1.4.8 client-error-gone (0x407) (0x0407)

         The requested object is no longer available at the server and no
         forwarding address is known.  This condition should be considered
         permanent.  Clients with link editing capabilities should delete
         references to the request URI after user approval.  If the server does
         not know or has no facility to determine, whether or not the condition
         is permanent, the status code "client-error-not-found" should be used
         instead.

         This response is primarily intended to assist the task of web
         maintenance by notifying the recipient that the resource is
         intentionally unavailable and that the server owners desire that
         remote links to that resource be removed. It is not necessary to mark
         all permanently unavailable resources as "gone" or to keep the mark
         for any length of time -- that is left to the discretion of the server
         owner.

         12.1.4.9

         13.1.4.9 client-error-request-entity-too-large (0x408) (0x0408)

         The server is refusing to process a request because the request entity
         is larger than the server is willing or able to process.  An IPP
         Printer returns this status code when it limits the size of print jobs
         and it receives a print job that exceeds that limit or when the
         operation parameters
         attributes are so many that their encoding causes the request entity
         to exceed server capacity.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         12.1.4.10

         13.1.4.10 client-error-request-URI-too-long (0x409) (0x0409)

         The server is refusing to service the request because the request URI
         is longer than the server is willing to interpret.  This rare
         condition is only likely to occur when a client has improperly
         submitted a request with long query information (e.g. an IPP
         application allows an end-user to enter an invalid URI), when the
         client has descended into a URI "black hole" of redirection (e.g., a
         redirected URI prefix that points to a suffix of itself), or when the
         server is under attack by a client attempting to exploit security
         holes present in some servers using fixed-length buffers for reading
         or manipulating the Request-URI.

         12.1.4.11

         13.1.4.11 client-error-unsupported-document-format (0x40A) (0x040A)

         The server is refusing to service the request because the print document
         data is in a format, as specified in the "document-format" input
         attribute, that is not supported by the IPP Printer.

         12.1.4.12 Printer object.

                                 Expires April 14, 1998
         13.1.4.12 client-error-attribute-not-supported (0x40B) (0x040B)

         For a Create-Job, Print-Job or Validate-Job operation, if the IPP
         Printer does not support one or more attributes or attribute values
         supplied in the request, the Printer shall return this status.  For
         example, if the request indicates 'iso-a4' media, but that media type
         is not supported by the Printer.  Or, if the client supplies an
         optional attribute and the attribute itself is not even supported by
         the Printer.  If "ipp-attribute-fidelity" it is set to false, the Printer
         can ignore or substitute values for unsupported attributes and values
         rather than reject the request and return this status code. .

         For a Get-Jobs operation, if the IPP Printer does not support one of
         the requested attributes, the Printer shall return this status.

         In practice, an IPP application should avoid this situation by
         querying an IPP Printer for its valid attributes and values before
         performing an operation on the Printer.

         12.1.5

         13.1.4.13 client-error-uri-scheme-not-supported (0x040C)

         The type of the client supplied URI in a Print-URI or a Send-URI
         operation is not supported.

         13.1.4.14 client-error-charset-not-supported (0x040D)

         For any operation, if the IPP Printer does not support the charset
         supplied by the client in the "attributes-charset" operation
         attribute, the Printer SHALL reject the operation and return this
         status (see Section 3.1.3.1).

         13.1.4.15 client-error-natural-language-not-supported (0x040E)

         For any operation, if the IPP Printer does not support the natural
         language supplied by the client in the "attributes-natural-language"
         operation attribute and the implementation has chosen to reject the
         operation, the Printer SHALL return this status (see Section 3.1.3.1).

         13.1.5 Server Error Status Codes

         This class of status codes indicates cases in which the server is
         aware that it has erred or is incapable of performing the request.
         The server SHOULD include a message containing an explanation of the
         error situation, and whether it is a temporary or permanent condition.

         deBry, Hastings, Herriot, Isaacson, Powell

                                 Expires February xx, April 14, 1998
         12.1.5.1
         13.1.5.1 server-error-internal- error (0x500) (0x0500)

         The server encountered an unexpected condition that prevented it from
         fulfilling the request.  This error status code differs from "server-
         error-temporary-error" in that it implies a more permanent type of
         internal error.  It also differs from "server-error-device-error" in
         that it implies an unexpected condition (unlike a paper-jam or out-of-
         toner problem which is undesirable but expected).  This error status
         code indicates that probably some knowledgeable human intervention is
         required.

         12.1.5.2

         13.1.5.2 server-error-operation-not-supported (0x501) (0x0501)

         The server does not support the functionality required to fulfill the
         request. This is the appropriate response when the server does not
         recognize an operation or is not capable of supporting it.

         12.1.5.3

         13.1.5.3 server-error-service-unavailable (0x502) (0x0502)

         The server is currently unable to handle the request due to a
         temporary overloading or maintenance of the server.  The implication
         is that this is a temporary condition which will be alleviated after
         some delay. If known, the length of the delay may be indicated in the
         message.  If no delay is given, the IPP application should handle the
         response as it would for a "server-error-temporary-internal-error"
         response.  If the condition is more permanent, the error status codes
         "client-error-gone" or "client-error-not-found" could be used.

         12.1.5.4

         13.1.5.4 server-error-version-not-supported (0x503) (0x0503)

         The server does not support, or refuses to support, the IPP protocol
         version that was used in the request message.  The server is
         indicating that it is unable or unwilling to complete the request
         using the same version as supplied in the request other than with this
         error message. The response should contain a Message describing why
         that version is not supported and what other versions are supported by
         that server.

         A conforming IPP client shall specify the valid version (IPP 1.0)on
         each request.  A conforming IPP server (IPP 1.0) SHALL NOT return this
         status code to a conforming IPP 1.0 client.  An IPP server shall
         return this status code to a non-conforming IPP client.

         12.1.5.5

         13.1.5.5 server-error-device-error (0x504) (0x0504)

         A printer error, such as a paper jam, occurs while the IPP Printer
         processes a Print or Send operation.  The response contains the true
         Job Status (the values of the "job-state" and "job-state-reasons"

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         attributes).  Additional information "job-state" and "job-state-reasons"

                                 Expires April 14, 1998
         attributes).  Additional information can be returned in the optional
         "job-state-message" attribute value or in the OPTIONAL status message
         that describes the error in more detail.  This error status code is
         only returned in situations where the Printer is unable to accept the
         create request because of such a device error.  For example, if the
         Printer is unable to spool, and can only accept one job at a time, the
         reason it might reject a create request is that the printer currently
         has a paper jam.  In many cases however, where the Printer object can be returned in the optional
         "job-state-message" attribute value or in
         accept the OPTIONAL status code
         message that describes request even though the Printer has some error in more detail.  This error condition,
         the 'successful-ok' status code MAY will be returned even though returned.  In such a case, the operation was successful (the
         client would look at the returned Job
         was submitted and is now in Object Attributes or later query
         the 'pending' state waiting Printer to be
         processed).

         ISSUE: This doesn't seem like a good error.  If the create request
         succeeded, an OK should be returned. The job-status of printer-stopped
         gives information about the printer being stopped.

         12.1.5.6 determine its state and state reasons.

         13.1.5.6 server-error-temporary-error (0x505) (0x0505)

         A temporary error such as a buffer full write error, a memory overflow
         (i.e. the document data exceeds the memory of the Printer), or a disk
         full condition, occurs while the IPP Printer processes an operation.
         The client MAY try the unmodified request again at some later point in
         time with an expectation that the temporary internal error condition
         may have been cleared.

         deBry, Hastings, Herriot, Isaacson, Powell

                                 Expires February xx, April 14, 1998
         12.2
         13.2 Status Keywords Codes for IPP Operations

         PJ = Print-Job, PU = Print-URI, CJ = Create-Job, SD = Send-Document
         SU = Send-URI, V = Validate-Job, GA = Get-Attributes, GJ = Get-Jobs
         C = Cancel-Job

                                                        IPP Operations
         IPP Status Keyword                       PJ PU CJ SD SU V GA GJ C
         ------------------                       -- -- -- -- -- - -- -- -
         successful-OK                            x  x  x  x  x  x x  x x
         successful-ok-ignored-or-substituted-    x  x  x  x  x  x
              attributes
         client-error-bad-request                 x  x  x  x  x  x x  x x
         client-error-not-authenticated           x  x  x  x  x  x x  x x
         client-error-not-authorized              x  x  x  x  x  x x  x x
         client-error-forbidden                   x  x  x  x  x  x x  x x
         client-error-not-possible                x  x  x  x  x  x x  x x
         client-error-not-found                   x  x  x  x  x  x x  x x
         client-error-timeout                     x  x  x  x  x  x x  x x
         client-error-gone                        x  x  x  x  x  x x  x x
         client-error-request-entity-too-large    x  X  X  X  X  X X  X X
         client-error-request-URI-too-long        x  x  x  x  x  x x  x x
         client-error-unsupported-document-format x  x     x  x
         client-error-attribute-value-not-        x  x  x        x
              supported
         server-error-internal-error              x  x  x  x  x  x x  x x
         server-error-service-unavailable         x  x  x  x  x  x x  x x
         server-error-timeout                     x  x  x  x  x  x x  x x
         server-error-HTTP-version-not-supported  x  x  x  x  x  x x  x x
         server-error-IPP-version-not-supported   x  x  x  x  x  x x  x x
         server-error-device-error                x  x  x  x  x
         server-error-temporary-error             x  x  x  x  x

         13.

         14. APPENDIX C: "document-format"  "media" keyword values

         Standard keyword values are taken from several sources.

         Standard values are defined (taken from DPA[ISODPA] and the Printer
         MIB[RFC1759]):

           'default': The default medium for the output device
           'iso-a4-white': Specifies the ISO A4 white medium
           'iso-a4-colored': Specifies the ISO A4 colored medium
           'iso-a4-transparent' Specifies the ISO A4 transparent medium
           'iso-a3-white': Specifies the ISO A3 white medium
           'iso-a3-colored': Specifies the ISO A3 colored medium
           'iso-a5-white': Specifies the ISO A5 white medium

                                 Expires April 14, 1998
           'iso-a5-colored': Specifies the ISO A5 colored medium
           'iso-b4-white': Specifies the ISO B4 white medium
           'iso-b4-colored': Specifies the ISO B4 colored medium
           'iso-b5-white': Specifies the ISO B5 white medium
           'iso-b5-colored': Specifies the ISO B5 colored medium
           'jis-b4-white': Specifies the JIS B4 white medium
           'jis-b4-colored': Specifies the JIS B4 colored medium
           'jis-b5-white': Specifies the JIS B5 white medium
           'jis-b5-colored': Specifies the JIS B5 colored medium

         The Printer Working Group has registered a set of type2 enum following standard values
         with IANA as part of are defined for North American media:

           'na-letter-white': Specifies the IETF Printer MIB [1] project. North American letter white medium
           'na-letter-colored': Specifies the North American letter colored
              medium
           'na-letter-transparent': Specifies the North American letter
              transparent medium
           'na-legal-white': Specifies the North American legal white medium
           'na-legal-colored': Specifies the North American legal colored
              medium

         The symbols following standard values are defined for each value assigned by envelopes:

           'iso-b4-envelope': Specifies the PWG starts with ISO B4 envelope medium
           'iso-b5-envelope': Specifies the four letters:
         "lang", in order to follow SNMP ASN.1 rules that all enum symbols
         SHALL start with a lower case letter.  MIME types corresponding to ISO B5 envelope medium
           'iso-c3-envelope': Specifies the
         integer enum value is ISO C3 envelope medium
           'iso-c4-envelope': Specifies the ISO C4 envelope medium
           'iso-c5-envelope': Specifies the ISO C5 envelope medium
           'iso-c6-envelope': Specifies the ISO C6 envelope medium
           'iso-designated-long-envelope': Specifies the ISO Designated Long
              envelope medium
           'na-10x13-envelope': Specifies the North American 10x13 envelope
              medium
           'na-9x12-envelope': Specifies the North American 9x12 envelope
              medium
           'monarch-envelope': Specifies the Monarch envelope
           'na-number-10-envelope': Specifies the North American 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-envelope': Specifies the North American 10x14 inch
              envelope
           'na-number-9-envelope': Specifies the North American number 9
              business envelope
           'na-6x9-envelope': Specifies the North American 6x9 inch envelope

                                 Expires April 14, 1998
           'na-10x15-envelope': Specifies the North American 10x15 inch
              envelope

         The following standard values are defined for the less commonly used as
         media (white-only):

           'executive-white': Specifies the value white executive medium
           'folio-white': Specifies the folio white medium
           'invoice-white': Specifies the IPP "document-format"
         attribute.

         This APPENDIX lists white invoice medium
           'ledger-white': Specifies the document formats that are currently registered
         with IANA.

         The standard values registered as of white ledger medium
           'quarto-white': Specified the data of this document are:

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           'other': 1 -
           'langPCL': 3 - PCL.  Starting with PCL version 5, HP-GL/2 is
              included as part of white quarto medium
           'iso-a0-white': Specifies the PCL language.  PCL and HP-GL/2 are
              registered trademarks of Hewlett-Packard Company.
           'langHPGL': 4 - Hewlett-Packard Graphics Language.  HP-GL is a
              registered trademark of Hewlett-Packard Company.
           'langPJL': 5 - Peripheral Job Language.  Appears in ISO A0 white medium
           'iso-a1-white': Specifies the data stream
              between data intended for a page description language.  Hewlett-
              Packard Co.
           'langPS': 6 - PostScript Language (tm) Postscript - a trademark of
              Adobe Systems Incorporated which may be registered in certain
              jurisdictions
           'langIPDS': 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 ISO A1 white medium
           'iso-a2-white': Specifies the print process.  Pennant Systems, IBM
           'langPPDS': 8 - IBM Personal Printer Data Stream.  Originally
              called IBM ASCII, ISO A2 white medium
           'iso-a6-white': Specifies the name was changed to PPDS when ISO A6 white medium
           'iso-a7-white': Specifies the Laser
              Printer was introduced in 1989.  Lexmark International, Inc.
           'langEscapeP': 9 - Epson Corp.
           'langEpson': 10 -
           'langDDIF': 11 - Digital Document Interchange Format Digital
              Equipment Corp., Maynard MA
           'langInterpress': 12 - Xerox Corp.
           'langISO6429': 13 - ISO 6429.  Control functions for Coded
              Character Sets (has ASCII control characters, plus additional
              controls for character imaging devices.) A7 white medium
           'iso-a8-white': Specifies the ISO Standard, Geneva,
              Switzerland
           'langLineData': 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 A8 white medium
           'iso-a9-white': Specifies the ISO 10175
              Document Printing Application (DPA) A9 white medium
           'iso-10-white': Specifies the ISO standard, Geneva,
              Switzerland
           'langMODCA': 15 - Mixed Object Document Content Architecture
              Definitions that allow A10 white medium
           'iso-b0-white': Specifies 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
           'langREGIS': 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
           'langSPDL': 18 - ISO 10180 Standard Page Description Language B0 white medium
           'iso-b1-white': Specifies the ISO
              Standard

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           'langTEK4014': 19 - Tektronix Corp.
           'langPDS': 20 -
           'langIGP': 21 - Printronix Corp.
           'langCodeV': 22 - Magnum Code-V, Image and printer control language
              used to control impact/dot- matrix printers.  QMS, Inc., Mobile
              AL
           'langDSCDSE': 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
           'langWPS': 24 - Windows Printing System, Resource based
              command/data stream used by Microsoft At Work Peripherals.
              Developed by B1 white medium
           'iso-b2-white': Specifies the Microsoft Corporation.
           'langLN03': 25 - Early DEC-PPL3, Digital Equipment Corp.
           'langCCITT': 26 -
           'langQUIC': 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.
           'langCPAP': 28 - Common Printer Access Protocol Digital Equipment
              Corp
           'langDecPPL': 29 - Digital ANSI-Compliant Printing Protocol (DEC-
              PPL) Digital Equipment Corp
           'langSimpleText': 30 - simple-text: character coded data, including
              NUL, CR , LF, HT, and FF control characters.  See ISO 10175
              Document Printing Application (DPA) B2 white medium
           'iso-b3-white': Specifies the ISO standard, Geneva,
              Switzerlan
           'langNPAP': 31 - Network Printer Alliance Protocol (NPAP).  This
              protocol has been superseded by B3 white medium
           'iso-b6-white': Specifies the IEEE 1284.1 TIPSI standard.
              (ref.  LangTIPSI(49)).
           'langDOC': 32 - Document Option Commands, Appears in ISO B6 white medium
           'iso-b7-white': Specifies the data
              stream between data intended for a page description .  QMS, Inc
           'langimPress': 33 - imPRESS, Page description language originally
              developed for ISO B7 white medium
           'iso-b8-white': Specifies the ImageServer line of systems.  A binary language
              providing representations for text, simple graphics (rules,
              lines, conic sections), and some large forms (simple bit-map and
              CCITT group 3/4 encoded).The language was intended to be sent
              over an 8-bit channel and supported early document preparation
              languages (e.g.  TeX and TROFF).  QMS, Inc.
           'langPinwriter': 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
           'langNPDL': 35 - Page printer for Japanese market.  NEC
           'langNEC201PL': 36 - Serial printer language used in ISO B8 white medium
           'iso-b9-white': Specifies the Japanese
              market.  NEC
           'langAutomatic': 37 - Automatic PDL sensing.  Automatic sensing of ISO B9 white medium
           'iso-b10-white': Specifies the interpreter language family by ISO B10 white medium
           'jis-b0-white': Specifies the printer examining JIS B0 white medium
           'jis-b1-white': Specifies the
              document content.  Which actual interpreter language families are
              sensed depends on JIS B1 white medium
           'jis-b2-white': Specifies the printer implementation.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           'langPages': 38 - Page printer Advanced Graphic Escape Set IBM
              Japan
           'langLIPS': 39 - LBP Image Processing System
           'langTIFF': 40 - Tagged Image File Format (Aldus)
           'langDiagnostic': 41 - A hex dump of JIS B2 white medium
           'jis-b3-white': Specifies the input to JIS B3 white medium
           'jis-b6-white': Specifies the interpreter
           'langPSPrinter': 42 - JIS B6 white medium
           'jis-b7-white': Specifies the JIS B7 white medium
           'jis-b8-white': Specifies the JIS B8 white medium
           'jis-b9-white': Specifies the JIS B9 white medium
           'jis-b10-white': Specifies the JIS B10 white medium

         The PostScript Language used for control
              (with any PDLs) Adobe Systems Incorporated
           'langCaPSL': 43 - Canon Print Systems Language
           'langEXCL': 44 - Extended Command Language Talaris Systems Inc
           'langLCDS': 45 - Line Conditioned Data Stream Xerox Corporatio
           'langXES': 46 - Xerox Escape Sequences Xerox Corporation
           'langPCLXL': 47 - Printer Control Language.  Extended language
              features for printing, and printer control.  Technical reference
              manual # TBD.  Hewlett-Packard Co.
           'langART': 48 - Advanced Rendering Tools (ART).  Page Description
              language originally developed following standard values are defined for engineering media:

           'a': Specifies the Laser Press printers.
              Tehnical reference manual: "ART IV Reference Manual", No F33M.
              Fuji Xerox Co., Ltd.
           'langTIPSI': 49 - Transport Independent Printer System Interface
              (ref.  IEEE Std.  1284.1)
           'langPrescribe': 50 - Page description and printer control
              language.  It can be described with ordinary ASCII characters.
              Technical reference manual: "PRESCRIBE II Programming Manual"
           'langLinePrinter': 51 - engineering A simple-text character stream which
              supports size medium
           'b': Specifies 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.
           'langIDP': 52 - Imaging Device Protocol Apple Computer.
           'langXJCL': 53 - Xerox Corp.

         ISSUE: What are we going to do with 'langAutomatic (37)'?.

         14. APPENDIX D:  "media" keyword values

         Standard keyword values are taken from several sources.

         Standard engineering B size medium
           'c': Specifies the engineering C size medium
           'd': Specifies the engineering D size medium
           'e': Specifies the engineering E size medium

                                 Expires April 14, 1998
         The following standard values are defined (taken from for input-trays (from ISO DPA[5]
         DPA and the Printer
         MIB[1]):

           'default': MIB):

           'top': The default medium top input tray in the printer.
           'middle': The middle input tray in the printer.
           'bottom': The bottom input tray in the printer.
           'envelope': The envelope input tray in the printer.
           'manual': The manual feed input tray in the printer.
           'large-capacity': The large capacity input tray in the printer.
           'main': The main input tray
           'side': The side input tray

         The following standard values are defined for media sizes (from ISO
         DPA):

           'iso-a0': Specifies the output device
           'iso-a4-white': ISO A0 size: 841 mm by 1189 mm as defined
              in ISO 216
           'iso-a1': Specifies the ISO A4 white medium
           'iso-a4-colored': A1 size: 594 mm by 841 mm as defined in
              ISO 216
           'iso-a2': Specifies the ISO A2 size: 420 mm by 594 mm as defined in
              ISO 216
           'iso-a3': Specifies the ISO A3 size: 297 mm by 420 mm as defined in
              ISO 216
           'iso-a4': Specifies the ISO A4 coloured medium
           'iso-a4-transparent' size: 210 mm by 297 mm as defined in
              ISO 216
           'iso-a5': Specifies the ISO A5 size: 148 mm by 210 mm as defined in
              ISO 216
           'iso-a6': Specifies the ISO A6 size: 105 mm by 148 mm as defined in
              ISO 216
           'iso-a7': Specifies the ISO A7 size: 74 mm by 105 mm as defined in
              ISO 216
           'iso-a8': Specifies the ISO A8 size: 52 mm by 74 mm as defined in
              ISO 216
           'iso-a9': Specifies the ISO A9 size: 37 mm by 52 mm as defined in
              ISO 216
           'iso-a10': Specifies the ISO A4 transparent medium
           'iso-a3-white': Specifies the A10 size: 26 mm by 37 mm as defined in
              ISO A3 white medium
           'iso-a3-colored': 216
           'iso-b0': Specifies the ISO A3 coloured medium
           'iso-a5-white': B0 size: 1000 mm by 1414 mm as defined
              in ISO 216
           'iso-b1': Specifies the ISO A5 white medium

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           'iso-a5-colored': B1 size: 707 mm by 1000 mm as defined
              in ISO 216
           'iso-b2': Specifies the ISO A5 coloured medium
           'iso-b4-white': B2 size: 500 mm by 707 mm as defined in
              ISO 216
           'iso-b3': Specifies the ISO B4 white medium
           'iso-b4-colored': B3 size: 353 mm by 500 mm as defined in
              ISO 216
           'iso-b4': Specifies the ISO B4 coloured medium
           'iso-b5-white': size: 250 mm by 353 mm as defined in
              ISO 216

                                 Expires April 14, 1998
           'iso-b5': Specifies the ISO B5 white medium
           'iso-b5-colored': size: 176 mm by 250 mm as defined in
              ISO 216
           'iso-b6': Specifies the ISO B5 coloured medium
           'jis-b4-white': B6 size: 125 mm by 176 mm as defined in
              ISO 216
           'iso-b7': Specifies the JIS B4 white medium
           'jis-b4-colored': ISO B7 size: 88 mm by 125 mm as defined in
              ISO 216
           'iso-b8': Specifies the JIS B4 coloured medium
           'jis-b5-white': ISO B8 size: 62 mm by 88 mm as defined in
              ISO 216
           'iso-b9': Specifies the JIS B5 white medium
           'jis-b5-colored': ISO B9 size: 44 mm by 62 mm as defined in
              ISO 216
           'iso-b10': Specifies the JIS B5 coloured medium

         The following standard values are ISO B10 size: 31 mm by 44 mm as defined for North American media:

           'na-letter-white': in
              ISO 216
           'na-letter': Specifies the North American letter white medium
           'na-letter-colored': size: 8.5 inches
              by 11 inches
           'na-legal': Specifies the North American letter coloured
              medium
           'na-letter-transparent': legal size: 8.5 inches by
              14 inches
           'executive': Specifies the North American letter
              transparent medium
           'na-legal-white': executive size (7.25 X 10.5 in)
           'folio': Specifies the North American legal white medium
           'na-legal-colored': folio size (8.5 X 13 in)
           'invoice': Specifies the North American legal coloured
              medium

         The following standard values are defined for envelopes:

           'iso-b4-envelope': invoice size (5.5 X 8.5 in)
           'ledger': Specifies the ISO B4 envelope medium
           'iso-b5-envelope': ledger size (11 X 17 in)
           'quarto': Specifies the ISO B5 envelope medium
           'iso-c3-envelope': quarto size (8.5 X 10.83 in)
           'iso-c3': Specifies the ISO C3 envelope medium
           'iso-c4-envelope': size: 324 mm by 458 mm as defined in
              ISO 269
           'iso-c4': Specifies the ISO C4 envelope medium
           'iso-c5-envelope': size: 229 mm by 324 mm as defined in
              ISO 269
           'iso-c5': Specifies the ISO C5 envelope medium
           'iso-c6-envelope': size: 162 mm by 229 mm as defined in
              ISO 269
           'iso-c6': Specifies the ISO C6 envelope medium
           'iso-designated-long-envelope': size: 114 mm by 162 mm as defined in
              ISO 269
           'iso-designated-long': Specifies the ISO Designated Long
              envelope medium size: 110
              mm by 220 mm as defined in ISO 269
           'na-10x13-envelope': Specifies the North American 10x13 envelope
              medium size: 10
              inches by 13 inches
           'na-9x12-envelope': Specifies the North American 9x12 envelope
              medium
           'monarch-envelope': Specifies the Monarch envelope
           'na-number-10-envelope': Specifies the North American 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-envelope': Specifies the North American 10x14 inch
              envelope
           'na-number-9-envelope': Specifies the North American number size: 9
              business envelope
           'na-6x9-envelope': Specifies the North American 6x9 inch envelope

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           'na-10x15-envelope': Specifies the North American 10x15 inch
              envelope

         The following standard values are defined for the less commonly used
         media (white-only):

           'executive-white': Specifies the white executive medium
           'folio-white': Specifies the folio white medium
           'invoice-white': Specifies the white invoice medium
           'ledger-white': Specifies the white ledger medium
           'quarto-white': Specified the white quarto medium
           'iso-a0-white':
              inches by 12 inches
           'na-number-10-envelope': Specifies the ISO A0 white medium
           'iso-a1-white': North American number 10
              business envelope size: 4.125 inches by 9.5 inches
           'na-7x9-envelope': Specifies the ISO A1 white medium
           'iso-a2-white': North American 7x9 inch envelope
              size
           'na-9x11-envelope': Specifies the ISO A2 white medium
           'iso-a6-white': North American 9x11 inch envelope
              size
           'na-10x14-envelope': Specifies the ISO A6 white medium
           'iso-a7-white': North American 10x14 inch
              envelope size
           'na-number-9-envelope': Specifies the ISO A7 white medium
           'iso-a8-white': North American number 9
              business envelope size
           'na-6x9-envelope': Specifies the ISO A8 white medium
           'iso-a9-white': North American 6x9 envelope size
           'na-10x15-envelope': Specifies the ISO A9 white medium
           'iso-10-white': North American 10x15 envelope
              size

                                 Expires April 14, 1998
           'monarch-envelope': Specifies the ISO A10 white medium
           'iso-b0-white': Monarch envelope size (3.87 x 7.5
              in)
           'jis-b0': Specifies the ISO JIS B0 white medium
           'iso-b1-white': size: 1030mm x 1456mm
           'jis-b1': Specifies the ISO JIS B1 white medium
           'iso-b2-white': size: 728mm x 1030mm
           'jis-b2': Specifies the ISO JIS B2 white medium
           'iso-b3-white': size: 515mm x 728mm
           'jis-b3': Specifies the ISO JIS B3 white medium
           'iso-b6-white': size: 364mm x 515mm
           'jis-b4': Specifies the ISO JIS B4 size: 257mm x 364mm
           'jis-b5': Specifies the JIS B5 size: 182mm x 257mm
           'jis-b6': Specifies the JIS B6 white medium
           'iso-b7-white': size: 128mm x 182mm
           'jis-b7': Specifies the ISO JIS B7 white medium
           'iso-b8-white': size: 91mm x 128mm
           'jis-b8': Specifies the ISO JIS B8 white medium
           'iso-b9-white': size: 64mm x 91mm
           'jis-b9': Specifies the ISO JIS B9 white medium
           'iso-b10-white': size: 45mm x 64mm
           'jis-b10': Specifies the ISO B10 white medium
           'jis-b0-white': Specifies JIS B10 size: 32mm x 45mm

         15. APPENDIX D: Processing IPP Attributes

         When submitting a print job to a Printer object, the IPP model allows
         a client to supply operation and Job Template attributes along with
         the document data.  These Job Template attributes in the create
         request affect the rendering, production and finishing of the
         documents in the JIS B0 white medium
           'jis-b1-white': Specifies job.  Similar types of instructions may also be
         contained in the JIS B1 white medium
           'jis-b2-white': Specifies document to be printed, that is, embedded within the JIS B2 white medium
           'jis-b3-white': Specifies
         print data itself.  In addition, the JIS B3 white medium
           'jis-b6-white': Specifies Printer has a set of attributes
         that describe what rendering and finishing options which are supported
         by that Printer.  This model, which allows for flexibility and power,
         also introduces the JIS B6 white medium
           'jis-b7-white': Specifies potential that at job submission time, these
         client-supplied attributes may conflict with either:

           - what the JIS B7 white medium
           'jis-b8-white': Specifies implementation is capable of realizing (i.e., what the JIS B8 white medium
           'jis-b9-white': Specifies
              Printer supports), as well as
           - the JIS B9 white medium
           'jis-b10-white': Specifies instructions embedded within the JIS B10 white medium print data itself.

         The following standard values sections describe how these two types of conflicts are defined for engineering media:

           'a': Specifies
         handled in the engineering A size medium
           'b': Specifies IPP model.

         15.1 Fidelity

         If there is a conflict between what the engineering B size medium
           'c': Specifies client requests and what a
         Printer supports, the engineering C size medium
           'd': Specifies client may request one of two possible conflict
         handling mechanisms:

           1) either reject the engineering D size medium
           'e': Specifies job since the engineering E size medium

         deBry, Hastings, Herriot, Isaacson, Powell job can not be processed exactly
              as specified, or
           2) allow the Printer to make any changes necessary to proceed with
              processing the Job the best it can.

                                 Expires February xx, April 14, 1998
         The following standard values are defined for input-trays (from ISO
         DPA
         In the first case the client is indicating to the Printer: "Print the
         job exactly as specified with no exceptions, and if that can't be
         done, don't even bother printing the Printer MIB):

           'top': The top input tray in job at all." In the printer.
           'middle': The middle input tray in second case,
         the printer.
           'bottom': The bottom input tray in client is indicating to the printer.
           'envelope': The envelope input tray in Printer: "It is more important to make
         sure the printer.
           'manual': The manual feed input tray in job is printed rather than be processed exactly as specified;
         just make sure the printer.
           'large-capacity': job is printed even if client supplied attributes
         need to be changed or ignored."

         The large capacity input tray in IPP model accounts for this situation by introducing an "ipp-
         attribute-fidelity" attribute.

         In a create request, "ipp-attribute-fidelity" is a boolean attribute
         that is OPTIONALLY supplied by the printer.
           'main': The main input tray
           'side': The side input tray client.  The following standard value 'true' indicates
         that total fidelity to client supplied attributes and values are defined for media sizes (from ISO
         DPA):

           'iso-a0': Specifies is
         required.  The client is requesting that the ISO A0 size: 841 mm by 1189 mm Job be printed exactly as defined
              in ISO 216
           'iso-a1': Specifies
         specified, and if that is not possible then the ISO A1 size: 594 mm by 841 mm as defined in
              ISO 216
           'iso-a2': Specifies job must be rejected
         rather than processed incorrectly.  The value 'false' indicates that a
         reasonable attempt to print the ISO A2 size: 420 mm by 594 mm as defined in
              ISO 216
           'iso-a3': Specifies Job is acceptable.  If a Printer does
         not support some of the ISO A3 size: 297 mm by 420 mm as defined in
              ISO 216
           'iso-a4': Specifies client supplied Job Template attributes or
         values, the ISO A4 size: 210 mm by 297 mm as defined in
              ISO 216
           'iso-a5': Specifies Printer may ignore them or substitute any supported value
         for unsupported values.  The Printer may choose to substitute the ISO A5 size: 148 mm by 210 mm as defined in
              ISO 216
           'iso-a6': Specifies
         default value associated with that attribute, or use some other
         supported value that is similar to the ISO A6 size: 105 mm by 148 mm as defined in
              ISO 216
           'iso-a7': Specifies unsupported requested value.
         For example, if a client supplies a "media" value of 'na-letter', the ISO A7 size: 74 mm by 105 mm as defined in
              ISO 216
           'iso-a8': Specifies
         Printer may choose to substitute 'iso-a4' rather than a default value
         of 'envelope'.  Since this is an OPTIONAL attribute, if the ISO A8 size: 52 mm by 74 mm as defined in
              ISO 216
           'iso-a9': Specifies client
         does not supply a value, the ISO A9 size: 37 mm by 52 mm as defined in
              ISO 216
           'iso-a10': Specifies Printer assumes a value of 'false'.

         Each Printer implementation MUST support both types of "fidelity"
         printing (that is whether the client supplies a value of 'true' or
         'false').  This is possible across all types of implementations, since
         there is a broad range of acceptable actions when substituting or
         ignoring unsupported attributes and values.  Also, even if the ISO A10 size: 26 mm by 37 mm as defined in
              ISO 216
           'iso-b0': Specifies client
         supplies a value of 'false', a Printer might still reject the ISO B0 size: 1000 mm by 1414 mm as defined
              in ISO 216
           'iso-b1': Specifies Job for
         any reason including an unsupported attributes and/or values.  In the ISO B1 size: 707 mm by 1000 mm as defined
              in ISO 216
           'iso-b2': Specifies
         other case, where the ISO B2 size: 500 mm by 707 mm as defined in
              ISO 216
           'iso-b3': Specifies client requests a value of 'true', it is
         expected that the ISO B3 size: 353 mm by 500 mm as defined in
              ISO 216
           'iso-b4': Specifies Printer support this type of printing since the ISO B4 size: 250 mm by 353 mm as defined in
              ISO 216

         deBry, Hastings, Herriot, Isaacson, Powell
         Printer is already indicating functional support corresponding to all
         advertised supported attributes and values.

         Since a client can always query a Printer to find out exactly what is
         and is not supported, "ipp-attribute-fidelity" set to 'false' is
         useful when:

           1) The End-User uses a command line interface to request attributes
              that might not be supported.

                                 Expires February xx, April 14, 1998
           '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
           2) In a GUI context, if the ISO B8 size: 62 mm by 88 mm as defined in
              ISO 216
           'iso-b9': Specifies End User expects the ISO B9 size: 44 mm by 62 mm as defined job might be moved
              to another printer and prefers a sub-optimal result to nothing at
              all.
           3) The End User just wants something reasonable in
              ISO 216
           'iso-b10': Specifies lieu of nothing
              at all.

         15.2 Page Description Language (PDL) Override

         If there is a conflict between the ISO B10 size: 31 mm by 44 mm as defined value of an IPP Job Template
         attribute and a corresponding instruction in
              ISO 216
           'na-letter': Specifies the North American letter size: 8.5 inches
              by 11 inches
           'na-legal': Specifies the North American legal size: 8.5 inches by
              14 inches
           'executive': Specifies the executive size (7.25 X 10.5 in)
           'folio': Specifies the folio size (8.5 X 13 in)
           'invoice': Specifies document data, the invoice size (5.5 X 8.5 in)
           'ledger': Specifies
         value of the ledger size (11 X 17 in)
           'quarto': Specifies IPP attribute SHOULD take precedence over the quarto size (8.5 X 10.83 in)
           'iso-c3': Specifies document
         instruction.  Consider the ISO C3 size: 324 mm by 458 mm as defined in
              ISO 269
           'iso-c4': Specifies case where a previously formatted file of
         document data is sent to an IPP Printer.  In this case, if the ISO C4 size: 229 mm by 324 mm as defined in
              ISO 269
           'iso-c5': Specifies client
         supplies any attributes at job submission time, the ISO C5 size: 162 mm by 229 mm as defined in
              ISO 269
           'iso-c6': Specifies client desires
         that those attributes override the ISO C6 size: 114 mm by 162 mm as defined in
              ISO 269
           'iso-designated-long': Specifies embedded instructions.  Consider
         the ISO Designated Long size: 110
              mm by 220 mm as defined case were a previously formatted document has embedded in ISO 269
           'na-10x13-envelope': Specifies the North American 10x13 size: 10
              inches by 13 inches
           'na-9x12-envelope': Specifies it
         commands to load 'iso-a4' media.  However, the North American 9x12 size: 9
              inches by 12 inches
           'na-number-10-envelope': Specifies document is passed to
         an end user that only has access to a printer with 'na-letter' media
         loaded.  That end user most likely wants to submit that document to an
         that IPP Printer with the North American number 10
              business envelope size: 4.125 inches by 9.5 inches
           'na-7x9-envelope': Specifies "media" Job Template attribute set to 'na-
         letter'.  The job submission attribute should take precedence over the North American 7x9 inch envelope
              size
           'na-9x11-envelope': Specifies
         embedded PDL instruction.  However, until companies that supply
         document data interpreters allow a way for external IPP attributes to
         take precedence over embedded job production instructions, a Printer
         might not be able to support the North American 9x11 inch envelope
              size
           'na-10x14-envelope': Specifies semantics that IPP attributes
         override the North American 10x14 inch
              envelope size
           'na-number-9-envelope': Specifies embedded instructions.

         The IPP model accounts for this situation by introducing a "pdl-
         override-supported" attribute.

         This MANDATORY attribute takes on the North American number 9
              business envelope size
           'na-6x9-envelope': Specifies following values:

           - 'attempted': This value indicates that the North American 6x9 envelope size
           'na-10x15-envelope': Specifies Printer attempts to
              make sure that IPP attribute values take precedence over embedded
              instructions in the North American 10x15 envelope
              size

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           'monarch-envelope': Specifies document data, however there is no guarantee.
           - 'not-attempted': This value indicates that the Monarch envelope size (3.87 x 7.5
              in)
           'jis-b0': Specifies Printer makes not
              attempt to ensure that IPP attribute values take precedence over
              embedded instructions in the JIS B0 size: 1030mm x 1456mm
           'jis-b1': Specifies document data.

         At job processing time, an implementation that supports the JIS B1 size: 728mm x 1030mm
           'jis-b2': Specifies value of
         'attempted' might try to do one of several different actions:

           1) generate an output device specific command sequence to realize
              the JIS B2 size: 515mm x 728mm
           'jis-b3': Specifies feature represented by the JIS B3 size: 364mm x 515mm
           'jis-b4': Specifies IPP attribute value
           2) parse the JIS B4 size: 257mm x 364mm
           'jis-b5': Specifies document data itself and replace the JIS B5 size: 182mm x 257mm
           'jis-b6': Specifies conflicting
              embedded instruction with a new embedded instruction that matches
              the JIS B6 size: 128mm x 182mm
           'jis-b7': Specifies intent of the JIS B7 size: 91mm x 128mm
           'jis-b8': Specifies IPP attribute value

                                 Expires April 14, 1998
           3) indicate to the JIS B8 size: 64mm x 91mm
           'jis-b9': Specifies Printer that external supplied attributes take
              precedence over embedded instructions and then pass the JIS B9 size: 45mm x 64mm
           'jis-b10': Specifies external
              IPP attribute values to the JIS B10 size: 32mm x 45mm

         15. APPENDIX E: Processing document data interpreter
           4) anything else that allows for the semantics that IPP Attributes

         When submitting attributes
              override embedded document data instructions.

         Since 'attempted' does not offer any type of guarantee, even though a print
         given implementation might not do a very "good" job of attempting to an IPP Printer, the
         ensure that IPP model allows a
         client to supply operation and Job Template attributes along with the
         print data.  These Job Template attributes in the create request
         affect the rendering, production and finishing of the documents in the
         job.  Similar types of take a higher precedence over instructions may also be contained
         embedded in the document to data, it would still be printed, that is, embedded within a conforming
         implementation.

         Note:  The "ipp-attribute-fidelity" attribute applies to the print data
         itself. Printer's
         ability to either accept or reject other unsupported attributes.  In addition, the Printer has a
         other words, if "ipp-attribute-fidelity" is set of to 'true', a Job is
         accepted if and only if the client supplied attributes that
         describe what rendering and finishing options which values are
         supported by
         that Printer.  This model, which allows for flexibility and power,
         also introduces the potential that at job submission time, Printer.  Whether these
         client-supplied attributes may conflict with either:

           - what actually affect
         the implementation is capable processing of the Job depends on the ability of realizing (i.e., what the Printer supports), as well as
           - to
         override the instructions embedded within in the print document data itself.

         The following sections describe how these two types with the
         semantics of conflicts are
         handled in the IPP model.

         15.1 Fidelity attributes.  If there is a conflict between what the client requests and what a document data attributes can
         be overridden ("pdl-override-supported" set to 'attempted'), the
         Printer supports, makes an attempt to use the client may request one of two possible conflict
         handling mechanisms:

           1) either reject IPP attributes when processing the job since
         Job. If the job document data attributes can not be processed exactly
              as specified, or
           2) allow overridden ("pdl-
         override-supported" set to 'not-attempted'), the Printer makes no
         attempt to make any changes necessary to proceed with use the IPP attributes when processing the Job, and hence,
         the IPP attributes may fail to affect the Job processing and output in
         any manner whatsoever.

         15.3 Suggested Operation Processing Algorithm

         When a Printer receives a create request, the best it can.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         In Printer either accepts
         or rejects the first case request. The Printer accepts the client create request and
         creates a Job object if it is indicating able to accept all Job Template and
         Document attributes in the Printer: "Print request.  The Printer rejects the
         job exactly as specified with no exceptions, request
         and does not create a Job object if that can't be
         done, don't even bother printing the job at all." In the second case, the client is indicating to Printer rejects any Job
         Template or Document attribute in the Printer: "It is more important request.  In order to make
         sure the job is printed rather than be processed exactly as specified;
         just make sure the job is printed even if client supplied attributes
         need determine
         whether or not to be changed accept or ignored."

         The IPP model accounts for this situation by introducing an "ipp-
         attribute-fidelity" attribute.

         In a create reject the request, "ipp-attribute-fidelity" is a boolean attribute
         that is OPTIONALLY supplied by the client. Printer SHOULD use
         the following algorithm:

           1. The value 'true' indicates
         that total fidelity implementation checks to client supplied attributes and values is
         required.  The client is requesting that the Job be printed exactly as
         specified, and see if that the operation is not possible then supported.
              If not, the job must be rejected
         rather than processed incorrectly. Printer rejects the request and sets the appropriate
              status code in the response.

           2. The value 'false' indicates that a
         reasonable attempt implementation checks to print see if the Job requested major version
              number is acceptable. supported. If a not, the Printer does
         not support some of rejects the client supplied Job Template attributes or
         values, request and
              sets the Printer may ignore them or substitute any supported value
         for unsupported values.  The Printer may choose to substitute appropriate status code in the
         default value associated with that attribute, or use some other response.  Differences in
              the minor version number requested versus what is supported value that is similar to OK

                                 Expires April 14, 1998
              if  a.) the unsupported requested value.
         For example, if a client supplies a "media" value of 'na-letter', version number has the same Major version
              number and the minor version number is higher than supported by
              the Printer may choose object, and b.) any attributes that are not known to substitute 'iso-a4' rather than a default value
              the recipient of 'envelope'.  Since this is an OPTIONAL attribute, the operation can be ignored (i.e., if the client
         does not supply a value, "ipp-
              attribute-fidelity" attribute has the Printer assumes a value of 'false'.

         Each Printer 'false'.)

           3. The implementation MUST support both types of "fidelty"
         printing (that is whether checks to see if the client supplies a value of 'true' or
         'false').  This is possible across all types of implementations, since
         there supplied an "ipp-
              attribute-fidelity" attribute.  If the attribute is a broad range of acceptable actions when substituting or
         ignoring unsupported attributes and values.  Also, even missing (not
              supplied by the client), the Printer assumes that the value is
              'false'.

           4.  The Printer loops through all other attributes, checking to see
              if the client
         supplies a requested values are supported (e.g., the value of 'false', a Printer might still reject "foo"
              in the Job for
         any reason including an unsupported attributes and/or values.  In request is one of the
         other case, where values in the client requests a Printer's "foo-
              supported" attribute).  If the attribute or its value of 'true', it is
         expected that
              unsupported, the Printer support this type of printing since flags it as unsupported.

           5. Once all attributes have been checked individually, the Printer is already indicating functional support corresponding to
              checks for any inconsistent values among all
         advertised the supported attributes and
              values.

         Since a client can always query  For example a Printer might be able to find out exactly what is staple and is not supported, "ipp-attribute-fidelity" set to 'false' is
         useful when:

           1) The End-User uses a command line interface
              print on transparencies, however due to request attributes
              that might not be supported.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           2) In a GUI context, if the End User expects physical stapling
              limitations, the job Printer might not be moved able to another printer staple
              transparencies.  Any inconsistent values are flagged as
              unsupported.

           6.  Once all attributes have been checked and prefers a sub-optimal result validated, if "ipp-
              attribute-fidelity" is set to nothing at
              all.
           3) The End User just wants something reasonable in lieu of nothing
              at all.

         15.2 Page Description Language (PDL) Override

         If true and there is a conflict between are any attributes
              flagged as unsupported, the value of an IPP Job Template
         attribute Printer rejects the request and a corresponding instruction
              returns all unsupported attributes and values in the print data, it response and
              sets the appropriate status code.

           7. If "ipp-attribute-fidelity" is
         desirable set to 'false' (or it was not
              supplied by the client) and there are any attributes that are
              flagged as unsupported, the value of Printer, chooses to either ignore the IPP attribute take precedence over
              unsupported attributes or change the
         document instruction.  Consider requested value to some
              supported value.  If, for some reason, it is not possible for the case where a previously formatted
         file of
              implementation to ignore or substitute values and is unable to
              "just print data the job", the Printer is sent still able to an IPP Printer.  In this case, if reject the
         client supplies any
              request and return all unsupported attributes at job submission time, and values in the client
         desires that those attributes override
              response.  In doing so, the embedded instructions.
         Consider Printer sets the case were a previously formatted document has embedded in
         it commands to load 'iso-a4' media.  However, appropriate status
              code.

           8a. If the document requested operation is passed
         to an end user that only has access to a printer with 'na-letter'
         media loaded.  That end user most likely wants to submit that document
         to an that IPP Printer with the "media" Job Template attribute set to
         'na-letter'.  The job submission Validate-Job operation and a
              "document-uri" attribute should take precedence over is supplied in the request, then the
              "document-uri" is validated as specified in section 3.2.3,
              Validate-Job Operation. If the embedded PDL instruction.  However, until companies that supply
         interpreters for print data allow a way for external IPP attributes to
         take precedence over embedded job production instructions, a Printer
         might not be is able to support accept the semantics that IPP attributes
         override
              request and the embedded instructions.

         The IPP model accounts for this situation by introducing validation of any "document-uri" succeeded, then
              the Printer object returns the status code "successful-ok".

                                 Expires April 14, 1998
              Otherwise, it returns a "pdl-
         override-supported" attribute.

         This attribute takes on set of unsupported attributes and/or the following values:

           - 'attempted': This value indicates that
              appropriate error status code. In either case the Printer attempts to
              make sure that IPP attribute values take precedence over embedded
              instructions in processing of
              the Print data, however there operation is completed and no guarantee.
           - 'not-attempted': This value indicates that objects are created.

           8b. The operation is a create request. If the Printer makes not
              attempt is able to ensure that IPP attribute values take precedence over
              embedded instructions in
              accept the print data.

         This create request (either as is a MANDATORY Printer attribute.

         At job processing time, an implementation that supports or  the value of
         'attempted' might try "ipp-attribute-
              fidelity" attribute is set to do one 'false' and some of several different actions:

           1) generate an output device specific command sequence to realize the feature represented by requested
              attributes can be ignored or have their values substituted), then
              the IPP attribute value

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           2) parse Printer creates a new Job object . The Job object is
              populated with those Job Template attributes from the print data itself and replace create
              request that the conflicting embedded
              instruction Printer object can honor. If the "ipp-attribute-
              fidelity" attribute is set to 'true', the Job Template attributes
              associated with a the new embedded instruction that matches Job object are necessarily all the Job
              Template attributes in the
              intent of accepted create request.  If the IPP "ipp-
              attribute-fidelity" attribute value
           3) indicate is set to 'false', the Printer that external Job Template
              attributes associated with the new Job object are all the client
              supplied Job Template attributes take
              precedence over embedded instructions and then pass that are not ignored and/or have
              no value substitution. Thus, some of the requested Job Template
              attributes may not appear in the Job object because the external IPP attribute values
              processor was not able to the print data interpreter
           4) anything else honor those attributes. The attributes
              that allows for were honored are persistently stored with the semantics Job object for
              that IPP Job.  A Get-Attributes operation on that Job object will
              return only those attributes
              override embedded print data instructions.

         Since 'attempted' does not offer any type of guarantee, even though a
         given implementation might not do that a very "good" job of attempting persistently stored with the
              Job object.

           Note: All Job Template attributes that are persistently stored with
              the Job object are intended to
         ensure be "override values"; that is,
              they that IPP attributes take a higher precedence over instructions whatever other embedded
              instructions might be in the print data, document data itself.  However, it would still be a conforming
         implementation.

         Note:  The "ipp-attribute-fidelity" attribute applies
              is not possible for all implementations to realize the semantics
              of "override". End users may query the Printer's
         ability "pdl-override"
              attribute to determine if the Printer either accept attempts or reject other unsupported attributes.  In
         other words, if "ipp-attribute-fidelity" is set does not
              attempt to 'true', override document data instructions with IPP
              attributes.

           9. There are some cases, where a Job is
         accepted if and only if the client supplied attributes Printer supports a Job Template
              attribute and values are
         supported by has an associated default value set for that
              attribute. In the Printer.  Whether these attributes actually affect case where a client does not supply the processing of
              corresponding attribute, the Printer does not use its default
              values to populate Job depends on attributes when creating the ability of new Job
              object; only Job Template attributes actually in the Printer create
              request are used to
         override populate the instructions Job object. The Printer's
              default values are only used at Job processing time if no other
              IPP attribute or instruction embedded in the print document data with the
         semantics of the IPP attributes. is
              present.

           Note: If the print data default values associated with un-requested Job
              Template attributes can be
         overridden ("pdl-override-supported" set were used to 'attempted'), populate the Job object, then

                                 Expires April 14, 1998
              these values would become "override values" rather than defaults.
              If the Printer
         makes an attempt to use supports the IPP attributes when processing 'attempted' value of the Job. If "pdl-
              override" attribute, then these override values could replace
              values specified within the print data attributes can document data. This is not be overridden ("pdl-override-
         supported" set to 'not-attempted'), the Printer makes no attempt to
         use the IPP attributes when processing the Job, and hence, intent
              of the IPP
         attributes may fail to affect default value mechanism. A default value for an attrbute
              SHALL be used only if the Job processing and output in any
         manner whatsoever.

         15.3 Suggested Attribute Processing Algorithm

         When a Printer receives a create request, request did not specify that
              attribute (or it was ignored when allowed by "ipp-attribute-
              fidelity" being 'false') and no value was provided within the Printer either accepts
         or rejects
              content of the request. The Printer accepts document data.

           10. If the create request and
         creates client does not supply a Job object if it is able to accept all value for some Job Template
              attribute, and
         Document attributes in the request.  The Printer rejects the request
         and does not create a Job object if support that attribute, as
              far as IPP is concerned, the Printer rejects any result of processing that Job
         Template or Document attribute in the request.  In order to determine
         whether or not (with
              respect to accept or reject the request, missing attribute) is undefined.

           11. Once the Printer SHOULD use Job object has been created, the following algorithm:

           1. The implementation checks Printer responds back
              to see if the operation is supported.
              If not, client with a successful response including Job status
              attributes that indicate the Printer rejects initial state of the request Job ('pending',
              'processing', etc.).  The Printer uses its own configuration and sets
              implementation specific algorithms for scheduling the appropriate
              status code Job in the response.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           2. The implementation checks to see if the requested version is
              supported. If not,
              correct processing order.  Once the Printer rejects begins processing the request and sets
              Job, the
              appropriate status code in Printer changes the response.

           3. The implementation checks Job's state to see if the client supplied an "ipp-
              attribute-fidelity" attribute. 'processing'. If the attribute is missing (not
              supplied by the client), the
              Printer assumes that supports PDL override (the "pdl-override" attribute set
              to 'attempted'), the value is
              'false'.

           4.  The Printer loops through all other attributes, checking implementation does its best to see
              if the requested values are supported (e.g., the value of "foo" that IPP
              attributes take precedence over embedded instructions in the request is one
              document data.

           12. The implementation of the values in Printer object continues to process
              the Printer's "foo-
              supported" attribute).  If Job until it can move the attribute or its value Job into the 'completed' state.  If
              an Cancel-Job operation is
              unsupported, received, the Printer flags it as unsupported.

           5. Once all attributes have been checked individually, implementation
              eventually moves the Printer
              checks for any inconsistent values among all Job into the supported
              values.  For example a Printer might be able to staple and to
              print on transparencies, however due to physical stapling
              limitations, 'cancelled' state.  If the Printer might
              system encounters errors during processing that do not be able to staple
              transparencies.  Any inconsistent values are flagged as
              unsupported.

           6.  Once all attributes have been checked and validated, if "ipp-
              attribute-fidelity" is set allow it
              to true and there are any attributes
              flagged as unsupported, progress the Printer rejects Job into a completed state, the request and
              returns implementation
              halts all unsupported attributes processing, cleans up any resources, and values in moves the response and
              sets Job
              into the appropriate status code.

           7. If "ipp-attribute-fidelity" is set 'aborted' state.

           13. Once the Job moves to 'false' (nor the 'completed', 'aborted', or 'canceled'
              state, it was not
              supplied by is an implementation decision as to when to destroy the client)
              Job object and there are any attributes that are
              flagged as unsupported, release all associated resources.  Once the Printer, chooses to Job
              has been destroyed, the Printer would return either ignore the
              unsupported attributes "not-
              found" or change the requested value to some
              supported value.  If, for some reason, it is not possible "gone" status codes for the
              implementation operations directed at that
              Job.

         Some Printer implementations may support "ipp-attribute-fidelity" set
         to ignore or substitute values 'true' and is unable "pdl-override" set to
              "just print the job", the Printer is 'attempted' and yet still not be
         able to reject realize exactly what the
              request and return all unsupported attributes and values client specifies in the
              response.  In doing so, create
         request.  This is due to legacy decisions and assumptions that have
         been made about the Printer sets role of job instructions embedded within the appropriate status
              code.

           8. If

                                 Expires April 14, 1998
         document data and external job instructions that accompany the Printer is able
         document data and how to accept the request (either as handle conflicts between such instructions.
         The inability to be 100% precise about how a given implementation will
         behave is or also compounded by
              making changes and the fact that the two special attributes,
         "ipp-attribute-fidelity" attribute is set and "pdl-override", apply to 'false'), the Printer creates a new whole job
         rather than specific values for each attribute. For example, some
         implementations may be able to override almost all Job object with the
              remaining valid Template
         attributes except for "number-up".

         15.4 Using Job Template attributes.  Initially it sets Attributes During Document Processing.

         The Printer object uses some of the
              Job's state to 'pending'.  These Job object's Job Template
         attributes are
              associated with during the Job object.  All attributes which are processing of the document data associated with the Job object are intended to be override values
         that take precedence over whatever other embedded instructions

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              might be job.  These include, but are not limited to, "orientation",
         "number-up", "sides", "media", and "copies".  The processing of each
         document in a Job Object SHALL follow the print data itself.  That is, IPP allows for
              submission time algorithm below. This
         algorithm is intended only to identify when and how attributes are to take precedence over static
              instructions embedded
         be used in processing document data and any algorithm that
         accomplishes the print data.  These submission time
              attributes are persistently stored with the Job.  However, it is
              not possible for all implementations same effect can be used to realize implement this
         specification.

           1. Using the semantics "document-format" attribute or some form of
              "override".  End users may query format
              detection algorithm (if the Printer's "pdl-override"
              attribute to value of "document-format" is not
              specific enough), determine if the Printer either attempts whether or does not
              attempt to override print the document data instructions with IPP attributes.

           9. There are some cases, where a Printer supports a Job Template
              attribute and has an associated default value set
              already been formatted for that
              attribute.  In the case where a client does not supply printing. If the
              corresponding attribute, document data has
              been formatted, then goto step 2. Otherwise, the Printer does document data
              SHALL be formatted. The formatting algorithm is implementation
              defined and is not use its default
              values to populate Job attributes when creating the new Job
              object. specified by this specification. The Printer's default values are used at Job processing
              time where no other IPP attribute or instruction embedded in
              formatting of the
              print document data is present.  Suppose uses the Printer were "orientation" attribute
              to associate the
              Printer's default value with determine how the Job at creation time formatted print data is place on a print-
              stream page, see section 4.2.15 for an
              attribute not supplied by the client.  This would change it from
              a default value to an override value.  A later query of details.

           2. The document data is in the Job
              object would return form of a print-stream in a known
              media type. The "page-range" attribute is used to select, as
              specified in section 4.2.14, a set sub-sequence of attributes.  Neither the Printer nor pages in the end user would
              print-stream that are to be able processed and images.

           3. The input to tell the difference between an
              attribute that this step is an "override PDL" attribute supplied by the
              client or a "default value" attribute supplied sequence of print-stream pages. This
              step is controlled by the printer.

           10. "number-up" attribute. If the client does not supply a value for some Job Template
              attribute, and of
              "number-up" is N, then during the Printer processing of the print-stream
              pages, each N print-stream pages are positioned, as specified in
              section 4.2.8, to create a single imposed page. If a given
              Document Object does not support that attribute, as
              far as IPP is concerned, have N more print-stream pages, then the result
              completion of processing that Job (with
              respect to the missing attribute) imposed page is undefined.

           11. Once the Job object has been created, the Printer responds back
              to controlled by the client with a successful response including Job status
              attributes that indicate "multiple-
              document-handling" attribute as described in section 4.2.6; when
              the initial state value of this attribute is 'separate-documents-collated-

                                 Expires April 14, 1998
              copies', the Job ('pending',
              'processing', etc.). document data from subsequent Document Objects is
              used to complete the imposed page.

           The Printer uses its own configuration size(scaling), position(translation) and
              implementation specific algorithms for scheduling rotation of the Job in print-
              stream pages on the
              correct processing order.  Once imposed page is implementation defined. Note
              that during this process the Printer begins processing print-stream pages may be rendered
              to a form suitable for placing on the
              Job, imposed page; this
              rendering is controlled by the Printer changes values of the Job's state to 'processing'.  The
              Printer monitors all Jobs "printer-resolution"
              and notifies the intended recipients
              for each event by processing "print-quality" attributes as described in sections 4.2.10
              and 4.2.11. In the all of case N=1, the "notify-events" and
              "notify-addresses" Job attributes.  If imposed pages are nearly the Printer supports PDL
              override (the "pdl-override" attribute set to 'attempted'),
              same as the
              implementation does its best to see that IPP attributes take
              precedence over embedded instructions print-stream pages; the differences would only be in
              the print data.

           12. The implementation size, position and rotation of the Printer object continues print-stream page and/or
              any decoration, such as a frame to process
              the Job until it can move the Job into the 'completed' state.  If
              an Cancel-Job operation page, that is received, the implementation
              eventually moves added by the Job into
              implementation.

           4. The collection of imposed pages is placed, in sequence, onto
              sides of the 'cancelled' state.  If print media. This placement is controlled by the

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              system encounters errors during processing that do not allow it
              to progress
              "sides" attribute and the Job into a completed state, orientation of the implementation
              halts all processing, cleans up any resources, and moves page, as described
              in section 4.2.9. The orientation of the Job
              into page is defined by the 'aborted' state.

           13. Once
              orientation of the Job moves to imposed pages; for example, if "number-up"
              equals 2, then, typically, two portrait print-stream pages become
              one landscape imposed page. Note that the 'completed', 'aborted', or
              'cancelled' state, it placement of imposed
              pages onto media instances is an implementation decision also controlled by the "multiple-
              document-handling" attribute as described in section 4.2.6.

           5. The "copies" and "multiple-document-handling" attributes are
              used to when to
              destroy the Job object determine how many copies of each media instance are
              created and release all associated resources.
              Once in what order. See sections 4.2.6 and 4.2.13 for the Job has been destroyed,
              details.

           6. When the correct number of copies are created, the Printer would return either media
              instances are finished according to the "not-found" or "gone" status codes for operations directed at values of the
              "finishings" attribute as described in 4.2.12. Note that Job.

         Some Printer implementations
              sometimes finishing operations may support "ipp-attribute-fidelity" set require manual intervention to 'true' and "pdl-override" set
              perform the finishing operations on the copies, especially
              uncollated copies. This specification allows any or all of the
              processing steps to 'attempted' and yet still not be
         able to realize exactly what performed automatically or manually at the client specifies in
              discretion of the create
         request. Printer object.

         16. APPENDIX E: Generic Directory Schema

         This section defines a generic schema for an entry in a directory
         service.  A directory service is due to legacy decisions and assumptions a means by which service users can
         locate service providers.  In IPP environments, this means that have
         been made about IPP
         Printers can be registered (either automatically or with the role help of job instructions embedded within
         an administrator) as entries of type printer in the print
         data and external job instructions that accompany directory.  IPP
         clients can search or browse for entries of type printer.  Clients use
         the print data directory service to find entries based on naming, organizational

                                 Expires April 14, 1998
         contexts, or filtered searches on attribute values of entries.  For
         example, a client can find all printers in the "Local Department"
         context. Authentication and
         how authorization are also often part of a
         directory service so that an administrator can place limits on end
         users so that they are only allowed to handle conflicts between such instructions.  The inability find entries to
         be 100% precise about how a given implementation will behave which they have
         certain access rights.  IPP itself does not require any specific
         directory service protocol or provider.

         The generic schema is also
         compounded by a subset of IPP Printer attributes (section
         4.4).  These attributes are identified as either MANDATORY or OPTIONAL
         for the fact that entry itself.  This conformance labeling is NOT the two special attributes, "ipp-
         attribute-fidelity" and "pdl-override", apply same
         conformance labeling applied to the whole job rather
         than specific values for attributes of IPP Printers
         themselves.  MANDATORY attributes MUST be associated with each attribute. For example, some
         implementations may
         directory entry.  OPTIONAL attributes SHOULD be able to override almost associated with the
         directory entry (if known or supported).  In addition, all Job Template directory
         entry attributes except for "number-up". It would only make SHOULD reflect the IPP model
         more complex (with relatively little added value) to allow for
         additional special attributes that apply uniquely to each Job Template current attribute or even specific values for the
         corresponding Printer object.

         In order to bridge between the directory service protocol and IPP, one
         of each the MANDATORY attributes is the "printer-uri" attribute.

         16. APPENDIX F: Relationship to SNMP MIBs  The IPP model is related to the
         client addresses an IPP Printer MIB [??] in using its URI and so the following
         ways:

         ISSUE: TBS.

         The IPP model is related to directory
         entry's "printer-uri" becomes the Job Monitoring MIB [??] in link between the directory entry and
         the corresponding IPP Printer.

         The following ways:

         ISSUE: TBS

         deBry, Hastings, Herriot, Isaacson, Powell attributes define the generic schema for directory
         entries of type printer:

           printer-uri                      MANDATORY      Section 4.4.1
           printer-tls-uri                  OPTIONAL       Section
           printer-name                     OPTIONAL       Section 4.4.2
           printer-location                 OPTIONAL       Section 4.4.3
           printer-info                     OPTIONAL       Section 4.4.4
           printer-more-info                OPTIONAL       Section 4.4.5
           printer-make-and-model           OPTIONAL       Section 4.4.7
           security-mechanisms-supported    MANDATORY      Section 4.4.23
           media-supported                  OPTIONAL       Section 4.2.5
           number-up-supported              OPTIONAL       Section 4.2.6
           sides-supported                  OPTIONAL       Section 4.2.7
           printer-resolution-supported     OPTIONAL       Section 4.2.8
           print-quality-supported          OPTIONAL       Section 4.2.9
           color-supported                  OPTIONAL       Section 4.4.20
           finishings-supported             OPTIONAL       Section 4.2.10
           document-formats-supported       OPTAIONL       Section 4.2.14

                                 Expires February xx, April 14, 1998