RFC3381

Network Working Group T. Hastings Request for Comments: 3381 Xerox Corporation Updates: 2910 H. Lewis Category: Standards Track IBM Printing Company

                                                          R. Bergman
                                      Hitachi Koki Imaging Solutions
                                                      September 2002

               Internet Printing Protocol (IPP):
                    Job Progress Attributes

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract

This document defines four new Job Description attributes for monitoring job progress to be registered as OPTIONAL extensions to the Internet Printing Protocol (IPP/1.0 and IPP/1.1). These attributes are drawn from the PWG Job Monitoring MIB. This document also defines a new "sheet-collate" Job Template attribute to control sheet collation and to help with the interpretation of the job progress attributes.

1 Introduction

This document defines four new Job Description attributes for monitoring job progress to be registered as OPTIONAL extensions to IPP/1.0 RFC2566 and IPP/1.1 RFC2911. These attributes are drawn from the PWG Job Monitoring MIB RFC2707. See section 10 for a description of the base IPP documents. The new Job Description attributes are:

  "job-collation-type" (type2 enum)
  "sheet-completed-copy-number" (integer(0:MAX))
  "sheet-completed-document-number" (integer(0:MAX))
  "impressions-completed-current-copy" (integer(0:MAX))

This document also defines a new "sheet-collate" Job Template attribute to control sheet collation and to help with the interpretation of the job progress attributes. These new attributes may also be used by themselves in combination with the IPP/1.1 "job- impressions-completed" attribute, as useful job progress monitoring attributes and/or may be passed in an IPP Notification (see [ipp- ntfy]).

2 Terminology

This section defines terminology used throughout this document.

Conformance Terminology

Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to conformance, as defined in RFC 2119 RFC2119 and RFC2911 section 12.1. If an implementation supports the extension defined in this document, then these terms apply; otherwise, they do not. These terms define conformance to this document only; they do not affect conformance to other documents, unless explicitly stated otherwise.

Other terminology

This document uses terms such as Job object (or Job), IPP Printer object (or Printer), "operation", "attribute", "keyword", "support", and "impression". These terms have special meaning and are defined in the model terminology RFC2911, section 12.2.

3 Job Template attributes

sheet-collate (type2 keyword)

+===================+======================+=====================+ | Job Attribute |Printer: Default Value| Printer: Supported | | | Attribute | Values Attribute | +===================+======================+=====================+ | sheet-collate | sheet-collate-default| sheet-collate- | | (type2 keyword) | (type2 keyword) | supported (1setOf | | | | type2 keyword) | +-------------------+----------------------+---------------------+

This attribute specifies whether or not the media sheets of each copy of each printed document in a job are to be in sequence, when multiple copies of the document are specified by the 'copies' attribute.

Standard keyword values are:

  'uncollated':  each print-stream sheet is printed a number of
     times in succession equal to the value of the 'copies'
     attribute, followed by the next print-stream sheet.

  'collated':  each copy of each document is printed with the
     print-stream sheets in sequence, followed by the next document
     copy.

For example, suppose a document produces two media sheets as output, and "copies" is equal to '6'. For the 'uncollated' case, six copies of the first media sheet are printed, followed by six copies of the second media sheet. For the 'collated' case, one copy of each of the six sheets is printed, followed by another copy of each of the six media sheets.

Whether the effect of sheet collation is achieved by placing copies of a document in multiple output bins, or in the same output bin with implementation defined document separation, is implementation dependent. Also whether it is achieved by making multiple passes over the job or by using an output sorter, is implementation dependent.

Note: IPP/1.0 RFC2566 and IPP/1.1 RFC2911 are silent on whether or not sheets within documents are collated. The "sheet-collate- supported" Printer attribute permits a Printer object to indicate whether or not it collates sheets with each document and whether it allows the client to control sheet collation. An implementation is able to indicate that it supports uncollated sheets, collated sheets, or both, using the 'uncollated', 'collated', or both 'uncollated' and 'collated' values, respectively.

This attribute is affected by "multiple-document-handling". The "multiple-document-handling" attribute describes the collation of documents, and the "sheet-collate" attribute describes the semantics of collating individual pages within a document. To better explain the interaction between these two attributes, the term "set" is introduced. A "set" is a logical boundary between the delivered media sheets of a printed job. For example, in the case of a ten page single document with collated pages and a request for 50 copies, each of the 50 printed copies of the document constitutes a "set". In the above example if the pages were uncollated, then 50 copies of each of the individual pages within the document would represent each "set".

The following table describes the interaction of "sheet-collate" with multiple document handling.

  "sheet-        "multiple-       Semantics
  collate"       document-
                 handling"

  'collated'     'single-         Each copy of the concatenated
                 document'        documents, with their pages in
                                  sequence, represents a "set".

  'collated'     'single-         Each copy of the concatenated
                 document-new-    documents, with their pages in
                 sheet'           sequence, represents a "set".

  'collated'     'separate-       Each copy of each separate
                 documents-       document, with its pages in
                 collated-        sequence, represents a "set".
                 copies'

  'collated'     'separate-       Each copy of each separate
                 documents-       document, with its pages in
                 uncollated-      sequence, represents a "set".
                 copies

  'uncollated'   'single-         Each media sheet of the document
                 document'        is printed a number of times equal
                                  to the "copies" attribute; which
                                  constitutes a "set".

  'uncollated'   'single-         Each media sheet of the
                 document-new-    concatenated documents is printed
                 sheet'           a number of times equal to the
                                  "copies" attribute; which
                                  constitutes a "set".

  'uncollated'   'separate-       This is a degenerate case, and the
                 documents-       printer object MUST reject the job
                 collated-        and return the status, "client-
                 copies'          error-conflicting-attributes".

  'uncollated'   'separate-       This is a degenerate case, and the
                 documents-       printer object MUST reject the job
                 uncollated-      and return the status "client-
                 copies           error-conflicting-attributes".

  From the above table it is obvious that the implicit value of the
  "sheet-collate" attribute in a printer that does not support the
  "sheet-collate" attribute, is 'collated.'  The semantics of
  "multiple-document-handling" are otherwise nonsensical in the case
  of separate documents.

4 IPP Job Description attributes for monitoring Job Progress

The following IPP Job Description attributes are proposed to be added to IPP through the type2 registration procedures. They are useful for monitoring the progress of a job. They are also used as attributes in the notification content in a notification report [ipp-ntfy].

There are a number of Job Description attributes for monitoring the progress of a job. These objects and attributes count the number of K octets, impressions, sheets, and pages requested or completed. For impressions and sheets, "completed" means stacked, unless the implementation is unable to detect when each sheet is stacked, in which case, stacked is approximated when the processing of each sheet is completed. There are objects and attributes for the overall job and for the current copy of the document currently being stacked. For the latter, the rate at which the various objects and attributes count, depends on the sheet and document collation of the job.

Consider the following four Job Description attributes that are used to monitor the progress of a job's impressions:

  1. "job-impressions-completed" - counts the total number of
     impressions stacked for the job (see RFC2911 section
     4.3.18.2).

  2. "impressions-completed-current-copy" - counts the number of
     impressions stacked for the current document copy.

  3. "sheet-completed-copy-number" - identifies the number of the
     copy for the current document being stacked, where the first
     copy is 1.

  4. "sheet-completed-document-number" - identifies the current
     document within the job that is being stacked, where the first
     document in a job is 1.  NOTE: this attribute SHOULD NOT be
     implemented for implementations that only support one document
     per job.

For each of the three types of job collation, a job with three copies of two documents (1, 2), where each document consists of 3 impressions, the four variables have the following values, as each sheet is stacked for one-sided printing:

"job-collation-type" = 'uncollated-sheets(3)'

"job- "impressions- "sheet- "sheet- impressions- completed- completed- completed- completed" current-copy" copy-number" document-

                                                  number"

    0                0                0               0
    1                1                1               1
    2                1                2               1
    3                1                3               1
    4                2                1               1
    5                2                2               1
    6                2                3               1
    7                3                1               1
    8                3                2               1
    9                3                3               1
   10                1                1               2
   11                1                2               2
   12                1                3               2
   13                2                1               2
   14                2                2               2
   15                2                3               2
   16                3                1               2
   17                3                2               2
   18                3                3               2

"job-collation-type" = 'collated-documents(4)'

"job- "impressions- "sheet- "sheet- impressions- completed- completed- completed- completed" current-copy" copy- document-

                                  number"         number"

    0                0                0               0
    1                1                1               1
    2                2                1               1
    3                3                1               1
    4                1                1               2
    5                2                1               2
    6                3                1               2
    7                1                2               1
    8                2                2               1
    9                3                2               1
   10                1                2               2
   11                2                2               2
   12                3                2               2
   13                1                3               1
   14                2                3               1
   15                3                3               1
   16                1                3               2
   17                2                3               2
   18                3                3               2

"job-collation-type" = 'uncollated-documents(5)'

"job- "impressions- "sheet- "sheet- impressions- completed- completed- completed- completed" current-copy" copy-t document-

                                  number"         number"

    0                0                0               0
    1                1                1               1
    2                2                1               1
    3                3                1               1
    4                1                2               1
    5                2                2               1
    6                3                2               1
    7                1                3               1
    8                2                3               1
    9                3                3               1
   10                1                1               2
   11                2                1               2
   12                3                1               2
   13                1                2               2
   14                2                2               2
   15                3                2               2
   16                1                3               2
   17                2                3               2
   18                3                3               2

job-collation-type (type2 enum)

Job Collation includes sheet collation and document collation. Sheet collation is defined to be the ordering of sheets within a document copy. Document collation is defined to be the ordering of document copies within a multi-document job. The value of the "job- collation-type" is affected by the value of the "sheet-collate" Job Template attribute (see section 3.1), if supplied and supported.

The Standard enum values are:

  '1' 'other':  not one of the defined values

  '2' 'unknown':  the collation type is unknown

  '3' 'uncollated-sheets':  No collation of the sheets within each
                document copy, i.e., each sheet of a document that
                is to produce multiple copies, is replicated before
                the next sheet in the document is processed and
                stacked.  If the device has an output bin collator,
                the 'uncollated-sheets(3)' value may actually

                produce collated sheets as far as the user is
                concerned (in the output bins).  However, when the
                job collation is the 'uncollated-sheets(3)' value,
                job progress is indistinguishable from a monitoring
                application between a device that has an output bin
                collator and one that does not.

  '4' 'collated-documents':  Collation of the sheets within each
                document copy is performed within the printing
                device by making multiple passes over, either the
                source or an intermediate representation of the
                document.  In addition, when there are multiple
                documents per job, the i'th copy of each document is
                stacked before the j'th copy of each document, i.e.,
                the documents are collated within each job copy.
                For example, if a job is submitted with documents, A
                and B, the job is made available to the end user as:

                corresponds to the IPP RFC2911 'separate-
                documents-collated-copies' keyword value of the
                "multiple-document-handling" attribute.

                If the job's "copies" attribute is '1' (or not
                supplied), then the "job-collation-type" attribute
                is defined to be '4'.

  '5' 'uncollated-documents':  Collation of the sheets within each
                document copy is performed within the printing
                device by making multiple passes over either the
                source or an intermediate representation of the
                document.  In addition, when there are multiple
                documents per job, all copies of the first document
                in the job are stacked before any copied of the next
                document in the job, i.e., the documents are
                uncollated within the job.  For example, if a job is
                submitted with documents, A and B, the job is made
                available to the end user as:  A, A, ..., B, B, ....
                The 'uncollated-documents(5)' value corresponds to
                the IPP RFC2911 'separate-documents-uncollated-
                copies' keyword value of the "multiple-document-
                handling" attribute.

sheet-completed-copy-number (integer(0:MAX))

The number of the copy being stacked for the current document. This number starts at 0, is set to 1 when the first sheet of the first copy for each document is being stacked and is equal to n where n is the nth sheet stacked in the current document copy. If the value is unknown, the Printer MUST return the 'unknown' out-of-band value (see RFC2911 section 4.1), rather than the -2 value used in some MIBs RFC2707.

sheet-completed-document-number (integer(0:MAX))

The ordinal number of the document in the job that is currently being stacked. This number starts at 0, increments to 1 when the first sheet of the first document in the job is being stacked, and is equal to n where n is the nth document in the job, starting with 1. If the value is unknown, the Printer MUST return the 'unknown' out-of-band value (see RFC2911 section 4.1), rather than the -2 value used in some MIBs RFC2707.

Implementations that only support one document job SHOULD NOT implement this attribute.

impressions-completed-current-copy (integer(0:MAX))

The number of impressions completed by the device for the current copy of the current document so far. For printing, the impressions completed includes interpreting, marking, and stacking the output. For other types of job services, the number of impressions completed includes the number of impressions processed. If the value is unknown, the Printer MUST return the 'unknown' out-of-band value (see RFC2911 section 4.1), rather than the -2 value used in some MIBs RFC2707.

This value MUST be reset to 0 for each document in the job and for each document copy.

5 Conformance Requirements

This section summarizes the Conformance Requirements detailed in the definitions in this document. In general each of the attributes defined in this document are OPTIONAL for a client and/or a Printer to support, so that client and Printer implementers MAY implement any combination of these attributes.

6 IANA Considerations

This section contains registration information for IANA to add to the IPP Registry according to the procedures defined in RFC 2911 RFC2911, section 6. The resulting registrations will be published in the http://www.iana.org/assignments/ipp-registrations registry.

Attributes

Job Template attributes: Ref. Section: sheet-collate (type2 keyword) RFC 3381 3.1 sheet-default (type2 keyword) RFC 3381 3.1 sheet-supported (1setOf type2 keyword) RFC 3381 3.1

Job Description attributes: Ref. Section: job-collation-type (type2 enum) RFC 3381 4.1 sheet-completed-copy-number (integer(0:MAX)) RFC 3381 4.2 sheet-completed-document-number (integer(0:MAX))RFC 3381 4.3 impressions-completed-current-copy (integer(0:MAX))

                                               RFC 3381       4.4

Keyword Attribute Values

The following table provides registration information for all of the attributes defined in this document that have keyword values. These keywords are to be registered according to the procedures defined in RFC 2911 RFC2911 section 6.1.

sheet-collate (type2 keyword) RFC 3381 3.1

 'uncollated'                                  RFC 3381       3.1
 'collated'                                    RFC 3381       3.1

sheet-collate-default (type2 keyword) RFC 3381 3.1

 See "sheet-collate" attribute

sheet-collate-supported (1setOf type2 keyword) RFC 3381 3.1

 See "sheet-collate" attribute

Enum Attribute Values

The following table provides registration information for all of the attributes defined in this document that have enum values. These enums are to be registered according to the procedures defined in RFC 2911 RFC2911 section 6.1.

job-collation-type (type2 enum) RFC 3381 4.1

 '1'   'other'                                 RFC 3381       4.1
 '2'   'unknown'                               RFC 3381       4.1
 '3'   'uncollated-sheets'                     RFC 3381       4.1
 '4'   'collated-documents'                    RFC 3381       4.1
 '5'   'uncollated-documents'                  RFC 3381       4.1

7 Internationalization Considerations

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

8 Security Considerations

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

9 References

Normative References

RFC2910 Herriot, R., Butler, S., Moore, P. and R. Turner,

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

Informative 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. and P.

          Powell, "Internet Printing Protocol/1.0: Model and
          Semantics", RFC 2566, April 1999.

RFC2567 Wright, F.D., "Design Goals for an Internet Printing

          Protocol", RFC 2567, April 1999.

RFC2568 Zilles, S., "Rationale for the Structure and Model and

          Protocol for the Internet Printing Protocol", RFC 2568,
          April 1999.

RFC2569 Herriot, R., Hastings, T., Jacobs, N. and J. Martin,

          "Mapping between LPD and IPP Protocols", RFC 2569, April
          1999.

RFC2707 Bergman, R., Hastings, T., Isaacson, S. and H. Lewis, "PWG

          Job Monitoring MIB - V1", RFC 2707,  November 1999.

RFC3196 Hastings, T., Manros, C., Zehler, P., Kugler, C. and H.

          Holst, "Internet Printing Protocol/1.1: Implementor's
          Guide", RFC 3196, November 2001.

[ipp-ntfy] Herriot, R., Hastings, T., et. al., "Internet Printing

          Protocol (IPP): Event Notification and Subscriptions",
          Work in Progress.

10 Description of the Base IPP Documents

The base 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 RFC3196
  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 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 [RFC2566, RFC2565]. A few OPTIONAL operator operations have been added to IPP/1.1 [RFC2911, RFC2910].

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 IPP working group's major decisions.

The "Internet Printing Protocol/1.1: Model and Semantics" document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. The Job supports multiple documents per Job. The model document also addresses how security, internationalization, and directory issues are addressed.

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 also 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 the 'ipp' scheme 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.

In addition to the base IPP documents, the "Event Notification Specification" document [ipp-ntfy] defines OPTIONAL operations that allow a client to subscribe to printing related events. Subscriptions include "Per-Job subscriptions" and "Per-Printer subscriptions". Subscriptions are modeled as Subscription objects. Four other operations are defined for subscription objects: get attributes, get subscriptions, renew a subscription, and cancel a subscription.

11 Authors' Addresses

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

Phone: 310-333-6413 Fax: 310-333-5514 EMail: [email protected]

Harry Lewis IBM 6300 Diagonal Hwy Boulder, CO 80301-9191

Phone: (303) 924-5337 EMail: [email protected]

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

Phone: 805-578-4421 Fax: 805-578-4001 EMail: [email protected]

IPP Web Page: http://www.pwg.org/ipp/ IPP Mailing List: [email protected]

To subscribe to the ipp mailing list, send the following email:

  1) send it to [email protected]
  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 the IPP Mailing List in order to participate in any discussions of clarification issues and review of registration proposals for additional attributes and values. In order to reduce spam, the mailing list rejects mail from non-subscribers, so you must subscribe to the mailing list in order to send a question or comment to the mailing list.

12 Full Copyright Statement

Copyright (C) The Internet Society (2002). 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.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.