RFC 2566
Internet Printing Protocol/1.0: Model and Semantics
8. Security Considerations Some IPP objects MAY be deployed over protocol stacks that support Secure Socket Layer Version 3 (SSL3) [SSL]. Note: SSL3 is not an IETF standards track specification. Other IPP objects MAY be deployed over protocol stacks that do not support SSL3. Some IPP objects MAY be deployed over both types of protocol stacks. Those IPP objects that support SSL3, are capable of supporting mutual authentication as well as privacy of messages via multiple encryption schemes. An important point about security related information for SSL3 access to an IPP object, is that the security-related parameters (authentication, encryption keys, etc.) are "out-of-band" to the actual IPP protocol. An IPP object that does not support SSL3 MAY elect to support a transport layer that provides other security mechanisms. For example, in a mapping of IPP over HTTP/1.1 [RFC2565], if the IPP object does not support SSL3, HTTP still allows for client authentication using Digest Access Authentication (DAA) [RFC2069]. It is difficult to anticipate the security risks that might exist in any given IPP environment. For example, if IPP is used within a given corporation over a private network, the risks of exposing document data may be low enough that the corporation will choose not to use encryption on that data. However, if the connection between the client and the IPP object is over a public network, the client may wish to protect the content of the information during transmission through the network with encryption. Furthermore, the value of the information being printed may vary from one IPP environment to the next. Printing payroll checks, for example, would have a different value than printing public information from a file. There is also the possibly of denial-of- service attacks, but denial-of-service attacks against printing resources are not well understood and there is no published precedents regarding this scenario. Once the authenticated identity of the requester has been supplied to the IPP object, the object uses that identity to enforce any authorization policy that might be in place. For example, one site's policy might be that only the job owner is allowed to cancel a job. The details and mechanisms to set up a particular access control policy are not part of IPP/1.0, and must be established via some other type of administrative or access control framework. However, there are operation status codes that allow an IPP server to return information back to a client about any potential access control violations for an IPP object.
During a create operation, the client's identity is recorded in the Job object in an implementation-defined attribute. This information can be used to verify a client's identity for subsequent operations on that Job object in order to enforce any access control policy that might be in effect. See section 8.3 below for more details. Since the security levels or the specific threats that any given IPP system administrator may be concerned with cannot be anticipated, IPP MUST be capable of operating with different security mechanisms and security policies as required by the individual installation. Security policies might vary from very strong, to very weak, to none at all, and corresponding security mechanisms will be required. SSL3 supports the type of negotiated levels of security required by most, if not all, potential IPP environments. IPP environments that require no security can elect to deploy IPP objects that do not utilize the optional SSL3 security mechanisms. 8.1 Security Scenarios The following sections describe specific security attacks for IPP environments. Where examples are provided they should be considered illustrative of the environment and not an exhaustive set. Not all of these environments will necessarily be addressed in initial implementations of IPP. 8.1.1 Client and Server in the Same Security Domain This environment is typical of internal networks where traditional office workers print the output of personal productivity applications on shared work-group printers, or where batch applications print their output on large production printers. Although the identity of the user may be trusted in this environment, a user might want to protect the content of a document against such attacks as eavesdropping, replaying or tampering. 8.1.2 Client and Server in Different Security Domains Examples of this environment include printing a document created by the client on a publicly available printer, such as at a commercial print shop; or printing a document remotely on a business associate's printer. This latter operation is functionally equivalent to sending the document to the business associate as a facsimile. Printing sensitive information on a Printer in a different security domain requires strong security measures. In this environment authentication of the printer is required as well as protection against unauthorized use of print resources. Since the document crosses security domains,
protection against eavesdropping and document tampering are also required. It will also be important in this environment to protect Printers against "spamming" and malicious document content. 8.1.3 Print by Reference When the document is not stored on the client, printing can be done by reference. That is, the print request can contain a reference, or pointer, to the document instead of the actual document itself. Standard methods currently do not exist for remote entities to "assume" the credentials of a client for forwarding requests to a 3rd party. It is anticipated that Print-By-Reference will be used to access "public" documents and that sophisticated methods for authenticating "proxies" will not be specified for version 1 of IPP. 8.2 URIs for SSL3 and non-SSL3 Access As described earlier, an IPP object can support SSL3 access, non-SSL3 access, or both. The "printer-uri-supported" attribute contains the Printer object's URI(s). Its companion attribute, "uri-security- supported", identifies the security mechanism used for each URI listed in the "printer-uri-supported" attribute. For each Printer 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, RFC 1035, November 1987.
[RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J. Gyllenskog, "Printer MIB", RFC 1759, March 1995. [RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC1179] McLaughlin, L. (Editor), "Line Printer Daemon Protocol", RFC 1179, August 1990. [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996. [RFC2045] Freed, N. and N. Borenstein, " Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extension (MIME) Part Four: Registration Procedures", RFC 2048, November 1996. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. AND T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2068, 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", RFC 2069, January 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 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" RFC 2277, January 1998. [RFC2278] Freed, N. and J. Postel: "IANA Charset Registration Procedures", BCP 19, RFC 2278, January 1998. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC2316] Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998. [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999. [RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999. [RFC2568] Zilles, S., "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", RFC 2568, April 1999. [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569, April 1999. [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, 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 RFC 2119 [RFC2119]. 12.1.1 NEED NOT This term is not included in RFC 2119. 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
(next page on part 7)
