INTERNET-DRAFT
                                                                       R. deBry
                                                                IBM Corporation
                                                                    T. Hastings
                                                              Xerox Corporation
                                                                     R. Herriot
                                                               Sun Microsystems
                                                                    S. Isaacson
                                                                   Novell, Inc.
                                                                      P. Powell
                                                     San Diego State University
                                                                  June 23,
                                                                  July 14, 1997

                  Internet Printing Protocol/1.0: Model and Semantics
                             draft-ietf-ipp-model-02.txt
                              draft-ietf-ipp-model-03.txt

         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:

                       June 23, 1997,

                                Expires December 23, 1997 January 14, 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.

                       June 23, 1997,

                                Expires December 23, 1997 January 14, 1998
                                   Table of Contents

         1. Introduction.......................................................7
       2. Terminology........................................................7
          2.1  Conformance Terminology ......................................8
             2.1.1 MUST......................................................8
             2.1.2 MUST NOT..................................................8
             2.1.3 SHOULD....................................................8
             2.1.4 SHOULD NOT................................................8
             2.1.5 MAY.......................................................8
             2.1.6 CONDITIONALLY MANDATORY...................................9
             2.1.7 NEED NOT..................................................9
          2.2  Model Terminology ...........................................10
             2.2.1 Keyword..................................................10
             2.2.2 Parameters...............................................10
                2.2.2.1  Parameter Name ....................................10
                2.2.2.2  Parameter Value ...................................10
                2.2.2.3  Parameter Syntax ..................................10
             2.2.3 Attributes...............................................11
                2.2.3.1  Attribute Name ....................................11
                2.2.3.2  Attribute Group Name ..............................11
                2.2.3.3  Attribute Value ...................................11
                2.2.3.4  Attribute Syntax ..................................11
             2.2.4 Supports.................................................12
       3.   Simplified Printing Model.........................................12
       4. Model......................................7
         2.   IPP Objects.......................................................15
          4.1 Objects....................................................9
         2.1  Printer Object ..............................................15
          4.2 Object................................................10
         2.2  Job Object ..................................................17
          4.3 Object....................................................12
         2.3  Document Object...............................................13
         2.4  Object .............................................18
          4.4  Object Relationships ........................................19
          4.5  Object Attributes ...........................................19
             4.5.1 Job Template Attribute Overview..........................19
             4.5.2 The "best-effort" Job Attribute Overview.................20
          4.6 Relationships..........................................14
         2.5  Object Identity .............................................20
       5. Identity...............................................14
         3.   IPP Operations....................................................21
          5.1 Operations................................................15
         3.1  Operation Semantics .........................................22
             5.1.1 Semantics...........................................16
         3.1.1     Get-Operations Operation.................................22
                5.1.1.1 Operation.................................17
         3.1.1.1        Get-Operations Request ............................23
                5.1.1.2 Request..............................17
         3.1.1.2        Get-Operations Response ...........................23
             5.1.2 Response.............................17
         3.1.2     Print-Job Operation......................................23
                5.1.2.1 Operation......................................17
         3.1.2.1        Print-Job Request .................................23
                5.1.2.2 Request...................................18
         3.1.2.2        Print-Job Response ................................25
             5.1.3 Response..................................20
         3.1.3     Print-URI Operation......................................26
                5.1.3.1 Operation......................................20
         3.1.3.1        Print-URI Request .................................26
                5.1.3.2 Request...................................20
         3.1.3.2        Print-URI Response ................................26
             5.1.4 Response..................................21
         3.1.4     Validate-Job Operation...................................27
                5.1.4.1 Operation...................................21
         3.1.4.1        Validate-Job Request ..............................27
                5.1.4.2 Request................................21
         3.1.4.2        Validate-Job Response .............................27

                       June 23, 1997, Expires December 23, 1997
             5.1.5 Response...............................21
         3.1.5     Create-Job Operation.....................................28
                5.1.5.1 Operation.....................................22
         3.1.5.1        Create-Job Request ................................28
                5.1.5.2 Request..................................22
         3.1.5.2        Create Job Response ...............................28
             5.1.6 Response.................................22
         3.1.6     Send-Document Operation..................................29
                5.1.6.1 Operation..................................23
         3.1.6.1        Send-Document Request .............................29
                5.1.6.2 Request...............................23
         3.1.6.2        Send-Document Response ............................29
             5.1.7 Response..............................23
         3.1.7     Send-URI Operation.......................................30
                5.1.7.1 Operation.......................................23
         3.1.7.1        Send-URI Request ..................................30
                5.1.7.2 Request....................................24
         3.1.7.2        Send-URI Response .................................30
             5.1.8 Response...................................24
         3.1.8     Cancel Job Operation.....................................30
                5.1.8.1 Operation.....................................24
         3.1.8.1        Cancel-Job Request ................................31
                5.1.8.2 Request..................................24
         3.1.8.2        Cancel-Job Response ...............................31
             5.1.9 Response.................................25
         3.1.9     Get-Attributes Operation.................................31
                5.1.9.1 Operation.................................25
         3.1.9.1        Get-Attributes Request ............................31
                5.1.9.2 Request..............................25
         3.1.9.2        Get-Attributes Response ...........................33
             5.1.10 Response.............................27
         3.1.10    Get-Jobs Operation .....................................34
                5.1.10.1 Operation.......................................27
         3.1.10.1       Get-Jobs Request ..................................34
                5.1.10.2 Request....................................27
         3.1.10.2       Get-Jobs Response .................................34
          5.2 Response...................................28
         3.2  Operation Status Codes and Messages .........................35
       6. Messages...........................28
         4.   Object Attributes.................................................35
          6.1 Attributes.............................................29
         4.1  Attribute Syntaxes ..........................................36
             6.1.1 Syntaxes............................................29
         4.1.1     Attribute Extensibility..................................37
          6.2 Extensibility..................................31
         4.2  Job Template Attributes .....................................38
             6.2.1 Attributes.......................................33
         4.2.1     job-name (name)..........................................42
             6.2.2 (name)..........................................37
         4.2.2     job-sheets (type4 keyword)...............................43
             6.2.3 keyword)...............................38

                                Expires January 14, 1998
         4.2.3     notify-events (1setOf type2 keyword).....................43
             6.2.4 keyword).....................38
         4.2.4     notify-addresses (1setOf uri)............................43
             6.2.5 uri)............................38
         4.2.5     job-priority (integer(1:100))............................44
             6.2.6 (integer(1:100))............................39
         4.2.6     job-hold-until (type4 keyword)...........................44
             6.2.7 multiple-documents-are keyword)...........................39
         4.2.7     multiple-documenthandling (type2 keyword)...................45
             6.2.8 keyword)................40
         4.2.8     best-effort (type2 keyword)..............................45
             6.2.9 (boolean)....................................40
         4.2.9     media (type4 keyword)....................................47
             6.2.10 keyword)....................................42
         4.2.10    number-up (type3 keyword) ..............................47
             6.2.11 keyword)................................42
         4.2.11    sides (type2 keyword) ..................................48
             6.2.12 keyword)....................................43
         4.2.12    printer-resolution (type2 keyword) .....................48
             6.2.13 enum)..........................43
         4.2.13    print-quality (type2 keyword) ..........................49
             6.2.14 enum)...............................44
         4.2.14    copies (integer(1:2**31 - 1)) ..........................49
             6.2.15 1))............................45
         4.2.15    finishing (1setOf type2 keyword) .......................49
             6.2.16 enum)............................45
         4.2.16    document-format (type2 keyword) ........................50
             6.2.17 keyword)..........................46
         4.2.17    compression (type3 keyword) ............................50
             6.2.18 keyword)..............................46
         4.2.18    job-k-octets (integer(0:2**31 - 1)) ....................50
             6.2.19 1))......................46
         4.2.19    job-impressions (integer(0:2**31 - 1)) .................50
             6.2.20 job- media-sheets 1))...................46
         4.2.20    job-media-sheets (integer(0:2**31 - 1)) ...............51
          6.3 1))..................47
         4.3  Job Description Attributes ..................................51
             6.3.1 Attributes....................................47
         4.3.1     job-uri (uri)............................................52
             6.3.2 (uri)............................................48
         4.3.2     job-uri-user (uri).......................................53
             6.3.3 (uri).......................................49
         4.3.3     job-originating-user (name)..............................53
             6.3.4 (name)..............................49
         4.3.4     job-originating-host (name)..............................53

                       June 23, 1997, Expires December 23, 1997
             6.3.5 (name)..............................49
         4.3.5     user-locale (type3 keyword)..............................53
             6.3.6 (locale).....................................49
         4.3.6     job-state (type1 keyword)................................53
             6.3.7 enum)...................................49
         4.3.7     job-state-reasons (1setOf  type2 keyword)................53
             6.3.8 keyword)................51
         4.3.8     job-state-message (text).................................53
             6.3.9
         4.3.9     output-device-assigned (name)............................53
             6.3.10
         4.3.10    time-since-pending (milliseconds) ......................54
             6.3.11 (milliseconds)........................53
         4.3.11    time-since-processing (milliseconds) ...................54
             6.3.12 (milliseconds).....................53
         4.3.12    time-since-completed (milliseconds) ....................54
             6.3.13 (milliseconds)......................53
         4.3.13    number-of-intervening-jobs (integer(0:2**31 - 1)) ......54
             6.3.14 1))........53
         4.3.14    job-message-from-operator (text) .......................54
             6.3.15 job-k-octets-completed (text).........................53
         4.3.15    job-k-octets-processed (integer(0:2**31 - 1)) ..........54
             6.3.16 1))............54
         4.3.16    job-impressions-completed  (integer(0:2**31 - 1)) ......55
             6.3.17 1))........54
         4.3.17    job-media-sheets-completed (integer(0:2**31 - 1)) ......55
          6.4 1))........54
         4.4  Document Attributes .........................................55
             6.4.1 Attributes...........................................54
         4.4.1     document-name (name).....................................55
             6.4.2 (name).....................................54
         4.4.2     document-format (type2 keyword)..........................55
             6.4.3 enum).............................55
         4.4.3     document-uri (uri).......................................56
          6.5 (uri).......................................55
         4.5  Printer Description Attributes ..............................56
             6.5.1 Attributes................................55
         4.5.1     printer-uri (uri)........................................57
             6.5.2 (uri)........................................56
         4.5.2     printer-uri-user (uri)...................................58
             6.5.3 (uri)...................................57
         4.5.3     printer-name (name)......................................58
             6.5.4 (name)......................................57
         4.5.4     printer-location (text)..................................58
             6.5.5 (text)..................................57
         4.5.5     printer-description (text)...............................58
             6.5.6 (text)...............................57
         4.5.6     printer-more-info-site (uri).............................58
             6.5.7 (uri).............................57
         4.5.7     printer-driver-installer (uri)...........................58
             6.5.8 (uri)...........................57

                                Expires January 14, 1998
         4.5.8     printer-make-and-model (text)............................58
             6.5.9 (text)............................57
         4.5.9     printer-more-info-manufacturer (uri).....................59
             6.5.10 (uri).....................58
         4.5.10    printer-state (type1 keyword) ..........................59
             6.5.11 keyword)............................58
         4.5.11    printer-state-reasons (1setOf type2 keyword) ...........60
             6.5.12 keyword).............59
         4.5.12    printer-is-accepting-jobs (boolean) ....................62
             6.5.13 (boolean)......................61
         4.5.13    printer-state-message (text) ...........................62
             6.5.14 (text).............................61
         4.5.14    queued-job-count (integer(0:2**31 - 1)) ................62
             6.5.15 1))..................61
         4.5.15    printer-message-from-the-operator (text) ...............62
             6.5.16 (text).................61
         4.5.16    printer-locale (locale) ................................62
             6.5.17 (locale)..................................61
         4.5.17    printer-locales-supported (1setOf locale) ..............62
             6.5.18 locale)................61
         4.5.18    color-supported (boolean) ..............................62
       7. Conformance.......................................................63
          7.1 (boolean)................................61
         4.5.19    pdl-override (type2 keyword).............................62
         4.5.20    Security Related Attributes..............................63
         4.5.20.1       message-protection-supported (keyword)..............63
         4.5.20.2       authentication-authorization-supported (keyword)....63
         5.   Conformance...................................................64
         5.1  Conditionally Mandatory .....................................63
          7.2 Mandatory.......................................64
         5.2  Client Conformance Requirements .............................63
          7.3 Requirements...............................64
         5.3  Printer Object Conformance Requirements .....................63
             7.3.1 Objects..................................................64
             7.3.2 Operations...............................................64
             7.3.3 Attributes...............................................64
             7.3.4 Requirements.......................65
         5.3.1     Objects..................................................65
         5.3.2     Operations...............................................65
         5.3.3     Attributes...............................................65
         5.3.4     Printer extensions.......................................65
             7.3.5 extensions.......................................66
         5.3.5     Attribute Syntaxes.......................................65
          7.4 Syntaxes.......................................66
         5.4  Security Conformance Requirements ...........................65
       8. Requirements.............................66
         6.   IANA Considerations, Registered Extensions, Private Extensions....66
       9. Considerations (registered and private extensions).......66
         6.1  Typed Extensions..............................................67
         6.1.1     Type1....................................................67
         6.1.2     Type2....................................................67
         6.1.3     Type3....................................................68
         6.1.4     Type4....................................................68
         6.2  Registration of MIME types/sub-types for document-formats.....68
         7.   Security Considerations...........................................66

                       June 23, 1997, Considerations.......................................69
         8.   References....................................................69
         9.   Author's Address..............................................70
         10.  APPENDIX A: Terminology.......................................73
         10.1 Conformance Terminology.......................................73
         10.1.1    MUST.....................................................73
         10.1.2    MUST NOT.................................................73
         10.1.3    SHOULD...................................................73
         10.1.4    SHOULD NOT...............................................73
         10.1.5    MAY......................................................73
         10.1.6    CONDITIONALLY MANDATORY..................................74
         10.1.7    NEED NOT.................................................74
         10.2 Model Terminology.............................................74
         10.2.1    Keyword..................................................74
         10.2.2    Parameters...............................................74
         10.2.2.1       Parameter Name......................................74

                                Expires December 23, 1997
       10.References .......................................................66
       11.Author's Address .................................................67
       12.APPENDIX A - January 14, 1998
         10.2.2.2       Parameter Value.....................................75
         10.2.2.3       Parameter Syntax....................................75
         10.2.3    Attributes...............................................75
         10.2.3.1       Attribute Name......................................75
         10.2.3.2       Attribute Group Name................................76
         10.2.3.3       Attribute Value.....................................76
         10.2.3.4       Attribute Syntax....................................76
         10.2.4    Supports.................................................76
         11.  APPENDIX B:  Status Codes ........................................70
          12.1 Codes.....................................77
         11.1 Status Codes (type2 keyword) ................................70
             12.1.1 Informational ..........................................71
             12.1.2 keyword)..................................78
         11.1.1    Informational............................................78
         11.1.2    Successful Status Codes ................................71
                12.1.2.1 successful-OK (IPPL1) .............................71
             12.1.3 Codes..................................78
         11.1.2.1       successful-ok.......................................78
         11.1.3    Redirection Status Codes ...............................71
             12.1.4 Codes.................................78
         11.1.4    Client Error Status Codes ..............................71
                12.1.4.1 client-error-bad-request (IPPL1) ..................71
                12.1.4.2 client-error-unauthorized .........................71
                12.1.4.3 client-error-payment-required .....................72
                12.1.4.4 client-error-forbidden (IPPL1) ....................72
                12.1.4.5 client-error-method-not-allowed ...................72
                12.1.4.6 client-error-timeout (NEW) ........................72
                12.1.4.7 client-error-not-found ............................72
                12.1.4.8 client-error-gone .................................72
                12.1.4.9 client-error-request-entity-too-large (IPPL1) .....73
                12.1.4.10client-error-request-URI-too-long .................73
                12.1.4.11client-error-unsupported-media-type (IPPL1) .......73
                12.1.4.12client-error-attribute-value-not-supported ........73
             12.1.5 Codes................................79
         11.1.4.1       client-error-bad-request............................79
         11.1.4.2       client-error-forbidden..............................79
         11.1.4.3       client-error-not-authenticated......................79
         11.1.4.4       client-error-not-authorized.........................79
         11.1.4.5       client-error-not-possible...........................80
         11.1.4.6       client-error-timeout................................80
         11.1.4.7       client-error-not-found..............................80
         11.1.4.8       client-error-gone...................................80
         11.1.4.9       client-error-request-entity-too-large...............81
         11.1.4.10      client-error-request-URI-too-long...................81
         11.1.4.11      client-error-unsupported-document-format............81
         11.1.4.12      client-error-attribute- not-supported...............81
         11.1.5    Server Error Status Codes ..............................74
                12.1.5.1 server-error-internal-server-error ................74
                12.1.5.2 server-error-operation-not-implemented ............74
                12.1.5.3 server-error-service-unavailable ..................74
                12.1.5.4 server-error-timeout (NEW) ........................74
                12.1.5.5 server-error-HTTP-version-not-supported (NEW) .....74
                12.1.5.6 server-error-IPP-version-not-supported ............75
                12.1.5.7 server-error-printer-error ........................75
                12.1.5.8 server-error-write-fault ..........................75
          12.2 Mapping of HTTP 1.1 Status Codes to IPP Status Keywords .....76
          12.3 Codes................................82
         11.1.5.1       server-error-internal- error........................82
         11.1.5.2       server-error-operation-not-supported................82
         11.1.5.3       server-error-service-unavailable....................82
         11.1.5.4       server-error- version-not-supported.................82
         11.1.5.5       server-error-device-error...........................83
         11.1.5.6       server-error-temporary-error........................83
         11.2 Status Keywords for IPP Operations ..........................77
       13.APPENDIX B - Operations............................84
         12.  APPENDIX C: "document-format" Values ............................77
       14.APPENDIX C - enum values.....................84
         13.  APPENDIX D:  "media" Values ......................................80

                       June 23, 1997, keyword values...........................87

                                Expires December 23, 1997 January 14, 1998
         1. Introduction

       The Internet Simplified Printing Protocol (IPP) is an application level protocol
       that can be used for distributed printing on the Internet.  The Model

         In order to a achieve its goal of realizing a workable printing
         protocol
       is heavily influenced by for the printing model introduced in Internet, the Document Internet Printing Application (ISO/IEC 10175 DPA) standard.  Although DPA
       identifies both end user and administrative features, the first version
       of IPP Protocol (IPP) is focused only
         based on end user functionality.

       Section 2 introduces the terminology used within this document.

       Section 3 introduces the a simplified IPP model.  The IPP printing model is made
       simple by exposing only which abstracts the objects, attributes, many (often
         complex) components of real world printing solutions.  Many of these
         systems include features, interfaces, and operations relationships that are
       essential for end user access and control of
         beyond the print system.  When
       future versions scope of IPP.  IPP include features which satisfy operator has to run in a distributed computing
         environment where requesters of print services  (clients,
         applications, PC drivers, etc.) cooperate and
       administrator requirements, interact with print
         service providers.  Although the model can underlying configuration may be extended to support the
       appropriate objects, attributes, and operations.

       Section 4 introduces a
         complex n-tier client/server system, an important simplifying step in
         the full semantics of IPP model is to expose only the Printer, Job, and
       Document key objects in the and interfaces
         required for printing.  The IPP model.  It covers how instances of model encapsulates these
       objects are identified, named, important
         elements into three simple object types:

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

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

         It is important, however, to each other.

       Section 5 covers the operations understand that are part of in real system
         implementations (which lie underneath the abstracted IPP model.  These
       operations include: the Create-Job, Send-Document, Print-Job, Cancel,
       Get-Attributes, and Get-Jobs operations.

       Section 6 describes the attributes, their syntaxes, and semantics which model), there
         are part other components of a print service which are not explicitly
         defined in the IPP model.  Each object's attributes are described, and
       the attributes are grouped into logical groups The following figure illustrates where IPP
         fits with respect to help clarify their
       relationships these other components.

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

         IPP Printers encapsulate the functions normally associated with
         physical output devices along with the spooling, scheduling and meaning.  These groups are also used to simplify
       queries that request
         multiple attributes.

       Section 7 is device management functions associated with a review print server.
         Printers may be registered as entries in a directory where end users
         find and select them based on some sort of conformance issues filtered and clarifies requirements
       that apply context based
         searching.  The directory is used to client side and server side implementations.

       Sections 8-11 cover extensibility, security, technical references, and
       author information.

       2. Terminology

       This specification uses store relatively static
         information about the terminology defined in this section.

                       June 23, 1997, Expires December 23, 1997
       2.1 Conformance Terminology

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and  "OPTIONAL" in this
       document are Printer, allowing end users to be interpreted as described in RFC 2119 [25].

       2.1.1 MUST

       This word, or search for and
         find Printers that match their search criteria (name, context, printer
         capabilities, etc.).

         IPP clients implement the terms "REQUIRED",  "SHALL" IPP protocol on the client side and give end
         users or "MANDATORY", mean that programs the definition is ability to query an absolute requirement IPP Printer and submit and
         manage their print jobs.  An IPP server is just that part of the specification.

       ISSUE: There are too many "SHALLs" in IPP
         Printer that implements the document right now.  Carl-Uno
       makes protocol.  The rest of the comment: "I think we have gone overboard in IPP Printer
         implements the use application semantics of SHALL
       in this version.  Every time we need a verb it is preceded by a SHALL,
       also in places where it does not serve any purpose.  I think that this
       only detracts from the places where SHALL is really useful."  These do
       need to print service itself.  The
         IPP Printer may be cleaned up.    Also, many of our conformance requirements embedded in
       the form of MANDATORY, CONDITIONALLY MANDATORY and SHALL statements are
       too stringent, and needs quite a bit of relaxation.

       2.1.2 MUST NOT

       This phrase, an output device or may be implemented
         on a host on the phrase "SHALL NOT", mean network that communicates with the definition is an
       absolute prohibition of the specification.

       2.1.3 SHOULD

       This word, or the adjective "RECOMMENDED", mean that there may exist
       valid reasons in particular circumstances to ignore a particular item,
       but output device.

                                Expires January 14, 1998
         All information about the full implications must Printer, both static and dynamic
         information, can be understood accessed directly from the Printer itself.  The
         more dynamic information associated with a Printer includes state,
         currently loaded and carefully weighed
       before choosing ready media, number of jobs on the Printer,
         errors, warnings, etc.  The Printer is optionally represented by an
         entry in a different course.

       2.1.4 SHOULD NOT

       This phrase, or directory service.  The more static information (name, URI,
         location, etc.) are stored with along with the phrase "NOT RECOMMENDED" mean that there may exist
       valid reasons entry in particular circumstances when the particular behavior directory
         service to enable filtered directory queries.

         When a job is acceptable or even useful, but submitted to the full implications should be
       understood and Printer, the case carefully weighed before implementing any
       behavior described Printer SHALL create a Job
         object.  The end user then interacts with this label.

       2.1.5 MAY

       This word, or the adjective "OPTIONAL", mean that an item is truly
       optional.  One vendor may choose new Job to include the item because a
       particular marketplace requires it or because query its
         status and monitor the vendor feels that it
       enhances progress of the product while another vendor job.  End users may omit also cancel
         the same item.   An
       implementation which does not include a particular option MUST be
       prepared Job.  The end user is able to interoperate with another implementation register to receive certain events
         which does include

                       June 23, 1997, Expires December 23, 1997 are then routed using the option, though perhaps with reduced functionality. In the same vein
       an implementation which does include notification service(s).

         2. IPP Objects

         The IPP model introduces objects of type Printer, Job, and Document.
         Each object type is defined as a particular option MUST be
       prepared to interoperate with another implementation which does not
       include the option (except, set of course, for the feature the option
       provides.)

       2.1.6 CONDITIONALLY MANDATORY

       This term means possible attributes that an item MUST may
         be implemented in a conforming supported by each instance of an object of that type.  The
         attributes (and values) supported by each object instance describe the
         implementation if (that is the item corresponds to a feature realizable features, functions, and
         characteristics either in software or behavior hardware) for that object
         instance.  For example, the
       implementation object type "Printer" is capable defined as set of realizing.  It is also true,
         attributes that each instance of a
       conforming implementation is not required to implement Printer object might potentially
         support.  In the items that
       correspond to features or behaviors that same manner, the implementation object type "Job" is not
       capable defined as a
         set of realizing.

       ISSUE:  Should we use the following definition and define an explicit
       condition for attributes that are potentially supported by each instance of a
         Job object.

         Each attribute labeled as CONDITIONALLY MANDATORY?

         This term means that included in the set of attributes defining an item object
         type labeled as:

           "MANDATORY": each object instance MUST be implemented in a conforming
            implementation if support the specified condition attribute.
           "OPTIONAL": each object instance MAY support the attribute.
           "CONDITIONALLY MANDATORY": whether or not the object instance
              supports the attribute is true.  Furthermore, determined by a
            conforming implementation NEED NOT implement the item semantic condition.
              For example, if the
            specified condition implementation behind a given instance of a
              Printer object knows about and is false.

       2.1.7 NEED NOT

       The verb "NEED NOT" indicates an action able to support multiple levels
              of job priorities, that instance MUST support the subject of "job-priority-
              supported" attribute.  An administrator may set the sentence
       does not have to implement in order to claim conformance values to be
              somewhat more restrictive that what a given implementation might
              allow, however the
       standard.  The verb "NEED NOT" is used instead attribute MUST still be supported.

                                Expires January 14, 1998
         2.1 Printer Object

         A major component of "MAY NOT" since "MAY
       NOT" sounds like a prohibition.

       ISSUE:  Occasionally in the document IPP model is the terms MANDATORY Printer object.  The
         capabilities and OPTIONAL
       get used for what a requester shall supply in a request or what 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)

         Operations which are invoked on a
       provider shall return in printer include:

           Get-Operations (Section 3.1.1)
           Print-Job (section 3.1.2)
           Print-URI (Section 3.1.3)
           Validate-Job (Section 3.1.4)
           Create-Job (section 3.1.5)
           Get-Attributes (section 3.1.9)
           Get-Jobs (section 3.1.10)

         An instance of a response.  I think that it is confusing to
       say that such and such input parameter is OPTIONAL meaning that Printer object implements the
       requester NEED NOT supply it in a request because it sounds like we are
       saying that IPP protocol.  Using
         the requester NEED not implement protocol, end users may query the input parameter and
       that attributes of the provide need not support Printer,
         submit jobs to the input parameter.  Same for
       responses.  Instead Printer, determine subsequent states of labeling input parameters submitted
         and output parameters
       as MANDATORY queued jobs, and OPTIONAL, just say something like "the requester SHALL
       supply the xxx input-parameter in the yyy operation"  or "the requester
       MAY supply cancel their own print jobs.  The actual
         implementation components behind the zzz input-parameter in the yyy operation" or "the
       requester NEED NOT supply the zzz input-parameter in the yyy operation".
       In headings for parameters, how about: "(SHALL be supplied)" Printer object abstraction may
         take on different forms and "(MAY
       be omitted)"?  In different configurations, however, the description of each parameter we need to also
       specify whether support
         details of the input parameter is MANDATORY for the
       provider or whether support is OPTIONAL.

                       June 23, 1997, Expires December 23, 1997
       2.2 Model Terminology

       2.2.1 Keyword

       Keywords are used within this document as identifiers configuration of semantic
       entities within the abstract model.  Attribute names, attribute values,
       attribute syntaxes, and attribute groups real components are represented as keywords. In
       this document, a keyword is a sequence of characters (length of 1 transparent to
       255) which consists of the following ASCII characters: lower-case
       letters, digits, hyphen ("-"), and underscore ("_").  A keyword MUST
       start with
         end user.

         Since a lower-case letter.  In the actual protocol, these keywords
       will be represented using an appropriate protocol encoding (strings,
       enumerated values, constants, operation codes, identifiers, etc.).

       2.2.2 Parameters

       A parameter Printer object is an item of information supplied in an operation
       consisting abstraction of a parameter name and parameter value(s) using a specific
       syntax for that parameter.  Clients supply input parameters in an
       operation request and Printers return generic document output parameters in
         device and print service provider, an operation
       response.  Most parameters have corresponding IPP Printer object attributes, some do
       not.  All parameters are defined in section 5.  Parameterare identified
       as being "MANDATORY", "CONDITIONALLY MANDATORY", or "OPTIONAL" for
       implementation and "SHALL could be supplied" used
         to represent any real or "MAY virtual device with semantics consistent with
         the Printer object. For example, an instance of a Printer object could
         be omitted" in operation
       requests and responses.

       2.2.2.1 Parameter Name

       Each parameter is uniquely identified in this document by its parameter
       name which is used to front end 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
       (").

       2.2.2.2 Parameter Value

       Each parameter has fax-out device, any kind of 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 values.  Parameter values are represented
       in 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 syntax type specified following figures for 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.

       2.2.2.3 Parameter Syntax

       Each parameter some examples on how to view Printer
         objects on top of several print system configurations.  The embedded

                                Expires January 14, 1998
         case below represents configurations 1 and 2. The hosted and fan-out
         figures below represent configuration 3.

                                Expires January 14, 1998
         Legend:

         ##### indicates a Printer object which is defined using
               either embedded in an explicit syntax.  In this document,
       each syntax type output device or is defined as
               hosted in a keyword with specific meaning. server.  The
       protocol specification document [23] indicates the actual representation
       for each parameter syntax that SHALL implementation
               might or might not be used for the actual protocol.

                       June 23, 1997, Expires December 23, 1997
       Parameter syntaxes are the same as attribute syntaxes which are defined
       in section 6.1.

       2.2.3 Attributes

       An attribute is an item capable of information that is associated with an 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 |
                                                  |               |
                                                  +---------------+

         2.2 Job Object

         A Job object
       instance consisting of an attribute name and attribute value(s) using is used to model a
       specific syntax for that attribute. job.  A requester sets an attribute by
       supplying an input parameter job can contain one or more
         documents.  The information required to create a Job object is sent in an operation

                                Expires January 14, 1998
         a create request which has the same
       syntax as from the attribute.  A provider returns an attribute by supplying
       an output parameter in end user via an operation response which has the same syntax
       as the attribute.  The attributes that can be set by a IPP client have to a
       corresponding representation as an input parameter.  The attributes that Printer.  A
         create request can be queires by either a client have Print-Job Request, a corresonding representation as an
       output parameter.   All attributes are defined in section 6.  Attributes
       are identified as being "MANDATORY", "CONDITIONALLY MANDATORY", Print-URI Request,
         or
       "OPTIONAL".

       2.2.3.1 Attribute Name

       Each attribute is uniquely identified in this document by its attribute
       name which is a keyword. Create-Job Request.  The keyword attribute name is given in the
       section header describing Printer MUST perform validation checks
         to verify that attribute.  In running text in this
       document, attribute names are indicated inside double quotation marks
       (").

       2.2.3.2 Attribute Group Name

       Related attributes are grouped into named attribute groups.  The name of the group is a keyword.  It MAY job may indeed be used as processed.  A client MAY send a
         Validate-Job Request (with no document data) so that the value of an input
       parameter in place Printer
         performs all validation checks without the overhead of naming transferring
         all of the attributes in document data.  As an example of some of the group explicitly.
       Attribute groups are defined in section 6.

       2.2.3.3 Attribute Value

       Each attribute has one or more values.  Attribute values validation
         checks that are represented
       in performed, the syntax type specified for create request may specify that attribute. In running text in this
       document, attribute values the
         documents within the job are indicated inside single quotation marks
       ('), whether their attribute syntax is keyword, integer, text, etc.

       2.2.3.4 Attribute Syntax

       Each attribute is defined using an explicit attribute syntax.  In this
       document, each attribute syntax is defined as to be printed duplex (on both sides of
         the media).  However, the Printer might not support such a keyword with specific
       meaning. feature.
         Once the Printer validates the submitted information, a Job object is
         created.  The protocol specification document [23] indicates instance of the actual
       representation for each attribute syntax that SHALL be used for the
       actual protocol.  Attribute syntaxes are defined in section 6.1.

                       June 23, 1997, Expires December 23, 1997
       2.2.4 Supports

       By definition, a job processing behavior or selectable feature Job object is
       supported by a Printer only if that Printer responds initialized with
         information from the
       corresponding attribute and the associated value in create request.  If a response Create-Job operation is
         used to a
       query for that attribute. A given implementation may exhibit a behavior
       that corresponds create the Job object, subsequent Send-Document operations are
         used to transfer the value of some supported attribute, but if document data from the
       implementation, when queried for that attribute, doesn't respond with client to the supported attribute populated with that specific value, then as far
       as IPP Printer.

         This model specification defines rules for what is concerned, that Printer does not support that feature. A
       conforming implementation SHALL support all MANDATORY done when:

           - optional attributes are missing
           - there are conflicts between what is supported and all
       CONDITIONALLY MANDATORY attributes whose possible values correspond to what is
              requested
           - there are conflicts between what the behaviors that client requests via external
              attributes in the implementation is capable of realizing. Therefore
       conformance to IPP does not mandate that all implementations support all
       possible values representing all possible job processing behaviors operation and
       features.

       For example, if a given instance of a Printer supports only certain
       document formats, then that Printer SHALL respond with the "document-
       format-supported" attribute populated with a set of values, possibly
       only one, taken from what the entire set of possible values defined client requests in
              embedded instructions in this
       model document.  This set of values represent the Printer's set of
       supported document formats.  Another example is page description language
              (PDL).

         Job attributes are grouped as follows:

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

         The following operations can be invoked on Jobs:

           Send-Document (section 3.1.6)
           Send-URI (Section 3.1.7)
           Cancel Job (section 3.1.8)
           Get-Attributes (section 3.1.9)

         2.3 Document Object

         A Document object consists of either printable data or a Printer is not physically capable reference
         (URI) to printable data and a set of
       stapling (there is no stapler in the output device itself), Document Attributes (see section
         4.4).  These Document Attributes only describe the
       "finishings-supported" attribute MUST NOT data to be populated with the value of
       'staple'.

       Note: The supported printed;
         they do not include any specialized document processing instructions
         that apply to only this one Document. All Job Template attributes,
         that isthose attributes that describe desired job processing behavior,

                                Expires January 14, 1998
         are set (populated) by some
       administrative process or automatic sensing mechanism which is outside
       the scope defined as part of IPP.

       3. Simplified Printing Model

       In order the Job object, therefore, they apply equally
         to all Documents within a achieve its goal of realizing a workable printing protocol Job.

         Currently there are no operations defined for the Internet, IPP is based on a simplified printing model which
       abstracts the many (often complex) components of real world printing
       solutions.  Many Document objects.

         2.4 Object Relationships

         Instances of these systems include features, interfaces, and objects within the system have relationships that are beyond MUST be
         maintained persistently along with the scope persistent storage of the
         object attributes.  An instance of IPP.  IPP has to run in a
       distributed computing environment where requesters 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
         data could be sent to a the same or a different Printer, but the
         corresponding Job object would be an identical, but different Job
         object).  A Job object contains one or more Documents.  If the
         Document is simply a reference to some print services
       (clients, applications, PC drivers, etc.) cooperate and interact with
       print service providers.  Although data stream, the underlying configuration
         reference may be used in multiple Documents in the same Job or even in
         different Jobs.  If the Document is not just a
       complex n-tier client/server system, reference, but an important simplifying step in
         actual stream of print data, the IPP model stream is to expose contained in only one
         Document, although there can be copies of the key 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 interfaces required
       for printing. unambiguously referenced.  The IPP model encapsulates requires
         that these important elements into
       three simple objects:

                       June 23, 1997, Expires December 23, 1997 values be URIs as defined by RFC 1738 [11] and RFC 1808.
         In addition to an identifier attribute, instances of Printer (Section 4.1) and Job (Section 4.2)
         Document (Section 4.3)

       Each of these
         objects has may have a set name.  An object name need not be unique across all
         instances of operations associated with it.  These
       include:

         Printer:
            Get-Operations (Section 5.1.1)
            Print-Job (Section 5.1.2)
            Print-URI (Section 5.1.3)
            Validate-Job (Section 5.1.4)
            Create-Job (Section 5.1.5)
            Get-Attributes (Section 5.1.9)
            Get-Jobs (Section 5.1.10) all objects. The Printer name is chosen and set by an
         administrator. If not supplied by the client, the Printer creates the
         Job
            Send-Document(Section 5.1.6)
            Send-URI (Section 5.1.7)
            Cancel-Job (Section 5.1.8)
            Get-Attributes (Section 5.1.9)

       There are no operations defined for a Document object.  All document
       information name.  In all cases, the name only has local meaning, and it is accessed through a
         not constrained to be unique.

         To summarize, each instance of Printer and Job objects will have two
         identifying attributes:

           - "xxx-uri": The unique identifier for this object and its operations.

       It instance
           - "xxx-name": The non unique name for this object instance

         Document objects sent to an IPP Printer only have names, no
         identifiers.  The "document-name" attribute is important, however, used to understand that in real system
       implementations (which lie underneath store the abstracted IPP model), there
       are other components name

                                Expires January 14, 1998
         of the Document.  This name is just of interest within the context of
         a print service which Job; it need not be unique.

         If Documents are printed by reference, the corresponding document
         object contains a "document-uri" attribute, but the value of this
         attribute is a reference to the document data to be printed; it is not explicitly defined
       in
         the unique identifier of the Document object itself.

         3. IPP model. The following figure illustrates where IPP fits with
       respect to Operations

         Jobs and Printers each have a set of associated operations. End users
         or programs invoke these other components.

                       June 23, 1997, Expires December 23, 1997
                                    +--------------+
                                    |  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                   +-----------------+  | operations using an IPP client. The
         operations are:

           For a Printer
                           |  Print Service  |  |
                           +-----------------+  |
                                    |         --+
                           +-----------------+
                           | Output Device(s)|
                           +-----------------+ object:
              Get-Operations (section 3.1.1) Print-Job (section 3.1.2) Print-
                URI (section 3.1.3)
              Validate-Job (section 3.1.4)
              Create-Job (section 3.1.5)
              Get-Jobs (section 3.1.8)
              Get-Attributes (section 3.1.9)

           For a Job object:
              Send-Document (section 3.1.6)
              Send-URI (section 3.1.7)
              Cancel-Job (section 3.1.8)
              Get-Attributes (section 3.1.9)

         When a client communicates with a remote IPP Printers encapsulate object, it sends an
         operation request to the functions normally associated with physical
       output devices URI for that object.  Each request carries
         along with it the spooling, scheduling and multiple device
       management functions associated with a print server. Printers may be
       registered as entries in a directory where end users find and select
       them based on some sort of filtered input parameters and context based searching.  The
       directory is used data required to store relatively static information about perform the
       Printer, allowing end users to search for
         specified operation.  Each request requires a response from the object
         indicating success or failure of the operation including output
         parameters, status codes, and/or status messages. The representation
         and find Printers that match
       their search criteria (name, context, printer capabilities, etc.).

       IPP clients implement encoding of the IPP protocol on the client side and give are contained in "Internet Printing
         Protocol: Protocol Specification."[23]

         It is assumed that URIs for IPP Printers are available to end users or
         programs the ability that wish to query an IPP invoke Printer and submit and
       manage their print jobs.  An IPP server operations.  Although NOT
         MANDATORY, it is just that part of the IPP
       Printer RECOMMENDED that implements the protocol.  The rest of the IPP Printer
       implements the application semantics of the print service itself.  The
       IPP Printer MAY be embedded in an output device or MAY Printers be embedded registered in a
       host on the network that communicates with the output device.  All
       information about the Printer, both static
         directory service which end users and dynamic information, programs can

                       June 23, 1997, Expires December 23, 1997
       be accessed directly from interrogate.
         "Internet Printing Protocol: Directory Schema"[24] defines the Printer itself.  The more dynamic
       information
         attributes to be associated with a Printer includes state, currently loaded
       and ready media, number of jobs on the Printer, errors, warnings, etc.
       When entry in a job is submitted to directory
         service.

                                Expires January 14, 1998
         3.1 Operation Semantics

         In this section, the Printer, IPP operations are described in terms of their
         contents and semantics including both the Printer SHALL request and the response for
         each operation.

         In order to create a Job
       object.  The end user then interacts with this new Job to query its
       status and monitor the progress object, a client uses one of the job.  End users may also cancel
       the Job. three
         operations:

           - The end user Print-Job operation: This operation is able to register used if the client
              wants to receive certain events
       which are then routed using create a Job with only a single Document and the notification service(s).

       4. IPP Objects

       An IPP object
              document data is defined as set of attributes that can be potentially
       supported by each instance of included in the object.  The attributes for each
       object type are identified as MANDATORY, CONDITIONALLY MANDATORY, or
       OPTIONAL (see section 2).  Each instance of an IPP object supports an
       appropriate set of attributes (with values for each of request.  In this case, the attributes)
       that describe that instance.  That is, an IPP Printer object is defined
       as set of attributes that can potentially be implemented by some entity
       claiming
              client "pushes" the document data to be an IPP the Printer.  In

           - The Print-URI operation: This operation is used if the same manner, client
              wants to create a Job object is
       defined as a set of attributes that are potentially associated with each
       instance of only a Job object.

       4.1 Printer Object

       A major component of single Document and only a URI
              reference to the IPP model document data (not the document data itself) is
              included in the request.  In this case, the Printer object.The
       capabilities and state of an IPP Printer are described "pulls" the
              document data from the location identified by its
       attributes.  Printer attributes are grouped as follows:

         "job-template" attributes (section 6.2)
         "printer-description" attributes (section 6.5)

       Operations which are invoked on a printer include:

         Get-Operations (Section 5.1.1)
         Print-Job (section 5.1.2)
         Print-URI (Section 5.1.3)
         Validate-Job (Section 5.1.4) the URI.

           - The Create-Job (section 5.1.5)
         Get-Attributes (section 5.1.9)
         Get-Jobs (section 5.1.10)

       An instance of operation: This operation is used if the client
              wants to create a Printer object implements IPP.  Using Job with one or more Documents.  This operation
              is followed by an arbitrary number of Send-Document or Send-URI
              operations (each creating another Document for this Job).  The
              Send-Document operation includes the protocol, end
       users may query document data with the attributes of
              operation request (client "pushes" the Printer, submit jobs document data to the
       Printer, determine subsequent states of submitted and queued jobs,
              printer), and
       cancel their own print jobs. The realization of the Send-URI operation includes only a Printer object may
       take on different forms for any given configuration of real components.

                       June 23, 1997, Expires December 23, 1997
       However, reference (a
              URI) to the details of document data (the Printer "pulls" the configuration of real components are
       transparent to document data
              from the end user.

       Since referenced location).

         A Create-Job operation followed by a Printer object only one Send-Document operation
         is an abstraction of a generic document output
       device or print service provider, an IPP Printer object could be used semantically equivalent to
       represent any real or virtual device with semantics consistent with the
       Printer object. For example, an instance of a Printer object could be Print-Job operation, however, for
         performance reasons, the client SHOULD use the Print-Job operation for
         all single Document Jobs.  Throughout this model specification, the
         term "create request" is used to front end a fax-out device, refer to any kind of imager, or even these three operation
         requests.

         Every operation response returns 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 MANDATORY status code and an
         OPTIONAL status message (see Section 10).  In most cases, if the
         status code indicates an error (the code belongs to either the
         "client-error" or more associated output
            devices
            3a) The associated the "server-error" group), there are additional
         output devices might or might parameters returned that are not be capable returned in the successful
         case.

         In many of
              spooling jobs
            3b) The associated output devices might or might not support IPP

       See these operations, a client supplies a list of attributes to
         be returned in the following figures response.  A Printer may be configured, for some examples on how
         security reasons, not to view Printer
       objects on top return all attributes that a client requests.
         It may even return none of several print system configurations.  The embedded
       case below represents configurations 1 and 2. The hosted and fan-out
       figures below represent configuration 3.

                       June 23, 1997, the requested attributes.  In such cases,

                                Expires December 23, 1997
       Legend:

       ##### indicates a Printer object which is
             either embedded in an output device or January 14, 1998
         the status returned is
             hosted in a server. the same as if the Printer had returned all
         requested attributes.  The implementation
             might client cannot tell by such a response
         whether the requested attribute was present or might not be capable absent on the Printer.

         3.1.1 Get-Operations Operation

         Since some of queuing/spooling.

       any   indicates any network protocol or direct
             connect, including the 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 |
                                                |               |
                                                +---------------+

       4.2 Job Object

       A Job object is used to model a job.  A job can contain one or more
       documents.  The information required operations defined in this specification are
         OPTIONAL and therefore some implementations may choose to create a Job object not
         implement support them, this operation is sent in a

                       June 23, 1997, Expires December 23, 1997
       create request from the end user via an IPP simple, MANDATORY
         operation that all implementations MUST support.  The client uses this
         operation to query a Printer.  A
       create request can be either a Print-Job Request, a Print-URI request,
       or specific implementation for a Create-Job Request. list of supported
         operations.

         3.1.1.1 Get-Operations Request

         The Printer MUST perform validation checks to
       verify that the job may indeed be processed.  A client MAY send a
       Validate-Job Get-Operations Request (with has no document data) so that the input parameters.

         3.1.1.2 Get-Operations Response

         The Printer
       performs all validation checks without returns the overhead of transferring all following output parameters as part of the document data.  As an example of some
         Get-Operations Response:

           Supported Operations ("supported-operations"):
              A list of the validation checks operations that this implementation supports
                (including all MANDATORY operations).  The values are performed, the create request may specify that the documents
       within taken
                from the job are to 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
              be printed duplex (on both sides of the media).
       However, the Printer might not support such empty.

         3.1.2 Print-Job Operation

         When an end user desires to submit a feature.  Once print job with only one Document,
         the client sends a Print-Job Request to a Printer
       validates the submitted information, and receives a Job object is created.
         Print-Job Response from that Printer.  The
       instance of the Job object is initialized information in a Print-Job
         Request (along with any default information from associated with the
       create request.  If a Create-Job operation
         Printer) is used sufficient for the Printer to create the a Job
       object, subsequent Send-Document operations are used to transfer object 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 from the client to the IPP Printer.

       This model specification defines rules for what MUST
         be done when:

         - optional attributes are missing
         - there are conflicts between what is supported printed and what is requested
         - there a Print-URI operation only contains a reference to the
         document data.

                                Expires January 14, 1998
         3.1.2.1 Print-Job Request

         The following input parameters are conflicts between what part of the client requests via external Print-Job Request:

           Job Template Attributes:
              An optional set of Job Template attributes as defined in the IPP operation and what section
              4.2.  If the client requests in
            embedded instructions in the document page description language
            (PDL). supplies no Job Template attributes are grouped as follows:

         "job-template" attributes (optionally supplied by in the client/end
            user, section 6.2)
         "job-description"
              Create-Job Request, the Printer uses its default value attributes (set by
              when processing the Printer, section 6.3)

       The following operations can be invoked on Jobs:

         Send-Document (section 5.1.6)
         Send-URI (Section 5.1.7)Cancel job.  Since a Print-Job operation is used for
              a Job (section 5.1.8)
         Get-Attributes (section 5.1.9)

       4.3 Document Object

       A with only one Document, the Document object consists of printable data attributes "document-
              name" and "document-format" are also supplied by the client.
              "document-name" is MANDATORY; "document-format" is OPTIONAL.

           Document Attributes
       (see section 6.4).  These Document Attributes only describe Content:
              The client supplies the document data to be printed; they do not include any specialized document processing
       instructions that apply to only one processed.

         The simplest Print-Job Request consists of just the Document in Content
         and nothing else.  In this case, the Printer creates a multi-document Job.
       All new Job object
         with no associated Job Template attributes (those attributes that describe desired job
       processing behavior) are defined as part of and the Job object, therefore,
       they apply equally to all Documents within job contains a Job. Currently there are no
       operations defined for Document objects.

                       June 23, 1997, Expires December 23, 1997
       4.4 Object Relationships

       Instances of objects within the system have relationships that MUST be
       maintained persistently along with the persistent storage of
         single Document.

         When a Printer receives a Print-Job Request, the object
       attributes.  A Printer can represent one either
         accepts or more output devices.  An
       output device can be represented by at most one Printer object.  A rejects the request. The Printer can contain zero or more Job objects.  A accepts the Print-Job
         Request and creates a Job object if it is contained able to accept all Job
         Template attributes in exactly one the request.  The Printer object.  A Job object contains one or more
       Documents.  If rejects the Document is simply request
         and does not create a reference to some print data
       stream, the reference may be used in multiple Documents in Job object if the same Printer rejects any Job
       or even
         Template attribute in different Jobs.  If the Document is not just request.  There are six cases to consider
         when accepting or rejecting Job Template attributes:

           1. The client supplies a reference, but
       an actual stream of print data, Job Template attribute named "xxx" and the stream SHALL contain only one
       document, although there can be copies of
              value supplied by the same document data in
       other Documents in client is among the same or different Jobs.

       ISSUE: Does "An output device can be represented values supported by at most one the
              Printer
       object" kill "fan-in" too much?

       4.5 Object Attributes

       Each object type (i.e., is defined by a set of possible attributes which
       describe among the realization of each instance values of an object.  That is, a
       Printer object the Printer's "xxx-
              supported" attribute): The "xxx" Job Template attribute is defined as set of attributes which each instance of a
              accepted. The Printer object might potentially support.  In creates the same manner, a Job object is defined as a set of attributes that are associated with each
       instance of a Job object.  Some attributes are OPTIONAL, some are
       MANDATORY, and some are CONDITIONALLY MANDATORY (see section 2).  Object
       attributes are defined in section 6 of this document.

       4.5.1 associates the
              "xxx" attribute with the new Job Template Attribute Overview

       Attributes that a object using  the value supplied
              by the client.

           2. The client may optionally include in supplies a create request are
       called Job Template attributes.  These are described in detail in
       section 6.2. attribute but the attribute
              is syntactically bad: The Printer object has associated attributes which define
       supported SHALL reject the job and default values for return
              name of the Printer.

         - When badly formed attribute (if known) in the
              "unsupported-attributes" response parameter.

           3. The client supplies a Job Template attribute and the attribute
              value is supplied not among the values supported by a the Printer:  This
              case depending on the value of the "best-effort' attribute (see
              Section 4.2.8), tIf the client in supplies a create
            request, the "best-effort" of
              'false' (or supplies no "best-effort" attribute and its value describe the desired job
            processing behavior.

         - The Printer object's supported attribute describes what behaviors
            are possible.

         - The Printer object's Printer's
              default value behavior attribute describes what will be
            done when no other job processing information is supplied by set to 'false') the
            client.

                       June 23, 1997, Printer SHALL

                                Expires December 23, 1997
       4.5.2 The "best-effort" Job Attribute Overview

       Client supplied January 14, 1998
              reject the Job Template attributes affect and return the rendering,
       production, 'client-error-attribute-
              unsupported" error code and finishing of the documents unsupported attribute in a job.  Similar types of
       instructions may also be contained within the Page Description Language
       (PDL) of
              "unsupported-attributes " output parameter. If the document to be printed.  The client
              supplies a "best-effort" attribute,
       described in detail in section 6.2.8 of 'true' (or supplies no "best-effort"
              attribute and the Printer's default behavior attribute is provided set to help manage
              'true') the Printer SHALL accept the
       conflicts between values supplied in IPP Job Template attributes and
       corresponding instructions contained within the body of substitute supported
              values for all unsupported values supplied by the document
       itself.  The "best-effort" attribute SHALL take one of client.  In
              this case, if everything else is ok, the following
       values:

         - 'shall-honor-ipp-attributes': If a Printer supports this value and returns a
              "successful-ok" status code.  The client requests this value, the Printer guarantees that all IPP
            attribute values take precedence over embedded instructions in must query the
            job data (the PDL newly
              create Job object to find out if any of the job's documents).
         - 'should-honor-ipp-attributes': If requested values have
              been modified.

           4. The client supplies a Printer supports this value, Job Template attribute and a client requests this value, the Printer SHOULD try to make
            sure that IPP attribute values take precedence over embedded PDL
            instructions, however there is no guarantee

       This "best-effort" attribute has nothing to do with conflict between
       what a
              does not support the attribute: The Printer supports and what an IPP client requests.  If there is
       such a conflict, rejects the
              attribute.  The Printer SHALL reject returns the create request.  A client
       SHOULD query 'client-error-attribute-
              unsupported' error code and the printer to find out what is supported before supplying
       specific values  rejected attribute in the
              "unsupported-attributes" output parameter.

           5. The client does not supply a create request.

       4.6 Object Identity

       All instances of Printer and Job objects have an identifier attribute
       whose value is globally unique so that they can persistently and
       unambiguously referenced.  The IPP model requires that these values be
       URIs as defined by RFC 1738 and RFC 1808.  In addition to an identifier Template attribute, instances of but the
              Printer and Job objects may have a name.  An
       object name need not be unique across all instances of  all objects. supports the attribute:  The
       Printer name attribute is chosen accepted and set by an administrator. If not supplied by
              when the Printer creates the client, tthe Job name is created by object, the Printer.  In all cases, Printer SHALL NOT
              associate the
       name only has local meaning, and is not constrained attribute with the new  Job object using Printer's
              default value attribute.  When the Printer processes that Job,
              the Printer uses the behavior implied by the default value
              Printer attribute as set at the time of Job processing (not Job
              creation).  In other words, these rules allow for a Job object to
              be unique.

       To summarize, each instance created without implementing some of Printer and the Job objects will have two
       identifying attributes:

         - "xxx-uri": The globally unique identifier Template
              attributes.  As the Printer processes the Job, if the Printer
              supports a corresponding default value attribute for this object instance
         - "xxx-name": the missing
              Job Template attribute, the Printer uses the default value.

           6. The non unique name for this object instance

                       June 23, 1997, Expires December 23, 1997
       Document objects sent to client does not supply an IPP attribute, and the Printer only have names, no identifiers. does
              not support the attribute:  The "document-name" attribute Printer accepts the Job. However,
              as far as IPP is used to store concerned, the name result of processing that Job
              (with respect to the Document.
       This name missing attributes) is just of interest within the context of undefined.  In many
              cases though, this case represents a Job; it need not legacy environment, and even
              without IPP attributes, the job will be unique.

       If Documents are printed by reference, they are identified processed successfully.
              For example, the document data might have been generated by URIs.

       5. IPP Operations

       Jobs a
              device-specific printer driver that formats the job and Printers each have emits a set
              data stream (a stream of associated operations. End users or
       programs invoke these operations using an IPP client. The operations
       are:

         For a Printer object:
            Get-Operations (section 5.1.1)               MANDATORY
            Print-Job (section 5.1.2)                    MANDATORY
            Print-URI (section 5.1.3)                    OPTIONAL
            Validate-Job (section 5.1.4)                 OPTIONAL
            Create-Job (section 5.1.5)                   OPTIONAL
            Get-Jobs (section 5.1.8)                     OPTIONAL
            Get-Attributes (section 5.1.9)               OPTIONAL

         For a Job object:
            Send-Document (section 5.1.6)                OPTIONAL
            Send-URI (section 5.1.7)                     OPTIONAL
            Cancel-Job (section 5.1.8)                   MANDATORY
            Get-Attributes (section 5.1.9)               OPTIONAL

       When a client communicates with a remote IPP object, it sends an
       operation request to the URI for PDL) that object.  Each request carries
       along with it is finely tuned for the input parameters
              intended output device and data required to perform the
       specified operation.  Each request requires a response from the object
       indicating success or failure of its internal interpreter. But, both
              the operation including response data
       and/or error messages. The representation output device and encoding the printer driver are unaware of the IPP
       protocol are contained in "Internet Printing Protocol: Protocol
       Specification."[23]

       It
              protocol, and an intermediate process (which is assumed that URIs for IPP Printers are available aware) is
              able to end users or
       programs submit the job and make sure that wish to invoke Printer operations.  Although NOT
       MANDATORY, it is RECOMMENDED that Printers delivered to the
              output device, yet not be registered in a directory
       service which end users and programs can interrogate. "Internet Printing
       Protocol: Directory Schema"[24] defines aware of all the Job Template
              attributes to that might possibly be associated
       with a Printer entry in a directory service.

                       June 23, 1997, supported.

                                Expires December 23, 1997
       5.1 Operation Semantics

       In this section, January 14, 1998
         3.1.2.2 Print-Job Response

         The Printer SHALL return to the IPP operations are described in terms of their
       contents and semantics including both client the request and following output parameters
         as part of the response.

       In order to create a new Print-Job Response:

           Job object, a Identifier ("job-uri"):
              A URI which the client MAY SHALL use one of three
       operations:

         - The Print-Job operation: for all other operations on this
              Job

           Job Status Attributes:
              This operation is used if includes the client
            wants to create a following Job with only a single Document attributes:  "job-name", "job-
              state", and "job-state-reasons".  The value of each attribute is
              taken from a "snapshot" of the document
            data new Job object sometime after the
              time the Printer receives the print request until just prior to
              returning the response to the client.  Since the  "job-state-
              message" attribute is OPTIONAL, it MAY be included in the request.  In this case, the client "pushes"
              response, but it is NOT REQUIRED.

              Note: Since any printer state information which affects a job's
              state is reflected in the document data "job-state" and "job-state-reasons"
              attributes, it is sufficient to the Printer.

         - The Print-URI operation: return only these attributes and
              no specific printer status attributes.

           Unsupported Attributes:
              If there is an error, this output parameter contains a set of
              attributes that are unsupported.  This operation output parameter is not
              used if the client wants
            to create a status code indicates that there were no errors.

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

         3.1.3 Print-URI Operation

         This operation is identical to the Print-Job operation (section 3.1.2)
         except that a client supplies a URI reference (a URI) to the document data (not
         to be printed rather than the document data itself) itself.  It is
            included in up to the request.  In this case,
         IPP server to interpret the Printer "pulls" URI and subsequently "pull" the document data
         from the location identified source referenced by the URI.

         - URI string.

         3.1.3.1 Print-URI Request

         The Create-Job operation:  This operation is used if following elements are part of the client
            wants to create a Print-URI Request:

                                Expires January 14, 1998
           Job with one or more Documents.  This operation
            is followed by an arbitrary number of Send-Document or Send-URI
            operations (each creating another Template Attributes:
              (see section 3.1.2.1)

           Document for this Job). URI ("document-uri"):
              The
            Send-Document operation includes client supplies a URI reference to the document data with the
            operation request (client "pushes" rather
              than the document data itself.

         3.1.3.2 Print-URI Response

         The Printer SHALL return to the
            printer), and client the Send-URI following output parameters
         as part of the Print-URI Response:

           Job Identifier ("job-uri"):
              (see section 3.1.2.2)

           Job Status:
              (see section 3.1.2.2)

           Unsupported Attributes:
              (see section 3.1.2.2)

         3.1.4 Validate-Job Operation

         This operation includes only a reference (a
            URI) is identical to the Print-Job operation (section 3.1.2)
         except that a client supplies no document data (the Printer "pulls" the or any reference to
         document data
            from and the referenced location).

       A Create-Job operation followed by Printer allocates no resources (i.e., a only one Send-Document operation new Job
         object) to process the job. The VALIDATE request is
       semantically equivalent only used to
         verify capabilities of a Print-Job operation, however, for
       performance reasons, printer object against whatever input
         parameters are supplied in the Validate-Job request.

         3.1.4.1 Validate-Job Request

         The following elements are part of the Validate-Job Request:

           Job Template Attributes:
              (see section 3.1.2.1)

         3.1.4.2 Validate-Job Response

         The Printer SHALL return to the client SHOULD use the Print-Job operation for
       all single Document Jobs. Throughout this model specification, following output parameters
         as part of the term
       "create request" Validate-Job Response:

                                Expires January 14, 1998
           Unsupported Attributes:
              (see section 3.1.2.2)

         Note: In this case, no "job-uri" or Job Status output parameters are
         returned.

         3.1.5 Create-Job Operation

         This operation is used to refer similar to any of the three Print-Job operation requests (section 3.1.2)
         except that creates a new job object (a Print-Job request, a Print-URI request,
       or a Create-Job request).

       5.1.1 Get-Operations Operation

       Since some of the IPP operations defined in this specification are
       OPTIONAL and therefore some implementations MAY choose client supplies no document data or any reference to not implement
       support them, this operation, Get-Operations,
         document data in the Create-Job request.  This operation is followed
         by one or more Send-Document or Send-URI operations.  It is possible
         for a simple, MANDATORY
       operation that all implementations MUST support.  The client uses this
       operation given implementation to query only support either Send-Document or
         Send-URI but not both.  In that case, a specific implementation for client SHOULD NOT use an
         unsupported operation.  If a list Printer supports the Create-Job
         operation, it MUST also support one of supported
       OPTIONAL operations.

                       June 23, 1997, Expires December 23, 1997
       5.1.1.1 Get-Operations the Send-Document or Send-URI
         operations or both.

         3.1.5.1 Create-Job Request

         The Get-Operations Request has no parameters.

       5.1.1.2 Get-Operations following elements are part of the Create-Job Request:

           Job Template Attributes:
              (see section 3.1.2.1)

         3.1.5.2 Create Job Response

         The Printer SHALL return returns to the client the following output parameters as
         part of the Get-Operations Create-Job Response:

         Supported Operations:
            A list of the OPTIONAL operations that this implementation
            supports.  This set of OPTIONAL operations are 'Create-Job',
            'Print-URI', 'Submit-Document', 'Submit-URI', 'Get-Jobs', and 'Get-
            Attributes'.

         Status
            Status information including error status

       5.1.2 Print-Job

           Job Identifier ("job-uri"):
              (see section 3.1.2.2)

           Job Status:
              (see section 3.1.2.2)

           Unsupported Attributes:
              (see section 3.1.2.2)

                                Expires January 14, 1998
         3.1.6 Send-Document Operation

       When an end user desires to submit

         Once a print job with only one Document,
       the client sends Job object has been created using a Print-Job Request to Create-Job operation
         (returning a Printer and receives "job-uri"), a Print-
       Job Response from that Printer. The information in client directs a Print-Job Request
       (along with any default information associated with the Printer) is
       sufficient for the Printer Send-Document operation to
         the newly create a Job object and then process that
       Job.  A Print-Job operation differs from a Print-URI object.  The operation in that adds a
       Print-Job operation contains new Document to the
         Job object. An entire document data to MUST be printed and a
       Print-URI operation only contains sent in a reference to the document data.

       5.1.2.1 Print-Job single Send-Document
         operation.

         3.1.6.1 Send-Document Request

         The client submits the request to a Job URI.

         The following elements abstract data types are part of the Print-Job Send-Document
         Request:

         Job Template

           Document Attributes:
            An optional
              A set of Job Template attributes as defined in section
            6.2.  If the client supplies no Job Template attributes in the
            Create-Job Request, the Printer uses its default value Document Description attributes
            when processing the job.  Since a Print-Job operation (section 4.4).

           Last Document Flag ("last-document"):
              This is used for a
            Job with only one Document, boolean flag that is set to 'true' if this is the last
              Document attributes "document-name"
            and "document-format" are also supplied by for the client.  "document-
            name" is MANDATORY; "document-format" is OPTIONAL. Job.

           Document Content Content:
              The client supplies the document data.

                       June 23, 1997, Expires December 23, 1997

         3.1.6.2 Send-Document Response

         The simplest Print-Job Request consists following output parameters are part of just the Document Content and
       nothing else. Send-Document
         Response:

           Job Status:
              (see section 3.1.2.2)

           Unsupported Attributes:
              (see section 3.1.2.2)

         3.1.7 Send-URI Operation

         This means that operation is identical to the Printer SHALL create a new Job object
       with no Job Template attributes and a single contained Document.

       When Send-Document operation (see
         section 3.1.6) except that a Printer receives client supplies a Print-Job Request, the Printer SHALL either
       accept or reject reference (a URI) to
         the request. The Printer SHALL accept document data to be printed rather than the Print-Job
       Request and SHALL create a Job object if it document data itself.
         It is able up to accept all
       attributes in the request. IPP server to interpret the URI and subsequently
         "pull" the document from the source referenced by the URI string.

                                Expires January 14, 1998
         3.1.7.1 Send-URI Request

         The Printer SHALL reject client submits the request and
       SHALL NOT create to a Job object if the Printer rejects any attribute in
       the request. There URI.

         The following abstract data types are six cases to consider when accepting or
       rejectingJob and part of the Send-URI Request:

           Document attributes:

         1. Attributes:
              (see section 3.1.6.1)

           Last Document Flag ("last-document"):
              (see section 3.1.6.1)

           Document Reference ("document-uri"):
              The client supplies a Job Template attribute named "xxx" and URI reference to the
            value supplied by document data.

         3.1.7.2 Send-URI Response

         The following output parameters are part of the client is among Send-URI Response:

           Job Status:
              (see section 3.1.6.2)

           Unsupported Attributes:
              (see section 3.1.6.2)

         3.1.8 Cancel Job Operation

         This operation allows a user to cancel one specific Print Job any time
         after the values supported by print job has been established on the
            Printer (i.e., Printer.  Some pages
         may be printed before a job is among the values of terminated if printing has already
         started when the Printer's "xxx-supported"
            attribute): The "xxx" Cancel Job Template attribute operation is accepted.  If the
            "best-effort-supported" attribute contains the value 'shall-honor-
            ipp-attributes' the Printer SHALL guarantee the behavior
            represented by received.  Only the value in end user
         who is also the "xxx" attribute (i.e., job originator ("job-originating-user" Job attribute)
         can cancel the IPP
            attribute has precedence over any other embedded job instruction).
            If using IPP 1.0.

         3.1.8.1 Cancel-Job Request

         The client submits the value request to a Job URI.

         The following abstract data types are part of the "best-effort-supported" is 'should-honor-ipp-
            attributes' then the Printer SHOULD try Cancel Job Request:

           Message ("message"):
              Optional message to realize the behavior
            requested by the client, but NEED NOT guarantee operator

                                Expires January 14, 1998
         3.1.8.2 Cancel-Job Response

         There are no output parameters other Cancel Job Response other than
         the behavior. Status Code and optional Status Message.

         3.1.9 Get-Attributes Operation

         The Get-Attributes operation allows a client to obtain information
         from a Printer creates the Job object and associates the "xxx" attribute
            with the new or Job object using  the value supplied by the client.

         2. object. The client supplies a Job Template  attribute but as an operation
         parameter the set of attribute names and/or attribute group names that
         the requester is
            syntactically bad: interested in.  The Printer SHALL reject the job and return the
            'attribute-unsupported' error code and the name of the badly formed returns a corresponding
         attribute (if known) set in the "unsupported-attributes" response
            parameter.

         3. The client supplies a Job Template attribute and with the appropriate attribute
            value is not among the values supported by the Printer:  The
            Printer SHALL reject the Job and return the 'attribute--value-
            unsupported' error code and the name of the unsupported
         filled in for each requested attribute (either explicitly named in the "unsupported-attribute-values" response parameter.

         4. The client supplies a Job Template
         request or implicitly included by naming an attribute and the group).

         3.1.9.1 Get-Attributes Request

         When querying a Printer does
            not support object, the attribute: The Printer rejects client submits the attribute.  The Get-Attributes
         request to a Printer returns the 'attribute-unsupported' error code and the name
            of the rejected attribute in URI.  When querying a Job object, the "unsupported-attributes" response
            parameter.

         5. The client does not supply
         submits the Get-Attributes request to a Job Template  attribute, but URI.The following input
         parameters are part of the
            Printer supports Get-Attributes Request whether or not the attribute:  The attribute
         request is accepted and when
            the to a Printer creates the URI or a Job object, the Printer SHALL NOT associate

                       June 23, 1997, Expires December 23, 1997
            the URI:

           Requested Attributes ("requested-attributes") :
              An optional set of attribute with names (without values) or attribute
              group names in whose values the new  Job object.  When requester is interested.  If the Printer processes
            that Job,
              client omits this input parameter, the Printer SHOULD attempt to use the behavior implied SHALL respond as
              if this input parameter had been supplied with a value of 'all'.

              Attributes may be requested by name or by group name.  For Jobs,
              the default value Printer attribute as set at the time groups include:

              - 'job-template': all of the Job
            processing (not Job creation).  In other words, these rules allow
            for Template attributes that apply
                to a Job object to be created without implementing some (the first column of the Job
            Template attributes.  As the Printer processes table in Section
                4.2).
              - 'job-description': the Job, if Job Description attributes in Section
                4.3.

              For Printers, the
            Printer supports  a corresponding default value attribute for groups include:

              - 'job-template': all of the
            missing Job Template attribute, the attributes that apply
                to a Printer uses the default value.
            Depending on the value object (the last two columns of the Printer's "best-effort" attribute,
            the Printer either guarantees the behavior corresponding to the
            default value or it does its best to realize table in
                Section 4.2).
              - 'printer-description': the behavior attributes specified in Section 4.5.

                                Expires January 14, 1998
              There are also special groups:

              - 'none': no attributes of the
            default value.  The results of processing specified object.  'none' is
                primarily useful in Get-Jobs, but can be used as a Job are undefined if "ping" with
                the Get-Attributes operation.
              - 'all': all supported attributes

              It is NOT REQUIRED that a Printer does not support the default value attribute and the
            client does not supply ALL attributes
              belonging to a group, however it is MANDATORY that a Printer
              implementation understand these group names.

              Document Attributes ("document-name", "document-format", and
              "document-uri", see Section 4.4) may also be requested either
              individually or as a group named 'document-attributes'.  If any
              or all of these attributes are requested, in the response, they
              are treated as multi-valued attributes (one value for each
              Document in the create request.

         6. The client does not supply an attribute, and Job).  If there are 5 Documents in the Printer does not
            support Job, then
              each returned Document attribute MUST have 5 values: the attribute:  The Printer accepts set of
              first values from each attribute correspond to the Job but how first
              Document, the Job
            is finally processed (with respect set of second values correspond to the missing Job Template
            attributes) is undefined.

       5.1.2.2 Print-Job Response

       The Printer SHALL return second
              Document, and so on.  In order to maintain the client same number of
              values in each returned attribute, if there is no value for the following output parameters
       as part
              "document-format" attribute for one of the Print-Job Response:

         Job Identifier:
            A URI which Documents, the client SHALL use for all other operations on this
            Job

         Job Status:
            The following Job attributes:  job-name, job-state, value
              'other' is returned in its place, and job-state-
            reasons.  The if there is no value of each attribute SHALL be from a snapshot
            taken sometime after for
              the time "document-uri" attribute for one of the Printer receives Documents, the print
            request.  The "job-state-message" attribute is OPTIONAL.

            Note: Since any printer state information which affects a job's
            state
              special URI 'none' is reflected returned in the "job-state" and "job-state-reasons"
            attributes, it is sufficient to return only these its place.  For example if all
              Document attributes are requested, and no
            specific printer status attributes.

       ISSUE:  Randy suggest that the following there are optional returns in 3 Documents is a
       response: job-originating-user  job-originating-host  user-locale  job-
       state  job-state-reasons  job-state-message  output-device-assigned
       time-since-submission  time-since-processing  number-of-intervening-jobs
       job-message-from-operator  time-since-completion  job-k-octets-completed
       job-impressions-completed  job-media-sheets-completed

                       June 23, 1997, Expires December 23, 1997
         Unsupported Attributes:
            A list of attribute names which are unsupported.
              Job, the returned attributes might look like:

              document-name = 'Document 1', 'Document 2', Document 3'
              document-format = 'langPS', 'other', 'langPCL'
              document-uri = ' ftp://some.domain.com/file1.ps', 'none', 'none'
         The existence following input parameters are part of
            any attribute name in this list implies that the Job was rejected.

         Unsupported Attribute Values:
            A list of attribute names whose client supplied Get-Attributes Request
         only when querying a Printer:

           Document Format ("document-format") :

              This input parameter conditions the Printer attributes and values are
            unsupported.  The existence of any attribute name in this list
            implies
              that might depend on the Job was rejected.

       ISSUE: Should we call both of these "attribute-syntax-invalid'?

         Status
            Status information including error status document format.  The simplest response Printer SHALL consist of the job identifier, the Job
       Status attributes, and an operation status
              return only (1) those attributes that is either an "ok" status
       or an "error" status.

       5.1.3 Print-URI Operation

       This operation is identical to are supported and (2) the Print-Job operation (section 5.1.2)
       except
              attribute values that a client supplies a reference (a URI) to are supported for the specified document data
       to be printed rather than
              format.  By specifying the document data itself.  It is up to format, the IPP
       server to interpret client can
              eliminate the URI attributes and subsequently "pull" the document from
       the source referenced by the URI string.

       5.1.3.1 Print-URI Request

       The following elements values that are part of the Print-URI Request:

         Job Template Attributes:
            (see section 5.1.2.1)

         Document Reference:
            The client supplies the not supported for a URI reference to the
              specific document data.

       5.1.3.2 Print-URI Response

       The format.  For example, a Printer SHALL return might have
              multiple interpreters to support both 'langPS' (for PostScript)
              and 'langPCL' (for PCL) documents.  However, for only one of
              those interpreters might the client the following output parameters
       as part Printer be able to support "number-
              up" with values of 'one', 'two', and 'four'.  For the Print-URI Response:

         Job Identifier:

                       June 23, 1997, other

                                Expires December 23, 1997
            (see section 5.1.2.2)

         Job Status:
            (see section 5.1.2.2)

         Unsupported Attributes:
            (see section 5.1.2.2)

         Unsupported Attribute Values:
            (see section 5.1.2.2)

         Status
            (see section 5.1.2.2)

       5.1.4 Validate-Job Operation

       This operation is identical January 14, 1998
              interpreter it might be able to the Print-Job operation (section 5.1.2)
       except that only support "number-up" with a
              value of 'one'.

              If the client supplies no document data or any reference to
       document data and omits this input parameter, the Printer allocates no resources (i.e., a new Job
       object) to process SHALL
              respond as if the job. The VALIDATE request is only used input parameter had been set to verify
       capabilities the value of
              the Printer's default value "document-format" attribute were
              supplied.  It is recommended that the client always supply a printer object against whatever input parameters are
       supplied
              value for document-format, since the Printer's default value for
              document-format may be 'langAutomatic', in which case the Validate-Job request.

       5.1.4.1 Validate-Job Request

       The following elements
              returned attributes and values are part for the union of the Validate-Job Request: document
              formats that the Printer can automatically sense.

              If this input parameter is sent in a Get-Attribute Request sent
              to a Job Template Attributes:
            (see section 5.1.2.1)

       5.1.4.2 Validate-Job URI, the request is rejected with a status code of
              'client-error-not-possible'.

         3.1.9.2 Get-Attributes Response

         The Printer SHALL return to the client returns the following output response parameters as part of the Validate-Job
         Get-Attributes Response:

         Job Identifier:
            (see section 5.1.2.2)

         Job Status:
            (see section 5.1.2.2)

         Unsupported

           Requested Attributes:
            (see section 5.1.2.2)

                       June 23, 1997, Expires December 23, 1997
         Unsupported Attribute Values:
            (see section 5.1.2.2)

         Status
            (see section 5.1.2.2)

       5.1.5 Create-Job Operation
              This operation is similar to the Print-Job operation (section 5.1.2)
       except that a client supplies no document data or any reference to
       document data in the Create-Job request.  This operation is followed by
       one or more Send-Document or Send-URI operations.  It set of requested attributes and their current
              values.  The Printer ignores (does not respond with) any
              requested attribute which is possible for a
       given implementation to only support either Send-Document or Send-URI
       but not both.  In that case, supported.

         3.1.10 Get-Jobs Operation

         The Get-Jobs operation allows a client SHOULD NOT use an unsupported
       operation.  If a Printer supports the Create-Job operation, it MUST also
       support one of the Send-Document or Send-URI operations or both.

       5.1.5.1 Create-Job Request

       The following elements are part to retrieve list of the Create-Job Request:

         Job Template Attributes:
             (see section 5.1.2.1)

       5.1.5.2 Create Job Response

       The Printer SHALL return Jobs
         belonging to the target Printer object.  The client the following output parameters
       as part may also supply a
         list of the Create-Job Response: Job Identifier:
            (see section 5.1.2.2) attribute names or attribute group names.  These Job Status:
            (see section 5.1.2.2)

         Unsupported Attributes:
            (see section 5.1.2.2)

         Unsupported Attribute Values:
            (see section 5.1.2.2)

                       June 23, 1997, Expires December 23, 1997
         Status
            (see section 5.1.2.2)

       (see section 5.1.2.2)

       5.1.6 Send-Document Operation

       Once a
         attributes will be returned for each Job object has been created using a Create-Job operation
       (returning a "job-uri"), a client directs a Send-Document that is returned.

         This operation to
       the newly create Job object (identified by the returned "job-uri").  The is like Get-Attributes, except that Get-Jobs operation adds a new Document to the Job
         returns attributes from more than one object. An entire document MUST
       be sent in a single Send-Document operation.SEND-DOCUMENT requests are
       directed towards the job object referenced by the "job_URI" string
       returned in a successful CREATE-JOB-RESP message.

       5.1.6.1 Send-Document

         3.1.10.1 Get-Jobs Request

         The client submits the Get-Jobs request to a Job Printer URI.

         The following abstract data types input parameters are part of the Send-Document Get-Jobs Request:

         Document Attributes:
            A set of Document Description attributes (section 6.4).
         Last Document Flag

                                Expires January 14, 1998
           Limit ("limit"):
              This is a boolean flag an integer value that indicates a limit to the number of
              Jobs returned.  The limit is set a "stateless limit" in that if this the
              limit is n then only the last Document first n jobs are returned in the Get-
              Jobs Response; there is no mechanism to allow for the Job.

         Document Content: "next" n
              jobs.  The limit applies across all Job States requested.  For
              example, if the limit if 50, and there are 75 jobs in the
              'completed' state and 25 in the 'pending state' and the client supplies
              requests first 'completed jobs' and then 'pending' jobs, only the document data.

       5.1.6.2 Send-Document Response
              oldest 50 'completed' jobs are returned.  The following output parameters other 25
              'completed' jobs are part not returned and neither are any of the Send-Document Response:
              'pending' jobs returned.

           Requested Job Status:
            (see section 5.1.2.2)

         Unsupported Attributes:
            (see section 5.1.2.2)

         Unsupported Attribute Values:
            (see section 5.1.2.2)

         Status:
            (see section 5.1.2.2)

                       June 23, 1997, Expires December 23, 1997
       5.1.7 Send-URI Operation Attributes ("requested-attributes"):
              An optional set of Job attribute names or attribute groups names
              in whose values the requester is interested.  This operation set of
              attributes is identical to the Send-Document operation (see section
       5.1.6) except returned for each Job that a client supplies a reference (a URI) to the document
       data to be printed rather than the document data itself.  It is up to
       the IPP server to interpret returned..  The
              attribute group names are the URI and subsequently "pull" same as for the document
       from Get-Attributes
              operation for the source referenced by Job object.  If the URI string.

       5.1.7.1 Send-URI Request

       The client submits omits this input
              parameter, the request to a Job URI.

       The following abstract data types are part of the Send-URI Request:

         Document Attributes:
            (see section 5.1.6.1)

         Last Document Flag
            (see section 5.1.6.1)

         Document Reference:
            The client supplies Printer SHALL respond as if this input parameter
              had been supplied with a URI reference to the document data.

       5.1.7.2 Send-URI value of " 'job-uri'.

         3.1.10.2 Get-Jobs Response

         The Printer SHALL return the following output parameters are as part of
         the Send-URI Get-Jobs Response:

         Job Status:
            (see section 5.1.6.2)

         Unsupported

           Req     uested Attributes:
            (see section 5.1.6.2)

         Unsupported Attribute Values:
            (see section 5.1.6.2)

         Status:
            (see section 5.1.6.2)

       5.1.8 Cancel
              The result includes zero or more Job Operation

       This operation allows 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 that move from 'pending-held' to cancel one specific Print Job any time
       after 'pending' as
              seeming to jump ahead in the print job has been established queue).

         3.2 Operation Status Codes and Messages

         An operation status code provides information on the Printer.  Some pages may
       be printed before processing of a job is terminated if printing has already started
       when
         request.  A message provides a short textual description of the Cancel Job operation is received.  Only status

                                Expires January 14, 1998
         of the end user who operation.  The status code is
       also the job originator ("job-originating-user" Job attribute) can
       cancel intended for use by automata and
         a status message is intended for the job using human user.  An IPP 1.0.

                       June 23, 1997, Expires December 23, 1997
       5.1.8.1 Cancel-Job Request

       The client submits the request to application
         (i.e. a Job URI.

       The following abstract data types are part of the Cancel Job Request:

         Message:
            Optional message to the operator

       5.1.8.2 Cancel-Job Response

       The following information browser, GUI, print driver or gateway) is part of the Cancel Job Response:

         Status:
            Status information including error status

       ISSUE:  Randy suggests that the following might be optionally returned
       in a response:  job-state  job-state-reasons  job-state-message  job-k-
       octets-completed  job-impressions-completed  job-media-sheets-completed
       time-since-submission  time-since-processing  job-originating-user  job-
       originating-host

       5.1.9 Get-Attributes Operation

       The Get-Attributes operation allows a client not required to obtain information from
       a Printer
         examine or Job object. The client supplies as an operation parameter
       the set of attribute names and/or attribute group names that display the
       requester is interested in.  The Printer SHALL return a message.  Status codes and suggested
         corresponding
       attribute list status messages are described in section 11..

         4. Object Attributes

         This section describes the response attributes with the appropriate attribute their corresponding
         syntaxes and values
       filled in for each attribute (explicitly named or implicitly included in
       an attribute group) that the client supplied in the request.

       ISSUE: Should this be broken up into two sections - one for Printer one
       for Job?

       5.1.9.1 Get-Attributes Request

       The client SHALL submit the Get-Attributes request to a Job URI or
       Printer URI.

       The following input parameters SHALL be are part of the Get-Attributes
       Request:

         Document Format:

                       June 23, 1997, Expires December 23, 1997 IPP model. The client SHALL supply this input parameter only when requesting sections below
         show the objects and their associated attributes of which are included
         within the Printer object.  The Printer SHALL reject this
            request, if scope of this input parameter is supplied for a Job object.

            This input parameter conditions the Printer protocol.  Many of these attributes and values
            that might depend on the 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 in this document format. using a
         "keyword" (see section 10.2.1).  The Printer SHALL return
            only (1) those attributes that are supported and (2) keyword is included in the attribute
            values
         section header describing that attribute. Not only are supported for the specified document format.  By
            specifying the document format, the client can eliminate the attributes and values that
         uniquely identified with keywords, some attributes are not supported.

            If defined to have
         a syntax which is a set of keywords.

         4.1 Attribute Syntaxes

         The following table shows the basic syntax types that a client omits this input parameter, the effect and
         server SHALL be the
            same as if the value able to handle.

           text:  a sequence of the Printer's default value document format
            attribute were supplied.  It characters, length: 0 to 4095, UTF8
              characters.  This syntax type is recommended that the client always
            supply a value for document-format, since the Printer's default
            value used for document-format may be 'auto-sense', in which case the
            returned attributes and values are free form human
              readable text intended for the union of the document
            formats that the Printer supports in its 'auto-sense' support."

         Requested Attributes:
            An optional set human consumption.

           name:  a sequence of attribute names (without values) or attribute
            group names in whose values the requester characters, length: 1 to 255, UTF8 characters.
              This syntax type is interested.  If the
            client omits this input parameter, the effect SHALL be the same used for referencing some object or entity
              via a user-friendly string, such as
            if the "all" attribute group were supplied.

       Attributes may be requested by name a Printer name, a document
              name, a user name, or by group a host name.  For Jobs, the
       attribute groups include:

         - 'job-template': all

           fileName:  a sequence of the Job Template attributes that apply characters, length: 1 to 1024, UTF8
              characters.  This syntax type is used for referencing some file.
              The limit is the same as in POSIX and Microsoft NT.

                                Expires January 14, 1998
           keyword:  a
            Job object (the first column sequence of characters, length: 1 to 255, containing
              only the table in Section 6.2). characters ASCII lowercase letters ("a" - 'job-description': the Job Description attributes "z"), ASCII
              digits ("0" - "9"), hyphen ("-"), and underscore ("_").  The
              first character MUST be an ASCII lowercase letter.  This syntax
              type is used for enumerating semantic identifiers of entities in Section 6.3.

       For Printers,
              the abstract protocol (specified in this document).  These
              entities can be attribute groups include:

         - 'job-template': all names or values of attributes.  When a
              keyword is used to represent an attribute (its name), it MUST be
              unique within the Job Template attributes that apply full scope of IPP objects and attributes.  When
              a keyword is used to represent a
            Printer object (the last two columns value of an attribute, it MUST
              be unique just within the table in Section 6.2).
         - 'printer-description': the attributes specified in Section 6.5.

       There are also special groups:

         - 'none': no attributes scope of that attribute.  That is, the specified object.  Note: none is
            primarily useful in Get-Jobs, but
              same keyword can not be used as a "ping" with for two different values within the
            Get-Attributes operation.
         - 'all': all attributes of
              same attribute to mean two different semantic ideas.  However,
              the specified object

                       June 23, 1997, Expires December 23, 1997
       5.1.9.2 Get-Attributes Response

       The Printer SHALL return same keyword can be used across two or more attributes,
              representing different semantic ideas for each attribute.

           enum:  an enumerated integer value that is in the following response parameters as part of range from -2**31
              to 2**31 - 1.   Each value has an associated keyword name.  Each
              attribute (whose syntax is enum) enumerates the Get-Attributes Response:

         Result Attributes: values that are
              defined for the attribute.  The requested enum type is used for attributes of the object with their current
            valuesSHALL

         Unknown Attributes:
              for which there are enum values assigned by other standards, such
              as SNMP MIBs.  A list number of attribute names included enum values in the Get-Attributes request
            which this
              specification are unknown by also used for corresponding attributes in the Printer.

         Status:
            Status information including error status

       A
              IETF Printer MAY be configured, for security reasons, MIB [1] and the Job Monitoring MIB [27].  Enums are
              not to return all used for attributes that a client requests. It to which the system administrator may even return none of
              assign values.  Values in the
       requested attributes. In range 2**30 to 2**31 - 1 are
              reserved for private or experimental use.  Implementers are
              warned that use of such cases, the status returned is values may conflict with other
              implementations.  Implementers are encouraged to request
              registration of enum values following the same procedures in Section
              6.

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

           uriScheme:  a sequence of characters representing the Printer had returned all requested attributes. The client cannot
       tell by such a response whether the requested attribute was present or
       absent on the Printer.

       In response to URI Scheme.
              These include 'http' for HTTP schemed URIs (e.g., http://...),
              and 'ftp' for FTP schemed URIs (e.g., ftp://...).

           locale:  a "Get-Attributes" (or standard identifier for human language and optionally a "Get-Jobs") operation
              country.  The values for this syntax type are taken from RFC 1766
              [26].  RFC 1766 does not have provision for expressing the
       following requirements apply to coded
              character set component of a locale.  The coded character set
              used in the Printer:

         1. If IPP protocol SHALL be UTF-8 [28].

              ISSUE: The term 'locale' usually includes country, language, and
              coded character set.  But our data type and RFC 1766 do not

                                Expires January 14, 1998
              include coded character set.  Should we change the client supplies an attribute name in from
              'locale' to 'human-language' and the Requested
            Attribute input parameter corresponding attributes
              from "user-locale" to "user-language", and that attribute "printer-locale" to
              "printer-language" (though printer language is supported by the
            Printer, what IANA
              registers for our document formats)?

           octetString:  a sequence of octets.  This syntax type is used for
              opaque data, such as the printer SHALL respond with all current document-content.

           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 that
            attribute.

         2. If the client supplies an attribute name with this
              syntax type.

           integer:  an integer value that is in the Requested
            Attributes input parameter and that range from -2**31 to
              2**31 - 1.  Each attribute is not supported by specifies the Printer, range constraint
              explicitly if the Printer SHALL respond with range is different from the attribute name in
            the "unsupported attributes" response parameter.

         3. If the client supplies an attribute group that is supported by the
            Printer, the Printer SHALL respond with all current full range of
              possible integer values (e.g., 0 - 100 for each
            supported attribute in the group. It SHALL not respond for
            unsupported attributes in the group.

         4. If the client supplies an attribute group keyword that is not
            unsupported, the Printer assumes that it is an unknown attribute
            and responds  group name in the "unknown attribute list" response
            parameter.

                       June 23, 1997, Expires December 23, 1997
       5.1.10 Get-Jobs Operation

       The Get-Jobs operation allows a client to retrieve Printer attributes
       and "job-priority"
              attribute).

           dateTime:  a list standard, fixed length representation of print jobs belonging to date and time
              (to the target Printer object. A list nearest second) as defined in RFC 1123 [27].  For
              example, Sun, 06 Nov 1994 08:49:37 GMT.  This is a fixed-length
              subset of Job attribute names or attribute group names that the client is
       interested in seeing may defined by RFC 1123  (an update to RFC 822).  All
              values MUST be included represented in the request. Greenwich Mean Time (GMT). This operation is like Get-Attributes, except that Get-Jobs operation
       returns attributes from more than one object.

       5.1.10.1 Get-Jobs Request

       The client SHALL submit
              indicated by the Get-Jobs request to a Printer URI.

       The following input parameters are part inclusion of "GMT" as the Get-Jobs Request:

         Limit
            This is an integer value which indicates three-letter
              abbreviation for time.

           seconds:  a limit to the number non-negative integer with implicit units of
            Jobs returned.  The limit seconds.
              This is used for relative time.

           milliseconds:  a "stateless limit" in that if the
            limit non-negative integer with implicit units of
              milliseconds.  This is n then only the first n jobs are returned in the Get-Jobs
            Response; there used for relative time.

           1setOf  X:  1 or more values of type X.  This syntax type is no mechanism to allow used
              for the "next" n jobs. multi-valued attributes, whose value is a set of values.
              Note:  The limit applies across all Job States requested.  For example, if syntax type is called "1setOf" to indicate that set of
              values SHALL NOT be empty (a set of size 0).

           rangeOf  X:  a range of value of type X.  This syntax type is used
              for ordered values (numeric, lexical, etc.) such as integers.

         4.1.1 Attribute Extensibility

           This document uses prefixes to the limit if 50, "keyword" and there are 75 jobs "enum" basic
           syntax type in order to communicate extra information to the 'completed' state and
            25 reader
           through its name. This extra information need not be represented in the 'pending state' and the

                                Expires January 14, 1998
           an implementation because it is unimportant to a client requests first 'completed
            jobs' and then 'pending' jobs, only the oldest 50 'completed' jobs
            are returned. or Printer.
           The other 25 'completed' jobs are not returned table below describes the prefixes and
            neither their meaning.

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

           "type2":  Implementers can, at any of the 'pending' jobs returned.

         Requested Job Attributes:
            A optional set of attribute names (without values) time, add new keyword or attribute
            groups names in whose enum
              values by proposing them to the requester is interested from each
            of the jobs on the specified Printer.  The attribute group names
            are the same as IPP working group for
              registration (or an IANA-appointed registry advisor after the Get-Attributes operation IPP
              working group is no longer certified) where they are reviewed for
              approval.  IANA keeps the Job
            object.  If the client omits this input parameter, the effect SHALL
            be the same as if the "job-uri" attribute were supplied.

       5.1.10.2 Get-Jobs Response

       The Printer SHALL return the following output parameters as part of the
       Get-Jobs Response:

         Result Attributes:
            The result includes zero or more objects each with zero 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 more
            attributes.  Each Job is returned in chronological order.  This
            order IANA-appointed registry advisor review is explicitly defined to be: oldest to newest with respect to
            completion
              required.

           "type4":  Anyone (system administrators, system integrators, site
              managers, etc.) can, at any time, either actual add new installation-defined
              values (keywords or expected. Jobs that are in the
            'pending-held' state SHALL appear in their position as if they were
            'pending'  (otherwise, new enum values) to a user might local system. Care
              SHOULD be deceived taken by jobs that move

                       June 23, 1997, Expires December 23, 1997
            from 'pending-held' to 'pending' as seeming to jump ahead in the
            queue).

            If the client did not supply any Job attributes, the Printer SHALL
            assume implementers to see that keywords do not
              conflict with other keywords defined by the client is implicitly requesting standard or as
              defined by the "job-uri"
            attribute (that implementing product. There is no other Job attributes are returned, but the
            Job URI registration or
              approval procedure for each Job).

         Status
            Status information including error status

       A Printer MAY be configured, for security reasons, not to return all
       attributes that a client requests. It may even return none type 4 keywords.

         Each of the
       requested attributes. In such cases, four types above assert some sort of registry or review
         process in order to be valid extensions.  "type1" extensions are only
         valid if the status returned specification is the same as updated, "type2" extensions are only
         valid if the Printer had returned all requested attributes. The client cannot
       tell by such a response whether the requested attribute was present IPP working group or
       absent on an IANA approved review process
         approves them, "type3" extensions are only valid if IANA registers the Printer.

       ISSUE: Some people still have complaints about this security statement.

       5.2 Operation Status Codes
         value with no review process required, and Messages

       An operation status code provides information on the processing of "type4" extensions are
         always valid (there is no review or registration process required).
         Any typeN value MAY be registered using a
       request.  A message provides process for some typeM where
         M is less than N, however such registration is NOT REQUIRED.  For
         example, a short textual description type4 value MAY be registered in a type 1 manner (by being
         included in a future version of the Status.
       The status code an IPP specification) however it is intended for use by automata
         NOT REQUIRED.

         This specification defines keyword and a message is
       intended enum values for all of the human user.  An IPP application (i.e.
         above types, including type4 keywords.

         For private (unregistered) keyword extensions, implementers SHOULD use
         keywords with a browser, GUI,
       print driver or gateway) suitable distinguishing prefix, such as "xxx-" where
         xxx is not required to examine or display the
       message.  Status codes (lowercase) company name registered with IANA for use in
         domain names [30].

         Note: RFC 1035 [30] indicates that while upper and suggested corresponding messages lower case letters
         are included allowed in section 12 "APPENDIX A - Status Codes".

       6. Object Attributes

       This section describes domain names, no significance is attached to the attributes case.

                                Expires January 14, 1998
         That is, two names with their corresponding syntaxes
       and values that are part of the IPP model. The sections below show the
       objects and their associated attributes which are included within the
       scope of this protocol.  Many of these attributes same spelling but different case are derived from other
       relevant specifications:

         - ISO/IEC 10175 DPA (Final, June 1996)
         - RFC 1759 Printer MIB (Proposed Standard, May 1995)
         - Internet-Draft: Printer MIB (Draft Standard in progress, December
            1996)
         - Internet-Draft: Job Monitoring MIB (I-D in progress, March 1997)

       Each attribute is uniquely identified to be
         treated as if identical.  Also, he labels in this document using a "keyword"
       (see section 2.2.1).  The keyword in included in domain name must follow
         the section header

                       June 23, 1997, Expires December 23, 1997
       describing that attribute. Not only are attributes uniquely identified rules for ARPANET host names:  They must start with keywords, some attributes take on a syntax which is a set of
       keywords.

       6.1 Attribute Syntaxes

       The following table shows the basic syntax types that letter, end
         with a client letter or digit, and
       server SHALL have as interior characters only letters,
         digits, and hyphen.  Labels must be able to handle.

         text:  a sequence of characters, length: 0 to 4095, any characters.
            This syntax type 63 characters or less.

         ISSUE: Since "." is used for free form human readable text intended allowed in fully qualified domain names we must
         state that "." gets mapped to "_" for human consumption.

         name:  a sequence of characters, length: 1 to 255, any characters.
            This syntax type is used for referencing some object or entity via
            a user-friendly string, such as a Printer name, a document name, a
            user name, keywords or a host name.

         fileName:  a sequence of characters, length: 1 to 1024, any
            characters.  This syntax type is used we must allow for referencing some file.
            The limit
         "." in keywords.  Also, why do we not allow uppercase in keywords?
         Should we make keyword be much more broad (all printable ASCII) now
         that we have binary delimeters?

         For private (unregistered) enum extension, implementers SHOULD values
         in the reserved integer range (see "enum").

         4.2 Job Template Attributes

         Job Template attributes describe job processing behavior.  Take for
         example, a generic Job Template attribute called "xxx":

           1. "xxx" is optionally supplied by the same as client in POSIX and Microsoft NT.

         keyword: a sequence of characters, length: 1 to 255, containing only create request.
              If "xxx" is supplied, the characters ASCII letters, ASCII digits, hyphen ("-"),
            underscore ("_").  The first character MUST be an ASCII letter.
            This syntax type client is used for enumerating semantic identifiers of
            entities in specifying that the abstract protocol (specified in this document).
            These entities can be attribute names or values of attributes.
            When Printer
              SHALL apply a keyword is used specific job processing behavior to represent an attribute (its name), it
            MUST be unique within this job while
              processing the full scope of IPP objects and attributes. Job.  When a keyword "xxx" is used to represent a value of an attribute, it
            MUST be unique just within not supplied by the scope of that attribute.  That is, client,
              the same keyword can not be used for two different values within the same Printer applies thedefault job processing behavior.

           2. "xxx-supported" is a Printer 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.

         uri: that describes which
              behaviors are supported by a sequence of characters as defined in rfc1738 and rfc1808.
            This syntax type Printer.  "xxx-supported" is used for carrying Universal Resource
            Identifiers.

         uriScheme: a sequence
              CONDITIONALLY MANDATORY attribute, that is the "xxx-supported"
              attribute is MANDATORY if the Printer is capable of realizing one
              or more of characters representing the URI Scheme.
            These include 'http' for HTTP schemed URIs (e.g., http://...), behaviors associated with the attribute and
            'ftp' for FTP schemed URIs (e.g., ftp://...).

         locale:  a standard identifier for country its
              values.  A client can query the Printer and language.  The values
            for this syntax type find out what
              behaviors are taken from RFC 1766 [26].

                       June 23, 1997, Expires December 23, 1997
         octetString:  a sequence of octets.  This syntax type is used for
            opaque data, such as supported by inspecting the document-content.

         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 the "xxx-
              supported" attribute.

           3. The Printer also supports a checkbox for an default value attribute with this syntax type.

         integer:  an integer named "xxx".
              This default value that attribute describes what will be done when no
              other job processing information is in supplied by the range from -2**31 to 2**31
            - 1.  Each client
              (either explicitly as an IPP attribute specifies in the range constraint explicitly if create request or
              implicitly as an embedded instruction within the range job data).
              Along with the supported attribute, the default value attribute
              is different from also CONDITIONALLY MANDATORY.  However, if the full range Printer
              supports either the "xxx" default value attribute or the "xxx-
              supported" attribute, the Printer MUST support the other and vice
              versa.

                                Expires January 14, 1998
           4. If a client application wishes to present an end user with a
              list of possible integer supported and default values (e.g., 0 - 100 from which to choose, the
              client program SHOULD query the Printer for the "job-priority" attribute).

         dateTime:  a standard, fixed length representation of date supported and time
            (to
              default value attributes. The values that the nearest second) as defined client then
              supplies in RFC 1123 [27].  For example,
            Sun, 06 Nov 1994 08:49:37 GMT.  This is a fixed-length subset the create request will all fall within the supported
              values of
            that defined the Printer.  When querying the Printer, the client MAY
              enumerate each attribute by RFC 1123  (an update to RFC 822).  All values MUST
            be represented name in Greenwich Mean Time (GMT). This is indicated by the inclusion of "GMT" as Get-Attributes Request,
              or the three-letter abbreviation for time.

         seconds:  a non-negative integer with implicit units client MAY just name the "printer-job-template" group in
              order to get the complete set of seconds.
            This supported and default value
              attributes which are supported.

         The "job-priority" attribute is used for relative time.

         milliseconds:  a non-negative integer with implicit units an example of
            milliseconds.  This a Job Template
         attribute.  It is used for relative time.

         1setOf  X: an integer in the range from 1 or more values of type X.  This syntax type is used to 100.  A client can
         query the Printer for
            multi-valued attributes, whose the "job-priority-supported" attribute and the
         "job-priority" default value is attribute.  The supported attribute
         contains a set range of supported priority values.  Note:  The syntax type is called "1setOf" to indicate default value
         attribute contains the job priority value that set of values
            SHALL NOT will be empty (a set of size 0).

         rangeOf  X: used for a new
         job if the client does not supply one in the create request.  If the
         client does supply the "job-priority" attribute, the Printer validates
         the value to make sure that it falls within the range of supported
         values.  If the client-supplied value of type X.  This syntax type is used
            for ordered values (numeric, lexical, etc.) such as integers.

       6.1.1 Attribute Extensibility

         This document uses prefixes to supported, the "keyword" basic syntax type in
         order to communicate extra information to Job object is
         created and the reader through its
         name. This extra information need "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 be represented supply a "job-priority" value in an
         implementation because it the
         create request, the Job object is unimportant to a created, but no "job-priority"
         attribute is associated with the Job.  The client or Printer. queries the
         Printer's default value "job-priority" value to find out at what
         priority the job will be processed.

         The table below describes summarizes the prefixes names, relationships, and their meaning.

         "type1": conformance
         requirements for all Job Template attributes.  The editor MUST revise the IPP standard following general
         rules apply to add implementation requirements:

           1. In a new name.
            No private names create request, all Job Template attributes are allowed.

         "type2":  Implementers can, at any time, add new values by proposing
            them to the PWG for registration (or an IANA-appointed registry

                       June 23, 1997, Expires December 23, 1997
            advisor after the PWG is no longer certified) where they OPTIONAL.

           2. In a Printer Object, all supported attributes ("xxx-supported")
              are
            reviewed for approval.  IANA keeps CONDITIONALLY MANDATORY.

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

           Note:  If the registry.  Implementers can
            support private (unregistered) with a suitable distinguishing
            prefix, such as "-xxx-" where xxx is Printer implements either the company name registered
            with IANA for use in domain names.

         "type3":  Implementers can, at any time, add new default value attribute
              or the supported values by submitting
            a registration request directly attribute, the Printer MUST also
              implement the other and vice versa.

         The table only shows exceptions to IANA, no PWG or IANA-appointed
            registry advisor review is required.  Implementers can support
            private (unregistered) names with a suitable distinguishing prefix,
            such as "-xxx-" where xxx is the company above rules.   The first column
         of the table (Job) shows the name registered with IANA and syntax for use each Job Template

                                Expires January 14, 1998
         attribute in domain names.

         "type4":  Anyone (system administrators, system integrators, site
            managers, etc.) can, at any time, add new installation-defined
            names to a local system. Care SHOULD be taken by the implementers
            to see that keywords do not conflict with other keywords defined by Job object (in the standard or as defined by create request, the implementing product. There same name and
         syntax is no
            registration or approval procedure for type 4 keywords.

       Each used). All of the four types above assert some sort of registry or review
       process attributes in order to be valid.  "type1" values are only valid if the
       specification is updated, "type2" values are only valid if first column make up the PWG or an
       IANA approved review process approves them, "type3" values are only
       valid if IANA registers
         "job-template" group.  The last two columns show the value with no review process required, name and
       "type4" values are always valid (there is no review or registration
       process required).  Any typeN value MAY be registered using a process
       for some typeM where M is less than N, however such registration is NOT
       REQUIRED.  For example, a type4 value MAY be registered in a type 1
       manner (by being included in a future version of an IPP specification)
       however it is NOT REQUIRED.

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

       6.2 Job Template Attributes

       Job Template attributes describe job processing behavior.  Take syntax
         for
       example, a generic each Job Template attribute called "xxx":

         1. "xxx" is optionally supplied by the client in a create request.
            If "xxx" is supplied, the client is specifying that the Printer
            will apply a specific job processing behavior to this job while
            processing the Job.  When "xxx" is not supplied, the client expects the Printer will apply the object (the default job processing behavior.

                       June 23, 1997, Expires December 23, 1997
         2. "xxx-supported" is a Printer
         value attribute that describes which
            behaviors are and the supported by a Printer.  "xxx-supported" is a
            CONDITIONALLY MANDATORY  attribute which attribute).  A "No" in the table
         means that the Printer
            only supports SHALL NOT support the attribute if it is capable of realizing one or
            more of the behaviors associated with the attribute and its values.
            A client can query the Printer and find out what behaviors are
            supported by inspecting at the values in the "xxx-supported" attribute.

         3. The Printer also supports a default value attribute named "xxx".
            This default value attribute describes what will be done when no
            other job processing information is supplied by the client (either
            explicitly as an IPP attribute in the create request or implicitly
            as an embedded instruction within the job data).  Along with the
            supported attribute, the default value attribute is also
            CONDITIONALLY MANDATORY.  However, if the Printer supports the
            "xxx-supported" attribute, the Printer MUST support the
            corresponding default value attribute and vice versa.

         4. If a client application wishes to present an end user with a list
            of supported and default values from which to choose, the client
            program SHOULD query the supported and default value attributes.
            The values  A "MAN" indicates
         that the client then supplies in the create request will
            all fall within the 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 "printer-
            job-template" group in order to get the complete set of supported
            and default value attributes which are supported.

       The "job-priority" attribute is an example of a MANDATORY.

                                Expires January 14, 1998
           +-------------------+----------------------+----------------------+
           |    Job Template attribute.
       It is an integer in the range from 1 to 100.  A client can query the
       Printer for the "job-priority-supported" attribute and the "job-
       priority" default value attribute.  The supported attribute contains a
       set of            |Printer: Default Value|  Printer: Supported  |
           +===================+======================+======================+
           | job-name          | No                   | No                   |
           | (name, MAN)       |                      |                      |
           +-------------------+----------------------+----------------------+
           | 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 priority values (a range).  The default value attribute
       contains the job priority value that will be used for a new job if the
       client does not supply one in the create request.  If the client does
       supply the "job-priority" attribute, the Printer validates the value to
       make sure that it falls within the range of            |
           | type2 keyword)    |                      |(1setOf type2 keyword)|
           +-------------------+----------------------+----------------------+
           |notify-addresses   | No                   |notify-addresses      |
           |(1setOf uri)       |                      |-supported            |
           |                   |                      |(1setOf uri scheme)   |
           +-------------------+----------------------+----------------------+
           | 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 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.

                       June 23, 1997, Expires December 23, 1997
       The following table summarize the names, relationships, and conformance
       requirements for all Job Template attributes.  The following general
       rules apply to implementation requirements:

         1. In a create request, all Job Template attributes are OPTIONAL.

         2. In a Printer Object, all supported attributes are CONDITIONALLY
            MANDATORY.

         3. All Printer default value attributes are CONDITIONALLY MANDATORY.
            However, if the Printer implements that "supported" attribute then
            the Printer MUST also implement the default value attribute as
            well. and vice versa.

       The table only shows exceptions to the above rules.   The first column
       of the table (Job) shows the name and syntax for each Job Template
       attribute in the Job object (in the create request, the same name and
       syntax is used).  Section All of the attributes in the first column make
       up the groupThe last two columns show the name and syntax for each Job
       Template attribute in the Printer object (the default value attribute
       and the supported attribute).  A "No" in the table means the Printer
       SHALL NOT support the attribute.  A "MAN" indicates that the attribute
       is MANDATORY.

                       June 23, 1997, Expires December 23, 1997
       +----------------------+----------------------+----------------------+            |    Job               |Printer: Default Value|  Printer: Supported
           |
       +----------------------+----------------------+----------------------+                   | job-name                      |(1setOf type4 keyword)|
           +-------------------+----------------------+----------------------+
           |multiple-document- |multiple-document-    |multiple-document-    | No
           | No handling          | handling             |handling-supported    | (name,
           | (type2 keyword)   | (type2 keyword)      |(1setOf type2 keyword)|
           +-------------------+----------------------+----------------------+
           | best-effort       | best-effort          | best-effort-supported|
           | (boolean)         | (boolean, MAN)       |(boolean, MAN)        |
           |                   |
       +----------------------+----------------------+----------------------+                      | job-sheets                      | job-sheets           |job-sheets-supported
           +-------------------+----------------------+----------------------+
           | media             | media                | media-supported      |
           | (type4 keyword)   | (type4 keyword)      |(1setOf type4 keyword)|
           |                   |                      |                      |
       +----------------------+----------------------+----------------------+
           +-------------------+----------------------+----------------------+
           | notify-events number-up         | notify-events number-up            | number-up-supported  | notify-events-
           | (type3 keyword)   | (type3 keyword)      |(1setOf type2 keyword)|(1setOf type2 type3 keyword)| supported
           |                   |                      |                      |
           +-------------------+----------------------+----------------------+
           | sides             | sides                | sides-supported      |
           | (type2 keyword)   | (type2 keyword)      |(1setOf type2 keyword)|
       +----------------------+----------------------+----------------------+
       |notify-addresses      |No                    |notify-addresses
           |
       |(1setOf uri)                   |                      |-supported                      |                      |
           +-------------------+----------------------+----------------------+
           |                      |(1setOf uri scheme) printer-resolution| printer-resolution   |
       +----------------------+----------------------+----------------------+ printer-resolution-  | 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-documents-are|multiple-documents-are|multiple-documents-are|
       | (type2 keyword)      | (type2 keyword)      |-supported            |
       |                      |                      |(1setOf type2 keyword)|
       +----------------------+----------------------+----------------------+
       | best-effort          | best-effort          | best-effort-supported|

                                Expires January 14, 1998
           | (type2 keyword) enum)      | (type2 keyword, MAN) |(1setOf type2 keyword,| enum)         |                      |                      |MAN)                  |
       +----------------------+----------------------+----------------------+
       | 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 supported            |
           | (type2 keyword)                   | (type2 keyword)                      |(1setOf type2 keyword)|
       |                      | enum)   |
           +-------------------+----------------------+----------------------+
           |
       +----------------------+----------------------+----------------------+
       | resolution print-quality     | resolution print-quality        | resolution-supported print-quality-       |

                       June 23, 1997, Expires December 23, 1997
           | (type2 keyword) enum)      | (type2 keyword)      |(1setOf type2 keyword)|
       |                      | enum)         |                      |
       +----------------------+----------------------+----------------------+
       | quality              | quality              | quality-supported supported            |
           | (type2 keyword)                   | (type2 keyword)                      |(1setOf type2 keyword)| enum)   |                      |                      |                      |
       +----------------------+----------------------+----------------------+
           +-------------------+----------------------+----------------------+
           | finishings        | finishings           | finishings-supported |
           |(1setOf type2 keyword)|(1setOf enum)|(1setOf type2 keyword)|(1setOf enum)   |(1setOf type2 keyword)| enum)   |
           |                   |                      |                      |
       +----------------------+----------------------+----------------------+
           +-------------------+----------------------+----------------------+
           | copies            | copies               | copies-supported     |
           | (integer: 0 1 - MAX)   | MAX)| (integer: 0 1 - MAX)   | (rangeOf integer     |
           |                   |                      |  0-     1- MAX)          |
       +----------------------+----------------------+----------------------+
           +-------------------+----------------------+----------------------+
           | document-format   | document-format      | document-format-     |
           | (type2 keyword) enum)      | (type2 keyword) enum)         | supported            |
           |                   |                      |(1setOf type3 keyword)|
       +----------------------+----------------------+----------------------+ type2 enum)   |
           +-------------------+----------------------+----------------------+
           | compression       | No                   | compression-supported|
           | (type3 keyword)   |                      |(1setOf type3 keyword)|
           |                   |                      |                      |
       +----------------------+----------------------+----------------------+
           +-------------------+----------------------+----------------------+
           | job-k-octets      | No                   |job-k-octets-supported|
           | (integer)         |                      | (rangeOf integer)    |
           |                   |                      |                      |
       +----------------------+----------------------+----------------------+
           +-------------------+----------------------+----------------------+
           | job-impressions   | No                   | job-impressions-     |
           | (integer)         |                      | supported            |
           |                   |                      | (rangeOf integer)    |
       +----------------------+----------------------+----------------------+
           +-------------------+----------------------+----------------------+
           | job-media-sheets  | No                   | job-media-sheets-    |
           | (integer)         |                      | supported            |
           |                   |                      | (rangeOf integer)    |
       +----------------------+----------------------+----------------------+

       6.2.1
           +-------------------+----------------------+----------------------+

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

         If "job-name" is not supplied in the create request, the Printer, on
         creation of the Job, SHALL generate a name.  The name MAY be generated
         using the name of the first Document in the Job ((the (the "document-name"
       attribute)..
         attribute).  If "job-name" is supplied in the create request, the
         Printer SHALL use its value as the name of the created Job.

                       June 23, 1997,

                                Expires December 23, 1997
       6.2.2 January 14, 1998
         4.2.2 job-sheets (type4 keyword)

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

         Standard values are:

           'none': no job sheet is printed
           'standard': a site specific standard job sheet (start only) or
              sheets (start and end) 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'.  If  In this case, if a client
         requests 'none' in 'none', the create request, the request is rejected.

       6.2.3

         4.2.3 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 event occurs. the events occur.
           'job-completion':  the Printer SHALL notify when the job containing
              this attribute value completes (i.e., enters the 'completed', 'canceled',
              or 'aborted' state) with or without errors.
         'job-canceled':  the Printer SHALL notify when the job containing
            this attribute is canceled by the end-user or by the operator, or
            aborts before completion.
           'job-problems':  the Printer SHALL notify when this job has a
              problem while this job is printing. processing (i.e., when the Job moves
              from the 'processing' to the 'processing-stopped' state).
              Problems include any of the "job-state-
            reasons" "job-state-reasons" or "printer-state-reason" "printer-
              state-reason" values.
           'printer-problems': the Printer SHALL notify when any job, including this job, job is
              affected by a Printer problem (the problem.  This happens when the printer has moved
            to
              enters the stopped 'stopped' state and there is a reason in the printer-state-
            reasons attribute) while this job is waiting to print in the 'pending',
              'pending-held', 'processing', or printing.
            Problems include any of 'processing-stopped' state.  If
              the "job-state-reasons" or "printer-state-
            reason" values.

       ISSUE:  Should these correspond with Job states job-completed, job-
       completed-aborted, job-completed-canceled?

       6.2.4 Printer enters the 'stopped' state the reason in the
              "printer-state-reasons" attribute.

         4.2.4 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

                       June 23, 1997, Expires December 23, 1997 attribute as the set of addresses and methods for sending

                                Expires January 14, 1998
         messages when an event occurs that the end user (job submitter) has
         registered an interest in.

         Standard uri scheme values are:

           'mailto': email is used
           'http': an HTTP  method is used to add HTML formatted events to the
              end of the specified HTML file.
           'ftp': FTP is used to append a record at the end of a specified
           text file.

       6.2.5

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

         This attribute specifies a priority for scheduling the print-job. A
         higher value specifies a higher priority. The value 1 is defined to
         indicate the lowest possible priority. The value 100 is defined to
         indicate 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.

       6.2.6
         implementation-specific.

         4.2.6 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 attribute, move the job to the 'pending-
         held' state, and SHALL NOT schedule the
       print-job job for printing until the
         specified time-period arrives.  When

                       June 23, 1997, Expires December 23, 1997 the specified time period

                                Expires January 14, 1998
         arrives, the Printer SHALL remove the 'job-
       hold-until-specified' 'job-hold-until-specified' value
         from the job's "job-state-reason attribute" and, if no other job
         reasons remain, SHALL consider the job as a candidate for processing. processing
         by moving the job to the 'pending' state.

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

       6.2.7 multiple-documents-are

         4.2.7 multiple-documenthandling (type2 keyword)

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

       ISSUE: Change name to "finishing-for-multiple-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
              and
            b. 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. 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, ....

       Both of ...., and the 'separate-xxx' values Printer
              shall force each new document copy to start on a new media sheet.

       6.2.8 sheet

         4.2.8 best-effort (type2 keyword)

       A (boolean)

         This attribute determines how to control a conflict between what a
         client supplies requests in a create request and what a Printer supports.  The
         value 'true' means that a best effort attempt to print the Job Template attributes is
         possible (or acceptable).  In order to affect achieve this, the rendering,
       production and finishing of Printer might
         have to substitute some supported value for a requested value which is
         unsupported.  The value 'false' means that total fidelity is required;

                                Expires January 14, 1998
         a best effort attempt to print the documents in Job is not possible (or not
         acceptable).  In other words, the job.  Similar types of
       instructions may also job must be contained printed exactly as
         specified in the document to be printed, that
       is, within the Page Description Language (PDL) create request.  If one or more of the document data.  If
       there client-
         supplied values in the create request is a conflict between not supported by the value of one of these IPP Job Template
       attributes, and a corresponding instruction in Printer,
         the document (either
       implicit or explicit), it Printer rejects the create request.

         There are two cases to consider:

           - The Printer's "best-effort-supported" attribute is desirable set to 'true':
              This indicates that the value Printer is capable of best effort
              printing.  In this case either the "best-effort" Job Template
              attribute

                       June 23, 1997, Expires December 23, 1997
       SHALL take precedence over in the document instruction.  Until companies
       that supply interpreters for PDLs, such as PostScript and PCL allow a
       way create request or the Printer's "best-effort"
              (the default value attribute) can be set to external attributes (such as IPP attributes) either 'true' or
              'false'.  If "best-effort" is set to take precedence
       over internal job production instructions, a 'false' the Printer might not be able
       to support ensures
              full fidelity of the semantics that other IPP attributes override (take on a higher
       precedence) in the embedded PDL instructions.   Therefore, this create request.
              That is, if any other attribute
       gives in the end user some ability create-request is set to influence, or at least understand,
       how a particular
              value that is not supported, the Printer implementation handles these conflicts.

       This attribute takes on rejects the following values:

         - 'shall-honor-ipp-attributes': create
              request.  If a Printer supports this value and
            a client requests this value, "best-effort" attribute is set to 'true', the the
              Printer guarantees makes whatever substitutions are necessary to ensure that all IPP
            attribute values take precedence over embedded instructions in
              the job data (the PDL of the job's documents).
         - 'should-honor-ipp-attributes': If a Printer supports this value,
            and is printed.  For example, if a client requests this value, the Printer SHOULD try to make
            sure that IPP supplies a
              "finishings" Job Template attribute values take precedence over embedded PDL
            instructions, however there is no guarantee

       ISSUE: Should these be 'shall-honor-attribute-precedence' and 'should-
       honor-attribute-prcedence'?

       A Printer SHALL implement set to 'staple' but the "best-effort-supported" attribute.  Notice
       that since 'should-honor-ipp-attributes'
              printer does not offer any type of
       guarantee, a Printer may not do support stapling (not a very "good" job feature or it is
              temporarily out of implementing staples) then if the
       semantics of "should", but it would "best-effort" attribute
              is set to 'true' the job can still be a conforming
       implementation. printed but it is not
              stapled.  If there "best-effort" is ever a conflict between what a set to 'false', the create request
              is rejected since the Printer supports and what an
       IPP client requests, can not guarantee that the job will
              be stapled.

           - The Printer's "best-effort-supported" attribute is set to
              'false':  This indicates that the Printer SHALL reject is not capable of (or
              will not support) best effort printing.  The Job Template
              attributes supplied by the print request.  A client SHOULD query in the printer to find out what is create request must
              match all of the Printer's supported before
       making a values, or else the Printer
              rejects the create request.  This ensures that all requested attribute values are
       supported.

       ISSUE: Should  In this case Printer's "best-effort"
              attribute (the default value attribute) MUST also be called "effort-level" rather than "best-effort"? set to
              'false'.  If the value of this attribute is 'shall-honor-ipp-attributes', client supplies the
       implementation "best-effort" Job Template
              create request, it too MUST guarantee be set to 'false'.  If it is set to
              'true', the Printer rejects the create request.

         Note: that the IPP "best-effort" attribute values take
       precedence over any related job processing instructions in the PDL Job's
       document data.  This can a create request is unlikely
         to be done by modifying the interpreter within used much. Many clients will submit a job with no attributes,
         and the
       output device itself to understand IPP attributes, or by merging theses
       Job Template attributes directly into Printer will use default values.  Other clients will submit a
         job via a GUI that limits the document data, or attribute values to values which are
         supported.  Best-effort is useful in any other
       implementation specific manner.  In any case, the semantics of 'shall-
       honor-ipp-attributes' MUST be preserved.

                       June 23, 1997, Expires December 23, 1997
       Note: Since 'should-honor-ipp-attributes' does not offer any type of
       guarantee, a Printer may not do GUI context only if a very "good" job of implementing user
         expects the
       semantics of 'should', but it would still job to be moved to another printer and prefers a conforming
       implementation.

       6.2.9 sub-
         optimal result to nothing at all.  Best-effort is most useful in the
         case where an end-user uses a command line interface to request
         attributes that might not be supported.

                                Expires January 14, 1998
         4.2.9 media (type4 keyword)

         This job attribute identifies the medium that the Printer SHALL use uses for all
         pages of the document regardless of what media are specified within
       the document. 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 in turn implicitly selects
         an input-tray that contains the medium with the specified size.  If a
         printer allows a client to specify an input-tray as the value of this
         attribute, such an input-tray implicitly selects the medium that is in
         that input-tray at the time the job prints. This case includes manual-
         feed input-trays.  If a printer allows a client to specify an
         electronic form as the value of this attribute, such an electronic
         form implicitly selects a medium-name which in turn implicitly selects
         an input-tray that contains the medium specified by the electronic
         form. The electronic form also implicitly selects an image that the
         Printer SHALL merge with the data from the document as its prints each
         page.

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

       6.2.10 13.
         4.2.10 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).

                       June 23, 1997, Expires December 23, 1997
           'two': The Printer SHALL place two logical page 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 page on a single side
              of an instance of the selected medium (MAY add some sort of
              translation, scaling, or rotation).

                                Expires January 14, 1998
         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.

       6.2.11

         4.2.11 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
              page-image upon front and back sides of consecutive media sheets,
              such that the orientation of each pair of source-pages on the
              medium would be correct for the reader as if for binding on the
              long edge.  This imposition is sometimes called 'duplex'.
           'two-sided-short-edge': imposes each consecutive pair of source page-
            image
              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'.
              'head-to-toe'.

         'two-sided-long-edge', 'two-sided-short-edge', 'tumble'. 'duplex', and
         'head-to-toe' all work the same for portrait or landscape, that is,
         'head-to-toe' is 'tumble' in portrait but 'duplex' in landscape.  'head-
       to-head'
         'head-to-head' also switches between 'duplex' and 'tumble' when using
         portrait and landscape modes.

       6.2.12

         4.2.12 printer-resolution (type2 keyword) enum)

         This job attribute specifies identifies the resolution that the Printer SHOULD use. uses for a
         certain Job.

         The values are type2 keywords enums which represent single integers or pair of
         integers. The latter are to specify the resolution when the x and y
         dimensions differ. When two integers are specified, the first is in
         the x direction, i.e., in the direction of the shortest dimension of
         the medium, so that the value is independent of whether the printer
         feeds long edge or short edge first.

                       June 23, 1997, Expires December 23, 1997

         The standard values are:

           'normal'(3):

                                Expires January 14, 1998
           'res-100'(4):  100 x 100 dpi
           'res-200'(5):  200 x 200 dpi
           'res-240'(6):  240 x 240 dpi
           'res-300'(7):  300 x 300 dpi
           'res-360'(8):  360 x 360 dpi
           'res-400'(9):  400 x 400 dpi
           'res-600'(10):  600 x 600 dpi
           'res-720'(11):  720 x 720 dpi
           'res-800'(12):  800 x 800 dpi
           'res-1200'(13):  1200 x 1200 dpi
           'res-1440'(14):  1440 x 1440 dpi
           'res-1600'(15):  1600 x 1600 dpi
           'res-1800'(16):  1800 x 1800 dpi
           'res-100x200'(100):  100 x 200 dpi
           'res-200x100'(101):  200 x 100 dpi
           'res-300x600'(102):  300 x 600 dpi
           'res-600x300'(103):  600 x 300 dpi
           'res-360x720'(104):  360 x 260 dpi
           'res-720x360'(105):  720 x 360 dpi
           'res-400x800'(106):  400 x 800 dpi
           'res-800x400'(107):  800 x 400 dpi
           'res-600x1200'(108):  600 x 1200 dpi
           'res-1200x600'(109):  1200 x 600 dpi
           'res-720x1440'(110):  720 x 1440 dpi
           'res-1440x720'(111):  1440 x 720 dpi
           'res-1800x600'(112):  1800 x 600 dpi

         ISSUE: TBD   normal: res-100:  res-300x300:  ...

         'normal':
         'res-100':
         'res-200':
         'res-240':
         'res-300':
         'res-600':
         'res-800':
         'res-1200':
         'res-1800':
         'res-100x200':
         'res-300x600':
         'res-600x300':
         'res-400x800':
         'res-800x400':
         'res-600x1200':
         'res-1200x600':
         'res-1800x600':

       6.2.13 Should we add metric enums?  Such as

           'res-8x3.85'(200):  8 lines per 3.85 mm (fax)
           'res-8x7.7'(201): 8 lines per 7.7 mm (fax)
           'res-8x15.4'(202): 8 lines per 15.4 mm (fax)
           'res-16x15.4'(203): 16 lines per 15.4 mm (fax)

         4.2.13 print-quality (type2 keyword) enum)

         This job attribute specifies the print quality that the Printer SHOULD
       use. Printeruses for a
         certain Job.

         The standard values are:

         draft:

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

       6.2.14

                                Expires January 14, 1998
         4.2.14 copies (integer(1:2**31 - 1))

         This job attribute specifies the number of copies of the job to be
         printed.

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

       6.2.15
         4.2.7).

         4.2.15 finishing (1setOf type2 keyword) enum)

         This job attribute identifies the finishing operations that the Printer
       SHOULD apply to
         uses for each copy of each printed document in the job where the

                       June 23, 1997, Expires December 23, 1997 a particular Job. The
         definition of a copy for Jobs with multiple documents is controlled by
         the "multiple-documents-are" Job
       attributes. "multiple-document-handling" attribute.

         Standard values are:

         none:
         staple:
         ...
       6.2.16 document-format (type2

           'none'(3):  Perform no finishing
           'staple'(4):  Bind the document(s) with one or more staples. The
              exact number and placement of the staples is site-defined.
           'staple-top-left'(5):  Place one or more staples on the top left
              corner of the document(s).
           'staple-bottom-left'(6):  Place one or more staples on the bottom
              left corner of the document(s).
           'staple-top-right'(7):  Place one or more staples on the top right
              corner of the document(s).
           'staple-bottom-right'(8):  Place one or more staples on the bottom
              right corner of the document(s).
           'saddle-stitch'(9):  Bind the document(s) with one or more staples
              (wire stitches) along the middle fold.  The exact number and
              placement of the stitches is site-defined.
           'edge-stitch'(10):  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.
           'punch'(11):  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.
           'cover'(12):  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.

                                Expires January 14, 1998
           'bind'(13):  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.16 document-format (type2 keyword)

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

         If the "document-format" Values.

       6.2.17 is unknown for a certain document, the client
         SHALL NOT supply the attribute in the create request or the Send-
         Document Request.

         4.2.17 compression (type3 keyword)

         This attribute identifies compression algorithms used for compressed
         document data.

         Standard values for this attribute are:

           'none': no compression is used.
           'zip':ZIP compression technology
           'tar': UNIX TAR compression technology

       6.2.18

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

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

         Note:  This attribute is and the following two attributes ("job-
         impressions" and "job-media-sheets") are not intended to be a counter as
       in the Job Monitoring MIB;  it is  counters;
         they are intended to be useful routing and scheduling information if
         known.  If The Printer tries to compute the client does value if it is not supply this
       attribute supplied in
         the create request, the Printer request.  The Printer, however, might not be able to
         compute this value at the time the Job is created.

       6.2.19  If not, the
         Printer may support this attribute at any later time as it is able to
         compute value.

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

         This job attribute specifies the total size of the job in impressions.
       This attribute is not intended to be a counter as in the Job Monitoring
       MIB;  it is intended to be useful routing and scheduling information if
       known.  The Printer SHALL try to compute the value if it is not supplied
       in the create request.  The Printer might not be able to compute this
       value (if not supplied by the client in the request) at the time the Job
       is created.  If not, the Printer may support this attribute at any later
       time as it is able to compute the total size of the Job.

                       June 23, 1997,

                                Expires December 23, 1997
       6.2.20 job- media-sheets January 14, 1998
         4.2.20 job-media-sheets (integer(0:2**31 - 1))

         This job attribute specifies the total size of the job in media-sheets.
       This attribute is not intended to be a counter as in the Job Monitoring
       MIB; it is intended to be useful routing and scheduling information if
       known. The Printer SHALL try to compute the value if it is not supplied
       in the creaet request.  The Printer might not be able to compute this
       value (if not supplied by the client in the request) at the time the Job
       is created.  If not, the Printer may support this attribute at any later
       time as it is able to compute the total size of the Job.

       6.3

         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.

                       June 23, 1997,

                                Expires December 23, 1997 January 14, 1998
         +----------------------------+----------------------+----------------+
         |      Attribute             |     Syntax           |   MANDATORY?   |
         +----------------------------+----------------------+----------------+
         | job-uri                    | uri                  |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | job-uri-user               | uri                  |                |
         +----------------------------+----------------------+----------------+
         | job-originating-user       | name                 |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | job-originating-host       | name                 |                |
         +----------------------------+----------------------+----------------+
         | user-locale                | locale               |                |
         +----------------------------+----------------------+----------------+
         | job-state                  | type1 keyword enum           |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | job-state-reasons          | 1setOf type2 keyword |                |
         +----------------------------+----------------------+----------------+
         | job-state-message          | text                 |                |
         +----------------------------+----------------------+----------------+
         | output-device-assigned     | name                 |                |
         +----------------------------+----------------------+----------------+
         | time-since-pending         | milliseconds         |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | time-since-processing      | milliseconds         |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | time-since-completed       | milliseconds         |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | number-of-intervening-jobs | integer              |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | job-message-from-operator  | text                 |                |
         +----------------------------+----------------------+----------------+
         | job-k-octets-completed job-k-octets-processed     | integer              |                |
         +----------------------------+----------------------+----------------+
         | job-impressions-completed  | integer              |                |
         +----------------------------+----------------------+----------------+
         | job-media-sheets-completed | integer              |                |
         +----------------------------+----------------------+----------------+

       6.3.1

         4.3.1 job-uri (uri)

         This attribute contains the URI for the job.  The Printer, on receipt
         of a new job, SHALL generate generates a URI which identifies the job new Job on the that
         Printer. The Printer, SHALL return Printer returns the value of the "job-uri" attribute as
         part of the response to a create request.   The precise format of a
         job URI
       SHALL be is implementation dependent.

                       June 23, 1997,

                                Expires December 23, 1997
       6.3.2 January 14, 1998
         4.3.2 job-uri-user (uri)

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

       6.3.3

         4.3.3 job-originating-user (name)

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

       6.3.4

         4.3.4 job-originating-host (name)

         This attribute identifies the originating host of the job. The Printer
         SHALL set this attribute to the most authentic authenticated host name it can
         obtain from the protocol over which the operation was received from
         the client.

       6.3.5

         4.3.5 user-locale (type3 keyword) (locale)

         This attribute identifies the locale of human language and optional the job, i.e, country
         of the country,
       language, and coded character set. end user.  The Printer sets this attribute to the most authentic reliable
         value it can obtain from the protocol over which the Print operation
         was received from the client.

         The Printer SHALL use uses this attribute to determine the locale it SHOULD use
         for
       notification messages localizing any text strings that it sends.

       6.3.6 job-state (type1 keyword)

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

       6.3.8 job-state-message (text)

       This attributes specifies supplemental information about the Job State
       in human readable text.  It SHALL be set by sends back to the Printer.

       6.3.9 output-device-assigned (name) end user.
         These include status messages, text attributes, and notification
         messages.

         4.3.6 job-state (type1 enum)

         This attribute identifies the Output Device to which current state of the Printer has
       assigned this job.  If an output device implements an embedded  Even though
         the IPP
       Printer, protocol defines eight values for job states, implementations
         only need to support those states which are appropriate for the Printer NEED NOT set this attribute.  If a Print Server

                       June 23, 1997, Expires December 23, 1997
       implements
         particular implementation.  In other words, a Printer, the value MAY be empty until the Printer assigns
       an supports only
         those job states implemented by the output device and available to the job.

       6.3.10 time-since-pending (milliseconds)

       This attribute indicates the amount
         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 time that has passed since reasons but will return to the
       Job was first put into 'pending' state as

                                Expires January 14, 1998
              soon as the pending state..

       6.3.11 time-since-processing (milliseconds)

       This reasons are no longer present.  The job's "job-state-
              reason" attribute indicates SHALL indicate why the amount of time 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 passed since made the
       Job first entered job ready for printing, but the processing state.

       6.3.12 time-since-completed (milliseconds)

       This attribute indicates
                output device is not yet printing it, either because the amount of time that has passed since job
                hasn't reached the
       Job was completed.

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

       This attribute indicates output device or because the number of jobs that are "ahead" of this job is queued
                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 output device or some relative position indicator if there
       are other jobs interspersed spooler, awaiting the
                output device to print it.
              When the job is in the waiting list which are not returned 'processing' state, the entire job state
              includes the detailed status represented in the response or cannot be because of site security policy
       restrictions.

       6.3.14 job-message-from-operator (text)

       This 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 provides a message from an operator, system administrator
       or "intelligent" process to indicate to the end user progress of the reasons for
       modification or other management action taken on a job.

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

       This attribute specifies job,
              such as adding the number of octets completed in K octets,
       i.e., in units of 1024 octets.  The 'job-printing' value SHALL be rounded up, so that a
       job between 1 and 1024 octets SHALL be indicated as being 1K, 1025 to
       2048 SHALL be 2, etc. This attribute indicate when the
              output device is intended 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 be a counter as in the Job Monitoring MIB.

                       June 23, 1997, Expires December 23, 1997
       6.3.16 job-impressions-completed  (integer(0:2**31 - 1))

       This job attribute specifies 'processing' state
              as soon as the number of impressions completed. This reasons are no longer present.
              The job's "job-state-reason" attribute is intended to be a counter as in MAY indicate why the Job Monitoring MIB.

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

       This job attribute specifies
              has stopped processing.  For example, if the media-sheets completed. This attribute output device is intended to
              stopped, the 'printer-stopped' value MAY be a counter as included in the Job Monitoring MIB.

       ISSUE: Should job's
              "job-state-reasons" attribute.  For example, if the above three attributes output device
              is stopped, the 'printer-stopped' value MAY be regularly named as job-size-
       in-xxx-yyy where xxx included in the
              job's "job-state-reasons" attribute.
              NOTE - When an output device is k-octets, impressions and media sheets 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 where
       yyy is a "printer-state-message" attributes.
           'canceled'(7):  The job state pending, processing and completed. So job-impressions
       becomes job-size-in-impressions-pending has been canceled by a Cancel-Job operation
              and job-impressions-completed is
       job-size-in-impressions-processing while printing and job-size-in-
       impressions-completed  when either (1) in the job completed. Thus job-impressions-
       completed doesn't serve two functions.

       6.4 Document Attributes

       This group process of attributes describes terminating or (2) has
              completed terminating.  The job's "job-state-reasons" attribute
              SHOULD contain either the document data for 'canceled-by-user' or 'canceled-by-
              operator' value.
           'aborted'(8):  The job has been aborted by the job.  For
       single-Document Jobs, they are supplied system, usually
              while the job was in the Print-Job 'processing' or Print-URI
       requests.  For multi-Document Jobs, they are supplied 'processing-stopped'
              state.
           '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 each Send-
       Document the appropriate output

                                Expires January 14, 1998
              bin(s).  The job's "job-state-reasons" attribute SHOULD contain
              one of: 'completed-successfully', 'completed-with-warnings', or Send-URI request.

       +----------------------------+----------------------+----------------+
       |      Attribute             |     Syntax           |   MANDATORY?   |
       +----------------------------+----------------------+----------------+
       | document-name              | name                 |  MANDATORY     |
       +----------------------------+----------------------+----------------+
       | document-format            | type 2 keyword       |                |
       +----------------------------+----------------------+----------------+
              '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
             | document-uri         ^                   ^                \
         --->+         | uri                   |                 +----> aborted
             |
       +----------------------------+----------------------+----------------+

       6.4.1 document-name (name)         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.7 job-state-reasons (1setOf  type2 keyword)

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

         Implementation of these values is OPTIONAL, i.e., a Printer NEED NOT
         implement them, even if (1) the client to
       initially identify output device supports the document. When a client prints
         functionality represented by reference, i.e.
       includes the document-URI attribute reason and no document content, this
       attribute SHALL (2) is available to the
         Printer object implementation.  These values MAY be absent.

       6.4.2 document-format (type2 keyword)

       See section 6.2.16 used with any job
         state or states for which describes "document-format" as a Job Template
       attribute.

                       June 23, 1997, Expires December 23, 1997
       6.4.3 document-uri (uri)

       This attribute contains the URI of reason makes sense.  Furthermore, when
         implemented, the document Printer SHALL return these values when the document
       content is not included in reason
         applies and SHALL NOT return them when the Send Document operation.  Document-number
       is reason no longer applies
         whether the only other attribute allowed when a document-URI value of the job's "job-state" attribute is
       present in a Send Document operation.

       ISSUE: Now that we changed or not.
         When the job does not have Print-URI and Send-URI, do we still need this?
       Do we allow any reasons for being in its current state,
         the query Printer shall set the value of this the job's "job-state-reasons"
         attribute via Get-Attributes?

       6.5 Printer Description Attributes

       These attributes form to 'none'.

         NOTE - While values cannot be added to the 'job-state' attribute group called "printer-description".
       A Printer object may
         without impacting deployed clients that take actions upon receiving
         "job-state"values, it is the intent that additional "job-state-
         reasons" values can be realized defined and registered without impacting such

                                Expires January 14, 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 either a print server or output
       device.  Note: How these attributes the order in which the reason is most likely to occur:

           'none':  There are set no reasons for the job's current state.
           'job-incoming':  The CreateJob operation has been accepted by an Administrator the
              Printer, but the Printer is
       outside expecting additional SendDocument
              operations and/or is accessing/accepting document data.
           'job-outgoing':  The Printer is transmitting the scope job to the output
              device.
           'job-hold-until-specified':  The value of this specification. the job's "job-hold-
              until" attribute specifies a time period that is still in the
              future.  The following table summarizes
       these attributes, their syntax, job SHALL NOT be a candidate for processing until
              this reason is removed and whether or not they are MANDATORY.
       If they there are no other reasons to hold the
              job.
           'resources-are-not-ready':  At least one of the resources needed by
              the job, such as media, fonts, resource objects, etc., is not MANDATORY, they are OPTIONAL.

                       June 23, 1997, Expires December 23, 1997
       +----------------------------+----------------------+----------------+
       |      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     | uri                  |                |
       +----------------------------+----------------------+----------------+
       | printer-driver-installer   | uri                  |                |
       +----------------------------+----------------------+----------------+
       | printer-make-and-model     | text                 |                |
       +----------------------------+----------------------+----------------+
       | printer-more-info-         | uri                  |                |
       | manufacturer               | uri                  |                |
       +----------------------------+----------------------+----------------+
       | printer-state              | type1 keyword        |  MANDATORY     |
       +----------------------------+----------------------+----------------+
       | printer-state-reasons      | type2 keyword        |                |
       +----------------------------+----------------------+----------------+
       | printer-state-message      | text                 |                |
       +----------------------------+----------------------+----------------+
       | printer-is-accepting-jobs  | boolean              |  MANDATORY     |
       +----------------------------+----------------------+----------------+
       | queued-job-count           | integer              |                |
       +----------------------------+----------------------+----------------+
       | printer-message-from-      | text                 |                |
       | operator                   |                      |                |
       +----------------------------+----------------------+----------------+
       | printer-locale             | locale               |  MANDATORY     |
       +----------------------------+----------------------+----------------+
       | printer-locales-supported  | 1setOf locale        |  MANDATORY     |
       +----------------------------+----------------------+----------------+
       | color-supported            | boolean              |                |
       +----------------------------+----------------------+----------------+

       6.5.1 printer-uri (uri)

       This attribute contains
              ready on any of the URI physical printer's for which the printer.  An administrator SHALL
       determine job is a printer's URI and SHALL set this attribute to that URI.
              candidate.  This condition MAY be detected when the job is
              accepted, or subsequently while the job is pending or processing,
              depending on implementation.
           'printer-stopped-partly':  The
       precise format value of a printer URI SHALL be implementation dependent.

                       June 23, 1997, Expires December 23, 1997
       6.5.2 printer-uri-user (uri)

       Similar to "printer-uri", this attribute contains the URI for an HTML
       page with more information about this printer.

       6.5.3 printer-name (name)

       This Printer's "printer-
              state-reasons" attribute contains the name value 'stopped-partly'.
           'printer-stopped':  The value of the printer. It Printer's "printer-state"
              attribute is 'stopped'.
           'job-printing':  The output device is marking media. This value is
              useful for Printers which spend a name that great deal of time processing
              when no marking is
       more user friendly than the printer-URI. An administrator SHALL
       determine a printer's name happening and SHALL set this attribute then want to show that name.
       This 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 may be is the last part same as
              the value of the printer's URI or it may be
       unrelated. In non-US-English locales, 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 may contain characters that
       are not allowed in a URI.

       6.5.4 printer-location (text)

       This attribute identifies is
              different than the location value of this printer.

       6.5.5 printer-description 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).
           'logfile-pending ':  The job's logfile is pending file transfer.
           'logfile-transferring':  The job's logfile is being transferred.

                                Expires January 14, 1998
         4.3.8 job-state-message (text)

         This attribute identifies the descriptive attributes specifies supplemental information about the 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".

       6.5.6 printer-more-info-site (uri) Job State
         in human readable text.

         4.3.9 output-device-assigned (name)

         This attribute contains a URI used identifies the Output Device to obtain more information about which the Printer has
         assigned this
       specific printer.  The information obtained from job.  If an output device implements an embedded IPP
         Printer, the Printer NEED NOT set this URI is intended
       for end user consumption. Features outside attribute.  If a Print Server
         implements a Printer, the scope of IPP can value MAY be
       accessed from this URI.  The information is intended to be specific empty until the Printer assigns
         an output device to
       this printer instance and site services (e.g. job pricing, services
       offered, end user assistance).  The printer manufacturer may initially
       populate this attribute.

       6.5.7 printer-driver-installer (uri) the job.

         4.3.10 time-since-pending (milliseconds)

         This attribute contains a URI to use to locate indicates the driver installer for
       this printer. amount of time that has passed since the
         Job was first put into the pending state..

         4.3.11 time-since-processing (milliseconds)

         This attribute is intended for consumption by automata.
       The mechanics of print driver installation is outside indicates the scope amount of IPP.
       The printer manufacturer may initially populate this attribute.

       6.5.8 printer-make-and-model (text) time that has passed since the
         Job first entered the processing state.

         4.3.12 time-since-completed (milliseconds)

         This attribute identifies indicates the make and model amount of time that has passed since the printer.

                       June 23, 1997, Expires December 23, 1997
       6.5.9 printer-more-info-manufacturer (uri)
         Job was completed.

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

         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 indicates the scope number of jobs that are "ahead" of IPP can be accessed
       from this URI (e.g., latest firmware, upgrades, print drivers, optional
       features available).  The information
         job in the current scheduled order.  For efficiency, it is intended to be germane only
         necessary to calculate this
       printer without regard to site specific modifications or services.

       6.5.10 printer-state (type1 keyword) value when an operation is performed that
         requests this attribute.

         Note: This attribute identifies 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 current state of the printer.  The
       "printer-state reasons" attribute augments waiting list which are not returned
         in the "printer-state" response or cannot be because of site security policy
         restrictions.

         4.3.14 job-message-from-operator (text)

         This attribute provides a message from an operator, system
         administrator or "intelligent" process to indicate to give more detailed information about the Printer in end user the given printer
       state.

       A Printer SHALL continually keep this
         reasons for modification or other management action taken on a job.

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

         This attribute set to specifies the value number of octets completed in the
       table below which most accurately reflects the state K octets,
         i.e., in units of the Printer.  A
       Printer NEED NOT implement all values if they are not applicable to a
       given implementation.

       The following standard values are defined:

         'unknown': 1024 octets.  The Printer state is not known, or is indeterminate. A
            Printer value SHALL use this state only if it cannot determine its actual
            state.

         'idle':  If a Printer receives be rounded up, so that
         a job (whose required resources 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
            ready) while intended to be
         counters as in this state, such a job SHALL transit into the
            processing state immediately.  If Job Monitoring MIB [27].

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

         This job attribute specifies the printer-state-reasons number of impressions completed. This
         attribute contains any reasons, they SHALL is intended to be reasons that would
            not prevent a counter as in the Job Monitoring MIB.

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

         This job from transiting into attribute specifies the processing state
            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 media-sheets completed. This
         attribute is idle.

         'processing':  If a Printer receives intended to be a job (whose required resources 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 are ready) while supplied in this state, such a job SHALL transit into the
            pending state immediately. Such a job SHALL transit into Print-Job or Print-URI
         requests.  For multi-Document Jobs, they are supplied in each Send-
         Document or Send-URI request.

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

         4.4.1 document-name (name)

         This attribute contains the
            processing state only after jobs ahead name of it complete.  If the
            printer-state-reasons 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 contains any reasons, they SHALL be
            reasons absent.

                                Expires January 14, 1998
         4.4.2 document-format (type2 enum)

         See section 4.2.16 that do describes the "document-format" Job Template
         attribute.

         4.4.3 document-uri (uri)

         This attribute contains the URI of the document when the document
         content is not prevent included in the current job from printing, e.g.
            toner-low.  Note: if a Printer controls more than one output
            device, Send Document operation.  Document-
         number is the above definition implies that only other attribute allowed when a Printer document-URI
         attribute is processing
            if at least one output device is processing, and none is idle.

         'stopped':  If a Printer receives a job (whose required resources are
            ready) while present in this state, such a job SHALL transit into the

                       June 23, 1997, Expires December 23, 1997
            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. paper-jam, which prevents it from either processing
            the current job or transiting a pending job to the processing
            state.

            Note: if a Send Document operation.

         4.5 Printer controls more than one output device, Description Attributes

         These attributes form the above
            definition implies that a attribute group called "printer-
         description".  A Printer is stopped only if all output
            devices are stopped.  Also, it is tempting to define stopped as
            when object may be realized in either a sufficient number of print
         server or output devices device.  Note: How these attributes are stopped and leave it
            to set by 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
         Administrator is stopped.

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

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

       Each MAY have an adornment to indicate its level scope of severity. this specification.  The three
       levels are: report (least severe), warning,
         following table summarizes these attributes, their syntax, and error (most severe).

         - 'report':  it has the adornment of "report". An implementation may
            choose to omit some whether
         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 not they are MANDATORY.  If they are not MANDATORY, they are
         OPTIONAL.

                                Expires January 14, 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     | uri                  |                |
         +----------------------------+----------------------+----------------+
         | printer-driver-installer   | uri                  |                |
         +----------------------------+----------------------+----------------+
         | printer-make-and-model     | text                 |                |
         +----------------------------+----------------------+----------------+
         | printer-more-info-         | uri                  |                |
         | manufacturer               |                      |                |
         +----------------------------+----------------------+----------------+
         | printer-state              | type1 enum           |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | printer-state-reasons      | type2 keyword        |                |
         +----------------------------+----------------------+----------------+
         | printer-state-message      | text                 |                |
         +----------------------------+----------------------+----------------+
         | printer-is-accepting-jobs  | boolean              |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | queued-job-count           | integer              |                |
         +----------------------------+----------------------+----------------+
         | printer-message-from-      | text                 |                |
         | operator                   |                      |                |
         +----------------------------+----------------------+----------------+
         | printer-locale             | locale               |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | printer-locales-supported  | 1setOf locale        |  MANDATORY     |
         +----------------------------+----------------------+----------------+
         | color-supported            | boolean              |                |
         +----------------------------+----------------------+----------------+

         4.5.1 printer-uri (uri)

         This attribute contains the
            printed output.
         - 'warning': it has URI for the adornment of "warning". printer.  An implementation may
            choose to omit some or all warnings. Warnings serve as administrator
         SHALL determine a precursor
            to an error. A warning printer's URI and SHALL contain nothing set this attribute to that prevents
         URI. The precise format of a job
            from completing, though in some cases the output may printer URI SHALL be of lower
            quality.
         - 'error': it has no adornment. An implementation SHALL include all
            errors. If
         dependent.

                                Expires January 14, 1998
         4.5.2 printer-uri-user (uri)

         Similar to "printer-uri", this attribute contains one or the URI for an HTML
         page with more errors, printer
            SHALL be in information about this printer.

         4.5.3 printer-name (name)

         This attribute contains the stopped state.

       An implementation may add 'error-', 'warning-', or 'report-' to any name of the reasons below to indicate the level of severity.

       If printer. It is a Printer controls name that is
         more user friendly than one output device, each value of the printer-URI. An administrator SHALL
         determine a printer's name and SHALL set this attribute SHALL apply to one or more of the output devices. An error on
       one output device that does not stop name.
         This name may be the Printer as a whole appears as a
       warning in last part of the Printer's printer-state-reasons attribute. Such a
       Printer's printer-state value printer's URI or it may be stopped even with no printer-state-
       reasons
         unrelated. In non-US-English locales, a name may contain characters
         that are errors.

                       June 23, 1997, Expires December 23, 1997
       The following standard values are defined:

         'media-needed': A tray has run out of media.
         'media-jam': The printer has not allowed in a media jam.
         'paused': Someone has paused URI.

         4.5.4 printer-location (text)

         This attribute identifies the Printer. In location of this state, a Printer
            SHALL not produce printed output, but it SHALL perform other
            operations requested by a client. If a Printer had been printing a
            job when printer.

         4.5.5 printer-description (text)

         This attribute identifies the Printer was paused, descriptive information about the Printer SHALL resume this
         Printer.  This could include things like: "This printer can be used
         for printing
            that job when the Printer is no longer paused and leave no evidence
            in the printed output color transparencies for HR presentations", or "Out of such
         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 pause.
         'shutdown': Someone has removed new printer".

         4.5.6 printer-more-info-site (uri)

         This attribute contains a Printer URI used to obtain more information about
         this specific printer.  The information obtained from service, this URI is
         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 it site services (e.g. job pricing,
         services offered, end user assistance).  The printer manufacturer may be
            powered down or physical removed. In
         initially populate this state, attribute.

         4.5.7 printer-driver-installer (uri)

         This attribute contains a Printer SHALL
            not produce printed output, and unless URI to use to locate the Printer driver installer
         for this printer.   This attribute is realized intended for consumption by a
         automata. The mechanics of print server that is still active, the 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 Printer driver installation is
            no longer shutdown. If outside the Printer resumes printing such a job, it
         scope of IPP.  The printer manufacturer may leave evidence in initially populate this
         attribute.

         4.5.8 printer-make-and-model (text)

         This attribute identifies the printed output make and model of such a shutdown, e.g. the part printed before the shutdown may be printed printer.

                                Expires January 14, 1998
         4.5.9 printer-more-info-manufacturer (uri)

         This attribute contains a second time
            after the shutdown.

         ISSUE: Bob suggests:  From an English point URI used to obtain more information about
         this type of view the suffixes
            should be -partly and -mostly rather than -report and -warning with
            all being -warnings.  For example, paused-partly-warning or media-
            needed-mostly-warning

         'connecting-to-device': printer.  The server has scheduled a job on the Printer
            and information obtained from this URI is in
         intended for end user consumption.  Features outside the process scope of connecting IPP
         can be accessed from this URI (e.g., latest firmware, upgrades, print
         drivers, optional features available).  The information is intended to a shared network output
            device (and might not
         be able germane to actually start printing the job
            for an arbitrarily long time depending on this printer without regard to site specific
         modifications or services.

         4.5.10 printer-state (type1 keyword)

         This attribute identifies the usage current state of the output
            device by other servers on the network).
         'timed-out': printer.  The server was able to connect to
         "printer-state reasons" attribute augments the output device (or
            is always connected), but was unable "printer-state"
         attribute to get a response from give more detailed information about 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 output-device
            ceases accepting jobs, in the
         given printer state.

         A Printer will have SHALL continually keep this attribute set to the value in
         the table below which most accurately reflects the state while of the
            output device completes printing.
         'stopped-partly': When a
         Printer.  A Printer controls more than one output
            device, this reason indicates that one or more output devices are
            stopped. If the reason is a report, fewer than half of the output
            devices NEED NOT implement all values if they are stopped. If the reason is not
         applicable to a warning, fewer than all of
            the output devices given implementation.

         The following standard values are stopped.
         'toner-low': defined:

           'unknown'(2):  The Printer state is low on toner.

                       June 23, 1997, Expires December 23, 1997
       6.5.12 printer-is-accepting-jobs (boolean)

       This attribute determines whether the printer not known, or is currently accepting
       job. indeterminate.
              A Printer SHALL use this state only if it cannot determine its
              actual state.

           'idle'(3):  If a Printer receives a job (whose required resources
              are ready) while in this state, such a job SHALL transit into the value is true, the printer is accepting jobs.
              processing state immediately.  If the value
       is false, the printer is currently rejecting printer-state-reasons
              attribute contains any jobs submitted to it.

       Note: This value is independent of the printer state and printer-state- reasons, they SHALL be reasons because its value does that would
              not affect the current job; rather it
       affects future jobs. This attribute may cause prevent a job from transiting into the processing state
              immediately, e.g., toner-low. Note: if a Printer to reject jobs
       when controls more
              than one output device, the printer-state above definition implies that a
              Printer is idle or it may cause the Printer to accepts
       jobs when the printer-state if at least one output device is stopped.

       6.5.13 printer-state-message (text)

       This attribute specifies the additional information about the printer
       state idle.

           'processing'(4):  If a Printer receives a job (whose required
              resources are ready) while in human readable text and it this state, such a job SHALL be set by
              transit into the Printer (or the
       Administrator by some mechanism outside the scope of IPP). When a
       Printer returns the value of this attribute to pending state immediately. Such a client, the Printer job SHALL localize the value of this attribute to be in
              transit into the locale processing state only after jobs ahead of it
              complete.  If the
       user, as specified by the Get-Attributes or Get-Jobs operation.

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

       This 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 count of Printer controls
              more than one output device, the number of jobs above definition implies that are either
       pending and/or a
              Printer is processing if at least one output device is
              processing, and none is idle.

                                Expires January 14, 1998
           'stopped'(5):  If a Printer receives a job (whose required
              resources are ready) while in this state, such a job SHALL be set by
              transit into the Printer.

       6.5.15 printer-message-from-the-operator (text)

       This attribute provides pending state immediately. Such a message from an operator, system administrator
       or "intelligent" process to indicate to job SHALL
              transit into the end user information or
       status of processing state only after some human fixes the printer, such as why it is unavailable or when
              problem that stopped the printer and after jobs ahead of it is
       expected to be available.

       6.5.16 printer-locale (locale)

       This
              complete printing.  The "printer-state-reasons" attribute specifies SHALL
              contain at least one reason, e.g. media-jam, which prevents it
              from either processing the current locale that job or transiting a pending
              job to the processing state.

              Note: if a Printer is
       operating in.

       6.5.17 printer-locales-supported (1setOf locale)

       This attribute specifies the locales that the Printer operates in.

       6.5.18 color-supported (boolean)

       This attribute identifies whether controls more than one output device, the
              above definition implies that a Printer is capable of any type of
       color printing at all.  All document instructions having to do with
       color stopped only if all
              output devices are embedded within the document PDL (none stopped.  Also, it is tempting to define
              stopped as when a sufficient number of output devices are external IPP
       attributes).

                       June 23, 1997, Expires December 23, 1997
       7. Conformance

       This section describes conformance issues stopped
              and requirements. This
       document introduces model entities leave it to an implementation to define the sufficient
              number.  But such as objects, operations,
       attributes, and attribute values.  These conformance sections describe a rule complicates the conformance requirements which apply to these model entities.

       7.1 Conditionally Mandatory definition of stopped
              and processing. For example, with this alternate definition of
              stopped, a conditionally mandatory job can move from idle to processing without human
              intervention, even though the Printer is stopped.

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

         This attribute means 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 Printer "report".
              An implementation need not support the attribute if may choose to omit some or all reports. Some
              reports specify finer granularity about the attribute controls printer state; others
              serve as a feature precursor to a warning. A report SHALL contain nothing
              that could affect the output device does not implement or expose.  For
       example, for an output device printed output.
           - '-warning': This suffix indicates that can only print on one side, the reason is a Printer
       need not support the "sides" attribute.  For "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 device may be of lower quality.
           - '-error': This suffix indicates that the reason is an "error". .
              An implementation SHALL include all errors. If this attribute
              contains one or more errors, printer SHALL be in the stopped
              state.

         If the implementation does not support add any one of the finishing attribute values, a Printer need not
       support the "finishing" attribute.

       7.2 Client Conformance Requirements

       There are no conformance requirements placed on three suffixes, all
         parties SHALL assume that the user interfaces
       provided by IPP clients or their applications.  For example, one
       application might not allow reason is an end user to submit multiple documents per
       job, while another does.  One application might first query "error".

         If a logical Printer
       object in order controls more than one output device, each value
         of this attribute MAY apply 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 one or create request, an IPP client need not
       supply any attributes.

       A client SHALL be able to accept any more of the attribute syntaxes defined
       in Section 6.1 output devices.  An
         error on one output device that may be returned to it in does not stop the logical Printer as a response from

                                Expires January 14, 1998
         whole MAY appear as a warning in the Printer's "printer-state-reasons
         attribute".  The "printer-state" for such a Printer

       A query response may contain attributes and values that the client does
       not expect.  Therefore, have a client implementation MUST gracefully handle
       such responses and not refuse to interoperate value
         of 'stopped' even though there are with a conforming Printer
       that is returning extended registered or private attributes and/or
       attribute no "printer-state-reasons"
         values that conform to Section 8.  Clients may choose to
       ignore any attributes that it does are "errors".

         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. In this state, a Printer
              SHALL not understand.

       7.3 produce printed output, but it SHALL perform other
              operations requested by a client. If a Printer Object Conformance Requirements

       This section specifies had been printing
              a job when the conformance requirements for conforming Printer object implementations with respect to objects, operations, and
       attributes.

                       June 23, 1997, Expires December 23, 1997
       7.3.1 Objects

       Conforming was paused, the Printer implementations SHALL implement all of resume
              printing that job when the model
       objects as defined in this specification Printer is no longer paused and leave
              no evidence in the indicated sections:

         Section 4.1 printed output of such a pause.
           'shutdown': Someone has removed a Printer Object
         Section 4.2 Job Object
         Section 4.3 Document Object

       7.3.2 Operations

       Conforming from service, and it may
              be powered down or physical removed. In this state, a Printer implementations
              SHALL implement all of not produce printed output, and unless the MANDATORY
       model operations, Printer is
              realized by a print server that is still active, the Printer
              SHALL perform no other operations requested by a client,
              including mandatory responses, as defined in returning this
       specification in the indicated sections:

         For value. If a Printer object:
            Get-Operations (section 5.1.1)               MANDATORY
            Print-Job (section 5.1.2)                    MANDATORY
            Print-URI (section 5.1.3)                    OPTIONAL
            Validate-Job (section 5.1.4)                 OPTIONAL
            Create-Job (section 5.1.5)                   OPTIONAL
            Get-Jobs (section 5.1.8)                OPTIONAL
            Get-Attributes (section 5.1.9)                    OPTIONAL

         For had been printing a Job object:
            Send-Document (section 5.1.6)           OPTIONAL
            Send-URI (section 5.1.7)                OPTIONAL
            Cancel-Job (section 5.1.8)                   MANDATORY
            Get-Attributes (section 5.1.9)                    OPTIONAL

       7.3.3 Attributes

       ISSUE:  Some
              job when it was shutdown, the Printer attributes are purely software, so need not resume printing
              that
       Conditionally Mandatory doesn't apply, such as job when the Printer Description
       Attributes.  For example, what does it mean for is no longer shutdown. If the "printer-location"
       to be Conditionally Mandatory?  Should we add Printer
              resumes printing such a "OPTIONAL" job, it may leave evidence in the header printed
              output of such a shutdown, e.g. the few attributes for which Conditionally Mandatory doesn't make
       sense?

       Conforming Printer implementations SHALL support all of part printed before the MANDATORY
       attributes, as defined in this specification in
              shutdown may be printed a second time after the indicated sections.

       Conforming Printer implementations SHALL support all CONDITIONALLY
       MANDATORY attributes as defined in this specification in shutdown.
           'connecting-to-device': The server has scheduled a job on the indicated
       sections that represent features
              Printer and behaviors that is in the actual process of connecting to a shared network
              output device implements.

                       June 23, 1997, Expires December 23, 1997
       It is (and might not required that a conforming Printer support all values of all
       supported attributes.  For example, if a Printer supports some be able to actually start printing
              the job for an arbitrarily long time depending on the usage of
              the
       "finishing" attribute values in this document, it is not required that a
       Printer implement or support all finishing methods indicated output device by all other servers on the
       values of network).
           'timed-out': The server was able to connect to the "finishing" attribute contained in this document.

       If a Printer implements output device
              (or is always connected), but was unable to get a "xxx-supported" attribute it MUST implement response from
              the corresponding "xxx" default value attribute output device.
           'stopping': The printer will be stopping in a while and vice versa.

       7.3.4 Printer extensions

       A conforming will change
              its reason to printer-stopped. This reason is a non-critical,
              even for a Printer may support registered extensions and private
       extensions, as long as they meet with a single output device. When an output-
              device ceases accepting jobs, the requirements specified in Section
       8.

       7.3.5 Attribute Syntaxes

       A Printer SHALL be able to accept any of will have this state
              while the attribute syntaxes defined
       in Section 6.1 in any operation in which a client may supply attributes.
       Furthermore, output device completes printing.
           'stopped-partly': When a Printer SHALL return attributes to the client in
       operation responses controls more than one output
              device, this reason indicates that conform to the syntax specified in Section 6.1.

       7.4 Security Conformance Requirements

       The security mechanisms being considered for IPP fall outside one or more output devices are
              stopped. If the scope reason is a report, fewer than half of the application layer protocol itself.  There output
              devices are two mechanisms used
       to begin secure communications using IPP:

         1. Information in stopped. If the directory entry for an IPP Printer (or from
            additional information at reason is a Web site hosting warning, fewer than all
              of the IPP Printer)
            indicate which, if any, security protocols output devices are used in conjunction
            with IPP.

         2. stopped.
           'toner-low': The URI for the IPP Printer contains the security protocol
            information (https://..., etc.).

       In either case, the security protocol (if any) is initiated first which
       allows low on toner.
           'spool-area-full': The limit of persistent storage allocated for
              spooling has been reached.

                                Expires January 14, 1998
         4.5.12 printer-is-accepting-jobs (boolean)

         This attribute determines whether the negotiation of security features.  IPP printer is then run as an
       application protocol on top of currently accepting
         job.  If the security protocols.  One cannot
       "bootstrap" value is true, the security features from IPP itself.

       ISSUE: The above printer is not quite correct.  Waiting for better description
       from accepting jobs. If the security document [22].

                       June 23, 1997, Expires December 23, 1997
       8. IANA Considerations, Registered Extensions, Private Extensions

       IPP
         value is explicitly designed false, the printer is currently rejecting any jobs submitted
         to be extensible.  Additional attributes can
       be proposed it.

         Note: This value is independent of the printer state and printer-
         state-reasons because its value does not affect the current job;
         rather it affects future jobs. This attribute may cause the Printer to be registered by going through
         reject jobs when the type 2 printer-state is idle or type 3
       keyword process which will register their specification after approval
       with IANA.  In addition specific implementation instances it may support
       not only cause the basic protocol as defined in this specification, but may
       add vendor-specific private extensions by prefixing attribute-names with
       their company name registered with IANA for use in domains.  See
       attribute syntax section.  However, such private extensions SHALL not
       duplicate Printer
         to accepts jobs when the printer-state is stopped.

         4.5.13 printer-state-message (text)

         This attribute semantics already specifies the additional information about the printer
         state in this specification.

       9. Security Considerations

       There is another Internet-Draft called "Internet Printing Protocol/1.0:
       Security" [22].  That document is being drafted human readable text and reviewed in parallel
       with this document.  The mapping it SHALL be set by the Printer (or
         the Administrator by some mechanism outside the scope of IPP on top IPP).

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

         This attribute contains a count of appropriate security
       protocols will be described in the number of jobs that document.  IPP does not introduce
       any new, general purpose security mechanisms for authentication are either
         pending and/or processing and
       encryption.

       A Printer may choose, for security reasons, not to return all attributes
       that SHALL be set by the Printer.

         4.5.15 printer-message-from-the-operator (text)

         This attribute provides a client requests. It may even return none message from an operator, system
         administrator or "intelligent" process to indicate to the end user
         information or status of the requested
       attributes. In printer, such cases, the status returned as why it is unavailable or
         when it is expected to be available.

         4.5.16 printer-locale (locale)

         This attribute specifies the same as if current locale that the Printer had returned all requested attributes. The client cannot tell by
       such a response whether the requested is
         operating in.

         4.5.17 printer-locales-supported (1setOf locale)

         This attribute was present or absent on specifies the Printer.

       10. References

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

       [2]  Berners-Lee, T, Fielding, R., and Nielsen, H., "Hypertext Transfer
            Protocol - HTTP/1.0", RFC 1945, August 1995.

       [3]  Crocker, D., "Standard for supported locales that the Format Printer
         operates in.

         4.5.18 color-supported (boolean)

         This attribute identifies whether the Printer is capable of ARPA Internet Text
            Messages", RFC 822, August 1982.

       [4]  Postel, J., "Instructions any type
         of color printing at all.  All document instructions having 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.

                       June 23, 1997, do with
         color are embedded within the document PDL (none are external IPP
         attributes).

                                Expires December 23, 1997
       [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 January 14, 1998
         4.5.19 pdl-override (type2 keyword)

         A client supplies Job Template attributes to affect the rendering,
         production and Describing finishing of the
            Format documents in the job.  Similar types
         of Internet Message Bodies", RFC 1521, September, 1993.

       [9]  Braden, S., "Requirements for Internet Hosts - Application and
            Support", RFC 1123, October, 1989,

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

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

        [20]     Internet Printing Protocol: Requirements

       [21] Internet Printing Protocol/1.0: Model and Semantics (This document)

       [22] Internet Printing Protocol/1.0: Security

       [23] Internet Printing Protocol/1.0: Protocol Specification

       [24] Internet Printing Protocol/1.0: Directory Schema

       [25] S. Bradner, "Key words for use instructions may also be contained in RFCs the document to Indicate Requirement
            Levels", RFC 2119 , March 1997

       [26] H. Alvestrand, " Tags for be printed,
         that is, within the Identification Page Description Language (PDL) of Languages", RFC
            1766, March 1995.

       11. Author's Address

            Scott A. Isaacson
            Novell, Inc.
            122 E 1700 S
            Provo, UT   84606

            Phone: 801-861-7366
            Fax:   801-861-4025
            EMail: scott_isaacson@novell.com

            Tom Hastings
            Xerox Corporation

                       June 23, 1997, Expires December 23, 1997
            701 S. Aviation Blvd.
            El Segundo, CA   90245

            Phone: 310-333-6413
            Fax:   310-333-5514
            EMail: hastings@cp10.es.xerox.com

            Robert Herriot
            Sun Microsystems Inc.
            2550 Garcia Ave., MPK-17
            Mountain View, CA 94043

            Phone: 415-786-8995
            Fax:  415-786-7077
            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 the document
         data.  If there is a conflict between the value of one of these IPP Mailing List:  ipp@pwg.org
         Job Template attributes, and a corresponding instruction in the
         document (either implicit or explicit), it is desirable that the value
         of the IPP Mailing List Subscription:  ipp-request@pwg.org attribute take precedence over the document instruction.
         Until companies that supply interpreters for PDLs, such as PostScript
         and PCL allow a way for external attributes (such as IPP Web Page:  http://www.pwg.org/ipp/

         Other Participants:

            Chuck Adams - Tektronix
            Jeff Barnett - IBM
            Ron Bergman - Data Products
            Keith Carter, IBM Corporation
            Jeff Copeland attributes)
         to take precedence over internal job production instructions, a
         Printer might not be able to support the semantics that IPP attributes
         override (take on a higher precedence) the embedded PDL instructions.
         This attribute expresses how a particular Printer implementation
         handles these conflicts.

         This attribute takes on the following values:

           - QMS
            Andy Davidson 'guaranteed': This value indicates that the Printer guarantees
              that all IPP attribute values take precedence over embedded PDL
              instructions.
           - Tektronix
            Mabry Dozier 'attempted': This value indicates that the Printer attempts to
              make sure that IPP attribute values take precedence over embedded
              PDL instructions, however there is no guarantee.
           - QMS

                       June 23, 1997, 'ignored': This value indicates that the Printer ignores all IPP
              Job Template attributes and it makes no attempts to ensure that
              IPP attribute values take precedence over embedded PDL
              instructions.

         This is a MANDATORY attribute.

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

         If the value of this attribute is 'guaranteed', the implementation
         MUST guarantee that the IPP attribute values take precedence over any
         related job processing instructions in the PDL Job's document data.
         This can be done by modifying the interpreter within the output device
         itself to understand IPP attributes, or by merging theses Job Template
         attributes directly into the document data, or in any other
         implementation specific manner.  In any case, the semantics of
         'guaranteed' MUST be preserved.

                                Expires December 23, 1997
            Lee Farrell - Canon Information Systems
            Steve Gebert - IBM
            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
            Pat Nogay - IBM
            Bob Pentecost - HP
            Rob Rhoads - Intel
            David Roach - Unisys
            Hiroyuki Sato - Canon
            Bob Setterbo January 14, 1998
         4.5.20 Security Related Attributes

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

           - Adobe
            Devon Taylor, Novell, Inc.
            Mike Timperman no security
           - Lexmark
            Randy Turner message protection
           - Sharp
            Atsushi Yuki client authentication and authorization
           - Kyocera
            Lloyd Young - Lexmark
            Bill Wagner - DPI
            Jim Walker - DAZEL
            Chris Wellens mutual authentication, authorization, and message protection

         In order to let an end user know what to expect in terms of security,
         there are two attributes described below.  Since by definition an end
         user, because of security reasons, might not be allowed to query these
         two attributes, therefore, it is important that if these two
         attributes are supported, then they are also populated in the
         directory entry (see [24]).

         These attributes allow for minimal client/server negotiation regarding
         security features.  If the Printer requires the feature, the client
         can decide whether or not to participate.  If the client does not
         support the feature, and the Printer requires it, then the client
         knows before hand that such an interaction would fail.

         Standard values for these two attributes include:

           'supported' - Interworking Labs
            Rob Whittle  means that the Printer is capable of supporting the
              security feature (somehow), but it is does not require the client
              to use it.
           'required' - Novell
            Don Wright  means that the Printer is capable of supporting the
              security feature (somehow) and the client is required to use it.
           'none' - Lexmark
            Peter Zehler, Xerox, Corp.

                       June 23, 1997, means that the Printer is not capable of supporting
              message protection at all.

         Note:  This is a single-valued attribute, not a multi-valued
         attribute, i.e., an implementation can not support 'none' and
         'required' or any other combination of values.

         4.5.20.1 message-protection-supported (keyword)

         This attribute is used to determine whether or not a printer supports
         or requires message protection (whether it be through encryption or
         some other privacy mechanism).

         4.5.20.2 authentication-authorization-supported (keyword)

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

                                Expires January 14, 1998
         5. Conformance

         This section describes conformance issues and requirements. This
         document 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 Conditionally Mandatory

         For example, a conditionally mandatory attribute means that a Printer
         implementation need not support the attribute if the attribute
         controls a feature that the output device does not implement or
         expose.  For example, for an output device that can only print on one
         side, a Printer need not support the "sides" attribute.  For an output
         device that does not support any of the finishing attribute values, a
         Printer need not support the "finishing" attribute.

         5.2 Client Conformance Requirements

         There are no conformance requirements placed on the user interfaces
         provided by IPP clients or their applications.  For example, one
         application might not allow an end user to submit multiple documents
         per job, while another does.  One application might first query a
         Printer 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 accept any of the attribute syntaxes defined
         in Section 4.1 that may be returned to it in a response from a Printer

         A query response may contain 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 that is returning extended registered or private attributes
         and/or attribute values that conform to Section 6.  Clients may choose
         to ignore any attributes that it does not understand.

                                Expires January 14, 1998
         5.3 Printer Object Conformance Requirements

         This section specifies the conformance requirements for conforming
         Printer object implementations with respect to objects, operations,
         and attributes.

         5.3.1 Objects

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

           Section 2.1 Printer Object
           Section 2.2 Job Object
           Section 2.3 Document Object

         5.3.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:
              Get-Operations (section 3.1.1)               MANDATORY
              Print-Job (section 3.1.2)                    MANDATORY
              Print-URI (section 3.1.3)                    OPTIONAL
              Validate-Job (section 3.1.4)                 MANDATORY
              Create-Job (section 3.1.5)                   OPTIONAL
              Get-Jobs (section 3.1.8)              	     MANDATORY
              Get-Attributes (section 3.1.9)               MANDATORY

           For a Job object:
              Send-Document (section 3.1.6)                OPTIONAL
              Send-URI (section 3.1.7)                     OPTIONAL
              Cancel-Job (section 3.1.8)                   MANDATORY
              Get-Attributes (section 3.1.9)               MANDATORY

         5.3.3 Attributes

         Conforming Printer implementations SHALL support all of the MANDATORY
         attributes, as defined in this specification in the indicated
         sections.

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

                                Expires January 14, 1998
         If a Printer implements a "xxx-supported" attribute it MUST implement
         the corresponding "xxx" default value attribute and vice versa.

         5.3.4 Printer extensions

         A conforming Printer may support registered extensions and private
         extensions, as long as they meet the requirements specified in Section
         6.

         5.3.5 Attribute Syntaxes

         A Printer SHALL be able to accept any of the attribute syntaxes
         defined in Section 4.1 in any operation in which a client may supply
         attributes or parameters.  Furthermore, a Printer SHALL return
         attributes to the client in operation responses that conform to the
         syntax specified 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 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 in
              conjunction with IPP.

           2. The URI for the 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.  IPP is then
         run as an application protocol on top of the security protocols.  One
         cannot "bootstrap" the security features from IPP itself.

         ISSUE: The above is not quite correct.  Waiting for better description
         from the security document [22].

         6. IANA Considerations (registered and private extensions)

         During the development of this standard, the IPP working group
         (working with IANA) will register additional keywords and enums while
         the standard is in the proposed and draft states according to the

                                Expires January 14, 1998
         procedures described in this section.  IANA will handle registration
         of additional enums after this standard is approved in cooperation
         with an IANA-appointed registration editor from the IPP working group
         according to the procedures described in this section.

         6.1 Typed Extensions

         This document identifies both keywords and enum values.  Throughout
         this document, references to "typeN enum" or "typeN keyword" can be
         found (where N can be 1, 2, 3 or 4).  The typeN extension has more
         registration controls than a typeM extension where M is greater than
         N.  That is, there are more controls in place to extend a type1 value
         over a type 2 value.  However, any typeN value MAY be registered using
         a process for some typeM where M is less than N, however such
         registration is NOT REQUIRED.  For example, a type4 value MAY be
         registered in a type1 manner (i.e., by being included in a future
         version of an IPP specification).  For private (unregistered) keyword
         extensions, implementers SHOULD use keywords with a suitable
         distinguishing prefix, such as "xxx-" where xxx is the (lowercase)
         company name registered with IANA for use in domain names.  For
         private (unregistered) enum extension, implementers SHOULD support
         values in the reserved integer range (see "enum").

         The definitions of these various types are as follows.

         6.1.1 Type1

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

         This draft contains the following type1 keywords:

           - <fill in>

         This draft contains the following type1 enums:

           - <fill in>

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

         This draft contains the following type2 keywords:

                                Expires January 14, 1998
           - <fill in>

         This draft contains the following type2 enums:

           - <fill in>

         6.1.3 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 is required.

         This draft contains the following type3 keywords:

           - <fill in>

         This draft contains 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 a local system.  Care SHOULD be taken by the
         implementers to see that keywords do not conflict with other keywords
         defined by the standard or as defined by the implementing product.
         There is no registration or approval procedure for type4 values.

         This draft contains the following type4 keywords:

           - <fill in>

         This draft contains the following type4 enums:

           - <fill in>

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

         The "document-format" attribute has MIME type/sub-type values for
         indicating document formats which IANA registers as "media type"
         names.

                                Expires January 14, 1998
         7. 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 document.  The mapping of IPP on top of
         appropriate security protocols will be described in that document.
         IPP does not introduce any new, general purpose security mechanisms
         for authentication and encryption.

         A Printer may choose, for security reasons, not to return all
         attributes that a client requests. It may even return none of the
         requested attributes. In such cases, the status returned is the same
         as if the Printer had returned all requested attributes. The client
         cannot tell by such a response whether the requested attribute was
         present or absent on the Printer.

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

         [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 the
              Format of Internet Message Bodies", RFC 1521, September, 1993.

         [9]  Braden, S., "Requirements for Internet Hosts - Application and
              Support", RFC 1123, October, 1989,

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

                                Expires January 14, 1998
         [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 Semantics (This
              document)

         [22] Internet Printing Protocol/1.0: Security

         [23] Internet Printing Protocol/1.0: Protocol Specification

         [24] Internet Printing Protocol/1.0: Directory Schema

         [25] S. Bradner, "Key words for use in RFCs to Indicate Requirement
              Levels", RFC 2119 , March 1997

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

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

         [28] F. Yergeau, "UTF-8, 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.

         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.
              El Segundo, CA   90245

                                Expires January 14, 1998
              Phone: 310-333-6413
              Fax:   310-333-5514
              EMail: hastings@cp10.es.xerox.com

              Robert Herriot
              Sun Microsystems Inc.
              2550 Garcia Ave., MPK-17
              Mountain View, CA 94043

              Phone: 415-786-8995
              Fax:  415-786-7077
              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
              IPP Mailing List Subscription:  ipp-request@pwg.org
              IPP Web Page:  http://www.pwg.org/ipp/

           Other Participants:

              Chuck Adams - Tektronix
              Jeff Barnett - IBM
              Ron Bergman - Data Products
              Keith Carter, IBM Corporation
              Jeff Copeland - QMS
              Andy Davidson - Tektronix
              Mabry Dozier - QMS
              Lee Farrell - Canon Information Systems
              Steve Gebert - IBM

                                Expires January 14, 1998
              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
              Pat Nogay - IBM
              Bob Pentecost - HP
              Rob Rhoads - Intel
              David Roach - Unisys
              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.

                                Expires January 14, 1998
         10. APPENDIX A: Terminology

         This specification uses 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", and  "OPTIONAL" in this
         document are to be interpreted as described in RFC 2119 [25].

         10.1.1 MUST

         This word, or the terms "REQUIRED",  "SHALL" or "MANDATORY", means
         that the definition is an absolute requirement of the specification.

         10.1.2 MUST NOT

         This phrase, or the phrase "SHALL NOT", means that the definition is
         an absolute prohibition 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 a different course.

         10.1.4 SHOULD NOT

         This phrase, or the phrase "NOT RECOMMENDED" means that there may
         exist valid reasons in particular circumstances when the particular
         behavior is acceptable or even useful, but the full implications
         should be understood and the case carefully weighed before
         implementing any behavior described with this label.

         10.1.5 MAY

         This word, or the adjective "OPTIONAL", means that an item is truly
         optional.  One vendor may choose to include the item because a
         particular marketplace requires it or because the vendor feels that it
         enhances the product while another vendor may omit the same item.   An
         implementation which does not include a particular option MUST be
         prepared to interoperate with another implementation which does
         include the option, though perhaps with reduced functionality. In the
         same vein an implementation which does include a particular option
         MUST be prepared to interoperate with another implementation which

                                Expires January 14, 1998
         does not include the option (except, of course, for the feature the
         option provides.)

         10.1.6 CONDITIONALLY MANDATORY

         This term means that an item MUST be implemented in a conforming
         implementation if the specified condition is true.  Conversely, a
         conforming implementation NEED NOT implement the item if the specified
         condition is false.

         10.1.7 NEED NOT

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

         10.2 Model Terminology

         10.2.1 Keyword

         Keywords are used within this document as identifiers of semantic
         entities within the abstract model.  Attribute names, some attribute
         values, attribute syntaxes, and attribute group names are represented
         as keywords.  In this document, a keyword is a sequence of characters
         (length of 1 to 255) which consists of the following ASCII characters:
         lower-case letters ("a" - "z"), digits ("0" - "9"), hyphen ("-"), and
         underscore ("_").  A keyword starts with a lower-case letter.  In the
         actual protocol, these keywords will be represented using an
         appropriate protocol encoding.

         10.2.2 Parameters

         A parameter is an item of information supplied in an operation
         consisting of a parameter name and a parameter value(s).  Each
         parameter has a specific syntax. Clients supply input parameters in
         operation requests and servers return output parameters in operation
         responses.  Most 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 (").

                                Expires January 14, 1998
         10.2.2.2 Parameter Value

         Each parameter has one or more values.  Parameter values are
         represented in the syntax type specified for 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.  The
         protocol specification document [23] indicates the actual on-the-wire
         encoding for each parameter syntax. Parameter syntaxes are the same as
         attribute syntaxes and they are defined in section 4.1.

         10.2.3 Attributes

         An attribute is an item of information that is associated with an
         instance of an IPP object.  An attribute consists of an attribute name
         and an attribute value(s).  Each attribute has a specific syntax..
         All attributes are defined in section 4.

         An interesting set of attributes is called Job Template Attributes
         (these attributes are described in detail in section 4.2.)  The client
         optionally supplies Job Template attributes as input parameters in a
         create request (operation requests that create Job objects).  The
         Printer object has associated attributes which define supported and
         default values for the Printer.  Thee following rules apply:

           - When a Job Template attribute is supplied as an input parameter
              in a create request, the attribute and its value describe the
              desired job processing behavior.

           - The Printer object's supported attribute describes what behaviors
              are possible.

           - The Printer object's default value attribute describes what will
              be done when no other job processing information is supplied by
              the client.

         10.2.3.1 Attribute Name

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

                                Expires January 14, 1998
         10.2.3.2 Attribute Group Name

         Related attributes are grouped into named groups.  The name of the
         group is a keyword.  The group name may be used in an input parameter
         in place of naming all the attributes in the group explicitly.
         Attribute groups are defined in section 4.

         10.2.3.3 Attribute Value

         Each attribute has one or more values.  Attribute values are
         represented in the syntax type specified for that attribute. In
         running text in this document, attribute values are indicated inside
         single quotation marks ('), whether their attribute syntax is keyword,
         integer, text, etc.

         10.2.3.4 Attribute Syntax

         Each attribute is defined using an explicit attribute syntax.  In this
         document, each attribute syntax is defined as a keyword 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 an IPP object)
         supports an attribute (or a particular value of an attribute) only if
         that implementation responds with the corresponding attribute and
         value in a response to a query for that attribute.  A given
         implementation may exhibit a behavior that corresponds to 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 is concerned, that
         implementation does not support that feature.

         A conforming implementation SHALL support all MANDATORY attributes and
         all CONDITIONALLY MANDATORY attributes where the implementation
         satisfies the condition associated with the CONDITIONALLY MANDATORY
         attribute.  Conformance to IPP does not mandate that all
         implementations support all possible values representing all possible
         job processing behaviors and features.  For example, if a given
         instance of a Printer supports only certain document formats, then
         that Printer responds with the "document-format-supported" attribute
         populated with a set of values, possibly only one, taken from the
         entire set of possible values defined in this model document.  This
         set of values represent the Printer's set of supported document
         formats.  Another example is the "finishings-supported" attribute.  If
         a Printer is not physically capable of stapling (there is no stapler

                                Expires December 23, 1997
       12. January 14, 1998
         in the output device itself), the "finishings-supported" attribute
         MUST NOT be populated with the value of 'staple'.

         In order to ease the implementation burden, if a certain
         implementation supports only one well-known value of some "xxx-
         supported" attribute, it is NOT REQUIRED that that implementation
         support that attribute.  For example, if a Printer object represents a
         physical device that can not print on two sides of the media, the only
         possible value for the "sides-supported" attribute could be 'one-
         sided'.  In this case, it is NOT REQUIRED that the implementation
         support the "sides-supported" attribute since a client could infer
         that the implementation supports only single-sided printing from the
         absence of the "sides-supported" attribute.  If for some reason, an
         implementation only supported "two-sided-long-edge" then that
         implementation MUST support the "sides-supported" attribute to be a
         conforming implementation.  The "well-known value" for CONDITIONALLY
         MANDATORY attribute is specified in the section describing that
         attribute.

         Note: The supported attributes are set (populated) by some
         administrative process or automatic sensing mechanism that  is outside
         the scope of IPP.

         11. APPENDIX A - B:  Status Codes

       The Status keyword provides

         This section defines status code keywords that are used to provide
         semantic information on the results of a an operation request. The
       Message  Each
         operation response MUST include a status code.  For error type status
         codes, the response MAY also contain a message that provides a short
         textual description of the Status. status. The Status status code is intended for use
         by automata automata, and the Message message is intended for the human end user.  An
         Since the message is an OPTIONAL component of the operation response,
         an IPP application (i.e. a browser, GUI, print driver or gateway) is not required
         NOT REQUIRED to examine or display the Message. message.

         The prefix of the Status status keyword defines the class of response as
         follows:

         informational

           "informational" - Request received, continuing process

         successful
           "successful" - The action was successfully received, understood,
              and accepted

         redirection
           "redirection" - Further action must be taken in order to complete
              the request

         client-error
           "client-error" - The request contains bad syntax or cannot be
              fulfilled

         server-error
           "server-error" - The server failed to fulfill an apparently valid
              request

                                Expires January 14, 1998
         IPP status codes are extensible.  IPP applications are not required NOT REQUIRED to
         understand the meaning of all registered status codes, though such
         understanding is obviously desirable.  However, applications shall SHALL
         understand the class of any status code, as indicated by the prefix,
         and treat any unrecognized response as being equivalent to the first
         status code of that class, with the exception that an unrecognized
         response shall not be cached.  For example, if an unrecognized status
         code of
       client-error-foo-bar "client-error-foo-bar" is received by the client, it can
         safely assume that there was something wrong with its request and
         treat the response as if it had received a client-error-bad-request "client-error-bad-request"
         status code.  In such cases, IPP applications should could present the Message
         OPTIONAL message (if present) to the user, end user since
       that Message the message is
         likely to include human-readable contain human readable information which will help to
         explain the unusual status.

       12.1

         11.1 Status Codes (type2 keyword)

         Each Status status code is described below, including below. Section 11.2 contains a description of table
         that indicates which
       operation(s) it can follow and any metainformation required in the
       response.

                       June 23, 1997, Expires December 23, 1997
       12.1.1 status codes apply to which operations.

         11.1.1 Informational

         This class of status code indicates a provisional response and is to
         be used for informational purposes only.

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

       12.1.2

         11.1.2 Successful Status Codes

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

       12.1.2.1 successful-OK (IPPL1)

         11.1.2.1 successful-ok

         The request has succeeded.

       Note:  IPPL1 only includes OK.  IPPL1 does not include Created nor No
       Content successful status codes.  This is consistent with our agreement
       at the IPP Model telecon on May 9, but I believe we had this discussion
       before Bob Herriot joined the telecon.

       12.1.3

         11.1.3 Redirection Status Codes

         This class of status code indicates that further action needs to be
         taken to fulfill the request.

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

       12.1.4

                                Expires January 14, 1998
         11.1.4 Client Error Status Codes

         This class of status code is intended for cases in which the client
         seems to have erred.  The server should SHOULD return a Message message containing an
         explanation of the error situation and whether it is a temporary or
         permanent condition.  IPP applications should display any returned
       Message to the end-user.  Unless otherwise noted, these status codes
       apply to all operations.

       12.1.4.1

         11.1.4.1 client-error-bad-request (IPPL1)

         The request could not be understood by the server due to malformed
         syntax.  The IPP application should not SHOULD NOT repeat the request without
         modifications.

       12.1.4.2 client-error-unauthorized

         11.1.4.2 client-error-forbidden

         The server understood the request, but is refusing to fulfill it.
         Additional authentication information or authorization credentials
         will not help and the request SHOULD NOT be repeated.  This status
         code is commonly used when the server does not wish to reveal exactly
         why the request has been refused or when no other response is
         applicable.

         11.1.4.3 client-error-not-authenticated

         The request requires user authentication.  The IPP client may repeat
         the request with suitable authorization credentials. authentication information. If the request
         already included authorization credentials, authentication information, then this status code
         indicates that authorization has been refused for those credentials.
         If this response contains the same challenge as the prior response,
         and the user agent

                       June 23, 1997, Expires December 23, 1997 has already attempted authentication at least once,
         then the user should
       be presented the Message in the response, since that Message response message may include contain relevant diagnostic information.

       12.1.4.3 client-error-payment-required
         This request requires payment by the end-user to perform the operation.

       12.1.4.4 client-error-forbidden (IPPL1) status codes reveals more information than "client-error-
         forbidden".

         11.1.4.4 client-error-not-authorized

         The server understood the request, but requester is refusing not authorized to fulfill it.
       Authorization perform the request.  Additional
         authentication information or authorization credentials will not help
         and the request should not SHOULD be repeated.  This status code is commonly used when the server does not wish to
       reveal exactly why the request has been refused or when no other
       response is applicable.

       12.1.4.5 client-error-method-not-allowed

       The operation specified in 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 14, 1998
         11.1.4.5 client-error-not-possible

         This status code is used when the request is not allowed for the object
       identified something that can
         happen.  For example, there might be a request to cancel a job that
         has already been aborted by the request URI.

       12.1.4.6 system.  The IPP client SHOULD NOT
         repeat the request.

         11.1.4.6 client-error-timeout (NEW)

         The client did not produce a request within the time that the server
         was prepared to wait.  For example, a client issued a Create-Job
         operation and then, after a long period of time, issued a Send-
         Document operation and this error status code was returned in response
         to the Send-Document request.  The server might have been forced to
         clean up resources that had been held for the waiting additional
         Documents.  The server was forced to close the Job since the client MAY
         took too long.  The client SHOULD NOT repeat the request without
       modifications at any later time.

       12.1.4.7
         modifications.

         11.1.4.7 client-error-not-found

         The server has not found anything matching the request URI.  No
         indication is given of whether the condition is temporary or
         permanent.  For example, a client with an old reference to a Job (a
         URI) tries to cancel the Job, however in the mean time the Job might
         have been completed and all record of it at the Printer has been
         deleted.  This status code, 'client-error-not-found' is returned
         indicating that the referenced Job can not be found.  This error
         status code is also used when a client supplies a URI as a reference
         to the document data in either a Print-URI or Send-URI operation
         however the document can not be found.

         ISSUE: Shall a printer be required to validate the URI at submit time?
         If the Printer tries to resolve the URI at job processing time, how is
         this error returned?  In a new "job-state-reasons" value?  In a "job-
         state-message" value?

         In practice, an IPP application should avoid this a not found situation by
         first querying and presenting a list of valid Printer URIs and Job
         URIs to the end-user.

       12.1.4.8

         11.1.4.8 client-error-gone

         The requested object is no longer available at the server and no
         forwarding address is known.  This condition should be considered
         permanent.  Clients with link editing capabilities should delete
         references to the request URI after user approval.  If the server does
         not know or has no facility to determine,whether determine, whether or not the condition

                                Expires January 14, 1998
         is permanent, the status code client-error-not-found "client-error-not-found" should be used
         instead.

         This response is cachable unless indicated otherwise.

       This response is primarily intended to assist the task of web
         maintenance by notifying the recipient that the resource is
         intentionally unavailable and that the server owners desire that
         remote

                       June 23, 1997, Expires December 23, 1997 links to that resource be removed.  Such an event is common for limited-
       time, promotional services and for resources belonging to individuals no
       longer working at the server's site. It is not necessary to mark
         all permanently unavailable resources as "gone" or to keep the mark
         for any length of time -- that is left to the discretion of the server
         owner.

       12.1.4.9

         11.1.4.9 client-error-request-entity-too-large (IPPL1)

         The server is refusing to process a request because the request entity
         is larger than the server is willing or able to process.  An IPP
         Printer returns this status code when it limits the size of print jobs
         and it receives a print job that exceeds that limit.

       12.1.4.10 limit or when the
         operation parameters are so many that their encoding causes the
         request entity to exceed server capacity.

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

         The server is refusing to service the request because the request URI
         is longer than the server is willing to interpret.  This rare
         condition is only likely to occur when a client has improperly
         submitted a request with long query information (e.g. an IPP
         application allows an end-user to enter an invalid URI), when the
         client has descended into a URL URI "black hole" of redirection (e.g., a
         redirected URL URI prefix that points to a suffix of itself), or when the
         server is under attack by a client attempting to exploit security
         holes present in some servers using fixed-length buffers for reading
         or manipulating the Request-URI.

       12.1.4.11 client-error-unsupported-media-type (IPPL1)

         11.1.4.11 client-error-unsupported-document-format

         The server is refusing to service the request because the print data
         is in a format, as specified in document-format, the "document-format" input parameter,
         that is not supported by the IPP Printer.

       12.1.4.12 client-error-attribute-value-not-supported

         11.1.4.12 client-error-attribute- not-supported

         For a Create-Job, Print-Job or Validate operation, if the IPP Printer
         does not support at least one attribute or one attribute value specified
         supplied in the request, the Printer shall return this status.  For
         example, if the request requires A4 paper and that paper size is not
         supported by the Printer, the Printer shall return this status.

                                Expires January 14, 1998
         For a Get-Jobs operation, if the IPP Printer does not support at least one attribute value for Job Owner and/or Job States in of
         the request, requested attributes, , the Printer shall return this status.

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

                       June 23, 1997, Expires December 23, 1997
       12.1.5

         11.1.5 Server Error Status Codes

         This class of status codes indicates cases in which the server is
         aware that it has erred or is incapable of performing the request.
         The server
       should SHOULD include a Message message containing an explanation of the
         error situation, and whether it is a temporary or permanent condition. IPP
       applications should display any included Message to the user. These
       response codes are applicable to any operation.

       12.1.5.1 server-error-internal-server-error

         11.1.5.1 server-error-internal- error

         The server encountered an unexpected condition which that prevented it from
         fulfilling the request.

       12.1.5.2 server-error-operation-not-implemented  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 the functionality required to fulfill the
         request. This is the appropriate response when the server does not
         recognize an operation and or is not capable of supporting it for any
       object.

       12.1.5.3 it.

         11.1.5.3 server-error-service-unavailable

         The server is currently unable to handle the request due to a
         temporary overloading or maintenance of the server.  The implication
         is that this is a temporary condition which will be alleviated after
         some delay. If known, the length of the delay may be indicated in the Message.  If no
       delay is given, the IPP application should handle the response as it
       would for a server-error-internal-server-error response.

       12.1.5.4 server-error-timeout (NEW)

       The server did not produce a response within the time that the client
       was prepared to wait.  The client MAY repeat the request without
       modifications at any later time.

       12.1.5.5 server-error-HTTP-version-not-supported (NEW)

       The server does not support, or refuses to support, the HTTP protocol
       version that was used in the request message.  The server is indicating
       that it is unable or unwilling to complete the request using length of the same
       major version as delay may be indicated in the client other than with this error
         message.  The  If no delay is given, the IPP application should handle the
         response SHOULD contain as it would for a message describing why "server-error-temporary-internal-error"
         response.  If the version condition is not
       supported and what other protocols are supported by that server.

                       June 23, 1997, Expires December 23, 1997
       12.1.5.6 server-error-IPP-version-not-supported more permanent, the error status codes
         "client-error-gone" or "client-error-not-found" could be used.

         11.1.5.4 server-error- version-not-supported

         The server does not support, or refuses to support, the IPP protocol
         version that was used in the request message.  The server is
         indicating that it is unable or unwilling to complete the request
         using the same
       major version as supplied in the client request other than with this

                                Expires January 14, 1998
         error message. The response should contain a Message describing why
         that version is not supported and what other versions are supported by
         that server.

         A conforming IPP client shall specify the valid version for IPP 1.0 on (IPP 1.0)on
         each request.  A conforming IPP server shall not (IPP 1.0) SHALL NOT return this
         status code to a conforming IPP 1.0 client.  An IPP server shall
         return this status code to a non-conforming IPP client.

       12.1.5.7 server-error-printer-error

         11.1.5.5 server-error-device-error

         A printer error, such as a paper jam, occurs while the IPP Printer
         processes a Print or Send operation.  The response shall contain contains the true
         Job Status with (the values of the specific error "job-state" and should contain a Message describing
       the error.  An IPP application should check the Job Status "job-state-reasons"
         attributes).  Additional information can be returned in the
       response for the specific error.

       12.1.5.8 server-error-write-fault

       A write error, such as a memory overflow (i.e. the document data exceeds optional
         "job-state-message" attribute value or in the memory of OPTIONAL status code
         message that describes the Printer) or a disk full condition, occurs while error in more detail.  This error status
         code MAY be returned even though the
       IPP Printer processes a Print or Send operation.

                       June 23, 1997, Expires December 23, 1997
       12.2 Mapping of HTTP 1.1 Status Codes to IPP Status Keywords

       HTTP 1.1 Status                    IPP Keyword
       ---------------                    -----------
       100 Continue                       none
       101 Switching Protocols            none
       200 OK                             successful-OK
       201 Created                        successful-OK
       202 Accepted                       successful-OK
       203 Non-Authoritive Information    successful-OK
       204 No Content                     successful-OK
       205 Reset Content                  none
       206 Partial Content (GET)          none
       300 Multiple Choices               none
       301 Moved Permanently              none
       302 Moved Temporarily              none
       303 See Other                      none
       304 Not Modified (GET)             none
       305 Use Proxy                      none
       400 Bad Request                    client-error-bad-request
       401 Unauthorized                   client-error-unauthorized
       402 Payment Required               client-error-payment-required
       403 Forbidden                      client-error-forbidden
       404 Not Found                      client-error-not-found
       405 Method Not Allowed             client-error-method-not-allowed
       406 Not Acceptable                 client-error-bad-request
       407 Proxy Authentication Required  client-error-unauthorized
       408 Request Timeout                client-error-timeout
       409 Conflict (most likely PUT)     client-error-bad-request
       410 Gone                           client-error-gone
       411 Length Required                client-error-bad-request
       412 Precondition Failed            client-error-bad-request
       413 Request Entity Too Large       client-error-request-entity-
                                               too-large
       414 Request-URI Too Long           client-error-request-URI-too-long
       415 Unsupported Media Type         client-error-unsupported-media-
                                               type
       none                               client-error-attribute-value-
                                               not-supported
       500 Internal Server Error          server-error-internal-server-error
       501 Not Implemented                server-error-not-implemented
       502 Bad Gateway                    server-error-internal-server-error
       503 Service Unavailable            server-error-service-unavailable
       504 Gateway Timeout                server-error-timeout
       505 HTTP Version Not Supported     server-error-HTTP-version-
                                               not-supported
       none                               server-error-IPP-version-
                                               not-supported

                       June 23, 1997, operation was successful (the Job
         was submitted and is now in the 'pending' state waiting to be
         processed).

         11.1.5.6 server-error-temporary-error

         A temporary error such as a buffer full write error, a memory overflow
         (i.e. the document data exceeds the memory of the Printer), or a disk
         full condition, occurs while the IPP Printer processes an operation.
         The client MAY try the unmodified request again at some later point in
         time with an expectation that the temporary internal error condition
         may have been cleared.

                                Expires December 23, 1997
       none                               server-error-printer-error
       none                               server-error-write-fault

       12.3 January 14, 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, 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-unauthorized
         client-error-not-authenticated           x  x  x  x  x  x x  x  x  x
         client-error-not-authorized              x  x  x  x
       client-error-payment-required  x  x x  x  x  x
         client-error-forbidden                   x  x  x  x  x  x x  x  x  x
       client-error-not-found
         client-error-not-possible                x  x  x  x  x  x x  x  x  x
       client-error-method-not-allowed
         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  X  X X  X  X  X
         client-error-request-URI-too-long        x  x  x  x  x  x x  x  x  x
       client-error-unsupported-media-type
         client-error-unsupported-document-format x  x     x  x
         client-error-attribute-value-not-        x  x  x        x
              supported
       server-error-internal-server-error
         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-printer-error
         server-error-device-error                x  x  x  x  x
       server-error-write-fault
         server-error-temporary-error             x  x  x  x  x

       13.

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

         The Printer Working Group has registered a set of type2 enum values
         with IANA as part of the IETF Printer MIB [1] project.  The standard
         value assigned by the PWG starts with the four letters: "lang", in
         order to follow SNMP ASN.1 rules that all enum symbols SHALL start
         with a lower case letter. The keyword values in IPP integer enum value is the same used as the PWG standard values value
         the "document-format" attribute.

         This APPENDIX lists the document formats that are currently registered
         with IANA IANA.  As with the "lang" removed.  The MIB (integer) value
       is included here for reference only, the MIB integer value SHALL NOT all type 2 and type 3 enums, when additional enum
         values are registered with IANA, they may be used in IPP; the keyword value SHALL be used.  In the IPP Protocol
       Specification [22], the keyword value SHALL be encoded as withhout
         updating this appendix.

         ISSUE: PDF does not have an enum value, though it has a MIME type.

                       June 23, 1997,
         Adobe needs to register PDF as one of the standard values.

                                Expires December 23, 1997 January 14, 1998
         The standard values registered at the current time are:

           'other': 1 -
         'PCL':
           'langPCL': 3 - PCL.  Starting with PCL version 5, HP-GL/2 is
              included as part of the PCL language.  PCL and HP-GL/2 are
              registered trademarks of Hewlett-Packard Company.
         'HPGL':
           'langHPGL': 4 - Hewlett-Packard Graphics Language.  HP-GL is a
              registered trademark of Hewlett-Packard Company.
         'PJL':
           'langPJL': 5 - Peripheral Job Language.  Appears in the data stream
              between data intended for a page description language.  Hewlett-
              Packard Co.
         'PS':
           'langPS': 6 - PostScript Language (tm) Postscript - a trademark of
              Adobe Systems Incorporated which may be registered in certain
              jurisdictions
         'IPDS':
           '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 print process.  Pennant Systems, IBM
         'PPDS':
           'langPPDS': 8 - IBM Personal Printer Data Stream.  Originally
              called IBM ASCII, the name was changed to PPDS when the Laser
              Printer was introduced in 1989.  Lexmark International, Inc.
         'EscapeP':
           'langEscapeP': 9 - Epson Corp.
         'Epson':
           'langEpson': 10 -
         'DDIF':
           'langDDIF': 11 - Digital Document Interchange Format Digital
              Equipment Corp., Maynard MA
         'Interpress':
           'langInterpress': 12 - Xerox Corp.
         'ISO6429':
           '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
         'LineData':
           'langLineData': 14 - line-data: Lines of data as separate ASCII or
              EBCDIC records and containing no control functions (no CR, LF,
              HT, FF, etc.).  For use with traditional line printers.  May use
              CR and/or LF to delimit lines, instead of records.  See ISO 10175
              Document Printing Application (DPA) ISO standard, Geneva,
              Switzerland
         'MODCA':
           'langMODCA': 15 - Mixed Object Document Content Architecture
              Definitions that allow the composition, interchange, and
              presentation of final form documents as a collection of data
              objects (text, image, graphics, bar codes), resources (fonts,
              overlays) and page, form and finishing instructions.  Pennant
              Systems, IBM
         'REGIS':
           '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
         'SPDL':

                                Expires January 14, 1998
           'langSPDL': 18 - ISO 10180 Standard Page Description Language ISO
              Standard
         'TEK4014':
           'langTEK4014': 19 - Tektronix Corp.

                       June 23, 1997, Expires December 23, 1997
         'PDS':
           'langPDS': 20 -
         'IGP':
           'langIGP': 21 - Printronix Corp.
         'CodeV':
           'langCodeV': 22 - Magnum Code-V, Image and printer control language
              used to control impact/dot- matrix printers.  QMS, Inc., Mobile
              AL
         'DSCDSE':
           'langDSCDSE': 23 - DSC-DSE: Data Stream Compatible and Emulation Bi-
            directional
              Bi-directional print data stream for non-SNA (DSC) and SNA LU-3
              3270 controller (DSE) communications IBM
         'WPS':
           'langWPS': 24 - Windows Printing System, Resource based
              command/data stream used by Microsoft At Work Peripherals.
              Developed by the Microsoft Corporation.
         'LN03':
           'langLN03': 25 - Early DEC-PPL3, Digital Equipment Corp.
         'CCITT':
           'langCCITT': 26 -
         'QUIC':
           'langQUIC': 27 - QUIC (Quality Information Code), Page Description
              Language for laser printers.  Included graphics, printer control
              capability and emulation of other well- known printer .  QMS,
              Inc.
         'CPAP':
           'langCPAP': 28 - Common Printer Access Protocol Digital Equipment
              Corp
         'DecPPL':
           'langDecPPL': 29 - Digital ANSI-Compliant Printing Protocol (DEC-PPL) (DEC-
              PPL) Digital Equipment Corp
         'SimpleText':
           '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
         'NPAP':
           'langNPAP': 31 - Network Printer Alliance Protocol (NPAP).  This
              protocol has been superseded by the IEEE 1284.1 TIPSI standard.
              (ref.  LangTIPSI(49)).
         'DOC':
           'langDOC': 32 - Document Option Commands, Appears in the data
              stream between data intended for a page description .  QMS, Inc
         'imPress':
           'langimPress': 33 - imPRESS, Page description language originally
              developed for the ImageServer line of systems.  A binary language
              providing representations for text, simple graphics (rules,
              lines, conic sections), and some large forms (simple bit-map and
              CCITT group 3/4 encoded).The language was intended to be sent
              over an 8-
            bit 8-bit channel and supported early document preparation
              languages (e.g.  TeX and TROFF).  QMS, Inc.
         'Pinwriter':
           'langPinwriter': 34 - 24 wire dot matrix printer for USA, Europe,
              and Asia except Japan.  More widely used in Germany, and some
              Asian countries than in US.  NEC
         'NPDL':
           'langNPDL': 35 - Page printer for Japanese market.  NEC
         'NEC201PL':
           'langNEC201PL': 36 - Serial printer language used in the Japanese
              market.  NEC
         'Automatic':
           'langAutomatic': 37 - Automatic PDL sensing.  Automatic sensing of
              the interpreter language family by the printer examining the

                                Expires January 14, 1998
              document content.  Which actual interpreter language families are
              sensed depends on the printer implementation.
         'Pages':
           'langPages': 38 - Page printer Advanced Graphic Escape Set IBM
              Japan
         'LIPS':
           'langLIPS': 39 - LBP Image Processing System
         'TIFF':
           'langTIFF': 40 - Tagged Image File Format (Aldus)
         'Diagnostic':
           'langDiagnostic': 41 - A hex dump of the input to the interpreter

                       June 23, 1997, Expires December 23, 1997
         'PSPrinter':
           'langPSPrinter': 42 - The PostScript Language used for control
              (with any PDLs) Adobe Systems Incorporated
         'CaPSL':
           'langCaPSL': 43 - Canon Print Systems Language
         'EXCL':
           'langEXCL': 44 - Extended Command Language Talaris Systems Inc
         'LCDS':
           'langLCDS': 45 - Line Conditioned Data Stream Xerox Corporatio
         'XES':
           'langXES': 46 - Xerox Escape Sequences Xerox Corporation
         'PCLXL':
           'langPCLXL': 47 - Printer Control Language.  Extended language
              features for printing, and printer control.  Technical reference
              manual # TBD.  Hewlett-Packard Co.
         'ART':
           'langART': 48 - Advanced Rendering Tools (ART).  Page Description
              language originally developed for the Laser Press printers.
              Tehnical reference manual: "ART IV Reference Manual", No F33M.
              Fuji Xerox Co., Ltd.
         'TIPSI':
           'langTIPSI': 49 - Transport Independent Printer System Interface
              (ref.  IEEE Std.  1284.1)
         'Prescribe':
           'langPrescribe': 50 - Page description and printer control
              language.  It can be described with ordinary ASCII characters.
              Technical reference manual: "PRESCRIBE II Programming Manual"
         'LinePrinter':
           'langLinePrinter': 51 - A simple-text character stream which
              supports the control codes LF, VT, FF and CR plus Centronics or
              Dataproducts Vertical Format Unit (VFU).  language is commonly
              used on many older model line and matrix printers.
         'IDP':
           'langIDP': 52 - Imaging Device Protocol Apple Computer.
         'XJCL':
           'langXJCL': 53 - Xerox Corp.

         One special value is 'auto-sense'. 'langAutomatic (37)'.  However a client SHALL NOT
         supply the value 'auto-sense' 'langAutomatic' in a create request.  If the
         "document-format" is unknown for a certain document, the client SHALL
         NOT supply the attribute in the create request or the Send-Document
         Request.

       14.

         13. APPENDIX C - D:  "media" Values keyword values

         Standard keyword values are taken from several sources.

         Standard values are defined(taken defined (taken from ISO DPA DPA[5] and the Printer MIB):
         MIB[1]):

           'default': The default medium for the output device

                                Expires January 14, 1998
           'iso-a4-white': Specifies the ISO A4 white medium
           'iso-a4-colored': Specifies the ISO A4 coloured medium
           'iso-a4-transparent' Specifies the ISO A4 transparent medium
           'iso-a3-white': Specifies the ISO A3 white medium
           'iso-a3-colored': Specifies the ISO A3 coloured medium
           'iso-a5-white': Specifies the ISO A5 white medium
           'iso-a5-colored': Specifies the ISO A5 coloured medium
           'iso-b4-white': Specifies the ISO B4 white medium
           'iso-b4-colored': Specifies the ISO B4 coloured medium

                       June 23, 1997, Expires December 23, 1997
           'iso-b5-white': Specifies the ISO B5 white medium
           'iso-b5-colored': Specifies the ISO B5 coloured medium
           'jis-b4-white': Specifies the JIS B4 white medium
           'jis-b4-colored': Specifies the JIS B4 coloured medium
           'jis-b5-white': Specifies the JIS B5 white medium
           'jis-b5-colored': Specifies the JIS B5 coloured medium

         The following standard values are defined for North American media:

           'na-letter-white': Specifies the North American letter white medium
           'na-letter-colored': Specifies the 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 following standard values are defined for envelopes:

           'iso-b4-envelope': Specifies the ISO B4 envelope medium
           'iso-b5-envelope': Specifies the ISO B5 envelope medium
           'iso-c3-envelope': Specifies the ISO C3 envelope medium
           'iso-c4-envelope': Specifies the ISO C4 envelope medium
           'iso-c5-envelope': Specifies the ISO C5 envelope medium
           'iso-c6-envelope': Specifies the ISO C6 envelope medium
           'iso-designated-long-envelope': Specifies the ISO Designated Long
              envelope medium
           'na-10x13-envelope': Specifies the North American 10x13 envelope
              medium
           'na-9x12-envelope': Specifies the North American 9x12 envelope
              medium
           'monarch-envelope': Specifies the Monarch envelope
           'na-number-10-envelope': Specifies the North American number 10
              business envelope medium
           'na-7x9-envelope': Specifies the North American 7x9 inch envelope
           'na-9x11-envelope': Specifies the North American 9x11 inch envelope

                                Expires January 14, 1998
           'na-10x14-envelope': Specifies the North American 10x14 inch
              envelope
           'na-number-9-envelope': Specifies the North American number 9
              business envelope
           'na-6x9-envelope': Specifies the North American 6x9 inch envelope
           'na-10x15-envelope': Specifies the North American 10x15 inch
              envelope

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

                       June 23, 1997, Expires December 23, 1997

           'executive-white': Specifies the white executive medium
           'folio-white': Specifies the folio white medium
           'invoice-white': Specifies the white invoice medium
           'ledger-white': Specifies the white ledger medium
           'quarto-white': Specified the white quarto medium
           'iso-a0-white': Specifies the ISO A0 white medium
           'iso-a1-white': Specifies the ISO A1 white medium
           'iso-a2-white': Specifies the ISO A2 white medium
           'iso-a6-white': Specifies the ISO A6 white medium
           'iso-a7-white': Specifies the ISO A7 white medium
           'iso-a8-white': Specifies the ISO A8 white medium
           'iso-a9-white': Specifies the ISO A9 white medium
           'iso-10-white': Specifies the ISO A10 white medium
           'iso-b0-white': Specifies the ISO B0 white medium
           'iso-b1-white': Specifies the ISO B1 white medium
           'iso-b2-white': Specifies the ISO B2 white medium
           'iso-b3-white': Specifies the ISO B3 white medium
           'iso-b6-white': Specifies the ISO B6 white medium
           'iso-b7-white': Specifies the ISO B7 white medium
           'iso-b8-white': Specifies the ISO B8 white medium
           'iso-b9-white': Specifies the ISO B9 white medium
           'iso-b10-white': Specifies the ISO B10 white medium
           'jis-b0-white': Specifies the JIS B0 white medium
           'jis-b1-white': Specifies the JIS B1 white medium
           'jis-b2-white': Specifies the JIS B2 white medium
           'jis-b3-white': Specifies the JIS B3 white medium
           'jis-b6-white': Specifies the JIS B6 white medium
           'jis-b7-white': Specifies the JIS B7 white medium
           'jis-b8-white': Specifies the JIS B8 white medium
           'jis-b9-white': Specifies the JIS B9 white medium
           'jis-b10-white': Specifies the JIS B10 white medium

         The following standard values are defined for engineering media:

           'a': Specifies the engineering A size medium

                                Expires January 14, 1998
           'b': Specifies the engineering B size medium
           'c': Specifies the engineering C size medium
           'd': Specifies the engineering D size medium
           'e': Specifies the engineering E size medium

         The following standard values are defined for input-trays (from ISO
         DPA and the Printer MIB):

           'top': The top input tray in the printer.
           'middle': The middle input tray in the printer.
           'bottom': The bottom input tray in the printer.

                       June 23, 1997, Expires December 23, 1997
           'envelope': The envelope input tray in the printer.
           'manual': The manual feed input tray in the printer.
           'large-capacity': The large capacity input tray in the printer.
           'main': The main input tray
           'side': The side input tray

         The following standard values are defined for media sizes (from ISO
         DPA):

           'iso-a0': Specifies the ISO A0 size: 841 mm by 1189 mm as defined
              in ISO 216
           'iso-a1': Specifies the ISO A1 size: 594 mm by 841 mm as defined in
              ISO 216
           'iso-a2': Specifies the ISO A2 size: 420 mm by 594 mm as defined in
              ISO 216
           'iso-a3': Specifies the ISO A3 size: 297 mm by 420 mm as defined in
              ISO 216
           'iso-a4': Specifies the ISO A4 size: 210 mm by 297 mm as defined in
              ISO 216
           'iso-a5': Specifies the ISO A5 size: 148 mm by 210 mm as defined in
              ISO 216
           'iso-a6': Specifies the ISO A6 size: 105 mm by 148 mm as defined in
              ISO 216
           'iso-a7': Specifies the ISO A7 size: 74 mm by 105 mm as defined in
              ISO 216
           'iso-a8': Specifies the ISO A8 size: 52 mm by 74 mm as defined in
              ISO 216
           'iso-a9': Specifies the ISO A9 size: 37 mm by 52 mm as defined in
              ISO 216
           'iso-a10': Specifies the ISO A10 size: 26 mm by 37 mm as defined in
              ISO 216
           'iso-b0': Specifies the ISO B0 size: 1000 mm by 1414 mm as defined
              in ISO 216
           'iso-b1': Specifies the ISO B1 size: 707 mm by 1000 mm as defined
              in ISO 216

                                Expires January 14, 1998
           'iso-b2': Specifies the ISO B2 size: 500 mm by 707 mm as defined in
              ISO 216
           'iso-b3': Specifies the ISO B3 size: 353 mm by 500 mm as defined in
              ISO 216
           'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in
              ISO 216
           'iso-b5': Specifies the ISO B5 size: 176 mm by 250 mm as defined in
              ISO 216
           'iso-b6': Specifies the ISO B6 size: 125 mm by 176 mm as defined in
              ISO 216
           'iso-b7': Specifies the ISO B7 size: 88 mm by 125 mm as defined in
              ISO 216

                       June 23, 1997, Expires December 23, 1997
           'iso-b8': Specifies the ISO B8 size: 62 mm by 88 mm as defined in
              ISO 216
           'iso-b9': Specifies the ISO B9 size: 44 mm by 62 mm as defined in
              ISO 216
           'iso-b10': Specifies the ISO B10 size: 31 mm by 44 mm as defined in
              ISO 216
           'na-letter': Specifies the North American letter size: 8.5 inches
              by 11 inches
           'na-legal': Specifies the North American legal size: 8.5 inches by
              14 inches
           'executive': Specifies the executive size (7.25 X 10.5 in)
           'folio': Specifies the folio size (8.5 X 13 in)
           'invoice': Specifies the invoice size (5.5 X 8.5 in)
           'ledger': Specifies the ledger size (11 X 17 in)
           'quarto': Specifies the quarto size (8.5 X 10.83 in)
           'iso-c3': Specifies the ISO C3 size: 324 mm by 458 mm as defined in
              ISO 269
           'iso-c4': Specifies the ISO C4 size: 229 mm by 324 mm as defined in
              ISO 269
           'iso-c5': Specifies the ISO C5 size: 162 mm by 229 mm as defined in
              ISO 269
           'iso-c6': Specifies the ISO C6 size: 114 mm by 162 mm as defined in
              ISO 269
           'iso-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

                                Expires January 14, 1998
           '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
           '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 515mm
           'jis-b4': Specifies the JIS B4 size: 257mm x 364mm

                       June 23, 1997, Expires December 23, 1997
           'jis-b5': Specifies the JIS B5 size: 182mm x 257mm
           'jis-b6': Specifies the JIS B6 size: 128mm x 182mm
           'jis-b7': Specifies the JIS B7 size: 91mm x 128mm
           'jis-b8': Specifies the JIS B8 size: 64mm x 91mm
           'jis-b9': Specifies the JIS B9 size: 45mm x 64mm
           'jis-b10': Specifies the JIS B10 size: 32mm x 45mm

                       June 23, 1997,

                                Expires December 23, 1997 January 14, 1998