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 'iso-a4-colored': Specifies the ISO A4 colored medium 'iso-a4-transparent' Specifies the ISO A4 transparent medium 'iso-a3-white': Specifies the ISO A3 white medium 'iso-a3-colored': Specifies the ISO A3 colored medium 'iso-a5-white': Specifies the ISO A5 white medium 'iso-a5-colored': Specifies the ISO A5 colored medium 'iso-b4-white': Specifies the ISO B4 white medium 'iso-b4-colored': Specifies the ISO B4 colored medium 'iso-b5-white': Specifies the ISO B5 white medium 'iso-b5-colored': Specifies the ISO B5 colored medium 'jis-b4-white': Specifies the JIS B4 white medium 'jis-b4-colored': Specifies the JIS B4 colored medium 'jis-b5-white': Specifies the JIS B5 white medium 'jis-b5-colored': Specifies the JIS B5 colored medium 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 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 (white-only): '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 'iso-a1-white': Specifies the ISO A1 white medium 'iso-a2-white': Specifies the ISO A2 white medium 'iso-a6-white': Specifies the ISO A6 white medium 'iso-a7-white': Specifies the ISO A7 white medium 'iso-a8-white': Specifies the ISO A8 white medium 'iso-a9-white': Specifies the ISO A9 white medium 'iso-10-white': Specifies the ISO A10 white medium 'iso-b0-white': Specifies the ISO B0 white medium 'iso-b1-white': Specifies the ISO B1 white medium 'iso-b2-white': Specifies the ISO B2 white medium 'iso-b3-white': Specifies the ISO B3 white medium 'iso-b6-white': Specifies the ISO B6 white medium 'iso-b7-white': Specifies the ISO B7 white medium 'iso-b8-white': Specifies the ISO B8 white medium 'iso-b9-white': Specifies the ISO B9 white medium 'iso-b10-white': Specifies the ISO B10 white medium 'jis-b0-white': Specifies the JIS B0 white medium 'jis-b1-white': Specifies the JIS B1 white medium 'jis-b2-white': Specifies the JIS B2 white medium 'jis-b3-white': Specifies the JIS B3 white medium 'jis-b6-white': Specifies the JIS B6 white medium 'jis-b7-white': Specifies the JIS B7 white medium
'jis-b8-white': Specifies the JIS B8 white medium 'jis-b9-white': Specifies the JIS B9 white medium 'jis-b10-white': Specifies the JIS B10 white medium The following standard values are defined for engineering media: 'a': Specifies the engineering A size medium 'b': Specifies the engineering B size medium 'c': Specifies the engineering C size medium 'd': Specifies the engineering D size medium 'e': Specifies the engineering E size medium 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 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 '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 '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 'jis-b9': Specifies the JIS B9 size: 45mm x 64mm 'jis-b10': Specifies the JIS B10 size: 32mm x 45mm
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. 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 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'): - 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 IPP/1.0. 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 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", "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. 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 specification. 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 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 specification allows any or all of the processing steps to be performed automatically or manually at the discretion of the Printer object.
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. IPP 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. 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 IPP client queries the "printer-uri-supported" attribute in the directory entry
and then addresses 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-security-supported RECOMMENDED Section 4.4.2 printer-name RECOMMENDED Section 4.4.3 printer-location RECOMMENDED Section 4.4.4 printer-info OPTIONAL Section 4.4.5 printer-more-info OPTIONAL Section 4.4.6 printer-make-and-model RECOMMENDED Section 4.4.8 charset-supported OPTIONAL Section 4.4.15 generated-natural-language- supported OPTIONAL Section 4.4.17 document-format-supported RECOMMENDED Section 4.4.19 color-supported RECOMMENDED Section 4.4.23 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: Change History for the IPP Model and Semantics document The following substantive changes and major clarifications have been made to this document from the June 30, 1998 version based on the interoperability testing that took place September 23-25 1998 and subsequent mailing list and meeting discussions. They are listed in the order of occurrence in the document. These changes are the ones that might affect implementations. Clarifications that are unlikely to affect implementations are not listed. The issue numbers refer to the IPP Issues List which is available in the following directory: ftp://ftp.pwg.org/pub/pwg/ipp/approved-clarifications/ Section Description global Replaced TLS references with SSL3 references as agreed with our Area Director on 11/12/1998. global Removed the indications that some of these IPP documents are informational, since the intent is now to publish all IPP/1.0 documents as informational as agreed with our Area Director on 11/12/1998. 3.1.2, Clarify that the IPP object SHOULD NOT validate the 16.3.3 range of the request-id being 1 to 2**31-1, but accepts [now ipp- and returns any value. Clients MUST still keep in the iig] range 1 to 2**31 though. If the request is terminated before the complete "request-id" is received, the IPP object rejects the request and returns a response with a "request-id" of 0 (Issue 1.36). 126.96.36.199, Clarified that when a client submits a request in a 188.8.131.52 charset that is not supported, the IPP object SHOULD return any 'text' or 'name' attributes in the 'utf-8' charset, if it returns any, since clients and IPP objects MUST support 'utf-8'. (Issue 1.19) 184.108.40.206 Clarified Section 220.127.116.11 Request Operation Attributes that a client MAY use the attribute level natural language override (text/nameWithLanguage) redundantly in a request. (Issue 1.46) 18.104.22.168 Clarified Section 22.214.171.124 Response Operation Attributes that an IPP object MAY use the attribute level natural language override (text/nameWithLanguage) redundantly in a response. (Issue 1.46)
3.1.6 Clarified section 3.1.6: If the Printer object supports the "status-message" operation attribute, it NEED NOT return a status message for the following error status codes: 'client-error-bad-request', 'client-error- charset-not-supported', 'server-error-internal-error', 'server-error-operation-not-supported', and 'server- error-version-not-supported'. 126.96.36.199 Clarified that if a client is not supplying any Job Template attributes in a request, the client SHOULD omit Group 2 rather than sending an empty group. However, a Printer object MUST be able to accept an empty group. This makes [RFC2566] agree with [RFC2565]. (Issue 1.16) 188.8.131.52, Clarified that if an IPP object is not returning any 184.108.40.206, Unsupported Attributes in a response, the IPP object 220.127.116.11, SHOULD omit Group 2 rather than sending an empty group. 18.104.22.168, However, a client MUST be able to accept an empty group. 22.214.171.124, This makes [RFC2566] agree with [RFC2565]. (Issue 1.17) 126.96.36.199 188.8.131.52, Clarified that an IPP object MUST treat an unsupported 184.108.40.206, attribute syntax supplied in a request in the same way 220.127.116.11 as an unsupported value. The IPP object MUST return the attribute, the attribute syntax, and the value in the Unsupported Attributes group. (Issue 1.26) 18.104.22.168, Clarified for Get-Printer-Attributes, Get-Jobs, and Get- 22.214.171.124, Job-Attributes that an IPP object MUST return 126.96.36.199, 'successful-ok-ignored-or-substituted-attributes' (0x1), 188.8.131.52, rather than 'successful-ok' (0x0), when a client 184.108.40.206, supplies unsupported attributes as values of the 220.127.116.11 'requested-attributes' operation attribute. (Issue 1.24) Also clarified that the response NEED NOT contain the "requested-attributes" operation attribute with any supplied values (attribute keywords) that were requested by the client but are not supported by the IPP object. (Issue 1.18) 18.104.22.168 Deleted the job-level natural language override (NLO) 22.214.171.124 from Section 126.96.36.199 Get-Jobs Response so that all 4.3.24 operation responses are the same with respect to NLO. (Issue 1.47)
3.3.1 Clarified that an IPP Printer that supports the Create- Job operation MUST handle the situation when a client does not supply Send-Document or Send-URI operations within a one- to four-minute time period. Also clarified that a client MUST send documents in a multi- document job without undue or unbounded delay. (Issue 1.28) 3.3.3 Clarified that the IPP object MUST reject a Cancel-Job request if the job is in 'completed', 'canceled', or 'aborted' job states. (Issue 1.12) 188.8.131.52 Added this new sub-section: it specifies that nameWithoutLanguage plus the implicit natural language matches nameWithLanguage, if the values and natural languages are the same. Also added that keyword never matches nameWithLanguage or nameWithoutLanguage. Clarified that if both have countries, that the countries SHOULD match as well. If either do not, then the country field SHOULD be ignored. (Issues 1.33 and 1.34) 4.1.5 Clarified regarding the case-insensitivity of URLs to refer only to the RFCs that define them. (Issue 1.10) 4.1.11 Clarified that 'boolean' is not a full-sized integer. (Issue 1.38) 4.1.15 Clarified that 'resolution' is not three full-sized integers. (Issue 1.20) 4.2.* Clarified that standard values are keywords or enums, not names. (Issue 1.49). 4.2.4 Added the 'single-document-new-sheet' value to Section 4.2.4 multiple-document-handling. (Issue 1.54) 4.4.18, Clarified that the "document-format-default" and 4.4.19 "document-format-supported" Printer Description attributes are REQUIRED to agree with the table. (Issue 1.4) 4.4.21 Changed "queued-job-count" from OPTIONAL to RECOMMENDED. (Issue 1.14)
4.4.28 Clarified that the implementation supplied value for the "multiple-operation-time-out" attribute SHOULD be between 30 and 240 seconds, though the implementation MAY allow the administrator to set values, and MAY allow values outside this range. (Issue 1.28) 5.1, Clarified Client Conformance that if a client supports 5.2.5 an attribute of 'text' attribute syntax, that it MUST support both the textWithoutLanguage and the textWithLanguage forms. Same for 'name' attribute syntax. Same for an IPP object (Issue 1.48) 6.5, Added new section to allow Attribute Groups to be 12.8 registered as extensions for being passed in operation requests and responses. (Issue 1.25) 7. Updated the table of text and name attributes to agree with Section 4.2. 8.5 Added a new section RECOMMENDING that the Get-Jobs SHOULD return non-IPP jobs whether or not assigning them a job-id and job-uri. Also RECOMMENDED generating, if possible, job-id and job-uri and supporting other IPP operations on foreign jobs as an implementer option. (Issue 1.32) 9. Updated document references. 184.108.40.206 Clarified 'client-error-charset-not-supported' that 'utf-8' must be used for any 'text' or 'name' attributes returned in the error response (Issue 1.19). 220.127.116.11 Added a new error code 'server-error-job-canceled' (0x0508) to be returned if a job is canceled by another client or aborted by the IPP object while the first client is still sending the document data. (Issue 1.29) 15.3, Moved these sections recommending operation processing 15.4 steps to the new Implementer's Guide (informational). There indicated that all of the error checks are not required, so an IPP object MAY be forgiving and accept non-conforming requests. However, a conforming client MUST supply requests that would pass all of the error checks indicated. (Issue 1.21)
16 Changed directory schema attributes from REQUIRED to RECOMMENDED. Changed some of the OPTIONAL to RECOMMENDED to agree with the SLP template. Changed the "charset-supported" and "natural-language-supported" from REQUIRED to OPTIONAL. Recommended that the names be the same in a directory entry as the IPP attribute names. (Issue 1.53)
18. Full Copyright Statement Copyright (C) The Internet Society (1999). 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.