RFC 2566
Internet Printing Protocol/1.0: Model and Semantics
14. APPENDIX C: "media" keyword values Standard keyword values are taken from several sources. Standard values are defined (taken from DPA[ISO10175] and the Printer MIB[RFC1759]): 'default': The default medium for the output device 'iso-a4-white': Specifies the ISO A4 white medium 'iso-a4-colored': Specifies the ISO A4 colored medium 'iso-a4-transparent' Specifies the ISO A4 transparent medium 'iso-a3-white': Specifies the ISO A3 white medium 'iso-a3-colored': Specifies the ISO A3 colored medium 'iso-a5-white': Specifies the ISO A5 white medium 'iso-a5-colored': Specifies the ISO A5 colored medium 'iso-b4-white': Specifies the ISO B4 white medium 'iso-b4-colored': Specifies the ISO B4 colored medium 'iso-b5-white': Specifies the ISO B5 white medium 'iso-b5-colored': Specifies the ISO B5 colored medium 'jis-b4-white': Specifies the JIS B4 white medium 'jis-b4-colored': Specifies the JIS B4 colored medium 'jis-b5-white': Specifies the JIS B5 white medium 'jis-b5-colored': Specifies the JIS B5 colored medium The following standard values are defined for North American media: 'na-letter-white': Specifies the North American letter white medium 'na-letter-colored': Specifies the North American letter colored medium 'na-letter-transparent': Specifies the North American letter transparent medium 'na-legal-white': Specifies the North American legal white medium 'na-legal-colored': Specifies the North American legal colored medium The following standard values are defined for envelopes: 'iso-b4-envelope': Specifies the ISO B4 envelope medium 'iso-b5-envelope': Specifies the ISO B5 envelope medium 'iso-c3-envelope': Specifies the ISO C3 envelope medium 'iso-c4-envelope': Specifies the ISO C4 envelope medium 'iso-c5-envelope': Specifies the ISO C5 envelope medium 'iso-c6-envelope': Specifies the ISO C6 envelope medium 'iso-designated-long-envelope': Specifies the ISO Designated Long envelope medium 'na-10x13-envelope': Specifies the North American 10x13 envelope medium
'na-9x12-envelope': Specifies the North American 9x12 envelope
medium
'monarch-envelope': Specifies the Monarch envelope
'na-number-10-envelope': Specifies the North American number 10
business envelope medium
'na-7x9-envelope': Specifies the North American 7x9 inch envelope
'na-9x11-envelope': Specifies the North American 9x11 inch envelope
'na-10x14-envelope': Specifies the North American 10x14 inch
envelope
'na-number-9-envelope': Specifies the North American number 9
business envelope
'na-6x9-envelope': Specifies the North American 6x9 inch envelope
'na-10x15-envelope': Specifies the North American 10x15 inch
envelope
The following standard values are defined for the less commonly used
media (white-only):
'executive-white': Specifies the white executive medium
'folio-white': Specifies the folio white medium
'invoice-white': Specifies the white invoice medium
'ledger-white': Specifies the white ledger medium
'quarto-white': Specified the white quarto medium
'iso-a0-white': Specifies the ISO A0 white medium
'iso-a1-white': Specifies the ISO A1 white medium
'iso-a2-white': Specifies the ISO A2 white medium
'iso-a6-white': Specifies the ISO A6 white medium
'iso-a7-white': Specifies the ISO A7 white medium
'iso-a8-white': Specifies the ISO A8 white medium
'iso-a9-white': Specifies the ISO A9 white medium
'iso-10-white': Specifies the ISO A10 white medium
'iso-b0-white': Specifies the ISO B0 white medium
'iso-b1-white': Specifies the ISO B1 white medium
'iso-b2-white': Specifies the ISO B2 white medium
'iso-b3-white': Specifies the ISO B3 white medium
'iso-b6-white': Specifies the ISO B6 white medium
'iso-b7-white': Specifies the ISO B7 white medium
'iso-b8-white': Specifies the ISO B8 white medium
'iso-b9-white': Specifies the ISO B9 white medium
'iso-b10-white': Specifies the ISO B10 white medium
'jis-b0-white': Specifies the JIS B0 white medium
'jis-b1-white': Specifies the JIS B1 white medium
'jis-b2-white': Specifies the JIS B2 white medium
'jis-b3-white': Specifies the JIS B3 white medium
'jis-b6-white': Specifies the JIS B6 white medium
'jis-b7-white': Specifies the JIS B7 white medium
'jis-b8-white': Specifies the JIS B8 white medium
'jis-b9-white': Specifies the JIS B9 white medium
'jis-b10-white': Specifies the JIS B10 white medium
The following standard values are defined for engineering media:
'a': Specifies the engineering A size medium
'b': Specifies the engineering B size medium
'c': Specifies the engineering C size medium
'd': Specifies the engineering D size medium
'e': Specifies the engineering E size medium
The following standard values are defined for input-trays (from ISO
DPA and the Printer MIB):
'top': The top input tray in the printer.
'middle': The middle input tray in the printer.
'bottom': The bottom input tray in the printer.
'envelope': The envelope input tray in the printer.
'manual': The manual feed input tray in the printer.
'large-capacity': The large capacity input tray in the printer.
'main': The main input tray
'side': The side input tray
The following standard values are defined for media sizes (from ISO
DPA):
'iso-a0': Specifies the ISO A0 size: 841 mm by 1189 mm as defined
in ISO 216
'iso-a1': Specifies the ISO A1 size: 594 mm by 841 mm as defined in
ISO 216
'iso-a2': Specifies the ISO A2 size: 420 mm by 594 mm as defined in
ISO 216
'iso-a3': Specifies the ISO A3 size: 297 mm by 420 mm as defined in
ISO 216
'iso-a4': Specifies the ISO A4 size: 210 mm by 297 mm as defined in
ISO 216
'iso-a5': Specifies the ISO A5 size: 148 mm by 210 mm as defined in
ISO 216
'iso-a6': Specifies the ISO A6 size: 105 mm by 148 mm as defined in
ISO 216
'iso-a7': Specifies the ISO A7 size: 74 mm by 105 mm as defined in
ISO 216
'iso-a8': Specifies the ISO A8 size: 52 mm by 74 mm as defined in
ISO 216
'iso-a9': Specifies the ISO A9 size: 37 mm by 52 mm as defined in
ISO 216
'iso-a10': Specifies the ISO A10 size: 26 mm by 37 mm as defined in
ISO 216
'iso-b0': Specifies the ISO B0 size: 1000 mm by 1414 mm as defined
in ISO 216
'iso-b1': Specifies the ISO B1 size: 707 mm by 1000 mm as defined
in ISO 216
'iso-b2': Specifies the ISO B2 size: 500 mm by 707 mm as defined in
ISO 216
'iso-b3': Specifies the ISO B3 size: 353 mm by 500 mm as defined in
ISO 216
'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in
ISO 216
'iso-b5': Specifies the ISO B5 size: 176 mm by 250 mm as defined in
ISO 216
'iso-b6': Specifies the ISO B6 size: 125 mm by 176 mm as defined in
ISO 216
'iso-b7': Specifies the ISO B7 size: 88 mm by 125 mm as defined in
ISO 216
'iso-b8': Specifies the ISO B8 size: 62 mm by 88 mm as defined in
ISO 216
'iso-b9': Specifies the ISO B9 size: 44 mm by 62 mm as defined in
ISO 216
'iso-b10': Specifies the ISO B10 size: 31 mm by 44 mm as defined in
ISO 216
'na-letter': Specifies the North American letter size: 8.5 inches by
11 inches
'na-legal': Specifies the North American legal size: 8.5 inches by
14 inches
'executive': Specifies the executive size (7.25 X 10.5 in)
'folio': Specifies the folio size (8.5 X 13 in)
'invoice': Specifies the invoice size (5.5 X 8.5 in)
'ledger': Specifies the ledger size (11 X 17 in)
'quarto': Specifies the quarto size (8.5 X 10.83 in)
'iso-c3': Specifies the ISO C3 size: 324 mm by 458 mm as defined in
ISO 269
'iso-c4': Specifies the ISO C4 size: 229 mm by 324 mm as defined in
ISO 269
'iso-c5': Specifies the ISO C5 size: 162 mm by 229 mm as defined in
ISO 269
'iso-c6': Specifies the ISO C6 size: 114 mm by 162 mm as defined in
ISO 269
'iso-designated-long': Specifies the ISO Designated Long size: 110
mm by 220 mm as defined in ISO 269
'na-10x13-envelope': Specifies the North American 10x13 size: 10
inches by 13 inches
'na-9x12-envelope': Specifies the North American 9x12 size: 9
inches by 12 inches
'na-number-10-envelope': Specifies the North American number 10
business envelope size: 4.125 inches by 9.5 inches
'na-7x9-envelope': Specifies the North American 7x9 inch envelope
size
'na-9x11-envelope': Specifies the North American 9x11 inch envelope
size
'na-10x14-envelope': Specifies the North American 10x14 inch
envelope size
'na-number-9-envelope': Specifies the North American number 9
business envelope size
'na-6x9-envelope': Specifies the North American 6x9 envelope size
'na-10x15-envelope': Specifies the North American 10x15 envelope
size
'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5
in)
'jis-b0': Specifies the JIS B0 size: 1030mm x 1456mm
'jis-b1': Specifies the JIS B1 size: 728mm x 1030mm
'jis-b2': Specifies the JIS B2 size: 515mm x 728mm
'jis-b3': Specifies the JIS B3 size: 364mm x 515mm
'jis-b4': Specifies the JIS B4 size: 257mm x 364mm
'jis-b5': Specifies the JIS B5 size: 182mm x 257mm
'jis-b6': Specifies the JIS B6 size: 128mm x 182mm
'jis-b7': Specifies the JIS B7 size: 91mm x 128mm
'jis-b8': Specifies the JIS B8 size: 64mm x 91mm
'jis-b9': Specifies the JIS B9 size: 45mm x 64mm
'jis-b10': Specifies the JIS B10 size: 32mm x 45mm
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 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 IPP/1.0.
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",
"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.
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 specification. 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 specification 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. IPP 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. 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 IPP client queries the "printer-uri-supported" attribute in the directory entry
and then 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-security-supported RECOMMENDED Section 4.4.2
printer-name RECOMMENDED Section 4.4.3
printer-location RECOMMENDED Section 4.4.4
printer-info OPTIONAL Section 4.4.5
printer-more-info OPTIONAL Section 4.4.6
printer-make-and-model RECOMMENDED Section 4.4.8
charset-supported OPTIONAL Section 4.4.15
generated-natural-language-
supported OPTIONAL Section 4.4.17
document-format-supported RECOMMENDED Section 4.4.19
color-supported RECOMMENDED Section 4.4.23
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: Change History for the IPP Model and Semantics document The following substantive changes and major clarifications have been made to this document from the June 30, 1998 version based on the interoperability testing that took place September 23-25 1998 and subsequent mailing list and meeting discussions. They are listed in the order of occurrence in the document. These changes are the ones that might affect implementations. Clarifications that are unlikely to affect implementations are not listed. The issue numbers refer to the IPP Issues List which is available in the following directory: ftp://ftp.pwg.org/pub/pwg/ipp/approved-clarifications/ Section Description global Replaced TLS references with SSL3 references as agreed with our Area Director on 11/12/1998. global Removed the indications that some of these IPP documents are informational, since the intent is now to publish all IPP/1.0 documents as informational as agreed with our Area Director on 11/12/1998. 3.1.2, Clarify that the IPP object SHOULD NOT validate the 16.3.3 range of the request-id being 1 to 2**31-1, but accepts [now ipp- and returns any value. Clients MUST still keep in the iig] range 1 to 2**31 though. If the request is terminated before the complete "request-id" is received, the IPP object rejects the request and returns a response with a "request-id" of 0 (Issue 1.36). 3.1.4.1, Clarified that when a client submits a request in a 13.1.4.14 charset that is not supported, the IPP object SHOULD return any 'text' or 'name' attributes in the 'utf-8' charset, if it returns any, since clients and IPP objects MUST support 'utf-8'. (Issue 1.19) 3.1.4.1 Clarified Section 3.1.4.1 Request Operation Attributes that a client MAY use the attribute level natural language override (text/nameWithLanguage) redundantly in a request. (Issue 1.46) 3.1.4.2 Clarified Section 3.1.4.2 Response Operation Attributes that an IPP object MAY use the attribute level natural language override (text/nameWithLanguage) redundantly in a response. (Issue 1.46)
3.1.6 Clarified section 3.1.6: If the Printer object supports
the "status-message" operation attribute, it NEED NOT
return a status message for the following error status
codes: 'client-error-bad-request', 'client-error-
charset-not-supported', 'server-error-internal-error',
'server-error-operation-not-supported', and 'server-
error-version-not-supported'.
3.2.1.1 Clarified that if a client is not supplying any Job
Template attributes in a request, the client SHOULD omit
Group 2 rather than sending an empty group. However, a
Printer object MUST be able to accept an empty group.
This makes [RFC2566] agree with [RFC2565]. (Issue 1.16)
3.2.1.2, Clarified that if an IPP object is not returning any
3.2.5.2, Unsupported Attributes in a response, the IPP object
3.2.6.2, SHOULD omit Group 2 rather than sending an empty group.
3.3.1.2, However, a client MUST be able to accept an empty group.
3.3.3.2, This makes [RFC2566] agree with [RFC2565]. (Issue 1.17)
3.3.4.2
3.2.1.2, Clarified that an IPP object MUST treat an unsupported
13.1.2.2, attribute syntax supplied in a request in the same way
13.1.4.12 as an unsupported value. The IPP object MUST return the
attribute, the attribute syntax, and the value in the
Unsupported Attributes group. (Issue 1.26)
3.2.5.2, Clarified for Get-Printer-Attributes, Get-Jobs, and Get-
3.2.6.2, Job-Attributes that an IPP object MUST return
3.3.4.2, 'successful-ok-ignored-or-substituted-attributes' (0x1),
13.1.2.1, rather than 'successful-ok' (0x0), when a client
13.1.2.2, supplies unsupported attributes as values of the
13.1.4.12 'requested-attributes' operation attribute. (Issue
1.24)
Also clarified that the response NEED NOT contain the
"requested-attributes" operation attribute with any
supplied values (attribute keywords) that were requested
by the client but are not supported by the IPP object.
(Issue 1.18)
3.2.6.2 Deleted the job-level natural language override (NLO)
4.1.1.2 from Section 3.2.6.2 Get-Jobs Response so that all
4.3.24 operation responses are the same with respect to NLO.
(Issue 1.47)
3.3.1 Clarified that an IPP Printer that supports the Create-
Job operation MUST handle the situation when a client
does not supply Send-Document or Send-URI operations
within a one- to four-minute time period. Also
clarified that a client MUST send documents in a multi-
document job without undue or unbounded delay. (Issue
1.28)
3.3.3 Clarified that the IPP object MUST reject a Cancel-Job
request if the job is in 'completed', 'canceled', or
'aborted' job states. (Issue 1.12)
4.1.2.3 Added this new sub-section: it specifies that
nameWithoutLanguage plus the implicit natural language
matches nameWithLanguage, if the values and natural
languages are the same. Also added that keyword never
matches nameWithLanguage or nameWithoutLanguage.
Clarified that if both have countries, that the
countries SHOULD match as well. If either do not, then
the country field SHOULD be ignored. (Issues 1.33 and
1.34)
4.1.5 Clarified regarding the case-insensitivity of URLs to
refer only to the RFCs that define them. (Issue 1.10)
4.1.11 Clarified that 'boolean' is not a full-sized integer.
(Issue 1.38)
4.1.15 Clarified that 'resolution' is not three full-sized
integers. (Issue 1.20)
4.2.* Clarified that standard values are keywords or enums,
not names. (Issue 1.49).
4.2.4 Added the 'single-document-new-sheet' value to Section
4.2.4 multiple-document-handling. (Issue 1.54)
4.4.18, Clarified that the "document-format-default" and
4.4.19 "document-format-supported" Printer Description
attributes are REQUIRED to agree with the table. (Issue
1.4)
4.4.21 Changed "queued-job-count" from OPTIONAL to RECOMMENDED.
(Issue 1.14)
4.4.28 Clarified that the implementation supplied value for the
"multiple-operation-time-out" attribute SHOULD be
between 30 and 240 seconds, though the implementation
MAY allow the administrator to set values, and MAY allow
values outside this range. (Issue 1.28)
5.1, Clarified Client Conformance that if a client supports
5.2.5 an attribute of 'text' attribute syntax, that it MUST
support both the textWithoutLanguage and the
textWithLanguage forms. Same for 'name' attribute
syntax. Same for an IPP object (Issue 1.48)
6.5, Added new section to allow Attribute Groups to be
12.8 registered as extensions for being passed in operation
requests and responses. (Issue 1.25)
7. Updated the table of text and name attributes to agree
with Section 4.2.
8.5 Added a new section RECOMMENDING that the Get-Jobs
SHOULD return non-IPP jobs whether or not assigning them
a job-id and job-uri. Also RECOMMENDED generating, if
possible, job-id and job-uri and supporting other IPP
operations on foreign jobs as an implementer option.
(Issue 1.32)
9. Updated document references.
13.1.4.14 Clarified 'client-error-charset-not-supported' that
'utf-8' must be used for any 'text' or 'name' attributes
returned in the error response (Issue 1.19).
13.1.5.9 Added a new error code 'server-error-job-canceled'
(0x0508) to be returned if a job is canceled by another
client or aborted by the IPP object while the first
client is still sending the document data. (Issue 1.29)
15.3, Moved these sections recommending operation processing
15.4 steps to the new Implementer's Guide (informational).
There indicated that all of the error checks are not
required, so an IPP object MAY be forgiving and accept
non-conforming requests. However, a conforming client
MUST supply requests that would pass all of the error
checks indicated. (Issue 1.21)
16 Changed directory schema attributes from REQUIRED to
RECOMMENDED. Changed some of the OPTIONAL to
RECOMMENDED to agree with the SLP template. Changed the
"charset-supported" and "natural-language-supported"
from REQUIRED to OPTIONAL. Recommended that the names
be the same in a directory entry as the IPP attribute
names. (Issue 1.53)
18. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.