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 3, 23, 1997

                 Internet Printing Protocol/1.0: Model and Semantics
                             draft-ietf-ipp-model-01.txt
                             draft-ietf-ipp-model-02.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 3, 23, 1997, Expires December 3, 23, 1997
         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 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 3, 23, 1997, Expires December 3, 23, 1997
                                  Table of Contents

       1. 6
       Introduction..........................................................7 Introduction.......................................................7
       2. Terminology........................................................7
          2.1  Conformance Terminology........................................8 Terminology ......................................8
             2.1.1 MUST......................................................8
             2.1.2 MUST NOT..................................................8
             2.1.3 SHOULD....................................................8
             2.1.4 SHOULD NOT................................................8
             2.1.5 MAY.......................................................8
             2.1.6 CONDITIONALLY MANDATORY...................................8 MANDATORY...................................9
             2.1.7 NEED NOT..................................................9
          2.2  Model Terminology..............................................9 Terminology ...........................................10
             2.2.1 Keyword...................................................9 Keyword..................................................10
             2.2.2 Attributes................................................9 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 Name............................................9
             2.2.4 Group Name................................................9
             2.2.5 Name ..............................11
                2.2.3.3  Attribute Value..........................................10
             2.2.6 Value ...................................11
                2.2.3.4  Attribute Syntax.........................................10
             2.2.7 Implements...............................................10
             2.2.8 Supports.................................................10 Syntax ..................................11
             2.2.4 Supports.................................................12
       3. Simplified Printing Model.........................................11 Model.........................................12
       4. IPP Objects.......................................................13 Objects.......................................................15
          4.1  Printer Object................................................13 Object ..............................................15
          4.2  Job Object....................................................15 Object ..................................................17
          4.3  Document Object...............................................16 Object .............................................18
          4.4  Object Relationships..........................................17 Relationships ........................................19
          4.5  Object Attributes.............................................17 Attributes ...........................................19
             4.5.1 Job Template Attribute Overview..........................17 Overview..........................19
             4.5.2 The "best-effort" Job Attribute Overview.................18 Overview.................20
          4.6  Object Identity...............................................19 Identity .............................................20
       5. IPP Operations....................................................19 Operations....................................................21
          5.1  Operation Semantics...........................................20 Semantics .........................................22
             5.1.1 Print-Job Operation......................................20 Get-Operations Operation.................................22
                5.1.1.1 Print-Job Request...................................20  Get-Operations Request ............................23
                5.1.1.2 Print-Job Response..................................22  Get-Operations Response ...........................23
             5.1.2 Create-Job Operation.....................................23 Print-Job Operation......................................23
                5.1.2.1 Create-Job Request..................................23  Print-Job Request .................................23
                5.1.2.2 Create Job Response.................................24  Print-Job Response ................................25
             5.1.3 Send-Document Operation..................................25 Print-URI Operation......................................26
                5.1.3.1 Send-Document Request...............................25  Print-URI Request .................................26
                5.1.3.2 Send-Document Response..............................25  Print-URI Response ................................26
             5.1.4 Cancel Job Operation.....................................26 Validate-Job Operation...................................27
                5.1.4.1 Cancel-Job Request..................................26  Validate-Job Request ..............................27
                5.1.4.2 Cancel-Job Response.................................26
             5.1.5 Get-Attributes Operation.................................26
                5.1.5.1 Get-Attributes Request..............................27  Validate-Job Response .............................27

                       June 3, 23, 1997, Expires December 3, 23, 1997
             5.1.5 Create-Job Operation.....................................28
                5.1.5.1  Create-Job Request ................................28
                5.1.5.2 Get-Attributes Response.............................28  Create Job Response ...............................28
             5.1.6 Get-Jobs Operation.......................................29 Send-Document Operation..................................29
                5.1.6.1 Get-Jobs Request....................................29  Send-Document Request .............................29
                5.1.6.2  Send-Document Response ............................29
             5.1.7 Send-URI Operation.......................................30
                5.1.7.1  Send-URI Request ..................................30
                5.1.7.2  Send-URI Response .................................30
             5.1.8 Cancel Job Operation.....................................30
                5.1.8.1  Cancel-Job Request ................................31
                5.1.8.2  Cancel-Job Response ...............................31
             5.1.9 Get-Attributes Operation.................................31
                5.1.9.1  Get-Attributes Request ............................31
                5.1.9.2  Get-Attributes Response ...........................33
             5.1.10 Get-Jobs Response...................................30 Operation .....................................34
                5.1.10.1 Get-Jobs Request ..................................34
                5.1.10.2 Get-Jobs Response .................................34
          5.2  Operation Status and Messages.................................31
          5.3 Status Codes (type2 keyword)..................................31 and Messages .........................35
       6. Object Attributes.................................................31 Attributes.................................................35
          6.1  Attribute Syntaxes............................................32 Syntaxes ..........................................36
             6.1.1 Attribute Extensibility..................................35 Extensibility..................................37
          6.2  Job Template Attributes.......................................36 Attributes .....................................38
             6.2.1 job-name (name)..........................................41 (name)..........................................42
             6.2.2 job-sheets (type4 keyword)...............................42 keyword)...............................43
             6.2.3 notification-events notify-events (1setOf type2 keyword)...............42 keyword).....................43
             6.2.4 notification-addresses notify-addresses (1setOf uri)......................42 uri)............................43
             6.2.5 job-priority (integer(1:100))............................43 (integer(1:100))............................44
             6.2.6 job-hold-until (type4 keyword)...........................43 keyword)...........................44
             6.2.7 multiple-documents-are (type2 keyword)...................44 keyword)...................45
             6.2.8 best-effort (type2 keyword)..............................44 keyword)..............................45
             6.2.9 media (type4 keyword)....................................45 keyword)....................................47
             6.2.10 number-up (type3 keyword)...............................46 keyword) ..............................47
             6.2.11 sides (type2 keyword)...................................46 keyword) ..................................48
             6.2.12 printer-resolution (type2 keyword)......................47 keyword) .....................48
             6.2.13 print-quality (type2 keyword)...........................47 keyword) ..........................49
             6.2.14 copies (integer(1:2**31 - 1))...........................48 1)) ..........................49
             6.2.15 finishings finishing (1setOf type2 keyword).......................48 keyword) .......................49
             6.2.16 document-format (type2 keyword) ........................50
             6.2.17 compression (type3 keyword).............................48
             6.2.17 keyword) ............................50
             6.2.18 job-k-octets (integer(0:2**31 - 1)).....................48
             6.2.18 1)) ....................50
             6.2.19 job-impressions (integer(0:2**31 - 1))..................49
             6.2.19 1)) .................50
             6.2.20 job- media-sheets (integer(0:2**31 - 1))................49 1)) ...............51
          6.3  Job Attributes................................................49 Description Attributes ..................................51
             6.3.1 Job Template Attributes..................................49 job-uri (uri)............................................52
             6.3.2 Job Description Attributes...............................49
                6.3.2.1 job-URI (uri).......................................51
                6.3.2.2 job-uri-user (uri).......................................53
             6.3.3 job-originating-user (name).........................51
                6.3.2.3 (name)..............................53
             6.3.4 job-originating-host (name).........................51
                6.3.2.4 (name)..............................53

                       June 23, 1997, Expires December 23, 1997
             6.3.5 user-locale (type3 keyword).........................51
                6.3.2.5 keyword)..............................53
             6.3.6 job-state (type1 keyword)...........................51
                6.3.2.6 keyword)................................53
             6.3.7 job-state-reasons (1setOf  type2 keyword)...........55
                6.3.2.7 keyword)................53
             6.3.8 job-state-message (text)............................58
                6.3.2.8 (text).................................53
             6.3.9 output-device-assigned (uri)........................58
                6.3.2.9 time-since-submission (milliseconds)................58
                6.3.2.10 (name)............................53
             6.3.10 time-since-pending (milliseconds) ......................54
             6.3.11 time-since-processing (milliseconds)...............58
                6.3.2.11 (milliseconds) ...................54
             6.3.12 time-since-completed (milliseconds) ....................54
             6.3.13 number-of-intervening-jobs (integer(0:2**31 - 1))..58
                6.3.2.12 1)) ......54
             6.3.14 job-message-from-operator (text)...................59
                6.3.2.13 time-since-completion (milliseconds)...............59
                6.3.2.14 (text) .......................54
             6.3.15 job-k-octets-completed (integer(0:2**31 - 1))......59
                6.3.2.15 1)) ..........54
             6.3.16 job-impressions-completed  (integer(0:2**31 - 1))..59
                6.3.2.16 1)) ......55
             6.3.17 job-media-sheets-completed (integer(0:2**31 - 1))..59

                        June 3, 1997, Expires December 3, 1997 1)) ......55
          6.4  Document Attributes...........................................59 Attributes .........................................55
             6.4.1 document-name(name, Mandatory)...........................60 document-name (name).....................................55
             6.4.2 document-format (type2 keyword)..........................60 keyword)..........................55
             6.4.3 document-URI (uri).......................................61 document-uri (uri).......................................56
          6.5  Printer Attributes............................................61 Description Attributes ..............................56
             6.5.1 Printer Job Template Attributes..........................61 printer-uri (uri)........................................57
             6.5.2 Printer Description  Attributes..........................61
                6.5.2.1 printer-URI (uri)...................................63
                6.5.2.2 printer-uri-user (uri)...................................58
             6.5.3 printer-name (name).................................63
                6.5.2.3 (name)......................................58
             6.5.4 printer-location (text).............................63
                6.5.2.4 (text)..................................58
             6.5.5 printer-description (text)..........................63
                6.5.2.5 (text)...............................58
             6.5.6 printer-more-info-site (uri)........................64
                6.5.2.6 (uri).............................58
             6.5.7 printer-driver-installer (uri)......................64
                6.5.2.7 (uri)...........................58
             6.5.8 printer-make-and-model (text).......................64
                6.5.2.8 maximum-printer-speed (integerUnits)................64
                6.5.2.9 printer-more-info-manf (uri)........................64
                6.5.2.10 (text)............................58
             6.5.9 printer-more-info-manufacturer (uri).....................59
             6.5.10 printer-state (type1 keyword)......................65
                6.5.2.11 keyword) ..........................59
             6.5.11 printer-state-reasons (1setOf type2 keyword).......67
                6.5.2.12 keyword) ...........60
             6.5.12 printer-is-accepting-jobs (boolean)................69
                6.5.2.13 (boolean) ....................62
             6.5.13 printer-state-message (text).......................69
                6.5.2.14 (text) ...........................62
             6.5.14 queued-job-count (integer(0:2**31 - 1))............70
                6.5.2.15 1)) ................62
             6.5.15 printer-message-from-the-operator (text)...........70
                6.5.2.16 (text) ...............62
             6.5.16 printer-locale (locale)............................70
                6.5.2.17 (locale) ................................62
             6.5.17 printer-locales-supported (1setOf locale)..........70 locale) ..............62
             6.5.18 color-supported (boolean) ..............................62
       7. Conformance.......................................................70 Conformance.......................................................63
          7.1  Conditionally Mandatory.......................................70 Mandatory .....................................63
          7.2  Client Conformance Requirements...............................71 Requirements .............................63
          7.3  Printer Object Conformance Requirements.......................71 Requirements .....................63
             7.3.1 Objects..................................................71 Objects..................................................64
             7.3.2 Operations...............................................71 Operations...............................................64
             7.3.3 Attributes...............................................72 Attributes...............................................64
             7.3.4 Default Value............................................72
             7.3.5 Availability.............................................73
             7.3.6 Printer extensions.......................................73
             7.3.7 extensions.......................................65
             7.3.5 Attribute Syntaxes.......................................73 Syntaxes.......................................65
          7.4  Security Conformance Requirements.............................73 Requirements ...........................65
       8. IANA Considerations, Registered Extensions, Private Extensions....73 Extensions....66
       9. Security Considerations...........................................74
       10. References.......................................................74
       11. Author's Address.................................................75
       12.77
       Change History.......................................................78 Considerations...........................................66

                       June 23, 1997, Expires December 23, 1997
       10.References .......................................................66
       11.Author's Address .................................................67
       12.APPENDIX A - Status Codes ........................................70
          12.1 Changes made to version 970512, dated 12-May-1997 to make
          version 970603, dated  03-June-1997...............................78 Status Codes (type2 keyword) ................................70
             12.1.1 Informational ..........................................71
             12.1.2 Successful Status Codes ................................71
                12.1.2.1 successful-OK (IPPL1) .............................71
             12.1.3 Redirection Status Codes ...............................71
             12.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 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 Changes made to version 970509, dated 9-May-1997 Mapping of HTTP 1.1 Status Codes to make version
          970512, dated 12-May-1997.........................................78 IPP Status Keywords .....76
          12.3 Changes made to version 2.2, dated 5-May-1997 to make version
          970509, dated 9-May-1997..........................................79 Status Keywords for IPP Operations ..........................77
       13.APPENDIX B - "document-format" Values ............................77
       14.APPENDIX C - "media" Values ......................................80

                       June 3, 23, 1997, Expires December 3, 23, 1997
          12.4 Changes made to version 2.1, dated 24-April-1997 to make version
          2.2, dated 5-May-1997.............................................79
          12.5 Changes made to version 2.0, dated 26-March-1997 to make version
          2.1, dated 22-April-1997..........................................79
          12.6 Changes made to version 1.8, dated 24-March-1997 to make version
          2.0, dated 26-March-1997..........................................79
          12.7 Changes made to version 1.7, dated 24-Mar-1997 to make version
          1.8, dated 24-March-1997..........................................79
          12.8 Changes made to version 1.6, dated 12-Mar-1997 to make version
          1.7, dated 24-March-1997..........................................80
          12.9 Changes made to version 1.5, dated 11-Mar-1997 to make version
          1.6, dated 12-March-1997..........................................80
          12.10 Changes made to version 1.4, dated 27-Feb-1997 to make version
          1.5, dated 9-March-1997...........................................82
       1.

                        June 3, 1997, Expires December 3, 1997 Introduction

       The Internet Printing Protocol (IPP) is an application level protocol
       that can be used for distributed printing on the Internet.  The protocol
       is heavily influenced by the printing model introduced in the Document
       Printing Application (ISO/IEC 10175 DPA) standard.  Although DPA
       identifies both end user and administrative features, the first version
       of IPP is focused only on end user functionality.

       Section 2.  Terminology 2 introduces the terminology used within this document.

       Section 0 3 introduces the simplified IPP model.  The IPP model is made
       simple by exposing only the objects, attributes, and operations that are
       essential for end user access and control of the print subsystem. system.  When
       future versions of IPP include features which satisfy operator and
       administrator requirements, the model can be extended to support the
       appropriate objects, attributes, and operations.

       Section 0 4 introduces the full semantics of the Printer, Job, and
       Document objects in the IPP model.  It covers how instances of these
       objects are identified, named, and related to each other.

       Section 0 5 covers the operations that are part of the IPP model.  These
       operations include: the Create-Job, Send-Document, Print-Job, Cancel,
       Get-Attributes, and Get-Jobs operations.

       Section 0 6 describes the attributes, their syntaxes, and semantics which
       are part of the IPP model.  Each object's attributes are described, and
       the attributes are grouped into logical groups to help clarify their
       relationships and meaning.  These groups are also used to simplify
       queries that request multiple attributes.

       Section 7.  Conformance 7 is a review of conformance issues and clarifies requirements
       that apply to client side and server side implementations.

       Sections 8. IANA Considerations, Registered Extensions, Private
       Extensions-11. Author's Address 8-11 cover extensibility, security, technical references, and
       author information.

       2. Terminology

       This specification uses the terminology defined in this section.

                       June 3, 23, 1997, Expires December 3, 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 to be interpreted as described in RFC 2119 [25].

       2.1.1 MUST

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

       ISSUE: There are too many "SHALLs" in the document right now.  Carl-Uno
       makes the comment: "I think we have gone overboard in the use 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 be cleaned up.    Also, many of our conformance requirements 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, or the phrase "SHALL NOT", mean that 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 the full implications must be understood and carefully weighed
       before choosing a different course.

       2.1.4 SHOULD NOT

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

       2.1.5 MAY

       This word, or the adjective "OPTIONAL", mean 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

                       June 23, 1997, Expires December 23, 1997
       the option, though perhaps with reduced functionality. In the same vein
       an implementation which does include a particular option MUST be
       prepared to interoperate with another implementation which does not
       include the option (except, of course, for the feature the option
       provides.)

       2.1.6 CONDITIONALLY MANDATORY

                        June 3, 1997, Expires December 3, 1997

       This term means that an item MUST be implemented in a conforming
       implementation if the item corresponds to a feature or behavior that the
       implementation is capable of realizing.  It is also true, that a
       conforming implementation NEED NOT is not required to implement the items that
       correspond to features or behaviors that the implmentation implementation is not
       capable of realizing.

       ISSUE:  Should we use the following definition and define an explicit
       condition for each attribute labeled as CONDITIONALLY MANDATORY?

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

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

       2.2  Model Terminology

       2.2.1     Keyword

       Keywords are used within this

       ISSUE:  Occasionally in the document as identifiers of semantic
       entities within the abstract model.  These entities are often attribute
       names, attribute values, attribute syntaxes, terms MANDATORY and attribute groups. In
       this document, OPTIONAL
       get used for what a keyword is requester shall supply in a sequence of characters (length of 1 request or what a
       provider shall return in a response.  I think that it is confusing to
       255) which consists of
       say that such and such input parameter is OPTIONAL meaning that the
       requester NEED NOT supply it in a request because it sounds like we are
       saying that the requester NEED not implement the input parameter and
       that the provide need not support the input parameter.  Same for
       responses.  Instead of labeling input parameters and output parameters
       as MANDATORY and OPTIONAL, just say something like "the requester SHALL
       supply the xxx input-parameter in the yyy operation"  or "the requester
       MAY supply 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)" and "(MAY
       be omitted)"?  In the description of each parameter we need to also
       specify whether support 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 of semantic
       entities within the abstract model.  Attribute names, attribute values,
       attribute syntaxes, and attribute groups 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, digits, hyphen ("-"), and underscore ("_").  A keyword MUST
       start with 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     Attributes

       An attribute Parameters

       A parameter is an item of information supplied in an operation
       consisting of an attribute a parameter name and attribute parameter value(s) using a specific
       syntax for that attribute. parameter.  Clients supply input parameters in an
       operation request and Printers return output parameters in an operation
       response.  Most parameters have corresponding object attributes, some do
       not.  All
       attributes parameters are defined in section 6.    Object Attributes.  Attributes
       are 5.  Parameterare identified
       as being "MANDATORY", "CONDITIONALLY MANDATORY", or
       "OPTIONAL".

       2.2.3     Attribute "OPTIONAL" for
       implementation and "SHALL be supplied" or "MAY be omitted" in operation
       requests and responses.

       2.2.2.1 Parameter Name

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

       2.2.4     Group Name

       Related attributes

       2.2.2.2 Parameter Value

       Each parameter has one or more values.  Parameter values are grouped into named groups.  The name of the group
       is a keyword.  It can be used wherever an attribute name is used in

                        June 3, 1997, Expires December 3, 1997
       place of naming all the attributes in the group explicitly.  Attribute
       groups are defined in section 6.   Object Attributes.

       2.2.5     Attribute Value

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

       2.2.6     Attribute

       2.2.2.3 Parameter Syntax

       Each attribute 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] shall indicate indicates the actual representation
       for each parameter syntax type that shall SHALL be used for the actual protocol.  Attribute

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

       2.2.7     Implements

       By definition, an 6.1.

       2.2.3 Attributes

       An attribute is implemented if, in response to a query
       for that attribute, an implementation responds item of information that is associated with both the an object
       instance consisting of an attribute name and attribute value(s) using a current value (or values)
       specific syntax for that attribute. . A conforming
       implementation SHALL implement all MANDATORY attributes and it SHALL
       implement all CONDITIONALLY MANDATORY attributes whose possible values
       correspond to requester sets an attribute by
       supplying an input parameter in an operation request which has the behaviors that same
       syntax as the implementation is capable of
       realizing.

       2.2.8     Supports

       By definition, a job processing behavior or selectable feature is
       supported attribute.  A provider returns an attribute by Printer only if that Printer implements supplying
       an output parameter in an operation response which has the corresponding
       "supported" attribute populated with same syntax
       as the value representing attribute.  The attributes that
       behavior or feature.  A given implementation may exhibit can be set by a behavior client have a
       corresponding representation as an input parameter.  The attributes that
       corresponds to the value of some supported 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
       can be queires by a client have a corresonding representation as IPP is concerned, that Printer does not  support that feature.
       Section an
       output parameter.   All attributes are defined in section 6.  Object  Attributes describes all of the Printer object's
       supported attributes.  Most of the Printer object's supported attributes
       are OPTIONAL identified as being "MANDATORY", "CONDITIONALLY MANDATORY", or CONDITIONALLY MANDATORY, therefore conformance to IPP
       does not mandate that all implementations support all possible value
       representing all possible job processing behaviors and features.

                        June 3, 1997, Expires December 3, 1997
       For example, if a given instance of a Printer supports only certain
       document formats, then that Printer SHALL implement the "document-
       format-supported" attribute and that
       "OPTIONAL".

       2.2.3.1 Attribute Name

       Each attribute SHALL be populated with a
       set of values, possibly only one, taken from the entire set of possible
       values defined is uniquely identified in this model document.  This implemented set of values
       represent the Printer's set of supported document formats.  Another
       example by its attribute
       name which is the "finishings-supported" attribute.  If a Printer is not
       physically capable of stapling (there keyword.  The keyword attribute name is no stapler given in the output device
       itself), the "finishings-supported"
       section header describing that attribute.  In running text in this
       document, attribute MUST NOT 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 be implemented
       with used as the value of 'staple'.  Note: The supported attributes are set
       (populated) by some administrative process an input
       parameter in place of naming all the attributes in the group explicitly.
       Attribute groups are defined in section 6.

       2.2.3.3 Attribute Value

       Each attribute has one or automatic sensing
       mechanism which is outside more values.  Attribute values are represented
       in the scope of IPP.

       3.   Simplified Printing Model syntax type specified for that attribute. In order to a achieve its goal of realizing running text in this
       document, attribute values 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 a workable printing keyword with specific
       meaning.  The protocol specification document [23] indicates the actual
       representation for each attribute syntax that SHALL be used for the Internet, IPP
       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 is based on
       supported by a simplified printing model which
       abstracts Printer only if that Printer responds with the many (often complex) components of real world printing
       solutions.  Many of these systems include features, interfaces,
       corresponding attribute and
       relationships that are beyond the scope of IPP.  IPP has to run associated value in a
       distributed computing environment where requesters of print services
       (clients, applications, PC drivers, etc.) cooperate and interact with
       print service providers.  Although the underlying configuration response to a
       query for that attribute. A given implementation may be exhibit a
       complex n-tier client/server system, an important simplifying step in
       the IPP model is behavior
       that corresponds to expose only the key objects and interfaces required value of some supported attribute, but if the
       implementation, when queried for printing.  The that attribute, doesn't respond with
       the supported attribute populated with that specific value, then as far
       as IPP model encapsulates these important elements into
       three simple objects: is concerned, that Printer (Section 0)
         Job (Section 0)
         Document (Section 0)

       Each does not support that feature. A
       conforming implementation SHALL support all MANDATORY attributes and all
       CONDITIONALLY MANDATORY attributes whose possible values correspond to
       the behaviors that the implementation is capable of these objects has realizing. Therefore
       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 set given instance of operations associated with it.  These
       include:

         Printer:
            Create-Job (Section 0)
            Print-Job (Section ???)
            Get-Attributes (Section 0)
            Get-Jobs (Section 0)
         Job
            Send-Document(section ???)
            Get-Attributes (Section 0)
            Cancel Job (Section 0)

                        June 3, 1997, Expires December 3, 1997
       There are no operations defined for a Document object.  All Printer supports only certain
       document
       information is accessed through a Job object and its operations.

       It is important, however, to understand formats, then that Printer SHALL respond 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 real system
       implementations (which lie underneath this
       model document.  This set of values represent the abstracted IPP model), there
       are other components Printer's set of
       supported document formats.  Another example is the "finishings-
       supported" attribute.  If a print service which are Printer is not explicitly defined physically capable of
       stapling (there is no stapler in the IPP model. The following figure illustrates where IPP fits with
       respect to these other components.

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

       IPP Printers encapsulate the functions normally associated with physical output devices along with the spooling, scheduling and multiple device
       management functions associated with a print server. Printers may itself), the
       "finishings-supported" attribute MUST NOT be
       registered as entries in a directory where end users find and select
       them based on some sort populated with the value of filtered and context based searching.
       'staple'.

       Note: The
       directory supported attributes are set (populated) by some
       administrative process or automatic sensing mechanism which is used to store relatively static information about outside
       the

                        June 3, 1997, Expires December 3, 1997
       Printer, allowing end users scope of IPP.

       3. Simplified Printing Model

       In order to search a achieve its goal of realizing a workable printing protocol
       for and find Printers that match
       their search criteria (name, context, printer capabilities, etc.)

       IPP clients implement the Internet, IPP protocol is based on a simplified printing model which
       abstracts the client side and give end
       users or programs the ability to query an IPP Printer and submit and
       manage their print jobs.  An IPP server is just that part many (often complex) components of the IPP
       Printer real world printing
       solutions.  Many of these systems include features, interfaces, and
       relationships that implements are beyond the protocol.  The rest scope of the IPP.  IPP Printer
       implements the application semantics has to run in a
       distributed computing environment where requesters of the print services
       (clients, applications, PC drivers, etc.) cooperate and interact with
       print service itself.  All
       information about providers.  Although the Printer, both static and dynamic information, can underlying configuration may be accessed directly from the Printer itself.  The more dynamic
       information associated with a Printer includes state, currently loaded
       and ready media, number of jobs on
       complex n-tier client/server system, an important simplifying step in
       the Printer, errors, warnings, etc..
       When a job IPP model is submitted to expose only the Printer, a Job object is created.  The
       end user then interacts with this new Job to query its status key objects and
       monitor the progress of the job.  End users may also cancel the Job. interfaces required
       for printing.  The end user is able to register to receive certain events which are
       then routed using the notification service(s).

       4.   IPP Objects

       4.1  Printer Object

       A major component of the IPP model is the encapsulates these important elements into
       three simple objects:

                       June 23, 1997, Expires December 23, 1997
         Printer object.

       The capabilities and state (Section 4.1)
         Job (Section 4.2)
         Document (Section 4.3)

       Each of an IPP Printer are described by its
       attributes.  Printer attributes are defined in the following categories:

         Job Template Attributes (section 6.5.1     Printer Job Template
            Attributes)
         Printer Description Attributes (section 6.5.2   Printer Description
            Attributes)

       Operations which are invoked on these objects has a printer set of operations associated with it.  These
       include:

         Create-Job (section 0)

         Printer:
            Get-Operations (Section 5.1.1)
            Print-Job (section ???) (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 0) (Section 5.1.9)
            Get-Jobs (section 0)

       An instance of (Section 5.1.10)
         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 Printer object implements IPP.  Using the protocol, end
       users may query the attributes of the Printer, submit jobs to the
       Printer, determine subsequent states of submitted and queued jobs, and
       cancel their own print jobs. The realization of Document object.  All document
       information is accessed through a Printer Job object may
       take on different forms for any given configuration of and its operations.

       It is important, however, to understand that in real components.
       However, the details of system
       implementations (which lie underneath the configuration of real abstracted IPP model), there
       are other components must be
       transparent to the end user.

                        June 3, 1997, Expires December 3, 1997
       Since a Printer object is an abstraction of a generic document output
       device or print service provider, an which are not explicitly defined
       in the IPP Printer object could be used to
       represent any real or virtual device with semantics consistent model. The following figure illustrates where IPP fits with the
       Printer object. For example, an instance of a Printer object could be
       used
       respect to front end a 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 associated output
            devices
            3a) The associated output devices might or might not be capable of
              spooling jobs
            3b) The associated output devices might or might not support IPP

       See the following figures for some examples on how to view Printer
       objects on top of several print system configurations.  The embedded
       case below represents configurations 1 and 2. The hosted and fan-out
       figures below represent configuration 3. these other components.

                       June 3, 23, 1997, Expires December 3, 23, 1997
       Legend:

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

       any   indicates any network protocol or direct
             connect, including IPP

       embedded printer:
                                                 output device
                                               +---------------+
        O   +--------+
                                    +--------------+
                                    |  ###########  Application |
       /|\
                          o         +. . . . . . . | client |------------IPP------------># Printer #
                         \|/        |   Spooler    |
                         / \  +--------+        +. . . . . . . |  # Object  #   +---------+
                       End-User     | Print Driver |---|  File   |  ###########
             +-----------+ +-----+  +------+-------+   +----+----+
             |
                                               +---------------+

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

                                                +---------------+
       fan out:                |
                   |
                                            +-->| output device          |
                                        any/            |                |
        O   +--------+      ###########   /     +---------------+
       /|\
                   | client |-IPP-># Printer #--*
       / \  +--------+      # Object  #   \     +---------------+
                            ########### any\      +---+------------+---+            |
       N   D   S   |
                                            +-->| output device      |      IPP Client    |------------+
       O   I   E   |      +---------+----------+
       T   R   C   |
                                                +---------------+

       4.2  Job Object

       A Job object is used to model a job.                |
       I   E   U   |
       F   C   R   -------------- Transport ------------------
       I   T   I
       C   O   T                    |         --+
       A job can contain one or more
       documents.  The information required to create   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 multiple device
       management functions associated with a Job object is sent print server. Printers may be
       registered as entries in a
       create request from directory where end users find and select
       them based on some sort of filtered and context based searching.  The
       directory is used to store relatively static information about the
       Printer, allowing end user via an users to search for and find Printers that match
       their search criteria (name, context, printer capabilities, etc.).

       IPP clients implement the IPP protocol on the client to a Printer.  A

                        June 3, 1997, Expires December 3, 1997
       create request can be either a Create-Job Request side and give end
       users or a Print-Job
       Request.  The Printer may perform some validation checks programs the ability to verify query an IPP Printer and submit and
       manage their print jobs.  An IPP server is just that part of the job may indeed be processed.  For example, the create request may
       specify IPP
       Printer that implements the documents within the job are to be printed duplex (on
       both sides protocol.  The rest of the media).  However, the IPP Printer might not support such a
       feature.  Once
       implements the Printer validates application semantics of the submitted information, a Job
       object is created. print service itself.  The instance of
       IPP Printer MAY be embedded in an output device or MAY be embedded in a
       host on the Job object is initialized network that communicates with the output device.  All
       information about the Printer, both static and dynamic information, can

                       June 23, 1997, Expires December 23, 1997
       be accessed directly from the create request.  If Printer itself.  The more dynamic
       information associated with a Create-Job operation Printer includes state, currently loaded
       and ready media, number of jobs on the Printer, errors, warnings, etc.
       When a job is used submitted to create the Printer, the Printer SHALL create a Job
       object.  The end user then interacts with this new Job object, subsequent Send-Document operations are used to transfer query its
       status and monitor the document data from progress of the client job.  End users may also cancel
       the Job.  The end user is able to register to receive certain events
       which are then routed using the notification service(s).

       4. IPP Printer.

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

         - optional attributes are missing
         - there are  conflicts between what Objects

       An IPP object is defined as set of attributes that can be potentially
       supported and what is
            requested
         - there are conflicts between what by each instance of the client requests via external object.  The attributes in the for each
       object type are identified as MANDATORY, CONDITIONALLY MANDATORY, or
       OPTIONAL (see section 2).  Each instance of an IPP operation and what the client requests in
            embedded instructions in object supports an
       appropriate set of attributes (with values for each of the document page description language
            (PDL).

       Job attributes)
       that describe that instance.  That is, an IPP Printer object is defined
       as set of attributes are broken up into the following groups:

         Job Template Attributes (optionally supplied that can potentially be implemented by some entity
       claiming to be an IPP Printer.  In the client/end user,
            section 6.3.1 same manner, a Job Template Attributes object is
       defined as a set of attributes that are potentially associated with each
       instance of a Job Description Attributes (set by object.

       4.1 Printer Object

       A major component of the Printer, section 6.3.2  Job
            Description Attributes)

       The following operations can be IPP model is the Printer object.The
       capabilities and state of an IPP Printer are described 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 Jobs:
         Send-Document(section 5.1.3 Send-Document Operation)
         Cancel Job 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)
         Create-Job (section 0) 5.1.5)
         Get-Attributes (section 0)

       4.3  Document Object

       Documents consist 5.1.9)
         Get-Jobs (section 5.1.10)

       An instance of printable data and attributes that describe a Printer object implements IPP.  Using the
       data to be printed.  In this version protocol, end
       users may query the attributes of the protocol only Printer, submit jobs to the attributes
       in section 6.4 Document Attributes are  defined for individual
       documents.  Documents are sent in a Send-Document operation or in
       Printer, determine subsequent states of submitted and queued jobs, and
       cancel their own print jobs. The realization of a
       Print-Job operation.

       Document attributes include:

         Document Attributes (section 0)

       Currently no operations are defined Printer object may
       take on documents. different forms for any given configuration of real components.

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

       Instances
       However, the details of objects within the system have relationships that must be
       maintained persistently along with the persistent storage configuration of real components are
       transparent to the object
       attributes.  A end user.

       Since a Printer can represent one or more output devices.  An object is an abstraction of a generic document output
       device can be represented by at most one Printer object.  A
       Printer can contain zero or more Job objects.  A Job object is contained
       in exactly one print service provider, an IPP Printer object.  A Job object contains one or more
       Documents.  If the Document is simply a reference to some print data
       stream, the reference may could be used in multiple documents in the same Job to
       represent any real or even in different Jobs.  If virtual device with semantics consistent with the Document is not just a reference, but
       Printer object. For example, an actual stream of print data, it shall only be contained in one
       Document, although there can be copies of it in other Documents.

       4.5  Object Attributes

       Each object type is defined by a set of attributes which describe the
       realization of each instance of an object.  That is, a Printer object is
       defined as set could be
       used to front end a fax-out device, any kind of attributes that are associated with each instance imager, or even a CD
       writer.

       Some examples of configurations supporting a Printer object.  In the same manner, a Job object is defined by defining
       the set of attributes that are associated include:

         1) An output device, with no spooling capabilities
         2) An output device, 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 0 of this document.

       4.5.1     Job Template Attribute Overview

       Attributes that a client may optionally include in a create request are
       called Job Template attributes.  These are described in detail in
       section 0. built-in spooler
         3) A print server supporting IPP with one or more associated output
            devices
            3a) The Printer object has associated attributes which define
       supported and default values for the Printer.

         - When a Job Template attribute is supplied by a client in a create
            request, the attribute and its value describe the desired job
            processing behavior.

         - output devices might or might not be capable of
              spooling jobs
            3b) The associated output devices might or might not support IPP

       See the following figures for some examples on how to view Printer object's supported attribute describes what behaviors
            are possible.

         -
       objects on top of several print system configurations.  The Printer object's default value attribute describes what will be
            done when no other job processing information is supplied by the
            client. embedded
       case below represents configurations 1 and 2. The hosted and fan-out
       figures below represent configuration 3.

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

       A client supplies Job Template attributes to affect the rendering,
       production and finishing of the documents in the job.  Similar types of
       instructions may also be contained
       Legend:

       ##### indicates a Printer object which is
             either embedded in the document to be printed, that
       is, within the Page Description Language (PDL) of the document data.  If
       there an output device or is
             hosted in a conflict between the value of one server.  The implementation
             might or might not be capable of these 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 |
                                                |               |
                                                +---------------+

       4.2 Job Template
       attributes, and a corresponding instruction in the document (either
       implicit or explicit), it Object

       A Job object is desirable that the value of the attribute
       shall take precedence over the document instruction.   Until companies
       that supply interpreters for PDLs, such as PostScript and PCL allow a
       way to external attributes (such as IPP attributes) used to take precedence
       over internal job production instructions, model a Printer might not be able job.  A job can contain one or more
       documents.  The information required to implement the semantics that IPP attributes override (take on a
       higher precedence) the embedded PDL instructions.   Therefore, IPP
       introduces create a special Job Template attribute named "best-effort".  This
       attribute gives object is sent in a

                       June 23, 1997, Expires December 23, 1997
       create request from the end user some ability via an IPP client to influence, a Printer.  A
       create request can be either a Print-Job Request, a Print-URI request,
       or at least
       understand, how a particular Printer implementation handles these
       conflicts.

       This attribute takes on the following values:

         - 'shall-honor-ipp-attributes': If a Create-Job Request.  The Printer supports this value and
            a MUST perform validation checks to
       verify that the job may indeed be processed.  A client requests this value, MAY send a
       Validate-Job Request (with no document data) so that the Printer guarantees that
       performs all IPP
            attribute values take precedence over embedded instructions in validation checks without the
            job data (the PDL overhead of transferring all
       of the job's documents).
         - 'should-honor-ipp-attributes': If a Printer supports this value,
            and a client requests this value, document data.  As an example of some of the Printer should try to make
            sure validation checks
       that IPP 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 are performed, the "best-effort-supported" attribute.  Notice create request may specify that since 'should-honor-ipp-attributes' does not offer any type the documents
       within the job are to be printed duplex (on both sides of
       guarantee, a the media).
       However, the Printer may might not do support such a very "good" job of implementing feature.  Once the
       semantics of "should", but it would still be Printer
       validates the submitted information, a conforming
       implementation.

       If there Job object is ever a conflict between what a Printer supports and what an
       IPP client requests, created.  The
       instance of the Printer shall reject Job object is initialized with information from the print
       create request.  A
       client should query the printer to find out what is supported before
       making  If a request.  This ensures that all requested attribute values Create-Job operation is used to create the Job
       object, subsequent Send-Document operations are
       supported.

       ISSUE: Should this be called "effort-level" rather than "best-effort"?

                        June 3, 1997, Expires December 3, 1997
       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 used to transfer the
       document data from the client to the IPP Printer.

       This model requires that these values be
       URIs as defined by RFC 1738 and RFC 1808.  In addition to an identifier
       attribute, instances of Printer and Job objects may have a name.  An
       object name need not specification defines rules for what MUST be unique across all instances of  all objects.
       The Printer name done when:

         - optional attributes are missing
         - there are conflicts between what is chosen supported and set by an administrator.  The Job name what is
       created by requested
         - there are conflicts between what the Printer using client requests via external
            attributes in the name of IPP operation and what the first document client requests in
            embedded instructions in the job.
       In all cases, document page description language
            (PDL).

       Job attributes are grouped as follows:

         "job-template" attributes (optionally supplied by the name only has local meaning, and is not constrained to client/end
            user, section 6.2)
         "job-description" attributes (set by the Printer, section 6.3)

       The following operations can be globally unique.

       To summarize, each instance of Printer and invoked on Jobs:

         Send-Document (section 5.1.6)
         Send-URI (Section 5.1.7)Cancel Job objects will have two
       identifying attributes:

         - "xxx-URI": The globally unique identifier for this object instance
         - "xxx-name": The non-globally unique name for this (section 5.1.8)
         Get-Attributes (section 5.1.9)

       4.3 Document Object

       A Document object instance consists of printable data and Document objects only have names, no identifiers.  The "document-name"
       attribute is used to store the name of the Document.  This name is just
       of interest within Attributes
       (see section 6.4).  These Document Attributes only describe the context of a Job.  It need not data to
       be globally
       unique.

       If Documents are printed by reference, printed; they are identified by URIs.

       5.   IPP Operations

       Jobs and Printers each have a set of associated operations. End users or
       programs invoke these operations using an IPP client. The operations
       are:

         For a Printer object:
            Create-Job (section 0)
            Print-Job (section ???)
            Get-Attributes (section 0)
            Get-Jobs (section 0).

         For do not include any specialized document processing
       instructions that apply to only one Document in a multi-document Job.
       All Job object:
            Send-Document (section ??)
            Cancel-Job (section 0)
            Get-Attributes (section 0)

       IPP Job and Printer objects are identified by URIs.  When a client
       communicates with a remote IPP object, it sends an operation request to
       the URI for Template attributes (those attributes that object.  Each request carries along with it describe desired job
       processing behavior) are defined as part of the input
       parameters and data required Job object, therefore,
       they apply equally to perform the specified operation.  Each
       request requires all Documents within a response from the object indicating success or Job. Currently there are no
       operations defined for Document objects.

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

       Instances of objects within the operation including response data and/or error messages.
       The representation and encoding system have relationships that MUST be
       maintained persistently along with the persistent storage of the IPP protocol are contained in
       "Internet Printing Protocol: Protocol Specification."[23]

       It is assumed that URIs for IPP Printers are available to end users or
       programs that wish to invoke object
       attributes.  A Printer operations.  Although NOT
       MANDATORY, it is RECOMMENDED that Printers be registered in a directory
       service which end users and programs can interrogate. "Internet Printing
       Protocol: Directory Schema"[24] defines the attributes to represent one or more output devices.  An
       output device can be associated
       with a represented by at most one Printer entry in a directory service.

       5.1  Operation Semantics

       In this section, the IPP operations are described object.  A
       Printer can contain zero or more Job objects.  A Job object is contained
       in terms of their
       contents and semantics including both the request and the response.

       In order to create a new exactly one Printer object.  A Job object, a client MAY use object contains one of two
       operations:  either the Create-Job operation or the Print-Job operation. more
       Documents.  If the client wants to create a Job with only Document is simply a single Document, reference to some print data
       stream, the
       client MAY use reference may be used in multiple Documents in the Print-Job operation same Job
       or a Create-Job operation
       followed by a single Send-Document operation.  For performance reasons,
       the client SHOULD use the Print-Job operation for all single Document even in different Jobs.  If the client wants to create a Job with more than one Document,
       the client SHALL use the Create-Job operation followed by as many Send- Document operations as needed (on Document per Send-Document operation).
       The Print-Job operation is not just a convenience operation for creating a Job
       with reference, but
       an actual stream of print data, the stream SHALL contain only one Document.  Throughout this model specification,
       document, although there can be copies of the term
       create request is used to refer to either a Create-Job Request same document data in
       other Documents in the same or a
       Print-Job Request.

       5.1.1     Print-Job Operation

       When an end user desires to submit a print job with only different Jobs.

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

       4.5 Object Attributes

       Each object type is defined by a set of possible attributes which
       describe the client sends realization of each instance of an object.  That is, a Print-Job Request to
       Printer object is defined as set of attributes which each instance of a
       Printer and receives object might potentially support.  In the same manner, a Print- Job Response from that Printer. The information in
       object is defined as a Print-Job Request
       (along with any default information set of attributes that are associated with the Printer) is
       sufficient for the Printer to create each
       instance of a Job object object.  Some attributes are OPTIONAL, some are
       MANDATORY, and then process that
       Job.

       5.1.1.1   Print-Job Request

       The following elements some are part of the Print-Job Request:

         Job Template Attributes:
            An optional set of Job Template CONDITIONALLY MANDATORY (see section 2).  Object
       attributes as are defined in section
            6.2 6 of this document.

       4.5.1 Job Template Attributes.  If the Attribute Overview

       Attributes that a client supplies no may optionally include in a create request are
       called Job Template attributes attributes.  These are described in the Create-Job Request, the detail in
       section 6.2.  The Printer uses its
            default value object has associated attributes when processing which define
       supported and default values for the job.

                        June 3, 1997, Expires December 3, 1997
         Document Content
            The Printer.

         - When a Job Template attribute is supplied by a client either supplies the raw document data or in a URI reference
            to the data but not both.

       The simplest Print-Job Request consists of just create
            request, the Document Content attribute and
       nothing else.  This means that its value describe the desired job
            processing behavior.

         - The Printer SHALL create a new Job object
       with 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.

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

       Client supplied Job Template attributes affect the rendering,
       production, and finishing of the documents in a single job.  Similar types of
       instructions may also be contained Document.

       When a Printer receives a Print-Job Request, within the Printer SHALL either
       accept or reject Page Description Language
       (PDL) of the request. document to be printed.  The Printer SHALL accept the Print-Job
       Request and SHALL create a Job object if it "best-effort" attribute,
       described in detail in section 6.2.8 is able provided to accept all
       attributes help manage the
       conflicts between values supplied in IPP Job Template attributes and
       corresponding instructions contained within the request. body of the document
       itself.  The Printer "best-effort" attribute SHALL reject take one of the request following
       values:

         - 'shall-honor-ipp-attributes': If a Printer supports this value and
       SHALL NOT create
            a Job object if client requests this value, the Printer rejects any guarantees that all IPP
            attribute values take precedence over embedded instructions in the request. There are six cases to consider with respect to each Job
       and Document attributes:

         1. The client supplies
            job data (the PDL of the job's documents).
         - 'should-honor-ipp-attributes': If a Job Template attribute named "xxx" Printer supports this value,
            and the
            value supplied by the client is among the values supported by the
            Printer (i.e., is among the values of the Printer's "xxx-supported"
            attribute): The "xxx" Job Template attribute is accepted.  If the
            "best-effort-supported" attribute contains the value 'shall-honor-
            ipp-attributes' a client requests this value, the Printer SHALL guarantee the behavior
            represented by the value in the "xxx" attribute (i.e., the SHOULD try to make
            sure that IPP attribute has values take precedence over any other embedded job instruction).
            If the value of the "best-effort-supported" PDL
            instructions, however there is 'should-honor-ipp-
            attributes' then the Printer SHOULD try to realize the behavior
            requested by the client, but NEED NOT no guarantee the behavior.  The
            Printer creates the Job object and implements the "xxx"

       This "best-effort" attribute
            in the new Job object has nothing to do with conflict between
       what a Printer supports and uses the value supplied by the client.

         2. The client supplies what an attribute value but the attribute IPP client requests.  If there is
            syntactically bad: The
       such a conflict, the Printer shall SHALL reject the job and return the
            ??? error code.

         3. The create request.  A client supplies an attribute value and
       SHOULD query the attribute value printer to find out what is
            not among the values supported by the Printer:  The before supplying
       specific values in a create request.

       4.6 Object Identity

       All instances of Printer SHALL
            reject the job and return the 'attribute-unsupported' error code.

         4. The client supplies Job objects have an identifier attribute
       whose value and the Printer does not
            implement the attribute: The attribute is ignored. globally unique so that they can persistently and
       unambiguously referenced.  The Printer
            behaves IPP model requires that these values be
       URIs as if the attribute was never supplied defined by the client in the
            Print-Job Request. RFC 1738 and RFC 1808.  In the response, the addition to an identifier
       attribute, instances of Printer SHALL return the
            names and Job objects may have a name.  An
       object name need not be unique across all instances of  all ignored attributes. objects. The final result of the Job
       Printer name is
            undefined for chosen and set by an ignored attribute (that administrator. If not supplied by
       the client, tthe Job name is created by the desired behavior
            might or might Printer.  In all cases, the
       name only has local meaning, and is not constrained to be realized).

         ISSUE: Should the printer just reject the job? unique.

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

         - "xxx-uri": The globally unique identifier for this object instance
         - "xxx-name": The non unique name for this object instance

                       June 3, 23, 1997, Expires December 3, 23, 1997
         5. The client does not supply
       Document objects sent to an attribute, but the IPP Printer
            implements the attribute: only have names, no identifiers.
       The "document-name" attribute is accepted and when the
            Printer creates the Job object, the Printer SHALL NOT implement the
            attribute in the Job object.  When the Printer processes that Job,
            the Printer SHOULD attempt used to use store the behavior implied by name of the
            default value Printer attribute as set at Document.
       This name is just of interest within the time context of Job
            processing (not Job creation).  In other words, these rules allow
            for a Job object to Job; it need not
       be created without implementing some unique.

       If Documents are printed by reference, they are identified by URIs.

       5. IPP Operations

       Jobs and Printers each have a set of the Job
            Template attributes.  As the Printer processes the Job, if the
            Printer implements associated operations. End users or
       programs invoke these operations using an IPP client. The operations
       are:

         For a default value attribute for the missing Job
            Template attribute, the Printer does its best to realize the
            behavior of the default value.  If the Printer does not implement
            the default value attribute, the results are undefined.

            Note: 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 each Job Template attribute, this specification REQUIRES
            that a Printer to implement the CONDITIONALLY Job object:
            Send-Document (section 5.1.6)                OPTIONAL
            Send-URI (section 5.1.7)                     OPTIONAL
            Cancel-Job (section 5.1.8)                   MANDATORY attributes.

         6. The
            Get-Attributes (section 5.1.9)               OPTIONAL

       When a client does not supply communicates with a remote IPP object, it sends an attribute, and the Printer does not
            implement the attribute:  The Printer accepts
       operation request to the Job and creates a
            Job URI for that object.  When the Job is processed, the actual behavior
            realized  Each request carries
       along with respect to it the missing Job Template attribute is
            undefined.

       5.1.1.2   Print-Job Response

       The Printer shall return input parameters and data required to perform the client
       specified operation.  Each request requires a response from the following output parameters
       as part object
       indicating success or failure of the Print-Job Response:

         Job Identifier:
            A URI which the client shall use for all other operations on this
            Job

         Job Status: operation including response data
       and/or error messages. The following Job attributes:  job-name, job-state, representation and job-state-
            reasons.  The value encoding of each attribute shall be from a snapshot
            taken sometime after the time the Printer receives the print
            request.  The "job-state-message" attribute is OPTIONAL.

            Note: Since any job affecting printer state information  is
            reflected IPP
       protocol are contained in the "job-state" and "job-state-reasons" job
            attributes, it "Internet Printing Protocol: Protocol
       Specification."[23]

       It is sufficient assumed that URIs for IPP Printers are available to return only job status attributes end users or
       programs that wish to invoke Printer operations.  Although NOT
       MANDATORY, it is RECOMMENDED that Printers be registered in a directory
       service which end users and no printer status programs can interrogate. "Internet Printing
       Protocol: Directory Schema"[24] defines the attributes at Job creation time.

         Ignored Attributes:
            A list of attribute names which were ignored to be associated
       with a Printer entry in the creation of the
            Job object. a directory service.

                       June 3, 23, 1997, Expires December 3, 23, 1997
         Unsupported Attributes:
            A list of attribute names which are unsupported.  Any attributes in
       5.1 Operation Semantics

       In this list imply that section, the Job object was not created.

         Bad Attributes:
            A list of attribute names which were syntactically incorrect. Any
            attributes IPP operations are described in this list imply that the Job object was not created.

         Status
            Status information including error status

       The simplest response shall consist terms of their
       contents and semantics including both the job identifier, request and the response.

       In order to create a new Job
       Status attributes, and an object, a client MAY use one of three
       operations:

         - The Print-Job operation:  This operation status that is either an "ok" status
       or an "error" status.

       5.1.2     Create-Job Operation

       When an end user desires to submit a print job, used if the client sends a
       Create-Job Request
            wants to create a Printer and receives a Create-Job Response from
       that Printer. The information in a Create-Job Request along with any
       default information associated Job with only a single Document and the Printer document
            data is sufficient for included in the
       Printer request.  In this case, the client "pushes"
            the document data to the Printer.

         - The Print-URI operation: This operation is used if the client wants
            to create a Job object.  An instance of with only a Job object contains
       all single Document and only a URI
            reference to the information needed by document data (not the document data itself) is
            included in the request.  In this case, the Printer to print one or more documents
       as a print job.  If "pulls" the client follows
            document data from the Create-Job operations with as
       many Send-Document operations as needed.

       5.1.2.1   Create-Job Request

       The following elements are part of location identified by the URI.

         - The Create-Job Request:

         Number of Documents:
            An optional integer value specifying operation:  This operation is used if the client
            wants to create a Job with one or more Documents.  This operation
            is followed by an arbitrary number of Documents Send-Document or Send-URI
            operations (each creating another Document for this Job. Job).  The document data is transferred in a series of
            subsequent
            Send-Document operations (one operation includes the document per Send-Document
            operation).  If this value is not supplied by data with the client,
            operation request (client "pushes" the
            Printer waits document data to receive an empty Send-Document operation signaling the end of Documents for this Job.  If
            printer), and the client wants to create a
            Job with Send-URI operation includes only a single document, reference (a
            URI) to the client MAY use document data (the Printer "pulls" the Print-Job
            operation.  This is a convenience document data
            from the referenced location).

       A Create-Job operation for creating followed by a Job with only one Document.  The Print-Job Operation Send-Document operation is
       semantically the
            same as equivalent to a Create-Job Print-Job operation, however, for
       performance reasons, the client SHOULD use the Print-Job operation followed by one Send-Document
            operation.

         Job Template Attributes:
            An optional set of Job Template attributes as defined in section
            6.2  Job Template Attributes.  If the client supplies no Job

                        June 3, 1997, Expires December 3, 1997
            Template attributes in for
       all single Document Jobs. Throughout this model specification, the Create-Job Request, term
       "create request" is used to refer to any of the implemented
            Printer defaults are used.

       The simplest Create-Job Request has no data which means three operation requests
       that the Printer
       SHALL create creates a new Job job object with no Job Template attributes and the
       number of Documents is yet to be determined.

         When (a Print-Job request, a Printer receives Print-URI request,
       or a Create-Job Request, the Printer SHALL
         either accept or reject request).

       5.1.1 Get-Operations Operation

       Since some of the request. IPP operations defined in this specification are
       OPTIONAL and therefore some implementations MAY choose to not implement
       support them, this operation, Get-Operations, is a simple, MANDATORY
       operation that all implementations MUST support.  The rules client uses this
       operation to query a specific implementation for accepting or
         rejecting a Create-Job list of supported
       OPTIONAL operations.

                       June 23, 1997, Expires December 23, 1997
       5.1.1.1 Get-Operations Request are the same as the rules for
         accepting or rejecting the Print-Job

       The Get-Operations Request (see section 5.1.1.1
                        Print-Job Request).

       5.1.2.2   Create Job has no parameters.

       5.1.1.2 Get-Operations Response

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

         Job Identifier:

         Supported Operations:
            A URI which list of the client shall use for all other OPTIONAL operations on that this
            Job

         Job Status:
            The following Job attributes:  job-name, job-state, and job-state-
            reasons.  The value implementation
            supports.  This set of each attribute shall be from a snapshot
            taken sometime after the time the Printer receives the print
            request.

            Note: Since any job affecting printer state information  is
            reflected in the "job-state" OPTIONAL operations are 'Create-Job',
            'Print-URI', 'Submit-Document', 'Submit-URI', 'Get-Jobs', and "job-state-reasons" job
            attributes, it is sufficient to return only job status attributes
            and no printer status attributes at Job creation time.

         Ignored Attributes:
            A list of attribute names which were ignored in the creation of the
            Job object.

         Unsupported Attributes:
            A list of attribute names which are unsupported.  Any attributes in
            this list imply that the Job object was not created.

         Bad Attributes:
            A list of attribute names which were syntactically incorrect. Any
            attributes in this list imply that the Job object was not created. 'Get-
            Attributes'.

         Status
            Status information including error status

                        June 3, 1997, Expires December 3, 1997
       The simplest response shall consist of the

       5.1.2 Print-Job Operation

       When an end user desires to submit a print job identifier, with only one Document,
       the Job
       Status attributes, client sends a Print-Job Request to a Printer and an operation status receives a Print-
       Job Response from that Printer. The information in a Print-Job Request
       (along with any default information associated with the Printer) is either an "ok" status
       or an "error" status.

       5.1.3     Send-Document Operation

       Once
       sufficient for the Printer to create a Job object has been created using and then process that
       Job.  A Print-Job operation differs from a Create-Job operation, Print-URI operation in that a
       client uses the Send-Document
       Print-Job operation to transport contains the documents document data to be printed and add them a
       Print-URI operation only contains a reference to the named Job object.  A document MUST be sent
       in a single Send-Document operation.

       5.1.3.1   Send-Document data.

       5.1.2.1 Print-Job Request

       The client submits the request to a Job URI.

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

         Document

         Job Template Attributes:
            An optional set of Document Description Job Template attributes (section 6.4
                 Document Attributes).

         Document Content:
            The as defined in section
            6.2.  If the client either supplies the raw document data or a URI reference
            to the data but not both.

       5.1.3.2   Send-Document Response

       The following abstract data types are part of the Send-Document
       Response:

         Job Status:
            The following no Job attributes:  job-name, job-state, and job-state-
            reasons.  The value of each attribute shall be from a snapshot
            taken sometime after Template attributes in the time
            Create-Job Request, the Printer receives uses its default value attributes
            when processing the print
            request.

            Note: job.  Since any job affecting printer state information  is
            reflected in the "job-state" and "job-state-reasons" job
            attributes, it a Print-Job operation is sufficient to return used for a
            Job with only job status one Document, the Document attributes "document-name"
            and no printer status attributes at Job creation time.

         Ignored Attributes:
            A list of attribute names which were ignored in "document-format" are also supplied by the creation of client.  "document-
            name" is MANDATORY; "document-format" is OPTIONAL.

         Document Content
            The client supplies the
            Job object. document data.

                       June 3, 23, 1997, Expires December 3, 23, 1997
         Unsupported Attributes:
            A list
       The simplest Print-Job Request consists of attribute names which are unsupported.  Any attributes in
            this list imply just the Document Content and
       nothing else.  This means that the Printer SHALL create a new Job object was not created.

         Bad Attributes:
            A list of attribute names which were syntactically incorrect. Any
       with no Job Template attributes in this list imply that and a single contained Document.

       When a Printer receives a Print-Job Request, the Printer SHALL either
       accept or reject the request. The Printer SHALL accept the Print-Job
       Request and SHALL create a Job object was not created.

         Status:
            Status information including error status

       5.1.4     Cancel Job Operation

       This operation allows a user if it is able to cancel one specific Print Job any time
       after accept all
       attributes in the print job has been established on request.  The Printer SHALL reject the Printer.  Some pages may
       be printed before request and
       SHALL NOT create a job is terminated if printing has already started
       when the Cancel Job operation is received.  Only the end user who is
       also object if the job originator ("job-originating-user" Job attribute) can
       cancel Printer rejects any attribute in
       the job using IPP 1.0.

       5.1.4.1   Cancel-Job Request request. There are six cases to consider when accepting or
       rejectingJob and Document attributes:

         1. The client submits the request to supplies a Job URI.

       The following abstract data types are part of Template attribute named "xxx" and the Cancel Job Request:

         Message:
            Optional message to
            value supplied by the operator

       5.1.4.2   Cancel-Job Response

       The following information client is part among the values supported by the
            Printer (i.e., is among the values of the Cancel Job Response:

         Status:
            Status information including error status

       5.1.5     Get-Attributes Operation Printer's "xxx-supported"
            attribute): The Get-Attributes operation allows client to obtain information from a
       Printer or "xxx" Job object. The client supplies Template attribute is accepted.  If the set of attributes names
       and/or
            "best-effort-supported" attribute group names that contains the value 'shall-honor-
            ipp-attributes' the requester is interested in as
       operation input parameters.  The Printer shall return a corresponding
       attribute list in SHALL guarantee the response with behavior
            represented by the appropriate attribute values
       filled value in for each the "xxx" attribute (explicitly named or implicitly included in
       an (i.e., the IPP
            attribute group) that has precedence over any other embedded job instruction).
            If the client supplied in value of the request.

                        June 3, 1997, Expires December 3, 1997
       5.1.5.1   Get-Attributes Request

       The client shall submit "best-effort-supported" is 'should-honor-ipp-
            attributes' then the Get-Attributes request to a Job URI or Printer URI.

       The following input parameters shall be part of SHOULD try to realize the Get-Attributes
       Request:

         Document Format:
            The client shall supply this input parameter only when requesting
            attributes of behavior
            requested by the Printer object. client, but NEED NOT guarantee the behavior.  The
            Printer shall reject this
            request, if this input parameter is creates the Job object and associates the "xxx" attribute
            with the new Job object using  the value supplied for by the client.

         2. The client supplies a Job object.

            This input parameter conditions Template  attribute but the attribute is
            syntactically bad: The Printer attributes SHALL reject the job and values
            that might depend on return the document format.
            'attribute-unsupported' error code and the name of the badly formed
            attribute (if known) in the "unsupported-attributes" response
            parameter.

         3. The Printer shall return
            only (1) those attributes that are implemented client supplies a Job Template attribute and (2) the attribute
            value is not among the values that are supported for the specified document
            format.  By specifying by the document format, Printer:  The
            Printer SHALL reject the client can
            eliminate Job and return the attributes that are not implemented 'attribute--value-
            unsupported' error code and values that
            are not supported for the document format that name of the client has or is
            able to generate.

            If unsupported attribute
            in the "unsupported-attribute-values" response parameter.

         4. The client omits this input parameter, supplies a Job Template attribute and the effect shall be Printer does
            not support the
            same as if attribute: The Printer rejects the value attribute.  The
            Printer returns the 'attribute-unsupported' error code and the name
            of the Printer's document format rejected attribute
            were supplied.  It is recommended that in the "unsupported-attributes" response
            parameter.

         5. The client always does not supply a
            value for document-format, since the Printer's default value for
            document-format may be 'auto-sense', in which case Job Template  attribute, but the returned
            attributes
            Printer supports the attribute:  The attribute is accepted and values are for when
            the union of Printer creates the document formats
            that Job object, the Printer supports in its 'auto-sense' support."

         Requested Attributes:
            An optional set of attribute names (without values) or attribute
            group names in whose values SHALL NOT associate

                       June 23, 1997, Expires December 23, 1997
            the requester is interested.  If attribute with the
            client omits this input parameter, new  Job object.  When the effect shall be Printer processes
            that Job, the same as
            if Printer SHOULD attempt to use the "all" attribute group were supplied.

       Attributes may be requested by name or behavior implied by group name.  For Jobs,
            the default value Printer attribute groups include:

         - 'job-template': as set at the attributes specified in Section 6.3.1 time of Job
            Template Attributes.
         - 'job-description':
            processing (not Job creation).  In other words, these rules allow
            for a Job object to be created without implementing some of the attributes specified in Section 6.3.2 Job
            Description Attributes.

       For Printers,
            Template attributes.  As the attribute groups include:

         - 'printer-job-template': Printer processes the Job, if the attributes specified in Section 6.5.1
            Printer supports  a corresponding default value attribute for the
            missing Job Template Attributes.

                        June 3, 1997, Expires December 3, 1997
         - 'printer-description': attribute, the attributes specified in Section 6.5.2 Printer Description  Attributes.

       There are also special groups:

         - 'none': no attributes of uses the specified object.  Note: none is
            primarily useful in Get-Jobs, but can be used as a "ping" with default value.
            Depending on the
            Get-Attributes operation.
         - 'all': all attributes value of the specified object

       5.1.5.2   Get-Attributes Response

       The Printer's "best-effort" attribute,
            the Printer shall either guarantees the behavior corresponding to the
            default value or it does its best to realize the behavior of the
            default value.  The results of processing a Job are undefined if
            the Printer does not support the default value attribute and the
            client does not supply a value in the create request.

         6. The client does not supply an attribute, and the Printer does not
            support the attribute:  The Printer accepts the Job but how the Job
            is finally processed (with respect to the missing Job Template
            attributes) is undefined.

       5.1.2.2 Print-Job Response

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

         Result Attributes:

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

         Job Status:
            The requested attributes following Job attributes:  job-name, job-state, and job-state-
            reasons.  The value of the object with their current values,
            if the requester supplied any Requested Attributes.  If the request
            did not supply any each attribute names, SHALL be from a snapshot
            taken sometime after the time the Printer shall assume that receives the client print
            request.  The "job-state-message" attribute is implicitly requesting OPTIONAL.

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

       ISSUE:  Randy suggest that the specified Job or
            Printer object.

         Unimplemented following are optional returns in 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 unimplemented.

         Unknown:
            A list unsupported.  The existence of
            any attribute names which name in this list implies that the Job was rejected.

         Unsupported Attribute Values:
            A list of attribute names whose client supplied values are unknown.

         Status:
            unsupported.  The existence of any attribute name in this list
            implies that the Job was rejected.

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

         Status
            Status information including error status

       A Printer may choose, for security reasons, not to return all attributes
       that a client requests. It may even return none

       The simplest response SHALL consist of the requested
       attributes. In such cases, job identifier, the Job
       Status attributes, and an operation status returned that is either an "ok" status
       or an "error" status.

       5.1.3 Print-URI Operation

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

       In response document data itself.  It is up to a "Get-Attributes" (or a "Get-Jobs") operation the
       following requirements apply IPP
       server to interpret the Printer:

         1. If URI and subsequently "pull" the document from
       the source referenced by the URI string.

       5.1.3.1 Print-URI Request

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

         Job Template Attributes:
            (see section 5.1.2.1)

         Document Reference:
            The client supplies an attribute name in the Requested
            Attribute input parameter and that attribute is implemented by a URI reference to the
            Printer, document data.

       5.1.3.2 Print-URI Response

       The Printer SHALL return to the printer shall respond with all current values for that
            attribute.  If client the value following output parameters
       as part of an implemented attribute is unknown for the Print-URI Response:

         Job Identifier:

                       June 3, 23, 1997, Expires December 3, 23, 1997
            some reason, the Printer shall respond with the attribute name in
            the "unknown attribute list" response parameter.

         2. If the client supplies an attribute name in the Requested
            (see section 5.1.2.2)

         Job Status:
            (see section 5.1.2.2)

         Unsupported Attributes:
            (see section 5.1.2.2)

         Unsupported Attribute input parameter that attributed Values:
            (see section 5.1.2.2)

         Status
            (see section 5.1.2.2)

       5.1.4 Validate-Job Operation

       This operation is not implemented by the
            Printer, the Printer shall respond with the attribute name in the
            "unimplemented attribute list" response parameter.

         3. If identical to the Print-Job operation (section 5.1.2)
       except that a client supplies an attribute group that is implemented by
            the Printer, no document data or any reference to
       document data and the Printer shall respond with all current values for
            each implemented attribute in allocates no resources (i.e., a new Job
       object) to process the group. It shall not respond for
            unimplemented attributes job. The VALIDATE request is only used to verify
       capabilities of a printer object against whatever input parameters are
       supplied in the group. If the value Validate-Job request.

       5.1.4.1 Validate-Job Request

       The following elements are part of an attribute
            is unknown for some reason, the Validate-Job Request:

         Job Template Attributes:
            (see section 5.1.2.1)

       5.1.4.2 Validate-Job Response

       The Printer shall respond with SHALL return to the
            attribute name in client the "unknown attribute list" response parameter.

         4. If following output parameters
       as part of the client supplies an attribute group keyword that Validate-Job Response:

         Job Identifier:
            (see section 5.1.2.2)

         Job Status:
            (see section 5.1.2.2)

         Unsupported 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 not
            implemented, similar to the Printer has Print-Job operation (section 5.1.2)
       except that a client supplies no means for determining if it is an
            unimplemented attribute document data or attribute group.  In this case, any reference to
       document data in the
            Printer assumes that it is an unimplemented attribute and responds
            as if it Create-Job request.  This operation is followed by
       one or more Send-Document or Send-URI operations.  It is possible for a
       given implementation to only support either Send-Document or Send-URI
       but not both.  In that case, a client SHOULD NOT use an unimplemented attribute (the unsupported
       operation.  If a Printer responds with supports the attribute name in Create-Job operation, it MUST also
       support one of the "unknown attribute list" response
            parameter). Send-Document or Send-URI operations or both.

       5.1.5.1 Create-Job Request

       The following elements are part 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 to the client the following output parameters
       as part of the Create-Job Response:

         Job Identifier:
            (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)

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

       (see section 5.1.2.2)

       5.1.6     Get-Jobs Send-Document Operation

       The Get-Jobs

       Once a Job object has been created using a Create-Job operation allows
       (returning a "job-uri"), a client to retrieve Printer attributes
       and directs a list of print jobs belonging Send-Document operation to
       the target Printer object. A list
       of newly create Job attribute names or attribute group names that object (identified by the client is
       interested in seeing may returned "job-uri").  The
       operation adds a new Document to the Job object. An entire document MUST
       be included sent in a single Send-Document operation.SEND-DOCUMENT requests are
       directed towards the request.

       This operation is like Get-Attributes, except that Get-Jobs operation
       returns attributes from more than one object. job object referenced by the "job_URI" string
       returned in a successful CREATE-JOB-RESP message.

       5.1.6.1   Get-Jobs Send-Document Request

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

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

         Job Owner
            This is the user-name.  If the value is non-null, then the
            requester wants only those jobs whose job-originating-owner is the
            same as the specified user-name.  If the value is null, then the
            requester wants all jobs.

         Limit
            This is an integer value which indicates a limit to the number

         Document Attributes:
            A set of
            Jobs returned.  The limit Document Description attributes (section 6.4).
         Last Document Flag
            This is a "stateless limit" in boolean flag that is set if this is the last Document for
            the Job.

         Document Content:
            The client supplies the document data.

       5.1.6.2 Send-Document Response

       The following output parameters are part of the Send-Document Response:

         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 3, 23, 1997, Expires December 3, 23, 1997
            limit
       5.1.7 Send-URI Operation

       This operation is n then only identical to the first n jobs are returned in Send-Document operation (see section
       5.1.6) except that a client supplies a reference (a URI) to the Get-Jobs
            Response; there document
       data to be printed rather than the document data itself.  It is no mechanism up to allow for
       the "next" n jobs.
            The limit applies across all Job States requested.  For example, if IPP server to interpret the limit if 50, URI and there are 75 jobs in subsequently "pull" the 'completed' state and
            25 in document
       from the 'pending state' and source referenced by the URI string.

       5.1.7.1 Send-URI Request

       The client requests first 'completed
            jobs' and then 'pending' jobs, only submits the first 50 'completed' jobs
            are returned. request to a Job URI.

       The other 25 'completed' jobs following abstract data types are not returned and
            neither 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 a URI reference to the document data.

       5.1.7.2 Send-URI Response

       The following output parameters are any part of the 'pending' jobs returned. Send-URI Response:

         Job States
            A possibly empty set of Status:
            (see section 5.1.6.2)

         Unsupported 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 Job Operation

       This operation allows a user to cancel one specific Print Job any time
       after the print job state values.  If has been established on the set Printer.  Some pages may
       be printed before a job is not empty,
            then terminated if printing has already started
       when the requester wants only those jobs whose job-state Cancel Job operation is received.  Only the
            same as one of end user who is
       also the specified job state values.   If this originator ("job-originating-user" Job attribute) can
       cancel the job using IPP 1.0.

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

       The client submits the request to 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 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 to obtain information from
       a Printer or Job object. The client supplies as an operation parameter has more than one value,
       the set of attribute names and/or attribute group names that the
       requester is interested in.  The Printer SHALL return a corresponding
       attribute list in the
            jobs grouped by state response with the appropriate attribute values
       filled in for each group being attribute (explicitly named or implicitly included in the same order as
            supplied by
       an attribute group) that the client supplied in this parameter.  Within each group, the
            jobs are ordered from oldest to newest with respect to completion
            time (either actual or expected).  For example, if the 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
            requests all 'pending' and 'completed' jobs, first all jobs in the
            'pending' state are returned (ordered from oldest to newest) and
            then all jobs in the 'completed' state are returned (ordered from
            oldest to newest).  If SHALL submit the client Get-Attributes request all 'completed' and
            'processing' jobs, first all jobs in the 'completed' state are
            returned (ordered from oldest to newest) and then all jobs in the
            'processing' state are returned (oldest to newest).  If a Job URI or
       Printer URI.

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

         Document Format:

                       June 23, 1997, Expires December 23, 1997
            The client
            does not SHALL supply this operation parameter, input parameter only when requesting
            attributes of the value Printer object.  The Printer SHALL be
            assumed to be (by both the client and reject this
            request, if this input parameter is supplied for a Job object.

            This input parameter conditions the Printer) first 'pending' Printer attributes and then 'processing'.

         Requested Job Attributes:
            A optional set of attribute names (without values) or attribute
            groups names in whose values the requester is interested from each
            of the jobs
            that might depend on the specified Printer. document format.  The attribute group names Printer SHALL return
            only (1) those attributes that are supported and (2) the same as attribute
            values that are supported for the Get-Attributes operation for specified document format.  By
            specifying the Job
            object. document format, the client can eliminate the
            attributes and values that are not supported.

            If the client omits this input parameter, the effect shall SHALL be the
            same as if the 'none'  attribute group were supplied.

       5.1.6.2   Get-Jobs Response

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

         Result Attributes:
            The result includes zero or more objects each with zero or more
            attributes.  Each Job is returned in chronological order.  This

                        June 3, 1997, Expires December 3, 1997
            order Printer's default value document format
            attribute were supplied.  It is explicitly defined to be: oldest to newest with respect to
            completion time, either actual or expected.

            If recommended that the client did not always
            supply any Job attributes, the Printer shall
            assume that a value for document-format, since the client is implicitly requesting Printer's default
            value for document-format may be 'auto-sense', in which case the 'none' group
            (that is no Job
            returned attributes and values are returned, just the Job URI for each
            Job).

         Status
            Status information including error status

       A Printer may choose, for security reasons, not to return all attributes
       that a client requests. It may even return none the union of the requested
       attributes. In such cases, document
            formats that the status returned Printer supports in its 'auto-sense' support."

         Requested Attributes:
            An optional set of attribute names (without values) or attribute
            group names in whose values the requester is interested.  If the
            client omits this input parameter, the effect SHALL be the same as
            if the
       Printer had returned all "all" attribute group were supplied.

       Attributes may be requested attributes. The client cannot tell by
       such a response whether the requested attribute was present name or absent on
       the Printer.

       5.2  Operation Status and Messages

         The Status code provides information on by group name.  For Jobs, the results
       attribute groups include:

         - 'job-template': all of the Job Template attributes that apply to a request.
         The Message provides a short textual description
            Job object (the first column of the Status.  The
         Status is intended for use by automata and the Message is intended
         for the human user.  An IPP application (i.e. a browser, GUI, print
         driver or gateway) is not required to examine or display table in Section 6.2).
         - 'job-description': the Message.

       5.3  Status Codes (type2 keyword)

         Each Status is described below, including a description of which
         operation(s) it can follow and any meta-information required Job Description attributes in Section 6.3.

       For Printers, the
         response.

         ISSUE: Keith's doc still need to go here.

       6.   Object Attributes

       This section describes attribute groups include:

         - 'job-template': all of the Job Template attributes with their corresponding syntaxes
       and values that are part apply to a
            Printer object (the last two columns of the IPP model. The sections below show the
       objects and their associated attributes which are included within table in Section 6.2).
         - 'printer-description': the
       scope of this protocol.  Many of these attributes specified in Section 6.5.

       There are derived from other
       relevant specifications:

         - ISO/IEC 10175 DPA (Final, June 1996)
         - RFC 1759 Printer MIB (Proposed Standard, May 1995) also special groups:

         - Internet-Draft: Printer MIB (Draft Standard 'none': no attributes of the specified object.  Note: none is
            primarily useful in progress, December
            1996) Get-Jobs, but can be used as a "ping" with the
            Get-Attributes operation.
         - Internet-Draft: Job Monitoring MIB (I-D in progress, March 1997) 'all': all attributes of the specified object

                       June 3, 23, 1997, Expires December 3, 23, 1997
       Each attribute is uniquely identified in this document using a "keyword"
       in
       5.1.9.2 Get-Attributes Response

       The Printer SHALL return the section header describing that attribute.  A keyword is a
       sequence following response parameters as part of characters (length of  1 to 255) which consists of just
       letters, digits, hyphen ("-"), and underscore ("_").  With these
       restrictions, there will be a straight forward encoding of these
       keywords onto real values in
       the protocol specification.  Not only are
       attributes uniquely identified with keywords, some Get-Attributes Response:

         Result Attributes:
            The requested attributes take on a
       syntax which is a set of keywords.  This set of keywords represents the
       domain object with their current
            valuesSHALL

         Unknown Attributes:
            A list of attribute names included in the attribute.

       6.1  Attribute Syntaxes

       The following table shows Get-Attributes request
            which are unknown by the basic syntax types that a client and
       server shall Printer.

         Status:
            Status information including error status

       A Printer MAY be able to handle.

       Table 1 - Attribute Syntaxes

            Basic Type         Description       Comments

            text               a sequence of     For free form human
                               characters;       readable text
                               length: 0 to      intended configured, for human
                               4095;             consumption.
                               characters: any

            name security reasons, not to return all
       attributes that a sequence client requests. It may even return none of     For referencing some
                               characters;       object via a user-
                               length: 1 to      friendly string,
                               255; the
       requested attributes. In such cases, the status returned is the same as a
       if the Printer
                               characters: any   name, a document
                                                 name, had returned all requested attributes. The client cannot
       tell by such a user name, response whether the requested attribute was present or a host name.  May
                                                 include
       absent on the SPACE
                                                 character.

                                                 Note: The protocol
                                                 may need Printer.

       In response to provide
                                                 means a "Get-Attributes" (or a "Get-Jobs") operation the
       following requirements apply to quote the
                                                 SPACE character if Printer:

         1. If the protocol uses
                                                 SPACE for other
                                                 purposes.

            fileName           a sequence of     For referencing some
                               characters;       file.  The limit is
                               length: 1 to client supplies an attribute name in the same as POSIX
                               1024;

                        June 3, 1997, Expires December 3, 1997
            Basic Type         Description       Comments

                               characters: any Requested
            Attribute input parameter and NT.

            keyword            a sequence of
                               characters;       identifiers of
                               length: 1 to      entities in the
                               255;              abstract protocol
                               characters:       (specified in this
                               letters, digits,  document).  These
                               hyphen ("-"),     entities can be
                                                 For semantic
                               underscore ("_") that attribute names or
                                                 values of
                                                 attributes,  When a
                                                 keyword is used to
                                                 represent supported by the
            Printer, the printer SHALL respond with all current values for that
            attribute.

         2. If the client supplies an attribute (its
                                                 name), it must be
                                                 unique within name in the
                                                 full scope of IPP
                                                 objects Requested
            Attributes input parameter and
                                                 attributes.  When a
                                                 keyword is used to
                                                 represent a value of
                                                 an attribute, it
                                                 must be unique just
                                                 within the scope of that attribute.
                                                 That is, a keyword
                                                 can attribute is not be used for
                                                 two different values
                                                 of supported by
            the Printer, the Printer SHALL respond with the same attribute to mean
                                                 two different
                                                 semantic ideas.
                                                 However, name in
            the same
                                                 keyword can be used
                                                 across two or more
                                                 attributes,
                                                 representing
                                                 different semantic
                                                 ideas "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 values for each
                                                 attribute.

            uri                a sequence of     Universal Resource
                               characters as     Identifier
                               defined
            supported attribute in
                               rfc1738 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 3, 23, 1997, Expires December 3, 23, 1997
            Basic Type         Description       Comments

                               rfc1808

            uriScheme
       5.1.10 Get-Jobs Operation

       The Get-Jobs operation allows a sequence of     "http" for HTTP
                               characters        schemed URIs (e.g.,
                               representing the  http://...).  "ftp"
                               URI Scheme        for FTP schemed URIs
                                                 (e.g., ftp://...).

            locale             a standard        ISSUE: What standard
                               identifier for    values will be used
                               language client to retrieve Printer attributes
       and      for locale?
                               character set

            octetString a sequence list of     Used for opaque
                               octets            data, such as print jobs belonging to the
                                                 document-content.

            boolean            two values target Printer object. A list
       of     like an keywordSet,
                               'true' and        but there are only
                               'false'           two values. Note: An
                                                 application might
                                                 use a checkbox for
                                                 such a value.

            integer            an integer value  each Job attribute names or attribute group names that the client is
       interested in seeing may be included in the    specifies the range
                               range from -      constraint
                               2**31 to 2**31 -  explicitly.
                               1

            dateTime           a value request.

       This operation is like Get-Attributes, except that      absolute date and
                               holds Get-Jobs operation
       returns attributes from more than one object.

       5.1.10.1 Get-Jobs Request

       The client SHALL submit the date    time
                               and time Get-Jobs request to the
                               nearest second.

            seconds            a non-negative    a relative time
                               integer with
                               implicit units
                               of seconds

            milliseconds       a non-negative a relative time
                               interger with
                               implicit units Printer URI.

       The following input parameters are part of milliseconds

                        June 3, 1997, Expires December 3, 1997
            Basic Type         Description       Comments

            integerUnits       an integer with the Get-Jobs Request:

         Limit
            This is an integer value
                               explicit units    expressed which indicates a limit to the number of
            Jobs returned.  The limit is a "stateless limit" in units

                                                 ISSUE: we have two
                                                 types with implicit
                                                 units and one with
                                                 explicit units where that if the units
            limit is n then only the first n jobs are
                                                 specific for one
                                                 attribute:
                                                 "printer-speed".

            1setOf  X          1 or more values returned in the Get-Jobs
            Response; there is no mechanism to allow for sets of values
                               of type X.

            rangeOf  X         a range of value  for a range of
                               of type X         values, such as
                                                 integers

       6.1.1     Attribute Extensibility

         This document uses prefixes to the keyword basic syntax type "next" n jobs.
            The limit applies across all Job States requested.  For example, if
            the limit if 50, and there are 75 jobs in order
         to communicate extra information to the reader through its name. This
         extra information need not be represented 'completed' state and
            25 in an implementation
         because it is unimportant to a the 'pending state' and the client or Printer.  The table below
         describes requests first 'completed
            jobs' and then 'pending' jobs, only the prefixes oldest 50 'completed' jobs
            are returned.  The other 25 'completed' jobs are not returned and their meaning.

         ISSUE: There
            neither are some references to any of the Printer Working Group (PWG).
         How do we describe 'pending' jobs returned.

         Requested Job Attributes:
            A optional set of attribute names (without values) or attribute
            groups names in this document whose values the process for requester is interested from each
            of the PWG to
         approve type 2 extensions?

            Basic       Prefix  Comments
            Type

            keyword     type1   someone must revise jobs on the IPP standard
                                to add a new name.  No private specified Printer.  The attribute group names
            are allowed.

            keyword     type2   implementers can, at any time, add new
                                values by proposing them to the PWG same as for registration (or an IANA-appointed
                                registry advisor after the PWG is no

                        June 3, 1997, Expires December 3, 1997
            Basic       Prefix  Comments
            Type

                                longer certified) where they are
                                reviewed Get-Attributes operation for approval.  IANA keeps the
                                registry.  Implementers can support
                                private (unregistered) with a suitable
                                distinguishing prefix, such as -xxx-
                                where xxx is Job
            object.  If the company name
                                registered 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 IANA for use in domain
                                names.

            keyword     type3   implementers can, at any time, add new
                                values by submitting a registration
                                request directly to IANA, no PWG zero or
                                IANA-appointed registry advisor review more
            attributes.  Each Job is required.  Implementers can support
                                private (unregistered) names with a
                                suitable distinguishing prefix, such
                                as -xxx- where xxx returned in chronological order.  This
            order is the company name
                                registered explicitly defined to be: oldest to newest with IANA for use in domain
                                names.

            keyword     type4   system administrators can, at any
                                time, add new installation-defined
                                names respect to
            completion time, either actual or expected. Jobs that are in the
            'pending-held' state SHALL appear in their position as if they were
            'pending'  (otherwise, a local system. Care should user might be taken deceived by the administrator to see jobs that keywords do not conflict with
                                other keywords defined by the standard
                                or move

                       June 23, 1997, Expires December 23, 1997
            from 'pending-held' to 'pending' as defined by seeming to jump ahead in the implementing
                                product. There is no registration or
                                approval procedure for type 4
                                keywords.

                                ISSUE: Since
            queue).

            If the standard specifies
                                some of client did not supply any Job attributes, the type 4 values, shouldn't
                                it be possible to register additional
                                type 4 values after Printer SHALL
            assume that the standard client is
                                approved?

       Note: This standard defines keyword values for all of implicitly requesting  the above types.

       6.2  Job Template Attributes "job-uri"
            attribute (that is no other Job Template attributes describe job processing behavior.  Take are returned, but the
            Job URI for
       example, each Job).

         Status
            Status information including error status

       A Printer MAY be configured, for security reasons, not to return all
       attributes that a generic Job Template attribute called "xxx":

                        June 3, 1997, Expires December 3, 1997
         1. "xxx" is optionally supplied by the client in a create request.
            If "xxx" is supplied, requests. It may even return none of the client
       requested attributes. In such cases, the status returned is specifying that the same as
       if the Printer
            will apply had returned all requested attributes. The client cannot
       tell by such a specific job processing behavior to this job while
            processing the Job.  When "xxx" is not supplied, response whether the client expects requested attribute was present or
       absent on the Printer will apply Printer.

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

       5.2 Operation Status Codes and Messages

       An operation status code provides information on the default job processing behavior.

         2. "xxx-supported" is of a Printer attribute that describes what
       request.  A message provides a short textual description of the Status.
       The status code is
            behaviors are supported intended for use by that Printer. "xxx-supported" is automata and a
            CONDITIONALLY MANDATORY  attribute which means that the Printer
            only implements message is
       intended for the attribute if it human user.  An IPP application (i.e. a browser, GUI,
       print driver or gateway) is capable of realizing one not required to examine or
            more of the behaviors associated with the attribute and its values.
            A client can query display the Printer
       message.  Status codes and find out what behaviors suggested corresponding messages are
            supported by inspecting at the values included
       in the "xxx-supported"
            attribute.

         3. The Printer also implements a default value attribute named "xxx". section 12 "APPENDIX A - Status Codes".

       6. Object Attributes

       This default value attribute section 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 attributes with the
            supported attribute, the default value attribute is also
            CONDITIONALLY MANDATORY.  However, if the Printer implements the
            "xxx-supported" attribute, the Printer MUST implement the their corresponding default value attribute syntaxes
       and vice versa.

         4. The Printer OPTIONALLY implements the "xxx-available" attribute.
            This attribute describes a state values that are part of readiness for each supported
            attribute. the IPP model. The supported sections below show the
       objects and available their associated attributes have which are included within the same
            number
       scope of this protocol.  Many of these attributes and are ordered so that there derived from other
       relevant specifications:

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

       Each attribute is uniquely identified in this document using a set of
            ordered value pairs between the two attributes. "keyword"
       (see section 2.2.1).  The availability
            state of a supported attribute value indicates keyword in included in the level section header

                       June 23, 1997, Expires December 23, 1997
       describing that attribute. Not only are attributes uniquely identified
       with keywords, some attributes take on a syntax which is a set of effort
            required by the Printer to actually use resource indicated by the
            supported value.
       keywords.

       6.1 Attribute Syntaxes

       The following values are used in the "xxx-
            available" attributes:

            'ready' - table shows the resource can basic syntax types that a client and
       server SHALL be used by able to handle.

         text:  a Job without human
              intervention (the resource is not exhausted)
            'not-ready' - the use sequence of the resource requires human intervention
              (the resource may be exhausted or not automatically available)

            Note: The "xxx-available" attribute only applies characters, length: 0 to the "media" and
            "finishings" attributes.

         5. If 4095, any characters.
            This syntax type is used for free form human readable text intended
            for human consumption.

         name:  a client application wishes sequence of characters, length: 1 to present an end 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 with name, or a list host name.

         fileName:  a sequence of supported and default values from which characters, length: 1 to choose, the client
            program should query 1024, any
            characters.  This syntax type is used for referencing some file.
            The limit is the supported, default values, same as in POSIX and possibly Microsoft NT.

         keyword:  a sequence of characters, length: 1 to 255, containing only
            the available attributes. characters ASCII letters, ASCII digits, hyphen ("-"),
            underscore ("_").  The values that the client then sends first character MUST be an ASCII letter.
            This syntax type is used for enumerating semantic identifiers of
            entities in the create request will all fall within the supported abstract protocol (specified in this document).
            These entities can be attribute names or values at the

                        June 3, 1997, Expires December 3, 1997
            Printer. of attributes.
            When querying the Printer, the client MAY enumerate each a keyword is used to represent an attribute by name in the Get-Attributes Request, or (its name), it
            MUST be unique within the client MAY
            just name the "printer-job-template" group in order to get the
            complete set full scope of supported, default value, IPP objects and available attributes
            which are implemented.

       The "job-priority" attribute attributes.
            When a keyword is used to represent a value of an example attribute, it
            MUST be unique just within the scope of a Job Template that attribute.
       It is an integer in  That is,
            the range from 1 to 100.  A client same keyword can query the
       Printer not be used for two different values within
            the "job-priority-supported" same attribute and to mean two different semantic ideas.  However,
            the "job-
       priority" default value same keyword can be used across two or more attributes,
            representing different semantic ideas for each attribute.  The supported attribute contains

         uri:  a
       set sequence of supported priority values (a range).  The default value attribute
       contains job priority value that will be characters as defined in rfc1738 and rfc1808.
            This syntax type is used for carrying Universal Resource
            Identifiers.

         uriScheme:  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 sequence of supported values.  If the
       client-supplied value is supported, characters representing the Job object is created URI Scheme.
            These include 'http' for HTTP schemed URIs (e.g., http://...), 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
            'ftp' for FTP schemed URIs (e.g., ftp://...).

         locale:  a "job-priority" value in the create request, the Job
       object is created, but no "job-priority" attribute is implemented standard identifier for
       the Job. country and language.  The client queries the Printer's default value "job-priority"
       value to find out at what priority the job will be processed.

       The following table summarize the names, relationships, and conformance
       requirements values
            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 supported attribute is implemented then the default
            value attribute MUST be implemented and vice versa.

         4. All "available" attributes are OPTIONAL.

       The table only shows exceptions to the above rules.   The first column
       of the table (Job) shows the name and this syntax for each Job Template type are taken from RFC 1766 [26].

                       June 3, 23, 1997, Expires December 3, 23, 1997
       attribute in the Job object (in the create request, the same name and
         octetString:  a sequence of octets.  This syntax type is used).  The next three columns show used for
            opaque data, such as the name 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
       each Job Template an attribute with this syntax type.

         integer:  an integer value that is in the Printer object (the default value
       attribute, range from -2**31 to 2**31
            - 1.  Each attribute specifies the supported attribute, and range constraint explicitly if
            the available attribute).  A
       "No" in range is different from the table means full range of possible integer
            values (e.g., 0 - 100 for the Printer SHALL NOT implement "job-priority" attribute).

         dateTime:  a standard, fixed length representation of date and time
            (to the attribute.

              Job            Printer           Printer          Printer
                          Default Value       Supported        Available

       job-name          No               No                No
       (name, MAN))

       job-sheets        job-sheets       job-sheets-       No
       (type4 keyword)   (type4 keyword)  supported
                                          (1setOf type4
                                          keyword)

       notificaiton-     notification-                      No
       events            events           events
                         (1setOf type2    (1setOf type2
                                          notification-
       (1setOf type2
       keyword)          keyword)         keyword)

       notification-     No               notification-     No
       addresses                          addresses-
       (1setOf uri)                       supported
                                          (1setOf uri
                                          scheme)

       job-priority      job-priority     job-priority-     No
       (int)             (int)            supported
                                          (rangeOf int)

       job-hold-until    job-hold-until   job-hold-until-   No
       (type4 keyword)   (type4 keyword)  supported
                                          (1setOf type4
                                          keyword)

       multiple-         multiple-        multiple-         No
       documents-are     documents-are    documents-are-
       (type2 keyword)   (type2 keyword)  supported
                                          (1setOf type2

                        June 3, 1997, Expires December 3, 1997
              Job            Printer           Printer          Printer
                          Default Value       Supported        Available

                                          keyword)

       best-effort       best-effort      best-effort-      No
       (type2 keyword)   (type2 keyword,  supported
                         MAN)             (1setOf type2
                                          keyword, MAN)

       media             media            media-supported   media-available
       (type4 keyword)   (type4 keyword)  (1setOf type2     (1setOf avail
                                          keyword)          keyword)

       number-up         number-up        number-up-
       (type3 keyword)   (type3 keyword)  supported
                                          (1setOf type3
                                          keyword)

       sides             sides            sides-supported
       (type2 keyword)   (type2 keyword)  (1setOf type2
                                          keyword)

       printer-          printer-         printer-
       resolution        resolution       resolution-
       (type2 keyword)   (type2 keyword)  supported
                                          (1setOf type2
                                          keyword)

       print-quality     print-quality    print-quality -
       (type2 keyword)   (type2 keyword)  supported
                                          (1setOf type2
                                          keyword)

       finishings        finishings       finishings-       finishings-
       (setOf type2      (setOf type2     supported         available
       keyword)          keyword)         (setOf type2      (setOf avail
                                          keyword)          keyword)

       copies            copies           copies-supported  No
       (int)             (int)            (rangeOf int)

                        June 3, 1997, Expires December 3, 1997
              Job            Printer           Printer          Printer
                          Default Value       Supported        Available

       compression       compression      compression-      No
       (type3 keyword)   (type3 keyword)  supported
                                          (1setOf type3
                                          keyword)

       job-k-octets      No               job-k-octets-
                                          supported
                                                            No
       (int)
                                          (rangeOf int)

       job-impressions   No               job-impressions-  No
       (int)                              supported
                                          (rangeOf int)

       job-media-sheets  No               job-media-        No
       (int)                              sheets-supported
                                          (rangeOf int)

       6.2.1     job-name (name) nearest second) as defined in RFC 1123 [27].  For example,
            Sun, 06 Nov 1994 08:49:37 GMT.  This attribute defines the name of the job.  It is a name fixed-length subset of
            that is more
       user friendly than the job-URI.

       If "job-name" is not supplied in the defined by RFC 1123  (an update to RFC 822).  All values MUST
            be represented in Greenwich Mean Time (GMT). This is indicated by
            the create request, the Printer,
       on creation inclusion of "GMT" as the Job, shall generate three-letter abbreviation for time.

         seconds:  a name which is the name non-negative integer with implicit units of the
       first document in the job. seconds.
            This name comes from the "document-name"
       attribute or "document-URI" attribute depending on which attribute is
       supplied in the Create-Job Request used for the first document.  If "job-
       name" is supplied in the Create-Job Request, the Printer uses its value
       as the name relative time.

         milliseconds:  a non-negative integer with implicit units of the created Job.

                        June 3, 1997, Expires December 3, 1997
       6.2.2     job-sheets (type4 keyword)
            milliseconds.  This attribute determines which of any banner page(s) shall be printed
       with a job.

       Standard is used for relative time.

         1setOf  X:  1 or more values are:

         'none': no job sheet of type X.  This syntax type is printed
         'standard': a site specific standard job sheet used for
            multi-valued attributes, whose value is printed
         extensions: names the specific job sheet (banner page)

       To force no job sheets, the system administrator SHALL a set the only
       supported value of values.  Note:
            The syntax type is called "1setOf" to 'none'..  To force the use indicate that set of banner pages, the
       supported values shall not include 'none'.  If
            SHALL NOT be empty (a set of size 0).

         rangeOf  X:  a client requests 'none'
       in the create request, the request is rejected.

       6.2.3     notification-events (1setOf type2 keyword)

       This attribute specifies the events for which the end user desires some
       sort range of notification.  The "notification-addresses" attribute value of type X.  This syntax type is used to
       describe the destination addresses
            for these events.

       Standard ordered values are:

         'none': (numeric, lexical, etc.) such as integers.

       6.1.1 Attribute Extensibility

         This document uses prefixes to the Printer shall not notify
         'all': "keyword" basic syntax type in
         order to communicate extra information to the Printer shall notify when any of event occurs.
         'job-completion':  the Printer shall notify when the job containing
            this attribute completes with or without errors.
         'job-canceled':  the Printer shall notify when the job containing
            this attribute reader through its
         name. This extra information need not be represented in an
         implementation because it is canceled by the end-user or by the operator, or
            aborts before completion.
         'job-problems':  the Printer shall notify when this job has unimportant to a problem
            while this job is printing. Problems include any of the "job-state-
            reasons" client or "printer-state-reason" values
         'printer-problems': the Printer shall notify when any job, including
            this job, is affected by a Printer problem (the printer has moved
            to Printer.  The
         table below describes the stopped state prefixes and there is a reason in their meaning.

         "type1":  The editor MUST revise the printer-state-
            reasons attribute) while this job is waiting IPP standard to print or printing.
            Problems include add a new name.
            No private names are allowed.

         "type2":  Implementers can, at any of the "job-state-reasons" or "printer-state-
            reason" time, add new values

       6.2.4     notification-addresses (1setOf uri)

       This attribute describes both where (the address) and how (the mechanism
       for delivery )  notification events are by proposing
            them to be delivered. The Printer
       shall use this attribute as the set of addresses and methods PWG for sending
       messages when an event occurs that the end user (job submitter) has
       registered registration (or an interest in. IANA-appointed registry

                       June 3, 23, 1997, Expires December 3, 23, 1997
       Standard uri scheme values are:

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

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

       This attribute specifies a priority no longer certified) where they are
            reviewed for scheduling approval.  IANA keeps the print-job. A
       higher value specifies registry.  Implementers can
            support private (unregistered) with a higher priority. The value 1 is defined to
       indicate the lowest possible priority. The value 100 suitable distinguishing
            prefix, such as "-xxx-" where xxx is defined to
       indicate the highest possible priority. Priority is expected to be
       evenly or "normally" distributed across this range.  Among those jobs
       that are ready to print, a Printer shall print all jobs company name registered
            with IANA for use in domain names.

         "type3":  Implementers can, at any time, add new values by submitting
            a priority
       value of n before printing those registration request directly to IANA, no PWG or IANA-appointed
            registry advisor review is required.  Implementers can support
            private (unregistered) names with a priority value of n-1 for all n.
       The mapping of vendor-defined priority over this range suitable distinguishing prefix,
            such as "-xxx-" where xxx is
       implementation-specific.

       6.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 company name registered with IANA
            for named time periods are:

         'no-hold': immediately, if there are not other reasons use in domain names.

         "type4":  Anyone (system administrators, system integrators, site
            managers, etc.) can, at any time, add new installation-defined
            names to hold a local system. Care SHOULD be taken by the
            job.
         'day-time': during implementers
            to see that keywords do not conflict with other keywords defined by
            the day.
         'evening': evening
         'night': night
         'weekend': weekend (Saturday standard or Sunday)
         '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 as defined by the implementing product. There is no
            registration or approval procedure for type 4 keywords.

       Each of time period.

       If the value four types above assert some sort of this attribute specifies a time period that is registry or review
       process in the
       future, the Printer shall add the 'job-hold-until-specified' value order to be valid.  "type1" values are only valid if the job's "job-state-reasons" attribute and shall not schedule the
       print-job for printing until the specified time-period arrives.  When
       the specified time period arrives, the Printer shall remove the 'job-
       hold-until-specified' value from
       specification is updated, "type2" values are only valid if the job's "job-state-reason attribute"

                        June 3, 1997, Expires December 3, 1997
       and, PWG or an
       IANA approved review process approves them, "type3" values are only
       valid if no other reasons remain, shall consider IANA registers the job as a candidate
       for processing.

       If this job attribute value with no review process required, and
       "type4" values are always valid (there is the named value "'no-hold'", no review or the time
       period has already started , the job shall registration
       process required).  Any typeN value MAY be registered using a candidate process
       for processing
       immediately.

       6.2.7     multiple-documents-are (type2 keyword)

       This job attribute some typeM where M is relevant only if less than N, however such registration is NOT
       REQUIRED.  For example, a job consists type4 value MAY be registered in a type 1
       manner (by being included in a future version of two or more
       documents. It controls finishing operations, job-sheet placement, and
       the order an IPP specification)
       however it is NOT REQUIRED.

       Note: This specification defines keyword values for all of documents when the copies attribute exceeds 1.

       Standard values are:

         'single-document': If the files for the above
       types, including type4 keywords.

       6.2 Job Template Attributes

       Job Template attributes describe job are a and b, then files a
            and b are treated as a single document processing behavior.  Take for finishing operations.
            Also, there will be no slip sheets between files
       example, a and b. If more
            than one copy generic Job Template attribute called "xxx":

         1. "xxx" is made, the ordering shall be a, b, a, b, ....
         'separate-documents-uncollated-copies': If the files for optionally supplied by the job are client in a and b, then each file create request.
            If "xxx" is treated as a single document for
            finishing operations. Also, a supplied, the client may specify is specifying that the Printer
            will apply a slip sheet
            be placed between files a and b.  If more than one copy specific job processing behavior to this job while
            processing the Job.  When "xxx" is made, not supplied, the ordering shall be a, a, b, b, ....
         'separate-documents-collated-copies': If client expects
            the files for Printer will apply the default job are a
            and b, then each file processing behavior.

                       June 23, 1997, Expires December 23, 1997
         2. "xxx-supported" is treated as a single document for finishing
            operations. Also, a client may specify Printer attribute that describes which
            behaviors are supported by a slip sheet be placed
            between files a and b. If more than one copy Printer.  "xxx-supported" is made, a
            CONDITIONALLY MANDATORY  attribute which means that the ordering
            shall be a, b, a, b, ....

       Both Printer
            only supports the attribute if it is capable of realizing one or
            more of the 'separate-xxx' values force each new document to start on a
       new media sheet.

       6.2.8     best-effort (type2 keyword)

       This behaviors associated with the attribute determines what to do if there is a conflict between what
       a and its values.
            A client requests can query the Printer and find out what a Printer supports.

       Standard behaviors are
            supported by inspecting at the values for this attribute are:

         - 'shall-honor-ipp-attributes': If a in the "xxx-supported"
            attribute.

         3. The Printer also supports this value and a client requests this value, default value attribute named "xxx".
            This default value attribute describes what will be done when no
            other job processing information is supplied by the Printer guarantees that all client (either
            explicitly as an IPP attribute values take precedence over embedded instructions in the create request or implicitly
            as an embedded instruction within the job data (the PDL of data).  Along with the
            supported attribute, the default value attribute is also
            CONDITIONALLY MANDATORY.  However, if the job's documents).
         - 'should-honor-ipp-attributes': If a Printer supports this value, the
            "xxx-supported" attribute, the Printer MUST support the
            corresponding default value attribute and vice versa.

         4. If a client requests this value, the Printer should try application wishes to make

                        June 3, 1997, Expires December 3, 1997
            sure that IPP attribute present an end user with a list
            of supported and default values take precedence over embedded PDL
            instructions, however there is no guarantee from which to choose, the client
            program SHOULD query the supported and default value attributes.
            The values that the client then supplies Job Template attributes in the create request to
       affect will
            all fall within the rendering, production and finishing of supported values at the documents in Printer.  When querying
            the
       job.  Similar types of instructions may also be contained Printer, the client MAY enumerate each attribute by name in the
       document to be printed, that is, within
            Get-Attributes Request, or the Page Description Language
       (PDL) of client MAY just name the document data.  If there is a conflict between "printer-
            job-template" group in order to get the value of
       one complete set of these attributes, supported
            and default value attributes which are supported.

       The "job-priority" attribute is an example of a corresponding instruction Job Template attribute.
       It is an integer in the document
       (either implicit or explicit), it is desireable that range from 1 to 100.  A client can query the value of
       Printer for the "job-priority-supported" attribute shall take precedence over and the document instruction.  Many "job-
       priority" default value attribute.  The supported attribute contains a
       set of
       these supported priority values (a range).  The default value attribute
       contains the job template attributes provides priority value that will be used for a new job if the
       client with a way does not supply one in the create request.  If the client does
       supply the "job-priority" attribute, the Printer validates the value to request
       some feature at print time
       make sure that might not have been embedded it falls within the
       document data when range of supported values.  If the
       client-supplied value is supported, the document was created. Job template object is created and the
       "job-priority" attribute
       also provides a client is populated with a way to override a feature at print time that was embedded within the document data value.  The Job object,
       when queried, returns the document was
       created.  Note: until companies that value supplied by the client.  If the client
       does not supply interpreters for PDLs, such
       as PostScript and PCL allow a way to specify overrides for internal "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
       production instructions, a Printer might not will be able 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 implement these implementation requirements:

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

         2. In order to solve this problem, a Printer Object, all supported attributes are CONDITIONALLY
            MANDATORY.

         3. All Printer default value attributes are CONDITIONALLY MANDATORY.
            However, if the IPP Printer implements that "supported" attribute then
            the MANDATORY
       best-effort-supported" attribute.  If Printer MUST also implement the default value of this attribute is
       'shall-honor-ipp-attributes', as
            well. and vice versa.

       The table only shows exceptions to the implementation MUST guarantee that above rules.   The first column
       of the
       IPP table (Job) shows the name and syntax for each Job Template
       attribute values take precedence over any related job processing
       instructions in the PDL Job's document data.  This can be done by
       modifying Job object (in the interpreter within create request, the output device itself to understand
       IPP attributes, or by mergeing theses 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 attributes directly
       into attribute in the document data, or Printer object (the default value attribute
       and the supported attribute).  A "No" in any other implementation specific manner.
       In any case, the semantics of 'shall-honor-ipp-attributes' MUST be
       preserved.

       Note: Since 'should-honor-ipp-attributes' does not offer any type of
       guarantee, a Printer may not do a very "good" job of implementing the
       semantics of "should", but it would still be a conforming
       implementation.

       This "best-effort" attribute has nothing to do with conflict between
       what a Printer supports and what an IPP client requests.  If there is
       such a conflict, table means the Printer shall reject
       SHALL NOT support the create request. attribute.  A client
       SHOULD query the printer to find out what is supported before supplying
       specific values in a create request.

       6.2.9     media (type4 keyword)

       This job attribute identifies the medium "MAN" indicates that the Printer shall use for
       all pages of the document regardless of what media are specified within
       the document. attribute
       is MANDATORY.

                       June 3, 23, 1997, Expires December 3, 23, 1997
       The values for medium 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-
       freed input-trays.  If a printer allows a client to specify an
       electronic form as the value of this attribute, such an electronic form
       implicitly selects a medium-name which in turn implicitly selects an
       input-tray that contains the medium specified by the electronic form.
       The electronic form also implicitly selects an image that the Printer
       shall merge with the data from the document as its prints each page.

       Standard values are (taken from ISO DPA and the Printer MIB):

         default:
         iso-a4-white:
         ...

       6.2.10
       +----------------------+----------------------+----------------------+
       |    Job               |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 type2 keyword)|(1setOf type2 keyword)| supported            |
       |                      |                      |(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            |
       |                      |                      |(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|
       | (type2 keyword)      | (type2 keyword, MAN) |(1setOf type2 keyword,|
       |                      |                      |MAN)                  |
       +----------------------+----------------------+----------------------+
       | media                | media                | media-supported      |
       | (type4 keyword)      | (type4 keyword)      |(1setOf type4 keyword)|
       |                      |                      |                      |
       +----------------------+----------------------+----------------------+
       | number-up            | number-up            | number-up-supported  |
       | (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 but is allowed to add
            embellishments or some sort of translation, scaling, or rotation.
         'two':
         'four':

       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      | (type3 keyword)      |(1setOf type3 keyword)|
       |                      |                      |                      |
       +----------------------+----------------------+----------------------+
       | sides                | sides                | sides-supported      |
       | (type2 keyword)

       This attribute specifies how source page-images are to be imposed upon
       the sides of an instance of a selected medium.      | (type2 keyword)      |(1setOf type2 keyword)|
       |                      |                      |                      |
       +----------------------+----------------------+----------------------+
       | resolution           | resolution           | resolution-supported |

                       June 3, 23, 1997, Expires December 3, 23, 1997
       The standard values are:

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

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

       6.2.12    printer-resolution
       | (type2 keyword)      | (type2 keyword)      |(1setOf type2 keyword)|
       |                      |                      |                      |
       +----------------------+----------------------+----------------------+
       | quality              | quality              | quality-supported    |
       | (type2 keyword)      | (type2 keyword)      |(1setOf type2 keyword)|
       |                      |                      |                      |
       +----------------------+----------------------+----------------------+
       | finishings           | finishings           | finishings-supported |
       |(1setOf type2 keyword)|(1setOf type2 keyword)|(1setOf type2 keyword)|
       |                      |                      |                      |
       +----------------------+----------------------+----------------------+
       | copies               | copies               | copies-supported     |
       | (integer: 0 - MAX)   | (integer: 0 - MAX)   | (rangeOf integer     |
       |                      |                      |  0- MAX)             |
       +----------------------+----------------------+----------------------+
       | document-format      | document-format      | document-format-     |
       | (type2 keyword)      | (type2 keyword)      | supported            |
       |                      |                      |(1setOf type3 keyword)|
       +----------------------+----------------------+----------------------+
       | 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 job-name (name)

       This job attribute specifies the resolution that is the Printer should use.

       The values are type2 keywords which represent single integers or pair name of
       integers. The latter are to specify the resolution when the x and y
       dimensions differ. When two integers are specified, job.  It is a name that is more user
       friendly than the first "job-uri" attribute value.  It does not need to be
       unique.

       If "job-name" is not supplied in the
       x direction, i.e., in create request, the direction Printer, on
       creation of the shortest dimension Job, SHALL generate a name.  The name MAY be generated
       using the name of the
       medium, so that first Document in the value Job ((the "document-name"
       attribute)..  If "job-name" is independent of whether the printer feeds
       long edge or short edge first.

       The standard values are:

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

       6.2.13    print-quality (type2 keyword)

       This job attribute specifies supplied in the print quality that create request, the
       Printer should
       use.

       The standard values are:

         draft: lowest quality available on SHALL use its value as the printer name of the created Job.

                       June 3, 23, 1997, Expires December 3, 23, 1997
         normal: normal or intermediate quality on the printer
         high: highest quality available on the printer

       6.2.14    copies (integer(1:2**31 - 1))
       6.2.2 job-sheets (type4 keyword)

       This job attribute specifies the number of copies of the job to determines which if any banner page(s) SHALL be
       printed.  Note: The effect of this attribute on jobs and documents printed
       with a job.

       Standard values are:

         'none': no job sheet is
       controlled by the multiple-files-are printed
         'standard': a site specific standard job attribute.

       6.2.15    finishings (1setOf type2 keyword)

       This sheet is printed

       To force no job attribute identifies sheets, the finishing operation that system administrator SHALL set the Printer
       should apply supported
       value to each copy only 'none'.  To force the use of each printed document banner pages, the supported
       values SHALL not include 'none'.  If a client requests 'none' in the job where
       create request, the
       definition of a copy request is controlled by the "multiple-documents-are" Job
       attributes.

       Standard values are:

         none:
         staple:
         ...

       6.2.16    compression (type3 rejected.

       6.2.3 notify-events (1setOf type2 keyword)

       This attribute identifies compression algorithms 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 compressed
       document data. these events.

       Standard values for this attribute are:

         'none':
         'zip':
         'tar':
         ...

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

       This Job attribute specifies the total size of Printer SHALL not notify.
         'all': the job in K octets,
       i.e., in units Printer SHALL notify when any of 1024 octets.  The value shall be rounded up, so that a event occurs.
         'job-completion':  the Printer SHALL notify when the job between 1 and 1024 octets shall be indicated as being 1K, 1025 to
       2048 shall be 2, etc. This containing
            this attribute is not intended to be a counter as
       in completes with or without errors.
         'job-canceled':  the Job Monitoring MIB;  it is intended to be useful routing and
       scheduling information if known.  The Printer might not be able to

                        June 3, 1997, Expires December 3, 1997
       compute SHALL notify when the job containing
            this value (if not supplied attribute is canceled by the client in the request) at the
       time end-user or by the Job is created.  If not, operator, or
            aborts before completion.
         'job-problems':  the Printer may implement SHALL notify when this
       attribute at any later time as it job has a problem
            while this job is able to compute the total size printing. Problems include any of the Job.

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

       This job attribute specifies the total size of "job-state-
            reasons" or "printer-state-reason" values.
         'printer-problems': the job in impressions.
       This attribute Printer SHALL notify when any job, including
            this job, is not intended to be affected by a counter as in the Job Monitoring
       MIB;  it is intended to be useful routing and scheduling information if
       known.  The Printer shall try problem (the printer has moved
            to compute the value if it stopped state and there is not supplied a reason in the create request.  The Printer might not be able to compute printer-state-
            reasons attribute) while this
       value (if not supplied by the client in the request) at the time the Job job is created.  If not, waiting to print or printing.
            Problems include any of 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 notify-addresses (1setOf uri)

       This attribute describes both where (the address) and how (the mechanism
       for delivery ) events are to be delivered. The Printer may implement SHALL use this

                       June 23, 1997, Expires December 23, 1997
       attribute at any
       later time as it is able to compute the total size set of addresses and methods for sending messages when
       an event occurs that the Job.

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

       This job attribute specifies 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 total size
            end of the job in media-sheets.
       This attribute specified HTML file.
         'ftp': FTP is not intended used to be append a counter as in record at the Job Monitoring
       MIB;  it is intended to be useful routing and end of a specified text
         file.

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

       This attribute specifies a priority for scheduling information if
       known. The Printer shall try to compute the print-job. A
       higher value if it specifies a higher priority. The value 1 is not supplied
       in defined to
       indicate the Create-Job Request. lowest possible priority. The Printer might not be able to compute
       this value (if not supplied by the client in the request) at the time
       the Job 100 is created.  If not, defined to
       indicate the Printer may implement this attribute at
       any later time as it is able highest possible priority.  Among those jobs that are ready
       to compute the total size print, a Printer SHALL print all jobs with a priority value of the Job.

       6.3  Job Attributes n
       before printing those with a priority value of n-1 for all n.  The attributes in
       mapping of vendor-defined priority over this section range is implementation-
       specific.

       6.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 associated 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 Job.

       6.3.1     Job Template Attributes

       The Job Template attributes which apply specifically 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 Job object are
       described time period that is in section 6.2   Job Template Attributes.   These Job specific
       attributes form the attribute group called "job-template".

       6.3.2     Job Description Attributes

       These attributes form
       future, the Printer SHALL add the 'job-hold-until-specified' value to
       the job's "job-state-reasons" attribute group called "job-description".

           Attribute       Man
                            ?

                        June 3, 1997, Expires December 3, 1997
       job-URI             Man
       (uri)

       job-originating-    Man
       user
       (name)

       job-originating-
       host
       (name)

       user-locale
       (type2 keyword)

       job-state           Man
       (type1 keyword)

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

       job-state-message
       (text)

       output-device-
       assigned
       (name)

       time-since-         Man
       submission
       (milliseconds)

       number-of-          Man
       intervening-jobs
       (int)

       job-message-from-
       operator
       (text)

       time-since-         Man
       completion
       (milliseconds)

       job-k-octets-
       completed
       (int) and SHALL NOT schedule the
       print-job for printing until the specified time-period arrives.  When

                       June 3, 23, 1997, Expires December 3, 23, 1997
       job-impressions-
       completed
       (int)

       job-media-sheets-
       completed
       (int)

       6.3.2.1   job-URI (uri)

       This attribute contains
       the URI for the job.  The Printer, on receipt of
       a new job, shall generate a URI which identifies the job on specified time period arrives, the Printer.
       The Printer, shall return Printer SHALL remove the 'job-
       hold-until-specified' value of from the job's "job-state-reason attribute"
       and, if no other reasons remain, SHALL consider the URI job attribute as part of
       the PrintResult in the Print operation. The precise format of a job URI
       shall be implementation dependent.

       6.3.2.2   job-originating-user (name)

       This attribute specifies the user name of the person submitting the
       print job.  The Printer shall set candidate
       for processing.

       If this job attribute to the most authentic
       name that it can obtain from value is the protocol over which named value "'no-hold'", or the operation was
       received from time
       period has already started , the client.

       6.3.2.3   job-originating-host (name) job SHALL be a candidate for processing
       immediately.

       6.2.7 multiple-documents-are (type2 keyword)

       This job attribute identifies is relevant only if a job consists of two or more
       documents. It controls finishing operations, job-sheet placement, and
       the originating host order of documents when the job. The Printer
       shall set this copies attribute to the most authentic host exceeds 1.

       ISSUE: Change name it can obtain
       from to "finishing-for-multiple-documents"??

       Standard values are:

         'single-document': If the protocol over which files for the operation was received from 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. If more than one copy is made, the
       client.

       6.3.2.4   user-locale (type3 keyword)

       This attribute identifies ordering SHALL be a, b, a, b,
            ....
         'separate-documents-uncollated-copies': If the locale of files for the job, i.e, the country,
       language, job are
            a and coded character set. The Printer sets this attribute to
       the most authentic value it can obtain from the protocol over which 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
       Print operation was received from ordering SHALL be a, a, b, b, ....
         'separate-documents-collated-copies': If the client.

       The Printer shall use this attribute to determine files for the locale job are a
            and b, then each file SHALL be treated as a single document for
       notification messages
            finishing operations. Also, a client may specify that it sends.

       6.3.2.5   job-state (type1 keyword)

       This attribute identifies a slip sheet
            be placed between files a and b. If more than one copy is made, the current state
            ordering SHALL be a, b, a, b, ....

       Both of the job.

                        June 3, 1997, Expires December 3, 1997
       The Printer may provide additional information about each state value by
       supplying one or more 'separate-xxx' values force each new document to start on a
       new media sheet.

       6.2.8 best-effort (type2 keyword)

       A client supplies Job Template attributes to affect the rendering,
       production and finishing of the job's companion "job-state-reasons"
       attribute depending on implementation.  While documents in the job states cannot job.  Similar types of
       instructions may also be
       added contained in the document to without impacting deployed clients be printed, that take actions upon
       receiving job state values, it is
       is, within the intent that additional "job-state-
       reasons" values can be defined without impacting such deployed clients.
       In other words, Page Description Language (PDL) of the "job-state-reasons" attribute is intended to be
       extensible.

       Standard values are:

            unknown     The job state is not known, or its
                        state is indeterminate.
            pending     The job is a candidate to start
                        processing, but is not yet
                        processing..
            pending-    The job document data.  If
       there is not a candidate for
            stopped     processing for any number conflict between the value of reasons one of these IPP Job Template
       attributes, and will resume pending as soon as the
                        reasons are no longer present.  The
                        job's "job-state-reason" attribute
                        shall indicate why a corresponding instruction in the job document (either
       implicit or explicit), it is no
                        longer a candidate for processing. desirable that the value of the attribute

                       June 3, 23, 1997, Expires December 3, 23, 1997
            processing  Either:
                        1.
       SHALL take precedence over the job is using, or is attempting
                        to use, one or more document
                        transforms which include (1) purely
                        software processes instruction.  Until companies
       that are
                        interpreting a PDL, supply interpreters for PDLs, such as PostScript and (2) hardware
                        devices that are interpreting a PDL,
                        making marks on PCL allow a medium, and/or
                        performing finishing, such
       way to external attributes (such as stapling
                        OR
                        2.  the server has made the IPP attributes) to take precedence
       over internal job ready
                        for printing, but the output device is production instructions, a Printer might not yet printing it, either because
                        the job hasn't reached be able
       to support the output
                        device or because semantics that IPP attributes override (take on a higher
       precedence) the job is queued in embedded PDL instructions.   Therefore, this attribute
       gives the output device or end user some other
                        spooler, awaiting the output device ability to
                        print it.
                        ISSUE: The "job-state-reasons"
                        specification is that the job is in
                        'pending' state not 'processing'
                        state.
                        When influence, or at least understand,
       how a particular Printer implementation handles these conflicts.

       This attribute takes on the job is in the 'processing'
                        state, the entire job state includes
                        the detailed status represented in the
                        printer's "printer-state", "printer-
                        state-reasons", following values:

         - 'shall-honor-ipp-attributes': If a Printer supports this value and "printer-state-
                        message attributes.
                        Implementations may include additional
                        values in
            a client requests this value, the job's "job-state-
                        reasons" Printer guarantees that all IPP
            attribute to indicate the
                        progress of the job, such as adding
                        the 'job-printing' value to indicate
                        when values take precedence over embedded instructions in the output device is actually
                        making marks on paper.  Most
                        implementations won't bother with this
                        nuance.

                        June 3, 1997, Expires December 3, 1997
            processing  The
            job has stopped while processing
            -stopped    for any number data (the PDL of reasons and will
                        continue processing as soon as the
                        reasons are no longer present.  The job's "job-state-reason" attribute
                        shall indicate why the job has stopped
                        processing. documents).
         - 'should-honor-ipp-attributes': If a Printer supports this value,
            and a client requests this value, the output device Printer SHOULD try to make
            sure that IPP attribute values take precedence over embedded PDL
            instructions, however there is stopped, the
                        'printer-stopped' value shall no guarantee

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

       A Printer SHALL implement the job's "job-state-
                        reasons" "best-effort-supported" attribute.  When  Notice
       that since 'should-honor-ipp-attributes' does not offer any type of
       guarantee, a Printer may not do a very "good" job of implementing the output
                        device
       semantics of "should", but it would still be a conforming
       implementation.

       If there is stopped, ever a conflict between what a Printer supports and what an
       IPP client requests, the device usually
                        indicates its condition in human
                        readable form locally at Printer SHALL reject the device. print request.  A
       client can obtain more complete
                        device status remotely by querying SHOULD query the
                        printer's "printer-state-reasons"
                        attribute.
            canceled    The job has been canceled by a Cancel-
                        Job operation and printer to find out what is either (1) in supported before
       making a request.  This ensures that all requested attribute values are
       supported.

       ISSUE: Should this be called "effort-level" rather than "best-effort"?

       If the
                        process value of terminating or (2) has
                        completed terminating.  The job's
                        "job-state-reasons" this attribute shall
                        contain either the 'canceled-by-user'
                        or 'canceled-by-operator' value.
            aborted     The job has been aborted by is 'shall-honor-ipp-attributes', the
                        system, usually while
       implementation MUST guarantee that the IPP attribute values take
       precedence over any related job was processing instructions in the 'processing' state.
            completed   The job has completed successfully or
                        with warnings or errors and all of PDL Job's
       document data.  This can be done by modifying the
                        job media sheets have been properly
                        stacked in interpreter within the appropriate
       output tray device itself to understand IPP attributes, or bin.  The job's "job-state-reasons"
                        attribute shall contain one of:
                        'completed-successfully', 'completed-
                        with-warnings', by merging theses
       Job Template attributes directly into the document data, or 'completed-with-
                        errors'.

       The length of time that jobs remain in any other
       implementation specific manner.  In any case, the 'canceled', 'aborted', and
       'completed' states depends on implementation.

       The following figure shows the normal job state transitions.  Other
       transitions are unlikely, but are not forbidden. semantics of 'shall-
       honor-ipp-attributes' MUST be preserved.

                       June 3, 23, 1997, Expires December 3, 23, 1997
                                                   +--> canceled
                                                  /
           +----> pending --------> processing --+----> aborted
           |         ^                  ^         \
       ----+         |                  |          +--> completed
           |         v                  v
           +----> pending-stopped   processing-stopped

       Figure 1 - Normal job state transitions

       Normally
       Note: Since 'should-honor-ipp-attributes' does not offer any type of
       guarantee, a Printer may not do a very "good" job progresses only from left to right through three states.

       Even though the IPP protocol defines seven values for job states,
       Printers SHALL only implement those states which are appropriate for of implementing the
       particular
       semantics of 'should', but it would still be a conforming
       implementation.

       6.3.2.6   job-state-reasons (1setOf  type2

       6.2.9 media (type4 keyword)

       This job attribute identifies the reason or reasons medium that the job is in the
       state that it is in (e.g., 'pending', 'processing', 'completed', etc.).
       The Printer shall indicate the particular reason(s) by setting SHALL use for
       all pages of the value document regardless of what media are specified within
       the job's "job-state-reasons" attribute. document.

       The following standard values are defined for use with "media" include medium-names, medium-sizes, input-trays
       and electronic forms so that one attribute specifies the job states
       indicated media. If a
       printer allows a client to specify a medium name as applicable.

       NOTE - For easy of understanding the order of the reasons is presented
       in the normal order value of job state progression:

            none                Mandatory:  There are no reasons
                                for the job's current state.
                                Applicable job states:
                                'pending', 'processing',
                                'aborted'.
            job-incoming        Mandatory.  The PrintJob or
                                CreateJob operation has been
                                accepted by the Printer, but the
                                Printer is waiting for additional
                                SendDocument operations and/or this
       attribute, such a medium name implicitly selects an input-tray that
       contains the transfer of specified medium.  If a printer allows a client to specify
       a medium size as the remainder value of this attribute, such a medium size
       implicitly selects a medium name which in turn implicitly selects an
       input-tray that contains the job or document data.
                                Applicable job states: 'pending-
                                stopped'
            job-outgoing        Optional. The Printer is
                                transmitting the job to medium with the
                                output device.
                                Applicable job states: 'pending'

                        June 3, 1997, Expires December 3, 1997
            job-hold-until-     Conditionally mandatory. specified           Mandatory if size.  If a
       printer allows a client to specify an input-tray as the "job-hold-until"
                                job attribute is implemented.
                                The value of this
       attribute, such an input-tray implicitly selects the job's "job-hold-
                                until" attribute has specified a
                                time period medium that has not yet
                                arrived, so is in
       that input-tray at the Printer
                                shall not consider time the job as prints. This case includes manual-
       feed input-trays.  If a
                                candidate for processing.
                                Applicable job states: 'pending-
                                stopped'.
            job-hold-until-     Optional.  At least one of the
            resources-are-      resources needed by the job, such
            ready printer allows a client to specify an electronic
       form as media, fonts, resource
                                objects, etc., is not ready on
                                any of the physical printer's for
                                which the job is a candidate.
                                Usually value of this attribute, such an electronic form implicitly
       selects a condition is
                                detected while the job is medium-name which in the
                                'pending' state.  If a job starts
                                processing and encounters a
                                resource turn implicitly selects an input-tray
       that is not ready, there
                                are two possible implementations:
                                (1) contains the device is stopped and no
                                jobs can run until medium specified by the
                                resource(s) are made ready, in
                                which case electronic form. The
       electronic form also implicitly selects an image that the Printer shall keep SHALL
       merge with the job in data from the 'processing' state document as its prints each page.

         Standard values are (taken from ISO DPA and shall add the 'printer-
                                stopped' reason to the job's
                                "job-state-reasons" attribute
                                (not the 'job-hold-until-
                                resources-are-ready' value) OR
                                (2) another Printer MIB) and are
            listed in section 14.

       6.2.10 number-up (type3 keyword)

       This job is found to use
                                the device while attribute specifies the current job
                                goes back number of source page-images to waiting for its turn impose
       upon a single side of an instance of a selected medium.

       Standard values are:

         'none': The Printer SHALL not include any embellishments and for the resources to be made
                                ready, in which case 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 change SHALL place one logical page on a single side of
            an instance of the job's "job-
                                state" attribute to 'pending' and selected medium (MAY add the 'job-hold-until-
                                resources-are-ready' value to the
                                job's "job-state-reasons"
                                attribute.
                                Applicable job states: 'pending-
                                stopped'. some sort of
            translation, scaling, or rotation).

                       June 3, 23, 1997, Expires December 3, 23, 1997
            printer-stopped-    Optional.  This reason appears in
            partly              all jobs in
         'two': The Printer SHALL place two logical page on a single side of
            an instance of the 'pending' state
                                when 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 value selected medium (MAY add some sort of
            translation, scaling, or rotation).

       This attribute primarily controls the Printer's
                                "printer-state-reasons" 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 sides (type2 keyword)

       This attribute
                                contains specifies how source page-images are to be imposed upon
       the value 'stopped-
                                partly'.
                                Applicable job states: 'pending'
            printer-stopped     Mandatory. sides of an instance of a selected medium.

       The output device is
                                stopped.  This reason appears in
                                all jobs in standard values are:

         'one-sided': imposes each consecutive source page-image upon the 'pending' same
            side of consecutive media sheets.
         'two-sided-long-edge': imposes each consecutive pair of source page-
            image upon front and
                                'processing' states when back sides of consecutive media sheets, such
            that the
                                value orientation of each pair of source-pages on the Printer's "printer-
                                state" attribute is 'stopped'.
                                Applicable job states: 'pending-
                                stopped', 'processing-stopped'
            job-printing        Optional. The output device is
                                marking media. medium
            would be correct for the reader as if for binding on the long edge.
            This value imposition is
                                useful for Printers which spend a
                                great deal sometimes called 'duplex'.
         'two-sided-short-edge': imposes each consecutive pair of time processing
                                when no marking is happening source page-
            image upon front and
                                then want to show back sides of consecutive media sheets, such
            that marking is
                                now happening.
                                Applicable job states:
                                'processing', 'processing-
                                stopped'
            job-cancelled-by-   Level 2 Mandatory.  The job was
            user                cancelled by the user using orientation of each pair of source-pages on the
                                CancelJob request.
                                Applicable job states:
                                'canceled'.
            job-cancelled-by-   Level 2 Mandatory.  The job was
            operator            cancelled by medium
            would be correct for the operator using reader as if for binding on the CancelJob request.
                                Applicable job states:
                                'canceled'.
            logfile-pending     Optional.  The job's logfile short
            edge.  This imposition is
                                pending file transfer.
                                Applicable job states:
                                'canceled', 'aborted', and
                                'completed'.
            logfile-            Optional.  The job's logfile sometimes called 'tumble' or '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
            transferring        being transferred.
                                Applicable 'tumble' in portrait but 'duplex' in landscape.  'head-
       to-head' also switches between 'duplex' and 'tumble' when using portrait
       and landscape modes.

       6.2.12 printer-resolution (type2 keyword)

       This job states:
                                'canceled', 'aborted', attribute specifies the resolution that the Printer SHOULD use.

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

                       June 3, 23, 1997, Expires December 3, 23, 1997
            job-completed-      Mandatory.  The job completed
            successfully        successfully.
                                Applicable job states:
                                'completed'.
            job-completed-      Mandatory.
       The standard values are:

       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 print-quality (type2 keyword)

       This job completed
            with-warnings       with warnings.
                                Applicable job states:
                                'completed'.
            job-completed-      Mandatory. attribute specifies the print quality that the Printer SHOULD
       use.

       The job completed
            with-errors         with errors (and possibly
                                warnings too).
                                Applicable job states:
                                'completed'.

       6.3.2.7   job-state-message (text) standard values are:

         draft: lowest quality available on the printer
         normal: normal or intermediate quality on the printer
         high: highest quality available on the printer

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

       This attributes job attribute specifies suplimental information about the Job State in
       human readable text.  It SHALL number of copies of the job to be set
       printed.

       Note: The effect of this attribute on jobs and documents is controlled
       by the Printer.

       6.3.2.8   output-device-assigned (uri) "multiple-documents-are" job attribute (section 6.2.7).

       6.2.15 finishing (1setOf type2 keyword)

       This job attribute identifies the Output Device to which finishing operations that the Printer has
       assigned this job.  If an output device implements an embedded IPP
       Printer, the Printer NEED NOT set this attribute.  If a Print Server
       implements a Printer, the value MAY be empty until the Printer assigns
       an output device
       SHOULD apply to each copy of each printed document in the job.

       ISSUE: Why is this a uri?

       6.3.2.9   time-since-submission (milliseconds)

       This attribute indicates job where the amount

                       June 23, 1997, Expires December 23, 1997
       definition of time that has passed since a copy is controlled by the "multiple-documents-are" Job was first created.

       6.3.2.10  time-since-processing (milliseconds)
       attributes.

       Standard values are:

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

       This optional attribute indicates defines the amount of time that has passed since document format for each Document in
       a Job.  The standard values for this attribute are keywords.  Since the
       Job first entered
       complete list is rather long, the processing state.

       6.3.2.11  number-of-intervening-jobs full enumeration of standard values is
       found in section 13 APPENDIX B - "document-format" Values.

       6.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 job-k-octets (integer(0:2**31 - 1))

       This Job attribute indicates specifies the number total size of jobs that are "ahead" the job in K octets,
       i.e., in units of this 1024 octets.  The value SHALL be rounded up, so that a
       job between 1 and 1024 octets SHALL be indicated as being 1K, 1025 to
       2048 SHALL be 2, etc. This attribute is not intended to be a counter as
       in the current scheduled order.  For efficiency, Job Monitoring MIB;  it is only necessary intended to
       calculate this value when an operation be useful routing and
       scheduling information if performed that requests this
       attribute.

                        June 3, 1997, Expires December 3, 1997
       Note: This attribute is necessary since an end user may request just
       their own jobs and they need some relative position indicator if there
       are other jobs interspersed in known.  If the waiting list which are client does not returned supply this
       attribute in the response or cannot create request, the Printer might not be because of site security policy
       restrictions.

       6.3.2.12  job-message-from-operator (text)

       This attribute provides a message from an operator, system administrator
       or "intelligent" process to indicate able to
       compute this value at the end user the reasons for
       modification or other management action taken on a job.

       6.3.2.13  time-since-completion (milliseconds)

       This attribute indicates the amount of time that has passed since the Job was first is created.

       6.3.2.14  job-k-octets-completed

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

       This job attribute specifies the number of octets completed in K octets,
       i.e., in units total size of 1024 octets.  The value shall be rounded up, so that a the job between 1 and 1024 octets shall be indicated as being 1K, 1025 to
       2048 shall be 2, etc. in impressions.
       This attribute is not intended to be a counter as in the Job Monitoring MIB.

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

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

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

       This job attribute specifies useful routing and scheduling information if
       known.  The Printer SHALL try to compute the media-sheets completed. This attribute value if it is intended to be a counter as not supplied
       in the Job Monitoring MIB.

       6.4  Document Attributes

       This group of attributes describes the document data for the job.  They
       are create request.  The Printer might not be able to compute this
       value (if not supplied by the client in the Send-Document request.

                        June 3, 1997, Expires December 3, 1997
           Attribute       Man
                            ?

       document-name       Man
       (name)

       document-format
       (type2 keyword

       document-URI
       (uri)

       6.4.1     document-name(name, Mandatory)

       This attribute contains the name of the document used by request) at the client to
       initially identify time the document. When a client prints by reference, i.e.
       includes Job
       is created.  If not, the document-URI attribute and no document content, Printer may support this attribute shall be absent. When a document's contents are spread across
       multiple Send Document operations "document-name" at any later
       time as it is ignored by able to compute the
       Printer in all but total size of the first Send-Document operation.

       6.4.2     document-format (type2 keyword) Job.

                       June 23, 1997, Expires December 23, 1997
       6.2.20 job- media-sheets (integer(0:2**31 - 1))

       This job attribute defines specifies the document format total size of this document. When a
       client prints by reference, i.e. includes the document-URI attribute and
       no document content, this job in media-sheets.
       This attribute shall is not intended to be absent. When a document's
       contents are spread across multiple Send-Document operations, document-
       format is ignored by the Printer counter as in all but the first Send Document
       operation for that document.

       This attribute identifies the document format of this document.  One
       possible supported Job Monitoring
       MIB; it is intended to be useful routing and default scheduling information if
       known. The Printer SHALL try to compute the value if it is 'auto-sense'.  However, 'auto-
       sense' shall not be sent supplied
       in the Send-Document Request. creaet request.  The following standard values have been reviewed with the Printer
       Working Group and are registered with IANA as part of the IETF Printer
       MIB project.  The standard might not be able to compute this
       value assigned (if not supplied by the PWG starts with the
       four letters: "lang", client in order to follow SNMP ASN.1 rules that all enum
       symbols shall start with a lower case letter.  The keyword values in IPP
       shall be the same as request) at the PWG standard values registered with IANA with time the "lang" removed.  The MIB (integer) value Job
       is included here for

                        June 3, 1997, Expires December 3, 1997
       reference only, the MIB integer value shall not be used in IPP;  the
       keyword value shall be used instead:

       Note:  In created.  If not, the protocol specification [22], these keywords will be
       encoded as MIME types.

       6.4.3     document-URI (uri)

       This Printer may support this attribute contains the URI of the document when the document
       content at any later
       time as it is not included in able to compute the Send Document operation.  Document-number
       is total size of the only other attribute allowed when a document-URI attribute is
       present in a Send Document operation.

       6.5  Printer Attributes

       The attributes in this section are associated with a Printer object.

       6.5.1     Printer Job.

       6.3 Job Template Description Attributes

       The Job Template attributes which apply specifically to a Printer object
       are described in this section 6.2  Job Template Attributes.

       These Printer attributes form the attribute group named "printer-job-
       template".

       6.5.2     Printer Description  Attributes

       These attributes form called "job-
       description".  The following table summarizes these attributes.  The
       third column indicates whether the attribute group called "printer-description".

       A Printer object may be realized in either is a print server or output
       device. Note: How these attributes are set by an Administrator MANDATORY attribute.
       If it is
       outside the scope of this specification.

            Attribute         Man?

       printer-URI           Man
       (uri)

       printer-name          Man
       (name) not MANDATORY, then it is OPTIONAL.

                       June 3, 23, 1997, Expires December 3, 23, 1997
       printer-location
       (text)

       printer-description
       (text)

       printer-more-info-
       site
       (uri)

       printer-driver-
       installer
       (uri)

       printer-make-and-
       model
       (text)

       maximum-printer-
       speed
       (integerUnits)

       printer-more-info-
       manf
       (uri)

       printer-state         Man
       (type1 keyword)

       printer-state-        Man
       reasons
       (type2 keyword)

       printer-is-           Man
       accepting-job
       (boolean)s

       printer-state-
       message
       (text)

       queued-job-count
       (int)

       printer-message-
       from-operator

                        June 3, 1997, Expires December 3, 1997
       (text)

       printer-locale        Man
       (locale)

       printer-locales-      Man
       supported
       (1setOf locale)

       multiple-documents-
       are-supported
       (boolean)

       6.5.2.1   printer-URI
       +----------------------------+----------------------+----------------+
       |      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        |  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     | integer              |                |
       +----------------------------+----------------------+----------------+
       | job-impressions-completed  | integer              |                |
       +----------------------------+----------------------+----------------+
       | job-media-sheets-completed | integer              |                |
       +----------------------------+----------------------+----------------+

       6.3.1 job-uri (uri)

       This attribute contains the URI for the printer.  An administrator shall
       determine job.  The Printer, on receipt of
       a new job, SHALL generate a printer's URI and shall set this which identifies the job on the Printer.
       The Printer, SHALL return the value of the "job-uri" attribute as part
       of the response to that URI. a create request.   The precise format of a printer job URI shall
       SHALL be implementation dependent.

       6.5.2.2   printer-name

                       June 23, 1997, Expires December 23, 1997
       6.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 job-originating-user (name)

       This attribute contains specifies the user name of the printer. It is a name that is
       more user friendly than person submitting the printer-URI. An administrator shall
       determine a printer's name and shall
       print job.  The Printer SHALL set this attribute to that name.
       This the most authentic
       name may be that it can obtain from the last part of protocol over which the printer's URI or it may be
       unrelated. In non-US-English locales, a name may contain characters that
       are not allowed in a URI.

       6.5.2.3   printer-location (text) operation was
       received from the client.

       6.3.4 job-originating-host (name)

       This attribute identifies the location originating host of the job. The Printer
       SHALL set this printer.

       6.5.2.4   printer-description (text)

       This attribute identifies to the descriptive information about most authentic host name it can obtain
       from the this
       Printer. protocol over which the operation was received from  the
       client.

       6.3.5 user-locale (type3 keyword)

       This could include things like: "This printer can be used for
       printing color transparencies for HR presentations", or "Out attribute identifies the locale of courtesy
       for others, please print only small (1-5 page) jobs at the job, i.e, the country,
       language, and coded character set. The Printer sets this printer", or
       even "This printer is going away on July 1, 1997, please find a new
       printer".

                        June 3, 1997, Expires December 3, 1997
       6.5.2.5   printer-more-info-site (uri)

       This attribute contains a URI used to
       the most authentic value it can obtain more information about this
       specific printer.  The information obtained from this URI is intended
       for end user consumption. Features outside the scope of IPP can be
       accessed protocol over which the
       Print operation was received from this URI.  The information is intended to be specific to
       this printer instance and site services (e.g. job pricing, services
       offered, end user assistance). the client.

       The manufacturer may initially populate Printer SHALL use this attribute.

       6.5.2.6   printer-driver-installer (uri)

       This attribute contains a URI to use to locate determine the driver installer locale for
       this printer.
       notification messages 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 attribute is intended for consumption by automata.
       The mechanics of print driver installation is outside the scope of IPP.
       The manufacturer may initially populate this attribute.

       6.5.2.7   printer-make-and-model (text)

       This attribute identifies the make and model of attributes specifies supplemental information about the printer.

       ISSUE: Several comments that we should break this up into two
       attributes. Job State
       in human readable text.  It is just a text string, so it could really SHALL be anything.

       6.5.2.8   maximum-printer-speed (integerUnits) set by the Printer.

       6.3.9 output-device-assigned (name)

       This attribute indicates identifies the maximum printer speed of Output Device to which the Printer in
       units of pages per minute, impressions per minute, lines per minute, and
       characters per second. A job cannot control a Printer's speed, but a
       Printer Browser can use printer speed as a criteria.

       The standard units are a type2 setOf keyword : ppm, ipm, spm, lpm, and
       cps.  These  mean pages per minute, impressions per minutes, sides per
       minutes, lines per minute, and characters-per-second, respectively.

       6.5.2.9   printer-more-info-manf (uri)

       This attribute contains a URI used to obtain more information about this
       type of printer.  The information obtained from has
       assigned this URI is intended for
       end user consumption.  Features outside the scope of job.  If an output device implements an embedded IPP can be accessed
       from this URI (e.g., latest firmware, upgrades, print drivers, optional
       features available).  The information is intended to be germane to
       Printer, the Printer NEED NOT set this
       printer without regard to site specific modifications or services. attribute.  If a Print Server

                       June 3, 23, 1997, Expires December 3, 23, 1997
       6.5.2.10  printer-state (type1 keyword)
       implements a Printer, the value MAY be empty until the Printer assigns
       an output device to the job.

       6.3.10 time-since-pending (milliseconds)

       This attribute identifies indicates the current state amount of time that has passed since the printer.  The
       printer-state reasons attribute augments
       Job was first put into the printer-state pending state..

       6.3.11 time-since-processing (milliseconds)

       This attribute to
       give more detailed information about indicates the Printer is in amount of time that has passed since the given printer
       Job first entered the processing state.

       The protocol shall support all values for printer states. A Printer
       shall continually keep this

       6.3.12 time-since-completed (milliseconds)

       This attribute set to indicates the value in amount of time that has passed since the table
       below which most accurately reflects
       Job was completed.

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

       This attribute indicates the state number of the Printer.

       The following standard values jobs that are defined:

            unknown     The Printer state "ahead" of this job
       in the current scheduled order.  For efficiency, it is not known, or only necessary to
       calculate this value when an operation is
                        indeterminate. A Printer shall use performed that requests this state only
       attribute.

       Note: This attribute is necessary since an end user may request just
       their own jobs and they need some relative position indicator if it cannot
                        determine its actual state.

            idle        If a Printer receives a job (whose
                        required resources there
       are ready) while other jobs interspersed in this state, such a job shall
                        transit into the processing state
                        immediately.

                        If waiting list which are not returned
       in the printer-state-reasons
                        attribute contains any reasons, they
                        shall response or cannot be reasons that would not
                        prevent because of site security policy
       restrictions.

       6.3.14 job-message-from-operator (text)

       This attribute provides a job message from transiting into an operator, system administrator
       or "intelligent" process to indicate to the processing state immediately,
                        e.g., toner-low.

                        Note: if a Printer controls more than
                        one output device, end user the above
                        definition implies that reasons for
       modification or other management action taken on a Printer is
                        idle if at least one output device is
                        idle.

                        June 3, 1997, Expires December 3, 1997
            processing  If a Printer receives a job (whose
                        required resources are ready) while job.

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

       This attribute specifies the number of octets completed in this state, such K octets,
       i.e., in units of 1024 octets.  The value SHALL be rounded up, so that a
       job shall
                        transit into the pending state
                        immediately. Such between 1 and 1024 octets SHALL be indicated as being 1K, 1025 to
       2048 SHALL be 2, etc. This attribute is intended 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 shall transit
                        into attribute specifies the processing state only after
                        jobs ahead number of it complete printing.

                        If the printer-state-reasons impressions completed. This
       attribute contains any reasons, they
                        shall is intended to be reasons that do not prevent a counter as in the current Job Monitoring MIB.

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

       This job from printing, e.g.
                        toner-low.

                        Note: if attribute specifies the media-sheets completed. This attribute
       is intended to be a Printer controls more than
                        one output device, counter as in the Job Monitoring MIB.

       ISSUE: Should the above
                        definition implies that a Printer is
                        processing if at least one output
                        device three attributes be regularly named as job-size-
       in-xxx-yyy where xxx is processing, k-octets, impressions and none media sheets and where
       yyy is
                        idle.

            stopped     If a Printer receives a job (whose
                        required resources are ready) while
                        in this state, such a job shall
                        transit into the pending state
                        immediately. Such a job shall transit
                        into the pending, 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 completed. So job-impressions
       becomes job-size-in-impressions-pending and job-impressions-completed is
       job-size-in-impressions-processing while printing and job-size-in-
       impressions-completed  when the current
                        job or transiting a pending job to completed. Thus job-impressions-
       completed doesn't serve two functions.

       6.4 Document Attributes

       This group of attributes describes the processing state.

                        Note: if a Printer controls more than
                        one output device, document data for the above
                        definition implies that a Printer is
                        stopped only if all output devices job.  For
       single-Document Jobs, they are stopped.

       Note: In supplied in the case where a Printer controls more than one output device,
       it is tempting to define stopped as when a sufficient number of output
       devices Print-Job or Print-URI
       requests.  For multi-Document Jobs, they are stopped and leave it to an implementation supplied in each Send-
       Document or Send-URI request.

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

       6.4.1 document-name (name)

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

       6.4.2 document-format (type2 keyword)

       See section 6.2.16 which describes "document-format" as a Job Template
       attribute.

                       June 3, 23, 1997, Expires December 3, 23, 1997
       sufficient number.  But such a rule complicates
       6.4.3 document-uri (uri)

       This attribute contains the definition of
       stopped and processing. For example, with this alternate definition URI of
       stopped, a job can move from idle to processing without human
       intervention, even though the Printer document when the document
       content is stopped.

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

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

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

         - 'report':  it has the adornment of "report". An implementation may
            choose to omit some or all reports. Some reports specify finer
            granularity about the printer state; others serve as a precursor to
            a warning. A report shall contain nothing that could affect not included in the
            printed output.
         - 'warning': it has Send Document operation.  Document-number
       is the adornment of "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 only other attribute allowed when a job
            from completing, though in some cases the output may be of lower
            quality.
         - 'error': it has no adornment. An implementation shall include all
            errors. If this document-URI attribute contains one or more errors, printer
            shall be is
       present in the stopped state. a Send Document operation.

       ISSUE: How do Now that we indicate report, warning, or error without adornments?
       Proposal add a parallel attribute to print-state-reasons have Print-URI and name it
       "printer-state-reasons-severity-level".  The ith element of the reasons
       attribute has the severity level of Send-URI, do we still need this?
       Do we allow for the ith element query of this attribute via Get-Attributes?

       6.5 Printer Description Attributes

       These attributes form the severity
       level attribute.  Another proposal:  an implementation attribute group called "printer-description".
       A Printer object may add 'error-',
       'warning-', or 'report-' to any of the reasons to indicate the level of
       severity.

       ISSUE: Toner-low should be a warning because it allows printing to
       proceed, but realized in some printers, toner-low may also produce degraded
       output. Do we want a fourth category, perhaps severe-warning which
       allows a job to continue printing but with reduced quality?

       If either a Printer controls more than one print server or output device, each value
       device.  Note: How these attributes are set by an Administrator is
       outside the scope of this specification.  The following table summarizes
       these attributes, their syntax, and whether or not they are MANDATORY.
       If they are not MANDATORY, they are OPTIONAL.

                       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 shall apply to one more of contains the output devices. An error on one
       output device that does not stop URI for the Printer as a whole appears as printer.  An administrator SHALL
       determine a
       warning in the Printer's printer-state-reasons attribute. Such printer's URI and SHALL set this attribute to that URI. The
       precise format of a
       Printer's printer-state value may printer URI SHALL be stopped even 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 no printer-state-
       reasons more information about this printer.

       6.5.3 printer-name (name)

       This attribute contains the name of the printer. It is a name that is
       more user friendly than the printer-URI. An administrator SHALL
       determine a printer's name and SHALL set this attribute to that name.
       This name may be the last part of the printer's URI or it may be
       unrelated. In non-US-English locales, a name may contain characters that
       are errors. not allowed in a URI.

       6.5.4 printer-location (text)

       This attribute identifies the location of this printer.

       6.5.5 printer-description (text)

       This attribute identifies the descriptive 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)

       This attribute contains a URI used to obtain more information about this
       specific printer.  The following standard values are defined: information obtained from 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 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)

       This attribute contains a URI to use to locate the driver installer for
       this printer.   This attribute is intended for consumption by automata.
       The mechanics of print driver installation is outside the scope of IPP.
       The printer manufacturer may initially populate this attribute.

       6.5.8 printer-make-and-model (text)

       This attribute identifies the make and model of the printer.

                       June 23, 1997, Expires December 23, 1997
       6.5.9 printer-more-info-manufacturer (uri)

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

       6.5.10 printer-state (type1 keyword)

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

       A Printer SHALL continually keep this attribute set to the value in the
       table below which most accurately reflects the state 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':  The Printer state is not known, or is indeterminate. A
            Printer SHALL use this state only if it cannot determine its actual
            state.

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

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

         'stopped':  If a Printer receives a job (whose required resources are
            ready) while 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 Printer controls more than one output device, the above
            definition implies that a Printer is stopped only if all output
            devices are stopped.  Also, it is tempting to define stopped as
            when a sufficient number of output devices are stopped and leave it
            to an implementation to define the sufficient number.  But such a
            rule complicates the definition of stopped and processing. For
            example, with this alternate definition of stopped, a job can move
            from idle to processing without human intervention, even though the
            Printer is stopped.

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

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

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

         - 'report':  it has the adornment of "report". An implementation may
            choose to omit some or all reports. Some reports specify finer
            granularity about the printer state; others serve as a precursor to
            a warning. A report SHALL contain nothing that could affect the
            printed output.
         - 'warning': it has the adornment of "warning". An implementation may
            choose to omit some or all warnings. Warnings serve as a precursor
            to an error. A warning SHALL contain nothing that prevents a job
            from completing, though in some cases the output may be of lower
            quality.
         - 'error': it has no adornment. An implementation SHALL include all
            errors. If this attribute contains one or more errors, printer
            SHALL be in the stopped state.

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

       If a Printer controls more than one output device, each value of this
       attribute SHALL apply to one or more of the output devices. An error on
       one output device that does not stop the Printer as a whole appears as a
       warning in the Printer's printer-state-reasons attribute. Such a
       Printer's printer-state value may be stopped even with no printer-state-
       reasons 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 a media jam.
         'paused': Someone has paused the Printer. In this state, a Printer
            SHALL not produce printed output, but it SHALL perform other
            operations requested by a client. If a Printer had been printing a
            job when the Printer was paused, the Printer SHALL resume printing
            that job when the Printer is no longer paused and leave no evidence
            in the printed output of such a pause.
         'shutdown': Someone has removed a Printer from service, and it may be
            powered down or physical removed. In this state, a Printer SHALL
            not produce printed output, and unless the Printer is realized by a
            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 is
            no longer shutdown. If the Printer resumes printing such a job, it
            may leave evidence in the printed output of such a shutdown, e.g.
            the part printed before the shutdown may be printed a second time
            after the shutdown.

         ISSUE: Bob suggests:  From an English point 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': The server has scheduled a job on the Printer
            and is in the process of connecting to a shared network output
            device (and might not be able to actually start printing the job
            for an arbitrarily long time depending on the usage of the output
            device by other servers on the network).
         'timed-out': The server was able to connect to the output device (or
            is always connected), but was unable to get a response from the
            output device.
         'stopping': The printer will be stopping in a while and will change
            its reason to printer-stopped. This reason is a non-critical, even
            for a Printer with a single output device. When an output-device
            ceases accepting jobs, the Printer will have this state while the
            output device completes printing.
         'stopped-partly': When 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 are stopped. If the reason is a warning, fewer than all of
            the output devices are stopped.
         'toner-low': The Printer is low on toner.

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

       This attribute determines whether the printer is currently accepting
       job.  If the value is true, the printer is accepting jobs. If the value
       is false, the printer is currently rejecting any jobs submitted to 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 reject jobs
       when the printer-state is idle or it may cause the Printer to accepts
       jobs when the printer-state is stopped.

       6.5.13 printer-state-message (text)

       This attribute specifies the additional information about the printer
       state in human readable text and it SHALL be set by the Printer (or the
       Administrator by some mechanism outside the scope of IPP). When a
       Printer returns the value of this attribute to a client, the Printer
       SHALL localize the value of this attribute to be in the locale of the
       user, as specified by the Get-Attributes or Get-Jobs operation.

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

       This attribute contains a count of the number of jobs that are either
       pending and/or processing and SHALL be set by the Printer.

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

       This attribute provides a message from an operator, system administrator
       or "intelligent" process to indicate to the end user information or
       status of the printer, such as why it is unavailable or when it is
       expected to be available.

       6.5.16 printer-locale (locale)

       This attribute specifies the current locale that the 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 the Printer is capable of any type of
       color printing at all.  All document instructions having to do with
       color are embedded within the document PDL (none are external IPP
       attributes).

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

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

       7.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 6.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 8.  Clients may choose to
       ignore any attributes that it does not understand.

       7.3 Printer Object Conformance Requirements

       This section specifies 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 Printer implementations SHALL implement all of the model
       objects as defined in this specification in the indicated sections:

         Section 4.1 Printer Object
         Section 4.2 Job Object
         Section 4.3 Document Object

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

       7.3.3 Attributes

       ISSUE:  Some Printer attributes are purely software, so that
       Conditionally Mandatory doesn't apply, such as Printer Description
       Attributes.  For example, what does it mean for the "printer-location"
       to be Conditionally Mandatory?  Should we add a "OPTIONAL" in the header
       of the few attributes for which Conditionally Mandatory doesn't make
       sense?

       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 that represent features and behaviors that the actual output
       device implements.

                       June 23, 1997, Expires December 23, 1997
       It is not required that a conforming Printer support all values of all
       supported attributes.  For example, if a Printer supports some of the
       "finishing" attribute values in this document, it is not required that a
       Printer implement or support all finishing methods indicated by all the
       values of the "finishing" attribute contained in this document.

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

       7.3.4 Printer extensions

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

       7.3.5 Attribute Syntaxes

       A Printer SHALL be able to accept any of the attribute syntaxes defined
       in Section 6.1 in any operation in which a client may supply attributes.
       Furthermore, a Printer SHALL return attributes to the client in
       operation responses that conform to the syntax specified in Section 6.1.

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

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

       IPP is explicitly designed to be extensible.  Additional attributes can
       be proposed to be registered by going through the type 2 or type 3
       keyword process which will register their specification after approval
       with IANA.  In addition specific implementation instances may support
       not only 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 attribute semantics already in this specification.

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

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

                       June 23, 1997, 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 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.

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

       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

            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

                       June 23, 1997, 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 - 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.

                       June 3, 23, 1997, Expires December 3, 23, 1997
            stopped-partly      When a Printer controls more than
                                one output device, this reason
                                indicates that one or more output
                                devices are stopped. If
       12. APPENDIX A - Status Codes

       The Status keyword provides information on the
                                reason is a report, fewer than
                                half results of the output devices are
                                stopped. If the reason is a
                                warning, fewer than all request. The
       Message provides a short textual description of the
                                output devices are stopped.
            media-needed        A tray has run out of media
            paper-jam Status. The printer has a paper jam.
            paused              Someone has paused Status
       is intended for use by automata and the Printer.
                                In this state, Message is intended for the
       human user.  An IPP application (i.e. a Printer shall browser, GUI, print driver or
       gateway) is not produce printed output, but
                                it shall perform other operations
                                requested by a client. If a
                                Printer had been printing a job
                                when the Printer was paused, required to examine or display the
                                Printer shall resume printing
                                that job when Message.

       The prefix of the Printer is no
                                longer paused and leave no
                                evidence in Status keyword defines the printed output class of
                                such a pause .
            shutdown            Someone has removed a Printer
                                from service, response as
       follows:

         informational - Request received, continuing process

         successful - The action was successfully received, understood, and it may
            accepted

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

         client-error - The request contains bad syntax or physical removed.
                                In this state, a Printer shall cannot be fulfilled

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

       IPP status codes are extensible.  IPP applications are not produce printed output, and
                                unless required to
       understand the Printer meaning of all registered status codes, though such
       understanding is realized obviously desirable.  However, applications shall
       understand the class of any status code, as indicated by
                                a print server the prefix, and
       treat any unrecognized response as being equivalent to the first  status
       code of that is still
                                active, class, with the Printer exception that an unrecognized response
       shall perform
                                no other operations requested not be cached.  For example, if an unrecognized status  code of
       client-error-foo-bar is received by
                                a the client, including returning
                                this value. If a Printer had been
                                printing a job when it was
                                shutdown, the Printer need not
                                resume printing can safely assume
       that job when the
                                Printer is no longer shutdown. If there was something wrong with its request and treat the Printer resumes printing such
                                a job, response
       as if it may leave evidence in
                                the printed output of such had received a
                                shutdown, e.g. client-error-bad-request status code.  In such
       cases, IPP applications should present the part printed
                                before Message to the shutdown may be
                                printed a second time after user, since
       that Message is likely to include human-readable information which will
       explain the unusual status.

       12.1 Status Codes (type2 keyword)

       Each Status is described below, including a description of which
       operation(s) it can follow and any metainformation required in the
                                shutdown..
       response.

                       June 3, 23, 1997, Expires December 3, 23, 1997
            connecting-to-      The server has scheduled
       12.1.1 Informational

       This class of status code indicates a job on
            printer             the Printer provisional response and is in the process
                                of connecting to a shared network
                                output device (and might not be
                                able to actually start printing
                                the job
       used for an arbitrarily long
                                time depending on the usage informational purposes only.  There are no status codes defined
       in IPP 1.0 for this class of status code.

       12.1.2 Successful Status Codes

       This class of status code indicates that the output device by other
                                servers on the network).
            timed-out           The server was able to connect to
                                the output device (or is always
                                connected), but client's request was unable to get
                                a response from the output device
                                in the time specified by the
                                printer's printer-timeout-period
                                attribute.
            stopping            The printer will be stopping in a
                                while
       successfully received, understood, and will change its reason
                                to printer-stopped. accepted.

       12.1.2.1 successful-OK (IPPL1)

       The request has succeeded.

       Note:  IPPL1 only includes OK.  IPPL1 does not include Created nor No
       Content successful status codes.  This reason is a non-critical, even for a
                                Printer consistent with a single output
                                device. When an output-device
                                ceases accepting jobs, our agreement
       at the
                                Printer will have IPP Model telecon on May 9, but I believe we had this state
                                while discussion
       before Bob Herriot joined the output device completes
                                printing.

       6.5.2.12  printer-is-accepting-jobs (boolean) telecon.

       12.1.3 Redirection Status Codes

       This attribute determines whether the printer is currently accepting
       job.  If the value is true, the printer is accepting jobs. If the value
       is false, the printer is currently rejecting any jobs submitted class of status code indicates that further action needs to it.

       Note: 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 Client Error Status Codes

       This value class of status code is independent intended for cases in which the client
       seems to have erred.  The server should return a Message containing an
       explanation of the printer state error situation and printer-state-
       reasons because its value does not affect the current job; rather whether it
       affects future jobs. This attribute may cause the Printer to reject jobs
       when the printer-state is idle a temporary or it may cause the Printer
       permanent condition.  IPP applications should display any returned
       Message to accepts
       jobs when the printer-state is stopped.

       6.5.2.13  printer-state-message (text)

       This attribute specifies the additional informaion about the printer
       state in human readable text and it shall end-user.  Unless otherwise noted, these status codes
       apply to all operations.

       12.1.4.1 client-error-bad-request (IPPL1)

       The request could not be set understood by the Printer (or server due to malformed
       syntax.  The IPP application should not repeat the
       Administrator by some mechanism outside request without
       modifications.

       12.1.4.2 client-error-unauthorized

       The request requires user authentication.  The IPP client may repeat the scope of IPP). When a
       Printer returns
       request with suitable authorization credentials. If the value of request already
       included authorization credentials, then this attribute to a client, status code indicates that
       authorization has been refused for those credentials.  If this response
       contains the Printer same challenge as the prior response, and the user agent

                       June 3, 23, 1997, Expires December 3, 23, 1997
       shall localize
       has already attempted authentication at least once, then the value of this attribute to user should
       be in the locale of the
       user, as specified by presented the Get-Attributes or Get-Jobs operation.

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

       This attribute contains a count of Message in the number of jobs response, since that are either
       pending and/or processing and shall be set Message may include
       relevant diagnostic information.

       12.1.4.3 client-error-payment-required

       This request requires payment by the Printer.

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

       This attribute provides a message from an operator, system administrator
       or "intelligent" process end-user to indicate perform the operation.

       12.1.4.4 client-error-forbidden (IPPL1)

       The server understood the request, but is refusing to fulfill it.
       Authorization will not help and the end user information or request should not be repeated.
       This status of code is commonly used when the printer, such as server does not wish to
       reveal exactly why it is unavailable the request has been refused or when it no other
       response is
       expected to be available.

       6.5.2.16  printer-locale (locale)

       This attribute specifies the current locale that applicable.

       12.1.4.5 client-error-method-not-allowed

       The operation specified in the Printer request is
       operating in.

       6.5.2.17  printer-locales-supported (1setOf locale)

       This attribute specifies the locales that the Printer operates in.

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

       7.1  Conditionally Mandatory

         For example, a conditionally mandatory attribute means that a Printer
         implementation need not implement allowed for the attribute if object
       identified by the attribute
         controls request URI.

       12.1.4.6 client-error-timeout (NEW)

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

       12.1.4.7 client-error-not-found

       The server has not implement found anything matching the request URI.  No
       indication is given of whether the condition is temporary or
         expose.  For example, for permanent.

       In practice, an output device that can only print on one
         side, application should avoid this situation by presenting a
       list of valid Printer need not implement URIs and Job URIs to the "sides" attribute.  For an
         output device that does not support any of end-user.

       12.1.4.8 client-error-gone

       The requested object is no longer available at the finishing attribute
         values, a Printer need not implement server and no
       forwarding address is known.  This condition should be considered
       permanent.  Clients with link editing capabilities should delete
       references to the "finishing" attribute.  An
         implementation that request URI after user approval.  If the server does
       not allow for 'not-ready' supported values
         in addition know or has no facility to 'ready' values, need determine,whether or not implement the corresponding
         "xxx-availability" Printer attribute.  For an output device with only
         a single input tray with only one media type in condition is
       permanent, the status code 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 tray, a Printer
         need not implement the "media" attribute. resource is
       intentionally unavailable and that the server owners desire that remote

                       June 3, 23, 1997, Expires December 3, 23, 1997
       7.2  Client Conformance Requirements

         There are
       links to that resource be removed.  Such an event is common for limited-
       time, promotional services and for resources belonging to individuals no conformance requirements placed on
       longer working at the user interfaces
         provided by IPP clients or their applications.  For example, one
         application might server's site.  It is not allow an end user necessary to submit multiple documents
         per job, while another does.  One application might first query a
         Printer object in order mark all
       permanently unavailable resources as "gone" or to supply keep the mark for any
       length of time -- that is left to the discretion of the server owner.

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

       The server is refusing to process a graphical user interface (GUI)
         dialogue box with supported 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 default values whereas it
       receives a different
         application might not.

         When sending print job that exceeds that limit.

       12.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 Get-Attributes or Create-Job request, client has improperly submitted a request
       with long query information (e.g. an IPP client
         need not supply any attributes.

         A client shall be able application allows an end-user
       to accept any of enter an invalid URI), when the attribute syntaxes
         defined in Section 0 that may be returned to it in client has descended into a response from URL
       "black hole" of redirection (e.g., a
         Printer

         ISSUE: Are there any attributes redirected URL prefix that are mandatory for a client points
       to
         set in a Print request?

         A query response may contain attributes and values that the client
         does not implement suffix of itself), or expect.  Therefore, when the server is under attack by a client implementation
         must gracefully handle such responses and not refuse
       attempting to interoperate
         with a conforming Printer that is returning extended registered exploit security holes present in some servers using
       fixed-length buffers for reading or
         private attributes and/or attribute values that conform to Section 8.
                        IANA Considerations, Registered Extensions, Private
         Extensions.  Some clients may choose to ignore any attributes that it
         does not implement.

       7.3  Printer Object Conformance Requirements

         This section specifies manipulating the conformance requirements for conforming
         Printer object implementations with respect Request-URI.

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

       The server is refusing to objects, operations,
         and attributes.

       7.3.1     Objects

         Conforming Printer implementations shall implement all of service the model
         objects as defined request because the print data is
       in this specification a format, as specified in document-format, not supported by the indicated sections:

            Section 0 4.1  Printer Object
            Section 0 4.2  Job Object
            Section 0 4.3  Document Object
       7.3.2     Operations

         Conforming Printer implementations shall implement all of IPP
       Printer.

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

       For a Create-Job, Print-Job or Validate operation, if the model
         operations, including mandatory responses, as defined in this
         specification IPP Printer
       does not support at least one attribute value specified in the indicated sections:

                        June 3, 1997, Expires December 3, 1997
            Section 0
            Section Job 0 5.1.4 Cancel Job Operation
            Section 0 5.1.5     Get-Attributes Operation
            Section 0 5.1.6     Get-Jobs Operation
       7.3.3     Attributes

         ISSUE:  Some request,
       the Printer attributes are purely software, so shall return this status.  For example, if the request
       requires A4 paper and that
         Conditionally Mandatory doesn't apply, such as paper size is not supported by the Printer,
       the Printer Description
         Attributes. shall return this status.

       For example, what a Get-Jobs operation, if the IPP Printer does it mean not support at least
       one attribute value for the "printer-
         location" to be Conditionally Mandatory?  Should we add a "OPTIONAL" Job Owner and/or Job States in the header of request, the few attributes for which Conditionally Mandatory
         doesn't make sense?

         Conforming
       Printer implementations shall implement all of the
         mandatory attributes, as defined in return this specification in the
         indicated sections.  Mandatory status.

       In practice, an IPP application should avoid this situation by querying
       an IPP Printer for its valid attributes are indicated as
         "MANDATORY" in and values before performing an
       operation on the header of each sub-section Printer.

                       June 23, 1997, Expires December 23, 1997
       12.1.5 Server Error Status Codes

       This class of Section 0 that
         specifies the attribute status codes indicates cases in which the server is copied into aware
       that it has erred or is incapable of performing the Table request.  The server
       should include a Message containing an explanation of Contents:

         ISSUE: What if this list differs from the headers, which wins?
         Wouldn't it be safer error
       situation, and more compact to replace the above list with whether it is a reference temporary or permanent condition. IPP
       applications should display any included Message to section 6 attributes that the user. These
       response codes are flagged as MANDATORY in applicable to any operation.

       12.1.5.1 server-error-internal-server-error

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

       12.1.5.2 server-error-operation-not-implemented

       The server does not support the header line (and automatically copied functionality required to fulfill the Table of Contents)?

         Conforming Printer implementations shall implement all conditionally
         mandatory attributes in Section 0, i.e.,
       request. This is the additional Job and
         Printer attributes that represent features that appropriate response when the output device
         implements.

         It server does not
       recognize an operation and is not required that a conforming Printer implement or support all
         values capable of all implemented attributes.  For example, if supporting it for any
       object.

       12.1.5.3 server-error-service-unavailable

       The server is currently unable to handle the request due to a Printer
         supports some temporary
       overloading or maintenance of the "finishing" attribute values in this document,
         it server.  The implication is not required that this
       is a Printer implement or support all finishing
         methods indicated by all temporary condition which will be alleviated after some delay. If
       known, the values length of the "finishing" attribute
         contained delay may be indicated in this document. the Message.  If no
       delay is given, the IPP application should handle the response as it
       would for a Printer implements server-error-internal-server-error response.

       12.1.5.4 server-error-timeout (NEW)

       The server did not produce a "xxx-supported" attribute it must implement response within the corresponding "xxx" default value attribute and vice versa.

       7.3.4     Default Value

         If time that the output device itself 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 the concept of a default
         value support, or refuses to support, the output device's default value HTTP protocol
       version that was used in the request message.  The server is indicating
       that it is unpredictable, unable or
         unknown, unwilling to complete the implementation of request using the Printer shall always supply its
         default value to same
       major version as the physical device each time client other than with this error message.  The
       response SHOULD contain a message describing why the Printer submits version is not
       supported and what other protocols are supported by that server.

                       June 3, 23, 1997, Expires December 3, 23, 1997
       12.1.5.6 server-error-IPP-version-not-supported

       The server does not support, or refuses to support, the job IPP protocol
       version that was used in the request message. The server is indicating
       that it is unable or unwilling to complete the output device. request using the same
       major  version as the client other than with this error message. The default value specified by
       response should contain a
         Printer shall not be 'unknown'.

       7.3.5     Availability

         Conforming implementation need not implement the "xxx-available"
         attributes since if an "xxx-supported"  printer attribute does Message describing why that version is not
         have have an associated "xxx-available" Printer attribute, all
       supported values shall be 'ready'.

       7.3.6     Printer extensions and what other versions are supported by that server.

       A conforming Printer may implement registered extensions and private
         extensions, as long as they meet IPP client shall specify the requirements specified in
         Section 8.     IANA Considerations, Registered Extensions, Private
         Extensions.

       7.3.7     Attribute Syntaxes valid version for IPP 1.0 on
       each request.  A Printer conforming IPP server shall be able not return this status code
       to accept any of the attribute syntaxes
         defined in Section 0 in any operation in which a client may supply
         attributes.  Furthermore, a Printer conforming IPP 1.0 client.  An IPP server shall return attributes to the
         client in operation responses that conform this status
       code to a non-conforming IPP client.

       12.1.5.7 server-error-printer-error

       A printer error, such as a paper jam, occurs while the syntax specified in
         Section 0.

       7.4  Security Conformance Requirements IPP Printer
       processes a Print or Send operation.  The security mechanisms being considered for response shall contain the Job
       Status with the specific error and should contain a Message describing
       the error.  An IPP fall outside application should check the Job Status in the
       response for the
         scope specific error.

       12.1.5.8 server-error-write-fault

       A write error, such as a memory overflow (i.e. the document data exceeds
       the memory of the application layer protocol itself.  There are two
         mechanisms used to begin secure communications using IPP:

         1. Information in Printer) or a disk full condition, occurs while the directory entry for an
       IPP Printer (or from
         additional information at processes a Web site hosting the Print or Send operation.

                       June 23, 1997, Expires December 23, 1997
       12.2 Mapping of HTTP 1.1 Status Codes to IPP Priner) indicate
         which, if any, security protocols are used in conjunction with IPP.

         2. 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, Expires December 23, 1997
       none                               server-error-printer-error
       none                               server-error-write-fault

       12.3 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                x  x  x  x  x  x 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                   x  x  x  x  x  x x  x  x  x
       client-error-method-not-allowed          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
       client-error-request-URI-too-long        x  x  x  x  x  x x  x  x  x
       client-error-unsupported-media-type      x  x     x  x
       client-error-attribute-value-not-        x  x  x        x
            supported
       server-error-internal-server-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               x  x  x  x  x
       server-error-write-fault                 x  x  x  x  x

       13. APPENDIX B - "document-format" Values

       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.

       8.   IANA Considerations, Registered Extensions, Private Extensions

         IPP is explicitly designed to be extensible.  Additional attributes
         can be proposed to be registered by going through the type 2 or type
         3 keyword process which will register their specification after

                        June 3, 1997, Expires December 3, 1997
         approval with IANA.  In addition specific implementation instances
         may support not only the basic protocol as defined in this
         specification, but may add vendor-specific private extensions by
         prefixing attribute-names with their company name Working Group has registered with
         IANA for use in domains.  See attribute syntax section.  However,
         such private extensions shall not duplicate attribute semantics
         already in this specification.

       9.   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 a set of IPP on top values with IANA as
       part 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 the IETF Printer may choose, for security reasons, not MIB project.  The standard value assigned by
       the PWG starts with the four letters: "lang", in order to return all
         attributes follow SNMP
       ASN.1 rules that all enum symbols SHALL start with a client requests. It may even return none of the
         requested attributes. In such cases, the status returned lower case letter.
       The keyword values in IPP is the same as if the Printer had returned all requested attributes. PWG standard values
       registered with IANA with the "lang" removed.  The client
         cannot tell by such a response whether MIB (integer) value
       is included here for reference only, the requested attribute was
         present or absent on MIB integer value SHALL NOT be
       used in IPP; 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 keyword value SHALL be used.  In 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), Final, June
            1996.

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

       [7]  Kirk, M. (editor), POSIX System Administration - Part 4: Printing
            Interfaces, POSIX 1387.4 D8, 1994. [22], the keyword value SHALL be encoded as a MIME type.

                       June 3, 23, 1997, Expires December 3, 23, 1997
       [8]  Borenstein, N.,
       The standard values are:

         'other': 1 -
         'PCL': 3 - PCL.  Starting with PCL version 5, HP-GL/2 is included as
            part of the PCL language.  PCL and Freed, N., "MIME (Multi-purpose Internet Mail
            Extensions) Part One: Mechanism HP-GL/2 are registered
            trademarks of Hewlett-Packard Company.
         'HPGL': 4 - Hewlett-Packard Graphics Language.  HP-GL is a registered
            trademark of Hewlett-Packard Company.
         'PJL': 5 - Peripheral Job Language.  Appears in the data stream
            between data intended for Specifying a page description language.  Hewlett-
            Packard Co.
         'PS': 6 - PostScript Language (tm) Postscript - a trademark of Adobe
            Systems Incorporated which may be registered in certain
            jurisdictions
         'IPDS': 7 - Intelligent Printer Data Stream Bi-directional print data
            stream for documents consisting of data objects (text, image,
            graphics, bar codes), resources (fonts, overlays) and Describing page, form
            and finishing instructions.  Facilitates system level device
            control, document tracking and error recovery throughout the print
            process.  Pennant Systems, IBM
         'PPDS': 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': 9 - Epson Corp.
         'Epson': 10 -
         'DDIF': 11 - Digital Document Interchange Format of Internet Message Bodies", RFC 1521, September, 1993.

       [9]  Braden, S., "Requirements Digital Equipment
            Corp., Maynard MA
         'Interpress': 12 - Xerox Corp.
         'ISO6429': 13 - ISO 6429.  Control functions for Internet Hosts Coded Character Sets
            (has ASCII control characters, plus additional controls for
            character imaging devices.) ISO Standard, Geneva, Switzerland
         'LineData': 14 - 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 line-data: Lines of data as separate ASCII or EBCDIC
            records and Semantics (This document)

       [22] Internet Printing Protocol/1.0: Security

       [23] Internet Printing Protocol/1.0: Protocol Specification

       [24] Internet 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 Protocol/1.0: Directory Schema

       [25] S. Bradner, "Key words Application (DPA) ISO standard, Geneva, Switzerland
         'MODCA': 15 - Mixed Object Document Content Architecture Definitions
            that allow the composition, interchange, and presentation of final
            form documents as a collection of data objects (text, image,
            graphics, bar codes), resources (fonts, overlays) and page, form
            and finishing instructions.  Pennant Systems, IBM
         'REGIS': 16 - Remote Graphics Instruction Set, Digital Equipment
            Corp., Maynard MA
         'SCS': 17 - SNA Character String Bi-directional print data stream for use in RFCs to Indicate Requirement
            Levels", RFC 2119 , March 1997

       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
            701 S. Aviation Blvd.
            El Segundo, CA   90245

            Phone: 310-333-6413
            Fax:   310-333-5514
            EMail: hastings@cp10.es.xerox.com
            SNA LU-1 mode of communications IBM
         'SPDL': 18 - ISO 10180 Standard Page Description Language ISO
            Standard
         'TEK4014': 19 - Tektronix Corp.

                       June 3, 23, 1997, Expires December 3, 23, 1997
            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  92123

            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
         'PDS': 20 - Tektronix
            Jeff Barnett
         'IGP': 21 - IBM
            Ron Bergman Printronix Corp.
         'CodeV': 22 - Magnum Code-V, Image and printer control language used
            to control impact/dot- matrix printers.  QMS, Inc., Mobile AL
         'DSCDSE': 23 - DSC-DSE: Data Products
            Keith Carter, Stream Compatible and Emulation Bi-
            directional print data stream for non-SNA (DSC) and SNA LU-3 3270
            controller (DSE) communications IBM Corporation
            Jeff Copeland
         'WPS': 24 - QMS
            Andy Davidson Windows Printing System, Resource based command/data
            stream used by Microsoft At Work Peripherals.  Developed by the
            Microsoft Corporation.
         'LN03': 25 - Early DEC-PPL3, Digital Equipment Corp.
         'CCITT': 26 -
         'QUIC': 27 - QUIC (Quality Information Code), Page Description
            Language for laser printers.  Included graphics, printer control
            capability and emulation of other well- known printer .  QMS, Inc.
         'CPAP': 28 - Common Printer Access Protocol Digital Equipment Corp
         'DecPPL': 29 - Digital ANSI-Compliant Printing Protocol (DEC-PPL)
            Digital Equipment Corp
         'SimpleText': 30 - simple-text: character coded data, including NUL,
            CR , LF, HT, and FF control characters.  See ISO 10175 Document
            Printing Application (DPA) ISO standard, Geneva, Switzerlan
         'NPAP': 31 - Network Printer Alliance Protocol (NPAP).  This protocol
            has been superseded by the IEEE 1284.1 TIPSI standard.  (ref.
            LangTIPSI(49)).
         'DOC': 32 - Tektronix
            Mabry Dozier Document Option Commands, Appears in the data stream
            between data intended for a page description .  QMS, Inc
         'imPress': 33 - QMS
            Lee Farrell 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 channel and supported early document preparation languages
            (e.g.  TeX and TROFF).  QMS, Inc.
         'Pinwriter': 34 - Canon Information Systems
            Steve Gebert 24 wire dot matrix printer for USA, Europe, and
            Asia except Japan.  More widely used in Germany, and some Asian
            countries than in US.  NEC
         'NPDL': 35 - IBM
            David Kellerman Page printer for Japanese market.  NEC
         'NEC201PL': 36 - Northlake Software
            Rick Landau Serial printer language used in the Japanese market.
            NEC
         'Automatic': 37 - Digital
            Harry Lewis Automatic PDL sensing.  Automatic sensing of the
            interpreter language family by the printer examining the document
            content.  Which actual interpreter language families are sensed
            depends on the printer implementation.
         'Pages': 38 - Page printer Advanced Graphic Escape Set IBM
            Pete Loya Japan
         'LIPS': 39 - LBP Image Processing System
         'TIFF': 40 - HP Tagged Image File Format (Aldus)
         'Diagnostic': 41 - A hex dump of the input to the interpreter

                       June 3, 23, 1997, Expires December 3, 23, 1997
            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
         'PSPrinter': 42 - Unisys
            Hiroyuki Sato The PostScript Language used for control (with any
            PDLs) Adobe Systems Incorporated
         'CaPSL': 43 - Canon
            Bob Setterbo - Adobe
            Devon Taylor, Novell, Inc.
            Mike Timperman Print Systems Language
         'EXCL': 44 - Lexmark
            Randy Turner Extended Command Language Talaris Systems Inc
         'LCDS': 45 - Sharp
            Atsushi Yuki Line Conditioned Data Stream Xerox Corporatio
         'XES': 46 - Kyocera
            Lloyd Young Xerox Escape Sequences Xerox Corporation
         'PCLXL': 47 - Lexmark
            Bill Wagner Printer Control Language.  Extended language features
            for printing, and printer control.  Technical reference manual #
            TBD.  Hewlett-Packard Co.
         'ART': 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': 49 - DPI
            Jim Walker Transport Independent Printer System Interface (ref.
            IEEE Std.  1284.1)
         'Prescribe': 50 - DAZEL
            Chris Wellens Page description and printer control language.  It
            can be described with ordinary ASCII characters.  Technical
            reference manual: "PRESCRIBE II Programming Manual"
         'LinePrinter': 51 - Interworking Labs
            Rob Whittle 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': 52 - Novell
            Don Wright Imaging Device Protocol Apple Computer.
         'XJCL': 53 - Lexmark
            Peter Zehler, Xerox, Xerox Corp.

       12.

       One special value is 'auto-sense'.  However a client SHALL NOT supply
       the value 'auto-sense' 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. APPENDIX C - "media" Values

       Standard values are taken from several sources.

       Standard values are defined(taken from ISO DPA and the Printer MIB):

         'default': The default medium for the output device
         '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 3, 23, 1997, Expires December 3, 23, 1997
       Change History

         This section will be deleted when
         'iso-b5-white': Specifies the document is forwarded to ISO B5 white medium
         'iso-b5-colored': Specifies the
         IESG to be considered 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 becoming an RFC. 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 changes following standard values are
         summarized in reverse chronological order.

       12.1 Changes made to version 970512, dated 12-May-1997 to make version
       970603, dated  03-June-1997.

       1. Removed defined for envelopes:

         'iso-b4-envelope': Specifies the idea of "default beahvior"

       2. Removed ISO B4 envelope medium
         'iso-b5-envelope': Specifies the idea of "best-effort" 'substitute-as-needed' and 'do-not-
       substitute'

       3. Deleted all of ISO B5 envelope medium
         'iso-c3-envelope': Specifies the definitions from section 3 and changed ISO C3 envelope medium
         'iso-c4-envelope': Specifies the figures

       4. Added references to RFC 2119 (standard conformance language) and
       started to capitalize all of ISO C4 envelope medium
         'iso-c5-envelope': Specifies the implementation requirement words such
       as SHALL, NEED NOT, MUST, etc.

       5. Removed font Printer attributes and scheduling algorithm

       6. Reformated all ISO C5 envelope medium
         'iso-c6-envelope': Specifies the of 6.2 (Job Template)

       7. Consolidated ISO C6 envelope medium
         'iso-designated-long-envelope': Specifies the 3 sections on Job Template down into just one
       section.

       8. Added attribute tables to be beginning of each first level section in
       6.0.  These tables show attribute name, syntax, and MAND/OPT/etc.

       9. Fixed ISO Designated Long
            envelope medium
         'na-10x13-envelope': Specifies the definitions for Implements and Supports

       10. Added Create-Job, Print-Job, and Send-Document operations

       11. Reformatted North American 10x13 envelope
            medium
         'na-9x12-envelope': Specifies the whole Operations section

       12. Reformatted most of North American 9x12 envelope medium
         'monarch-envelope': Specifies the Monarch envelope
         'na-number-10-envelope': Specifies the North American number 10
            business envelope medium
         'na-7x9-envelope': Specifies the North American 7x9 inch envelope
         'na-9x11-envelope': Specifies the North American 9x11 inch envelope
         'na-10x14-envelope': Specifies the North American 10x14 inch envelope
         'na-number-9-envelope': Specifies the North American number 9
            business envelope
         'na-6x9-envelope': Specifies the North American 6x9 inch envelope
         'na-10x15-envelope': Specifies the North American 10x15 inch envelope

       The following standard values sections for keyword
       attributes.  This needs to be finished are defined for the next rev of the document.

       13. Changed URL to URI.

       12.2 Changes made to version 970509, dated 9-May-1997 to make version
       970512, dated 12-May-1997.

         1. Replaced Print with Create-Job and Send-Document

         2. Added status codes (ok, error, and messages) less commonly used
       media (white-only):

                       June 3, 23, 1997, Expires December 3, 23, 1997
         3. Removed all "may not" language (replace with might not)

         4. Fixed attribute sections to show more detail

         5. Misc. typos and edits

       12.3 Changes made to version 2.2, dated 5-May-1997 to make version
       970509, dated 9-May-1997.

         1.
            Too many to mention.

       12.4 Changes made to version 2.1, dated 24-April-1997 to make version
       2.2, dated 5-May-1997.

         Added terminology to
         'executive-white': Specifies the conformance section for keyword, attribute,
         attribute name, attribute value(s), default, default behavior,
         availabilty.

         Removed most discussion about adornments and tags, except for
         embedded tag and job-state-reasons, report, warning, error tags.

         Moved Conformance description to white executive medium
         'folio-white': Specifies the appropriate operation sections,
         so that folio white medium
         'invoice-white': Specifies the Conformance section is a checklist with references to white invoice medium
         'ledger-white': Specifies the
         sections where white ledger medium
         'quarto-white': Specified the semantics are described.

         Changed white quarto medium
         'iso-a0-white': Specifies the job-size attributes into xxx-requested, xxx-completed Job
         attributes, and xxx-supported Printer attributes.

       12.5 Changes made to version 2.0, dated 26-March-1997 to make version
       2.1, dated 22-April-1997.

         1.
            Added terminology to ISO A0 white medium
         'iso-a1-white': Specifies the conformance section for supported and
            implemented.

       12.6 Changes made to version 1.8, dated 24-March-1997 to make version
       2.0, dated 26-March-1997.

         The following changes were made to version 1.8 to make version 2.0:

         1. Minor editing fixes

         2. Submitted 2.0 as draft-ietf-ipp-model-00.txt

       12.7 Changes made to version 1.7, dated 24-Mar-1997 to make version 1.8,
       dated 24-March-1997. 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 changes were made to version 1.7 to make version 1.8:

                        June 3, 1997, Expires December 3, 1997
         1. Minor editing fixes

       12.8 Changes made to version 1.6, dated 12-Mar-1997 to make version 1.7,
       dated 24-March-1997. standard values are defined for engineering media:

         'a': Specifies the engineering A size medium
         '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 changes were made to version 1.6 to make version 1.7:

         1. Removed Text Handling attributes

         2. Removed best-effort tag, added best-effort Job attribute

         3. Moved job-name from Job Template to Job Identification

         4. Fixed many typos, spelling errors, etc.

         5. Removed enum standard values are defined for input-trays (from ISO DPA
       and added keyword

         6. Print Response returns Job Status not Printer Status (since Job
         status includes interesting the Printer

         Status)

         7. Removed file type, added format to Get-Attributes

         8. Added Patrick Powell as author

         9. Move conformance to section 1, added client and server
         considerations

         10. Added a IANA considerations section

         11. Added a type4 keyword

         12. Removed MIB):

         'top': The top input tray in the notion of "secondary tags"

         13. Added more section headers

         14. Merged printer.
         'middle': The middle input tray in the Job Production Attributes and Document Production
         Attributes section

       12.9 Changes made to version 1.5, dated 11-Mar-1997 to make version 1.6,
       dated 12-March-1997. printer.
         'bottom': The following changes were made to version 1.5, dated 11-Feb-1997 to
         make version 1.6, dated 12-March-1997 from bottom input tray in the miscellaneous e-mail
         messages, suggestions, and agreements: printer.

                       June 3, 23, 1997, Expires December 3, 23, 1997
         1.
            Added a new abstract with includes a reference to other IPP
            documents

         2.
            Added Roger deBry's "new intro" document.

         3.
            Added a modified text diagram showing IPP mapped onto a generic
            distributed printing model
         'envelope': The envelope input tray in section 2.0

         4.
            Added some new summary and introductory comments to 2.0 to clarify
            that this section is not only meant to introduce the IPP model but
            to show a mapping onto 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 various architecture and product
            solutions on which IPP will be implemented.

         5.
            Added a new section (3.4) summarizing ISO A4 size: 210 mm by 297 mm as defined in
            ISO 216
         'iso-a5': Specifies the role of object attributes
            and introduced ISO A5 size: 148 mm by 210 mm as defined in
            ISO 216
         'iso-a6': Specifies the notion of Job Template (Printer and Job)
            attributes along with "adornments"

         6.
            Fixed up section 3.3 on Object relationships.

         7.
            Fixed Section 3.5 on object identity.  This section now shows that
            Jobs and Printers have both URLs and Names.  Documents have Names
            and Ids

         8.
            Added ISO A6 size: 105 mm by 148 mm as defined in
            ISO 216
         'iso-a7': Specifies the correct references to Printer attributes ISO A7 size: 74 mm by 105 mm as defined in section 3.1

         9.
            Fixed
            ISO 216
         'iso-a8': Specifies the references to Job attributes ISO A8 size: 52 mm by 74 mm as defined in section 3.2

         10.
            Added a high level over view of ISO
            216
         'iso-a9': Specifies the IPP operations and their
            purpose and interactions to section 4.1 (Roger deBry worked on this
            section)

         11.
            Replaced ISO A9 size: 37 mm by 52 mm as defined in ISO
            216
         'iso-a10': Specifies the security section with a reference to a new IPP
            Security document which will eventually be merged back into this
            document

         12.
            In section 5.2 I added subheading for each attribute to more
            easily locate ISO A10 size: 26 mm by 37 mm as defined in
            ISO 216
         'iso-b0': Specifies the text associated with ISO B0 size: 1000 mm by 1414 mm as defined in
            ISO 216
         'iso-b1': Specifies the attribute ISO B1 size: 707 mm by 1000 mm as a Job
            object attribute and then defined in
            ISO 216
         'iso-b2': Specifies the text associated with ISO B2 size: 500 mm by 707 mm as defined in
            ISO 216
         'iso-b3': Specifies the attribute ISO B3 size: 353 mm by 500 mm as
            a Printer object attribute.

         13.
            Reorganized section 3 to include a Document object.

         14.
            Added IPP Mailing list info to contact list

                        June 3, 1997, Expires December 3, 1997
       12.10     Changes made to version 1.4, dated 27-Feb-1997 to make version
       1.5, dated 9-March-1997.

         The following changes were made to version 1.4, dated 27-Feb-1997 to
         make version 1.5, dated 9-March-1997 from defined in
            ISO 216
         'iso-b4': Specifies the 3/6/97 telecon
         agreements:

         1.
            Replaced ISO B4 size: 250 mm by 353 mm as defined in
            ISO 216
         'iso-b5': Specifies the data types with ISO B5 size: 176 mm by 250 mm as defined in
            ISO 216
         'iso-b6': Specifies the ones discussed on ISO B6 size: 125 mm by 176 mm as defined in
            ISO 216
         'iso-b7': Specifies the 3/6/97
            telecon.  Added back octetString, type1Enum, type2Enum, type3Enum
            types ISO B7 size: 88 mm by 125 mm as well.

         2.
            Added range constraints to defined in
            ISO 216

                       June 23, 1997, Expires December 23, 1997
         'iso-b8': Specifies the integer data type.

         3.
            Changed ISO B8 size: 62 mm by 88 mm as defined in ISO
            216
         'iso-b9': Specifies the xxx-locale attributes to be type3Enum.

         4.
            Added standard printer-resolution enum values.

         5.
            Added standard document-format enum values from ISO B9 size: 44 mm by 62 mm as defined in ISO
            216
         'iso-b10': Specifies the Printer MIB and
            IANA registries.

         6.
            Added back job-hold-until attribute using named periods only and
            added back 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 job-hold-until-specified value to executive size (7.25 X 10.5 in)
         'folio': Specifies the job-state-
            reasons attribute.

         7.
            Changed folio size (8.5 X 13 in)
         'invoice': Specifies the job state from printing to processing to agree with invoice size (5.5 X 8.5 in)
         'ledger': Specifies the
            Printer state and changed ledger size (11 X 17 in)
         'quarto': Specifies the optional job-processing job-state-
            reasons value to job-printing for use with Printers that take a lot
            of time processing while not marking.

         8.
            Deleted quarto size (8.5 X 10.83 in)
         'iso-c3': Specifies the second occurrence of ISO C3 size: 324 mm by 458 mm as defined in
            ISO 269
         'iso-c4': Specifies the job-name attribute, since we
            removed any attributes that are common to both Job and Printer.

         9.
            Changed job-priority from a type1Enum to integer(1:100) so ISO C4 size: 229 mm by 324 mm as to
            have more levels so defined in
            ISO 269
         'iso-c5': Specifies the ISO C5 size: 162 mm by 229 mm as to be able to match existing systems.

         10.
            Changed job-retention-period to use integerSeconds, instead of
            minutes.

         11.
            Changed defined in
            ISO 269
         'iso-c6': Specifies the Text Formatting attributes to take only ISO C6 size: 114 mm by 162 mm as defined in
            ISO 269
         'iso-designated-long': Specifies the computer
            points ISO Designated Long size: 110 mm
            by 220 mm as units.

         12.
            Changed job-octets to job-K-octets, defined in order to be able to print
            large documents.  Aligns with 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 IETF Job Monitoring MIB.

         13.
            Clarified that 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 job-incomplete value of job-state-reasons is
            waiting for document data, as opposed waiting for North American 9x11 inch envelope
            size
         'na-10x14-envelope': Specifies the job to be
            closed. 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 3, 23, 1997, Expires December 3, 23, 1997