Internet Printing Protocol/1.1: Model and Semantics
draft-sweet-rfc2911bis-11
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8011.
|
|
|---|---|---|---|
| Authors | Michael Sweet , Ira McDonald | ||
| Last updated | 2021-06-23 (Latest revision 2016-08-25) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-09)
by Russ Housley
Almost ready
|
||
| Stream | WG state | (None) | |
| Document shepherd | Barry Leiba | ||
| Shepherd write-up | Show Last changed 2016-06-21 | ||
| IESG | IESG state | Became RFC 8011 (Internet Standard) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Alexey Melnikov | ||
| Send notices to | "Barry Leiba" <barryleiba@computer.org> | ||
| IANA | IANA review state | IANA OK - Actions Needed | |
| IANA action state | RFC-Ed-Ack |
draft-sweet-rfc2911bis-11
lt;http://ftp.pwg.org/pub/pwg/candidates/
cs-ippprodprint10-20010212-5100.3.pdf>.
Sweet & McDonald Expires February 26, 2017 [Page 179]
Internet-Draft IPP/1.1: Model and Semantics August 2016
[PWG5100.5]
Carney, D., Hastings, T., and P. Zehler, "IPP: Document
Object", October 2003,
<http://ftp.pwg.org/pub/pwg/candidates/
cs-ippdocobject10-20031031-5100.5.pdf>.
[PWG5100.6]
Zehler, P., Herriot, R., and K. Ocke, "IPP: Page
Overrides", October 2003,
<http://ftp.pwg.org/pub/pwg/candidates/
cs-ipppageoverride10-20031031-5100.6.pdf>.
[PWG5100.7]
Hastings, T. and P. Zehler, "IPP: Job Extensions", October
2003, <http://ftp.pwg.org/pub/pwg/candidates/
cs-ippjobext10-20031031-5100.7.pdf>.
[PWG5100.8]
Carney, D. and H. Lewis, "IPP: "-actual" attributes",
March 2003, <http://ftp.pwg.org/pub/pwg/candidates/
cs-ippactuals10-20030313-5100.8.pdf>.
[PWG5100.9]
McDonald, I. and C. Whittle, "IPP: Printer State
Extensions v1.0", July 2009,
<http://ftp.pwg.org/pub/pwg/candidates/
cs-ippstate10-20090731-5100.9.pdf>.
[PWG5101.1]
Sweet, M., Bergman, R., and T. Hastings, "PWG Media
Standardized Names 2.0 (MSN2)", March 2013,
<http://ftp.pwg.org/pub/pwg/candidates/
cs-pwgmsn20-20130328-5101.1.pdf>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996.
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.
Randers-Pehrson, "GZIP file format specification version
4.3", RFC 1952, May 1996.
[RFC1977] Schryver, V., "PPP BSD Compression Protocol", RFC 1977,
August 1996.
Sweet & McDonald Expires February 26, 2017 [Page 180]
Internet-Draft IPP/1.1: Model and Semantics August 2016
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<http://www.rfc-editor.org/info/rfc20>.
[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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2910bis]
Sweet, M. and I. McDonald, "Internet Printing
Protocol/1.1: Encoding and Transport", July 2016,
<http://tools.ietf.org/html/draft-sweet-rfc2910bis>.
[RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H.
Holst, "Internet Printing Protocol/1.1: Implementor's
Guide", RFC 3196, November 2001.
[RFC3380] Hastings, T., Herriot, R., Kugler, C., and H. Lewis,
"Internet Printing Protocol (IPP): Job and Printer Set
Operations", RFC 3380, September 2002.
[RFC3510] Herriot, R. and I. McDonald, "Internet Printing
Protocol/1.1: IPP URL Scheme", RFC 3510, April 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3805] Bergman, R., Lewis, H., and I. McDonald, "Printer MIB v2",
RFC 3805, June 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC3995] Herriot, R. and T. Hastings, "Internet Printing Protocol
(IPP): Event Notifications and Subscriptions", RFC 3995,
March 2005.
Sweet & McDonald Expires February 26, 2017 [Page 181]
Internet-Draft IPP/1.1: Model and Semantics August 2016
[RFC3996] Herriot, R., Hastings, T., and H. Lewis, "Internet
Printing Protocol (IPP): The 'ippget' Delivery Method for
Event Notifications", RFC 3996, March 2005.
[RFC3998] Kugler, C., Lewis, H., and T. Hastings, "Internet Printing
Protocol (IPP): Job and Printer Administrative
Operations", RFC 3998, March 2005.
[RFC5051] Crispin, M., "i;unicode-casemap - Simple Unicode Collation
Algorithm", RFC 5051, DOI 10.17487/RFC5051, October 2007,
<http://www.rfc-editor.org/info/rfc5051>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC
6838, January 2013.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014.
[RFC7472] McDonald, I. and M. Sweet, "Internet Printing Protocol
(IPP) over HTTPS Transport Binding and the 'ipps' URI
Scheme", RFC 7472, March 2015.
[RFC7612] Flemming, P. and I. McDonald, "Lightweight Directory
Access Protocol (LDAP): Schema for Printer Services", RFC
7612, June 2015.
[RFC7616] Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest
Access Authentication", September 2015,
<http://tools.ietf.org/html/rfc7616>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
September 2015, <http://tools.ietf.org/html/rfc7617>.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
Sweet & McDonald Expires February 26, 2017 [Page 182]
Internet-Draft IPP/1.1: Model and Semantics August 2016
11.2. Informative References
[HTPP] Barnett, J., Carter, K., and R. DeBry, "Initial Draft -
Hypertext Printing Protocol - HTPP/1.0", 10 1996,
<ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/
overview.ps.gz>.
[IANA-CS] "IANA Registry of Coded Character Sets",
<http://www.iana.org/assignments/character-sets/
character-sets.xhtml>.
[IANA-MT] "IANA Registry of Media Types",
<http://www.iana.org/assignments/media-types/
media-types.xhtml>.
[IANA-PEN]
"IANA Registry of Private Enterprise Numbers",
<http://www.iana.org/assignments/enterprise-numbers/
enterprise-numbers>.
[ISO32000]
"Document management -- Portable document format -- Part
1: PDF 1.7", 7 2008,
<http://www.adobe.com/devnet/acrobat/pdfs/
PDF32000_2008.pdf>.
[LDPA] Hastings, T., Isaacson, S., MacKay, M., Manros, C.,
Taylor, D., and 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., "POSIX System Administration - Part 4: Printing
Interfaces, POSIX 1387.4 D8", 1998.
[PSIS] Herriot, R., "X/Open: A Printing System Interoperability
Specification (PSIS)", August 1995.
[PWG-IPP-WG]
"IEEE-ISTO Printer Working Group: Internet Printing
Protocol Workgroup", <http://www.pwg.org/ipp>.
[RFC1179] McLaughlin, L., "Line printer daemon protocol", RFC 1179,
August 1990.
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738,
December 1994, <http://www.rfc-editor.org/info/rfc1738>.
Sweet & McDonald Expires February 26, 2017 [Page 183]
Internet-Draft IPP/1.1: Model and Semantics August 2016
[RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228, October
1997.
[RFC2316] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC 2316, April 1998.
[RFC2565] Herriot, R., Butler, S., Moore, P., and R. Turner,
"Internet Printing Protocol/1.0: Encoding and Transport",
RFC 2565, April 1999.
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and P.
Powell, "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2566, April 1999.
[RFC2567] Wright, F., "Design Goals for an Internet Printing
Protocol", RFC 2567, April 1999.
[RFC2568] Zilles, S., "Rationale for the Structure of the Model and
Protocol for the Internet Printing Protocol", RFC 2568,
April 1999.
[RFC2569] Herriot, R., Jacobs, N., Hastings, T., and J. Martin,
"Mapping between LPD and IPP Protocols", RFC 2569, April
1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD
58, RFC 2579, April 1999.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
[RFC3239] Kugler, C., Lewis, H., and T. Hastings, "Internet Printing
Protocol (IPP): Requirements for Job, Printer, and Device
Administrative Operations", RFC 3239, February 2002.
[RFC3997] Hastings, T., deBry, R., and H. Lewis, "Internet Printing
Protocol (IPP): Requirements for IPP Notifications", RFC
3997, March 2005.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI
10.17487/RFC4122, July 2005,
<http://www.rfc-editor.org/info/rfc4122>.
Sweet & McDonald Expires February 26, 2017 [Page 184]
Internet-Draft IPP/1.1: Model and Semantics August 2016
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
<http://www.rfc-editor.org/info/rfc6068>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
[SWP] Moore, P., Jahromi, B., and S. Butler, "Simple Web
Printing SWP/1.0", May 1997,
<ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/swp9705.pdf>.
Appendix A. 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 7 for:
1. attributes
2. type2 'keyword' attribute values
3. type2 'enum' attribute values
4. operations
5. status codes
A.1. Attribute Registration
Type of registration: attribute
Proposed keyword name of this attribute:
Types of attribute (Document Description, Document Status, Document
Template, Event Notifications, Job Description, Job Status, Job
Template, Operation, Printer Description, Printer Status,
Sweet & McDonald Expires February 26, 2017 [Page 185]
Internet-Draft IPP/1.1: Model and Semantics August 2016
Subscription Description, Subscription Status, Subscription
Template):
Operations to be used with if the attribute is an operation
attribute:
Object (Document, Job, Printer, Subscription, etc. if bound to an
object):
Attribute syntax(es) (include 1setOf and range as in Section 5.2):
If attribute syntax is 'keyword' or 'enum', is it type1 or type2:
If this is a Printer attribute, MAY the value returned depend on
"document-format" (See Section 7.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 Section 5.2):
Name of proposer:
Email address of proposer:
Note: For attributes, the IPP Designated Expert will be the point of
contact and change controller for the approved registration
specification, if any maintenance of the registration specification
is needed.
A.2. Type2 Keyword Attribute Value 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
Section 5.1.3.3):
Name of proposer:
Email address of proposer:
Note: For type2 keywords, the Designated Expert will be the point of
contact and change controller for the approved registration
Sweet & McDonald Expires February 26, 2017 [Page 186]
Internet-Draft IPP/1.1: Model and Semantics August 2016
specification, if any maintenance of the registration specification
is needed.
A.3. Type2 Enum Attribute Value 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 Section 5.1.5):
Name of proposer:
Email address of proposer:
Note: For type2 enums, the Designated Expert will be the point of
contact and change controller for the approved registration
specification, if any maintenance of the registration specification
is needed.
A.4. Operation Registration
Type of registration: operation
Proposed name of this operation:
Numeric operation-id value according to Section 5.4.15 (to be
assigned by the IPP Designated Expert in consultation with IANA):
Object Target (Document, Job, Printer, Subscription, etc. that
operation is upon):
Specification of this operation (follow the style of Section 4):
Name of proposer:
Email address of proposer:
Note: For operations, the IPP Designated Expert will be the point of
contact and change controller for the approved registration
specification, if any maintenance of the registration specification
is needed.
Sweet & McDonald Expires February 26, 2017 [Page 187]
Internet-Draft IPP/1.1: Model and Semantics August 2016
A.5. 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 can be used with:
Specification of this status code (follow the style of Appendix B):
Name of proposer:
Email address of proposer:
Note: For status codes, the Designated Expert will be the point of
contact and change controller for the approved registration
specification, if any maintenance of the registration specification
is needed.
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.
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 is 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
Sweet & McDonald Expires February 26, 2017 [Page 188]
Internet-Draft IPP/1.1: Model and Semantics August 2016
As with type2 enums, IPP status codes are extensible. Regardless of
whether all status codes are recognized, 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. The name of the enum is the suggested status message for US
English.
See [PWG5100.19] for guidelines on presenting status messages to End
Users.
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" - 0x0300 to 0x03FF
"client-error" - 0x0400 to 0x04FF
"server-error" - 0x0500 to 0x05FF
The top half (128 values) of each range (0x0n80 to 0x0nFF, for n = 0
to 5) is reserved for vendor use within each status code class.
Values 0x0600 to 0x7FFF are reserved for future assignment by
standards track documents and MUST NOT be used.
B.1. Status Codes
Each status code is described below. Appendix B.1.5.9 contains a
table that indicates which status codes apply to which operations.
The Implementor's Guides [RFC3196] [PWG5100.19] provide guidance for
processing IPP attributes for all operations, including returning
status codes.
B.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 this document for this class of
status code.
Sweet & McDonald Expires February 26, 2017 [Page 189]
Internet-Draft IPP/1.1: Model and Semantics August 2016
B.1.2. Successful Status Codes
This class of status code indicates that the client's request was
successfully received, understood, and accepted.
B.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 Job Creation 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.
B.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 SHOULD
return the "requested-attributes" attribute in the Unsupported
Attribute response group (with the unsupported values only). See
Sections 4.1.7 and 4.2.1.2.
B.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 Sections 4.1.7 and 4.2.1.2.
B.1.3. Redirection Status Codes
This class of status code indicates that further action needs to be
taken to fulfill the request.
Sweet & McDonald Expires February 26, 2017 [Page 190]
Internet-Draft IPP/1.1: Model and Semantics August 2016
There are no status codes defined in this document for this class of
status code.
B.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.
B.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 Implementor's Guides [RFC3196] [PWG5100.19]). The IPP
application SHOULD NOT repeat the request without modifications.
B.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.
B.1.4.3. client-error-not-authenticated (0x0402)
The request requires user authentication. The IPP Client can 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 can contain relevant diagnostic
information. This status codes reveals more information than
"client-error-forbidden".
B.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
Sweet & McDonald Expires February 26, 2017 [Page 191]
Internet-Draft IPP/1.1: Model and Semantics August 2016
more information than "client-error-forbidden" and "client-error-not-
authenticated".
B.1.4.5. client-error-not-possible (0x0404)
This status code is used when the request is for something that
cannot 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.
B.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 4.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.
B.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 cannot 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 cannot 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.
B.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.
Sweet & McDonald Expires February 26, 2017 [Page 192]
Internet-Draft IPP/1.1: Model and Semantics August 2016
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 Adminstrator 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 Adminstrator and/or Printer implementation.
B.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.
B.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 can pass the value onto some other system component
which is not able to accept the large value. For more details, see
the Implementor's Guides [RFC3196] [PWG5100.19].
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.
B.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. This
error is returned independent of the Client-supplied "ipp-attribute-
fidelity". The Printer MUST return this status code, even if there
Sweet & McDonald Expires February 26, 2017 [Page 193]
Internet-Draft IPP/1.1: Model and Semantics August 2016
are other Job Template attributes that are not supported as well,
since this error is a bigger problem than with Job Template
attributes. See Sections 4.1.6.1, 4.1.7, and 4.2.1.1.
B.1.4.12. client-error-attributes-or-values-not-supported (0x040B)
In a Job Creation request, if the Printer does not support one or
more attributes, attribute syntaxes, or attribute values supplied in
the request and the Client supplied the "ipp-attribute-fidelity"
operation attribute with the 'true' value, the Printer MUST return
this status code. The Printer MUST also return in the Unsupported
Attributes group all the attributes and/or values supplied by the
Client that are not supported. See Section 4.1.7. For example, if
the request indicates 'iso-a4' media, but that media type is not
supported by the Printer. Or, if the Client supplies a Job Template
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 Job Template
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 SHOULD return the unsupported attributes
as values of the "requested-attributes" in the Unsupported Attributes
group (see Appendix B.1.2.2).
B.1.4.13. client-error-uri-scheme-not-supported (0x040C)
The scheme of the Client-supplied URI in a Print-URI or a Send-URI
operation is not supported. See Sections 4.1.6.1 and 4.1.7.
B.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 4.1.4.1). See Sections 4.1.6.1 and 4.1.7.
Sweet & McDonald Expires February 26, 2017 [Page 194]
Internet-Draft IPP/1.1: Model and Semantics August 2016
B.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 document does not permit to
be substituted or ignored. The Printer MUST also return in the
Unsupported Attributes group the conflicting attributes supplied by
the Client. See Sections 4.1.7 and 4.2.1.2.
B.1.4.16. client-error-compression-not-supported (0x040F)
The IPP object is refusing to service the request because the
Document data, as specified in the "compression" operation attribute,
is compressed in a way that is not supported by the Printer. This
error is returned independent of the Client-supplied "ipp-attribute-
fidelity". The Printer MUST return this status code, even if there
are other Job Template attributes that are not supported as well,
since this error is a bigger problem than with Job Template
attributes. See Sections 4.1.6.1, 4.1.7, and 4.2.1.1.
B.1.4.17. client-error-compression-error (0x0410)
The IPP object is refusing to service the request because the
Document data cannot be decompressed when using the algorithm
specified by the "compression" operation attribute. This error is
returned independent of the Client-supplied "ipp-attribute-fidelity".
The Printer MUST return this status code, even if there are Job
Template attributes that are not supported as well, since this error
is a bigger problem than with Job Template attributes. See Sections
4.1.7 and 4.2.1.1.
B.1.4.18. client-error-document-format-error (0x0411)
The IPP object is refusing to service the request because Printer
encountered an error in the Document data while interpreting it.
This error is returned independent of the Client-supplied "ipp-
attribute-fidelity". The Printer MUST return this status code, even
if there are Job Template attributes that are not supported as well,
since this error is a bigger problem than with Job Template
attributes. See Sections 4.1.7 and 4.2.1.1.
B.1.4.19. client-error-document-access-error (0x0412)
The IPP object is refusing to service the Print-URI or Send-URI
request because Printer encountered an access error while attempting
to validate the accessibility or access the Document data specified
in the "document-uri" operation attribute. The Printer MAY also
return a specific document access error code using the "document-
access-error" operation attribute (see Section 4.1.6.4). This error
Sweet & McDonald Expires February 26, 2017 [Page 195]
Internet-Draft IPP/1.1: Model and Semantics August 2016
is returned independent of the Client-supplied "ipp-attribute-
fidelity". The Printer MUST return this status code, even if there
are Job Template attributes that are not supported as well, since
this error is a bigger problem than with Job Template attributes.
See Sections 4.1.6.1 and 4.1.7.
B.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.
B.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.
B.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.
See Sections 4.1.6.1 and 4.1.7.
B.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 can
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.
Sweet & McDonald Expires February 26, 2017 [Page 196]
Internet-Draft IPP/1.1: Model and Semantics August 2016
B.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 supplied as the value of the "version-
number" operation parameter in the request. The IPP object is
indicating that it is unable or unwilling to complete the request
using the same major and minor version number as supplied in the
request other than with this error message. The error response
SHOULD contain a "status-message" attribute (see Section 4.1.6.2)
describing why that version is not supported and what other versions
are supported by that IPP object. See Sections 4.1.6.1, 4.1.7, and
4.1.8.
The error response MUST identify in the "version-number" operation
parameter the closest version number that the IPP object does
support. For example, if a Client supplies version '1.0' and an
IPP/1.1 object supports version '1.0', then it responds with version
'1.0' in all responses to such a request. If the IPP/1.1 object does
not support version '1.0', then it should accept the request and
respond with version '1.1' or can reject the request and respond with
this error code and version '1.1'. If a Client supplies a version
'1.2', the IPP/1.1 object should accept the request and return
version '1.1' or can reject the request and respond with this error
code and version '1.1'. See Sections 4.1.8 and 5.3.14.
B.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
Job Creation 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 Job Creation request is that the
printer currently has a paper jam. In many cases however, where the
Printer 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.
B.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
Sweet & McDonald Expires February 26, 2017 [Page 197]
Internet-Draft IPP/1.1: Model and Semantics August 2016
operation. The Client MAY try the unmodified request again at some
later point in time with an expectation that the temporary internal
error condition has been cleared. Alternatively, as an
implementation option, a Printer MAY delay the response until the
temporary condition is cleared so that no error is returned.
B.1.5.7. server-error-not-accepting-Jobs (0x0506)
A temporary error indicating that the Printer is not currently
accepting jobs, because the Adminstrator has set the value of the
Printer's "printer-is-accepting-jobs" attribute to 'false' (by means
outside the scope of this IPP/1.1 document).
B.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.
B.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.
B.1.5.10. server-error-multiple-document-jobs-not-supported (0x0509)
The IPP object does not support multiple Documents per Job and a
Client attempted to supply Document data with a second Send-Document
or Send-URI operation.
B.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
Sweet & McDonald Expires February 26, 2017 [Page 198]
Internet-Draft IPP/1.1: Model and Semantics August 2016
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
client-error-compression-not-supported x x x x x
client-error-compression-error x x x x
client-error-document-format-error x x x x
client-error-document-access-error 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 x
server-error-multiple-document-jobs- x x
not-supported
HJ = Hold-Job, RJ = Release-Job, RS = Restart-Job
PP = Pause-Printer, RP = Resume-Printer, PJ = Purge-Jobs
IPP Operations (cont.)
IPP Status Keyword HJ RJ RS PP RP PJ
------------------ -- -- -- -- -- --
successful-ok x x x x x x
successful-ok-ignored-or-substituted- x x x x x x
attributes
successful-ok-conflicting-attributes x x x x x x
client-error-bad-request x x x x x x
client-error-forbidden x x x x x x
client-error-not-authenticated x x x x x x
client-error-not-authorized x x x x x x
client-error-not-possible x x x x x x
client-error-timeout
client-error-not-found x x x x x x
client-error-gone x x x x x x
Sweet & McDonald Expires February 26, 2017 [Page 199]
Internet-Draft IPP/1.1: Model and Semantics August 2016
client-error-request-entity-too-large x x x x x x
client-error-request-value-too-long x x x x x x
client-error-document-format-not-
supported
client-error-attributes-or-values-not- x x x x x x
supported
client-error-uri-scheme-not-supported
client-error-charset-not-supported x x x x x x
client-error-conflicting-attributes x x x x x x
client-error-compression-not-supported
client-error-compression-error
client-error-document-format-error
client-error-document-access-error
server-error-internal-error x x x x x x
server-error-operation-not-supported x x x x x x
server-error-service-unavailable x x x x x x
server-error-version-not-supported x x x x x x
server-error-device-error
server-error-temporary-error x x x x x x
server-error-not-accepting-jobs
server-error-busy x x x x x x
server-error-job-canceled
server-error-multiple-document-jobs-
not-supported
Appendix C. Processing IPP Attributes
When submitting a print Job to a Printer, the IPP model allows a
Client to supply operation and Job Template attributes along with the
Document data. These Job Template attributes in the Job Creation
request affect the rendering, production and finishing of the
documents in the Job. Similar types of instructions can also be
contained in the Document data itself. In addition, the Printer has
a set of attributes that describe what rendering and finishing
processes which are supported by that Printer. This model, which
allows for flexibility and power, also introduces the potential that
at Job submission time, these Client-supplied attributes can conflict
with either:
o what the implementation is capable of realizing (i.e., what the
Printer supports), as well as
o the instructions embedded within the Document data itself.
The following sections describe how these two types of conflicts are
handled in the IPP model.
Sweet & McDonald Expires February 26, 2017 [Page 200]
Internet-Draft IPP/1.1: Model and Semantics August 2016
C.1. Fidelity
If there is a conflict between what the Client requests and what a
Printer supports, the Client can request one of two possible conflict
handling mechanisms:
1) either reject the Job since the Job cannot be processed exactly as
specified, or
2) allow the Printer to make any changes necessary to proceed with
processing the Job the best it can.
In the first case the Client is indicating to the Printer: "Print the
Job exactly as specified with no exceptions, and if that can't be
done, don't even bother printing the Job at all." In the second
case, the Client is indicating to the Printer: "It is more important
to make sure the Job is printed rather than be processed exactly as
specified; just make sure the Job is printed even if some Client-
supplied attributes need to be changed or ignored."
The IPP model accounts for this situation by introducing an "ipp-
attribute-fidelity" attribute.
In a Job Creation request, "ipp-attribute-fidelity" is a boolean
operation attribute that MAY be supplied by the Client. The value
'true' indicates that total fidelity to Client supplied Job Template
attributes and values is required. The Client is requesting that the
Job be printed exactly as specified, and if that is not possible then
the Job MUST be rejected rather than processed incorrectly. The
value 'false' indicates that a reasonable attempt to print the Job is
acceptable. If a Printer does not support some of the Client
supplied Job Template attributes or values, the Printer MUST ignore
or replace them with supported values. The Printer can choose to
substitute the default value associated with that attribute, or use
some other supported value that is similar to the unsupported
requested value. For example, if a Client supplies a "media" value
of 'na_letter_8.5x11in', the Printer can choose to substitute
'iso_a4_210x297mm' rather than a default value of
'na_personal_3.625x6.5in'. If the Client does not supply the "ipp-
attribute-fidelity" attribute, the Printer assumes a value of
'false'.
Each Printer implementation MUST support both types of "fidelity"
printing (that is whether the Client supplies a value of 'true' or
'false'):
o If the Client supplies 'false' or does not supply the attribute,
the Printer MUST always accept the request by ignoring unsupported
Sweet & McDonald Expires February 26, 2017 [Page 201]
Internet-Draft IPP/1.1: Model and Semantics August 2016
Job Template attributes and by substituting unsupported values of
supported Job Template attributes with supported values.
o If the Client supplies 'true', the Printer MUST reject the request
if the Client supplies unsupported Job Template attributes.
Since a Client can always query a Printer to find out exactly what is
and is not supported, "ipp-attribute-fidelity" set to 'false' is
useful when:
1) The End User uses a command line interface to request attributes
that might not be supported.
2) In a GUI context, if the End User expects the Job might be moved
to another printer and prefers a sub-optimal result to nothing at
all.
3) The End User just wants something reasonable in lieu of nothing at
all.
C.2. Page Description Language (PDL) Override
If there is a conflict between the value of an IPP Job Template
attribute and a corresponding instruction in the Document data, the
value of the IPP attribute SHOULD take precedence over the document
instruction. Consider the case where a previously formatted file of
Document data is sent to an IPP Printer. In this case, if the Client
supplies any attributes at Job submission time, the Client desires
that those attributes override the embedded instructions. Consider
the case were a previously formatted document has embedded in it
commands to load 'iso-a4' media. However, the document is passed to
an End User that only has access to a printer with 'na-letter' media
loaded. That End User most likely wants to submit that document to
an IPP Printer with the "media" Job Template attribute set to 'na-
letter'. The Job submission attribute should take precedence over
the embedded PDL instruction. However, until companies that supply
Document data interpreters allow a way for external IPP attributes to
take precedence over embedded Job production instructions, a Printer
might not be able to support the semantics that IPP attributes
override the embedded instructions.
The IPP model accounts for this situation by introducing a "pdl-
override-supported" attribute that describes the Printers
capabilities to override instructions embedded in the PDL data
stream. The value of the "pdl-override-supported" attribute is
configured by means outside the scope of this IPP/1.1 document.
This REQUIRED Printer attribute takes on the following values:
Sweet & McDonald Expires February 26, 2017 [Page 202]
Internet-Draft IPP/1.1: Model and Semantics August 2016
o 'attempted': This value indicates that the Printer attempts to
make the IPP attribute values take precedence over embedded
instructions in the Document data, however there is no guarantee.
o 'not-attempted': This value indicates that the Printer makes no
attempt to make the IPP attribute values take precedence over
embedded instructions in the Document data.
At Job processing time, an implementation that supports the value of
'attempted' might do one of several different actions:
1) Generate an Output Device specific command sequence to realize the
feature represented by the IPP attribute value.
2) Parse the Document data itself and replace the conflicting
embedded instruction with a new embedded instruction that matches the
intent of the IPP attribute value.
3) Indicate to the Printer that external supplied attributes take
precedence over embedded instructions and then pass the external IPP
attribute values to the Document data interpreter.
4) Anything else that allows for the semantics that IPP attributes
override embedded Document data instructions.
Since 'attempted' does not offer any type of guarantee, even though a
given Printer might not do a very "good" Job of attempting to ensure
that IPP attributes take a higher precedence over instructions
embedded in the Document data, it would still be a conforming
implementation.
At Job processing time, an implementation that supports the value of
'not-attempted' might do one of the following actions:
1) Simply pre-pend the Document data with the PDL instruction that
corresponds to the Client-supplied PDL attribute, such that if the
Document data also has the same PDL instruction, it will override
what the Printer pre-pended. In other words, this implementation is
using the same implementation semantics for the Client-supplied IPP
attributes as for the Printer defaults.
2) Parse the Document data and replace the conflicting embedded
instruction with a new embedded instruction that approximates, but
does not match, the semantic intent of the IPP attribute value.
Note: The "ipp-attribute-fidelity" attribute applies to the Printer's
ability to either accept or reject other unsupported Job Template
attributes. In other words, if "ipp-attribute-fidelity" is set to
Sweet & McDonald Expires February 26, 2017 [Page 203]
Internet-Draft IPP/1.1: Model and Semantics August 2016
'true', a Job is accepted if and only if the Client supplied Job
Template attributes and values are supported by the Printer. Whether
these attributes actually affect the processing of the Job when the
Document data contains embedded instructions depends on the ability
of the Printer to override the instructions embedded in the Document
data with the semantics of the IPP attributes. If the Document data
attributes can be overridden ("pdl-override-supported" set to
'attempted'), the Printer makes an attempt to use the IPP attributes
when processing the Job. If the Document data attributes cannot be
overridden ("pdl-override-supported" set to 'not-attempted'), the
Printer makes no attempt to override the embedded Document data
instructions with the IPP attributes when processing the Job, and
hence, the IPP attributes can fail to affect the Job processing and
output when the corresponding instruction is embedded in the Document
data.
C.3. Using Job Template Attributes During Document Processing.
The Printer uses some of the Job's Job Template attributes during the
processing of the Document data associated with that Job. These
include, but are not limited to, "orientation-requested", "number-
up", "sides", "media", and "copies". The processing of each document
in a Job Object MUST follow the steps below. These steps are
intended only to identify when and how attributes are to be used in
processing Document data and any alternative steps that accomplishes
the same effect can be used to implement this specification document.
1. Using the Client supplied "document-format" attribute or some
form of Document format detection algorithm (if the value of
"document-format" is not specific enough), determine whether the
Document data has already been formatted for printing. If the
Document data has been formatted, then go to step 2. Otherwise,
the Document data MUST be formatted. The formatting detection
algorithm is implementation defined and is not specified by this
document. The formatting of the Document data uses the
"orientation-requested" attribute to determine how the formatted
print data should be placed on a Input Page, see Section 5.2.10
for the details.
2. The Document data is a set of Input Pages in a known media type.
The "page-ranges" attribute is used to select, as specified in
Section 5.2.7, a sub-sequence of the pages in the print-stream
that are to be processed and images.
3. The input to this step is a sequence of Input Pages. This step
is controlled by the "number-up" attribute. If the value of
"number-up" is N, then during the processing of the Input Pages,
each N Input Pages are positioned, as specified in Section 5.2.9,
Sweet & McDonald Expires February 26, 2017 [Page 204]
Internet-Draft IPP/1.1: Model and Semantics August 2016
to create a single Impression. If a given document does not have
N more Input Pages, then the completion of the Impression is
controlled by the "multiple-document-handling" attribute as
described in Section 5.2.4; when the value of this attribute is
'single-document' or 'single-document-new-sheet', the Input Pages
of Document data from subsequent documents is used to complete
the Impression.
The size (scaling), position (translation) and rotation of the Input
Pages on the Impression is implementation defined. Note that during
this process the Input Pages can be rendered to a form suitable for
placing on the Impression; this rendering is controlled by the values
of the "printer-resolution" and "print-quality" attributes as
described in Sections 5.2.12 and 5.2.13. In the case N=1, the
Impression is nearly the same as the Input Page; the differences
would only be in the size, position and rotation of the Input Page
and/or any decoration, such as a frame to the page, that is added by
the implementation.
1. The collection of Impressions is placed, in sequence, onto sides
of the Media Sheets. This placement is controlled by the "sides"
attribute and the orientation of the Input Page, as described in
Section 5.2.8. The orientation of the Input Pages affects the
orientation of the Impression; for example, if "number-up" equals
2, then, typically, two portrait Input Pages become one landscape
Impression. Note that the placement of Impressions onto Media
Sheets is also controlled by the "multiple-document-handling"
attribute as described in Section 5.2.4.
2. The "copies" and "multiple-document-handling" attributes are used
to determine how many copies of each Media Sheet are printed and
in what order. See Sections 5.2.4 and 5.2.5 for the details.
3. When the correct number of copies are created, the Media Sheets
are finished according to the values of the "finishings"
attribute as described in 4.2.6. Note that sometimes finishing
processes can require manual intervention to perform the
finishing processes on the copies, especially uncollated copies.
This document allows any or all of the processing steps to be
performed automatically or manually at the discretion of the
Printer.
Appendix D. Generic Directory Schema
This section defines a generic schema for an entry in a directory
service. Implementations of this schema are defined by the LDAP
Schema for Printer Services [RFC7612] and IPP Everywhere
[PWG5100.14]. A directory service is a means by which service users
Sweet & McDonald Expires February 26, 2017 [Page 205]
Internet-Draft IPP/1.1: Model and Semantics August 2016
can locate service providers. In IPP environments, this means that
IPP Printers can be registered (either automatically or with the help
of an Adminstrator) as entries of type printer in the directory using
an implementation specific mechanism such as entry attributes, entry
type fields, specific branches, etc. Directory clients can search or
browse for entries of type printer. Clients use the directory
service to find entries based on naming, organizational contexts, or
filtered searches on attribute values of entries. For example, a
Client can find all printers in the "Local Department" context.
Authentication and authorization are also often part of a directory
service so that an Adminstrator can place limits on End Users so that
they are only allowed to find entries to which they have certain
access rights. IPP itself does not require any specific directory
service protocol or provider.
Note: Some directory implementations allow for the notion of
"aliasing". That is, one directory entry object can appear as
multiple directory entry object with different names for each object.
In each case, each alias refers to the same directory entry object
which refers to a single IPP Printer.
The generic schema is a subset of IPP Printer Job Template and
Printer Description attributes (Sections 5.2 and 5.4). These
attributes are identified as either RECOMMENDED or OPTIONAL for the
directory entry itself. This conformance labeling is NOT the same
conformance labeling applied to the attributes of IPP Printers
objects. The conformance labeling in this Appendix is intended to
apply to directory templates and to IPP Printer implementations that
subscribe by adding one or more entries to a directory. RECOMMENDED
attributes SHOULD be associated with each directory entry. OPTIONAL
attributes MAY be associated with the directory entry (if known or
supported). In addition, all directory entry attributes SHOULD
reflect the current attribute values for the corresponding Printer.
The names of attributes in directory schema and entries SHOULD be the
same as the IPP Printer attribute names as shown, as much as
possible.
In order to bridge between the directory service and the IPP Printer,
one of the RECOMMENDED directory entry attributes is the Printer's
"printer-uri-supported" attribute. The directory Client queries the
"printer-uri-supported" attribute (or its equivalent) in the
directory entry and then the IPP Client addresses the IPP Printer
using one of its URIs. The "uri-security-supported" attribute
identifies the protocol (if any) used to secure a channel.
The attributes in Table 23 define the generic schema for directory
entries of type PRINTER.
Sweet & McDonald Expires February 26, 2017 [Page 206]
Internet-Draft IPP/1.1: Model and Semantics August 2016
+------------------------------------+-------------+----------------+
| Attribute | Conformance | Section |
+------------------------------------+-------------+----------------+
| charset-supported | OPTIONAL | Section 5.4.18 |
+------------------------------------+-------------+----------------+
| color-supported | RECOMMENDED | Section 5.4.26 |
+------------------------------------+-------------+----------------+
| compression-supported | RECOMMENDED | Section 5.4.32 |
+------------------------------------+-------------+----------------+
| document-format-supported | RECOMMENDED | Section 5.4.22 |
+------------------------------------+-------------+----------------+
| finishings-supported | OPTIONAL | Section 5.2.6 |
+------------------------------------+-------------+----------------+
| generated-natural-language- | OPTIONAL | Section 5.4.20 |
| supported | | |
+------------------------------------+-------------+----------------+
| ipp-versions-supported | RECOMMENDED | Section 5.4.14 |
+------------------------------------+-------------+----------------+
| media-supported | RECOMMENDED | Section 5.2.11 |
+------------------------------------+-------------+----------------+
| multiple-document-jobs-supported | OPTIONAL | Section 5.4.16 |
+------------------------------------+-------------+----------------+
| number-up-supported | OPTIONAL | Section 5.2.7 |
+------------------------------------+-------------+----------------+
| pages-per-minute-color | OPTIONAL | Section 5.4.37 |
+------------------------------------+-------------+----------------+
| pages-per-minute | OPTIONAL | Section 5.4.36 |
+------------------------------------+-------------+----------------+
| print-quality-supported | OPTIONAL | Section 5.2.13 |
+------------------------------------+-------------+----------------+
| printer-info | OPTIONAL | Section 5.4.6 |
+------------------------------------+-------------+----------------+
| printer-location | RECOMMENDED | Section 5.4.5 |
+------------------------------------+-------------+----------------+
| printer-make-and-model | RECOMMENDED | Section 5.4.9 |
+------------------------------------+-------------+----------------+
| printer-more-info | OPTIONAL | Section 5.4.7 |
+------------------------------------+-------------+----------------+
| printer-name | RECOMMENDED | Section 5.4.4 |
+------------------------------------+-------------+----------------+
| printer-resolution-supported | OPTIONAL | Section 5.2.12 |
+------------------------------------+-------------+----------------+
| printer-uri-supported | RECOMMENDED | Section 5.4.1 |
+------------------------------------+-------------+----------------+
| sides-supported | RECOMMENDED | Section 5.2.8 |
+------------------------------------+-------------+----------------+
| supported | OPTIONAL | Section 5.4.20 |
+------------------------------------+-------------+----------------+
Sweet & McDonald Expires February 26, 2017 [Page 207]
Internet-Draft IPP/1.1: Model and Semantics August 2016
| uri-authentication-supported | RECOMMENDED | Section 5.4.2 |
+------------------------------------+-------------+----------------+
| uri-security-supported | RECOMMENDED | Section 5.4.3 |
+------------------------------------+-------------+----------------+
Table 23: Attributes in Directory Entries
Appendix E. Acknowledgements
The authors would like to acknowledge the following individuals for
their contributions to the original IPP/1.1 specifications:
Roger deDry, Tom Hastings (original RFC 2911 editor), Robert Herriot,
Scott A. Isaacson, Kirk Ocke, Patrick Powell, and Peter Zehler
Appendix F. Change History
F.1. Changes In -11
The following changes are in draft-sweet-rfc2911bis-11:
o Restored the acknowledgements section to include authors from the
original RFC 2911 and 3382.
o Updated the vendor extension recommendations for keywords and
attributes to use SMI Enterprise Number prefixes, per ISTO-PWG IPP
workgroup decision on August 23, 2016.
F.2. Changes In -10
The following changes are in draft-sweet-rfc2910bis-10:
o Abstract: Mention that this document obsoletes RFC 2910 and 3382,
and reword for clarity.
o Editor's Note: Add parenthetical note to RFC editor to remove
before publication.
o Acronyms: Drop external reference to PWG web site.
o Updated references to ASCII to RFC 20/STD 80.
o Updated links to IANA-CS and IANA-MT.
o Spelling: Fixed spelling of Administrative.
Sweet & McDonald Expires February 26, 2017 [Page 208]
Internet-Draft IPP/1.1: Model and Semantics August 2016
o Clarified that IPP objects are Jobs, Printers, etc., and that IPP
Printer object is referred to as "Printer", IPP Job object is
"Job", etc.
o Fixed figure captions and references.
o Fixed references to appendices.
o Changed examples using old working draft on ftp.pwg.org to an
imaginary file on www.example.com.
o Section 1: Change external references to PWG IPP WG so they appear
as an informational reference. Also mention IPP 2.0, 2.1, and
2.2.
o Section 1.1: Editorial changes.
o Section 2.3.11: Reword to avoid duplicate conformance terms.
o Section 3.4: Reword use of secure URIs.
o Section 4.1.4.1: Added reference to RFC 2978 for charsets,
clarified that charset conversion, filtering, and/or replacement
might be done on the client side.
o Section 4.1.4.1: Added reference to RFC 5646 for language tags,
reword section on incompatible combinations of language and
charset.
o Section 4.1.5: Reword to avoid duplicate conformance terms.
o Section 4.1.6: Reword to avoid duplicate conformance terms.
o Section 4.1.6.2: an IPP Client CAN examine or display the
messages.
o Section 4.1.7: Clarified section reference (in this document).
o Sections 4.1.9, 4.2.1.2, and 4.2.2: Reworded references to the
implementor's guides.
o Section 5.1.3.3: Clarified language tag matching, reference RFC
5051.
o Section 5.2.11: Reworded "media-col" note to use MAY.
Sweet & McDonald Expires February 26, 2017 [Page 209]
Internet-Draft IPP/1.1: Model and Semantics August 2016
o Section 5.4.2: Clarify that the textual name can come from the
Common Name or Subject Alternate Name fields in the X.509
certificate.
o Section 5.4.3: Added reference to RFC 7525.
o Section 6.1: Reword to avoid duplicate conformance terms.
o Section 7: Clarify that the IANA IPP registry already exists and
only the pointers to the current registration procedures should be
updated. Harmonize registration procedures and rules with what is
shown in the current IANA IPP Registry. Provide a separate
subsection for each sub-registry.
o Section 7.1: Reverse domain name for vendor keyword prefixes.
o Section 7.8: Updated MIME media type registration RFC
o Section 9: Reword small business example as "private LAN with
physical security", add reference for private information in Job
objects.
o Section 9.1.1: Add reference to TLS.
o Section 9.1.2: Mention authentication and scanning of document
data for mitigation of spamming and malicious content threats.
o Section 9.1.3: Mention that print-by-reference is not a DoS
threat.
o Appendix A: Dropped attribute syntaxes, attribute groups, and out-
of-band attribute values which now require a specification.
Updated templates to reflect current requirements. IPP Designated
Expert(s) are the change controllers.
o Appendix C.1: Reword section on substituting unsupported values to
avoid confusion.
o Moved RFC 3239 and 3997 references to the Informative References
section.
F.3. Changes In -09
The following changes are in draft-sweet-rfc2911bis-09:
o Section 2.3.4: Mention imposition of input pages on impressions
during processing.
Sweet & McDonald Expires February 26, 2017 [Page 210]
Internet-Draft IPP/1.1: Model and Semantics August 2016
o Section 2.3.8: Mention roll media.
o Section 4.1.4: Reworded for clarity.
o Section 4.2.1.2: Moved Status Message after Natural Language and
Character Set.
o Section 4.2.5.2: Moved Status Message after Natural Language and
Character Set.
o Section 4.2.6.2: Moved Status Message after Natural Language and
Character Set.
o Section 4.2.7.2: Moved Status Message after Natural Language and
Character Set.
o Section 4.3.1.2: Moved Status Message after Natural Language and
Character Set.
o Section 4.3.3.2: Moved Status Message after Natural Language and
Character Set.
o Section 4.3.4.2: Moved Status Message after Natural Language and
Character Set.
o Section 5.1: Moved out-of-band syntaxes to their own sub-section.
o Section 5.2.6: Origin of media sheet is the top left corner.
F.4. Changes In -08
The following changes are in draft-sweet-rfc2911bis-08:
o Section 2.3.3 (End User): Capitalize defined terms.
o Section 2.3.11 (Supports): Add a final paragraph on naming
conventions for xxx-supported, xxx-default, and xxx-configured.
o Section 4.1.3 (Attributes): Updated last paragraph to use
normative language (IPP object MUST return an error)
o Section 4.2.1.2: (Print-Job Response): Reword reference to job-
state-reasons attribute.
o Section 5.4.12 (printer-state-reasons): Added RFC 3805 property
values that correspond to each reason, sorted list.
Sweet & McDonald Expires February 26, 2017 [Page 211]
Internet-Draft IPP/1.1: Model and Semantics August 2016
o Section 11.1 (Normative References): Fixed title of RFC 7612
reference.
F.5. Changes In -07
The following changes are in draft-sweet-rfc2911bis-07:
o Global: Normalize "end-user" as "End User" (defined term).
o Global: Fix capitalization of "xxx-from-operator" and "xxx-by-
operator".
o Global: Drop "system" in front of "Administrator".
o Updated terminology for Administrator, End User, and Operator to
include information from RFC 2567 as well as referencing the
complete definition in that RFC.
o Simplified the definition of "job-state" in the Print-Job
response.
o Section 5.4.1: Dropped "It MAY contain more than one ..."
o Section 5.4.12: "Clients can assume" instead of "all parties
SHOULD assume".
o Section 6.1: Best practices are for user interfaces.
o Section 9.1: Drop "considered" from "are considered illustrative"
(they are).
o Appendix B: Point to IIG 2.0 for how to display status messages.
o Appendix D: Add references to LDAP schema and IPP Everywhere.
o
F.6. Changes In -06
The following changes are in draft-sweet-rfc2911bis-06:
o Global: Changed "malformed" to "malformed".
o Global: Make sure all operations are marked OPTIONAL, RECOMMENDED,
or REQUIRED.
o Global: Fix spelling: "attribure" to "attribute".
Sweet & McDonald Expires February 26, 2017 [Page 212]
Internet-Draft IPP/1.1: Model and Semantics August 2016
o Global: Change "See Rule N" to "(note N)" and "Rule N:" to "Note
N:".
o Global: Change "OPTION N:" to "Option N:".
o Global: Change "Sections A and N" to be "Appendix A and
Section N".
o Global: Change 'job-state-reasons' to "job-state-reasons".
o Global: Capitalize "output device" - defined term.
o Global: Capitalize "terminating state" and define.
o Global: Capitalize "administrator", "end user", and "operator",
and define.
o Global: Change "defined in this document" to "defined in this
document".
o Section 1.1: Drop "OPTIONAL" in front of "Notification Service".
o Section 2.2: Add reference to PWG 5100.5 for Document definition.
o Section 2.3: Fix typo, sort terms, add definitions of
Administrator, End User, Job Creation Operation, Operator, and
Terminating State.
o Section 3.2: Clarify the job-uri is deprecated for Clients.
o Section 4: Reword Client operation request.
o Section 4.1.2: "in other transport mappings".
o Section 4.1.6.2: Reword second paragraph on localization
requirements.
o Section 4.1.6.3: Reword to make it clear that localization should
only be performed when it does not obscure the meaning of the
technical information.
o Section 4.1.7: Fix typo.
o Section 4.1.8: Fix reference to Appendix E.
o Section 4.1.9: Fix typos.
Sweet & McDonald Expires February 26, 2017 [Page 213]
Internet-Draft IPP/1.1: Model and Semantics August 2016
o Section 4.2.1.1: Clarify document-natural-language, drop "In
addition to the REQUIRED parameters".
o Section 4.2.1.2: Cleanup.
o Section 4.2.2: Discover instead of determine.
o Section 4.2.7: Fix typo.
o Section 4.2.9: Clarify.
o Section 4.3.1: Reword first sentence - Create-Job creates the Job.
o Section 4.3.1.1: Reword document-natural-language description.
o Section 5.1.4: "Some SNMP MIBs".
o Section 5.2: Printers SHOULD support Job Template attributes.
o Section 5.2.1: Added table of values.
o Section 5.2.6: Reword note about '3' ('none'), add missing period.
o Section 5.2.7: Fix typos.
o Section 5.2.11: Change "historical" to "legacy", reword.
o Section 5.2.12: Missing "the".
o Section 5.2.13: Move note above table.
o Table 13: Fix order of attributes.
o Section 5.3.1: Move after job-id.
o Section 5.3.8: "service-offline" should be "service-off-line".
o Section 5.3.10: Same changes as section 4.1.6.3.
o Section 5.3.12: Drop "or not".
o Section 5.3.17.1: Capitalize Document(s), fix typo.
o Section 5.3.17.2: Capitalize Document(s), fix typo.
o Section 5.3.17.3: RECOMMENDED.
o Section 5.3.18: Values.
Sweet & McDonald Expires February 26, 2017 [Page 214]
Internet-Draft IPP/1.1: Model and Semantics August 2016
o Section 5.3.18.3: RECOMMENDED.
o Section 5.4.1: Reword.
o Section 5.4.3: Reword.
o Section 5.4.12: Add references to Printer MIB (RFC 3805) and say
something about how to interpret the lack of a suffix (not just an
error).
o Section 5.4.29: Drop extra "job" qualifier.
o Section 5.4.30: "In order to be useful" instead of "in order to
work."
o Section 5.4.32: Fix typos.
o Section 6.1: Reword UI conformance requirements (or lack thereof).
o Section 7.6: Fix reference and typo.
o Section 8: Clarify/reword some requirements.
o Section 9.x: Rewording.
o Appendix B: Rewording.
o Appendix B.1.3: "in this document" (not in IPP/1.1).
o Appendix C: Deleted this appendix in its entirety since PWG 5101.1
supersedes it and is already referenced.
o Appendix D.3: Rewording, fix typos.
o Table 22: Fix (missing cells)
F.7. Changes In -05
The following changes are in draft-sweet-rfc2911bis-05:
o Global: Drop use of "OPTIONALLY", use MAY instead.
o Global: Printers SHOULD return unsupported attributes.
o Global: Update use of "need only" to less awkward wording.
o Global: Reword all usage of "NOT REQUIRED".
Sweet & McDonald Expires February 26, 2017 [Page 215]
Internet-Draft IPP/1.1: Model and Semantics August 2016
o Global: Move notes about deprecation right after the initial
description.
o Global: type3 -> type2, drop all type3 registration instructions.
o Global: Avoid using "object" for Jobs and Printers.
o Global: Prefer printer-uri + job-id to target Jobs instead of job-
uri.
o Global: Don't talk about documents not being IPP objects, since
that is covered by PWG 5100.5.
o Global: Reword "The Client MAY supply this attribute. The Printer
MUST support ..." construct.
o Global: Remove use of "MANDATORY".
o Global: Do not capitalize Operation in "Operation attribute".
o Global: "Client" for IPP Client.
o Global: Fix section references.
o Global: printer's, job's changed to Printer's, Job's
o Global: Optional operations and attributes that are required for
IPP Everywhere are now listed as RECOMMENDED.
o Section 1: Added short list of PWG IPP specifications.
o Section 4.1.6.2: MUST use the language in the request.
o Section 4.1.6.3: SHOULD localize message.
o Section 4.1.8: SHOULD support all previous standards track
versions.
o Section 4.1.9: validating the *format* of the Document data.
o Section 4.2.9: Make MUST conditional on whether Purge-Jobs is
supported.
o Section 5.1.9: Reference PWG 5101.1 for media attribute.
o Section 5.3.7: Drop "most implementations won't bother with this
nuance."
Sweet & McDonald Expires February 26, 2017 [Page 216]
Internet-Draft IPP/1.1: Model and Semantics August 2016
o Section 5.3.10: SHOULD localize
o Section 5.3.13: SHOULD set
o Section 5.3.14: Remove ambiguity about negative time-at-xxx
values: only if the Printer knows the exact number of seconds
o Section 5.4.11: printer-state updated continuously if RFC 3995 is
supported.
o Section 5.4.12: Reword "is no longer shutdown" as "is restarted".
o Section 5.4.32: Drop Send-URI from list of operations, fix some
typos.
o Section 6.1: Drop "may omit" paragraph, reference IIG2 instead of
using a lot of weasel words about client implementations.
o Section 6.3: Drop talk about translation (confusing).
o Section 7.1: Drop type3 registrations, use example.com, use
reverse-DNS notation as recommendation unless otherwise specified
for the keyword.
o Section B.*: Drop conformance, move the rest to the beginning.
o Added references to the IPP Implementor's Guide 2.0, PWG 5101.1
(MSN2), IPP 2.0, and IPP Everywhere.
o Updated PWG 5100.12 reference to current stable draft in formal
vote (for full IEEE standard).
o Various editorial corrections.
F.8. Changes In -04
The following changes are in draft-sweet-rfc2911bis-04:
o Removed restart and purge from the abstract.
o Eliminated use of confusing ISO "NEED NOT" conformance
terminology.
o Added DEPRECATED terminology.
o Marked Purge-Jobs and Restart-Job as DEPRECATED.
Sweet & McDonald Expires February 26, 2017 [Page 217]
Internet-Draft IPP/1.1: Model and Semantics August 2016
o Added reference to PWG 5100.11 (JPS2) for the Resubmit-Job
operation (safe replacement for Restart-Job)
F.9. Changes In -03
The following changes are in draft-sweet-rfc2911bis-03:
o Submission type is now IETF (AD-sponsored), clarify goals.
o Also obsolete RFC 3381 per PWG IPP WG
o References to RFC 2617 are updated to the updated drafts in the
RFC editor's queue
o Section 4.1.5: Clarify note at end of section.
o Section 4.1.8: Clarify conformance requirements are for IPP/1.1
implementations.
o Section 5.4.3: Drop 'ssl3' value, fix examples.
o Section 6.2.4: Reword "understand" -> "decode and process"
o References: Drop SSL reference.
o Global: Don't use SSL3 in examples, use TLS
o Global: Client, Printer, and Job are defined terms, capitalize
o Global: Fix lots of uses of "may" (conformance term)
F.10. Changes In -02
The following changes are in draft-sweet-rfc2911bis-02:
o Section 1: Dropped RFC 3381 reference since we are obsoleting it.
o Section 4.1.5: Added reference to IPP and IPPS URI scheme RFCs.
o Section 4.1.8: Added references to RFC 3510 and 7472 which define
the IPP and IPPS URI schemes and port number.
o Added section listing major changes since RFC 2911.
o Fix all "it is recommended" passive voice conformance
requirements.
Sweet & McDonald Expires February 26, 2017 [Page 218]
Internet-Draft IPP/1.1: Model and Semantics August 2016
F.11. Changes In -01
The following changes are in draft-sweet-rfc2911bis-01:
o Errata ID 364: Fix range of "redirection" status codes (to 0x03xx)
o Errata ID 694: Fix range of vendor status codes (0x0n80 to 0x0nff)
o Errata ID 3072: Reword multiple-document-handling definition since
it also applies to single document Jobs and is the only
interoperable way to request uncollated copies.
o Errata ID 3365: Fix bad nameWithLanguage maximum length -
reference nameWithoutLanguage section for length
o Errata ID 4173: Fix range of vendor operation codes (0x4000 to
0x7fff)
o Updated obsoleted RFC references
o Change IPP-IIG reference to RFC 3196
o Updated Create-Job, Send-Document, and Send-URI to RECOMMENDED.
Authors' Addresses
Michael Sweet
Apple Inc.
1 Infinite Loop
MS 111-HOMC
Cupertino, CA 95014
US
Email: msweet@apple.com
Ira McDonald
High North, Inc.
PO Box 221
Grand Marais, MI 49839
US
Phone: +1 906-494-2434
Email: blueroofmusic@gmail.com
Sweet & McDonald Expires February 26, 2017 [Page 219]