INTERNET-DRAFT
<draft-ietf-ipp-output-bin-attr-00.txt>
                                                             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