RFC3381 - Internet Printing Protocol (IPP): Job Progress Attributes

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.

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.

Table of Contents

1 IntrodUCtion.....................................................2

2 Terminology......................................................2

2.1 Conformance Terminology........................................4

2.2 Other terminology..............................................4

3 Job Template attributes..........................................4

3.1 sheet-collate (type2 keyWord)..................................4

4 IPP Job Description attributes for monitoring Job Progress.......6

4.1 job-collation-type (type2 enum)................................9

4.2 sheet-completed-copy-number (integer(0:MAX))..................11

4.3 sheet-completed-document-number (integer(0:MAX))..............11

4.4 impressions-completed-current-copy (integer(0:MAX))...........11

5 Conformance Requirements........................................11

6 IANA Considerations.............................................12

6.1 Attributes....................................................

6.2 Keyword Attribute Values......................................

6.3 Enum Attribute Values.........................................

7 Internationalization Considerations.............................12

8 Security Considerations.........................................12

9 References......................................................12

10 Description of the Base IPP Documents..........................13

11 Authors' Addresses.............................................15

12 Full Copyright Statement.......................................16

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.

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, as defined in RFC2119 [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.

2.2 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

3.1 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

4.1 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:

A, B, A, B, .... The 'collated-documents(4)' value

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.

4.2 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].

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

4.4 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 RFC2911

[RFC2911], section 6. The resulting registrations will be published

in the http://www.iana.org/assignments/ipp-registrations registry.

6.1 Attributes

Job Template attributes: Ref. Section:

sheet-collate (type2 keyword) RFC3381 3.1

sheet-default (type2 keyword) RFC3381 3.1

sheet-supported (1setOf type2 keyword) RFC3381 3.1

Job Description attributes: Ref. Section:

job-collation-type (type2 enum) RFC3381 4.1

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

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

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

RFC3381 4.4

6.2 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

RFC2911 [RFC2911] section 6.1.

sheet-collate (type2 keyword) RFC3381 3.1

'uncollated' RFC3381 3.1

'collated' RFC3381 3.1

sheet-collate-default (type2 keyword) RFC3381 3.1

See "sheet-collate" attribute

sheet-collate-supported (1setOf type2 keyword) RFC3381 3.1

See "sheet-collate" attribute

6.3 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) RFC3381 4.1

'1' 'other' RFC3381 4.1

'2' 'unknown' RFC3381 4.1

'3' 'uncollated-sheets' RFC3381 4.1

'4' 'collated-documents' RFC3381 4.1

'5' 'uncollated-documents' RFC3381 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

9.1 Normative References

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

"Internet Printing Protocol/1.1: Encoding and Transport",

RFC2910, September 2000.

[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P.

Powell, "Internet Printing Protocol/1.1: Model and

Semantics", RFC2911, September 2000.

9.2 Informative References

[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Turner,

"Internet Printing Protocol/1.0: Encoding and Transport",

RFC2565, April 1999.

[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.

Powell, "Internet Printing Protocol/1.0: Model and

Semantics", RFC2566, April 1999.

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

Protocol", RFC2567, April 1999.

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

Protocol for the Internet Printing Protocol", RFC2568,

April 1999.

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

"Mapping between LPD and IPP Protocols", RFC2569, April

1999.

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

Job Monitoring MIB - V1", RFC2707, November 1999.

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

Holst, "Internet Printing Protocol/1.1: Implementor's

Guide", RFC3196, 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: hastings@cp10.es.xerox.com

Harry Lewis

IBM

6300 Diagonal Hwy

Boulder, CO 80301-9191

Phone: (303) 924-5337

EMail: harryl@us.ibm.com

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: rbergma@hitachi-hkis.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

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

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 RFCEditor function is currently provided by the

Internet Society.