The changes are the ones indicated in the change paper posted 2/4 to make
validation of collections simpler. At the IETF December meeting, in
consultation with the Application Area Directors, IPP extensions dealing
with production printing, such as this one, were agreed not to be IETF
standards track documents. Instead, it is intended to be a PWG-DRAFT. It
also contains the updated IEEE-ISTO copyrights that we agreed to at the New
Orleans PWG meeting. I tried to insert the PWG logo, but I didn't have the
tools for handling a JPEG drawing in WORD. Could we also make another form
that most WORD (.rtf) and Acrobat Distillers can deal with?
The 2/16 telecon (1-3 EST/10-12 PST) has the Production Printing Document on
the agenda for review.
The files are at:
Here is the 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 issues are all resolved.
Here is the Change History:
The following changes were made to the January 30, 2000 version to create
the February 7, 2000 version:
1. Changed the attribute syntax of "cover-front-supported" and
"cover-back-supported" from 'collection' to 'boolean', since a Printer MUST
support all (both) member attributes and any combinations of values.
2. Changed the 'sheet' member attribute in each of the following
collections to give them distinct names so that the "xxx-supported" Printer
attribute can indicate their respective (potentially different) values:
"job-accounting-sheets", "job-error-sheets", "job-sheets", and
3. Added "media-" to the beginning of each member attribute of the
"media" collection, so that ordinary "media-xxx-supported" could be used to
represent their individual supported values.
4. Removed the 'name(MAX)" choice from the "media-size" member
attribute. If the properties of a medium are being given, either the
keyword name or the exact numerical dimensions known to the implementation,
not a name made up by the administrator.
5. Added "media-size-supported (1setOf collection) which contains the
combinations of numerical sizes supported (x-dimension and y-dimension) by
the Printer. This "xxx-supported" attribute is the only one that has a
value of '1setOf collection' in order to list the pairs of x and y
dimensions supported. The attribute syntax of the "x-dimension" and
"y-dimension" is a choice of 'integer(0:MAX)' or 'rangeOfInteger(0:MAX)' to
cover the case of continuous media and cut sheet printers that can cut the
medium to any size within the specified range.
6. Changed the "media-supported" from containing a collection whose
member attributes listed the supported values that the client could supply
as member attributes to just containing a new out-of-band 'any-collection'
value that indicates that the implementation allows any combination of
member attributes that are indicated by the corresponding "xxx-supported"
The only remaining issue is:
ISSUE 01 - Should we change the name from "collate-sheets" to
"uncollated-sheets", since the absence of the attribute (and non-support of
this attribute) is more likely to indicate collated sheets and so should be
the 'false' value of the attribute, rather than the 'true' value?