tech-invite   World Map     

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

RFC 3196

 
 
 

Internet Printing Protocol/1.1: Implementor's Guide

Part 2 of 5, p. 17 to 36
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 17 
3.1.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.

Top      Up      ToC       Page 18 
   IIG Sect #         Flow                 IPP error status codes
   ----------         ----                 ----------------------
                        |
                        v          err
   3.1.2.1.1   <Validate version>  --> server-error-version-not-
                                       supported
                      ok|
                        v          err
   3.1.2.1.2  <Validate operation> --> server-error-operation-not-
                                       supported
                      ok|
                        v          err
   3.1.2.1.4.1- <Validate presence> --> client-error-bad-request
   3.1.2.1.4.2    <of attributes>
                      ok|
                        v          err
   3.1.2.1.4.3 <Validate presence> --> client-error-bad-request
               <of operation attr>
                      ok|
                        v          err
   3.1.2.1.5  <Validate values of> --> client-error-bad-request
               <operation attrs>       client-error-request-value-
                                       too-long
             <(length, tag, range,>
                 <multi-value)>
                      ok|
                        v          err
   3.1.2.1.5    <Validate values>  --> client-error-bad-request
             <with supported values>   client-error-charset-not-
                                       supported
                      ok|              client-error-attributes-or-
                                       values-
                        |                           not-supported
                        v          err
   3.1.2.1.6 <Validate optionally> --> client-error-bad-request
                <operation attr>       client-error-natural-language-
                                       not-supported
                        |              client-error-request-value-
                                       too-long
                        |              client-error-attributes-or-
                                       values-not-supported

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

Top      Up      ToC       Page 19 
   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 major version number matches, but the minor version
   number does not, the Printer SHOULD accept and attempt to process the
   request, or MAY reject the request and return the 'server-error-
   version-not-supported' status code.  In all cases, the Printer MUST
   return the nearest version number that it supports.  For example,
   suppose that an IPP/1.2 Printer supports versions '1.1' and '1.2'.
   The following responses are conforming:

               Table 6 - Examples of validating IPP version

      Client supplies   Printer Accept Request?   Printer returns


      1.0               yes (SHOULD)              1.1

      1.0               no (SHOULD NOT)           1.1

      1.1               yes (MUST)                1.1

      1.2               yes (MUST)                1.2

      1.3               yes (SHOULD)              1.2

      1.3               no (SHOULD NOT)           1.2

   It is advantageous for Printers to support both IPP/1.1 and IPP/1.0,
   so that they can interoperate with either client implementations.
   Some implementations may allow an Administrator to explicitly disable
   support for one or the other by setting the "ipp-versions-supported"
   Printer description attribute.

Top      Up      ToC       Page 20 
   Likewise, it is advantageous for clients to support both versions to
   allow interoperability with new and legacy Printers.

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

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

   Note: The "version-number", "operation-id", and the "request-id"
   parameters are in fixed octet positions in the IPP/1.1 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.

3.1.2.1.4   Validate attribute group and attribute presence and order

   The order of the following validation steps depends on
   implementation.

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

Top      Up      ToC       Page 21 
   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.

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

3.1.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 [RFC2911] 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:

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

Top      Up      ToC       Page 22 
      accepts the request and uses the first occurrence of the attribute
      no matter where it is

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

      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
   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 [RFC2911] 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 or operation that an IPP
            object MUST support
      O     indicates an OPTIONAL attribute or operation 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.
      +     indicates that this is not a IPP/1.0 operation, but is only
            a part of IPP/1.1 and future versions of IPP.

Top      Up      ToC       Page 23 
   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 (R):
     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 (R*)
          job-k-octets (O*)
          job-impressions (O*)
          job-media-sheets (O*)
     Group 2: Job Template Attributes (R*)
          <Job Template attributes> (O*)
               (see [RFC2911] Section 4.2)
     Group 3: Document Content (R)
          <document content>

   Validate-Job Request (R):
     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 (R*)
          job-k-octets (O*)
          job-impressions (O*)
          job-media-sheets (O*)
     Group 2: Job Template Attributes (R*)
          <Job Template attributes> (O*)
               (see [RFC2911] Section 4.2)

Top      Up      ToC       Page 24 
   Print-URI Request (O):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          printer-uri (R)
          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 (R*)
          job-k-octets (O*)
          job-impressions (O*)
          job-media-sheets (O*)
     Group 2: Job Template Attributes (R*)
          <Job Template attributes> (O*) (see
               (see [RFC2911] Section 4.2)

   Create-Job Request (O):
     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 [RFC2911] Section 4.2)

   Get-Printer-Attributes Request (R):
     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-Jobs Request (R):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)

Top      Up      ToC       Page 25 
          printer-uri (R)
          requesting-user-name (R*)
          limit (R*)
          requested-attributes (R*)
          which-jobs (R*)
          my-jobs (R*)

   Send-Document Request (O):
     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 (R*)
     Group 2: Document Content (R*)
          <document content>

   Send-URI Request (O):
     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 (R*)

   Cancel-Job Request (R):
   Release-Job Request (O+):
     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*)

Top      Up      ToC       Page 26 
   Get-Job-Attributes Request (R):
     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*)

   Pause-Printer Request (O+):
   Resume-Printer Request (O+):
   Purge-Printer Request (O+):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          printer-uri (R)
          requesting-user-name (R*)

   Hold-Job Request (O+):
   Restart-Job Request (O+):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          (printer-uri & job-id) | job-uri (R)
          requesting-user-name (R*)
          job-hold-until (R*)
          message (O*)

   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 (R):
   Create-Job Response (O):
   Send-Document Response (O):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          status-message (O*)
          detailed-status-message (O*)
     Group 2: Unsupported Attributes (R*) (see Note 3)
      n    <unsupported attributes> (R*)
     Group 3: Job Object Attributes(R*) (see Note 2)
          job-uri (R)
          job-id (R)

Top      Up      ToC       Page 27 
          job-state (R)
          job-state-reasons (O* | R+)
          job-state-message (O*)
          number-of-intervening-jobs (O*)

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

   Print-URI Response (O):
   Send-URI Response (O):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          status-message (O*)
          detailed-status-message (O*)
          document-access-error (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* | R+)
          job-state-message (O*)
          number-of-intervening-jobs (O*)

   Get-Printer-Attributes Response (R):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          status-message (O*)
          detailed-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*)

Top      Up      ToC       Page 28 
   Get-Jobs Response (R):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          status-message (O*)
          detailed-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*)

   Get-Job-Attributes Response (R):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          status-message (O*)
          detailed-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*)

   Pause-Printer Response (O+):
   Resume-Printer Response (O+):
   Purge-Printer Response (O+):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          status-message (O*)
          detailed-status-message (O*)
     Group 2: Unsupported Attributes (R*) (see Note 4)
          <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.

   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      Up      ToC       Page 29 
   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.

3.1.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 [RFC2911] Section 4.1,

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

      c) that the value is in the range specified for that Operation
         attribute according to [RFC2911] 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 [RFC2911] Section 3.

   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.

Top      Up      ToC       Page 30 
   -----------------------------------------------

   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.

   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.

Top      Up      ToC       Page 31 
   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'

      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 the client-supplied URI scheme is not supported, i.e., the
      value is not in the Printer object's referenced-uri-scheme-
      supported" attribute, the Printer object MUST reject the request

Top      Up      ToC       Page 32 
      and return the 'client-error-uri-scheme-not-supported' status
      code. 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.

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

Top      Up      ToC       Page 33 
      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.

   -----------------------------------------------

3.1.2.1.6   Validate the values of the OPTIONAL Operation attributes

   OPTIONAL Operation attributes are those that an IPP object MAY
   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 3.1.2.1.5.  As in Section 3.1.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
   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.

Top      Up      ToC       Page 34 
   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,
      REJECT/RETURN 'client-error-compression-not-supported'.

      Note to IPP/1.0 implementers:  Support for the "compression"
      attribute was optional in IPP/1.0 and was changed to REQUIRED in
      IPP/1.1.  However, an IPP/1.0 object SHOULD at least check for the
      "compression" attribute being present and reject the create
      request, if they don't support "compression".  Not checking is a
      bug, since the data will be unintelligible.

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

Top      Up      ToC       Page 35 
   job-impressions (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-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

Top      Up      ToC       Page 36 
   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 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.


Next RFC Part