Internet Printing Protocol/1.1: Model and Semantics
RFC 2911
| Document | Type |
RFC
- Proposed Standard
(September 2000)
Errata
Obsoleted by RFC 8011
Obsoletes RFC 2566
|
|
|---|---|---|---|
| Authors | Scott A. Isaacson , Thomas N. Hastings , Patrick Powell , Robert G. Herriot , Roger deBry | ||
| Last updated | 2020-01-21 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | (None) | |
| Send notices to | (None) |
RFC 2911
quot; 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 sections 3.1.7 and 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 sections 3.1.7 and 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.1 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. Hastings, et al. Standards Track [Page 179] RFC 2911 IPP/1.1: Model and Semantics September 2000 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. Hastings, et al. Standards Track [Page 180] RFC 2911 IPP/1.1: Model and Semantics September 2000 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 and/or Printer implementation. Hastings, et al. Standards Track [Page 181] RFC 2911 IPP/1.1: Model and Semantics September 2000 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 Job Template attributes that are not supported as well, since this error is a bigger problem than with Job Template attributes. See sections 3.1.6.1, 3.1.7, and 3.2.1.1. Hastings, et al. Standards Track [Page 182] RFC 2911 IPP/1.1: Model and Semantics September 2000 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-attribute-fidelity" operation attribute with the 'true' value, the Printer object MUST return this status code. The Printer object MUST also return in the Unsupported Attributes Group all the attributes and/or values supplied by the client that are not supported. See section 3.1.7. 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 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 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 scheme of the client-supplied URI in a Print-URI or a Send-URI operation is not supported. See sections 3.1.6.1 and 3.1.7. 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). See sections 3.1.6.1 and 3.1.7. 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 document does not permit to be substituted or ignored. The Printer object MUST also return in the Unsupported Attributes Group the conflicting attributes supplied by the client. See sections 3.1.7 and 3.2.1.2. Hastings, et al. Standards Track [Page 183] RFC 2911 IPP/1.1: Model and Semantics September 2000 13.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 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 Job Template attributes that are not supported as well, since this error is a bigger problem than with Job Template attributes. See sections 3.1.6.1, 3.1.7, and 3.2.1.1. 13.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 object 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 3.1.7 and 3.2.1.1. 13.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 object 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 3.1.7 and 3.2.1.1. 13.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 3.1.6.4). This error is returned independent of the client-supplied "ipp-attribute- fidelity". The Printer object 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 3.1.6.1 and 3.1.7. Hastings, et al. Standards Track [Page 184] RFC 2911 IPP/1.1: Model and Semantics September 2000 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. See sections 3.1.6.1 and 3.1.7. 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 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 3.1.6.2) describing Hastings, et al. Standards Track [Page 185] RFC 2911 IPP/1.1: Model and Semantics September 2000 why that version is not supported and what other versions are supported by that IPP object. See sections 3.1.6.1, 3.1.7, and 3.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 may 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 may reject the request and respond with this error code and version '1.1'. See sections 3.1.8 and 4.4.14. 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. Hastings, et al. Standards Track [Page 186] RFC 2911 IPP/1.1: Model and Semantics September 2000 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-accepting-jobs" attribute to 'false' (by means outside the scope of this IPP/1.1 document). 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.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. 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 Hastings, et al. Standards Track [Page 187] RFC 2911 IPP/1.1: Model and Semantics September 2000 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 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 Hastings, et al. Standards Track [Page 188] RFC 2911 IPP/1.1: Model and Semantics September 2000 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 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 Hastings, et al. Standards Track [Page 189] RFC 2911 IPP/1.1: Model and Semantics September 2000 14. APPENDIX C: "media" keyword values Standard keyword values are taken from several sources. Standard values are defined (taken from DPA[ISO10175] and the Printer MIB[RFC1759]): 'default': The default medium for the output device 'iso-a4-white': Specifies the ISO A4 white medium: 210 mm x 297 mm 'iso-a4-colored': Specifies the ISO A4 colored medium: 210 mm x 297 mm 'iso-a4-transparent' Specifies the ISO A4 transparent medium: 210 mm x 297 mm 'iso-a3-white': Specifies the ISO A3 white medium: 297 mm x 420 mm 'iso-a3-colored': Specifies the ISO A3 colored medium: 297 mm x 420 mm 'iso-a5-white': Specifies the ISO A5 white medium: 148 mm x 210 mm 'iso-a5-colored': Specifies the ISO A5 colored medium: 148 mm x 210 mm 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-colored': Specifies the ISO B4 colored medium: 250 mm x 353 mm 'iso-b5-white': Specifies the ISO B5 white medium: 176 mm x 250 mm 'iso-b5-colored': Specifies the ISO B5 colored medium: 176 mm x 250 mm 'jis-b4-white': Specifies the JIS B4 white medium: 257 mm x 364 mm 'jis-b4-colored': Specifies the JIS B4 colored medium: 257 mm x 364 mm 'jis-b5-white': Specifies the JIS B5 white medium: 182 mm x 257 mm 'jis-b5-colored': Specifies the JIS B5 colored medium: 182 mm x 257 mm The following standard values are defined for North American media: 'na-letter-white': Specifies the North American letter white medium 'na-letter-colored': Specifies the North American letter colored medium 'na-letter-transparent': Specifies the North American letter transparent medium 'na-legal-white': Specifies the North American legal white medium 'na-legal-colored': Specifies the North American legal colored medium Hastings, et al. Standards Track [Page 190] RFC 2911 IPP/1.1: Model and Semantics September 2000 The following standard values are defined for envelopes: 'iso-b4-envelope': Specifies the ISO B4 envelope medium 'iso-b5-envelope': Specifies the ISO B5 envelope medium 'iso-c3-envelope': Specifies the ISO C3 envelope medium 'iso-c4-envelope': Specifies the ISO C4 envelope medium 'iso-c5-envelope': Specifies the ISO C5 envelope medium 'iso-c6-envelope': Specifies the ISO C6 envelope medium 'iso-designated-long-envelope': Specifies the ISO Designated Long envelope medium 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'na-9x12-envelope': Specifies the North American 9x12 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium 'na-7x9-envelope': Specifies the North American 7x9 inch envelope 'na-9x11-envelope': Specifies the North American 9x11 inch envelope 'na-10x14-envelope': Specifies the North American 10x14 inch envelope 'na-number-9-envelope': Specifies the North American number 9 business envelope 'na-6x9-envelope': Specifies the North American 6x9 inch envelope 'na-10x15-envelope': Specifies the North American 10x15 inch envelope The following standard values are defined for the less commonly used media: 'executive-white': Specifies the white executive medium 'folio-white': Specifies the folio white medium 'invoice-white': Specifies the white invoice medium 'ledger-white': Specifies the white ledger medium 'quarto-white': Specified the white quarto medium 'iso-a0-white': Specifies the ISO A0 white medium: 841 mm x 1189 mm 'iso-a0-transparent': Specifies the ISO A0 transparent medium: 841 mm x 1189 mm 'iso-a0-translucent': Specifies the ISO A0 translucent medium: 841 mm x 1189 mm 'iso-a1-white': Specifies the ISO A1 white medium: 594 mm x 841 mm 'iso-a1-transparent': Specifies the ISO A1 transparent medium: 594 mm x 841 mm 'iso-a1-translucent': Specifies the ISO A1 translucent medium: 594 mm x 841 mm 'iso-a2-white': Specifies the ISO A2 white medium: 420 mm x 594 mm Hastings, et al. Standards Track [Page 191] RFC 2911 IPP/1.1: Model and Semantics September 2000 'iso-a2-transparent': Specifies the ISO A2 transparent medium: 420 mm x 594 mm 'iso-a2-translucent': Specifies the ISO A2 translucent medium: 420 mm x 594 mm 'iso-a3-transparent': Specifies the ISO A3 transparent medium: 297 mm x 420 mm 'iso-a3-translucent': Specifies the ISO A3 translucent medium: 297 mm x 420 mm 'iso-a4-translucent': Specifies the ISO A4 translucent medium: 210 mm x 297 mm 'iso-a5-transparent': Specifies the ISO A5 transparent medium: 148 mm x 210 mm 'iso-a5-translucent': Specifies the ISO A5 translucent medium: 148 mm x 210 mm 'iso-a6-white': Specifies the ISO A6 white medium: 105 mm x 148 mm 'iso-a7-white': Specifies the ISO A7 white medium: 74 mm x 105 mm 'iso-a8-white': Specifies the ISO A8 white medium: 52 mm x 74 mm 'iso-a9-white': Specifies the ISO A9 white medium: 37 mm x 52 mm 'iso-a10-white': Specifies the ISO A10 white medium: 26 mm x 37 mm 'iso-b0-white': Specifies the ISO B0 white medium: 1000 mm x 1414 mm 'iso-b1-white': Specifies the ISO B1 white medium: 707 mm x 1000 mm 'iso-b2-white': Specifies the ISO B2 white medium: 500 mm x 707 mm 'iso-b3-white': Specifies the ISO B3 white medium: 353 mm x 500 mm 'iso-b6-white': Specifies the ISO B6 white medium: 125 mm x 176 mm 'iso-b7-white': Specifies the ISO B7 white medium: 88 mm x 125 mm 'iso-b8-white': Specifies the ISO B8 white medium: 62 mm x 88 mm 'iso-b9-white': Specifies the ISO B9 white medium: 44 mm x 62 mm 'iso-b10-white': Specifies the ISO B10 white medium: 31 mm x 44 mm 'jis-b0-white': Specifies the JIS B0 white medium: 1030 mm x 1456 mm 'jis-b0-transparent': Specifies the JIS B0 transparent medium: 1030 mm x 1456 mm 'jis-b0-translucent': Specifies the JIS B0 translucent medium: 1030 mm x 1456 mm 'jis-b1-white': Specifies the JIS B1 white medium: 728 mm x 1030 mm 'jis-b1-transparent': Specifies the JIS B1 transparent medium: 728 mm x 1030 mm 'jis-b1-translucent': Specifies the JIS B1 translucent medium: 728 mm x 1030 mm 'jis-b2-white': Specifies the JIS B2 white medium: 515 mm x 728 mm 'jis-b2-transparent': Specifies the JIS B2 transparent medium: 515 mm x 728 mm 'jis-b2-translucent': Specifies the JIS B2 translucent medium: 515 mm x 728 mm 'jis-b3-white': Specifies the JIS B3 white medium: 364 mm x 515 mm 'jis-b3-transparent': Specifies the JIS B3 transparent medium: 364 mm x 515 mm 'jis-b3-translucent': Specifies the JIS B3 translucent medium: 364 mm x 515 mm Hastings, et al. Standards Track [Page 192] RFC 2911 IPP/1.1: Model and Semantics September 2000 'jis-b4-transparent': Specifies the JIS B4 transparent medium: 257 mm x 364 mm 'jis-b4-translucent': Specifies the JIS B4 translucent medium: 257 mm x 364 mm 'jis-b5-transparent': Specifies the JIS B5 transparent medium: 182 mm x 257 mm 'jis-b5-translucent': Specifies the JIS B5 translucent medium: 182 mm x 257 mm 'jis-b6-white': Specifies the JIS B6 white medium: 128 mm x 182 mm 'jis-b7-white': Specifies the JIS B7 white medium: 91 mm x 128 mm 'jis-b8-white': Specifies the JIS B8 white medium: 64 mm x 91 mm 'jis-b9-white': Specifies the JIS B9 white medium: 45 mm x 64 mm 'jis-b10-white': Specifies the JIS B10 white medium: 32 mm x 45 mm The following standard values are defined for American Standard (i.e. ANSI) engineering media: 'a-white': Specifies the engineering ANSI A size white medium: 8.5 inches x 11 inches 'a-transparent': Specifies the engineering ANSI A size transparent medium: 8.5 inches x 11 inches 'a-translucent': Specifies the engineering ANSI A size translucent medium: 8.5 inches x 11 inches 'b-white': Specifies the engineering ANSI B size white medium: 11 inches x 17 inches 'b-transparent': Specifies the engineering ANSI B size transparent medium: 11 inches x 17 inches) 'b-translucent': Specifies the engineering ANSI B size translucent medium: 11 inches x 17 inches 'c-white': Specifies the engineering ANSI C size white medium: 17 inches x 22 inches 'c-transparent': Specifies the engineering ANSI C size transparent medium: 17 inches x 22 inches 'c-translucent': Specifies the engineering ANSI C size translucent medium: 17 inches x 22 inches 'd-white': Specifies the engineering ANSI D size white medium: 22 inches x 34 inches 'd-transparent': Specifies the engineering ANSI D size transparent medium: 22 inches x 34 inches 'd-translucent': Specifies the engineering ANSI D size translucent medium: 22 inches x 34 inches 'e-white': Specifies the engineering ANSI E size white medium: 34 inches x 44 inches 'e-transparent': Specifies the engineering ANSI E size transparent medium: 34 inches x 44 inches 'e-translucent': Specifies the engineering ANSI E size translucent medium: 34 inches x 44 inches Hastings, et al. Standards Track [Page 193] RFC 2911 IPP/1.1: Model and Semantics September 2000 The following standard values are defined for American Standard (i.e. ANSI) engineering media for devices that provide the "synchro-cut" feature (see section 14.1): 'axsynchro-white': Specifies the roll paper having the width of the longer edge (11 inches) of the engineering ANSI A size white medium and cuts synchronizing with data. 'axsynchro-transparent': Specifies the roll paper having the width of the longer edge (11 inches) of the engineering ANSI A size transparent medium and cuts synchronizing with data. 'axsynchro-translucent': Specifies the roll paper having the width of the longer edge (11 inches) of the engineering ANSI A size translucent medium and cuts synchronizing with data. 'bxsynchro-white': Specifies the roll paper having the width of the longer edge (17 inches) of the engineering ANSI B size white medium and cuts synchronizing with data. 'bxsynchro-transparent': Specifies the roll paper having the width of the longer edge (17 inches) of the engineering ANSI B size transparent medium and cuts synchronizing with data. 'bxsynchro-translucent': Specifies the roll paper having the width of the longer edge (17 inches) of the engineering ANSI B size translucent medium and cuts synchronizing with data. 'cxsynchro-white': Specifies the roll paper having the width of the longer edge (22 inches) of the engineering ANSI C size white medium and cuts synchronizing with data. 'cxsynchro-transparent': Specifies the roll paper having the width of the longer edge (22 inches) of the engineering ANSI C size transparent medium and cuts synchronizing with data. 'cxsynchro-translucent': Specifies the roll paper having the width of the longer edge (22 inches) of the engineering ANSI C size translucent medium and cuts synchronizing with data. 'dxsynchro-white': Specifies the roll paper having the width of the longer edge (34 inches) of the engineering ANSI D size white medium and cuts synchronizing with data. 'dxsynchro-transparent': Specifies the roll paper having the width of the longer edge (34 inches) of the engineering ANSI D size transparent medium and cuts synchronizing with data. 'dxsynchro-translucent': Specifies the roll paper having the width of the longer edge (34 inches) of the engineering ANSI D size translucent medium and cuts synchronizing with data. 'exsynchro-white': Specifies the roll paper having the width of the longer edge (44 inches) of the engineering ANSI E size white medium and cuts synchronizing with data. 'exsynchro-transparent': Specifies the roll paper having the width of the longer edge (44 inches) of the engineering ANSI E size transparent medium and cuts synchronizing with data. Hastings, et al. Standards Track [Page 194] RFC 2911 IPP/1.1: Model and Semantics September 2000 'exsynchro-translucent': Specifies the roll paper having the width of the longer edge (44 inches) of the engineering ANSI E size translucent medium and cuts synchronizing with data. The following standard values are defined for American Architectural engineering media: 'arch-a-white': Specifies the Architectural A size white medium: 9 inches x 12 inches 'arch-a-transparent': Specifies the Architectural A size transparent medium: 9 inches x 12 inches 'arch-a-translucent': Specifies the Architectural A size translucent medium: 9 inches x 12 inches 'arch-b-white': Specifies the Architectural B size white medium: 12 inches x 18 inches 'arch-b-transparent': Specifies the Architectural B size transparent medium: 12 inches x 18 inches 'arch-b-translucent': Specifies the Architectural B size translucent medium: 12 inches x 18 inches 'arch-c-white': Specifies the Architectural C size white medium: 18 inches x 24 inches 'arch-c-transparent': Specifies the Architectural C size transparent medium: 18 inches x 24 inches 'arch-c-translucent': Specifies the Architectural C size translucent medium: 18 inches x 24 inches 'arch-d-white': Specifies the Architectural D size white medium: 24 inches x 36 inches 'arch-d-transparent': Specifies the Architectural D size transparent medium: 24 inches x 36 inches 'arch-d-translucent': Specifies the Architectural D size translucent medium: 24 inches x 36 inches 'arch-e-white': Specifies the Architectural E size white medium: 36 inches x 48 inches 'arch-e-transparent': Specifies the Architectural E size transparent medium: 36 inches x 48 inches 'arch-e-translucent': Specifies the Architectural E size translucent medium: 36 inches x 48 inches The following standard values are defined for American Architectural engineering media for devices that provide the "synchro-cut" feature (see section 14.1): 'arch-axsynchro-white': Specifies the roll paper having the width of the longer edge (12 inches) of the Architectural A size white medium and cuts synchronizing with data. 'arch-axsynchro-transparent': Specifies the roll paper having the width of the longer edge (12 inches) of the Architectural A size transparent medium and cuts synchronizing with data. Hastings, et al. Standards Track [Page 195] RFC 2911 IPP/1.1: Model and Semantics September 2000 'arch-axsynchro-translucent': Specifies the roll paper having the width of the longer edge (12 inches) of the Architectural A size translucent medium and cuts synchronizing with data. 'arch-bxsynchro-white': Specifies the roll paper having the width of the longer edge (18 inches) of the Architectural B size white medium and cuts synchronizing with data. 'arch-bxsynchro-transparent': Specifies the roll paper having the width of the longer edge (18 inches) of the Architectural B size transparent medium and cuts synchronizing with data. 'arch-bxsynchro-translucent': Specifies the roll paper having the width of the longer edge (18 inches) of the Architectural B size translucent medium and cuts synchronizing with data. 'arch-cxsynchro-white': Specifies the roll paper having the width of the longer edge (24 inches) of the Architectural C size white medium and cuts synchronizing with data. 'arch-cxsynchro-transparent': Specifies the roll paper having the width of the longer edge (24 inches) of the Architectural C size transparent medium and cuts synchronizing with data. 'arch-cxsynchro-translucent': Specifies the roll paper having the width of the longer edge (24 inches) of the Architectural C size translucent medium and cuts synchronizing with data. 'arch-dxsynchro-white': Specifies the roll paper having the width of the longer edge (36 inches) of the Architectural D size white medium and cuts synchronizing with data. 'arch-dxsynchro-transparent': Specifies the roll paper having the width of the longer edge (36 inches) of the Architectural D size transparent medium and cuts synchronizing with data. 'arch-dxsynchro-translucent': Specifies the roll paper having the width of the longer edge (36 inches) of the Architectural D size translucent medium and cuts synchronizing with data. 'arch-exsynchro-white': Specifies the roll paper having the width of the longer edge (48 inches) of the Architectural E size white medium and cuts synchronizing with data. 'arch-exsynchro-transparent': Specifies the roll paper having the width of the longer edge (48 inches) of the Architectural E size transparent medium and cuts synchronizing with data. 'arch-exsynchro-translucent': Specifies the roll paper having the width of the longer edge (48 inches) of the Architectural E size translucent medium and cuts synchronizing with data. The following standard values are defined for Japanese and European Standard (i.e. ISO) engineering media, which are of a long fixed size [ASME-Y14.1M]: 'iso-a1x3-white': Specifies the ISO A1X3 white medium having the width of the longer edge (841 mm) of the ISO A1 medium Hastings, et al. Standards Track [Page 196] RFC 2911 IPP/1.1: Model and Semantics September 2000 'iso-a1x3-transparent': Specifies the ISO A1X3 transparent medium having the width of the longer edge (841 mm) of the ISO A1 medium 'iso-a1x3-translucent': Specifies the ISO A1X3 translucent medium having the width of the longer edge (841 mm) of the ISO A1 medium 'iso-a1x4-white': Specifies the ISO A1X4 white medium having the width of the longer edge (841 mm) of the ISO A1 medium 'iso-a1x4-transparent': Specifies the ISO A1X4 transparent medium having the width of the longer edge (841 mm) of the ISO A1 medium 'iso-a1x4- translucent': Specifies the ISO A1X4 translucent medium having the width of the longer edge (841 mm) of the ISO A1 medium 'iso-a2x3-white': Specifies the ISO A2X3 white medium having the width of the longer edge (594 mm) of the ISO A2 medium 'iso-a2x3-transparent': Specifies the ISO A2X3 transparent medium having the width of the longer edge (594 mm) of the ISO A2 medium 'iso-a2x3-translucent': Specifies the ISO A2X3 translucent medium having the width of the longer edge (594 mm) of the ISO A2 medium 'iso-a2x4-white': Specifies the ISO A2X4 white medium having the width of the longer edge (594 mm) of the ISO A2 medium 'iso-a2x4-transparent': Specifies the ISO A2X4 transparent medium having the width of the longer edge (594 mm) of the ISO A2 medium 'iso-a2x4-translucent': Specifies the ISO A2X4 translucent medium having the width of the longer edge (594 mm) of the ISO A2 medium 'iso-a2x5-white': Specifies the ISO A2X5 white medium having the width of the longer edge (594 mm) of the ISO A2 medium 'iso-a2x5-transparent': Specifies the ISO A2X5 transparent medium having the width of the longer edge (594 mm) of the ISO A2 medium 'iso-a2x5-translucent': Specifies the ISO A2X5 translucent medium having the width of the longer edge (594 mm) of the ISO A2 medium 'iso-a3x3-white': Specifies the ISO A3X3 white medium having the width of the longer edge (420 mm) of the ISO A3 medium 'iso-a3x3-transparent': Specifies the ISO A3X3 transparent medium having the width of the longer edge (420 mm) of the ISO A3 medium 'iso-a3x3-translucent': Specifies the ISO A3X3 translucent medium having the width of the longer edge (420 mm) of the ISO A3 medium 'iso-a3x4-white': Specifies the ISO A3X4 white medium having the width of the longer edge (420 mm) of the ISO A3 medium Hastings, et al. Standards Track [Page 197] RFC 2911 IPP/1.1: Model and Semantics September 2000 'iso-a3x4-transparent': Specifies the ISO A3X4 transparent medium having the width of the longer edge (420 mm) of the ISO A3 medium 'iso-a3x4-translucent': Specifies the ISO A3X4 translucent medium having the width of the longer edge (420 mm) of the ISO A3 medium 'iso-a3x5-white': Specifies the ISO A3X5 white medium having the width of the longer edge (420 mm) of the ISO A3 medium 'iso-a3x5-transparent': Specifies the ISO A3X5 transparent medium having the width of the longer edge (420 mm) of the ISO A3 medium 'iso-a3x5-translucent': Specifies the ISO A3X5 translucent medium having the width of the longer edge (420 mm) of the ISO A3 medium 'iso-a3x6-white': Specifies the ISO A3X6 white medium having the width of the longer edge (420 mm) of the ISO A3 medium 'iso-a3x6-transparent': Specifies the ISO A3X6 transparent medium having the width of the longer edge (420 mm) of the ISO A3 medium 'iso-a3x6-translucent': Specifies the ISO A3X6 translucent medium having the width of the longer edge (420 mm) of the ISO A3 medium 'iso-a3x7-white': Specifies the ISO A3X7 white medium having the width of the longer edge (420 mm) of the ISO A3 medium 'iso-a3x7-transparent': Specifies the ISO A3X7 transparent medium having the width of the longer edge (420 mm) of the ISO A3 medium 'iso-a3x7-translucent'': Specifies the ISO A3X7 translucent' medium having the width of the longer edge (420 mm) of the ISO A3 medium 'iso-a4x3-white': Specifies the ISO A4X3 white medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x3-transparent': Specifies the ISO A4X3 transparent medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x3-translucent'': Specifies the ISO A4X3 translucent' medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x4-white': Specifies the ISO A4X4 white medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x4-transparent': Specifies the ISO A4X4 transparent medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x4-translucent': Specifies the ISO A4X4 translucent medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x5-white': Specifies the ISO A4X5 white medium having the width of the longer edge (297 mm) of the ISO A4 medium Hastings, et al. Standards Track [Page 198] RFC 2911 IPP/1.1: Model and Semantics September 2000 'iso-a4x5-transparent': Specifies the ISO A4X5 transparent medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x5-translucent': Specifies the ISO A4X5 translucent medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x6-white': Specifies the ISO A4X6 white medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x6-transparent': Specifies the ISO A4X6 transparent medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x6-translucent': Specifies the ISO A4X6 translucent medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x7-white': Specifies the ISO A4X7 white medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x7-transparent': Specifies the ISO A4X7 transparent medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x7-translucent': Specifies the ISO A4X7 translucent medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x8-white': Specifies the ISO A4X8 white medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x8-transparent': Specifies the ISO A4X8 transparent medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x8-translucent': Specifies the ISO A4X8 translucent medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x9-white': Specifies the ISO A4X9 white medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x9-transparent': Specifies the ISO A4X9 transparent medium having the width of the longer edge (297 mm) of the ISO A4 medium 'iso-a4x9-translucent': Specifies the ISO A4X9 translucent medium having the width of the longer edge (297 mm) of the ISO A4 medium The following standard values are defined for Japanese and European Standard (i.e. ISO) engineering media, which are either a long fixed size [ASME-Y14.1M] or roll feed, for devices that provide the "synchro-cut" feature (see section 14.1): 'iso-a0xsynchro-white': Specifies the paper having the width of the longer edge (1189 mm) of the ISO A0 white medium and cuts synchronizing with data. Hastings, et al. Standards Track [Page 199] RFC 2911 IPP/1.1: Model and Semantics September 2000 'iso-a0xsynchro-transparent': Specifies the paper having the width of the longer edge (1189 mm) of the ISO A0 transparent medium and cuts synchronizing with data. 'iso-a0xsynchro-translucent': Specifies the paper having the width of the longer edge (1189 mm) of the ISO A0 translucent medium and cuts synchronizing with data. 'iso-a1xsynchro-white': Specifies the paper having the width of the longer edge (841 mm) of the ISO A1 white medium and cuts synchronizing with data. 'iso-a1xsynchro-transparent': Specifies the paper having the width of the longer edge (841 mm) of the ISO A1 transparent medium and cuts synchronizing with data. 'iso-a1xsynchro-translucent': Specifies the paper having the width of the longer edge (841 mm) of the ISO A1 translucent medium and cuts synchronizing with data. 'iso-a2xsynchro-white': Specifies the paper having the width of the longer edge (594 mm) of the ISO A2 white medium and cuts synchronizing with data. 'iso-a2xsynchro-transparent': Specifies the paper having the width of the longer edge (594 mm) of the ISO A2 transparent medium and cuts synchronizing with data. 'iso-a2xsynchro-translucent': Specifies the paper having the width of the longer edge (594 mm) of the ISO A2 translucent medium and cuts synchronizing with data. 'iso-a3xsynchro-white': Specifies the paper having the width of the longer edge (420 mm) of the ISO A3 white medium and cuts synchronizing with data. 'iso-a3xsynchro-transparent': Specifies the paper having the width of the longer edge (420 mm) of the ISO A3 transparent medium and cuts synchronizing with data. 'iso-a3xsynchro-translucent': Specifies the paper having the width of the longer edge (420 mm) of the ISO A3 translucent medium and cuts synchronizing with data. 'iso-a4xsynchro-white': Specifies the paper having the width of the longer edge (297 mm) of the ISO A4 white medium and cuts synchronizing with data. 'iso-a4xsynchro-transparent': Specifies the paper having the width of the longer edge (297 mm) of the ISO A4 transparent medium and cuts synchronizing with data. 'iso-a4xsynchro-translucent': Specifies the paper having the width of the longer edge (297 mm) of the ISO A4 transparent medium and cuts synchronizing with data. The following standard values are defined for American Standard (i.e. ANSI) engineering media, American Architectural engineering media, and Japanese and European Standard (i.e. ISO) engineering media, Hastings, et al. Standards Track [Page 200] RFC 2911 IPP/1.1: Model and Semantics September 2000 which are either a long fixed size [ASME-Y14.1M] or roll feed, for devices that provide the "synchro-cut" feature and/or the "auto- select" feature (see section 14.1): 'auto-white': Specifies that the printer selects the white medium with the appropriate fixed size (e.g. a1, a2, etc.) or data- synchro size, and the selection is implementation-defined. 'auto-transparent': Specifies that the printer selects the transparent medium with the appropriate fixed size (e.g. a1, a2, etc.) or data-synchro size, and the selection is implementation- defined. 'auto-translucent': Specifies that the printer selects the translucent medium with the appropriate fixed size (e.g. a1, a2, etc.) or data-synchro size, and the selection is implementation- defined. 'auto-fixed-size-white': Specifies that the printer selects the white medium with the appropriate fixed size (e.g. a1, a2, etc.) or the appropriate long fixed size listed above. 'auto-fixed-size-transparent': Specifies that the printer selects the transparent medium with the appropriate fixed size (e.g. a1, a2, etc.) or the appropriate long fixed size listed above. 'auto-fixed-size-translucent': Specifies that the printer selects the translucent medium with the appropriate fixed size (e.g. a1, a2, etc.) or the appropriate long fixed size listed above. 'auto-synchro-white': Specifies that the printer selects the white paper with the appropriate width and cuts it synchronizing with data. 'auto-synchro-transparent': Specifies that the printer selects the transparent paper with the appropriate width and cuts it synchronizing with data. 'auto-synchro-translucent': Specifies that the printer selects the translucent paper with the appropriate width and cuts it synchronizing with data. The following standard values are defined for input-trays (from ISO DPA and the Printer MIB): 'top': The top input tray in the printer. 'middle': The middle input tray in the printer. 'bottom': The bottom input tray in the printer. 'envelope': The envelope input tray in the printer. 'manual': The manual feed input tray in the printer. 'large-capacity': The large capacity input tray in the printer. 'main': The main input tray 'side': The side input tray Hastings, et al. Standards Track [Page 201] RFC 2911 IPP/1.1: Model and Semantics September 2000 The following standard values are defined for media sizes (from ISO DPA): 'iso-a0': Specifies the ISO A0 size: 841 mm by 1189 mm as defined in ISO 216 'iso-a1': Specifies the ISO A1 size: 594 mm by 841 mm as defined in ISO 216 'iso-a2': Specifies the ISO A2 size: 420 mm by 594 mm as defined in ISO 216 'iso-a3': Specifies the ISO A3 size: 297 mm by 420 mm as defined in ISO 216 'iso-a4': Specifies the ISO A4 size: 210 mm by 297 mm as defined in ISO 216 'iso-a5': Specifies the ISO A5 size: 148 mm by 210 mm as defined in ISO 216 'iso-a6': Specifies the ISO A6 size: 105 mm by 148 mm as defined in ISO 216 'iso-a7': Specifies the ISO A7 size: 74 mm by 105 mm as defined in ISO 216 'iso-a8': Specifies the ISO A8 size: 52 mm by 74 mm as defined in ISO 216 'iso-a9': Specifies the ISO A9 size: 37 mm by 52 mm as defined in ISO 216 'iso-a10': Specifies the ISO A10 size: 26 mm by 37 mm as defined in ISO 216 'iso-b0': Specifies the ISO B0 size: 1000 mm by 1414 mm as defined in ISO 216 'iso-b1': Specifies the ISO B1 size: 707 mm by 1000 mm as defined in ISO 216 'iso-b2': Specifies the ISO B2 size: 500 mm by 707 mm as defined in ISO 216 'iso-b3': Specifies the ISO B3 size: 353 mm by 500 mm as defined in ISO 216 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 'iso-b5': Specifies the ISO B5 size: 176 mm by 250 mm as defined in ISO 216 'iso-b6': Specifies the ISO B6 size: 125 mm by 176 mm as defined in ISO 216 'iso-b7': Specifies the ISO B7 size: 88 mm by 125 mm as defined in ISO 216 'iso-b8': Specifies the ISO B8 size: 62 mm by 88 mm as defined in ISO 216 'iso-b9': Specifies the ISO B9 size: 44 mm by 62 mm as defined in ISO 216 'iso-b10': Specifies the ISO B10 size: 31 mm by 44 mm as defined in ISO 216 Hastings, et al. Standards Track [Page 202] RFC 2911 IPP/1.1: Model and Semantics September 2000 'na-letter': Specifies the North American letter size: 8.5 inches by 11 inches 'na-legal': Specifies the North American legal size: 8.5 inches by 14 inches 'na-8x10': Specifies the North American 8 inches by 10 inches 'na-5x7': Specifies the North American 5 inches by 7 inches 'executive': Specifies the executive size (7.25 X 10.5 in) 'folio': Specifies the folio size (8.5 X 13 in) 'invoice': Specifies the invoice size (5.5 X 8.5 in) 'ledger': Specifies the ledger size (11 X 17 in) 'quarto': Specifies the quarto size (8.5 X 10.83 in) 'iso-c3': Specifies the ISO C3 size: 324 mm by 458 mm as defined in ISO 269 'iso-c4': Specifies the ISO C4 size: 229 mm by 324 mm as defined in ISO 269 'iso-c5': Specifies the ISO C5 size: 162 mm by 229 mm as defined in ISO 269 'iso-c6': Specifies the ISO C6 size: 114 mm by 162 mm as defined in ISO 269 'iso-designated-long': Specifies the ISO Designated Long size: 110 mm by 220 mm as defined in ISO 269 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'na-9x12-envelope': Specifies the North American 9x12 size: 9 inches by 12 inches 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches 'na-7x9-envelope': Specifies the North American 7x9 inch envelope size 'na-9x11-envelope': Specifies the North American 9x11 inch envelope size 'na-10x14-envelope': Specifies the North American 10x14 inch envelope size 'na-number-9-envelope': Specifies the North American number 9 business envelope size 'na-6x9-envelope': Specifies the North American 6x9 envelope size 'na-10x15-envelope': Specifies the North American 10x15 envelope size 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'jis-b0': Specifies the JIS B0 size: 1030mm x 1456mm 'jis-b1': Specifies the JIS B1 size: 728mm x 1030mm 'jis-b2': Specifies the JIS B2 size: 515mm x 728mm 'jis-b3': Specifies the JIS B3 size: 364mm x 515mm 'jis-b4': Specifies the JIS B4 size: 257mm x 364mm 'jis-b5': Specifies the JIS B5 size: 182mm x 257mm 'jis-b6': Specifies the JIS B6 size: 128mm x 182mm 'jis-b7': Specifies the JIS B7 size: 91mm x 128mm 'jis-b8': Specifies the JIS B8 size: 64mm x 91mm Hastings, et al. Standards Track [Page 203] RFC 2911 IPP/1.1: Model and Semantics September 2000 'jis-b9': Specifies the JIS B9 size: 45mm x 64mm 'jis-b10': Specifies the JIS B10 size: 32mm x 45mm The following standard values are defined for American Standard (i.e. ANSI) engineering media sizes: 'a': Specifies the engineering ANSI A size medium: 8.5 inches x 11 inches 'b': Specifies the engineering ANSI B size medium: 11 inches x 17 inches 'c': Specifies the engineering ANSI C size medium: 17 inches x 22 inches 'd': Specifies the engineering ANSI D size medium: 22 inches x 34 inches 'e': Specifies the engineering ANSI E size medium: 34 inches x 44 inches The following standard values are defined for American Architectural engineering media sizes: 'arch-a': Specifies the Architectural A size medium: 9 inches x 12 inches 'arch-b': Specifies the Architectural B size medium: 12 inches x 18 inches 'arch-c': Specifies the Architectural C size medium: 18 inches x 24 inches 'arch-d': Specifies the Architectural D size medium: 24 inches x 36 inches 'arch-e': Specifies the Architectural E size medium: 36 inches x 48 inches Hastings, et al. Standards Track [Page 204] RFC 2911 IPP/1.1: Model and Semantics September 2000 14.1. Examples Below are examples to supplement the engineering media value definitions. Example 1: "Synchro-Cut", a device cutting the roll paper in synchronization with the data data height: A1 height data width (shaded): A1 width < data width < (A1 width) x 2 specified value: 'iso-a1xsynchro-white' | | |<--- data width --->| | | | | | | |<- A1 width ->|<- A1 width ->| | | | | cross ^ | | | | feed | +--------------------------------------------/ direction | |//////////////|/////| | ^ / | |//////////////|/////| | | / | |//////////////|/////| | | / | |//////////////|/////| | | \ <-----------+- |//////////////|/////| | A1 \ roll feed | |//////////////|/////| | height \ paper direction |//////////////|/////| | | \ |//////////////|/////| | | / |//////////////|/////| | v / +------------------------------------------/ | | |<------ CUT HERE (to synchronize | with data width) | Hastings, et al. Standards Track [Page 205] RFC 2911 IPP/1.1: Model and Semantics September 2000 Example 2: "Auto-Cut", a device cutting the roll paper at multiples of fixed-size media width data height: A1 height data width (shaded): A1 width < data width < (A1 width) x 2 specified value: 'auto-fixed-size-white' | | |<--- data width --->| | | | | | | |<- A1 width ->|<- A1 width ->| | | | | cross ^ | | | | feed | +--------------------------------------------/ direction | |//////////////|/////| | ^ / | |//////////////|/////| | | / | |//////////////|/////| | | / | |//////////////|/////| | | \ <-----------+- |//////////////|/////| | A1 \ roll feed | |//////////////|/////| | height \ paper direction |//////////////|/////| | | \ |//////////////|/////| | | / |//////////////|/////| | v / +------------------------------------------/ | | |<--- CUT HERE | (to synchronize | with data width) Hastings, et al. Standards Track [Page 206] RFC 2911 IPP/1.1: Model and Semantics September 2000 Example 3: the 'iso-a4x4-white' fixed size paper paper height: A4 height paper width: (A4 width) x 4 specified value: 'iso-a4x4-white' | | | | | |<- A4 width ->|<- A4 width ->|<- A4 width ->|<- A4 width ->| | | | | | | | | | | +-----------------------------------------------------------+ | ^ | | | | | | | | | | | | | | | | | A4 | | | | | height | | | | | | | | | | | | | | | | | | | | | | | v | | | | +-----------------------------------------------------------+ Hastings, et al. Standards Track [Page 207] RFC 2911 IPP/1.1: Model and Semantics September 2000 Example 4: "Synchro-Cut", a device cutting the fixed size paper in synchronization with the data data height: A4 height data width (shaded): (A4 width) x 2 < data width < (A4 width) x 3 specified value: 'iso-a4xsynchro-white' | | |<---------- data width ----------->| | | | | | | | |<- A4 width ->|<- A4 width ->|<- A4 width ->| | | | | | cross ^ | | | | | feed | +--------------------------------------------+ direction | |//////////////|//////////////|/////| ^ | | |//////////////|//////////////|/////| | | | |//////////////|//////////////|/////| | | | |//////////////|//////////////|/////| | | <-----------+- |//////////////|//////////////|/////| A4 | feed | |//////////////|//////////////|/////| height | direction |//////////////|//////////////|/////| | | |//////////////|//////////////|/////| | | |//////////////|//////////////|/////| v | +--------------------------------------------+ | CUT HERE ---->| (to synchronize | with data width) | 15. APPENDIX D: Processing IPP Attributes When submitting a print job to a Printer object, the IPP model allows a client to supply operation and Job Template attributes along with the document data. These Job Template attributes in the create request affect the rendering, production and finishing of the documents in the job. Similar types of instructions may also be contained in the document to be printed, that is, embedded within the print data itself. In addition, the Printer has a set of attributes that describe what rendering and finishing options which are supported by that Printer. This model, which allows for flexibility and power, also introduces the potential that at job submission time, these client-supplied attributes may conflict with either: - what the implementation is capable of realizing (i.e., what the Printer supports), as well as - the instructions embedded within the print data itself. Hastings, et al. Standards Track [Page 208] RFC 2911 IPP/1.1: Model and Semantics September 2000 The following sections describe how these two types of conflicts are handled in the IPP model. 15.1 Fidelity If there is a conflict between what the client requests and what a Printer object supports, the client may request one of two possible conflict handling mechanisms: 1) either reject the job since the job can not be processed exactly as specified, or 2) allow the Printer to make any changes necessary to proceed with processing the Job the best it can. In the first case the client is indicating to the Printer object: "Print the job exactly as specified with no exceptions, and if that can't be done, don't even bother printing the job at all." In the second case, the client is indicating to the Printer object: "It is more important to make sure the job is printed rather than be processed exactly as specified; just make sure the job is printed even if 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 create request, "ipp-attribute-fidelity" is a boolean operation attribute that is OPTIONALLY supplied by the client. The value 'true' indicates that total fidelity to client supplied Job Template attributes and values is required. The client is requesting that the Job be printed exactly as specified, and if that is not possible then the job MUST be rejected rather than processed incorrectly. The value 'false' indicates that a reasonable attempt to print the Job is acceptable. If a Printer does not support some of the client supplied Job Template attributes or values, the Printer MUST ignore them or substitute any supported value for unsupported values, respectively. The Printer may choose to substitute the default value associated with that attribute, or use some other supported value that is similar to the unsupported requested value. For example, if a client supplies a "media" value of 'na-letter', the Printer may choose to substitute 'iso-a4' rather than a default value of 'envelope'. If the client does not supply the "ipp-attribute- fidelity" attribute, the Printer assumes a value of 'false'. Each Printer implementation MUST support both types of "fidelity" printing (that is whether the client supplies a value of 'true' or 'false'): Hastings, et al. Standards Track [Page 209] RFC 2911 IPP/1.1: Model and Semantics September 2000 - If the client supplies 'false' or does not supply the attribute, the Printer object MUST always accept the request by ignoring unsupported Job Template attributes and by substituting unsupported values of supported Job Template attributes with supported values. - If the client supplies 'true', the Printer object MUST reject the request if the client supplies unsupported Job Template attributes. Since a client can always query a Printer to find out exactly what is and is not supported, "ipp-attribute-fidelity" set to 'false' is useful when: 1) The End-User uses a command line interface to request attributes that might not be supported. 2) In a GUI context, if the End User expects the job might be moved to another printer and prefers a sub-optimal result to nothing at all. 3) The End User just wants something reasonable in lieu of nothing at all. 15.2 Page Description Language (PDL) Override If there is a conflict between the value of an IPP Job Template attribute and a corresponding instruction in the document data, the value of the IPP attribute SHOULD take precedence over the document instruction. Consider the case where a previously formatted file of document data is sent to an IPP Printer. In this case, if the client supplies any attributes at job submission time, the client desires that those attributes override the embedded instructions. Consider the case were a previously formatted document has embedded in it commands to load 'iso-a4' media. However, the document is passed to an end user that only has access to a printer with 'na-letter' media loaded. That end user most likely wants to submit that document to an IPP Printer with the "media" Job Template attribute set to 'na- letter'. The job submission attribute should take precedence over the embedded PDL instruction. However, until companies that supply document data interpreters allow a way for external IPP attributes to take precedence over embedded job production instructions, a Printer might not be able to support the semantics that IPP attributes override the embedded instructions. The IPP model accounts for this situation by introducing a "pdl- override-supported" attribute that describes the Printer objects capabilities to override instructions embedded in the PDL data stream. The value of the "pdl-override-supported" attribute is configured by means outside the scope of this IPP/1.1 document. Hastings, et al. Standards Track [Page 210] RFC 2911 IPP/1.1: Model and Semantics September 2000 This REQUIRED Printer attribute takes on the following values: - 'attempted': This value indicates that the Printer object attempts to make the IPP attribute values take precedence over embedded instructions in the document data, however there is no guarantee. - 'not-attempted': This value indicates that the Printer object makes no attempt to make the IPP attribute values take precedence over embedded instructions in the document data. At job processing time, an implementation that supports the value of 'attempted' might do one of several different actions: 1) Generate an output device specific command sequence to realize the feature represented by the IPP attribute value. 2) Parse the document data itself and replace the conflicting embedded instruction with a new embedded instruction that matches the intent of the IPP attribute value. 3) Indicate to the Printer that external supplied attributes take precedence over embedded instructions and then pass the external IPP attribute values to the document data interpreter. 4) Anything else that allows for the semantics that IPP attributes override embedded document data instructions. Since 'attempted' does not offer any type of guarantee, even though a given Printer object might not do a very "good" job of attempting to ensure that IPP attributes take a higher precedence over instructions embedded in the document data, it would still be a conforming implementation. At job processing time, an implementation that supports the value of 'not-attempted' might do one of the following actions: 1) Simply pre-pend the document data with the PDL instruction that corresponds to the client-supplied PDL attribute, such that if the document data also has the same PDL instruction, it will override what the Printer object pre-pended. In other words, this implementation is using the same implementation semantics for the client-supplied IPP attributes as for the Printer object defaults. 2) Parse the document data and replace the conflicting embedded instruction with a new embedded instruction that approximates, but does not match, the semantic intent of the IPP attribute value. Note: The "ipp-attribute-fidelity" attribute applies to the Printer's ability to either accept or reject other unsupported Job Hastings, et al. Standards Track [Page 211] RFC 2911 IPP/1.1: Model and Semantics September 2000 Template attributes. In other words, if "ipp-attribute-fidelity" is set to 'true', a Job is accepted if and only if the client supplied Job Template attributes and values are supported by the Printer. Whether these attributes actually affect the processing of the Job when the document data contains embedded instructions depends on the ability of the Printer to override the instructions embedded in the document data with the semantics of the IPP attributes. If the document data attributes can be overridden ("pdl-override-supported" set to 'attempted'), the Printer makes an attempt to use the IPP attributes when processing the Job. If the document data attributes can not be overridden ("pdl-override-supported" set to 'not- attempted'), the Printer makes no attempt to override the embedded document data instructions with the IPP attributes when processing the Job, and hence, the IPP attributes may fail to affect the Job processing and output when the corresponding instruction is embedded in the document data. 15.3 Using Job Template Attributes During Document Processing. The Printer object uses some of the Job object's Job Template attributes during the processing of the document data associated with that job. These include, but are not limited to, "orientation- 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 or not the document data has already been formatted for printing. If the document data has been formatted, then go to step 2. Otherwise, the document data MUST be formatted. The formatting detection algorithm is implementation defined and is not specified by this document. The formatting of the document data uses the "orientation-requested" attribute to determine how the formatted print data should be placed on a print-stream page, see section 4.2.10 for the details. 2. The document data is in the form of a print-stream in a known media type. The "page-ranges" attribute is used to select, as specified in section 4.2.7, a sub-sequence of the pages in the print-stream that are to be processed and images. 3. The input to this step is a sequence of print-stream pages. This step is controlled by the "number-up" attribute. If the Hastings, et al. Standards Track [Page 212] RFC 2911 IPP/1.1: Model and Semantics September 2000 value of "number-up" is N, then during the processing of the print-stream pages, each N print-stream pages are positioned, as specified in section 4.2.9, to create a single impression. If a given document does not have N more print-stream pages, then the completion of the impression is controlled by the "multiple-document-handling" attribute as described in section 4.2.4; when the value of this attribute is 'single-document' or 'single-document-new-sheet', the print-stream pages of document data from subsequent documents is used to complete the impression. The size(scaling), position(translation) and rotation of the print-stream pages on the impression is implementation defined. Note that during this process the print-stream pages may be rendered to a form suitable for placing on the impression; this rendering is controlled by the values of the "printer- resolution" and "print-quality" attributes as described in sections 4.2.12 and 4.2.13. In the case N=1, the impression is nearly the same as the print-stream page; the differences would only be in the size, position and rotation of the print-stream page and/or any decoration, such as a frame to the page, that is added by the implementation. 4. The collection of impressions is placed, in sequence, onto sides of the media sheets. This placement is controlled by the "sides" attribute and the orientation of the print-stream page, as described in section 4.2.8. The orientation of the print- stream pages affects the orientation of the impression; for example, if "number-up" equals 2, then, typically, two portrait print-stream pages become one landscape impression. Note that the placement of impressions onto media sheets is also controlled by the "multiple-document-handling" attribute as described in section 4.2.4. 5. The "copies" and "multiple-document-handling" attributes are used to determine how many copies of each media instance are created and in what order. See sections 4.2.5 and 4.2.4 for the details. 6. When the correct number of copies are created, the media instances are finished according to the values of the "finishings" attribute as described in 4.2.6. Note that sometimes finishing operations may require manual intervention to perform the finishing operations on the copies, especially uncollated copies. This document allows any or all of the processing steps to be performed automatically or manually at the discretion of the Printer object. Hastings, et al. Standards Track [Page 213] RFC 2911 IPP/1.1: Model and Semantics September 2000 16. APPENDIX E: Generic Directory Schema This section defines a generic schema for an entry in a directory service. A directory service is a means by which service users can locate service providers. In IPP environments, this means that IPP Printers can be registered (either automatically or with the help of an administrator) as entries of type printer in the directory using an implementation specific mechanism such as entry attributes, entry type fields, specific branches, etc. 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 administrator can place limits on end users so that they are only allowed to find entries to which they have certain access rights. IPP itself does not require any specific directory service protocol or provider. Note: Some directory implementations allow for the notion of "aliasing". That is, one directory entry object can appear as multiple directory entry object with different names for each object. In each case, each alias refers to the same directory entry object which refers to a single IPP Printer object. The generic schema is a subset of IPP Printer Job Template and Printer Description attributes (sections 4.2 and 4.4). These attributes are identified as either RECOMMENDED or OPTIONAL for the directory entry itself. This conformance labeling is NOT the same conformance labeling applied to the attributes of IPP Printers objects. The conformance labeling in this Appendix is intended to apply to directory templates and to IPP Printer implementations that subscribe by adding one or more entries to a directory. RECOMMENDED attributes SHOULD be associated with each directory entry. OPTIONAL attributes MAY be associated with the directory entry (if known or supported). In addition, all directory entry attributes SHOULD reflect the current attribute values for the corresponding Printer object. The names of attributes in directory schema and entries SHOULD be the same as the IPP Printer attribute names as shown, as much as possible. In order to bridge between the directory service and the IPP Printer object, one of the RECOMMENDED directory entry attributes is the Printer object's "printer-uri-supported" attribute. The directory client queries the "printer-uri-supported" attribute (or its equivalent) in the directory entry and then the IPP client addresses Hastings, et al. Standards Track [Page 214] RFC 2911 IPP/1.1: Model and Semantics September 2000 the IPP Printer object using one of its URIs. The "uri-security- supported" attribute identifies the protocol (if any) used to secure a channel. The following attributes define the generic schema for directory entries of type PRINTER: printer-uri-supported RECOMMENDED Section 4.4.1 uri-authentication-supported RECOMMENDED Section 4.4.2 uri-security-supported RECOMMENDED Section 4.4.3 printer-name RECOMMENDED Section 4.4.4 printer-location RECOMMENDED Section 4.4.5 printer-info OPTIONAL Section 4.4.6 printer-more-info OPTIONAL Section 4.4.7 printer-make-and-model RECOMMENDED Section 4.4.9 ipp-versions-supported RECOMMENDED Section 4.4.14 multiple-document-jobs-supported OPTIONAL Section 4.4.16 charset-supported OPTIONAL Section 4.4.18 generated-natural-language- supported OPTIONAL Section 4.4.20 document-format-supported RECOMMENDED Section 4.4.22 color-supported RECOMMENDED Section 4.4.26 compression-supported RECOMMENDED Section 4.4.32 pages-per-minute OPTIONAL Section 4.4.36 pages-per-minute-color OPTIONAL Section 4.4.37 finishings-supported OPTIONAL Section 4.2.6 number-up-supported OPTIONAL Section 4.2.7 sides-supported RECOMMENDED Section 4.2.8 media-supported RECOMMENDED Section 4.2.11 printer-resolution-supported OPTIONAL Section 4.2.12 print-quality-supported OPTIONAL Section 4.2.13 17. APPENDIX F: Differences between the IPP/1.0 and IPP/1.1 "Model and Semantics" Documents This Appendix is divided into two lists that summarize the differences between IPP/1.1 (this document) and IPP/1.0 [RFC2566]. The section numbers refer to the numbers in this document which in some cases have changed from RFC 2566. When a change affects multiple sections, the item is listed once in the order of the first section affected and the remaining affected section numbers are indicated. Hastings, et al. Standards Track [Page 215] RFC 2911 IPP/1.1: Model and Semantics September 2000 The first list contains extensions and clarifications and the second list contains changes in semantics or conformance. However, client and IPP object implementations of IPP/1.0 MAY implement any of the extensions and clarifications in this document. The following extensions and clarifications have been incorporated into this document: 1. Section 2.1 - clarified that the term "client" can be either contained in software controlled by an end user or a part of a print server that controls devices. 2. Section 2 - clarified that the term "IPP object" and "Printer object" can either be embedded in a device object or part of a print server that accepts IPP requests. 3. Section 2.4 - added the description of the new "uri- authentication-supported" Printer Description attribute. 4. Section 3.1.3, 3.1.6, 3.2.5.2, and 3.2.6.2 - clarified the error handling for operation attributes that have their own status code. 5. Section 3.1.3 - clarified that multiple occurrences of the same attribute in an attribute group is mal-formed. An IPP Printer MAY reject the request or choose one of the attributes. 6. Section 3.1.6 - reorganized this section into sub-sections to separately describe "status-code", "status-message", "detailed-status-message", and "document-access-error" attributes. 7. Section 3.1.6.1 - clarified the error status codes and their relationship to operation attributes. 8. Section 3.1.6.3 - Added the OPTIONAL "detailed-status-message (text(MAX))" operation attribute to provide additional more detailed information about a response. 9. Section 3.1.6.4 and 3.2.2 - Added the OPTIONAL "document- access-error (text(MAX))" operation attribute for use with Print-URI and Send-URI responses. 10. Sections 3.1.7 - Added this new section to clarify returning Unsupported Attributes for all operations, including only returning attributes that were in the request. Moved the text from section 3.2.1.2 Unsupported Attributes to this section. 11. Sections 3.1.7 and 4.1 - clarified the encoding of the "out- of-band" 'unsupported' and 'unknown' values. 12. Section 3.1.8 - clarified that only the version number parameter will be carried forward into future major or minor versions of the protocol. 13. Section 3.1.8 - relaxed the requirements to increment the major version number in future versions of the Model and Semantics document. Hastings, et al. Standards Track [Page 216] RFC 2911 IPP/1.1: Model and Semantics September 2000 14. Section 3.1.9, and 3.2.5 - added the 'processing' state to the list of job states that a job can be in after a Create-Job operation. 15. Section 3.1.9 - clarified that a non-spooling Printer MAY accept zero or more subsequent jobs while processing a job and flow control them down. Subsequent create requests are rejected with the 'server-error-busy' error status. 16. Section 3.2.1.1 - clarified the validation of the "compression" operation attribute and its relationship to the validation of the "document-format" attribute and returning Unsupported Attributes. 17. Sections 3.2.1.1, 4.3.8, 13.1.4.16, and 13.1.4.17 - added the 'client-error-compression-not-supported', 'client-error- compression-error' status codes and the 'unsupported- compression' and 'compression-error' job-state-reasons. 18. Sections 3.2.1.1 and 4.3.8 - added 'unsupported-document- format' and 'document-format-error' job-state-reasons. 19. Sections 3.2.2, 4.3.8 and 13.1.4.19 - added 'client-error- document-access-error' status code and 'document-access-error' job state reason. 20. Section 3.2.5.2 and 3.2.6.2 - clarified that the Unsupported Attributes group MUST NOT include attributes not requested in the Get-Printer-Attributes request. 21. Section 3.2.6 - clarified that "limit" takes precedence over "which-jobs" and "my-jobs'. 22. Section 3.2.6.2 - clarified that Get-Jobs returns 'successful-ok' when no jobs to return. 23. Sections 3.2.7, 3.2.8, and 3.2.9 - added the OPTIONAL Pause- Printer, Resume-Printer, and Purge-Jobs operations 24. Section 3.3.1 - clarified that the authorization required for a Send-Document request MUST be the same user as the Create- Job or an operator. 25. Section 3.3.1.1 - clarified that a Create-Job Send-Document with "last-document" = 'true' and no data is not an error; its a job with no documents. 26. Sections 3.3.5, 3.3.6, and 3.3.7 - added the OPTIONAL Hold- Job, Release-Job, and Restart-Job operations. Clarified the Restart-Job operation so that the Printer MUST re-fetch any documents passed by-reference (Print-URI or Send-URI). 27. Section 4.1 - clarified that the encoding of the out-of-band values are specified in the Encoding and Transport" document. 28. Section 4.1 - Clarified that the requirement that clients MUST NOT send "out-of-band" values in requests applies only to operations defined in this document. Other operations are allowed to define "out-of-band" values that clients can supply. Hastings, et al. Standards Track [Page 217] RFC 2911 IPP/1.1: Model and Semantics September 2000 29. Sections 4.1.1 and 4.1.2 - clarified that the maximum 'text' and 'name' values of 1023 and 255 are for the 'textWithoutLanguage' portion of the 'textWithLanguage' form, so that the maximum number of octets for the actual text and name data is the same for the without and with language forms; the 'naturalLanguage' part is in addition. 30. Section 4.1.9 - clarified that 'mimeMediaType' values can include any parameters from the IANA Registry, not just charset parameters. 31. Section 4.1.9.1 - clarified that 'application/octet-stream' auto-sensing can happen at create request time and/or job/document processing time. 32. Section 4.1.9.1 - clarified that auto-sensing involves the Printer examining some number of octets of document data using an implementation-dependent method. 33. Section 4.1.14 - clarified that the localization of dateTime by the client includes the time zone. 34. Section 4.2 - clarified that xxx-supported have multiple keywords and/or names by adding parentheses to the table to give: (1setOf (type3 keyword | name)) 35. Section 4.2.2 - added the 'indefinite' keyword value to the "job-hold-until" attribute for use with the create operations and Hold-Job and Restart-Job operations. 36. Section 4.2.6 - added more enum values to the "finishings" Job Template attribute. 37. Section 4.2.6 - clarified that the landscape definition is a rotation of the image with respect to the medium. 38. Section 4.3.7 - added that a forwarding server that cannot get any job state MAY return the job's state as 'completed', provided that it also return the new 'queued-in-device' job state reason. 39. Section 4.3.7.2 - added the Partitioning of Job States section to clarify the concepts of Job Retention, Job History, and Job Removal. 40. Section 4.3.8 - added 'job-data-insufficient' job state reason to indicate whether sufficient data has arrived for the document to start to be processed. 41. Section 4.3.8 - added 'document-access-error' job state reason to indicate an access error of any kind. 42. Section 4.3.8 - added 'job-queued-for-marker' job state reason to indicate whether the job has completed some processing and is waiting for the marker. 43. Section 4.3.8 - added 'unsupported-compression' and 'compression-error' job state reasons to indicate compression not supported or compression processing error after the create has been accepted. Hastings, et al. Standards Track [Page 218] RFC 2911 IPP/1.1: Model and Semantics September 2000 44. Section 4.3.8 - added 'unsupported-document-format' and 'document-format-error' job state reasons to indicate document not supported or document format processing error after the create has been accepted. 45. Section 4.3.8 - added 'queued-in-device' job state reason to indicate that a job as been forwarded to a print system or device that does not provide any job status. 46. Section 4.3.10 - added "job-detailed-status-messages (1setOf text(MAX)) for returning detailed error messages. 47. Section 4.3.11 - added the "job-document-access-errors (1setOf text(MAX)) 48. Section 4.3.14.2 - clarified that the time recorded is the first time processing since the create operation or the Restart-Job operation. 49. Section 4.3.14.2 and 4.3.14.3 - clarified that the out-of-band value 'no-value' is returned if the job has not started processing or has not completed, respectively. 50. Section 4.3.14 - Added the OPTIONAL "date-time-at-creation", "date-time-at-processing", and "date-time-at-completed" Event Time Job Description attributes 51. Section 4.4.3 - added the 'tls' value to "uri-security- supported" attribute. 52. Section 4.4.3 - clarified "uri-security-supported" is orthogonal to Client Authentication so that 'none' does not exclude Client Authentication. 53. Section 4.4.11 - simplified the "printer-state" descriptions while generalizing to allow high end devices that interpret one or more jobs while marking another. Indicated that 'spool-area-full' and 'stopped-partly' "printer-state-reasons" may be used to provide further state information. 54. Section 4.4.12 - added the 'moving-to-paused' keyword value to the "printer-state-reasons" attribute for use with the Pause- Printer operation. 55. Section 4.4.12 - replaced the duplicate 'marker-supply-low' keyword with the missing 'toner-empty' keyword for the "printer-state-reasons" attribute. (This correction was also made before RFC 2566 was published). 56. Section 4.4.12 - clarified 'spool-area-full' "printer-state- reasons" to include non-spooling printers to indicate when it can and cannot accept another job. 57. Section 4.4.15 - added the enum values to the "operations- supported" attribute for the new operations. Clarified that the values of this attribute are encoded as any enum, namely 32-bit values. 58. Section 4.4.30 - clarified that the dateTime value of "printer-current-time" is on a "best efforts basis". If a proper date-time cannot be obtained, the implementation returns the 'no-value' out-of-band value. Also clarified that Hastings, et al. Standards Track [Page 219] RFC 2911 IPP/1.1: Model and Semantics September 2000 the time zone NEED NOT be the time zone that the people near the device use and that the client SHOULD display the dateTime attributes in the user's local time. 59. Sections 4.4.36 and 4.4.37 - added the OPTIONAL "pages-per- minute" and "pages-per-minute-color" Printer Description attributes. 60. Section 5.1 - clarified that the client conformance requirements apply to clients controlled by an end user and clients in servers. 61. Section 5.1 - clarified that any response MAY contain additional attribute groups, attributes, attribute syntaxes, or attribute values. 62. Section 5.1 - clarified that a client SHOULD do its best to prevent a channel from being closed by a lower layer when the channel is flow controlled off by the IPP Printer. 63. Section 5.2 - clarified that the IPP object requirements apply to objects embedded in devices or that are parts of servers. 64. Section 5.2.2 - clarified that IPP objects MAY return operation responses that contain attribute groups, attribute names, attribute syntaxes, attribute values, and status codes that are extensions to this standard. 65. Section 6 - changed the terminology of "private extensions" to "vendor extensions" and indicated that they are registered with IANA along with IETF standards track extensions. 66. Section 6.7 - inserted this section on registering out-of-band attribute values with IANA as extensions. 67. Section 8.3 - clarified the use of URIs for each Client Authentication mechanism. 68. Section 8.5 - added the security discussion around the new operator/administrator operations. 69. Section 13.1.4.16 - added client-error-compression-not- supported (0x040F) 70. Section 13.1.4.17 - added client-error-compression-error (0x0410) 71. Section 13.1.4.18 - added client-error-document-format-error (0x0411) 72. Section 13.1.4.19 - added client-error-document-access-error (0x0412) 73. Section 13.1.5.10 - added server-error-multiple-document- jobs-not-supported (0x0509) 74. Section 14 - added 'a-white', 'b-white', 'c-white', 'd-white', and 'e-white' and clarified that the existing 'a', 'b', 'c', 'd', and 'e' values are size values. Added American, Japanese, and European Engineering sizes, filled out -transparent and - translucent media names and drawings for the synchro cut sizes. Hastings, et al. Standards Track [Page 220] RFC 2911 IPP/1.1: Model and Semantics September 2000 75. Section 16 - softened the RECOMMENDATION for IPP Printer attributes in a Directory schema so that they can have equivalents. 76. Section 16 - added the OPTIONAL "pages-per-minute" and "pages-per-minute-color" Printer attributes to the Directory schema. 77. Section 16 - added OPTIONAL "multiple-document-jobs-supported" to the Directory schema. 78. Section 16 - added RECOMMENDED "uri-authentication-supported", "ipp-versions-supported", and "compression-supported" to the Directory schema. The following changes in semantics and/or conformance have been incorporated into this document: 1. Section 3.1.6.3 - allowed a Printer to localize the "detailed-status-message" operation response attribute, but indicated that such localization might obscure the technical meaning of such messages. 2. Section 3.1.8, 5.2.4, and 13.1.5.4 - Clients and IPP objects MUST support version 1.1 conformance requirements. It is recommended that they interoperate with 1.0. Also clarified that IPP Printers MUST accept '1.1' requests. It is recommended that they also accept '1.x' requests. 3. Section 3.2.1.1 and section 4.4.32 - changed the "compression" operation and the "compression-supported" Printer Description attribute from OPTIONAL to REQUIRED. 4. Sections 3.2.1.2 and 4.3.8 - changed "job-state-reasons" from RECOMMENDED to REQUIRED, so that "job-state-reasons" MUST be returned in create operation responses. 5. Sections 3.2.4, 3.3.1, 4.4.16, and 16 - changed Create- Job/Send-Document so that they MAY be implemented while only supporting one document jobs. Added the "multiple-document- jobs-supported" boolean Printer Description attribute to indicate whether Create-Job/Send-Document support multiple document jobs or not. Added to the Directory schema. 6. Section 4.1.9 - deleted 'text/plain; charset=iso-10646-ucs-2', since binary is not legal with the 'text' type. 7. Section 4.1.9.1 - added the RECOMMENDATION that a Printer indicate by printing on the job's job-start-sheet that auto- sensing has occurred and what document format was auto-sensed. 8. Section 4.2.4 - indicated that the "multiple-document- handling" Job Template attribute MUST be supported with at least one value if the Printer supports multiple documents per job Hastings, et al. Standards Track [Page 221] RFC 2911 IPP/1.1: Model and Semantics September 2000 9. Section 4.3.7.2 - indicated that the 'job-restartable' job state reason SHOULD be supported if the Restart-Job operation is supported. 10. Section 4.3.8 - changed "job-state-reasons" from RECOMMENDED to REQUIRED. 11. Section 4.3.8 - clarified the conformance of the values of the "job-state-reasons" attribute by copying conformance requirements from other sections of the document so that it is clear from reading the definition of "job-state-reasons" which values MUST or SHOULD be supported. The 'none', 'unsupported-compression', and 'unsupported-document-format' values MUST be supported. The 'job-hold-until-specified' SHOULD be specified if the "job-hold-until" Job Template is supported. The following values SHOULD be supported: 'job- canceled-by-user', 'aborted-by-system', and 'job-completed- successfully'. The 'job-canceled-by-operator' SHOULD be supported if the implementation permits canceling by other than the job owner. The 'job-canceled-at-device' SHOULD be supported if the device supports canceling jobs at the console. The 'job-completed- with-warnings' SHOULD be supported, if the implementation detects warnings. The 'job-completed-with-errors' SHOULD be supported if the implementation detects errors. The 'job- restartable' SHOULD be supported if the Restart-Job operation is supported. 12. Section 4.3.10 - allowed a Printer to localize the "job- detailed-status-message" Job Description attribute, but indicated that such localization might obscure the technical meaning of such messages. 13. Section 4.3.14 - changed the "time-at-creation", "time-at- processing", and "time-at-completed" Event Time Job Description attributes from OPTIONAL to REQUIRED. 14. Section 4.3.14.4 - added the REQUIRED "job-printer-up-time (integer(1:MAX))" Job Description attribute as an alias for "printer-up-time" to reduce number of operations to get job times. 15. Section 4.4.2 - added the REQUIRED "uri-authentication- supported (1setOf type2 keyword)" Printer Description attribute to describe the Client Authentication used by each Printer URI. 16. Section 4.4.12 - changed "printer-state-reasons" Printer Description attribute from OPTIONAL to REQUIRED. 17. Section 4.4.12 - changed 'paused' value of "printer-state- reasons" to MUST if Pause-Printer operation is supported. Hastings, et al. Standards Track [Page 222] RFC 2911 IPP/1.1: Model and Semantics September 2000 18. Section 4.4.14 - added the REQUIRED "ipp-versions-supported (1setOf keyword)" Printer Description attribute, since IPP/1.1 Printers do not have to support version '1.0' conformance requirements. Section 4.4.16 - added the "multiple-document- jobs-supported (boolean)" Printer Description attribute so that a client can tell whether a Printer that supports Create-Job/Send-Document supports multiple document jobs or not. This attribute is REQUIRED if the Create-Job operation is supported. 19. Section 4.4.24 - changed the "queued-job-count" Printer Description attribute from RECOMMENDED to REQUIRED. 20. Section 4.4.32 - changed "compression-supported (1setOf type3 keyword)" Printer Description attribute from OPTIONAL to REQUIRED. 21. Section 5.1 - changed the client security requirements from RECOMMENDED non-standards track SSL3 to MUST support Client Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. A client SHOULD support Operation Privacy and Server Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. 22. Section 5.2.7 - changed the IPP object security requirements from OPTIONAL non-standards track SSL3 to SHOULD contain support for Client Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. A Printer implementation MAY allow an administrator to configure the Printer so that all, some, or none of the users are authenticated. An IPP Printer implementation SHOULD contain support for Operation Privacy and Server Authentication as defined in the IPP/1.1 Encoding and Transport document [RFC2910]. A Printer implementation MAY allow an administrator to configure the degree of support for Operation Privacy and Server Authentication. Security MUST NOT be compromised when the client supplies a lower version-number in a request. 23. Section 14 (Appendix C): Corrected typo, changing the keyword 'iso-10-white' to 'iso-a10-white'. See also the "IPP/1.1 Encoding and Transport" [RFC2910] document for differences between IPP/1.0 [RFC2565] and IPP/1.1 [RFC2910]. Hastings, et al. Standards Track [Page 223] RFC 2911 IPP/1.1: Model and Semantics September 2000 18. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Hastings, et al. Standards Track [Page 224]