RFC 2911
Internet Printing Protocol/1.1: Model and Semantics
Pages: 224
Obsoletes: 2566
Obsoleted by: 8011
Updated by: 3380 3382 3996 3995 7472
Obsoletes: 2566
Obsoleted by: 8011
Updated by: 3380 3382 3996 3995 7472
Part 9 of 9 – Pages 205 to 224
14.1. Examples
Below are examples to supplement the engineering media value definitions. Example 1: "Synchro-Cut", a device cutting the roll paper in synchronization with the data data height: A1 height data width (shaded): A1 width < data width < (A1 width) x 2 specified value: 'iso-a1xsynchro-white' | | |<--- data width --->| | | | | | | |<- A1 width ->|<- A1 width ->| | | | | cross ^ | | | | feed | +--------------------------------------------/ direction | |//////////////|/////| | ^ / | |//////////////|/////| | | / | |//////////////|/////| | | / | |//////////////|/////| | | \ <-----------+- |//////////////|/////| | A1 \ roll feed | |//////////////|/////| | height \ paper direction |//////////////|/////| | | \ |//////////////|/////| | | / |//////////////|/////| | v / +------------------------------------------/ | | |<------ CUT HERE (to synchronize | with data width) |
Example 2: "Auto-Cut", a device cutting the roll paper at multiples
of fixed-size media width
data height: A1 height
data width (shaded): A1 width < data width < (A1 width) x 2
specified value: 'auto-fixed-size-white'
| |
|<--- data width --->|
| |
| | | |
|<- A1 width ->|<- A1 width ->|
| | | |
cross ^ | | | |
feed | +--------------------------------------------/
direction | |//////////////|/////| | ^ /
| |//////////////|/////| | | /
| |//////////////|/////| | | /
| |//////////////|/////| | | \
<-----------+- |//////////////|/////| | A1 \ roll
feed | |//////////////|/////| | height \ paper
direction |//////////////|/////| | | \
|//////////////|/////| | | /
|//////////////|/////| | v /
+------------------------------------------/
|
|
|<--- CUT HERE
| (to synchronize
| with data width)
Example 3: the 'iso-a4x4-white' fixed size paper
paper height: A4 height
paper width: (A4 width) x 4
specified value: 'iso-a4x4-white'
| | | | |
|<- A4 width ->|<- A4 width ->|<- A4 width ->|<- A4 width ->|
| | | | |
| | | | |
+-----------------------------------------------------------+
| ^ | | | |
| | | | | |
| | | | | |
| A4 | | | |
| height | | | |
| | | | | |
| | | | | |
| | | | | |
| v | | | |
+-----------------------------------------------------------+
Example 4: "Synchro-Cut", a device cutting the fixed size paper in
synchronization with the data
data height: A4 height
data width (shaded): (A4 width) x 2 < data width < (A4 width) x 3
specified value: 'iso-a4xsynchro-white'
| |
|<---------- data width ----------->|
| |
| | | | |
|<- A4 width ->|<- A4 width ->|<- A4 width ->|
| | | | |
cross ^ | | | | |
feed | +--------------------------------------------+
direction | |//////////////|//////////////|/////| ^ |
| |//////////////|//////////////|/////| | |
| |//////////////|//////////////|/////| | |
| |//////////////|//////////////|/////| | |
<-----------+- |//////////////|//////////////|/////| A4 |
feed | |//////////////|//////////////|/////| height |
direction |//////////////|//////////////|/////| | |
|//////////////|//////////////|/////| | |
|//////////////|//////////////|/////| v |
+--------------------------------------------+
|
CUT HERE ---->|
(to synchronize |
with data width) |
15. APPENDIX D: Processing IPP Attributes
When submitting a print job to a Printer object, the IPP model allows
a client to supply operation and Job Template attributes along with
the document data. These Job Template attributes in the create
request affect the rendering, production and finishing of the
documents in the job. Similar types of instructions may also be
contained in the document to be printed, that is, embedded within the
print data itself. In addition, the Printer has a set of attributes
that describe what rendering and finishing options which are
supported by that Printer. This model, which allows for flexibility
and power, also introduces the potential that at job submission time,
these client-supplied attributes may conflict with either:
- what the implementation is capable of realizing (i.e., what the
Printer supports), as well as
- the instructions embedded within the print data itself.
The following sections describe how these two types of conflicts are handled in the IPP model.15.1 Fidelity
If there is a conflict between what the client requests and what a Printer object supports, the client may request one of two possible conflict handling mechanisms: 1) either reject the job since the job can not be processed exactly as specified, or 2) allow the Printer to make any changes necessary to proceed with processing the Job the best it can. In the first case the client is indicating to the Printer object: "Print the job exactly as specified with no exceptions, and if that can't be done, don't even bother printing the job at all." In the second case, the client is indicating to the Printer object: "It is more important to make sure the job is printed rather than be processed exactly as specified; just make sure the job is printed even if some client-supplied attributes need to be changed or ignored." The IPP model accounts for this situation by introducing an "ipp- attribute-fidelity" attribute. In a create request, "ipp-attribute-fidelity" is a boolean operation attribute that is OPTIONALLY supplied by the client. The value 'true' indicates that total fidelity to client supplied Job Template attributes and values is required. The client is requesting that the Job be printed exactly as specified, and if that is not possible then the job MUST be rejected rather than processed incorrectly. The value 'false' indicates that a reasonable attempt to print the Job is acceptable. If a Printer does not support some of the client supplied Job Template attributes or values, the Printer MUST ignore them or substitute any supported value for unsupported values, respectively. The Printer may choose to substitute the default value associated with that attribute, or use some other supported value that is similar to the unsupported requested value. For example, if a client supplies a "media" value of 'na-letter', the Printer may choose to substitute 'iso-a4' rather than a default value of 'envelope'. If the client does not supply the "ipp-attribute- fidelity" attribute, the Printer assumes a value of 'false'. Each Printer implementation MUST support both types of "fidelity" printing (that is whether the client supplies a value of 'true' or 'false'):
- If the client supplies 'false' or does not supply the attribute,
the Printer object MUST always accept the request by ignoring
unsupported Job Template attributes and by substituting
unsupported values of supported Job Template attributes with
supported values.
- If the client supplies 'true', the Printer object MUST reject
the request if the client supplies unsupported Job Template
attributes.
Since a client can always query a Printer to find out exactly what is
and is not supported, "ipp-attribute-fidelity" set to 'false' is
useful when:
1) The End-User uses a command line interface to request
attributes that might not be supported.
2) In a GUI context, if the End User expects the job might be
moved to another printer and prefers a sub-optimal result to
nothing at all.
3) The End User just wants something reasonable in lieu of nothing
at all.
15.2 Page Description Language (PDL) Override
If there is a conflict between the value of an IPP Job Template
attribute and a corresponding instruction in the document data, the
value of the IPP attribute SHOULD take precedence over the document
instruction. Consider the case where a previously formatted file of
document data is sent to an IPP Printer. In this case, if the client
supplies any attributes at job submission time, the client desires
that those attributes override the embedded instructions. Consider
the case were a previously formatted document has embedded in it
commands to load 'iso-a4' media. However, the document is passed to
an end user that only has access to a printer with 'na-letter' media
loaded. That end user most likely wants to submit that document to
an IPP Printer with the "media" Job Template attribute set to 'na-
letter'. The job submission attribute should take precedence over
the embedded PDL instruction. However, until companies that supply
document data interpreters allow a way for external IPP attributes to
take precedence over embedded job production instructions, a Printer
might not be able to support the semantics that IPP attributes
override the embedded instructions.
The IPP model accounts for this situation by introducing a "pdl-
override-supported" attribute that describes the Printer objects
capabilities to override instructions embedded in the PDL data
stream. The value of the "pdl-override-supported" attribute is
configured by means outside the scope of this IPP/1.1 document.
This REQUIRED Printer attribute takes on the following values:
- 'attempted': This value indicates that the Printer object
attempts to make the IPP attribute values take precedence over
embedded instructions in the document data, however there is no
guarantee.
- 'not-attempted': This value indicates that the Printer object
makes no attempt to make the IPP attribute values take
precedence over embedded instructions in the document data.
At job processing time, an implementation that supports the value of
'attempted' might do one of several different actions:
1) Generate an output device specific command sequence to realize
the feature represented by the IPP attribute value.
2) Parse the document data itself and replace the conflicting
embedded instruction with a new embedded instruction that
matches the intent of the IPP attribute value.
3) Indicate to the Printer that external supplied attributes take
precedence over embedded instructions and then pass the
external IPP attribute values to the document data interpreter.
4) Anything else that allows for the semantics that IPP attributes
override embedded document data instructions.
Since 'attempted' does not offer any type of guarantee, even though a
given Printer object might not do a very "good" job of attempting to
ensure that IPP attributes take a higher precedence over instructions
embedded in the document data, it would still be a conforming
implementation.
At job processing time, an implementation that supports the value of
'not-attempted' might do one of the following actions:
1) Simply pre-pend the document data with the PDL instruction that
corresponds to the client-supplied PDL attribute, such that if
the document data also has the same PDL instruction, it will
override what the Printer object pre-pended. In other words,
this implementation is using the same implementation semantics
for the client-supplied IPP attributes as for the Printer
object defaults.
2) Parse the document data and replace the conflicting embedded
instruction with a new embedded instruction that approximates,
but does not match, the semantic intent of the IPP attribute
value.
Note: The "ipp-attribute-fidelity" attribute applies to the
Printer's ability to either accept or reject other unsupported Job
Template attributes. In other words, if "ipp-attribute-fidelity" is
set to 'true', a Job is accepted if and only if the client supplied
Job Template attributes and values are supported by the Printer.
Whether these attributes actually affect the processing of the Job
when the document data contains embedded instructions depends on the
ability of the Printer to override the instructions embedded in the
document data with the semantics of the IPP attributes. If the
document data attributes can be overridden ("pdl-override-supported"
set to 'attempted'), the Printer makes an attempt to use the IPP
attributes when processing the Job. If the document data attributes
can not be overridden ("pdl-override-supported" set to 'not-
attempted'), the Printer makes no attempt to override the embedded
document data instructions with the IPP attributes when processing
the Job, and hence, the IPP attributes may fail to affect the Job
processing and output when the corresponding instruction is embedded
in the document data.
15.3 Using Job Template Attributes During Document Processing.
The Printer object uses some of the Job object's Job Template
attributes during the processing of the document data associated with
that job. These include, but are not limited to, "orientation-
requested", "number-up", "sides", "media", and "copies". The
processing of each document in a Job Object MUST follow the steps
below. These steps are intended only to identify when and how
attributes are to be used in processing document data and any
alternative steps that accomplishes the same effect can be used to
implement this specification document.
1. Using the client supplied "document-format" attribute or some
form of document format detection algorithm (if the value of
"document-format" is not specific enough), determine whether or
not the document data has already been formatted for printing.
If the document data has been formatted, then go to step 2.
Otherwise, the document data MUST be formatted. The formatting
detection algorithm is implementation defined and is not
specified by this document. The formatting of the document
data uses the "orientation-requested" attribute to determine
how the formatted print data should be placed on a print-stream
page, see section 4.2.10 for the details.
2. The document data is in the form of a print-stream in a known
media type. The "page-ranges" attribute is used to select, as
specified in section 4.2.7, a sub-sequence of the pages in the
print-stream that are to be processed and images.
3. The input to this step is a sequence of print-stream pages.
This step is controlled by the "number-up" attribute. If the
value of "number-up" is N, then during the processing of the
print-stream pages, each N print-stream pages are positioned,
as specified in section 4.2.9, to create a single impression.
If a given document does not have N more print-stream pages,
then the completion of the impression is controlled by the
"multiple-document-handling" attribute as described in section
4.2.4; when the value of this attribute is 'single-document' or
'single-document-new-sheet', the print-stream pages of document
data from subsequent documents is used to complete the
impression.
The size(scaling), position(translation) and rotation of the
print-stream pages on the impression is implementation defined.
Note that during this process the print-stream pages may be
rendered to a form suitable for placing on the impression; this
rendering is controlled by the values of the "printer-
resolution" and "print-quality" attributes as described in
sections 4.2.12 and 4.2.13. In the case N=1, the impression is
nearly the same as the print-stream page; the differences would
only be in the size, position and rotation of the print-stream
page and/or any decoration, such as a frame to the page, that
is added by the implementation.
4. The collection of impressions is placed, in sequence, onto
sides of the media sheets. This placement is controlled by the
"sides" attribute and the orientation of the print-stream page,
as described in section 4.2.8. The orientation of the print-
stream pages affects the orientation of the impression; for
example, if "number-up" equals 2, then, typically, two portrait
print-stream pages become one landscape impression. Note that
the placement of impressions onto media sheets is also
controlled by the "multiple-document-handling" attribute as
described in section 4.2.4.
5. The "copies" and "multiple-document-handling" attributes are
used to determine how many copies of each media instance are
created and in what order. See sections 4.2.5 and 4.2.4 for the
details.
6. When the correct number of copies are created, the media
instances are finished according to the values of the
"finishings" attribute as described in 4.2.6. Note that
sometimes finishing operations may require manual intervention
to perform the finishing operations on the copies, especially
uncollated copies. This document allows any or all of the
processing steps to be performed automatically or manually at
the discretion of the Printer object.
16. APPENDIX E: Generic Directory Schema
This section defines a generic schema for an entry in a directory service. A directory service is a means by which service users can locate service providers. In IPP environments, this means that IPP Printers can be registered (either automatically or with the help of an administrator) as entries of type printer in the directory using an implementation specific mechanism such as entry attributes, entry type fields, specific branches, etc. Directory clients can search or browse for entries of type printer. Clients use the directory service to find entries based on naming, organizational contexts, or filtered searches on attribute values of entries. For example, a client can find all printers in the "Local Department" context. Authentication and authorization are also often part of a directory service so that an administrator can place limits on end users so that they are only allowed to find entries to which they have certain access rights. IPP itself does not require any specific directory service protocol or provider. Note: Some directory implementations allow for the notion of "aliasing". That is, one directory entry object can appear as multiple directory entry object with different names for each object. In each case, each alias refers to the same directory entry object which refers to a single IPP Printer object. The generic schema is a subset of IPP Printer Job Template and Printer Description attributes (sections 4.2 and 4.4). These attributes are identified as either RECOMMENDED or OPTIONAL for the directory entry itself. This conformance labeling is NOT the same conformance labeling applied to the attributes of IPP Printers objects. The conformance labeling in this Appendix is intended to apply to directory templates and to IPP Printer implementations that subscribe by adding one or more entries to a directory. RECOMMENDED attributes SHOULD be associated with each directory entry. OPTIONAL attributes MAY be associated with the directory entry (if known or supported). In addition, all directory entry attributes SHOULD reflect the current attribute values for the corresponding Printer object. The names of attributes in directory schema and entries SHOULD be the same as the IPP Printer attribute names as shown, as much as possible. In order to bridge between the directory service and the IPP Printer object, one of the RECOMMENDED directory entry attributes is the Printer object's "printer-uri-supported" attribute. The directory client queries the "printer-uri-supported" attribute (or its equivalent) in the directory entry and then the IPP client addresses
the IPP Printer object using one of its URIs. The "uri-security-
supported" attribute identifies the protocol (if any) used to secure
a channel.
The following attributes define the generic schema for directory
entries of type PRINTER:
printer-uri-supported RECOMMENDED Section 4.4.1
uri-authentication-supported RECOMMENDED Section 4.4.2
uri-security-supported RECOMMENDED Section 4.4.3
printer-name RECOMMENDED Section 4.4.4
printer-location RECOMMENDED Section 4.4.5
printer-info OPTIONAL Section 4.4.6
printer-more-info OPTIONAL Section 4.4.7
printer-make-and-model RECOMMENDED Section 4.4.9
ipp-versions-supported RECOMMENDED Section 4.4.14
multiple-document-jobs-supported OPTIONAL Section 4.4.16
charset-supported OPTIONAL Section 4.4.18
generated-natural-language-
supported OPTIONAL Section 4.4.20
document-format-supported RECOMMENDED Section 4.4.22
color-supported RECOMMENDED Section 4.4.26
compression-supported RECOMMENDED Section 4.4.32
pages-per-minute OPTIONAL Section 4.4.36
pages-per-minute-color OPTIONAL Section 4.4.37
finishings-supported OPTIONAL Section 4.2.6
number-up-supported OPTIONAL Section 4.2.7
sides-supported RECOMMENDED Section 4.2.8
media-supported RECOMMENDED Section 4.2.11
printer-resolution-supported OPTIONAL Section 4.2.12
print-quality-supported OPTIONAL Section 4.2.13
17. APPENDIX F: Differences between the IPP/1.0 and IPP/1.1 "Model and
Semantics" Documents
This Appendix is divided into two lists that summarize the
differences between IPP/1.1 (this document) and IPP/1.0 [RFC2566].
The section numbers refer to the numbers in this document which in
some cases have changed from RFC 2566. When a change affects
multiple sections, the item is listed once in the order of the first
section affected and the remaining affected section numbers are
indicated.
The first list contains extensions and clarifications and the second
list contains changes in semantics or conformance. However, client
and IPP object implementations of IPP/1.0 MAY implement any of the
extensions and clarifications in this document.
The following extensions and clarifications have been incorporated
into this document:
1. Section 2.1 - clarified that the term "client" can be either
contained in software controlled by an end user or a part of a
print server that controls devices.
2. Section 2 - clarified that the term "IPP object" and "Printer
object" can either be embedded in a device object or part of a
print server that accepts IPP requests.
3. Section 2.4 - added the description of the new "uri-
authentication-supported" Printer Description attribute.
4. Section 3.1.3, 3.1.6, 3.2.5.2, and 3.2.6.2 - clarified the
error handling for operation attributes that have their own
status code.
5. Section 3.1.3 - clarified that multiple occurrences of the
same attribute in an attribute group is mal-formed. An IPP
Printer MAY reject the request or choose one of the
attributes.
6. Section 3.1.6 - reorganized this section into sub-sections to
separately describe "status-code", "status-message",
"detailed-status-message", and "document-access-error"
attributes.
7. Section 3.1.6.1 - clarified the error status codes and their
relationship to operation attributes.
8. Section 3.1.6.3 - Added the OPTIONAL "detailed-status-message
(text(MAX))" operation attribute to provide additional more
detailed information about a response.
9. Section 3.1.6.4 and 3.2.2 - Added the OPTIONAL "document-
access-error (text(MAX))" operation attribute for use with
Print-URI and Send-URI responses.
10. Sections 3.1.7 - Added this new section to clarify returning
Unsupported Attributes for all operations, including only
returning attributes that were in the request. Moved the text
from section 3.2.1.2 Unsupported Attributes to this section.
11. Sections 3.1.7 and 4.1 - clarified the encoding of the "out-
of-band" 'unsupported' and 'unknown' values.
12. Section 3.1.8 - clarified that only the version number
parameter will be carried forward into future major or minor
versions of the protocol.
13. Section 3.1.8 - relaxed the requirements to increment the
major version number in future versions of the Model and
Semantics document.
14. Section 3.1.9, and 3.2.5 - added the 'processing' state to the
list of job states that a job can be in after a Create-Job
operation.
15. Section 3.1.9 - clarified that a non-spooling Printer MAY
accept zero or more subsequent jobs while processing a job and
flow control them down. Subsequent create requests are
rejected with the 'server-error-busy' error status.
16. Section 3.2.1.1 - clarified the validation of the
"compression" operation attribute and its relationship to the
validation of the "document-format" attribute and returning
Unsupported Attributes.
17. Sections 3.2.1.1, 4.3.8, 13.1.4.16, and 13.1.4.17 - added the
'client-error-compression-not-supported', 'client-error-
compression-error' status codes and the 'unsupported-
compression' and 'compression-error' job-state-reasons.
18. Sections 3.2.1.1 and 4.3.8 - added 'unsupported-document-
format' and 'document-format-error' job-state-reasons.
19. Sections 3.2.2, 4.3.8 and 13.1.4.19 - added 'client-error-
document-access-error' status code and 'document-access-error'
job state reason.
20. Section 3.2.5.2 and 3.2.6.2 - clarified that the Unsupported
Attributes group MUST NOT include attributes not requested in
the Get-Printer-Attributes request.
21. Section 3.2.6 - clarified that "limit" takes precedence over
"which-jobs" and "my-jobs'.
22. Section 3.2.6.2 - clarified that Get-Jobs returns
'successful-ok' when no jobs to return.
23. Sections 3.2.7, 3.2.8, and 3.2.9 - added the OPTIONAL Pause-
Printer, Resume-Printer, and Purge-Jobs operations
24. Section 3.3.1 - clarified that the authorization required for
a Send-Document request MUST be the same user as the Create-
Job or an operator.
25. Section 3.3.1.1 - clarified that a Create-Job Send-Document
with "last-document" = 'true' and no data is not an error; its
a job with no documents.
26. Sections 3.3.5, 3.3.6, and 3.3.7 - added the OPTIONAL Hold-
Job, Release-Job, and Restart-Job operations. Clarified the
Restart-Job operation so that the Printer MUST re-fetch any
documents passed by-reference (Print-URI or Send-URI).
27. Section 4.1 - clarified that the encoding of the out-of-band
values are specified in the Encoding and Transport" document.
28. Section 4.1 - Clarified that the requirement that clients MUST
NOT send "out-of-band" values in requests applies only to
operations defined in this document. Other operations are
allowed to define "out-of-band" values that clients can
supply.
29. Sections 4.1.1 and 4.1.2 - clarified that the maximum 'text'
and 'name' values of 1023 and 255 are for the
'textWithoutLanguage' portion of the 'textWithLanguage' form,
so that the maximum number of octets for the actual text and
name data is the same for the without and with language forms;
the 'naturalLanguage' part is in addition.
30. Section 4.1.9 - clarified that 'mimeMediaType' values can
include any parameters from the IANA Registry, not just
charset parameters.
31. Section 4.1.9.1 - clarified that 'application/octet-stream'
auto-sensing can happen at create request time and/or
job/document processing time.
32. Section 4.1.9.1 - clarified that auto-sensing involves the
Printer examining some number of octets of document data using
an implementation-dependent method.
33. Section 4.1.14 - clarified that the localization of dateTime
by the client includes the time zone.
34. Section 4.2 - clarified that xxx-supported have multiple
keywords and/or names by adding parentheses to the table to
give: (1setOf (type3 keyword | name))
35. Section 4.2.2 - added the 'indefinite' keyword value to the
"job-hold-until" attribute for use with the create operations
and Hold-Job and Restart-Job operations.
36. Section 4.2.6 - added more enum values to the "finishings" Job
Template attribute.
37. Section 4.2.6 - clarified that the landscape definition is a
rotation of the image with respect to the medium.
38. Section 4.3.7 - added that a forwarding server that cannot get
any job state MAY return the job's state as 'completed',
provided that it also return the new 'queued-in-device' job
state reason.
39. Section 4.3.7.2 - added the Partitioning of Job States section
to clarify the concepts of Job Retention, Job History, and Job
Removal.
40. Section 4.3.8 - added 'job-data-insufficient' job state reason
to indicate whether sufficient data has arrived for the
document to start to be processed.
41. Section 4.3.8 - added 'document-access-error' job state reason
to indicate an access error of any kind.
42. Section 4.3.8 - added 'job-queued-for-marker' job state reason
to indicate whether the job has completed some processing and
is waiting for the marker.
43. Section 4.3.8 - added 'unsupported-compression' and
'compression-error' job state reasons to indicate compression
not supported or compression processing error after the create
has been accepted.
44. Section 4.3.8 - added 'unsupported-document-format' and
'document-format-error' job state reasons to indicate document
not supported or document format processing error after the
create has been accepted.
45. Section 4.3.8 - added 'queued-in-device' job state reason to
indicate that a job as been forwarded to a print system or
device that does not provide any job status.
46. Section 4.3.10 - added "job-detailed-status-messages (1setOf
text(MAX)) for returning detailed error messages.
47. Section 4.3.11 - added the "job-document-access-errors (1setOf
text(MAX))
48. Section 4.3.14.2 - clarified that the time recorded is the
first time processing since the create operation or the
Restart-Job operation.
49. Section 4.3.14.2 and 4.3.14.3 - clarified that the out-of-band
value 'no-value' is returned if the job has not started
processing or has not completed, respectively.
50. Section 4.3.14 - Added the OPTIONAL "date-time-at-creation",
"date-time-at-processing", and "date-time-at-completed" Event
Time Job Description attributes
51. Section 4.4.3 - added the 'tls' value to "uri-security-
supported" attribute.
52. Section 4.4.3 - clarified "uri-security-supported" is
orthogonal to Client Authentication so that 'none' does not
exclude Client Authentication.
53. Section 4.4.11 - simplified the "printer-state" descriptions
while generalizing to allow high end devices that interpret
one or more jobs while marking another. Indicated that
'spool-area-full' and 'stopped-partly' "printer-state-reasons"
may be used to provide further state information.
54. Section 4.4.12 - added the 'moving-to-paused' keyword value to
the "printer-state-reasons" attribute for use with the Pause-
Printer operation.
55. Section 4.4.12 - replaced the duplicate 'marker-supply-low'
keyword with the missing 'toner-empty' keyword for the
"printer-state-reasons" attribute. (This correction was also
made before RFC 2566 was published).
56. Section 4.4.12 - clarified 'spool-area-full' "printer-state-
reasons" to include non-spooling printers to indicate when it
can and cannot accept another job.
57. Section 4.4.15 - added the enum values to the "operations-
supported" attribute for the new operations. Clarified that
the values of this attribute are encoded as any enum, namely
32-bit values.
58. Section 4.4.30 - clarified that the dateTime value of
"printer-current-time" is on a "best efforts basis". If a
proper date-time cannot be obtained, the implementation
returns the 'no-value' out-of-band value. Also clarified that
the time zone NEED NOT be the time zone that the people near
the device use and that the client SHOULD display the dateTime
attributes in the user's local time.
59. Sections 4.4.36 and 4.4.37 - added the OPTIONAL "pages-per-
minute" and "pages-per-minute-color" Printer Description
attributes.
60. Section 5.1 - clarified that the client conformance
requirements apply to clients controlled by an end user and
clients in servers.
61. Section 5.1 - clarified that any response MAY contain
additional attribute groups, attributes, attribute syntaxes,
or attribute values.
62. Section 5.1 - clarified that a client SHOULD do its best to
prevent a channel from being closed by a lower layer when the
channel is flow controlled off by the IPP Printer.
63. Section 5.2 - clarified that the IPP object requirements apply
to objects embedded in devices or that are parts of servers.
64. Section 5.2.2 - clarified that IPP objects MAY return
operation responses that contain attribute groups, attribute
names, attribute syntaxes, attribute values, and status codes
that are extensions to this standard.
65. Section 6 - changed the terminology of "private extensions" to
"vendor extensions" and indicated that they are registered
with IANA along with IETF standards track extensions.
66. Section 6.7 - inserted this section on registering out-of-band
attribute values with IANA as extensions.
67. Section 8.3 - clarified the use of URIs for each Client
Authentication mechanism.
68. Section 8.5 - added the security discussion around the new
operator/administrator operations.
69. Section 13.1.4.16 - added client-error-compression-not-
supported (0x040F)
70. Section 13.1.4.17 - added client-error-compression-error
(0x0410)
71. Section 13.1.4.18 - added client-error-document-format-error
(0x0411)
72. Section 13.1.4.19 - added client-error-document-access-error
(0x0412)
73. Section 13.1.5.10 - added server-error-multiple-document-
jobs-not-supported (0x0509)
74. Section 14 - added 'a-white', 'b-white', 'c-white', 'd-white',
and 'e-white' and clarified that the existing 'a', 'b', 'c',
'd', and 'e' values are size values. Added American,
Japanese, and European Engineering sizes, filled out
-transparent and - translucent media names and drawings for
the synchro cut sizes.
75. Section 16 - softened the RECOMMENDATION for IPP Printer
attributes in a Directory schema so that they can have
equivalents.
76. Section 16 - added the OPTIONAL "pages-per-minute" and
"pages-per-minute-color" Printer attributes to the Directory
schema.
77. Section 16 - added OPTIONAL "multiple-document-jobs-supported"
to the Directory schema.
78. Section 16 - added RECOMMENDED "uri-authentication-supported",
"ipp-versions-supported", and "compression-supported" to the
Directory schema.
The following changes in semantics and/or conformance have been
incorporated into this document:
1. Section 3.1.6.3 - allowed a Printer to localize the
"detailed-status-message" operation response attribute, but
indicated that such localization might obscure the technical
meaning of such messages.
2. Section 3.1.8, 5.2.4, and 13.1.5.4 - Clients and IPP objects
MUST support version 1.1 conformance requirements. It is
recommended that they interoperate with 1.0. Also clarified
that IPP Printers MUST accept '1.1' requests. It is
recommended that they also accept '1.x' requests.
3. Section 3.2.1.1 and section 4.4.32 - changed the "compression"
operation and the "compression-supported" Printer Description
attribute from OPTIONAL to REQUIRED.
4. Sections 3.2.1.2 and 4.3.8 - changed "job-state-reasons" from
RECOMMENDED to REQUIRED, so that "job-state-reasons" MUST be
returned in create operation responses.
5. Sections 3.2.4, 3.3.1, 4.4.16, and 16 - changed Create-
Job/Send-Document so that they MAY be implemented while only
supporting one document jobs. Added the "multiple-document-
jobs-supported" boolean Printer Description attribute to
indicate whether Create-Job/Send-Document support multiple
document jobs or not. Added to the Directory schema.
6. Section 4.1.9 - deleted 'text/plain; charset=iso-10646-ucs-2',
since binary is not legal with the 'text' type.
7. Section 4.1.9.1 - added the RECOMMENDATION that a Printer
indicate by printing on the job's job-start-sheet that auto-
sensing has occurred and what document format was auto-sensed.
8. Section 4.2.4 - indicated that the "multiple-document-
handling" Job Template attribute MUST be supported with at
least one value if the Printer supports multiple documents per
job
9. Section 4.3.7.2 - indicated that the 'job-restartable' job
state reason SHOULD be supported if the Restart-Job operation
is supported.
10. Section 4.3.8 - changed "job-state-reasons" from RECOMMENDED
to REQUIRED.
11. Section 4.3.8 - clarified the conformance of the values of the
"job-state-reasons" attribute by copying conformance
requirements from other sections of the document so that it is
clear from reading the definition of "job-state-reasons" which
values MUST or SHOULD be supported. The 'none',
'unsupported-compression', and 'unsupported-document-format'
values MUST be supported. The 'job-hold-until-specified'
SHOULD be specified if the "job-hold-until" Job Template is
supported. The following values SHOULD be supported: 'job-
canceled-by-user', 'aborted-by-system', and 'job-completed-
successfully'. The
'job-canceled-by-operator' SHOULD be supported if the
implementation permits canceling by other than the job owner.
The 'job-canceled-at-device' SHOULD be supported if the device
supports canceling jobs at the console. The 'job-completed-
with-warnings' SHOULD be supported, if the implementation
detects warnings. The 'job-completed-with-errors' SHOULD be
supported if the implementation detects errors. The 'job-
restartable' SHOULD be supported if the Restart-Job operation
is supported.
12. Section 4.3.10 - allowed a Printer to localize the "job-
detailed-status-message" Job Description attribute, but
indicated that such localization might obscure the technical
meaning of such messages.
13. Section 4.3.14 - changed the "time-at-creation", "time-at-
processing", and "time-at-completed" Event Time Job
Description attributes from OPTIONAL to REQUIRED.
14. Section 4.3.14.4 - added the REQUIRED "job-printer-up-time
(integer(1:MAX))" Job Description attribute as an alias for
"printer-up-time" to reduce number of operations to get job
times.
15. Section 4.4.2 - added the REQUIRED "uri-authentication-
supported (1setOf type2 keyword)" Printer Description
attribute to describe the Client Authentication used by each
Printer URI.
16. Section 4.4.12 - changed "printer-state-reasons" Printer
Description attribute from OPTIONAL to REQUIRED.
17. Section 4.4.12 - changed 'paused' value of "printer-state-
reasons" to MUST if Pause-Printer operation is supported.
18. Section 4.4.14 - added the REQUIRED "ipp-versions-supported
(1setOf keyword)" Printer Description attribute, since IPP/1.1
Printers do not have to support version '1.0' conformance
requirements. Section 4.4.16 - added the "multiple-document-
jobs-supported (boolean)" Printer Description attribute so
that a client can tell whether a Printer that supports
Create-Job/Send-Document supports multiple document jobs or
not. This attribute is REQUIRED if the Create-Job operation
is supported.
19. Section 4.4.24 - changed the "queued-job-count" Printer
Description attribute from RECOMMENDED to REQUIRED.
20. Section 4.4.32 - changed "compression-supported (1setOf type3
keyword)" Printer Description attribute from OPTIONAL to
REQUIRED.
21. Section 5.1 - changed the client security requirements from
RECOMMENDED non-standards track SSL3 to MUST support Client
Authentication as defined in the IPP/1.1 Encoding and
Transport document [RFC2910]. A client SHOULD support
Operation Privacy and Server Authentication as defined in the
IPP/1.1 Encoding and Transport document [RFC2910].
22. Section 5.2.7 - changed the IPP object security requirements
from OPTIONAL non-standards track SSL3 to SHOULD contain
support for Client Authentication as defined in the IPP/1.1
Encoding and Transport document [RFC2910]. A Printer
implementation MAY allow an administrator to configure the
Printer so that all, some, or none of the users are
authenticated. An IPP Printer implementation SHOULD contain
support for Operation Privacy and Server Authentication as
defined in the IPP/1.1 Encoding and Transport document
[RFC2910]. A Printer implementation MAY allow an
administrator to configure the degree of support for Operation
Privacy and Server Authentication. Security MUST NOT be
compromised when the client supplies a lower version-number in
a request.
23. Section 14 (Appendix C): Corrected typo, changing the keyword
'iso-10-white' to 'iso-a10-white'.
See also the "IPP/1.1 Encoding and Transport" [RFC2910] document for
differences between IPP/1.0 [RFC2565] and IPP/1.1 [RFC2910].
18. Full Copyright Statement
Copyright (C) The Internet Society (2000). 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.