tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 2639


Pages: 64
Top     in Index     Prev     Next
 

Internet Printing Protocol/1.0: Implementer's Guide

Part 1 of 3, p. 1 to 26
None       Next RFC Part

Obsoleted by:    3196


Top       ToC       Page 1 
Network Working Group                                        T. Hastings
Request for Comments: 2639                                     C. Manros
Category: Informational                                Xerox Corporation
                                                               July 1999


          Internet Printing Protocol/1.0: Implementer's Guide

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

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 technologies.  This document contains
   information that supplements the IPP Model and Semantics [RFC2566]
   and the IPP Transport and Encoding [RFC2565] documents.  It is
   intended to help implementers understand IPP/1.0 and some of the
   considerations that may assist them in the design of their client
   and/or IPP object implementations.  For example, a typical order of
   processing requests is given, including error checking.  Motivation
   for some of the specification decisions is also included.

   The full set of IPP documents includes:

     Design Goals for an Internet Printing Protocol [RFC2567]
     Rationale for the Structure and Model and Protocol for the Internet
        Printing Protocol [RFC2568]
     Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
     Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
     Mapping between LPD and IPP Protocols [RFC2569]

   The document, "Design Goals for an Internet Printing Protocol", takes
   a broad look at distributed printing functionality, and it enumerates
   real-life scenarios that help to clarify the features that need to be
   included in a printing protocol for the Internet.  It identifies
   requirements for three types of users: end users, operators, and

Page 2 
   administrators.  The design goals document calls out a subset of end
   user requirements that are satisfied in IPP/1.0.  Operator and
   administrator requirements are out of scope for version 1.0.

   The document, "Rationale for the Structure and Model and Protocol for
   the Internet Printing Protocol", describes IPP from a high level
   view, defines a roadmap for the various documents that form the suite
   of IPP specifications, and gives background and rationale for the
   IETF working group's major decisions.

   The document, "Internet Printing Protocol/1.0: Model and Semantics",
   describes a simplified model with abstract objects, their attributes,
   and their operations.  The model introduces a Printer and a Job.  The
   Job supports multiple documents per Job.  The model document also
   addresses how security, internationalization, and directory issues
   are addressed.

   The document, "Internet Printing Protocol/1.0: Encoding and
   Transport", is a formal mapping of the abstract operations and
   attributes defined in the model document onto HTTP/1.1.  It also
   defines the encoding rules for a new Internet media type called
   "application/ipp".

   The document, "Mapping between LPD and IPP Protocols", gives some
   advice to implementers of gateways between IPP and LPD (Line Printer
   Daemon) implementations.

Table of Contents

  1  Introduction......................................................4
   1.1 Conformance language............................................4
   1.2 Other terminology...............................................5
  2  Model and Semantics...............................................5
   2.1 Summary of Operation Attributes.................................5
   2.2 Suggested Operation Processing Steps for IPP Objects ..........10
       2.2.1 Suggested Operation Processing Steps for all Operations..11
       2.2.1.1  Validate version number...............................11
       2.2.1.2  Validate operation identifier.........................11
       2.2.1.3  Validate the request identifier.......................11
       2.2.1.4  Validate attribute group and attribute presence and
                order.................................................12
       2.2.1.5  Validate the values of the REQUIRED Operation
                attributes............................................19
       2.2.1.6  Validate the values of the OPTIONAL Operation
                attributes............................................23
     2.2.2 Suggested Additional Processing Steps for Operations that
           Create/Validate Jobs and Add Documents.....................26
       2.2.2.1  Default "ipp-attribute-fidelity" if not supplied......26

Top      ToC       Page 3 
       2.2.2.2  Check that the Printer object is accepting jobs.......26
       2.2.2.3  Validate the values of the Job Template attributes....26
     2.2.3 Algorithm for job validation...............................27
       2.2.3.1  Check for conflicting Job Template attributes values..33
       2.2.3.2  Decide whether to REJECT the request..................33
       2.2.3.3  For the Validate-Job operation, RETURN one of the
                success status codes..................................34
       2.2.3.4  Create the Job object with attributes to support......34
       2.2.3.5  Return one of the success status codes................36
       2.2.3.6  Accept appended Document Content......................36
       2.2.3.7  Scheduling and Starting to Process the Job............36
       2.2.3.8  Completing the Job....................................37
       2.2.3.9  Destroying the Job after completion...................37
       2.2.3.10 Interaction with "ipp-attribute-fidelity".............37
   2.3 Status codes returned by operation ............................37
     2.3.1 Printer Operations.........................................38
       2.3.1.1  Print-Job.............................................38
       2.3.1.2  Print-URI.............................................40
       2.3.1.3  Validate-Job..........................................40
       2.3.1.4  Create-Job............................................41
       2.3.1.5  Get-Printer-Attributes................................41
       2.3.1.6  Get-Jobs..............................................42
     2.3.2 Job Operations.............................................43
       2.3.2.1  Send-Document.........................................43
       2.3.2.2  Send-URI..............................................44
       2.3.2.3  Cancel-Job............................................44
       2.3.2.4  Get-Job-Attributes....................................45
   2.4 Validate-Job...................................................46
   2.5 Case Sensitivity in URIs ......................................46
   2.6 Character Sets, natural languages, and internationalization....46
     2.6.1 Character set code conversion support .....................46
     2.6.2 What charset to return when an unsupported charset is
           requested?.................................................48
     2.6.3 Natural Language Override (NLO) ...........................48
   2.7 The "queued-job-count" Printer Description attribute...........50
     2.7.1 Why is "queued-job-count" RECOMMENDED?.....................50
     2.7.2 Is "queued-job-count" a good measure of how busy a printer
           is?........................................................50
   2.8 Sending empty attribute groups ................................50
   2.9 Returning unsupported attributes in Get-Xxxx responses ........51
   2.10 Returning job-state in Print-Job response ....................51
   2.11 Flow controlling the data portion of a Print-Job request .....52
   2.12 Multi-valued attributes ......................................53
   2.13 Querying jobs with IPP that were submitted using other job
        submission protocols .........................................53
   2.14 The 'none' value for empty sets ..............................54
   2.15 Get-Jobs, my-jobs='true', and 'requesting-user-name'?.........54

Top      ToC       Page 4 
   2.16 The "multiple-document-handling" Job Template attribute and
        support of multiple document jobs.............................54
  3  Encoding and Transport...........................................55
   3.1 General Headers................................................56
   3.2 Request  Headers...............................................57
   3.3 Response Headers...............................................58
   3.4 Entity  Headers................................................59
   3.5 Optional support for HTTP/1.0..................................60
   3.6 HTTP/1.1 Chunking..............................................60
     3.6.1 Disabling IPP Server Response Chunking.....................60
     3.6.2 Warning About the Support of Chunked Requests..............60
  4  References.......................................................61
   4.1 Authors' Addresses.............................................62
  5  Security Considerations..........................................62
  6  Notices..........................................................62
  Full Copyright Statement............................................64

1  Introduction

  This document contains information that supplements the IPP Model and
  Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565]
  documents.  As such this information is not part of the formal
  specifications.  Instead information is presented to help implementers
  understand the specification, including some of the motivation for
  decisions taken by the committee in developing the specification.
  Some of the implementation considerations are intended to help
  implementers design their client and/or IPP object implementations.
  If there are any contradictions between this document and [RFC2566] or
  [RFC2565], those documents take precedence over this document.

1.1 Conformance language

  Usually, this document does not contain the terminology MUST, MUST
  NOT, MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL.
  However, when those terms do appear in this document, their intent is
  to repeat what the [RFC2566] and [RFC2565] documents require and
  allow, rather than specifying additional conformance requirements.
  These terms are defined in section 13 on conformance terminology in
  [RFC2566], most of which is taken from RFC 2119 [RFC2119].

  Implementers should read section 13 in [RFC2566] in order to
  understand these capitalized words.  The words MUST, MUST NOT, and
  REQUIRED indicate what implementations are required to support in a
  client or IPP object in order to be conformant to [RFC2566] and
  [RFC2565].  MAY, NEED NOT, and OPTIONAL indicate was is merely allowed
  as an implementer option.  The verbs SHOULD and SHOULD NOT indicate
  suggested behavior, but which is not required or disallowed,
  respectively, in order to conform to the specification.

Top      ToC       Page 5 
1.2 Other terminology

  The term "sender" refers to the client that sends a request or an IPP
  object that returns a response.  The term "receiver" refers to the IPP
  object that receives a request and to a client that receives a
  response.

2  Model and Semantics

  This section discusses various aspects of IPP/1.0 Model and Semantics
  [RFC2566].

2.1 Summary of Operation Attributes

  Legend for the following table:

      R indicates a REQUIRED operation or attribute for an
        implementation to support

      O indicates an OPTIONAL operation or attribute for an
        implementation to support

Top      ToC       Page 6 
    Table 1.  Summary of operation attributes for Printer operations

                           Printer Operations

                         Requests                         Responses

     Operation           Print-   Pri  Crea Get-     Get- All
     Attributes          Job,     nt-  te-  Printer- Jobs Opera-
                         Validate URI  Job  Attribut      tions
                         -Job     (O)  (O)  es

     Operation parameters--REQUIRED to be supplied by the sender

     operation-id           R      R    R      R      R

     status-code                                            R

     request-id             R      R    R      R      R     R

     version-number         R      R    R      R      R     R

     Operation attributes-REQUIRED to be supplied by the sender

     attributes-charset     R      R    R      R      R     R

     attributes-            R      R    R      R      R     R
     natural-language

     document-uri                   R

     job-id*

     job-uri*

     last-document

     printer-uri            R      R    R      R      R

     Operation attributes-RECOMMENDED to be supplied by the sender

     job-name               R      R    R

     requesting-user-       R      R    R      R      R
     name

Top      ToC       Page 7 
                           Printer Operations

                         Requests                        Responses

      Operation          Print-   Pri  Crea Get-    Get-  All
      Attributes         Job,     nt-  te-  Printer Jobs  Opera-
                         Vali-    URI  Job  Attri-        tions
                         date-Job (O)  (O)  butes

      Operation attributes-OPTIONAL to be supplied by the sender

      status-message                                         O

      compression           O     O

      document-format       R     R           O

      document-name         O     O

      document-natural-     O     O
      language

      ipp-attribute-        R     R    R
      fidelity

      job-impressions       O     O    O

      job-k-octets          O     O    O

      job-media-sheets      O     O    O

      limit                                           R

      message

      my-jobs                                         R

      requested-                               R      R
      attributes

      which-jobs                                      R

      *  "job-id" is REQUIRED only if used together with
      "printer-uri" to identify the target job; otherwise, "job-
      uri" is REQUIRED.

Top      ToC       Page 8 
      Table 2.  Summary of operation attributes for Job operations


                         Requests                         Responses

      Operation          Send-    Send-  Cancel  Get-     All
      Attributes         Document URI    -Job    Job-     Opera-
                         (O)      (O)            Attri-   tions
                                                 butes

      Operation parameters--REQUIRED to be supplied by the sender

      operation-id          R       R      R       R

      status-code                                          R

      request-id            R       R      R       R       R

      version-number        R       R      R       R       R

      Operation attributes-REQUIRED to be supplied by the sender

      attributes-           R       R      R       R       R
      charset

      attributes-           R       R      R       R       R
      natural-language

      document-uri                   R

      job-id*               R       R      R       R

      job-uri*              R       R      R       R

      last-document         R       R

      printer-uri           R       R      R       R

      Operation attributes-RECOMMENDED to be supplied by the
      sender

      job-name

      requesting-user-      R       R      R       R
      name

Top      ToC       Page 9 
                             Job Operations

                           Requests                      Responses

     Operation Attributes  Send-    Send-   Cance Get-    All
                           Document URI     l-Job Job-    Opera-
                           (O)      (O)           Attri-  tions
                                                  butes

     Operation attributes.OPTIONAL to be supplied by the sender

     status-message                                       O

     compression               O       O

     document-format           R       R

     document-name             O       O

     document-natural-         O       O
     language

     ipp-attribute-
     fidelity

     job-impressions

     job-k-octets

     job-media-sheets

     limit

     message                                   O

     my-jobs

     requested-attributes                             R

     which-jobs

     *  "job-id" is REQUIRED only if used together with "printer-
     uri" to identify the target job; otherwise, "job-uri" is
     REQUIRED.

Top      ToC       Page 10 
2.2 Suggested Operation Processing Steps for IPP Objects

   This section suggests the steps and error checks that an IPP object
   MAY perform when processing requests and returning responses.  An IPP
   object MAY perform some or all of the error checks.  However, some
   implementations MAY choose to be more forgiving than the error checks
   shown here, in order to be able to accept requests from non-
   conforming clients.  Not performing all of these error checks is a
   so-called "forgiving" implementation.  On the other hand, clients
   that successfully submit requests to IPP objects that do perform all
   the error checks will be more likely to be able to interoperate with
   other IPP object implementations.  Thus an implementer of an IPP
   object needs to decide whether to be a "forgiving" or a "strict"
   implementation.  Therefore, the error status codes returned may
   differ between implementations.   Consequentially, client SHOULD NOT
   expect exactly the error code processing described in this section.

   When an IPP object receives a request, the IPP object either accepts
   or rejects the request. In order to determine whether or not to
   accept or reject the request, the IPP object SHOULD execute the
   following steps.  The order of the steps may be rearranged and/or
   combined, including making one or multiple passes over the request.

   A client MUST supply requests that would pass all of the error checks
   indicated here in order to be a conforming client.  Therefore, a
   client SHOULD supply requests that are conforming, in order to avoid
   being rejected by some IPP object implementations and/or risking
   different semantics by different implementations of forgiving
   implementations.  For example, a forgiving implementation that
   accepts multiple occurrences of the same attribute, rather than
   rejecting the request might use the first occurrences, while another
   might use the last occurrence.  Thus such a non-conforming client
   would get different results from the two forgiving implementations.

   In the following, processing continues step by step until a "RETURNS
   the xxx status code ." statement is encountered.  Error returns are
   indicated by the verb: "REJECTS".  Since clients have difficulty
   getting the status code before sending all of the document data in a
   Print-Job request, clients SHOULD use the Validate-Job operation
   before sending large documents to be printed, in order to validate
   whether the IPP Printer will accept the job or not.

   It is assumed that security authentication and authorization has
   already taken place at a lower layer.

Top      ToC       Page 11 
2.2.1 Suggested Operation Processing Steps for all Operations

   This section is intended to apply to all operations.  The next
   section contains the additional steps for the Print-Job, Validate-
   Job, Print-URI, Create-Job, Send-Document, and Send-URI operations
   that create jobs, adds documents, and validates jobs.

2.2.1.1   Validate version number

   Every request and every response contains the "version-number"
   attribute.  The value of this attribute is the major and minor
   version number of the syntax and semantics that the client and IPP
   object is using, respectively.  The "version-number" attribute
   remains in a fixed position across all future versions so that all
   clients and IPP object that support future versions can determine
   which version is being used.  The IPP object checks to see if the
   major version number supplied in the request is supported.  If not,
   the Printer object REJECTS the request and RETURNS the 'server-
   error-version-not-supported' status code in the response.  The IPP
   object returns in the "version-number" response attribute the major
   and minor version for the error response.  Thus the client can learn
   at least one major and minor version that the IPP object supports.
   The IPP object is encouraged to return the closest version number to
   the one supplied by the client.

   The checking of the minor version number is implementation dependent,
   however if the client supplied minor version is explicitly supported,
   the IPP object MUST respond using that identical minor version
   number.  If the requested minor version is not supported (the
   requested minor version is either higher or lower) than a supported
   minor version, the IPP object SHOULD return the closest supported
   minor version.

2.2.1.2   Validate operation identifier

   The Printer object checks to see if the "operation-id" attribute
   supplied by the client is supported as indicated in the Printer
   object's "operations-supported" attribute.  If not, the Printer
   REJECTS the request and returns the 'server-error-operation-not-
   supported' status code in the response.

2.2.1.3   Validate the request identifier

   The Printer object SHOULD NOT check to see if the "request-id"
   attribute supplied by the client is in range: between 1 and 2**31 - 1
   (inclusive), but copies all 32 bits.

Top      ToC       Page 12 
   Note: The "version-number",  "operation-id", and the "request-id"
   parameters are in fixed octet positions in the IPP/1.0 encoding.  The
   "version-number" parameter will be the same fixed octet position in
   all versions of the protocol.  These fields are validated before
   proceeding with the rest of the validation.

2.2.1.4   Validate attribute group and attribute presence and order

   The order of the following validation steps depends on
   implementation.

2.2.1.4.1 Validate the presence and order of attribute groups

   Client requests and IPP object responses contain attribute groups
   that Section 3 requires to be present and in a specified order.  An
   IPP object verifies that the attribute groups are present and in the
   correct order in requests supplied by clients (attribute groups
   without an * in the following tables).

   If an IPP object receives a request with (1) required attribute
   groups missing, or (2) the attributes groups are out of order, or (3)
   the groups are repeated, the IPP object REJECTS the request and
   RETURNS the 'client-error-bad-request' status code.  For example, it
   is an error for the Job Template Attributes group to occur before the
   Operation Attributes group, for the Operation Attributes group to be
   omitted, or for an attribute group to occur more than once, except in
   the Get-Jobs response.

   Since this kind of attribute group error is most likely to be an
   error detected by a client developer rather than by a customer, the
   IPP object NEED NOT return an indication of which attribute group was
   in error in either the Unsupported Attributes group or the Status
   Message.  Also, the IPP object NEED NOT find all attribute group
   errors before returning this error.

2.2.1.4.2 Ignore unknown attribute groups in the expected position

   Future attribute groups may be added to the specification at the end
   of requests just before the Document Content and at the end of
   response, except for the Get-Jobs response, where it maybe there or
   before the first job attributes returned.  If an IPP object receives
   an unknown attribute group in these positions, it ignores the entire
   group, rather than returning an error, since that group may be a new
   group in a later minor version of the protocol that can be ignored.
   (If the new attribute group cannot be ignored without confusing the
   client, the major version number would have been increased in the

Top      ToC       Page 13 
   protocol document and in the request).  If the unknown group occurs
   in a different position, the IPP object REJECTS the request and
   RETURNS the 'client-error-bad-request' status code.

   Clients also ignore unknown attribute groups returned in a response.

   Note:  By validating that requests are in the proper form, IPP
   objects force clients to use the proper form which, in turn,
   increases the chances that customers will be able to use such clients
   from multiple vendors with IPP objects from other vendors.

2.2.1.4.3 Validate the presence of a single occurrence of required
          Operation attributes

   Client requests and IPP object responses contain Operation attributes
   that [RFC2566] Section 3 requires to be present.  Attributes within a
   group may be in any order, except for the ordering of target,
   charset, and natural languages attributes.  These attributes MUST be
   first, and MUST be supplied in the following order: charset, natural
   language, and then target. An IPP object verifies that the attributes
   that Section 4 requires to be supplied by the client have been
   supplied in the request (attributes without an * in the following
   tables).  An asterisk (*) indicates groups and Operation attributes
   that the client may omit in a request or an IPP object may omit in a
   response.

   If an IPP object receives a request with required attributes missing
   or repeated from a group or in the wrong position, the behavior of
   the IPP object is IMPLEMENTATION DEPENDENT.  Some of the possible
   implementations are:

      1.REJECTS the request and RETURNS the 'client-error-bad-request'
        status code

      2.accepts the request and uses the first occurrence of the
        attribute no matter where it is

      3.accepts the request and uses the last occurrence of the
        attribute no matter where it is

      4.accept the request and assume some default value for the missing
        attribute

   Therefore, client MUST send conforming requests, if they want to
   receive the same behavior from all IPP object implementations.  For
   example, it is an error for the "attributes-charset" or "attributes-
   natural-language" attribute to be omitted in any operation request,
   or for an Operation attribute to be supplied in a Job Template group

Top      ToC       Page 14 
   or a Job Template attribute to be supplied in an Operation Attribute
   group in a create request.  It is also an error to supply the
   "attributes-charset" attribute twice.

   Since these kinds of attribute errors are most likely to be detected
   by a client developer rather than by a customer, the IPP object NEED
   NOT return an indication of which attribute was in error in either
   the Unsupported Attributes group or the Status Message.  Also, the
   IPP object NEED NOT find all attribute errors before returning this
   error.

   The following tables list all the attributes for all the operations
   by attribute group in each request and each response.  The order of
   the groups is the order that the client supplies the groups as
   specified in [RFC2566] Section 3.  The order of the attributes within
   a group is arbitrary, except as noted for some of the special
   operation attributes (charset, natural language, and target).  The
   tables below use the following notation:

     R   indicates a REQUIRED attribute that an IPP object MUST support
     O   indicates an OPTIONAL attribute that an IPP object NEED NOT
               support
     *   indicates that a client MAY omit the attribute in a request
               and that an IPP object MAY omit the attribute in a
               response. The absence of an * means that a client MUST
               supply the attribute in a request and an IPP object MUST
               supply the attribute in a response.

                            Operation Requests

   The tables below show the attributes in their proper attribute groups
   for operation requests:

   Note: All operation requests contain "version-number", "operation-
   id", and "request-id" parameters.

   Print-Job Request:
        Group 1: Operation Attributes (R)
             attributes-charset (R)
             attributes-natural-language (R)
             printer-uri (R)
             requesting-user-name (R*)
             job-name (R*)
             ipp-attribute-fidelity (R*)
             document-name (R*)
             document-format (R*)
             document-natural-language (O*)
             compression (O*)

Top      ToC       Page 15 
             job-k-octets (O*)
             job-impressions (O*)
             job-media-sheets (O*)
        Group 2: Job Template Attributes (R*)
             <Job Template attributes> (O*)
                  (see [RFC2566] Section 4.2)
        Group 3: Document Content (R)
             <document content>

   Validate-Job Request:
        Group 1: Operation Attributes (R)
             attributes-charset (R)
             attributes-natural-language (R)
             printer-uri (R)
             requesting-user-name (R*)
             job-name (R*)
             ipp-attribute-fidelity (R*)
             document-name (R*)
             document-format (R*)
             document-natural-language (O*)
             compression (O*)
             job-k-octets (O*)
             job-impressions (O*)
             job-media-sheets (O*)
        Group 2: Job Template Attributes (R*)
             <Job Template attributes> (O*)
                  (see [RFC2566] Section 4.2)

   Create-Job Request:
        Group 1: Operation Attributes (R)
             attributes-charset (R)
             attributes-natural-language (R)
             printer-uri (R)
             requesting-user-name (R*)
             job-name (R*)
             ipp-attribute-fidelity (R*)
             job-k-octets (O*)
             job-impressions (O*)
             job-media-sheets (O*)
        Group 2: Job Template Attributes (R*)
             <Job Template attributes> (O*) (see
                  (see [RFC2566] Section 4.2)

   Print-URI Request:
        Group 1: Operation Attributes (R)
             attributes-charset (R)
             attributes-natural-language (R)
             printer-uri (R)

Top      ToC       Page 16 
             document-uri (R)
             requesting-user-name (R*)
             job-name (R*)
             ipp-attribute-fidelity (R*)
             document-name (R*)
             document-format (R*)
             document-natural-language (O*)
             compression (O*)
             job-k-octets (O*)
             job-impressions (O*)
             job-media-sheets (O*)
        Group 2: Job Template Attributes (R*)
             <Job Template attributes> (O*) (see
                  (see [RFC2566] Section 4.2)

   Send-Document Request:
        Group 1: Operation Attributes (R)
             attributes-charset (R)
             attributes-natural-language (R)
             (printer-uri & job-id) | job-uri (R)
             last-document (R)
             requesting-user-name (R*)
             document-name (R*)
             document-format (R*)
             document-natural-language (O*)
             compression (O*)
        Group 2: Document Content (R*)
             <document content>

   Send-URI Request:
        Group 1: Operation Attributes (R)
             attributes-charset (R)
             attributes-natural-language (R)
             (printer-uri & job-id) | job-uri (R)
             last-document (R)
             document-uri (R)
             requesting-user-name (R*)
             document-name (R*)
             document-format (R*)
             document-natural-language (O*)
             compression (O*)

Top      ToC       Page 17 
   Cancel-Job Request:
        Group 1: Operation Attributes (R)
             attributes-charset (R)
             attributes-natural-language (R)
             (printer-uri & job-id) | job-uri (R)
             requesting-user-name (R*)
             message (O*)

   Get-Printer-Attributes Request:
        Group 1: Operation Attributes (R)
             attributes-charset (R)
             attributes-natural-language (R)
             printer-uri (R)
             requesting-user-name (R*)
             requested-attributes (R*)
             document-format (R*)

   Get-Job-Attributes Request:
        Group 1: Operation Attributes (R)
             attributes-charset (R)
             attributes-natural-language (R)
             (printer-uri & job-id) | job-uri (R)
             requesting-user-name (R*)
             requested-attributes (R*)

   Get-Jobs Request:
        Group 1: Operation Attributes (R)
             attributes-charset (R)
             attributes-natural-language (R)
             printer-uri (R)
             requesting-user-name (R*)
             limit (R*)
             requested-attributes (R*)
             which-jobs (R*)
             my-jobs (R*)


                            Operation Responses

   The tables below show the response attributes in their proper
   attribute groups for responses.

   Note: All operation responses contain "version-number", "status-
   code", and "request-id" parameters.

   Print-Job Response:
   Print-URI Response:
   Create-Job Response:

Top      ToC       Page 18 
   Send-Document Response:
   Send-URI Response:
        Group 1: Operation Attributes (R)
             attributes-charset (R)
             attributes-natural-language (R)
             status-message (O*)
        Group 2: Unsupported Attributes (R*) (see Note 3)
             <unsupported attributes> (R*)
        Group 3: Job Object Attributes(R*) (see Note 2)
             job-uri (R)
             job-id (R)
             job-state (R)
             job-state-reasons (O*)
             job-state-message (O*)
             number-of-intervening-jobs (O*)

   Validate-Job Response:
   Cancel-Job Response:
        Group 1: Operation Attributes (R)
             attributes-charset (R)
             attributes-natural-language (R)
             status-message (O*)
        Group 2: Unsupported Attributes (R*) (see Note 3)
             <unsupported attributes> (R*)

   Note 2 - the Job Object Attributes and Printer Object Attributes are
   returned only if the IPP object returns one of the success status
   codes.

   Note 3 - the Unsupported Attributes Group is present only if the
   client included some Operation and/or Job Template attributes or
   values that the Printer doesn't support whether a success or an error
   return.

   Get-Printer-Attributes Response:
        Group 1: Operation Attributes (R)
             attributes-charset (R)
             attributes-natural-language (R)
             status-message (O*)
        Group 2: Unsupported Attributes (R*) (see Note 4)
             <unsupported attributes> (R*)
        Group 3: Printer Object Attributes(R*) (see Note 2)
             <requested attributes> (R*)

   Note 4 - the Unsupported Attributes Group is present only if the
   client included some Operation attributes that the Printer doesn't
   support whether a success or an error return.

Top      ToC       Page 19 
   Get-Job-Attributes Response:
        Group 1: Operation Attributes (R)
             attributes-charset (R)
             attributes-natural-language (R)
             status-message (O*)
        Group 2: Unsupported Attributes (R*) (see Note 4)
             <unsupported attributes> (R*)
        Group 3: Job Object Attributes(R*) (see Note 2)
             <requested attributes> (R*)

   Get-Jobs Response:
        Group 1: Operation Attributes (R)
             attributes-charset (R)
             attributes-natural-language (R)
             status-message (O*)
        Group 2: Unsupported Attributes (R*) (see Note 4)
             <unsupported attributes> (R*)
        Group 3: Job Object Attributes(R*) (see Note 2, 5)
             <requested attributes> (R*)

   Note 5:  for the Get-Jobs operation the response contains a separate
   Job Object Attributes group 3 to N containing requested-attributes
   for each job object in the response.

2.2.1.5   Validate the values of the REQUIRED Operation attributes

   An IPP object validates the values supplied by the client of the
   REQUIRED Operation attribute that the IPP object MUST support.  The
   next section specifies the validation of the values of the OPTIONAL
   Operation attributes that IPP objects MAY support.

   The IPP object performs the following syntactic validation checks of
   each Operation attribute value:

      a)that the length of each Operation attribute value is correct for
        the attribute syntax tag supplied by the client according to
        [RFC2566] Section 4.1,

      b)that the attribute syntax tag is correct for that Operation
        attribute according to [RFC2566] Section 3,

      c)that the value is in the range specified for that Operation
        attribute according to [RFC2566] Section 3,

      d)that multiple values are supplied by the client only for
        operation attributes that are multi-valued, i.e., that are
        1setOf X according to [RFC2566] Section 3.

Top      ToC       Page 20 
   If any of these checks fail, the IPP object REJECTS the request and
   RETURNS the 'client-error-bad-request' or the 'client-error-request-
   value-too-long' status code.  Since such an error is most likely to
   be an error detected by a client developer, rather than by an end-
   user, the IPP object NEED NOT return an indication of which attribute
   had the error in either the Unsupported Attributes Group or the

   Status Message.  The description for each of these syntactic checks
   is explicitly expressed in the first IF statement in the following
   table.

   In addition, the IPP object checks each Operation attribute value
   against some Printer object attribute or some hard-coded value if
   there is no "xxx-supported" Printer object attribute defined. If its
   value is not among those supported or is not in the range supported,
   then the IPP object REJECTS the request and RETURNS the error status
   code indicated in the table by the second IF statement.  If the value
   of the Printer object's "xxx-supported" attribute is 'no-value'
   (because the system administrator hasn't configured a value), the
   check always fails.

   attributes-charset (charset)

      IF NOT a single non-empty 'charset' value, REJECT/RETURN 'client-
         error-bad-request'.

      IF the value length is greater than 63 octets, REJECT/RETURN '
         client-error-request-value-too-long'.
      IF NOT in the Printer object's "charset-supported" attribute,
         REJECT/RETURN "client-error-charset-not-supported".


   attributes-natural-language(naturalLanguage)

      IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
         'client-error-bad-request'.
      IF the value length is greater than 63 octets, REJECT/RETURN '
         client-error-request-value-too-long'.
      ACCEPT the request even if not a member of the set in the Printer
         object's "generated-natural-language-supported" attribute.  If
         the supplied value is not a member of the Printer object's
         "generated-natural-language-supported" attribute, use the
         Printer object's "natural-language-configured" value.

Top      ToC       Page 21 
   requesting-user-name

      IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
         request'.
      IF the value length is greater than 255 octets, REJECT/RETURN
         'client-error-request-value-too-long'.
      IF the IPP object can obtain a better authenticated name, use it
         instead.


   job-name(name)

      IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
         request'.
      IF the value length is greater than 255 octets, REJECT/RETURN
         'client-error-request-value-too-long'.
      IF NOT supplied by the client, the Printer object creates a name
         from the document-name or document-uri.


   document-name (name)

      IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
         request'.
      IF the value length is greater than 255 octets, REJECT/RETURN
         'client-error-request-value-too-long'.


   ipp-attribute-fidelity (boolean)

      IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
         REJECT/RETURN 'client-error-bad-request'.
      IF the value length is NOT equal to 1 octet, REJECT/RETURN '
         client-error-request-value-too-long'
      IF NOT supplied by the client, the IPP object assumes the value
         'false'.


   document-format (mimeMediaType)

      IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN
         'client-error-bad-request'.
      IF the value length is greater than 255 octets, REJECT/RETURN
         'client-error-request-value-too-long'.
      IF NOT in the Printer object's "document-format-supported"
         attribute, REJECT/RETURN 'client-error-document-format-not-
         supported'

Top      ToC       Page 22 
      IF NOT supplied by the client, the IPP object assumes the value of
         the Printer object's "document-format-default" attribute.


   document-uri (uri)

      IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client-
         error-bad-request'.
      IF the value length is greater than 1023 octets, REJECT/RETURN
         'client-error-request-value-too-long'.
      IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-
         request'.
      IF scheme is NOT in the Printer object's "reference-uri-schemes-
         supported" attribute, REJECT/RETURN 'client-error-uri-scheme-
         not-supported'.
      The Printer object MAY check to see if the document exists and is
         accessible.  If the document is not found or is not accessible,
         REJECT/RETURN 'client-error-not found'.


   last-document (boolean)

      IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
         REJECT/RETURN 'client-error-bad-request'.
      IF the value length is NOT equal to 1 octet, REJECT/RETURN '
         client-error-request-value-too-long'


   job-id (integer(1:MAX))

      IF NOT an single 'integer' value equal to 4 octets AND in the
         range 1 to MAX, REJECT/RETURN 'client-error-bad-request'.

      IF NOT a job-id of an existing Job object, REJECT/RETURN 'client-
         error-not-found' or 'client-error-gone' status code, if keep
         track of recently deleted jobs.


   requested-attributes (1setOf keyword)

      IF NOT one or more 'keyword' values, REJECT/RETURN 'client-error-
         bad-request'.
      IF the value length is greater than 255 octets, REJECT/RETURN
         'client-error-request-value-too-long'.
      Ignore unsupported values which are the keyword names of
         unsupported attributes.  Don't bother to copy such requested
         (unsupported) attributes to the Unsupported Attribute response
         group since the response will not return them.

Top      ToC       Page 23 
   which-jobs (type2 keyword)

      IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
         request'.
      IF the value length is greater than 255 octets, REJECT/RETURN
         'client-error-request-value-too-long'.
      IF NEITHER 'completed' NOR 'not-completed', copy the attribute and
         the unsupported value to the Unsupported Attributes response
         group and REJECT/RETURN 'client-error-attributes-or-values-
         not-supported'.
      Note: a Printer still supports the 'completed' value even if it
         keeps no completed/canceled/aborted jobs:  by returning no jobs
         when so queried.
      IF NOT supplied by the client, the IPP object assumes the 'not-
         completed' value.


   my-jobs (boolean)

      IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
         REJECT/RETURN 'client-error-bad-request'.
      IF the value length is NOT equal to 1 octet, REJECT/RETURN '
         client-error-request-value-too-long'
      IF NOT supplied by the client, the IPP object assumes the 'false'
         value.


   limit (integer(1:MAX))

      IF NOT a single 'integer' value equal to 4 octets AND in the range
         1 to MAX, REJECT/RETURN 'client-error-bad-request'.
      IF NOT supplied by the client, the IPP object returns all jobs, no
         matter how many.

2.2.1.6   Validate the values of the OPTIONAL Operation attributes

   OPTIONAL Operation attributes are those that an IPP object MAY or MAY
   NOT support.  An IPP object validates the values of the OPTIONAL
   attributes supplied by the client.  The IPP object performs the same
   syntactic validation checks for each OPTIONAL attribute value as in
   Section 2.2.1.5.  As in Section 2.2.1.5, if any fail, the IPP object
   REJECTS the request and RETURNS the 'client-error-bad-request' or the
   'client-error-request-value-too-long' status code.

   In addition, the IPP object checks each Operation attribute value
   against some Printer attribute or some hard-coded value if there is
   no "xxx-supported" Printer attribute defined. If its value is not
   among those supported or is not in the range supported, then the IPP

Top      ToC       Page 24 
   object REJECTS the request and RETURNS the error status code
   indicated in the table.  If the value of the Printer object's "xxx-
   supported" attribute is 'no-value' (because the system administrator
   hasn't configured a value), the check always fails.

   If the IPP object doesn't recognize/support an attribute, the IPP
   object treats the attribute as an unknown or unsupported attribute
   (see the last row in the table below).

   document-natural-language (naturalLanguage)

      IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN '
         client-error-bad-request'.
      IF the value length is greater than 63 octets, REJECT/RETURN '
         client-error-request-value-too-long'.
      IF NOT a value that the Printer object supports in document
         formats, (no corresponding "xxx-supported" Printer attribute),
         REJECT/RETURN 'client-error-natural-language-not-supported'.


   compression (type3 keyword)

      IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
         request'.
      IF the value length is greater than 255 octets, REJECT/RETURN '
         client-error-request-value-too-long'.
      IF NOT in the Printer object's "compression-supported" attribute,
         copy the attribute and the unsupported value to the Unsupported
         Attributes response group and REJECT/RETURN 'client-error-
         attributes-or-values-not-supported'.


   job-k-octets (integer(0:MAX))

      IF NOT a single 'integer' value equal to 4 octets,
      REJECT/RETURN 'client-error-bad-request'.
      IF NOT in the range of the Printer object's "job-k-octets-
         supported" attribute, copy the attribute and the unsupported
         value to the Unsupported Attributes response group and
         REJECT/RETURN 'client-error-attributes-or-values-not-
         supported'.


   job-impressions (integer(0:MAX))

      IF NOT a single 'integer' value equal to 4 octets,
      REJECT/RETURN 'client-error-bad-request'.

Top      ToC       Page 25 
      IF NOT in the range of the Printer object's "job-impressions-
         supported" attribute, copy the attribute and the unsupported
         value to the Unsupported Attributes response group and
         REJECT/RETURN 'client-error-attributes-or-values-not-
         supported'.


   job-media-sheets (integer(0:MAX))

      IF NOT a single 'integer' value equal to 4 octets,
      REJECT/RETURN 'client-error-bad-request'.
      IF NOT in the range of the Printer object's "job-media-sheets-
         supported" attribute, copy the attribute and the unsupported
         value to the Unsupported Attributes response group and
         REJECT/RETURN 'client-error-attributes-or-values-not-
         supported'.


   message (text(127))

      IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad-
         request'.
      IF the value length is greater than 127 octets,
      REJECT/RETURN 'client-error-request-value-too-long'.


   unknown or unsupported attribute

      IF the attribute syntax supplied by the client is supported but
         the length is not legal for that attribute syntax,
         REJECT/RETURN 'client-error-request-value-too-long'.
      ELSE copy the attribute and value to the Unsupported Attributes
         response group and change the attribute value to the "out-of-
         band" 'unsupported' value, but otherwise ignore the attribute.

      Note: Future Operation attributes may be added to the protocol
      specification that may occur anywhere in the specified group.
      When the operation is otherwise successful, the IPP object returns
      the 'successful-ok-ignored-or-substituted-attributes' status code.
      Ignoring unsupported Operation attributes in all operations is
      analogous to the handling of unsupported Job Template attributes
      in the create and Validate-Job operations when the client supplies
      the "ipp-attribute-fidelity" Operation attribute with the 'false'
      value.  This last rule is so that we can add OPTIONAL Operation
      attributes to future versions of IPP so that older clients can
      inter-work with new IPP objects and newer clients can inter-work
      with older IPP objects.  (If the new attribute cannot be ignored
      without performing unexpectedly, the major version number would

Top      ToC       Page 26 
      have been increased in the protocol document and in the request).
      This rule for Operation attributes is independent of the value of
      the "ipp-attribute-fidelity" attribute.   For example, if an IPP
      object doesn't support the OPTIONAL "job-k-octets" attribute', the
      IPP object treats "job-k-octets" as an unknown attribute and only
      checks the length for the 'integer' attribute syntax supplied by
      the client.  If it is not four octets, the IPP object REJECTS the
      request and RETURNS the 'client-error-bad-request' status code,
      else the IPP object copies the attribute to the Unsupported
      Attribute response group, setting the value to the "out-of-band" '
      unsupported' value, but otherwise ignores the attribute.



(page 26 continued on part 2)

Next RFC Part