operation request, a client MUST supply only one URI in the
"printer-uri" operation attribute. In other words, even though the
Printer supports more than one URI, the client only interacts with
the Printer object using one if its URIs. This duality is not needed
for Job objects, since the Printer objects is the factory for Job
objects, and the Printer object will generate the correct URI for new
Job objects depending on the Printer object's security configuration.
8.3 The "requesting-user-name" (name(MAX)) Operation Attribute
Each operation MUST specify the user who is performing the operation
in both of the following two ways:
1) via the REQUIRED "requesting-user-name" operation attribute that
a client SHOULD supply in all operations. The client MUST obtain
the value for this attribute from an environmental or network
login name for the user, rather than allowing the user to supply
any value. If the client does not supply a value for
"requesting-user-name", the printer MUST assume that the client
is supplying some anonymous name, such as "anonymous".
2) via an authentication mechanism of the underlying transport
which may be configured to give no authentication information.
There are six cases to consider:
a) the authentication mechanism gives no information, and the
client doesn't specify "requesting-user-name".
b) the authentication mechanism gives no information, but the
client specifies "requesting-user-name".
c) the authentication mechanism specifies a user which has no human
readable representation, and the client doesn't specify
"requesting-user-name".
d) the authentication mechanism specifies a user which has no human
readable representation, but the client specifies "requesting-
user-name".
e) the authentication mechanism specifies a user which has a human
readable representation. The Printer object ignores the
"requesting-user-name".
f) the authentication mechanism specifies a user who is trusted and
whose name means that the value of the "requesting-user-name",
which MUST be present, is treated as the authenticated name.
Note: Case "f" is intended for a tightly coupled gateway and server
to work together so that the "user" name is able to be that of the
gateway client and not that of the gateway. Because most, if not
all, system vendors will initially implement IPP via a gateway into
their existing print system, this mechanism is necessary unless the
authentication mechanism allows a gateway (client) to act on behalf
of some other client.
The user-name has two forms:
- one that is human readable: it is held in the REQUIRED "job-
originating-user-name" Job Description attribute which is set
during the job creation operations. It is used for presentation
only, such as returning in queries or printing on start sheets
- one for authorization: it is held in an undefined (by IPP) Job
object attribute which is set by the job creation operation. It
is used to authorize other operations, such as Send-Document,
Send-URI, Cancel-Job, to determine the user when the "my-jobs"
attribute is specified with Get-Jobs, and to limit what
attributes and values to return with Get-Job-Attributes and Get-
Jobs.
The human readable user name:
- is the value of the "requesting-user-name" for cases b, d and f.
- comes from the authentication mechanism for case e
- is some anonymous name, such as "anonymous" for cases a and c.
The user name used for authorization:
- is the value of the "requesting-user-name" for cases b and f.
- comes from the authentication mechanism for cases c, d and e
- is some anonymous name, such as "anonymous" for case a.
The essence of these rules for resolving conflicting sources of
user-names is that a printer implementation is free to pick either
source as long as it achieves consistent results. That is, if a user
uses the same path for a series of requests, the requests MUST appear
to come from the same user from the standpoint of both the human-
readable user name and the user name for authorization. This rule
MUST continue to apply even if a request could be authenticated by
two or more mechanisms. It doesn't matter which of several
authentication mechanisms a Printer uses as long as it achieves
consistent results. If a client uses more than one authentication
mechanism, it is recommended that an administrator make all
credentials resolve to the same user and user-name as much as
possible.
8.4 Restricted Queries
In many IPP operations, a client supplies a list of attributes to be
returned in the response. For security reasons, an IPP object may be
configured not to return all attributes (or all values) that a client
requests. The job attributes returned MAY depend on whether the
requesting user is the same as the user that submitted the job. The
IPP object MAY even return none of the requested attributes. In such
cases, the status returned is the same as if the object had returned
all requested attributes. The client cannot tell by such a response
whether the requested attribute was present or absent on the object.
8.5 Queries on jobs submitted using non-IPP protocols
If the device that an IPP Printer is representing is able to accept
jobs using other job submission protocols in addition to IPP, it is
RECOMMENDED that such an implementation at least allow such "foreign"
jobs to be queried using Get-Jobs returning "job-id" and "job-uri" as
'unknown'. Such an implementation NEED NOT support all of the same
IPP job attributes as for IPP jobs. The IPP object returns the '
unknown' out-of-band value for any requested attribute of a foreign
job that is supported for IPP jobs, but not for foreign jobs.
It is further RECOMMENDED, that the IPP Printer generate "job-id" and
"job-uri" values for such "foreign jobs", if possible, so that they
may be targets of other IPP operations, such as Get-Job-Attributes
and Cancel-Job. Such an implementation also needs to deal with the
problem of authentication of such foreign jobs. One approach would
be to treat all such foreign jobs as belonging to users other than
the user of the IPP client. Another approach would be for the
foreign job to belong to 'anonymous'. Only if the IPP client has
been authenticated as an operator or administrator of the IPP Printer
object, could the foreign jobs be queried by an IPP request.
Alternatively, if the security policy is to allow users to query
other users' jobs, then the foreign jobs would also be visible to an
end-user IPP client using Get-Jobs and Get-Job-Attributes.
8.6 IPP Security Application Profile for SSL3
The IPP application profile for SSL3 follows the "Secure Socket
Layer" requirement as documented in the SSL3 specification [SSL].
For interoperability, the SSL3 cipher suites are:
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
SSL_RSA_WITH_NULL_MD5
Client implementations MUST NOT assume any other cipher suites are
supported by an IPP Printer object.
If a conforming IPP object supports SSL3, it MUST implement and
support the cipher suites listed above and MAY support additional
cipher suites.
A conforming IPP client SHOULD support SSL3 including the cipher
suites listed above. A conforming IPP client MAY support additional
cipher suites.
It is possible that due to certain government export restrictions
some non-compliant versions of this extension could be deployed.
Implementations wishing to inter-operate with such non-compliant
versions MAY offer the SSL_RSA_EXPORT_WITH_RC4_40_MD5 and
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 mechanisms. However, since 40 bit
ciphers are known to be vulnerable to attack by current technology,
any client which actives a 40 bit cipher MUST NOT indicate to the
user that the connection is completely secure from eavesdropping.
9. References
[ASCII] Coded Character Set - 7-bit American Standard Code for
Information Interchange (ASCII), ANSI X3.4-1986. This
standard is the specification of the US-ASCII charset.
[HTPP] J. Barnett, K. Carter, R. DeBry, "Initial Draft -
Hypertext Printing Protocol - HTPP/1.0", October 1996.
ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/
overview.ps.gz
[IANA-CS] IANA Registry of Coded Character Sets:
ftp://ftp.isi.edu/in-notes/iana/assignments/character-
sets
[IANA-MT] IANA Registry of Media Types: ftp://ftp.isi.edu/in-
notes/iana/assignments/media-types/
[ipp-iig] Hastings, T. and C. Manros, "Internet Printing
Protocol/1.0: Implementer's Guide", Work in Progress.
[ISO10646-1] ISO/IEC 10646-1:1993, "Information technology --
Universal Multiple-Octet Coded Character Set (UCS) -
Part 1: Architecture and Basic Multilingual Plane,
JTC1/SC2."
[ISO8859-1] ISO/IEC 8859-1:1987, "Information technology -- 8-bit
One-Byte Coded Character Set - Part 1: Latin Alphabet Nr
1", 1987, JTC1/SC2.
[ISO10175] ISO/IEC 10175 Document Printing Application (DPA), June
1996.
[LDPA] T. Hastings, S. Isaacson, M. MacKay, C. Manros, D. Taylor, P.
Zehler, "LDPA - Lightweight Document Printing
Application", October 1996,
ftp://ftp.pwg.org/pub/pwg/ipp/historic/ldpa/ldpa8.pdf.gz
[P1387.4] Kirk, M. (Editor), POSIX System Administration - Part 4:
Printing Interfaces, POSIX 1387.4 D8, 1994.
[PSIS] Herriot, R. (editor), X/Open A Printing System
Interoperability Specification (PSIS), August 1995.
[PWG] Printer Working Group, http://www.pwg.org.
[RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION", STD 13, RFC1035, November 1987.
[RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
Gyllenskog, "Printer MIB", RFC1759, March 1995.
[RFC1766] Alvestrand, H., "Tags for the Identification of
Languages", RFC1766, March 1995.
[RFC1179] McLaughlin, L. (Editor), "Line Printer Daemon Protocol",
RFC1179, August 1990.
[RFC1952] Deutsch, P., "GZIP file format specification version
4.3", RFC1952, May 1996.
[RFC2045] Freed, N. and N. Borenstein, " Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC2046,
November 1996.
[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extension (MIME) Part Four: Registration
Procedures", RFC2048, November 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. AND T.
Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
RFC2068, January 1997.
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
Luotonen, A., Sink, E. and L. Stewart, "An Extension to
HTTP: Digest Access Authentication", RFC2069, January
1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC2228] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC
2228, October 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages" RFC2277, January 1998.
[RFC2278] Freed, N. and J. Postel: "IANA Charset Registration
Procedures", BCP 19, RFC2278, January 1998.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC2279, January 1998.
[RFC2316] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC2316, April 1998.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC2396,
August 1998.
[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