Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2566

Internet Printing Protocol/1.0: Model and Semantics

Pages: 173
Obsoleted by:  2911
Part 6 of 7 – Pages 125 to 154
First   Prev   Next

ToP   noToC   RFC2566 - Page 125   prevText
8. Security Considerations

   Some IPP objects MAY be deployed over protocol stacks that support
   Secure Socket Layer Version 3 (SSL3) [SSL].  Note:  SSL3 is not an
   IETF standards track specification.  Other IPP objects MAY be
   deployed over protocol stacks that do not support SSL3.  Some IPP
   objects MAY be deployed over both types of protocol stacks.  Those
   IPP objects that support SSL3, are capable of supporting mutual
   authentication as well as privacy of messages via multiple encryption
   schemes.  An important point about security related information for
   SSL3 access to an IPP object, is that the security-related parameters
   (authentication, encryption keys, etc.) are "out-of-band" to the
   actual IPP protocol.

   An IPP object that does not support SSL3 MAY elect to support a
   transport layer that provides other security mechanisms.  For
   example, in a mapping of IPP over HTTP/1.1 [RFC2565], if the IPP
   object does not support SSL3, HTTP still allows for client
   authentication using Digest Access Authentication (DAA) [RFC2069].

   It is difficult to anticipate the security risks that might exist in
   any given IPP environment. For example, if IPP is used within a given
   corporation over a private network, the risks of exposing document
   data may be low enough that the corporation will choose not to use
   encryption on that data.  However, if the connection between the
   client and the IPP object is over a public network, the client may
   wish to protect the content of the information during transmission
   through the network with encryption.

   Furthermore, the value of the information being printed may vary from
   one IPP environment to the next. Printing payroll checks, for
   example, would have a different value than printing public
   information from a file.  There is also the possibly of denial-of-
   service attacks, but denial-of-service attacks against printing
   resources are not well understood and there is no published
   precedents regarding this scenario.

   Once the authenticated identity of the requester has been supplied to
   the IPP object, the object uses that identity to enforce any
   authorization policy that might be in place.  For example, one site's
   policy might be that only the job owner is allowed to cancel a job.
   The details and mechanisms to set up a particular access control
   policy are not part of IPP/1.0, and must be established via some
   other type of administrative or access control framework.  However,
   there are operation status codes that allow an IPP server to return
   information back to a client about any potential access control
   violations for an IPP object.
ToP   noToC   RFC2566 - Page 126
   During a create operation, the client's identity is recorded in the
   Job object in an implementation-defined attribute.  This information
   can be used to verify a client's identity for subsequent operations
   on that Job object in order to enforce any access control policy that
   might be in effect.  See section 8.3 below for more details.

   Since the security levels or the specific threats that any given IPP
   system administrator may be concerned with cannot be anticipated, IPP
   MUST be capable of operating with different security mechanisms and
   security policies as required by the individual installation.
   Security policies might vary from very strong, to very weak, to none
   at all, and corresponding security mechanisms will be required. SSL3
   supports the type of negotiated levels of security required by most,
   if not all, potential IPP environments. IPP environments that require
   no security can elect to deploy IPP objects that do not utilize the
   optional SSL3 security mechanisms.

8.1 Security Scenarios

   The following sections describe specific security attacks for IPP
   environments.  Where examples are provided they should be considered
   illustrative of the environment and not an exhaustive set. Not all of
   these environments will necessarily be addressed in initial
   implementations of IPP.

8.1.1 Client and Server in the Same Security Domain

   This environment is typical of internal networks where traditional
   office workers print the output of personal productivity applications
   on shared work-group printers, or where batch applications print
   their output on large production printers. Although the identity of
   the user may be trusted in this environment, a user might want to
   protect the content of a document against such attacks as
   eavesdropping, replaying or tampering.

8.1.2 Client and Server in Different Security Domains

   Examples of this environment include printing a document created by
   the client on a publicly available printer, such as at a commercial
   print shop; or printing a document remotely on a business associate's
   printer.  This latter operation is functionally equivalent to sending
   the document to the business associate as a facsimile. Printing
   sensitive information on a Printer in a different security domain
   requires strong security measures. In this environment authentication
   of the printer is required as well as protection against unauthorized
   use of print resources. Since the document crosses security domains,
ToP   noToC   RFC2566 - Page 127
   protection against eavesdropping and document tampering are also
   required. It will also be important in this environment to protect
   Printers against "spamming" and malicious document content.

8.1.3 Print by Reference

   When the document is not stored on the client, printing can be done
   by reference. That is, the print request can contain a reference, or
   pointer, to the document instead of the actual document itself.
   Standard methods currently do not exist for remote entities to
   "assume" the credentials of a client for forwarding requests to a 3rd
   party. It is anticipated that Print-By-Reference will be used to
   access "public" documents and that sophisticated methods for
   authenticating "proxies" will not be specified for version 1 of IPP.

8.2 URIs for SSL3 and non-SSL3 Access

   As described earlier, an IPP object can support SSL3 access, non-SSL3
   access, or both.  The "printer-uri-supported" attribute contains the
   Printer object's URI(s).  Its companion attribute, "uri-security-
   supported", identifies the security mechanism used for each URI
   listed in the "printer-uri-supported" attribute.  For each Printer
   operation request, a client MUST supply only one URI in the
   "printer-uri" operation attribute.  In other words, even though the
   Printer supports more than one URI, the client only interacts with
   the Printer object using one if its URIs.  This duality is not needed
   for Job objects, since the Printer objects is the factory for Job
   objects, and the Printer object will generate the correct URI for new
   Job objects depending on the Printer object's security configuration.

8.3 The "requesting-user-name" (name(MAX)) Operation Attribute

   Each operation MUST specify the user who is performing the operation
   in both of the following two ways:

     1) via the REQUIRED "requesting-user-name" operation attribute that
        a client SHOULD supply in all operations. The client MUST obtain
        the value for this attribute from an environmental or network
        login name for the user, rather than allowing the user to supply
        any value. If the client does not supply a value for
        "requesting-user-name", the printer MUST assume that the client
        is supplying some anonymous name, such as "anonymous".
     2) via an authentication mechanism of the underlying transport
        which may be configured to give no authentication information.
ToP   noToC   RFC2566 - Page 128
   There are six cases to consider:

     a) the authentication mechanism gives no information, and the
        client doesn't specify  "requesting-user-name".
     b) the authentication mechanism gives no information, but the
        client specifies "requesting-user-name".
     c) the authentication mechanism specifies a user which has no human
        readable representation, and the client doesn't specify
        "requesting-user-name".
     d) the authentication mechanism specifies a user which has no human
        readable representation, but the client specifies "requesting-
        user-name".
     e) the authentication mechanism specifies a user which has a human
        readable representation. The Printer object ignores the
        "requesting-user-name".
     f) the authentication mechanism specifies a user who is trusted and
        whose name means that the value of the "requesting-user-name",
        which MUST be present, is treated as the authenticated name.

   Note:  Case "f" is intended for a tightly coupled gateway and server
   to work together so that the "user" name is able to be that of the
   gateway client and not that of the gateway.  Because most, if not
   all, system vendors will initially implement IPP via a gateway into
   their existing print system, this mechanism is necessary unless the
   authentication mechanism allows a gateway (client) to act on behalf
   of some other client.

   The user-name has two forms:

     - one that is human readable: it is held in the REQUIRED "job-
       originating-user-name" Job Description attribute which is set
       during the job creation operations. It is used for presentation
       only, such as returning in queries or printing on start sheets
     - one for authorization: it is held in an undefined (by IPP) Job
       object attribute which is set by the job creation operation.  It
       is used to authorize other operations, such as Send-Document,
       Send-URI, Cancel-Job, to determine the user when the "my-jobs"
       attribute is specified with Get-Jobs, and to limit what
       attributes and values to return with Get-Job-Attributes and Get-
       Jobs.

   The human readable user name:

     - is the value of the "requesting-user-name" for cases b, d and f.
     - comes from the authentication mechanism for case e
     - is some anonymous name, such as "anonymous" for cases a and c.

   The user name used for authorization:
ToP   noToC   RFC2566 - Page 129
     - is the value of the "requesting-user-name" for cases b  and f.
     - comes from the authentication mechanism for cases c, d and  e
     - is some anonymous name, such as "anonymous" for case a.

   The essence of these rules for resolving conflicting sources of
   user-names is that a printer implementation is free to pick either
   source as long as it achieves consistent results.  That is, if a user
   uses the same path for a series of requests, the requests MUST appear
   to come from the same user from the standpoint of both the human-
   readable user name and the user name for authorization.  This rule
   MUST continue to apply even if a request could be authenticated by
   two or more mechanisms.  It doesn't matter which of  several
   authentication mechanisms a Printer uses as long as it achieves
   consistent results.  If a client uses more than one authentication
   mechanism, it is recommended that an administrator make all
   credentials resolve to the same user and user-name as much as
   possible.

8.4 Restricted Queries

   In many IPP operations, a client supplies a list of attributes to be
   returned in the response.  For security reasons, an IPP object may be
   configured not to return all attributes (or all values) that a client
   requests.  The job attributes returned MAY depend on whether the
   requesting user is the same as the user that submitted the job. The
   IPP object MAY even return none of the requested attributes. In such
   cases, the status returned is the same as if the object had returned
   all requested attributes.  The client cannot tell by such a response
   whether the requested attribute was present or absent on the object.

8.5 Queries on jobs submitted using non-IPP protocols

   If the device that an IPP Printer is representing is able to accept
   jobs using other job submission protocols in addition to IPP, it is
   RECOMMENDED that such an implementation at least allow such "foreign"
   jobs to be queried using Get-Jobs returning "job-id" and "job-uri" as
   'unknown'.  Such an implementation NEED NOT support all of the same
   IPP job attributes as for IPP jobs.  The IPP object returns the '
   unknown' out-of-band value for any requested attribute of a foreign
   job that is supported for IPP jobs, but not for foreign jobs.

   It is further RECOMMENDED, that the IPP Printer generate "job-id" and
   "job-uri" values for such "foreign jobs", if possible, so that they
   may be targets of other IPP operations, such as Get-Job-Attributes
   and Cancel-Job.  Such an implementation also needs to deal with the
   problem of authentication of such foreign jobs.  One approach would
   be to treat all such foreign jobs as belonging to users other than
   the user of the IPP client.  Another approach would be for the
ToP   noToC   RFC2566 - Page 130
   foreign job to belong to 'anonymous'.  Only if the IPP client has
   been authenticated as an operator or administrator of the IPP Printer
   object, could the foreign jobs be queried by an IPP request.
   Alternatively, if the security policy is to allow users to query
   other users' jobs, then the foreign jobs would also be visible to an
   end-user IPP client using Get-Jobs and Get-Job-Attributes.

8.6 IPP Security Application Profile for SSL3

   The IPP application profile for SSL3 follows the "Secure Socket
   Layer" requirement as documented in the SSL3 specification [SSL].
   For interoperability, the SSL3 cipher suites are:

        SSL_RSA_WITH_RC4_128_MD5
        SSL_RSA_WITH_3DES_EDE_CBC_SHA
        SSL_RSA_WITH_DES_CBC_SHA
        SSL_RSA_EXPORT_WITH_RC4_40_MD5
        SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
        SSL_RSA_WITH_NULL_MD5

   Client implementations MUST NOT assume any other cipher suites are
   supported by an IPP Printer object.

   If a conforming IPP object supports SSL3, it MUST implement and
   support the cipher suites listed above and MAY support additional
   cipher suites.

   A conforming IPP client SHOULD support SSL3 including the cipher
   suites listed above.  A conforming IPP client MAY support additional
   cipher suites.

   It is possible that due to certain government export restrictions
   some non-compliant versions of this extension could be deployed.
   Implementations wishing to inter-operate with such non-compliant
   versions MAY offer the SSL_RSA_EXPORT_WITH_RC4_40_MD5 and
   SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 mechanisms.  However, since 40 bit
   ciphers are known to be vulnerable to attack by current technology,
   any client which actives a 40 bit cipher MUST NOT indicate to the
   user that the connection is completely secure from eavesdropping.
ToP   noToC   RFC2566 - Page 131
9. References

   [ASCII]      Coded Character Set - 7-bit American Standard Code for
                Information Interchange (ASCII), ANSI X3.4-1986. This
                standard is the specification of the US-ASCII charset.

   [HTPP]       J. Barnett, K. Carter, R. DeBry,  "Initial Draft -
                Hypertext Printing Protocol - HTPP/1.0", October 1996.
                ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/
                overview.ps.gz

   [IANA-CS]    IANA Registry of Coded Character Sets:
                ftp://ftp.isi.edu/in-notes/iana/assignments/character-
                sets

   [IANA-MT]    IANA Registry of Media Types:  ftp://ftp.isi.edu/in-
                notes/iana/assignments/media-types/

   [ipp-iig]    Hastings, T. and C. Manros, "Internet Printing
                Protocol/1.0:  Implementer's Guide", Work in Progress.

   [ISO10646-1] ISO/IEC 10646-1:1993, "Information technology --
                Universal Multiple-Octet Coded Character Set (UCS) -
                Part 1: Architecture and Basic Multilingual Plane,
                JTC1/SC2."

   [ISO8859-1]  ISO/IEC 8859-1:1987, "Information technology -- 8-bit
                One-Byte Coded Character Set - Part 1: Latin Alphabet Nr
                1", 1987, JTC1/SC2.

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

   [LDPA] T. Hastings, S. Isaacson, M. MacKay, C. Manros, D. Taylor, P.
                Zehler, "LDPA - Lightweight Document Printing
                Application", October 1996,
                ftp://ftp.pwg.org/pub/pwg/ipp/historic/ldpa/ldpa8.pdf.gz

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

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

   [PWG]        Printer Working Group, http://www.pwg.org.

   [RFC1035]    Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
                SPECIFICATION", STD 13, RFC 1035, November 1987.
ToP   noToC   RFC2566 - Page 132
   [RFC1759]    Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
                Gyllenskog, "Printer MIB", RFC 1759, March 1995.

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

   [RFC1179]    McLaughlin, L. (Editor), "Line Printer Daemon Protocol",
                RFC 1179, August 1990.

   [RFC1952]    Deutsch, P., "GZIP file format specification version
                4.3", RFC 1952, May 1996.

   [RFC2045]    Freed, N. and N. Borenstein, " Multipurpose Internet
                Mail Extensions (MIME) Part One: Format of Internet
                Message Bodies", RFC 2045, November 1996.

   [RFC2046]    Freed, N. and N. Borenstein, "Multipurpose Internet Mail
                Extensions (MIME) Part Two: Media Types", RFC 2046,
                November 1996.

   [RFC2048]    Freed, N., Klensin, J. and J. Postel, "Multipurpose
                Internet Mail Extension (MIME) Part Four: Registration
                Procedures", RFC 2048, November 1996.

   [RFC2068]    Fielding, R., Gettys, J., Mogul, J., Frystyk, H. AND T.
                Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
                RFC 2068, January 1997.

   [RFC2069]    Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
                Luotonen, A., Sink, E. and L. Stewart, "An Extension to
                HTTP: Digest Access Authentication", RFC 2069, January
                1997.

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

   [RFC2228]    Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC
                2228, October 1997.

   [RFC2277]    Alvestrand, H., "IETF Policy on Character Sets and
                Languages" RFC 2277, January 1998.

   [RFC2278]    Freed, N. and J. Postel:  "IANA Charset Registration
                Procedures", BCP 19, RFC 2278, January 1998.

   [RFC2279]    Yergeau, F., "UTF-8, a transformation format of ISO
                10646", RFC 2279, January 1998.
ToP   noToC   RFC2566 - Page 133
   [RFC2316]    Bellovin, S., "Report of the IAB Security Architecture
                Workshop", RFC 2316, April 1998.

   [RFC2396]    Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
                Resource Identifiers (URI): Generic Syntax", RFC 2396,
                August 1998.

   [RFC2434]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
                IANA Considerations Section in RFCs", BCP 26, RFC 2434,
                October 1998.

   [RFC2565]    Herriot, R., Butler, S., Moore, P. and R. Tuner
                "Internet Printing Protocol/1.0: Encoding and
                Transport", RFC 2565, April 1999.

   [RFC2567]    Wright, D.,  "Design Goals for an Internet Printing
                Protocol", RFC 2567, April 1999.

   [RFC2568]    Zilles, S., "Rationale for the Structure and Model and
                Protocol for the Internet Printing Protocol", RFC 2568,
                April 1999.

   [RFC2569]    Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
                "Mapping between LPD and IPP Protocols", RFC 2569, April
                1999.

   [RFC2579]    McCloghrie, K., Perkins, D. and J. Schoenwaelder,
                "Textual Conventions for SMIv2", STD 58, RFC 2579, April
                1999.

   [SSL]        Netscape, The SSL Protocol, Version 3, (Text version
                3.02), November 1996.

   [SWP]        P. Moore, B. Jahromi, S. Butler, "Simple Web Printing
                SWP/1.0", May 7, 1997,
                ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/swp9705.pdf
ToP   noToC   RFC2566 - Page 134
10. Authors' Addresses

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

   Phone: 801-861-7366
   Fax:   801-861-2517
   EMail: sisaacson@novell.com


   Tom Hastings
   Xerox Corporation
   737 Hawaii St.
   El Segundo, CA   90245

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


   Robert Herriot
   Xerox Corporation
   3400 Hillview Ave., Bldg #1
   Palo Alto, CA 94304

   Phone: 650-813-7696
   Fax:  650-813-6860
   EMail: robert.herriot@pahv.xerox.com


   Roger deBry
   Utah Valley State College
   Orem, UT 84058

   Phone: (801) 222-8000
   EMail: debryro@uvsc.edu
ToP   noToC   RFC2566 - Page 135
   Patrick Powell
   Astart Technologies
   9475 Chesapeake Dr., Suite D
   San Diego, CA  95123

   Phone: (619) 874-6543
   Fax: (619) 279-8424
   EMail: papowell@astart.com

   IPP Mailing List:  ipp@pwg.org
   IPP Mailing List Subscription: ipp-request@pwg.org
   IPP Web Page:  http://www.pwg.org/ipp/

   Implementers of this specification are encouraged to join IPP Mailing
   List in order to participate in any discussions of clarification
   issues and review of registration proposals for additional attributes
   and values.

   Other Participants:

      Chuck Adams - Tektronix
      Jeff Barnett - IBM
      Ron Bergman - Dataproducts Corp.
      Sylvan Butler - HP
      Keith Carter - IBM Corporation
      Jeff Copeland - QMS
      Andy Davidson - Tektronix
      Mabry Dozier - QMS
      Lee Farrell - Canon Information Systems
      Steve Gebert - IBM
      Babek Jahromi - Microsoft
      David Kellerman - Northlake Software
      Rick Landau - Digital
      Greg LeClair - Epson
      Harry Lewis - IBM
      Pete Loya - HP
      Ray Lutz - Cognisys
      Mike MacKay - Novell, Inc.
      Daniel Manchala - Xerox
      Carl-Uno Manros - Xerox
      Jay Martin - Underscore
      Larry Masinter - Xerox
      Stan McConnell - Xerox
      Ira McDonald - High North Inc.
      Paul Moore - Microsoft
      Tetsuya Morita - Ricoh
      Yuichi Niwa - Ricoh
      Pat Nogay - IBM
ToP   noToC   RFC2566 - Page 136
      Ron Norton - Printronics
      Bob Pentecost - HP
      Rob Rhoads - Intel
      Xavier Riley - Xerox
      David Roach - Unisys
      Stuart Rowley - Kyocera
      Hiroyuki Sato - Canon
      Bob Setterbo - Adobe
      Devon Taylor - Novell, Inc.
      Mike Timperman - Lexmark
      Randy Turner - Sharp
      Atsushi Yuki - Kyocera
      Rick Yardumian - Xerox
      Lloyd Young - Lexmark
      Bill Wagner - DPI
      Jim Walker - DAZEL
      Chris Wellens - Interworking Labs
      Rob Whittle - Novell, Inc.
      Don Wright - Lexmark
      Peter Zehler - Xerox
      Steve Zilles - Adobe

11. Formats for IPP Registration Proposals

   In order to propose an IPP extension for registration, the proposer
   must submit an application to IANA by email to "iana@iana.org" or by
   filling out the appropriate form on the IANA web pages
   (http://www.iana.org).  This section specifies the required
   information and the formats for proposing registrations of extensions
   to IPP as provided in Section 6 for:

     1. type2 'keyword' attribute values
     2. type3 'keyword' attribute values
     3. type2 'enum' attribute values
     4. type3 'enum' attribute values
     5. attributes
     6. attribute syntaxes
     7. operations
     8. status codes

11.1 Type2 keyword attribute values registration

   Type of registration:  type2 keyword attribute value
   Name of attribute to which this keyword specification is to be added:
   Proposed keyword name of this keyword value:
   Specification of this keyword value (follow the style of IPP Model
   Section 4.1.2.3):
   Name of proposer:
ToP   noToC   RFC2566 - Page 137
   Address of proposer:
   Email address of proposer:

   Note:  For type2 keywords, the Designated Expert will be the point of
   contact for the approved registration specification, if any
   maintenance of the registration specification is needed.

11.2 Type3 keyword attribute values registration

   Type of registration:  type3 keyword attribute value
   Name of attribute to which this keyword specification is to be added:
   Proposed keyword name of this keyword value:
   Specification of this keyword value (follow the style of IPP Model
   Section 4.1.2.3):
   Name of proposer:
   Address of proposer:
   Email address of proposer:

   Note:  For type3 keywords, the proposer will be the point of contact
   for the approved registration specification, if any maintenance of
   the registration specification is needed.

11.3 Type2 enum attribute values registration

   Type of registration:  type2 enum attribute value
   Name of attribute to which this enum specification is to be added:
   Keyword symbolic name of this enum value:
   Numeric value (to be assigned by the IPP Designated Expert in
   consultation with IANA):
   Specification of this enum value (follow the style of IPP Model
   Section 4.1.4):
   Name of proposer:
   Address of proposer:
   Email address of proposer:

   Note:  For type2 enums, the Designated Expert will be the point of
   contact for the approved registration specification, if any
   maintenance of the registration specification is needed.

11.4 Type3 enum attribute values registration

   Type of registration:  type3 enum attribute value
   Name of attribute to which this enum specification is to be added:
   Keyword symbolic name of this enum value:
   Numeric value (to be assigned by the IPP Designated Expert in
   consultation with IANA):
   Specification of this enum value (follow the style of IPP Model
   Section 4.1.4):
ToP   noToC   RFC2566 - Page 138
   Name of proposer:
   Address of proposer:
   Email address of proposer:

   Note:  For type3 enums, the proposer will be the point of contact for
   the approved registration specification, if any maintenance of the
   registration specification is needed.

11.5 Attribute registration

   Type of registration:  attribute
   Proposed keyword name of this attribute:
   Types of attribute (Operation, Job Template, Job Description,
   Printer Description):
   Operations to be used with if the attribute is an operation
   attribute:
   Object (Job, Printer, etc. if bound to an object):
   Attribute syntax(es) (include 1setOf and range as in Section 4.2):
   If attribute syntax is 'keyword' or 'enum', is it type2 or type3:
   If this is a Printer attribute, MAY the value returned depend on
   "document-format" (See Section 6.2):
   If this is a Job Template attribute, how does its specification
   depend on the value of the "multiple-document-handling" attribute:
   Specification of this attribute (follow the style of IPP Model
   Section 4.2):
   Name of proposer:
   Address of proposer:
   Email address of proposer:

   Note:  For attributes, the IPP Designated Expert will be the point of
   contact for the approved registration specification, if any
   maintenance of the registration specification is needed.

11.6 Attribute Syntax registration

   Type of registration:  attribute syntax
   Proposed name of this attribute syntax:
   Type of attribute syntax (integer, octetString, character-string,
   see [RFC2565]):
   Numeric value (to be assigned by the IPP Designated Expert in
   consultation with IANA):
   Specification of this attribute (follow the style of IPP Model
   Section 4.1):
   Name of proposer:
   Address of proposer:
   Email address of proposer:
ToP   noToC   RFC2566 - Page 139
   Note:  For attribute syntaxes, the IPP Designated Expert will be the
   point of contact for the approved registration specification, if any
   maintenance of the registration specification is needed.

11.7 Operation registration

   Type of registration:  operation
   Proposed name of this operation:
   Numeric operation-id value (to be assigned by the IPP Designated
   Expert in consultation with IANA):
   Object Target (Job, Printer, etc. that operation is upon):
   Specification of this attribute (follow the style of IPP Model
   Section 3):
   Name of proposer:
   Address of proposer:
   Email address of proposer:

   Note:  For operations, the IPP Designated Expert will be the point of
   contact for the approved registration specification, if any
   maintenance of the registration specification is needed.

11.8 Attribute Group registration

   Type of registration:  attribute group
   Proposed name of this attribute group:
   Numeric tag according to [RFC2565] (to be assigned by the IPP
   Designated Expert in consultation with IANA):
   Operation requests and group number for each operation in which the
   attribute group occurs:
   Operation responses and group number for each operation in which the
   attribute group occurs:
   Specification of this attribute group (follow the style of IPP Model
   Section 3):
   Name of proposer:
   Address of proposer:
   Email address of proposer:

   Note:  For attribute groups, the IPP Designated Expert will be the
   point of contact for the approved registration specification, if any
   maintenance of the registration specification is needed.

11.9 Status code registration

   Type of registration:  status code
   Keyword symbolic name of this status code value:
   Numeric value (to be assigned by the IPP Designated Expert in
   consultation with IANA):
   Operations that this status code may be used with:
ToP   noToC   RFC2566 - Page 140
   Specification of this status code (follow the style of IPP Model
   Section 14 APPENDIX B:  Status Codes and Suggested Status Code
   Messages):
   Name of proposer:
   Address of proposer:
   Email address of proposer:

   Note:  For status codes, the Designated Expert will be the point of
   contact for the approved registration specification, if any
   maintenance of the registration specification is needed.
ToP   noToC   RFC2566 - Page 141
12. APPENDIX A: Terminology

   This specification uses the terminology defined in this section.

12.1 Conformance Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and  "OPTIONAL" in this document are to be
   interpreted as described in RFC 2119 [RFC2119].

12.1.1 NEED NOT

   This term is not included in RFC 2119.  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.

12.2 Model Terminology

12.2.1 Keyword

   Keywords are used within this document as identifiers of semantic
   entities within the abstract model (see section 4.1.2.3).  Attribute
   names, some attribute values, attribute syntaxes, and attribute group
   names are represented as keywords.

12.2.2 Attributes

   An attribute is an item of information that is associated with an
   instance of an IPP object.  An attribute consists of an attribute
   name and one or more attribute values.  Each attribute has a specific
   attribute syntax.  All object attributes are defined in section 4 and
   all operation attributes are defined in section 3.

   Job Template Attributes are described in section 4.2. The client
   optionally supplies Job Template attributes in a create request
   (operation requests that create Job objects).  The Printer object has
   associated attributes which define supported and default values for
   the Printer.

12.2.2.1 Attribute Name

   Each attribute is uniquely identified in this document by its
   attribute name.  An attribute name is a keyword.  The keyword
   attribute name is given in the section header describing that
ToP   noToC   RFC2566 - Page 142
   attribute.  In running text in this document, attribute names are
   indicated inside double quotation marks (") where the quotation marks
   are not part of the keyword itself.

12.2.2.2 Attribute Group Name

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

12.2.2.3 Attribute Value

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

12.2.2.4 Attribute Syntax

   Each attribute is defined using an explicit syntax type.  In this
   document, each syntax type is defined as a keyword with specific
   meaning.  The Encoding and Transport document [RFC2565] indicates the
   actual "on-the-wire" encoding rules for each syntax type.  Attribute
   syntax types are defined in section 4.1.

12.2.3 Supports

   By definition, a Printer object supports an attribute only if that
   Printer object responds with the corresponding attribute populated
   with some value(s) in a response to a query for that attribute.  A
   Printer object supports an attribute value if the value is one of the
   Printer object's "supported values" attributes.  The device behind a
   Printer object may exhibit a behavior that corresponds to some IPP
   attribute, but if the Printer object, when queried for that
   attribute, doesn't respond with the attribute, then as far as IPP is
   concerned, that implementation does not support that feature. If the
   Printer object's "xxx-supported" attribute is not populated with a
   particular value (even if that value is a legal value for that
   attribute), then that Printer object does not support that particular
   value.

   A conforming implementation MUST support all REQUIRED attributes.
   However, even for REQUIRED attributes, conformance to IPP does not
   mandate that all implementations support all possible values
   representing all possible job processing behaviors and features.  For
ToP   noToC   RFC2566 - Page 143
   example, if a given instance of a Printer supports only certain
   document formats, then that Printer responds with the "document-
   format-supported" attribute populated with a set of values, possibly
   only one, taken from the entire set of possible values defined for
   that attribute. This limited set of values represents the Printer's
   set of supported document formats.  Supporting an attribute and some
   set of values for that attribute enables IPP end users to be aware of
   and make use of those features associated with that attribute and
   those values.  If an implementation chooses to not support an
   attribute or some specific value, then IPP end users would have no
   ability to make use of that feature within the context of IPP itself.
   However, due to existing practice and legacy systems which are not
   IPP aware, there might be some other mechanism outside the scope of
   IPP to control or request the "unsupported" feature (such as embedded
   instructions within the document data itself).

   For example, consider the "finishings-supported" attribute.

     1) If a Printer object is not physically capable of stapling, the
        "finishings-supported" attribute MUST NOT be populated with the
        value of 'staple'.
     2) A Printer object is physically capable of stapling, however an
        implementation chooses not to support stapling in the IPP
        "finishings" attribute.  In this case, 'staple' MUST NOT be a
        value in the "finishings-supported" Printer object attribute.
        Without support for the value 'staple', an IPP end user would
        have no means within the protocol itself to request that a Job
        be stapled.  However, an existing document data formatter might
        be able to request that the document be stapled directly with an
        embedded instruction within the document data.  In this case,
        the IPP implementation does not "support" stapling, however the
        end user is still able to have some control over the stapling of
        the completed job.
     3) A Printer object is physically capable of stapling, and an
        implementation chooses to support stapling in the IPP
        "finishings" attribute. In this case, 'staple' MUST be a value
        in the "finishings-supported" Printer object attribute. Doing
        so, would enable end users to be aware of and make use of the
        stapling feature using IPP attributes.

   Even though support for Job Template attributes by a Printer object
   is OPTIONAL, it is RECOMMENDED that if the device behind a Printer
   object is capable of realizing any feature or function that
   corresponds to an IPP attribute and some associated value, then that
   implementation SHOULD support that IPP attribute and value.
ToP   noToC   RFC2566 - Page 144
   The set of values in any of the supported value attributes is set
   (populated) by some administrative process or automatic sensing
   mechanism that is outside the scope of IPP.  For administrative
   policy and control reasons, an administrator may choose to make only
   a subset of possible values visible to the end user.  In this case,
   the real output device behind the IPP Printer abstraction may be
   capable of a certain feature, however an administrator is specifying
   that access to that feature not be exposed to the end user through
   the IPP protocol.  Also, since a Printer object may represent a
   logical print device (not just a physical device) the actual process
   for supporting a value is undefined and left up to the
   implementation.  However, if a Printer object supports a value, some
   manual human action may be needed to realize the semantic action
   associated with the value, but no end user action is required.

   For example, if one of the values in the "finishings-supported"
   attribute is 'staple', the actual process might be an automatic
   staple action by a physical device controlled by some command sent to
   the device.  Or, the actual process of stapling might be a manual
   action by an operator at an operator attended Printer object.

   For another example of how supported attributes function, consider a
   system administrator who desires to control all print jobs so that no
   job sheets are printed in order to conserve paper.  To force no job
   sheets, the system administrator sets the only supported value for
   the "job-sheets-supported" attribute to 'none'.  In this case, if a
   client requests anything except 'none', the create request is
   rejected or the "job-sheets" value is ignored (depending on the value
   of "ipp-attribute-fidelity").  To force the use of job start/end
   sheets on all jobs, the administrator does not include the value '
   none' in the "job-sheets-supported" attribute.  In this case, if a
   client requests 'none', the create request is rejected or the "job-
   sheets" value is ignored (again depending on the value of "ipp-
   attribute-fidelity").

12.2.4 print-stream page

   A "print-stream page" is a page according to the definition of pages
   in the language used to express the document data.

12.2.5 impression

   An "impression" is the image (possibly many print-stream pages in
   different configurations) imposed onto a single media page.
ToP   noToC   RFC2566 - Page 145
13. APPENDIX B:  Status Codes and Suggested Status Code Messages

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

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

     "informational" - Request received, continuing process
     "successful" - The action was successfully received, understood,
        and accepted
     "redirection" - Further action must be taken in order to complete
        the request
     "client-error" - The request contains bad syntax or cannot be
        fulfilled
     "server-error" - The IPP object  failed to fulfill an apparently
        valid request

   As with type2 enums, IPP status codes are extensible.  IPP clients
   are NOT REQUIRED to understand the meaning of all registered status
   codes, though such understanding is obviously desirable.  However,
   IPP clients MUST understand the class of any status code, as
   indicated by the prefix, and treat any unrecognized response as being
   equivalent to the first status code of that class, with the exception
   that an unrecognized response MUST NOT be cached.  For example, if an
   unrecognized status code of "client-error-xxx-yyy" is received by the
   client, it can safely assume that there was something wrong with its
   request and treat the response as if it had received a "client-
   error-bad-request" status code.  In such cases, IPP applications
   SHOULD present the OPTIONAL message (if present) to the end user
   since the message is likely to contain human readable information
   which will help to explain the unusual status.  The name of the enum
   is the suggested status message for US English.

   The status code values range from 0x0000 to 0x7FFF.  The value ranges
   for each status code class are as follows:

     "successful" - 0x0000 to 0x00FF
     "informational" - 0x0100 to 0x01FF
     "redirection" - 0x0200 to 0x02FF
ToP   noToC   RFC2566 - Page 146
     "client-error" - 0x0400 to 0x04FF
     "server-error" - 0x0500 to 0x05FF

   The top half (128 values) of each range (0x0n40 to 0x0nFF, for n = 0
   to 5) is reserved for private use within each status code class.
   Values 0x0600 to 0x7FFF are reserved for future assignment and MUST
   NOT be used.

13.1 Status Codes

   Each status code is described below. Section 13.1.5.9 contains a
   table that indicates which status codes apply to which operations.
   The Implementer's Guide [ipp-iig] describe the suggested steps for
   processing IPP attributes for all operations, including returning
   status codes.

13.1.1 Informational

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

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

13.1.2 Successful Status Codes

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

13.1.2.1 successful-ok (0x0000)

   The request has succeeded and no request attributes were substituted
   or ignored.  In the case of a response to a create request, the '
   successful-ok' status code indicates that the request was
   successfully received and validated, and that the Job object has been
   created; it does not indicate that the job has been processed.  The
   transition of the Job object into the 'completed' state is the only
   indicator that the job has been printed.

13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001)

   The request has succeeded, but some supplied (1) attributes were
   ignored or (2) unsupported values were substituted with supported
   values or were ignored in order to perform the operation without
   rejecting it.  Unsupported attributes, attribute syntaxes, or values
   MUST be returned in the Unsupported Attributes group of the response
   for all operations.  There is an exception to this rule for the query
   operations:  Get-Printer-Attributes, Get-Jobs, and Get-Job-Attributes
ToP   noToC   RFC2566 - Page 147
   for the "requested-attributes" operation attribute only.  When the
   supplied values of the "requested-attributes" operation attribute are
   requesting attributes that are not supported, the IPP object MAY, but
   is NOT REQUIRED to, return the "requested-attributes" attribute in
   the Unsupported Attribute response group (with the unsupported values
   only).  See section 3.2.1.2.

13.1.2.3 successful-ok-conflicting-attributes (0x0002)

   The request has succeeded, but some supplied attribute values
   conflicted with the values of other supplied attributes.  These
   conflicting values were either (1) substituted with (supported)
   values or (2) the attributes were removed in order to process the job
   without rejecting it.  Attributes or values which conflict with other
   attributes and have been substituted or ignored MUST be returned in
   the Unsupported Attributes group of the response for all operations
   as supplied by the client.  See section 3.2.1.2.

13.1.3 Redirection Status Codes

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

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

13.1.4 Client Error Status Codes

   This class of status code is intended for cases in which the client
   seems to have erred.  The IPP object SHOULD return a message
   containing an explanation of the error situation and whether it is a
   temporary or permanent condition.

13.1.4.1 client-error-bad-request (0x0400)

   The request could not be understood by the IPP object due to
   malformed syntax (such as the value of a fixed length attribute whose
   length does not match the prescribed length for that attribute - see
   the Implementer's Guide [ipp-iig] ).  The IPP application SHOULD NOT
   repeat the request without modifications.

13.1.4.2 client-error-forbidden (0x0401)

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

13.1.4.3 client-error-not-authenticated (0x0402)

   The request requires user authentication.  The IPP client may repeat
   the request with suitable authentication information. If the request
   already included authentication information, then this status code
   indicates that authorization has been refused for those credentials.
   If this response contains the same challenge as the prior response,
   and the user agent has already attempted authentication at least
   once, then the response message may contain relevant diagnostic
   information.  This status codes reveals more information than
   "client-error-forbidden".

13.1.4.4 client-error-not-authorized (0x0403)

   The requester is not authorized to perform the request.  Additional
   authentication information or authorization credentials will not help
   and the request SHOULD NOT be repeated.  This status code is used
   when the IPP object wishes to reveal that the authentication
   information is understandable, however, the requester is explicitly
   not authorized to perform the request.  This status codes reveals
   more information than "client-error-forbidden" and "client-error-
   not-authenticated".

13.1.4.5 client-error-not-possible (0x0404)

   This status code is used when the request is for something that can
   not happen.  For example, there might be a request to cancel a job
   that has already been canceled or aborted by the system.  The IPP
   client SHOULD NOT repeat the request.

13.1.4.6 client-error-timeout (0x0405)

   The client did not produce a request within the time that the IPP
   object was prepared to wait.  For example, a client issued a Create-
   Job operation and then, after a long period of time, issued a Send-
   Document operation and this error status code was returned in
   response to the Send-Document request  (see section 3.3.1).  The IPP
   object might have been forced to clean up resources that had been
   held for the waiting additional Documents.  The IPP object was forced
   to close the Job since the client took too long.  The client SHOULD
   NOT repeat the request without modifications.
ToP   noToC   RFC2566 - Page 149
13.1.4.7 client-error-not-found (0x0406)

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

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

13.1.4.8 client-error-gone (0x0407)

   The requested object is no longer available and no forwarding address
   is known.  This condition should be considered permanent.  Clients
   with link editing capabilities should delete references to the
   request URI after user approval.  If the IPP object does not know or
   has no facility to determine, whether or not the condition is
   permanent, the status code "client-error-not-found" should be used
   instead.

   This response is primarily intended to assist the task of maintenance
   by notifying the recipient that the resource is intentionally
   unavailable and that the IPP object administrator desires that remote
   links to that resource be removed. It is not necessary to mark all
   permanently unavailable resources as "gone" or to keep the mark for
   any length of time -- that is left to the discretion of the IPP
   object administrator.

13.1.4.9 client-error-request-entity-too-large (0x0408)

   The IPP object is refusing to process a request because the request
   entity is larger than the IPP object is willing or able to process.
   An IPP Printer returns this status code when it limits the size of
   print jobs and it receives a print job that exceeds that limit or
   when the attributes are so many that their encoding causes the
   request entity to exceed IPP object capacity.
ToP   noToC   RFC2566 - Page 150
13.1.4.10 client-error-request-value-too-long (0x0409)

   The IPP object is refusing to service the request because one or more
   of the client-supplied attributes has a variable length value that is
   longer than the maximum length specified for that attribute.  The IPP
   object might not have sufficient resources (memory, buffers, etc.) to
   process (even temporarily), interpret, and/or ignore a value larger
   than the maximum length.  Another use of this error code is when the
   IPP object supports the processing of a large value that is less than
   the maximum length, but during the processing of the request as a
   whole, the object may pass the value onto some other system component
   which is not able to accept the large value.  For more details, see
   the Implementer's Guide [ipp-iig] .

   Note:  For attribute values that are URIs, this rare condition is
   only likely to occur when a client has improperly submitted a request
   with long query information (e.g. an IPP application allows an end-
   user to enter an invalid URI), when the client has descended into a
   URI "black hole" of redirection (e.g., a redirected URI prefix that
   points to a suffix of itself), or when the IPP object is under attack
   by a client attempting to exploit security holes present in some IPP
   objects using fixed-length buffers for reading or manipulating the
   Request-URI.

13.1.4.11 client-error-document-format-not-supported (0x040A)

   The IPP object is refusing to service the request because the
   document data is in a format, as specified in the "document-format"
   operation attribute, that is not supported by the Printer object.
   This error is returned independent of the client-supplied "ipp-
   attribute-fidelity".  The Printer object MUST return this status
   code, even if there are other attributes that are not supported as
   well, since this error is a bigger problem than with Job Template
   attributes.

13.1.4.12 client-error-attributes-or-values-not-supported (0x040B)

   In a create request, if the Printer object does not support one or
   more attributes, attribute syntaxes, or attribute values supplied in
   the request and the client supplied the "ipp-attributes-fidelity"
   operation attribute with the 'true' value, the Printer object MUST
   return this status code.  For example, if the request indicates '
   iso-a4' media, but that media type is not supported by the Printer
   object.  Or, if the client supplies an optional attribute and the
   attribute itself is not even supported by the Printer.  If the "ipp-
   attribute-fidelity" attribute is 'false', the Printer MUST ignore or
   substitute values for unsupported attributes and values rather than
   reject the request and return this status code.
ToP   noToC   RFC2566 - Page 151
   For any operation where a client requests attributes (such as a Get-
   Jobs, Get-Printer-Attributes, or Get-Job-Attributes operation), if
   the IPP object does not support one or more of the requested
   attributes, the IPP object simply ignores the unsupported requested
   attributes and processes the request as if they had not been
   supplied, rather than returning this status code.  In this case, the
   IPP object MUST return the 'successful-ok-ignored-or-substituted-
   attributes' status code and MAY return the unsupported attributes as
   values of the "requested-attributes" in the Unsupported Attributes
   Group (see section 13.1.2.2).

13.1.4.13 client-error-uri-scheme-not-supported (0x040C)

   The type of the client supplied URI in a Print-URI or a Send-URI
   operation is not supported.

13.1.4.14 client-error-charset-not-supported (0x040D)

   For any operation, if the IPP Printer does not support the charset
   supplied by the client in the "attributes-charset" operation
   attribute, the Printer MUST reject the operation and return this
   status and any 'text' or 'name' attributes using the 'utf-8' charset
   (see Section 3.1.4.1).

13.1.4.15 client-error-conflicting-attributes (0x040E)

   The request is rejected because some attribute values conflicted with
   the values of other attributes which this specification does not
   permit to be substituted or ignored.

13.1.5 Server Error Status Codes

   This class of status codes indicates cases in which the IPP object is
   aware that it has erred or is incapable of performing the request.
   The IPP object SHOULD include a message containing an explanation of
   the error situation, and whether it is a temporary or permanent
   condition.

13.1.5.1 server-error-internal-error (0x0500)

   The IPP object encountered an unexpected condition that prevented it
   from fulfilling the request.  This error status code differs from
   "server-error-temporary-error" in that it implies a more permanent
   type of internal error.  It also differs from "server-error-device-
   error" in that it implies an unexpected condition (unlike a paper-jam
   or out-of-toner problem which is undesirable but expected).  This
   error status code indicates that probably some knowledgeable human
   intervention is required.
ToP   noToC   RFC2566 - Page 152
13.1.5.2 server-error-operation-not-supported (0x0501)

   The IPP object does not support the functionality required to fulfill
   the request. This is the appropriate response when the IPP object
   does not recognize an operation or is not capable of supporting it.

13.1.5.3 server-error-service-unavailable (0x0502)

   The IPP object is currently unable to handle the request due to a
   temporary overloading or maintenance of the IPP object.  The
   implication is that this is a temporary condition which will be
   alleviated after some delay. If known, the length of the delay may be
   indicated in the message.  If no delay is given, the IPP application
   should handle the response as it would for a "server-error-
   temporary-error" response.  If the condition is more permanent, the
   error status codes "client-error-gone" or "client-error-not-found"
   could be used.

13.1.5.4 server-error-version-not-supported (0x0503)

   The IPP object does not support, or refuses to support, the IPP
   protocol version that was used in the request message.  The IPP
   object is indicating that it is unable or unwilling to complete the
   request using the same version as supplied in the request other than
   with this error message. The response should contain a Message
   describing why that version is not supported and what other versions
   are supported by that IPP object.

   A conforming IPP/1.0 client MUST specify the valid version ('1.0') on
   each request.  A conforming IPP/1.0 object MUST NOT return this
   status code to a conforming IPP/1.0 client.  An IPP object MUST
   return this status code to a non-conforming IPP client.  The response
   MUST identify in the "version-number" operation attribute the closest
   version number that the IPP object does support.

13.1.5.5 server-error-device-error (0x0504)

   A printer error, such as a paper jam, occurs while the IPP object
   processes a Print or Send operation.  The response contains the true
   Job Status (the values of the "job-state" and "job-state-reasons"
   attributes).  Additional information can be returned in the optional
   "job-state-message" attribute value or in the OPTIONAL status message
   that describes the error in more detail.  This error status code is
   only returned in situations where the Printer is unable to accept the
   create request because of such a device error.  For example, if the
   Printer is unable to spool, and can only accept one job at a time,
   the reason it might reject a create request is that the printer
   currently has a paper jam.  In many cases however, where the Printer
ToP   noToC   RFC2566 - Page 153
   object can accept the request even though the Printer has some error
   condition, the 'successful-ok' status code will be returned.  In such
   a case, the client would look at the returned Job Object Attributes
   or later query the Printer to determine its state and state reasons.

13.1.5.6 server-error-temporary-error (0x0505)

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

13.1.5.7 server-error-not-accepting-jobs (0x0506)

   A temporary error indicating that the Printer is not currently
   accepting jobs, because the administrator has set the value of the
   Printer's "printer-is-not-accepting-jobs" attribute to 'false' (by
   means outside of IPP/1.0).

13.1.5.8 server-error-busy (0x0507)

   A temporary error indicating that the Printer is too busy processing
   jobs and/or other requests. The client SHOULD try the unmodified
   request again at some later point in time with an expectation that
   the temporary busy condition will have been cleared.

13.1.5.9 server-error-job-canceled (0x0508)

   An error indicating that the job has been canceled by an operator or
   the system while the client was transmitting the data to the IPP
   Printer.  If a job-id and job-uri had been created, then they are
   returned in the Print-Job, Send-Document, or Send-URI response as
   usual; otherwise, no job-id and job-uri are returned in the response.

13.2 Status Codes for IPP Operations

   PJ = Print-Job, PU = Print-URI, CJ = Create-Job, SD = Send-Document
   SU = Send-URI, V = Validate-Job, GA = Get-Job-Attributes and
   Get-Printer-Attributes, GJ = Get-Jobs, C = Cancel-Job
ToP   noToC   RFC2566 - Page 154
                                                  IPP Operations
   IPP Status Keyword                       PJ PU CJ SD SU V GA GJ C
   ------------------                       -- -- -- -- -- - -- -- -
   successful-ok                            x  x  x  x  x  x x  x  x
   successful-ok-ignored-or-substituted-    x  x  x  x  x  x x  x  x
        attributes
   successful-ok-conflicting-attributes     x  x  x  x  x  x x  x  x
   client-error-bad-request                 x  x  x  x  x  x x  x  x
   client-error-forbidden                   x  x  x  x  x  x x  x  x
   client-error-not-authenticated           x  x  x  x  x  x x  x  x
   client-error-not-authorized              x  x  x  x  x  x x  x  x
   client-error-not-possible                x  x  x  x  x  x x  x  x
   client-error-timeout                           x  x
   client-error-not-found                   x  x  x  x  x  x x  x  x
   client-error-gone                        x  x  x  x  x  x x  x  x
   client-error-request-entity-too-large    x  x  x  x  x  x x  x  x
   client-error-request-value-too-long      x  x  x  x  x  x x  x  x
   client-error-document-format-not-        x  x     x  x  x x
        supported
   client-error-attributes-or-values-not-   x  x  x  x  x  x x  x  x
        supported
   client-error-uri-scheme-not-supported       x        x
   client-error-charset-not-supported       x  x  x  x  x  x x  x  x
   client-error-conflicting-attributes      x  x  x  x  x  x x  x  x
   server-error-internal-error              x  x  x  x  x  x x  x  x
   server-error-operation-not-supported        x  x  x  x
   server-error-service-unavailable         x  x  x  x  x  x x  x  x
   server-error-version-not-supported       x  x  x  x  x  x x  x  x
   server-error-device-error                x  x  x  x  x
   server-error-temporary-error             x  x  x  x  x
   server-error-not-accepting-jobs          x  x  x        x
   server-error-busy                        x  x  x  x  x  x x  x  x
   server-error-job-canceled                x        x


(next page on part 7)

Next Section