INTERNET-DRAFT T. Hastings Xerox Corporation R. Bergman Dataproducts Corp. October 21, 1999 Internet Printing Protocol/1.1: "output-bin" attribute extension Copyright (C) The Internet Society (1999). All Rights Reserved. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed as http://www.ietf.org/shadow.html. Abstract This document defines an extension to the IPP/1.0 [RFC2566] & IPP/1.1 [ipp-mod] Model and Semantics specification for the OPTIONAL "output-bin" 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. T. Hastings, R. Bergman [page 1] Expires: April 21, 2000 INTERNET-DRAFT IPP/1.1: "output-bin" attribute October 21, 1999 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 [ipp-mod] Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro] Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] Mapping between LPD and IPP Protocols [RFC2569] The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. A few OPTIONAL operator operations have been added to IPP/1.1. The "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF working group's major decisions. The "Internet Printing Protocol/1.1: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616]. It defines the encoding rules for a new Internet MIME media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs. The "Internet Printing Protocol/1.1: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.1 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included. The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations. T. Hastings, R. Bergman [page 2] Expires: April 21, 2000 INTERNET-DRAFT IPP/1.1: "output-bin" attribute October 21, 1999 TABLE OF CONTENTS 1 Add new "output-bin" Job Template attributes.....................4 1.1 Problem.......................................................4 1.2 Suggested solution............................................4 1.3 Proposed text.................................................4 2 IANA Considerations..............................................7 3 Internationalization Considerations..............................7 4 Security Considerations..........................................7 5 Author's Addresses...............................................7 6 Appendix A: Full Copyright Statement.............................8 T. Hastings, R. Bergman [page 3] Expires: April 21, 2000 INTERNET-DRAFT IPP/1.1: "output-bin" attribute October 21, 1999 1 Add new "output-bin" Job Template attributes 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 Suggested solution Add a single-valued "output-bin" Job Template attribute that captures existing practice. Allow integer values, 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 Proposed text +===================+======================+======================+ | 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 | | | integer(1:MAX) | integer(1:MAX) | name(MAX) | | | | | integer(1:MAX))) | +===================+======================+======================+ output-bin (type2 keyword | name(MAX) | integer(1:MAX)) T. Hastings, R. Bergman [page 4] Expires: April 21, 2000 INTERNET-DRAFT IPP/1.1: "output-bin" attribute October 21, 1999 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' or 'integer'. 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). Output bins whose attribute syntax is 'integer', if any, are assigned by a printer vendor or local administrator to identify a number of similar output bins which are better differentiated by number than by one of the descriptive names defined in the following keyword list. Each output bin may have implementation-dependent properties. Output bins identified by 'integer' or '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 create (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 [ipp-mod] 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. T. Hastings, R. Bergman [page 5] Expires: April 21, 2000 INTERNET-DRAFT IPP/1.1: "output-bin" attribute October 21, 1999 '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 [ipp-mod] 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 or integer values. 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 T. Hastings, R. Bergman [page 6] Expires: April 21, 2000 INTERNET-DRAFT IPP/1.1: "output-bin" attribute October 21, 1999 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 [ipp-mod] 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. 2 IANA Considerations This "output-bin" attribute registration proposal will be published by IANA according to the procedures in RFC 2566 [rfc2566] section 6.2 with the following URL: ftp.isi.edu/iana/assignments/ipp/attributes/output-bin.txt 3 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 [ipp-mod] section 4.1.2 and 4.1.3). The numeric form for the output bin may be simpler for a client to localize. 4 Security Considerations The 'my-mailbox' attribute requires some form of Client Authorization to be really secure. See [ipp-mod] section 8. 5 Author's Addresses Tom Hastings Xerox Corporation 737 Hawaii St. ESAE 231 El Segundo, CA 90245 T. Hastings, R. Bergman [page 7] Expires: April 21, 2000 INTERNET-DRAFT IPP/1.1: "output-bin" attribute October 21, 1999 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 6 Appendix A: Full Copyright Statement Copyright (C) The Internet Society (1998,1999). All Rights Reserved This document and translations of it 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 and this paragraph 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 Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. T. Hastings, R. Bergman [page 8] Expires: April 21, 2000