A Project of the PWG IPP Working Group

Internet Printing Protocol (IPP): 
“output-bin” attribute extension

IEEE-ISTO Printer Working Group
Standard 5100.2-2001

February 7, 2001

Abstract
This document defines an extension to the Internet Printing Protocol/1.0 (IPP/1.0) [RFC2566, RFC2565] & IPP/1.1 [RFC2911, RFC2910] for the OPTIONAL “output-bin” (type2 keyword | name(MAX)) Job Template attribute.  This attribute allows the client to specify in which output bin a job is to be placed and to query the Printer’s default and supported output bins.  

This document is an IEEE-ISTO PWG Draft Standard. For a definition of a "PWG Draft Standard", see:  ftp://ftp.pwg.org/pub/pwg/general/pwg-process.pdf.
This document is available from:  ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.2.pdf, .doc, .rtf

Copyright (C) 2001, 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): “output-bin” attribute extension
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
1.1	Problem
1.2	Solution
1.3	Summary of the “output-bin” Job Template attribute
2	Definition of the “output-bin” Job Template attribute
2.1	output-bin (type2 keyword | name(MAX))
3	Conformance Requirements
4	IANA Considerations
5	Internationalization Considerations
6	Security Considerations
7	References
8	Author’s Addresses
9	Appendix A: Summary of other IPP documents
10	Appendix B: Description of the IEEE Industry Standards and Technology (ISTO)
11	Appendix C: Description of the IEEE-ISTO PWG

1	Introduction
1.1	Problem
Many printers have multiple output bins, that the job submission protocol permits the submitter to select in which to put the entire job.  
1.2	Solution
Add a single-valued “output-bin” Job Template attribute that captures existing practice.  Allow keywords with an integer values component, so that the number of output bins is not constrained.  Do not specify internal mechanisms, such as collators.  Do specify an externally accessible stacker, since current devices allow a user to  select a stacker.  Do not make the attribute multi-valued.  Add the corresponding Job Template Printer attributes: “output-bin-default” and “output-bin-supported”.
Note:  If it is desired to allow the job submitter to select several output bin mail boxes that can be identified by number or recipient’s name, propose a separate multi-valued attribute.  Since the destination may also be electronic and have a method associated with it, also allow the uri attribute syntax. Probably call this other attribute “output-destination” with an attribute syntax of (1setOf uri | name).  Or possibly the output-destination should be a parameter on the URL?  If both “output-bin” and “output-destination” are specified, the job is both printed and sent to the specified destination.  This note is provided so that the “output-bin” attribute will not suffer “scope creep” during the review and be changed into “output-destination”.  Printers have been allowing something like the “output-bin” specification for many years.  Supporting something like “output-destination” is just starting to appear now.
1.3	Summary of the “output-bin” Job Template attribute
  +===================+======================+======================+
  | Job Attribute     |Printer: Default Value|  Printer: Supported  |
  |                   |   Attribute          |   Values Attribute   |
  +===================+======================+======================+
  | output-bin        | output-bin-default   | output-bin-supported |
  | (type2 keyword    | (type2 keyword       | (1setOf (            |
  |  name(MAX))       |  name(MAX))          |     type2 keyword |  |
  |                   |                      |     name(MAX)))      |
  +===================+======================+======================+
2	Definition of the “output-bin” Job Template attribute
2.1	output-bin (type2 keyword | name(MAX))
This Job Template attribute identifies the device output bin to which the job is to be delivered.  There are standard values whose attribute syntax is ‘keyword’, but there are no standard values whose attribute syntax is ‘name’.  Output bins whose attribute syntax is ‘name’, if any, are assigned by local administrators (by means outside the scope of IPP/1.0 and IPP/1.1).   
Each output bin may have implementation-dependent properties.  Output bins identified by ‘name’ values MAY possess any of the properties of the output bins identified by the following keywords, depending on implementation.  However, each output bin MUST be identified by only one value of any attribute syntax type.  Otherwise, clients might be mis-led as to the capabilities of the device when querying the associated Printer object’s “output-bin-supported” attribute.
Note:  Output bin types, such as sorter(s) or collator(s), have not been included in the values of this attribute, since implementations that employ such internal or external bins, determine which to use by the values of other job attributes, such as “finishings”, and “copies”.  
When validating a job in a Job Creation (or Validate-Job) operation, which subset of the output bins are allowed as a destination for a job MAY depend on the user submitting that job, the user’s authentication, and possibly other job attributes, such as “finishings” and “copies”.  When returning the values of the associated “output-bin-supported” attribute, the values returned MAY depend on the user issuing the Get-Printer-Attributes operation.  For example, some implementations MAY omit the ‘my-mailbox’ value for users who do not have a defined mailbox for this IPP Printer object, while others MAY always return ‘my-mailbox’ to all users even if only supported for certain users.
If this IPP Printer object is associated with multiple devices (fan-out) (see [RFC2911] section 2.1), the value of its “output-bin-supported” attribute is the union of the values supported with duplicates removed.  
Standard keyword values are:
‘top’:	The output-bin that, when facing the device, is best identified as the “top” bin with respect to the device.
‘middle’	The output-bin that, when facing the device, is best identified as the “middle” bin with respect to the device.
‘bottom’	The output-bin that, when facing the device, is best identified as the “bottom” bin with respect to the device.
‘side’	The output-bin that, when facing the device, is best identified as the “side” bin with respect to the device.
‘left’	The output-bin that, when facing the device, is best identified as the “left” bin with respect to the device.
‘right’	The output-bin that, when facing the device, is best identified as the “right” bin with respect to the device.
‘center’	The output-bin that, when facing the device, is best identified as the “center” bin with respect to the device.
‘rear’:	The output-bin that, when facing the device, is best identified as the “rear” bin with respect to the device.
‘face-up’	The output-bin that is best identified as the “face-up” bin with respect to the device. The selection of this output bin does not cause output to be made face-up; rather this output bin is given this name because a sheet with printing on one-side arrives in the output bin in the face-up position.
‘face-down’ The output-bin that is best identified as the “face-down” bin with respect to the device. The selection of this output bin does not cause output to be made face-down; rather this output bin is given this name because a sheet with printing on one-side arrives in the output bin in the face-down position.
‘large-capacity’	The output-bin that is best identified as the “large-capacity” bin (in terms of the number of sheets) with respect to the device.
‘stacker-N’:	The output-bin that is best identified as the stacker with values ‘stacker-1’, ‘stacker-2’, ....  A stacker is typically used to collate sheets within a single document (not to be confused with collated copies in which document copies are collated within a job - see the description of the ‘separate-documents-collated-copies’ value of the “multiple-document-handling” attribute in [RFC2911] section 4.2.4).  The correspondence between the ‘stacker-N’ keyword and the actual stacker in the device is implementation-dependent, as is the number of stackers.  If this group of values is supported, at least the ‘stacker-1’ value MUST be supported, unless the system administrator has assigned names.
For client implementations that require distinct keywords for each possible value, say, for localization purposes, it is recommended for interoperability with other vendor’s Printer implementations that ‘stacker-1’ to ‘stacker-10’ keywords be represented.
‘mailbox-N’:	The output-bin that is best identified as a mailbox with values ‘mailbox-1’, ‘mailbox-2’, ‘mailbox-3’, ….  Each mailbox is typically used to collect jobs for an individual or group.  Whether the mailbox has doors and/or locks or is open, depends on implementation.  The correspondence between the ‘mailbox-N’ keyword and the actual output-bin in the device is implementation-dependent, as is the number of mailboxes.  A system administrator MAY be able to assign a name to each mailbox in order to make selection of a mailbox easier for the user.  If this group of values is supported, at least the ‘mailbox-1’ value MUST be supported, unless the system administrator has assigned names or integer values to mailboxes.
For client implementations that require distinct keywords for each possible value, say, for localization purposes, it is recommended for interoperability with other vendor’s Printer implementations that ‘mailbox-1’ to ‘mailbox-25’ keywords be represented.
‘my-mailbox’:	The output-bin that is best identified as functioning like a private “mailbox” with respect to the device.  An output-bin functions like a private mailbox if a printer selects the actual output bin using additional implementation-dependent criteria, such as the “authenticated user” (see [RFC2911] section 8.3) that depends on the user submitting the job.  Whether the mailbox has doors and/or locks or is open, depends on implementation, as is the number of mailboxes.
‘tray-N’:	Output bins that are best identified as ‘tray-1’, ‘tray-2’, ... rather than the descriptive names defined in the above keyword list.  

3	Conformance Requirements
The Printer and client conformance requirements for supporting this attribute are the same as for any Job Template attribute (see [RFC2911]).
4	IANA Considerations
The “output-bin” attribute defined in this document will be published by IANA according to the procedures in RFC 2911 [RFC2911] section 6.2 with the following path:
ftp.isi.edu/iana/assignments/ipp/attributes/
The registry entry will contain the following information:
Reference:  
ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.2.pdf

Job Template attributes:                                   Section:
output-bin (type2 keyword | name(MAX))                       2.1
5	Internationalization Considerations
Normally a client will provide localization of the keywords values of this attribute to the language of the user, but will not localize the name values (see [RFC2911] section 4.1.2 and 4.1.3).  The numeric form for the output bin may be simpler for a client to localize.
6	Security Considerations
The ‘my-mailbox’ attribute requires some form of Client Authorization to be really secure.  See [RFC2911] section 8.
7	References
[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.
8	Author’s Addresses
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

Ron Bergman (Editor)
Hitachi Koki Imaging Systems, Inc.
1757 Tapo Canyon Road
Simi Valley, CA 93063-3394

Phone: 805-578-4421
Fax:  805-578-4001
Email: rbergman@dpc.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	

9	Appendix A: 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 [RFC2911]
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.
10	Appendix B: 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.
11	Appendix C: 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