3.1.2.2 Suggested Additional Processing Steps for Operations that
        Create/Validate Jobs and Add Documents

   This section in combination with the previous section recommends the
   processing steps for the Print-Job, Validate-Job, Print-URI, Create-
   Job, Send-Document, and Send-URI operations that IPP objects SHOULD
   use.  These are the operations that create jobs, validate a Print-Job
   request, and add documents to a job.

   IIG Sect #         Flow                 IPP error status codes
   ----------         ----                 ----------------------
                        |
                        v             No
   3.1.2.2.1 <ipp-attribute-fidelity> ------------------+
                  <supplied?>                           |
                     Yes|                               |
                        |  ipp-attribute-fidelity = no  |
                        |<------------------------------+
                        v          No
   3.1.2.2.2       <Printer is>    --> server-error-not-accepting-jobs
                <accepting jobs?>
                     Yes|
                        v          err
   3.1.2.3    <Validate values of> --> client-error-bad-request
           <Job template attributes>   client-error-request-value-too-
                                       long
            <(length, tag, range,>
                 <multi-value)>
                      ok|
                        v          err
   3.1.2.3  <Validate values with> --> client-error-bad-request
             <supported values>        client-error-attributes-or-
                        |              values-not-supported
                        v          err
   3.1.2.3.1   <Any conflicting>   --> client-error-conflicting-
                                       attributes
          <Job Template attr values>   client-error-attributes-or-
                                       values-not-supported
                           v

3.1.2.2.1   Default "ipp-attribute-fidelity" if not supplied

   The Printer object checks to see if the client supplied an "ipp-
   attribute-fidelity" Operation attribute.  If the attribute is not
   supplied by the client, the IPP object assumes that the value is
   'false'.

3.1.2.2.2   Check that the Printer object is accepting jobs

   If the value of the Printer objects "printer-is-accepting-jobs" is
   'false', the Printer object REJECTS the request and RETURNS the
   'server-error-not-accepting-jobs' status code.

3.1.2.2.3   Validate the values of the Job Template attributes

   An IPP object validates the values of all Job Template attribute
   supplied by the client.  The IPP object performs the analogous
   syntactic validation checks of each Job Template attribute value that
   it performs for Operation attributes (see Section 3.1.2.1.5.):

      a) that the length of each 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 attribute
         according to [RFC2911] Sections 4.2 to 4.4.

      c) that multiple values are supplied only for multi-valued
         attributes, i.e., that are 1setOf  X according to [RFC2911]
         Sections 4.2 to 4.4.

   As in Section 3.1.2.1.5, if any of these syntactic checks fail, the
   IPP object REJECTS the request and RETURNS the 'client-error-bad-
   request' or 'client-error-request-value-too-long' status code as
   appropriate, independent of the value of the "ipp-attribute-
   fidelity".  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.

   Each Job Template attribute MUST occur no more than once.  If an IPP
   Printer receives a create request with multiple occurrences of a Job
   Template attribute, it MAY:

      1. reject the operation and return the 'client-error-bad-request'
         error status code

      2. accept the operation and use the first occurrence of the
         attribute

      3. accept the operation and use the last occurrence of the
         attribute

   depending on implementation.  Therefore, clients MUST NOT supply
   multiple occurrences of the same Job Template attribute in the Job
   Attributes group in the request.

3.1.2.3  Algorithm for job validation

   The process of validating a Job-Template attribute "xxx" against a
   Printer attribute "xxx-supported" can use the following validation
   algorithm (see section 3.2.1.2 in [RFC2911]).

   To validate the value U of Job-Template attribute "xxx" against the
   value V of Printer "xxx-supported", perform the following algorithm:

   1. If U is multi-valued, validate each value X of U by performing the
      algorithm in Table 7 with each value X. Each validation is
      separate from the standpoint of returning unsupported values.
      Example:  If U is "finishings" that the client supplies with
      'staple', 'bind' values, then X takes on the successive values:
      'staple', then 'bind'

   2. If V is multi-valued, validate X against each Z of V by performing
      the algorithm in Table 7 with each value Z.  If a value Z
      validates, the validation for the attribute value X succeeds. If
      it fails, the algorithm is applied to the next value Z of V. If
      there are no more values Z of V, validation fails. Example"  If V
      is "sides-supported" with values: 'one- sided', 'two-sided-long',
      and 'two-sided-short', then Z takes on the successive values:
      'one-sided', 'two-sided-long', and 'two-sided-short'.  If the
      client supplies "sides" with 'two-sided- long', the first
      comparison fails ('one-sided' is not equal to 'two-sided-long'),
      the second comparison succeeds ('two-sided-long' is equal to
      'two-sided-long"), and the third comparison ('two-sided-short'
      with 'two-sided-long') is not even performed.

   3. If both U and V are single-valued, let X be U and Z be V and use
      the validation rules in Table 7.

   Table 7 - Rules for validating single values X against Z

   Attribute syntax   attribute syntax validated if:
   of X               of Z

   integer            rangeOfInteger   X is within the range of Z

   uri                uriScheme        the uri scheme in X is equal to
                                       Z

   any                boolean          the value of Z is TRUE

   any                any              X and Z are of the same type
                                       and are equal.

   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 check fails, the IPP object
   copies the attribute to the Unsupported Attributes response group
   with its unsupported value.  If the attribute contains more than one
   value, each value is checked and each unsupported value is separately
   copied, while supported values are not copied.  If an IPP object
   doesn't recognize/support a Job Template attribute, i.e., there is no
   corresponding Printer object "xxx-supported" attribute, the IPP
   object treats the attribute as an unknown or unsupported attribute
   (see the last row in the table below).

   If some Job Template attributes are supported for some document
   formats and not for others or the values are different for different
   document formats, the IPP object SHOULD take that into account in
   this validation using the value of the "document-format" supplied by
   the client (or defaulted to the value of the Printer's "document-
   format-default" attribute, if not supplied by the client).  For
   example, if "number-up" is supported for the 'text/plain' document
   format, but not for the 'application/postscript' document format, the
   check SHOULD (though it NEED NOT) depend on the value of the
   "document-format" operation attribute.  See "document-format" in
   [RFC2911] section 3.2.1.1 and 3.2.5.1.

   Note: whether the request is accepted or rejected is determined by
   the value of the "ipp-attribute-fidelity" attribute in a subsequent
   step, so that all Job Template attribute supplied are examined and
   all unsupported attributes and/or values are copied to the
   Unsupported Attributes response group.

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

   job-priority (integer(1:100))

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

      IF NOT supplied by the client, use the value of the Printer
      object's "job-priority-default" attribute at job submission time.

      IF NOT in the range 1 to 100, inclusive, copy the attribute and
      the unsupported value to the Unsupported Attributes response
      group.

      Map the value to the nearest supported value in the range 1:100 as
      specified by the number of discrete values indicated by the value
      of the Printer's "job-priority-supported" attribute.  See the
      formula in [RFC2911] Section 4.2.1.

   job-hold-until (type3 keyword | name)

      IF NOT a single 'keyword' or '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, use the value of the Printer
      object's "job-hold-until" attribute at job submission time.

      IF NOT in the Printer object's "job-hold-until-supported"
      attribute, copy the attribute and the unsupported value to the
      Unsupported Attributes response group.

   job-sheets (type3 keyword | name)

      IF NOT a single 'keyword' or '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 in the Printer object's "job-sheets-supported" attribute,
      copy the attribute and the unsupported value to the Unsupported
      Attributes response group.

   multiple-document-handling (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 NOT in the Printer object's "multiple-document-handling-
      supported" attribute, copy the attribute and the unsupported value
      to the Unsupported Attributes response group.

   copies (integer(1:MAX))

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

      IF NOT in range of the Printer object's "copies-supported"
      attribute

      copy the attribute and the unsupported value to the Unsupported
      Attributes response group.

   finishings (1setOf type2 enum)

      IF NOT an 'enum' value(s) each with a length equal to 4 octets,
      REJECT/RETURN 'client-error-bad-request'.

      IF NOT in the Printer object's "finishings-supported" attribute,
      copy the attribute and the unsupported value(s), but not any
      supported values, to the Unsupported Attributes response group.

   page-ranges (1setOf  rangeOfInteger(1:MAX))

      IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8
      octets, REJECT/RETURN 'client-error-bad-request'.

      IF first value is greater than second value in any range, the
      ranges are not in ascending order, or ranges overlap,
      REJECT/RETURN 'client-error-bad-request'.

      IF the value of the Printer object's "page-ranges-supported"
      attribute is 'false', copy the attribute to the Unsupported
      Attributes response group and set the value to the "out-of-band"
      'unsupported' value.

   sides (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 NOT in the Printer object's "sides-supported" attribute, copy
      the attribute and the unsupported value to the Unsupported
      Attributes response group.

   number-up (integer(1:MAX))

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

      IF NOT a value or in the range of one of the values of the Printer
      object's "number-up-supported" attribute, copy the attribute and
      value to the Unsupported Attribute response group.

   orientation-requested (type2 enum)

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

      IF NOT in the Printer object's "orientation-requested-supported"
      attribute, copy the attribute and the unsupported value to the
      Unsupported Attributes response group.

   media (type3 keyword | name)

      IF NOT a single 'keyword' or '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 in the Printer object's "media-supported" attribute, copy
      the attribute and the unsupported value to the Unsupported
      Attributes response group.

   printer-resolution (resolution)

      IF NOT a single 'resolution' value with a length equal to 9
      octets, REJECT/RETURN 'client-error-bad-request'.

      IF NOT in the Printer object's "printer-resolution-supported"
      attribute, copy the attribute and the unsupported value to the
      Unsupported Attributes response group.

   print-quality (type2 enum)

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

      IF NOT in the Printer object's "print-quality-supported"
      attribute, copy the attribute and the unsupported value to the
      Unsupported Attributes response group.

      unknown or unsupported attribute (i.e., there is no corresponding
      Printer object "xxx-supported" 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-bad-request' if the length of the
      attribute syntax is fixed or 'client-error-request-value-too-long'
      if the length of the attribute syntax is variable.

      ELSE copy the attribute and value to the Unsupported Attributes
      response group and change the attribute value to the "out-of-band"
      'unsupported' value.  Any remaining Job Template Attributes are
      either unknown or unsupported Job Template attributes and are
      validated algorithmically according to their attribute syntax for
      proper length (see below).

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

      If the attribute syntax is supported AND the length check fails,
      the IPP object REJECTS the request and RETURNS the 'client-error-
      bad-request' if the length of the attribute syntax is fixed or the
      'client-error-request-value-too-long' status code if the length of
      the attribute syntax is variable. Otherwise, the IPP object copies
      the unsupported Job Template attribute to the Unsupported
      Attributes response group and changes the attribute value to the
      "out-of-band" 'unsupported' value.  The following table shows the
      length checks for all attribute syntaxes.  In the following table:
      "<=" means less than or equal, "=" means equal to:

   Name                    Octet length check for read-write attributes
   ----------              ---------------------------------------------

   'textWithLanguage          <= 1023 AND 'naturalLanguage' <= 63
   'textWithoutLanguage'      <= 1023
   'nameWithLanguage'         <= 255 AND 'naturalLanguage'  <= 63
   'nameWithoutLanguage'      <= 255
   'keyword'                  <= 255
   'enum'                     = 4
   'uri'                      <= 1023
   'uriScheme'                <= 63
   'charset'                  <= 63
   'naturalLanguage'          <= 63
   'mimeMediaType'            <= 255
   'octetString'              <= 1023
   'boolean'                  = 1
   'integer'                  = 4
   'rangeOfInteger'           = 8
   'dateTime'                 = 11
   'resolution'               = 9
   '1setOf X'

   Note:  It's possible for a Printer to receive a zero length keyword
   in a request.  Since this is a keyword, its value needs to be
   compared with the supported values.  Assuming that the printer
   doesn't have any values in its corresponding "xxx-supported"
   attribute that are keywords of zero length, the comparison will fail.
   Then the request will be accepted or rejected depending on the value
   of "ipp-attributes-fidelity" being 'false' or 'true', respectively.
   No special handling is required for

3.1.2.3.1   Check for conflicting Job Template attributes values

   Once all the Operation and Job Template attributes have been checked
   individually, the Printer object SHOULD check for any conflicting
   values among all the supported values supplied by the client.  For
   example, a Printer object might be able to staple and to print on
   transparencies, however due to physical stapling constraints, the
   Printer object might not be able to staple transparencies.  The IPP
   object copies the supported attributes and their conflicting
   attribute values to the Unsupported Attributes response group.  The
   Printer object only copies over those attributes that the Printer
   object either ignores or substitutes in order to resolve the
   conflict, and it returns the original values which were supplied by
   the client.  For example suppose the client supplies "finishings"
   equals 'staple' and "media" equals 'transparency', but the Printer
   object does not support stapling transparencies.  If the Printer
   chooses to ignore the stapling request in order to resolve the

   conflict, the Printer objects returns "finishings" equal to 'staple'
   in the Unsupported Attributes response group.  If any attributes are
   multi-valued, only the conflicting values of the attributes are
   copied.

   Note: The decisions made to resolve the conflict (if there is a
   choice) is implementation dependent.

3.1.2.3.2   Decide whether to REJECT the request

   If there were any unsupported Job Template attributes or
   unsupported/conflicting Job Template attribute values and the client
   supplied the "ipp-attribute-fidelity" attribute with the 'true'
   value, the Printer object REJECTS the request and return the status
   code:

      1.'client-error-conflicting-attributes' status code, if there were
         any conflicts between attributes supplied by the client.

      2.'client-error-attributes-or-values-not-supported' status code,
         otherwise.

   Note:  Unsupported Operation attributes or values that are returned
   do not affect the status returned in this step.  If the unsupported
   Operation attribute was a serious error, the above already rejected
   the request in a previous step.  If control gets to this step with
   unsupported Operation attributes being returned, they are not serious
   errors.

   In general, the final results of Job processing are unknown at Job
   submission time.  The client has to rely on notifications or polling
   to find out what happens at Job processing time.  However, there are
   cases in which some Printers can determine at Job submission time
   that Job processing is going to fail.  As an optimization, we'd like
   to have the Printer reject the Job in these cases.

   There are three types of "processing" errors that might be detectable
   at Job submission time:

   1.  'client-error-document-format-not-supported' :  For the Print-
   Job, Send-Document, Print-URI, and Send-URI operations, if  all these
   conditions are true:

      -  the Printer supports auto-sensing,
      -  the request "document-format"  operation attribute is
         'application/octet-stream',
      -  the Printer receives document data before responding,
      -  the Printer auto-senses the document format before responding,

      -  the sensed document format is not supported by the Printer

   then the  Printer should respond with 'client-error-document-format-
   not-supported' status.

   2.  'client-error-compression-error':  For the Print-Job, Send-
   Document, Print-URI, and Send-URI operations, if  all these
   conditions are true:

      -  the client supplies a supported value for the "compression"
         operation attribute in the request
      -  the Printer receives document data before responding,
      -  the Printer attempts to decompress the document data before
         responding,
      -  the document data cannot be decompressed using the algorithm
         specified by the "compression" operation attribute

   then the Printer should respond with 'client-error-compression-error'
   status.

   3.  'client-error-document-access-error':  For the Print-URI, and
   Send-URI operations, if the Printer attempts and fails to pull the
   referenced document data before responding, it should respond with
   'client-error-document-access-error' status.

   Some Printers are not able to detect these errors until Job
   processing time.  In that case, the errors are recorded in the
   corresponding job-state and job-state reason attributes.  (There is
   no standard way for a client to determine whether a Printer can
   detect these errors at Job submission time.)  For example, if auto-
   sensing happens AFTER the job is accepted (as opposed to auto-sensing
   at submit time before returning the response), the implementation
   aborts the job, puts the job in the 'aborted' state and sets the
   'unsupported-document-format' value in the job's "job-state-reasons".

   A client should always provide a valid "document-format" operation
   attribute whenever practical.  In the absence of other information, a
   client itself may sniff the document data to determine document
   format.

   Auto sensing at Job submission time may be more difficult for the
   Printer when combined with compression.  For auto-sensed Jobs, a
   client may be better off  deferring compression to the transfer
   protocol layer, e.g.; by using the HTTP Content-Encoding header.

3.1.2.3.3   For the Validate-Job operation, RETURN one of the success
            status codes

   If the requested operation is the Validate-Job operation, the Printer
   object returns:

      1. the "successful-ok" status code, if there are no unsupported or
         conflicting Job Template attributes or values.
      2. the "successful-ok-conflicting-attributes, if there are any
         conflicting Job Template attribute or values.
      3. the "successful-ok-ignored-or-substituted-attributes, if there
         are only unsupported Job Template attributes or values.

   Note:  Unsupported Operation attributes or values that are returned
   do not affect the status returned in this step.  If the unsupported
   Operation attribute was a serious error, the above already rejected
   the request in a previous step.  If control gets to this step with
   unsupported Operation attributes being returned, they are not serious
   errors.

3.1.2.3.4   Create the Job object with attributes to support

   If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied
   by the client), the Printer object:

      1. creates a Job object, assigns a unique value to the job's
         "job-uri" and "job-id" attributes, and initializes all of the
         job's other supported Job Description attributes.
      2. removes all unsupported attributes from the Job object.
      3. for each unsupported value, removes either the unsupported
         value or substitutes the unsupported attribute value with some
         supported value.  If an attribute has no values after removing
         unsupported values from it, the attribute is removed from the
         Job object (so that the normal default behavior at job
         processing time will take place for that attribute).
      4. for each conflicting value, removes either the conflicting
         value or substitutes the conflicting attribute value with some
         other supported value.  If an attribute has no values after
         removing conflicting values from it, the attribute is removed
         from the Job object (so that the normal default behavior at job
         processing time will take place for that attribute).

   If there were no attributes or values flagged as unsupported, or the
   value of 'ipp-attribute-fidelity" was 'false', the Printer object is
   able to accept the create request and create a new Job object.  If
   the "ipp-attribute-fidelity" attribute is set to 'true', the Job
   Template attributes that populate the new Job object are necessarily
   all the Job Template attributes supplied in the create request.  If

   the "ipp-attribute-fidelity" attribute is set to 'false', the Job
   Template attributes that populate the new Job object are all the
   client supplied Job Template attributes that are supported or that
   have value substitution.  Thus, some of the requested Job Template
   attributes will not appear in the Job object because the Printer
   object did not support those attributes.  The attributes that
   populate the Job object are persistently stored with the Job object
   for that Job.  A Get-Job-Attributes operation on that Job object will
   return only those attributes that are persistently stored with the
   Job object.

   Note: All Job Template attributes that are persistently stored with
   the Job object are intended to be "override values"; that is, they
   that take precedence over whatever other embedded instructions might
   be in the document data itself.  However, it is not possible for all
   Printer objects to realize the semantics of "override".  End users
   may query the Printer's "pdl-override-supported" attribute to
   determine if the Printer either attempts or does not attempt to
   override document data instructions with IPP attributes.

   There are some cases, where a Printer supports a Job Template
   attribute and has an associated default value set for that attribute.
   In the case where a client does not supply the corresponding
   attribute, the Printer does not use its default values to populate
   Job attributes when creating the new Job object; only Job Template
   attributes actually in the create request are used to populate the
   Job object.  The Printer's default values are only used later at Job
   processing time if no other IPP attribute or instruction embedded in
   the document data is present.

   Note: If the default values associated with Job Template attributes
   that the client did not supply were to be used to populate the Job
   object, then these values would become "override values" rather than
   defaults.  If the Printer supports the 'attempted' value of the
   "pdl-override-supported" attribute, then these override values could
   replace values specified within the document data.  This is not the
   intent of the default value mechanism.  A default value for an
   attribute is used only if the create request did not specify that
   attribute (or it was ignored when allowed by "ipp-attribute-fidelity"
   being 'false') and no value was provided within the content of the
   document data.

   If the client does not supply a value for some Job Template
   attribute, and the Printer does not support that attribute, as far as
   IPP is concerned, the result of processing that Job (with respect to
   the missing attribute) is undefined.

3.1.2.3.5   Return one of the success status codes

   Once the Job object has been created, the Printer object accepts the
   request and returns to the client:

      1. the 'successful-ok' status code, if there are no unsupported or
         conflicting Job Template attributes or values.
      2. the 'successful-ok-conflicting-attributes' status code, if
         there are any conflicting Job Template attribute or values.
      3. the 'successful-ok-ignored-or-substituted-attributes' status
         code, if there are only unsupported Job Template attributes or
         values.

   Note:  Unsupported Operation attributes or values that are returned
   do not affect the status returned in this step.  If the unsupported
   Operation attribute was a serious error, the above already rejected
   the request in a previous step.  If control gets to this step with
   unsupported Operation attributes being returned, they are not serious
   errors.

   The Printer object also returns Job status attributes that indicate
   the initial state of the Job ('pending', 'pending-held',
   'processing', etc.), etc.  See Print-Job Response, [RFC2911] section
   3.2.1.2.

3.1.2.3.6   Accept appended Document Content

   The Printer object accepts the appended Document Content data and
   either starts it printing, or spools it for later processing.

3.1.2.3.7   Scheduling and Starting to Process the Job

   The Printer object uses its own configuration and implementation
   specific algorithms for scheduling the Job in the correct processing
   order.  Once the Printer object begins processing the Job, the
   Printer changes the Job's state to 'processing'.  If the Printer
   object supports PDL override (the "pdl-override-supported" attribute
   set to 'attempted'), the implementation does its best to see that IPP
   attributes take precedence over embedded instructions in the document
   data.

3.1.2.3.8   Completing the Job

   The Printer object continues to process the Job until it can move the
   Job into the 'completed' state.  If an Cancel-Job operation is
   received, the implementation eventually moves the Job into the
   'canceled' state.  If the system encounters errors during processing
   that do not allow it to progress the Job into a completed state, the

   implementation halts all processing, cleans up any resources, and
   moves the Job into the 'aborted' state.

3.1.2.3.9   Destroying the Job after completion

   Once the Job moves to the 'completed', 'aborted', or 'canceled'
   state, it is an implementation decision as to when to destroy the Job
   object and release all associated resources.  Once the Job has been
   destroyed, the Printer would return either the "client-error-not-
   found" or "client-error-gone" status codes for operations directed at
   that Job.

   Note:  the Printer object SHOULD NOT re-use a "job-uri" or "job-id"
   value for a sufficiently long time after a job has been destroyed, so
   that stale references kept by clients are less likely to access the
   wrong (newer) job.

3.1.2.3.10  Interaction with "ipp-attribute-fidelity"

   Some Printer object implementations may support "ipp-attribute-
   fidelity" set to 'true' and "pdl-override-supported" set to
   'attempted' and yet still not be able to realize exactly what the
   client specifies in the create request.  This is due to legacy
   decisions and assumptions that have been made about the role of job
   instructions embedded within the document data and external job
   instructions that accompany the document data and how to handle
   conflicts between such instructions.  The inability to be 100%
   precise about how a given implementation will behave is also
   compounded by the fact that the two special attributes, "ipp-
   attribute-fidelity" and "pdl-"override-supported", apply to the whole
   job rather than specific values for each attribute. For example, some
   implementations may be able to override almost all Job Template
   attributes except for "number-up".  Character Sets, natural
   languages, and internationalization

   This section discusses character set support, natural language
   support and internationalization.

3.1.2.3.11  Character set code conversion support

   IPP clients and IPP objects are REQUIRED to support UTF-8.  They MAY
   support additional charsets.  It is RECOMMENDED that an IPP object
   also support US-ASCII, since many clients support US-ASCII, and
   indicate that UTF-8 and US-ASCII are supported by populating the
   Printer's "charset-supported" with 'utf-8' and 'us-ascii' values.  An
   IPP object is required to code covert with as little loss as possible
   between the charsets that it supports, as indicated in the Printer's
   "charsets-supported" attribute.

   How should the server handle the situation where the "attributes-
   charset" of the response itself is "us-ascii", but one or more
   attributes in that response is in the "utf-8" format?

   Example: Consider a case where a client sends a Print-Job request
   with "utf-8" as the value of "attributes-charset" and with the "job-
   name" attribute supplied.  Later another client submits a Get-Job-
   Attribute or Get-Jobs request.  This second request contains the
   "attributes-charset" with value "us-ascii" and "requested-attributes"
   attribute with exactly one value "job-name".

   According to the RFC2911 document (section 3.1.4.2), the value of the
   "attributes-charset" for the response of the second request must be
   "us-ascii" since that is the charset specified in the request.  The
   "job-name" value, however, is in "utf-8" format.  Should the request
   be rejected even though both "utf-8" and "us-ascii" charsets are
   supported by the server? or should the "job-name" value be converted
   to "us-ascii" and return "successful-ok-conflicting-attributes"
   (0x0002) as the status code?

   Answer: An IPP object that supports both utf-8 (REQUIRED) and us-
   ascii, the second paragraph of section 3.1.4.2 applies so that the
   IPP object MUST accept the request, perform code set conversion
   between these two charsets with "the highest fidelity possible" and
   return 'successful-ok', rather than a warning 'successful-ok-
   conflicting-attributes, or an error.  The printer will do the best it
   can to convert between each of the character sets that it supports --
   even if that means providing a string of question marks because none
   of the characters are representable in US ASCII.  If it can't perform
   such conversion, it MUST NOT advertise us-ascii as a value of its
   "attributes-charset-supported" and MUST reject any request that
   requests 'us-ascii'.

   One IPP object implementation strategy is to convert all request text
   and name values to a Unicode internal representation.  This is 16-bit
   and virtually universal.  Then convert to the specified operation
   attributes-charset on output.

   Also it would be smarter for a client to ask for 'utf-8', rather than
   'us-ascii' and throw away characters that it doesn't understand,
   rather than depending on the code conversion of the IPP object.

3.1.2.3.12  What charset to return when an unsupported charset is
            requested (Issue 1.19)?

   Section 3.1.4.1 Request Operation attributes was clarified in
   November 1998 as follows:

   All clients and IPP objects MUST support the 'utf-8' charset
   [RFC2044] and MAY support additional charsets provided that they are
   registered with IANA [IANA-CS].  If the Printer object does not
   support the client supplied charset value, the Printer object MUST
   reject the request, set the "attributes-charset" to 'utf-8' in the
   response, and return the 'client-error-charset-not-supported' status
   code and any 'text' or 'name' attributes using the 'utf-8' charset.

   Since the client and IPP object MUST support UTF-8, returning any
   text or name attributes in UTF-8 when the client requests a charset
   that is not supported should allow the client to display the text or
   name.

   Since such an error is a client error, rather than a user error, the
   client should check the status code first so that it can avoid
   displaying any other returned 'text' and 'name' attributes that are
   not in the charset requested.

   Furthermore, [RFC2911] section 14.1.4.14 client-error-charset-not-
   supported (0x040D) was clarified in November 1998 as follows:

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

3.1.2.3.13  Natural Language Override (NLO)

   The 'text' and 'name' attributes each have two forms.  One has an
   implicit natural language, and the other has an explicit natural
   language.  The 'textWithoutLanguage' and 'textWithLanguage' are the
   two 'text' forms.  The 'nameWithoutLanguage" and 'nameWithLanguage
   are the two 'name' forms.  If a receiver (IPP object or IPP client)
   supports an attribute with attribute syntax 'text', it MUST support
   both forms in a request and a response.  A sender (IPP client or IPP
   object) MAY send either form for any such attribute.  When a sender
   sends a WithoutLanguage form, the implicit natural language is
   specified in the "attributes-natural-language" operation attribute,
   which all senders MUST include in every request and response.

   When a sender sends a WithLanguage form, it MAY be different from the
   implicit natural language supplied by the sender or it MAY be the
   same.  The receiver MUST treat either form equivalently.

   There is an implementation decision for senders, whether to always
   send the WithLanguage forms or use the WithoutLanguage form when the
   attribute's natural language is the same as the request or response.

   The former approach makes the sender implementation simpler.  The
   latter approach is more efficient on the wire and allows inter-
   working with non-conforming receivers that fail to support the
   WithLanguage forms.  As each approach have advantages, the choice is
   completely up to the implementer of the sender.

   Furthermore, when a client receives a 'text' or 'name' job attribute
   that it had previously supplied, that client MUST NOT expect to see
   the attribute in the same form, i.e., in the same WithoutLanguage or
   WithLanguage form as the client supplied when it created the job.
   The IPP object is free to transform the attribute from the
   WithLanguage form to the WithoutLanguage form and vice versa, as long
   as the natural language is preserved.  However, in order to meet this
   latter requirement, it is usually simpler for the IPP object
   implementation to store the natural language explicitly with the
   attribute value, i.e., to store using an internal representation that
   resembles the WithLanguage form.

   The IPP Printer MUST copy the natural language of a job, i.e., the
   value of the "attributes-natural-language" operation attribute
   supplied by the client in the create operation, to the Job object as
   a Job Description attribute, so that a client is able to query it.
   In returning a Get-Job-Attributes response, the IPP object MAY return
   one of three natural language values in the responses "attributes-
   natural-language" operation attribute: (1) that requested by the
   requester, (2) the natural language of the job, or (3) the configured
   natural language of the IPP Printer, if the requested language is not
   supported by the IPP Printer.

   This "attributes-natural-language" Job Description attribute is
   useful for an IPP object implementation that prints start sheets in
   the language of the user who submitted the job.  This same Job
   Description attribute is useful to a multi-lingual operator who has
   to communicate with different job submitters in different natural
   languages.  This same Job Description attribute is expected to be
   used in the future to generate notification messages in the natural
   language of the job submitter.

   Early drafts of [RFC2911] contained a job-level natural language
   override (NLO) for the Get-Jobs response.  A job-level (NLO) is an
   (unrequested) Job Attribute which then specified the implicit natural
   language for any other WithoutLanguage job attributes returned in the
   response for that job.  Interoperability testing of early
   implementations showed that no one was implementing the job-level NLO
   in Get-Job responses.  So the job-level NLO was eliminated from the
   Get-Jobs response.  This simplification makes all requests and
   responses consistent in that the implicit natural language for any

   WithoutLanguage 'text' or 'name' form is always supplied in the
   request's or response's "attributes-natural-language" operation
   attribute.