INTERNET-DRAFT
         draft-ietf-ipp-model-05.txt
                                                                       R. deBry
      draft-ietf-ipp-model-04.txt
                                                                IBM Corporation
                                                                    T. Hastings
                                                              Xerox Corporation
                                                                     R. Herriot
                                                               Sun Microsystems
                                                                    S. Isaacson
                                                                   Novell, Inc.
                                                                      P. Powell
                                                     San Diego State University
                                                                  July 25,
                                                              September 3, 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) standard.  Although DPA specifies both
         end user and administrative features, IPP version 1.0 is focused only
         on end user functionality.

         The full set of IPP documents includes:

         deBry, Hastings, Herriot, Isaacson, Powell
                                  Expires January 25, March3, 1998
           Internet Printing Protocol: Requirements
           Internet Printing Protocol/1.0: Model and Semantics
           Internet Printing Protocol/1.0: Security
           Internet Printing Protocol/1.0: Protocol Specification
           Internet Printing Protocol/1.0: Directory Schema

         The requirements document takes a broad look at distributed printing
         functionality, and it enumerates real-life scenarios 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 and semantics
         document describes a simplified model with abstract objects, their
         attributes, and their operations. The model introduces a Printer
         object and a Job object.  The Job object supports multiple documents
         per job.  The security document covers potential threats and proposed
         counters to those threats.  The protocol specification is formal
         document which incorporates the ideas in all the other documents into
         a concrete mapping using clearly defined data representations and
         transport protocol mappings that real implementers can use to develop
         interoperable client and server side components. Finally, the
         directory schema document shows a generic schema for directory service
         entries that represent instances of IPP Printers.

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

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
                                   Table of Contents

         1. Simplified Printing Model......................................7 Model .......................................7
         2. IPP Objects....................................................9 Objects .....................................................9
         2.1  Printer Object .............................................10 Object..................................................9
         2.2  Job Object .................................................12 Object.....................................................12
         2.3  Document Object ............................................12 Object................................................12
         2.4  Object Relationships .......................................12 Relationships...........................................12
         2.5  Object Identity ............................................13 Identity................................................13
         3. IPP Operations................................................13 Operations .................................................15
         3.1  General Semantics ..........................................14 Semantics..............................................16
         3.1.1     Operation Targets........................................16
         3.1.2     Operation Status Codes and Messages......................14
         3.1.2     Security and Query Operations............................14 Messages......................16
         3.1.3     Security Concerns for IPPOperations......................17
         3.1.3.1     Authenticated Requester Identity .......................17
         3.1.3.2     Restricted Queries .....................................17
         3.1.4     Versions.................................................18
         3.1.5     Job Creation Operations..................................15 Operations..................................18
         3.2  Printer Operations .........................................16 Operations.............................................20
         3.2.1     Get-Operations Operation.................................16
         3.2.1.1     Get-Operations Request ................................16
         3.2.1.2     Get-Operations Response ...............................16
         3.2.2     Print-Job Operation......................................17
         3.2.2.1 Operation......................................20
         3.2.1.1     Print-Job Request .....................................17
         3.2.2.2 ......................................20
         3.2.1.2     Print-Job Response ....................................20
         3.2.3 .....................................22
         3.2.2     Print-URI Operation......................................20
         3.2.4 Operation......................................23
         3.2.3     Validate-Job Operation...................................21
         3.2.5 Operation...................................23
         3.2.4     Create-Job Operation.....................................21
         3.2.6 Operation.....................................23
         3.2.5     Get-Attributes Operation.................................21
         3.2.6.1 Operation.................................24
         3.2.5.1     Get-Attributes Request ................................22
         3.2.6.2 .................................24
         3.2.5.2     Get-Attributes Response ...............................23
         3.2.7 ................................25
         3.2.6     Get-Jobs Operation.......................................23
         3.2.7.1 Operation.......................................25
         3.2.6.1     Get-Jobs Request ......................................24
         3.2.7.2 .......................................25
         3.2.6.2     Get-Jobs Response .....................................24 ......................................26
         3.3  Job Operations .............................................25 Operations.................................................27
         3.3.1     Send-Document Operation..................................25 Operation..................................27
         3.3.1.1     Send-Document Request .................................25 ..................................27
         3.3.1.2     Send-Document Response ................................25 .................................28
         3.3.2     Send-URI Operation.......................................25 Operation.......................................29
         3.3.3     Cancel Job Operation.....................................26 Operation.....................................29
         3.3.3.1     Cancel-Job Request ....................................26 .....................................29
         3.3.3.2     Cancel-Job Response ...................................26 ....................................29
         3.3.4     Get-Attributes Operation.................................26 Operation.................................29
         3.3.4.1     Get-Attributes Request ................................26 .................................30
         3.3.4.2     Get-Attributes Response ................................30
         4. Object Attributes.............................................27 Attributes ..............................................31
         4.1  Attribute Syntaxes .........................................27
         4.1.1     Attribute Extensibility..................................29 Syntaxes.............................................31
         4.2  Job Template Attributes ....................................31 Attributes........................................33
         4.2.1     job-sheets (type4 keyword)...............................34 keyword)...............................37
         4.2.2     notify-events (1setOf type2 keyword).....................35 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)............................35 uri)............................39
         4.2.4     job-priority (integer(1:100))............................36

                                Expires January 25, 1998 (integer(1:100))............................39
         4.2.5     job-hold-until (type4 keyword)...........................36 keyword)...........................40
         4.2.6     multiple-document-handling (type2 keyword)...............37 keyword)...............40
         4.2.7     media (type4 keyword)....................................37 keyword)....................................41
         4.2.8     number-up (type3 keyword)................................38 keyword)................................42
         4.2.9     sides (type2 keyword)....................................38 keyword)....................................42
         4.2.10    printer-resolution (resoultion)..........................39 (resoultion)..........................43
         4.2.11    print-quality (type2 enum)...............................39 enum)...............................43
         4.2.12    finishings (1setOf type2 enum)...........................39 enum)...........................43
         4.2.13    copies (integer(1:2**31 - 1))............................40 1))............................44
         4.2.14    document-format (type2 enum).............................40    page-range (rangeOf integer).............................44
         4.2.15    orientation (type2 enum).................................45
         4.2.16    document-format (mimeType)...............................45
         4.2.17    compression (type3 keyword)..............................41
         4.2.16 keyword)..............................45
         4.2.18    job-k-octets (integer(0:2**31 - 1))......................41
         4.2.17 1))......................46
         4.2.19    job-impressions (integer(0:2**31 - 1))...................41
         4.2.18 1))...................46
         4.2.20    job-media-sheets (integer(0:2**31 - 1))..................41 1))..................46
         4.3  Job Description Attributes .................................42 Attributes.....................................46
         4.3.1     job-uri (uri)............................................43 (uri)............................................47
         4.3.2     job-uri-user (uri).......................................44     job-id (32bit unsigned integer)..........................48
         4.3.3     job-name (name)..........................................44     job-uri-user (uri).......................................48
         4.3.4     job-originating-user (name)..............................44     job-name (name)..........................................48
         4.3.5     job-originating-host (name)..............................44     job-originating-user (name)..............................48
         4.3.6     user-human-language (human-language).....................44     job-originating-host (name)..............................48
         4.3.7     user-content-char-set (char-set).........................45     user-human-language (human-language).....................49
         4.3.8     job-state (type1 enum)...................................45 enum)...................................49
         4.3.9     job-state-reasons (1setOf  type2 keyword)................47 keyword)................51
         4.3.10    job-state-message (text).................................49 (text).................................53
         4.3.11    output-device-assigned (name)............................49 (name)............................53
         4.3.12    time-since-pending (integer).............................49 (integer).............................53
         4.3.13    time-since-processing (integer)..........................49 (integer)..........................53
         4.3.14    time-since-completed (integer)...........................49 (integer)...........................53
         4.3.15    number-of-intervening-jobs (integer(0:2**31 - 1))........49 1))........53
         4.3.16    job-message-from-operator (text).........................50 (text).........................54
         4.3.17    job-k-octets-processed (integer(0:2**31 - 1))............50 1))............54
         4.3.18    job-impressions-completed  (integer(0:2**31 - 1))........50 1))........54
         4.3.19    job-media-sheets-completed (integer(0:2**31 - 1))........50 1))........54
         4.4  Document Attributes ........................................50 Attributes............................................54
         4.4.1     document-name (name).....................................51 (name).....................................55
         4.4.2     document-format (type2 enum).............................51
         4.4.3     document-uri (uri).......................................51 (uri).......................................55
         4.5  Printer Description Attributes .............................51 Attributes.................................56
         4.5.1     printer-uri (uri)........................................53 (uri)........................................58
         4.5.2     printer-uri-user (uri)...................................53
         4.5.3     printer-name (name)......................................53
         4.5.4 (name)......................................58
         4.5.3     printer-location (text)..................................53
         4.5.5 (text)..................................58
         4.5.4     printer-description (text)...............................53 (text)...............................58
         4.5.5     printer-more-info (uri)..................................58
         4.5.6     printer-more-info-site (uri).............................53
         4.5.7     printer-driver-installer (uri)...........................54
         4.5.8     printer-make-and-model (text)............................54
         4.5.9     printer-more-info-manufacturer (uri).....................54 (uri)...........................59

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
         4.5.10
         4.5.7     printer-make-and-model (text)............................59
         4.5.8     printer-more-info-manufacturer (uri).....................59
         4.5.9     printer-state (type1 enum)...............................54
         4.5.11 enum)...............................59
         4.5.10    printer-state-reasons (1setOf type2 keyword).............55
         4.5.12 keyword).............60
         4.5.11    printer-state-message (text).............................57 (text).............................62
         4.5.12    operations-supported (1setOf type2 enum).................62
         4.5.13    printer-is-accepting-jobs (boolean)......................57 (boolean)......................63
         4.5.14    queued-job-count (integer(0:2**31 - 1))..................58 1))..................63
         4.5.15    printer-message-from-operator (text).....................58 (text).....................63
         4.5.16    printer-human-language (human-language)..................58 (human-language)..................63
         4.5.17    printer-human-language-supported (1setOf human-language).58 human-language).63
         4.5.18    printer-content-char-set (char-set)......................58
         4.5.19    printer-content-char-set-supported (1setOf char-set).....58
         4.5.20    color-supported (boolean)................................58
         4.5.21 (boolean)................................64
         4.5.19    pdl-override (type2 keyword).............................58
         4.5.22 keyword).............................64
         4.5.20    Security Related Attributes..............................59
         4.5.22.1 Attributes..............................64
         4.5.20.1    message-protection-supported (keyword) ................60
         4.5.22.2 .................65
         4.5.20.2    authentication-authorization-supported (keyword) ......60
         4.5.23    best-effort (1setOf boolean).............................60 .......65
         4.5.21    printer-up-time (seconds)................................65
         4.5.22    printer-current-time (dateTime)..........................65
         5.   Conformance...................................................61 Conformance ....................................................66
         5.1    Conditionally Mandatory ....................................61
         5.2  Client Conformance Requirements ............................62
         5.3 Requirements................................66
         5.2  Printer Object Conformance Requirements ....................62
         5.3.1     Objects..................................................62
         5.3.2     Operations...............................................63
         5.3.3     Attributes...............................................63
         5.3.4 Requirements........................67
         5.2.1     Objects..................................................67
         5.2.2     Operations...............................................67
         5.2.3     Attributes...............................................67
         5.2.4     Printer extensions.......................................64
         5.3.5 extensions.......................................68
         5.2.5     Attribute Syntaxes.......................................64
         5.4 Syntaxes.......................................68
         5.3  Security Conformance Requirements ..........................64 Requirements..............................68
         6. IANA Considerations (registered and private extensions).......65 extensions) ........68
         6.1  Typed Extensions ...........................................65
         6.1.1     Type1....................................................65
         6.1.2     Type2....................................................65
         6.1.3     Type3....................................................66
         6.1.4     Type4....................................................66 Extensions...............................................68
         6.2  Registration of MIME types/sub-types for document-formats ..66 document-formats......70
         6.3  Attribute Extensibility........................................70
         6.4  Attribute Syntax Extensibility.................................70
         7.   Security Considerations.......................................66 Internationalization Considerations ............................70
         8.   References....................................................67 Security Considerations ........................................71
         9.   Author's Address..............................................68
         10.  APPENDIX References .....................................................71
         10.Author's Address ...............................................73
         11.APPENDIX A: Terminology.......................................71
         10.1   Conformance Terminology ....................................71
         10.1.1    MUST.....................................................71
         10.1.2 ........................................76
         11.1 Conformance Terminology........................................76
         11.1.1    MUST.....................................................76
         11.1.2    MUST NOT.................................................71
         10.1.3    SHOULD...................................................71
         10.1.4 NOT.................................................76
         11.1.3    SHOULD...................................................76
         11.1.4    SHOULD NOT...............................................71
         10.1.5    MAY......................................................71
         10.1.6    CONDITIONALLY MANDATORY..................................72
         10.1.7 NOT...............................................76
         11.1.5    MAY......................................................76
         11.1.6    NEED NOT.................................................73
         10.2 NOT.................................................77
         11.2 Model Terminology ..........................................74
         10.2.1    Keyword..................................................74
         10.2.2    Parameters...............................................74

                                Expires January 25, 1998
         10.2.2.1    Parameter Name ........................................74
         10.2.2.2    Parameter Value .......................................74
         10.2.2.3    Parameter Syntax ......................................74
         10.2.3    Attributes...............................................75
         10.2.3.1 Terminology..............................................77
         11.2.1    Keyword..................................................77
         11.2.2    Attributes...............................................77
         11.2.2.1    Attribute Name ........................................75
         10.2.3.2 .........................................77

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         11.2.2.2    Attribute Group Name ..................................75
         10.2.3.3 ...................................78
         11.2.2.3    Attribute Value .......................................75
         10.2.3.4 ........................................78
         11.2.2.4    Attribute Syntax ......................................76
         10.2.4    Supports.................................................76
         11.  APPENDIX .......................................78
         11.2.3    Supports.................................................78
         12.APPENDIX B:  Status Codes.....................................77
         11.1 Codes ......................................80
         12.1 Status Codes (type2 keyword) ...............................78
         11.1.1    Informational............................................78
         11.1.2 keyword)...................................80
         12.1.1    Informational............................................81
         12.1.2    Successful Status Codes..................................78
         11.1.2.1 Codes..................................81
         12.1.2.1    successful-ok .........................................78
         11.1.2.2 (0x00) ...................................81
         12.1.2.2    successful-ok-ignored-or-substituted-attributes .......78
         11.1.3 (0x01) .81
         12.1.3    Redirection Status Codes.................................78
         11.1.4 Codes.................................81
         12.1.4    Client Error Status Codes................................79
         11.1.4.1 Codes................................81
         12.1.4.1    client-error-bad-request ..............................79
         11.1.4.2 (0x400) .......................81
         12.1.4.2    client-error-forbidden ................................79
         11.1.4.3 (0x401) .........................82
         12.1.4.3    client-error-not-authenticated ........................79
         11.1.4.4 (0x402) .................82
         12.1.4.4    client-error-not-authorized ...........................79
         11.1.4.5 (0x403) ....................82
         12.1.4.5    client-error-not-possible .............................80
         11.1.4.6 (0x404) ......................82
         12.1.4.6    client-error-timeout ..................................80
         11.1.4.7 (0x405) ...........................82
         12.1.4.7    client-error-not-found ................................80
         11.1.4.8 (0x406) .........................83
         12.1.4.8    client-error-gone .....................................80
         11.1.4.9 (0x407) ..............................83
         12.1.4.9    client-error-request-entity-too-large .................81
         11.1.4.10 (0x408) ..........83
         12.1.4.10   client-error-request-URI-too-long .....................81
         11.1.4.11 (0x409) ..............84
         12.1.4.11   client-error-unsupported-document-format ..............81
         11.1.4.12 (0x40A) .......84
         12.1.4.12   client-error-attribute-not-supported ..................81
         11.1.5 (0x40B) ...........84
         12.1.5    Server Error Status Codes................................82
         11.1.5.1 Codes................................84
         12.1.5.1    server-error-internal- error ..........................82
         11.1.5.2 (0x500) ...................85
         12.1.5.2    server-error-operation-not-supported ..................82
         11.1.5.3 (0x501) ...........85
         12.1.5.3    server-error-service-unavailable ......................82
         11.1.5.4 (0x502) ...............85
         12.1.5.4    server-error-version-not-supported ....................82
         11.1.5.5 (0x503) .............85
         12.1.5.5    server-error-device-error .............................83
         11.1.5.6 (0x504) ......................85
         12.1.5.6    server-error-temporary-error ..........................83
         11.2 (0x505) ...................86
         12.2 Status Keywords for IPP Operations .........................84
         12.  APPENDIX Operations.............................87
         13.APPENDIX C: "document-format" enum values.....................84
         13.  APPENDIX values ...........................87
         14.APPENDIX D:  "media" keyword values...........................88 values ............................90
         15.APPENDIX E: Processing IPP Attributes ..........................95
         15.1 Fidelity.......................................................95
         15.2 Page Description Language (PDL) Override.......................97
         15.3 Suggested Attribute Processing Algorithm.......................98
         16.APPENDIX F: Relationship to SNMP MIBs .........................101

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 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 abstracts the many
         components of real world printing solutions.  The Internet is a
         distributed computing environment where requesters of print services
         (clients, applications, PC 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 [20].

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

           - Printer (Section 0) 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 uses
         specific model terminology (such is defined in
         Appendix A (section 11) .  Terms such as "attributes", "supports", "keywords", and "parameters")
         "supports" have special meaning in this document and conformance are defined in
         the model terminology (such section.  .  Terms such as "MANDATORY", "MUST",
         and "OPTIONAL").  Appendix A defines these terms
         as they relate "OPTIONAL" have special meaning relating to this document. conformance.  These
         terms are defined in the section on conformance terminology, most of
         which is taken from RFC 2119 [25].

         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 January 25, February xx, 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, context, printer capabilities, etc.). The more dynamic
         information associated with a Printer includes state, currently loaded
         and ready media, number of jobs at the Printer, errors, warnings, and
         so forth.

         IPP 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 their print jobs.  An IPP server is just that part of the IPP
         Printer that implements the server-side protocol.  The rest of the IPP

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
         IPP
         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, Printer and the Printer validates the
         data in the submission request, the Printer creates a Job object.  The
         end user then interacts with this new Job to query its status and
         monitor the progress of the job.  End users may also cancel the Job.
         The end user is able to register to receive certain events that are
         then routed using the specified notification service(s).

         2. IPP Objects

         The IPP model introduces objects of type Printer, Job, and Document.
         Each object type is defined as a set of possible attributes that may
         be supported by each instance of an object of that type.  The
         attributes (and values) supported by  For each
         object instance describe instance, the
         implementation (that is actual set of supported attributes and values
         describe the specific implementation.  The object's attributes and
         values describe its capabilities, realizable features, job processing
         functions, and
         characteristics either in software or hardware) for that object
         instance. default behaviors and characteristics. For example, the
         object type "Printer" is defined as a set of
         attributesthat attributes that each
         instance of a Printer object might potentially support.  In the same
         manner, the object type "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 support the attribute.
           - "OPTIONAL": each object instance MAY support the attribute.
           - "CONDITIONALLY MANDATORY": whether or not the object instance
              supports the attribute is determined by a semantic condition.
              For example, a Printer object implementation MUST support the
              "job-priority-supported" attribute if the implementation knows
              about and is able to realize multiple levels of job priorities.
              An administrator may set the values to be somewhat more
              restrictive that what a given implementation might allow, however
              the attribute MUST still be supported.

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

                                Expires January 25, 1998

         2.1 Printer Object

         A major component of the IPP model is the Printer object.  An instance
         of a Printer object implements the IPP protocol.  Using the protocol,
         end users may query the attributes of the Printer, Printer and submit Jobs to
         the
         Printer, determine subsequent states of submitted and queued Jobs, and
         cancel Jobs Printer (section 3 describes each of the Printer specific
         operations in detail).  The actual implementation components 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 to the end
         user.

         The capabilities and state of an IPP Printer are described by its
         attributes.  Printer attributes are grouped as follows:

           "job-template" attributes (section 4.2)
           "printer-description" attributes (section 4.5)

         Since a Printer object is an abstraction of a generic document output
         device and print service provider, an IPP Printer object could be used
         to represent any real or virtual device with semantics consistent with
         thePrinter
         the Printer object, such as a fax-out 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 following figures for some examples on how to view IPP Printer
         objects implemented on top of various print system 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 January 25, February xx, 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 is assumed that URIs for IPP Printers are available to end users or
         programs that wish to interact with the Printer.  Although NOT
         MANDATORY, it is RECOMMENDED that Printers be registered in a
         directory service which end users and programs can interrogate.
         "Internet Printing Protocol: Directory Schema"[24] defines the

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
         attributes to be associated with a Printer entry in a directory
         service.

         2.2 Job Object

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

         The characteristics and state of an IPP Job are described by its
         attributes.  Job attributes are grouped as follows:

           "job-template" attributes (optionally supplied by the client/end
              user, section 4.2)
           "job-description" attributes (set by the Printer, section 4.3)

         2.3 Document Object

         A Document object is used to model a document.  A Document consists of
         either printable data or a URI reference
         (URI) to printable data and  An
         instance of a Document object is a set of attributes which describe
         the document data.  Document Attributes (see section 4.4).  These Document
         attributes only describe the data to be printed; they do not include
         any specialized document processing instructions.  All document processing
         instructions are included as at the Job level
         attributes (called and are called called Job Template attributes),
         attributes and they apply equally to all Documents within a Job.

         Currently there are no operations defined for Document objects.

         2.4 Object Relationships

         Instances of objects within the system have relationships that MUST be
         maintained persistently along with the persistent storage of the
         object attributes.  An instance of a Printer object usually represents
         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 zero or more Job objects.  An instance of a Job
         object is contained in exactly one Printer object (the same document object, however the
         identical Job data could be sent to a either the same or a different Printer, but
         Printer.  In this case, the
         corresponding new Job object would be an identical, but
         different Jobsince it each would have a different Job identifier.  A

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
         object).  A
         Job object contains one or more Documents.  If the Document is simply
         a reference to some print data stream, the referenced 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 data,
         the stream is contained in only one Document, although there can be
         copies of the same document data in other Documents in the same or
         different Jobs.

         2.5 Object Identity

         All instances of Printer and Job objects have a URI so that they can
         persistently and unambiguously referenced.  The IPP model requires
         that these values be URIs as defined by RFC 1738 [11] and RFC 1808. 1808
         [34].  In addition to an identifier attribute, identifier, instances of Printer Printers, Jobs, and Job
         objects
         Documents may have a name.  An object name need not be unique across
         all instances of all objects. The Printer name is chosen and set by an
         administrator.
         administrator through some mechanism outside the scope of IPP itself.
         If not supplied by the client, client does not supply Job name or a Document name, the Printer creates the
         Job
         generates a name.  In all cases, the name only has local meaning, and
         it is not constrained to be unique.

         To summarize, each instance of summarize:

           - Each Printer and will be uniquely identified with a URI.  The
              Printer's "printer-uri" attribute contains the URI.
           - Each Job objects will have two
         identifying attributes: be uniquely identified with a URI.  The Job's "job-
              uri" attribute contains the URI.
           - "xxx-uri": Each Printer has name (which is not necessarily unique).  The unique identifier for
              administrator chooses and sets this object instance name through some mechanism
              outside the scope of IPP itself.  The Printer's "printer-name"
              attribute contains the name.
           - "xxx-name": Each Job has name (which is not necessarily unique).  The non unique client
              optionally supplies this name for in the create request.  If the
              client does not supply this object instance

         Document objects sent to an IPP name, the Printer only have names, no
         identifiers. generates a name
              for the Job. The "document-name" Job's "job-name" attribute is used to store contains the name.
           - Each Document has name
         of (which is not necessarily unique).  The
              client optionally supplies this name in the request which creates
              the Document.  This name is just of interest within  If the context of
         a Job; it need client does not be unique. 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
         Document object contains a "document-uri" attribute, but the attribute.  The value of
         this attribute is a reference to the document data to be printed; it
         is not
         the a unique identifier of the Document object itself.

         3. IPP Operations

         Jobs and Printers each have a set of associated operations.
         Operations consist

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

         All instances of requests and responses.  When Printer objects have a client
         communicates with an URI so that they can
         persistently and unambiguously referenced.  The IPP object, it issues an operation request model requires
         that these values be URIs as defined by RFC 1738 [11] and RFC 1808.
         All Printer operations are directed to the
         URI for Printer's URI.  All
         instances of Job objects have an opaque identifier that object.  Each request carries along when used in
         combination with its Printer URI, allow it the input
         parameters and any data required to perform be persistently and
         unambiguously referenced.  Instances of Document objects have no
         identifier since they are always created and queried using Job
         operations; that is the operation.  Each
         request requires a response from 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,
         and Document objects may have a name.  An object indicating success or
         failure name need not be
         unique across all instances of the operation including output parameters, status codes,

                                Expires January 25, 1998
         and/or status messages. all objects. The representation Printer name is chosen
         and encoding of IPP
         operations, parameters, set by an administrator.  A client optionally supplies Job and attributes is described
         Document names in "Internet
         Printing Protocol: Protocol Specification" [23].  This section of this
         document describes the IPP operations in terms of their contents and
         semantics including both the request that create Jobs and Documents.  If a
         client does not supply a name, the response for each
         operation.

         The Printer operations are fully defined in section ??:

           Get-Operations (section 3.2.1)
           Print-Job (section 3.2.2)
           Print-URI (section 3.2.3)
           Validate-Job (section 3.2.4)
           Create-Job (section 3.2.5)
           Get-Jobs (section 3.3.3)
           Get-Attributes (section 3.3.4) 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 operations are fully defined in section ??:

           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 Document operations.

         3.1 General Semantics

         3.1.1 Operation Status Codes and Messages

         Every operation response returns will be uniquely identified with a MANDATORY status code Job ID and an
         OPTIONAL status message. A status code provides information on the
         processing of a request.  A message provides a short textual
         description of the status of Printer
              URI.  The Job's "job-id" attribute contains the operation. Job ID.  The status code
              Printer's "printer-uri" attribute contains the Printer's URI.
           - Each Printer has name (which is
         intended for use by automata not necessarily unique).  The
              administrator chooses and a status message is intended for sets this name through some mechanism
              outside the
         human user.  An scope of IPP application (i.e. a browser, GUI, print driver or
         gateway) itself.  The Printer's "printer-name"
              attribute contains the name.
           - Each Job has name (which is not required to examine or display the message.  Status
         codes and suggested corresponding status messages are described necessarily unique).  The client
              optionally supplies this name in
         section 11.. In most cases, if the status code indicates an error (the
         code belongs to either the "client-error" or create request.  If the "server-error"
         group), there are additional output parameters (such as "unsupported-
         attributes") returned that are
              client does not returned in supply this name, the successful case.

         3.1.2 Security and Query Operations

         In many of these IPP operations, Printer generates a name
              for the Job. The Job's "job-name" attribute contains the name.
           - Each Document has name (which is not necessarily unique).  The
              client optionally supplies a list of
         attributes to be returned this name in the response.  A Printer may be

                                Expires January 25, 1998
         configured, for security reasons, not to return all attributes request that a
         client requests.  It may even return none of the requested attributes.
         In such cases, creates
              the status returned is Document.  If the same as if client does not supply this name, the
              Printer had
         returned all requested attributes.  The client cannot tell by such generates a
         response whether name for the requested Document. The Document's
              "document-name" attribute was present or absent on contains the
         Printer.

         3.1.3 Job Creation Operations

         In order to create a new Job object, a client issues name.

         Note: If Documents are printed by reference, the corresponding
         Document object contains a create request.
         A create request any one of following three operation requests:

           - "document-uri" attribute.  The Print-Job operation:  This operation value of

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         this attribute is used by a client that
              wants to create a Job with only a single Document.  The operation
              allows for the client reference to "push" the document data to be printed; it
         is not a unique identifier of the Printer
              by including the document data in the request Document object itself.

           - The Print-URI operation:  This operation is used by

         3. IPP Operations

         Jobs and Printers each have a client that
              wants to create set of associated operations.
         Operations consist of requests and responses.  When a Job client
         communicates with only a single Document, however, an IPP object, it issues an operation request to the
              client wants
         URI for that object.  Each request carries along with it any operation
         attributes and data required by the Printer object to "pull" the document data.  In this
              case, perform the client includes only operation.
         Each request requires a URI reference to response from the document
              data (not object.  Each response
         indicates success or failure of the document data itself).

           - The Create-Job operation:  This operation is used by a client
              that wants to create a Job with multiple Documents. This a status code, and
         may include operation is followed by attributes  and an arbitrary number optional status message.  The
         representation and encoding of Send-Document or
              Send-URI IPP operations (each creating another Document for this
              Job).  The Send-Document operation includes is described in
         "Internet Printing Protocol: Protocol Specification" [23].  This
         section describes the document data
              with IPP operations in terms of their semantics and
         contents, including both the operation request (client "pushes" the document data to
              the printer), and the Send-URI operation includes only a URI
              reference to the document data (the response for each
         operation.

         The Printer "pulls" the document
              data from the referenced location). operations are fully defined in section 3.2:

           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 last Job operations are fully defined in section 3.3:

           Send-Document or (section 3.3.1)
           Send-URI request includes a parameter indicating (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 this is the
              last are used to create and query Document for this Job.

         A Create-Job operation followed by only one objects
         contained within a Job object.  The Send-Document operation is
         semantically equivalent and Send-URI Job
         operations are used to add a Print-Job operation, however, for
         performance reasons, the client SHOULD use new Document to an existing multi-
         Document Job.  If requested, the Print-Job Get-Attribute operation used for
         all single a
         Job also returns any Document Jobs.  Throughout this model specification, object attributes.  If the
         term "create request" Job is used to refer to any a
         single Document Job, only a single set of these three operation
         requests.

         Also, as the Printer evaluates input parameters and Job Template Document attributes in a create request at the time the Job is first submitted,
         it makes a decision whether or not to accept or reject the request and
         create
         returned.  If however, the Job object.  At job submission time, the Printer does not
         need to validate the document data or contains multiple Documents, the URI reference to document Get-
         Attribute Response contains multiple sets of Document attributes, one
         set for each Document.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
         data (in the case of a Print-URI).  However,
         3.1 General Semantics

         3.1.1 Operation Targets

         All IPP operations are directed at job processing time,
         the Printer might realize any an instance of the following:

           - there an error in the document data and it can not be parsed
           - IPP object.  For
         Printer operations, the document data operation is in directed at an unsupported format
           - the URI reference is incomplete or incorrect
           - IPP Printer using
         its URI.  That is, all Printer operations must somehow contain the URI reference is no longer valid (i.e.,
         target attribute "printer-uri" indicating the server hosting target of the data might be down)
           - or any other job processing error operation.
         In this case, the Printer, depending on mapping of IPP over HTTP, the error, can set "printer-uri" attribute is
         actually encoded as the "job-
         state", "job-state-reasons", or "job-state-message" to some
         appropriate value.

         3.2 Printer Operations

         3.2.1 Get-Operations Operation

         The client uses this operation to query a specific implementation for
         a list "request-URI" component of supported operations. All implementations MUST support this
         operation because the HTTP operation.
         In other mappings, the target URI might be encoded using some of other
         transport specific mechanism.

         For Job operations, the operation is directed at an IPP operations defined in this
         specification are OPTIONAL.

         3.2.1.1 Get-Operations Request

         The Get-Operations Request has no input parameters.

         3.2.1.2 Get-Operations Response

         The Job using its
         URI.  Like Printer returns operations, all Job operations must somehow contain
         the following output parameters as part target attribute "job-uri" indicating the target of the
         Get-Operations Response:

           Target operation.
         Also, like Printer ("printer-uri"):
              The URI operations, in the mapping of IPP over HTTP, the target printer.

           Supported Operations ("supported-operations"):
              A list
         "job-uri" attribute is actually encoded as the "request-URI" component
         of the operations that this implementation supports
              (including all MANDATORY operations).  The values are taken from HTTP operation.  In other mappings, the following set: 'Get-Operations', 'Print-Job', 'Print-URI',
              'Validate-Job', 'Create-Job', 'Get-Jobs', 'Get-Attributes',
              'Send-Document', 'Send-URI', and 'Cancel-Job'.

              Note: Since this list contains all MANDATORY operations ('Get-
              Operations', 'Print-Job', 'Validate-Job', 'Get-Jobs', 'Get-
              Attributes', and 'Cancel-Job'), this output parameter will never target URI might be empty.

                                Expires January 25, 1998
         3.2.2 Print-Job Operation

         When an end user desires to submit a print job with only one Document,
         encoded using some other transport specific mechanism.

         Propsal:

         For Job operations, the client sends a Print-Job Request to a Printer and receives a
         Print-Job Response from that Printer.  The information in a Print-Job
         Request (along with any default information associated with the
         Printer) operation is sufficient for directed at the Printer's URI
         and it is accompanied by the Job ID .  This allows the IPP Printer
         implementation to create a find the correct Job object object.  That is, both the
         "printer-uri" attribute and then
         process that Job.  A Print-Job operation differs from a Print-URI
         operation in that a Print-Job operation contains the document data to "job-id" attribute must both be printed and a Print-URI operation only contains a reference to
         supplied as the
         document data.

         3.2.2.1 Print-Job Request

         The following input parameters are part target of every Job operation.  Like Printer
         operations, in the mapping of IPP over HTTP, the Print-Job Request: "printer-uri" (uri):
              The URI
         attribute is encoded in the "request-URI" component of the target printer.

           "job-name" (name):
              This optional parameter HTTP
         operation.  However, the "job-id" attribute is supplied as an
         operation attribute within the operation data itself.  If a Printer
         receives an IPP operation, it must check to see if the "job-id"
         attribute is included among the operation attributes.  If it is there,
         the operation is being directed at the Job identified by the client. value of
         "job-id".  If it is not
              supplied by there, the client, operation is being directed at the
         Printer generates a name (see Section
              4.3.3).

           "best-effort" (boolean):
              This parameter identifies the clients desire to accept best
              effort printing or not.  Best effor printing allows a job to be
              printed even though there might be a conflict between what a
              client requests in itself.

         3.1.2 Operation Status Codes and Messages

         Every operation response returns a create request MANDATORY status code and what an
         OPTIONAL status message. A status code provides information on the
         processing of a Printer supports.
              This is request.  A status message provides a MANDATORY parameter. short textual
         description of the status of the operation.  The value 'true' indicates that a
              "best effort attempt to print status code is
         intended for use by automata and the Job" status message is acceptable. intended for
         the human user.  If a
              Printer response does not support some of the client supplied Job Template
              attributes or values, the Printer might have include a status message,an IPP
         application is not required to ignore or
              substitute attributes examine or values.  The value 'false' display the status message.
         Status codes and suggested corresponding status messages are described

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         in section 12. In most cases, if the status code indicates an error,
         there are additional attributes in the response  that a best effort attempt to print are not returned
         in the Job successful case.  One such example is not acceptable;
              total fidelity to client supplied the group of unsupported
         attributes and values values.  This set of attributes is
              required.  In this case, returned in response
         to an operation request that includes attributes that are not
         supported by the client object.

         3.1.3 Security Concerns for IPPOperations

         3.1.3.1 Authenticated Requester Identity

         IPP is requesting layered on top of security services that supply the Job be
              printed exactly as specified, and if requester's
         identity.  It is assumed that identity supplied by the authentication
         service is not possible the most authenticated identity required by a given site's
         configuration and current policy.  It is also assumed that the
              Job must
         layering allows for a single IPP implementation to be rejected rather than processed incorrectly.  A client
              may query run over a
         consistent interface that supplies the Printer's MANDATORY "best-effort-supported"
              attribute to determine if either type of best effort printing (or
              both) are supported. authenticated identity. The request is rejected outright if either
              the Printer's "best-effort-supported" attribute is set to only
              'true'
         authentication interface should allow for various modular and
         extensible authentication service implementations without requiring
         changes to the client supplies a value IPP implementation.

         Once the authenticated identity of 'false' or the
              Printer's "best-effort-supported" attribute is set requester has been supplied to only
              'false' and
         the client supplies a value of 'true'.

           Job Template Attributes:

                                Expires January 25, 1998
              An optional set of Job Template attributes as defined in section
              4.2.  If IPP implementation, the client supplies no Job Template attributes implementation uses that identity to
         enforce any authorization policy(ies) that might be in place.  When a
         Job is created, the
              Print-Job Request, the Printer uses its default value attributes
              when processing identity of the job.

           Document Attributes
              The client optionally supplies requester of the "document-name" and "document-
              format" attributes.   If "document-name" create operation
         is not supplied, the
              Printer generates a name for persistently stored in the Document.  If "document-format"
              is not supplied, Job's "job-originating-user" attribute.
         This attribute can be used to match the Printer assumes requester's identity of
         subsequent operations on that the document data is Job in
              a format order to enforce the local
         authorization policy(ies), if any.  There are operation status codes
         that this acceptable allow an implementation to return information back to the Printer.

              ISSUE: Should "document-name" be
         operation requester about what has been forbidden, not allowed, or not
         authorized.

         For example, a parameter and document-format
              just site security policy might be a Job Template attribute?

           Document Content:
              The client supplies that only the document data job owner
         is allowed to be processed.

         The simplest Print-Job Request consists of just cancel a job using the Document Content
         and nothing else. Cancel-Job operation.

         3.1.3.2 Restricted Queries

         In this case, the Printer creates many of these IPP operations, a new Job object
         with no associated Job Template client supplies a list of
         attributes and to be returned in the job contains a
         single Document.  The response.  A Printer also generates a name may be
         configured, for security reasons, not to return all attributes that a
         client requests.  It may even return none of the Document
         and for requested attributes.
         In such cases, the Job.

         When a Printer receives a Print-Job Request, the Printer either
         accepts or rejects the request. The Printer accepts the Print-Job
         Request and creates a Job object if it status returned is able to accept all Job
         Template attributes in the request.  The Printer rejects the request
         and does not create a Job object same as if the Printer rejects any Job
         Template attribute in the request.  There are six cases to consider
         when accepting or rejecting Job Template attributes:

           1. had
         returned all requested attributes.  The client supplies a Job Template attribute named "xxx" and the
              value supplied by the client is among the values supported cannot tell by such a
         response whether the
              Printer (i.e., is among the values of the Printer's "xxx-
              supported" attribute): The "xxx" Job Template requested attribute is
              accepted. The Printer creates the Job object and associates was present or absent on the
              "xxx" attribute
         Printer.

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

         Each operation request carries with the new Job object using the value supplied
              by the client.

           2. The client supplies it a Job Template attribute but version number. Each version
         number is in the attribute form X.Y where X is syntactically bad: The Printer rejects the job major version number and returns Y is
         the
              attribute minor version number.

         By including a version number in the "unsupported-attributes" output parameter.

           3. The client supplies a Job Template attribute and request, it allows the attribute
              value
         client (the requester) to identify which version of IPP it is not among the values supported by the Printer or
         interested in using.  If the Printer does not support that version,
         the attribute at all:  This case depends
              on the value of the "best-effort' parameter.   If the client

                                Expires January 25, 1998
              supplies Printer responds with a value status code of 'false'the Printer SHALL reject the Job and
              return the 'client-error-attribute-unsupported" error code and
              the unsupported attribute in the "unsupported-attributes " output
              parameter.  If the client supplies  'server-error-version-not-
         supported'.  There is no version negotiation per se.  However, if
         after receiving a "best-effort" value of
              'true' the Printer SHALL accept the Job either ignore unsupported
              attributes or substitute version not supported values for all unsupported
              values supplied by status code from the client.  In this case, if everything else Printer,
         there is ok, the Printer returns nothing that prevents a "successful-ok-ignored-or-
              substituted-attributes" status code.  The client could later
              query the Job object from trying again with a
         different version number.  For example, a client might be configured
         to find which 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 the Job major version number
         include any changes to the protocol specification itself such as:

           - reordering of ordered attributes had been
              ignored or substituted.

              ISSUE: Does attribute sets
           - changes to the above satisfy Jim W.'s issue about persistence syntax of
                the best effort value?

           5. The client does not supply a Job Template attribute existing attributes
           - changing OPTIONAL to MANDATORY and vice versa

         Items that is
              supported by might affect the Printer::  If all other attributes are
              acceepted, changing of the Printer accepts minor version number
         include any changes to the request model objects and  creates the Job
              object, the Printer does attributes but not associate the attribute with the
         protocol specification itself, such as:

           - grouping all extensions not included in a previous version into a
              new version
           - formally adding in new
              Job object. When the Printer processes that Job, the Printer uses
              the behavior implied by the default value Printer attribute as
              set at the time values
           - changing any of the type1 attributes

         3.1.5 Job processing (not Job creation). Creation Operations

         In other
              words, these rules allow order to create a new Job object, a client issues a create request.
         A create request is any one of following three operation requests:

           - The Print-Job Request: A client that wants to submit create a Job with no Job
              Template attribute and as
              only a single Document uses the Printer processes Print-Job operation. .  The
              operation allows for the Job, client to "push" the document data to
              the Printer uses its by including the default value attribute document data in place of the
              missing request itself.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           - The Print-URI Request: A client that wants to create a Job Template attribute.  Suppose with
              only a single Document where the Printer were to
              associate the Printer's default value is with "pulls" the Job at creation
              time for an attribute which was not supplied by document
              data uses the client.  A
              later query of Print-URI operation.   In this case, the Job object would reveal client
              includes only a set of Job object
              attributes and neither URI reference to the Printer nor document data (not the end user would be able
              document data itself).

           - The Create-Job Request:  A client that wants to tell the difference between create a Job attribute that is an
              "override PDL" attribute (supplied by with
              multiple Documents uses the client) and another
              which Create-Job operation. . This
              operation is a "default value" attribute (supplied followed by an arbitrary number of Send-Document or
              Send-URI operations (each creating another Document for this
              Job).  The Send-Document operation includes the printer).

           6. Neither document data in
              the request (the client supplies an attribute nor "pushes" the Printer
              supports document data to the attribute: :  The Printer accepts
              printer), and the Job, however,
              as far as IPP is concerned, the result of processing that Job
              (with respect Send-URI operation includes only a URI
              reference to the missing attributes) is undefined.

              In many cases though, this case represents a legacy environment,
              and even without IPP attributes, document data in the Job will be processed
              successfully.  For example, request (the Printer
              "pulls" the document data might have been
              generated by a device-specific printer driver that formats from the
              job and emits referenced location).  The
              last Send-Document or Send-URI request includes a data stream (a stream of PDL) "last-document"
              attribute set to 'true'  indicating that this is finely
              tuned for the intended output device and its internal
              interpreter.  But, neither the output device nor last
              Document for this Job.

         Throughout this model specification, the printer
              driver are aware term "create request" is used
         to refer to 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, the IPP protocol.  However, an intermediate

                                Expires January 25, 1998
              process, which client SHOULD use the Print-Job operation for
         all single Document Jobs.  Also, Print-Job is IPP aware, a MANDATORY operation
         (all implementations MUST support it) whereas Create-Job is able to submit an
         OPTIONAL operation, hence some implemations might not support it.

         Appendix E: Processing IPP Attributes (see Section 15) describes the job
         rules and make
              sure that it is delivered to issues surrounding either the output device, yet be unaware acceptance or rejection of
              all a
         create request.

         At job submission time, the Job Template attributes that might possibly be supported.

         3.2.2.2 Print-Job Response

         The Printer SHALL return does not need to validate the client
         document data or the following output parameters
         as part actual contents of the Print-Job Response:

           "job-uri" (uri):
              A URI which reference to document
         data (in the client SHALL use for all other operations on this
              Job

           Job Status Attributes:
              This includes the following Job attributes:  "job-name", "job-
              state", and "job-state-reasons". case of a Print-URI).  The value Printer SHOULD check the
         syntax of each attribute is
              taken from the URI to make sure that it appears to be a "snapshot" valid URI.
         However, other checks are essentially useless,since they require
         actually parsing and interpreting all of the new Job object sometime after print data, or in the
         case of a URI, checking for availability at Job submission time does
         not guarantee availability at Job processing time.  In other words,
         even if the Printer receives the print request until just prior to
              returning checks were made a Job submission time, they MUST also be
         done later at Job processing time, since at job processing time, the response to
         Printer might discover any of the client.  Since following conditions:

           - additional runtime errors in the  "job-state-
              message" attribute document data,
           - some nested document data  is OPTIONAL, it MAY be included in an unsupported format,

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           - the
              response, but it URI reference is NOT REQUIRED.

              Note: Since no longer valid (i.e., the server hosting
              the data might be down), or
           - any printer state information which affects a job's
              state is reflected in other run-time job processing error

         At this point, the "job-state" and "job-state-reasons"
              attributes, it Printer is sufficient unable to return only these attributes and
              no specific printer an error status attributes.

           Unsupported Attributes:
              This is a set of attributes and attribute values that are
              unsupported.  This output parameter is only returned code in
         the
              response if create response, since it had already sent the status code indicates that there was such an
              error.

         The simplest create response consists of the just the job identifier ("job-
         uri") and Job Status attributes output parameters
         with a successful status code
         of "successful-ok".

         3.2.3 Print-URI Operation

         This operation is identical to the Print-Job operation (section 3.2.2)
         except that a client supplies a URI reference to code.  In this case, the document data
         using Printer, depending
         on the "document-uri" (uri)  input parameter rather than including error, can set the document data itself.  It is up "job-state", "job-state-reasons", or "job-
         state-message" attributes to the IPP server to interpret appropriate value(s) so that later
         queries can report the
         URI and subsequently "pull" correct job status.  Also, if the document from client has
         requested notification for 'job-problems', the source referenced by Printer could notify
         the URI string.

                                Expires January 25, 1998
         3.2.4 Validate-Job client via the address(es) in the "notify-addresses" attribute.

         3.2 Printer Operations

         3.2.1 Print-Job Operation

         This operation is similar

         When an end user desires to submit a print job with only one Document,
         the client uses a Print-Job operation.   A Print-Job operation (section 3.2.2)
         except differs
         from a Print-URI operation in that a client supplies no Print-Job operation contains the
         document data to be printed and a Print-URI operation only contains a
         reference to the Printer
         allocates document data.  A Validate-Job operation contains no resources (i.e., it does not create
         data, only a new set of Job object) to
         process the job. This Template and Document attributes whose values
         can be validated for consistency.  A Create-Job operation is similar
         as well, however the Create-Job Request is used only to verify capabilities
         of create a printer object against whatever input parameters multi-
         Document Job.

         3.2.1.1 Print-Job Request

         The following sets of attributes are supplied in
         the Validate-Job request.  There is no "job-uri" output parameter
         returned in the Validate-Job Response.  If as  as part of the client supplies a
         "document-uri" input parameter,
         Print-Job Request:

         Operation Attributes

           "job-name" (name):
              This OPTIONAL attribute identifies the Printer SHOULD only validate client supplied Job name.
              If this attribute is supplied, its value it used for the
         syntax "job-
              name" attribute of the URI rather than follow the reference and validate newly created Job object. If this
              attribute is not supplied by the
         contents of client, the reference.  The Printer may choose generates a
              name to validate use in the
         reference, however, later at job processing time, "job-name" attribute of the reference will
         need to be validated yet again.  If all newly created Job
              object (see Section 4.3.4).

           "ipp-attribute-fidelity" (boolean):
              This is well, an OPTIONAL attribute.  If not supplied, the Printer returns
              assumes the status code "successful-ok".

         3.2.5 Create-Job Operation

         This operation value is similar 'false'.  The value 'true' indicates that
              total fidelity to the Print-Job operation (section 3.2.2)
         except client supplied attributes and values is
              required. The value 'false' indicates that a client supplies no document data or any reference reasonable attempt

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              to
         document data in print the Create-Job request.  This operation Job is followed
         by one or more Send-Document or Send-URI operations.  If acceptable.  All implementations support both
              types of job processing.  See section 15 for a Printer
         object supports full description
              of "ipp-attribute-fidelity" and its relationship to other
              attributes, especially the Create-Job operation, Printer's "pdl-override" attribute.

           "document-name" (name):
              This OPTIONAL attribute identifies the client supplied Document
              name.  If this attribute is supplied, its value it MUST also support either used for the Send-Document operation or
              "document-name" attribute of the Send-URI operation or both.  Since newly created Document object.
              If this attribute is not supplied by the client, the Printer
              optionally generates a client can name to use in the Get-Operations operation, a client SHOULD NOT
         attempt to use an unsupported operation.

         3.2.6 Get-Attributes Operation

         The Get-Attributes operation allows "document-name"
              attribute of the newly created Document object (see Section 4.4).

              ISSUE: Since this is part of a client to obtain information
         from Print-Job that creates only a Printer object. The
              single Document, should we
              not allow this attribute?

         Job Template Attributes

              An optional set of Job Template attributes as defined in section
              4.2.  If the client supplies as an operation parameter 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 of attribute names and/or attribute group names Document Attributes as defined in section 4.4.
              If "document-format" is not supplied, the Printer assumes that
              the
         requester document data is interested in.  The Printer returns a corresponding
         attribute set in a format that this acceptable to the response with
              Printer.  If the appropriate attribute values
         filled in "document-format" is unknown for each requested a certain
              document, the client SHALL NOT supply the attribute (either explicitly named in the create
              request or implicitly included by naming an attribute group).

         For Printers, the attribute groups include:

           - 'job-template': Send-Document Request.

         Document Content

              The client MUST supply the document data to be processed.

         Note: Since all Print-Job Request attributes are OPTIONAL, the
         simplest Print-Job Request consists of just the Document Content and
         nothing else.  In this case, the Job Template attributes that apply to
              a Printer creates a new Job object (the last two columns of the table and
         stores a generated Job name in Section
              4.2).
           - 'printer-description': the attributes specified in Section 4.5.

         There are also special groups: "job-name" attribute.  The Job
         contains a single Document.  The Printer optionally generates a name

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
           - 'none': no attributes of
         the specified object.  'none' is
              primarily useful Document and stores it in Get-Jobs, but can be used as a "ping" with the Get-Attributes operation.
           - 'all': all supported attributes

         It is NOT REQUIRED that a "document-name" attribute.  The
         Printer support all attributes belonging to
         a group, however it is MANDATORY assumes that each Printer implementation
         understand all group names.

         There is one group named 'document-attributes' which consists of the
         Document Attributes described document data is in section 4.4 ("document-name",
         "document-format", and "document-uri").  These attributes may be
         requested either individually or as a group.  If any or all of these
         attributes are requested, in format supported by the response, they are treated as multi-
         valued attributes (one value for each Document in
         Printer.  When the Job).  For
         example, there are 5 Documents in Printer processes the Job, then each returned Document
         attribute MUST have 5 values: the set it uses all of first its
         default values from each
         attribute correspond for the missing Job Template attributes.

         3.2.1.2 Print-Job Response

         The Printer SHALL return to the first Document, client the set following sets of
         attributes as part of second values
         correspond to the second Document, and so on.  In order to maintain Print-Job Response:

         Operation Attributes

           "job-uri" (uri):
              A URI which the same number of values in each returned attribute, if there is no
         value client SHALL use for either all other operations on this
              Job.  This is the "document-format" or "document-uri" attributes, MANDATORY "job-uri" attribute.

              ISSUE: Can this just be a
         special "out of band" value of 'none' is returned in its place. "Job Status Attribute"?

         Job Status Attributes

           "job-name":
              This
         out of band value requires an encoding described in is the Protocol
         Specification document [23].

         For a complete example, consider Job's "job-name" attribute.

           "job-state":
              This is the Job's "job-state" attribute. The value of  this
              attribute is taken from a "snapshot" of the new Job with 3 Documents and in object
              sometime after the
         Get-Attributes Request time the group 'document-attributes' Printer receives the print request
              until just prior to returning the response to the client.

           "job-state-reasons":
              This is requested.
         The returned attributes (in the Get-Attributes Response) might look
         like:

           document-name = 'Document 1', 'Document 2', Document 3'
           document-format = 'langPS', 'none', 'langPCL'
           document-uri = ' ftp://some.domain.com/file1.ps', 'none', 'none'

         3.2.6.1 Get-Attributes Request Job's "job-state-reasons" attribute.  The following input parameters are part value of
              this attribute is taken from a "snapshot" of the Get-Attributes Request
         when new Job object
              sometime after the time the Printer receives the print request is directed
              until just prior to a Printer object:

           "printer-uri" (uri):
              The URI of returning the target printer.

           "requested-attributes" (1setOf keyword) :
              An optional set of attribute names (without values) or attribute
              group names in whose values response to the requester client.

           "job-state-message":
              This is interested.  If the
              client omits this input parameter, Job's "job-state-message" attribute.  Since the Printer SHALL respond as
              if this input parameter had been supplied with "job-
              state-message" attribute is OPTIONAL Job attribute, itis
              OPTIONALLY included in the response.

              Note: Since any printer state information which affects a value of 'all'. job's
              state is reflected in the "job-state" and "job-state-reasons"
              attributes, it is sufficient to return only these attributes and
              no specific printer status attributes.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
           "document-format" (enum) :
         Unsupported Attributes:

              This input parameter is useful for determining the a set of
              supported attribute values which relate to the requested document
              format.  The Printer SHALL return only (1) those attributes that
              are supported and (2) the attributes and attribute values that are supported for
              the specified document format.  By specifying the document
              format, the client can get
              unsupported.  This output parameter is only returned in the Printer to eliminate
              response if the
              attributes and values status code indicates that are not supported for a specific
              document format.  For example, a Printer might have multiple
              interpreters to support both 'langPS' (for PostScript) and
              'langPCL' (for PCL) documents.  However, for only one there was such an
              error.

         Note: The simplest response consists of those
              interpreters might the Printer be able to support "number-up"
              with values of 'one', 'two', just the job URI ("job-
         uri") and 'four'.  For the other
              interpreter it might be able to only support "number-up" Job Status attributes with a
              value status code of 'one'.

              If "successful-
         ok".

         3.2.2 Print-URI Operation

         This operation is identical to the Print-Job operation (section 3.2.1)
         except that a client omits this input parameter, the Printer SHALL
              respond as if the input parameter had been set supplies a URI reference to the value of document data
         using the Printer's default value "document-format" "document-uri" (uri)  operation attribute were
              supplied. rather than
         including the document data itself.  It is recommended that the client always supply a
              value for document-format, since up to the Printer's default value for
              document-format may be 'langAutomatic', in which case IPP server to
         interpret the
              returned attributes URI and values are for the union of subsequently "pull" the document
              formats that the Printer can automatically sense.

         3.2.6.2 Get-Attributes Response

         The Printer returns from the following response parameters as part of source
         referenced by the
         Get-Attributes Response:

           Requested Attributes: URI string.

         3.2.3 Validate-Job Operation

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

         3.2.7 Get-Jobs Operation

         The Get-Jobs Print-Job operation allows (section 3.2.1)
         except that a client to retrieve the list of Jobs
         belonging to supplies no document data and the target Printer object.  The client may also supply
         allocates no resources (i.e., it does not create a
         list of Job attribute names or attribute group names.  These Job
         attributes will be returned for each new Job that is returned. object).
         This operation is like Get-Attributes, except that Get-Jobs operation
         returns attributes from possibly more than one used only to verify capabilities of a printer object (see
         against whatever attributes are supplied by the
         description of client in the
         Validate-Job request.  There is no "job-uri" attribute groups returned in section 3.2.6).

                                Expires January 25, 1998
         3.2.7.1 Get-Jobs Request the
         Validate-Job Response neither are there any Job Status attributes
         returned in the response.  The client submits the Get-Jobs request to MAY include a "document-uri"
         attribute in the request.  In this case, the Printer URI.

         The following input parameters are part SHOULD only
         validate the syntax of the Get-Jobs Request:

           "printer-uri" (uri):
              The URI of rather than follow the target printer.

           "limit" (integer):
              This is an integer value that indicates a limit to reference and
         validate the number contents of
              Jobs returned.  The limit is a "stateless limit" in that if the
              limit reference. If all is n then only well, the first n jobs are returned in Printer
         returns the Get-
              Jobs Response; there status code "successful-ok".  Otherwise, the Printer
         returns a set of unsupported attributes and the appropriate error
         status code.

         3.2.4 Create-Job Operation

         This operation is no mechanism similar to allow for the "next" n
              jobs.  The limit applies across all Job States requested.  For
              example, if Print-Job operation (section 3.2.1)
         except that a client supplies no document data or any reference to
         document data in the limit if 50, and there are 75 spooled jobs, only Create-Job request.  This operation is followed
         by one or more Send-Document or Send-URI operations.  If a Printer
         object supports the first 50  jobs are returned; Create-Job operation, it MUST also support either
         the other 25 jobs are not
              returned.

           "requested-attributes" (1setOf keyword):
              An Send-Document operation or the Send-URI operation or both.  Since
         a client can query the Printer's "operations-supported" attribute, a
         client SHOULD NOT attempt to use an unsupported optional operation.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         3.2.5 Get-Attributes Operation

         The Printer Get-Attributes operation allows a client to obtain
         information from a Printer object. In the operations attributes in a
         request, the client supplies the set of Job attribute names or and/or
         attribute groups group names in whose values which the requester is interested.  This set of
              attributes is returned for each Job that is returned..  The
              attribute group names are the same as for  In the Get-Attributes
         operation for the Job object.  If attribute in the client omits this input
              parameter, response, the Printer SHALL respond as if this input parameter
              had been supplied with returns a value of " 'job-uri'.

         3.2.7.2 Get-Jobs Response

         The Printer SHALL return
         corresponding attribute set with the following output parameters as part appropriate attribute values
         filled in.

         For Printers, the attribute groups include:

           - 'job-template': all of the Get-Jobs Response:

           Requested Attributes:
              The result includes zero or more Job objects each with zero or
              more attributes.  Jobs are returned 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 to expected completion time) followed by all
              completed Jobs (Jobs in the 'completed', 'aborted', or 'canceled'
              states) newest to oldest (with respect to actual completion
              time).  Jobs that are in the 'pending-held' state SHALL appear in
              their position as if they were 'pending' (otherwise, a user might
              be confused by Jobs Template attributes that move from 'pending-held' to 'pending' as
              seeming apply to jump ahead in the queue).

                                Expires January 25, 1998
         3.3 Job Operations

         3.3.1 Send-Document Operation

         Once
              a Job Printer object has been created using a Create-Job operation
         (returning a "job-uri"), a client directs a Send-Document operation to (the last two columns of the newly create Job object.  The operation adds a new Document to table in Section
              4.2).
           - 'printer-description': the
         Job object. An entire document MUST be sent attributes specified in a single Send-Document
         Request.

         3.3.1.1 Send-Document Request

         The client submits Section 4.5.

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

         It is NOT REQUIRED that a Printer support all attributes belonging to
         a Job URI. group, however it is MANDATORY that each Printer implementation
         understand all group names.

         3.2.5.1 Get-Attributes Request

         The following abstract data types sets of attributes are part of the Send-Document
         Request:

           "job-uri" (uri):
              The URI of Get-Attributes
         Request when the target Job.

           Document Attributes: request is directed to a Printer object:

           Operation Attributes"requested-attributes" (1setOf keyword) :
              An optional set of Document Description attributes (section 4.4).

           Last Document Flag ("last-document"):
              This is a boolean flag that attribute names (without values) or attribute
              group names in whose values the requester is set to 'true' interested.  If the
              client omits this input parameter, the Printer SHALL respond as
              if this input parameter had been supplied with a value of 'all'.

           "document-format" (mimeType) :
              This input parameter is the last
              Document useful for determining the Job.

           Document Content:
              The client supplies set of
              supported attribute values which relate to the requested document data.

         3.3.1.2 Send-Document Response
              format.  The following output parameters Printer SHALL return only (1) those attributes that
              are part of the Send-Document
         Response:

           Job Status:
              (see section 3.2.2.2)

           Unsupported Attributes:
              (see section 3.2.2.2)

         3.3.2 Send-URI Operation

         This operation is identical to supported and (2) the Send-Document operation (see
         section 3.3.1) except attribute values that a client supplies a URI reference
         ("document-uri") rather than are supported for
              the specified document data itself.  It is up to

                                Expires January 25, 1998 format.  By specifying the IPP server document
              format, the client can get the Printer to interpret eliminate the URI
              attributes and subsequently "pull" the values that are not supported for a specific
              document from the source referenced by the URI string.

         3.3.3 Cancel Job Operation

         This operation allows format.  For example, a user Printer might have multiple
              interpreters to cancel support both 'application/postscript' (for
              PostScript) and 'text/plain' (for text) documents.  However, for
              only one specific Print Job any time
         after of those interpreters might the print job has been established on Printer be able to
              support "number-up" with values of 'one', 'two', and 'four'.  For

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              the Printer.  Some pages
         may other interpreter it might be printed before able to only support "number-
              up" with a job is terminated if printing has already
         started when value of 'one'.

              If the client omits this input parameter, the Cancel Job operation is received. The Printer
         determines via SHALL
              respond as if the security layer (authentication) and administrative
         policy input parameter had been set outside to the scope value of IPP (authorization) whether or not to
         allow
              the Cancel-Job operation.

         3.3.3.1 Cancel-Job Request

         The client submits Printer's default value "document-format" attribute were
              supplied.  It is recommended that the request to client always supply a Job URI.

         The following abstract data types
              value for document-format, since the Printer's default value for
              document-format may be 'langAutomatic', in which case the
              returned attributes and values are part of for the Cancel Job Request:

           "job-uri" (uri):
              The URI union of the target Job.

           "message" (text):
              Optional message to document
              formats that the operator

         3.3.3.2 Cancel-Job Response

         There are no output parameters other Cancel Job Printer can automatically sense.

              ISSUE: What about MIME types.

         3.2.5.2 Get-Attributes Response other than

         The Printer returns the following sets of attributes as part of the Status Code and optional Status Message.

         3.3.4
         Get-Attributes Response:

         Requested Attributes

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

         3.2.6 Get-Jobs Operation

         The Get-Attributes Get-Jobs operation allows a client to obtain information
         from a Job object and it is almost identical retrieve the list of Jobs
         belonging to the Get-Attributes
         operation for a target Printer object (see section 3.2.6). object.  The only
         differences are that the operation is directed at a Printer URI rather
         than a Job URI and there is no Document Format input parameter used
         for querying a Job object.. In an input parameter, the client supplies
         the set may also supply a
         list of Job attribute names and/or or attribute group names names.  These Job
         attributes will be returned for each Job that the
         requester is interested in.

         3.3.4.1 Get-Attributes Request

                                Expires January 25, 1998
         4. Object Attributes returned.

         This section describes the attributes with their corresponding
         syntaxes and values operation is like Get-Attributes, except that are part of the IPP model. The sections below
         show the objects and their associated Get-Jobs operation
         returns attributes which are included
         within from possibly more than one object (see the scope of this protocol.  Many
         description 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 attribute is uniquely identified groups in this document using a
         "keyword" (see section 10.2.1). 3.3.4).

         3.2.6.1 Get-Jobs Request

         The keyword is included in client submits the
         section header describing that attribute. Not only are attributes
         uniquely identified with keywords, some attributes are defined Get-Jobs request to have
         a syntax which is a set of keywords.

         4.1 Attribute Syntaxes Printer URI.

         The following table shows the basic syntax types that a client and
         server SHALL be able to handle.

           text:  a sequence sets of characters, length: 0 to 4095,  where each
              character is a member attributes are part of the UCS-2 coded character set.. Get-Jobs Request:

         Operation Attributes

           "limit" (integer):
              This
              syntax type is used for free form human readable text intended
              for human consumption. The default encoding for attributes an integer value that indicates a limit to the number of
              type "text"
              Jobs returned.  The limit is the UTF8 encoding rules.  However, a "stateless limit" in that if the
              attribute "content-char-set"

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              limit is set to a value of type "char-set" n then that value describes the encoding rules used for text
              attributes.

           name:  this is only the same a "text" except that first n jobs are returned in the sequence of
              characters Get-
              Jobs Response; there is of length 1 no mechanism to 255  This syntax type is used allow 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.

           keyword:  a sequence of characters, length: 1 to 255, containing
              only the characters ASCII lowercase letters ("a" - "z"), ASCII
              digits ("0" - "9"), hyphen ("-"), dot ("."), and underscore
              ("_"). "next" n
              jobs.  The limit applies across all Job States requested.  For
              example, if the limit if 50, and there are 75 spooled jobs, only
              the first character MUST be an ASCII lowercase letter.
              This syntax type is used for enumerating semantic identifiers of

                                Expires January 25, 1998
              entities in 50  jobs are returned;  the abstract protocol (specified in this document).
              These entities can be other 25 jobs are not
              returned.

           "requested-attributes" (1setOf keyword):
              An optional set of Job attribute names or values of attributes.
              When a keyword is used to represent an attribute (its name), it
              MUST be unique within groups names
              in whose values the full scope of IPP objects and
              attributes.  When a keyword requester is used to represent a value of an
              attribute, it MUST be unique just within the scope interested.  This set of
              attributes is returned for each Job that
              attribute.  That is, is returned..  The
              attribute group names are the same keyword can not be used as for two
              different values within the same attribute to mean two different
              semantic ideas.  However, the same keyword can be used across two
              or more attributes, representing different semantic ideas Get-Attributes
              operation for
              each attribute.

           enum:  an enumerated integer value that is in the range from -2**31
              to 2**31 - 1.   Each value has an associated keyword name.  Each
              attribute (whose syntax is enum) enumerates Job object.  If the values that are
              defined for client omits this input
              parameter, the attribute. 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 enum type Printer returns zero or more Job objects each with zero or more
         attributes.  There is used for a set of requested attributes for which each Job.
         After each Job, there are enum values assigned by other standards, such
              as SNMP MIBs.  A number is a set of attribute enum values in this
              specification are also used for corresponding requested attributes for each
         Document in the
              IETF Printer MIB [1] and the Job.  For example:

              Job Monitoring MIB [27].  Enums 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
              not used for attributes to which returned in the system administrator may
              assign values.  Values following order: First all active Jobs (Jobs
         in the range 2**30 to 2**31 - 1 'pending', 'processing', 'pending-held', and 'processing-
         stopped' states) are
              reserved for private returned oldest to newest (with respect to
         expected completion time).  Next, all completed Jobs (Jobs in the
         'completed', 'aborted', or experimental use.  Implementers are
              warned 'canceled' states) newest to oldest (with
         respect to actual completion time).  Jobs that use of such values may conflict with other
              implementations.  Implementers are encouraged to request
              registration of enum values following in the procedures 'pending-
         held' state SHALL appear in Section
              6.

           uri:  a sequence of characters their position as defined in rfc1738 and rfc1808.
              This syntax type is used for carrying Universal Resource
              Identifiers.

           uriScheme:  a sequence of characters representing the URI Scheme.
              These include 'http' for HTTP schemed URIs (e.g., http://...),
              and 'ftp' for FTP schemed URIs (e.g., ftp://...).

           human-language:  a standard identifier for human language and
              optionally if they were 'pending'
         (otherwise, a country.  The values for this syntax type are taken user might be confused by Jobs that move from RFC 1766 [26].  RFC 1766 does not have provision for
              expressing the coded character set component of a locale.  The
              "content-char-set" attribute contains a value which represents
              the encoding rules used.  If "content-char-set" is not supported,
              the coded character set used 'pending-
         held' to 'pending' as seeming to jump ahead in the IPP protocol MUST be UTF-8
              [28].

           char-set:  a standard identifier the character set used queue). Note:  Jobs
         are returned in the
              encoding of attributes of type "text". The values for this syntax
              type are taken from RFC 2130 [31]. following order:

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
           octetString:  a sequence of octets.  This syntax type is used for
              opaque data, such as
           First, all active Jobs (Jobs in the document-content.

           boolean:  two values of 'true' 'pending', 'processing',
              'pending-held', and 'false'.  This syntax type is
              like a keywordSet, but there 'processing-stopped' states) are only two values. Note: An
              application might use a checkbox for an attribute with this
              syntax type.

           integer:  an integer value that is returned
              oldest to newest (with respect to expected completion time),
              followed by
           Second, all completed Jobs (Jobs in the range from -2**31 'completed', 'aborted', or
              'canceled' states) newest to
              2**31 - 1.  Each attribute specifies oldest (with respect to actual
              completion time).  Jobs that are in the range constraint
              explicitly 'pending-held' state
              SHALL appear in their position as if the range is different they were 'pending'
              (otherwise, a user might be confused by Jobs that move from
              'pending-held' to 'pending' as seeming to jump ahead in the full range
              queue).

         3.3 Job Operations

         The target of
              possible integer values (e.g., 0 - 100 for Job operations are Job objects.  Since Job objects are
         identified with both the "job-priority"
              attribute).

           dateTime:  a standard, fixed length representation of date Printer's URI and time the "job-id" attribute, the
         following applies rules apply to all Job operations:

           - The Printer's URI is encoded at the transport level the same as defined in RFC 1514 [32] and RFC 1903 [33].

           resolution:  a special syntax used only
              all Printer operations
           - The "job-id" attribute is included as an operation attribute for "printer-resolution"
              and "printer-resolution-supported"  It consists of 3 parts:
              all Job operations.
         3.3.1 Send-Document Operation

         Once a
              cross feed direction resolution (positive integer value), Job object has been created using a feed
              direction resolution (positive integer value) and Create-Job operation
         (returning a units value.
              All these are taken from the Printer MIB [1] suggested values.

           1setOf  X:  1 or more values of type X.  This syntax type is used
              for multi-valued attributes, whose value is "job-uri"), a set of values.
              Note: client directs a Send-Document operation to
         the newly create Job object.  The syntax type is called "1setOf" operation adds a new Document to indicate that set of
              values SHALL NOT the
         Job object. An entire document MUST be empty (a set of size 0).

           rangeOf  X:  a range of value sent in a single Send-Document
         Request.

         3.3.1.1 Send-Document Request

         The client submits the request to a Job URI.

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

         Operation Attributes:

           "document-name" (name):
              This syntax type OPTIONAL attribute identifies the client supplied Document
              name.  If this attribute is supplied, its value it used for ordered values (numeric, lexical, etc.) such as integers.

         4.1.1 Attribute Extensibility

           This document uses prefixes to the "keyword" and "enum" basic
           syntax type in order to communicate extra information
              "document-name" attribute of the newly created Document object.
              If this attribute is not supplied by the client, the Printer
              optionally generates a name to use in the reader
           through its name. "document-name"
              attribute of the newly created Document object (see Section ??).

           "last-document" (boolean):

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              This extra information need not be represented is a boolean flag that is set to 'true' if this is the last
              Document for the Job.
         Document Attributes:

              An optional set of Document Attributes as defined in
           an implementation because it section 4.4.
              If "document-format" is unimportant not supplied, the Printer assumes that
              the document data is in a format that this acceptable 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 Printer.
           The table below describes the prefixes and their meaning.

           "type1": Send-Document Request.

         Document Content

              The IPP standard must be revised client MUST supply the document data to add a new keyword or
              a new enum.  No private keywords or enums be processed.

         3.3.1.2 Send-Document Response

         The following sets of attributes are allowed.

                                Expires January 25, 1998
           "type2":  Implementers can, at any time, add new keyword or enum
              values by proposing them to part of the IPP working group for
              registration (or an IANA-appointed registry advisor after Send-Document
         Response:

         Job Status Attributes

           "job-name":
              This is the IPP
              working group Job's "job-name" attribute.

           "job-state":
              This is no longer certified) where they are reviewed for
              approval.  IANA keeps the registry.

           "type3":  Implementers can, at any time, add new keyword and enum
              values by submitting a registration request directly to IANA, no
              IPP working group or IANA-appointed registry advisor review Job's "job-state" attribute. The value of  this
              attribute is
              required.

           "type4":  Anyone (system administrators, system integrators, site
              managers, etc.) can, at any time, add new installation-defined
              values (keywords or taken from a "snapshot" of the new enum values) Job object
              sometime after the time the Printer receives the print request
              until just prior to a local system. Care
              SHOULD be taken by returning the implementers response to see that keywords do not
              conflict with other keywords defined by the standard or as
              defined by client.

           "job-state-reasons":
              This is the implementing product. There Job's "job-state-reasons" attribute.  The value of
              this attribute is no registration or
              approval procedure for type 4 keywords.

         By definition, each taken from a "snapshot" of the four types above assert some sort of
         registry or review process in order for extensions new Job object
              sometime after the time the Printer receives the print request
              until just prior to be considered
         valid.  Each higher level (1, 2, 3, 4) tends returning the response to be decreasingly less
         stringent than the previous level.   Therefore, any typeN value MAY be
         registered using a process for some typeM where M client.

           "job-state-message":
              This is less than N,
         however such registration the Job's "job-state-message" attribute.  Since the "job-
              state-message" attribute is NOT REQUIRED.  For example, a type4 value
         MAY be registered in a type 1 manner (by being OPTIONAL Job attribute, itis
              OPTIONALLY included in the response.

         Unsupported Attributes:

              This is a future
         version set of an IPP specification) however it is NOT REQUIRED.

         This specification defines keyword attributes and enum attribute 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 that are
              unsupported.  This output parameter is the (lowercase) fully qualified company name registered with
         IANA for use only returned in domain names [30].

         Note: RFC 1035 [30] the

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              response if the status code indicates that while upper and lower case letters
         are allowed in domain names, no significance there was such an
              error.

         3.3.2 Send-URI Operation

         This operation is attached identical to the case.
         That is, two names with Send-Document operation (see
         section 3.3.1) except that a client supplies a URI reference
         ("document-uri" operation attribute) rather than the same spelling but different case are document data
         itself.  It is up to be
         treated as if identical.  Also, the labels in a domain name must
         follow IPP server to interpret the 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, URI and hyphen.  Labels must be 63 characters or
         less.  Lables are separated
         subsequently "pull" the document from the source referenced by the "." character.

                                Expires January 25, 1998
         For private (unregistered) enum extension, implementers SHOULD use
         values in the reserved integer range (see "enum").

         4.2 URI
         string.

         3.3.3 Cancel Job Template Attributes Operation

         This operation allows a client to cancel a Print Job Template attributes describe any time after
         the print job processing behavior.  Take for
         example, has been submitted to the Printer.  Since a generic Job Template attribute called "xxx":

           1. "xxx" is optionally supplied might
         already be printing by the client in time a create request.
              If "xxx" Cancel-Job is supplied, received, some pages
         may be printed before the client job is specifying that actually terminated.

         3.3.3.1 Cancel-Job Request

         The client submits the Printer
              SHALL apply a specific job processing behavior request to this job while
              processing a Job URI.

         The following attribute sets are part of the Job.  When "xxx" is not supplied by Cancel Job Request:

         Operation Attributes

           "message" (text):
              Optional message to the client, operator

         3.3.3.2 Cancel-Job Response

         There are no attributes in the Printer applies Cancel Job Response other than the default job processing behavior.

           2. "xxx-supported" is a Printer attribute that describes which
              behaviors are supported by a Printer.  "xxx-supported" is
         Status Code and optional Status Message.  Once a
              CONDITIONALLY MANDATORY attribute, successful response
         has been sent, the implementation guarantees that is the "xxx-supported"
              attribute is MANDATORY if Job will
         eventually end up in the Printer is capable of realizing two
              or more of 'cancelled' state.  If the behaviors associated with implementation is
         forced to leave the attribute and its
              values.  A client can query job in the Printer and find out what
              behaviors are supported by inspecting some other state, the values of "job-state-
         reasons" SHOULD contain the "xxx-
              supported" attribute.

           3. The Printer also supports a default value attribute named "xxx".
              This default 'processing-to-stop-point' value attribute describes what will be done when no
              other job processing information is supplied by which
         indicates to later queries that although the client
              (either explicitly as an IPP attribute Job may still be
         'processing', it will eventually end up in the create request or
              implicitly as an embedded instruction within the job data).
              Along with the supported attribute, the default value attribute
              is also CONDITIONALLY MANDATORY.  However, if the Printer
              supports either the "xxx" default value attribute or the "xxx-
              supported" attribute, 'cancelled' state, not
         the Printer MUST support both.

           4. If 'completed' state.

         3.3.4 Get-Attributes Operation

         The Job Get-Attributes operation allows a client application wishes to present an end user with obtain information
         from a
              list of supported Job object and default values from which it is almost identical to choose, the
              client program SHOULD query the Printer Get-Attributes

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         operation for a Printer object (see section 3.2.5).  The only
         differences are that the supported operation is directed at a Job rather than a
         Printer and
              default value attributes. The values 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 client then
              supplies table in Section 4.2).
           - 'job-description': the create request will all fall within attributes specified in Section 4.3.

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

         There is another special group named 'document-attributes' which
         consists of the Printer.  When querying the Printer, Document Attributes described in section 4.4. If any
         Document Attributes are requested, the client MAY
              enumerate response contains a separate
         set of Document attributes for each attribute by name Document in the Job.

         3.3.4.1 Get-Attributes Request,
              or the client MAY just name the "job-template" group in order to
              get the complete set of supported and default value attributes
              which are supported. Request

         The "job-priority" following attribute is an example sets are part of a Job Template
         attribute.  It is an integer in the range from 1 to 100.  A client can
         query the Printer for the "job-priority-supported" attribute and Get-Attributes Request
         when the

                                Expires January 25, 1998
         "job-priority" default value attribute.  The supported attribute
         contains a range of supported priority values which request is equal directed to or
         smaller than the maximum range a Job object:

         Operation Attributes:

           "requested-attributes" (1setOf keyword) :
              An optional set of 1 to 100.  The default value attribute contains the job priority value that will be used for a new
         job if the client does not supply one names (without values) or attribute
              group names in whose values the create request. requester is interested.  If the
              client does supply the "job-priority" omits this attribute, the Printer validates
         the SHALL respond as if this
              input parameter had been supplied with a value to make sure that it falls within the range of supported
         values.  If 'all'.

         3.3.4.2 Get-Attributes Response

         The implementation returns the client-supplied value is supported, following response attributes as part
         of the Get-Attributes Response:

         Job object Attributes:

              This is
         created and the "job-priority" attribute is populated with that value. set of requested attributes and their current values.
              The Job object, when queried, returns the value supplied by the
         client.  If the client does implementation ignores (does not supply a "job-priority" value in the
         create request, the Job object is created, but no "job-priority" respond with) any requested
              attribute which is not supported.

         Document Attributes:

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              This is associated with the Job.  The client queries the
         Printer's default value "job-priority" value to find out at what
         priority the job will be processed.

         The table below summarizes the names, relationships, set of requested attributes and conformance
         requirements for all Job Template attributes. their current values.
              The following general
         rules apply to implementation requirements:

           1. In a create request, all Job Template attributes are optionally
              supplied by the client.

           2. In a Printer Object, all supported attributes ("xxx-supported")
              are CONDITIONALLY MANDATORY.

           3. All Printer default value attributes ("xxx") are CONDITIONALLY
              MANDATORY.

           Note:  If the Printer implements either the default value ignores (does not respond with) any requested
              attribute
              or the supported values attribute, the Printer MUST also
              implement the other and vice versa.

         The table only shows exceptions to the above rules.   The first column
         of the table (Job) shows the name and syntax which is not supported.  One set is returned for each Job Template
         attribute
              Document in the Job object.. All of Job.

         4. Object Attributes

         This section describes the attributes in the first
         column make up with their corresponding
         syntaxes and values that are part of the "job-template" group. IPP model. The last two columns sections below
         show the name objects and syntax for each Job Template attribute in their associated attributes which are included
         within the scope of this protocol.  Many of these attributes are
         derived from other relevant specifications:

           - ISO/IEC 10175 DPA (Final, June 1996) [5]
           - RFC 1759 Printer
         object (the default value attribute and the supported attribute).  A
         "No" in the table means the MIB (Proposed Standard, May 1995) [1]
           - Internet-Draft: Printer SHALL NOT support the attribute.
         A "MAN" indicates that it is MANDATORY that MIB (Draft Standard in progress, July
              1997) [29]
           - Internet-Draft: Job Monitoring MIB (I-D in progress, June 1997)
              [27]

         Each attribute is uniquely identified in this document using a
         "keyword" (see section 11.2.1).  The keyword is included in the
         section header describing that 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 the basic syntax types that a client and server
         SHALL be able to handle.  These are considered to be a set of type2
         enum values.  The values are:

           '1'     'text':  a sequence of characters, length: 0 to 4095,  where
                        each character is a member of the ISO 10646 [??] coded
                        character set using the UTF-8 character encoding scheme
                        [28]..  This syntax type is used for free form human
                        readable text intended for human consumption.
           '2'     'name':  this is the same a "text" 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 support name, a
                        document name, a user name, or a host name.
           '3'     'keyword':  a sequence of characters, length: 1 to 255,
                        containing only the
         attribute. characters ASCII lowercase letters
                        ("a" - "z"), ASCII digits ("0" - "9"), hyphen ("-"),
                        dot ("."), and underscore ("_").  The first character

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
           +-------------------+----------------------+----------------------+
           |    Job            |Printer: Default Value|  Printer: Supported  |
           +===================+======================+======================+
           | job-sheets        | job-sheets           |job-sheets-supported  |
           | (type4 keyword)   | (type4 keyword)      |(1setOf type4 keyword)|
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           | notify-events     |
                        MUST be an ASCII lowercase letter.  This syntax type is
                        used for enumerating semantic identifiers of entities
                        in the abstract protocol (specified in this document).
                        These entities can be attribute names or values of
                        attributes.  When a keyword is used to represent an
                        attribute (its name), it MUST be unique within the full
                        scope of IPP objects and attributes.  When a keyword is
                        used to represent a value of an attribute, it MUST be
                        unique just within the scope of that attribute.  That
                        is, the same keyword can not be used for two different
                        values within the same attribute to mean two different
                        semantic ideas.  However, the same keyword can be used
                        across two or more attributes, representing different
                        semantic ideas for each attribute.
           '4'     'enum':  an enumerated integer value that is in the range
                        from -2**31 to 2**31 - 1.   Each value has an
                        associated keyword name.  Each attribute (whose syntax
                        is enum) enumerates the values that are defined for the
                        attribute.  The enum 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 the IETF Printer MIB [1]
                        and the Job Monitoring MIB [27].  Enums are not used
                        for attributes to which the system administrator may
                        assign values.  Values in the range 2**30 to 2**31 - 1
                        are reserved for private or experimental use.
                        Implementers are warned 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 the URI
                        Scheme.  These include 'http' for HTTP schemed URIs
                        (e.g., http://...), and 'ftp' for FTP schemed URIs
                        (e.g., ftp://...).
           '7'     'human-language':  a standard identifier for human language
                        and optionally a country.  The values for this syntax
                        type are taken from RFC 1766 [26].  Independent of the
                        human language, all text strings are strings of
                        characters where each character is a member of the ISO
                        10646 [??] coded character set.  Text strings are
                        encoded using the UTF-8 character encoding scheme [28]
           '8'     'octetString:'  a sequence of octets.  This syntax type is
                        used for opaque data, such as the document-content.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           '9'     'boolean':  two values of 'true' and 'false'.  This syntax
                        type is like a keywordSet, but there are only two
                        values. Note: An application might use a checkbox for
                        an attribute with this syntax type.
           '10'    'integer':  an integer value that is in the range from -
                        2**31 to 2**31 - 1.  Each attribute specifies 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).
           '11'    'dateTime':  a standard, fixed length representation of date
                        and time as defined in RFC 1514 [32] and RFC 1903 [33].
           '12'    'resolution':  a special syntax used only for "printer-
                        resolution" and "printer-resolution-supported"  It
                        consists of 3 parts:  a cross feed direction resolution
                        (positive integer value), a feed direction resolution
                        (positive integer value) and a units value.  All these
                        are taken from the 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 a
                        set of values.  Note:  The syntax type is called
                        "1setOf" to indicate that set of values SHALL NOT be
                        empty (a set of size 0).

           '15'    'rangeOf  X':  a range of value 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.  Job
         Template attributes are OPTIONAL (see section 11.2.3 for a description
         of support for OPTIONAL attributes).

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

           1. The Printer supports a "foo-supported" attribute that describes
              which job processing behaviors are supported by 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 named "foo".
              This default value attribute describes what will be done when no
              other job processing information is supplied by the client

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              (either explicitly as an IPP attribute in the create request or
              implicitly as an embedded instruction within the job data).
              However, if the Printer supports either the "foo" default value
              attribute or the "foo-supported" attribute, the Printer MUST
              support both.

           3. "foo" is also optionally supplied by the client in a create
              request.  If "foo" is supplied, the client is specifying that the
              Printer SHALL apply thecorresponding 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.  Since an administrator could change the
              default value after the Job has been submitted (while it is
              waiting to be processed), the default value in affect a job
              processing time is used for processing a Job with no client
              supplied attribute.

         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, application
         guarantees 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 supported
         attributes (both supported value and default value attributes).

         The "job-priority" attribute is an example of a Job Template
         attribute.  It is an integer in the range from 1 to 100.  A client can
         query the Printer for the "job-priority-supported" attribute and the
         "job-priority" default value attribute.  The supported attribute
         contains a range of supported priority values which is equal to or
         smaller than the maximum range of 1 to 100.  The default value
         attribute contains the job priority value that will be used for a new
         job if the client does not supply a value in the create request.  If
         the client does supply the "job-priority" attribute, the Printer
         validates the value to make sure that it falls within the range of
         supported values.  If the client-supplied value is supported, the Job
         object is created and the "job-priority" attribute is populated with
         that value.  The Job object, when queried, returns the value supplied
         by the client.  If the client does not supply a "job-priority" value
         in the create request, the Job object is created, but no "job-
         priority" attribute is associated with the Job.  The client queries
         the Printer's default value "job-priority" value to find out at what
         priority the job will be processed.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         The table below summarizes the names and relationships for all Job
         Template attributes. The first column of the table (labled "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 (labled
         "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
         (the attribute is simply not applicable).    The second part of the
         table lists Document level attributes.  Document level attributes have
         the same semantics as Job Template

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           +===================+======================+======================+
           | Job Attribute     |Printer: Default Value|  Printer: Supported  |
           |                   |   Attribute          |   Values Attribute   |
           +===================+======================+======================+
           | job-sheets        | job-sheets           |job-sheets-supported  |
           | (type4 keyword)   | (type4 keyword)      |(1setOf type4 keyword)|
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           | notify-events     | notify-events        | notify-events-       |
           |(1setOf            |(1setOf type2 keyword)| supported            |
           | type2 keyword)    |                      |(1setOf type2 keyword)|
           +-------------------+----------------------+----------------------+
           |notify-addresses   | No                   |notify-addresses      |
           |(1setOf uri)       |                      |-supported            |
           |                   |                      |(1setOf uriScheme)    |
           +-------------------+----------------------+----------------------+
           | job-priority      | job-priority         |job-priority-supported|
           | (integer 1-100)   | (integer 1-100)      |(rangeOf integer      |
           |                   |                      | 1-100)               |
           +-------------------+----------------------+----------------------+
           | job-hold-until    | 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)   | (type2 keyword)      |(1setOf type2 keyword)|
           +-------------------+----------------------+----------------------+
           | media             | 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
                               Expires January 25, February xx, 1998
           +-------------------+----------------------+----------------------+
           | finishings        | finishings           | finishings-supported |
           |(1setOf type2 enum)|(1setOf type2 enum)   |(1setOf type2 enum)   |
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           | copies copies            | copies               | copies-supported     |
           | (integer: 1 - MAX)| (2setOf integer      | (2rangeOf integer    |
           |                   |     1 - MAX)         |     1- MAX)          |
           +-------------------+----------------------+----------------------+
           | page-range        | No                   | page-range-          |
           | (rangeOf integer) |                      | supported (boolean)  |
           |                   |                      |                      |
           +===================+======================+======================+
           |                                                                 |
           | Note: The following attributes are Document attributes, they    |
           |       have the same semantics a Job Template attributes,        |
           |       however they apply to each Document object rather than    |
           | copies       at the Job level as Job object attributes.                | copies-supported
           |                                                                 | (integer: 1 - MAX)| (integer: 1 - MAX)
           +===================+======================+======================+
           | (rangeOf integer Document          |Printer: Default Value|  Printer: Supported  |
           | Attribute         |   Attribute          |     1- MAX)   Values Attribute   |
           +-------------------+----------------------+----------------------+
           +===================+======================+======================+
           | document-format   | document-format      | document-format-     |
           | (type2 enum) (mimeType)        | (type2 enum) (mimeType)           | supported            |
           |                   |                      |(1setOf type2 enum) mimeType)     |
           +-------------------+----------------------+----------------------+
           | compression       | No                   | compression-supported|
           | (type3 keyword)   |                      |(1setOf type3 keyword)|
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           | job-k-octets document-k-octets | No                   |job-k-octets-supported|
           | (integer)         |                      | (rangeOf integer)    |
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           | job-impressions document-         | No                   | job-impressions-     |
           | (integer) impressions       |                      | supported            |
           | (integer)         |                      | (rangeOf integer)    |
           +-------------------+----------------------+----------------------+
           | job-media-sheets document-media-   | No                   | job-media-sheets-    |
           | (integer) sheets            |                      | supported            |
           | (integer)         |                      | (rangeOf integer)    |
           +-------------------+----------------------+----------------------+

         4.2.1 job-sheets (type4 keyword)

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

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         Standard values are:

           '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

         To force no job sheets, the system administrator SHALL set the
         supported value to only 'none'.  To force the use of banner pages, the
         supported values SHALL not include 'none'.  In this case, if a client
         requests 'none', the create request is rejected.

                                Expires January 25, 1998

         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 the end user desires
         some sort 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 any of the events occur.
           'job-completion':  the Printer SHALL notify when the job containing
              this value completes (i.e., enters the 'completed', 'canceled',
              or 'aborted' state) with or without errors.
           'job-problems':  the Printer SHALL notify when this job has a
              problem while this job is processing (i.e., when the Job moves
              from job leaves the 'processing' to state and
              enters the 'processing-stopped' state or from state).
           'job-started-processing':  the Printer SHALL notify when the
              Printer starts processing the Job (i.e., when the job leaves the
              'pending' to 'pending-held').  Problems also can include any of state and enters the "job-state-reasons" or "printer-state-reason" values.

           ISSUE: All or none or some "xxx-reasons"?? 'processing' state).
           'printer-problems': the Printer SHALL notify when this job is
              affected by a Printer problem.  This happens when the printer
              enters the 'stopped' state while this job is in the 'pending',
              'pending-held', 'processing', or 'processing-stopped' state.  If

           ISSUE: Need to add generic alerts from the Printer enters 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 'stopped' state, absolute time
                           of the reason is in event>CRLF
              event: <keyword for the event>CRLF
              printer-uri: <Printer's URI>CRLF
              printer-state: <keyword for printer state>CRLF
              *printer-state-reason: <set 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 the event notification are intended for machine
         consumption more than human consumption, however the
              "printer-state-reasons" attribute.

           ISSUE: Do you really need this last sentence. That is, should this
              document state what information an implementation should use of US ASCII
         enables humans to
              compose retrieve some semantics from the event report
         itself.  Items above marked with and asterisk ('*') are optional.  If
         the implementation does not support any notion of time, then field is
         not present in the notification message. body.  If the event is Printer
         related, only the Printer related fields are included.  If the event
         is Job related, all of the Job fields SHOULD be included.

         4.2.3 notify-addresses (1setOf uri)

         This attribute describes both where (the address) and how (the
         mechanism for delivery ) events are to be delivered. The Printer SHALL
         use this attribute as the set of addresses and methods for sending
         messages when an event occurs that the end user (job submitter) has
         registered an interest in.

         Standard uriScheme values are:

                                Expires January 25, 1998

           'mailto': the Printer sends a  text message via email to the
              specified email address
           'http': the Printer sends an HTML formatted message via an HTTP
              POST method to the specified URI
           'ftp': the Printer sends a text message via an FTP `append' command
           to the specified remote file.

         4.2.4 job-priority (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 mapping of vendor-defined
         priority over this range is implementation-specific.

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

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

         Standard values for named time periods are:

           'no-hold': 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.

         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.

                                Expires January 25, 1998

         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.

         4.2.6 multiple-document-handling (type2 keyword)

         This job attribute is relevant only if a job consists of two or more
         documents. It controls finishing operations, and job-sheet placement.
         When the copies attribute exceeds 1, it also controls the order of
         documents..

         Standard values are:

           'single-document': If the files for the 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
                               Expires February xx, 1998
              and b and the Printer SHALL NOT force each document to start on a
              new page or new media sheet.  If more than one copy is made, the
              ordering SHALL be a, b, a, b, ...., and the Printer SHALL force
              each copy to start on a new sheet.
           'separate-documents-uncollated-copies': If the files for the job
              are a and b, then each file SHALL be treated as a single document
              for finishing operations. Also, a client may specify that a slip
              sheet be placed between files a and b and the Printer shall force
              each document copy to start on a new sheet.  If more than one
              copy is made, the ordering SHALL be a, a, b, b, ....
           'separate-documents-collated-copies': If the files for the job are
              a and b, then each file SHALL be treated as a single document for
              finishing operations. Also, a client may specify that a slip
              sheet be placed between files a and b. If more than one copy is
              made, the ordering SHALL be a, b, a, b, ...., and the Printer
              shall force each document copy to start on a new sheet

         4.2.7 media (type4 keyword)

         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 which 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

                                Expires January 25, 1998
         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 which 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 data from the document as its prints each
         page.

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

         Standard values are (taken from ISO DPA and the Printer MIB) and are
         listed in section 13. 14.

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

         This job attribute specifies the number of source page-images to
         impose upon a single side of an instance of a selected medium.

         Standard values are:

           'none': The Printer SHALL not include any embellishments and SHALL
              place one logical page on a single side of an instance of the
              selected medium without any translation, scaling, or rotation.
           'one': The Printer SHALL place one logical page on a single side of
              an instance of the selected medium (MAY add some sort of
              translation, scaling, or rotation).
           'two': 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).
           'four': 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.

         4.2.9 sides (type2 keyword)

         This attribute specifies how source page-images are to be imposed upon
         the sides of an instance of a selected medium.

         The standard values are:

           '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,

                                Expires January 25, 1998
              such that the orientation of each pair of source-pages on the
              medium would be correct for the reader as if for binding on the
              long edge.  This imposition is sometimes called 'duplex'.
           '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

         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 that Printer uses for a
         certain Job.

           The value is a special type consisting of a pair of integers and a
              value which specifies the units for the two integers. The three
              values are the same as those specified in the draft-ietf-
              printmib-mib-info-02.txt as prtMarkerAddressabilityFeedDir (the
              resolution in the feed direction),
              prtMarkerAddressabilityXFeedDir (the resolution in the cross feed
              direction), and prtMarkerAddressabilityUnit (the units of the
              first two values, namely dots per inch and dots per centimeter).
         4.2.11 print-quality (type2 enum)

         This attribute specifies the print quality that the Printeruses Printer uses for a
         certain Job.

         The standard values are:

           'draft' (3):

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

         4.2.12 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 _copy_ for purposes of
         finishing.

                                Expires January 25, 1998

         Standard values are:

           'none'(3):

           '3'     'none':  Perform no finishing
           'staple'(4):
           '4'     'staple':  Bind the document(s) with one or more staples.
                        The exact number and placement of the staples is site-defined.
           'staple-top-left'(5): site-
                        defined.
           '5'     'staple-top-left':  Place one or more staples on the top
                        left corner of the document(s).
           'staple-bottom-left'(6):
           '6'     'staple-bottom-left':  Place one or more staples on the
                        bottom left corner of the document(s).
           'staple-top-right'(7):
           '7'     'staple-top-right':  Place one or more staples on the top
                        right corner of the document(s).
           'staple-bottom-right'(8):

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           '8'     'staple-bottom-right':  Place one or more staples on the
                        bottom right corner of the document(s).
           'saddle-stitch'(9):
           '9'     'saddle-stitch':  Bind the document(s) with one or more
                        staples (wire stitches) along the middle fold.  The
                        exact number and
              placement and placement of the stitches is site-
                        defined.
           '10'    'edge-stitch':  Bind the document(s) with one or more
                        staples (wire stitches) along one edge.  The exact
                        number and placement of the staples is site-defined.
           '11'    'punch':  This value indicates that holes are required in
                        the finished document. The exact number and placement
                        of the holes is site-defined  The punch specification
                        MAY be satisfied (in a site- and implementation-
                        specific manner) either by drilling/punching, or by
                        substituting pre-drilled media.
           '12'    'cover':  This value is specified when it is desired to
                        select a non-printed (or pre-printed) cover for the
                        document. This does not supplant the specification of a
                        printed cover (on cover stock medium) by the document
                        itself.
           '13'    'bind':  This value indicates that a binding is to be
                        applied to the document; the type and placement of the
                        binding is site-defined."

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

         This attribute specifies the number of copies to be printed.  On many
         devices the supported number of collated copies will be limited by the
         number of  physical output bins on the device, and may be different
         from the number of uncollated copies which can be supported. Therefore
         the copies-supported attribute specifies a set of ranges; the first
         defines the supported range of values for uncollated copies, and the
         second the supported range of values for collated printing.  The set
         of default values for copies specify the default number of uncollated
         copies followed by the stitches default number of collated copies.

         The effect of this attribute is site-defined.
           'edge-stitch'(10):  Bind controlled by the "multiple-documents-
         handling" attribute (section 4.2.6).This attribute specifies the document(s) with one or more staples
              (wire stitches) along one edge.  The exact
         number and placement of copies of the staples is site-defined.
           'punch'(11): job to be printed.

         4.2.14 page-range (rangeOf integer)

         This value indicates that holes attribute specifies the pages of a document which are required in to be
         printed. In most cases, the
              finished document. The exact number pages to be printed will be
         generated by a device driver and placement this attribute would not be required.
         However, when printing an archived document which has already been
         formatted, the end user may elect to print just a subset of the holes pages
         contained in the document. In this case, if page-range = n.m is
              site-defined  The punch specification MAY

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         specified, the first page to be satisfied (in a
              site- printed will be page n. All subsequent
         pages of the document will be printed through and implementation-specific manner) either by
              drilling/punching, including page m.

         Page-range supported is a boolean value indicating whether or by substituting pre-drilled media.
           'cover'(12): not the
         printer is capable of supporting the printing of page ranges.  This
         capability may differ from one PDL to another. The page-range default
         value is specified when it is desired to select
              a non-printed (or pre-printed) cover for always zero (0) and indicates that all pages of the document. This does document
         will be printed if a page-range is not supplant specified.

         4.2.15 orientation (type2 enum)

         This attribute specifies the specification orientation of a printed cover (on cover stock
              medium) the content on the output
         pages to be 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 itself.
           'bind'(13):  This value indicates that a binding formats (such as "text") do not
         support the notion of page orientation, and it is possible to be applied
              to bind the document; the type and placement of
         orientation after the binding is site-
              defined."

         4.2.13 copies (integer(1:2**31 - 1)) document content has been generated.  This
         attribute specifies the number of copies of provides an end user with the job means to specify orientation
         for such documents.

         Standard values are:

           '1'     'portrait': The content will be
         printed.

         Note: printed across the short
                        edge of the media.
           '2'     'landscape': The effect content will be printed across the long
                        edge of this attribute on job with multiple documents is
         controlled by the "multiple-document-handling" job attribute (section
         4.2.6).

         4.2.14 media.

         4.2.16 document-format (type2 enum) (mimeType)

         This attribute defines the document format for each Document in a Job. of the data to be printed.
         The standard values for this attribute are enums. MIME types.  Since the
         complete list is rather long, the full enumeration of standard values
         is found in section 12 13 APPENDIX C: "document-format" enum values.

                                Expires January 25, 1998

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

         4.2.15

         4.2.17 compression (type3 keyword)

         This attribute identifies compression algorithms used for compressed
         document data.

         ISSUE: Is this in data (not the HTTP header and an attribute is compression
         applied at both levels? operation data).

         Standard values are :

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

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           'compress': UNIX compression technology

         4.2.16

           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.  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. The For these three attributes,  the Printer may try to compute the
         value if it is not supplied in the create request.  The Printer, however, might not be  Even if the client
         does supply a value for this attribute in the create request, the
         Printer may choose to change the value if the Printer is able to
         compute this a value at the time the Job which is created.  If not, more accurate than the client supplied value.
         The Printer may support be able to determine the correct value for this
         attribute either right at any later job submission time as it is able to
         compute value.

         ISSUE: What does or at any later point in
         time.  If the value of this last sentence mean. Do we need to make attribute is unknown, the
         distinction as Printer may
         choose to whether respond with a value of '-2' (which signifies "unknown")
         rather than choose to not support the printer computes this attribute
         immediately as it is creates versus somewhat later?

         4.2.17 at all.

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

         This attribute specifies the total size number of the job in impressions.

         4.2.18 impressions for this job.

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

         This attribute specifies the total size number of the job in media-sheets.

                                Expires January 25, 1998 media sheets used by this
         job.

         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 MANDATORY attribute.
         If it is not MANDATORY, then it is OPTIONAL.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
         +----------------------------+----------------------+----------------+
         |      Attribute             |     Syntax           |   MANDATORY?   |
         +----------------------------+----------------------+----------------+
         | job-uri                    | uri                  |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | job-uri-user 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       |                |
         +----------------------------+----------------------+----------------+
         | user-content-char-set      | char-set             |                |
         +----------------------------+----------------------+----------------+
         | job-state                  | type1 enum           |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | job-state-reasons          | 1setOf type2 keyword |                |
         +----------------------------+----------------------+----------------+
         | job-state-message          | text                 |                |
         +----------------------------+----------------------+----------------+
         | output-device-assigned     | name                 |                |
         +----------------------------+----------------------+----------------+
         | time-since-pending time-at-pending            | milliseconds seconds              |  MANDATORY                |
         +----------------------------+----------------------+----------------+
         | time-since-processing time-at-processing         | milliseconds seconds              |  MANDATORY                |
         +----------------------------+----------------------+----------------+
         | time-since-completed time-at-completed          | milliseconds seconds              |  MANDATORY                |
         +----------------------------+----------------------+----------------+
         | number-of-intervening-jobs | integer              |  MANDATORY                |
         +----------------------------+----------------------+----------------+
         | job-message-from-operator  | text                 |                |
         +----------------------------+----------------------+----------------+
         | job-k-octets-processed     | integer              |                |
         +----------------------------+----------------------+----------------+
         | job-impressions-completed  | integer              |                |
         +----------------------------+----------------------+----------------+
         | job-media-sheets-completed | integer              |                |
         +----------------------------+----------------------+----------------+

         ISSUE: Should time-since-xxx and number-of jobs be MANDATORY?

         4.3.1 job-uri (uri)

         This attribute contains the URI for the job.  The Printer, on receipt
         of a new job, generates a URI which identifies the new Job on that

                                Expires January 25, 1998
         Printer. The Printer returns the value of the "job-uri" attribute as

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         part of the response to a create request.   The precise format of a
         job URI is implementation dependent.

         4.3.2 job-id (32bit unsigned integer)

         This attribute contains the ID of the job.  The Printer, on receipt of
         a new job, generates an ID which identifies the new Job on that
         Printer. The Printer returns the value of the "job-id" attribute as
         part of the response to a create request.

         ISSUE: job-uri 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 the Job.

         4.3.3

         4.3.4 job-name (name)

         This attribute is the name of the job.  It is a name that is more user
         friendly than the "job-uri" attribute value.  It does not need to be
         unique.  This  The Job's "job-name" attribute is set to the value of supplied
         by the client in the "job-name" input parameter operation attribute in the create
         request.  However,   If, however, if it is not supplied by the client in the
         create request, the Printer, on creation of the Job, SHALL generate a
         name.  The Printer can be generate the name using any method convenient
         to the name application.  The Printer MAY choose to use the value of the
         "document-name" attribute of the first (or only) Document (the "document-name" attribute) if supplied or some (or any
         other piece of Job specific information.

         4.3.4 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 be applied to the Job independent of the Job URI
         or the Job ID.  However, after reviewing the semantics of "job-name",
         the two sound identical.

         4.3.5 job-originating-user (name)

         This attribute specifies the user name of the person submitting the
         print job.  The Printer sets this attribute to the most authenticated
         name that it can obtain from the protocol over which the operation was
         received from the client.

         4.3.5

         4.3.6 job-originating-host (name)

         This attribute identifies the originating host of the job. The Printer
         sets this attribute to the most authenticated host name it can obtain

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         from the protocol over which the operation was received from  the
         client.

         4.3.6

         4.3.7 user-human-language (human-language)

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

         The Printer uses this attribute to determine the locale human language it
         SHOULD use for localizing any translating ALL text strings that it sends back to the
         end user.
         These include status messages, text attributes, and notification
         messages.

         ISSUE: should we a statement about which attributes should be
         localized. I would expect the text attributes set by the manufacturer

                                Expires January 25, 1998
         would be localized. They are: job-state-message , printer-more-info-
         manufacturer,  printer-state-message, and printer-make-and-model. I
         would expect text attribute set by a site would not be localized. They
         are job-message-from-operator, printer-location, printer-description,
         printer-message-from-the-operator.  Should there be a separate text
         type called localized-text for the 4 attributes mentioned in the
         previous issue that can be localized.  Should all "text" be localized
         text?   Unless we do something, the localization issue is left very
         vague.

         4.3.7 user-content-char-set (char-set)

         This attribute identifies encoding character set for any text
         attributes the client sends or desires to receive in IPP operations.  The Printer sets this attribute to the most reliable value it can
         obtain from the protocol over which the Print operation was received
         from the client.  If this has a "human-languages-supported" supported
         values attribute is not supported, the and a "human-language" default value UTF-8
         MUST attribute.

         ISSUE: This should be assumed.  All clients and all servers MUST support UTF-8. a Job Template attribute.

         4.3.8 job-state (type1 enum)

         This attribute identifies the current state of the job.  Even though
         the IPP protocol defines eight values for job states, implementations
         only need to support those states which are appropriate for the
         particular implementation.  In other words, a Printer supports only
         those job states implemented by the output device and available to the
         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 'pending' state as
              soon as the reasons are no longer present.  The job's "job-state-
              reason" attribute SHALL indicate why the job is no longer a
              candidate for processing.
           'processing'(5):  Either:
              1.  the job is using, or is attempting to use, one or more
                document transforms which include (1) purely software
                processes that are interpreting a PDL, and (2) hardware
                devices that are interpreting a PDL, making marks on a medium,
                and/or performing finishing, such as stapling OR
              2.  the server has made the job ready for printing, but the
                output device is not yet printing it, either because the job
                hasn't reached the output device or because the job is queued

                                Expires January 25, 1998
                in the output device or some other spooler, awaiting the
                output device to print it.
              When the job is in the 'processing' state, the entire job state
              includes the detailed status represented in the printer's
              "printer-state", "printer-state-reasons", and "printer-state-
              message" attributes.
              Implementations MAY include additional values in the job's "job-
              state-reasons" attribute to indicate the progress of the job,
              such as adding the 'job-printing' value to indicate when the
              output device is actually making marks on paper.  Most
              implementations won't bother with this nuance. some other spooler, awaiting the
                output device to print it.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         ISSUE:  Change  Suggested change to (but 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. 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. the server has made the job ready for printing, but the output
                device is not yet printing it, either because the job hasn't
                reached the output device or because the job is queued in the
                output device or some other spooler, awaiting the output
                device to print it.

              When the job is in the 'processing' state, the entire job state
              includes the detailed status represented in the printer's
              "printer-state", "printer-state-reasons", and "printer-state-
              message" attributes.
              Implementations MAY include additional values in the job's "job-
              state-reasons" attribute to indicate the progress of the job,
              such as adding the 'job-printing' value 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 of reasons and will return to the 'processing' state
              as soon as the reasons are no longer present.
              The job's "job-state-reason" attribute MAY indicate why the job
              has stopped processing.  For example, if the output device is
              stopped, the 'printer-stopped' value MAY 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 the
              device.  A client can obtain more complete device status remotely
              by querying the printer's "printer-state", "printer-state-
              reasons" and "printer-state-message" attributes.
           'canceled'(7):  The job has been canceled by a Cancel-Job operation
              and is either (1) in the process 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 has been aborted by the system, usually
              while the job was in the 'processing' or 'processing-stopped'
              state.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           'completed'(9):  The job has completed successfully or with
              warnings or errors after processing and all of the job media
              sheets have been successfully stacked in the appropriate output

                                Expires January 25, 1998
              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 SHALL be one of: 'completed',
         'canceled', or 'aborted' before the Printer removes the job
         altogether.  The length of time that jobs remain in the 'canceled',
         'aborted', and 'completed' states depends on implementation.

         The following figure shows the normal job state transitions.

                                                             +----> canceled
                                                            /
             +----> pending --------> 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
         the 'canceled' state from the 'pending', 'pending-held', 'processing',
         and 'processing-stopped' states.

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

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

         Implementation of these values is OPTIONAL, i.e., a Printer NEED NOT
         implement them, even if (1) the output device supports the
         functionality represented by the reason and (2) is available to the
         Printer object implementation.  These values MAY be used with any job
         state or states for which the reason makes sense.  Furthermore, when
         implemented, the Printer SHALL return these values when the reason
         applies and SHALL NOT return them when the reason no longer applies
         whether the value of the job's "job-state" attribute changed or not.
         When the job does not have any reasons 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
         "job-state"values,

         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 and registered without impacting such

                                Expires January 25, 1998
         deployed clients.  In other words, the "job-state-reasons" attribute
         is intended to be extensible.

         The following standard values are defined:

         NOTE - For easy of understanding the order of the reasons is presented
         in the order in which the reason is most likely to occur:

           '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':
           '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 be a candidate for processing until
              this reason is removed and there are no other reasons to hold the
              job.
           'resources-are-not-ready':
           'job-hold-until-resources-are -ready':  At least one of the
              resources needed by the job, such as media, fonts, resource
              objects, etc., is not ready on any of the physical printer's for
              which the job is a candidate.  This condition MAY be detected
              when the job is accepted, or subsequently while the job is
              pending or processing, depending on implementation.
           ISSUE: Change to job-hold-until-specified-time and job-hold-until-
              resources-ready to make it clear that the job-state is pending-
              held?.
           'printer-stopped-partly':  The value of the Printer's "printer-
              state-reasons" attribute contains the value 'stopped-partly'.
           'printer-stopped':  The value of the Printer's "printer-state"
              attribute is 'stopped'.
           'job-printing':  The output device is marking media. This value is
              useful for Printers which spend a great deal of time processing
              when no marking is happening and then want 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 is the same as
              the value of the job's "job-originating-user" attribute.
           'job-cancelled-by-operator':  The job was cancelled by the operator
              using the CancelJob request, i.e., by a user whose name is
              different than the value 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':  The job completed with errors (and
              possibly warnings too).
           'job-interpreting': Job is in the 'processing' state, but more
              specifically, the Printer is interpreting the data.
           'job-printing': Job is in the 'processing' state, but more
              specifically, the Printer is actually printing (making marks on
              the media).

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
           'logfile-pending ':  The job's logfile
           'job-queued': Job is pending file transfer.
           'logfile-transferring':  The job's logfile in the 'processing' state, but more
              specifically, the Printer is being transferred. queuing the data.
           'job-transforming': Job is in the 'processing' state, but more
              specifically, the Printer is transforming the data.

         ISSUE: How does this protocol get Show a logfile transfer to occur? I
              suggest we delete them. 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 information about the Job State
         in human readable text.

         4.3.11 output-device-assigned (name)

         This attribute identifies the Output Device to which the Printer has
         assigned this job.  If an output device implements an embedded IPP
         Printer, the Printer NEED NOT set this attribute.  If a Print Server
         implements a Printer, the value MAY be empty until the Printer assigns
         an output device to the job.

         4.3.12 time-since-pending (integer)

         This attribute indicates the amount of time in milliseconds that has
         passed since the Job was first put 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 the processing state.

         4.3.14 time-since-completed (integer)

         This attribute indicates the amount of time in milliseconds that has
         passed since the Job was completed.

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

         This attribute indicates the number of jobs that are "ahead" of this
         job in the current scheduled order.  For efficiency, it is only
         necessary to calculate this value when an operation is performed that
         requests this attribute.

         Note: This attribute is necessary since an end user may request just
         their own jobs and they need some relative position indicator if there
         are other jobs interspersed in the waiting list which are not returned
         in the response or cannot be because of site security policy
         restrictions.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
         ISSUE: No longer possible to request an owners job, so may this
         attribute isn't important now.
         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 the
         reasons for modification or other management action taken on 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., in units of 1024 octets.  The value SHALL be rounded up, so that
         a job between 1 and 1024 octets SHALL be indicated as being 1, 1025 to
         2048 SHALL be 2, etc.

         Note: This attribute and the following two attributes ("job-
         impressions-completed" and "job-sheets-completed") are intended to be
         counters as (as described in the Job Monitoring MIB [27]. [27]). That is, if
         the "job-
         state" "job-state" is 'processing' or 'processing-stopped', this value is
         intended to contain the amount of the job that has been processed to
         the 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.18 job-impressions-completed  (integer(0:2**31 - 1))

         This job attribute specifies the number of impressions completed. This
         attribute is intended to be a counter as in the Job Monitoring MIB.

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

         This job attribute specifies the media-sheets completed. This
         attribute is intended to be a counter as in the Job Monitoring MIB.

         4.4 Document Attributes

         This group of attributes describes the document data for the job.  For
         single-Document Jobs, they applies to Document objects.  If there are supplied
         multiple Documents in a Job, then there is a different set of Document
         attributes associated with Document in the Print-Job Job.

         When using the Get-Attributes or Print-URI
         requests.  For multi-Document Jobs, they are supplied Get-Jobs operations, the group named
         "document-attributes" includes all of the attributes in each Send- this section,
         including the Document or Send-URI request. level Job Template attributes (attributes that
         have the same characteristics as Job Template attribute, yet apply to

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
         +----------------------------+----------------------+----------------+
         Documents, not Jobs).  These are identified in the second part 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:

         +-----------------+-------------+----------------+
         |      Attribute    Document     |  Syntax     |   MANDATORY?   |
         +----------------------------+----------------------+----------------+
         | document-name    Attribute    | name             |  MANDATORY                |
         +----------------------------+----------------------+----------------+
         +-----------------+-------------+----------------+
         | document-format document-name   | type 2 enum name        |  NO            |
         +----------------------------+----------------------+----------------+
         +-----------------+-------------+----------------+
         | document-uri    | uri         |                |
         +----------------------------+----------------------+----------------+

         4.4.1 document-name (name)

         This attribute contains the name of the document used by the client to
         initially identify the document. When a client prints by reference,
         i.e. includes the document-URI attribute and no document content, this
         attribute SHALL be absent.

         4.4.2 document-format (type2 enum)

         See section 4.2.13 that describes the "document-format" Job Template
         attribute. This attribute is a job-template attribute. It may be
         specified with the job or separately for each document. In a Print-Job
         or Print-URI operation, there is no distinction between job and
         document attributes because there is only one job.  If document-format  NO            |
         +-----------------+-------------+----------------+

         4.4.1 document-name (name)

         This attribute contains the name of the document.  The name is included with a Create-Job operation, it specifies
         optionally supplied by the format for
         all documents. client in the "document-name" operation
         attribute in the create request.  If document-format it is included with not supplied by the client
         in the create request, the Printer MAY generate a Send-Document Document name.  The
         "document-name" attribute contains the name whether supplied or
         Send-URI operation, it overrides whatever format was specified with
         Create-Job.

         4.4.3
         generated.

         4.4.2 document-uri (uri)

         This attribute contains

         If a "pull" operations is used to create the Document object (such as
         the Print-URI or Send-URI operations which include only a URI of
         reference to the document when data, not the document
         content data itself), then
         this "document-uri" attribute contains the URI reference.  This
         attribute is not included populated from the "document-uri" operation attribute
         supplied by the client in the Send Document operation. Note: For Print-URI and or Send-URI "document-uri" operation.

         If a "push" operation is an explicit parameter used to create the Document object (such as
         the Print-Job or Send-Document operations which
         sets include the "document-uri" document
         data rather than just a reference to the data) then this "document-
         uri" attribute in is not associated with the Document object.

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

         These attributes form the attribute group called "printer-
         description".  A Printer object may be realized in either a print
         server or output device.  Note: How these attributes are set by an
         Administrator is outside the scope of this specification.  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 January 25, February xx, 1998
         +----------------------------+----------------------+----------------+
         |      Attribute             |     Syntax           |   MANDATORY?   |
         +----------------------------+----------------------+----------------+
         | printer-uri                | uri                  |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | printer-uri-user           | uri                  |                |
         +----------------------------+----------------------+----------------+
         | printer-name               | name                 |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | printer-location           | text                 |                |
         +----------------------------+----------------------+----------------+
         | printer-description        | text                 |                |
         +----------------------------+----------------------+----------------+
         | printer-more-info-site 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     |
         +----------------------------+----------------------+----------------+
         | content-char-set-supported | 1setOf char-set      |                |
         +----------------------------+----------------------+----------------+
         | content-char-set color-supported            | char-set boolean              |                |
         +----------------------------+----------------------+----------------+
         | color-supported pdl-override               | boolean type2 keyword        |                |
         +----------------------------+----------------------+----------------+
         | message-protection-        | keyword              |                |
         | supported                  |                      |                |
         +----------------------------+----------------------+----------------+

                                Expires January 25, 1998
         | authentication-author      | keyword              |                |
         | ization-supported          |                      |                |

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         +----------------------------+----------------------+----------------+
         | color-supported printer-up-time            | boolean seconds              |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | pdl-override-supported printer-current-time       | type2 keyword dateTime             |                |
         +----------------------------+----------------------+----------------+

         4.5.1 printer-uri (uri)

         This attribute contains the URI for the printer.  An administrator
         determines a printer's URI and sets this attribute to that URI. The
         precise format of a printer URI is implementation dependent.

         4.5.2 printer-uri-user (uri)

         This attribute contains the URI for an HTML page with more information
         about this printer.

         ISSUE: Get rid of "printer-uri-user" or "printer-more-info-site"?

         4.5.3 a printer URI is implementation dependent.

         4.5.2 printer-name (name)

         This attribute contains the name of the printer. It is a 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 name may be
         the last part of the 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.5.4

         4.5.3 printer-location (text)

         This attribute identifies the location of this printer. This could
         include things like: _in Room 123A, second floor of building XYZ_.

         4.5.5

         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", or even "This printer is going away on July 1, 1997, please
         find a new printer".

         4.5.6 printer-more-info-site

         4.5.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 a Web Browser.  The information
         obtained from this URI is

                                Expires January 25, 1998 intended for end user consumption. Features
         outside the scope of IPP can be accessed from this URI.  The
         information is intended to be specific to this printer instance and
         site specific services (e.g. job pricing, services offered, end user
         assistance).  The printer manufacturer may
         initially populate this attribute.

         4.5.7

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 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 is intended for consumption by
         automata. The mechanics of print driver installation is outside the
         scope of IPP.  The printer manufacturer may initially populate this
         attribute.

         4.5.8

         4.5.7 printer-make-and-model (text)

         This attribute identifies the make and model of the printer.

         4.5.9

         4.5.8 printer-more-info-manufacturer (uri)

         This attribute contains a URI used to obtain more information about
         this type of printer.  The information obtained from this URI is
         intended for end user consumption.  Features outside the scope of IPP
         can be accessed from this URI (e.g., latest firmware, upgrades, print
         drivers, optional features available).  The information is intended to
         be germane to this printer without regard to site specific
         modifications or services.

         4.5.10

         4.5.9 printer-state (type1 enum)

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

         A Printer SHALL keep this attribute set in a timely manner to the
         value in the table below which most accurately reflects the state of
         the Printer. If the printer has jobs that are requesting notification
         of printer-problems or job-problems, then _timely manner_ means
         continually..  Otherwise, _timely manner_ means whether 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 Printer SHALL use this state only if it cannot determine its
              actual state.

                                Expires January 25, 1998

           'idle'(3):  If a Printer receives a job (whose required resources
              are ready) while in this state, such a job SHALL transit into the
              processing state immediately.  If the printer-state-reasons
              attribute contains any reasons, they SHALL be reasons that would
              not prevent a job from transiting into into the processing state

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
              immediately, e.g., toner-low. Note: if a Printer controls more
              than one output device, the above definition implies that a
              Printer is idle if at least one output device is idle.

           'processing'(4):  If a Printer receives a job (whose required
              resources are ready) while in this state, such a job SHALL
              transit into the pending state immediately. Such a job SHALL
              transit into the processing state only after jobs ahead of it
              complete.  If the printer-state-reasons attribute contains any
              reasons, they SHALL be reasons that do not prevent the current
              job from printing, e.g. toner-low.  Note: if a Printer controls
              more than one output device, the above definition implies that a
              Printer is processing if at least one output device is
              processing, and none is idle.

           'stopped'(5):  If a Printer receives a job (whose required
              resources are ready) while in this state, such a job SHALL
              transit into the pending state immediately. Such a job SHALL
              transit into the processing state only after some human fixes the
              problem that stopped the printer and after jobs ahead of it
              complete printing.  The "printer-state-reasons" attribute SHALL
              contain at least one reason, e.g. media-jam, which prevents it
              from either processing the current job or transiting a pending
              job to the processing state
              immediately, e.g., toner-low. state.

              Note: if a Printer controls more than one output device, the
              above definition implies that a Printer is idle stopped only if at least one all
              output device devices are stopped.  Also, it is idle.

           'processing'(4):  If a Printer receives tempting to define
              stopped as when a job (whose required
              resources sufficient number of output devices are ready) while in this state, stopped
              and leave it to an implementation to define the sufficient
              number.  But such a rule complicates the definition of stopped
              and processing. For example, with this alternate definition of
              stopped, a job can move from idle to processing without human
              intervention, even though the Printer is stopped.

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

         This attribute supplies additional detail about the printer's state.

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

           - '-report':  This suffix indicates that the reason is a "report".
              An implementation may choose to omit some or all reports. Some
              reports specify finer granularity about the printer state; others
              serve as a precursor to a warning. A report SHALL contain nothing
              that could affect the printed output.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           - '-warning': This suffix indicates that the reason is a "warning".
              An implementation may choose to omit some or all warnings.
              Warnings serve as a precursor to an error. A warning SHALL
              contain nothing that prevents a job from completing, though in
              some cases the output may be of lower quality.
           - '-error': This suffix indicates that the reason is an "error". .
              An implementation SHALL
              transit into the pending state immediately. Such a job include all errors. If this attribute
              contains one or more errors, printer SHALL
              transit into be in the processing state only after jobs ahead of it
              complete. stopped
              state.

         If the printer-state-reasons attribute contains implementation does not add any
              reasons, they one of the three suffixes, all
         parties SHALL be reasons assume that do not prevent the current
              job from printing, e.g. toner-low.  Note: if reason is an "error".

         If a logical Printer controls more than one output device, each value
         of this attribute MAY apply to one or more of the above definition implies that a
              Printer is processing if at least output devices.  An
         error on one output device is
              processing, and none is idle.

           'stopped'(5):  If a that does not stop the logical Printer receives as a job (whose required
              resources are ready) while
         whole MAY appear as a warning in this state, the Printer's "printer-state-reasons
         attribute".  The "printer-state" for such a job SHALL
              transit into the pending state immediately. Such Printer may have a job SHALL
              transit into the processing state only after some human fixes the
              problem value
         of 'stopped' even though there are with no "printer-state-reasons"
         values that stopped the printer and after jobs ahead are "errors".

         The following standard values are defined:

           'media-needed': A tray has run out of it
              complete printing. media.
           'media-jam': The "printer-state-reasons" attribute printer has a media jam.
           'paused': Someone has paused the Printer. In this state, a Printer
              SHALL
              contain at least one reason, e.g. media-jam, which prevents not produce printed output, but it
              from either processing the current job or transiting SHALL perform other
              operations requested by a client. If a Printer had been printing
              a pending job to when the processing state.

              Note: if a Printer controls more than one output device, was paused, the
              above definition implies Printer SHALL resume
              printing that a job when the Printer is stopped only if all
              output devices are stopped.  Also, it is tempting to define
              stopped as when a sufficient number of output devices are stopped no longer paused and leave it to an implementation to define
              no evidence in the sufficient
              number.  But printed output of such a rule complicates the definition of stopped pause.
           'shutdown': Someone has removed a Printer from service, and processing. For example, with it may
              be powered down or physical removed. In this alternate definition of
              stopped, state, a job can move from idle to processing without human
              intervention, even though Printer
              SHALL not produce printed output, and unless the Printer is stopped.

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

         This attribute supplies additional detail about
              realized by a print server that is still active, the printer's state.

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

                                Expires January 25, 1998
           - '-report':  This suffix indicates Printer
              SHALL perform no other operations requested by a client,
              including returning this value. If a Printer had been printing a
              job when it was shutdown, the Printer need not resume printing
              that job when the reason Printer is no longer shutdown. If the Printer
              resumes printing such a "report".
              An implementation job, it may choose to omit some or all reports. Some
              reports specify finer granularity about leave evidence in the printer state; others
              serve as a precursor to printed
              output of such a warning. A report SHALL contain nothing
              that could affect shutdown, e.g. the part printed output.
           - '-warning': This suffix indicates that before the reason is a "warning".
              An implementation
              shutdown may choose to omit some or all warnings.
              Warnings serve as be printed a precursor to an error. A warning SHALL
              contain nothing that prevents second time after the shutdown.
           'connecting-to-device': The server has scheduled a job from completing, though on the
              Printer and is in
              some cases the process of connecting to a shared network
              output may device (and might not be of lower quality.
           - '-error': This suffix indicates that able to actually start printing
              the reason is job for an "error". .
              An implementation SHALL include all errors. If this attribute
              contains one or more errors, printer SHALL be in the stopped
              state.

         If arbitrarily long time depending on the implementation does not add any one usage of
              the three suffixes, all
         parties SHALL assume that output device by other servers on the network).

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           'timed-out': The server was able to connect to the output device
              (or is always connected), but was unable to get a response from
              the output device.
           'stopping': The printer will be stopping in a while and will change
              its reason to printer-stopped. This reason is a non-critical,
              even for a Printer with a single output device. When an "error".

         If output-
              device ceases accepting jobs, the Printer will have this state
              while the output device completes printing.
           'stopped-partly': When a logical Printer controls more than one output
              device, each value
         of this attribute MAY apply to reason indicates that one or more output devices are
              stopped. If the reason is a report, fewer than half of the output devices.  An
         error on one output device that does not stop
              devices are stopped. If the logical Printer as a
         whole MAY appear as reason is a warning in warning, fewer than all
              of the Printer's "printer-state-reasons
         attribute". output devices are stopped.
           'toner-low': The "printer-state" for such a Printer may have 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 value partitioning of 'stopped' even though there are with no which "printer-state-reasons"
         values that are "errors". valid
         or expected for each "printer-state" value.

         4.5.11 printer-state-message (text)

         This attribute specifies the additional information about the printer
         state and printer state reasons in human readable text.

         4.5.12 operations-supported (1setOf type2 enum)

         This attribute specifies the set of supported operations for this
         Printer.

         The following standard values are defined:

           'media-needed': A tray has run out of media.
           'media-jam': The printer has a media jam.
           'paused': Someone has paused the Printer.

           0x00    reserved, not used
           0x01    Print-Job
           0x02    Print-URI
           0x03    Validate-Job
           0x04    Create-Job
           0x05    Get-Jobs
           0x06    Get-Attributes
           0x07    Send-Document
           0x08    Send-URI
           0x09    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 for IPP to be extensible, this state, a Printer
              SHALL not produce printed output, but it SHALL perform other set of operations requested by a client. If a Printer had been printing
              a job when the Printer was paused, the Printer SHALL resume
              printing that job when the Printer is no longer paused and leave
              no evidence in the printed output of such a pause.
           'shutdown': Someone has removed a Printer from service, and it may defined
         to be powered down or physical removed. In this state, a Printer
              SHALL not produce printed output, and unless 1setOf  type2 enum (see section 6.1 for a description of typed
         extensions).  Since the Printer base type is
              realized by enum, the possible full range of
         values is 0x0000-0xFFFF, however a print server special range of 0x4000-0xFFFF has
         been reserved for private extensions.  This allows for certain vendors
         to implement private extensions that are guaranteed to not conflict
         with future registered extensions.  However, there is still active, the Printer
              SHALL perform no other operations requested by a client,
              including returning this value. 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 a Printer had been printing a
              job when it was shutdown, the Printer need not resume printing
              that job when value is true, the Printer printer is no longer shutdown. accepting jobs. If the Printer
              resumes printing such a job, it may leave evidence in
         value is false, the printed
              output printer is currently rejecting any jobs submitted
         to it.

         Note: This value is independent of such a shutdown, e.g. the part printed before printer state and printer-
         state-reasons because its value does not affect the
              shutdown current job;
         rather it affects future jobs. This attribute may be printed a second time after the shutdown.

                                Expires January 25, 1998
           'connecting-to-device': The server has scheduled a job on cause the Printer and to
         reject jobs when the printer-state is in idle or it may cause the process of connecting to a shared network
              output device (and might not be able Printer
         to actually start printing
              the job for an arbitrarily long time depending on accepts jobs when the usage printer-state is stopped.

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

         This attribute contains a count of the output device number of jobs that are either
         pending and/or processing and is set by other servers on the network).
           'timed-out': The server was able Printer.

         4.5.15 printer-message-from-operator (text)

         This attribute provides a message from an operator, system
         administrator or "intelligent" process to connect indicate to the output device
              (or end user
         information or status of the printer, such as why it is always connected), but was unable unavailable or
         when it is expected to get a response from
              the output device.
           'stopping': The printer will be stopping in a while and will change
              its reason to printer-stopped. available.

         4.5.16 printer-human-language (human-language)

         This reason is a non-critical,
              even for a Printer with a single output device. When an output-
              device ceases accepting jobs, the Printer will have this state
              while attribute specifies the output device completes printing.
           'stopped-partly': When a Printer controls more than one output
              device, this reason indicates current human-language that one or more output devices are
              stopped. If the reason Printer
         is a report, fewer than half of operating in.

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

         This attribute specifies the output
              devices are stopped. If supported human languages that the reason is a warning, fewer than all
              of
         Printer operates in.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         4.5.18 color-supported (boolean)

         This attribute identifies whether the output devices are stopped.
           'toner-low': The Printer is low on toner.
           'spool-area-full': The limit capable of persistent storage allocated for
              spooling has been reached.

         4.5.12 printer-state-message (text) 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).

         4.5.19 pdl-override (type2 keyword)

         This attribute expresses the ability for a particular Printer
         implementation to either attempt to override print data instructions
         with IPP attributes or not.

         This attribute specifies takes on the additional information about following values:

           - 'attempted': This value indicates that the printer
         state Printer attempts to
              make sure that IPP attribute values take precedence over embedded
              instructions in human readable text and it the Print data, however there is set by no guarantee.
           - 'not-attempted': This value indicates that the Printer (or the
         Administrator by some mechanism outside the scope of IPP).

         ISSUE:  Do we want makes not
              attempt to delete the last phrase and imply ensure that this IPP attribute values take precedence over
              embedded instructions in the print data.

         This is a
         human readable version MANDATORY attribute.

         Appendix E: Processing IPP Attributes (see Section 15) contains a full
         description of printer-state 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 printer-state-reason authorization
           - mutual authentication, authorization, and
         not something created by message protection

         In order to let an admin?  printer-message-from-the-operator
         is from end user know what to expect in terms of security,
         there are two attributes described below.  Since by definition an admin.

         4.5.13 printer-is-accepting-jobs (boolean)

         This attribute determines whether the printer is currently accepting
         job.  If the value end
         user, because of security reasons, might not be allowed to query these
         two attributes, therefore, it is true, important that if these two
         attributes are supported, then they are also populated in the printer is accepting jobs.
         directory entry (see [24]).

         These attributes allow for minimal client/server negotiation regarding
         security features.  If the
         value is false, Printer requires the printer is currently rejecting any jobs submitted feature, the client
         can decide whether or not to it.

         Note: This value is independent of participate.  If the printer state and printer-
         state-reasons because its value client does not affect

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         support the current job;
         rather it affects future jobs. This attribute may cause feature, and the Printer to
         reject jobs when requires it, then the printer-state client
         knows before hand that such an interaction would fail.

         Standard values for these two attributes include:

           'supported' -  means that the Printer is idle or capable of supporting the
              security feature (somehow), but it may cause is does not require the Printer client
              to accepts jobs when use it.
           'required' -  means that the printer-state Printer is stopped.

                                Expires January 25, 1998
         4.5.14 queued-job-count (integer(0:2**31 - 1))

         This attribute contains a count capable of supporting the number of jobs that are either
         pending and/or processing
              security feature (somehow) and the client is set by required to use it.
           'none' - means that the Printer.

         4.5.15 printer-message-from-operator (text) Printer is not capable of supporting
              message protection at all.

         Note:  This attribute provides is a message from single-valued attribute, not a multi-valued
         attribute, i.e., an operator, system
         administrator or "intelligent" process to indicate to the end user
         information implementation can not support 'none' and
         'required' or status any other combination of the printer, such as why it values.

         4.5.20.1 message-protection-supported (keyword)

         This attribute is unavailable used to determine whether or
         when not a printer supports
         or requires message protection (whether it is expected to be available.

         4.5.16 printer-human-language (human-language) through encryption or
         some other privacy mechanism).

         4.5.20.2 authentication-authorization-supported (keyword)

         This attribute is used to determine whether or not a printer supports
         or requires authentication and authorization.

         4.5.21 printer-up-time (seconds)

         This attribute specifies is a MANDATORY attribute.  It indicates the current human-language amount of
         time (in seconds) that the this instance of this Printer
         is operating in.

         4.5.17 printer-human-language-supported (1setOf human-language) implementation
         has been up and running.  This attribute specifies the supported human languages that value is used to populate the
         Printer operates in.

         4.5.18 printer-content-char-set (char-set) Job
         attributes "time-at-pending", "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".

         ISSUE: Does this need to be MANDATORY?

         4.5.22 printer-current-time (dateTime)

         This attribute specifies is an OPTIONAL attribute.  It indicates the current character set encoding that the
         Printer is operating in.
         absolute wall-clock time.  If an implementation supports this attribute is not supported, the
         Printer MUST support UTF-8.

         4.5.19 printer-content-char-set-supported (1setOf char-set)

         This attribute specifies
         attribute, the supported character set encodings that a client could calculate the Printer operates in.  If absolute wall-clock time
         each Job's "time-at-pending", "time-at-processing", and "time-at-

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         completed" attributes by using both "printer-up-time" and this attribute is
         attribute, "printer-current-time".  If an implementation does not supported, the
         Printer MUST
         support UTF-8.

         4.5.20 color-supported (boolean)

         This attribute identifies whether this attribute, a client can only calculate the Printer is capable of any type relative time
         of color printing at all.  All document instructions having to do with
         color are embedded within certain events based on the MANDATORY "printer-up-time" attribute.

         5. Conformance

         This section describes conformance issues and requirements. This
         document PDL (none are external IPP
         attributes).

         4.5.21 pdl-override (type2 keyword) introduces model entities such as objects, operations,
         attributes, and attribute values.  These conformance sections describe
         the conformance requirements which apply to these model entities.

         5.1 Client Conformance Requirements

         A client supplies Job Template attributes conforming client SHALL send operations that conform to affect the rendering,
         production and finishing of the documents protocol
         defined in the job.  Similar types
         of instructions may also be contained _Internet Printing Protocol/1.0: Protocol Specification_
         [23]. For each parameter or attribute included in the document an operation
         request, a conforming client SHALL send a value whose type and value
         syntax conforms to be printed,
         that is, within the Page Description Language (PDL) requirement of the this document
         data.  If

         Otherwise, there is a conflict between are no conformance requirements placed on the value of one of these user
         interfaces provided by IPP

                                Expires January 25, 1998
         Job Template attributes, and a corresponding instruction in the
         document (either implicit clients or explicit), it is desirable that the value
         of the IPP attribute take precedence over the document instruction.
         Until companies that supply interpreters for PDLs, such as PostScript
         and PCL their applications.  For
         example, one application might not allow a way for external attributes (such as IPP attributes) an end user to take precedence over internal job production instructions, submit
         multiple documents per job, while another does.  One application might
         first query a Printer object in order to supply a graphical user
         interface (GUI) dialogue box with supported and default values whereas
         a different implementation might not.

         When sending a Get-Attributes or create request, an IPP client need
         not supply any attributes.

         A client SHALL be able to support accept any of the semantics attribute syntaxes defined
         in Section 4.1 that IPP attributes
         override (take on may be returned to it in a higher precedence) the embedded PDL instructions.
         This attribute expresses how response from a particular Printer implementation
         handles these conflicts.

         This attribute takes on the following values:

           - 'guaranteed': This value indicates Printer

         A query response may contain parameters, attributes, and values that
         the client does not expect.  Therefore, a client implementation MUST
         gracefully handle such responses and not refuse to interoperate with a
         conforming Printer guarantees that all IPP is returning extended registered or private
         attributes and/or attribute values take precedence over embedded PDL
              instructions.
           - 'attempted': This value indicates that the Printer attempts conform to
              make sure that IPP attribute Section 6.  Clients
         may choose to ignore any parametes, attributes, or values take precedence over embedded
              PDL instructions, however there is no guarantee.
           - 'ignored': This value indicates 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 ignores object implementations with respect to objects, operations,
         and attributes.

         5.2.1 Objects

         Conforming Printer implementations SHALL implement all IPP of the model
         objects as defined in this specification in the indicated sections:

           Section 2.1 Printer Object
           Section 2.2 Job Template attributes and it makes no attempts to ensure that
              IPP attribute values take precedence over embedded PDL
              instructions.

         This is Object
           Section 2.3 Document Object

         5.2.2 Operations

         Conforming Printer implementations SHALL implement all of the
         MANDATORY model operations, including mandatory responses, as defined
         in this specification in the indicated sections:

           For a Printer object:
              Print-Job (section 3.2.1)                    MANDATORY attribute.

         Note: Since 'attempted' does not offer any type
              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

           For 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 and
         response parameters and all values of guarantee, a given
         implementation might not do a very "good" job such parameters, except for
         parameters which are collections of attempting to ensure
         that IPP attributes. The following section
         on attributes take a higher precedence over PDL instructions
         embedded in the document data, but it would still be a conforming
         implementation.

         If specifies the value support required for attributes.

         5.2.3 Attributes

         Conforming Printer implementations SHALL support all of this attribute is 'guaranteed', the implementation
         MUST guarantee that MANDATORY
         attributes, as defined in this specification in the IPP attribute indicated
         sections.

         If a Printer supports an attribute, it SHALL support only those values take precedence over any
         related job processing instructions
         specified in the PDL Job's this document data.
         This can be done by modifying the interpreter within the output device
         itself to understand IPP attributes, or by merging theses Job Template
         attributes directly into through the document data, or extension mechanism

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         described in any other
         implementation specific manner.  In any case, the semantics next section. It MAY support any non-empty subset of
         'guaranteed' MUST be preserved.

         4.5.22 Security Related Attributes

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

           - no security
           - message protection
           - client authentication
         these values. That is, it SHALL support at least one of the specified
         values and authorization

                                Expires January 25, 1998
           - mutual authentication, authorization, at most all of them.

         5.2.4 Printer extensions

         A conforming Printer may support registered extensions and message protection

         In order to let an end user know what private
         extensions, as long as they meet the requirements specified in Section
         6.

         A conforming Printer SHALL send responses that conform to expect the protocol
         defined in _Internet Printing Protocol/1.0: Protocol Specification_
         [23]. For each parameter or attribute included in terms of security,
         there are two attributes described below.  Since by definition an end
         user, because operation
         response, a conforming printer SHALL send a value whose type and value
         syntax conforms to the requirement of security reasons, might not this document

         5.2.5 Attribute Syntaxes

         A Printer SHALL be allowed able to query these
         two attributes, therefore, it is important that if these two
         attributes are supported, then they are also populated in accept any of the
         directory entry (see [24]).

         These attribute syntaxes
         defined in Section 4.1 in any operation in which a client may supply
         attributes allow for minimal client/server negotiation regarding
         security features.  If the or parameters.  Furthermore, a Printer requires the feature, SHALL return
         attributes to the client
         can decide whether or not in operation responses that conform to participate.  If the client does not
         support
         syntax specified in Section 4.1.

         5.3 Security Conformance Requirements

         ISSUE: The "why" and "what" needs to be moved from the feature, Security
         document to this document.  The "how" from the Security document needs
         to be moved to the Protocol Specification document.

         6. IANA Considerations (registered and private extensions)

         During the Printer requires it, then development of this standard, the client
         knows before hand that such an interaction would fail.

         Standard values for these two attributes include:

           'supported' -  means that IPP working group
         (working with IANA) will register additional keywords and enums while
         the Printer standard is capable of supporting in the
              security feature (somehow), but it proposed and draft states according to the
         procedures described in this section.  IANA will handle registration
         of additional enums after this standard is does not require approved in cooperation
         with an IANA-appointed registration editor from the client IPP working group
         according to use it.
           'required' -  means that the Printer is capable of supporting procedures described in this section.

         6.1 Typed Extensions

         This document uses prefixes to the
              security feature (somehow) "keyword" and the client is required "enum" basic syntax
         type in order to communicate extra information to use it.
           'none' - means that the Printer is not capable of supporting
              message protection at all.

         Note: reader through
         its name. This is a single-valued attribute, extra information need not a multi-valued
         attribute, i.e., be represented in an

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         implementation can not support 'none' and
         'required' or any other combination of values.

         4.5.22.1 message-protection-supported (keyword)

         This attribute because it is used unimportant to determine whether or not a printer supports client or requires message protection (whether it Printer.  The
         list below describes the prefixes and their meaning.

           "type1":  The IPP standard must be through encryption or
         some other privacy mechanism).

         4.5.22.2 authentication-authorization-supported (keyword)

         This attribute is used revised to determine whether or not add a printer supports new keyword or requires authentication and authorization.

         4.5.23 best-effort (1setOf boolean)

         This attribute determines how a Printer handles a conflict between
         what a client requests in
              a create request new enum.  No private keywords or enums are allowed.

           "type2":  Implementers can, at any time, add new keyword or enum
              values by proposing them to the IPP working group for
              registration (or an IANA-appointed registry advisor after the IPP
              working group is no longer certified) where they are reviewed for
              approval.  IANA keeps the registry.

           "type3":  Implementers can, at any time, add new keyword and what a Printer
         supports.  The value 'true' means that enum
              values by submitting a best effort attempt registration request directly to print
         the Job IANA, no
              IPP working group or IANA-appointed registry advisor review is possible.  In order to achieve this, the Printer might
         ignore some attributes
              required.

           "type4":  Anyone (system administrators, system integrators, site
              managers, etc.) can, at any time, add new installation-defined
              values (keywords or might have new enum values) to substitute some supported
         value for a requested value which is unsupported.  The value 'false'

                                Expires January 25, 1998
         means that only total fidelity is supported; a best effort attempt to
         print local system. Care
              SHOULD be taken by the Job is implementers to see that keywords do not possible.  In
              conflict with other words, keywords defined by the job can only be
         printed exactly standard or as specified in
              defined by the create request.  If one implementing product. There is no registration or more
              approval procedure for type 4 keywords.

         By definition, each of the client-supplied values four types above assert some sort of
         registry or review process in order for extensions to be considered
         valid.  Each higher level (1, 2, 3, 4) tends to be decreasingly less
         stringent than the create request previous level.   Therefore, any typeN value MAY be
         registered using a process for some typeM where M is not supported by
         the Printer, the Printer rejects the create request. less than N,
         however such registration is NOT REQUIRED.  For example, if a client supplies type4 value
         MAY be registered in a "finishings" Job Template
         attribute set to 'staple' but the printer does not support stapling
         (not type 1 manner (by being included in a feature or future
         version of an IPP specification) however it is temporarily out of staples) NOT REQUIRED.

         This specification defines keyword and if enum values for all of the "best-
         effort" input parameter
         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 set to 'true' and the Printer's "best-
         effort-supported" attributes includes 'true' then the Printer tries to
         still print the job even if it can not be stapled. (lowercase) fully qualified company name registered with
         IANA for use in domain names [30].

         Note: RFC 1035 [30] indicates that the "best-effort" attribute while upper and lower case letters
         are allowed in a create request domain names, no significance is unlikely attached to be used much. Many clients will submit a job with no attributes,
         and the Printer will use default values.  Other clients will submit a
         job via a GUI that limits case.
         That is, two names with the attribute values to values which same spelling but different case are
         supported.  Best effort printing is useful in the GUI context only if
         a user expects the job to be moved to another printer and prefers a
         sub-optimal result to nothing at all.  Best effort printing is most
         useful
         treated as if identical.  Also, the labels in a domain name must
         follow the case where an end-user uses rules for ARPANET host names:  They must start with a command line interface to
         request attributes that might not be supported.

         5. Conformance

         This section describes conformance issues
         letter, end with a letter or digit, and requirements. This
         document introduces model entities such have as objects, operations,
         attributes, interior characters

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         only letters, digits, and attribute values.  These conformance sections describe hyphen.  Labels must be 63 characters or
         less.  Labels are separated by the conformance requirements which apply to these model entities.

         5.1 Conditionally Mandatory "." character.

         For example, a conditionally mandatory attribute means that a Printer
         implementation need not support the attribute if private (unregistered) enum extension, implementers SHOULD use
         values in the attribute
         controls a feature reserved integer range (see "enum").

         6.2 Registration of MIME types/sub-types for document-formats

         The "document-format" attribute's syntax is "mimeType".  This means
         that valid values are MIME types.  RFC 2045 [??] defines the output device does not implement or
         expose.  For example, syntax
         for an output device that can only print on one
         side, a Printer need not support valid MIME types.  Also, IANA is the "sides" attribute.  For an output
         device that does not support any registry for all MIME types.

         6.3 Attribute Extensibility

         Attribute names are considered to be set of type2 keywords.  In order
         to be extended, the finishing attribute values, a
         Printer need not support same rules as type2 keywords apply.

         6.4 Attribute Syntax Extensibility

         Attribute syntaxes are considered to be set of type2 enums.  In order
         to be extended, the "finishing" attribute.

         ISSUE: We still have a problem with conditionally mandatory.  What
         MUST same rules as type2 enums apply.

         7. Internationalization Considerations

         This model describes attributes whose values can be supported?  What NEED NOT?  What SHOULD NOT? 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 January 25, February xx, 1998
         5.2 Client Conformance Requirements

         A conforming client SHALL send operations that conform to
           document-name

         These attributes MUST contain characters for the protocol
         defined in _Internet Printing Protocol/1.0: Protocol Specification_
         [23]. For each parameter or attribute included coded character set
         defined in an operation
         request, a conforming client SHALL send a value whose type ISO 10646 [??] and value
         syntax conforms to be encoded using the requirement of this document

         Otherwise, there UTF-8 character
         encoding rules [28].  No other coded character sets or encoding rules
         are no conformance requirements placed on allowed.

         However, since these strings are intended for human understanding, the user
         interfaces provided by IPP clients or their applications.  For
         example, one application might not allow an end user to submit
         multiple documents per job, while another does.  One application might
         first query a Printer object in order to supply a graphical user
         interface (GUI) dialogue box with supported and default values whereas
         a different implementation might not.

         When sending a Get-Attributes or create request, an IPP client need
         not supply any attributes.

         A client SHALL
         strings can be able to accept in any of the attribute syntaxes human language identifiable with tags defined in Section 4.1
         RFC 1766 [??].  A client that may be returned queries the above mentioned text
         attributes needs to it in a response from a Printer know what human language is being used for these
         text attributes.  A query response may contain parameters, attributes, and Printer optionally supports a "human-languages-
         supported" supported values that attribute and a "human-language" default
         value attribute.  Since these are optional, if the client printer does not expect.  Therefore, a
         support these attributes, the client implementation MUST
         gracefully handle such responses and not refuse to interoperate with a
         conforming Printer that is returning extended registered or private
         attributes and/or attribute values can assume that conform to Section 6.  Clients
         may choose to ignore any parametes, attributes, the text strings
         are either US English "en-US" or values any other language that it does
         not understand.

         5.3 Printer Object Conformance Requirements

         This section specifies is specific
         to a given site.  Whatever the conformance requirements value, the same value applies to ALL
         text based attributes for conforming a given Printer object implementations with respect to objects, operations, and attributes.

         5.3.1 Objects

         Conforming Printer implementations SHALL implement all of its contained Jobs.

         In the model
         objects as defined in this specification HTTP mapping for IPP/1.0, these attributes are mapped in to the indicated sections:

           Section 0
           Printer Object
           Section 2.2 Job Object
           Section 2.3 Document Object

                                Expires January 25, 1998
         5.3.2 Operations

         Conforming Printer implementations SHALL implement all
         HTTP headers that control negotiation of the
         MANDATORY model operations, including mandatory responses, as defined 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 in parallel with this specification document.  The mapping of IPP on top of
         appropriate security protocols will be described in the indicated sections:

           For a Printer object:
              Get-Operations (section 3.2.1)               MANDATORY
              Print-Job (section 3.2.2)                    MANDATORY
              Print-URI (section 3.2.3)                    OPTIONAL
              Validate-Job (section 3.2.4)                 MANDATORY
              Create-Job (section 3.2.5)                   OPTIONAL
              Get-Jobs (section 3.2.7)                MANDATORY
              Get-Attributes (section3.2.6)                MANDATORY

           For 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 and
         response parameters that document.
         IPP does not introduce any new, general purpose security mechanisms
         for authentication and all values of such parameters, except encryption.

         A Printer may choose, for
         parameters which are collections security reasons, not to return all
         attributes that a client requests. It may even return none of attributes. The following section
         on attributes specifies the support required for
         requested attributes.

         5.3.3 Attributes

         Conforming Printer implementations SHALL support all of In such cases, the MANDATORY
         attributes, as defined in this specification in status returned is the indicated
         sections.

         Conforming Printer implementations SHALL support all CONDITIONALLY
         MANDATORY attributes same
         as defined in this specification (in the
         indicated sections) if in the implementation the condition us true.

         If a Printer implements had returned all requested attributes. The client
         cannot tell by such a "xxx-supported" attribute it MUST implement response whether the corresponding "xxx" default value attribute and vice versa.

         ISSUE: For each attribute Job-Template  attribute _xxx_, there are 3
         attributes: Job attributes _xxx_, Printer attribute _xxx_ (default
         value) and Printer requested attribute _xxx-supported_;  a Printer supports
         either all three of these attributes was
         present or none of absent on the three

         If a Printer implements an attribute, it SHALL support only those
         values specified in this document or through Printer.

         9. References

         [1]  Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog,
              J., "Printer MIB", RFC 1759, March 1995.

         [2]  R Fielding, et al, _Hypertext Transfer Protocol _ HTTP/1.1_ RFC
              2068, January 1997

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         [3]  Crocker, D., "Standard for the extension mechanism
         described in Format of ARPA Internet Text
              Messages", RFC 822, August 1982.

         [4]  Postel, J., "Instructions to RFC Authors", RFC 1543, October
              1993.

         [5]  ISO/IEC 10175 Document Printing Application (DPA), June 1996.

         [6]  Herriot, R. (editor), X/Open A Printing System Interoperability
              Specification (PSIS), August 1995.

         [7]  Kirk, M. (editor), POSIX System Administration - Part 4: Printing
              Interfaces, POSIX 1387.4 D8, 1994.

         [8]  Borenstein, N., and Freed, N., "MIME (Multi-purpose Internet Mail
              Extensions) Part One: Mechanism for Specifying and Describing the next section. It MAY support any non-empty subset of

                                Expires January 25, 1998
         these values. That is, it SHALL support at least one
              Format of the specified
         values Internet Message Bodies", RFC 1521, September, 1993.

         [9]  Braden, S., "Requirements for Internet Hosts - Application and at most all of them.

         5.3.4 Printer extensions

         A conforming
              Support", RFC 1123, October, 1989,

         [10] McLaughlin, L. III, (editor), "Line Printer may support registered extensions Daemon Protocol" RFC
              1179, August 1990.

         [11] 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 and private
         extensions, as long as they meet the requirements specified in Section
         6.

         A conforming Printer SHALL send responses that conform to the protocol
         defined in _Internet Semantics (This
              document)

         [22] Internet Printing Protocol/1.0: Security

         [23] Internet Printing Protocol/1.0: Protocol Specification_
         [23]. For each parameter or attribute included Specification

         [24] Internet Printing Protocol/1.0: Directory Schema

         [25] S. Bradner, "Key words for use in an operation
         response, a conforming printer SHALL send a value whose type and value
         syntax conforms RFCs to Indicate Requirement
              Levels", RFC 2119 , March 1997

         [26] H. Alvestrand, " Tags for the requirement of this document

         5.3.5 Attribute Syntaxes

         A Printer SHALL be able to accept any Identification of the attribute syntaxes
         defined in Section 4.1 in any operation in which a client may supply
         attributes or parameters.  Furthermore, 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
                               Expires February xx, 1998
         [28] F. Yergeau, "UTF-8, a Printer SHALL return
         attributes transformation format of Unicode and ISO
              10646, RFC 2044, October 1996.

         [29] Turner, R. "Printer MIB", draft-ietf-printmib-mib-info-02.txt,
              July 8, 1997.  This I-D is an update to the client in operation responses that conform RFC 1759, March 1995 [1].

         [30] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND
              SPECIFICATION", RFC 1035, November 1987.

         [31] ?, "  ", RFC 2130, ?.

         [32] ?, "  ", RFC 1514, ?.

         [33] ?, "  ", RFC 1903, ?.

         [34] ?, "  ", RFC 1808, ?.

         10. 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

              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 the
         syntax specified 650 in Section 4.1.

         5.4 Security Conformance Requirements

         The security mechanisms being considered for IPP fall outside the
         scope of the application layer protocol itself.  There are two
         mechanisms used August 1997)
              Fax:  415-786-7077 (Area code change to begin secure communications using IPP:

           1. Information in the directory entry for an IPP Printer (or from
              additional information at a Web site hosting the IPP Printer)
              indicate which, if any, security protocols are used 650 in
              conjunction with IPP.

           2. The URI for the 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 Printer contains the security protocol
              information (https://..., etc.).

         In either case, the security protocol (if any) is initiated first
         which allows for the negotiation of security features. Mailing List:  ipp@pwg.org
              IPP is then
         run as an application protocol on top of the security protocols.  One
         cannot "bootstrap" the security features from Mailing List Subscription:  ipp-request@pwg.org
              IPP itself.

         ISSUE: The above is not quite correct.  Waiting for better description
         from the security document [22]. 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
              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
              Paul Moore, Microsoft
              Pat Nogay - IBM
              Bob Pentecost - HP
              Rob Rhoads - Intel

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
         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
              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
                               Expires February xx, 1998
         11. APPENDIX A: Terminology

         This specification uses the standard is terminology defined in the proposed this section.

         11.1 Conformance Terminology

         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
         "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and draft states according  "OPTIONAL" in this
         document are to the
         procedures be interpreted as described in this section.  IANA will handle registration
         of RFC 2119 [25]. The
         sections below reiterate these definitions and include some additional enums after this standard
         ones.

         11.1.1 MUST

         This word, or the terms "REQUIRED",  "SHALL" or "MANDATORY", means
         that the definition is approved in cooperation
         with an IANA-appointed registration editor from the IPP working group
         according to absolute requirement of the procedures described in this section.

         6.1 Typed Extensions specification.

         11.1.2 MUST NOT

         This document identifies both keywords and enum values. For private
         (unregistered) keyword extensions, implementers SHOULD use keywords
         with a suitable distinguishing prefix, such as "xxx-" where xxx phrase, or the phrase "SHALL NOT", means that the definition is
         an absolute prohibition of the
         (lowercase) company name registered with IANA for use in domain names.
         For private (unregistered) enum extension, implementers specification.

         11.1.3 SHOULD support
         values

         This word, or the adjective "RECOMMENDED", means that there may exist
         valid reasons in particular circumstances to ignore a particular item,
         but the reserved integer range (see "enum").

         The definitions of these various types are as follows.

         6.1.1 Type1

         The IPP standard full implications must be revised to add understood and carefully weighed
         before choosing a new keyword different course.

         11.1.4 SHOULD NOT

         This phrase, or a new enum.
         No private keywords the phrase "NOT RECOMMENDED" means that there may
         exist valid reasons in particular circumstances when the particular
         behavior is acceptable or enums are allowed.

         This draft contains even useful, but the following type1 keywords:

           - <fill in>

         This draft contains full implications
         should be understood and the following type1 enums:

           - <fill in>

         6.1.2 Type2

         Implementers can, at case carefully weighed before
         implementing any time, add new keyword behavior described with this label.

         11.1.5 MAY

         This word, or enum values by
         proposing them to the IPP working group for registration (or adjective "OPTIONAL", means that an IANA-
         appointed registry advisor after the IPP working group item is no longer
         certified) where they are reviewed for approval.  IANA keeps truly
         optional.  One vendor may choose to include the
         registry.

         This draft contains item because a
         particular marketplace requires it or because the following type2 keywords:

           - <fill in>

         This draft contains vendor feels that it
         enhances the following type2 enums:

                                Expires January 25, 1998
           - <fill in>

         6.1.3 Type3

         Implementers can, at any time, add new keyword and enum values by
         submitting product while another vendor may omit the same item.   An
         implementation which does not include a registration request directly particular option MUST be
         prepared to IANA, no IPP working
         group or IANA-appointed registry advisor review is required.

         This draft contains interoperate with another implementation which does
         include the following type3 keywords:

           - <fill in>

         This draft contains option, though perhaps with reduced functionality. In the following type3 enums:

           - <fill in>

         6.1.4 Type4

         Anyone (system administrators, system integrators, site managers,
         etc.) can, at any time, add new installation-defined values (keywords
         or new enum values) to

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         same vein an implementation which does include a local system.  Care SHOULD particular option
         MUST be taken by prepared to interoperate with another implementation which
         does not include the option (except, of course, for the
         implementers to see feature the
         option provides.)

         11.1.6 NEED NOT

         The verb "NEED NOT" indicates an action that keywords do the subject of the
         sentence does not conflict with other keywords
         defined by have to implement in order to claim conformance to
         the standard or standard.  The verb "NEED NOT" is used instead of "MAY NOT" since
         "MAY NOT" sounds like a prohibition.

         11.2 Model Terminology

         11.2.1 Keyword

         Keywords are used within this document as defined by identifiers of semantic
         entities within the implementing product.
         There abstract model.  Attribute names, some attribute
         values, attribute syntaxes, and attribute group names are represented
         as keywords.  In this document, a keyword is no registration or approval procedure for type4 values.

         This draft contains a sequence of characters
         (length of 1 to 255) which consists of the following type4 keywords: ASCII characters:
         lower-case letters ("a" - <fill in>

         This draft contains the following type4 enums: "z"), digits ("0" - <fill in>

         6.2 Registration of MIME types/sub-types for document-formats

         The "document-format" "9"), hyphen ("-"),
         period ("."), and underscore ("_").  A keyword starts with a lower-
         case letter.

         11.2.2 Attributes

         An attribute IANA enums for indicating document
         formats which IANA registers as ?  names.

         ISSUE: MIME type/sub-types has raised its head again.

         7. Security Considerations

         There is another Internet-Draft called "Internet Printing
         Protocol/1.0: Security" [22].  That document an item of information that is being drafted and
         reviewed in parallel associated with this document.  The mapping an
         instance of an IPP on top object.  An attribute consists of
         appropriate security protocols will be 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.)  The client
         optionally supplies Job Template attributes as input parameters in a
         create request (operation requests that document.

                                Expires January 25, 1998
         IPP does not introduce any new, general purpose security mechanisms
         for authentication and encryption.

         A create Job objects).  The
         Printer may choose, for security reasons, not to return all object has associated attributes that a client requests. It may even return none of the
         requested attributes. In such cases, which define supported and
         default values for the status returned Printer.

         11.2.2.1 Attribute Name

         Each attribute is the same
         as if the Printer had returned all requested attributes. The client
         cannot tell uniquely identified in this document by such its
         attribute name.  An attribute name  is a response whether the requested keyword.  The keyword
         attribute was
         present or absent on name is given in the Printer.

         8. References

         [1]  Smith, R., Wright, F., section header describing that

         deBry, Hastings, T., Zilles, S., and Gyllenskog,
              J., "Printer MIB", RFC 1759, March 1995.

         [2]  R Fielding, et al, _Hypertext Transfer Protocol _ HTTP/1.1_ RFC
              2068, January 1997

         [3]  Crocker, D., "Standard for the Format of ARPA Internet Text
              Messages", RFC 822, August 1982.

         [4]  Postel, J., "Instructions to RFC Authors", RFC 1543, October
              1993.

         [5]  ISO/IEC 10175 Document Printing Application (DPA), June 1996.

         [6] Herriot, R. (editor), X/Open A Printing System Interoperability
              Specification (PSIS), August 1995.

         [7]  Kirk, M. (editor), POSIX System Administration - Part 4: Printing
              Interfaces, POSIX 1387.4 D8, 1994.

         [8]  Borenstein, N., and Freed, N., "MIME (Multi-purpose Internet Mail
              Extensions) Part One: Mechanism for Specifying and Describing 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 Attribute Group Name

         Related attributes are grouped into named groups.  The name of the
              Format
         group is a keyword.  The group name may be used in an input parameter
         in place of Internet Message Bodies", RFC 1521, September, 1993.

         [9]  Braden, S., "Requirements naming all the attributes in the group explicitly.
         Attribute groups are defined in section 3.

         11.2.2.3 Attribute Value

         Each attribute has one or more values.  Attribute values are
         represented in the syntax type specified for Internet Hosts - Application and
              Support", RFC 1123, October, 1989,

         [10] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" RFC
              1179, August 1990.

         [11] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform Resource
              Locators (URL)", RFC 1738, December, 1994.

          [20]     Internet Printing Protocol: Requirements

                                Expires January 25, 1998
         [21] Internet Printing Protocol/1.0: Model and Semantics (This
              document)

         [22] Internet Printing Protocol/1.0: Security 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 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] Internet Printing Protocol/1.0: Protocol Specification

         [24] Internet Printing Protocol/1.0: Directory Schema

         [25] S. Bradner, "Key words indicates the
         actual "on-the-wire" encoding rules for use each syntax type. Attribute
         syntax types are defined in section 4.1.

         11.2.3 Supports

         By definition, an implementation (an instance of an IPP object)
         supports an attribute  only if that implementation responds with the
         corresponding attribute and value in RFCs a response to Indicate Requirement
              Levels", RFC 2119 , March 1997

         [26] H. Alvestrand, " Tags a query for the Identification of Languages", RFC
              1766, March 1995.

         [27] T. Hastings, "Job Monitoring MIB", <draft-ietf-print-mib-
              monitoring-01.txt>, June 1997.

         [28] F. Yergeau, "UTF-8, that
         attribute.  A given implementation may exhibit a transformation format of Unicode and ISO
              10646, RFC 2044, October 1996.

         [29] Turner, R. "Printer MIB", draft-ietf-printmib-mib-info-02.txt,
              July 8, 1997.  This I-D is an update to RFC 1759, March 1995 [1].

         [30] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND
              SPECIFICATION", RFC 1035, November 1987.

         [31] ?, "  ", RFC 2130, ?.

         [32] ?, "  ", RFC 1514, ?.

         [33] ?, "  ", RFC 1903, ?.

         9. 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.

                                Expires January 25, 1998
              El Segundo, CA   90245

              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 behavior that
         corresponds to 650 in August 1997)
              Email: robert.herriot@eng.sun.com

              Roger deBry
              HUC/003G
              IBM Corporation
              P.O. Box 1900
              Boulder, CO 80301-9191

              Phone: (303) 924-4080
              Fax: (303) 924-9889
              Email: debry@vnet.ibm.com

              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 the value of some attribute, but if the implementation,
         when queried for that attribute, doesn't respond with the supported
         attribute populated with that specific value, then as far as IPP Mailing List Subscription:  ipp-request@pwg.org is
         concerned, that implementation does not support that feature.

         A conforming implementation SHALL support all MANDATORY attributes.
         However, even for MANDATORY attributes, conformance to IPP Web Page:  http://www.pwg.org/ipp/

           Other Participants:

              Chuck Adams - Tektronix
              Jeff Barnett - IBM
              Ron Bergman - Data Products
              Sylvan Butler, HP
              Keith Carter, IBM Corporation
              Jeff Copeland - QMS
              Andy Davidson - Tektronix
              Mabry Dozier - QMS

                                Expires January 25, 1998
              Lee Farrell - Canon Information Systems
              Steve Gebert - IBM
              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
              Paul Moore, Microsoft
              Pat Nogay - IBM
              Bob Pentecost - HP
              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. 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-
         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 January 25, February xx, 1998
         10. APPENDIX A: Terminology

         This specification uses
         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 terminology defined in this section.

         10.1 Conformance Terminology

         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
         "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", context of IPP itself.
         However, due to existing practice and  "OPTIONAL" in 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 data itself, for example).

         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 data
         formatter might be able to request that the document be stapled
         directly within the print data itself.  In this
         document 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 be interpreted as described
         support OPTIONAL attributes and values, even if those attributes and
         values correspond to features and functions that are realizable in RFC 2119 [25]. The
         sections below reiterate these definitions the
         implementation. However, it is RECOMMENDED that if an IPP
         implementation that is capable of realizing any feature or function
         that corresponds to an IPP attribute and include some additional
         ones.

         10.1.1 MUST

         This word, or associated value, then
         that implementation support that IPP attribute and value.

         Note: The set of values in any of the terms "REQUIRED",  "SHALL" supported value attributes is
         set (populated) by some administrative process or "MANDATORY", means 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
                               Expires February xx, 1998
         12. 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 definition status. The status code is an absolute requirement of intended
         for use by automata, and the specification.

         10.1.2 MUST NOT

         This phrase, or status message is intended for the phrase "SHALL NOT", means that human
         end user.  Since the definition status message is an absolute prohibition OPTIONAL component of the specification.

         10.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
         operation response, an IPP application (i.e. a different course.

         10.1.4 SHOULD NOT

         This phrase, browser, GUI, print
         driver or the phrase "NOT RECOMMENDED" means that there may
         exist valid reasons in particular circumstances when the particular
         behavior gateway) is acceptable NOT REQUIRED to examine or even useful, but display the full implications
         should be understood and status
         message.

         The prefix of the case carefully weighed before
         implementing any behavior described with this label.

         10.1.5 MAY

         This word, or status keyword defines the adjective "OPTIONAL", means that an item is truly
         optional.  One vendor may choose class of response as
         follows:

           "informational" - Request received, continuing process
           "successful" - The action was successfully received, understood,
              and accepted
           "redirection" - Further action must be taken in order to include complete
              the item because a
         particular marketplace requires it request
           "client-error" - The request contains bad syntax 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 cannot be
         prepared
              fulfilled
           "server-error" - The server failed to interoperate with another implementation which does
         include fulfill an apparently valid
              request

         Since IPP status codes are type2 enums, they are extensible.  IPP
         applications are NOT REQUIRED to understand the option, meaning of all
         registered status codes, though perhaps with reduced functionality. In such understanding is obviously
         desirable.  However, applications SHALL understand the

                                Expires January 25, 1998
         same vein an implementation which does include a particular option
         MUST be prepared class of any
         status code, as indicated by the prefix, and treat any unrecognized
         response as being equivalent to interoperate with another implementation which
         does not include the option (except, first status code of course, for the feature that class,
         with the
         option provides.)

         10.1.6 CONDITIONALLY MANDATORY

         This term means exception that an item MUST unrecognized response shall not be implemented in a conforming
         implementation cached.
         For example, if the specified condition an unrecognized status code of "client-error-foo-bar"
         is true.  Conversely, a
         conforming implementation NEED NOT implement received by the item 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 present the specified
         condition OPTIONAL message (if present) to the
         end user since the message is false.

         ISSUE: Bob H. writes: After writing likely to contain human readable
         information which will help to explain the paragraphs below, I have
         concluded unusual status.

         12.1 Status Codes (type2 keyword)

         Each status code is described below. Section 12.2 contains a table
         that job-template attributes should all be optional, indicates which status codes apply to which operations.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         12.1.1 Informational

         This class of status code indicates a provisional response and we
         should drop the "conditionally mandatory" term.  At the very least,
         they have is to
         be optional used for print servers. informational purposes only.

         There may be some
         argument for making some of them conditionally mandatory are no status codes defined in embedded
         printers, but the extra complexity of the explanation may not be worth
         the trouble. We all need to give IPP 1.0 for this issue some more thought. As long
         as the explanation is so murky, I don't think any two people would
         come up with the same list class of mandatory attributes for an
         implementation and status
         code.

         12.1.2 Successful Status Codes

         This class of status code indicates that is no better than making them optional.

         Now for the details.

         Before discussing the issue, we should understand that there are two
         categories of attributes:

           o printer control (e.g. media or sides)

           o job control (e.g. job-priority, job-sheets client's request was
         successfully received, understood, and accepted.

         12.1.2.1 successful-ok (0x00)

         The request has succeeded.

         12.1.2.2 successful-ok-ignored-or-substituted-attributes (0x01)

         The request has succeeded, but since ignoring or  notify-events)

         And there are two types substituting of  implementations

           o embedded printer

           o print server

         We also need
         values was requested ("ipp-attribute-fidelity" set to look at the model document's definition of
         conditionally mandatory. The following is paraphrasing from 3 parts of
         the model document. It says an implementation must support 'false' in the
         attribute if it knows about and is able
         create request), some attributes were ignored or unsupported values
         were substituted with supported values in order to support it, and need not
         support process the attribute that controls a feature job
         without rejecting it.

         12.1.3 Redirection Status Codes

         This class of status code indicates that further action needs to be
         taken to fulfill the output device
         does not implement or expose. It also says that if a certain
         implementation supports only one well-known value request.

         There are no status codes defined in IPP 1.0 for this class of some "xxx-
         supported" attribute, it is not required that that implementation
         support that attribute.

                                Expires January 25, 1998 status
         code.

         12.1.4 Client Error Status Codes

         This definition class of status code is somewhat reasonable intended for an embedded printer. It is
         easy cases in which the client
         seems to determine if an output device supports have erred.  The server SHOULD return a message containing an IPP printer control
         attribute, though if
         explanation of the feature has only one value error situation and whether it may not be easy
         to determine if the value is "well-known". If a printer supports only
         letter paper, then the rules above say that support of  "media" is temporary or
         permanent condition.

         12.1.4.1 client-error-bad-request (0x400)

         The request could not
         required. But suppose be understood by the size is B only. Is B "well-known" enough server due to
         qualify for the exclusion? If malformed
         syntax.  The IPP has an exclusion for a known
         feature, application SHOULD NOT repeat the rule should exclude "non- selectable" features rather
         than "well-known" because "well-known" is subjective.

         This definition is somewhat more difficult for job control attributes
         in an embedded printer. There request without
         modifications.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         12.1.4.2 client-error-forbidden (0x401)

         The server understood the request, but is no hardware associated with job-
         sheets or job-priority. So an output-device "knows" about such a
         feature only if its software implements it, in which case IPP likely
         supports refusing to fulfill it. This all seems rather circular. So
         Additional authentication information or authorization credentials
         will not help and the answer request SHOULD NOT be repeated.  This status
         code is that all
         job control attributes are optional for embedded printers.

         For print servers, commonly used when the rule is quite inscrutable because a print server can potentially serve all types of printers with a variety of
         features. Are all printer-control attributes mandatory because a
         connected printer could have does not wish to reveal exactly
         why the feature request has been refused or all printer-control
         attributes optional because when no other response is
         applicable.

         12.1.4.3 client-error-not-authenticated (0x402)

         The request requires user authentication.  The IPP client may repeat
         the printer-server itself request with suitable authentication information. If the request
         already included authentication information, then this status code
         indicates that authorization has none of been refused for those credentials.
         If this response contains the
         features? Because job-control attributes are normally implemented by a
         print servers same challenge as the prior response,
         and not output devices, the feature doesn't exist unless
         it is implemented, hence nothing user agent has already attempted authentication at least once,
         then the response message may contain relevant diagnostic information.
         This status codes reveals more information than "client-error-
         forbidden".

         12.1.4.4 client-error-not-authorized (0x403)

         The requester is mandatory.  So I am left not
         knowing what authorized to do for a print server. Can I implement nothing perform the request.  Additional
         authentication information or must
         I implement all to authorization credentials will not help
         and the request SHOULD be conforming.  I think everything repeated.  This status code is optional.

         When I look at the four combinations of used when the 2 types of implementations
         and 2 types of attributes, I conclude that only printer control
         attributes in embedded printer implementations could be conditionally
         mandatory.  All job control attributes in embedded printers and all
         attributes in print servers must be optional.

         10.1.7 NEED NOT

         The verb "NEED NOT" indicates an action
         server wishes to reveal that the subject of authentication information is
         understandable, however, the
         sentence does requester is explicitly not have to implement in order authorized to claim conformance
         perform the request.  This status codes reveals more information than
         "client-error-forbidden".

         12.1.4.5 client-error-not-possible (0x404)

         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 aborted by the standard. system.  The verb "NEED NOT" is used instead of "MAY NOT" since
         "MAY NOT" sounds like IPP client SHOULD
         NOT repeat the request.

         12.1.4.6 client-error-timeout (0x405)

         The client did not produce a prohibition.

                                Expires January 25, 1998
         10.2 Model Terminology

         10.2.1 Keyword

         Keywords are used within this document as identifiers of semantic
         entities request 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 time that the following ASCII characters:
         lower-case letters ("a" - "z"), digits ("0" - "9"), hyphen ("-"),
         period ("."), and underscore ("_").  A keyword starts with server
         was prepared to wait.  For example, a lower-
         case letter.

         10.2.2 Parameters

         A parameter is an item of information supplied in an operation
         consisting of client issued a parameter name Create-Job
         operation and then, after a parameter value(s).  Each
         parameter has long period of time, issued a specific syntax. Clients supply input parameters in Send-
         Document operation requests and servers return output parameters in operation
         responses.  Some parameters have corresponding object attributes; some
         do not.  All parameters are defined in section 3.

         10.2.2.1 Parameter Name

         Each parameter is uniquely identified in this document by its
         parameter name which is a keyword.  The keyword parameter name is
         given in the section header describing that parameter.  In running
         text in this document, parameter names are indicated inside double
         quotation marks (").

         10.2.2.2 Parameter Value

         Each parameter has one or more values.  Parameter values are
         represented error status code was returned in response
         to the syntax type specified for Send-Document request.  The server might have been forced to
         clean up resources that parameter. In
         running text in this document, parameter values are indicated inside
         single quotation marks ('), whether their parameter syntax is keyword,
         integer, text, etc.

         10.2.2.3 Parameter Syntax

         Each parameter is defined using an explicit syntax.  In this document,
         each syntax type is defined as a keyword with specific meaning. had been held for the waiting additional
         Documents.  The
         protocol specification document [23] indicates server was forced to close the actual on-the-wire
         encoding for each parameter syntax. Parameter syntaxes are Job since the same as
         attribute syntaxes and they are defined in section 4.1. client

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
         10.2.3 Attributes

         An attribute
         took too long.  The client SHOULD NOT repeat the request without
         modifications.

         12.1.4.7 client-error-not-found (0x406)

         The server has not found anything matching the request URI.  No
         indication is an item given of information that whether the condition is associated temporary or
         permanent.  For example, a client with an
         instance of an IPP object.  An attribute consists of an attribute name
         and an attribute value(s).  Each attribute has old reference to 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.)  The client
         optionally supplies Job Template attributes as input parameters (a
         URI) tries to cancel the Job, however in a
         create request (operation requests that create the mean time the Job objects).  The
         Printer object has associated attributes which define supported might
         have been completed and
         default values for all record of it at the Printer has been
         deleted.  This status code, 'client-error-not-found' is returned
         indicating that the Printer.  Thee following rules apply:

           - When a referenced Job Template attribute can not be found.  This error
         status code is supplied also used when a client supplies a URI as an input parameter a reference
         to the document data in either a create request, Print-URI or Send-URI operation
         however the attribute document can not be found.

         In practice, an IPP application should avoid a not found situation by
         first querying and its value describe the
              desired job processing behavior.

           - The presenting a list of valid Printer object's supported attribute describes what behaviors
              are possible.

           - URIs and Job
         URIs to the end-user.

         12.1.4.8 client-error-gone (0x407)

         The Printer object's default value attribute describes what will requested object is no longer available at the server and no
         forwarding address is known.  This condition should be done when 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 other job processing information facility to determine, whether or not the condition
         is supplied by permanent, the client.

         10.2.3.1 Attribute Name

         Each attribute status code "client-error-not-found" should be used
         instead.

         This response is uniquely identified in this document primarily intended to assist the task of web
         maintenance by its
         attribute name which notifying the recipient that the resource is a keyword.  The keyword attribute name
         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
         given in left to the section header describing that attribute.  In running
         text in this document, attribute names are indicated inside double
         quotation marks (").

         10.2.3.2 Attribute Group Name

         Related attributes are grouped into named groups.  The name discretion of the
         group server
         owner.

         12.1.4.9 client-error-request-entity-too-large (0x408)

         The server is refusing to process a keyword.  The group name may be used in an input parameter
         in place of naming all request because the attributes in request entity
         is larger than the group explicitly.
         Attribute groups are defined in section 4.

         10.2.3.3 Attribute Value

         Each attribute has one server is willing or more values.  Attribute values are
         represented in able to process.  An IPP
         Printer returns this status code when it limits the syntax type specified for size of print jobs
         and it receives a print job that attribute. In
         running text in this document, attribute values exceeds that limit or when the
         operation parameters are indicated inside
         single quotation marks ('), whether so many that their attribute syntax is keyword,
         integer, text, etc. encoding causes the
         request entity to exceed server capacity.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
         10.2.3.4 Attribute Syntax

         Each attribute
         12.1.4.10 client-error-request-URI-too-long (0x409)

         The server is defined using an explicit attribute syntax.  In this
         document, each attribute syntax refusing to service the request because the request URI
         is defined as longer than the server is willing to interpret.  This rare
         condition is only likely to occur when a keyword client has improperly
         submitted a request with specific
         meaning.  The protocol specification document [23] indicates the
         actual on-the-wire encoding for each attribute syntax. Attribute
         syntaxes are defined in section 4.1.

         10.2.4 Supports

         By definition, an implementation (an instance of long query information (e.g. an IPP object)
         supports
         application allows an attribute (or end-user to enter an invalid URI), when the
         client has descended into a particular value URI "black hole" of an attribute) only if redirection (e.g., a
         redirected URI prefix that implementation responds with points to a suffix of itself), or when the corresponding attribute and
         value in
         server is under attack by a response client attempting to a query exploit security
         holes present in some servers using fixed-length buffers for that attribute.  A given
         implementation may exhibit a behavior that corresponds reading
         or manipulating the Request-URI.

         12.1.4.11 client-error-unsupported-document-format (0x40A)

         The server is refusing to service the value of
         some attribute, but if request because the implementation, when queried for that
         attribute, doesn't respond with print data
         is in a format, as specified in the supported attribute populated with "document-format" input attribute,
         that specific value, then as far as IPP is concerned, that
         implementation not supported by the IPP Printer.

         12.1.4.12 client-error-attribute-not-supported (0x40B)

         For a Create-Job, Print-Job or Validate-Job operation, if the IPP
         Printer does not support that feature.

         A conforming implementation SHALL support all MANDATORY attributes and
         all CONDITIONALLY MANDATORY one or more attributes where or attribute values
         supplied in the implementation
         satisfies request, the condition associated with Printer shall return this status.  For
         example, if the CONDITIONALLY MANDATORY
         attribute.  Conformance 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 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 mandate that all
         implementations support all possible values representing all possible
         job processing behaviors and features.  For example, if a given
         instance one of a Printer supports only certain document formats, then
         that Printer responds with
         the "document-format-supported" attribute
         populated with a set of values, possibly only one, taken from requested attributes, the
         entire set of possible values defined in Printer shall return this model document.  This
         set of status.

         In practice, an IPP application should avoid this situation by
         querying an IPP Printer for its valid attributes and values represent before
         performing an operation on the Printer's set Printer.

         12.1.5 Server Error Status Codes

         This class of supported document
         formats.  Another example is status codes indicates cases in which the "finishings-supported" attribute.  If
         a Printer server is not physically capable of stapling (there
         aware that it has erred or is no stapler
         in incapable of performing the output device itself), request.
         The server SHOULD include a message containing an explanation of the "finishings-supported" attribute
         MUST NOT be populated with
         error situation, and whether it is a temporary or permanent condition.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         12.1.5.1 server-error-internal- error (0x500)

         The server encountered an unexpected condition that prevented it from
         fulfilling the value of 'staple'.

         ISSUE: We have said request.  This error status code differs from "server-
         error-temporary-error" in that conformance does not mandate support for any
         values. For example, it implies a printer could have more permanent type of
         internal error.  It also differs from "server-error-device-error" in
         that it implies an unexpected condition (unlike a stapler and supported
         finishings-supported 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 server-error-operation-not-supported (0x501)

         The server does not support the value _staple_ and still be in
         conformance, though functionality required to fulfill the
         request. This is the appropriate response when the server does not useful.  Is this true?

         In order
         recognize an operation or is not capable of supporting it.

         12.1.5.3 server-error-service-unavailable (0x502)

         The server is currently unable to ease handle the implementation burden, if request due to a certain
         implementation supports only one well-known value
         temporary overloading or maintenance of some "xxx-
         supported" attribute, it the server.  The implication
         is NOT REQUIRED that that implementation
         support that attribute.  For example, if a Printer object represents this is a
         physical device that can not print on two sides of the media, temporary condition which will be alleviated after
         some delay. If known, the only
         possible value for length of the "sides-supported" attribute could delay may be 'one-
         sided'.  In this case, it indicated in the
         message.  If no delay is NOT REQUIRED that given, the implementation

                                Expires January 25, 1998
         support IPP application should handle the "sides-supported" attribute since
         response as it would for a client could infer
         that "server-error-temporary-internal-error"
         response.  If the implementation supports only single-sided printing from condition is more permanent, the
         absence of error status codes
         "client-error-gone" or "client-error-not-found" could be used.

         12.1.5.4 server-error-version-not-supported (0x503)

         The server does not support, or refuses to support, the "sides-supported" attribute.  If for some reason, an
         implementation only supported "two-sided-long-edge" then IPP protocol
         version that
         implementation MUST support was used in the "sides-supported" attribute to be a
         conforming implementation. request message.  The "well known value" for CONDITIONALLY
         MANDATORY attribute server is specified in the section describing
         indicating that
         attribute.

         ISSUE: The "well known value" condition for each Job Template
         attribute has not yet been identified. 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 most difficult one will be
         "media-supported", response should contain a Message describing why
         that version is there probably not one "well known value"
         for "media supported".  This "well known value" is a very slippery
         slope...

         Note: The supported attributes and what other versions are set (populated) supported by some
         administrative process or automatic sensing mechanism
         that  is outside server.

         A conforming IPP client shall specify the scope of IPP.

         11. APPENDIX B:  Status Codes

         This section defines valid version (IPP 1.0)on
         each request.  A conforming IPP server (IPP 1.0) SHALL NOT return this
         status code keywords that are used to provide
         semantic information on the results of an operation request.  Each
         operation response MUST include a conforming IPP 1.0 client.  An IPP server shall
         return this status code.  For error type status
         codes, code to a non-conforming IPP client.

         12.1.5.5 server-error-device-error (0x504)

         A printer error, such as a paper jam, occurs while the response MAY also contain 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 can be returned in the optional
         "job-state-message" attribute value or in the OPTIONAL status code
         message that provides a
         short textual description of describes the status. The error in more detail.  This error status
         code is intended
         for use by automata, and MAY be returned even though the status message operation was successful (the Job
         was submitted and is intended for now in the human
         end user.  Since 'pending' state waiting to be
         processed).

         ISSUE: This doesn't seem like a good error.  If the status message is create request
         succeeded, an OPTIONAL component OK should be returned. The job-status of printer-stopped
         gives information about the
         operation response, an IPP application (i.e. printer being stopped.

         12.1.5.6 server-error-temporary-error (0x505)

         A temporary error such as a browser, GUI, print
         driver or gateway) is NOT REQUIRED to examine or display buffer full write error, a memory overflow
         (i.e. the status
         message.

         The prefix document data exceeds the memory of the status keyword defines Printer), or a disk
         full condition, occurs while the class of response as
         follows:

           "informational" - Request received, continuing process
           "successful" - IPP Printer processes an operation.
         The action was successfully received, understood,
              and accepted
           "redirection" - Further action must be taken in order to complete client MAY try the unmodified request
           "client-error" 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, 1998
         12.2 Status Keywords 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
         ------------------                       -- -- -- -- -- - The request contains bad syntax or cannot be
              fulfilled
           "server-error" -- -- -
         successful-OK                            x  x  x  x  x  x x  x x
         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. APPENDIX C: "document-format" values

         The server failed to fulfill an apparently valid
              request

         IPP status codes are extensible.  IPP applications are NOT REQUIRED to
         understand the meaning of all Printer Working Group has registered status codes, though such

                                Expires January 25, 1998
         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 a set of "client-error-foo-bar" is received by the client, it can
         safely assume that there was something wrong type2 enum values
         with its request and
         treat the response IANA as if it had received a "client-error-bad-request"
         status code.  In such cases, IPP applications could present part of the
         OPTIONAL message (if present) to IETF Printer MIB [1] project.  The symbols
         for each value assigned by the end user since PWG starts with the message is
         likely to contain human readable information which will help four letters:
         "lang", in order to
         explain the unusual status.

         11.1 Status Codes (type2 keyword)

         Each status code is described below. Section 11.2 contains a table follow SNMP ASN.1 rules that indicates which status codes apply to which operations.

         11.1.1 Informational

         This class of status code indicates all enum symbols
         SHALL start with a provisional response and is lower case letter.  MIME types corresponding to
         be the
         integer enum value is used for informational purposes only.

         There are no status codes defined in as the value the IPP 1.0 for this class of status
         code.

         11.1.2 Successful Status Codes "document-format"
         attribute.

         This class of status code indicates that APPENDIX lists the client's request was
         successfully received, understood, and accepted.

         11.1.2.1 successful-ok

         The request has succeeded.

         11.1.2.2 successful-ok-ignored-or-substituted-attributes document formats that are currently registered
         with IANA.

         The request has succeeded, but since "best effort" printing was
         allowed and requested, in order to print the job, some attributes were
         ignored or unsupported standard values were substituted with supported values.

         11.1.3 Redirection Status Codes

         This class registered as of status code indicates that further action needs to be
         taken to fulfill the request. data of this document are:

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
         There are no status codes defined in IPP 1.0 for this class
           'other': 1 -
           'langPCL': 3 - PCL.  Starting with PCL version 5, HP-GL/2 is
              included as part of status
         code.

         11.1.4 Client Error Status Codes

         This class the PCL language.  PCL and HP-GL/2 are
              registered trademarks of status code Hewlett-Packard Company.
           'langHPGL': 4 - Hewlett-Packard Graphics Language.  HP-GL is intended for cases in which the client
         seems to have erred.  The server SHOULD return a message containing an
         explanation
              registered trademark of Hewlett-Packard Company.
           'langPJL': 5 - Peripheral Job Language.  Appears in the error situation and whether it is data stream
              between data intended for a temporary or
         permanent condition.

         11.1.4.1 client-error-bad-request

         The request could not page description language.  Hewlett-
              Packard Co.
           'langPS': 6 - PostScript Language (tm) Postscript - a trademark of
              Adobe Systems Incorporated which may be understood by the server due to malformed
         syntax.  The IPP application SHOULD NOT repeat 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
              the request without
         modifications.

         11.1.4.2 client-error-forbidden

         The server understood print process.  Pennant Systems, IBM
           'langPPDS': 8 - IBM Personal Printer Data Stream.  Originally
              called IBM ASCII, the request, but is refusing name was changed to fulfill it.
         Additional authentication information PPDS when 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.) ISO Standard, Geneva,
              Switzerland
           'langLineData': 14 - line-data: Lines of data as separate ASCII or authorization credentials
         will not help
              EBCDIC records 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 containing no other response is
         applicable.

         11.1.4.3 client-error-not-authenticated

         The request requires user authentication.  The IPP client may repeat
         the request control functions (no CR, LF,
              HT, FF, etc.).  For use with suitable authentication information. If the request
         already included authentication information, then this status code
         indicates traditional line printers.  May use
              CR and/or LF to delimit lines, instead of records.  See ISO 10175
              Document Printing Application (DPA) ISO standard, Geneva,
              Switzerland
           'langMODCA': 15 - Mixed Object Document Content Architecture
              Definitions that authorization has been refused for those credentials.
         If this response contains allow the same challenge composition, interchange, and
              presentation of final form documents as the prior response, a collection of data
              objects (text, image, graphics, bar codes), resources (fonts,
              overlays) and the user agent has already attempted authentication at least once,
         then the response message may contain relevant diagnostic information.
         This status codes reveals more information than "client-error-
         forbidden".

         11.1.4.4 client-error-not-authorized

         The requester is not authorized to perform the request.  Additional
         authentication information or authorization credentials will not help 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 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 the request SHOULD be repeated.  This status code is printer control language
              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".

                                Expires January 25, 1998
         11.1.4.5 client-error-not-possible

         This status code is 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 when by Microsoft At Work Peripherals.
              Developed by the request is Microsoft Corporation.
           'langLN03': 25 - Early DEC-PPL3, Digital Equipment Corp.
           'langCCITT': 26 -
           'langQUIC': 27 - QUIC (Quality Information Code), Page Description
              Language for something that can
         not happen.  For example, there might be a request to cancel a job
         that 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) ISO standard, Geneva,
              Switzerlan
           'langNPAP': 31 - Network Printer Alliance Protocol (NPAP).  This
              protocol has already been aborted superseded by the system.  The IPP client SHOULD
         NOT repeat IEEE 1284.1 TIPSI standard.
              (ref.  LangTIPSI(49)).
           'langDOC': 32 - Document Option Commands, Appears in the request.

         11.1.4.6 client-error-timeout

         The client did not produce data
              stream between data intended for a request within the time that page description .  QMS, Inc
           'langimPress': 33 - imPRESS, Page description language originally
              developed for the server 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 prepared intended to wait.  For example, a client issued a Create-Job
         operation be sent
              over an 8-bit channel and then, after a long period of time, issued a Send-
         Document operation supported early document preparation
              languages (e.g.  TeX and this error status code was returned TROFF).  QMS, Inc.
           'langPinwriter': 34 - 24 wire dot matrix printer for USA, Europe,
              and Asia except Japan.  More widely used in response
         to the Send-Document request.  The server might have been forced to
         clean up resources that had been held Germany, and some
              Asian countries than in US.  NEC
           'langNPDL': 35 - Page printer for Japanese market.  NEC
           'langNEC201PL': 36 - Serial printer language used in the waiting additional
         Documents.  The server was forced to close Japanese
              market.  NEC
           'langAutomatic': 37 - Automatic PDL sensing.  Automatic sensing of
              the Job since interpreter language family by the printer examining the
              document content.  Which actual interpreter language families are
              sensed depends on 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 the client
         took too long.  The client SHOULD NOT repeat input to the request without
         modifications.

         11.1.4.7 client-error-not-found interpreter
           'langPSPrinter': 42 - The server has not found anything matching 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 for the request URI. Laser Press printers.
              Tehnical reference manual: "ART IV Reference Manual", No
         indication is given of whether the condition is temporary or
         permanent.  For example, a client 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 an old ordinary ASCII characters.
              Technical reference to a Job (a
         URI) tries to cancel the Job, however in the mean time manual: "PRESCRIBE II Programming Manual"
           'langLinePrinter': 51 - A simple-text character stream which
              supports the Job might
         have been completed 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 values are defined (taken from ISO DPA[5] and all record of it at the Printer has been
         deleted.  This status code, 'client-error-not-found' is returned
         indicating that
         MIB[1]):

           'default': The default medium for the referenced Job can not be found.  This error
         status code is also used when a client supplies a URI as a reference
         to output device
           'iso-a4-white': Specifies the document data in either a Print-URI or Send-URI operation
         however ISO A4 white medium
           'iso-a4-colored': Specifies 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 ISO A4 coloured medium
           'iso-a4-transparent' Specifies the end-user.

         11.1.4.8 client-error-gone

         The requested object is no longer available at ISO A4 transparent medium
           'iso-a3-white': Specifies the server and no
         forwarding address is known.  This condition should be considered
         permanent.  Clients with link editing capabilities should delete
         references to ISO A3 white medium
           'iso-a3-colored': Specifies the request URI after user approval.  If ISO A3 coloured medium
           'iso-a5-white': Specifies the server does
         not know or has no facility to determine, whether or not ISO A5 white medium

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           'iso-a5-colored': Specifies the condition
         is permanent, ISO A5 coloured medium
           'iso-b4-white': Specifies the status code "client-error-not-found" should be used
         instead.

         This response is primarily intended to assist ISO B4 white medium
           'iso-b4-colored': Specifies the task of web
         maintenance by notifying ISO B4 coloured medium
           'iso-b5-white': Specifies the ISO B5 white medium
           'iso-b5-colored': Specifies the ISO B5 coloured medium
           'jis-b4-white': Specifies the recipient that JIS B4 white medium
           'jis-b4-colored': Specifies the resource is

                                Expires January 25, 1998
         intentionally unavailable and that JIS B4 coloured medium
           'jis-b5-white': Specifies 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 JIS B5 white medium
           'jis-b5-colored': Specifies the mark JIS B5 coloured medium

         The following standard values are defined for any length of time -- that is left to North American media:

           'na-letter-white': Specifies the discretion of North American letter white medium
           'na-letter-colored': Specifies the server
         owner.

         11.1.4.9 client-error-request-entity-too-large North American letter coloured
              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 coloured
              medium

         The server is refusing to process a request because following standard values are defined for envelopes:

           'iso-b4-envelope': Specifies the request entity
         is larger than ISO B4 envelope medium
           'iso-b5-envelope': Specifies the server is willing or able to process.  An IPP
         Printer returns this status code when it limits ISO B5 envelope medium
           'iso-c3-envelope': Specifies the size of print jobs
         and it receives a print job that exceeds that limit or when ISO C3 envelope medium
           'iso-c4-envelope': Specifies the
         operation parameters are so many that their encoding causes ISO C4 envelope medium
           'iso-c5-envelope': Specifies the
         request entity to exceed server capacity.

         11.1.4.10 client-error-request-URI-too-long

         The server is refusing to service ISO C5 envelope medium
           'iso-c6-envelope': Specifies the request because ISO C6 envelope medium
           'iso-designated-long-envelope': Specifies the request URI
         is longer than ISO Designated Long
              envelope medium
           'na-10x13-envelope': Specifies the North American 10x13 envelope
              medium
           'na-9x12-envelope': Specifies 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 North American 9x12 envelope
              medium
           'monarch-envelope': Specifies 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 Monarch envelope
           'na-number-10-envelope': Specifies 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 North American number 10
              business envelope medium
           'na-7x9-envelope': Specifies the Request-URI.

         11.1.4.11 client-error-unsupported-document-format

         The server is refusing to service North American 7x9 inch envelope
           'na-9x11-envelope': Specifies the request because North American 9x11 inch envelope
           'na-10x14-envelope': Specifies the print data
         is in a format, as specified in North American 10x14 inch
              envelope
           'na-number-9-envelope': Specifies the "document-format" input parameter,
         that is not supported by North American number 9
              business envelope
           'na-6x9-envelope': Specifies the IPP Printer.

         11.1.4.12 client-error-attribute-not-supported

         For a Create-Job, Print-Job or Validate-Job operation, if North American 6x9 inch envelope

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           'na-10x15-envelope': Specifies the IPP
         Printer does not support one or more attributes or attribute North American 10x15 inch
              envelope

         The following standard values
         supplied in are defined for the request, less commonly used
         media (white-only):

           'executive-white': Specifies the Printer shall return this status.  For
         example, if white executive medium
           'folio-white': Specifies the request requires A4 paper and that paper size is not
         supported by folio white medium
           'invoice-white': Specifies the white invoice medium
           'ledger-white': Specifies the white ledger medium
           'quarto-white': Specified the Printer, and "best effort" printing was not
         requested, white quarto medium
           'iso-a0-white': Specifies the Printer shall return this status.

         For a Get-Jobs operation, if ISO A0 white medium
           'iso-a1-white': Specifies the IPP Printer does not support one of ISO A1 white medium
           'iso-a2-white': Specifies the requested attributes, ISO A2 white medium
           'iso-a6-white': Specifies the Printer shall return this status.

                                Expires January 25, 1998
         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 ISO A6 white medium
           'iso-a7-white': Specifies the Printer.

         11.1.5 Server Error Status Codes

         This class of status codes indicates cases in which ISO A7 white medium
           'iso-a8-white': Specifies the server is
         aware that it has erred or is incapable of performing ISO A8 white medium
           'iso-a9-white': Specifies the request.
         The server SHOULD include a message containing an explanation of ISO A9 white medium
           'iso-10-white': Specifies the
         error situation, and whether it is a temporary or permanent condition.

         11.1.5.1 server-error-internal- error

         The server encountered an unexpected condition that prevented it from
         fulfilling ISO A10 white medium
           'iso-b0-white': Specifies 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.

         11.1.5.2 server-error-operation-not-supported

         The server does not support ISO B0 white medium
           'iso-b1-white': Specifies the ISO B1 white medium
           'iso-b2-white': Specifies the ISO B2 white medium
           'iso-b3-white': Specifies the functionality required to fulfill ISO B3 white medium
           'iso-b6-white': Specifies the
         request. This is ISO B6 white medium
           'iso-b7-white': Specifies the appropriate response when ISO B7 white medium
           'iso-b8-white': Specifies the server does not
         recognize an operation or is not capable of supporting it.

         11.1.5.3 server-error-service-unavailable

         The server is currently unable to handle ISO B8 white medium
           'iso-b9-white': Specifies the request due to a
         temporary overloading or maintenance of ISO B9 white medium
           'iso-b10-white': Specifies the server.  The implication
         is that this is a temporary condition which will be alleviated after
         some delay. If known, ISO B10 white medium
           'jis-b0-white': Specifies the length of JIS B0 white medium
           'jis-b1-white': Specifies the delay may be indicated in JIS B1 white medium
           'jis-b2-white': Specifies the
         message.  If no delay is given, JIS B2 white medium
           'jis-b3-white': Specifies the IPP application should handle JIS B3 white medium
           'jis-b6-white': Specifies the
         response as it would JIS B6 white medium
           'jis-b7-white': Specifies the JIS B7 white medium
           'jis-b8-white': Specifies the JIS B8 white medium
           'jis-b9-white': Specifies the JIS B9 white medium
           'jis-b10-white': Specifies the JIS B10 white medium

         The following standard values are defined for a "server-error-temporary-internal-error"
         response.  If engineering media:

           'a': Specifies the condition is more permanent, engineering A size medium
           'b': Specifies the error status codes
         "client-error-gone" or "client-error-not-found" could be used.

         11.1.5.4 server-error-version-not-supported engineering B size medium
           'c': Specifies the engineering C size medium
           'd': Specifies the engineering D size medium
           'e': Specifies the engineering E size medium

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         The following standard values are defined for input-trays (from ISO
         DPA and the Printer MIB):

           'top': The top input tray in the printer.
           'middle': The server does not support, or refuses to support, middle input tray in the IPP protocol
         version that was used printer.
           'bottom': The bottom input tray in the request message. printer.
           'envelope': The server is
         indicating that it is unable or unwilling to complete envelope input tray in the request
         using printer.
           'manual': The manual feed input tray in the same version as supplied printer.
           'large-capacity': The large capacity input tray in the request other than with this
         error message. printer.
           'main': The response should contain a Message describing why
         that version is not supported and what other versions main input tray
           'side': The side input tray

         The following standard values are supported by
         that server.

                                Expires January 25, 1998
         A conforming IPP client shall specify defined for media sizes (from ISO
         DPA):

           'iso-a0': Specifies 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.

         11.1.5.5 server-error-device-error

         A printer error, such ISO A0 size: 841 mm by 1189 mm as a paper jam, occurs while defined
              in ISO 216
           'iso-a1': Specifies the IPP Printer
         processes a Print or Send operation.  The response contains ISO A1 size: 594 mm by 841 mm as defined in
              ISO 216
           'iso-a2': Specifies the true
         Job Status (the values of ISO A2 size: 420 mm by 594 mm as defined in
              ISO 216
           'iso-a3': Specifies the "job-state" and "job-state-reasons"
         attributes).  Additional information can be returned ISO A3 size: 297 mm by 420 mm as defined in
              ISO 216
           'iso-a4': Specifies the optional
         "job-state-message" attribute value or ISO A4 size: 210 mm by 297 mm as defined in
              ISO 216
           'iso-a5': Specifies the OPTIONAL status code
         message that describes the error ISO A5 size: 148 mm by 210 mm as defined in more detail.  This error status
         code MAY be returned even though
              ISO 216
           'iso-a6': Specifies the operation was successful (the Job
         was submitted and is now ISO A6 size: 105 mm by 148 mm as defined in
              ISO 216
           'iso-a7': Specifies the 'pending' state waiting 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 ISO A7 size: 74 mm by 105 mm as defined in
              ISO 216
           'iso-a8': Specifies the printer being stopped.

         11.1.5.6 server-error-temporary-error

         A temporary error such ISO A8 size: 52 mm by 74 mm as a buffer full write error, a memory overflow
         (i.e. defined in
              ISO 216
           'iso-a9': Specifies the document data exceeds ISO A9 size: 37 mm by 52 mm as defined in
              ISO 216
           'iso-a10': Specifies the memory of ISO A10 size: 26 mm by 37 mm as defined in
              ISO 216
           'iso-b0': Specifies the Printer), or a disk
         full condition, occurs while ISO B0 size: 1000 mm by 1414 mm as defined
              in ISO 216
           'iso-b1': Specifies the IPP Printer processes an operation.
         The client MAY try ISO B1 size: 707 mm by 1000 mm as defined
              in ISO 216
           'iso-b2': Specifies the unmodified request again at some later point ISO B2 size: 500 mm by 707 mm as defined in
         time with an expectation that
              ISO 216
           'iso-b3': Specifies the temporary internal error condition
         may have been cleared. ISO B3 size: 353 mm by 500 mm as defined in
              ISO 216
           'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in
              ISO 216

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
         11.2 Status Keywords 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
         GO = Get-Operations, C = Cancel-Job

                                                        IPP Operations
         IPP Status Keyword                       PJ PU CJ SD SU V GA GJ GO C
         ------------------                       -- -- -- -- -- - -- -- -- -
         successful-OK                            x  x  x  x  x  x x  x  x  x
         client-error-bad-request                 x  x  x  x  x  x x  x  x  x
         client-error-not-authenticated           x  x  x  x  x  x x  x  x  x
         client-error-not-authorized              x  x  x  x  x  x x  x  x  x
         client-error-forbidden                   x  x  x  x  x  x x  x  x  x
         client-error-not-possible                x  x  x  x  x  x x  x  x  x
         client-error-not-found                   x  x  x  x  x  x x  x  x  x
         client-error-timeout                     x  x  x  x  x  x x  x  x  x
         client-error-gone                        x  x  x  x  x  x x  x  x  x
         client-error-request-entity-too-large    x  X  X  X  X
           'iso-b5': Specifies the ISO B5 size: 176 mm by 250 mm as defined in
              ISO 216
           'iso-b6': Specifies the ISO B6 size: 125 mm by 176 mm as defined in
              ISO 216
           'iso-b7': Specifies the ISO B7 size: 88 mm by 125 mm as defined in
              ISO 216
           'iso-b8': Specifies the ISO B8 size: 62 mm by 88 mm as defined in
              ISO 216
           'iso-b9': Specifies the ISO B9 size: 44 mm by 62 mm as defined in
              ISO 216
           'iso-b10': Specifies the ISO B10 size: 31 mm by 44 mm as defined in
              ISO 216
           'na-letter': Specifies the North American letter size: 8.5 inches
              by 11 inches
           'na-legal': Specifies the North American legal size: 8.5 inches by
              14 inches
           'executive': Specifies the executive size (7.25 X 10.5 in)
           'folio': Specifies the folio size (8.5 X 13 in)
           'invoice': Specifies the invoice size (5.5 X 8.5 in)
           'ledger': Specifies the ledger size (11 X 17 in)
           'quarto': Specifies the quarto size (8.5 X
         client-error-request-URI-too-long        x  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  x
         server-error-service-unavailable         x  x  x  x  x  x x  x  x  x
         server-error-timeout                     x  x  x  x  x  x x  x  x  x
         server-error-HTTP-version-not-supported  x  x  x  x  x  x x  x  x  x
         server-error-IPP-version-not-supported   x  x  x  x  x  x x  x  x  x
         server-error-device-error                x  x  x  x  x
         server-error-temporary-error 10.83 in)
           'iso-c3': Specifies the ISO C3 size: 324 mm by 458 mm as defined in
              ISO 269
           'iso-c4': Specifies the ISO C4 size: 229 mm by 324 mm as defined in
              ISO 269
           'iso-c5': Specifies the ISO C5 size: 162 mm by 229 mm as defined in
              ISO 269
           'iso-c6': Specifies the ISO C6 size: 114 mm by 162 mm as defined in
              ISO 269
           'iso-designated-long': Specifies the ISO Designated Long size: 110
              mm by 220 mm as defined in ISO 269
           'na-10x13-envelope': Specifies the North American 10x13 size: 10
              inches by 13 inches
           'na-9x12-envelope': Specifies the North American 9x12 size: 9
              inches by 12 inches
           'na-number-10-envelope': Specifies the North American number 10
              business envelope size: 4.125 inches by 9.5 inches
           'na-7x9-envelope': Specifies the North American 7x9 inch envelope
              size
           'na-9x11-envelope': Specifies the North American 9x11 inch envelope
              size
           'na-10x14-envelope': Specifies the North American 10x14 inch
              envelope size
           'na-number-9-envelope': Specifies the North American number 9
              business envelope size
           'na-6x9-envelope': Specifies the North American 6x9 envelope size
           'na-10x15-envelope': Specifies the North American 10x15 envelope
              size

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5
              in)
           'jis-b0': Specifies the JIS B0 size: 1030mm x 1456mm
           'jis-b1': Specifies the JIS B1 size: 728mm x 1030mm
           'jis-b2': Specifies the JIS B2 size: 515mm x 728mm
           'jis-b3': Specifies the JIS B3 size: 364mm x

         ISSUE: The above needs to be re-reviewed in greater detail.

         12. APPENDIX C: "document-format" enum values

         The Printer Working Group has registered a set of type2 enum values
         with IANA as part of 515mm
           'jis-b4': Specifies the IETF Printer MIB [1] project.  The standard
         value assigned by JIS B4 size: 257mm x 364mm
           'jis-b5': Specifies the PWG starts with JIS B5 size: 182mm x 257mm
           'jis-b6': Specifies the four letters: "lang", in
         order to follow SNMP ASN.1 rules that all enum symbols SHALL start
         with a lower case letter. The integer enum value is used as JIS B6 size: 128mm x 182mm
           'jis-b7': Specifies the value JIS B7 size: 91mm x 128mm
           'jis-b8': Specifies the "document-format" attribute.

         This APPENDIX lists JIS B8 size: 64mm x 91mm
           'jis-b9': Specifies the document formats that are currently registered
         with IANA.  As with all type 2 and type 3 enums, when additional enum
         values are registered with IANA, they may be used in JIS B9 size: 45mm x 64mm
           'jis-b10': Specifies the JIS B10 size: 32mm x 45mm

         15. APPENDIX E: Processing IPP withhout
         updating this appendix.

                                Expires January 25, 1998
         ISSUE: PDF does not have an enum value, though it has Attributes

         When submitting a MIME type.
         Adobe needs print job to register PDF as one of the standard values.

         The standard values registered at the current time are:

           'other': 1 -
           'langPCL': 3 - PCL.  Starting with PCL version 5, HP-GL/2 is
              included as part of an IPP Printer, the PCL language.  PCL and HP-GL/2 are
              registered trademarks of Hewlett-Packard Company.
           'langHPGL': 4 - Hewlett-Packard Graphics Language.  HP-GL is IPP model allows a
              registered trademark of Hewlett-Packard Company.
           'langPJL': 5 - Peripheral
         client to supply operation and Job Language.  Appears in Template attributes along with 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 data.  These Job Template attributes in the print process.  Pennant Systems, IBM
           'langPPDS': 8 - IBM Personal Printer Data Stream.  Originally
              called IBM ASCII, create request
         affect the name was changed to PPDS when rendering, production and finishing of the Laser
              Printer was introduced documents 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.) ISO Standard, Geneva,
              Switzerland
           'langLineData': 14 - line-data: Lines the
         job.  Similar types 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 instructions may also be contained in the
         document to delimit lines, instead of records.  See ISO 10175
              Document Printing Application (DPA) ISO standard, Geneva,
              Switzerland
           'langMODCA': 15 - Mixed Object Document Content Architecture
              Definitions be printed, that allow is, embedded within the composition, interchange, and
              presentation of final form documents as print data
         itself.  In addition, the Printer has a collection set of data
              objects (text, image, graphics, bar codes), resources (fonts,
              overlays) and page, form attributes that
         describe what rendering and finishing instructions.  Pennant
              Systems, IBM

                                Expires January 25, 1998
           'langREGIS': 16 options which are supported by
         that Printer.  This model, which allows for flexibility and power,
         also introduces the potential that at job submission time, these
         client-supplied attributes may conflict with either:

           - Remote Graphics Instruction Set, Digital
              Equipment Corp., Maynard MA
           'SCS': 17 what the implementation is capable of realizing (i.e., what the
              Printer supports), as well as
           - SNA Character String Bi-directional the instructions embedded within the print data stream
              for SNA LU-1 mode itself.

         The following sections describe how these two types of communications IBM
           'langSPDL': 18 - ISO 10180 Standard Page Description Language ISO
              Standard
           'langTEK4014': 19 - Tektronix Corp.
           'langPDS': 20 -
           'langIGP': 21 - Printronix Corp.
           'langCodeV': 22 - Magnum Code-V, Image conflicts are
         handled in the IPP model.

         15.1 Fidelity

         If there is a conflict between what the client requests and printer control language
              used what a
         Printer supports, the client may request one of two possible conflict
         handling mechanisms:

           1) either reject the job since the job can not be processed exactly
              as specified, or
           2) allow the Printer to control impact/dot- matrix printers.  QMS, Inc., Mobile
              AL
           'langDSCDSE': 23 - DSC-DSE: Data Stream Compatible make any changes necessary to proceed with
              processing the Job the best it can.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
         In the first case the client is indicating to the Printer: "Print the
         job exactly as specified with no exceptions, and Emulation
              Bi-directional print data stream if that can't be
         done, don't even bother printing the job at all." In the second case,
         the client is indicating to the Printer: "It is more important 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 to be changed or ignored."

         The IPP model accounts for non-SNA (DSC) and SNA LU-3
              3270 controller (DSE) communications IBM
           'langWPS': 24 - Windows Printing System, Resource based
              command/data stream used this situation by Microsoft At Work Peripherals.
              Developed introducing an "ipp-
         attribute-fidelity" attribute.

         In a create request, "ipp-attribute-fidelity" is a boolean attribute
         that is OPTIONALLY supplied by 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 client.  The value 'true' indicates
         that total fidelity to client supplied attributes and emulation values is
         required.  The client is requesting that the Job be printed exactly as
         specified, and if that is not possible then the job must be rejected
         rather than processed incorrectly.  The value 'false' indicates that a
         reasonable attempt to print the Job is acceptable.  If a Printer does
         not support some of the client supplied Job Template attributes or
         values, the Printer may ignore them or substitute any supported value
         for unsupported values.  The Printer may choose to substitute the
         default value associated with that attribute, or use some other well- known printer .  QMS,
              Inc.
           'langCPAP': 28 - Common
         supported value that is similar to the unsupported requested value.
         For example, if a client supplies a "media" value of 'na-letter', the
         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) ISO standard, Geneva,
              Switzerlan
           'langNPAP': 31 - Network may choose to substitute 'iso-a4' rather than a default value
         of 'envelope'.  Since this is an OPTIONAL attribute, if the client
         does not supply a value, the Printer assumes a value of 'false'.

         Each Printer Alliance Protocol (NPAP). implementation MUST support both types of "fidelty"
         printing (that is whether the client supplies a value of 'true' or
         'false').  This
              protocol has been superseded by 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 IEEE 1284.1 TIPSI standard.
              (ref.  LangTIPSI(49)).
           'langDOC': 32 - Document Option Commands, Appears in client
         supplies a value of 'false', a Printer might still reject the data
              stream between data intended Job for
         any reason including an unsupported attributes and/or values.  In the
         other case, where the client requests a page description .  QMS, Inc
           'langimPress': 33 - imPRESS, Page description language originally
              developed for value of 'true', it is
         expected that the ImageServer line Printer support this type 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 printing since the
         Printer is already indicating functional support corresponding to be sent
              over an 8-bit channel and all
         advertised supported early document preparation
              languages (e.g.  TeX and TROFF).  QMS, Inc.
           'langPinwriter': 34 - 24 wire dot matrix printer for USA, Europe, attributes and Asia except Japan.  More widely used in Germany, values.

         Since a client can always query a Printer to find out exactly what is
         and some
              Asian countries than in US.  NEC
           'langNPDL': 35 - Page printer for Japanese market.  NEC 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.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
           'langNEC201PL': 36 - Serial
           2) In a GUI context, if the End User expects the job might be moved
              to another printer language used and prefers a sub-optimal result 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 there is a conflict between the Japanese
              market.  NEC
           'langAutomatic': 37 - Automatic PDL sensing.  Automatic sensing value of an IPP Job Template
         attribute and a corresponding instruction in the interpreter language family by print data, it is
         desirable that the printer examining value of the IPP attribute take precedence over the
         document content.  Which actual interpreter language families are
              sensed depends on instruction.  Consider the printer implementation.
           '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 case where a previously formatted
         file of print data is sent to an IPP Printer.  In this case, if the input
         client supplies any attributes at job submission time, the client
         desires that those attributes override the embedded instructions.
         Consider the case were a previously formatted document has embedded in
         it commands to load 'iso-a4' media.  However, the 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 "media" Job Template attribute set to
         'na-letter'.  The job submission attribute should take precedence over
         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 able to support the interpreter
           'langPSPrinter': 42 - semantics that IPP attributes
         override the embedded instructions.

         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 IPP model accounts for this situation by introducing a "pdl-
         override-supported" attribute.

         This attribute takes on the Laser Press printers.
              Tehnical reference manual: "ART IV Reference Manual", No F33M.
              Fuji Xerox Co., Ltd.
           'langTIPSI': 49 following values:

           - Transport Independent 'attempted': This value indicates that the 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 - A simple-text character stream which
              supports attempts to
              make sure that IPP attribute values take precedence over embedded
              instructions in the control codes LF, VT, FF and CR plus Centronics or
              Dataproducts Vertical Format Unit (VFU).  language Print data, however there is commonly
              used on many older model line and matrix printers.
           'langIDP': 52 - Imaging Device Protocol Apple Computer.
           'langXJCL': 53 no guarantee.
           - Xerox Corp.

         ISSUE: Add TIFF-F?

         One special 'not-attempted': This value indicates that the Printer makes not
              attempt to ensure that IPP attribute values take precedence over
              embedded instructions in the print data.

         This is 'langAutomatic (37)'.  However a client SHALL NOT
         supply MANDATORY Printer attribute.

         At job processing time, an implementation that supports the value 'langAutomatic' in a create request.  If of
         'attempted' might try to do one of several different actions:

           1) generate an output device specific command sequence to realize
              the
         "document-format" is unknown for feature represented by the IPP attribute value

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires February xx, 1998
           2) parse the print data itself and replace the conflicting embedded
              instruction with a certain document, new embedded instruction that matches the client SHALL
         NOT supply
              intent of the IPP attribute value
           3) indicate to the Printer that external supplied attributes take
              precedence over embedded instructions and then pass the external
              IPP attribute values to the print data interpreter
           4) anything else that allows for the semantics that IPP attributes
              override embedded print data instructions.

         Since 'attempted' does not offer any type of guarantee, even though a
         given implementation might not do a very "good" job of attempting to
         ensure that IPP attributes take a higher precedence over instructions
         embedded in the create request print data, it would still be a conforming
         implementation.

         Note:  The "ipp-attribute-fidelity" attribute applies to the Printer's
         ability to either accept or reject other unsupported attributes.  In
         other words, if "ipp-attribute-fidelity" is set to 'true', a Job is
         accepted if and only if the Send-Document
         Request.

                                Expires January 25, 1998
         13. APPENDIX D:  "media" keyword values

         Standard keyword values are taken from several sources.

         Standard client supplied attributes and values are defined (taken from ISO DPA[5] and
         supported by the Printer.  Whether these attributes actually affect
         the processing of the Job depends on the ability of the Printer
         MIB[1]):

           'default': The default medium for to
         override the output device
           'iso-a4-white': Specifies instructions embedded in the ISO A4 white medium
           'iso-a4-colored': Specifies print data with the ISO A4 coloured medium
           'iso-a4-transparent' Specifies
         semantics of the ISO A4 transparent medium
           'iso-a3-white': Specifies IPP attributes.  If the ISO A3 white medium
           'iso-a3-colored': Specifies print data attributes can be
         overridden ("pdl-override-supported" set to 'attempted'), the ISO A3 coloured medium
           'iso-a5-white': Specifies Printer
         makes an attempt to use the ISO A5 white medium
           'iso-a5-colored': Specifies IPP attributes when processing the ISO A5 coloured medium
           'iso-b4-white': Specifies Job. If
         the ISO B4 white medium
           'iso-b4-colored': Specifies print data attributes can not be overridden ("pdl-override-
         supported" set to 'not-attempted'), the ISO B4 coloured medium
           'iso-b5-white': Specifies Printer makes no attempt to
         use the ISO B5 white medium
           'iso-b5-colored': Specifies IPP attributes when processing the ISO B5 coloured medium
           'jis-b4-white': Specifies Job, and hence, the JIS B4 white medium
           'jis-b4-colored': Specifies IPP
         attributes may fail to affect the JIS B4 coloured medium
           'jis-b5-white': Specifies Job processing and output in any
         manner whatsoever.

         15.3 Suggested Attribute Processing Algorithm

         When a Printer receives a create request, the JIS B5 white medium
           'jis-b5-colored': Specifies Printer either accepts
         or rejects the JIS B5 coloured medium request. The following standard values are defined for North American media:

           'na-letter-white': Specifies Printer accepts the North American letter white medium
           'na-letter-colored': Specifies create request and
         creates a Job object if it is able to accept all Job Template and
         Document attributes in the North American letter coloured
              medium
           'na-letter-transparent': Specifies request.  The Printer rejects the North American letter
              transparent medium
           'na-legal-white': Specifies request
         and does not create a Job object if the Printer rejects any Job
         Template or Document attribute in the North American legal white medium
           'na-legal-colored': Specifies request.  In order to determine
         whether or not to accept or reject the North American legal coloured
              medium

         The following standard values are defined for envelopes:

           'iso-b4-envelope': Specifies request, the ISO B4 envelope medium
           'iso-b5-envelope': Specifies Printer SHOULD use
         the ISO B5 envelope medium
           'iso-c3-envelope': Specifies following algorithm:

           1. The implementation checks to see if the ISO C3 envelope medium
           'iso-c4-envelope': Specifies operation is supported.
              If not, the ISO C4 envelope medium
           'iso-c5-envelope': Specifies Printer rejects the ISO C5 envelope medium
           'iso-c6-envelope': Specifies request and sets the ISO C6 envelope medium
           'iso-designated-long-envelope': Specifies appropriate
              status code in the ISO Designated Long
              envelope medium response.

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
           'na-10x13-envelope': Specifies
           2. The implementation checks to see if the North American 10x13 envelope
              medium
           'na-9x12-envelope': Specifies requested version is
              supported. If not, the North American 9x12 envelope
              medium
           'monarch-envelope': Specifies Printer rejects the Monarch envelope
           'na-number-10-envelope': Specifies request and sets the North American number 10
              business envelope medium
           'na-7x9-envelope': Specifies
              appropriate status code in the North American 7x9 inch envelope
           'na-9x11-envelope': Specifies response.

           3. The implementation checks to see if the North American 9x11 inch envelope
           'na-10x14-envelope': Specifies client supplied an "ipp-
              attribute-fidelity" attribute.  If the North American 10x14 inch
              envelope
           'na-number-9-envelope': Specifies attribute is missing (not
              supplied by the North American number 9
              business envelope
           'na-6x9-envelope': Specifies client), the North American 6x9 inch envelope
           'na-10x15-envelope': Specifies Printer assumes that the North American 10x15 inch
              envelope value is
              'false'.

           4.  The following standard Printer loops through all other attributes, checking to see
              if the requested values are defined for supported (e.g., the less commonly used
         media (white-only):

           'executive-white': Specifies value of "foo"
              in the request is one of the white executive medium
           'folio-white': Specifies values in the folio white medium
           'invoice-white': Specifies Printer's "foo-
              supported" attribute).  If the white invoice medium
           'ledger-white': Specifies attribute or its value is
              unsupported, the white ledger medium
           'quarto-white': Specified Printer flags it as unsupported.

           5. Once all attributes have been checked individually, the white quarto medium
           'iso-a0-white': Specifies Printer
              checks for any inconsistent values among all the ISO A0 white medium
           'iso-a1-white': Specifies supported
              values.  For example a Printer might be able to staple and to
              print on transparencies, however due to physical stapling
              limitations, the ISO A1 white medium
           'iso-a2-white': Specifies Printer might 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 to true and there are any attributes
              flagged as unsupported, the ISO A2 white medium
           'iso-a6-white': Specifies Printer rejects the ISO A6 white medium
           'iso-a7-white': Specifies request and
              returns all unsupported attributes and values in the ISO A7 white medium
           'iso-a8-white': Specifies response and
              sets the ISO A8 white medium
           'iso-a9-white': Specifies appropriate status code.

           7. If "ipp-attribute-fidelity" is set to 'false' (nor it was not
              supplied by the ISO A9 white medium
           'iso-10-white': Specifies client) and there are any attributes that are
              flagged as unsupported, the ISO A10 white medium
           'iso-b0-white': Specifies Printer, chooses to either ignore the ISO B0 white medium
           'iso-b1-white': Specifies
              unsupported attributes or change the ISO B1 white medium
           'iso-b2-white': Specifies requested value to some
              supported value.  If, for some reason, it is not possible for the ISO B2 white medium
           'iso-b3-white': Specifies
              implementation to ignore or substitute values and is unable to
              "just print the ISO B3 white medium
           'iso-b6-white': Specifies job", the Printer is still able to reject the
              request and return all unsupported attributes and values in the ISO B6 white medium
           'iso-b7-white': Specifies
              response.  In doing so, the ISO B7 white medium
           'iso-b8-white': Specifies Printer sets the ISO B8 white medium
           'iso-b9-white': Specifies appropriate status
              code.

           8. If the ISO B9 white medium
           'iso-b10-white': Specifies Printer is able to accept the ISO B10 white medium
           'jis-b0-white': Specifies request (either as is or by
              making changes and the JIS B0 white medium
           'jis-b1-white': Specifies "ipp-attribute-fidelity" attribute is set
              to 'false'), the JIS B1 white medium
           'jis-b2-white': Specifies Printer creates a new Job object with the JIS B2 white medium
           'jis-b3-white': Specifies
              remaining valid Job Template attributes.  Initially it sets the JIS B3 white medium
           'jis-b6-white': Specifies
              Job's state to 'pending'.  These Job Template attributes are
              associated with the JIS B6 white medium Job object.  All attributes which are
              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 January 25, February xx, 1998
           'jis-b7-white': Specifies
              might be in the JIS B7 white medium
           'jis-b8-white': Specifies print data itself.  That is, IPP allows for
              submission time attributes to take precedence over static
              instructions embedded in the JIS B8 white medium
           'jis-b9-white': Specifies print data.  These submission time
              attributes are persistently stored with the JIS B9 white medium
           'jis-b10-white': Specifies Job.  However, it is
              not possible for all implementations to realize the JIS B10 white medium

         The following standard values semantics of
              "override".  End users may query the Printer's "pdl-override"
              attribute to determine if the Printer either attempts or does not
              attempt to override print data instructions with IPP attributes.

           9. There are defined some cases, where a Printer supports a Job Template
              attribute and has an associated default value set for engineering media:

           'a': Specifies the engineering A size medium
           'b': Specifies that
              attribute.  In the engineering B size medium
           'c': Specifies case where a client does not supply the engineering C size medium
           'd': Specifies
              corresponding attribute, the engineering D size medium
           'e': Specifies Printer does not use its default
              values to populate Job attributes when creating the engineering E size medium new Job
              object.  The following standard Printer's default values are defined for input-trays (from ISO
         DPA and the Printer MIB):

           'top': The top input tray in the printer.
           'middle': The middle input tray in the printer.
           'bottom': The bottom input tray used at Job processing
              time where no other IPP attribute or instruction embedded in the printer.
           'envelope': The envelope input tray in
              print data is present.  Suppose the printer.
           'manual': The manual feed input tray in Printer were to associate the printer.
           'large-capacity': The large capacity input tray in
              Printer's default value with the printer.
           'main': The main input tray
           'side': The side input tray

         The following standard values are defined Job at creation time for media sizes (from ISO
         DPA):

           'iso-a0': Specifies the ISO A0 size: 841 mm by 1189 mm as defined
              in ISO 216
           'iso-a1': Specifies the ISO A1 size: 594 mm an
              attribute not supplied 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 client.  This would change it from
              a default value to an override value.  A later query of the ISO A3 size: 297 mm by 420 mm as defined in
              ISO 216
           'iso-a4': Specifies Job
              object would return a set of attributes.  Neither the ISO A4 size: 210 mm by 297 mm as defined in
              ISO 216
           'iso-a5': Specifies Printer nor
              the ISO A5 size: 148 mm by 210 mm as defined in
              ISO 216
           'iso-a6': Specifies end user would be able to tell the ISO A6 size: 105 mm difference between an
              attribute that is an "override PDL" attribute supplied by 148 mm as defined in
              ISO 216
           'iso-a7': Specifies the ISO A7 size: 74 mm
              client or a "default value" attribute supplied by 105 mm as defined in
              ISO 216

                                Expires January 25, 1998
           'iso-a8': Specifies the ISO A8 size: 52 mm by 74 mm as defined in
              ISO 216
           'iso-a9': Specifies printer.

           10. If the ISO A9 size: 37 mm by 52 mm as defined in
              ISO 216
           'iso-a10': Specifies client does not supply a value for some Job Template
              attribute, and the ISO A10 size: 26 mm by 37 mm Printer does not support that attribute, as defined in
              ISO 216
           'iso-b0': Specifies the ISO B0 size: 1000 mm by 1414 mm
              far as defined
              in ISO 216
           'iso-b1': Specifies IPP is concerned, the ISO B1 size: 707 mm by 1000 mm as defined
              in ISO 216
           'iso-b2': Specifies result of processing that Job (with
              respect to the ISO B2 size: 500 mm by 707 mm as defined in
              ISO 216
           'iso-b3': Specifies missing attribute) is undefined.

           11. Once the ISO B3 size: 353 mm by 500 mm as defined in
              ISO 216
           'iso-b4': Specifies Job object has been created, the Printer responds back
              to the client with a successful response including Job status
              attributes that indicate the ISO B4 size: 250 mm by 353 mm as defined in
              ISO 216
           'iso-b5': Specifies initial state of the ISO B5 size: 176 mm by 250 mm as defined in
              ISO 216
           'iso-b6': Specifies Job ('pending',
              'processing', etc.).  The Printer uses its own configuration and
              implementation specific algorithms for scheduling the ISO B6 size: 125 mm by 176 mm as defined Job in
              ISO 216
           'iso-b7': Specifies the ISO B7 size: 88 mm by 125 mm as defined in
              ISO 216
           'iso-b8': Specifies
              correct processing order.  Once the ISO B8 size: 62 mm by 88 mm as defined in
              ISO 216
           'iso-b9': Specifies Printer begins processing the ISO B9 size: 44 mm by 62 mm as defined in
              ISO 216
           'iso-b10': Specifies
              Job, the ISO B10 size: 31 mm by 44 mm as defined in
              ISO 216
           'na-letter': Specifies Printer changes the North American letter size: 8.5 inches
              by 11 inches
           'na-legal': Specifies Job's state to 'processing'.  The
              Printer monitors all Jobs and notifies the North American legal size: 8.5 inches intended recipients
              for each event by
              14 inches
           'executive': Specifies processing the executive size (7.25 X 10.5 in)
           'folio': Specifies all of the folio size (8.5 X 13 in)
           'invoice': Specifies "notify-events" and
              "notify-addresses" Job attributes.  If the invoice size (5.5 X 8.5 in)
           'ledger': Specifies Printer supports PDL
              override (the "pdl-override" attribute set to 'attempted'), the ledger size (11 X 17 in)
           'quarto': Specifies
              implementation does its best to see that IPP attributes take
              precedence over embedded instructions in the quarto size (8.5 X 10.83 in)
           'iso-c3': Specifies print data.

           12. The implementation of the Printer object continues to process
              the Job until it can move the ISO C3 size: 324 mm by 458 mm as defined in
              ISO 269
           'iso-c4': Specifies Job into the ISO C4 size: 229 mm by 324 mm as defined in
              ISO 269
           'iso-c5': Specifies 'completed' state.  If
              an Cancel-Job operation is received, the ISO C5 size: 162 mm by 229 mm as defined in
              ISO 269
           'iso-c6': Specifies implementation
              eventually moves the ISO C6 size: 114 mm by 162 mm as defined in
              ISO 269
           'iso-designated-long': Specifies Job into the ISO Designated Long size: 110
              mm by 220 mm as defined in ISO 269 'cancelled' state.  If the

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998
           'na-10x13-envelope': Specifies
              system encounters errors during processing that do not allow it
              to progress the North American 10x13 size: 10
              inches by 13 inches
           'na-9x12-envelope': Specifies Job into a completed state, the North American 9x12 size: 9
              inches by 12 inches
           'na-number-10-envelope': Specifies implementation
              halts all processing, cleans up any resources, and moves the North American number 10
              business envelope size: 4.125 inches by 9.5 inches
           'na-7x9-envelope': Specifies Job
              into the North American 7x9 inch envelope
              size
           'na-9x11-envelope': Specifies 'aborted' state.

           13. Once the North American 9x11 inch envelope
              size
           'na-10x14-envelope': Specifies Job moves to the North American 10x14 inch
              envelope size
           'na-number-9-envelope': Specifies 'completed', 'aborted', or
              'cancelled' state, it is an implementation decision as to when to
              destroy the North American number 9
              business envelope size
           'na-6x9-envelope': Specifies Job object and release all associated resources.
              Once the North American 6x9 envelope size
           'na-10x15-envelope': Specifies Job has been destroyed, the Printer would return either
              the "not-found" or "gone" status codes for operations directed at
              that Job.

         Some Printer implementations may support "ipp-attribute-fidelity" set
         to 'true' and "pdl-override" set to 'attempted' and yet still not be
         able to realize exactly what the North American 10x15 envelope
              size
           'monarch-envelope': Specifies client specifies in the Monarch envelope size (3.87 x 7.5
              in)
           'jis-b0': Specifies create
         request.  This is due to legacy decisions and assumptions that have
         been made about the JIS B0 size: 1030mm x 1456mm
           'jis-b1': Specifies role of job instructions embedded within the JIS B1 size: 728mm x 1030mm
           'jis-b2': Specifies print
         data and external job instructions that accompany the JIS B2 size: 515mm x 728mm
           'jis-b3': Specifies print data and
         how to handle conflicts between such instructions.  The inability to
         be 100% precise about how a given implementation will behave is also
         compounded by the JIS B3 size: 364mm x 515mm
           'jis-b4': Specifies fact that the JIS B4 size: 257mm x 364mm
           'jis-b5': Specifies two special attributes, "ipp-
         attribute-fidelity" and "pdl-override", apply to the JIS B5 size: 182mm x 257mm
           'jis-b6': Specifies whole job rather
         than specific values for each attribute. For example, some
         implementations may be able to override almost all Job Template
         attributes except for "number-up". It would only make the JIS B6 size: 128mm x 182mm
           'jis-b7': Specifies IPP model
         more complex (with relatively little added value) to allow for
         additional special attributes that apply uniquely to each Job Template
         attribute or even specific values of each attribute.

         16. APPENDIX F: Relationship to SNMP MIBs

         The IPP model is related to the JIS B7 size: 91mm x 128mm
           'jis-b8': Specifies Printer MIB [??] in the JIS B8 size: 64mm x 91mm
           'jis-b9': Specifies following
         ways:

         ISSUE: TBS.

         The IPP model is related to the JIS B9 size: 45mm x 64mm
           'jis-b10': Specifies Job Monitoring MIB [??] in the JIS B10 size: 32mm x 45mm
         following ways:

         ISSUE: TBS

         deBry, Hastings, Herriot, Isaacson, Powell
                               Expires January 25, February xx, 1998