RFC 2911
Internet Printing Protocol/1.1: Model and Semantics
Pages: 224
Obsoletes: 2566
Obsoleted by: 8011
Updated by: 3380 3382 3996 3995 7472
Obsoletes: 2566
Obsoleted by: 8011
Updated by: 3380 3382 3996 3995 7472
Part 5 of 9 – Pages 91 to 118
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.
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
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))) |
+-------------------+----------------------+----------------------+
| 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
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
'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
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.
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.
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.
'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.
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.
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:
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.
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
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
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 | |
+----------------------------+----------------------+--------------+ | 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".
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
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.
'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
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 ---+
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
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.
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.
'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.
'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.
'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.
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)