Revisions show suggested changes from:
ftp://ftp.pwg.org/pub/pwg/ipp/new_PPE/ipp-prodPrintingExt-issues-000203.pdf
and improved PWG-DRAFT template
IEEE-ISTO Printer Working Group (PWG) 1 ISSUES are highlight like this Kirk Ocke
PWG-DRAFT Tom Hastings
Xerox Corporation
February 7, 2000
Internet Printing Protocol: Production Printing Attributes - Set1
Status of this Memo
This document is a draft of an IEEE-ISTO PWG Proposed Standard and is in full conformance with all provisions of the PWG Process (see http://www.pwg.org/chair/pwg-process-990825.pdf). PWG Proposed Standards are working documents of the IEEE-ISTO PWG and its working groups.
The list of current PWG drafts can be obtained at http://www.pwg.org/pub/pwg/ipp
Abstract
This document specifies an extension to the Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566] and IPP/1.1 [ipp-mod, ipp-pro]. This extension consists primarily of Job Template attributes defined for submitting print jobs to production printers. These attributes permit a user to control and/or override instructions in the document content to perform the following functions: print on document covers, insert sheets into the document, provide an accounting id, request accounting sheets, provide job sheet messages, request error sheets, provide a message to the operator, provide a job recipient name in cases that is intended to be different from the job submitter's name, control the media used for job sheets, request media by characteristic (size, weight, etc.), control collation, and shift the image. This extension also defines the "current-page-order" Job Description attribute and the 'none' out-of-band attribute value.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics (this document)
Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO]
Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
Mapping between LPD and IPP Protocols [RFC2569]
The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. A few OPTIONAL operator operations have been added to IPP/1.1.
The "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF working group's major decisions.
The "Internet Printing Protocol/1.1: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616]. It defines the encoding rules for a new Internet MIME media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs.
The "Internet Printing Protocol/1.1: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.1 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations.
Table of Contents
Table of Tables
Table 1 - Summary of Job Template Attributes 8
Introduction
This document specifies an extension to the Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566] and IPP/1.1 [ipp-mod, ipp-pro]. This extension consists primarily of Job Template attributes defined for submitting print jobs to production printers. These attributes permit a user to control and/or override instructions in the document content to perform the following functions: print on document covers, insert sheets into the document, provide an accounting id, request accounting sheets, provide job sheet messages, request error sheets, provide a message to the operator, provide a job recipient name in cases that is intended to be different from the job submitter's name, control the media used for job sheets, request media by characteristic (size, weight, etc.), control collation, and shift the image. This extension also defines the "current-page-order" Job Description attribute and the 'none' out-of-band attribute value.
Many of these functions MAY be specified in a document format (PDL). In such cases, the user MAY request that the application include these instructions as part of the document data when the document is generated, rather than in the IPP protocol at print time. However, some applications are unable to support some of the functions. Also some of these functions are not supported in some PDLs. Finally, in a production environment, the document may be generated separately from being printed, in which case the end user or the production printer operator supplies the instructions at print time, long after the document had been created.
Terminology
This section defines the following additional terms that are used throughout this document.
Conformance Terminology
Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to conformance to this specification. These terms are defined in [ipp-mod section 13.1 on conformance terminology, most of which is taken from RFC 2119 [RFC2119]. Since support of this entire IPP extension specification is OPTIONAL for conformance to IPP/1.0 or IPP/1.1 ([ipp-mod], [ipp-pro]), the terms MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL apply if and only if the extension specification in this document is implemented. Thus a feature labeled as REQUIRED in this document is not REQUIRED if implementing the basic IPP/1.1 protocol defined by [ipp-mod] and [ipp-pro].
Other terminology
document data
|
The data that represent an "original document" supplied with a Job Creation request. Typically Document Data is in the form of a PDL.
|
set
|
The sheets of either (1) one copy of an output document copy with collated sheets or (2) all the copies of a single sheet for uncollated sheets. See description in section .
|
original document
|
The document composed by a user that is eventually submitted in the for of Document Data as part of a create request.
|
original document order
|
The orders of the pages, typically reading order, as defined in the Original Document.
|
print-stream pages
|
The sequence of pages according to the definition of pages in the language used to express the document data.
|
rendered output
|
Media sheets that are delivered as part of the output of a print request, typically containing impressions.
|
Coordinate System
Some of the attribute extensions proposed in this document refer to specific edges of a sheet of printed media. For-example, specifying that a staple be placed in the upper left corner of a printed document. To resolve ambiguity the following coordinate system is used throughout this document:
The specified edge is always 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 (which may include a user) 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 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 from portrait, i.e., clockwise).
The x-axis is defined to be along the bottom edge, with positive values extending in the direction of the right edge.
The y-axis is defined to be along the left edge, with positive values extending toward the top edge.
The origin (0,0) is the bottom-left corner.
Enumeration and Ordering of print-stream pages
"A 'print-stream page' is a page according to the definition of pages in the language used to express the document data" (see section of 13.2.4 of the IPP Model and Semantics Document). The document data included in an IPP request is typically a PDL representation of a document composed by a user. For the remainder of this description we will use the term "document data" to mean the typical PDL representation sent with an IPP request (e.g., a PostScript File), and "original document" to mean the document composed by the user (e.g., a Word97 document).
The order of the "print-stream" pages in the "document data" is either the same as the order of the "original document," known as 1-N (read "one to N"), or the reverse of that order, known as N-1. There are no assumption on the order of the "original document," other than it is ordered.
The enumeration of "print-stream" pages begins with 1 and increments by 1 for each additional "print-stream" page. The enumeration is based on the order of the "original document," not the "document data" supplied with the IPP request. In other words, if the "document data" is supplied in N-1 order (reverse of the "original document" order), then "print-stream" page number "1" in the enumeration is actually the "Nth" "print-stream" page defined in the "document data" (see "page-order-received" in section ). Similarly, "print-stream page" number "2" is defined by the "Nth-1" "print-stream page" defined in the "document data." Suppose the "document data" is supplied in the 1-N order (same as the "original document" order), then "print-stream" page number "1" in the enumeration is the "1st" "print-stream" page defined in the "document data." Similarly, "print-stream page" number "2" is defined by the "2nd" "print-stream page" defined in the "document data." The enumeration of "print-stream pages" is only relevant when applying attributes or operations that act on a page, or range of page basis (e.g., "insert-sheet" in section ).
The enumeration of print-stream pages is affected by the "multiple-document-handling" attribute. When "multiple-document-handling" is 'single-document' or 'single-document-new-sheet,' the enumeration is based on the concatenation of all the print-stream pages in the job. In the case of 'separate-documents-collated-copies' and 'separate-documents-uncollated-copies,' the enumeration of print-stream pages applies to each document. For example, for a job with 8 document, referring to "print-stream page" number "1" actually refers to "print-stream page" number "1" in each of the 8 documents included with the job.
Collection Attributes
An attribute of type 'collection' has a value that is a set of attributes, called "member" attributes. The definition for each member attribute is specified as a sub-section of the collection attribute. Each member attribute MAY in turn be single-valued or multi-valued. The Printer validates and processes each member attribute of a Job Template collection attribute in the same way that it validates an processes Job Template attributes. The collection merely serves as a "container" for the member attributes. In other words, the 'collection' attribute type serves the same purpose as the 'struct' data type does in the C programming language. See [ipp-coll] for a complete definition and encoding of the 'collection' attribute syntax.
There are three general forms of "xxx" Job Template attribute definitions that include the 'collection' attribute syntax either (1) as the attribute syntax or (2) as one of the attribute syntaxes and the corresponding "xxx-supported" Printer attribute. As with other attribute syntaxes, the Printer uses the "xxx-supported" attribute to validate Job Creation requests that contain collections and that clients can use to discover the supported possible values of collections:
1. The "xxx-supported" attribute definition is of the form: (1setOf ( ... | collection) -- In this case, the Printer can be configured to contains multiple collection values. Each collection value contains one of the possible combinations of supported values for the "xxx" collection member attributes.
2. The "xxx-supported" attribute definition is only a 'boolean' -- In this case, the Printer is indicating whether or not the "xxx" attribute is supported.
3. The "xxx-supported" attribute definition is of the form: (1setOf ( ... | any-collection), where 'any-collection' is an out-of-band value -- In this case, the Printer will accept any combination of "xxx" member attribute values for which its "yyy" collection member attributes have values contained in corresponding "yyy-supported" Printer attributes.
Job Template Attributes
This section defines Job Template Attribute extensions for production printing. Table 1 summarizes the Job and Printer Job Template attributes. The "job-sheets" and "media" attributes are from IPP/1.1 [ipp-mod] with the addition of the 'collection' attribute syntax (indicated by * flag).
Table 1 - Summary of Job Template Attributes
Job Attribute
|
Printer: Default Value Attribute
|
Printer: Supported Values Attribute
|
cover-back (collection)
|
cover-back-default (collection)
|
cover-back-supported (boolean)
|
cover-front (collection)
|
cover-front-default (collection)
|
cover-front-supported (boolean)
|
insert-sheet (collection)
|
No
|
insert-sheet-supported (boolean)
|
job-account-id(name(MAX))
|
job-account-id-default (name(MAX))
|
job-account-id-supported (boolean)
|
job-accounting-sheets (type3 keyword | name(MAX) | collection)
|
job-accounting-sheets-default (type3 keyword | name(MAX) | collection)
|
job-accounting-sheets-supported (1setOf (type3 keyword | name(MAX) | any-collection))
|
job-error-sheets (type3 keyword | name(MAX) | collection)
|
job-error-sheets-default (type3 keyword | name(MAX) | collection )
|
job-error-sheets-supported (1setOf (type3 keyword | name(MAX) | any-collection))
|
job-message-to-operator (text(MAX))
|
job-message-to-operator-default (text(MAX))
|
job-message-to-operator-supported (boolean)
|
job-recipient-name (name(MAX))
|
job-recipient-name-default (name(MAX))
|
job-recipient-name-supported (boolean)
|
job-sheets (type3 keyword | name(MAX) | collection) *
|
job-sheets-default (type3 keyword | name(MAX) | collection)
|
job-sheets-supported (1setOf (type3 keyword | name(MAX) | collection))
|
job-sheet-message (text(MAX))
|
job-sheet-message-default (text(MAX))
|
job-sheet-message-supported (boolean)
|
media (type3 keyword | name(MAX) | collection) *
|
media-default (type3 keyword | name(MAX) | collection)
|
media-supported (1setOf (type3 keyword | name(MAX) | any-collection))
|
page-delivery (type2 keyword)
|
page-delivery-default (type2 keyword)
|
page-delivery-supported (1setOf type2 keyword)
|
page-order-received (type2 keyword)
|
page-order-received-default (type2 keyword)
|
page-order-received-supported (1setOf type2 keyword)
|
separator-sheets (type3 keyword | name(MAX) | collection)
|
separator-sheets-default (type3 keyword | name(MAX) | collection)
|
separator-sheets-supported (1setOf (type3 keyword | name(MAX) | any-collection))
|
sheet-collate (boolean)
|
sheet-collate-default (boolean)
|
sheet-collate-supported (1setOf boolean)
|
x-image-auto-center (boolean)
|
x-image-auto-center-default (boolean)
|
x-image-auto-center-supported (boolean)
|
x-image-shift (integer (MIN:MAX))
|
x-image-shift-default (integer (MIN:MAX))
|
x-image-shift-supported (rangeOfInteger (MIN:MAX))
|
x-side1-image-shift (integer (MIN:MAX))
|
x-side1-image-shift-default (integer (MIN:MAX))
|
x-side1-image-shift-supported (rangeOfInteger
(MIN,MAX))
|
x-side2-image-shift (integer (MIN:MAX))
|
x-side2-image-shift-default (integer (MIN:MAX))
|
x-side2-image-shift-supported (rangeOfInteger
(MIN,MAX))
|
y-image-auto-center (boolean)
|
y-image-auto-center-default (boolean)
|
y-image-auto-center-supported (boolean)
|
y-image-shift (integer (MIN:MAX))
|
y-image-shift-default (integer (MIN:MAX))
|
y-image-shift-supported (rangeOfInteger (MIN:MAX))
|
y-side1-image-shift (integer (MIN:MAX))
|
y-side1-image-shift-default (integer (MIN:MAX))
|
y-side1-image-shift-supported (rangeOfInteger
(MIN,MAX))
|
y-side2-image-shift (integer (MIN:MAX))
|
y-side2-image-shift-default (integer (MIN:MAX))
|
y-side2-image-shift-supported (rangeOfInteger
(MIN,MAX))
|
cover-front (collection) and cover-back (collection)
These two attributes specify how covers are to be applied to each copy of each printed document within a job. For jobs with multiple documents, the "multiple-document-handling" attribute determines what constitutes a document copy for the purposes of applying cover sheets (see the end of section for more details on the interaction with the "multiple-document-handling" attribute). Presence of the "cover-front" attribute indicates that a front cover is requested, and similarly, the presence of the "cover-back" attribute indicates that a back cover is requested. Each of the "cover-front" and "cover-back" attributes includes where printing should be applied on the cover (if any), and what media should be used for the cover.
Both the "cover-front" and "cover-back" attributes are defined by the following collection:
Attribute name
|
attribute syntax
|
request
|
Printer Support
|
media
|
type3 keyword | name(MAX) | collection
|
MAY
|
MUST
|
printed-sides
|
type2 keyword
|
MUST
|
MUST
|
media (type3 keyword | name(MAX) | collection)
The "media" member attribute is used to indicate what media MUST be used for the specified cover, and has the same semantics as the normal "media" attribute (see section ). If the "media" attribute is omitted, then the media currently being used by the printer object SHOULD also be used for the cover.
printed-sides (type2 keyword)
The "printed-sides" member attribute indicates which sides of the cover MUST contain print-stream pages. The print-stream pages used for printing on a cover come from the document data.
Standard keyword values for "printed-sides" are:
'none'
|
No printing on either side of the cover.
|
'front'
|
The front side (side one) of the cover MUST contain a print-stream page.
For a front cover ("cover-front") the first print-stream page MUST be placed on side one of the front cover sheet (this is the outside of the front cover). The Printer MUST place the second print stream page on side one of the first sheet of the output document.
For back cover ("cover-back") the last print-stream page MUST be placed on side one of the back cover sheet (this is the inside of the back cover). The Printer MUST place the second to last print stream page on the front or back side of the last sheet of the output document depending on whether there are an odd or an even number of print stream pages.
|
'back'
|
The back side (side two) of the cover MUST contain a print-stream page.
For a front cover ("cover-front") the first print-stream page MUST be placed on side two of the front cover sheet (this is the inside of the front cover). The Printer MUST place the second print stream page on side one of the first sheet of the output document.
For a back cover ("cover-back") the last print-stream page MUST be placed on side two of the back cover sheet (this is the outside of the back cover). The Printer MUST place the second to last print stream page on the front or back side of the last sheet of the output document depending on whether there are an odd or an even number of print stream pages.
|
'both'
|
Both the front and back sides of the cover MUST contain a print-stream page.
The front cover MUST contain the first and second print-stream pages on the front and back sides of the front cover sheet, respectively. The Printer MUST place the third print stream page on side one of the first sheet of the output document.
The back cover MUST contain the second to last and last print-stream pages on the front and back sides of the back cover sheet, respectively. The Printer MUST place the third to last print stream page on the front or back side of the last sheet of the output document depending on whether there are an odd or an even number of print stream pages.
|
When printing on the back side (side two) of a cover, the value of the "sides" attribute SHOULD be used to determine which edge is the reference edge (i.e., long or short edge). In the case where the "sides" attribute is 'one-sided,' then the reference edge SHOULD be the long edge.
NOTE: If referencing the "sides" attribute is insufficient for determining the reference edge printing on the back side of a cover, then an additional member attribute could be defined that indicates which edge to reference. However, the predominate use cases are covered without this additional member attribute.
In cases where the document data does not contain enough print-stream pages to satisfy the "cover-front" or "cover-back" request, the behavior is implementation dependent.
The sheets in the rendered output that represent the covers are treated like any other sheet in the document copy. For example, if the "finishings" attribute has a value of 'staple,' then the staple would bind the covers, along with all of the other sheets in the output.
Both the "cover-front" and "cover-back" attributes are affected by the "multiple-document-handling" attribute. In the case of the 'single-document' and 'single-document-new-sheet' values, the covers MUST be applied to each copy of the composite (single) document. When the value is either 'separate-documents-collated-copies' or 'separate-documents-uncollated-copies', then the covers MUST be applied to each document copy individually.
out-of-band value 'none'
A client MAY use the out-of-band value 'none' for either the "cover-front" or "cover-back" attributes. If the out-of-band value 'none' is used in a create request, then the printer object MUST NOT apply the attribute to the job, including the "cover-front-default" and "cover-back-default" attributes. If a printer supports either the "cover-front" or "cover-back" attributes, it MUST also support the "out-of-band" value 'none,' including as a value for the associated default attributes, namely, "cover-front-default" and "cover-back-default."
cover-front-supported (boolean), cover-back-supported (boolean)
The "cover-front-supported" and "cover-back-supported" attributes indicate whether or not the "cover-front" and "cover-back" attributes are supported, respectively.
insert-sheet (1setOf collection)
This attribute specifies how sheets that are not to be imaged, are to be inserted into the sequence of media sheets that are produced for each copy of each printed document in the job. How the sheet is inserted is implementation dependent, and could be as sophisticated as insertion hardware, or as simple as using media from an existing input-tray.
The order of the values of the "insert-sheet" attribute is important. In the case where more than one value refers to the same page (i.e., multiple values contain the same value for the "after-page-number" member attribute), the values of "insert-sheet" are to be applied in the order that they occur.
This attribute is affected by the "multiple-document-handling" attribute. For values of 'single-document' and 'single-document-new-sheet,' the sheet is inserted in the composite (single) document created by the concatenation of all the print-stream pages in all of the documents. In the case of 'separate-documents-collated-copies' and 'separate-documents-uncollated-copies,' the inserted sheets are applied to the print-stream in each document separately. The collection consists of:
Attribute name
|
attribute syntax
|
request
|
Printer Support
|
after-page-number
|
integer (0:MAX)
|
MUST
|
MUST
|
count
|
integer (1:MAX)
|
MAY
|
MAY
|
media
|
type3 keyword | name(MAX) | collection
|
MUST
|
MUST
|
after-page-number (integer(0:MAX))
The 'after-page-number' attribute specifies the page in the print-stream after which the sheet is to be placed. The inserted sheet(s) does not affect the number of print-stream pages. For-example, to insert a single sheet after both pages 2 and 3 of a given document, the value of "after-page-number" would be 2 and 3 respectively (not 2 and 4, as it would be if the inserted sheet affected the print-stream page count). For a complete description of the enumeration of print-stream pages see section .
If the "after-page-number" member attribute is 0, then the sheet is inserted before the first page.
Since the "after-page-number" attribute refers to a specific print-stream page, it is possible to specify an insertion between sides one and two, of a two sided document, or between print-stream pages that are part of a single impression if the "number-up" attribute has a value other than '1.' In this case, the error 'client-error-conflicting-attributes' MUST be returned to the client.
If the "after-page-number" attribute is not a valid page reference in the print-stream, then the IPP Printer should ignore the request. There is no way to validate the "after-page-number" attribute with the Validate-Job operation, since the validation cannot occur until the pages of the documents have arrived at the printer.
count (integer(1:MAX))
The "count" attribute indicates how many sheets to insert. If the "count" attribute is omitted, then the printer assumes a value of 1.
media (type3 keyword | name(MAX) | collection)
The "media" attribute is used to indicate the media to be used for the "insert-sheet." This is the standard IPP/1.0 "media" attribute, with the extensions provided for in this document (see section ).
insert-sheet-default attribute is not defined
There is NO "insert-sheet-default" attribute. If the client does not supply the "insert-sheet" attribute, then there is no defined effect.
insert-sheet-supported (boolean)
The "insert-sheet-supported" attribute only indicates if the attribute is supported, and does not indicate the supported values of the member attributes. It is assumed that if the "insert-sheet" attribute is supported, then all combinations of the member attributes are supported.
job-account-id (name (MAX))
The "job-account-id" attribute is a character string representing the account associated with the job. The "job-account-id" attribute could be a customer name, a sequence of digits referencing an internal billing number, or even a credit card number. How the printer uses the "job-account-id" is implementation dependent.
out-of-band value 'none'
A client MAY use the out-of-band value 'none' with the "job-account-id" attribute. If the out-of-band value 'none' is used in a create request, then the printer object MUST NOT apply the attribute to the job, including the "job-account-id-default" attribute. If a printer implements the "job-account-id" attribute, it MUST also implement the "out-of-band" value 'none,' including as a value for the "job-account-id-default" attribute.
job-accounting-sheets (type3 keyword | name(MAX) | collection)
This attribute specifies which job accounting sheets MUST be printed with the job. Job accounting sheets typically contain information such as the value of the "job-account-id" attribute, and the number and type of media sheets used while printing the job. The exact information contained on a job accounting sheet is implementation dependent, but should always be a reflection of the account information associated with the job.
Standard keyword values for job accounting sheets are:
'none'
|
No accounting sheets are to be printed (i.e. printing of job accounting sheets is totally suppressed).
|
'standard'
|
The standard site accounting sheet MUST be printed with the job.
|
The 'collection' syntax allows a client to specify media for job accounting sheets that is different than the current media being used for the print-stream page impressions. The collection consists of:
Attribute name
|
attribute syntax
|
request
|
Printer Support
|
media
|
type3 keyword | name(MAX) | collection
|
MUST
|
MUST
|
job-accounting-sheets
|
type3 keyword | name(MAX)
|
MUST
|
MUST
|
media (type3 keyword | name(MAX) | collection)
The "media" member attribute is used to indicate the media that should be used for the job accounting sheet (see section ).
job-accounting-sheets (type3 keyword | name(MAX))
The "job-accounting-sheets" member attribute specifies which job accounting sheets to print on the specified media. The values for this member attribute are identical to the keyword and name values for the "job-accounting-sheets" attribute itself, and convey the same semantics.
job-error-sheets (type3 keyword | name(MAX) | collection)
This attribute specifies which job error sheets MUST be printed with the job. This is a printer specific sheet enumerating any known errors or warnings that occurred during processing. For example: a printer could put the text 'warning: image off page 2," on the error sheet to indicate a possible image processing defect. The printer vendor defines the content of the error sheet.
Standard keyword values for job error sheets are:
'none'
|
No error sheets are to be printed. (i.e., printing of error sheets is totally suppressed – even if errors or warnings occurred during job processing).
|
'standard'
|
The standard site or vendor defined error sheet MUST be printed with the job if and only if errors or warning occurred.
|
'always'
|
The standard or vendor defined error sheet MUST always be printed with the job. (i.e. error sheets are printed even if no errors or warnings occurred during job processing – when no errors or warnings occurred a suitable message will be printed on the sheet to indicate this). The 'always' value gives an explicit indication of whether or not there were errors detected during the processing of the job.
|
If the "job-sheets" Job Template attribute is also specified, then the printer object may choose to print any error and warning messages on that same job sheet. This use of the job sheet for error only applies if the "job-error-sheet" attribute is supplied with the 'keyword' or 'name' attribute syntax; in cases where the 'collection' attribute syntax is used, a separate error sheet MUST always be used to print errors and warnings.
The 'collection' syntax allows a client to specify media for job error sheets that is different than the current media being used for the print-stream page impressions. The collection consists of:
Attribute name
|
attribute syntax
|
request
|
Printer Support
|
media
|
type3 keyword | name(MAX) | collection
|
MUST
|
MUST
|
job-error-sheets
|
type3 keyword | name(MAX)
|
MUST
|
MUST
|
media (type3 keyword | name(MAX) | collection)
The "media" member attribute is used to indicate the media that should be used for the job error sheet (see section ).
job-error-sheets (type3 keyword | name(MAX))
The "job-error-sheets" member attribute specifies which job error sheets to print on the specified media. The values for this member attribute are identical to the keyword and name values for the "job-error-sheets" attribute itself, and convey the same semantics.
media (type3 keyword | name(MAX) | collection)
The "media" member attribute is used to indicate the media that MUST be used for the job error sheet (see section ).
sheets (type3 keyword | name(MAX))
The "sheets" member attribute specifies which job error sheets to print on the specified media. The values for this member attribute are identical to the keyword and name values for the "job-error-sheets" attribute itself, and convey the same semantics.
job-error-sheets-default (type3 keyword | name(MAX) | collection )
An implementation SHOULD be configured out-of-the-box so that the "job-error-sheet-default" Printer Attribute has the value: 'standard' or 'always' rather than 'none'. Then the Administrator and End Users have to explicitly turn off error information.
job-message-to-operator (text(MAX))
This attribute carries a message from the user to the operator to indicate something about the processing of the print job. The printer object MUST make this message available to the operator once the job has been successfully received and before the job is moved to the 'processing' state.
Note: this attribute may be used in conjunction with the IPP 1.0 "job-hold-until" Job Template attribute; specifically with the 'indefinite' value. This combination allows a client to specify instructions to the operator, while simultaneously preventing the job from being processed until some operator intervention occurs. This combination is particularly useful in production printing environments, where printer configuration may be required to properly print the job.
out-of-band value 'none'
A client MAY use the out-of-band value 'none' with the "job-message-to-operator" attribute. If the out-of-band value 'none' is used in a create request, then the printer object MUST NOT apply the attribute to the job, including the "job-message-to-operator-default" attribute. If a printer implements the "job-message-to-operator" attribute, it MUST also implement the "out-of-band" value 'none,' including as a value for the "job-message-to-operator-default" attribute.
job-message-to-operator-supported (boolean)
The "job-message-to-operator-supported" attribute indicates only whether or not the attribute is supported.
job-recipient-name (name(MAX))
This attribute contains the name of the person that is to receive the output of the job. The value of the "job-recipient-name" attribute is commonly printed on job sheets printed with the job. An example of another use of the "job-recipient-name" attribute is if the printer accesses a database to get job delivery instructions for the recipient of a job.
If the client omits this attribute in a create request, the printer MAY use the "job-recipient-name-default" attribute value, unless it has not been configured by the administrator (i.e., it is not present, or has the "out-of-band" value 'no-value'), or MAY use the "authenticated user" name (see [IPP-MOD] section 8.3).
out-of-band value 'none'
A client MAY use the out-of-band value 'none' with the "job-recipient-name" attribute. If the out-of-band value 'none' is used in a create request, then the printer object MUST NOT apply the attribute to the job, including the "job-recipient-name-default" attribute. If a printer implements the "job-recipient-name" attribute, then it MUST also implement the "out-of-band" value 'none,' including as a value for the "job-recipient-name-default" attribute.
job-recipient-name-supported (boolean)
The "job-recipient-name-supported" attribute indicates only whether or not the attribute is supported.
job-sheets (type3 keyword | name(MAX) | collection) - extension to IPP/1.1 "job-sheets"
This attribute is an extension to the IPP/1.1 [ipp-mod] "job-sheets" attribute. The two differences are that the 'collection' attribute syntax defined in this description is added as an OPTIONAL choice for the "job-sheets" attribute, and that the following additional values are defined for the "job-sheets" attribute.
The additional standard keyword values for the "job-sheets" attribute are:
job-start-sheet
|
A job sheet MUST be printed to indicate the start of the job.
|
job-end-sheet
|
A job sheet MUST be printed to indicate the end of the job.
|
job-wrap-sheets
|
Job sheets MUST be printed to indicate the start and end of all the output associated with the job.
|
The 'collection' attribute syntax stems from the need to specify media for job sheets that is different than the current media being used for the print stream images. An example of where this is useful is for separator sheets, which may allow easier distinction of document copies. The collection consists of:
Attribute name
|
attribute syntax
|
request
|
Printer Support
|
media
|
type3 keyword | name(MAX) | collection
|
MUST
|
MUST
|
job-sheets
|
type3 keyword | name(MAX)
|
MUST
|
MUST
|
media (type3 keyword | name(MAX) | collection)
The "media" member attribute is used to indicate the media that should be used for the job sheet (see section ).
job-sheets (type3 keyword | name(MAX))
The "job-sheets" member attribute specifies which job sheets to print on the specified media. The values for this member attribute are identical to the keyword and name values for the "job-sheets" attribute itself, and convey the same semantics.
media (type3 keyword | name(MAX) | collection)
The 'media' attribute is used to indicate the media that should be used for the job sheet (see section ).
sheets (type3 keyword | name(MAX))
The "sheets" member attribute specifies which job sheet to print on the specified media. The values for this member attribute are identical to the keyword and name values for the "job-sheets" attribute itself, and convey the same semantics.
job-sheet-message(text(MAX))
This attribute is used to convey a message that is delivered with the job, and may be printer on a job sheet (e.g., the 'standard' job sheet). The message may contain any type of information, but typically includes either instructions for offline processing (e.g., finishing), or a message for the job recipient.
out-of-band value 'none'
A client MAY use the out-of-band value 'none' with the "job-delivery-message" attribute. If the out-of-band value 'none' is used in a create request, then the printer object MUST NOT apply the attribute to the job, including the "job-delivery-message-default" attribute. If a printer implements the "job-delivery-message" attribute, then is MUST also implement the "out-of-band" value none, including as a value for the "job-delivery-message-default" attribute.
job-sheet-message-supported (boolean)
The "job-delivery-message-supported" attribute indicates only whether or not the attribute is supported.
media (type3 keyword | name (MAX) | collection) - extension to IPP/1.1 "media"
This attribute is an extension to the IPP/1.1 [ipp-mod] "media" attribute. The 'collection' attribute syntax is added as an OPTIONAL choice for the "media" attribute and is used to enable a client end user to submit a list of media attributes to the printer as a way to more completely specify the characteristics of the media for the printer. The 'collection' attribute syntax is:
Attribute name
|
attribute syntax
|
request
|
Printer Support
|
media-name
|
type3 keyword | name (MAX)
|
MAY
|
MAY
|
media-color
|
type3 keyword | name (MAX)
|
MAY
|
MAY
|
media-opacity
|
type3 keyword
|
MAY
|
MAY
|
media-pre-printed
|
boolean
|
MAY
|
MAY
|
media-tabs
|
type3 keyword
|
MAY
|
MAY
|
media-hole-count
|
integer
|
MAY
|
MAY
|
media-order-count
|
integer
|
MAY
|
MAY
|
media-size
|
type3 keyword | collection
|
MAY
|
MUST
|
media-weight
|
integer
|
MAY
|
MAY
|
media-weight-units
|
type3 keyword
|
MAY
|
MAY
|
media-back-coating
|
type3 keyword | name(MAX)
|
MAY
|
MAY
|
media-front-coating
|
type3 keyword | name(MAX)
|
MAY
|
MAY
|
When media is specified by characteristic using the 'collection' attribute syntax, the printer object MUST match the requested media exactly. The "media" collection member attributes definitions are:
media-name (type3 keyword | name(MAX))
The "media-name" member attribute is used to specify a media name, similar to the standard IPP/1.0 'keyword | name' attribute syntaxes of the media attribute. The difference is that the "media-name" member attribute is treated as just another characteristic of the media that the printer must match to select the correct media.
For-example, if the "media-name" member attribute is "iso-a4" and the "hole-count" member attribute is 3, then the requested media is "three hole punched A4." Since many of the standard keyword values are under specified, this allows for further refinement of the specification of the desired media.
The standard type3 keyword values for media-name are the same as those defined for the "media" attribute in IPP/1.1. Typical values include "iso-a4-white", "na-letter-colored" and so forth.
The 'name' attribute syntax for "media-name" is used to enable a client to submit a site-defined name as a reference for a specific media. This attribute syntax can be used to enable a System Administrator to extend the list of IPP media names. Examples might include "1040 Tax Form", "Acme Letter Head", "Hammermill", and "U.S. Government 3R712".
Note: some printers may require that media with different characteristics be allowed to have the same name. If a printer does allow the ambiguous case of different media with the same name, then it is implementation dependent how the resolution to a single media occurs.
media-color (type3 keyword | name (MAX))
The "media-color" attribute indicates the desired color of the media being specified.
Standard keyword values for "color" are:
'clear'
|
The specified media should have no color.
|
'white'
|
The specified media should be white.
|
'pink'
|
The specified media should be pink.
|
'yellow'
|
The specified media should be yellow.
|
'blue'
|
The specified media should be blue.
|
'green'
|
The specified media should be green.
|
'buff'
|
The specified media should be buff.
|
'goldenrod'
|
The specified media should be goldenrod.
|
'red'
|
The specified media should be red.
|
Note: The standard keyword values for the "media-color" attribute are derived primarily from the Printer MIB [RFC1759] prtInputMediaColor standard values with the addition of 'red' and 'blue and 'clear' (instead of 'transparent' - see section ).
Custom paper colors can be specified using the 'name' (MAX) attribute syntax of the color attribute.
media-opacity (type3 keyword)
The "media-opacity" attribute indicates the desired opaqueness of the media being specified.
Standard keyword values for "opacity" are:
'opaque'
|
The specified media should be opaque.
|
'transparent'
|
The specified media should be transparent.
|
media-pre-printed (boolean)
The "media-pre-printed" attribute indicates that the desired media is already imaged. Examples of pre-printed media include forms and company letterhead. If the value is 'false', the Printer MAY use an electronic representation of a form, if the medium has some imaged information already associated with it.
media-tabs (type3 keyword)
The "media-tabs" member attribute indicates that the desired media should have tabs.
Standard keyword values for "media-tabs" are:
'none'
|
There are no tabs on the desired media
|
'pre-cut'
|
The desired media has tabs, each of which extends only partially along a given edge.
|
'full-cut'
|
The desired media has tabs which along the entire length of a given edge.
|
The "media-tabs" member attribute does not imply that media is ordered in any way. Ordered media is specified only using the "order-count" member attribute (see section ). If the tabbed media is ordered, then the order MUST be indicated using the "order-count" member attribute.
media-hole-count (integer (0:MAX))
The "media-hole-count" attribute indicates the number of pre-drilled holes in the desired media. A value of 0 (zero) indicates that no holes should be present in the media.
media-order-count (integer (1:MAX))
The "media-order-count" attribute indicates the number of sheets, within an ordered sequence of sheets; after which the sequence begins to repeat. For example, third cut tab stock has an order count of 3 (this is also sometimes called the modulus of the ordered media).
If the "media-order-count" is 1, then the media is not ordered.
media-size (type3 keyword | collection)
The "media-size" member attribute can either be a named media size, or a collection that explicitly specifies the media dimensions. The standard keywords for named media sizes are defined in section 15 (Appendix C) of the IPP Model and Semantics document. Only keyword and name values that specify size alone SHOULD be used with the "media-size" member attribute. Customized names that represent media sizes can be created using the 'name' attribute syntax.
Implementers Note: The "media-name" member attribute and the "media-size" member attribute can both implicitly specify media size. The resolution of such a conflict is implementation dependent; however, clients/users SHOULD NOT request media that have such a conflict.
The "media-size" collection member attributes are:
Attribute name
|
attribute syntax
|
request
|
Printer Support
|
x-dimension
|
integer (0:MAX)
|
MUST
|
MUST
|
y-dimension
|
integer (0:MAX)
|
MUST
|
MUST
|
|
