Project of the PWG-IPP Working Group

Internet Printing Protocol (IPP): 
Production Printing Attributes – Set1

Draft D0.8
October 26, 2000
ftp://ftp.pwg.org/pub/pwg/ipp/new_PPE/pwg-ipp-prod-print-set1-001026.doc, .rtf, .pdf

Abstract

This document specifies an extension to the Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566] and IPP/1.1 [RFC2910, RFC2911].  This extension consists primarily of Job Template attributes defined for submitting print jobs primarily (but not limited to) 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, control the positioning of stapling, force pages to the front side of the media, insert sheets into the document, provide an accounting id, provide an accounting user id, request accounting sheets, provide job sheet messages, request error sheets, provide a message to the operator, control the media used for job sheets, request media by characteristic (size, weight, etc.), request to check the media characteristics in an input tray, specify the presentation direction of page images on impressions, and shift the impression image.  

This extension also defines the "current-page-order" Job Description attribute, the "user-defined-values-supported" and "max-stitching-locations-supported" Printer Description attributes, and the 'resources-are-not-supported' value for the "job-state-reasons" Job Description attribute.  Some additional "media" keyword values are defined for use with the "media" and “media-col” Job Template attribute.

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 projects and drafts can be obtained at http://www.pwg.org

Copyright (C) 2000, IEEE Industry Standards and Technology Organization. All rights reserved. 

This document may be copied and furnished to others, and derivative works that comment on, or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice, this paragraph and the title of the Document as referenced below are included on all such copies and derivative works.  However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the IEEE-ISTO and the Printer Working Group, a program of the IEEE-ISTO. 

Title:  Internet Printing Protocol (IPP): Production Printing Attributes - Set1

The IEEE-ISTO and the Printer Working Group DISCLAIM ANY AND ALL WARRANTIES, WHETHER EXPRESS OR IMPLIED INCLUDING (WITHOUT LIMITATION) ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

The Printer Working Group, a program of the IEEE-ISTO, reserves the right to make changes to the document without further notice.  The document may be updated, replaced or made obsolete by other documents at any time. 

The IEEE-ISTO takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. 

The IEEE-ISTO invites any interested party to bring to its attention any copyrights, patents, or patent applications, or other proprietary rights which may cover technology that may be required to implement the contents of this document. The IEEE-ISTO and its programs shall not be responsible for identifying patents for which a license may be required by a document and/or IEEE-ISTO Industry Group Standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. Inquiries may be submitted to the IEEE-ISTO by e-mail at: 

ieee-isto@ieee.org.

The Printer Working Group acknowledges that the IEEE-ISTO (acting itself or through its designees) is, and shall at all times, be the sole entity that may authorize the use of certification marks, trademarks, or other special designations to indicate compliance with these materials. 

Use of this document is wholly voluntary.  The existence of this document does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to its scope. 

Table of Contents

1.	Introduction
2.	Terminology
2.1	Conformance Terminology
2.2	Other terminology
2.3	Coordinate System
2.4	Enumeration and Ordering of print-stream pages
2.5	Collection Attributes
2.6	Definition of 'none' values
3.	Job Template Attributes
3.1	cover-front (collection) and cover-back (collection)
3.1.1	media (type3 keyword | name(MAX)) or media-col (collection)
3.1.2	cover-type (type2 keyword)
3.1.3	cover-front-default (collection) and cover-back-default (collection)
3.1.4	cover-front-supported (1setOf type2 keyword), cover-back-supported (1setOf type2 keyword)
3.2	finishings-col (collection) - augments IPP "finishings"
3.2.1	finishing-template (name(MAX))
3.2.2	stitching (collection)
3.2.3	finishings-col-default (collection)
3.2.4	finishings-col-ready (1setOf collection)
3.2.5	finishings-col-supported (1setOf type2 keyword)
3.3	force-front-side (1setOf integer(1:MAX))
3.4	insert-sheet (1setOf collection)
3.4.1	insert-after-page-number (integer(0:MAX))
3.4.2	insert-count (integer(0:MAX))
3.4.3	media (type3 keyword | name(MAX)) or media-col (collection)
3.4.4	insert-sheet-default (1setOf collection)
3.4.5	insert-sheet-supported (1setOf type2 keyword)
3.5	job-account-id (name(MAX))
3.6	job-accounting-user-id (name(MAX))
3.7	job-accounting-sheets (collection)
3.7.1	job-accounting-sheets-type (type3 keyword | name(MAX))
3.7.2	media (type3 keyword | name(MAX)) or media-col (collection)
3.7.3	job-accounting-output-bin (type3 keyword | name(MAX))
3.7.4	job-accounting-sheets-default (collection)
3.7.5	job-accounting-sheets-supported (1setOf type2 keyword)
3.8	job-error-sheet (collection)
3.8.1	job-error-sheet-type (type3 keyword | name(MAX))
3.8.2	job-error-sheet-when (type2 keyword)
3.8.3	media (type3 keyword | name(MAX)) or media-col (collection)
3.8.4	job-error-sheet-default (collection )
3.8.5	job-error-sheet-supported (1setOf type2 keyword)
3.9	job-message-to-operator (text(MAX))
3.10	job-sheets-col (collection) - augments  IPP "job-sheets" attribute
3.10.1	job-sheets (type3 keyword | name(MAX))
3.10.2	media (type3 keyword | name(MAX)) or media-col (collection)
3.10.3	job-sheets-col-default (collection)
3.10.4	job-sheets-col-supported (1setOf type2 keyword)
3.11	job-sheet-message (text(MAX))
3.12	media-col (collection) - augments IPP "media"
3.12.1	media-key (type3 keyword | name(MAX))
3.12.2	media-type (type3 keyword | name(MAX))
3.12.3	media-info (text(255))
3.12.4	media-color (type3 keyword | name(MAX))
3.12.5	media-pre-printed (type3 keyword | name(MAX))
3.12.6	media-hole-count (integer(0:MAX))
3.12.7	media-order-count (integer(1:MAX))
3.12.8	media-size (collection)
3.12.9	media-weight-metric (integer(0:MAX))
3.12.10	media-front-coating (type3 keyword | name(MAX)) and media-back-coating (type3 keyword | name(MAX))
3.12.11	media-recycled (type3 keyword | name(MAX))
3.12.12	media-default (type3 keyword | name(MAX)) and media-col-default (collection)
3.12.13	media-ready (1setOf (type3 keyword | name(MAX))) and media-col-ready (1setOf collection)
3.12.14	media-col-supported (1setOf type2 keyword)
3.13	media-input-tray-check (type3 keyword | name(MAX))
3.14	page-delivery (type2 keyword)
3.14.1	Interaction with the "page-order-received" attribute
3.15	page-order-received (type2 keyword)
3.16	presentation-direction (type2 keyword)
3.17	separator-sheets (collection)
3.17.1	separator-sheet-type (type3 keyword | name(MAX))
3.17.2	media (type3 keyword | name(MAX)) or media-col (collection)
3.17.3	separator-sheets-default (collection)
3.17.4	separator-sheets-supported (1setOf type2 keyword)
3.18	Impression Image Shifting Attributes
3.18.1	x-image-position (type2 keyword)
3.18.2	x-image-shift (integer(MIN:MAX))
3.18.3	x-side1-image-shift (integer(MIN:MAX))
3.18.4	x-side2-image-shift (integer(MIN:MAX))
3.18.5	y-image-position (type2 keyword)
3.18.6	y-image-shift (integer(MIN:MAX))
3.18.7	y-side1-image-shift (integer(MIN:MAX))
3.18.8	y-side2-image-shift (integer(MIN:MAX))
3.19	Usage in Document-Overrides and Page-Overrides
4.	Job Description Attributes
4.1	current-page-order (type2 keyword)
5.	Printer Description Attributes
5.1	user-defined-values-supported (1setOf type2 keyword)
5.2	max-stitching-locations-supported (integer(1:MAX))
5.3	finishings-ready (1setOf type2 enum)
6.	Additional Values for Existing Attributes
6.1	Additional values for the "job-state-reasons" Job attribute
6.2	Additional values for the IPP "job-sheets" Job Template Attribute
6.3	Additional values for the IPP "media" Job Template and "media-key" member attributes
7.	Conformance Requirements
7.1	Conformance Requirements for Printer objects
7.2	Conformance Requirements for clients
8.	IANA Considerations
9.	Internationalization Considerations
10.	Security Considerations
11.	References
12.	Author's Addresses
13.	Appendix A: Change History
13.1	Changes to the June 5, 2000 to create the October 26, 2000 version
13.2	Changes to the May 9, 2000  to create the June 5, 2000 version
13.3	Changes to the April 26, 2000  to create the May 9, 2000 version
13.4	Changes to the April 11, 2000  to create the April 26, 2000 version
13.5	Changes to the February 7, 2000  to create the April 11, 2000 version
13.6	Changes to the January 30, 2000 to create the February 7, 2000 version
13.7	Changes to the January 28, 2000 to create the January 30, 2000 version
13.8	Changes to create the January 28, 2000 version
14.	Appendix B: Summary of other IPP documents
15.	Appendix C: Description of the IEEE Industry Standards and Technology (ISTO)
16.	Appendix D: Description of the IEEE-ISTO PWG

Table of Tables

Table 1 - Summary of Job Template Attributes
Table 2 - "cover-front" and "cover-back" member attributes
Table 3 - The "finishings-col" member attributes
Table 4 - The "stitching" member attributes
Table 5 - The "finishings-col-ready" member attributes
Table 6 - "insert-sheet" member attributes
Table 7 - "job-accounting-sheets" member attributes
Table 8 - "job-error-sheet" member attributes
Table 9 - "job-sheets-col" member attributes
Table 10 - "media-col" member attributes
Table 11 - "media-size" member attributes
Table 12 - "media-size-supported" member attributes
Table 13 - Standard Values for the “presentation direction” Attribute
Table 14 - "separator-sheets" member attributes
Table 15 - Job Template Attribute Override Semantics
Table 16 - Document and Page Override Semantics by Attribute
Table 17 - Additional values for the "job-sheets" Job Template attribute

Table of Figures

Figure 1 - General Finishing Coordinate System

1.	Introduction

This document specifies an extension to the Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566] and IPP/1.1 [RFC2910, RFC2911].  This extension consists primarily of OPTIONAL Job Template attributes defined for submitting print jobs primarily (but not limited to) 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, control the positioning of stapling, force pages to the front side of the media, insert sheets into the document, provide an accounting id, provide an accounting user id, request accounting sheets, provide job sheet messages, request error sheets, provide a message to the operator, control the media used for job sheets, request media by characteristic (size, weight, etc.), request to check the media characteristics in an input tray, specify the presentation direction of page images on impressions, and shift the impression image.  All of these Job Template attributes are OPTIONAL for a Printer to support.  However, some of these Job Template attributes do require other Job Template attributes in this document to be supported.  See the Conformance section (section 7.1).

This extension document also defines the "current-page-order" Job Description attribute, the "user-defined-values-supported" and "max-stitching-locations-supported" Printer Description attributes, and the 'resources-are-not-supported' value for the "job-state-reasons" Job Description attribute.

Some additional "media" keyword values are defined for use with the "media" and “media-col” Job Template attribute.

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.

2.	Terminology

This section defines the following additional terms that are used throughout this document.

2.1	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 [RFC2911 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 ([RFC2566], [RFC2565]) or IPP/1.1 ([RFC2911], [RFC2910]), 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 [RFC2911] and [RFC2910].
2.2	Other terminology

collection	An attribute syntax consisting of a set of attributes.  Such a collection attribute has a value that is a set of attributes, similar to a Java Map or a PostScript dictionary.  See [ipp-coll].	
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.	
Input-Document	The sequence of input pages that the client sends as document data to the IPP Printer (see [ipp-override]).	
Insert-Sheet	A media sheet that the Printer inserts into an Output-Document, on which no Input-Pages are imaged.	
Job Creation operation	An operation that creates a Job, i.e., Create-Job, Print-Job, and Print-URI, but not Validate-Job.  If Validate-Job is intended as well, then it is explicitly mentioned.	
original document	The document composed by a user that is eventually submitted in the form of Document Data as part of a Job Creation request.	
original document order	The orders of the pages, typically reading order, as defined in the Original Document.	
Output-Document 	The sequence of output pages that the Printer renders onto output media (see [ipp-override]).	
print-stream pages	The sequence of pages according to the definition of pages in the language used to express the document data defined relative to the Input Document.	
rendered output	Media sheets that are delivered as part of the output of a print request, typically containing impressions.	
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 3.17.1.	

2.3	Coordinate System

Some of the attribute extensions proposed in this document refer to specific edges of a sheet of printed media.  Specifying that a staple be placed in the upper left corner of a printed document is an example.  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.

2.4	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 the term original document to mean the document composed by the user (e.g., a Word97 document).  The print-stream page numbering is with respect to the Input-Document, not the Output-Document (see [ipp-override]).  Furthermore, the page numbers are ordinal numbers starting at 1 and are independent of the page numbers that may be printed on the pages.

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 assumptions 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 N th print-stream page defined in the document data  (see the "page-order-received" attribute in section 3.15).  Similarly, print-stream page number '2' is defined by the (N-1) th 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 1 st print-stream page defined in the document data.  Similarly, print-stream page number '2' is defined by the 2 nd 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., the "insert-sheet" attribute in section 3.4).

The enumeration of print-stream pages is affected by the "multiple-document-handling" attribute.  When the "multiple-document-handling" attribute 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 eight documents, referring to print-stream page number '1' actually refers to print-stream page number '1' in each of the eight documents included with the job.

The enumeration of print-stream pages is NOT affected by the "page-ranges" Job Template attribute, if supplied.  The "page-ranges" attribute merely affects which Input-Document pages are actually printed.  For example, if an insert sheet is to be inserted after print-stream page number is 5 of a 10-page document, the insert page will be inserted after page 5 with respect to the Input-Document as long as page 5 is included in the "page-ranges" attribute.  If the "page-ranges" attribute does not include Input-Document page 5, then the insert sheet will not be inserted.  Thus a user can supply the "page-ranges" attribute without having to change any other attributes in order to print a part of a document.

2.5	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 definition.  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 and 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 'map' data type in the Java programming language and the dictionary mechanism in PostScript.  See [ipp-coll] for a complete definition and encoding of the 'collection' attribute syntax with examples.

2.6	Definition of 'none' values

For most Job Template attributes, the client needs a way to indicate that the Printer MUST NOT perform the feature associated with the attribute, including not performing the default action indicated by the Printer's "xxx-default" attribute.  If the client omits the "xxx" Job Template attribute, a corresponding value is used from the PDL data, if present.  Otherwise, the Printer's "xxx-default" attribute value is used.  

For each attribute definition, the representation of none is specified or is explicitly disallowed.  For string attribute syntax types, such as 'text', 'name', 'uri', 'uriScheme', 'charset', 'naturalLanguage', 'mimeMediaType', and 'octetString', the client supplies a zero-length value to indicate an explicit none.  For 'enum', 'keyword', or 'keyword | name' a specific 'none' enum or keyword value is defined.  For 'integer' or 'rangeOfInteger' values, a particular distinguished value, such as 0 or -1' is defined to mean none.  The client can supply the defined none value in order to override a Printer's "xxx-default" value.  The Printer MUST return the 'no-value' out-of-band value for Printer Description attributes that have 'dateTime' or 'integer' time values that do not yet have a value (see [RFC2911] sections 4.3.14 and 4.4.30).

Similarly, for the corresponding Printer's "xxx-default", the Printer MUST use the same none value to indicate that there is no default value that will be applied.  Thus the defined values for the "xxx-default" attribute are the same as those that a client can supply, including the none case.  Consequently, no special mention is made of the none case in each "xxx-default" attribute definition.  However, a Printer implementation MUST support the defined none value for each Job Template attribute in job submission, as a value of the "xxx-default" Printer attribute, and as one of the values of the "xxx-supported" Printer attribute, if the Printer supports the "xxx" Job Template attribute.  Also the administrator SHOULD be able to remove the 'none' value from the list of supported values if the site policy is to disallow the none case.  See [ipp-set-ops] for means to set the values of the "xxx-supported" and "xxx-default" Printer attributes using the Set-Printer-Attributes operation.

There are a few Job Template attributes for which there is no none value defined, because of the inherent nature of the semantics associated with the attribute the Printer always supplies some value.  Examples of such attributes (see [RFC2911]) are: "media" (type3 keyword | name) and "sides" (keyword).  There is no 'none' keyword value defined for use with the media and a zero-length string will not match any supported values.  Similarly, there is no 'none' keyword value defined for the "sides" attribute.  All jobs that print use some media instance and either print on one side or on both sides.  Thus this kind of attribute does not have a defined none value.  Because some attributes do not have none values defined, while most do, the definition document MUST specify the distinguished none value in each attribute definition or explicitly state that there is no distinguished none value.  

3.	Job Template Attributes

This section defines Job Template Attribute extensions for production printing.  Table 1 summarizes the Job and Printer Job Template attributes.  
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 (1setOf type2 keyword)	
cover-front (collection)	cover-front-default (collection)	cover-front-supported (1setOf type2 keyword)	
finishings-col (collection)	finishings-col-default (collection)	finishings-col-supported (1setOf type2 keyword)
finishings-col-ready (1setOf collection)	
force-front-side (1setOf integer(1:MAX))	force-front-side-default (1setOf integer(1:MAX))	force-front-side-supported (rangeOfInteger(1:MAX))	
insert-sheet (collection)	insert-sheet-default (collection)	insert-sheet-supported (1setOf type2 keyword)	
job-account-id (name(MAX))	job-account-id-default (name(MAX))	job-account-id-supported (boolean)	
job-accounting-user-id (name(MAX))	job-accounting-user-id-default (name(MAX))	job-accounting-user-id-supported (boolean)	
job-accounting-sheets (collection)	job-accounting-sheets-default (collection)	job-accounting-sheets-supported (1setOf type2 keyword)	
job-error-sheet (collection)	job-error-sheet-default (collection)	job-error-sheet-supported (1setOf type2 keyword)	
job-message-to-operator (text(MAX))	job-message-to-operator-default (text(MAX))	job-message-to-operator-supported (boolean)	
job-sheets-col (collection)	job-sheets-col-default (collection)	job-sheets-col-supported (1setOf type2 keyword)	
job-sheet-message  (text(MAX))	job-sheet-message-default (text(MAX))	job-sheet-message-supported (boolean)	
media-col (collection)	media-col-default (collection)	media-col-supported (1setOf type2 keyword)
media-col-ready (1setOf collection)	
media-input-tray-check (type3 keyword | name(MAX))	media-input-tray-check-default (type3 keyword | name(MAX))	media-input-tray-check-supported (1setOf (type3 keyword | name(MAX)))	
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)	
presentation-direction (type2 keyword)	presentation-direction-default (type2 keyword)	presentation-direction-supported (1setOf type2 keyword)	
separator-sheets (collection)	separator-sheets-default (collection)	separator-sheets-supported (1setOf type2 keyword)	
x-image-position (type2 keyword)	x-image-position-default (type2 keyword)	x-image-position-supported (1setOf type2 keyword)	
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-position (type2 keyword)	y-image-position-default (type2 keyword)	y-image-position-supported (1setOf type2 keyword)	
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))	

3.1	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.  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 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. 

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 (see [RFC2911] section 4.2.6) has a value of 'staple,' then the staple would bind the covers, along with all of the other sheets in the output.

A client SHOULD use this attribute rather than the “page-overrides” attribute with the “media” attribute overridden for the first and last page of each Output-Document. A Printer MAY perform some special function with covers that it wouldn’t perform for “page-overrides”.

Both the "cover-front" and "cover-back" attributes are defined by the following collection:

Table 2 - "cover-front" and "cover-back" member attributes
Attribute name	attribute syntax	request	Printer Support	
media	type3 keyword | name(MAX)	MAY be neither or one of, but NOT both
	MUST	
media-col	collection		MAY	
cover-type	type2 keyword	MUST	MUST	

3.1.1	media (type3 keyword | name(MAX)) or media-col (collection)

Either the "media" (defined in [RFC2911] section 4.2.11) or the "media-col" member attribute is used to indicate what media that the Printer MUST use for the specified cover.  The member attributes are the same as those for the "media-col" attribute shown in Table 10.  

If the client omits both the "media" and the "media-col" member attributes, then the media currently being used by the Printer object for the document copy SHOULD also be used for the cover.  The client MUST NOT supply both the "media" and the "media-col" member attributes.  If the client supplies such a mal-formed request by supplying both, the Printer MUST either (1) reject the request and return the 'client-error-bad-request' status code (see [RFC2911] section 13.1.4.1) or (2) use either the "media" or the "media-col" member attribute, independent of the value of the "ipp-attribute-fidelity" attribute supplied by the client.

Since this "media" member attribute has the same name as the "media" Job Template attribute defined in [RFC2911] section 4.2.11), the "media-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute (also defined in [RFC2911] section 4.2.11) identifies the values of this "media" member attribute (as well as the values of the "media" Job Template attribute) that the Printer supports, i.e., the names of the supported media.

Since this "media-col" member attribute has the same name as the "media-col" Job Template attribute defined in section 3.12), the "media-col-supported" Printer attribute (defined in section 3.12.14) identifies the keyword names of the member attributes supported in this "media-col" member attribute (as well as the keyword names of the "media-col" Job Template attribute), i.e., the names of the member attributes in Table 10 that the Printer supports. 

3.1.2	cover-type (type2 keyword)

The "cover-type" member attribute indicates whether covers are wanted and 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 "cover-type" are:

'no-cover'	No covers are to be produced.	
'print-none'	No printing on either side of the cover.	
'print-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.	
'print-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.	
'print-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 "cover-type-supported" (1setOf type2 keyword) Printer attribute identifies the values that the Printer supports, i.e., the keyword cover types supported.

3.1.3	cover-front-default (collection) and cover-back-default (collection)

The "cover-front-default" and "cover-back-default" specify the cover that the Printer will provide, if any, if the client omits the "cover-front" or "cover-back" Job Template attribute, respectively.  The member attributes are defined in Table 2.  A Printer MUST support the same member attributes and values for these default attributes as it supports for the corresponding "cover-front" and "cover-back" Job Template attributes.

3.1.4	cover-front-supported (1setOf type2 keyword), cover-back-supported (1setOf type2 keyword)

The "cover-front-supported" and "cover-back-supported" attributes identify the keyword names of the member attributes supported in the "cover-front" and "cover-back" collection Job Template attributes, respectively, i.e., the keyword names of the member attributes in Table 2 that the Printer supports. 

3.2	finishings-col (collection) - augments IPP "finishings"

This attribute augments the IPP "finishings" Job Template attribute (defined in [RFC2911] section 4.2.6).  This "finishings-col" Job Template collection attribute enables a client end user to specify detailed finishing operations that cannot be specified using simple enumerated finishing values of the IPP "finishings" Job Template attribute.  Figure 1 shows the general finishing coordinate system used by the member attributes of the "finishing-col" collection attribute and relates to the general coordinate system defined in section 2.3 for all Job Template attributes.  A Printer MAY support the "finishings" attribute without supporting the "finishings-col" attribute.  However, if a Printer supports the "finishings-col" attribute, it MUST also support the "finishings" attribute.  Otherwise, clients that support only the IPP/1.0 or IPP/1.1 "finishings" Job Template attribute would not be able to interoperate with a Printer that supports only the "finishings-col" Job Template attribute.

Note:  The "finishings-col" (and the IPP/1.1 "finishing" ) Job Template attribute MAY be applied to page ranges using the "pages-per-subset" Job Template attribute (see [ipp-override]) in order to achieve so-called "subset finishing".

Figure 1 - General Finishing Coordinate System
Table 3 lists the member attributes of the "finishings-col" (collection) attribute.  Some of these member attributes are themselves collection attributes.
Table 3 - The "finishings-col" member attributes
Attribute	Request	Printer Support	
finishing-template (name(MAX))	MAY	MAY	
stitching (collection)	MAY	MAY	

Note:  other collection member attributes will be defined in the future, such as: "binding", "drilling", "folding", "trimming", and "offsetting", etc.  There may also be some future non-collection member attributes that are simply 'keyword | name'.

3.2.1	finishing-template (name(MAX))

The "finishing-template" member attribute contains a string value that specifies some particular finishing operation.  The value MAY be a list of parameters used by some implementation defined finishing software or finishing device, e.g. a third party finisher. Alternatively, the value MAY be the name of a file containing finishing parameters. 

The "finishing-template-supported" (1setOf name(MAX)) Printer attribute identifies the values of this "finishing-template" member attribute that the Printer supports, i.e., the implementation-specific parameter values supported.

3.2.2	stitching (collection)

The "stitching" member attribute is used to specify that each copy of each document in the job MUST be stitched or stapled using the detailed stitching parameters provided in the collection.  The stitching member attribute is used whether the implementation uses wire stitches or staples.  Table 4 lists the member attributes of the "stitching" (collection) attribute.
Table 4 - The "stitching" member attributes
Attribute	Request	Printer Support	
stitching-reference-edge (type2 keyword)	MUST	MUST	
stitching-offset (integer(0:MAX))	MUST	MUST	
stitching-locations (1setOf integer(0:MAX))	MUST	MUST	

While the "stitching-reference-edge," "stitching-offset", and "stitching-locations" member attributes are required to completely specify all possible stitching locations, it may not be possible to specify all of these (or to specify all of them independently) for every stitching device. 

A Printer that chooses to support the "stitching" collection attribute MUST support the "stitching-reference-edge", the "stitching-offset", and the "stitching-locations" member attributes  (in order to provide programmable stitching capability beyond that available through the IPP "finishings" Job Template attribute - see [RFC2911] section 4.2.6)
A client that chooses to request custom stitching using the "stitching" collection attribute MUST specify the "stitching-reference-edge", the  "stitching-offset", and the "stitching-locations".  If the client supplies a mal-formed request by not supplying all three member attributes, the Printer MUST (depending on implementation) either (1) reject the request and return the "client-error-bad-request' (see [RFC2911] section 13.1.4.1) or (2) default the omitted member attributes, independent of the value of the "ipp-attribute-fidelity" attribute supplied by the client.

3.2.2.1	stitching-reference-edge (type2 keyword)

The "stitching-reference-edge" member attribute specifies the Stitching Reference Edge of the output media relative to which the stapling or stitching MUST be applied.  The individual staples or stitches will be situated along a line or axis parallel to the Stitching Reference Edge that is called the Stitching Axis.

Notice that the "stitching-reference-edge" member attribute is single valued, and thus prohibits specification of location by a combination of values (e.g., top-left is not allowed). 

The standard keyword values are:
'bottom':  The bottom edge coincides with the x-axis of the coordinate system.
'top':  The top edge is opposite and parallel to the bottom edge.
'left':  The left edge coincides with the y-axis of the coordinate system.
'right':  The right edge is opposite and parallel to the left edge.

A Printer MUST support this member attribute and at least the 'left' value, however, which additional values depend on implementation.    

Note that the 'left' value works with 'portrait' and 'landscape' documents, since 'landscape' documents are rotated anti-clock-wise 90 degrees, i.e., plus 90 degrees, with respect to 'portrait' documents, if landscape documents are stapled along the long edge (which becomes the top edge when the human reader orients the 'landscape' document for reading).  If the documents to be stapled are two-sided, then the client supplies the 'two-sided-long' and 'two-sided-short' values for the "sides" attribute for the 'portrait' and 'landscape' documents, respectively.  Note:  the client can supply the proper value for the "sides" attribute for the user, by knowing whether the document is portrait or landscape, thereby relieving the user of having to distinguish between the two values for two-sided printing.

If the 'landscape' documents are to be stapled on the short edge (which becomes the left edge when the human reader orients the 'landscape' document for reading), the client supplies the 'bottom' and 'two-sided-short' values for the "stitching-reference-edge" and "sides" attributes, respectively.

For 'reverse-landscape' documents (ones rotated clock-wise 90 degrees, i.e., minus 90 degrees, the client supplies 'right' and 'two-sided-long' values for the "stitching-reference-edge" and "sides" attributes, respectively, if landscape documents are stapled along the long edge (which becomes the top edge when the human reader orients the 'landscape' document for reading).  If the 'reverse-landscape' documents are to be stapled on the short edge (which becomes the left edge when the human reader orients the 'landscape' document for reading), the client supplies the 'top' and 'two-sided-short' values for the "stitching-reference-edge" and "sides" attributes, respectively.

The "stitching-reference-edge-supported" (1setOf type2 keyword) Printer attribute identifies the values of this "stitching-reference-edge" member attribute that the Printer supports, i.e., the stitching reference edges supported.

3.2.2.2	stitching-offset (integer (0:MAX))

The "stitching-offset" member attribute specifies the perpendicular distance of the Stitching Axis from the Stitching Reference Edge.  Since the "stitching-offset" member attribute is positive or zero, the offset is always in the direction that is both away from the Stitching Reference Edge and toward the center of the media sheet.

The unit of measure for the "stitching-locations" member attribute is one hundredth of a millimeter.  This unit is equivalent to 1/2540 th of an inch resolution.

If the client specifies a "stitching-offset" then the Printer MUST produce a stitch (or stitches) along a line that is the specified number of hundreds of millimeters specified by the "stitching-offset" attribute away from the "stitching-reference-edge".

The "stitching-offset-supported" (1setOf (integer (0:MAX) | rangeOfInteger(0:MAX))) Printer attribute identifies the values of this "stitching-offset" member attribute that the Printer supports, i.e., the stitching offsets supported which can be a series of discrete numbers and/or ranges.  No relationship between values of this attribute and the number of stitching locations that the device supports can be inferred.

3.2.2.3	stitching-locations (1setOf integer(0:MAX))

Each value of "stitching-locations" specifies an absolute offset along the Stitching Axis at which a stitch MUST occur.  Each value in the 1setOf MUST be in order of increasing distance.  

If the "stitching-reference-edge" is either 'top' or 'bottom', then each value in the "stitching-locations" represents an offset in hundreds of millimeters from the left edge along the Stitching Axis toward the center of the medium. If the "stitching-reference-edge" is either 'left'  or 'right, then each value in the "stitching-locations" represents an offset in hundreds of millimeters from the bottom edge along the Stitching Axis toward the center of the medium.  

The unit of measure for the "stitching-locations" member attribute is one hundredth of a millimeter.  This unit is equivalent to 1/2540 th of an inch resolution.

The "stitching-locations-supported" (1setOf (integer(0:MAX) | rangeOfInteger(0:MAX))) Printer attribute identifies the values of this "stitching-locations" member attribute that the Printer supports, i.e., the stitching locations supported which can be a series of discrete numbers and/or ranges.  No relationship between values of this attribute and the number of stitching locations that the device supports can be inferred.

The "max-stitching-locations-supported" (integer(1:MAX)) Printer Description attribute indicates the maximum number of stitches or staples that the implementation is capable of inserting into an Output Document, even if that number would require human intervention in order to configure the (manual configured) stitcher.  See section 5.2.  In other words, "max-stitching-locations-supported" attribute specifies the maximum number of values that the client can supply in the "stitching-locations" member attribute.

3.2.2.4	stitching-supported (1setOf type2 keyword)

The "stitching-supported" Printer attribute identifies the keyword names of the member attributes supported in the "stitching" collection member attribute, i.e., the keyword names of the member attributes in Table 4 that the Printer supports.

3.2.3	finishings-col-default (collection)

The "finishings-col-default" Printer attribute specifies the finishing that the Printer uses, if any, if the client omits the "finishings-col" Job Template attribute in the Job Creation operation (and the PDL doesn't include a finishing specification).  The member attributes are defined in Table 3.  A Printer MUST support the same member attributes for this default collection attribute as it supports for the corresponding "finishings-col" Job Template attribute.

3.2.4	finishings-col-ready (1setOf collection)

The "finishings-col-ready" Printer attribute identifies the finishings configurations that do not require human intervention in order to be used.  Table 5 lists the member attributes, their attribute syntaxes, and the corresponding "xxx-supported" Printer attributes.  The member attributes have the same names as the member attributes that the client can supply in the "finishing-col" collection attribute (see Table 4), but have the attribute syntaxes of the corresponding "xxx-supported" Printer attributes.  The member attribute values will differ from the corresponding "xxx-supported" Printer attribute values to the extent that human intervention is needed, such as running out of staples (or stitching wire) and/or a stapler that requires manual position setting.  The rangeOfInteger value is used to indicate the range that can be selected by the client without human intervention, if the finisher is programmable.
Table 5 - The "finishings-col-ready" member attributes
member attribute	section	corresponding supported attribute	
finishing-template (1setOf name(MAX))	3.2.1	finishing-template-supported (1setOf name(MAX))	
stitching (1setOf collection)
which contains:	3.2.2	stitching-supported (1setOf type2 keyword)	
stitching-reference-edge (1setOf type2 keyword)	3.2.2.1	stitching-reference-edge-supported (1setOf type2 keyword)	
stitching-offset (1setOf (integer (0:MAX) | rangeOfInteger(0:MAX)))	3.2.2.2	stitching-offset-supported" (1setOf (integer (0:MAX) | rangeOfInteger(0:MAX)))	
stitching-locations (1setOf (integer(0:MAX) | rangeOfInteger(0:MAX))) 	3.2.2.3	stitching-locations-supported (1setOf (integer(0:MAX) | rangeOfInteger(0:MAX))) 	

3.2.5	finishings-col-supported (1setOf type2 keyword)

The "finishings-col-supported" Printer attribute identifies the keyword names of the member attributes supported in the "finishings-col" collection Job Template attribute, i.e., the keyword names of the member attributes in Table 3 that the Printer supports.

3.3	force-front-side (1setOf integer(1:MAX))

This attribute forces the identified Input-Pages (numbered 1 to n) to be imaged on the front side of a sheet.  For each identified Input-Page, if that page would have been (1) imaged on the back side of a sheet or (2) is under the scope of the "number-up" or "imposition-template" attribute and would have been imaged in any position on the front side but the first position, the Printer forces the page to be imaged on the front side of the next sheet (in the first position).  Otherwise, the Printer prints the page as usual.

3.4	insert-sheet (1setOf collection) 

This attribute specifies how Insert-Sheets are to be inserted into the sequence of media sheets that are produced for each copy of each printed document in the job.  Insert-Sheets are sheets on which no Input-Pages from the Input-Document are imaged.  However, the media specified for Insert-Sheets can be pre-printed media.  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 "insert-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:

Table 6 - "insert-sheet" member attributes
Attribute name	attribute syntax	request	Printer Support	
insert-after-page-number	integer (0:MAX)	MUST	MUST	
insert-count	integer (0:MAX)	MAY	MUST	
media	type3 keyword | name(MAX)	MUST be one or the other, but NOT both	MUST	
media-col	collection		MAY	

3.4.1	insert-after-page-number (integer(0:MAX))

The "insert-after-page-number" member attribute specifies the page in the Input-Document (see sections 2.2 and 2.4) print-stream after which the Insert-Sheet(s) is(are) to be placed. The inserted sheet(s) does not affect the numbering of print-stream pages.  For-example, to insert a single sheet after both pages 2 and 3 of a given document, the value of "input-after-page-number" would be 2 and 3 respectively (not 2 and 4, as it would be if the inserted sheet affected the Input-Document print-stream page count).  For a complete description of the enumeration of print-stream pages see section 2.4.

If the value of the "insert-after-page-number" member attribute is 0, then the sheet is inserted before the first page.  If the value is MAX, then the sheet is inserted after the last sheet in the document.

If the "insert-after-page-number" member attribute is not a valid input document page reference in the print-stream, then the IPP Printer SHOULD ignore the request.  For example, (1) the page number is beyond the last page of the document AND is not MAX or (2) the "page-ranges" Job Template attribute does not include the specified page number (see section 2.4).  There is no way to validate the "insert-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.

Since the "insert-after-page-number" member attribute refers to a specific Input-Document 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 Printer MUST force a new Sheet after the specified page, insert the specified sheet, place the following pages on the first side of the next Sheet, and issue a warning by adding ‘job-warnings-detected’ to the “job-state-reasons” and by increasing the value of  the “job-warnings-count” Job Description attribute by 1.  See [ipp-override] for this error handling specification under "Common Behavior for Sheet Attributes". 

The "insert-after-page-number-supported" (rangeOfInteger(0:MAX)) Printer attribute indicates the range of page numbers supported in the "insert-after-page-number" member attribute, i.e., the minimum (SHOULD be 0) and the maximum (SHOULD be MAX) page numbers supported.

3.4.2	insert-count (integer(0:MAX))

The "insert-count" member attribute indicates how many sheets to insert.  If the "insert-count" attribute is omitted, then the printer assumes a value of 1.  The value 0 indicates that no inserts sheets are to be inserted.

The "insert-count-supported (rangeOfInteger(0:MAX)) Printer attribute specifies the range of values that the Printer supports, i.e., the minimum number and the maximum number of pages.

3.4.3	media (type3 keyword | name(MAX)) or media-col (collection)

Either the "media" (defined in [RFC2911] section 4.2.11) or the "media-col" member attribute is used to indicate the media that the Printer MUST use for the insert sheet.   The member attributes are the same as those for the "media-col" attribute shown in Table 10.  

The client MUST supply either the "media" or the "media-col" member attribute, but NOT both.  If the client supplies such a mal-formed request by supplying neither or both, the Printer MUST (depending on implementation) either (1) reject the request and return the 'client-error-bad-request' status code (see [RFC2911] section 13.1.4.1) or (2) use either the "media" or the "media-col" member attribute, independent of the value of the "ipp-attribute-fidelity" attribute supplied by the client.

Since this "media" member attribute has the same name as the "media" Job Template attribute defined in [RFC2911] section 4.2.11), the "media-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute (also defined in [RFC2911] section 4.2.11) identifies the values of this "media" member attribute (as well as the values of the "media" Job Template attribute) that the Printer supports, i.e., the names of the supported media.

Since this "media-col" member attribute has the same name as the "media-col" Job Template attribute defined in section 3.12), the "media-col-supported" Printer attribute (defined in section 3.12.14) identifies the keyword names of the member attributes supported in this "media-col" member attribute (as well as the keyword names of the "media-col" Job Template attribute), i.e., the names of the member attributes in Table 10 that the Printer supports. 

3.4.4	insert-sheet-default (1setOf collection)

The "insert-sheet-default" Printer attributes specify the insert sheet(s) that the Printer MUST provide, if any, if the client omits the "insert-sheet" Job Template attribute.  The member attributes are defined in Table 6.  A Printer MUST support the same member attributes for this default collection attribute as it supports for the corresponding "insert-sheet" Job Template attribute.
 
3.4.5	insert-sheet-supported (1setOf type2 keyword) 

The "insert-sheet-supported" attribute identifies the keyword names of the member attributes supported in the "insert-sheet" collection Job Template attribute, i.e., the keyword names of the member attributes in Table 6 that the Printer supports. 

3.5	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" attribute is implementation dependent.  

A zero-length value indicates that there is no account name.

3.6	job-accounting-user-id (name(MAX))

The "job-accounting-user-id" attribute specifies the user ID associated with the account specified by the "job-account-id" attribute (see section 3.5) used for this job.  These two attributes are used for authentication and account tracking either by a mechanism internal to the printer, or by tracking software external to the printer such as Equitrac.  Account tracking systems will usually support a job account ID as having multiple job accounting user IDs, as well as, a job accounting user ID to be used with multiple job account IDs.  It is allowable for value of the "job-originating-user-name" (see RFC 2911 section 4.3.6) to be the same as the "job-accounting-user-id".

A zero-length value indicates that there is no user accounting ID.

3.7	job-accounting-sheets (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 (see section 3.5) and the "job-accounting-user-id" attribute (see section 3.6), 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.  Typically, job accounting sheets are printed after the job and are not finished (e.g., not stapled) with the document(s).

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:

Table 7 - "job-accounting-sheets" member attributes
Attribute name	attribute syntax	request	Printer Support	
job-accounting-sheets-type	type3 keyword | name(MAX)	MUST	MUST	
media	type3 keyword | name(MAX)	MAY be neither or one of, but NOT both	MUST	
media-col	collection		MAY	
job-accounting-output-bin	type3 keyword | name(MAX)	MAY	MAY	

3.7.1	job-accounting-sheets-type (type3 keyword | name(MAX))

The "job-accounting-sheets-type" member attribute specifies which job accounting sheets format the Printer MUST use to print on the specified media.  Standard keyword values 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 "job-accounting-sheets-type-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute identifies the values of this "job-accounting-sheets-type" member attribute that the Printer supports, i.e., the names of the job accounting sheets supported.

3.7.2	media (type3 keyword | name(MAX)) or media-col (collection)

Either the "media" (defined in [RFC2911] section 4.2.11) or the "media-col" member attribute is used to indicate the media that the Printer SHOULD use for the job accounting sheet.  The member attributes are the same as those for the "media-col" attribute shown in Table 10.  

If both the "media" and the "media-col" member attributes are omitted, then the media currently being used by the Printer object for the document copy SHOULD also be used for the accounting sheet.  The client MUST NOT supply both the "media" and the "media-col" member attribute.  If the client supplies such a mal-formed request by supplying both, the Printer MUST (depending on implementation) either (1) reject the request and return the 'client-error-bad-request' status code (see [RFC2911] section 13.1.4.1) or (2) use either the "media" or the "media-col" member attribute, independent of the value of the "ipp-attribute-fidelity" attribute supplied by the client.

Since this "media" member attribute has the same name as the "media" Job Template attribute defined in [RFC2911] section 4.2.11), the "media-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute (also defined in [RFC2911] section 4.2.11) identifies the values of this "media" member attribute (as well as the values of the "media" Job Template attribute) that the Printer supports, i.e., the names of the media supported.

Since this "media-col" member attribute has the same name as the "media-col" Job Template attribute defined in section 3.12), the "media-col-supported" Printer attribute (defined in section 3.12.14) identifies the keyword names of the member attributes supported in this "media-col" member attribute (as well as the keyword names of the "media-col" Job Template attribute), i.e., the names of the member attributes in Table 10 that the Printer supports.

3.7.3	job-accounting-output-bin (type3 keyword | name(MAX))

The "job-accounting-output-bin" member attribute specifies the output bin in which the accounting sheets are to be placed (see [pwg-output-bin]).  If this member attribute is not supplied by the client or not supported by the Printer, then the Printer places the accounting sheets in the same output-bin as the rest of the job.  

The "job-accounting-output-bin-default" (type3 keyword | name(MAX)) Printer attribute is configured to contain the default output bin for job accounting sheets.  If this attribute is not configured (has the 'no-value' out-of-band value), then the accounting sheets are printed with the job when not specified otherwise by the client.  

The  "job-accounting-output-bin-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute is configured to contain the supported output bins for accounting sheets.  As with any member attribute of a Job Template attribute, if the administrator wants to force accounting sheets into a specific output bin, then the administrator configures the "job-accounting-output-bin-default" and "job-accounting-output-bin-supported" Printer attributes to contain only that value.

3.7.4	job-accounting-sheets-default (collection)

The "job-accounting-default" Printer attributes specify the job accounting that the Printer MUST provide, if any, if the client omits the "job-accounting" Job Template attribute.  The member attributes are defined in Table 7.  A Printer MUST support the same member attributes and value for this default collection attribute as it supports for the corresponding "job-accounting-sheets" Job Template attribute.

3.7.5	job-accounting-sheets-supported (1setOf type2 keyword)

The "job-accounting-supported" attribute identifies the keyword names of the member attributes supported in the "job-accounting-sheets" Job Template collection attribute, i.e., the keyword names of the member attributes in Table 7 that the Printer supports.  

As with any Job Template attribute, if the system administrator wishes to force job accounting sheets to always be printed, then he/she configures the Printer's "job-accounting-sheets-default" (collection) Printer attribute and the "job-accounting-sheet-type-supported" Printer attribute to contain only the desired value and not contain the 'none' value.

3.8	job-error-sheet (collection)

This attribute specifies which job error sheet 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.  If necessary the error sheet can consist of more than one page of output.

If the Printer is producing a job sheet for this job (see section 3.10 and [RFC2911] section 4.2.3), then the Printer object MAY print any error and warning information on that same job sheet, i.e., merge the error sheet with the job sheet.  This use of the job sheet for errors only applies if the "job-error-sheet" attribute is supplied without either a "media" or "media-col" member attribute.  If the "media" or "media-col" member attribute is supplied, 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:

Table 8 - "job-error-sheet" member attributes
Attribute name	attribute syntax	request	Printer Support	
job-error-sheet-type	type3 keyword | name(MAX)	MUST	MUST	
job-error-sheet-when	type2 keyword	MAY	MAY	
media	type3 keyword | name(MAX)	MAY be neither or one of, but NOT both	MUST	
media-col	collection		MAY	

3.8.1	job-error-sheet-type (type3 keyword | name(MAX))

The "job-error-sheet-type" member attribute specifies which job error sheets format that the Printer SHOULD to print error information.  Standard keyword values are:

'none'	No error sheet information is 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 information MUST be printed with the job depending on the conditions specified by the "job-error-sheet-when" attribute.	

The "job-error-sheet-type-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute identifies the values of this "job-error-sheet-type" member attribute that the Printer supports, i.e., the names of the job error sheets.

3.8.2	job-error-sheet-when (type2 keyword)

The "job-error-sheet-when" member attribute specifies the conditions under which the error sheet information is to be produced.  The standard keyword values are:

'on-error'	Print the error sheet information if and only if errors or warnings occurred during the life of the job.  	
'always'	Always print the error sheet information, 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 or warnings detected during the processing of the job.	

The "job-error-sheet-when-supported" (1setOf type2 keyword) Printer attribute identifies the values of this "job-error-sheet-when" member attribute that the Printer supports, i.e., the possible conditions under which the job error sheet will be printer.

3.8.3	media (type3 keyword | name(MAX)) or media-col (collection)

Either the "media" (defined in [RFC2911] section 4.2.11) or the "media-col" member attribute is used to indicate the media that the Printer SHOULD be use for the job error sheets.  The member attributes are the same as those for the "media-col" attribute shown in Table 10.  

If the client omits both of the "media" or the "media-col" member attributes, the Printer prints any job sheet error information on either the job sheet, if it is being produced, or a separate sheet using the media of the document, depending on implementation.

The client MUST NOT supply both the "media" and the "media-col" member attribute.  If the client supplies such a mal-formed request by supplying both, the Printer MUST (depending on implementation) either (1) reject the request and return the 'client-error-bad-request' status code (see [RFC2911] section 13.1.4.1) or (2) use either the "media" or the "media-col" member attribute, independent of the value of the "ipp-attribute-fidelity" attribute supplied by the client.

Since this "media" member attribute has the same name as the "media" Job Template attribute defined in [RFC2911] section 4.2.11), the "media-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute (also defined in [RFC2911] section 4.2.11) identifies the values of this "media" member attribute (as well as the values of the "media" Job Template attribute) that the Printer supports, i.e., the names of the supported media.

Since this "media-col" member attribute has the same name as the "media-col" Job Template attribute defined in section 3.12), the "media-col-supported" Printer attribute (defined in section 3.12.14) identifies the keyword names of the member attributes supported in this "media-col" member attribute (as well as the keyword names of the "media-col" Job Template attribute), i.e., the names of the member attributes in Table 10 that the Printer supports.

3.8.4	job-error-sheet-default (collection )

The "job-error-sheet-default" Printer attributes specify the job error sheets that the Printer MUST provide, if any, if the client omits the "job-error-sheet" Job Template attribute.  The member attributes are defined in Table 8.  A Printer MUST support the same member attributes and values for this default attribute as it supports for the corresponding "job-error-sheet" Job Template attribute.

An implementation SHOULD be configured out-of-the-box so that the "job-error-sheet-default" Printer Attribute has the collection value consisting of the "job-error-sheet-type" with a value of: 'standard' rather than 'none'.  Then the Administrator and End Users have to explicitly turn off error information.

3.8.5	job-error-sheet-supported (1setOf type2 keyword)

The "job-error-sheet-supported" attribute identifies the names of the member attributes supported in the "job-error-sheet" Job Template collection attribute, i.e., the keyword names of the member attributes in Table 8 that the Printer supports. 

3.9	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.  A zero length text value indicates no message.

Note:  this attribute may be used in conjunction with the IPP "job-hold-until" Job Template attribute (see [RFC2911] section 4.2.2); 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.

3.10	job-sheets-col (collection) - augments  IPP "job-sheets" attribute

This attribute augments the IPP "job-sheets" Job Template attribute (define in [RFC2911] section 4.2.3). The 'collection' attribute syntax allows a client 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.  

Table 9 lists the member attributes of the "job-sheets-col" collection attribute:

Table 9 - "job-sheets-col" member attributes
Attribute name	attribute syntax	request	Printer Support	
job-sheets	type3 keyword | name(MAX)	MUST	MUST	
media	type3 keyword | name(MAX)	MUST be one or the other, but NOT both	MUST	
media-col	collection		MAY	

3.10.1	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" Job Template attribute itself, including the 'none' value, and convey the same semantics.

Since this "job-sheets" member attribute has the same name as the "job-sheets" Job Template attribute defined in [RFC2911] section 4.2.3), the "job-sheets-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute specifies which are the values of this "job-sheets" member attribute (as well as the values of the IPP/1.1 "job-sheets" Job Template attribute) that the Printer supports.

3.10.2	media (type3 keyword | name(MAX)) or media-col (collection)

Either the "media" (defined in [RFC2911] section 4.2.11) or the "media-col" member attribute is used to indicate the media that the Printer SHOULD use for the job sheet.  The member attributes are the same as those for the "media-col" attribute shown in Table 10.  

The client MUST supply either the "media" or the "media-col" member attribute, but NOT both.  If the client supplies such a mal-formed request by supplying neither or both, the Printer MUST (depending on implementation) either (1) reject the request and return the 'client-error-bad-request' status code (see [RFC2911] section 13.1.4.1) or (2) use either the "media" or the "media-col" member attribute, independent of the value of the "ipp-attribute-fidelity" attribute supplied by the client.

Since this "media" member attribute has the same name as the "media" Job Template attribute defined in [RFC2911] section 4.2.11), the "media-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute (also defined in [RFC2911] section 4.2.11) identifies the values of this "media" member attribute (as well as the values of the "media" Job Template attribute) that the Printer supports, i.e., the names of the supported media.

Since this "media-col" member attribute has the same name as the "media-col" Job Template attribute defined in section 3.12), the "media-col-supported" Printer attribute (defined in section 3.12.14) identifies the keyword names of the member attributes supported in this "media-col" member attribute (as well as the keyword names of the "media-col" Job Template attribute), i.e., the names of the member attributes in Table 10 that the Printer supports.

3.10.3	job-sheets-col-default (collection)

The "job-sheets-default (see [RFC2911] section 4.2.3) attribute and the "job-sheets-col-default" Printer attribute specify the job sheets that the Printer MUST provide, if the client omits both the "job-sheets" and the "job-sheets-col" Job Template attribute in the Job Creation operation (and the PDL doesn't include a job sheets specification).  The member attributes are defined in Table 9.  A Printer MUST support the same member attributes for this default collection attribute as it supports for the corresponding "job-sheets-col" Job Template attribute.

The "job-sheets-default" and "job-sheets-col-default" Printer attributes MUST both be configured to specify the same job sheet instance.  If the administrator sets one of them to a value (either locally or with the Set-Printer-Attributes operation - see [ipp-set]), the Printer MUST set the other attribute's value to specify the same job sheet instance or to the 'unknown' out-of-band value, if there isn't a corresponding value to be set for the other attribute.  If a client attempts to set both attributes, but their values specify different job sheet instances, the Printer MUST reject the Set-Printer-Attributes operation and return the 'client-error-conflicting-attributes' status code.  The reason to have both default attributes configured, is so that clients that only know about the "job-sheets" attribute will see the "job-sheets-default" attribute, while clients that know about the "job-sheets-col" attribute will be able to determine the characteristics of the job sheet default.

3.10.4	job-sheets-col-supported (1setOf type2 keyword)

The "job-sheets-col-supported" attribute identifies the keyword names of the member attributes supported in the "job-sheets-col" collection Job Template attribute, i.e., the keyword names of the member attributes in Table 9 that the Printer supports.

3.11	job-sheet-message (text(MAX))

This attribute is used to convey a message that is delivered with the job, and may be printed 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. 

3.12	media-col (collection) - augments IPP "media"

This attribute augments the "media" Job Template attribute (defined in [RFC2911] section 4.2.11).  This "media-col" Job Template collection attribute enables a client end user to submit a list of media characteristics to the Printer as a way to more completely specify the media to be used.  Each member attribute of the collection identifies a media characteristic.  A Printer MAY support the "media" attribute without supporting the "media-col" attribute.  However, if a Printer supports the "media-col" attribute, it MUST also support the "media" attribute.  Otherwise, clients that support only the IPP/1.0 or IPP/1.1 "media" Job Template attribute would not be able to interoperate with a Printer that supports only the "media-col" Job Template attribute.

Each value of the "media" (type3 keyword | name) Job Template attribute uniquely identifies an instance of media.  Each combination of values of the "media-col" collection attribute also uniquely identify an instance of media.  In other words, each media instance supported by a Printer MUST have a combination of member attribute values that differs from the combination of values for all other supported media instances.  

When associating standard media keywords with media instances to be used with the "media" attribute, the implementation and/or the administrator SHOULD associate them with media instances whose characteristics are what users would normally expect.  For example, the 'iso-a4-white' keyword SHOULD be associated with a media instance that is A4 in size, 20 pound or 24 pound in weight, white in color, with 'stationery' media type, no holes, etc.

The standard media keywords that identify media sizes, such as 'iso-a4' and 'na-letter', are associated with any media in an input tray that is configured for that media size.  Thus specifying media size keywords with the "media" attribute does not guarantee reproducible results from one job submission to another, since different media of the same size may be present from one time to the next.  If none of the input trays are configured for that size, the association with a media instance is IMPLEMENTATION DEPENDENT.

The client MUST NOT supply both the "media" and the "media-col" Job Template attributes in a Job Creation request.  If the client supplies such a mal-formed request by supplying both, the Printer MUST (depending on implementation) either (1) reject the request and return the 'client-error-bad-request' status code (see [RFC2911] section 13.1.4.1) or (2) use either the "media" or the "media-col" attribute, independent of the value of the "ipp-attribute-fidelity" attribute supplied by the client.

A number of collection Job Template attributes defined in this document have both the "media" and "media-col" member attributes.  The same rule against supplying both in a request holds for those collection attributes.  Those Job Template attributes whose sole purpose is to specify the media are defined so that the Printer MUST use the requested media, while those that have additional purposes as well are defined so that the Printer SHOULD use the requested media.

Each “media-col” value in a Printer MUST contain a value for each “media-col” member attribute supported by the Printer. That is, all “media-col” values in a Printer contain the same member attributes. The “media-col” values supported by a Printer MUST be either all combinations of supported member attribute values or a subset thereof. When a client supplies a “media-col” attribute in a Job Creation or Validate-Job request, the client NEED NOT include all “media-col” member attributes supported by the Printer.  

When a Printer receives a “media-col” attribute in a Job Creation or Validate-Job request, it finds the specified “media-col” value in the Printer using the following “matching algorithm”: (this algorithm effectively fills in the member attributes not supplied by the client)

1)	Find all “media-col” values where each member attribute value is identical to the corresponding member attribute in the client supplied “media-col” attribute.  Any member attribute not supplied by the client matches any value of the corresponding member attribute in the Printer. The Printer ignores those member attributes supplied by the client and not supported by the Printer.

2)	If the number of matched “media-col” values is:

0:  the Printer MUST either
a)	treat the client-supplied “media-col” value as an unsupported value (see [RFC2911] Print-Job operation) if “media-col” is not a value of the “user-defined-values-supported” attribute (see section 5.1), or
b)	accept the “media-col” value and put the Job in the ‘pending-held’ state if “media-col” is a value of the “user-defined-values-supported” attribute, and if the Job is otherwise accepted. 

1:  a Printer implementation MUST either
a)	use this single value of “media-col” as the value specified by the client, or
b)	use step “2 or more” below to confirm the single matched value or to eliminate it.

2 or more:  a Printer MUST reduce the number “media-col” values in an implementation-defined manner to 1 or 0.  If the number of values from this step is 1, the Printer implementation MUST go to step ‘1a)’ above.  If the number of values from this step is 0, the Printer implementation MUST go to step ‘0’ above. 

To reduce the number of “media-col” values, an implementation SHOULD pick an algorithm that gives reproducible results.  For example, an algorithm that picks one value at random does not give reproducible results. The following are some possible algorithms. Others are possible too.
a)	A Printer MAY apply implementation-defined defaults for member attributes not specified by the client and perform the matching algorithm again on the matched values. This algorithm may result in 0 matches.
b)	A Printer MAY find the “closest” or “best” match of the matched “media-col” values. This document doesn’t attempt to define “closest” or “best”, but the result MUST be a single match.
c)	A Printer MAY find the “closest” or “best” match of the matched “media-col” values that are also ready (i.e. loaded in trays). This algorithm has a chance of being less reproducible, but may still be sufficiently reproducible to be useful. This algorithm may yield 0 matches unless there is a fallback, such as to the preceding algorithm (b).

A Printer MUST implement either the above algorithm or one that produces equivalent results.

Table 10 lists the member attributes of the "media-col" collection attribute:
Table 10 - "media-col" member attributes
Attribute name	attribute syntax	request	Printer Support	
media-key	type3 keyword | name(MAX)	MAY	MAY	
media-type	type3 keyword | name(MAX)	MAY	MAY	
media-info	text(255)	MAY	MAY	
media-color	type3 keyword | name(MAX)	MAY	MAY	
media-pre-printed	type3 keyword | name(MAX)	MAY	MAY	
media-hole-count	integer(0:MAX)	MAY	MAY	
media-order-count	integer(1:MAX)	MAY	MAY	
media-size	collection	MAY	MUST	
media-weight-metric	integer(0:MAX)	MAY	MAY	
media-back-coating	type3 keyword | name(MAX)	MAY	MAY	
media-front-coating	type3 keyword | name(MAX)	MAY	MAY	
media-recycled	type3 keyword | name(MAX)	MAY	MAY	

The "media-col" collection member attributes definitions are:

3.12.1	media-key (type3 keyword | name(MAX))

The "media-key" member attribute contains the name of the media represented as a keyword or name.  Values MUST be the same as the keyword and name values for the "media" Job Template attribute and represent the same media, except for media size and input tray keywords (see section 6.3 in this document and [RFC2911] Appendix C) which MUST NOT be "media-key" values.  

The value of this member attribute MUST be unique for each media supported by an IPP Printer instance, i.e., no two media instances can have the same "media-key" value on the same IPP Printer instance.  However, the same "media-key" value can represent the same or different media on different IPP Printer instances.  For example, the 'iso-a4-white' keyword might represent recycled 80 gm/mm on two Printer instances and non-recycled, 72 gm/mm on a third Printer instance.  An administrator or a number of administrators within an organization MAY choose to have "media-key" values represent the same media instances across a set of Printers.

Note:  Since the above requires that each media instance have a unique "media-key" value (if "media-key" attribute is supported), then the Printer automatically meets the requirement (see section 3.12) that each media instance have a unique combination of member attribute values.

Note:  As with any combination of supported "media-col" member attributes, if a client supplies the "media-key" member attribute and other member attributes, the Printer will attempt to match all of the supplied member attributes, including the "media-key" value, following the algorithm defined in section 3.12.  So if the supplied collection value does not match any supported "media-col" value, the Printer treats the "media-col" attribute as having an undefined attribute value.  Thus, a client can ensure that the Printer maps a standard media name keyword to certain expected member attribute values.

The "media-key-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute identifies the values of this "media-key" member attribute that the Printer supports.  

For Printers that support a large number of media (and the "media-key" attribute), the burden of an administrator to define unique "media-key" values for each media instance could be quite large.  Therefore, it is RECOMMENDED that such a Printer assign a unique "media-key" value in an IMPLEMENTATION-DEFINED manner for each media instance for which the administrator has not defined a "media-key" value, rather than refusing the media definition.  The Printer also adds such generated values to its "media-key-supported" attribute.  A client can supply such a Printer-generated value with either (1) the "media-key" member attribute or (2) the "media" Job Template attribute.

3.12.2	media-type (type3 keyword | name(MAX))

The "media-type" member attribute identifies the type of media, i.e., the media instance's predominate characteristic.  Depending on implementation, the Printer MAY need to behave differently or perform different validation, depending on the type of the media.  For example, prohibiting stapling transparencies or selecting a different paper path for an envelope.

The values and descriptions indicated with 'yes' are taken verbatim from the Printer MIB [RFC1759] and "Media Features for Display, Print, and Fax" [RFC2534] documents.  Bracketed text indicates additions to these Descriptions taken from other standards.  Additional values MAY be registered according to both [REG] and [RFC2911].   

Keyword	Description	Printer MIB	RFC 2534	
stationery	Separately cut sheets of an opaque material	yes	yes	
transparency	Separately cut sheets of a transparent material	yes	yes	
envelope	Envelopes that can be used for conventional mailing purposes	yes	yes	
envelope-plain	Envelopes that are not preprinted and have no windows	yes	yes	
envelope-window	Envelopes that have windows for addressing purposes	yes	no	
continuous	Continuously connected sheets of an opaque material - which edge is connected is not specified 	no	yes	
continuous-long	Continuously connected sheets of an opaque material connected along the long edge	yes	no	
continuous-short	Continuously connected sheets of an opaque material connected along the short edge	yes	no	
tab-stock	Media with tabs [either pre-cut or full-cut]	yes	no	
pre-cut-tabs	Media with tabs that are cut so that more than one tab is visible extending out beyond the edge of non-tabbed media in an Output-Document.	no	no	
full-cut-tabs	Media with a tab that runs the full length of the sheet so  that only one tab is visible extending out beyond the edge of non-tabbed media in an Output-Document.	no	no	
multi-part-form	Form medium composed of multiple layers not pre-attached to one another; each sheet may be drawn separately from an input source	yes	no	
labels	Label stock [For example, a sheet of peel-off labels].	yes	no	
multi-layer	Form medium composed of multiple layers which are pre-attached to one another; e.g., for use with impact printers.	yes	no	
screen	A refreshable display	no	yes	
screen-paged	A refreshable display which cannot scroll	no	yes	
other	The 'other' keyword value is used when the media instance does not correspond to any of the Printer's supported media types (keyword or name).  

The 'other' keyword value SHOULD NOT be used to refine the defined values.  For example, the "media-type" member attribute SHOULD use the 'envelope' value for both self-sealing and moisture-required envelopes in combination with the "media-info" attributes indicating the difference, rather than using the value 'other'.  Alternatively, if the Printer supports the name attribute syntax for the "media-type" member attribute and allows the 'name' attribute syntax for envelopes, the administrator could define two new "media-type" name values: 'envelope-self-sealing' and 'envelope-moisture-required'.	no	no	

The "media-type-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute identifies the values of this "media-type" member attribute that the Printer supports, i.e., the media types supported.

Note:  The Administrator can define custom media types using the 'name' (MAX) attribute syntax of the "media-type-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute, if the Printer supports the 'name' attribute syntax for this attribute.  As with other Job Template and member attributes, the user can also supply user-defined media type names that are not among the values of the “media-type-supported” Printer attribute, if the Administrator has configured the Printer's "user-defined-values-supported" attribute to contain the 'media-type' attribute keyword value (see section 5.1).

3.12.3	media-info (text(255))

The "media-info" member attribute specifies information that helps describe the media instance for human consumption.  This attribute can also be used to distinguish two media instances for which all other member attributes (except "media-key", if implemented) are the same.  For example, this member attribute could be used to distinguish between self-sticking and moisture-required envelopes, both of which have a “media-type” value of ‘envelope’.      

The "media-info-supported" (boolean) Printer attribute indicates whether or not the Printer supports the "media-info" member attribute.

3.12.4	media-color (type3 keyword | name(MAX))

The "media-color" member attribute indicates the desired color of the media being specified. 

Standard keyword values for "media-color" are:

'no-color'	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.	
'gray'	The specified media should be gray.	
'ivory'	The specified media should be ivory.	
'orange'	The specified media should be orange.	

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 'blue', 'red', 'gray', 'ivory', 'orange', and 'no-color' (instead of 'transparent' - see ‘transparency’ in “media-type”, section 3.12.2). 

The "media-color-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute identifies the values of this "media-color" member attribute that the Printer supports, i.e., the colors supported.

The Administrator can define custom paper colors using the 'name' (MAX) attribute syntax  of the "media-color-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute.  Note: as with other Job Template and member attributes, the user can also supply user-defined color names that are not among the values of the “media-color-supported” Printer attribute, if the Administrator has configured the Printer's "user-defined-values-supported" attribute to contain the 'media-color' attribute keyword value (see section 5.1).

3.12.5	media-pre-printed (type3 keyword | name(MAX))

The "media-pre-printed" member attribute indicates that the pre-printed characteristics of the desired media.  Examples of pre-printed media include forms and company letterhead.  The standard keyword values for "media-pre-printed" are:

'blank'	The desired medium is not pre-printed.  The Printer MAY use an electronic representation of a form, if the medium has some imaged information already associated with it.  	
'pre-printed'	The desired medium is pre-printed; the other attributes identify which medium instance and so what is actually pre-printed.	
letter-head'	The site-defined letter head pre-printed is desired.	

The "media-pre-printed-supported" (1setOf (type3 keyword | name(MAX)) Printer attribute identifies the values of this "media-pre-printed" member attribute that the Printer supports.

3.12.6	media-hole-count (integer(0:MAX))

The "media-hole-count" member 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.

The "media-hole-count-supported" (1setOf rangeOfInteger(0:MAX)) Printer attribute identifies the ranges of values of this "media-hole-count" member attribute that the Printer supports.

3.12.7	media-order-count (integer(1:MAX))

The "media-order-count" member 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 in which all three forms are present has an order count of 3 (this is also sometimes called the modulus of the ordered media).  Full-cut tab stock MAY have an order count greater than 1 if it has an ordered sequence, such as a cycle of colors or cycle of pre-printing.

If the "media-order-count" is 1, then all media is the same.

The "media-order-count-supported" (rangeOfInteger(1:MAX)) Printer attribute identifies the range of values of this "media-order-count" member attribute that the Printer supports.

3.12.8	media-size (collection)

The "media-size" member attribute is a collection that explicitly specifies the numerical media width and height dimensions. 

It is RECOMMENDED that a client localize the collection values to the size names that users are familiar with, such as 'letter' and 'A4', possibly also including the exact dimensions as well (and in the units appropriate for the user's locale).  If a client does not recognize a pair of numbers as a named size, it can simply display the two numbers instead.  Thus the pair of size dimensions serve the same function as keyword values, except that the client has an obvious fallback display for an unrecognized pair, namely, the actual dimension numbers.

The "media-size" collection member attributes are:

Table 11 - "media-size" member attributes
Attribute name	attribute syntax	request	Printer Support	
x-dimension	integer (0:MAX)	MUST	MUST	
y-dimension	integer (0:MAX)	MUST	MUST	

3.12.8.1	x-dimension (integer(0:MAX))

Indicates the size of the media in hundredths of a millimeter along the bottom edge of the media.  See section 2.3 regarding the coordinate system.  This unit is equivalent to 1/2540 th of an inch resolution. 

3.12.8.2	y-dimension (integer(0:MAX))

Indicates the size of the media in hundredths of a millimeter along the left edge of the media.  See section 2.3 regarding the coordinate system.  This is equivalent to 1/2540 th of an inch resolution. 

3.12.8.3	media-size-supported (1setOf collection)

Indicates the sizes supported by the Printer.  A requested media size dimension matches a supported media dimension if it is within an implementation-defined tolerance.  For example, PostScript [redbook] specifies a tolerance of 5 points (5/72 of an inch = 1.7 mm) of a supported dimension, i.e., within 176 units of the value of the dimension.  

The "media-size-supported " collection member attributes are:

Table 12 - "media-size-supported" member attributes
Attribute name	attribute syntax	request	Printer Support	
x-dimension	integer (1:MAX) | rangeOfInteger (1:MAX)	MUST	MUST	
y-dimension	integer (1:MAX) | rangeOfInteger (1:MAX)	MUST	MUST	

3.12.8.3.1	x-dimension (integer(1:MAX) | rangeOfInteger(1:MAX))

Indicates the size of the media in hundredths of a millimeter along the bottom edge of the media.  This is equivalent to 1/2540 th of an inch resolution.  The rangeOfInteger attribute syntax accommodated variable size implementations, such as printers supporting adjustable input trays and web printers.  See section 2.3 regarding the coordinate system and section 5.1 regarding user-define media sizes. 

3.12.8.3.2	y-dimension (integer(1:MAX) | rangeOfInteger(1:MAX))

Indicates the size of the media in hundredths of a millimeter along the left edge of the media.  This is equivalent to 1/2540 th of an inch resolution.  The rangeOfInteger attribute syntax accommodated variable size implementations, such as printers supporting adjustable input trays and web printers.  See section 2.3 regarding the coordinate system and section 5.1 regarding user-defined media sizes. 

3.12.9	media-weight-metric (integer(0:MAX))

The "media-weight-metric" member attribute indicates the weight of the desired media rounded to the nearest whole number of grams per square meter.  

The "media-weight-metric-supported" (1setOf integer(MAX)) Printer attribute identifies the values of this "media-weight-metric" member attribute that the Printer supports, i.e., the weights supported in metric units.

3.12.10	media-front-coating (type3 keyword | name(MAX)) and media-back-coating (type3 keyword | name(MAX))

The "media-front-coating" and "media-back-coating" member attributes indicate what pre-process coating has been applied to the front and back of the desired media, respectively.  

Standard keyword values for "media-front-coating" and "media-back-coating" are:

'none'	Indicated that the media MUST not have any coating.	
'glossy'	Indicates that the media MUST have a "glossy" coating.	
'high-gloss'	Indicates that the media MUST have a "high-gloss" coating.	
'semi-gloss'	Indicates that the media MUST have a "semi-gloss" coating.	
'satin'	Indicates that the media MUST have a "satin" coating.	
'matte'	Indicates that the media MUST have a "matte" coating.	

The "media-front-coating-supported" (1setOf (type3 keyword | name(MAX))) and "media-back-coating-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute identifies the values of these "media-front-coating" and "media-back-coating" member attributes that the Printer supports.

3.12.11	media-recycled (type3 keyword | name(MAX))

The "media-recycled" member attribute indicates the recycled characteristics of the media.  The standard keyword values are:

'none'	The media MUST NOT be recycled.	
'standard'	The media MUST be the site-defined standard recycled stock.	

If this member attribute is supported, the Printer MUST support at least the 'none' and 'standard' values.

The "media-recycled-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute identifies the values of this "media-recycled" member attribute that the Printer supports, i.e., the recycled characteristics supported, which MUST include the 'none' keyword value so that validation follows the normal rules.  

3.12.12	media-default (type3 keyword | name(MAX)) and media-col-default (collection)

The "media-default" (see [RFC2911] section 4.2.11) and the "media-col-default" Printer attributes specify the media that the Printer uses, if the client omits both the "media" and the "media-col" Job Template attributes in the Job Creation operation (and the PDL doesn't include a media specification).  The member attributes are defined in Table 10.  A Printer MUST support the same member attributes for this default collection attribute as it supports for the corresponding "media-col" Job Template attribute.

The "media-default" and "media-col-default" Printer attributes MUST both be configured to specify the same media instance.  If the administrator sets one of them to a value (either locally or with the Set-Printer-Attributes operation - see [ipp-set]), the Printer MUST set the other attribute's value to specify the same media instance or to the 'unknown' out-of-band value, if there isn't a corresponding value to be set for the other attribute. If a client attempts to set both attributes, but their values specify different media instances, the Printer MUST reject the Set-Printer-Attributes operation and return the 'client-error-conflicting-attributes' status code.  The reason to have both default attributes configured, is so that clients that only know about the "media" attribute will see the "media-default" attribute, while clients that know about the "media-col" attribute will be able to determine the characteristics of the media default.

3.12.13	media-ready (1setOf (type3 keyword | name(MAX))) and media-col-ready (1setOf collection)

The "media-ready" (see [RFC2911] section 4.2.11) and "media-col-ready" Printer attribute identifies the media that are available for use without human intervention, i.e., the media that are ready to be used without human intervention.  The collection value MUST have all of the member attributes that are supported in Table 10.  If this attribute is supported, the Printer MUST support the IPP/1.1 "media-ready" (1setOf (type3 keyword | name(MAX))) Printer attribute also.  The i th value of the "media-ready" corresponds to the i th value of the "media-col-ready" attribute, so that the client can correlate the media name or keywords with the collection values, i.e., determine the characteristics of each ready media instance.

3.12.14	media-col-supported (1setOf type2 keyword)

The "media-col-supported" Printer attribute identifies the keyword names of the member attributes supported in the "media-col" collection Job Template attribute, i.e., the keyword names of the member attributes in Table 10 that the Printer supports. 

3.13	media-input-tray-check (type3 keyword | name(MAX))

The “media-input-tray-check” Job Template attribute indicates that the Printer MUST check that the characteristics of the media in the identified input tray are the same as characteristics of the media identified by the Job's "media" Job Template attribute or matched (see section 3.12) by the Job's "media-col" Job Template attribute.  The keyword values are the same input tray keyword values as are defined for the "media" Job Template attribute (see section 6.3 in this document and [RFC2911] Appendix C), i.e., 'top', 'middle', 'bottom', etc.

Independent of the "ipp-attributes-fidelity" operation attribute supplied by the client, if the characteristics differ, the Printer adds the ‘resources-are-not-ready’ value (see section 6.1) to the job's "job-state-reasons" attribute and MAY either (1) put the job into the ‘pending-held’ state or (2) start to process the job normally, but immediately stop the job (“job-state” = ‘processing-stopped’) and the Printer (“printer-state” = ‘stopped’).  In either implementation, the operator can change the media in the input tray to agree with the job or can modify the job’s “media” or “media-col” attributes to agree with the input tray, depending on policy.

3.14	page-delivery (type2 keyword) 

This attribute indicates whether print-stream pages of the job are to be delivered to the output bin or finisher in  the same page order as the original document, or, in reverse of that order, and, whether the print-stream pages are delivered face up or face down.  The "page-delivery" attribute specifies the intent based on the "original document" page order.  See section 2.4 for a complete discussion on the ordering of print-stream pages.

Standard keyword values for page delivery are:

'same-order-face-up'	The media sheets that represent the printed document MUST be delivered to the output bin or finishing device in the same order as defined by the "page-order-received" attribute.  Further, side one of each sheet MUST be delivered face up to the output bin or finishing device.	
'same-order-face-down'	The media sheets that represent the printed document MUST be delivered to the output bin or finishing device in the same order as defined by the "page-order-received" attribute.  Further, side one of each sheet MUST be delivered face down to the output bin or finishing device.	
'reverse-order-face-up'	The media sheets that represent the printed document MUST be delivered to the output bin or finishing device in the reverse order by the "page-order-received" attribute. Further, side one of each sheet MUST be delivered face up to the output bin or finishing device.	
'reverse-order-face-down'	The media sheets that represent the printed document MUST be delivered to the output bin or finishing device in the reverse order by the "page-order-received" attribute. Further, side one of each sheet MUST be delivered face down to the output bin or finishing device.	
'system-specified'	The Printer selects the most efficient delivery order based on other Job Template attributes supplied by the client, such as "finishings", “finishings-col”, and "page-order-received".	

The "page-delivery" attribute is often used in conjunction with on-line and off-line finishing devices.  The intent is to be able to deliver the media sheets in either the order of the page-stream pages as defined in the "original document" or in the reverse of that order.

3.14.1	Interaction with the "page-order-received" attribute

The "page-order-delivery" attribute is dependent on the value of the "page-order-received" attribute (defined in section 3.15 below):

"page-order-received"	"page-delivery"	Description of behavior	
'1-to-n-order'	'same-order-face-up'	The first print-stream page in the "document data" MUST be the first print-stream page delivered, followed by the second "print-stream" page, and so on.  Further, each media sheet MUST be delivered with side one of the sheet facing up. 	
'1-to-n-order'	'same-face-order-down'	The first print-stream page in the "document data" MUST be the first print-stream page delivered, followed by the second "print-stream" page, and so on.  Further, each media sheet MUST be delivered with side one of the sheet facing down. 	
'1-to-n-order'	'reverse-order-face-up'	The last print-stream page in the "document data" MUST be the first print-stream page delivered, followed by the second to last "print-stream" page, and so on. Further, each media sheet MUST be delivered with side one of the sheet facing up.	
'1-to-n-order'	'reverse-order-face-down'	The last print-stream page in the "document data" MUST be the first print-stream page delivered, followed by the second to last "print-stream" page, and so on. Further, each media sheet MUST be delivered with side one of the sheet facing down.	
'n-to-1-order'	'same-order-face-up'	The first print-stream page in the "document data" MUST be the first print-stream page delivered, followed by the second "print-stream" page, and so on.  Further, each media sheet MUST be delivered with side one of the sheet facing up.	
'n-to-1-order'	'same-order-face-down'	The first print-stream page in the "document data" MUST be the first print-stream page delivered, followed by the second "print-stream" page, and so on.  Further, each media sheet MUST be delivered with side one of the sheet facing down.	
'n-to-1-order'	'reverse-order-face-up'	The last print-stream page in the "document data" MUST be the first print-stream page delivered, followed by the second to last "print-stream" page, and so on.  Further, each media sheet MUST be delivered with side one of the sheet facing up.	
'n-to-1-order'	'reverse-order-face-down'	The last print-stream page in the "document data" MUST be the first print-stream page delivered, followed by the second to last "print-stream" page, and so on.  Further, each media sheet MUST be delivered with side one of the sheet facing down.	

3.15	page-order-received (type2 keyword)

This attribute specifies the page order of the print-stream pages defined in the document data.  The "page-order-received" attribute does not provide any direct processing instructions, it only provides information about the page order so that the client can specify ordinal page numbers with respect to the original source document, rather than having to take into account whether the print stream pages are being sent "one to N" or "N to one".  For example, consider such Job Template attributes as "insert-sheet" (section 3.4) and "page-overrides" (see [ipp-override]).  See section 2.4 for a complete discussion of print-stream page order.

Standard keyword values for "page-order-received" are:

'1-to-n-order'	The print-stream pages defined in the document data are in the same order as the original document.	
'n-to-1-order'	The print-stream pages defined in the document data are in the reverse order of the original document.	

The "page-order-received" attribute applies to all documents in a Job Creation or Document Creation request.  If a job consists of multiple documents, and all of the documents are not in the same page order, either '1-to-n-order' or 'reverse,' then inconsistent processing of other Job Template attributes that depend on "page-order-received" may occur. 

If the "page-order-received" attribute is not present in a Job Creation or Document Creation request, then the printer SHOULD assume a value of '1-to-n-order.'

3.16	presentation-direction (type2 keyword)

This attribute specifies the order that the Printer places page images on an impression (i.e. one side of a sheet). This attribute is especially useful to control the presentation direction in languages or multi-lingual documents that have more than one presentation direction, but may be used with any language. For example of the former, in Japanese text on pages can have a presentation direction that is either top-to-bottom-right-to-left or left-to-right-top-to-bottom.  For an example of the latter, a mixed English and Hebrew document, text on pages can have a presentation direction that is either left-to-right-top-to-bottom or right-to-left-top-to-bottom.  This attribute allows the client to specify the placement of page images on impressions to mirror the direction of the text on pages.

Each keyword value that a client supplies for this attribute MUST be a value of the “presentation-direction-supported (1setOf type2 keyword)” attribute. Table 13 below shows the standard values. A Printer MUST support at least one of value of Table 13. It MAY support any additional values from Table 13.

Table 13 shows the 8 standard values for this attribute. The name of each attribute value suggests the order of laying out pages on an impression when a human reader is holding the sheet in the proper orientation (i.e oriented so text is oriented for normal reading). For each ‘toxxx-toyyy’ value, the images are placed according to the ‘toxxx’ direction, and then according to the ‘toyyy’ direction, and the first image is placed in the corner diagonally opposite the ‘xxx-yyy’ corner.  For example, 'toright-tobottom' starts in the upper-left corner (which is diagonally opposite the ‘right-bottom’ corner). The images are placed from left to right in a line, and the line progression is from top to bottom.  

Table 13 has a separate column to show the order for each orientation. For example, if the orientation is ‘landscape’, then the order of pages appears to be the same as portrait if the viewer rotates the sheet 90 degrees clockwise.  Note: the coordinate system for this attribute is relative to the orientation of the sheets, unlike other Job Template attributes, such as “finishings”, “finishing-col” (see section 3.2), and the image shifting attributes (see section 3.18) which are absolute (i.e., as if the sheets were ‘portrait’ - see section 2.3).  The reason that this attribute has a relative coordinate system, is that the client may not know what the orientation of the document actually is, especially if the client did not generate the document.

The Printer determines the orientation in the following way:

1)	The value of the “orientation-requested” attribute is determined as follows:
a)	If the client supplies the “orientation-requested” attribute, that attribute specifies the orientation.
b)	If the client doesn’t supply the “orientation-requested” attribute and the Printer is able to determine the orientation by inspecting the document, that is the orientation.
c)	If the client doesn’t supply the “orientation-requested” attribute and the Printer is not able to determine the orientation by inspecting the document, the orientation is the value specified by the “orientation-requested-default” Printer attribute.
2)	The value of orientation used by the “presentation-direction” attribute for laying out pages on the impression is as follows:

a)	If the value of the “number-up” attribute is a power of 4, e.g. 1 and 4, the value from step 1 is the value.

b)	If the value of the “number-up” attribute is 2 times the power of 4, e.g. 2 and 8, the value is:
i)	‘landscape’ if the value from step 1 is ‘portrait’
ii)	‘portrait’ if the value from step 1 is ‘landscape’
iii)	‘reverse-landscape’ if the value from step 1 is ‘reverse-portrait’
iv)	‘reverse-portrait’ if the value from step 1 is ‘reverse-landscape’

c)	If the value of “number-up” is any other value, e.g. 3, 6 or 12, the value is IMPLEMENTATION DEFINED.

When a Printer lays out page images on one side of a sheet, the “presentation-direction” attribute determines the order of laying out each page and the frame of reference for that order is specified by the  orientation determined from the above algorithm. For example, if the value of “presentation-direction” is ‘toright-tobottom’ (English order), the Printer lays out 4 page images in the order of top-left, top-right, bottom-left and bottom-right in the frame of reference specified by the determined orientation. The top row of Table 13 shows this sample presentation direction.

If the Printer supports the “page-order-received” attribute and the value of the attribute is 'n-to-1-order', then the Printer MUST place the pages in reverse order on each impression. For example, if the “number-up” attribute has the value of 4, the first page of each impression is placed in the position labeled “4” in Table 13. If a Printer knows the number of pages in the document, it MUST treat the first impression as the logical last impression and place the first page according to the following formula:

P = ((N-1) mod n) + 1
Where P is the number of pages on the logical last image (first impression printed).
Where N is the number of pages in the document
Where n is the value of the “number-up” attribute
On the logical last page (first impression printed), the Printer MUST put the first page at position ‘P’ on the impression. 

A pictorial representation of each "presentation-direction" value for a "number-up" value of 4 and the orientation as shown below:
Table 13 - Standard Values for the “presentation direction” Attribute 
Value	Portrait	Landscape	Reverse-Landscape	Reverse-Portrait	
'toright-tobottom'					
'tobottom-toright'					
'toleft-tobottom'					
'tobottom-toleft'					
'toright-totop'					
'totop-toright'					
'toleft-totop'					
'totop-toleft'					

3.17	separator-sheets (collection)

This attribute specifies which separator sheets MUST be printed with the job.  Separator sheets are used to separate individual copies of a multiple copy job (i.e., when the "copies" attribute is greater than 1).  The "separator-sheets" attribute is dependent both on the value of "multiple-document-handling" and on the value of "sheet-collate" (see [ipp-prog]).  See sections 2.2 and 3.17.1 for a detailed description and examples of what constitutes a "set."

Separator sheets may either be non-imaged sheets, or may contain Printer generated information.

The 'collection' attribute syntax allows a client to specify media for job separator sheets that is different than the current media being used for the print-stream page impressions.  The collection consists of:

Table 14 - "separator-sheets" member attributes
Attribute name	attribute syntax	request	Printer Support	
separator-sheets-type	type3 keyword | name(MAX)	MUST	MUST	
media	type3 keyword | name(MAX)	MAY be neither or one of, but NOT both	MUST	
media-col	collection		MAY	

3.17.1	separator-sheet-type (type3 keyword | name(MAX))

The "separator-sheets-type" member attribute specifies which separator sheets type the Printer MUST use for the separator sheets.  Standard keyword values are:

'none'	No separator sheets are to be delivered with the printed output.	
'slip-sheets'	A separator sheet MUST be printed between "sets" of the job.  	
'start-sheet'	A separator sheet MUST be printed to indicate the start of each "set" of the job.	
'end-sheet'	A separator sheet MUST be printed to indicate the end of each "set" of the job.	
'both-sheets'	Separator sheets MUST be printed to indicate both the start and end of each "set" of the job.	

Example 1:  A job is created consisting of a single document, with the 
a)	the value of the "copies" attribute is '3', 
b)	the value of “job-sheets” attribute is ‘job-both-sheets’ (see section 6.2), and 
c)	the value of the "separator-sheets-type" attribute is 'slip-sheets'.  
If each of the 3 "sets" is denoted by (J1), (J2), (J3), a job-sheet is denoted by X, and a separator sheet is denoted by S, then the delivered output would be: X (J1) S (J2) S (J3) X If the value of the “separator-sheets-type” is ‘start-sheet’ instead, then the delivered output would be: X S (J1) S (J2) S (J3) X

Example 2:  A job is created consisting of two documents J and K, with
a)	the value of "copies" attribute is '3', 
b)	the value of “job-sheets” attribute is ‘job-both-sheets’ (see section 6.2), 
c)	the value of the "separator-sheets-type" attribute is 'slip-sheets', 
d)	the value of the “sheet-collate” attribute is ‘collated’ and 
e)	the value of the “multiple-document-handling” attribute is ‘separate-documents-uncollated-copies.  
If each of the  "sets" is denoted by (J1), (J2), (J3), (K1), (K2), (K3), a job-sheet is denoted by X, and a separator sheet is denoted by S, then the delivered output would be: X (J1) S (K1) S (J2) S (K2) S (J3) S (K3) X 

If for example 2, the value of the “separator-sheets-type” is ‘start-sheet’ instead, then the delivered output would be: X  S (J1) S (K1) S (J2) S (K2) S (J3) S (K3) X. 

If for example 2, the value of the “multiple-document-handling” attribute is ‘separate-documents-uncollated-copies, then the delivered output would be: X  (J1) S (J2) S (J3) S (K1) S (K2) S (K3) X. 

If for example 2, the value of the “sheet-collate” attribute is ‘uncollated’, then the delivered output would be: X  (JP1) S (JP2) S (JP3) S (KP1) S (KP2) X where JPn are 3 copies of page n of Job J and KPn are 3 copies of page n of Job K. Job J has 3 pages and Job K has two in this example.. 

The "separator-sheets-type-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute identifies the values of this "separator-sheet-type" member attribute that the Printer supports, i.e., the type names of the separator sheets.

3.17.2	media (type3 keyword | name(MAX)) or media-col (collection)

Either the "media" (defined in [RFC2911] section 4.2.11) or the "media-col" member attribute is used to indicate the media that the Printer MUST use for the job separator sheet.  The member attributes are the same as those for the "media-col" attribute shown in Table 10.  

If the client omits both the "media" and the "media-col" member attributes, then the implementation selects a media instance (by means outside the scope of this document) that is appropriate for separator sheets.  The client MUST NOT supply both the "media" and the "media-col" member attribute.  If client supplies such a mal-formed request by supplying both, the Printer MUST (depending on implementation) either (1) reject the request and return the 'client-error-bad-request' status code (see [RFC2911] section 13.1.4.1) or (2) use either the "media" or the "media-col" member attribute, independent of the value of the "ipp-attribute-fidelity" attribute supplied by the client.

Since this "media" member attribute has the same name as the "media" Job Template attribute defined in [RFC2911] section 4.2.11), the "media-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute (also defined in [RFC2911] section 4.2.11) identifies the values of this "media" member attribute (as well as the values of the "media" Job Template attribute) that the Printer supports, i.e., the names of the supported media.

Since this "media-col" member attribute has the same name as the "media-col" Job Template attribute defined in section 3.12), the "media-col-supported" Printer attribute (defined in section 3.12.14) identifies the keyword names of the member attributes supported in this "media-col" member attribute (as well as the keyword names of the "media-col" Job Template attribute), i.e., the names of the member attributes in Table 10 that the Printer supports.

3.17.3	separator-sheets-default (collection)

The "separator-sheets-default" Printer attributes specify the separator sheets that the Printer MUST provide, if any, if the client omits the "separator-sheets" Job Template attribute.  The member attributes are defined in Table 14.  A Printer MUST support the same member attributes for this default collection attribute as it supports for the corresponding "separator-sheets" Job Template attribute.

3.17.4	separator-sheets-supported (1setOf type2 keyword)

The "separator-sheets-supported" attribute identifies the keyword names of the member attributes supported in the "separator-sheets" collection Job Template attribute, i.e., the names of the member attributes in Table 14 that the Printer supports. 

3.18	Impression Image Shifting Attributes

The attributes defined in this sub-section shift the impression images as specified in the attribute definition.  The Printer MUST apply this shifting to the resulting impression after creating a single impression from a number of page images as specified by either (1) the "number-up" attribute (see [RFC2911] sections 4.2.9 and 15.3) or any other attribute that specifies imposition.  In other words, these attributes affect the impression, not individual page images.

The Printer determines the value for each attribute in this section as follows:
a)	if the client supplies a value and the Printer supports the attribute, the Printer uses that value, 
b)	otherwise, if the corresponding “xxx-default” attribute is configured, the Printer uses that value,
c)	otherwise, the Printer uses the value of 0 for  each integer valued attribute and ‘none’ for each keyword-valued attribute. These values cause the Printer to position the image as it normally would without these attributes.

To implement these attributes, the Printer first positions the impression image using the values it obtains for the “x-image-position” and “y-image-position” attributes. Then it shifts the impression image by the amount it obtains for the “x-image-shift” and “y-image-shift” attributes. Finally, for the front side of a sheet, it shifts the impression image by the amount it obtains for the “x-side1-image-shift” and “y-side1-image-shift” or for the back side of a sheet, it shifts the impression image by the amount it obtains for the “x-side2-image-shift” and “y-side2-image-shift” attributes.

3.18.1	x-image-position (type2 keyword) 

This attribute causes the specified edge of the impression image to be positioned at a specified location. One standard value causes the impression to be centered along the x-axis on the media to which it is applied. Two other standard values specify that the location is co-incident with the specified edge of the printable area by moving the image parallel to the x-axis on the media to which it is applied. 

Standard keyword values are:
‘none’	Place the impression wherever the print data specifies.	
‘center-on-media’	Center the impression between the physical edges of the medium by moving the impression in the direction parallel to the x-axis	
‘left’	Position the left edge of the impression image so that it is co-incident with the left edge of the printable area of the medium.  	
‘right’	Position the right edge of the impression image so that it is co-incident with the right edge of the printable area of the medium.  	

Note: the ‘center-on-media’ value is centered with respect to the physical edges of the medium rather than the printable area because the printable area may have different left and right margins. If there were two separate attribute, one for values that are medium-relative and one for values that are relative to printable area, the rules for defaulting would be complicated.

For example, if the print-stream image normally is placed on the media sheet as follows:

with the value of ‘center-on-media’, the result would be:

If the print-stream image normally is placed on the media sheet as follows where the dashed line indicates the edge of the printable area on the media sheet:

with the value of  'left', the result would be:

3.18.2	x-image-shift (integer(MIN:MAX))

This attribute causes the impression on both sides of each sheet, to be shifted in position with respect to the media on which the impression is to be rendered.  The direction of shift MUST be along the x-axis of the Coordinate System (see section 2.3) with respect to the medium. The sign of the value indicates the direction of the shift.  

The unit of measure for this attribute is hundredths of a millimeter.  This is equivalent to 1/2540th of an inch resolution.

3.18.3	x-side1-image-shift (integer(MIN:MAX)) 

This attribute causes the impression, on the front of each sheet, to be shifted in position with respect to the media on which the impression is to be rendered.  The direction MUST be along the x-axis of the Coordinate System (see section 2.3) with respect to the medium. The sign of the value indicates the direction of the shift.  

If the bind edge is along the y-axis, then a bind edge image shift can be accomplished by applying impression shifts of equal magnitude, and opposite sign, to the "x-side1-image-shift" and "x-side2-image-shift" attributes, respectively (assuming that the "sides" attribute is 'two-sided-long-edge').

The unit of measure for this attribute is hundredths of a millimeter.  This is equivalent to 1/2540th of an inch resolution.

3.18.4	x-side2-image-shift (integer(MIN:MAX))  

This attribute causes the impression, on the back of each sheet, to be shifted in position with respect to the media on which the impression is to be rendered.  The direction of shift MUST be along the x-axis of the Coordinate System (see section 2.3) with respect to the medium. The sign of the value indicates the direction of the shift.  

If the bind edge is along the y-axis, then a bind edge image shift can be accomplished by applying impression shifts of equal magnitude, and opposite sign, to the "x-side1-image-shift" and "x-side2-image-shift" attributes, respectively (assuming that the "sides" attribute is 'two-sided-long-edge').

The unit of measure for this attribute is hundredths of a millimeter.  This is equivalent to 1/2540th of an inch resolution.

3.18.5	y-image-position (type2 keyword) 

This attribute causes the specified edge of the impression image to be positioned at a specified location. One standard value causes the impression to be centered along the y-axis on the media to which it is applied. Two other standard values specify that the location is co-incident with the specified edge of the printable area by moving the image parallel to the y-axis on the media to which it is applied. 

Standard keyword values are:

‘none’	Place the impression wherever the print data specifies.	
‘center-on-media’	Center the impression between the physical edges of the medium by moving the impression in the direction parallel to the y-axis	
‘top’	Position the top edge of the impression image so that it is co-incident with the top edge of the printable area of the medium.  	
‘bottom’	Position the bottom edge of the impression image so that it is co-incident with the bottom edge of the printable area of the medium.  	

3.18.6	y-image-shift (integer(MIN:MAX))

This attribute causes the impression on both sides of each sheet, to be shifted in position with respect to the media on which the impression is to be rendered.  The direction of shift MUST be along the y-axis of the Coordinate System (see section 2.3) with respect to the medium. The sign of the value indicates the direction of the shift.  

The unit of measure for this attribute is hundredths of a millimeter.  This is equivalent to 1/2540th of an inch resolution.

3.18.7	y-side1-image-shift (integer(MIN:MAX)) 

This attribute causes the impression, on the front of each sheet, to be shifted in position with respect to the media on which the impression is to be rendered.  The direction of shift MUST be along the y-axis of the Coordinate System (see section 2.3) with respect to the medium. The sign of the value indicates the direction of the shift.  

If the bind edge is along the x-axis, then a bind edge image shift can be accomplished by applying impression shifts of equal magnitude, and opposite sign, to the "y-side1-image-shift" and "y-side2-image-shift" attributes, respectively (assuming that the "sides" attribute is 'two-sided-short-edge').

The unit of measure for this attribute is hundredths of a millimeter.  This is equivalent to 1/2540th of an inch resolution.

3.18.8	y-side2-image-shift (integer(MIN:MAX)) 

This attribute causes the impression, on the back of each sheet, to be shifted in position with respect to the media on which the impression is to be rendered.  The direction of shift MUST be along the y-axis of the reference coordinate system with respect to the medium. The sign of the value indicates the direction of the shift. 

If the bind edge is along the x-axis, then bind edge image shift can be accomplished by applying impression shifts of equal magnitude, and opposite sign, to the "y-side1-image-shift" and "y-side2-image-shift" attributes, respectively (assuming that the "sides" attribute is 'two-sided-short-edge').

The unit of measure for this attribute is hundredths of a millimeter.  This is equivalent to 1/2540th of an inch resolution.

3.19	Usage in Document-Overrides and Page-Overrides

Most of the Job Template attributes defined in this document are defined so that they MAY be used in the "document-overrides" (collection) and/or "page-overrides" (collection) Job Template attributes (see [ipp-override]).  According to that document, any Job Template attribute document MUST indicate the syntax and semantics for applying each Job Template attribute in any Document and/or Page overrides.

Table 16 augments the definitions of each Job Template attribute defined in this document by indicating with which parts of a job, the attribute "associates with" and "affects" (see [ipp-override]).  All Job Template attributes associate with the Job, so that is not indicated in Table 16.  A subset of the Job Template attributes are defined to be used in Document-Overrides to affect Input-Document and are associated with Input-Documents only via the "document-overrides" attribute.  Another subset affect Output-Documents and are associated with either Input-Documents or Output-Document via the "document-overrides" attribute.  A final subset of Job Template attributes affects Sheets, Pages, or Impressions and are associated with Pages of an Input-Document or an Output-Document by the "page-overrides" attribute or associated with Input-Document or Output-Document via a "document-overrides" attribute.  See [ipp-override] for the syntax of the "document-overrides" (1setOf collection), "page-overrides" (1setOf collection) and "page-per-subset" (1setOf integer(1:MAX)) and semantics of association with Document-Overrides, Page-Overrides, Sheets, and Pages.  The "pages-per-subset" attribute defines Output-Document to be subsets of pages within Input-Documents.

Table 15 lists the possible attribute override semantics for Job Template attributes and shows what clients can supply in Job Creation operations.
Table 15 - Job Template Attribute Override Semantics
Affects	Associates With	Override attribute	member attributes	
Job	Job	none	N/A	
Input-Document	Input-Document	"document-overrides"	"input-documents"	
Output-Document	Output-Document	"document-overrides"	"output-documents"	
		"pages-per-subset"	N/A	
	Input-Document	"document-overrides"	"input-documents"	
sheet, impression	Output-Page	"page-overrides"	"output-documents", "pages"	
	Input-Page	"page-overrides"	"input-documents", "pages"	
	Output-Document	"document-overrides"	"output-documents"	
		"pages-per-subset"	N/A	
	Input-Document	"document-overrides"	"input-documents"	

A client MUST NOT submit and a Printer MUST NOT support a Job Creation request with "document-overrides" (collection), "page-overrides" (collection), or "pages-per-subset" containing member attributes not indicated in Table 15 depending on what the Job Template attribute is defined to affect as indicated in Table 16.  If a client submits a Job Creation request with such a member attribute and "ipp-attribute-fidelity" = 'true', the Printer MUST reject the request and return the 'client-error-bad-request' status code.  If a client submits a Job Creation request with such a member attribute and "ipp-attribute-fidelity" = 'false' or omitted, the Printer MUST accept the request and return the 'successful-ok-ignored-or-substituted-attributes' status code, along with the collection and only those member attributes. 

Table 16 - Document and Page Override Semantics by Attribute
Section or Attribute	Affects:	
3.1 cover-front (collection) and cover-back (collection)	Output-Documents	
3.2 finishings-col (collection)	Output-Documents	
3.3 force-front-side (1setOf integer(1:MAX))	Input-Documents	
3.4 insert-sheet (1setOf collection)	Output-Documents	
3.5 job-account-id (name(MAX))	Job	
3.6 job-accounting-user-id (name(MAX))	Job	
3.7 job-accounting-sheets (collection)
	Job	
3.8 job-error-sheet (collection)	Job	
3.9 job-message-to-operator (text(MAX))	Job	
3.10 job-sheets-col (collection) - augments  IPP "job-sheets" attribute	Job	
3.11 job-sheet-message (text(MAX))	Job	
3.12 media-col (collection) - augments IPP "media"	Sheets	
3.13 media-input-tray-check (type3 keyword | name(MAX))	Sheets	
3.14 page-delivery (type2 keyword)	Output-Documents	
3.15 page-order-received (type2 keyword)	Input-Documents	
3.16 presentation-direction (type2 keyword)	Image	
3.17 separator-sheets (collection)	Job	
3.18.1 x-image-position (type2 keyword) through
3.18.8 y-side2-image-shift (integer(MIN:MAX))	Impressions	

4.	Job Description Attributes

This section defines Job Description attributes for use with IPP/1.0 [RFC 2566] and IPP/1.1 [RFC2911].

4.1	current-page-order (type2 keyword) 

This attribute represents the current page order of the document data supplied with the job.  Initially "current-page-order" is set to the value of the Job Template attribute "page-order-received."  The value of "current-page-order" may change based on processing and the value of the "page-order-delivery" attribute.  If the Printer changes the value of a Job's "current-page-order" Job Description attribute, then it is assumed that the associated document data has been transformed in some way to reflect this change.  It should be noted that the document data that "current-page-order" refers to is not always the document data sent with the Job Creation request, but may also refer to the processed images that are to be delivered to the printer.  The standard values for this attribute are the same as for of the "page-order-received" attribute (see section 3.15), namely, '1-to-n-order' and 'n-to-1-order'.

5.	Printer Description Attributes

This section defines Printer Description attributes for use with IPP/1.0 [RFC 2566] and IPP/1.1 [RFC2911].

5.1	user-defined-values-supported (1setOf type2 keyword)

This Printer attribute identifies the Job Template and Job Template member attributes for which the client can supply any value in a Job Creation request, i.e., any custom or user-defined value.  The values of this attribute are any "xxx" attribute names that are Job Template attributes or member attributes of a Job Template collection attributes for which the Printer will accept any value in a Job Creation request.  In effect, the presence of the 'xxx' keyword value in this attribute suspends validation of the "xxx" attribute supplied by the client with the values of the corresponding "xxx-supported" Printer attribute.  This feature MAY be used to specify any 'name', 'integer', or 'collection' (whose member attributes are 'name' or 'integer') attributes supplied by the client.  Thus a user can supply a custom name for this "xxx" attribute.  If there are no Job Template attributes that will accept any value, the value of this attribute MUST be the keyword 'none'.

For any "xxx" Job Template or Job Template member attributes identified by this attribute, the Printer suspends validation for values of type 'name', 'integer', and 'collection' and the job is created containing the user-defined value, even when the client supplied the "ipp-attribute-fidelity" with a 'true' value (which would otherwise, have caused the Printer to reject the request, if the "xxx" value had not been among those of the Printer's "xxx-supported" attribute).

For example, the system administrator could add the 'media' keyword attribute name value to the "user-defined-values-supported" Printer attribute in order to allow the user to supply any media name value for the "media" attribute even if that name wasn't one of the media names in the Printer's "media-supported" (1setOf (type3 keyword | name(MAX))) attribute.  As another example, the system administrator could add the 'media-size' keyword attribute name value to the "user-defined-values-supported" Printer attribute in order to allow the user to supply any media size x and y dimensions in the “media-size” member attribute of the “media-col” Job Template attribute, even if that pair wasn't one of the pairs in the Printer's "media-size-supported" (1setOf collection) attribute.

Keyword values include the IPP/1.1 Job Template attribute name keywords: 'job-priority', 'job-sheets', 'job-hold-until', 'number-up', and 'media', along with the Job Template and member attributes defined in this document: 'finishings-col', 'stitching-offset', 'stitching-locations', 'job-error-sheet-type', 'media-type', 'media-color', 'media-pre-punched', 'media-hole-count', 'media-order-count', 'media-size', 'media-weight-metric', 'media-front-coating', 'media-back-coating', 'media-recycled', and 'separator-sheet-type'.  

Note: The requirement that the "media-key" member attribute values of the "media-col" attribute be unique and that each supported media have a distinct value precludes the 'media-key' from being a value of the "user-defined-values-supported" Printer attribute.

When the client supplies a 'yyy' value for the "xxx" attribute that is not in the "xxx-supported" Printer attribute, the Printer does not return the "xxx" value in the Unsupported Attributes group in the response.  Instead, the Printer stores the requested attribute and value unmodified on the Job object for subsequent queries as with any supported value.  Subsequently, a user or operator can query the Job using the Get-Job-Attributes or Get-Jobs operations to see what user-defined value was requested.  Depending on implementation and/or site policy, the Printer schedules the job following one of the following options:

1.	Add the 'resources-are-not-supported' value (see section 6.1) to the Job's "job-state-reasons" attribute and move the job to the 'pending-held' state until either the operator adds the requested value to the Printer's "xxx-supported" attribute or the user or operator modifies the job to contain a value that is in the Printer's "xxx-supported" attribute; then releases the job using the Release-Job operation (see [RFC2911] section 3.3.6).

2.	Add the 'resources-are-not-supported' value (see section 6.1) to the Job's "job-state-reasons" attribute but keep the job in the 'pending' state and start to process the job as if the requested media were ready, but stop the job ("job-state" = 'processing-stopped') and the Printer ("printer-state" = 'stopped') and request immediate operator intervention.  The operator loads the requested media and continues the Printer, using the Resume-Printer operation (see [RFC2911] section 3.2.8).

5.2	max-stitching-locations-supported (integer(1:MAX))

This attribute indicates the maximum number of stitches or staples that the implementation is capable of inserting into an Output Document, even if that number would require human intervention in order to configure the (manual configured) stitcher.  In other words, "max-stitching-locations-supported" attribute specifies the maximum number of values that the client can supply in the "stitching-locations" member attribute (see section 3.2.2.3).

Note:  the client can determine the number of stitches or staples that the client can request without human intervention by querying the "finishing-col-ready" attribute (see section 3.2.4).

5.3	finishings-ready (1setOf type2 enum)

This attribute differs from "finishings-supported" in that legal values only include the subset of "finishings-supported" values that are physically ready for printing with no operator intervention required.  The "finishings-ready" attribute is useful for Printers where human intervention is required in order to change the finisher in order for a job to use certain "finishings" values.  If all "finishings-supported" values can be used without human intervention, a Printer NEED NOT implement the "finishings-ready" attribute.  If an IPP Printer supports "finishings-supported" (see [RFC2911] section 4.2.6, it NEED NOT support "finishings-ready".  However, if a Printer supports "finishings-ready", it MUST support "finishings-supported".

6.	Additional Values for Existing Attributes

This section defines additional values for existing attributes.

6.1	Additional values for the "job-state-reasons" Job attribute

This section defines additional values for the "job-state-reasons" (1setOf type2 keyword) Job Description attribute (see [RFC2911] section 4.3.8):

'resources-are-not-supported':  At least one of the resources needed by the job, such as media, fonts, resource objects, etc., is not supported 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 (1) remain in its current state, (2) be moved to the 'pending-held' state, depending on implementation and/or job scheduling policy, or (3) scheduled normally, but the Printer is put into the 'stopped' state when the job is attempted to be processed on the Printer.  This value is intended for use with an implementation that supports the "user-defined-values-supported" Printer attribute (see section 5.1) which allows a job to be accepted with an unsupported 'name' value.

6.2	Additional values for the IPP "job-sheets" Job Template Attribute

 The following additional values are defined for the IPP/1.1 "job-sheets" Job Template attribute:

Table 17 - Additional values for the "job-sheets" Job Template attribute
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-both-sheets	Job sheets MUST be printed to indicate the start and end of all the output associated with the job.	
first-print-stream-page	Some users have customized the banner sheets in their environment (Microsoft, Novell, etc.) and prefer them instead of the printer's standard ones.  The custom banner sheet is the first page of the PDL.  When the client supplies the 'first-print-stream-page' value, the first page in the document data is printed as the job sheet and the printer's standard job sheet is suppressed.	

6.3	Additional values for the IPP "media" Job Template and "media-key" member attributes

This section defines additional values for the "media" (type3 keyword | name(MAX)) Job Template attribute (see [RFC2911] section 4.2.11), the "media" member attribute defined in this document in a number of the collection attributes, and the "media-key" member attribute defined in section 3.12.1:

If the Printer implementation supports the use of tray name keywords to identify media, there SHOULD be one and only one keyword assigned for each input tray on the printer.  If multiple keywords for the same tray exist in "media-supported", the client UI could potentially become very confusing to the user because the Printer would appear to have more input trays than it actually has.  However, see the discussion in the Printer MIB [RFC1759] about a manual input tray that uses the same input slot as a regular input tray.  Also, if using tray names, it is RECOMMENDED that the printer implementation use the most descriptive keyword for a logical tray in order to assist the user or operator to recognize the matching physical tray at the printer.  There are three methods to choose the keyword: 1) If the printer trays aren't physically labeled, the keyword SHOULD best match the physical location of the tray (e.g. 'top', 'bottom').  2) If the printer trays are physically labeled, the keyword SHOULD best match the label of the tray (e.g. 'tray-1', tray-2'),   3) If more than one keyword matches the label of the tray, the keyword SHOULD be used that best distinguishes the tray from the Printer's other trays.

If a Printer allows the media to be specified by tray name keyword, the Printer implementation MUST NOT use the 'name(MAX)' attribute syntax to create custom tray names, but rather MUST use the most appropriate tray name keyword value.  This ensures interoperability among clients that submit jobs to multiple types of printers.

These are additional standard keyword values defined for input-trays.

'bypass-tray'	The specified tray is used for handling odd or special paper.  This paper tray usually has a small capacity and is physically located such that the paper travels through a shorter paper path.  In some printer implementations, the 'bypass-tray' may also be used to bypass any marking device and be used for insert sheets.  See the "insert-sheet" definition in section 3.4.	
'tray-N'	The input tray that is best specified as a tray with values 'tray-1', 'tray-2'….  The correspondence between the 'tray-N' keyword and the actual input-tray is implementation dependent, as is the number of input trays.  If this group of 'tray-N' values is supported, at least the 'tray-1' value MUST be supported.	

These additional keyword values are provided for use in implementations that don't support the "media-col" attribute, since they represent some of the more important "media-col" member attributes:

'plain'	The plain media as specified by the output device.	
'pre-punched'	The pre-punched media as specified by the output device.	
'transparency'	The transparent media as specified by the output device.	
'letterhead'	The pre-printed letterhead media as specified by the output device.	
'heavyweight'	The heavyweight media as specified by the output device.	
'recycled'	The recycled media as specified by the output device.	
'bond'	The bonded media as specified by the output device.  	
'labels'	The labels media as specified by the output device.	
'pre-printed'	The pre-printed media as specified by the output device.	
'customN'	A custom type of media understood by the user and the operator.  It is simply specified to the Printer as the keyword values 'custom1', 'custom2'…'custom7'.	

These additional keyword values are the same as the "media-type" keywords (see section 3.12.2), except 'other', for use in implementations that don't support the "media-col" attribute:

stationery
envelope
envelope-plain
envelope-window
continuous
continuous-long
continuous-short
tab-stock
pre-cut-tab
full-cut-tab
multi-part-form
multi-layer
screen
screen-paged

These are additional standard keyword values which are used by the implementation for specifying a pre-defined media size:

'iso-a4-wide'	Specifies the iso A4 cover size: 223 mm x 297 mm	
'na-letter-cover'	Specifies the letter cover size:  9 in x 11 in	
'jp-reply-postcard'	Specifies the Ofuku-Hagaki postcard size: 148 mm x 200 mm	
'na-postcard'	Specifies the North American postcard size: 4.5 in x 6 in	
'na-8x10'	Specifies the 8x10 inch size.	
'na-5x7'	Specifies the 5x7 inch size.	
'taiwan-815'	Specifies the 815 Taiwan size: 267 mm x 388 mm	
'iso-220x330'	Specifies the 220 mm x 330 mm size	

7.	Conformance Requirements

This section summarizes the Conformance Requirements detailed in the definitions in this document for clients and Printer objects (servers or devices).  

7.1	Conformance Requirements for Printer objects

In general each of the attributes defined in this document are OPTIONAL for a Printer to support, so that Printer implementers MAY implement any combination of attributes.  Only the following conditional conformance requirements are defined:

If the Printer supports:	then the Printer MUST also support (but vice-versa is OPTIONAL):	
"cover-back"	"cover-front"	
"finishings-col"	"finishings" (see [RFC2911] section 4.2.6)	
"finishings-col-ready"	"finishings-ready (see section 5.3)	
"job-sheets-col"	"job-sheets" (see [RFC2911] section 4.2.3)	
"media-col"	"media" (see [RFC2911] section 4.2.11)	
"media-col-ready"	"media-ready (see [RFC2911] section 4.2.11)	
"media-input-tray-check"	"media" (see [RFC2911] section 4.2.11) and/or "media-col"	
"x-side2-image-shift"	"x-side1-image-shift"	
"y-side2-image-shift"	"y-side1-image-shift"	
"x-side1-image-shift"	"x-image-shift"	
"y-side1-image-shift"	"y-image-shift"	

Each of the collection attribute definitions indicate which member attributes are REQUIRED and which are OPTIONAL for a Printer to support and is not repeated here.

If a Printer supports the 'collection' attribute syntax of a Job Template attribute , then it MUST support the distinguished none value defined for that collection.  See section 2.6.

Support of the 'name' attribute syntax for Job Template attributes and collection member attributes is OPTIONAL, as in IPP/1.1 [RFC2911].

7.2	Conformance Requirements for clients

Clients that support two Job Template attributes that control the same aspect, such as "media" and "media-col", MUST NOT supply both in a Job Creation request as indicated in the definitions of these attributes.  

Clients that support a "xxx" collection Job Template attribute SHOULD use the Get-Printer-Attributes request to obtain the "xxx-default" collection and display that to the user, so that the user can make any changes before submitting the Job.  Then the client submits values for all member attributes, rather than depending on the Printer's defaulting for omitted member attributes, since such defaulting is implementation dependent and will vary from Printer to Printer.

8.	IANA Considerations

IANA will be called on to register the attributes defined in this document, using the procedures outlined in [RFC2911] section 6.

9.	Internationalization Considerations

The IPP extensions defined in this document require the same internationalization considerations as any of the Job Template attributes defined in IPP/1.1 [RFC2911].

10.	Security Considerations

The IPP extensions defined in this document require the same security considerations as any of the Job Template attributes defined in IPP/1.1 [RFC2911].

11.	References

[ipp-admin-ops]
	Kugler, C, Hastings, T., Lewis, H., "Internet Printing Protocol (IPP): Job and Printer Administrative Operations", <draft-ietf-ipp-ops-set2-01.txt>, July 19, 2000.
[ipp-coll]
	deBry, R., , Hastings, T., Herriot, R., "Internet Printing Protocol (IPP): collection attribute syntax", <draft-ietf-ipp-collection-01.doc>, work in progress, May 5, 2000.
[ipp-override]
Ocke, K., Herriot, R., "Internet Printing Protocol (IPP):  Override Attributes for Documents and Pages", <pwg-ipp-exceptions-model-000915.doc>, work in progress, September 15, 2000.
[ipp-prog]
Hastings, T., Bergman, R., Lewis, H., "Internet Printing Protocol (IPP): Job Progress Attributes", <draft-ietf-ipp-job-prog-01.txt>  work in progress, August 30, 2000.
[pwg-output-bin]
	Hastings, T., and R. Bergman, “Internet Printing Protocol (IPP): output-bin attribute extension”, <work in progress>.
[redbook]
	"PostScript(R) LANGUAGE REFERENCE, third edition", Adobe Systems Incorporated, February 1999.
[REG]
	Holtman, K., Mutz, A. and T. Hardie, "Feature Tag Registration Procedures", BCP 31, RFC 2506, March 1999.
[RFC1759]
	Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, J., "Printer MIB", RFC 1759, March 1995.
[RFC2119]
	S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119 , March 1997
[RFC2534]
	Masinter, L., et al, “Media Features for Display, Print, and Fax”, RFC 2534, March 1999.
[RFC2565]
	Herriot, R., Butler, S., Moore, P., and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2566]
	deBry, R., , Hastings, T., Herriot, R., Isaacson, S., Powell, P., "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999.
[RFC2910]
	Herriot, R., Butler, S., Moore, P., Turner, R., and J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 2000.
[RFC2911]
	Hastings, T., Herriot, R., deBry, R., Isaacson, S., and P. Powell, "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, September 2000.

12.	Author's Addresses

Kirk Ocke
Xerox Corporation
800 Phillips Road
Webster, NY 14580

Phone: 716 422-4832
e-mail:  Kirk.Ocke@usa.xerox.com

Tom Hastings
Xerox Corporation
737 Hawaii St.  ESAE 231
El Segundo, CA  90245

Phone: 310-333-6413
Fax: 310-333-5514
e-mail: hastings@cp10.es.xerox.com

IPP Web Page:  http://www.pwg.org/ipp/
IPP Mailing List:  ipp@pwg.org

To subscribe to the ipp mailing list, send the following email:
1) send it to majordomo@pwg.org
2) leave the subject line blank
3) put the following two lines in the message body:
subscribe ipp
end

Implementers of this specification document are encouraged to join IPP Mailing List in order to participate in any discussions of clarification issues and review of registration proposals for additional attributes and values.

Other Participants:
Ron Bergman - Hitachi Koki Imaging Systems	Dan Calle - Digital Paper	
Weihai Chen - Microsoft	Lee Farrell - Canon Information Systems	
Satoshi Fujitani - Ricoh	Roelof Hamberg - Océ	
Tom Hastings - Xerox	Bob Herriot - Xerox	
David Kellerman - Northlake Software	Carl Kugler - IBM	
Harry Lewis - IBM	Carl-Uno Manros - Xerox	
Satoshi Matsushita - Brother	Ira McDonald - High North Inc.	
Paul Moore - Netreon	Hugo Parra, Novell	
Stuart Rowley - Kyocera	Gail Songer - Netreon	
Geoff Sorod - Software 2000	Jerry Thrasher - Lexmark	
Shinichi Tsuruyama - Epson	Atsushi Uchino - Epson	
Shigeru Ueda - Canon	William Wagner - NetSilicon/DPI	
Mark Vander Wiele - IBM	Don Wright - Lexmark	
Michael Wu - Heidelberg Digital	Peter Zehler - Xerox	

13.	Appendix A: Change History

This section summarizes the changes to the document.  Each sub-section is in reverse chronological order.  Adding or removing ISSUES that don't change the document are not listed here.  

13.1	Changes to the June 5, 2000 to create the October 26, 2000 version

The following changes were made to the June 5, 2000 version to create the October 26, 2000 version from the PWG IPP WG review in Chicago, September 13, 2000 and subsequent IPP telecons:

1.	Added "finishings-col" (collection) to control placement of staples which also requires the implementation of the "media" Job Template attribute in RFC 2911.
2.	Added “force-front-side” (1setOf integer(1:MAX)) Job Template attribute to force a page to the front side of the medium.
3.	Changed “job-account-id-supported” (integer(1:255)), “job-message-to-operator-supported” (integer(0:1023)), and “job-sheet-message-supported” (integer(0:1023)) to boolean on the grounds that conforming implementations are supposed to implement the maximum length and no one wanted to shorten the maximum in the spec.
4.	Added "job-accounting-user-id" Job Template attribute to go with "job-account-id".
5.	Added "job-accounting-output-bin" member attribute to the "job-accounting-sheets" collection to control the output bin.
6.	Removed “job-recipient-name” to a separate IETF spec, since it needs to be an IETF document, while the Production Printing Extension remains a PWG document.
7.	Specified how the matching algorithm works for "media-col" and what is IMPLEMENTATION-DEPENDENT.
8.	Added "media-key" member attribute to "media-col" collection as a unique key for media which must be present if implemented and removed "media-description" member attribute (which was neither unique nor required on all values when implemented - it was more like a “nick” name).
9.	Removed "media-opacity", "media-tabs", and "media-label-type" member attribute of the "media-col" Job Template attribute and added "media-type" member attribute with Printer MIB and Internet FAX Media type values to represent these media types.  Added 'full-cut-tab' and 'pre-cut-tab' values to disambiguate between these two forms of 'tab-stock' values.  Also added 'other' to cover cases when no supported keyword or name will do.
10.	Added "media-info" (text(255)) member attribute to give a text description of the media for human consumption.
11.	Changed the 'clear' "media-color" to 'no-color' to be clearer.
12.	Clarified that full-cut tabs can have a "media-order-count".
13.	Changed the lower limit of the "media-size" dimension attributes from 0 to 1.
14.	Clarified that the rangeOfInteger in media-size-supported can be used by Printers with adjustable input trays.
15.	Deleted “media-weight-english” member attribute as an unwanted supplemental attribute to “media-weight-metric” which is in metric units.
16.	Deleted the 'any' value from the "media-front-coating" and "media-back-coating" member attributes of the "media-col" attribute.  Matching a client supplied value of 'any' with 'any' in the supported list is straight forward, but then selecting the actual media instance is a special case.  It is simpler to allow the user to select one of the defined values.
17.	Added the "media-input-tray-check" Job Template attribute to control checking the media in a specified input tray.
18.	Added “presentation-direction” (type2 keyword) Job Template attribute to specify the direction that number up page images are to be placed on a side.
19.	Changed the 'wrap-sheets' value for "separator-sheet-type" to 'both-sheets'.
20.	Renamed the “x-auto-center” and “y-auto-center” attributes to “x-image-position” and “y-image-position” attributes with type2 keyword data types.  The values are ‘none’, ‘center-on-media, ‘left’, ‘right’ and ‘none’, ‘center-on-media, ‘top’, ‘bottom’, respectively.
21.	Renamed "user-defined-names-supported" Printer Description attribute to "user-defined-values-supported" and generalized it to allow the administrator to establish the policy to allow users to supply any integer values for integer attributes and collection values for collection attributes as well.
22.	Added "max-stitching-locations-supported" Printer Description attribute to indicate the maximum number to stitches/staples per sheet.
23.	Added "finishings-ready" (1setOf type2 enum) to specify the finishing that doesn't require operator intervention for use in systems where operator intervention MAY be required to changes the finisher.
24.	Changes the 'job-wrap-sheets' value of "job-sheets" to 'job-both-sheets' to give a more understandable name.
25.	Added more "media" keyword values.

13.2	Changes to the May 9, 2000  to create the June 5, 2000 version

The following changes were made to the May 9, 2000 version to create the June 5, 2000 version:

1.	Added the "cover-type-supported" Printer attribute.

2.	REQUIRED (rather than RECOMMENDED) the Printer to make the "job-sheets-default" and "job-sheets-col-default" Printer attributes identify the same job sheet instance or have one of them set to the 'unknown' out-of-band value.

3.	REQUIRED (rather than RECOMMENDED) the Printer to make the "media-default" and "media-col-default" Printer attributes identify the same media instance or have one of them set to the 'unknown' out-of-band value.

4.	Added the 'system-specified' keyword value to the "page-delivery" Job Template attribute.

13.3	Changes to the April 26, 2000  to create the May 9, 2000 version

The following changes were made to the April 26, 2000 version to create the May 9, 2000 version:

1.	Clarified that both the "job-sheets-default" and "job-sheets-col-default" Printer attributes SHOULD both be configured to specify the same job-sheet instance.
2.	Changed the "media-description" member attribute back to 'type3 keyword | name(MAX)' from 'text' so that clients can localize the value and the "media-description-supported" back to '1setOf (type3 keyword | name(MAX) from 'integer(0:255)'.
3.	Deleted the "media-weight-type" attribute - don't have two ways to specify the same thing until there is a way to indicate which one the Printer supports.
4.	Replaced the "media-weight" and "media-weight-units" with "media-weight-metric" and "media-weight-english", so that implementations can support "media-weight-metric" only or both and clients can request either.
5.	Clarified that the "media-size" tolerance is implementation-defined.  The 5 points tolerance for PostScript is given as an example.
6.	Removed "-supported" from the "x-dimension" and "y-dimension" member attributes to agree with the collection specification.
7.	Clarified that both the "media-default" and "media-col-default" Printer attributes SHOULD both be configured to specify the same media instance.
8.	Changed "job-separator-sheets" collection attribute so that if the client supplies neither the "media" or the "media-col" member attributes, the implementation picks some appropriate separator sheet medium, rather that using the document's media.
9.	Added the 'first-print-stream-page' keyword value to the "job-sheets" Job Template attribute.

13.4	Changes to the April 11, 2000  to create the April 26, 2000 version

The following changes were made to the April 11, 2000 version to create the April 26, 2000 version:

1.	Added discussion about distinguished none values for all but a few Job Template attributes.
2.	Clarified the table and language for collections that have both "media" and "media-col" around the client sending neither (error for some collection attributes, not for others), one or the other, or both (error).
3.	Removed the use of the 'none' out-of-band value and defined distinguished values for keywords (usually 'none', or 'no-xxx'), strings (zero-length), and integers (usually 0) instead.  Existing clients and Printers might get confused with the (new) 'none' out-of-band value.
4.	Broke "job-error-sheet-type" into two member attributes:  "job-error-sheet-type" and "job-error-sheet-when".
5.	Removed the "s" from "job-error-sheet".
6.	Banned "media-default" and "media-col-default" from both having a value, even if one is the name of the other.  Required the Printer to set the other to 'no-value' out-of-band value.
7.	Added "media-label-type" (type3 keyword | name(MAX)), and "media-recycled" (type3 keyword | name(MAX)) member attributes to "media-col".
8.	Changed the "xxx-supported" (boolean) to "xxx-supported" (integer(0:X) so that the maximum length of the string could be queried by the client.
9.	Added 'gray', 'ivory', and 'orange' colors
10.	Changed media-pre-printed (boolean) to media-pre-printed (type3 keyword | name(MAX)) and defined 'blank',  'pre-printed', and 'letter-head'.
11.	Removed -supported from the member attributes of the "media-col-supported" (1setOf collection).
12.	Added 'none' keyword value to media-front-coating (type3 keyword | name(MAX)) and media-back-coating (type3 keyword | name(MAX))
13.	Replaced the 'user-define' and 'user-define-supported' out-of-band values with the "user-defined-names-supported" Printer attribute.  This will help existing clients that query the Printer.
14.	Added some "media" keyword values.
15.	Enhanced the Conformance Section with client requirements.

13.5	Changes to the February 7, 2000  to create the April 11, 2000 version

The following changes were made to the February 7, 2000 version to create the April 11, 2000 version:

1.	Clarified that the "page-ranges" Job Template attribute does not affect the print-stream page numbering.
2.	Aligned the collection attribute definitions to agree with the updated Collection [ipp-coll] document:
a)	Changed "xxx-supported"(boolean) to "xxx-supported" (1setOf type2 keyword) to return the keyword names of the member attributes.
b)	Removed the 'type3 keyword | name' attribute syntaxes from "xxx" (type3 keyword | name | collection) attributes and moved those values into a new "xxx-type" member attribute in the collection for new attributes.  For the existing IPP/1.1 "job-sheets" (type3 keyword | name) and "media" (type3 keyword | name) attributes created new "xxx-col" (collection) companion attributes.
c)	For each collection attribute that had a "media" (type3 keyword | name(MAX) | collection) member attribute, removed the 'collection' and added a new OPTIONAL "media-col" (collection) member attribute to carry the media characteristics.
d)	Clarified that a client MUST NOT supply both "media" and a "media-col" Job Template attributes or member attributes.  If a Printer receives such a bad request, it MUST either reject it or use one or the other attributes depending on implementation.
e)	Add prefix names to member attributes when they are intended to be unique, such as "cover-" to "cover-printed-sided" so that the "xxx-supported" would not be ambiguous.  Same for "insert-" to insert-after-page-number" and "insert-count".
f)	Added "xxx-default" (collection) for all collection attributes for consistency as required by [ipp-coll].
g)	Added "xxx-supported" Printer attributes for all member attributes for consistency as required by [ipp-coll].
3.	Removed the prefix from the "media" and the "media-col" member attributes, so that they are the same as the IPP/1.1 Job Template attributes.
4.	Added the insert-after-page-number-supported" (1setOf type2 keyword) Printer attribute for consistency.
5.	Added that a value of MAX for "insert-after-page-number" inserts a page after the last page in the document no matter how many pages are in the document.
6.	Changed "insert-sheet" to agree with the Exceptions document [ipp-except], so that if a page number is not the first on a sheet, the insert happens after that sheet, and the page is forced to the next sheet and a warning given using the "job-warnings-count" Job Description attribute and the Job's 'job-warnings-detected' job-state-reasons.
7.	Add the "insert-count-supported (integer(1:MAX)) Printer attribute for consistency.
8.	Clarified that the "media" attribute maps a name or keyword to a media instance, but that not all media instances need have an associated media name or keyword.  Also that no two media instances can have the same "media" attribute name or keyword.
9.	Clarified that that the "media-col" collection attribute maps a set of characteristics to a media instance and that all media instances must have a distinct set of characteristics, not counting their names.  The "media-description" member attribute can be used as a characteristics to distinguish two otherwise identical media instances.
10.	Changed the name of the "media-name" member attribute to "media-description" and its attribute syntax from 'type3 keyword | name(MAX)' to 'text(255)' to make sure that the value is just an arbitrary string with no semantic content, such as a tray name or size.
11.	Clarified that several media instances can have the same "media-description" member attribute value.
12.	Specified the tolerance for media size matching of 5 points, same as PostScript.
13.	Removed the type3 keyword from the "media-size" (collection) member attribute, so as to have only one way to specify size, namely a pair of integers.  The client can use these integers to map to a media size name in the locale of the user, similar to keywords.
14.	Added a rangeOfInteger to the "media-size-supported" (1setOf collection) member attributes and so added a "-supported" suffix to "x-dimension" and "y-dimension" member attributes since they now have different attribute syntaxes to the member attributes of the "media-size" member attribute.
15.	Added "media-col-ready" (1setOf collection) Job Template Printer attribute to show the characteristics of the ready media.
16.	Clarified that the IPP/1.1 "media-ready" (1setOf (type3 keyword | name(MAX))) Printer attribute MUST also be supported, and that the values correspond, so that the client can determine the mapping of the media names/keywords to the media characteristics for the ready media at least.
17.	Deleted "sheet-collate", since it is already defined in the "Job Progress Attributes" document [ipp-prog].
18.	Added the section on Document and Page Exceptions to indicate the semantics of each Job Template attribute as required by [ipp-except].
19.	Deleted the definition of the 'none' out-of-band attribute value, since it is defined in the [ipp-coll] document.
20.	Added the 'user-define' out-of-band attribute value for use as one of the values of the Printer's "xxx-supported" attributes to indicate that a client can supply a name that is not in the Printer's supported list, i.e., can supply custom names.
21.	Added the 'user-define-supported' out-of-band value so that an implementation can indicate in the "xxx-supported" returned by the Get-Printer-Supported-Values operation whether or not it will allow the administrator to set the 'user-define' out-of-band value in the corresponding Printer's "xxx-supported" attribute.
22.	Added the 'resources-are-not-supported' value for use with the "job-state-reasons" Job Description attribute to indicate that a user has supplied a custom name.
23.	Clarified that if a Printer supports "job-sheets-col", it MUST also support the IPP/1.1 "job-sheets" Job Template attribute.
24.	Clarified that if a Printer supports "media-col", it MUST also support the IPP/1.1 "media" Job Template attribute.
25.	Clarified that if a Printer supports "media-col-ready", it MUST also support the IPP/1.1 "media-ready" Printer attribute.
26.	Changed the attribute syntax for "job-account-id-supported", "job-message-to-operator-supported", "job-recipient-name-supported", and "job-sheet-message-supported" from 'boolean' to 'integer(1:255)' to indicate the maximum string length supported, since IPP is often a gateway to another system that can't store the string length required for conforming IPP Printers.
27.	Added notes about the conversion between English and metric for different types of media.

13.6	Changes to the January 30, 2000 to create the February 7, 2000 version

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 "separator-sheets".
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" Printer attributes.

13.7	Changes to the January 28, 2000 to create the January 30, 2000 version

The following changes were made to the January 28, 2000 version to create the January 30, 2000 version:

1.	Ordered the Job Template attributes alphabetically.
2.	Add 'name(MAX)' to Job Template attributes that had (type3 keyword | collection) to be consistent with IPP/1.1 that has (type3 keyword | name(MAX)).

13.8	Changes to create the January 28, 2000 version

Initial version.

14.	Appendix B: Summary of other IPP documents

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 [RFC2910]
	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.

15.	Appendix C: Description of the IEEE Industry Standards and Technology (ISTO)

The IEEE-ISTO is a not-for-profit corporation offering industry groups an innovative and flexible operational forum and support services.  The IEEE-ISTO provides a forum not only to develop standards, but also to facilitate activities that support the implementation and acceptance of standards in the marketplace.  The organization is affiliated with the IEEE (http://www.ieee.org/) and the IEEE Standards Association (http://standards.ieee.org/). 

For additional information regarding the IEEE-ISTO and its industry programs visit:

http://www.ieee-isto.org.

16.	Appendix D: Description of the IEEE-ISTO PWG

The Printer Working Group (or PWG) is a Program of the IEEE Industry Standards and Technology Organization (ISTO) with member organizations including printer manufacturers, print server developers, operating system providers, network operating systems providers, network connectivity vendors, and print management application developers.  The group is chartered to make printers and the applications and operating systems supporting them work together better.  All references to the PWG in this document implicitly mean “The Printer Working Group, a Program of the IEEE ISTO.” In order to meet this objective, the PWG will document the results of their work as open standards that define print related protocols, interfaces, procedures and conventions. Printer manufacturers and vendors of printer related software will benefit from the interoperability provided by voluntary conformance to these standards. 

In general, a PWG standard is a specification that is stable, well understood, and is technically competent, has multiple, independent and interoperable implementations with substantial operational experience, and enjoys significant public support. 

For additional information regarding the Printer Working Group visit:  

http://www.pwg.org