RFC2566 - Internet Printing Protocol/1.0: Model and Semantics(6)
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC2434,
October 1998.
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner
"Internet Printing Protocol/1.0: Encoding and
Transport", RFC2565, April 1999.
[RFC2567] Wright, D., "Design Goals for an Internet Printing
Protocol", RFC2567, April 1999.
[RFC2568] Zilles, S., "Rationale for the Structure and Model and
Protocol for the Internet Printing Protocol", RFC2568,
April 1999.
[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
"Mapping between LPD and IPP Protocols", RFC2569, April
1999.
[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC2579, April
1999.
[SSL] Netscape, The SSL Protocol, Version 3, (Text version
3.02), November 1996.
[SWP] P. Moore, B. Jahromi, S. Butler, "Simple Web Printing
SWP/1.0", May 7, 1997,
ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/swp9705.pdf
10. Authors' Addresses
Scott A. Isaacson (Editor)
Novell, Inc.
122 E 1700 S
Provo, UT 84606
Phone: 801-861-7366
Fax: 801-861-2517
EMail: sisaacson@novell.com
Tom Hastings
Xerox Corporation
737 Hawaii St.
El Segundo, CA 90245
Phone: 310-333-6413
Fax: 310-333-5514
EMail: hastings@cp10.es.xerox.com
Robert Herriot
Xerox Corporation
3400 Hillview Ave., Bldg #1
Palo Alto, CA 94304
Phone: 650-813-7696
Fax: 650-813-6860
EMail: robert.herriot@pahv.xerox.com
Roger deBry
Utah Valley State College
Orem, UT 84058
Phone: (801) 222-8000
EMail: debryro@uvsc.edu
Patrick Powell
Astart Technologies
9475 Chesapeake Dr., Suite D
San Diego, CA 95123
Phone: (619) 874-6543
Fax: (619) 279-8424
EMail: papowell@astart.com
IPP Mailing List: ipp@pwg.org
IPP Mailing List Subscription: ipp-request@pwg.org
IPP Web Page: http://www.pwg.org/ipp/
Implementers of this specification are encouraged to join IPP Mailing
List in order to participate in any discussions of clarification
issues and review of registration proposals for additional attributes
and values.
Other Participants:
Chuck Adams - Tektronix
Jeff Barnett - IBM
Ron Bergman - Dataproducts Corp.
Sylvan Butler - HP
Keith Carter - IBM Corporation
Jeff Copeland - QMS
Andy Davidson - Tektronix
Mabry Dozier - QMS
Lee Farrell - Canon Information Systems
Steve Gebert - IBM
Babek Jahromi - Microsoft
David Kellerman - Northlake Software
Rick Landau - Digital
Greg LeClair - Epson
Harry Lewis - IBM
Pete Loya - HP
Ray Lutz - Cognisys
Mike MacKay - Novell, Inc.
Daniel Manchala - Xerox
Carl-Uno Manros - Xerox
Jay Martin - Underscore
Larry Masinter - Xerox
Stan McConnell - Xerox
Ira McDonald - High North Inc.
Paul Moore - Microsoft
Tetsuya Morita - Ricoh
Yuichi Niwa - Ricoh
Pat Nogay - IBM
Ron Norton - Printronics
Bob Pentecost - HP
Rob Rhoads - Intel
Xavier Riley - Xerox
David Roach - Unisys
Stuart Rowley - Kyocera
Hiroyuki Sato - Canon
Bob Setterbo - Adobe
Devon Taylor - Novell, Inc.
Mike Timperman - Lexmark
Randy Turner - Sharp
Atsushi Yuki - Kyocera
Rick Yardumian - Xerox
Lloyd Young - Lexmark
Bill Wagner - DPI
Jim Walker - DAZEL
Chris Wellens - Interworking Labs
Rob Whittle - Novell, Inc.
Don Wright - Lexmark
Peter Zehler - Xerox
Steve Zilles - Adobe
11. Formats for IPP Registration Proposals
In order to propose an IPP extension for registration, the proposer
must submit an application to IANA by email to "iana@iana.org" or by
filling out the appropriate form on the IANA web pages
(http://www.iana.org). This section specifies the required
information and the formats for proposing registrations of extensions
to IPP as provided in Section 6 for:
1. type2 'keyword' attribute values
2. type3 'keyword' attribute values
3. type2 'enum' attribute values
4. type3 'enum' attribute values
5. attributes
6. attribute syntaxes
7. operations
8. status codes
11.1 Type2 keyword attribute values registration
Type of registration: type2 keyword attribute value
Name of attribute to which this keyword specification is to be added:
Proposed keyword name of this keyword value:
Specification of this keyword value (follow the style of IPP Model
Section 4.1.2.3):
Name of proposer:
Address of proposer:
Email address of proposer:
Note: For type2 keywords, the Designated Expert will be the point of
contact for the approved registration specification, if any
maintenance of the registration specification is needed.
11.2 Type3 keyword attribute values registration
Type of registration: type3 keyword attribute value
Name of attribute to which this keyword specification is to be added:
Proposed keyword name of this keyword value:
Specification of this keyword value (follow the style of IPP Model
Section 4.1.2.3):
Name of proposer:
Address of proposer:
Email address of proposer:
Note: For type3 keywords, the proposer will be the point of contact
for the approved registration specification, if any maintenance of
the registration specification is needed.
11.3 Type2 enum attribute values registration
Type of registration: type2 enum attribute value
Name of attribute to which this enum specification is to be added:
Keyword symbolic name of this enum value:
Numeric value (to be assigned by the IPP Designated Expert in
consultation with IANA):
Specification of this enum value (follow the style of IPP Model
Section 4.1.4):
Name of proposer:
Address of proposer:
Email address of proposer:
Note: For type2 enums, the Designated Expert will be the point of
contact for the approved registration specification, if any
maintenance of the registration specification is needed.
11.4 Type3 enum attribute values registration
Type of registration: type3 enum attribute value
Name of attribute to which this enum specification is to be added:
Keyword symbolic name of this enum value:
Numeric value (to be assigned by the IPP Designated Expert in
consultation with IANA):
Specification of this enum value (follow the style of IPP Model
Section 4.1.4):
Name of proposer:
Address of proposer:
Email address of proposer:
Note: For type3 enums, the proposer will be the point of contact for
the approved registration specification, if any maintenance of the
registration specification is needed.
11.5 Attribute registration
Type of registration: attribute
Proposed keyword name of this attribute:
Types of attribute (Operation, Job Template, Job Description,
Printer Description):
Operations to be used with if the attribute is an operation
attribute:
Object (Job, Printer, etc. if bound to an object):
Attribute syntax(es) (include 1setOf and range as in Section 4.2):
If attribute syntax is 'keyword' or 'enum', is it type2 or type3:
If this is a Printer attribute, MAY the value returned depend on
"document-format" (See Section 6.2):
If this is a Job Template attribute, how does its specification
depend on the value of the "multiple-document-handling" attribute:
Specification of this attribute (follow the style of IPP Model
Section 4.2):
Name of proposer:
Address of proposer:
Email address of proposer:
Note: For attributes, the IPP Designated Expert will be the point of
contact for the approved registration specification, if any
maintenance of the registration specification is needed.
11.6 Attribute Syntax registration
Type of registration: attribute syntax
Proposed name of this attribute syntax:
Type of attribute syntax (integer, octetString, character-string,
see [RFC2565]):
Numeric value (to be assigned by the IPP Designated Expert in
consultation with IANA):
Specification of this attribute (follow the style of IPP Model
Section 4.1):
Name of proposer:
Address of proposer:
Email address of proposer:
Note: For attribute syntaxes, the IPP Designated Expert will be the
point of contact for the approved registration specification, if any
maintenance of the registration specification is needed.
11.7 Operation registration
Type of registration: operation
Proposed name of this operation:
Numeric operation-id value (to be assigned by the IPP Designated
Expert in consultation with IANA):
Object Target (Job, Printer, etc. that operation is upon):
Specification of this attribute (follow the style of IPP Model
Section 3):
Name of proposer:
Address of proposer:
Email address of proposer:
Note: For operations, the IPP Designated Expert will be the point of
contact for the approved registration specification, if any
maintenance of the registration specification is needed.
11.8 Attribute Group registration
Type of registration: attribute group
Proposed name of this attribute group:
Numeric tag according to [RFC2565] (to be assigned by the IPP
Designated Expert in consultation with IANA):
Operation requests and group number for each operation in which the
attribute group occurs:
Operation responses and group number for each operation in which the
attribute group occurs:
Specification of this attribute group (follow the style of IPP Model
Section 3):
Name of proposer:
Address of proposer:
Email address of proposer:
Note: For attribute groups, the IPP Designated Expert will be the
point of contact for the approved registration specification, if any
maintenance of the registration specification is needed.
11.9 Status code registration
Type of registration: status code
Keyword symbolic name of this status code value:
Numeric value (to be assigned by the IPP Designated Expert in
consultation with IANA):
Operations that this status code may be used with:
Specification of this status code (follow the style of IPP Model
Section 14 APPENDIX B: Status Codes and Suggested Status Code
Messages):
Name of proposer:
Address of proposer:
Email address of proposer:
Note: For status codes, the Designated Expert will be the point of
contact for the approved registration specification, if any
maintenance of the registration specification is needed.
12. APPENDIX A: Terminology
This specification uses the terminology defined in this section.
12.1 Conformance Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC2119 [RFC2119].
12.1.1 NEED NOT
This term is not included in RFC2119. The verb "NEED NOT" indicates
an action that the subject of the sentence does not have to implement
in order to claim conformance to the standard. The verb "NEED NOT"
is used instead of "MAY NOT" since "MAY NOT" sounds like a
prohibition.
12.2 Model Terminology
12.2.1 Keyword
Keywords are used within this document as identifiers of semantic
entities within the abstract model (see section 4.1.2.3). Attribute
names, some attribute values, attribute syntaxes, and attribute group
names are represented as keywords.
12.2.2 Attributes
An attribute is an item of information that is associated with an
instance of an IPP object. An attribute consists of an attribute
name and one or more attribute values. Each attribute has a specific
attribute syntax. All object attributes are defined in section 4 and
all operation attributes are defined in section 3.
Job Template Attributes are described in section 4.2. The client
optionally supplies Job Template attributes in a create request
(operation requests that create Job objects). The Printer object has
associated attributes which define supported and default values for
the Printer.
12.2.2.1 Attribute Name
Each attribute is uniquely identified in this document by its
attribute name. An attribute name is a keyword. The keyword
attribute name is given in the section header describing that
attribute. In running text in this document, attribute names are
indicated inside double quotation marks (") where the quotation marks
are not part of the keyword itself.
12.2.2.2 Attribute Group Name
Related attributes are grouped into named groups. The name of the
group is a keyword. The group name may be used in place of naming
all the attributes in the group explicitly. Attribute groups are
defined in section 3.
12.2.2.3 Attribute Value
Each attribute has one or more values. Attribute values are
represented in the syntax type specified for that attribute. In
running text in this document, attribute values are indicated inside
single quotation marks ('), whether their attribute syntax is
keyword, integer, text, etc. where the quotation marks are not part
of the value itself.
12.2.2.4 Attribute Syntax
Each attribute is defined using an explicit syntax type. In this
document, each syntax type is defined as a keyword with specific
meaning. The Encoding and Transport document [RFC2565] indicates the
actual "on-the-wire" encoding rules for each syntax type. Attribute
syntax types are defined in section 4.1.
12.2.3 Supports
By definition, a Printer object supports an attribute only if that
Printer object responds with the corresponding attribute populated
with some value(s) in a response to a query for that attribute. A
Printer object supports an attribute value if the value is one of the
Printer object's "supported values" attributes. The device behind a
Printer object may exhibit a behavior that corresponds to some IPP
attribute, but if the Printer object, when queried for that
attribute, doesn't respond with the attribute, then as far as IPP is
concerned, that implementation does not support that feature. If the
Printer object's "xxx-supported" attribute is not populated with a
particular value (even if that value is a legal value for that
attribute), then that Printer object does not support that particular
value.
A conforming implementation MUST support all REQUIRED attributes.
However, even for REQUIRED attributes, conformance to IPP does not
mandate that all implementations support all possible values
representing all possible job processing behaviors and features. For
example, if a given instance of a Printer supports only certain
document formats, then that Printer responds with the "document-
format-supported" attribute populated with a set of values, possibly
only one, taken from the entire set of possible values defined for
that attribute. This limited set of values represents the Printer's
set of supported document formats. Supporting an attribute and some
set of values for that attribute enables IPP end users to be aware of
and make use of those features associated with that attribute and
those values. If an implementation chooses to not support an
attribute or some specific value, then IPP end users would have no
ability to make use of that feature within the context of IPP itself.
However, due to existing practice and legacy systems which are not
IPP aware, there might be some other mechanism outside the scope of
IPP to control or request the "unsupported" feature (such as embedded
instructions within the document data itself).
For example, consider the "finishings-supported" attribute.
1) If a Printer object is not physically capable of stapling, the
"finishings-supported" attribute MUST NOT be populated with the
value of 'staple'.
2) A Printer object is physically capable of stapling, however an
implementation chooses not to support stapling in the IPP
"finishings" attribute. In this case, 'staple' MUST NOT be a
value in the "finishings-supported" Printer object attribute.
Without support for the value 'staple', an IPP end user would
have no means within the protocol itself to request that a Job
be stapled. However, an existing document data formatter might
be able to request that the document be stapled directly with an
embedded instruction within the document data. In this case,
the IPP implementation does not "support" stapling, however the
end user is still able to have some control over the stapling of
the completed job.
3) A Printer object is physically capable of stapling, and an
implementation chooses to support stapling in the IPP
"finishings" attribute. In this case, 'staple' MUST be a value
in the "finishings-supported" Printer object attribute. Doing
so, would enable end users to be aware of and make use of the
stapling feature using IPP attributes.
Even though support for Job Template attributes by a Printer object
is OPTIONAL, it is RECOMMENDED that if the device behind a Printer
object is capable of realizing any feature or function that
corresponds to an IPP attribute and some associated value, then that
implementation SHOULD support that IPP attribute and value.
The set of values in any of the supported value attributes is set
(populated) by some administrative process or automatic sensing
mechanism that is outside the scope of IPP. For administrative
policy and control reasons, an administrator may choose to make only
a subset of possible values visible to the end user. In this case,
the real output device behind the IPP Printer abstraction may be
capable of a certain feature, however an administrator is specifying
that access to that feature not be exposed to the end user through
the IPP protocol. Also, since a Printer object may represent a
logical print device (not just a physical device) the actual process
for supporting a value is undefined and left up to the
implementation. However, if a Printer object supports a value, some
manual human action may be needed to realize the semantic action
associated with the value, but no end user action is required.
For example, if one of the values in the "finishings-supported"
attribute is 'staple', the actual process might be an automatic
staple action by a physical device controlled by some command sent to
the device. Or, the actual process of stapling might be a manual
action by an operator at an operator attended Printer object.
For another example of how supported attributes function, consider a
system administrator who desires to control all print jobs so that no
job sheets are printed in order to conserve paper. To force no job
sheets, the system administrator sets the only supported value for
the "job-sheets-supported" attribute to 'none'. In this case, if a
client requests anything except 'none', the create request is
rejected or the "job-sheets" value is ignored (depending on the value
of "ipp-attribute-fidelity"). To force the use of job start/end
sheets on all jobs, the administrator does not include the value '
none' in the "job-sheets-supported" attribute. In this case, if a
client requests 'none', the create request is rejected or the "job-
sheets" value is ignored (again depending on the value of "ipp-
attribute-fidelity").
12.2.4 print-stream page
A "print-stream page" is a page according to the definition of pages
in the language used to express the document data.
12.2.5 impression
An "impression" is the image (possibly many print-stream pages in
different configurations) imposed onto a single media page.
13. APPENDIX B: Status Codes and Suggested Status Code Messages
This section defines status code enum keywords and values that are
used to provide semantic information on the results of an operation
request. Each operation response MUST include a status code. The
response MAY also contain a status message that provides a short
textual description of the status. The status code is intended for
use by automata, and the status message is intended for the human end
user. Since the status message is an OPTIONAL component of the
operation response, an IPP application (i.e., a browser, GUI, print
driver or gateway) is NOT REQUIRED to examine or display the status
message, since it MAY not be returned to the application.
The prefix of the status keyword defines the class of response as
follows:
"informational" - Request received, continuing process
"successful" - The action was successfully received, understood,
and accepted
"redirection" - Further action must be taken in order to complete
the request
"client-error" - The request contains bad syntax or cannot be
fulfilled
"server-error" - The IPP object failed to fulfill an apparently
valid request
As with type2 enums, IPP status codes are extensible. IPP clients
are NOT REQUIRED to understand the meaning of all registered status
codes, though such understanding is obviously desirable. However,
IPP clients MUST understand the class of any status code, as
indicated by the prefix, and treat any unrecognized response as being
equivalent to the first status code of that class, with the exception
that an unrecognized response MUST NOT be cached. For example, if an
unrecognized status code of "client-error-xxx-yyy" is received by the
client, it can safely assume that there was something wrong with its
request and treat the response as if it had received a "client-
error-bad-request" status code. In such cases, IPP applications
SHOULD present the OPTIONAL message (if present) to the end user
since the message is likely to contain human readable information
which will help to explain the unusual status. The name of the enum
is the suggested status message for US English.
The status code values range from 0x0000 to 0x7FFF. The value ranges
for each status code class are as follows:
"successful" - 0x0000 to 0x00FF
"informational" - 0x0100 to 0x01FF
"redirection" - 0x0200 to 0x02FF
"client-error" - 0x0400 to 0x04FF
"server-error" - 0x0500 to 0x05FF
The top half (128 values) of each range (0x0n40 to 0x0nFF, for n = 0
to 5) is reserved for private use within each status code class.
Values 0x0600 to 0x7FFF are reserved for future assignment and MUST
NOT be used.
13.1 Status Codes
Each status code is described below. Section 13.1.5.9 contains a
table that indicates which status codes apply to which operations.
The Implementer's Guide [ipp-iig] describe the suggested steps for
processing IPP attributes for all operations, including returning
status codes.
13.1.1 Informational
This class of status code indicates a provisional response and is to
be used for informational purposes only.
There are no status codes defined in IPP/1.0 for this class of status
code.
13.1.2 Successful Status Codes
This class of status code indicates that the client's request was
successfully received, understood, and accepted.
13.1.2.1 successful-ok (0x0000)
The request has succeeded and no request attributes were substituted
or ignored. In the case of a response to a create request, the '
successful-ok' status code indicates that the request was
successfully received and validated, and that the Job object has been
created; it does not indicate that the job has been processed. The
transition of the Job object into the 'completed' state is the only
indicator that the job has been printed.
13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001)
The request has succeeded, but some supplied (1) attributes were
ignored or (2) unsupported values were substituted with supported
values or were ignored in order to perform the operation without
rejecting it. Unsupported attributes, attribute syntaxes, or values
MUST be returned in the Unsupported Attributes group of the response
for all operations. There is an exception to this rule for the query
operations: Get-Printer-Attributes, Get-Jobs, and Get-Job-Attributes
for the "requested-attributes" operation attribute only. When the
supplied values of the "requested-attributes" operation attribute are
requesting attributes that are not supported, the IPP object MAY, but
is NOT REQUIRED to, return the "requested-attributes" attribute in
the Unsupported Attribute response group (with the unsupported values
only). See section 3.2.1.2.
13.1.2.3 successful-ok-conflicting-attributes (0x0002)
The request has succeeded, but some supplied attribute values
conflicted with the values of other supplied attributes. These
conflicting values were either (1) substituted with (supported)
values or (2) the attributes were removed in order to process the job
without rejecting it. Attributes or values which conflict with other
attributes and have been substituted or ignored MUST be returned in
the Unsupported Attributes group of the response for all operations
as supplied by the client. See section 3.2.1.2.
13.1.3 Redirection Status Codes
This class of status code indicates that further action needs to be
taken to fulfill the request.
There are no status codes defined in IPP/1.0 for this class of status
code.
13.1.4 Client Error Status Codes
This class of status code is intended for cases in which the client
seems to have erred. The IPP object SHOULD return a message
containing an explanation of the error situation and whether it is a
temporary or permanent condition.
13.1.4.1 client-error-bad-request (0x0400)
The request could not be understood by the IPP object due to
malformed syntax (such as the value of a fixed length attribute whose
length does not match the prescribed length for that attribute - see
the Implementer's Guide [ipp-iig] ). The IPP application SHOULD NOT
repeat the request without modifications.
13.1.4.2 client-error-forbidden (0x0401)
The IPP object understood the request, but is refusing to fulfill it.
Additional authentication information or authorization credentials
will not help and the request SHOULD NOT be repeated. This status
code is commonly used when the IPP object does not wish to reveal
exactly why the request has been refused or when no other response is
applicable.
13.1.4.3 client-error-not-authenticated (0x0402)
The request requires user authentication. The IPP client may repeat
the request with suitable authentication information. If the request
already included authentication information, then this status code
indicates that authorization has been refused for those credentials.
If this response contains the same challenge as the prior response,
and the user agent has already attempted authentication at least
once, then the response message may contain relevant diagnostic
information. This status codes reveals more information than
"client-error-forbidden".
13.1.4.4 client-error-not-authorized (0x0403)
The requester is not authorized to perform the request. Additional
authentication information or authorization credentials will not help
and the request SHOULD NOT be repeated. This status code is used
when the IPP object wishes to reveal that the authentication
information is understandable, however, the requester is explicitly
not authorized to perform the request. This status codes reveals
more information than "client-error-forbidden" and "client-error-
not-authenticated".
13.1.4.5 client-error-not-possible (0x0404)
This status code is used when the request is for something that can
not happen. For example, there might be a request to cancel a job
that has already been canceled or aborted by the system. The IPP
client SHOULD NOT repeat the request.
13.1.4.6 client-error-timeout (0x0405)
The client did not produce a request within the time that the IPP
object was prepared to wait. For example, a client issued a Create-
Job operation and then, after a long period of time, issued a Send-
Document operation and this error status code was returned in
response to the Send-Document request (see section 3.3.1). The IPP
object might have been forced to clean up resources that had been
held for the waiting additional Documents. The IPP object was forced
to close the Job since the client took too long. The client SHOULD
NOT repeat the request without modifications.
13.1.4.7 client-error-not-found (0x0406)
The IPP object has not found anything matching the request URI. No
indication is given of whether the condition is temporary or
permanent. For example, a client with an old reference to a Job (a
URI) tries to cancel the Job, however in the mean time the Job might
have been completed and all record of it at the Printer has been
deleted. This status code, 'client-error-not-found' is returned
indicating that the referenced Job can not be found. This error
status code is also used when a client supplies a URI as a reference
to the document data in either a Print-URI or Send-URI operation, but
the document can not be found.
In practice, an IPP application should avoid a not found situation by
first querying and presenting a list of valid Printer URIs and Job
URIs to the end-user.
13.1.4.8 client-error-gone (0x0407)
The requested object is no longer available and no forwarding address
is known. This condition should be considered permanent. Clients
with link editing capabilities should delete references to the
request URI after user approval. If the IPP object does not know or
has no facility to determine, whether or not the condition is
permanent, the status code "client-error-not-found" should be used
instead.
This response is primarily intended to assist the task of maintenance
by notifying the recipient that the resource is intentionally
unavailable and that the IPP object administrator desires that remote
links to that resource be removed. It is not necessary to mark all
permanently unavailable resources as "gone" or to keep the mark for
any length of time -- that is left to the discretion of the IPP
object administrator.
13.1.4.9 client-error-request-entity-too-large (0x0408)
The IPP object is refusing to process a request because the request
entity is larger than the IPP object is willing or able to process.
An IPP Printer returns this status code when it limits the size of
print jobs and it receives a print job that exceeds that limit or
when the attributes are so many that their encoding causes the
request entity to exceed IPP object capacity.
13.1.4.10 client-error-request-value-too-long (0x0409)
The IPP object is refusing to service the request because one or more
of the client-supplied attributes has a variable length value that is
longer than the maximum length specified for that attribute. The IPP
object might not have sufficient resources (memory, buffers, etc.) to
process (even temporarily), interpret, and/or ignore a value larger
than the maximum length. Another use of this error code is when the
IPP object supports the processing of a large value that is less than
the maximum length, but during the processing of the request as a
whole, the object may pass the value onto some other system component
which is not able to accept the large value. For more details, see
the Implementer's Guide [ipp-iig] .
Note: For attribute values that are URIs, this rare condition is
only likely to occur when a client has improperly submitted a request
with long query information (e.g. an IPP application allows an end-
user to enter an invalid URI), when the client has descended into a
URI "black hole" of redirection (e.g., a redirected URI prefix that
points to a suffix of itself), or when the IPP object is under attack
by a client attempting to exploit security holes present in some IPP
objects using fixed-length buffers for reading or manipulating the
Request-URI.
13.1.4.11 client-error-document-format-not-supported (0x040A)
The IPP object is refusing to service the request because the
document data is in a format, as specified in the "document-format"
operation attribute, that is not supported by the Printer object.
This error is returned independent of the client-supplied "ipp-
attribute-fidelity". The Printer object MUST return this status
code, even if there are other attributes that are not supported as
well, since this error is a bigger problem than with Job Template
attributes.
13.1.4.12 client-error-attributes-or-values-not-supported (0x040B)
In a create request, if the Printer object does not support one or
more attributes, attribute syntaxes, or attribute values supplied in
the request and the client supplied the "ipp-attributes-fidelity"
operation attribute with the 'true' value, the Printer object MUST
return this status code. For example, if the request indicates '
iso-a4' media, but that media type is not supported by the Printer
object. Or, if the client supplies an optional attribute and the
attribute itself is not even supported by the Printer. If the "ipp-
attribute-fidelity" attribute is 'false', the Printer MUST ignore or
substitute values for unsupported attributes and values rather than
reject the request and return this status code.
For any operation where a client requests attributes (such as a Get-
Jobs, Get-Printer-Attributes, or Get-Job-Attributes operation), if
the IPP object does not support one or more of the requested
attributes, the IPP object simply ignores the unsupported requested
attributes and processes the request as if they had not been
supplied, rather than returning this status code. In this case, the
IPP object MUST return the 'successful-ok-ignored-or-substituted-
attributes' status code and MAY return the unsupported attributes as
values of the "requested-attributes" in the Unsupported Attributes
Group (see section 13.1.2.2).
13.1.4.13 client-error-uri-scheme-not-supported (0x040C)
The type of the client supplied URI in a Print-URI or a Send-URI
operation is not supported.
13.1.4.14 client-error-charset-not-supported (0x040D)
For any operation, if the IPP Printer does not support the charset
supplied by the client in the "attributes-charset" operation
attribute, the Printer MUST reject the operation and return this
status and any 'text' or 'name' attributes using the 'utf-8' charset
(see Section 3.1.4.1).
13.1.4.15 client-error-conflicting-attributes (0x040E)
The request is rejected because some attribute values conflicted with
the values of other attributes which this specification does not
permit to be substituted or ignored.
13.1.5 Server Error Status Codes
This class of status codes indicates cases in which the IPP object is
aware that it has erred or is incapable of performing the request.
The IPP object SHOULD include a message containing an explanation of
the error situation, and whether it is a temporary or permanent
condition.
13.1.5.1 server-error-internal-error (0x0500)
The IPP object encountered an unexpected condition that prevented it
from fulfilling the request. This error status code differs from
"server-error-temporary-error" in that it implies a more permanent
type of internal error. It also differs from "server-error-device-
error" in that it implies an unexpected condition (unlike a paper-jam
or out-of-toner problem which is undesirable but expected). This
error status code indicates that probably some knowledgeable human
intervention is required.
13.1.5.2 server-error-operation-not-supported (0x0501)
The IPP object does not support the functionality required to fulfill
the request. This is the appropriate response when the IPP object
does not recognize an operation or is not capable of supporting it.
13.1.5.3 server-error-service-unavailable (0x0502)
The IPP object is currently unable to handle the request due to a
temporary overloading or maintenance of the IPP object. The
implication is that this is a temporary condition which will be
alleviated after some delay. If known, the length of the delay may be
indicated in the message. If no delay is given, the IPP application
should handle the response as it would for a "server-error-
temporary-error" response. If the condition is more permanent, the
error status codes "client-error-gone" or "client-error-not-found"
could be used.
13.1.5.4 server-error-version-not-supported (0x0503)
The IPP object does not support, or refuses to support, the IPP
protocol version that was used in the request message. The IPP
object is indicating that it is unable or unwilling to complete the
request using the same version as supplied in the request other than
with this error message. The response should contain a Message
describing why that version is not supported and what other versions
are supported by that IPP object.
A conforming IPP/1.0 client MUST specify the valid version ('1.0') on
each request. A conforming IPP/1.0 object MUST NOT return this
status code to a conforming IPP/1.0 client. An IPP object MUST
return this status code to a non-conforming IPP client. The response
MUST identify in the "version-number" operation attribute the closest
version number that the IPP object does support.
13.1.5.5 server-error-device-error (0x0504)
A printer error, such as a paper jam, occurs while the IPP object
processes a Print or Send operation. The response contains the true
Job Status (the values of the "job-state" and "job-state-reasons"
attributes). Additional information can be returned in the optional
"job-state-message" attribute value or in the OPTIONAL status message
that describes the error in more detail. This error status code is
only returned in situations where the Printer is unable to accept the
create request because of such a device error. For example, if the
Printer is unable to spool, and can only accept one job at a time,
the reason it might reject a create request is that the printer
currently has a paper jam. In many cases however, where the Printer
object can accept the request even though the Printer has some error
condition, the 'successful-ok' status code will be returned. In such
a case, the client would look at the returned Job Object Attributes
or later query the Printer to determine its state and state reasons.
13.1.5.6 server-error-temporary-error (0x0505)
A temporary error such as a buffer full write error, a memory
overflow (i.e. the document data exceeds the memory of the Printer),
or a disk full condition, occurs while the IPP Printer processes an
operation. The client MAY try the unmodified request again at some
later point in time with an expectation that the temporary internal
error condition may have been cleared. Alternatively, as an
implementation option, a Printer object MAY delay the response until
the temporary condition is cleared so that no error is returned.
13.1.5.7 server-error-not-accepting-jobs (0x0506)
A temporary error indicating that the Printer is not currently
accepting jobs, because the administrator has set the value of the
Printer's "printer-is-not-accepting-jobs" attribute to 'false' (by
means outside of IPP/1.0).
13.1.5.8 server-error-busy (0x0507)
A temporary error indicating that the Printer is too busy processing
jobs and/or other requests. The client SHOULD try the unmodified
request again at some later point in time with an expectation that
the temporary busy condition will have been cleared.
13.1.5.9 server-error-job-canceled (0x0508)
An error indicating that the job has been canceled by an operator or
the system while the client was transmitting the data to the IPP
Printer. If a job-id and job-uri had been created, then they are
returned in the Print-Job, Send-Document, or Send-URI response as
usual; otherwise, no job-id and job-uri are returned in the response.
13.2 Status Codes for IPP Operations
PJ = Print-Job, PU = Print-URI, CJ = Create-Job, SD = Send-Document
SU = Send-URI, V = Validate-Job, GA = Get-Job-Attributes and
Get-Printer-Attributes, GJ = Get-Jobs, C = Cancel-Job
IPP Operations
IPP Status Keyword PJ PU CJ SD SU V GA GJ C
------------------ -- -- -- -- -- - -- -- -
successful-ok x x x x x x x x x
successful-ok-ignored-or-substituted- x x x x x x x x x
attributes
successful-ok-conflicting-attributes x x x x x x x x x
client-error-bad-request x x x x x x x x x
client-error-forbidden x x x x x x x x x
client-error-not-authenticated x x x x x x x x x
client-error-not-authorized x x x x x x x x x
client-error-not-possible x x x x x x x x x
client-error-timeout x x
client-error-not-found x x x x x x x x x
client-error-gone x x x x x x x x x
client-error-request-entity-too-large x x x x x x x x x
client-error-request-value-too-long x x x x x x x x x
client-error-document-format-not- x x x x x x
supported
client-error-attributes-or-values-not- x x x x x x x x x
supported
client-error-uri-scheme-not-supported x x
client-error-charset-not-supported x x x x x x x x x
client-error-conflicting-attributes x x x x x x x x x
server-error-internal-error x x x x x x x x x
server-error-operation-not-supported x x x x
server-error-service-unavailable x x x x x x x x x
server-error-version-not-supported x x x x x x x x x
server-error-device-error x x x x x
server-error-temporary-error x x x x x
server-error-not-accepting-jobs x x x x
server-error-busy x x x x x x x x x
server-error-job-canceled x x