Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2911

Internet Printing Protocol/1.1: Model and Semantics

Pages: 224
Obsoletes:  2566
Obsoleted by:  8011
Updated by:  33803382399639957472
Part 5 of 9 – Pages 91 to 118
First   Prev   Next

ToP   noToC   RFC2911 - Page 91   prevText

4.2 Job Template Attributes

Job Template attributes describe job processing behavior. Support for Job Template attributes by a Printer object is OPTIONAL (see section 12.2.3 for a description of support for OPTIONAL attributes). Also, clients OPTIONALLY supply Job Template attributes in create requests. Job Template attributes conform to the following rules. For each Job Template attribute called "xxx": 1. If the Printer object supports "xxx" then it MUST support both a "xxx-default" attribute (unless there is a "No" in the table below) and a "xxx-supported" attribute. If the Printer object doesn't support "xxx", then it MUST support neither an "xxx- default" attribute nor an "xxx-supported" attribute, and it MUST treat an attribute "xxx" supplied by a client as unsupported. An attribute "xxx" may be supported for some document formats and not supported for other document formats. For example, it is expected that a Printer object would only support "orientation-requested" for some document formats (such as 'text/plain' or 'text/html') but not others (such as 'application/postscript'). 2. "xxx" is OPTIONALLY supplied by the client in a create request. If "xxx" is supplied, the client is indicating a desired job processing behavior for this Job. When "xxx" is not supplied, the client is indicating that the Printer object apply its default job processing behavior at job processing time if the document content does not contain an embedded instruction indicating an xxx-related behavior. Since an administrator MAY change the default value attribute after a Job object has been submitted but before it has been processed, the default value used by the Printer object at job processing time may be different that the default value in effect at job submission time. 3. The "xxx-supported" attribute is a Printer object attribute that describes which job processing behaviors are supported by that Printer object. A client can query the Printer object to find out what xxx-related behaviors are supported by inspecting the returned values of the "xxx-supported" attribute.
ToP   noToC   RFC2911 - Page 92
         Note: The "xxx" in each "xxx-supported" attribute name is
         singular, even though an "xxx-supported" attribute usually has
         more than one value, such as "job-sheet-supported", unless the
         "xxx" Job Template attribute is plural, such as "finishings" or
         "sides".  In such cases the "xxx-supported" attribute names
         are: "finishings- supported" and "sides-supported".

      4. The "xxx-default" default value attribute describes what will
         be done at job processing time when no other job processing
         information is supplied by the client (either explicitly as an
         IPP attribute in the create request or implicitly as an
         embedded instruction within the document data).

   If an application wishes to present an end user with a list of
   supported values from which to choose, the application SHOULD query
   the Printer object for its supported value attributes.  The
   application SHOULD also query the default value attributes.  If the
   application then limits selectable values to only those value that
   are supported, the application can guarantee that the values supplied
   by the client in the create request all fall within the set of
   supported values at the Printer.  When querying the Printer, the
   client MAY enumerate each attribute by name in the Get-Printer-
   Attributes Request, or the client MAY just name the "job-template"
   group in order to get the complete set of supported attributes (both
   supported and default attributes).

   The "finishings" attribute is an example of a Job Template attribute.
   It can take on a set of values such as 'staple', 'punch', and/or
   'cover'.  A client can query the Printer object for the "finishings-
   supported" attribute and the "finishings-default" attribute.  The
   supported attribute contains a set of supported values.  The default
   value attribute contains the finishing value(s) that will be used for
   a new Job if the client does not supply a "finishings" attribute in
   the create request and the document data does not contain any
   corresponding finishing instructions.  If the client does supply the
   "finishings" attribute in the create request, the IPP object
   validates the value or values to make sure that they are a subset of
   the supported values identified in the Printer object's "finishings-
   supported" attribute.  See section 3.1.7.

   The table below summarizes the names and relationships for all Job
   Template attributes. The first column of the table (labeled "Job
   Attribute") shows the name and syntax for each Job Template attribute
   in the Job object. These are the attributes that can optionally be
   supplied by the client in a create request.   The last two columns
   (labeled "Printer: Default Value Attribute" and "Printer: Supported
   Values Attribute") show the name and syntax for each Job Template
   attribute in the Printer object (the default value attribute and the
ToP   noToC   RFC2911 - Page 93
   supported values attribute).  A "No" in the table means the Printer
   MUST NOT support the attribute (that is, the attribute is simply not
   applicable).  For brevity in the table, the 'text' and 'name' entries
   do not show the maximum length for each attribute.

     +===================+======================+======================+
     | Job Attribute     |Printer: Default Value|  Printer: Supported  |
     |                   |   Attribute          |   Values Attribute   |
     +===================+======================+======================+
     | job-priority      | job-priority-default |job-priority-supported|
     | (integer 1:100)   | (integer 1:100)      |(integer 1:100)       |
     +-------------------+----------------------+----------------------+
     | job-hold-until    | job-hold-until-      |job-hold-until-       |
     | (type3 keyword |  |  default             | supported            |
     |    name)          |  (type3 keyword |    |(1setOf (             |
     |                   |    name)             |type3 keyword | name))|
     +-------------------+----------------------+----------------------+
     | job-sheets        | job-sheets-default   |job-sheets-supported  |
     | (type3 keyword |  | (type3 keyword |     |(1setOf (             |
     |    name)          |    name)             |type3 keyword | name))|
     +-------------------+----------------------+----------------------+
     |multiple-document- |multiple-document-    |multiple-document-    |
     | handling          | handling-default     |handling-supported    |
     | (type2 keyword)   | (type2 keyword)      |(1setOf type2 keyword)|
     +-------------------+----------------------+----------------------+
     | copies            | copies-default       | copies-supported     |
     | (integer (1:MAX)) | (integer (1:MAX))    | (rangeOfInteger      |
     |                   |                      |       (1:MAX))       |
     +-------------------+----------------------+----------------------+
     | finishings        | finishings-default   | finishings-supported |
     |(1setOf type2 enum)|(1setOf type2 enum)   |(1setOf type2 enum)   |
     +-------------------+----------------------+----------------------+
     | page-ranges       | No                   | page-ranges-         |
     | (1setOf           |                      | supported (boolean)  |
     |   rangeOfInteger  |                      |                      |
     |        (1:MAX))   |                      |                      |
     +-------------------+----------------------+----------------------+
     | sides             | sides-default        | sides-supported      |
     | (type2 keyword)   | (type2 keyword)      |(1setOf type2 keyword)|
     +-------------------+----------------------+----------------------+
     | number-up         | number-up-default    | number-up-supported  |
     | (integer (1:MAX)) | (integer (1:MAX))    |(1setOf (integer      |
     |                   |                      | (1:MAX) |            |
     |                   |                      |  rangeOfInteger      |
     |                   |                      |   (1:MAX)))          |
ToP   noToC   RFC2911 - Page 94
     +-------------------+----------------------+----------------------+
     | orientation-      |orientation-requested-|orientation-requested-|
     |  requested        |  default             |  supported           |
     |   (type2 enum)    |  (type2 enum)        |  (1setOf type2 enum) |
     +-------------------+----------------------+----------------------+
     | media             | media-default        | media-supported      |
     | (type3 keyword |  | (type3 keyword |     |(1setOf (             |
     |    name)          |    name)             |type3 keyword | name))|
     |                   |                      |                      |
     |                   |                      | media-ready          |
     |                   |                      |(1setOf (             |
     |                   |                      |type3 keyword | name))|
     +-------------------+----------------------+----------------------+
     | printer-resolution| printer-resolution-  | printer-resolution-  |
     | (resolution)      |  default             | supported            |
     |                   | (resolution)         |(1setOf resolution)   |
     +-------------------+----------------------+----------------------+
     | print-quality     | print-quality-default| print-quality-       |
     | (type2 enum)      | (type2 enum)         | supported            |
     |                   |                      |(1setOf type2 enum)   |
     +-------------------+----------------------+----------------------+

4.2.1 job-priority (integer(1:100))

This attribute specifies a priority for scheduling the Job. A higher value specifies a higher priority. The value 1 indicates the lowest possible priority. The value 100 indicates the highest possible priority. Among those jobs that are ready to print, a Printer MUST print all jobs with a priority value of n before printing those with a priority value of n-1 for all n. If the Printer object supports this attribute, it MUST always support the full range from 1 to 100. No administrative restrictions are permitted. This way an end-user can always make full use of the entire range with any Printer object. If privileged jobs are implemented outside IPP/1.1, they MUST have priorities higher than 100, rather than restricting the range available to end-users. If the client does not supply this attribute and this attribute is supported by the Printer object, the Printer object MUST use the value of the Printer object's "job-priority-default" at job submission time (unlike most Job Template attributes that are used if necessary at job processing time). The syntax for the "job-priority-supported" is also integer(1:100). This single integer value indicates the number of priority levels supported. The Printer object MUST take the value supplied by the client and map it to the closest integer in a sequence of n integers
ToP   noToC   RFC2911 - Page 95
   values that are evenly distributed over the range from 1 to 100 using
   the formula:

      roundToNearestInt((100x+50)/n)

   where n is the value of "job-priority-supported" and x ranges from 0
   through n-1.

   For example, if n=1 the sequence of values is 50;  if n=2, the
   sequence of values is:  25 and 75;  if n = 3, the sequence of values
   is:  17, 50 and 83;  if n = 10, the sequence of values is: 5, 15, 25,
   35, 45, 55, 65, 75, 85, and 95;  if n = 100, the sequence of values
   is:  1, 2, 3, ... 100.

   If the value of the Printer object's "job-priority-supported" is 10
   and the client supplies values in the range 1 to 10, the Printer
   object maps them to 5, in the range 11 to 20, the Printer object maps
   them to 15, etc.

4.2.2 job-hold-until (type3 keyword | name (MAX))

This attribute specifies the named time period during which the Job MUST become a candidate for printing. Standard keyword values for named time periods are: 'no-hold': immediately, if there are not other reasons to hold the job 'indefinite': - the job is held indefinitely, until a client performs a Release-Job (section 3.3.6) 'day-time': during the day 'evening': evening 'night': night 'weekend': weekend 'second-shift': second-shift (after close of business) 'third-shift': third-shift (after midnight) An administrator MUST associate allowable print times with a named time period (by means outside the scope of this IPP/1.1 document). An administrator is encouraged to pick names that suggest the type of time period. An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation. If the value of this attribute specifies a time period that is in the future, the Printer SHOULD add the 'job-hold-until-specified' value to the job's "job-state-reasons" attribute, MUST move the job to the
ToP   noToC   RFC2911 - Page 96
   'pending-held' state, and MUST NOT schedule the job for printing
   until the specified time-period arrives.

   When the specified time period arrives, the Printer MUST remove the
   'job-hold-until-specified' value from the job's "job-state-reason"
   attribute, if present.  If there are no other job state reasons that
   keep the job in the 'pending-held' state, the Printer MUST consider
   the job as a candidate for processing by moving the job to the
   'pending' state.

   If this job attribute value is the named value 'no-hold', or the
   specified time period has already started, the job MUST be a
   candidate for processing immediately.

   If the client does not supply this attribute and this attribute is
   supported by the Printer object, the Printer object MUST use the
   value of the Printer object's "job-hold-until-default" at job
   submission time (unlike most Job Template attributes that are used if
   necessary at job processing time).

4.2.3 job-sheets (type3 keyword | name(MAX))

This attribute determines which job start/end sheet(s), if any, MUST be printed with a job. Standard keyword values are: 'none': no job sheet is printed 'standard': one or more site specific standard job sheets are printed, e.g. a single start sheet or both start and end sheet is printed An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation. The effect of this attribute on jobs with multiple documents MAY be affected by the "multiple-document-handling" job attribute (section 4.2.4), depending on the job sheet semantics.

4.2.4 multiple-document-handling (type2 keyword)

This attribute is relevant only if a job consists of two or more documents. This attribute MUST be supported with at least one value if the Printer supports multiple documents per job (see sections 3.2.4 and 3.3.1). The attribute controls finishing operations and the placement of one or more print-stream pages into impressions and onto media sheets. When the value of the "copies" attribute exceeds 1, it also controls the order in which the copies that result from
ToP   noToC   RFC2911 - Page 97
   processing the documents are produced. For the purposes of this
   explanations, if "a" represents an instance of document data, then
   the result of processing the data in document "a" is a sequence of
   media sheets represented by "a(*)".

   Standard keyword values are:

      'single-document': If a Job object has multiple documents, say,
         the document data is called a and b, then the result of
         processing all the document data (a and then b) MUST be treated
         as a single sequence of media sheets for finishing operations;
         that is, finishing would be performed on the concatenation of
         the sequences a(*),b(*).  The Printer object MUST NOT force the
         data in each document instance to be formatted onto a new
         print-stream page, nor to start a new impression on a new media
         sheet. If more than one copy is made, the ordering of the sets
         of media sheets resulting from processing the document data
         MUST be a(*), b(*), a(*), b(*), start on a new media sheet.
      'separate-documents-uncollated-copies': If a Job object has
         multiple documents, say, the document data is called a and b,
         then the result of processing the data in each document
         instance MUST be treated as a single sequence of media sheets
         for finishing operations; that is, the sets a(*) and b(*) would
         each be finished separately. The Printer object MUST force each
         copy of the result of processing the data in a single document
         to start on a new media sheet. If more than one copy is made,
         the ordering of the sets of media sheets resulting from
         processing the document data MUST be a(*), a(*), ..., b(*),
         b(*) ... .
      'separate-documents-collated-copies': If a Job object has multiple
         documents, say, the document data is called a and b, then the
         result of processing the data in each document instance MUST be
         treated as a single sequence of media sheets for finishing
         operations; that is, the sets a(*) and b(*) would each be
         finished separately. The Printer object MUST force each copy of
         the result of processing the data in a single document to start
         on a new media sheet.  If more than one copy is made, the
         ordering of the sets of media sheets resulting from processing
         the document data MUST be a(*), b(*), a(*), b(*), ... .
      'single-document-new-sheet':  Same as 'single-document', except
         that the Printer object MUST ensure that the first impression
         of each document instance in the job is placed on a new media
         sheet.  This value allows multiple documents to be stapled
         together with a single staple where each document starts on a
         new sheet.
ToP   noToC   RFC2911 - Page 98
   The 'single-document' value is the same as 'separate-documents-
   collated-copies' with respect to ordering of print-stream pages, but
   not media sheet generation, since 'single-document' will put the
   first page of the next document on the back side of a sheet if an odd
   number of pages have been produced so far for the job, while
   'separate-documents-collated- copies' always forces the next document
   or document copy on to a new sheet.  In addition, if the "finishings"
   attribute specifies 'staple', then with 'single-document', documents
   a and b are stapled together as a single document with no regard to
   new sheets, with 'single-document-new-sheet', documents a and b are
   stapled together as a single document, but document b starts on a new
   sheet, but with 'separate-documents-uncollated-copies' and
   'separate-documents-collated-copies', documents a and b are stapled
   separately.

   Note: None of these values provide means to produce uncollated sheets
   within a document, i.e., where multiple copies of sheet n are
   produced before sheet n+1 of the same document.

   The relationship of this attribute and the other attributes that
   control document processing is described in section 15.3.

4.2.5 copies (integer(1:MAX))

This attribute specifies the number of copies to be printed. On many devices the supported number of collated copies will be limited by the number of physical output bins on the device, and may be different from the number of uncollated copies which can be supported. Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4) and the relationship of this attribute and the other attributes that control document processing is described in section 15.3.

4.2.6 finishings (1setOf type2 enum)

This attribute identifies the finishing operations that the Printer uses for each copy of each printed document in the Job. For Jobs with multiple documents, the "multiple-document-handling" attribute determines what constitutes a "copy" for purposes of finishing.
ToP   noToC   RFC2911 - Page 99
   Standard enum values are:

   Value  Symbolic Name and Description

   '3'    'none':  Perform no finishing
   '4'    'staple':  Bind the document(s) with one or more staples. The
             exact number and placement of the staples is site-
             defined.
   '5'    'punch':  This value indicates that holes are required in the
             finished document. The exact number and placement of the
             holes is site-defined  The punch specification MAY be
             satisfied (in a site- and implementation-specific manner)
             either by drilling/punching, or by substituting pre-
             drilled media.
   '6'    'cover':  This value is specified when it is desired to select
             a non-printed (or pre-printed) cover for the document.
             This does not supplant the specification of a printed
             cover (on cover stock medium) by the document itself.
   '7'    'bind':  This value indicates that a binding is to be applied
             to the document; the type and placement of the binding is
             site-defined.
   '8'    'saddle-stitch':  Bind the document(s) with one or more
             staples (wire stitches) along the middle fold.  The exact
             number and placement of the staples and the middle fold
             is implementation and/or site-defined.
   '9'    'edge-stitch':  Bind the document(s) with one or more staples
             (wire stitches) along one edge.  The exact number and
             placement of the staples is implementation and/or site-
             defined.
   '10'-'19'   reserved for future generic finishing enum values.

   The following values are more specific; they indicate a corner or an
   edge as if the document were a portrait document (see below):

   '20'   'staple-top-left':  Bind the document(s) with one or more
             staples in the top left corner.
   '21'   'staple-bottom-left':  Bind the document(s) with one or more
             staples in the bottom left corner.
   '22'   'staple-top-right':  Bind the document(s) with one or more
             staples in the top right corner.
   '23'   'staple-bottom-right':  Bind the document(s) with one or more
             staples in the bottom right corner.
   '24'   'edge-stitch-left':  Bind the document(s) with one or more
             staples (wire stitches) along the left edge.  The exact
             number and placement of the staples is implementation
             and/or site-defined.
ToP   noToC   RFC2911 - Page 100
   '25'   'edge-stitch-top':  Bind the document(s) with one or more
             staples (wire stitches) along the top edge.  The exact
             number and placement of the staples is implementation
             and/or site-defined.
   '26'   'edge-stitch-right':  Bind the document(s) with one or more
             staples (wire stitches) along the right edge.  The exact
             number and placement of the staples is implementation
             and/or site-defined.
   '27'   'edge-stitch-bottom':  Bind the document(s) with one or more
             staples (wire stitches) along the bottom edge.  The exact
             number and placement of the staples is implementation
             and/or site-defined.
   '28'   'staple-dual-left':  Bind the document(s) with two staples
             (wire stitches) along the left edge assuming a portrait
             document (see above).
   '29'   'staple-dual-top':  Bind the document(s) with two staples
             (wire stitches) along the top edge assuming a portrait
             document (see above).
   '30'   'staple-dual-right':  Bind the document(s) with two staples
             (wire stitches) along the right edge assuming a portrait
             document (see above).
   '31'   'staple-dual-bottom':  Bind the document(s) with two staples
             (wire stitches) along the bottom edge assuming a portrait
             document (see above).

   The 'staple-xxx' values are specified with respect to the document as
   if the document were a portrait document.  If the document is
   actually a landscape or a reverse-landscape document, the client
   supplies the appropriate transformed value.  For example, to position
   a staple in the upper left hand corner of a landscape document when
   held for reading, the client supplies the 'staple-bottom-left' value
   (since landscape is defined as a +90 degree rotation of the image
   with respect to the media from portrait, i.e., anti-clockwise).  On
   the other hand, to position a staple in the upper left hand corner of
   a reverse-landscape document when held for reading, the client
   supplies the 'staple-top-right' value (since reverse-landscape is
   defined as a -90 degree rotation of the image with respect to the
   media from portrait, i.e., clockwise).

   The angle (vertical, horizontal, angled) of each staple with respect
   to the document depends on the implementation which may in turn
   depend on the value of the attribute.

   Note: The effect of this attribute on jobs with multiple documents is
   controlled by the "multiple-document-handling" job attribute (section
   4.2.4) and the relationship of this attribute and the other
   attributes that control document processing is described in section
   15.3.
ToP   noToC   RFC2911 - Page 101
   If the client supplies a value of 'none' along with any other
   combination of values, it is the same as if only that other
   combination of values had been supplied (that is the 'none' value has
   no effect).

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

This attribute identifies the range(s) of print-stream pages that the Printer object uses for each copy of each document which are to be printed. Nothing is printed for any pages identified that do not exist in the document(s). Ranges MUST be in ascending order, for example: 1-3, 5-7, 15-19 and MUST NOT overlap, so that a non-spooling Printer object can process the job in a single pass. If the ranges are not ascending or are overlapping, the IPP object MUST reject the request and return the 'client-error-bad-request' status code. The attribute is associated with print-stream pages not application- numbered pages (for example, the page numbers found in the headers and or footers for certain word processing applications). For Jobs with multiple documents, the "multiple-document-handling" attribute determines what constitutes a "copy" for purposes of the specified page range(s). When "multiple-document-handling" is 'single-document', the Printer object MUST apply each supplied page range once to the concatenation of the print-stream pages. For example, if there are 8 documents of 10 pages each, the page-range '41:60' prints the pages in the 5th and 6th documents as a single document and none of the pages of the other documents are printed. When "multiple-document- handling" is 'separate-documents- uncollated-copies' or 'separate-documents-collated-copies', the Printer object MUST apply each supplied page range repeatedly to each document copy. For the same job, the page-range '1:3, 10:10' would print the first 3 pages and the 10th page of each of the 8 documents in the Job, as 8 separate documents. In most cases, the exact pages to be printed will be generated by a device driver and this attribute would not be required. However, when printing an archived document which has already been formatted, the end user may elect to print just a subset of the pages contained in the document. In this case, if page-range = n.m is specified, the first page to be printed will be page n. All subsequent pages of the document will be printed through and including page m. "page-ranges-supported" is a boolean value indicating whether or not the printer is capable of supporting the printing of page ranges. This capability may differ from one PDL to another. There is no "page-ranges-default" attribute. If the "page-ranges" attribute is not supplied by the client, all pages of the document will be printed.
ToP   noToC   RFC2911 - Page 102
   Note: The effect of this attribute on jobs with multiple documents is
   controlled by the "multiple-document-handling" job attribute (section
   4.2.4) and the relationship of this attribute and the other
   attributes that control document processing is described in section
   15.3.

4.2.8 sides (type2 keyword)

This attribute specifies how print-stream pages are to be imposed upon the sides of an instance of a selected medium, i.e., an impression. The standard keyword values are: 'one-sided': imposes each consecutive print-stream page upon the same side of consecutive media sheets. 'two-sided-long-edge': imposes each consecutive pair of print- stream pages upon front and back sides of consecutive media sheets, such that the orientation of each pair of print-stream pages on the medium would be correct for the reader as if for binding on the long edge. This imposition is sometimes called 'duplex' or 'head-to-head'. 'two-sided-short-edge': imposes each consecutive pair of print- stream pages upon front and back sides of consecutive media sheets, such that the orientation of each pair of print-stream pages on the medium would be correct for the reader as if for binding on the short edge. This imposition is sometimes called 'tumble' or 'head-to-toe'. 'two-sided-long-edge', 'two-sided-short-edge', 'tumble', and 'duplex' all work the same for portrait or landscape. However 'head-to-toe' is 'tumble' in portrait but 'duplex' in landscape. 'head-to-head' also switches between 'duplex' and 'tumble' when using portrait and landscape modes. Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4) and the relationship of this attribute and the other attributes that control document processing is described in section 15.3.

4.2.9 number-up (integer(1:MAX))

This attribute specifies the number of print-stream pages to impose upon a single side of an instance of a selected medium. For example, if the value is:
ToP   noToC   RFC2911 - Page 103
   Value  Description

   '1'    the Printer MUST place one print-stream page on a single side
             of an instance of the selected medium (MAY add some sort
             of translation, scaling, or rotation).
   '2'    the Printer MUST place two print-stream pages on a single side
             of an instance of the selected medium (MAY add some sort
             of translation, scaling, or rotation).
   '4'    the Printer MUST place four print-stream pages on a single
             side of an instance of the selected medium (MAY add some
             sort of translation, scaling, or rotation).

   This attribute primarily controls the translation, scaling and
   rotation of print-stream pages.

   Note: The effect of this attribute on jobs with multiple documents is
   controlled by the "multiple-document-handling" job attribute (section
   4.2.4) and the relationship of this attribute and the other
   attributes that control document processing is described in section
   15.3.

4.2.10 orientation-requested (type2 enum)

This attribute indicates the desired orientation for printed print- stream pages; it does not describe the orientation of the client- supplied print-stream pages. For some document formats (such as 'application/postscript'), the desired orientation of the print-stream pages is specified within the document data. This information is generated by a device driver prior to the submission of the print job. Other document formats (such as 'text/plain') do not include the notion of desired orientation within the document data. In the latter case it is possible for the Printer object to bind the desired orientation to the document data after it has been submitted. It is expected that a Printer object would only support "orientations-requested" for some document formats (e.g., 'text/plain' or 'text/html') but not others (e.g., 'application/postscript'). This is no different than any other Job Template attribute since section 4.2, item 1, points out that a Printer object may support or not support any Job Template attribute based on the document format supplied by the client. However, a special mention is made here since it is very likely that a Printer object will support "orientation-requested" for only a subset of the supported document formats.
ToP   noToC   RFC2911 - Page 104
   Standard enum values are:

   Value  Symbolic Name and Description

   '3'    'portrait':  The content will be imaged across the short edge
             of the medium.
   '4'    'landscape':  The content will be imaged across the long edge
             of the medium.  Landscape is defined to be a rotation of
             the print-stream page to be imaged by +90 degrees with
             respect to the medium (i.e. anti-clockwise) from the
             portrait orientation.  Note:  The +90 direction was
             chosen because simple finishing on the long edge is the
             same edge whether portrait or landscape
   '5'    'reverse-landscape':  The content will be imaged across the
             long edge of the medium.  Reverse-landscape is defined to
             be a rotation of the print-stream page to be imaged by -
             90 degrees with respect to the medium (i.e. clockwise)
             from the portrait orientation.  Note: The 'reverse-
             landscape' value was added because some applications
             rotate landscape -90 degrees from portrait, rather than
             +90 degrees.
   '6'    'reverse-portrait':  The content will be imaged across the
             short edge of the medium.  Reverse-portrait is defined to
             be a rotation of the print-stream page to be imaged by
             180 degrees with respect to the medium from the portrait
             orientation.  Note: The 'reverse-portrait' value was
             added for use with the "finishings" attribute in cases
             where the opposite edge is desired for finishing a
             portrait document on simple finishing devices that have
             only one finishing position.  Thus a 'text'/plain'
             portrait document can be stapled "on the right" by a
             simple finishing device as is common use with some middle
             eastern languages such as Hebrew.

   Note: The effect of this attribute on jobs with multiple documents is
   controlled by the "multiple-document-handling" job attribute (section
   4.2.4) and the relationship of this attribute and the other
   attributes that control document processing is described in section
   15.3.

4.2.11 media (type3 keyword | name(MAX))

This attribute identifies the medium that the Printer uses for all impressions of the Job. The values for "media" include medium-names, medium-sizes, input- trays and electronic forms so that one attribute specifies the media. If a Printer object supports a medium name as a value of this
ToP   noToC   RFC2911 - Page 105
   attribute, such a medium name implicitly selects an input-tray that
   contains the specified medium.  If a Printer object supports a medium
   size as a value of this attribute, such a medium size implicitly
   selects a medium name that in turn implicitly selects an input-tray
   that contains the medium with the specified size.  If a Printer
   object supports an input-tray as the value of this attribute, such an
   input-tray implicitly selects the medium that is in that input-tray
   at the time the job prints.  This case includes manual-feed input-
   trays.  If a Printer object supports an electronic form as the value
   of this attribute, such an electronic form implicitly selects a
   medium-name that in turn implicitly selects an input-tray that
   contains the medium specified by the electronic form.  The electronic
   form also implicitly selects an image that the Printer MUST merge
   with the document data as its prints each page.

   Standard keyword values are taken from ISO DPA [ISO10175], the
   Printer MIB [RFC1759], and ASME-Y14.1M [ASME-Y14.1M] and are listed
   in section 14.  An administrator MAY define additional values using
   the 'name' or 'keyword' attribute syntax, depending on
   implementation.

   There is also an additional Printer attribute named "media-ready"
   which differs from "media-supported" in that legal values only
   include the subset of "media-supported" values that are physically
   loaded and ready for printing with no operator intervention required.
   If an IPP object supports "media-supported", it NEED NOT support
   "media-ready".

   The relationship of this attribute and the other attributes that
   control document processing is described in section 15.3.

4.2.12 printer-resolution (resolution)

This attribute identifies the resolution that Printer uses for the Job.

4.2.13 print-quality (type2 enum)

This attribute specifies the print quality that the Printer uses for the Job. The standard enum values are: Value Symbolic Name and Description '3' 'draft': lowest quality available on the printer '4' 'normal': normal or intermediate quality on the printer '5' 'high': highest quality available on the printer
ToP   noToC   RFC2911 - Page 106

4.3 Job Description Attributes

The attributes in this section form the attribute group called "job- description". The following table summarizes these attributes. The third column indicates whether the attribute is a REQUIRED attribute that MUST be supported by Printer objects. If it is not indicated as REQUIRED, then it is OPTIONAL. The maximum size in octets for 'text' and 'name' attributes is indicated in parenthesizes. +----------------------------+----------------------+--------------+ | Attribute | Syntax | REQUIRED? | +----------------------------+----------------------+--------------+ | job-uri | uri | REQUIRED | +----------------------------+----------------------+--------------+ | job-id | integer(1:MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | job-printer-uri | uri | REQUIRED | +----------------------------+----------------------+--------------+ | job-more-info | uri | | +----------------------------+----------------------+--------------+ | job-name | name (MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | job-originating-user-name | name (MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | job-state | type1 enum | REQUIRED | +----------------------------+----------------------+--------------+ | job-state-reasons | 1setOf type2 keyword | REQUIRED | +----------------------------+----------------------+--------------+ | job-state-message | text (MAX) | | +----------------------------+----------------------+--------------+ | job-detailed-status- | 1setOf text (MAX) | | | messages | | | +----------------------------+----------------------+--------------+ | job-document-access-errors | 1setOf text (MAX) | | +----------------------------+----------------------+--------------+ | number-of-documents | integer (0:MAX) | | +----------------------------+----------------------+--------------+ | output-device-assigned | name (127) | | +----------------------------+----------------------+--------------+ | time-at-creation | integer (MIN:MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | time-at-processing | integer (MIN:MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | time-at-completed | integer (MIN:MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | job-printer-up-time | integer (1:MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | date-time-at-creation | dateTime | |
ToP   noToC   RFC2911 - Page 107
   +----------------------------+----------------------+--------------+
   | date-time-at-processing    | dateTime             |              |
   +----------------------------+----------------------+--------------+
   | date-time-at-completed     | dateTime             |              |
   +----------------------------+----------------------+--------------+
   | number-of-intervening-jobs | integer (0:MAX)      |              |
   +----------------------------+----------------------+--------------+
   | job-message-from-operator  | text (127)           |              |
   +----------------------------+----------------------+--------------+
   | job-k-octets               | integer (0:MAX)      |              |
   +----------------------------+----------------------+--------------+
   | job-impressions            | integer (0:MAX)      |              |
   +----------------------------+----------------------+--------------+
   | job-media-sheets           | integer (0:MAX)      |              |
   +----------------------------+----------------------+--------------+
   | job-k-octets-processed     | integer (0:MAX)      |              |
   +----------------------------+----------------------+--------------+
   | job-impressions-completed  | integer (0:MAX)      |              |
   +----------------------------+----------------------+--------------+
   | job-media-sheets-completed | integer (0:MAX)      |              |
   +----------------------------+----------------------+--------------+
   | attributes-charset         | charset              |  REQUIRED    |
   +----------------------------+----------------------+--------------+
   | attributes-natural-language| naturalLanguage      |  REQUIRED    |
   +----------------------------+----------------------+--------------+

4.3.1 job-uri (uri)

This REQUIRED attribute contains the URI for the job. The Printer object, on receipt of a new job, generates a URI which identifies the new Job. The Printer object returns the value of the "job-uri" attribute as part of the response to a create request. The precise format of a Job URI is implementation dependent. If the Printer object supports more than one URI and there is some relationship between the newly formed Job URI and the Printer object's URI, the Printer object uses the Printer URI supplied by the client in the create request. For example, if the create request comes in over a secure channel, the new Job URI MUST use the same secure channel. This can be guaranteed because the Printer object is responsible for generating the Job URI and the Printer object is aware of its security configuration and policy as well as the Printer URI used in the create request. For a description of this attribute and its relationship to "job-id" and "job-printer-uri" attribute, see the discussion in section 2.4 on "Object Identity".
ToP   noToC   RFC2911 - Page 108

4.3.2 job-id (integer(1:MAX))

This REQUIRED attribute contains the ID of the job. The Printer, on receipt of a new job, generates an ID which identifies the new Job on that Printer. The Printer returns the value of the "job-id" attribute as part of the response to a create request. The 0 value is not included to allow for compatibility with SNMP index values which also cannot be 0. For a description of this attribute and its relationship to "job-uri" and "job-printer-uri" attribute, see the discussion in section 2.4 on "Object Identity".

4.3.3 job-printer-uri (uri)

This REQUIRED attribute identifies the Printer object that created this Job object. When a Printer object creates a Job object, it populates this attribute with the Printer object URI that was used in the create request. This attribute permits a client to identify the Printer object that created this Job object when only the Job object's URI is available to the client. The client queries the creating Printer object to determine which languages, charsets, operations, are supported for this Job. For a description of this attribute and its relationship to "job-uri" and "job-id" attribute, see the discussion in section 2.4 on "Object Identity".

4.3.4 job-more-info (uri)

Similar to "printer-more-info", this attribute contains the URI referencing some resource with more information about this Job object, perhaps an HTML page containing information about the Job.

4.3.5 job-name (name(MAX))

This REQUIRED attribute is the name of the job. It is a name that is more user friendly than the "job-uri" attribute value. It does not need to be unique between Jobs. The Job's "job-name" attribute is set to the value supplied by the client in the "job-name" operation attribute in the create request (see Section 3.2.1.1). If, however, the "job-name" operation attribute is not supplied by the client in the create request, the Printer object, on creation of the Job, MUST generate a name. The printer SHOULD generate the value of the Job's "job-name" attribute from the first of the following sources that produces a value: 1) the "document-name" operation attribute of the
ToP   noToC   RFC2911 - Page 109
   first (or only) document, 2) the "document-URI" attribute of the
   first (or only) document, or 3) any other piece of Job specific
   and/or Document Content information.

4.3.6 job-originating-user-name (name(MAX))

This REQUIRED attribute contains the name of the end user that submitted the print job. The Printer object sets this attribute to the most authenticated printable name that it can obtain from the authentication service over which the IPP operation was received. Only if such is not available, does the Printer object use the value supplied by the client in the "requesting-user-name" operation attribute of the create operation (see Sections 4.4.2, 4.4.3, and 8). Note: The Printer object needs to keep an internal originating user id of some form, typically as a credential of a principal, with the Job object. Since such an internal attribute is implementation- dependent and not of interest to clients, it is not specified as a Job Description attribute. This originating user id is used for authorization checks (if any) on all subsequent operations.

4.3.7 job-state (type1 enum)

This REQUIRED attribute identifies the current state of the job. Even though the IPP protocol defines seven values for job states (plus the out-of-band 'unknown' value - see Section 4.1), implementations only need to support those states which are appropriate for the particular implementation. In other words, a Printer supports only those job states implemented by the output device and available to the Printer object implementation. Standard enum values are: Values Symbolic Name and Description '3' 'pending': The job is a candidate to start processing, but is not yet processing. '4' 'pending-held': The job is not a candidate for processing for any number of reasons but will return to the 'pending' state as soon as the reasons are no longer present. The job's "job-state-reason" attribute MUST indicate why the job is no longer a candidate for processing.
ToP   noToC   RFC2911 - Page 110
   '5'  'processing':  One or more of:

           1.  the job is using, or is attempting to use, one or
           more purely software processes that are analyzing,
           creating, or interpreting a PDL, etc.,
           2.  the job is using, or is attempting to use, one or
           more hardware devices that are interpreting a PDL, making
           marks on a medium, and/or performing finishing, such as
           stapling, etc.,
           3. the Printer object has made the job ready for
           printing, but the output device is not yet printing it,
           either because the job hasn't reached the output device
           or because the job is queued in the output device or some
           other spooler, awaiting the output device to print it.

           When the job is in the 'processing' state, the entire job
           state includes the detailed status represented in the
           Printer object's "printer-state", "printer-state-
           reasons", and "printer-state-message" attributes.

           Implementations MAY, though they NEED NOT,  include
           additional values in the job's "job-state-reasons"
           attribute to indicate the progress of the job, such as
           adding the 'job-printing' value to indicate when the
           output device is actually making marks on paper and/or
           the 'processing-to-stop-point' value to indicate that the
           IPP object is in the process of canceling or aborting the
           job.  Most implementations won't bother with this nuance.

   '6'  'processing-stopped':  The job has stopped while processing
           for any number of reasons and will return to the
           'processing' state as soon as the reasons are no longer
           present.

           The job's "job-state-reason" attribute MAY indicate why
           the job has stopped processing.  For example, if the
           output device is stopped, the 'printer-stopped' value MAY
           be included in the job's "job-state-reasons" attribute.

           Note:  When an output device is stopped, the device
           usually indicates its condition in human readable form
           locally at the device.  A client can obtain more complete
           device status remotely by querying the Printer object's
           "printer-state", "printer-state-reasons" and "printer-
           state-message" attributes.

   '7'  'canceled':  The job has been canceled by a Cancel-Job
           operation and the Printer object has completed canceling
ToP   noToC   RFC2911 - Page 111
           the job and all job status attributes have reached their
           final values for the job.  While the Printer object is
           canceling the job, the job remains in its current state,
           but the job's "job-state-reasons" attribute SHOULD
           contain the 'processing-to-stop-point' value and one of
           the 'canceled-by-user', 'canceled-by-operator', or
           'canceled-at-device' value.  When the job moves to the
           'canceled' state, the  'processing-to-stop-point' value,
           if present, MUST be removed, but the 'canceled-by-xxx',
           if present, MUST remain.

   '8'  'aborted':  The job has been aborted by the system, usually
           while the job was in the 'processing' or 'processing-
           stopped' state and the Printer has completed aborting the
           job and all job status attributes have reached their
           final values for the job.  While the Printer object is
           aborting the job, the job remains in its current state,
           but the job's "job-state-reasons" attribute SHOULD
           contain the 'processing-to-stop-point' and 'aborted-by-
           system' values.  When the job moves to the 'aborted'
           state, the  'processing-to-stop-point' value, if present,
           MUST be removed, but the 'aborted-by-system' value, if
           present, MUST remain.

   '9'  'completed':  The job has completed successfully or with
           warnings or errors after processing and all of the job
           media sheets have been successfully stacked in the
           appropriate output bin(s) and all job status attributes
           have reached their final values for the job.  The job's
           "job-state-reasons" attribute SHOULD contain one of:
           'completed-successfully', 'completed-with-warnings', or
           'completed-with-errors' values.

   The final value for this attribute MUST be one of: 'completed',
   'canceled', or 'aborted' before the Printer removes the job
   altogether.  The length of time that jobs remain in the 'canceled',
   'aborted', and 'completed' states depends on implementation.  See
   section 4.3.7.2.

   The following figure shows the normal job state transitions.

                                                      +----> canceled
                                                     /
       +----> pending --------> processing ---------+------> completed
       |         ^                   ^               \
   --->+         |                   |                +----> aborted
       |         v                   v               /
       +----> pending-held    processing-stopped ---+
ToP   noToC   RFC2911 - Page 112
   Normally a job progresses from left to right.  Other state
   transitions are unlikely, but are not forbidden.  Not shown are the
   transitions to the 'canceled' state from the 'pending', 'pending-
   held', and 'processing-stopped' states.

   Jobs reach one of the three terminal states: 'completed', 'canceled',
   or 'aborted', after the jobs have completed all activity, including
   stacking output media, after the jobs have completed all activity,
   and all job status attributes have reached their final values for the
   job.

4.3.7.1 Forwarding Servers
As with all other IPP attributes, if the implementation cannot determine the correct value for this attribute, it SHOULD respond with the out-of-band value 'unknown' (see section 4.1) rather than try to guess at some possibly incorrect value and give the end user the wrong impression about the state of the Job object. For example, if the implementation is just a gateway into some printing system from which it can normally get status, but temporarily is unable, then the implementation should return the 'unknown' value. However, if the implementation is a gateway to a printing system that never provides detailed status about the print job, the implementation MAY set the IPP Job object's state to 'completed', provided that it also sets the 'queued-in-device' value in the job's "job-state-reasons" attribute (see section 4.3.8).
4.3.7.2 Partitioning of Job States
This section partitions the 7 job states into phases: Job Not Completed, Job Retention, Job History, and Job Removal. This section also explains the 'job-restartable' value of the "job-state-reasons" Job Description attribute for use with the Restart-Job operation. Job Not Completed: When a job is in the 'pending', 'pending-held', 'processing', or 'processing-stopped' states, the job is not completed. Job Retention: When a job enters one of the three terminal job states: 'completed', 'canceled', or 'aborted', the IPP Printer object MAY "retain" the job in a restartable condition for an implementation-defined time period. This time period MAY be zero seconds and MAY depend on the terminal job state. This phase is called Job Retention. While in the Job Retention phase, the job's document data is retained and a client may restart the job using the Restart-Job operation. If the IPP object supports the Restart-Job
ToP   noToC   RFC2911 - Page 113
   operation, then it SHOULD indicate that the job is restartable by
   adding the 'job-restartable' value to the job's "job-state-reasons"
   attribute (see Section 4.3.8) during the Job Retention phase.

   Job History:  After the Job Retention phase expires for a job, the
   Printer object deletes the document data for the job and the job
   becomes part of the Job History.  The Printer object MAY also delete
   any number of the job attributes.  Since the job is no longer
   restartable, the Printer object MUST remove the 'job-restartable'
   value from the job's "job-state-reasons" attribute, if present.

   Job Removal:  After the job has remained in the Job History for an
   implementation-defined time, such as when the number of jobs exceeds
   a fixed number or after a fixed time period (which MAY be zero
   seconds), the IPP Printer removes the job from the system.

   Using the Get-Jobs operation and supplying the 'not-completed' value
   for the "which-jobs" operation attribute, a client is requesting jobs
   in the Job Not Completed phase.  Using the Get-Jobs operation and
   supplying the 'completed' value for the "which-jobs" operation
   attribute, a client is requesting jobs in the Job Retention and Job
   History phases.  Using the Get-Job-Attributes operation, a client is
   requesting a job in any phase except Job Removal.  After Job Removal,
   the Get-Job-Attributes and Get-Jobs operations no longer are capable
   of returning any information about a job.

4.3.8 job-state-reasons (1setOf type2 keyword)

This REQUIRED attribute provides additional information about the job's current state, i.e., information that augments the value of the job's "job-state" attribute. These values MAY be used with any job state or states for which the reason makes sense. Some of these value definitions indicate conformance requirements; the rest are OPTIONAL. Furthermore, when implemented, the Printer MUST return these values when the reason applies and MUST NOT return them when the reason no longer applies whether the value of the Job's "job-state" attribute changed or not. When the Job does not have any reasons for being in its current state, the value of the Job's "job-state-reasons" attribute MUST be 'none'. Note: While values cannot be added to the 'job-state' attribute without impacting deployed clients that take actions upon receiving "job-state" values, it is the intent that additional "job-state- reasons" values can be defined and registered without impacting such deployed clients. In other words, the "job-state-reasons" attribute is intended to be extensible.
ToP   noToC   RFC2911 - Page 114
   The following standard keyword values are defined.  For ease of
   understanding, the values are presented in the order in which the
   reasons are likely to occur (if implemented), starting with the
   'job-incoming' value:

      'none':  There are no reasons for the job's current state.  This
         state reason is semantically equivalent to "job-state-reasons"
         without any value and MUST be used when there is no other
         value, since the 1setOf attribute syntax requires at least one
         value.
      'job-incoming':  Either (1) the Printer has accepted the Create-
         Job operation and is expecting additional Send-Document and/or
         Send-URI operations, or (2) the Printer is retrieving/accepting
         document data as a result of a Print-Job, Print-URI, Send-
         Document or Send-URI operation.
      'job-data-insufficient':  The Create-Job operation has been
         accepted by the Printer, but the Printer is expecting
         additional document data before it can move the job into the
         'processing' state.  If a Printer starts processing before it
         has received all data, the Printer removes the 'job-data-
         insufficient' reason, but the 'job-incoming' remains.  If a
         Printer starts processing after it has received all data, the
         Printer removes the 'job-data-insufficient' reason and the
         'job-incoming' at the same time.
      'document-access-error':  After accepting a Print-URI or Send-URI
         request, the Printer could not access one or more documents
         passed by reference.  This reason is intended to cover any file
         access problem, including file does not exist and access denied
         because of an access control problem.  The Printer MAY also
         indicate the document access error using the "job-document-
         access-errors" Job Description attribute (see section 4.3.11).
         Whether the Printer aborts the job and moves the job to the
         'aborted' job state or prints all documents that are accessible
         and moves the job to the 'completed' job state and adds the
         'completed-with-errors' value in the job's "job-state-reasons"
         attribute depends on implementation and/or site policy.  This
         value SHOULD be supported if the Print-URI or Send-URI
         operations are supported.
      'submission-interrupted':  The job was not completely submitted
         for some unforeseen reason, such as: (1) the Printer has
         crashed before the job was closed by the client, (2) the
         Printer or the document transfer method has crashed in some
         non-recoverable way before the document data was entirely
         transferred to the Printer, (3) the client crashed or failed to
         close the job before the time-out period.  See section 4.4.31.
      'job-outgoing':  The Printer is transmitting the job to the output
         device.
ToP   noToC   RFC2911 - Page 115
      'job-hold-until-specified':  The value of the job's "job-hold-
         until" attribute was specified with a time period that is still
         in the future.  The job MUST NOT be a candidate for processing
         until this reason is removed and there are no other reasons to
         hold the job.  This value SHOULD be supported if the "job-
         hold-until" Job Template attribute is supported.
      'resources-are-not-ready':  At least one of the resources needed
         by the job, such as media, fonts, resource objects, etc., is
         not ready on any of the physical printer's for which the job is
         a candidate.  This condition MAY be detected when the job is
         accepted, or subsequently while the job is pending or
         processing, depending on implementation.  The job may remain in
         its current state or be moved to the 'pending-held' state,
         depending on implementation and/or job scheduling policy.
      'printer-stopped-partly':  The value of the Printer's "printer-
         state-reasons" attribute contains the value 'stopped-partly'.
      'printer-stopped':  The value of the Printer's "printer-state"
         attribute is 'stopped'.
      'job-interpreting': Job is in the 'processing' state, but more
         specifically, the Printer is interpreting the document data.
      'job-queued': Job is in the 'processing' state, but more
         specifically, the Printer has queued the document data.
      'job-transforming': Job is in the 'processing' state, but more
         specifically, the Printer is interpreting document data and
         producing another electronic representation.
      'job-queued-for-marker': Job is in any of the 'pending-held',
         'pending', or 'processing' states, but more specifically, the
         Printer has completed enough processing of the document to be
         able to start marking and the job is waiting for the marker.
         Systems that require human intervention to release jobs using
         the Release-Job operation, put the job into the 'pending-held'
         job state.  Systems that automatically select a job to use the
         marker put the job into the  'pending' job state or keep the
         job in the 'processing' job state while waiting for the marker,
         depending on implementation.  All implementations put the job
         into (or back into) the 'processing' state when marking does
         begin.
      'job-printing':  The output device is marking media. This value is
         useful for Printers which spend a great deal of time processing
         (1) when no marking is happening and then want to show that
         marking is now happening or (2) when the job is in the process
         of being canceled or aborted while the job remains in the
         'processing' state, but the marking has not yet stopped so that
         impression or sheet counts are still increasing for the job.
ToP   noToC   RFC2911 - Page 116
      'job-canceled-by-user':  The job was canceled by the owner of the
         job using the Cancel-Job request, i.e., by a user whose
         authenticated identity is the same as the value of the
         originating user that created the Job object, or by some other
         authorized end-user, such as a member of the job owner's
         security group.  This value SHOULD be supported.
      'job-canceled-by-operator':  The job was canceled by the operator
         using the Cancel-Job request, i.e., by a user who has been
         authenticated as having operator privileges (whether local or
         remote).  If the security policy is to allow anyone to cancel
         anyone's job, then this value may be used when the job is
         canceled by other than the owner of the job.  For such a
         security policy, in effect, everyone is an operator as far as
         canceling jobs with IPP is concerned.  This value SHOULD be
         supported if the implementation permits canceling by other than
         the owner of the job.
      'job-canceled-at-device':  The job was canceled by an unidentified
         local user, i.e., a user at a console at the device.  This
         value SHOULD be supported if the implementation supports
         canceling jobs at the console.
      'aborted-by-system':  The job (1) is in the process of being
         aborted, (2) has been aborted by the system and placed in the
         'aborted' state, or (3) has been aborted by the system and
         placed in the 'pending-held' state, so that a user or operator
         can manually try the job again.  This value SHOULD be
         supported.
      'unsupported-compression': The job was aborted by the system
         because the Printer determined while attempting to decompress
         the document-data's that the compression is actually not among
         those supported by the Printer.  This value MUST be supported,
         since "compressions is a REQUIRED operation attribute.
      'compression-error': The job was aborted by the system because the
         Printer encountered an error in the document-data while
         decompressing it.  If the Printer posts this reason, the
         document-data has already passed any tests that would have led
         to the 'unsupported-compression' job-state-reason.
      'unsupported-document-format': The job was aborted by the system
         because the document-data's document-format is not among those
         supported by the Printer.  If the client specifies the
         document-format as 'application/octet-stream', the printer MAY
         abort the job and post this reason even though the format is a
         member of the "document-format-supported" printer attribute,
         but not among the auto-sensed document-formats.  This value
         MUST be supported, since "document-format" is a REQUIRED
         operation attribute.
ToP   noToC   RFC2911 - Page 117
      'document-format-error': The job was aborted by the system because
         the Printer encountered an error in the document-data while
         processing it.  If the Printer posts this reason, the
         document-data has already passed any tests that would have led
         to the 'unsupported-document-format' job-state-reason.
      'processing-to-stop-point':  The requester has issued a Cancel-Job
         operation or the Printer object has aborted the job, but is
         still performing some actions on the job until a specified stop
         point occurs or job termination/cleanup is completed.

         If the implementation requires some measurable time to cancel
         the job in the 'processing' or 'processing-stopped' job states,
         the IPP object MUST use this value to indicate that the Printer
         object is still performing some actions on the job while the
         job remains in the 'processing' or 'processing-stopped' state.
         After all the job's job description attributes have stopped
         incrementing, the Printer object moves the job from the
         'processing' state to the 'canceled' or
         'aborted' job states.

      'service-off-line':  The Printer is off-line and accepting no
         jobs.  All 'pending' jobs are put into the 'pending-held'
         state.  This situation could be true if the service's or
         document transform's input is impaired or broken.
      'job-completed-successfully':  The job completed successfully.
         This value SHOULD be supported.
      'job-completed-with-warnings':  The job completed with warnings.
         This value SHOULD be supported if the implementation detects
         warnings.
      'job-completed-with-errors':  The job completed with errors (and
         possibly warnings too).  This value SHOULD be supported if the
         implementation detects errors.
      'job-restartable' - This job is retained (see section 4.3.7.2) and
         is currently able to be restarted using the Restart-Job
         operation (see section 3.3.7).  If 'job-restartable' is a value
         of the job's 'job-state-reasons' attribute, then the IPP object
         MUST accept a Restart-Job operation for that job.  This value
         SHOULD be supported if the Restart-Job operation is supported.
      'queued-in-device': The job has been forwarded to a device or
         print system that is unable to send back status.  The Printer
         sets the job's "job-state " attribute to 'completed'  and adds
         the 'queued-in-device' value to the job's "job-state-reasons"
         attribute to indicate that the Printer has no additional
         information about the job and never will have any better
         information.  See section 4.3.7.1.
ToP   noToC   RFC2911 - Page 118

4.3.9 job-state-message (text(MAX))

This attribute specifies information about the "job-state" and "job- state-reasons" attributes in human readable text. If the Printer object supports this attribute, the Printer object MUST be able to generate this message in any of the natural languages identified by the Printer's "generated-natural-language-supported" attribute (see the "attributes-natural-language" operation attribute specified in Section 3.1.4.1). The value SHOULD NOT contain additional information not contained in the values of the "job-state" and "job-states-reasons" attributes, such as interpreter error information. Otherwise, application programs might attempt to parse the (localized text). For such additional information such as interpreter errors for application program consumption or specific document access errors, new attributes with keyword values, needs to be developed and registered.

4.3.10 job-detailed-status-messages (1setOf text(MAX))

This attribute specifies additional detailed and technical information about the job. The Printer NEED NOT localize the message(s), since they are intended for use by the system administrator or other experienced technical persons. Localization might obscure the technical meaning of such messages. Clients MUST NOT attempt to parse the value of this attribute. See "job- document-access-errors" (section 4.3.11) for additional errors that a program can process.

4.3.11 job-document-access-errors (1setOf text(MAX))

This attribute provides additional information about each document access error for this job encountered by the Printer after it returned a response to the Print-URI or Send-URI operation and subsequently attempted to access document(s) supplied in the Print- URI or Send-URI operation. For errors in the protocol that is identified by the URI scheme in the "document-uri" operation attribute, such as 'http:' or 'ftp:', the error code is returned in parentheses, followed by the URI. For example: (404) http://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11.pdf Most Internet protocols use decimal error codes (unlike IPP), so the ASCII error code representation is in decimal.


(next page on part 6)

Next Section