tech-invite   World Map     

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

RFC 2911

 
 
 

Internet Printing Protocol/1.1: Model and Semantics

Part 9 of 9, p. 205 to 224
Prev RFC Part

 


prevText      Top      Up      ToC       Page 205 
14.1. Examples

   Below are examples to supplement the engineering media value
   definitions.

   Example 1:  "Synchro-Cut", a device cutting the roll paper in
   synchronization with the data

     data height:          A1 height
     data width (shaded):  A1 width < data width < (A1 width) x 2
     specified value:      'iso-a1xsynchro-white'

               |                    |
               |<--- data width --->|
               |                    |
               |              |     |        |
               |<- A1 width ->|<- A1 width ->|
               |              |     |        |
     cross  ^  |              |     |        |
      feed  |  +--------------------------------------------/
 direction  |  |//////////////|/////|        |     ^       /
            |  |//////////////|/////|        |     |      /
            |  |//////////////|/////|        |     |     /
            |  |//////////////|/////|        |     |     \
<-----------+- |//////////////|/////|        |    A1      \  roll
feed        |  |//////////////|/////|        |   height    \  paper
direction      |//////////////|/////|        |     |        \
               |//////////////|/////|        |     |        /
               |//////////////|/////|        |     v       /
               +------------------------------------------/
                                    |
                                    |
                                    |<------ CUT HERE (to synchronize
                                    |                with data width)
                                    |

Top      Up      ToC       Page 206 
   Example 2: "Auto-Cut", a device cutting the roll paper at multiples
   of fixed-size media width

     data height:          A1 height
     data width (shaded):  A1 width < data width < (A1 width) x 2
     specified value:      'auto-fixed-size-white'

                 |                    |
                 |<--- data width --->|
                 |                    |
                 |              |     |        |
                 |<- A1 width ->|<- A1 width ->|
                 |              |     |        |
     cross  ^    |              |     |        |
      feed  |    +--------------------------------------------/
 direction  |    |//////////////|/////|        |     ^       /
            |    |//////////////|/////|        |     |      /
            |    |//////////////|/////|        |     |     /
            |    |//////////////|/////|        |     |     \
<-----------+-   |//////////////|/////|        |    A1      \  roll
feed        |    |//////////////|/////|        |   height    \  paper
direction        |//////////////|/////|        |     |        \
                 |//////////////|/////|        |     |        /
                 |//////////////|/////|        |     v       /
                 +------------------------------------------/
                                               |
                                               |
                                               |<--- CUT HERE
                                               |      (to synchronize
                                               |       with data width)

Top      Up      ToC       Page 207 
   Example 3:  the 'iso-a4x4-white' fixed size paper

     paper height:         A4 height
     paper width:          (A4 width) x 4
     specified value:      'iso-a4x4-white'

   |              |              |              |              |
   |<- A4 width ->|<- A4 width ->|<- A4 width ->|<- A4 width ->|
   |              |              |              |              |
   |              |              |              |              |
   +-----------------------------------------------------------+
   |       ^      |              |              |              |
   |       |      |              |              |              |
   |       |      |              |              |              |
   |      A4      |              |              |              |
   |    height    |              |              |              |
   |       |      |              |              |              |
   |       |      |              |              |              |
   |       |      |              |              |              |
   |       v      |              |              |              |
   +-----------------------------------------------------------+

Top      Up      ToC       Page 208 
   Example 4: "Synchro-Cut", a device cutting the fixed size paper in
   synchronization with the data

     data height:          A4 height
     data width (shaded):  (A4 width) x 2 < data width < (A4 width) x 3
     specified value:      'iso-a4xsynchro-white'

                    |                                   |
                    |<---------- data width ----------->|
                    |                                   |
                    |              |              |     |        |
                    |<- A4 width ->|<- A4 width ->|<- A4 width ->|
                    |              |              |     |        |
        cross  ^    |              |              |     |        |
         feed  |    +--------------------------------------------+
    direction  |    |//////////////|//////////////|/////|    ^   |
               |    |//////////////|//////////////|/////|    |   |
               |    |//////////////|//////////////|/////|    |   |
               |    |//////////////|//////////////|/////|    |   |
   <-----------+-   |//////////////|//////////////|/////|   A4   |
   feed        |    |//////////////|//////////////|/////| height |
   direction        |//////////////|//////////////|/////|    |   |
                    |//////////////|//////////////|/////|    |   |
                    |//////////////|//////////////|/////|    v   |
                    +--------------------------------------------+
                                                        |
                                          CUT HERE ---->|
                                    (to synchronize     |
                                    with data width)    |

15. APPENDIX D: Processing IPP Attributes

   When submitting a print job to a Printer object, the IPP model allows
   a client to supply operation and Job Template attributes along with
   the document data.  These Job Template attributes in the create
   request affect the rendering, production and finishing of the
   documents in the job.  Similar types of instructions may also be
   contained in the document to be printed, that is, embedded within the
   print data itself.  In addition, the Printer has a set of attributes
   that describe what rendering and finishing options which are
   supported by that Printer.  This model, which allows for flexibility
   and power, also introduces the potential that at job submission time,
   these client-supplied attributes may conflict with either:

      - what the implementation is capable of realizing (i.e., what the
        Printer supports), as well as
      - the instructions embedded within the print data itself.

Top      Up      ToC       Page 209 
   The following sections describe how these two types of conflicts are
   handled in the IPP model.

15.1 Fidelity

   If there is a conflict between what the client requests and what a
   Printer object supports, the client may request one of two possible
   conflict handling mechanisms:

      1) either reject the job since the job can not be processed
         exactly as specified, or
      2) allow the Printer to make any changes necessary to proceed with
         processing the Job the best it can.

   In the first case the client is indicating to the Printer object:
   "Print the job exactly as specified with no exceptions, and if that
   can't be done, don't even bother printing the job at all." In the
   second case, the client is indicating to the Printer object: "It is
   more important to make sure the job is printed rather than be
   processed exactly as specified; just make sure the job is printed
   even if some client-supplied attributes need to be changed or
   ignored."

   The IPP model accounts for this situation by introducing an "ipp-
   attribute-fidelity" attribute.

   In a create request, "ipp-attribute-fidelity" is a boolean operation
   attribute that is OPTIONALLY supplied by the client.  The value
   'true' indicates that total fidelity to client supplied Job Template
   attributes and values is required.  The client is requesting that the
   Job be printed exactly as specified, and if that is not possible then
   the job MUST be rejected rather than processed incorrectly.  The
   value 'false' indicates that a reasonable attempt to print the Job is
   acceptable.  If a Printer does not support some of the client
   supplied Job Template attributes or values, the Printer MUST ignore
   them or substitute any supported value for unsupported values,
   respectively.  The Printer may choose to substitute the default value
   associated with that attribute, or use some other supported value
   that is similar to the unsupported requested value.  For example, if
   a client supplies a "media" value of 'na-letter', the Printer may
   choose to substitute 'iso-a4' rather than a default value of
   'envelope'. If the client does not supply the "ipp-attribute-
   fidelity" attribute, the Printer assumes a value of 'false'.

   Each Printer implementation MUST support both types of "fidelity"
   printing (that is whether the client supplies a value of 'true' or
   'false'):

Top      Up      ToC       Page 210 
      - If the client supplies 'false' or does not supply the attribute,
        the Printer object MUST always accept the request by ignoring
        unsupported Job Template attributes and by substituting
        unsupported values of supported Job Template attributes with
        supported values.
      - If the client supplies 'true', the Printer object MUST reject
        the request if the client supplies unsupported Job Template
        attributes.

   Since a client can always query a Printer to find out exactly what is
   and is not supported, "ipp-attribute-fidelity" set to 'false' is
   useful when:

      1) The End-User uses a command line interface to request
         attributes that might not be supported.
      2) In a GUI context, if the End User expects the job might be
         moved to another printer and prefers a sub-optimal result to
         nothing at all.
      3) The End User just wants something reasonable in lieu of nothing
         at all.

15.2 Page Description Language (PDL) Override

   If there is a conflict between the value of an IPP Job Template
   attribute and a corresponding instruction in the document data, the
   value of the IPP attribute SHOULD take precedence over the document
   instruction.  Consider the case where a previously formatted file of
   document data is sent to an IPP Printer.  In this case, if the client
   supplies any attributes at job submission time, the client desires
   that those attributes override the embedded instructions.  Consider
   the case were a previously formatted document has embedded in it
   commands to load 'iso-a4' media.  However, the document is passed to
   an end user that only has access to a printer with 'na-letter' media
   loaded.  That end user most likely wants to submit that document to
   an IPP Printer with the "media" Job Template attribute set to 'na-
   letter'.  The job submission attribute should take precedence over
   the embedded PDL instruction.  However, until companies that supply
   document data interpreters allow a way for external IPP attributes to
   take precedence over embedded job production instructions, a Printer
   might not be able to support the semantics that IPP attributes
   override the embedded instructions.

   The IPP model accounts for this situation by introducing a "pdl-
   override-supported" attribute that describes the Printer objects
   capabilities to override instructions embedded in the PDL data
   stream.  The value of the "pdl-override-supported" attribute is
   configured by means outside the scope of this IPP/1.1 document.

Top      Up      ToC       Page 211 
   This REQUIRED Printer attribute takes on the following values:

      - 'attempted': This value indicates that the Printer object
        attempts to make the IPP attribute values take precedence over
        embedded instructions in the document data, however there is no
        guarantee.
      - 'not-attempted': This value indicates that the Printer object
        makes no attempt to make the IPP attribute values take
        precedence over embedded instructions in the document data.

   At job processing time, an implementation that supports the value of
   'attempted' might do one of several different actions:

      1) Generate an output device specific command sequence to realize
         the feature represented by the IPP attribute value.
      2) Parse the document data itself and replace the conflicting
         embedded instruction with a new embedded instruction that
         matches the intent of the IPP attribute value.
      3) Indicate to the Printer that external supplied attributes take
         precedence over embedded instructions and then pass the
         external IPP attribute values to the document data interpreter.
      4) Anything else that allows for the semantics that IPP attributes
         override embedded document data instructions.

   Since 'attempted' does not offer any type of guarantee, even though a
   given Printer object might not do a very "good" job of attempting to
   ensure that IPP attributes take a higher precedence over instructions
   embedded in the document data, it would still be a conforming
   implementation.

   At job processing time, an implementation that supports the value of
   'not-attempted' might do one of the following actions:

      1) Simply pre-pend the document data with the PDL instruction that
         corresponds to the client-supplied PDL attribute, such that if
         the document data also has the same PDL instruction, it will
         override what the Printer object pre-pended.  In other words,
         this implementation is using the same implementation semantics
         for the client-supplied IPP attributes as for the Printer
         object defaults.

      2) Parse the document data and replace the conflicting embedded
         instruction with a new embedded instruction that approximates,
         but does not match, the semantic intent of the IPP attribute
         value.

   Note:  The "ipp-attribute-fidelity" attribute applies to the
   Printer's ability to either accept or reject other unsupported Job

Top      Up      ToC       Page 212 
   Template attributes.  In other words, if "ipp-attribute-fidelity" is
   set to 'true', a Job is accepted if and only if the client supplied
   Job Template attributes and values are supported by the Printer.
   Whether these attributes actually affect the processing of the Job
   when the document data contains embedded instructions depends on the
   ability of the Printer to override the instructions embedded in the
   document data with the semantics of the IPP attributes.  If the
   document data attributes can be overridden ("pdl-override-supported"
   set to 'attempted'), the Printer makes an attempt to use the IPP
   attributes when processing the Job. If the document data attributes
   can not be overridden ("pdl-override-supported" set to 'not-
   attempted'), the Printer makes no attempt to override the embedded
   document data instructions with the IPP attributes when processing
   the Job, and hence, the IPP attributes may fail to affect the Job
   processing and output when the corresponding instruction is embedded
   in the document data.

15.3 Using Job Template Attributes During Document Processing.

   The Printer object uses some of the Job object's Job Template
   attributes during the processing of the document data associated with
   that job.  These include, but are not limited to, "orientation-
   requested", "number-up", "sides", "media", and "copies".  The
   processing of each document in a Job Object MUST follow the steps
   below. These steps are intended only to identify when and how
   attributes are to be used in processing document data and any
   alternative steps that accomplishes the same effect can be used to
   implement this specification document.

      1. Using the client supplied "document-format" attribute or some
         form of document format detection algorithm (if the value of
         "document-format" is not specific enough), determine whether or
         not the document data has already been formatted for printing.
         If the document data has been formatted, then go to step 2.
         Otherwise, the document data MUST be formatted. The formatting
         detection algorithm is implementation defined and is not
         specified by this document.  The formatting of the document
         data uses the "orientation-requested" attribute to determine
         how the formatted print data should be placed on a print-stream
         page, see section 4.2.10 for the details.

      2. The document data is in the form of a print-stream in a known
         media type. The "page-ranges" attribute is used to select, as
         specified in section 4.2.7, a sub-sequence of the pages in the
         print-stream that are to be processed and images.

      3. The input to this step is a sequence of print-stream pages.
         This step is controlled by the "number-up" attribute. If the

Top      Up      ToC       Page 213 
         value of "number-up" is N, then during the processing of the
         print-stream pages, each N print-stream pages are positioned,
         as specified in section 4.2.9, to create a single impression.
         If a given document does not have N more print-stream pages,
         then the completion of the impression is controlled by the
         "multiple-document-handling" attribute as described in section
         4.2.4; when the value of this attribute is 'single-document' or
         'single-document-new-sheet', the print-stream pages of document
         data from subsequent documents is used to complete the
         impression.

         The size(scaling), position(translation) and rotation of the
         print-stream pages on the impression is implementation defined.
         Note that during this process the print-stream pages may be
         rendered to a form suitable for placing on the impression; this
         rendering is controlled by the values of the "printer-
         resolution" and "print-quality" attributes as described in
         sections 4.2.12 and 4.2.13. In the case N=1, the impression is
         nearly the same as the print-stream page; the differences would
         only be in the size, position and rotation of the print-stream
         page and/or any decoration, such as a frame to the page, that
         is added by the implementation.

      4. The collection of impressions is placed, in sequence, onto
         sides of the media sheets. This placement is controlled by the
         "sides" attribute and the orientation of the print-stream page,
         as described in section 4.2.8. The orientation of the print-
         stream pages affects the orientation of the impression; for
         example, if "number-up" equals 2, then, typically, two portrait
         print-stream pages become one landscape impression. Note that
         the placement of impressions onto media sheets is also
         controlled by the "multiple-document-handling" attribute as
         described in section 4.2.4.

      5. The "copies" and "multiple-document-handling" attributes are
         used to determine how many copies of each media instance are
         created and in what order. See sections 4.2.5 and 4.2.4 for the
         details.

      6. When the correct number of copies are created, the media
         instances are finished according to the values of the
         "finishings" attribute as described in 4.2.6. Note that
         sometimes finishing operations may require manual intervention
         to perform the finishing operations on the copies, especially
         uncollated copies. This document allows any or all of the
         processing steps to be performed automatically or manually at
         the discretion of the Printer object.

Top      Up      ToC       Page 214 
16. APPENDIX E: Generic Directory Schema

   This section defines a generic schema for an entry in a directory
   service.  A directory service is a means by which service users can
   locate service providers.  In IPP environments, this means that IPP
   Printers can be registered (either automatically or with the help of
   an administrator) as entries of type printer in the directory using
   an implementation specific mechanism such as entry attributes, entry
   type fields, specific branches, etc.  Directory clients can search or
   browse for entries of type printer.  Clients use the directory
   service to find entries based on naming, organizational contexts, or
   filtered searches on attribute values of entries.  For example, a
   client can find all printers in the "Local Department" context.
   Authentication and authorization are also often part of a directory
   service so that an administrator can place limits on end users so
   that they are only allowed to find entries to which they have certain
   access rights.  IPP itself does not require any specific directory
   service protocol or provider.

   Note: Some directory implementations allow for the notion of
   "aliasing".  That is, one directory entry object can appear as
   multiple directory entry object with different names for each object.
   In each case, each alias refers to the same directory entry object
   which refers to a single IPP Printer object.

   The generic schema is a subset of IPP Printer Job Template and
   Printer Description attributes (sections 4.2 and 4.4).  These
   attributes are identified as either RECOMMENDED or OPTIONAL for the
   directory entry itself.  This conformance labeling is NOT the same
   conformance labeling applied to the attributes of IPP Printers
   objects.  The conformance labeling in this Appendix is intended to
   apply to directory templates and to IPP Printer implementations that
   subscribe by adding one or more entries to a directory.  RECOMMENDED
   attributes SHOULD be associated with each directory entry.  OPTIONAL
   attributes MAY be associated with the directory entry (if known or
   supported).  In addition, all directory entry attributes SHOULD
   reflect the current attribute values for the corresponding Printer
   object.

   The names of attributes in directory schema and entries SHOULD be the
   same as the IPP Printer attribute names as shown, as much as
   possible.

   In order to bridge between the directory service and the IPP Printer
   object, one of the RECOMMENDED directory entry attributes is the
   Printer object's "printer-uri-supported" attribute.  The directory
   client queries the "printer-uri-supported" attribute (or its
   equivalent) in the directory entry and then the IPP client addresses

Top      Up      ToC       Page 215 
   the IPP Printer object using one of its URIs.  The "uri-security-
   supported" attribute identifies the protocol (if any) used to secure
   a channel.

   The following attributes define the generic schema for directory
   entries of type PRINTER:

     printer-uri-supported              RECOMMENDED    Section 4.4.1
     uri-authentication-supported       RECOMMENDED    Section 4.4.2
     uri-security-supported             RECOMMENDED    Section 4.4.3
     printer-name                       RECOMMENDED    Section 4.4.4
     printer-location                   RECOMMENDED    Section 4.4.5
     printer-info                       OPTIONAL       Section 4.4.6
     printer-more-info                  OPTIONAL       Section 4.4.7
     printer-make-and-model             RECOMMENDED    Section 4.4.9
     ipp-versions-supported             RECOMMENDED    Section 4.4.14
     multiple-document-jobs-supported   OPTIONAL       Section 4.4.16
     charset-supported                  OPTIONAL       Section 4.4.18

     generated-natural-language-
        supported                       OPTIONAL       Section 4.4.20
     document-format-supported          RECOMMENDED    Section 4.4.22
     color-supported                    RECOMMENDED    Section 4.4.26
     compression-supported              RECOMMENDED    Section 4.4.32
     pages-per-minute                   OPTIONAL       Section 4.4.36
     pages-per-minute-color             OPTIONAL       Section 4.4.37

     finishings-supported               OPTIONAL       Section 4.2.6
     number-up-supported                OPTIONAL       Section 4.2.7
     sides-supported                    RECOMMENDED    Section 4.2.8
     media-supported                    RECOMMENDED    Section 4.2.11
     printer-resolution-supported       OPTIONAL       Section 4.2.12
     print-quality-supported            OPTIONAL       Section 4.2.13

17. APPENDIX F:  Differences between the IPP/1.0 and IPP/1.1 "Model and
    Semantics" Documents

   This Appendix is divided into two lists that summarize the
   differences between IPP/1.1 (this document) and IPP/1.0 [RFC2566].
   The section numbers refer to the numbers in this document which in
   some cases have changed from RFC 2566.  When a change affects
   multiple sections, the item is listed once in the order of the first
   section affected and the remaining affected section numbers are
   indicated.

Top      Up      ToC       Page 216 
   The first list contains extensions and clarifications and the second
   list contains changes in semantics or conformance.  However, client
   and IPP object implementations of IPP/1.0 MAY implement any of the
   extensions and clarifications in this document.

   The following extensions and clarifications have been incorporated
   into this document:

      1.  Section 2.1 - clarified that the term "client" can be either
          contained in software controlled by an end user or a part of a
          print server that controls devices.
      2.  Section 2 - clarified that the term "IPP object" and "Printer
          object" can either be embedded in a device object or part of a
          print server that accepts IPP requests.
      3.  Section 2.4 - added the description of the new "uri-
          authentication-supported" Printer Description attribute.
      4.  Section 3.1.3, 3.1.6, 3.2.5.2, and 3.2.6.2 - clarified the
          error handling for operation attributes that have their own
          status code.
      5.  Section 3.1.3 - clarified that multiple occurrences of the
          same attribute in an attribute group is mal-formed.  An IPP
          Printer MAY reject the request or choose one of the
          attributes.
      6.  Section 3.1.6 - reorganized this section into sub-sections to
          separately describe "status-code", "status-message",
          "detailed-status-message", and "document-access-error"
          attributes.
      7.  Section 3.1.6.1 - clarified the error status codes and their
          relationship to operation attributes.
      8.  Section 3.1.6.3 - Added the OPTIONAL "detailed-status-message
          (text(MAX))" operation attribute to provide additional more
          detailed information about a response.
      9.  Section 3.1.6.4 and 3.2.2 - Added the OPTIONAL "document-
          access-error (text(MAX))" operation attribute for use with
          Print-URI and Send-URI responses.
      10. Sections 3.1.7 - Added this new section to clarify returning
          Unsupported Attributes for all operations, including only
          returning attributes that were in the request.  Moved the text
          from section 3.2.1.2 Unsupported Attributes to this section.
      11. Sections 3.1.7 and 4.1 - clarified the encoding of the "out-
          of-band" 'unsupported' and 'unknown' values.
      12. Section 3.1.8 - clarified that only the version number
          parameter will be carried forward into future major or minor
          versions of the protocol.
      13. Section 3.1.8 - relaxed the requirements to increment the
          major version number in future versions of the Model and
          Semantics document.

Top      Up      ToC       Page 217 
      14. Section 3.1.9, and 3.2.5 - added the 'processing' state to the
          list of job states that a job can be in after a Create-Job
          operation.
      15. Section 3.1.9 - clarified that a non-spooling Printer MAY
          accept zero or more subsequent jobs while processing a job and
          flow control them down.  Subsequent create requests are
          rejected with the 'server-error-busy' error status.
      16. Section 3.2.1.1 - clarified the validation of the
          "compression" operation attribute and its relationship to the
          validation of the "document-format" attribute and returning
          Unsupported Attributes.
      17. Sections 3.2.1.1, 4.3.8, 13.1.4.16, and 13.1.4.17 - added the
          'client-error-compression-not-supported', 'client-error-
          compression-error' status codes and the 'unsupported-
          compression' and 'compression-error' job-state-reasons.
      18. Sections 3.2.1.1 and 4.3.8 - added 'unsupported-document-
          format' and 'document-format-error' job-state-reasons.
      19. Sections 3.2.2, 4.3.8 and 13.1.4.19 - added 'client-error-
          document-access-error' status code and 'document-access-error'
          job state reason.
      20. Section 3.2.5.2 and 3.2.6.2 - clarified that the Unsupported
          Attributes group MUST NOT include attributes not requested in
          the Get-Printer-Attributes request.
      21. Section 3.2.6 - clarified that "limit" takes precedence over
          "which-jobs" and "my-jobs'.
      22. Section 3.2.6.2 - clarified that Get-Jobs returns
          'successful-ok' when no jobs to return.
      23. Sections 3.2.7, 3.2.8, and 3.2.9 - added the OPTIONAL Pause-
          Printer, Resume-Printer, and Purge-Jobs operations
      24. Section 3.3.1  - clarified that the authorization required for
          a Send-Document request MUST be the same user as the Create-
          Job or an operator.
      25. Section 3.3.1.1 - clarified that a Create-Job Send-Document
          with "last-document" = 'true' and no data is not an error; its
          a job with no documents.
      26. Sections 3.3.5, 3.3.6, and 3.3.7 - added the OPTIONAL Hold-
          Job, Release-Job, and Restart-Job operations.  Clarified the
          Restart-Job operation so that the Printer MUST re-fetch any
          documents passed by-reference (Print-URI or Send-URI).
      27. Section 4.1 - clarified that the encoding of the out-of-band
          values are specified in the Encoding and Transport" document.
      28. Section 4.1 - Clarified that the requirement that clients MUST
          NOT send "out-of-band" values in requests applies only to
          operations defined in this document.  Other operations are
          allowed to define "out-of-band" values that clients can
          supply.

Top      Up      ToC       Page 218 
      29. Sections 4.1.1 and 4.1.2 - clarified that the maximum 'text'
          and 'name' values of 1023 and 255 are for the
          'textWithoutLanguage' portion of the 'textWithLanguage' form,
          so that the maximum number of octets for the actual text and
          name data is the same for the without and with language forms;
          the 'naturalLanguage' part is in addition.
      30. Section 4.1.9 - clarified that 'mimeMediaType' values can
          include any parameters from the IANA Registry, not just
          charset parameters.
      31. Section 4.1.9.1 - clarified that 'application/octet-stream'
          auto-sensing can happen at create request time and/or
          job/document processing time.
      32. Section 4.1.9.1 - clarified that auto-sensing involves the
          Printer examining some number of octets of document data using
          an implementation-dependent method.
      33. Section 4.1.14 - clarified that the localization of dateTime
          by the client includes the time zone.
      34. Section 4.2 - clarified that xxx-supported have multiple
          keywords and/or names by adding parentheses to the table to
          give:  (1setOf (type3 keyword | name))
      35. Section 4.2.2 - added the 'indefinite' keyword value to the
          "job-hold-until" attribute for use with the create operations
          and Hold-Job and Restart-Job operations.
      36. Section 4.2.6 - added more enum values to the "finishings" Job
          Template attribute.
      37. Section 4.2.6 - clarified that the landscape definition is a
          rotation of the image with respect to the medium.
      38. Section 4.3.7 - added that a forwarding server that cannot get
          any job state MAY return the job's state as 'completed',
          provided that it also return the new 'queued-in-device' job
          state reason.
      39. Section 4.3.7.2 - added the Partitioning of Job States section
          to clarify the concepts of Job Retention, Job History, and Job
          Removal.
      40. Section 4.3.8 - added 'job-data-insufficient' job state reason
          to indicate whether sufficient data has arrived for the
          document to start to be processed.
      41. Section 4.3.8 - added 'document-access-error' job state reason
          to indicate an access error of any kind.
      42. Section 4.3.8 - added 'job-queued-for-marker' job state reason
          to indicate whether the job has completed some processing and
          is waiting for the marker.
      43. Section 4.3.8 - added 'unsupported-compression' and
          'compression-error' job state reasons to indicate compression
          not supported or compression processing error after the create
          has been accepted.

Top      Up      ToC       Page 219 
      44. Section 4.3.8 - added 'unsupported-document-format' and
          'document-format-error' job state reasons to indicate document
          not supported or document format processing error after the
          create has been accepted.
      45. Section 4.3.8 - added 'queued-in-device' job state reason to
          indicate that a job as been forwarded to a print system or
          device that does not provide any job status.
      46. Section 4.3.10 - added "job-detailed-status-messages (1setOf
          text(MAX)) for returning detailed error messages.
      47. Section 4.3.11 - added the "job-document-access-errors (1setOf
          text(MAX))
      48. Section 4.3.14.2 - clarified that the time recorded is the
          first time processing since the create operation or the
          Restart-Job operation.
      49. Section 4.3.14.2 and 4.3.14.3 - clarified that the out-of-band
          value 'no-value' is returned if the job has not started
          processing or has not completed, respectively.
      50. Section 4.3.14 - Added the OPTIONAL "date-time-at-creation",
          "date-time-at-processing", and "date-time-at-completed" Event
          Time Job Description attributes
      51. Section 4.4.3 - added the 'tls' value to "uri-security-
          supported" attribute.
      52. Section 4.4.3 - clarified "uri-security-supported" is
          orthogonal to Client Authentication so that 'none' does not
          exclude Client Authentication.
      53. Section 4.4.11 - simplified the "printer-state" descriptions
          while generalizing to allow high end devices that interpret
          one or more jobs while marking another.  Indicated that
          'spool-area-full' and 'stopped-partly' "printer-state-reasons"
          may be used to provide further state information.
      54. Section 4.4.12 - added the 'moving-to-paused' keyword value to
          the "printer-state-reasons" attribute for use with the Pause-
          Printer operation.
      55. Section 4.4.12 - replaced the duplicate 'marker-supply-low'
          keyword with the missing 'toner-empty' keyword for the
          "printer-state-reasons" attribute.  (This correction was also
          made before RFC 2566 was published).
      56. Section 4.4.12 - clarified 'spool-area-full' "printer-state-
          reasons" to include non-spooling printers to indicate when it
          can and cannot accept another job.
      57. Section 4.4.15 - added the enum values to the "operations-
          supported" attribute for the new operations.  Clarified that
          the values of this attribute are encoded as any enum, namely
          32-bit values.
      58. Section 4.4.30 - clarified that the dateTime value of
          "printer-current-time" is on a "best efforts basis".  If a
          proper date-time cannot be obtained, the implementation
          returns the 'no-value' out-of-band value.  Also clarified that

Top      Up      ToC       Page 220 
          the time zone NEED NOT be the time zone that the people near
          the device use and that the client SHOULD display the dateTime
          attributes in the user's local time.
      59. Sections 4.4.36 and 4.4.37 - added the OPTIONAL "pages-per-
          minute" and "pages-per-minute-color" Printer Description
          attributes.
      60. Section 5.1 - clarified that the client conformance
          requirements apply to clients controlled by an end user and
          clients in servers.
      61. Section 5.1 - clarified that any response MAY contain
          additional attribute groups, attributes, attribute syntaxes,
          or attribute values.
      62. Section 5.1 - clarified that a client SHOULD do its best to
          prevent a channel from being closed by a lower layer when the
          channel is flow controlled off by the IPP Printer.
      63. Section 5.2 - clarified that the IPP object requirements apply
          to objects embedded in devices or that are parts of servers.
      64. Section 5.2.2 - clarified that IPP objects MAY return
          operation responses that contain attribute groups, attribute
          names, attribute syntaxes, attribute values, and status codes
          that are extensions to this standard.
      65. Section 6 - changed the terminology of "private extensions" to
          "vendor extensions" and indicated that they are registered
          with IANA along with IETF standards track extensions.
      66. Section 6.7 - inserted this section on registering out-of-band
          attribute values with IANA as extensions.
      67. Section 8.3 - clarified the use of URIs for each Client
          Authentication mechanism.
      68. Section 8.5 - added the security discussion around the new
          operator/administrator operations.
      69. Section 13.1.4.16 - added client-error-compression-not-
          supported (0x040F)
      70. Section 13.1.4.17 - added client-error-compression-error
          (0x0410)
      71. Section 13.1.4.18 - added client-error-document-format-error
          (0x0411)
      72. Section 13.1.4.19 - added client-error-document-access-error
          (0x0412)
      73. Section 13.1.5.10 - added server-error-multiple-document-
          jobs-not-supported (0x0509)
      74. Section 14 - added 'a-white', 'b-white', 'c-white', 'd-white',
          and 'e-white' and clarified that the existing 'a', 'b', 'c',
          'd', and 'e' values are size values.  Added American,
          Japanese, and European Engineering sizes, filled out
          -transparent and - translucent media names and drawings for
          the synchro cut sizes.

Top      Up      ToC       Page 221 
      75. Section 16 - softened the RECOMMENDATION for IPP Printer
          attributes in a Directory schema so that they can have
          equivalents.
      76. Section 16 - added the OPTIONAL "pages-per-minute" and
          "pages-per-minute-color" Printer attributes to the Directory
          schema.
      77. Section 16 - added OPTIONAL "multiple-document-jobs-supported"
          to the Directory schema.
      78. Section 16 - added RECOMMENDED "uri-authentication-supported",
          "ipp-versions-supported", and "compression-supported" to the
          Directory schema.

   The following changes in semantics and/or conformance have been
   incorporated into this document:

      1.  Section 3.1.6.3 - allowed a Printer to localize the
          "detailed-status-message" operation response attribute, but
          indicated that such localization might obscure the technical
          meaning of such messages.
      2.  Section 3.1.8, 5.2.4, and 13.1.5.4 - Clients and IPP objects
          MUST support version 1.1 conformance requirements.   It is
          recommended that they interoperate with 1.0.  Also clarified
          that IPP Printers MUST accept '1.1' requests.   It is
          recommended that they also accept '1.x' requests.

      3.  Section 3.2.1.1 and section 4.4.32 - changed the "compression"
          operation and the "compression-supported" Printer Description
          attribute from OPTIONAL to REQUIRED.
      4.  Sections 3.2.1.2 and 4.3.8 - changed "job-state-reasons" from
          RECOMMENDED to REQUIRED, so that "job-state-reasons" MUST be
          returned in create operation responses.
      5.  Sections 3.2.4, 3.3.1, 4.4.16, and 16 - changed Create-
          Job/Send-Document so that they MAY be implemented while only
          supporting one document jobs.  Added the "multiple-document-
          jobs-supported" boolean Printer Description attribute to
          indicate whether Create-Job/Send-Document support multiple
          document jobs or not.  Added to the Directory schema.
      6.  Section 4.1.9 - deleted 'text/plain; charset=iso-10646-ucs-2',
          since binary is not legal with the 'text' type.
      7.  Section 4.1.9.1 - added the RECOMMENDATION that a Printer
          indicate by printing on the job's job-start-sheet that auto-
          sensing has occurred and what document format was auto-sensed.
      8.  Section 4.2.4 - indicated that the "multiple-document-
          handling" Job Template attribute MUST be supported with at
          least one value if the Printer supports multiple documents per
          job

Top      Up      ToC       Page 222 
      9.  Section 4.3.7.2 - indicated that the 'job-restartable' job
          state reason SHOULD be supported if the Restart-Job operation
          is supported.
      10. Section 4.3.8 - changed "job-state-reasons" from RECOMMENDED
          to REQUIRED.
      11. Section 4.3.8 - clarified the conformance of the values of the
          "job-state-reasons" attribute by copying conformance
          requirements from other sections of the document so that it is
          clear from reading the definition of "job-state-reasons" which
          values MUST or SHOULD be supported.  The 'none',
          'unsupported-compression', and 'unsupported-document-format'
          values MUST be supported.  The 'job-hold-until-specified'
          SHOULD be specified if the "job-hold-until" Job Template is
          supported.  The following values SHOULD be supported:  'job-
          canceled-by-user', 'aborted-by-system', and 'job-completed-
          successfully'.  The
          'job-canceled-by-operator' SHOULD be supported if the
          implementation permits canceling by other than the job owner.
          The 'job-canceled-at-device' SHOULD be supported if the device
          supports canceling jobs at the console.  The 'job-completed-
          with-warnings' SHOULD be supported, if the implementation
          detects warnings.  The 'job-completed-with-errors' SHOULD be
          supported if the implementation detects errors.  The 'job-
          restartable' SHOULD be supported if the Restart-Job operation
          is supported.
      12. Section 4.3.10 - allowed a Printer to localize the "job-
          detailed-status-message" Job Description attribute, but
          indicated that such localization might obscure the technical
          meaning of such messages.
      13. Section 4.3.14 - changed the "time-at-creation", "time-at-
          processing", and "time-at-completed" Event Time Job
          Description attributes from OPTIONAL to REQUIRED.
      14. Section 4.3.14.4 - added the REQUIRED "job-printer-up-time
          (integer(1:MAX))" Job Description attribute as an alias for
          "printer-up-time" to reduce number of operations to get job
          times.
      15. Section 4.4.2 - added the REQUIRED "uri-authentication-
          supported (1setOf type2 keyword)" Printer Description
          attribute to describe the Client Authentication used by each
          Printer URI.
      16. Section 4.4.12 - changed "printer-state-reasons" Printer
          Description attribute from OPTIONAL to REQUIRED.
      17. Section 4.4.12 - changed 'paused' value of "printer-state-
          reasons" to MUST if Pause-Printer operation is supported.

Top      Up      ToC       Page 223 
      18. Section 4.4.14 - added the REQUIRED "ipp-versions-supported
          (1setOf keyword)" Printer Description attribute, since IPP/1.1
          Printers do not have to support version '1.0' conformance
          requirements.  Section 4.4.16 - added the "multiple-document-
          jobs-supported (boolean)" Printer Description attribute so
          that a client can tell whether a Printer that supports
          Create-Job/Send-Document supports multiple document jobs or
          not.  This attribute is REQUIRED if the Create-Job operation
          is supported.
      19. Section 4.4.24 - changed the "queued-job-count" Printer
          Description attribute from RECOMMENDED to REQUIRED.
      20. Section 4.4.32 - changed "compression-supported (1setOf type3
          keyword)" Printer Description attribute from OPTIONAL to
          REQUIRED.
      21. Section 5.1 - changed the client security requirements from
          RECOMMENDED non-standards track SSL3 to MUST support Client
          Authentication as defined in the IPP/1.1 Encoding and
          Transport document [RFC2910].  A client SHOULD support
          Operation Privacy and Server Authentication as defined in the
          IPP/1.1 Encoding and Transport document [RFC2910].
      22. Section 5.2.7 - changed the IPP object security requirements
          from OPTIONAL non-standards track SSL3 to SHOULD contain
          support for Client Authentication as defined in the IPP/1.1
          Encoding and Transport document [RFC2910].  A Printer
          implementation MAY allow an administrator to configure the
          Printer so that all, some, or none of the users are
          authenticated.  An IPP Printer implementation SHOULD contain
          support for Operation Privacy and Server Authentication as
          defined in the IPP/1.1 Encoding and Transport document
          [RFC2910].  A Printer implementation MAY allow an
          administrator to configure the degree of support for Operation
          Privacy and Server Authentication.  Security MUST NOT be
          compromised when the client supplies a lower version-number in
          a request.
      23. Section 14 (Appendix C): Corrected typo, changing the keyword
          'iso-10-white' to 'iso-a10-white'.

   See also the "IPP/1.1 Encoding and Transport" [RFC2910] document for
   differences between IPP/1.0 [RFC2565] and IPP/1.1 [RFC2910].

Top      Up      ToC       Page 224 
18.  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.