summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3381.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3381.txt')
-rw-r--r--doc/rfc/rfc3381.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc3381.txt b/doc/rfc/rfc3381.txt
new file mode 100644
index 0000000..d7fd60f
--- /dev/null
+++ b/doc/rfc/rfc3381.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al. Standards Track [Page 1]
+
+RFC 3381 IPP: Job Progress Attributes September 2002
+
+
+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]).
+
+
+
+
+
+Hastings, et. al. Standards Track [Page 2]
+
+RFC 3381 IPP: Job Progress Attributes September 2002
+
+
+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 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.
+
+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.
+
+
+
+Hastings, et. al. Standards Track [Page 3]
+
+RFC 3381 IPP: Job Progress Attributes September 2002
+
+
+ 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".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al. Standards Track [Page 4]
+
+RFC 3381 IPP: Job Progress Attributes September 2002
+
+
+ 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".
+
+
+
+
+
+
+Hastings, et. al. Standards Track [Page 5]
+
+RFC 3381 IPP: Job Progress Attributes September 2002
+
+
+ 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.
+
+
+
+
+
+
+
+Hastings, et. al. Standards Track [Page 6]
+
+RFC 3381 IPP: Job Progress Attributes September 2002
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al. Standards Track [Page 7]
+
+RFC 3381 IPP: Job Progress Attributes September 2002
+
+
+ "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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al. Standards Track [Page 8]
+
+RFC 3381 IPP: Job Progress Attributes September 2002
+
+
+ "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
+
+
+
+Hastings, et. al. Standards Track [Page 9]
+
+RFC 3381 IPP: Job Progress Attributes September 2002
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al. Standards Track [Page 10]
+
+RFC 3381 IPP: Job Progress Attributes September 2002
+
+
+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.
+
+
+
+
+
+
+
+Hastings, et. al. Standards Track [Page 11]
+
+RFC 3381 IPP: Job Progress Attributes September 2002
+
+
+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.
+
+6.1 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
+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
+ 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
+
+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) 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
+
+
+
+Hastings, et. al. Standards Track [Page 12]
+
+RFC 3381 IPP: Job Progress Attributes September 2002
+
+
+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",
+ 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.
+
+9.2 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.
+
+
+
+
+Hastings, et. al. Standards Track [Page 13]
+
+RFC 3381 IPP: Job Progress Attributes September 2002
+
+
+ [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
+
+
+
+Hastings, et. al. Standards Track [Page 14]
+
+RFC 3381 IPP: Job Progress Attributes September 2002
+
+
+ "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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al. Standards Track [Page 15]
+
+RFC 3381 IPP: Job Progress Attributes September 2002
+
+
+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.
+
+
+
+
+
+Hastings, et. al. Standards Track [Page 16]
+
+RFC 3381 IPP: Job Progress Attributes September 2002
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hastings, et. al. Standards Track [Page 17]
+