| < draft-ietf-ipp-implementers-guide-v11-01.txt | draft-ietf-ipp-implementers-guide-v11-02.txt > | |||
|---|---|---|---|---|
| INTERNET-DRAFT | INTERNET-DRAFT | |||
| draft-ietf-ipp-implementers-guide-v11-01.txt | draft-ietf-ipp-implementers-guide-v11-02.txt | |||
| T. Hastings | [Obsoletes RFC 2639] T. Hastings | |||
| Xerox Corporation | Xerox Corporation | |||
| C. Manros | C. Manros | |||
| Xerox Corporation | Xerox Corporation | |||
| C. Kugler | C. Kugler | |||
| IBM Printing Systems Co | IBM Printing Systems Co | |||
| H. Holst | H. Holst | |||
| i-data Printing Systems | i-data Printing Systems | |||
| P. Zehler | P. Zehler | |||
| Xerox Corporation | Xerox Corporation | |||
| May 30, 2000 | January 25, 2001 | |||
| Internet Printing Protocol/1.1: Implementer's Guide | Internet Printing Protocol/1.1: Implementer's Guide | |||
| Copyright (C) The Internet Society (2000). All Rights Reserved. | Copyright (C) The Internet Society (2001). All Rights Reserved. | |||
| Status of this Memo | Status of this Memo | |||
| This document is an Internet-Draft and is in full conformance with all | This document is an Internet-Draft and is in full conformance with | |||
| provisions of Section 10 of [RFC2026]. Internet-Drafts are working | all provisions of Section 10 of [RFC2026]. Internet-Drafts are | |||
| documents of the Internet Engineering Task Force (IETF), its areas, and | working documents of the Internet Engineering Task Force (IETF), its | |||
| its working groups. Note that other groups may also distribute working | areas, and its working groups. Note that other groups may also | |||
| documents as Internet-Drafts. | distribute working documents as Internet-Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference material | time. It is inappropriate to use Internet-Drafts as reference | |||
| or to cite them other than as "work in progress". | material or to cite them other than as "work in progress". | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
| The list of Internet-Draft Shadow Directories can be accessed as | The list of Internet-Draft Shadow Directories can be accessed as | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| Abstract | Abstract | |||
| This document is one of a set of documents, which together describe | ||||
| all aspects of a new Internet Printing Protocol (IPP). IPP is an | ||||
| application level protocol that can be used for distributed printing | ||||
| using Internet tools and technologies. This document contains | ||||
| information that supplements the IPP Model and Semantics [RFC2911] | ||||
| and the IPP Transport and Encoding [RFC2910] documents. It is | ||||
| intended to help implementers understand IPP/1.1, as well as IPP/1.0, | ||||
| and some of the considerations that may assist them in the design of | ||||
| their client and/or IPP object implementations. For example, a | ||||
| typical order of processing requests is given, including error | ||||
| checking. Motivation for some of the specification decisions is also | ||||
| included. | ||||
| This document is one of a set of documents, which together describe all | This document obsoletes RFC 2639 which was the Implementer's Guide | |||
| aspects of a new Internet Printing Protocol (IPP). IPP is an | for IPP/1.0. | |||
| application level protocol that can be used for distributed printing | ||||
| using Internet tools and technologies. This document contains | ||||
| information that supplements the IPP Model and Semantics [IPP-MOD] and | ||||
| the IPP Transport and Encoding [IPP-PRO] documents. It is intended to | ||||
| Expires November 30, 2000 | ||||
| help implementers understand IPP/1.1, as well as IPP/1.0, and some of | ||||
| the considerations that may assist them in the design of their client | ||||
| and/or IPP object implementations. For example, a typical order of | ||||
| processing requests is given, including error checking. Motivation for | ||||
| some of the specification decisions is also included. | ||||
| Expires November 30, 2000 | The full set of IPP documents includes: | |||
| The full set of IPP documents includes: | Design Goals for an Internet Printing Protocol [RFC2567] | |||
| Design Goals for an Internet Printing Protocol [RFC2567] | Rationale for the Structure and Model and Protocol for the Internet | |||
| Rationale for the Structure and Model and Protocol for the Internet | ||||
| Printing Protocol [RFC2568] | Printing Protocol [RFC2568] | |||
| Internet Printing Protocol/1.1: Model and Semantics [IPP-MOD] | Internet Printing Protocol/1.1: Model and Semantics [RFC2911] | |||
| Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO] | Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] | |||
| Mapping between LPD and IPP Protocols [RFC2569] | Mapping between LPD and IPP Protocols [RFC2569] | |||
| The document, "Design Goals for an Internet Printing Protocol", takes | ||||
| The document, "Design Goals for an Internet Printing Protocol", takes a | a broad look at distributed printing functionality, and it enumerates | |||
| broad look at distributed printing functionality, and it enumerates | real-life scenarios that help to clarify the features that need to be | |||
| real-life scenarios that help to clarify the features that need to be | included in a printing protocol for the Internet. It identifies | |||
| included in a printing protocol for the Internet. It identifies | requirements for three types of users: end users, operators, and | |||
| requirements for three types of users: end users, operators, and | administrators. The design goal document calls out a subset of end | |||
| administrators. The design goal document calls out a subset of end user | user requirements that are satisfied in IPP/1.1. Operator and | |||
| requirements that are satisfied in IPP/1.1. Operator and administrator | administrator requirements are out of scope for version 1.1. | |||
| requirements are out of scope for version 1.1. | ||||
| The document, "Rationale for the Structure and Model and Protocol for | ||||
| the Internet Printing Protocol", describes IPP from a high level view, | ||||
| defines a roadmap for the various documents that form the suite of IPP | ||||
| specifications, and gives background and rationale for the IETF working | ||||
| group's major decisions. | ||||
| The document, "Internet Printing Protocol/1.1: Model and Semantics", | ||||
| describes a simplified model with abstract objects, their attributes, | ||||
| and their operations. The model introduces a Printer and a Job. The | ||||
| Job supports multiple documents per Job. The model document also | ||||
| addresses how security, internationalization, and directory issues are | ||||
| addressed. | ||||
| The document, "Internet Printing Protocol/1.1: Encoding and Transport", | ||||
| is a formal mapping of the abstract operations and attributes defined in | ||||
| the model document onto HTTP/1.1. It also defines the encoding rules | ||||
| for a new Internet media type called "application/ipp". | ||||
| The document, "Mapping between LPD and IPP Protocols", gives some advice | ||||
| to implementers of gateways between IPP and LPD (Line Printer Daemon) | ||||
| implementations. | ||||
| Expires November 30, 2000 | ||||
| TABLE OF CONTENTS | ||||
| 1 INTRODUCTION.......................................................8 | ||||
| 1.1 Conformance language.............................................8 | ||||
| 1.2 Other terminology................................................9 | ||||
| 1.3 Issues Raised from Interoperability Bake Offs....................9 | ||||
| 2 IPP OBJECTS........................................................9 | ||||
| 3 IPP OPERATIONS....................................................10 | ||||
| 3.1 Common Semantics................................................10 | ||||
| 3.1.1 Summary of Operation Attributes.............................10 | ||||
| 3.1.2 Suggested Operation Processing Steps for IPP Objects........16 | ||||
| 3.1.2.1 Suggested Operation Processing Steps for all Operations.17 | ||||
| 3.1.2.1.1 Validate version number............................17 | ||||
| 3.1.2.1.2 Validate operation identifier......................19 | ||||
| 3.1.2.1.3 Validate the request identifier....................19 | ||||
| 3.1.2.1.4 Validate attribute group and attribute presence and | ||||
| order 19 | ||||
| 3.1.2.1.4.1 Validate the presence and order of attribute | ||||
| groups 19 | ||||
| 3.1.2.1.4.2 Ignore unknown attribute groups in the expected | ||||
| position 20 | ||||
| 3.1.2.1.4.3 Validate the presence of a single occurrence of | ||||
| required Operation attributes................................20 | ||||
| 3.1.2.1.5 Validate the values of the REQUIRED Operation | ||||
| attributes 27 | ||||
| 3.1.2.1.6 Validate the values of the OPTIONAL Operation | ||||
| attributes 31 | ||||
| 3.1.2.2 Suggested Additional Processing Steps for Operations that | ||||
| Create/Validate Jobs and Add Documents..........................35 | ||||
| 3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied...35 | ||||
| 3.1.2.2.2 Check that the Printer object is accepting jobs....35 | ||||
| 3.1.2.2.3 Validate the values of the Job Template attributes.36 | ||||
| 3.1.2.3 Algorithm for job validation............................37 | ||||
| 3.1.2.3.1 Check for conflicting Job Template attributes values42 | ||||
| 3.1.2.3.2 Decide whether to REJECT the request...............43 | ||||
| 3.1.2.3.3 For the Validate-Job operation, RETURN one of the | ||||
| success status codes...........................................44 | ||||
| 3.1.2.3.4 Create the Job object with attributes to support...45 | ||||
| 3.1.2.3.5 Return one of the success status codes.............46 | ||||
| 3.1.2.3.6 Accept appended Document Content...................47 | ||||
| 3.1.2.3.7 Scheduling and Starting to Process the Job.........47 | ||||
| 3.1.2.3.8 Completing the Job.................................47 | ||||
| 3.1.2.3.9 Destroying the Job after completion................47 | ||||
| 3.1.2.3.10 Interaction with "ipp-attribute-fidelity"..........48 | ||||
| 3.1.2.3.11 Character set code conversion support..............48 | ||||
| Expires November 30, 2000 | ||||
| 3.1.2.3.12 What charset to return when an unsupported charset is | ||||
| requested (Issue 1.19)?........................................49 | ||||
| 3.1.2.3.13 Natural Language Override (NLO)....................50 | ||||
| 3.1.3 Status codes returned by operation..........................52 | ||||
| 3.1.3.1 Printer Operations......................................52 | ||||
| 3.1.3.1.1 Print-Job..........................................52 | ||||
| 3.1.3.1.2 Print-URI..........................................54 | ||||
| 3.1.3.1.3 Validate-Job.......................................54 | ||||
| 3.1.3.1.4 Create-Job.........................................55 | ||||
| 3.1.3.1.5 Get-Printer-Attributes.............................55 | ||||
| 3.1.3.1.6 Get-Jobs...........................................56 | ||||
| 3.1.3.1.7 Pause-Printer......................................57 | ||||
| 3.1.3.1.8 Resume-Printer.....................................57 | ||||
| 3.1.3.1.8.1 What about Printers unable to change state due to | ||||
| an error condition?..........................................58 | ||||
| 3.1.3.1.8.2 How is 'printer-state' handled on Resume-Printer?58 | ||||
| 3.1.3.1.9 Purge-Printer......................................59 | ||||
| 3.1.3.2 Job Operations..........................................59 | ||||
| 3.1.3.2.1 Send-Document......................................59 | ||||
| 3.1.3.2.2 Send-URI...........................................60 | ||||
| 3.1.3.2.3 Cancel-Job.........................................60 | ||||
| 3.1.3.2.4 Get-Job-Attributes.................................61 | ||||
| 3.1.3.2.5 Hold-Job...........................................62 | ||||
| 3.1.3.2.6 Release-Job........................................63 | ||||
| 3.1.3.2.7 Restart-Job........................................63 | ||||
| 3.1.3.2.7.1 Can documents be added to a restarted job?.......63 | ||||
| 3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue | ||||
| 1.18) 63 | ||||
| 3.1.5 Sending empty attribute groups..............................64 | ||||
| 3.2 Printer Operations..............................................64 | ||||
| 3.2.1 Print-Job operation.........................................64 | ||||
| 3.2.1.1 Flow controlling the data portion of a Print-Job request | ||||
| (Issue 1.22)....................................................64 | ||||
| 3.2.1.2 Returning job-state in Print-Job response (Issue 1.30)..65 | ||||
| 3.2.2 Get-Printer-Attributes operation............................66 | ||||
| 3.2.3 Get-Jobs operation..........................................66 | ||||
| 3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' | ||||
| (Issue 1.39)?...................................................66 | ||||
| 3.2.3.2 Why is there a "limit" attribute in the Get-Jobs | ||||
| operation?......................................................66 | ||||
| 3.2.4 Create-Job operation........................................67 | ||||
| 3.3 Job Operations..................................................67 | ||||
| 3.3.1 Validate-Job................................................67 | ||||
| 3.3.2 Restart-Job.................................................67 | ||||
| 4 OBJECT ATTRIBUTES.................................................68 | ||||
| 4.1 Attribute Syntax's..............................................68 | ||||
| 4.1.1 The 'none' value for empty sets (Issue 1.37)................68 | ||||
| Expires November 30, 2000 | ||||
| 4.1.2 Multi-valued attributes (Issue 1.31)........................68 | ||||
| 4.1.3 Case Sensitivity in URIs (issue 1.6)........................69 | ||||
| 4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage...69 | ||||
| 4.2 Job Template Attributes.........................................70 | ||||
| 4.2.1 multiple-document-handling(type2 keyword)...................70 | ||||
| 4.2.1.1 Support of multiple document jobs.......................70 | ||||
| 4.3 Job Description Attributes......................................70 | ||||
| 4.4 Printer Description Attributes..................................71 | ||||
| 4.4.1 queued-job-count............................................71 | ||||
| 4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)?.....71 | ||||
| 4.4.1.2 Is "queued-job-count" a good measure of how busy a printer | ||||
| is (Issue 1.15)?................................................71 | ||||
| 4.4.2 printer-current-time (dateTime).............................71 | ||||
| 4.4.3 'Printer-uri................................................72 | ||||
| 4.5 Empty Jobs......................................................72 | ||||
| 5 DIRECTORY CONSIDERATIONS..........................................73 | ||||
| 5.1 General Directory Schema Considerations.........................73 | The document, "Rationale for the Structure and Model and Protocol for | |||
| 5.2 IPP Printer with a DNS name.....................................73 | the Internet Printing Protocol", describes IPP from a high level | |||
| view, defines a roadmap for the various documents that form the suite | ||||
| of IPP specifications, and gives background and rationale for the | ||||
| IETF working group's major decisions. | ||||
| 6 SECURITY CONSIDERATIONS...........................................73 | The document, "Internet Printing Protocol/1.1: Model and Semantics", | |||
| describes a simplified model with abstract objects, their attributes, | ||||
| and their operations. The model introduces a Printer and a Job. The | ||||
| Job supports multiple documents per Job. The model document also | ||||
| addresses how security, internationalization, and directory issues | ||||
| are addressed. | ||||
| 6.1 Querying jobs with IPP that were submitted using other job | The document, "Internet Printing Protocol/1.1: Encoding and | |||
| submission protocols (Issue 1.32)...................................73 | Transport", is a formal mapping of the abstract operations and | |||
| attributes defined in the model document onto HTTP/1.1. It also | ||||
| defines the encoding rules for a new Internet media type called | ||||
| "application/ipp". | ||||
| 7 ENCODING AND TRANSPORT............................................74 | The document, "Mapping between LPD and IPP Protocols", gives some | |||
| advice to implementers of gateways between IPP and LPD (Line Printer | ||||
| Daemon) implementations. | ||||
| 7.1 General Headers.................................................76 | TABLE OF CONTENTS | |||
| 7.2 Request Headers................................................77 | ||||
| 7.3 Response Headers................................................78 | ||||
| 7.4 Entity Headers.................................................79 | ||||
| 7.5 Optional support for HTTP/1.0...................................80 | ||||
| 7.6 HTTP/1.1 Chunking...............................................80 | ||||
| 7.6.1 Disabling IPP Server Response Chunking......................80 | ||||
| 7.6.2 Warning About the Support of Chunked Requests...............80 | ||||
| 8 REFERENCES........................................................81 | 1 Introduction....................................................7 | |||
| 1.1 Conformance language.........................................7 | ||||
| 1.2 Other terminology............................................8 | ||||
| 1.3 Issues Raised from Interoperability Testing Events...........8 | ||||
| 9 AUTHORS' ADDRESS..................................................82 | 2 IPP Objects.....................................................8 | |||
| 10 NOTICES..........................................................83 | 3 IPP Operations.................................................10 | |||
| 3.1 Common Semantics............................................10 | ||||
| 3.1.1 Summary of Operation Attributes............................10 | ||||
| 3.1.2 Suggested Operation Processing Steps for IPP Objects.......16 | ||||
| 3.1.2.1 Suggested Operation Processing Steps for all Operations ..17 | ||||
| 3.1.2.1.1 Validate version number...............................18 | ||||
| 3.1.2.1.2 Validate operation identifier.........................19 | ||||
| 3.1.2.1.3 Validate the request identifier.......................19 | ||||
| 3.1.2.1.4 Validate attribute group and attribute presence and order | ||||
| 19 | ||||
| 3.1.2.1.4.1 Validate the presence and order of attribute groups .19 | ||||
| 3.1.2.1.4.2 Ignore unknown attribute groups in the expected | ||||
| position 20 | ||||
| 3.1.2.1.4.3 Validate the presence of a single occurrence of | ||||
| required Operation attributes.....................................21 | ||||
| 3.1.2.1.5 Validate the values of the REQUIRED Operation attributes | ||||
| 28 | ||||
| 3.1.2.1.6 Validate the values of the OPTIONAL Operation attributes | ||||
| 32 | ||||
| 3.1.2.2 Suggested Additional Processing Steps for Operations that | ||||
| Create/Validate Jobs and Add Documents............................35 | ||||
| 3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied......35 | ||||
| 3.1.2.2.2 Check that the Printer object is accepting jobs.......36 | ||||
| 3.1.2.2.3 Validate the values of the Job Template attributes....36 | ||||
| 3.1.2.3 Algorithm for job validation .............................37 | ||||
| 3.1.2.3.1 Check for conflicting Job Template attributes values..43 | ||||
| 3.1.2.3.2 Decide whether to REJECT the request..................43 | ||||
| 3.1.2.3.3 For the Validate-Job operation, RETURN one of the success | ||||
| status codes......................................................45 | ||||
| 3.1.2.3.4 Create the Job object with attributes to support......45 | ||||
| 3.1.2.3.5 Return one of the success status codes................47 | ||||
| 3.1.2.3.6 Accept appended Document Content......................48 | ||||
| 3.1.2.3.7 Scheduling and Starting to Process the Job............48 | ||||
| 3.1.2.3.8 Completing the Job....................................48 | ||||
| 3.1.2.3.9 Destroying the Job after completion...................48 | ||||
| 3.1.2.3.10 Interaction with "ipp-attribute-fidelity".............49 | ||||
| 3.1.2.3.11 Character set code conversion support.................49 | ||||
| 3.1.2.3.12 What charset to return when an unsupported charset is | ||||
| requested (Issue 1.19)?...........................................50 | ||||
| 3.1.2.3.13 Natural Language Override (NLO).......................51 | ||||
| 3.1.3 Status codes returned by operation.........................53 | ||||
| 3.1.3.1 Printer Operations .......................................53 | ||||
| 3.1.3.1.1 Print-Job.............................................53 | ||||
| 3.1.3.1.2 Print-URI.............................................55 | ||||
| 3.1.3.1.3 Validate-Job..........................................56 | ||||
| 3.1.3.1.4 Create-Job............................................56 | ||||
| 3.1.3.1.5 Get-Printer-Attributes................................56 | ||||
| 3.1.3.1.6 Get-Jobs..............................................57 | ||||
| 3.1.3.1.7 Pause-Printer.........................................58 | ||||
| 3.1.3.1.8 Resume-Printer........................................59 | ||||
| 3.1.3.1.8.1 What about Printers unable to change state due to an | ||||
| error condition?..................................................59 | ||||
| 3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer? ...59 | ||||
| 3.1.3.1.9 Purge-Printer.........................................60 | ||||
| 3.1.3.2 Job Operations ...........................................60 | ||||
| 3.1.3.2.1 Send-Document.........................................60 | ||||
| 3.1.3.2.2 Send-URI..............................................61 | ||||
| 3.1.3.2.3 Cancel-Job............................................62 | ||||
| 3.1.3.2.4 Get-Job-Attributes....................................62 | ||||
| 3.1.3.2.5 Hold-Job..............................................63 | ||||
| 3.1.3.2.6 Release-Job...........................................64 | ||||
| 3.1.3.2.7 Restart-Job...........................................64 | ||||
| 3.1.3.2.7.1 Can documents be added to a restarted job? ..........65 | ||||
| 3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue | ||||
| 1.18) 65 | ||||
| 3.1.5 Sending empty attribute groups.............................65 | ||||
| 3.2 Printer Operations..........................................66 | ||||
| 3.2.1 Print-Job operation........................................66 | ||||
| 3.2.1.1 Flow controlling the data portion of a Print-Job request | ||||
| (Issue 1.22)......................................................66 | ||||
| 3.2.1.2 Returning job-state in Print-Job response (Issue 1.30) ...66 | ||||
| 3.2.2 Get-Printer-Attributes operation...........................67 | ||||
| 3.2.3 Get-Jobs operation.........................................67 | ||||
| 3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue | ||||
| 1.39)? 67 | ||||
| 3.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation? | ||||
| 68 | ||||
| 3.2.4 Create-Job operation.......................................68 | ||||
| 3.3 Job Operations..............................................69 | ||||
| 3.3.1 Validate-Job...............................................69 | ||||
| 3.3.2 Restart-Job................................................69 | ||||
| TABLES | 4 Object Attributes..............................................70 | |||
| 4.1 Attribute Syntax's..........................................70 | ||||
| 4.1.1 The 'none' value for empty sets (Issue 1.37)...............70 | ||||
| 4.1.2 Multi-valued attributes (Issue 1.31).......................70 | ||||
| 4.1.3 Case Sensitivity in URIs (issue 1.6).......................70 | ||||
| 4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage..71 | ||||
| 4.2 Job Template Attributes.....................................72 | ||||
| 4.2.1 multiple-document-handling(type2 keyword)..................72 | ||||
| 4.2.1.1 Support of multiple document jobs ........................72 | ||||
| 4.3 Job Description Attributes..................................72 | ||||
| 4.3.1 Getting the date and time of day...........................72 | ||||
| 4.4 Printer Description Attributes..............................73 | ||||
| 4.4.1 queued-job-count (integer(0:MAX))..........................73 | ||||
| 4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)? ......73 | ||||
| 4.4.1.2 Is "queued-job-count" a good measure of how busy a printer | ||||
| is (Issue 1.15)?..................................................73 | ||||
| 4.4.2 printer-current-time (dateTime)............................73 | ||||
| 4.4.3 Printer-uri................................................74 | ||||
| 4.5 Empty Jobs..................................................74 | ||||
| Table 1 - Summary of Printer operation attributes that sender MUST | 5 Directory Considerations.......................................75 | |||
| supply............................................................10 | 5.1 General Directory Schema Considerations.....................75 | |||
| 5.2 IPP Printer with a DNS name.................................75 | ||||
| Table 2 - Summary of Printer operation attributes that sender MAY supply | 6 Security Considerations........................................75 | |||
| .................................................................11 | 6.1 Querying jobs with IPP that were submitted using other job | |||
| submission protocols (Issue 1.32).................................75 | ||||
| Expires November 30, 2000 | 7 Encoding and Transport.........................................76 | |||
| 7.1 General Headers.............................................78 | ||||
| 7.2 Request Headers............................................79 | ||||
| 7.3 Response Headers............................................81 | ||||
| 7.4 Entity Headers.............................................81 | ||||
| 7.5 Optional support for HTTP/1.0...............................82 | ||||
| 7.6 HTTP/1.1 Chunking...........................................83 | ||||
| 7.6.1 Disabling IPP Server Response Chunking.....................83 | ||||
| 7.6.2 Warning About the Support of Chunked Requests..............83 | ||||
| Table 3 - Summary of Job operation attributes that sender MUST supply13 | 8 References.....................................................84 | |||
| Table 4 - Summary of Job operation attributes that sender MAY supply.14 | 9 Authors' Address...............................................85 | |||
| Table 5 - Printer operation response attributes......................15 | 10 Full Copyright Statement.......................................86 | |||
| Table 6 - Examples of validating IPP version.........................18 | TABLES | |||
| Table 7 - Rules for validating single values X against Z.............37 | Table 1 - Summary of Printer operation attributes that sender MUST | |||
| supply ........................................................11 | ||||
| Table 2 - Summary of Printer operation attributes that sender MAY | ||||
| supply ........................................................12 | ||||
| Table 3 - Summary of Job operation attributes that sender MUST supply | ||||
| ..............................................................13 | ||||
| Table 4 - Summary of Job operation attributes that sender MAY supply | ||||
| ..............................................................14 | ||||
| Table 5 - Printer operation response attributes...................15 | ||||
| Table 6 - Examples of validating IPP version......................18 | ||||
| Table 7 - Rules for validating single values X against Z..........38 | ||||
| Expires November 30, 2000 | ||||
| 1 Introduction | 1 Introduction | |||
| The IPP Implementer's Guide (IIG) (this document) contains information | The IPP Implementer's Guide (IIG) (this document) contains | |||
| that supplements the IPP Model and Semantics [IPP-MOD] and the IPP | information that supplements the IPP Model and Semantics [RFC2911] | |||
| Transport and Encoding [IPP-PRO] documents. As such this information is | and the IPP Transport and Encoding [RFC2910] documents. As such this | |||
| not part of the formal specifications. Instead information is presented | information is not part of the formal specifications. Instead | |||
| to help implementers understand the specification, including some of the | information is presented to help implementers understand the | |||
| motivation for decisions taken by the committee in developing the | specification, including some of the motivation for decisions taken | |||
| specification. Some of the implementation considerations are intended | by the committee in developing the specification. Some of the | |||
| to help implementers design their client and/or IPP object | implementation considerations are intended to help implementers | |||
| implementations. If there are any contradictions between this document | design their client and/or IPP object implementations. If there are | |||
| and [IPP-MOD] or [IPP-PRO], those documents take precedence over this | any contradictions between this document and [RFC2911] or [RFC2910], | |||
| document. | those documents take precedence over this document. | |||
| Platform-specific implementation considerations will be included in this | Platform-specific implementation considerations will be included in | |||
| guide as they become known. | this guide as they become known. | |||
| In order to help the reader of the IIG and the IPP Model and Semantics | In order to help the reader of the IIG and the IPP Model and | |||
| document, the sections in this document parallel the corresponding | Semantics document, the sections in this document parallel the | |||
| sections in the Model document and are numbered the same for ease of | corresponding sections in the Model document and are numbered the | |||
| cross reference. The sections that correspond to the IPP Transport and | same for ease of cross reference. The sections that correspond to | |||
| Encoding are correspondingly offset. | the IPP Transport and Encoding are correspondingly offset. | |||
| 1.1 Conformance language | 1.1 Conformance language | |||
| Usually, this document does not contain the terminology MUST, MUST NOT, | Usually, this document does not contain the terminology MUST, MUST | |||
| MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL. However, | NOT, MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL. | |||
| when those terms do appear in this document, their intent is to repeat | However, when those terms do appear in this document, their intent is | |||
| what the [IPP-MOD] and [IPP-PRO] documents require and allow, rather | to repeat what the [RFC2911] and [RFC2910] documents require and | |||
| than specifying additional conformance requirements. These terms are | allow, rather than specifying additional conformance requirements. | |||
| defined in section 13 on conformance terminology in [IPP-MOD], most of | These terms are defined in section 12 on conformance terminology in | |||
| which is taken from RFC 2119 [RFC2119]. | [RFC2911], most of which is taken from RFC 2119 [RFC2119]. | |||
| Implementers should read section 13 (APPENDIX A) in [IPP-MOD] in order | Implementers should read section 12 (APPENDIX A) in [RFC2911] in | |||
| to understand these capitalized words. The words MUST, MUST NOT, and | order to understand these capitalized words. The words MUST, MUST | |||
| REQUIRED indicate what implementations are required to support in a | NOT, and REQUIRED indicate what implementations are required to | |||
| client or IPP object in order to be conformant to [IPP-MOD] and [IPP- | support in a client or IPP object in order to be conformant to | |||
| PRO]. MAY, NEED NOT, and OPTIONAL indicate was is merely allowed as an | [RFC2911] and [RFC2910]. MAY, NEED NOT, and OPTIONAL indicate was is | |||
| implementer option. The verbs SHOULD and SHOULD NOT indicate suggested | merely allowed as an implementer option. The verbs SHOULD and SHOULD | |||
| behavior, but which is not required or disallowed, respectively, in | NOT indicate suggested behavior, but which is not required or | |||
| order to conform to the specification. | disallowed, respectively, in order to conform to the specification. | |||
| Expires November 30, 2000 | ||||
| 1.2 Other terminology | 1.2 Other terminology | |||
| The term "sender" refers to the client that sends a request or an IPP | This document uses other terms, such as "attributes", "operation", | |||
| object that returns a response. The term "receiver" refers to the IPP | and "Printer" as defined in [RFC2911] section 12. In addition, the | |||
| object that receives a request and to a client that receives a response. | term "sender" refers to the client that sends a request or an IPP | |||
| object that returns a response. The term "receiver" refers to the | ||||
| 1.3 Issues Raised from Interoperability Bake Offs | IPP object that receives a request and to a client that receives a | |||
| response. | ||||
| The IPP WG has conducted two open interoperability "Bake Offs". The | 1.3 Issues Raised from Interoperability Testing Events | |||
| first bake off was held in September 1998 and Bake Off2 was held in | ||||
| March 1999. See the summary reports in: | ||||
| ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/ | The IPP WG has conducted three open Interoperability Testing Events. | |||
| The first one was held in September 1998, the second one was held in | ||||
| March 1999, and the third one was held in October 2000. See the | ||||
| summary reports in: | ||||
| The issues raised from the first bake off are numbered 1.n in this | ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/ | |||
| document and are described in: | ||||
| ftp://ftp.pwg.org/pub/pwg/ipp/approved-clarifications/ipp-agreed-fixes- | The issues raised from the first Interoperability Testing Event are | |||
| 981030.pdf | numbered 1.n in this document and have been incorporated into | |||
| "IPP/1.0 Model and Semantics" [RFC2566] and the "IPP/1.0 Encoding and | ||||
| Transport" [RFC2565] documents. However, some of the discussion is | ||||
| left here in the Implementer's Guide to help understanding. | ||||
| These issue resolutions have been incorporated into the November 16, | The issues raised from the second Interoperability Testing Event are | |||
| "IPP/1.0 Model and Semantics" [ipp-mod] and the "IPP/1.0 Encoding and | numbered 2.n in this document have been incorporated into "IPP/1.1 | |||
| Transport" [IPP-PRO] documents. However, some of the discussion is left | Model and Semantics" [RFC2911] and the "IPP/1.1 Encoding and | |||
| here in the Implementer's Guide to help understanding. | Transport" [RFC2910] documents. However, some of the discussion is | |||
| left here in the Implementer's Guide to help understanding. | ||||
| The issues raised from Bake Off2 are numbered 2.n in this document and | The issues raised from the third Interoperability Testing Event are | |||
| are described in: | numbered 3.n in this document and are described in: | |||
| ftp://ftp.pwg.org/pub/pwg/ipp/issues/issues-raised-at-bake-off2.pdf | ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.pdf | |||
| ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.doc | ||||
| ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off3.txt | ||||
| 2 IPP Objects | 2 IPP Objects | |||
| The term "client" in IPP is intended to mean any client that issues IPP | The term "client" in IPP is intended to mean any client that issues | |||
| operation requests and accepts IPP operation responses, whether it be a | IPP operation requests and accepts IPP operation responses, whether | |||
| desktop or a server. In other words, the term "client" does not just | it be a desktop or a server. In other words, the term "client" does | |||
| mean end-user clients, such as those associated with desktops. | not just mean end-user clients, such as those associated with | |||
| desktops. | ||||
| The term "IPP Printer" in IPP is intended to mean an object that accepts | The term "IPP Printer" in IPP is intended to mean an object that | |||
| IPP operation requests and returns IPP operation responses, whether | accepts IPP operation requests and returns IPP operation responses, | |||
| implemented in a server or a device. An IPP Printer object MAY, if | whether implemented in a server or a device. An IPP Printer object | |||
| implemented in a server, turn around and forward received jobs (and | MAY, if implemented in a server, turn around and forward received | |||
| other requests) to other devices and print servers/services, either | jobs (and other requests) to other devices and print | |||
| using IPP or some other protocol. | servers/services, either using IPP or some other protocol. | |||
| Expires November 30, 2000 | ||||
| 3 IPP Operations | 3 IPP Operations | |||
| This section corresponds to Section 3 "IPP Operations" in the IPP/1.1 | This section corresponds to Section 3 "IPP Operations" in the | |||
| Model and Semantics document [IPP-MOD]. | IPP/1.1 Model and Semantics document [RFC2911]. | |||
| 3.1 Common Semantics | 3.1 Common Semantics | |||
| This section discusses semantics common to all operations. | This section discusses semantics common to all operations. | |||
| 3.1.1 Summary of Operation Attributes | 3.1.1 Summary of Operation Attributes | |||
| Legend for the following table: | Legend for the following table: | |||
| R indicates a REQUIRED operation that MUST be supported by the IPP | R indicates a REQUIRED operation that MUST be supported by the IPP | |||
| object (Printer or Job). For attributes, R indicates that the attribute | object (Printer or Job). For attributes, R indicates that the | |||
| MUST be supported by the IPP object supports the associated operation. | attribute MUST be supported by the IPP object supports the | |||
| associated operation. | ||||
| O indicates an OPTIONAL operation or attribute that MAY be supported by | O indicates an OPTIONAL operation or attribute that MAY be | |||
| the IPP object (Printer or Job). | supported by the IPP object (Printer or Job). | |||
| + indicates that this is not an IPP/1.0 feature, but is only a part of | + indicates that this is not an IPP/1.0 feature, but is only a part | |||
| IPP/1.1 and future versions of IPP. | of IPP/1.1 and future versions of IPP. | |||
| Table 1 - Summary of Printer operation attributes that sender MUST | Table 1 - Summary of Printer operation attributes that sender MUST | |||
| supply | supply | |||
| Printer Operations | Printer Operations | |||
| Requests Respo | Requests Response | |||
| nses | s | |||
| Operation Print- Pri Crea Get- Get Pause- All | ||||
| Attributes Job, nt- te- Printer- - Printer Opera | ||||
| Validate URI Job Attribut Job , tions | ||||
| -Job (R) (O) (O) es (R) s Resume- | ||||
| (R) Printer | ||||
| , | ||||
| Purge- | ||||
| Printer | ||||
| (O+) | ||||
| Operation parameters--REQUIRED to be supplied by the sender: | ||||
| operation-id R R R R R R | ||||
| status-code R | ||||
| request-id R R R R R R R | ||||
| version-number R R R R R R R | ||||
| Operation attributes--REQUIRED to be supplied by the sender: | ||||
| attributes-charset R R R R R R R | ||||
| attributes- R R R R R R R | ||||
| natural-language | ||||
| Expires November 30, 2000 | Operation Print- Pri Crea Get- Get Pause- All | |||
| Printer Operations | Attributes Job, te- Printer- - Printer Operatio | |||
| Requests Respo | Validate URI Job Attribut Job , ns | |||
| nses | -Job (R) (O) (O) es (R) s Resume- | |||
| Operation Print- Pri Crea Get- Get Pause- All | (R) Printer | |||
| Attributes Job, nt- te- Printer- - Printer Opera | , | |||
| Validate URI Job Attribut Job , tions | Purge- | |||
| -Job (R) (O) (O) es (R) s Resume- | nt- Printer | |||
| (R) Printer | (O+) | |||
| , | ||||
| Purge- | ||||
| Printer | ||||
| (O+) | ||||
| document-uri R | ||||
| job-id* | ||||
| job-uri* | ||||
| last-document | ||||
| printer-uri R R R R R R | ||||
| Operation attributes--RECOMMENDED to be supplied by the sender: | ||||
| job-name R R R | ||||
| requesting-user- R R R R R R | ||||
| name | ||||
| Table 2 - Summary of Printer operation attributes that sender MAY supply | Operation parameters--REQUIRED to be supplied by the sender: | |||
| operation-id R R R R R R | ||||
| status-code R | ||||
| request-id R R R R R R R | ||||
| version- R R R R R R R | ||||
| number | ||||
| Operation attributes--REQUIRED to be supplied by the sender: | ||||
| attributes- R R R R R R R | ||||
| charset | ||||
| attributes- R R R R R R R | ||||
| natural- | ||||
| language | ||||
| document-uri R | ||||
| job-id* | ||||
| job-uri* | ||||
| last- | ||||
| document | ||||
| printer-uri R R R R R R | ||||
| Operation attributes--RECOMMENDED to be supplied by the sender: | ||||
| job-name R R R | ||||
| requesting- R R R R R R | ||||
| user-name | ||||
| Table 2 - Summary of Printer operation attributes that sender MAY | ||||
| supply | ||||
| Printer Operations | Printer Operations | |||
| Requests Respo | Requests Respo | |||
| nses | nses | |||
| Operation Attributes Print- Prin Crea Get- Get Pause- All | ||||
| Job, t- te- Printer - Printer Opera | ||||
| Valida URI Job - Job , tions | ||||
| te-Job (O) (O) Attribu s Resume- | ||||
| (R) tes (R) (R) Printer | ||||
| , | ||||
| Purge- | ||||
| Printer | ||||
| (O+) | ||||
| Operation attributes--OPTIONAL to be supplied by the sender: | ||||
| status-message O | ||||
| detailed-status- O | ||||
| message | ||||
| document-access- O** | ||||
| error | ||||
| compression O O | ||||
| document-format R R R | ||||
| document-name O O | ||||
| document-natural- O O | ||||
| language | ||||
| Expires November 30, 2000 | Operation Print- Prin Crea Get- Get Pause- All | |||
| Printer Operations | Attributes Job, t- te- Printer - Printer Opera | |||
| Requests Respo | Valida URI Job - Job , tions | |||
| nses | te-Job (O) (O) Attribu s Resume- | |||
| Operation Attributes Print- Prin Crea Get- Get Pause- All | (R) tes (R) (R) Printer | |||
| Job, t- te- Printer - Printer Opera | , | |||
| Valida URI Job - Job , tions | Purge- | |||
| te-Job (O) (O) Attribu s Resume- | Printer | |||
| (R) tes (R) (R) Printer | (O+) | |||
| , | ||||
| Purge- | ||||
| Printer | ||||
| (O+) | ||||
| ipp-attribute- R R R | ||||
| fidelity | ||||
| job-impressions O O O | ||||
| job-k-octets O O O | ||||
| job-media-sheets O O O | ||||
| limit R | ||||
| message | ||||
| my-jobs R | ||||
| requested-attributes R R | ||||
| which-jobs R | ||||
| * "job-id" is REQUIRED only if used together with "printer-uri" to | Operation attributes--OPTIONAL to be supplied by the sender: | |||
| identify the target job; otherwise, "job-uri" is REQUIRED. | status-message O | |||
| ** "document-access-error" applies to the Print-URI response only. | detailed-status- O | |||
| message | ||||
| document-access- O** | ||||
| error | ||||
| compression O O | ||||
| document-format R R R | ||||
| document-name O O | ||||
| document-natural- O O | ||||
| language | ||||
| ipp-attribute- R R R | ||||
| fidelity | ||||
| job-impressions O O O | ||||
| job-k-octets O O O | ||||
| job-media-sheets O O O | ||||
| limit R | ||||
| message | ||||
| my-jobs R | ||||
| requested- R R | ||||
| attributes | ||||
| which-jobs R | ||||
| * "job-id" is REQUIRED only if used together with "printer-uri" | ||||
| to identify the target job; otherwise, "job-uri" is REQUIRED. | ||||
| ** "document-access-error" applies to the Print-URI response | ||||
| only. | ||||
| Expires November 30, 2000 | Table 3 - Summary of Job operation attributes that sender MUST supply | |||
| Table 3 - Summary of Job operation attributes that sender MUST supply | ||||
| Job Operations | Job Operations | |||
| Requests Respons | Requests Respons | |||
| es | es | |||
| Operation Attributes Send- Send Cance Get- Hold- All | ||||
| Docume -URI l-Job Job- Job, Operati | Operation Send- Send Cance Get- All | |||
| nt (O) (R) Attrib Release ons | Attributes Docume -URI l-Job Job- Job, Operatio | |||
| (O) utes -Job, | nt (O) (R) Attrib Release ns | |||
| (R) Restart | (O) utes -Job, | |||
| (R) Restart | ||||
| -Job | -Job | |||
| (O+) | (O+) | |||
| Operation parameters--REQUIRED to be supplied by the sender: | ||||
| operation-id R R R R R | ||||
| status-code R | ||||
| request-id R R R R R R | ||||
| version-number R R R R R R | ||||
| Operation attributes--REQUIRED to be supplied by the sender: | ||||
| attributes-charset R R R R R R | ||||
| attributes-natural- R R R R R R | ||||
| language | ||||
| document-uri R | ||||
| job-id* R R R R R | ||||
| job-uri* R R R R R | ||||
| last-document R R | ||||
| printer-uri R R R R R | ||||
| Operation attributes--RECOMMENDED to be supplied by the sender: | ||||
| job-name | ||||
| requesting-user-name R R R R R | ||||
| Expires November 30, 2000 | Operation parameters--REQUIRED to be supplied by the sender: | |||
| Table 4 - Summary of Job operation attributes that sender MAY supply | operation-id R R R R R | |||
| status-code R | ||||
| request-id R R R R R R | ||||
| version-number R R R R R R | ||||
| Operation attributes--REQUIRED to be supplied by the sender: | ||||
| attributes-charset R R R R R R | ||||
| attributes-natural- R R R R R R | ||||
| language | ||||
| document-uri R | ||||
| job-id* R R R R R | ||||
| job-uri* R R R R R | ||||
| last-document R R | ||||
| printer-uri R R R R R | ||||
| Operation attributes--RECOMMENDED to be supplied by the sender: | ||||
| job-name | ||||
| requesting-user- R R R R R | ||||
| name | ||||
| Table 4 - Summary of Job operation attributes that sender MAY supply | ||||
| Job Operations | Job Operations | |||
| Requests Respo | Requests Respo | |||
| nses | nses | |||
| Operation Attributes Send- Sen Cance Get- Hold- Relea All | ||||
| Documen d- l-Job Job- Job, se- Opera | ||||
| t URI (R) Attrib Restar Job tions | ||||
| (O) (O) utes t-Job (O+) | ||||
| (R) (O+) | ||||
| Operation attributes--OPTIONAL to be supplied by the sender: | ||||
| status-message O | ||||
| detailed-status- O | ||||
| message | ||||
| document-access-error O** | ||||
| compression O O | ||||
| document-format R R | ||||
| document-name O O | ||||
| document-natural- O O | ||||
| language | ||||
| ipp-attribute- | ||||
| fidelity | ||||
| job-impressions | ||||
| job-k-octets | ||||
| job-media-sheets | ||||
| limit | ||||
| message O O O | ||||
| job-hold-until R | ||||
| my-jobs | ||||
| requested-attributes R | ||||
| which-jobs | ||||
| * "job-id" is REQUIRED only if used together with "printer-uri" to | ||||
| identify the target job; otherwise, "job-uri" is REQUIRED. | ||||
| ** "document-access-error" applies to the Send-URI operation only. | ||||
| Expires November 30, 2000 | Operation Send- Sen Cance Hold- Relea All | |||
| Table 5 - Printer operation response attributes | Attributes Documen d- l-Job Get- Job, se- Opera | |||
| t URI (R) Attrib Restar Job tions | ||||
| (O) (O) utes t-Job (O+) | ||||
| (R) (O+) | ||||
| Printer Operations | Operation attributes--OPTIONAL to be supplied by the sender: | |||
| Response | status-message O | |||
| Operation Print- Validat Prin Create Get- Get- Pause- | detailed-status- O | |||
| Attributes Job e-Job t- -Job Printe Jobs Printer | message | |||
| (R),Send (R) URI (O) r- (R) , | document-access- O** | |||
| - (O), Attrib Resume- | error | |||
| Document Send utes Printer | compression O O | |||
| (O) -URI (R) , | document-format R R | |||
| (O) Purge- | document-name O O | |||
| Printer | document-natural- O O | |||
| (O+) | language | |||
| job-uri R R R | ipp-attribute- | |||
| job-id R R R | fidelity | |||
| job-state R R R | job-impressions | |||
| job-state- R+ R+ R+ | job-k-octets | |||
| reasons | job-media-sheets | |||
| number-of- O O O | limit | |||
| intervening- | message O O O | |||
| jobs | job-hold-until R | |||
| document- O | my-jobs | |||
| access-error+ | requested- R | |||
| attributes | ||||
| which-jobs | ||||
| * "job-id" is REQUIRED only if used together with "printer-uri" to | ||||
| identify the target job; otherwise, "job-uri" is REQUIRED. | ||||
| ** "document-access-error" applies to the Send-URI operation only. | ||||
| Expires November 30, 2000 | Table 5 - Printer operation response attributes | |||
| 3.1.2 Suggested Operation Processing Steps for IPP Objects | Printer Operations | |||
| Response | ||||
| This section suggests the steps and error checks that an IPP object MAY | Operation Print- Validat Prin Create Get- Get- Pause- | |||
| perform when processing requests and returning responses. An IPP object | Attributes Job e-Job t- -Job Printe Jobs Printer | |||
| MAY perform some or all of the error checks. However, some | (R),Send (R) URI (O) r- (R) , | |||
| implementations MAY choose to be more forgiving than the error checks | - (O), Attrib Resume- | |||
| shown here, in order to be able to accept requests from non-conforming | Document Send utes Printer | |||
| clients. Not performing all of these error checks is a so-called | (O) -URI (R) , | |||
| "forgiving" implementation. On the other hand, clients that | (O) Purge- | |||
| successfully submit requests to IPP objects that do perform all the | Printer | |||
| error checks will be more likely to be able to interoperate with other | (O+) | |||
| IPP object implementations. Thus an implementer of an IPP object needs | ||||
| to decide whether to be a "forgiving" or a "strict" implementation. | ||||
| Therefore, the error status codes returned may differ between | ||||
| implementations. Consequentially, client SHOULD NOT expect exactly the | ||||
| error code processing described in this section. | ||||
| When an IPP object receives a request, the IPP object either accepts or | job-uri R R R | |||
| rejects the request. In order to determine whether or not to accept or | job-id R R R | |||
| reject the request, the IPP object SHOULD execute the following steps. | job-state R R R | |||
| The order of the steps may be rearranged and/or combined, including | job-state- R+ R+ R+ | |||
| making one or multiple passes over the request. | reasons | |||
| number-of- O O O | ||||
| intervening- | ||||
| jobs | ||||
| document- O | ||||
| access-error+ | ||||
| A client MUST supply requests that would pass all of the error checks | 3.1.2 Suggested Operation Processing Steps for IPP Objects | |||
| indicated here in order to be a conforming client. Therefore, a client | ||||
| SHOULD supply requests that are conforming, in order to avoid being | ||||
| rejected by some IPP object implementations and/or risking different | ||||
| semantics by different implementations of forgiving implementations. | ||||
| For example, a forgiving implementation that accepts multiple | ||||
| occurrences of the same attribute, rather than rejecting the request | ||||
| might use the first occurrences, while another might use the last | ||||
| occurrence. Thus such a non-conforming client would get different | ||||
| results from the two forgiving implementations. | ||||
| In the following, processing continues step by step until a "RETURNS the | This section suggests the steps and error checks that an IPP object | |||
| xxx status code ..." statement is encountered. Error returns are | MAY perform when processing requests and returning responses. An IPP | |||
| indicated by the verb: "REJECTS". Since clients have difficulty getting | object MAY perform some or all of the error checks. However, some | |||
| the status code before sending all of the document data in a Print-Job | implementations MAY choose to be more forgiving than the error checks | |||
| request, clients SHOULD use the Validate-Job operation before sending | shown here, in order to be able to accept requests from non- | |||
| large documents to be printed, in order to validate whether the IPP | conforming clients. Not performing all of these error checks is a | |||
| Printer will accept the job or not. | so-called "forgiving" implementation. On the other hand, clients | |||
| that successfully submit requests to IPP objects that do perform all | ||||
| the error checks will be more likely to be able to interoperate with | ||||
| other IPP object implementations. Thus an implementer of an IPP | ||||
| object needs to decide whether to be a "forgiving" or a "strict" | ||||
| implementation. Therefore, the error status codes returned may | ||||
| differ between implementations. Consequentially, client SHOULD NOT | ||||
| expect exactly the error code processing described in this section. | ||||
| It is assumed that security authentication and authorization has already | When an IPP object receives a request, the IPP object either accepts | |||
| taken place at a lower layer. | or rejects the request. In order to determine whether or not to | |||
| accept or reject the request, the IPP object SHOULD execute the | ||||
| following steps. The order of the steps may be rearranged and/or | ||||
| combined, including making one or multiple passes over the request. | ||||
| A client MUST supply requests that would pass all of the error checks | ||||
| indicated here in order to be a conforming client. Therefore, a | ||||
| client SHOULD supply requests that are conforming, in order to avoid | ||||
| being rejected by some IPP object implementations and/or risking | ||||
| different semantics by different implementations of forgiving | ||||
| implementations. For example, a forgiving implementation that | ||||
| accepts multiple occurrences of the same attribute, rather than | ||||
| rejecting the request might use the first occurrences, while another | ||||
| might use the last occurrence. Thus such a non-conforming client | ||||
| would get different results from the two forgiving implementations. | ||||
| In the following, processing continues step by step until a "RETURNS | ||||
| the xxx status code ..." statement is encountered. Error returns are | ||||
| indicated by the verb: "REJECTS". Since clients have difficulty | ||||
| getting the status code before sending all of the document data in a | ||||
| Print-Job request, clients SHOULD use the Validate-Job operation | ||||
| before sending large documents to be printed, in order to validate | ||||
| whether the IPP Printer will accept the job or not. | ||||
| It is assumed that security authentication and authorization has | ||||
| already taken place at a lower layer. | ||||
| Expires November 30, 2000 | ||||
| 3.1.2.1 Suggested Operation Processing Steps for all Operations | 3.1.2.1 Suggested Operation Processing Steps for all Operations | |||
| This section is intended to apply to all operations. The next section | This section is intended to apply to all operations. The next | |||
| contains the additional steps for the Print-Job, Validate-Job, Print- | section contains the additional steps for the Print-Job, Validate- | |||
| URI, Create-Job, Send-Document, and Send-URI operations that create | Job, Print-URI, Create-Job, Send-Document, and Send-URI operations | |||
| jobs, adds documents, and validates jobs. | that create jobs, adds documents, and validates jobs. | |||
| IIG Sect # Flow IPP error status codes | IIG Sect # Flow IPP error status codes | |||
| | | ---------- ---- ---------------------- | |||
| v err | | | |||
| 3.1.2.1.1 <Validate version> --> server-error-version-not-supported | v err | |||
| ok| | 3.1.2.1.1 <Validate version> --> server-error-version-not- | |||
| v err | supported | |||
| 3.1.2.1.2 <Validate operation> --> server-error-operation-not-supported | ok| | |||
| ok| | v err | |||
| v err | 3.1.2.1.2 <Validate operation> --> server-error-operation-not- | |||
| 3.1.2.1.4.1- <Validate presence> --> client-error-bad-request | supported | |||
| 3.1.2.1.4.2 <of attributes> | ok| | |||
| ok| | v err | |||
| v err | 3.1.2.1.4.1- <Validate presence> --> client-error-bad-request | |||
| 3.1.2.1.4.3 <Validate presence> --> client-error-bad-request | 3.1.2.1.4.2 <of attributes> | |||
| <of operation attr> | ok| | |||
| ok| | v err | |||
| v err | 3.1.2.1.4.3 <Validate presence> --> client-error-bad-request | |||
| 3.1.2.1.5 <Valied values of> --> client-error-bad-request | <of operation attr> | |||
| <operation attrs> client-error-request-value-too-long | ok| | |||
| <(length, tag, range,> | v err | |||
| <multi-value)> | 3.1.2.1.5 <Valied values of> --> client-error-bad-request | |||
| ok| | <operation attrs> client-error-request-value- | |||
| v err | too-long | |||
| 3.1.2.1.5 <Validate values> --> client-error-bad-request | <(length, tag, range,> | |||
| <with supported values> client-error-charset-not-supported | <multi-value)> | |||
| ok| client-error-attributes-or-values- | ok| | |||
| | not-supported | v err | |||
| v err | 3.1.2.1.5 <Validate values> --> client-error-bad-request | |||
| 3.1.2.1.6 <Validate optionally> --> client-error-bad-request | <with supported values> client-error-charset-not- | |||
| <operation attr> client-error-natural-language-not- | supported | |||
| ok| supported | ok| client-error-attributes-or- | |||
| | client-error-request-value-too-long | values- | |||
| | client-error-attributes-or-values- | | not-supported | |||
| v not-supported | v err | |||
| 3.1.2.1.6 <Validate optionally> --> client-error-bad-request | ||||
| <operation attr> client-error-natural-language- | ||||
| not-supported | ||||
| | client-error-request-value- | ||||
| too-long | ||||
| | client-error-attributes-or- | ||||
| values-not-supported | ||||
| 3.1.2.1.1 Validate version number | 3.1.2.1.1 Validate version number | |||
| Every request and every response contains the "version-number" | Every request and every response contains the "version-number" | |||
| attribute. The value of this attribute is the major and minor version | attribute. The value of this attribute is the major and minor | |||
| version number of the syntax and semantics that the client and IPP | ||||
| Expires November 30, 2000 | object is using, respectively. The "version-number" attribute | |||
| number of the syntax and semantics that the client and IPP object is | remains in a fixed position across all future versions so that all | |||
| using, respectively. The "version-number" attribute remains in a fixed | clients and IPP object that support future versions can determine | |||
| position across all future versions so that all clients and IPP object | which version is being used. The IPP object checks to see if the | |||
| that support future versions can determine which version is being used. | major version number supplied in the request is supported. If not, | |||
| The IPP object checks to see if the major version number supplied in the | the Printer object REJECTS the request and RETURNS the 'server-error- | |||
| request is supported. If not, the Printer object REJECTS the request | version-not-supported' status code in the response. The IPP object | |||
| and RETURNS the 'server-error-version-not-supported' status code in the | returns in the "version-number" response attribute the major and | |||
| response. The IPP object returns in the "version-number" response | minor version for the error response. Thus the client can learn at | |||
| attribute the major and minor version for the error response. Thus the | least one major and minor version that the IPP object supports. The | |||
| client can learn at least one major and minor version that the IPP | IPP object is encouraged to return the closest version number to the | |||
| object supports. The IPP object is encouraged to return the closest | one supplied by the client. | |||
| version number to the one supplied by the client. | ||||
| The checking of the minor version number is implementation dependent, | The checking of the minor version number is implementation dependent, | |||
| however if the client supplied minor version is explicitly supported, | however if the client supplied minor version is explicitly supported, | |||
| the IPP object MUST respond using that identical minor version number. | the IPP object MUST respond using that identical minor version | |||
| If the major version number matches, but the minor version number does | number. If the major version number matches, but the minor version | |||
| not, the Printer SHOULD accept and attempt to process the request, or | number does not, the Printer SHOULD accept and attempt to process | |||
| MAY reject the request and return the 'server-error-version-not- | the request, or MAY reject the request and return the 'server-error- | |||
| supported' status code. In all cases, the Printer MUST return the | version-not-supported' status code. In all cases, the Printer MUST | |||
| nearest version number that it supports. For example, suppose that an | return the nearest version number that it supports. For example, | |||
| IPP/1.2 Printer supports versions '1.1' and '1.2'. The following | suppose that an IPP/1.2 Printer supports versions '1.1' and '1.2'. | |||
| responses are conforming: | The following responses are conforming: | |||
| Table 6 - Examples of validating IPP version | Table 6 - Examples of validating IPP version | |||
| Client Printer Accept Request? Printer returns | Client supplies Printer Accept Request? Printer returns | |||
| supplies | ||||
| 1.0 yes (SHOULD) 1.1 | 1.0 yes (SHOULD) 1.1 | |||
| no (SHOULD NOT) 1.1 | 1.0 no (SHOULD NOT) 1.1 | |||
| 1.1 yes (MUST) 1.1 | 1.1 yes (MUST) 1.1 | |||
| 1.2 yes (MUST) 1.2 | 1.2 yes (MUST) 1.2 | |||
| 1.3 yes (SHOULD) 1.2 | 1.3 yes (SHOULD) 1.2 | |||
| no (SHOULD NOT) 1.2 | 1.3 no (SHOULD NOT) 1.2 | |||
| It is advantageous for Printers to support both IPP/1.1 and IPP/1.0, so | It is advantageous for Printers to support both IPP/1.1 and IPP/1.0, | |||
| that they can interoperate with either client implementations. Some | so that they can interoperate with either client implementations. | |||
| implementations may allow an Administrator to explicitly disable support | Some implementations may allow an Administrator to explicitly disable | |||
| for one or the other by setting the "ipp-versions-supported" Printer | support for one or the other by setting the "ipp-versions-supported" | |||
| description attribute. | Printer description attribute. | |||
| Expires November 30, 2000 | Likewise, it is advantageous for clients to support both versions to | |||
| Likewise, it is advantageous for clients to support both versions to | allow interoperability with new and legacy Printers. | |||
| allow interoperability with new and legacy Printers. | ||||
| 3.1.2.1.2 Validate operation identifier | 3.1.2.1.2 Validate operation identifier | |||
| The Printer object checks to see if the "operation-id" attribute | The Printer object checks to see if the "operation-id" attribute | |||
| supplied by the client is supported as indicated in the Printer object's | supplied by the client is supported as indicated in the Printer | |||
| "operations-supported" attribute. If not, the Printer REJECTS the | object's "operations-supported" attribute. If not, the Printer | |||
| request and returns the 'server-error-operation-not-supported' status | REJECTS the request and returns the 'server-error-operation-not- | |||
| code in the response. | supported' status code in the response. | |||
| 3.1.2.1.3 Validate the request identifier | 3.1.2.1.3 Validate the request identifier | |||
| The Printer object SHOULD NOT check to see if the "request-id" attribute | The Printer object SHOULD NOT check to see if the "request-id" | |||
| supplied by the client is in range: between 1 and 2**31 - 1 (inclusive), | attribute supplied by the client is in range: between 1 and 2**31 - 1 | |||
| but copies all 32 bits. | (inclusive), but copies all 32 bits. | |||
| Note: The "version-number", "operation-id", and the "request-id" | Note: The "version-number", "operation-id", and the "request-id" | |||
| parameters are in fixed octet positions in the IPP/1.1 encoding. The | parameters are in fixed octet positions in the IPP/1.1 encoding. The | |||
| "version-number" parameter will be the same fixed octet position in all | "version-number" parameter will be the same fixed octet position in | |||
| versions of the protocol. These fields are validated before proceeding | all versions of the protocol. These fields are validated before | |||
| with the rest of the validation. | proceeding with the rest of the validation. | |||
| 3.1.2.1.4 Validate attribute group and attribute presence and order | 3.1.2.1.4 Validate attribute group and attribute presence and order | |||
| The order of the following validation steps depends on implementation. | The order of the following validation steps depends on | |||
| implementation. | ||||
| 3.1.2.1.4.1 Validate the presence and order of attribute groups | 3.1.2.1.4.1 Validate the presence and order of attribute groups | |||
| Client requests and IPP object responses contain attribute groups | ||||
| that Section 3 requires to be present and in a specified order. An | ||||
| IPP object verifies that the attribute groups are present and in the | ||||
| correct order in requests supplied by clients (attribute groups | ||||
| without an * in the following tables). | ||||
| Client requests and IPP object responses contain attribute groups that | If an IPP object receives a request with (1) required attribute | |||
| Section 3 requires to be present and in a specified order. An IPP | groups missing, or (2) the attributes groups are out of order, or (3) | |||
| object verifies that the attribute groups are present and in the correct | the groups are repeated, the IPP object REJECTS the request and | |||
| order in requests supplied by clients (attribute groups without an * in | RETURNS the 'client-error-bad-request' status code. For example, it | |||
| the following tables). | is an error for the Job Template Attributes group to occur before the | |||
| Operation Attributes group, for the Operation Attributes group to be | ||||
| If an IPP object receives a request with (1) required attribute groups | omitted, or for an attribute group to occur more than once, except in | |||
| missing, or (2) the attributes groups are out of order, or (3) the | the Get-Jobs response. | |||
| groups are repeated, the IPP object REJECTS the request and RETURNS the | ||||
| 'client-error-bad-request' status code. For example, it is an error for | ||||
| the Job Template Attributes group to occur before the Operation | ||||
| Attributes group, for the Operation Attributes group to be omitted, or | ||||
| for an attribute group to occur more than once, except in the Get-Jobs | ||||
| response. | ||||
| Expires November 30, 2000 | Since this kind of attribute group error is most likely to be an | |||
| Since this kind of attribute group error is most likely to be an error | error detected by a client developer rather than by a customer, the | |||
| detected by a client developer rather than by a customer, the IPP object | IPP object NEED NOT return an indication of which attribute group was | |||
| NEED NOT return an indication of which attribute group was in error in | in error in either the Unsupported Attributes group or the Status | |||
| either the Unsupported Attributes group or the Status Message. Also, | Message. Also, the IPP object NEED NOT find all attribute group | |||
| the IPP object NEED NOT find all attribute group errors before returning | errors before returning this error. | |||
| this error. | ||||
| 3.1.2.1.4.2 Ignore unknown attribute groups in the expected position | 3.1.2.1.4.2 Ignore unknown attribute groups in the expected position | |||
| Future attribute groups may be added to the specification at the end | ||||
| of requests just before the Document Content and at the end of | ||||
| response, except for the Get-Jobs response, where it maybe there or | ||||
| before the first job attributes returned. If an IPP object receives | ||||
| an unknown attribute group in these positions, it ignores the entire | ||||
| group, rather than returning an error, since that group may be a new | ||||
| group in a later minor version of the protocol that can be ignored. | ||||
| (If the new attribute group cannot be ignored without confusing the | ||||
| client, the major version number would have been increased in the | ||||
| protocol document and in the request). If the unknown group occurs | ||||
| in a different position, the IPP object REJECTS the request and | ||||
| RETURNS the 'client-error-bad-request' status code. | ||||
| Future attribute groups may be added to the specification at the end of | Clients also ignore unknown attribute groups returned in a response. | |||
| requests just before the Document Content and at the end of response, | ||||
| except for the Get-Jobs response, where it maybe there or before the | ||||
| first job attributes returned. If an IPP object receives an unknown | ||||
| attribute group in these positions, it ignores the entire group, rather | ||||
| than returning an error, since that group may be a new group in a later | ||||
| minor version of the protocol that can be ignored. (If the new | ||||
| attribute group cannot be ignored without confusing the client, the | ||||
| major version number would have been increased in the protocol document | ||||
| and in the request). If the unknown group occurs in a different | ||||
| position, the IPP object REJECTS the request and RETURNS the 'client- | ||||
| error-bad-request' status code. | ||||
| Clients also ignore unknown attribute groups returned in a response. | ||||
| Note: By validating that requests are in the proper form, IPP objects | Note: By validating that requests are in the proper form, IPP | |||
| force clients to use the proper form which, in turn, increases the | objects force clients to use the proper form which, in turn, | |||
| chances that customers will be able to use such clients from multiple | increases the chances that customers will be able to use such clients | |||
| vendors with IPP objects from other vendors. | from multiple vendors with IPP objects from other vendors. | |||
| 3.1.2.1.4.3 Validate the presence of a single occurrence of required | 3.1.2.1.4.3 Validate the presence of a single occurrence of required | |||
| Operation attributes | Operation attributes | |||
| Client requests and IPP object responses contain Operation attributes | ||||
| that [RFC2911] Section 3 requires to be present. Attributes within a | ||||
| group may be in any order, except for the ordering of target, | ||||
| charset, and natural languages attributes. These attributes MUST be | ||||
| first, and MUST be supplied in the following order: charset, natural | ||||
| language, and then target. An IPP object verifies that the attributes | ||||
| that Section 4 requires to be supplied by the client have been | ||||
| supplied in the request (attributes without an * in the following | ||||
| tables). An asterisk (*) indicates groups and Operation attributes | ||||
| that the client may omit in a request or an IPP object may omit in a | ||||
| response. | ||||
| Client requests and IPP object responses contain Operation attributes | If an IPP object receives a request with required attributes missing | |||
| that [IPP-MOD] Section 3 requires to be present. Attributes within a | or repeated from a group or in the wrong position, the behavior of | |||
| group may be in any order, except for the ordering of target, charset, | the IPP object is IMPLEMENTATION DEPENDENT. Some of the possible | |||
| and natural languages attributes. These attributes MUST be first, and | implementations are: | |||
| MUST be supplied in the following order: charset, natural language, and | ||||
| then target. An IPP object verifies that the attributes that Section 4 | ||||
| requires to be supplied by the client have been supplied in the request | ||||
| (attributes without an * in the following tables). An asterisk (*) | ||||
| indicates groups and Operation attributes that the client may omit in a | ||||
| request or an IPP object may omit in a response. | ||||
| If an IPP object receives a request with required attributes missing or | ||||
| repeated from a group or in the wrong position, the behavior of the IPP | ||||
| object is IMPLEMENTATION DEPENDENT. Some of the possible | ||||
| implementations are: | ||||
| Expires November 30, 2000 | ||||
| 1. REJECTS the request and RETURNS the 'client-error-bad-request' | ||||
| status code | ||||
| 2. accepts the request and uses the first occurrence of the attribute | REJECTS the request and RETURNS the 'client-error-bad-request' | |||
| no matter where it is | status code | |||
| 3. accepts the request and uses the last occurrence of the attribute | accepts the request and uses the first occurrence of the | |||
| no matter where it is | attribute no matter where it is | |||
| 4. accept the request and assume some default value for the missing | accepts the request and uses the last occurrence of the | |||
| attribute | attribute no matter where it is | |||
| Therefore, client MUST send conforming requests, if they want to receive | accept the request and assume some default value for the | |||
| the same behavior from all IPP object implementations. For example, it | missing attribute | |||
| is an error for the "attributes-charset" or "attributes-natural- | ||||
| language" attribute to be omitted in any operation request, or for an | ||||
| Operation attribute to be supplied in a Job Template group or a Job | ||||
| Template attribute to be supplied in an Operation Attribute group in a | ||||
| create request. It is also an error to supply the "attributes-charset" | ||||
| attribute twice. | ||||
| Since these kinds of attribute errors are most likely to be detected by | Therefore, client MUST send conforming requests, if they want to | |||
| a client developer rather than by a customer, the IPP object NEED NOT | receive the same behavior from all IPP object implementations. For | |||
| return an indication of which attribute was in error in either the | example, it is an error for the "attributes-charset" or "attributes- | |||
| Unsupported Attributes group or the Status Message. Also, the IPP | natural-language" attribute to be omitted in any operation request, | |||
| object NEED NOT find all attribute errors before returning this error. | or for an Operation attribute to be supplied in a Job Template group | |||
| or a Job Template attribute to be supplied in an Operation Attribute | ||||
| group in a create request. It is also an error to supply the | ||||
| "attributes-charset" attribute twice. | ||||
| The following tables list all the attributes for all the operations by | Since these kinds of attribute errors are most likely to be detected | |||
| attribute group in each request and each response. The order of the | by a client developer rather than by a customer, the IPP object NEED | |||
| groups is the order that the client supplies the groups as specified in | NOT return an indication of which attribute was in error in either | |||
| [IPP-MOD] Section 3. The order of the attributes within a group is | the Unsupported Attributes group or the Status Message. Also, the | |||
| arbitrary, except as noted for some of the special operation attributes | IPP object NEED NOT find all attribute errors before returning this | |||
| (charset, natural language, and target). The tables below use the | error. | |||
| following notation: | ||||
| R indicates a REQUIRED attribute or operation that an IPP object MUST | The following tables list all the attributes for all the operations | |||
| support | by attribute group in each request and each response. The order of | |||
| O indicates an OPTIONAL attribute or operation that an IPP object | the groups is the order that the client supplies the groups as | |||
| NEED NOT support | specified in [RFC2911] Section 3. The order of the attributes within | |||
| * indicates that a client MAY omit the attribute in a request and | a group is arbitrary, except as noted for some of the special | |||
| that an IPP object MAY omit the attribute in a response. | operation attributes (charset, natural language, and target). The | |||
| The absence of an * means that a client MUST supply the | tables below use the following notation: | |||
| attribute in a request and an IPP object MUST supply the | ||||
| attribute in a response. | ||||
| + indicates that this is not a IPP/1.0 operation, but is only a part | ||||
| of IPP/1.1 and future versions of IPP. | ||||
| Operation Requests | R indicates a REQUIRED attribute or operation that an IPP object | |||
| MUST support | ||||
| O indicates an OPTIONAL attribute or operation that an IPP | ||||
| object NEED NOT support | ||||
| * indicates that a client MAY omit the attribute in a request | ||||
| and that an IPP object MAY omit the attribute in a | ||||
| response. The absence of an * means that a client MUST | ||||
| supply the attribute in a request and an IPP object | ||||
| MUST supply the attribute in a response. | ||||
| + indicates that this is not a IPP/1.0 operation, but is only a | ||||
| part of IPP/1.1 and future versions of IPP. | ||||
| Expires November 30, 2000 | Operation Requests | |||
| The tables below show the attributes in their proper attribute groups | The tables below show the attributes in their proper attribute groups | |||
| for operation requests: | for operation requests: | |||
| Note: All operation requests contain "version-number", "operation-id", | Note: All operation requests contain "version-number", "operation- | |||
| and "request-id" parameters. | id", and "request-id" parameters. | |||
| Print-Job Request (R): | Print-Job Request (R): | |||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| printer-uri (R) | printer-uri (R) | |||
| requesting-user-name (R*) | requesting-user-name (R*) | |||
| job-name (R*) | job-name (R*) | |||
| ipp-attribute-fidelity (R*) | ipp-attribute-fidelity (R*) | |||
| document-name (R*) | document-name (R*) | |||
| document-format (R*) | document-format (R*) | |||
| document-natural-language (O*) | document-natural-language (O*) | |||
| compression (O*) | compression (O*) | |||
| job-k-octets (O*) | job-k-octets (O*) | |||
| job-impressions (O*) | job-impressions (O*) | |||
| job-media-sheets (O*) | job-media-sheets (O*) | |||
| Group 2: Job Template Attributes (R*) | Group 2: Job Template Attributes (R*) | |||
| <Job Template attributes> (O*) | <Job Template attributes> (O*) | |||
| (see [IPP-MOD] Section 4.2) | (see [RFC2911] Section 4.2) | |||
| Group 3: Document Content (R) | Group 3: Document Content (R) | |||
| <document content> | <document content> | |||
| Validate-Job Request (R): | Validate-Job Request (R): | |||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| printer-uri (R) | printer-uri (R) | |||
| requesting-user-name (R*) | requesting-user-name (R*) | |||
| job-name (R*) | job-name (R*) | |||
| ipp-attribute-fidelity (R*) | ipp-attribute-fidelity (R*) | |||
| document-name (R*) | document-name (R*) | |||
| document-format (R*) | document-format (R*) | |||
| document-natural-language (O*) | document-natural-language (O*) | |||
| compression (O*) | compression (O*) | |||
| job-k-octets (O*) | job-k-octets (O*) | |||
| job-impressions (O*) | job-impressions (O*) | |||
| job-media-sheets (O*) | job-media-sheets (O*) | |||
| Group 2: Job Template Attributes (R*) | Group 2: Job Template Attributes (R*) | |||
| <Job Template attributes> (O*) | <Job Template attributes> (O*) | |||
| (see [IPP-MOD] Section 4.2) | (see [RFC2911] Section 4.2) | |||
| Expires November 30, 2000 | ||||
| Print-URI Request (O): | Print-URI Request (O): | |||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| printer-uri (R) | printer-uri (R) | |||
| document-uri (R) | document-uri (R) | |||
| requesting-user-name (R*) | requesting-user-name (R*) | |||
| job-name (R*) | job-name (R*) | |||
| ipp-attribute-fidelity (R*) | ipp-attribute-fidelity (R*) | |||
| document-name (R*) | document-name (R*) | |||
| document-format (R*) | document-format (R*) | |||
| document-natural-language (O*) | document-natural-language (O*) | |||
| compression (O*) | compression (O*) | |||
| job-k-octets (O*) | job-k-octets (O*) | |||
| job-impressions (O*) | job-impressions (O*) | |||
| job-media-sheets (O*) | job-media-sheets (O*) | |||
| Group 2: Job Template Attributes (R*) | Group 2: Job Template Attributes (R*) | |||
| <Job Template attributes> (O*) (see | <Job Template attributes> (O*) (see | |||
| (see [IPP-MOD] Section 4.2) | (see [RFC2911] Section 4.2) | |||
| Create-Job Request (O): | Create-Job Request (O): | |||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| printer-uri (R) | printer-uri (R) | |||
| requesting-user-name (R*) | requesting-user-name (R*) | |||
| job-name (R*) | job-name (R*) | |||
| ipp-attribute-fidelity (R*) | ipp-attribute-fidelity (R*) | |||
| job-k-octets (O*) | job-k-octets (O*) | |||
| job-impressions (O*) | job-impressions (O*) | |||
| job-media-sheets (O*) | job-media-sheets (O*) | |||
| Group 2: Job Template Attributes (R*) | Group 2: Job Template Attributes (R*) | |||
| <Job Template attributes> (O*) (see | <Job Template attributes> (O*) (see | |||
| (see [IPP-MOD] Section 4.2) | (see [RFC2911] Section 4.2) | |||
| Get-Printer-Attributes Request (R): | Get-Printer-Attributes Request (R): | |||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| printer-uri (R) | printer-uri (R) | |||
| requesting-user-name (R*) | requesting-user-name (R*) | |||
| requested-attributes (R*) | requested-attributes (R*) | |||
| document-format (R*) | document-format (R*) | |||
| Get-Jobs Request (R): | Get-Jobs Request (R): | |||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| Expires November 30, 2000 | ||||
| printer-uri (R) | printer-uri (R) | |||
| requesting-user-name (R*) | requesting-user-name (R*) | |||
| limit (R*) | limit (R*) | |||
| requested-attributes (R*) | requested-attributes (R*) | |||
| which-jobs (R*) | which-jobs (R*) | |||
| my-jobs (R*) | my-jobs (R*) | |||
| Send-Document Request (O): | Send-Document Request (O): | |||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| (printer-uri & job-id) | job-uri (R) | (printer-uri & job-id) | job-uri (R) | |||
| last-document (R) | last-document (R) | |||
| requesting-user-name (R*) | requesting-user-name (R*) | |||
| document-name (R*) | document-name (R*) | |||
| document-format (R*) | document-format (R*) | |||
| document-natural-language (O*) | document-natural-language (O*) | |||
| compression (O*) | compression (O*) | |||
| Group 2: Document Content (R*) | Group 2: Document Content (R*) | |||
| <document content> | <document content> | |||
| Send-URI Request (O): | Send-URI Request (O): | |||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| (printer-uri & job-id) | job-uri (R) | (printer-uri & job-id) | job-uri (R) | |||
| last-document (R) | last-document (R) | |||
| document-uri (R) | document-uri (R) | |||
| requesting-user-name (R*) | requesting-user-name (R*) | |||
| document-name (R*) | document-name (R*) | |||
| document-format (R*) | document-format (R*) | |||
| document-natural-language (O*) | document-natural-language (O*) | |||
| compression (O*) | compression (O*) | |||
| Cancel-Job Request (R): | Cancel-Job Request (R): | |||
| Release-Job Request (O+): | Release-Job Request (O+): | |||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| (printer-uri & job-id) | job-uri (R) | (printer-uri & job-id) | job-uri (R) | |||
| requesting-user-name (R*) | requesting-user-name (R*) | |||
| message (O*) | message (O*) | |||
| Get-Job-Attributes Request (R): | Get-Job-Attributes Request (R): | |||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| (printer-uri & job-id) | job-uri (R) | (printer-uri & job-id) | job-uri (R) | |||
| Expires November 30, 2000 | ||||
| requesting-user-name (R*) | requesting-user-name (R*) | |||
| requested-attributes (R*) | requested-attributes (R*) | |||
| Pause-Printer Request (O+): | Pause-Printer Request (O+): | |||
| Resume-Printer Request (O+): | Resume-Printer Request (O+): | |||
| Purge-Printer Request (O+): | Purge-Printer Request (O+): | |||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| printer-uri (R) | printer-uri (R) | |||
| requesting-user-name (R*) | requesting-user-name (R*) | |||
| Hold-Job Request (O+): | Hold-Job Request (O+): | |||
| Restart-Job Request (O+): | Restart-Job Request (O+): | |||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| (printer-uri & job-id) | job-uri (R) | (printer-uri & job-id) | job-uri (R) | |||
| requesting-user-name (R*) | requesting-user-name (R*) | |||
| job-hold-until (R*) | job-hold-until (R*) | |||
| message (O*) | message (O*) | |||
| Operation Responses | Operation Responses | |||
| The tables below show the response attributes in their proper attribute | The tables below show the response attributes in their proper | |||
| groups for responses. | attribute groups for responses. | |||
| Note: All operation responses contain "version-number", "status-code", | Note: All operation responses contain "version-number", "status- | |||
| and "request-id" parameters. | code", and "request-id" parameters. | |||
| Print-Job Response (R): | ||||
| Create-Job Response (O): | ||||
| Send-Document Response (O): | ||||
| Print-Job Response (R): | ||||
| Create-Job Response (O): | ||||
| Send-Document Response (O): | ||||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| status-message (O*) | status-message (O*) | |||
| detailed-status-message (O*) | detailed-status-message (O*) | |||
| Group 2: Unsupported Attributes (R*) (see Note 3) | Group 2: Unsupported Attributes (R*) (see Note 3) | |||
| <unsupported attributes> (R*) | <unsupported attributes> (R*) | |||
| Group 3: Job Object Attributes(R*) (see Note 2) | Group 3: Job Object Attributes(R*) (see Note 2) | |||
| job-uri (R) | job-uri (R) | |||
| job-id (R) | job-id (R) | |||
| job-state (R) | job-state (R) | |||
| job-state-reasons (O* | R+) | job-state-reasons (O* | R+) | |||
| job-state-message (O*) | job-state-message (O*) | |||
| number-of-intervening-jobs (O*) | number-of-intervening-jobs (O*) | |||
| Expires November 30, 2000 | Validate-Job Response (R): | |||
| Cancel-Job Response (R): | ||||
| Validate-Job Response (R): | Hold-Job Response (O+): | |||
| Cancel-Job Response (R): | Release-Job Response (O+): | |||
| Hold-Job Response (O+): | Restart-Job Response (O+): | |||
| Release-Job Response (O+): | ||||
| Restart-Job Response (O+): | ||||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| status-message (O*) | status-message (O*) | |||
| detailed-status-message (O*) | detailed-status-message (O*) | |||
| Group 2: Unsupported Attributes (R*) (see Note 3) | Group 2: Unsupported Attributes (R*) (see Note 3) | |||
| <unsupported attributes> (R*) | <unsupported attributes> (R*) | |||
| Print-URI Response (O): | Print-URI Response (O): | |||
| Send-URI Response (O): | Send-URI Response (O): | |||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| status-message (O*) | status-message (O*) | |||
| detailed-status-message (O*) | detailed-status-message (O*) | |||
| document-access-error (O*) | document-access-error (O*) | |||
| Group 2: Unsupported Attributes (R*) (see Note 3) | Group 2: Unsupported Attributes (R*) (see Note 3) | |||
| <unsupported attributes> (R*) | <unsupported attributes> (R*) | |||
| Group 3: Job Object Attributes(R*) (see Note 2) | Group 3: Job Object Attributes(R*) (see Note 2) | |||
| job-uri (R) | job-uri (R) | |||
| job-id (R) | job-id (R) | |||
| job-state (R) | job-state (R) | |||
| job-state-reasons (O* | R+) | job-state-reasons (O* | R+) | |||
| job-state-message (O*) | job-state-message (O*) | |||
| number-of-intervening-jobs (O*) | number-of-intervening-jobs (O*) | |||
| Get-Printer-Attributes Response (R): | Get-Printer-Attributes Response (R): | |||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| status-message (O*) | status-message (O*) | |||
| detailed-status-message (O*) | detailed-status-message (O*) | |||
| Group 2: Unsupported Attributes (R*) (see Note 4) | Group 2: Unsupported Attributes (R*) (see Note 4) | |||
| <unsupported attributes> (R*) | <unsupported attributes> (R*) | |||
| Group 3: Printer Object Attributes(R*) (see Note 2) | Group 3: Printer Object Attributes(R*) (see Note 2) | |||
| <requested attributes> (R*) | <requested attributes> (R*) | |||
| Get-Jobs Response (R): | Get-Jobs Response (R): | |||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| status-message (O*) | status-message (O*) | |||
| Expires November 30, 2000 | ||||
| detailed-status-message (O*) | detailed-status-message (O*) | |||
| Group 2: Unsupported Attributes (R*) (see Note 4) | Group 2: Unsupported Attributes (R*) (see Note 4) | |||
| <unsupported attributes> (R*) | <unsupported attributes> (R*) | |||
| Group 3: Job Object Attributes(R*) (see Note 2, 5) | Group 3: Job Object Attributes(R*) (see Note 2, 5) | |||
| <requested attributes> (R*) | <requested attributes> (R*) | |||
| Get-Job-Attributes Response (R): | Get-Job-Attributes Response (R): | |||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| status-message (O*) | status-message (O*) | |||
| detailed-status-message (O*) | detailed-status-message (O*) | |||
| Group 2: Unsupported Attributes (R*) (see Note 4) | Group 2: Unsupported Attributes (R*) (see Note 4) | |||
| <unsupported attributes> (R*) | <unsupported attributes> (R*) | |||
| Group 3: Job Object Attributes(R*) (see Note 2) | Group 3: Job Object Attributes(R*) (see Note 2) | |||
| <requested attributes> (R*) | <requested attributes> (R*) | |||
| Pause-Printer Response (O+): | Pause-Printer Response (O+): | |||
| Resume-Printer Response (O+): | Resume-Printer Response (O+): | |||
| Purge-Printer Response (O+): | Purge-Printer Response (O+): | |||
| Group 1: Operation Attributes (R) | Group 1: Operation Attributes (R) | |||
| attributes-charset (R) | attributes-charset (R) | |||
| attributes-natural-language (R) | attributes-natural-language (R) | |||
| status-message (O*) | status-message (O*) | |||
| detailed-status-message (O*) | detailed-status-message (O*) | |||
| Group 2: Unsupported Attributes (R*) (see Note 4) | Group 2: Unsupported Attributes (R*) (see Note 4) | |||
| <unsupported attributes> (R*) | <unsupported attributes> (R*) | |||
| Note 2 - the Job Object Attributes and Printer Object Attributes are | Note 2 - the Job Object Attributes and Printer Object Attributes are | |||
| returned only if the IPP object returns one of the success status codes. | returned only if the IPP object returns one of the success status | |||
| codes. | ||||
| Note 3 - the Unsupported Attributes Group is present only if the client | Note 3 - the Unsupported Attributes Group is present only if the | |||
| included some Operation and/or Job Template attributes or values that | client included some Operation and/or Job Template attributes or | |||
| the Printer doesn't support whether a success or an error return. | values that the Printer doesn't support whether a success or an error | |||
| return. | ||||
| Note 4 - the Unsupported Attributes Group is present only if the client | Note 4 - the Unsupported Attributes Group is present only if the | |||
| included some Operation attributes that the Printer doesn't support | client included some Operation attributes that the Printer doesn't | |||
| whether a success or an error return. | support whether a success or an error return. | |||
| Note 5: for the Get-Jobs operation the response contains a separate Job | Note 5: for the Get-Jobs operation the response contains a separate | |||
| Object Attributes group 3 to N containing requested-attributes for each | Job Object Attributes group 3 to N containing requested-attributes | |||
| job object in the response. | for each job object in the response. | |||
| 3.1.2.1.5 Validate the values of the REQUIRED Operation attributes | 3.1.2.1.5 Validate the values of the REQUIRED Operation attributes | |||
| An IPP object validates the values supplied by the client of the | An IPP object validates the values supplied by the client of the | |||
| REQUIRED Operation attribute that the IPP object MUST support. The next | REQUIRED Operation attribute that the IPP object MUST support. The | |||
| next section specifies the validation of the values of the OPTIONAL | ||||
| Expires November 30, 2000 | Operation attributes that IPP objects MAY support. | |||
| section specifies the validation of the values of the OPTIONAL Operation | ||||
| attributes that IPP objects MAY support. | ||||
| The IPP object performs the following syntactic validation checks of | ||||
| each Operation attribute value: | ||||
| a) that the length of each Operation attribute value is correct for | ||||
| the attribute syntax tag supplied by the client according to [IPP- | ||||
| MOD] Section 4.1, | ||||
| b) that the attribute syntax tag is correct for that Operation | ||||
| attribute according to [IPP-MOD] Section 3, | ||||
| c) that the value is in the range specified for that Operation | ||||
| attribute according to [IPP-MOD] Section 3, | ||||
| d) that multiple values are supplied by the client only for | The IPP object performs the following syntactic validation checks of | |||
| operation attributes that are multi-valued, i.e., that are 1setOf X | each Operation attribute value: | |||
| according to [IPP-MOD] Section 3. | ||||
| If any of these checks fail, the IPP object REJECTS the request and | a) that the length of each Operation attribute value is | |||
| RETURNS the 'client-error-bad-request' or the 'client-error-request- | correct for the attribute syntax tag supplied by the client | |||
| value-too-long' status code. Since such an error is most likely to be | according to [RFC2911] Section 4.1, | |||
| an error detected by a client developer, rather than by an end-user, the | ||||
| IPP object NEED NOT return an indication of which attribute had the | ||||
| error in either the Unsupported Attributes Group or the Status Message. | ||||
| The description for each of these syntactic checks is explicitly | ||||
| expressed in the first IF statement in the following table. | ||||
| In addition, the IPP object checks each Operation attribute value | b) that the attribute syntax tag is correct for that Operation | |||
| against some Printer object attribute or some hard-coded value if there | attribute according to [RFC2911] Section 3, | |||
| is no "xxx-supported" Printer object attribute defined. If its value is | ||||
| not among those supported or is not in the range supported, then the IPP | ||||
| object REJECTS the request and RETURNS the error status code indicated | ||||
| in the table by the second IF statement. If the value of the Printer | ||||
| object's "xxx-supported" attribute is 'no-value' (because the system | ||||
| administrator hasn't configured a value), the check always fails. | ||||
| c) that the value is in the range specified for that Operation | ||||
| attribute according to [RFC2911] Section 3, | ||||
| attributes-charset (charset) | d) that multiple values are supplied by the client only for | |||
| operation attributes that are multi-valued, i.e., that are 1setOf | ||||
| X according to [RFC2911] Section 3. | ||||
| IF NOT a single non-empty 'charset' value, REJECT/RETURN 'client- | If any of these checks fail, the IPP object REJECTS the request and | |||
| error-bad-request'. | RETURNS the 'client-error-bad-request' or the 'client-error-request- | |||
| IF the value length is greater than 63 octets, REJECT/RETURN | value-too-long' status code. Since such an error is most likely to | |||
| 'client-error-request-value-too-long'. | be an error detected by a client developer, rather than by an end- | |||
| user, the IPP object NEED NOT return an indication of which attribute | ||||
| had the error in either the Unsupported Attributes Group or the | ||||
| Status Message. The description for each of these syntactic checks | ||||
| is explicitly expressed in the first IF statement in the following | ||||
| table. | ||||
| Expires November 30, 2000 | In addition, the IPP object checks each Operation attribute value | |||
| against some Printer object attribute or some hard-coded value if | ||||
| there is no "xxx-supported" Printer object attribute defined. If its | ||||
| value is not among those supported or is not in the range supported, | ||||
| then the IPP object REJECTS the request and RETURNS the error status | ||||
| code indicated in the table by the second IF statement. If the value | ||||
| of the Printer object's "xxx-supported" attribute is 'no-value' | ||||
| (because the system administrator hasn't configured a value), the | ||||
| check always fails. | ||||
| IF NOT in the Printer object's "charset-supported" attribute, | ----------------------------------------------- | |||
| REJECT/RETURN "client-error-charset-not-supported". | ||||
| attributes-natural-language(naturalLanguage) | attributes-charset (charset) | |||
| IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN | IF NOT a single non-empty 'charset' value, REJECT/RETURN | |||
| 'client-error-bad-request'. | 'client-error-bad-request'. | |||
| IF the value length is greater than 63 octets, REJECT/RETURN | IF the value length is greater than 63 octets, REJECT/RETURN | |||
| 'client-error-request-value-too-long'. | 'client-error-request-value-too-long'. | |||
| ACCEPT the request even if not a member of the set in the Printer | IF NOT in the Printer object's "charset-supported" attribute, | |||
| object's "generated-natural-language-supported" attribute. If | REJECT/RETURN "client-error-charset-not-supported". | |||
| the supplied value is not a member of the Printer object's | ||||
| "generated-natural-language-supported" attribute, use the | ||||
| Printer object's "natural-language-configured" value. | ||||
| requesting-user-name | attributes-natural-language(naturalLanguage) | |||
| IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad- | IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN | |||
| request'. | 'client-error-bad-request'. | |||
| IF the value length is greater than 255 octets, REJECT/RETURN | IF the value length is greater than 63 octets, REJECT/RETURN | |||
| 'client-error-request-value-too-long'. | 'client-error-request-value-too-long'. | |||
| IF the IPP object can obtain a better-authenticated name, use it | ACCEPT the request even if not a member of the set in the | |||
| instead. | Printer object's "generated-natural-language-supported" | |||
| attribute. If the supplied value is not a member of the | ||||
| Printer object's "generated-natural-language-supported" | ||||
| attribute, use the Printer object's "natural-language- | ||||
| configured" value. | ||||
| job-name(name) | requesting-user-name | |||
| IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad- | IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad- | |||
| request'. | request'. | |||
| IF the value length is greater than 255 octets, REJECT/RETURN | IF the value length is greater than 255 octets, REJECT/RETURN | |||
| 'client-error-request-value-too-long'. | 'client-error-request-value-too-long'. | |||
| IF NOT supplied by the client, the Printer object creates a name | IF the IPP object can obtain a better-authenticated name, use it | |||
| from the document-name or document-uri. | instead. | |||
| document-name (name) | job-name(name) | |||
| IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad- | IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad- | |||
| request'. | request'. | |||
| IF the value length is greater than 255 octets, REJECT/RETURN | IF the value length is greater than 255 octets, REJECT/RETURN | |||
| 'client-error-request-value-too-long'. | 'client-error-request-value-too-long'. | |||
| ipp-attribute-fidelity (boolean) | IF NOT supplied by the client, the Printer object creates a name | |||
| from the document-name or document-uri. | ||||
| IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, | document-name (name) | |||
| REJECT/RETURN 'client-error-bad-request'. | ||||
| IF the value length is NOT equal to 1 octet, REJECT/RETURN 'client- | ||||
| error-request-value-too-long' | ||||
| IF NOT supplied by the client, the IPP object assumes the value | ||||
| 'false'. | ||||
| Expires November 30, 2000 | IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad- | |||
| request'. | ||||
| IF the value length is greater than 255 octets, REJECT/RETURN | ||||
| 'client-error-request-value-too-long'. | ||||
| document-format (mimeMediaType) | ipp-attribute-fidelity (boolean) | |||
| IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN | IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, | |||
| 'client-error-bad-request'. | REJECT/RETURN 'client-error-bad-request'. | |||
| IF the value length is greater than 255 octets, REJECT/RETURN | IF the value length is NOT equal to 1 octet, REJECT/RETURN | |||
| 'client-error-request-value-too-long'. | 'client-error-request-value-too-long' | |||
| IF NOT in the Printer object's "document-format-supported" | IF NOT supplied by the client, the IPP object assumes the value | |||
| attribute, REJECT/RETURN 'client-error-document-format-not- | 'false'. | |||
| supported' | ||||
| IF NOT supplied by the client, the IPP object assumes the value of | ||||
| the Printer object's "document-format-default" attribute. | ||||
| document-uri (uri) | document-format (mimeMediaType) | |||
| IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client-error- | IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN | |||
| bad-request'. | 'client-error-bad-request'. | |||
| IF the value length is greater than 1023 octets, REJECT/RETURN | IF the value length is greater than 255 octets, REJECT/RETURN | |||
| 'client-error-request-value-too-long'. | 'client-error-request-value-too-long'. | |||
| IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad- | IF NOT in the Printer object's "document-format-supported" | |||
| request'. | attribute, REJECT/RETURN 'client-error-document-format-not- | |||
| If the client-supplied URI scheme is not supported, i.e. the value | supported' | |||
| is not in the Printer object's referenced-uri-scheme- | IF NOT supplied by the client, the IPP object assumes the value | |||
| supported" attribute, the Printer object MUST reject the | of the Printer object's "document-format-default" | |||
| request and return the 'client-error-uri-scheme-not-supported' | attribute. | |||
| status code. The Printer object MAY check to see if the | ||||
| document exists and is accessible. If the document is not | ||||
| found or is not accessible, REJECT/RETURN 'client-error-not | ||||
| found'. | ||||
| last-document (boolean) | ||||
| IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, | ||||
| REJECT/RETURN 'client-error-bad-request'. | ||||
| IF the value length is NOT equal to 1 octet, REJECT/RETURN 'client- | ||||
| error-request-value-too-long' | ||||
| job-id (integer(1:MAX)) | document-uri (uri) | |||
| IF NOT an single 'integer' value equal to 4 octets AND in the range | IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client- | |||
| 1 to MAX, REJECT/RETURN 'client-error-bad-request'. | error-bad-request'. | |||
| IF NOT a job-id of an existing Job object, REJECT/RETURN 'client- | IF the value length is greater than 1023 octets, REJECT/RETURN | |||
| error-not-found' or 'client-error-gone' status code, if keep | 'client-error-request-value-too-long'. | |||
| track of recently deleted jobs. | IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad- | |||
| request'. | ||||
| If the client-supplied URI scheme is not supported, i.e. the | ||||
| value is not in the Printer object's referenced-uri-scheme- | ||||
| supported" attribute, the Printer object MUST reject the | ||||
| request and return the 'client-error-uri-scheme-not- | ||||
| supported' status code. The Printer object MAY check to see | ||||
| if the document exists and is accessible. If the document | ||||
| is not found or is not accessible, REJECT/RETURN 'client- | ||||
| error-not found'. | ||||
| last-document (boolean) | ||||
| IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, | ||||
| REJECT/RETURN 'client-error-bad-request'. | ||||
| IF the value length is NOT equal to 1 octet, REJECT/RETURN | ||||
| 'client-error-request-value-too-long' | ||||
| requested-attributes (1setOf keyword) | job-id (integer(1:MAX)) | |||
| IF NOT one or more 'keyword' values, REJECT/RETURN 'client-error- | IF NOT an single 'integer' value equal to 4 octets AND in the | |||
| bad-request'. | range 1 to MAX, REJECT/RETURN 'client-error-bad-request'. | |||
| IF NOT a job-id of an existing Job object, REJECT/RETURN | ||||
| 'client-error-not-found' or 'client-error-gone' status | ||||
| code, if keep track of recently deleted jobs. | ||||
| Expires November 30, 2000 | requested-attributes (1setOf keyword) | |||
| IF the value length is greater than 255 octets, REJECT/RETURN | IF NOT one or more 'keyword' values, REJECT/RETURN 'client- | |||
| 'client-error-request-value-too-long'. | error-bad-request'. | |||
| Ignore unsupported values, which are the keyword names of | IF the value length is greater than 255 octets, REJECT/RETURN | |||
| unsupported attributes. Don't bother to copy such requested | 'client-error-request-value-too-long'. | |||
| (unsupported) attributes to the Unsupported Attribute response | Ignore unsupported values, which are the keyword names of | |||
| group since the response will not return them. | unsupported attributes. Don't bother to copy such | |||
| requested (unsupported) attributes to the Unsupported | ||||
| Attribute response group since the response will not return | ||||
| them. | ||||
| which-jobs (type2 keyword) | which-jobs (type2 keyword) | |||
| IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad- | IF NOT a single 'keyword' value, REJECT/RETURN 'client-error- | |||
| request'. | bad-request'. | |||
| IF the value length is greater than 255 octets, REJECT/RETURN | IF the value length is greater than 255 octets, REJECT/RETURN | |||
| 'client-error-request-value-too-long'. | 'client-error-request-value-too-long'. | |||
| IF NEITHER 'completed' NOR 'not-completed', copy the attribute and | IF NEITHER 'completed' NOR 'not-completed', copy the attribute | |||
| the unsupported value to the Unsupported Attributes response | and the unsupported value to the Unsupported Attributes | |||
| group and REJECT/RETURN 'client-error-attributes-or-values- | response group and REJECT/RETURN 'client-error-attributes- | |||
| not-supported'. | or-values-not-supported'. | |||
| Note: a Printer still supports the 'completed' value even if it | Note: a Printer still supports the 'completed' value even if it | |||
| keeps no completed/canceled/aborted jobs: by returning no | keeps no completed/canceled/aborted jobs: by returning no | |||
| jobs when so queried. | jobs when so queried. | |||
| IF NOT supplied by the client, the IPP object assumes the 'not- | IF NOT supplied by the client, the IPP object assumes the 'not- | |||
| completed' value. | completed' value. | |||
| my-jobs (boolean) | my-jobs (boolean) | |||
| IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, | IF NEITHER a single 'true' NOR a single 'false' 'boolean' value, | |||
| REJECT/RETURN 'client-error-bad-request'. | REJECT/RETURN 'client-error-bad-request'. | |||
| IF the value length is NOT equal to 1 octet, REJECT/RETURN 'client- | IF the value length is NOT equal to 1 octet, REJECT/RETURN | |||
| error-request-value-too-long' | 'client-error-request-value-too-long' | |||
| IF NOT supplied by the client, the IPP object assumes the 'false' | IF NOT supplied by the client, the IPP object assumes the | |||
| value. | 'false' value. | |||
| limit (integer(1:MAX)) | limit (integer(1:MAX)) | |||
| IF NOT a single 'integer' value equal to 4 octets AND in the range | IF NOT a single 'integer' value equal to 4 octets AND in the | |||
| 1 to MAX, REJECT/RETURN 'client-error-bad-request'. | range 1 to MAX, REJECT/RETURN 'client-error-bad-request'. | |||
| IF NOT supplied by the client, the IPP object returns all jobs, no | IF NOT supplied by the client, the IPP object returns all jobs, | |||
| matter how many. | no matter how many. | |||
| ----------------------------------------------- | ||||
| 3.1.2.1.6 Validate the values of the OPTIONAL Operation attributes | 3.1.2.1.6 Validate the values of the OPTIONAL Operation attributes | |||
| OPTIONAL Operation attributes are those that an IPP object MAY or MAY | OPTIONAL Operation attributes are those that an IPP object MAY | |||
| NOT support. An IPP object validates the values of the OPTIONAL | support. An IPP object validates the values of the OPTIONAL | |||
| attributes supplied by the client. The IPP object performs the same | attributes supplied by the client. The IPP object performs the same | |||
| syntactic validation checks for each OPTIONAL attribute value as in | ||||
| Expires November 30, 2000 | Section 3.1.2.1.5. As in Section 3.1.2.1.5, if any fail, the IPP | |||
| syntactic validation checks for each OPTIONAL attribute value as in | object REJECTS the request and RETURNS the 'client-error-bad-request' | |||
| Section 3.1.2.1.5. As in Section 3.1.2.1.5, if any fail, the IPP object | or the 'client-error-request-value-too-long' status code. | |||
| REJECTS the request and RETURNS the 'client-error-bad-request' or the | ||||
| 'client-error-request-value-too-long' status code. | ||||
| In addition, the IPP object checks each Operation attribute value | In addition, the IPP object checks each Operation attribute value | |||
| against some Printer attribute or some hard-coded value if there is no | against some Printer attribute or some hard-coded value if there is | |||
| "xxx-supported" Printer attribute defined. If its value is not among | no "xxx-supported" Printer attribute defined. If its value is not | |||
| those supported or is not in the range supported, then the IPP object | among those supported or is not in the range supported, then the IPP | |||
| REJECTS the request and RETURNS the error status code indicated in the | object REJECTS the request and RETURNS the error status code | |||
| table. If the value of the Printer object's "xxx-supported" attribute | indicated in the table. If the value of the Printer object's "xxx- | |||
| is 'no-value' (because the system administrator hasn't configured a | supported" attribute is 'no-value' (because the system administrator | |||
| value), the check always fails. | hasn't configured a value), the check always fails. | |||
| If the IPP object doesn't recognize/support an attribute, the IPP object | If the IPP object doesn't recognize/support an attribute, the IPP | |||
| treats the attribute as an unknown or unsupported attribute (see the | object treats the attribute as an unknown or unsupported attribute | |||
| last row in the table below). | (see the last row in the table below). | |||
| ----------------------------------------------- | ||||
| document-natural-language (naturalLanguage) | document-natural-language (naturalLanguage) | |||
| IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN | IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN | |||
| 'client-error-bad-request'. | 'client-error-bad-request'. | |||
| IF the value length is greater than 63 octets, REJECT/RETURN | IF the value length is greater than 63 octets, REJECT/RETURN | |||
| 'client-error-request-value-too-long'. | 'client-error-request-value-too-long'. | |||
| IF NOT a value that the Printer object supports in document | IF NOT a value that the Printer object supports in document | |||
| formats, (no corresponding "xxx-supported" Printer attribute), | formats, (no corresponding "xxx-supported" Printer attribute), | |||
| REJECT/RETURN 'client-error-natural-language-not-supported'. | REJECT/RETURN 'client-error-natural-language-not-supported'. | |||
| compression (type3 keyword) | compression (type3 keyword) | |||
| IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad- | IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad- | |||
| request'. | request'. | |||
| IF the value length is greater than 255 octets, REJECT/RETURN | IF the value length is greater than 255 octets, REJECT/RETURN | |||
| 'client-error-request-value-too-long'. | 'client-error-request-value-too-long'. | |||
| IF NOT in the Printer object's "compression-supported" attribute, | IF NOT in the Printer object's "compression-supported" attribute, | |||
| copy the attribute and the unsupported value to the | copy the attribute and the unsupported value to the | |||
| Unsupported Attributes response group and REJECT/RETURN | Unsupported Attributes response group and REJECT/RETURN | |||
| 'client-error-attributes-or-values-not-supported'. | 'client-error-attributes-or-values-not-supported'. | |||
| Note to IPP/1.0 implementers: Support for the "compression" | Note to IPP/1.0 implementers: Support for the "compression" | |||
| attribute was optional in IPP/1.0 and was changed to REQUIRED | attribute was optional in IPP/1.0 and was changed to REQUIRED | |||
| in IPP/1.1. However, an IPP/1.0 object SHOULD at least check | in IPP/1.1. However, an IPP/1.0 object SHOULD at least check | |||
| for the "compression" attribute being present and reject the | for the "compression" attribute being present and reject the | |||
| create request, if they don't support "compression". Not | create request, if they don't support "compression". Not | |||
| checking is a bug, since the data will be unintelligible. | checking is a bug, since the data will be unintelligible. | |||
| job-k-octets (integer(0:MAX)) | job-k-octets (integer(0:MAX)) | |||
| IF NOT a single 'integer' value equal to 4 octets, | ||||
| Expires November 30, 2000 | IF NOT a single 'integer' value equal to 4 octets, | |||
| REJECT/RETURN 'client-error-bad-request'. | REJECT/RETURN 'client-error-bad-request'. | |||
| IF NOT in the range of the Printer object's "job-k-octets- | IF NOT in the range of the Printer object's "job-k-octets- | |||
| supported" attribute, copy the attribute and the unsupported | supported" attribute, copy the attribute and the unsupported | |||
| value to the Unsupported Attributes response group and | value to the Unsupported Attributes response group and | |||
| REJECT/RETURN 'client-error-attributes-or-values-not- | REJECT/RETURN 'client-error-attributes-or-values-not- | |||
| supported'. | supported'. | |||
| job-impressions (integer(0:MAX)) | job-impressions (integer(0:MAX)) | |||
| IF NOT a single 'integer' value equal to 4 octets, | IF NOT a single 'integer' value equal to 4 octets, | |||
| REJECT/RETURN 'client-error-bad-request'. | REJECT/RETURN 'client-error-bad-request'. | |||
| IF NOT in the range of the Printer object's "job-impressions- | IF NOT in the range of the Printer object's "job-impressions- | |||
| supported" attribute, copy the attribute and the unsupported | supported" attribute, copy the attribute and the unsupported | |||
| value to the Unsupported Attributes response group and | value to the Unsupported Attributes response group and | |||
| REJECT/RETURN 'client-error-attributes-or-values-not- | REJECT/RETURN 'client-error-attributes-or-values-not- | |||
| supported'. | supported'. | |||
| job-media-sheets (integer(0:MAX)) | job-media-sheets (integer(0:MAX)) | |||
| IF NOT a single 'integer' value equal to 4 octets, | IF NOT a single 'integer' value equal to 4 octets, | |||
| REJECT/RETURN 'client-error-bad-request'. | REJECT/RETURN 'client-error-bad-request'. | |||
| IF NOT in the range of the Printer object's "job-media-sheets- | IF NOT in the range of the Printer object's "job-media-sheets- | |||
| supported" attribute, copy the attribute and the unsupported | supported" attribute, copy the attribute and the unsupported | |||
| value to the Unsupported Attributes response group and | value to the Unsupported Attributes response group and | |||
| REJECT/RETURN 'client-error-attributes-or-values-not- | REJECT/RETURN 'client-error-attributes-or-values-not- | |||
| supported'. | supported'. | |||
| message (text(127)) | message (text(127)) | |||
| IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad- | IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad- | |||
| request'. | request'. | |||
| IF the value length is greater than 127 octets, | IF the value length is greater than 127 octets, | |||
| REJECT/RETURN 'client-error-request-value-too-long'. | REJECT/RETURN 'client-error-request-value-too-long'. | |||
| unknown or unsupported attribute | unknown or unsupported attribute | |||
| IF the attribute syntax supplied by the client is supported but the | IF the attribute syntax supplied by the client is supported but the | |||
| length is not legal for that attribute syntax, REJECT/RETURN | length is not legal for that attribute syntax, REJECT/RETURN | |||
| 'client-error-request-value-too-long'. | 'client-error-request-value-too-long'. | |||
| ELSE copy the attribute and value to the Unsupported Attributes | ELSE copy the attribute and value to the Unsupported Attributes | |||
| response group and change the attribute value to the "out-of- | response group and change the attribute value to the "out-of- | |||
| band" 'unsupported' value, but otherwise ignore the attribute. | band" 'unsupported' value, but otherwise ignore the attribute. | |||
| Note: Future Operation attributes may be added to the protocol | Note: Future Operation attributes may be added to the protocol | |||
| specification that may occur anywhere in the specified group. When the | specification that may occur anywhere in the specified group. When | |||
| operation is otherwise successful, the IPP object returns the | the operation is otherwise successful, the IPP object returns the | |||
| 'successful-ok-ignored-or-substituted-attributes' status code. Ignoring | 'successful-ok-ignored-or-substituted-attributes' status code. | |||
| unsupported Operation attributes in all operations is analogous to the | Ignoring unsupported Operation attributes in all operations is | |||
| analogous to the handling of unsupported Job Template attributes in | ||||
| Expires November 30, 2000 | the create and Validate-Job operations when the client supplies the | |||
| handling of unsupported Job Template attributes in the create and | "ipp-attribute-fidelity" Operation attribute with the 'false' value. | |||
| Validate-Job operations when the client supplies the "ipp-attribute- | This last rule is so that we can add OPTIONAL Operation attributes to | |||
| fidelity" Operation attribute with the 'false' value. This last rule is | future versions of IPP so that older clients can inter-work with new | |||
| so that we can add OPTIONAL Operation attributes to future versions of | IPP objects and newer clients can inter-work with older IPP objects. | |||
| IPP so that older clients can inter-work with new IPP objects and newer | (If the new attribute cannot be ignored without performing | |||
| clients can inter-work with older IPP objects. (If the new attribute | unexpectedly, the major version number would have been increased in | |||
| cannot be ignored without performing unexpectedly, the major version | the protocol document and in the request). This rule for Operation | |||
| number would have been increased in the protocol document and in the | attributes is independent of the value of the "ipp-attribute- | |||
| request). This rule for Operation attributes is independent of the | fidelity" attribute. For example, if an IPP object doesn't support | |||
| value of the "ipp-attribute-fidelity" attribute. For example, if an | the OPTIONAL "job-k-octets" attribute', the IPP object treats "job-k- | |||
| IPP object doesn't support the OPTIONAL "job-k-octets" attribute', the | octets" as an unknown attribute and only checks the length for the | |||
| IPP object treats "job-k-octets" as an unknown attribute and only checks | 'integer' attribute syntax supplied by the client. If it is not four | |||
| the length for the 'integer' attribute syntax supplied by the client. | octets, the IPP object REJECTS the request and RETURNS the 'client- | |||
| If it is not four octets, the IPP object REJECTS the request and RETURNS | error-bad-request' status code, else the IPP object copies the | |||
| the 'client-error-bad-request' status code, else the IPP object copies | attribute to the Unsupported Attribute response group, setting the | |||
| the attribute to the Unsupported Attribute response group, setting the | value to the "out-of-band" 'unsupported' value, but otherwise ignores | |||
| value to the "out-of-band" 'unsupported' value, but otherwise ignores | the attribute. | |||
| the attribute. | ||||
| Expires November 30, 2000 | ||||
| 3.1.2.2 Suggested Additional Processing Steps for Operations that | 3.1.2.2 Suggested Additional Processing Steps for Operations that | |||
| Create/Validate Jobs and Add Documents | Create/Validate Jobs and Add Documents | |||
| This section in combination with the previous section recommends the | This section in combination with the previous section recommends the | |||
| processing steps for the Print-Job, Validate-Job, Print-URI, Create-Job, | processing steps for the Print-Job, Validate-Job, Print-URI, Create- | |||
| Send-Document, and Send-URI operations that IPP objects SHOULD use. | Job, Send-Document, and Send-URI operations that IPP objects SHOULD | |||
| These are the operations that create jobs, validate a Print-Job request, | use. These are the operations that create jobs, validate a Print-Job | |||
| and add documents to a job. | request, and add documents to a job. | |||
| IIG Sect # Flow IPP error status codes | IIG Sect # Flow IPP error status codes | |||
| | | ---------- ---- ---------------------- | |||
| v No | | | |||
| 3.1.2.2.1 <ipp-attribute-fidelity> ------------------+ | v No | |||
| <supplied?> | | 3.1.2.2.1 <ipp-attribute-fidelity> ------------------+ | |||
| Yes| | | <supplied?> | | |||
| | ipp-attribute-fidelity = no | | Yes| | | |||
| |<------------------------------+ | | ipp-attribute-fidelity = no | | |||
| v No | |<------------------------------+ | |||
| 3.1.2.2.2 <Printer is> --> server-error-not-accepting-jobs | v No | |||
| <accepting jobs?> | 3.1.2.2.2 <Printer is> --> server-error-not-accepting-jobs | |||
| Yes| | <accepting jobs?> | |||
| v err | Yes| | |||
| 3.1.2.3 <Validate values of> --> client-error-bad-request | v err | |||
| <Job template attributes> client-error-request-value-too-long | 3.1.2.3 <Validate values of> --> client-error-bad-request | |||
| <(length, tag, range,> | <Job template attributes> client-error-request-value-too- | |||
| <multi-value)> | long | |||
| ok| | <(length, tag, range,> | |||
| v err | <multi-value)> | |||
| 3.1.2.3 <Validate values with> --> client-error-bad-request | ok| | |||
| <supported values> client-error-attributes-or-values- | v err | |||
| ok| not-supported | 3.1.2.3 <Validate values with> --> client-error-bad-request | |||
| v err | <supported values> client-error-attributes-or- | |||
| 3.1.2.3.1 <Any conflicting> --> client-error-conflicting-attributes | | values-not-supported | |||
| <Job Template attr values> client-error-attributes-or-values- | v err | |||
| ok| not-supported | 3.1.2.3.1 <Any conflicting> --> client-error-conflicting- | |||
| v | attributes | |||
| <Job Template attr values> client-error-attributes-or- | ||||
| values-not-supported | ||||
| v | ||||
| 3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied | 3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied | |||
| The Printer object checks to see if the client supplied an "ipp- | The Printer object checks to see if the client supplied an "ipp- | |||
| attribute-fidelity" Operation attribute. If the attribute is not | attribute-fidelity" Operation attribute. If the attribute is not | |||
| supplied by the client, the IPP object assumes that the value is | supplied by the client, the IPP object assumes that the value is | |||
| 'false'. | 'false'. | |||
| 3.1.2.2.2 Check that the Printer object is accepting jobs | 3.1.2.2.2 Check that the Printer object is accepting jobs | |||
| Expires November 30, 2000 | If the value of the Printer objects "printer-is-accepting-jobs" is | |||
| If the value of the Printer objects "printer-is-accepting-jobs" is | 'false', the Printer object REJECTS the request and RETURNS the | |||
| 'false', the Printer object REJECTS the request and RETURNS the 'server- | 'server-error-not-accepting-jobs' status code. | |||
| error-not-accepting-jobs' status code. | ||||
| 3.1.2.2.3 Validate the values of the Job Template attributes | 3.1.2.2.3 Validate the values of the Job Template attributes | |||
| An IPP object validates the values of all Job Template attribute | An IPP object validates the values of all Job Template attribute | |||
| supplied by the client. The IPP object performs the analogous syntactic | supplied by the client. The IPP object performs the analogous | |||
| validation checks of each Job Template attribute value that it performs | syntactic validation checks of each Job Template attribute value that | |||
| for Operation attributes (see Section 3.1.2.1.5.): | it performs for Operation attributes (see Section 3.1.2.1.5.): | |||
| a) that the length of each value is correct for the attribute | ||||
| syntax tag supplied by the client according to [IPP-MOD] Section 4.1. | ||||
| b) that the attribute syntax tag is correct for that attribute | a) that the length of each value is correct for the attribute | |||
| according to [IPP-MOD] Sections 4.2 to 4.4. | syntax tag supplied by the client according to [RFC2911] Section | |||
| 4.1. | ||||
| c) that multiple values are supplied only for multi-valued | b) that the attribute syntax tag is correct for that attribute | |||
| attributes, i.e., that are 1setOf X according to [IPP-MOD] Sections | according to [RFC2911] Sections 4.2 to 4.4. | |||
| 4.2 to 4.4. | ||||
| As in Section 3.1.2.1.5, if any of these syntactic checks fail, the IPP | c) that multiple values are supplied only for multi-valued | |||
| object REJECTS the request and RETURNS the 'client-error-bad-request' or | attributes, i.e., that are 1setOf X according to [RFC2911] | |||
| 'client-error-request-value-too-long' status code as appropriate, | Sections 4.2 to 4.4. | |||
| independent of the value of the "ipp-attribute-fidelity". Since such an | ||||
| error is most likely to be an error detected by a client developer, | ||||
| rather than by an end-user, the IPP object NEED NOT return an indication | ||||
| of which attribute had the error in either the Unsupported Attributes | ||||
| Group or the Status Message. The description for each of these | ||||
| syntactic checks is explicitly expressed in the first IF statement in | ||||
| the following table. | ||||
| Each Job Template attribute MUST occur no more than once. If an IPP | As in Section 3.1.2.1.5, if any of these syntactic checks fail, the | |||
| Printer receives a create request with multiple occurrences of a Job | IPP object REJECTS the request and RETURNS the 'client-error-bad- | |||
| Template attribute, it MAY: | request' or 'client-error-request-value-too-long' status code as | |||
| appropriate, independent of the value of the "ipp-attribute- | ||||
| fidelity". Since such an error is most likely to be an error | ||||
| detected by a client developer, rather than by an end-user, the IPP | ||||
| object NEED NOT return an indication of which attribute had the error | ||||
| in either the Unsupported Attributes Group or the Status Message. | ||||
| The description for each of these syntactic checks is explicitly | ||||
| expressed in the first IF statement in the following table. | ||||
| 1. reject the operation and return the 'client-error-bad-request' | Each Job Template attribute MUST occur no more than once. If an IPP | |||
| error status code | Printer receives a create request with multiple occurrences of a Job | |||
| Template attribute, it MAY: | ||||
| 2. accept the operation and use the first occurrence of the | 1. reject the operation and return the 'client-error-bad-request' | |||
| attribute | error status code | |||
| 3. accept the operation and use the last occurrence of the | 2. accept the operation and use the first occurrence of the | |||
| attribute | attribute | |||
| Expires November 30, 2000 | 3. accept the operation and use the last occurrence of the | |||
| attribute | ||||
| depending on implementation. Therefore, clients MUST NOT supply | depending on implementation. Therefore, clients MUST NOT supply | |||
| multiple occurrences of the same Job Template attribute in the Job | multiple occurrences of the same Job Template attribute in the Job | |||
| Attributes group in the request. | Attributes group in the request. | |||
| 3.1.2.3 Algorithm for job validation | 3.1.2.3 Algorithm for job validation | |||
| The process of validating a Job-Template attribute "xxx" against a | The process of validating a Job-Template attribute "xxx" against a | |||
| Printer attribute "xxx-supported" can use the following validation | Printer attribute "xxx-supported" can use the following validation | |||
| algorithm (see section 3.2.1.2 in [ipp-mod]). | algorithm (see section 3.2.1.2 in [RFC2911]). | |||
| To validate the value U of Job-Template attribute "xxx" against the | To validate the value U of Job-Template attribute "xxx" against the | |||
| value V of Printer "xxx-supported", perform the following algorithm: | value V of Printer "xxx-supported", perform the following | |||
| algorithm: | ||||
| 1.If U is multi-valued, validate each value X of U by performing the | 1.If U is multi-valued, validate each value X of U by performing | |||
| algorithm in Table 7 with each value X. Each validation is separate | the algorithm in Table 7 with each value X. Each validation is | |||
| from the standpoint of returning unsupported values. Example: If U | separate from the standpoint of returning unsupported values. | |||
| is "finishings" that the client supplies with 'staple', 'bind' | Example: If U is "finishings" that the client supplies with | |||
| values, then X takes on the successive values: 'staple', then 'bind' | 'staple', 'bind' values, then X takes on the successive values: | |||
| 'staple', then 'bind' | ||||
| 2.If V is multi-valued, validate X against each Z of V by performing | 2.If V is multi-valued, validate X against each Z of V by | |||
| the algorithm in Table 7 with each value Z. If a value Z validates, | performing the algorithm in Table 7 with each value Z. If a | |||
| the validation for the attribute value X succeeds. If it fails, the | value Z validates, the validation for the attribute value X | |||
| algorithm is applied to the next value Z of V. If there are no more | succeeds. If it fails, the algorithm is applied to the next | |||
| values Z of V, validation fails. Example" If V is "sides-supported" | value Z of V. If there are no more values Z of V, validation | |||
| with values: 'one-sided', 'two-sided-long', and 'two-sided-short', | fails. Example" If V is "sides-supported" with values: 'one- | |||
| then Z takes on the successive values: 'one-sided', 'two-sided- | sided', 'two-sided-long', and 'two-sided-short', then Z takes on | |||
| long', and 'two-sided-short'. If the client supplies "sides" with | the successive values: 'one-sided', 'two-sided-long', and 'two- | |||
| 'two-sided-long', the first comparison fails ('one-sided' is not | sided-short'. If the client supplies "sides" with 'two-sided- | |||
| equal to 'two-sided-long'), the second comparison succeeds ('two- | long', the first comparison fails ('one-sided' is not equal to | |||
| sided-long' is equal to 'two-sided-long"), and the third comparison | 'two-sided-long'), the second comparison succeeds ('two-sided- | |||
| ('two-sided-short' with 'two-sided-long') is not even performed. | long' is equal to 'two-sided-long"), and the third comparison | |||
| ('two-sided-short' with 'two-sided-long') is not even performed. | ||||
| 3.If both U and V are single-valued, let X be U and Z be V and use the | 3.If both U and V are single-valued, let X be U and Z be V and use | |||
| validation rules in Table 7. | the validation rules in Table 7. | |||
| Table 7 - Rules for validating single values X against Z | Table 7 - Rules for validating single values X against Z | |||
| Attribute attribute validated if: | Attribute syntax attribute syntax validated if: | |||
| syntax of X syntax of Z | of X of Z | |||
| integer rangeOfInteger X is within the range of Z | integer rangeOfInteger X is within the range of Z | |||
| uri uriScheme the uri scheme in X is equal to Z | ||||
| any boolean the value of Z is TRUE | ||||
| any any X and Z are of the same type and are | ||||
| equal. | ||||
| Expires November 30, 2000 | uri uriScheme the uri scheme in X is equal to | |||
| Z | ||||
| If the value of the Printer object's "xxx-supported" attribute is 'no- | any boolean the value of Z is TRUE | |||
| value' (because the system administrator hasn't configured a value), the | ||||
| check always fails. If the check fails, the IPP object copies the | ||||
| attribute to the Unsupported Attributes response group with its | ||||
| unsupported value. If the attribute contains more than one value, each | ||||
| value is checked and each unsupported value is separately copied, while | ||||
| supported values are not copied. If an IPP object doesn't | ||||
| recognize/support a Job Template attribute, i.e., there is no | ||||
| corresponding Printer object "xxx-supported" attribute, the IPP object | ||||
| treats the attribute as an unknown or unsupported attribute (see the | ||||
| last row in the table below). | ||||
| If some Job Template attributes are supported for some document formats | any any X and Z are of the same type | |||
| and not for others or the values are different for different document | and are equal. | |||
| formats, the IPP object SHOULD take that into account in this validation | ||||
| using the value of the "document-format" supplied by the client (or | ||||
| defaulted to the value of the Printer's "document-format-default" | ||||
| attribute, if not supplied by the client). For example, if "number-up" | ||||
| is supported for the 'text/plain' document format, but not for the | ||||
| 'application/postscript' document format, the check SHOULD (though it | ||||
| NEED NOT) depend on the value of the "document-format" operation | ||||
| attribute. See "document-format" in [IPP-MOD] section 3.2.1.1 and | ||||
| 3.2.5.1. | ||||
| Note: whether the request is accepted or rejected is determined by the | If the value of the Printer object's "xxx-supported" attribute is | |||
| value of the "ipp-attribute-fidelity" attribute in a subsequent step, so | 'no-value' (because the system administrator hasn't configured a | |||
| that all Job Template attribute supplied are examined and all | value), the check always fails. If the check fails, the IPP object | |||
| unsupported attributes and/or values are copied to the Unsupported | copies the attribute to the Unsupported Attributes response group | |||
| Attributes response group. | with its unsupported value. If the attribute contains more than one | |||
| value, each value is checked and each unsupported value is separately | ||||
| copied, while supported values are not copied. If an IPP object | ||||
| doesn't recognize/support a Job Template attribute, i.e., there is no | ||||
| corresponding Printer object "xxx-supported" attribute, the IPP | ||||
| object treats the attribute as an unknown or unsupported attribute | ||||
| (see the last row in the table below). | ||||
| If some Job Template attributes are supported for some document | ||||
| formats and not for others or the values are different for different | ||||
| document formats, the IPP object SHOULD take that into account in | ||||
| this validation using the value of the "document-format" supplied by | ||||
| the client (or defaulted to the value of the Printer's "document- | ||||
| format-default" attribute, if not supplied by the client). For | ||||
| example, if "number-up" is supported for the 'text/plain' document | ||||
| format, but not for the 'application/postscript' document format, the | ||||
| check SHOULD (though it NEED NOT) depend on the value of the | ||||
| "document-format" operation attribute. See "document-format" in | ||||
| [RFC2911] section 3.2.1.1 and 3.2.5.1. | ||||
| job-priority (integer(1:100)) | Note: whether the request is accepted or rejected is determined by | |||
| the value of the "ipp-attribute-fidelity" attribute in a subsequent | ||||
| step, so that all Job Template attribute supplied are examined and | ||||
| all unsupported attributes and/or values are copied to the | ||||
| Unsupported Attributes response group. | ||||
| ----------------------------------------------- | ||||
| job-priority (integer(1:100)) | ||||
| IF NOT a single 'integer' value with a length equal to 4 octets, | IF NOT a single 'integer' value with a length equal to 4 octets, | |||
| REJECT/RETURN 'client-error-bad-request'. | REJECT/RETURN 'client-error-bad-request'. | |||
| IF NOT supplied by the client, use the value of the Printer | IF NOT supplied by the client, use the value of the Printer | |||
| object's "job-priority-default" attribute at job submission | object's "job-priority-default" attribute at job submission | |||
| time. | time. | |||
| IF NOT in the range 1 to 100, inclusive, copy the attribute and the | IF NOT in the range 1 to 100, inclusive, copy the attribute and the | |||
| unsupported value to the Unsupported Attributes response | unsupported value to the Unsupported Attributes response | |||
| group. | group. | |||
| Map the value to the nearest supported value in the range 1:100 as | Map the value to the nearest supported value in the range 1:100 as | |||
| specified by the number of discrete values indicated by the | specified by the number of discrete values indicated by the | |||
| value of the Printer's "job-priority-supported" attribute. | value of the Printer's "job-priority-supported" attribute. | |||
| See the formula in [IPP-MOD] Section 4.2.1. | See the formula in [RFC2911] Section 4.2.1. | |||
| Expires November 30, 2000 | ||||
| job-hold-until (type3 keyword | name) | job-hold-until (type3 keyword | name) | |||
| IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client- | IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client- | |||
| error-bad-request'. | error-bad-request'. | |||
| IF the value length is greater than 255 octets, REJECT/RETURN | IF the value length is greater than 255 octets, REJECT/RETURN | |||
| 'client-error-request-value-too-long'. | 'client-error-request-value-too-long'. | |||
| IF NOT supplied by the client, use the value of the Printer | IF NOT supplied by the client, use the value of the Printer | |||
| object's "job-hold-until" attribute at job submission time. | object's "job-hold-until" attribute at job submission time. | |||
| IF NOT in the Printer object's "job-hold-until-supported" | IF NOT in the Printer object's "job-hold-until-supported" | |||
| attribute, copy the attribute and the unsupported value to the | attribute, copy the attribute and the unsupported value to the | |||
| Unsupported Attributes response group. | Unsupported Attributes response group. | |||
| job-sheets (type3 keyword | name) | job-sheets (type3 keyword | name) | |||
| IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client- | IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client- | |||
| error-bad-request'. | error-bad-request'. | |||
| IF the value length is greater than 255 octets, REJECT/RETURN | IF the value length is greater than 255 octets, REJECT/RETURN | |||
| 'client-error-request-value-too-long'. | 'client-error-request-value-too-long'. | |||
| IF NOT in the Printer object's "job-sheets-supported" attribute, | IF NOT in the Printer object's "job-sheets-supported" attribute, | |||
| copy the attribute and the unsupported value to the | copy the attribute and the unsupported value to the | |||
| Unsupported Attributes response group. | Unsupported Attributes response group. | |||
| multiple-document-handling (type2 keyword) | multiple-document-handling (type2 keyword) | |||
| IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad- | IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad- | |||
| request'. | request'. | |||
| IF the value length is greater than 255 octets, REJECT/RETURN | IF the value length is greater than 255 octets, REJECT/RETURN | |||
| 'client-error-request-value-too-long'. | 'client-error-request-value-too-long'. | |||
| IF NOT in the Printer object's "multiple-document-handling- | IF NOT in the Printer object's "multiple-document-handling- | |||
| supported" attribute, copy the attribute and the unsupported | supported" attribute, copy the attribute and the unsupported | |||
| value to the Unsupported Attributes response group. | value to the Unsupported Attributes response group. | |||
| copies (integer(1:MAX)) | copies (integer(1:MAX)) | |||
| IF NOT a single 'integer' value with a length equal to 4 octets, | IF NOT a single 'integer' value with a length equal to 4 octets, | |||
| REJECT/RETURN 'client-error-bad-request'. | REJECT/RETURN 'client-error-bad-request'. | |||
| IF NOT in range of the Printer object's "copies-supported" | IF NOT in range of the Printer object's "copies-supported" | |||
| attribute | attribute | |||
| copy the attribute and the unsupported value to the Unsupported | copy the attribute and the unsupported value to the Unsupported | |||
| Attributes response group. | Attributes response group. | |||
| finishings (1setOf type2 enum) | finishings (1setOf type2 enum) | |||
| IF NOT an 'enum' value(s) each with a length equal to 4 octets, | IF NOT an 'enum' value(s) each with a length equal to 4 octets, | |||
| REJECT/RETURN 'client-error-bad-request'. | REJECT/RETURN 'client-error-bad-request'. | |||
| IF NOT in the Printer object's "finishings-supported" attribute, | IF NOT in the Printer object's "finishings-supported" attribute, | |||
| copy the attribute and the unsupported value(s), but not any | copy the attribute and the unsupported value(s), but not any | |||
| Expires November 30, 2000 | ||||
| supported values, to the Unsupported Attributes response | supported values, to the Unsupported Attributes response | |||
| group. | group. | |||
| page-ranges (1setOf rangeOfInteger(1:MAX)) | page-ranges (1setOf rangeOfInteger(1:MAX)) | |||
| IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8 | IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8 | |||
| octets, REJECT/RETURN 'client-error-bad-request'. | octets, REJECT/RETURN 'client-error-bad-request'. | |||
| IF first value is greater than second value in any range, the | IF first value is greater than second value in any range, the | |||
| ranges are not in ascending order, or ranges overlap, | ranges are not in ascending order, or ranges overlap, | |||
| REJECT/RETURN 'client-error-bad-request'. | REJECT/RETURN 'client-error-bad-request'. | |||
| IF the value of the Printer object's "page-ranges-supported" | IF the value of the Printer object's "page-ranges-supported" | |||
| attribute is 'false', copy the attribute to the Unsupported | attribute is 'false', copy the attribute to the Unsupported | |||
| Attributes response group and set the value to the "out-of- | Attributes response group and set the value to the "out-of- | |||
| band" 'unsupported' value. | band" 'unsupported' value. | |||
| sides (type2 keyword) | sides (type2 keyword) | |||
| IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad- | IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad- | |||
| request'. | request'. | |||
| IF the value length is greater than 255 octets, REJECT/RETURN | IF the value length is greater than 255 octets, REJECT/RETURN | |||
| 'client-error-request-value-too-long'. | 'client-error-request-value-too-long'. | |||
| IF NOT in the Printer object's "sides-supported" attribute, copy | IF NOT in the Printer object's "sides-supported" attribute, copy | |||
| the attribute and the unsupported value to the Unsupported | the attribute and the unsupported value to the Unsupported | |||
| Attributes response group. | Attributes response group. | |||
| number-up (integer(1:MAX)) | number-up (integer(1:MAX)) | |||
| IF NOT a single 'integer' value with a length equal to 4 octets, | IF NOT a single 'integer' value with a length equal to 4 octets, | |||
| REJECT/RETURN 'client-error-bad-request'. | REJECT/RETURN 'client-error-bad-request'. | |||
| IF NOT a value or in the range of one of the values of the Printer | IF NOT a value or in the range of one of the values of the Printer | |||
| object's "number-up-supported" attribute, copy the attribute | object's "number-up-supported" attribute, copy the attribute | |||
| and value to the Unsupported Attribute response group. | and value to the Unsupported Attribute response group. | |||
| orientation-requested (type2 enum) | orientation-requested (type2 enum) | |||
| IF NOT a single 'enum' value with a length equal to 4 octets, | IF NOT a single 'enum' value with a length equal to 4 octets, | |||
| REJECT/RETURN 'client-error-bad-request'. | REJECT/RETURN 'client-error-bad-request'. | |||
| IF NOT in the Printer object's "orientation-requested-supported" | IF NOT in the Printer object's "orientation-requested-supported" | |||
| attribute, copy the attribute and the unsupported value to the | attribute, copy the attribute and the unsupported value to the | |||
| Unsupported Attributes response group. | Unsupported Attributes response group. | |||
| media (type3 keyword | name) | media (type3 keyword | name) | |||
| IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client- | IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client- | |||
| error-bad-request'. | error-bad-request'. | |||
| IF the value length is greater than 255 octets, REJECT/RETURN | IF the value length is greater than 255 octets, REJECT/RETURN | |||
| 'client-error-request-value-too-long'. | 'client-error-request-value-too-long'. | |||
| Expires November 30, 2000 | ||||
| IF NOT in the Printer object's "media-supported" attribute, copy | IF NOT in the Printer object's "media-supported" attribute, copy | |||
| the attribute and the unsupported value to the Unsupported | the attribute and the unsupported value to the Unsupported | |||
| Attributes response group. | Attributes response group. | |||
| printer-resolution (resolution) | printer-resolution (resolution) | |||
| IF NOT a single 'resolution' value with a length equal to 9 octets, | IF NOT a single 'resolution' value with a length equal to 9 octets, | |||
| REJECT/RETURN 'client-error-bad-request'. | REJECT/RETURN 'client-error-bad-request'. | |||
| IF NOT in the Printer object's "printer-resolution-supported" | IF NOT in the Printer object's "printer-resolution-supported" | |||
| attribute, copy the attribute and the unsupported value to the | attribute, copy the attribute and the unsupported value to the | |||
| Unsupported Attributes response group. | Unsupported Attributes response group. | |||
| print-quality (type2 enum) | print-quality (type2 enum) | |||
| IF NOT a single 'enum' value with a length equal to 4 octets, | IF NOT a single 'enum' value with a length equal to 4 octets, | |||
| REJECT/RETURN 'client-error-bad-request'. | REJECT/RETURN 'client-error-bad-request'. | |||
| IF NOT in the Printer object's "print-quality-supported" attribute, | IF NOT in the Printer object's "print-quality-supported" attribute, | |||
| copy the attribute and the unsupported value to the | copy the attribute and the unsupported value to the | |||
| Unsupported Attributes response group. | Unsupported Attributes response group. | |||
| unknown or unsupported attribute (i.e., there is no corresponding | unknown or unsupported attribute (i.e., there is no corresponding | |||
| Printer object "xxx-supported" attribute) | Printer object "xxx-supported" attribute) | |||
| IF the attribute syntax supplied by the client is supported but the | IF the attribute syntax supplied by the client is supported but the | |||
| length is not legal for that attribute syntax, | length is not legal for that attribute syntax, | |||
| REJECT/RETURN 'client-error-bad-request' if the length of the | REJECT/RETURN 'client-error-bad-request' if the length of the | |||
| attribute syntax is fixed or 'client-error-request-value-too- | attribute syntax is fixed or 'client-error-request-value-too- | |||
| long' if the length of the attribute syntax is variable. | long' if the length of the attribute syntax is variable. | |||
| ELSE copy the attribute and value to the Unsupported Attributes | ELSE copy the attribute and value to the Unsupported Attributes | |||
| response group and change the attribute value to the "out-of- | response group and change the attribute value to the "out-of- | |||
| band" 'unsupported' value. Any remaining Job Template | band" 'unsupported' value. Any remaining Job Template | |||
| Attributes are either unknown or unsupported Job Template | Attributes are either unknown or unsupported Job Template | |||
| attributes and are validated algorithmically according to | attributes and are validated algorithmically according to | |||
| their attribute syntax for proper length (see below). | their attribute syntax for proper length (see below). | |||
| ----------------------------------------------- | ||||
| If the attribute syntax is supported AND the length check fails, the | ||||
| IPP object REJECTS the request and RETURNS the 'client-error-bad- | ||||
| request' if the length of the attribute syntax is fixed or the | ||||
| 'client-error-request-value-too-long' status code if the length of | ||||
| the attribute syntax is variable. Otherwise, the IPP object copies | ||||
| the unsupported Job Template attribute to the Unsupported Attributes | ||||
| response group and changes the attribute value to the "out-of-band" | ||||
| 'unsupported' value. The following table shows the length checks for | ||||
| all attribute syntaxes. In the following table: "<=" means less | ||||
| than or equal, "=" means equal to: | ||||
| Name Octet length check for read-write attributes | ||||
| If the attribute syntax is supported AND the length check fails, the IPP | ----------- -------------------------------------------- | |||
| object REJECTS the request and RETURNS the 'client-error-bad-request' if | 'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63 | |||
| the length of the attribute syntax is fixed or the 'client-error- | 'textWithoutLanguage' <= 1023 | |||
| request-value-too-long' status code if the length of the attribute | 'nameWithLanguage' <= 255 AND 'naturalLanguage' <= 63 | |||
| syntax is variable. Otherwise, the IPP object copies the unsupported Job | 'nameWithoutLanguage' <= 255 | |||
| Template attribute to the Unsupported Attributes response group and | 'keyword' <= 255 | |||
| changes the attribute value to the "out-of-band" 'unsupported' value. | 'enum' = 4 | |||
| The following table shows the length checks for all attribute syntaxes. | 'uri' <= 1023 | |||
| In the following table: "<=" means less than or equal, "=" means equal | 'uriScheme' <= 63 | |||
| to: | 'charset' <= 63 | |||
| 'naturalLanguage' <= 63 | ||||
| Name Octet length check for read-write attributes | 'mimeMediaType' <= 255 | |||
| 'octetString' <= 1023 | ||||
| Expires November 30, 2000 | 'boolean' = 1 | |||
| 'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63 | 'integer' = 4 | |||
| 'textWithoutLanguage' <= 1023 | 'rangeOfInteger' = 8 | |||
| 'nameWithLanguage' <= 255 AND 'naturalLanguage' <= 63 | 'dateTime' = 11 | |||
| 'nameWithoutLanguage' <= 255 | 'resolution' = 9 | |||
| 'keyword' <= 255 | '1setOf X' | |||
| 'enum' = 4 | ||||
| 'uri' <= 1023 | ||||
| 'uriScheme' <= 63 | ||||
| 'charset' <= 63 | ||||
| 'naturalLanguage' <= 63 | ||||
| 'mimeMediaType' <= 255 | ||||
| 'octetString' <= 1023 | ||||
| 'boolean' = 1 | ||||
| 'integer' = 4 | ||||
| 'rangeOfInteger' = 8 | ||||
| 'dateTime' = 11 | ||||
| 'resolution' = 9 | ||||
| '1setOf X' | ||||
| Note: It's possible for a Printer to receive a zero length keyword in a | Note: It's possible for a Printer to receive a zero length keyword | |||
| request. Since this is a keyword, its value needs to be compared with | in a request. Since this is a keyword, its value needs to be | |||
| the supported values. Assuming that the printer doesn't have any values | compared with the supported values. Assuming that the printer | |||
| in its corresponding "xxx-supported" attribute that are keywords of zero | doesn't have any values in its corresponding "xxx-supported" | |||
| length, the comparison will fail. Then the request will be accepted or | attribute that are keywords of zero length, the comparison will fail. | |||
| rejected depending on the value of "ipp-attributes-fidelity" being | Then the request will be accepted or rejected depending on the value | |||
| 'false' or 'true', respectively. No special handling is required for | of "ipp-attributes-fidelity" being 'false' or 'true', respectively. | |||
| No special handling is required for | ||||
| 3.1.2.3.1 Check for conflicting Job Template attributes values | 3.1.2.3.1 Check for conflicting Job Template attributes values | |||
| Once all the Operation and Job Template attributes have been checked | Once all the Operation and Job Template attributes have been checked | |||
| individually, the Printer object SHOULD check for any conflicting values | individually, the Printer object SHOULD check for any conflicting | |||
| among all the supported values supplied by the client. For example, a | values among all the supported values supplied by the client. For | |||
| Printer object might be able to staple and to print on transparencies, | example, a Printer object might be able to staple and to print on | |||
| however due to physical stapling constraints, the Printer object might | transparencies, however due to physical stapling constraints, the | |||
| not be able to staple transparencies. The IPP object copies the | Printer object might not be able to staple transparencies. The IPP | |||
| supported attributes and their conflicting attribute values to the | object copies the supported attributes and their conflicting | |||
| Unsupported Attributes response group. The Printer object only copies | attribute values to the Unsupported Attributes response group. The | |||
| over those attributes that the Printer object either ignores or | Printer object only copies over those attributes that the Printer | |||
| substitutes in order to resolve the conflict, and it returns the | object either ignores or substitutes in order to resolve the | |||
| original values which were supplied by the client. For example suppose | conflict, and it returns the original values which were supplied by | |||
| the client supplies "finishings" equals 'staple' and "media" equals | the client. For example suppose the client supplies "finishings" | |||
| 'transparency', but the Printer object does not support stapling | equals 'staple' and "media" equals 'transparency', but the Printer | |||
| transparencies. If the Printer chooses to ignore the stapling request | object does not support stapling transparencies. If the Printer | |||
| in order to resolve the conflict, the Printer objects returns | chooses to ignore the stapling request in order to resolve the | |||
| "finishings" equal to 'staple' in the Unsupported Attributes response | conflict, the Printer objects returns "finishings" equal to 'staple' | |||
| in the Unsupported Attributes response group. If any attributes are | ||||
| Expires November 30, 2000 | multi-valued, only the conflicting values of the attributes are | |||
| group. If any attributes are multi-valued, only the conflicting values | copied. | |||
| of the attributes are copied. | ||||
| Note: The decisions made to resolve the conflict (if there is a choice) | Note: The decisions made to resolve the conflict (if there is a | |||
| is implementation dependent. | choice) is implementation dependent. | |||
| 3.1.2.3.2 Decide whether to REJECT the request | 3.1.2.3.2 Decide whether to REJECT the request | |||
| If there were any unsupported Job Template attributes or | If there were any unsupported Job Template attributes or | |||
| unsupported/conflicting Job Template attribute values and the client | unsupported/conflicting Job Template attribute values and the client | |||
| supplied the "ipp-attribute-fidelity" attribute with the 'true' value, | supplied the "ipp-attribute-fidelity" attribute with the 'true' | |||
| the Printer object REJECTS the request and return the status code: | value, the Printer object REJECTS the request and return the status | |||
| code: | ||||
| 1. 'client-error-conflicting-attributes' status code, if there were | 1. 'client-error-conflicting-attributes' status code, if there were | |||
| any conflicts between attributes supplied by the client. | any conflicts between attributes supplied by the client. | |||
| 2. 'client-error-attributes-or-values-not-supported' status code, | 2. 'client-error-attributes-or-values-not-supported' status code, | |||
| otherwise. | otherwise. | |||
| Note: Unsupported Operation attributes or values that are returned do | Note: Unsupported Operation attributes or values that are returned | |||
| not affect the status returned in this step. If the unsupported | do not affect the status returned in this step. If the unsupported | |||
| Operation attribute was a serious error, the above already rejected the | Operation attribute was a serious error, the above already rejected | |||
| request in a previous step. If control gets to this step with | the request in a previous step. If control gets to this step with | |||
| unsupported Operation attributes being returned, they are not serious | unsupported Operation attributes being returned, they are not serious | |||
| errors. | errors. | |||
| In general, the final results of Job processing are unknown at Job | In general, the final results of Job processing are unknown at Job | |||
| submission time. The client has to rely on notifications or polling to | submission time. The client has to rely on notifications or polling | |||
| find out what happens at Job processing time. However, there are cases | to find out what happens at Job processing time. However, there are | |||
| in which some Printers can determine at Job submission time that Job | cases in which some Printers can determine at Job submission time | |||
| processing is going to fail. As an optimization, we'd like to have the | that Job processing is going to fail. As an optimization, we'd like | |||
| Printer reject the Job in these cases. | to have the Printer reject the Job in these cases. | |||
| There are three types of "processing" errors that might be detectable at | There are three types of "processing" errors that might be detectable | |||
| Job submission time: | at Job submission time: | |||
| 1. 'client-error-document-format-not-supported' : For the Print-Job, | 1. 'client-error-document-format-not-supported' : For the Print- | |||
| Send-Document, Print-URI, and Send-URI operations, if all these | Job, Send-Document, Print-URI, and Send-URI operations, if all these | |||
| conditions are true: | conditions are true: | |||
| - the Printer supports auto-sensing, | - the Printer supports auto-sensing, | |||
| - the request "document-format" operation attribute is | - the request "document-format" operation attribute is | |||
| 'application/octet-stream', | 'application/octet-stream', | |||
| - the Printer receives document data before responding, | - the Printer receives document data before responding, | |||
| - the Printer auto-senses the document format before responding, | - the Printer auto-senses the document format before responding, | |||
| - the sensed document format is not supported by the Printer | - the sensed document format is not supported by the Printer | |||
| then the Printer should respond with 'client-error-document-format-not- | then the Printer should respond with 'client-error-document-format- | |||
| supported' status. | not-supported' status. | |||
| Expires November 30, 2000 | 2. 'client-error-compression-error': For the Print-Job, Send- | |||
| 2. 'client-error-compression-error': For the Print-Job, Send-Document, | Document, Print-URI, and Send-URI operations, if all these | |||
| Print-URI, and Send-URI operations, if all these conditions are true: | conditions are true: | |||
| - the client supplies a supported value for the "compression" | - the client supplies a supported value for the "compression" | |||
| operation attribute in the request | operation attribute in the request | |||
| - the Printer receives document data before responding, | - the Printer receives document data before responding, | |||
| - the Printer attempts to decompress the document data before | - the Printer attempts to decompress the document data before | |||
| responding, | responding, | |||
| - the document data cannot be decompressed using the algorithm | - the document data cannot be decompressed using the algorithm | |||
| specified by the "compression" operation attribute | specified by the "compression" operation attribute | |||
| then the Printer should respond with 'client-error-compression-error' | then the Printer should respond with 'client-error-compression-error' | |||
| status. | status. | |||
| 3. 'client-error-document-access-error': For the Print-URI, and Send- | 3. 'client-error-document-access-error': For the Print-URI, and | |||
| URI operations, if the Printer attempts and fails to pull the referenced | Send-URI operations, if the Printer attempts and fails to pull the | |||
| document data before responding, it should respond with 'client-error- | referenced document data before responding, it should respond with | |||
| document-access-error' status. | 'client-error-document-access-error' status. | |||
| Some Printers are not able to detect these errors until Job processing | Some Printers are not able to detect these errors until Job | |||
| time. In that case, the errors are recorded in the corresponding job- | processing time. In that case, the errors are recorded in the | |||
| state and job-state reason attributes. (There is no standard way for a | corresponding job-state and job-state reason attributes. (There is | |||
| client to determine whether a Printer can detect these errors at Job | no standard way for a client to determine whether a Printer can | |||
| submission time.) For example, if auto-sensing happens AFTER the job is | detect these errors at Job submission time.) For example, if auto- | |||
| accepted (as opposed to auto-sensing at submit time before returning the | sensing happens AFTER the job is accepted (as opposed to auto-sensing | |||
| response), the implementation aborts the job, puts the job in the | at submit time before returning the response), the implementation | |||
| 'aborted' state and sets the 'unsupported-document-format' value in the | aborts the job, puts the job in the 'aborted' state and sets the | |||
| job's "job-state-reasons". | 'unsupported-document-format' value in the job's "job-state-reasons". | |||
| A client should always provide a valid "document-format" operation | A client should always provide a valid "document-format" operation | |||
| attribute whenever practical. In the absence of other information, a | attribute whenever practical. In the absence of other information, a | |||
| client itself may sniff the document data to determine document format. | client itself may sniff the document data to determine document | |||
| format. | ||||
| Auto sensing at Job submission time may be more difficult for the | Auto sensing at Job submission time may be more difficult for the | |||
| Printer when combined with compression. For auto-sensed Jobs, a client | Printer when combined with compression. For auto-sensed Jobs, a | |||
| may be better off deferring compression to the transfer protocol layer, | client may be better off deferring compression to the transfer | |||
| e.g.; by using the HTTP Content-Encoding header. | protocol layer, e.g.; by using the HTTP Content-Encoding header. | |||
| 3.1.2.3.3 For the Validate-Job operation, RETURN one of the success | 3.1.2.3.3 For the Validate-Job operation, RETURN one of the success | |||
| status codes | status codes | |||
| If the requested operation is the Validate-Job operation, the Printer | If the requested operation is the Validate-Job operation, the Printer | |||
| object returns: | object returns: | |||
| 1. the "successful-ok" status code, if there are no unsupported or | ||||
| conflicting Job Template attributes or values. | ||||
| 2. the "successful-ok-conflicting-attributes, if there are any | ||||
| conflicting Job Template attribute or values. | ||||
| Expires November 30, 2000 | ||||
| 3. the "successful-ok-ignored-or-substituted-attributes, if there are | 1. the "successful-ok" status code, if there are no unsupported or | |||
| only unsupported Job Template attributes or values. | conflicting Job Template attributes or values. | |||
| 2. the "successful-ok-conflicting-attributes, if there are any | ||||
| conflicting Job Template attribute or values. | ||||
| 3. the "successful-ok-ignored-or-substituted-attributes, if there | ||||
| are only unsupported Job Template attributes or values. | ||||
| Note: Unsupported Operation attributes or values that are returned do | Note: Unsupported Operation attributes or values that are returned | |||
| not affect the status returned in this step. If the unsupported | do not affect the status returned in this step. If the unsupported | |||
| Operation attribute was a serious error, the above already rejected the | Operation attribute was a serious error, the above already rejected | |||
| request in a previous step. If control gets to this step with | the request in a previous step. If control gets to this step with | |||
| unsupported Operation attributes being returned, they are not serious | unsupported Operation attributes being returned, they are not serious | |||
| errors. | errors. | |||
| 3.1.2.3.4 Create the Job object with attributes to support | 3.1.2.3.4 Create the Job object with attributes to support | |||
| If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied by | If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied | |||
| the client), the Printer object: | by the client), the Printer object: | |||
| 1. creates a Job object, assigns a unique value to the job's "job- | ||||
| uri" and "job-id" attributes, and initializes all of the job's | ||||
| other supported Job Description attributes. | ||||
| 2. removes all unsupported attributes from the Job object. | ||||
| 3. for each unsupported value, removes either the unsupported value | ||||
| or substitutes the unsupported attribute value with some supported | ||||
| value. If an attribute has no values after removing unsupported | ||||
| values from it, the attribute is removed from the Job object (so | ||||
| that the normal default behavior at job processing time will take | ||||
| place for that attribute). | ||||
| 4. for each conflicting value, removes either the conflicting value | ||||
| or substitutes the conflicting attribute value with some other | ||||
| supported value. If an attribute has no values after removing | ||||
| conflicting values from it, the attribute is removed from the Job | ||||
| object (so that the normal default behavior at job processing time | ||||
| will take place for that attribute). | ||||
| If there were no attributes or values flagged as unsupported, or the | 1. creates a Job object, assigns a unique value to the job's "job- | |||
| value of 'ipp-attribute-fidelity" was 'false', the Printer object is | uri" and "job-id" attributes, and initializes all of the job's | |||
| able to accept the create request and create a new Job object. If the | other supported Job Description attributes. | |||
| "ipp-attribute-fidelity" attribute is set to 'true', the Job Template | 2. removes all unsupported attributes from the Job object. | |||
| attributes that populate the new Job object are necessarily all the Job | 3. for each unsupported value, removes either the unsupported value | |||
| Template attributes supplied in the create request. If the "ipp- | or substitutes the unsupported attribute value with some | |||
| attribute-fidelity" attribute is set to 'false', the Job Template | supported value. If an attribute has no values after removing | |||
| attributes that populate the new Job object are all the client supplied | unsupported values from it, the attribute is removed from the | |||
| Job Template attributes that are supported or that have value | Job object (so that the normal default behavior at job | |||
| substitution. Thus, some of the requested Job Template attributes may | processing time will take place for that attribute). | |||
| not appear in the Job object because the Printer object did not support | 4. for each conflicting value, removes either the conflicting value | |||
| those attributes. The attributes that populate the Job object are | or substitutes the conflicting attribute value with some other | |||
| persistently stored with the Job object for that Job. A Get-Job- | supported value. If an attribute has no values after removing | |||
| conflicting values from it, the attribute is removed from the | ||||
| Job object (so that the normal default behavior at job | ||||
| processing time will take place for that attribute). | ||||
| Expires November 30, 2000 | If there were no attributes or values flagged as unsupported, or the | |||
| Attributes operation on that Job object will return only those | value of 'ipp-attribute-fidelity" was 'false', the Printer object is | |||
| attributes that are persistently stored with the Job object. | able to accept the create request and create a new Job object. If | |||
| the "ipp-attribute-fidelity" attribute is set to 'true', the Job | ||||
| Template attributes that populate the new Job object are necessarily | ||||
| all the Job Template attributes supplied in the create request. If | ||||
| the "ipp-attribute-fidelity" attribute is set to 'false', the Job | ||||
| Template attributes that populate the new Job object are all the | ||||
| client supplied Job Template attributes that are supported or that | ||||
| have value substitution. Thus, some of the requested Job Template | ||||
| attributes will not appear in the Job object because the Printer | ||||
| object did not support those attributes. The attributes that | ||||
| populate the Job object are persistently stored with the Job object | ||||
| for that Job. A Get-Job-Attributes operation on that Job object will | ||||
| return only those attributes that are persistently stored with the | ||||
| Job object. | ||||
| Note: All Job Template attributes that are persistently stored with the | Note: All Job Template attributes that are persistently stored with | |||
| Job object are intended to be "override values"; that is, they that take | the Job object are intended to be "override values"; that is, they | |||
| precedence over whatever other embedded instructions might be in the | that take precedence over whatever other embedded instructions might | |||
| document data itself. However, it is not possible for all Printer | be in the document data itself. However, it is not possible for all | |||
| objects to realize the semantics of "override". End users may query the | Printer objects to realize the semantics of "override". End users | |||
| Printer's "pdl-override-supported" attribute to determine if the Printer | may query the Printer's "pdl-override-supported" attribute to | |||
| either attempts or does not attempt to override document data | determine if the Printer either attempts or does not attempt to | |||
| instructions with IPP attributes. | override document data instructions with IPP attributes. | |||
| There are some cases, where a Printer supports a Job Template attribute | There are some cases, where a Printer supports a Job Template | |||
| and has an associated default value set for that attribute. In the case | attribute and has an associated default value set for that attribute. | |||
| where a client does not supply the corresponding attribute, the Printer | In the case where a client does not supply the corresponding | |||
| does not use its default values to populate Job attributes when creating | attribute, the Printer does not use its default values to populate | |||
| the new Job object; only Job Template attributes actually in the create | Job attributes when creating the new Job object; only Job Template | |||
| request are used to populate the Job object. The Printer's default | attributes actually in the create request are used to populate the | |||
| values are only used later at Job processing time if no other IPP | Job object. The Printer's default values are only used later at Job | |||
| attribute or instruction embedded in the document data is present. | processing time if no other IPP attribute or instruction embedded in | |||
| the document data is present. | ||||
| Note: If the default values associated with Job Template attributes that | Note: If the default values associated with Job Template attributes | |||
| the client did not supply were to be used to populate the Job object, | that the client did not supply were to be used to populate the Job | |||
| then these values would become "override values" rather than defaults. | object, then these values would become "override values" rather than | |||
| If the Printer supports the 'attempted' value of the "pdl-override- | defaults. If the Printer supports the 'attempted' value of the "pdl- | |||
| supported" attribute, then these override values could replace values | override-supported" attribute, then these override values could | |||
| specified within the document data. This is not the intent of the | replace values specified within the document data. This is not the | |||
| default value mechanism. A default value for an attribute is used only | intent of the default value mechanism. A default value for an | |||
| if the create request did not specify that attribute (or it was ignored | attribute is used only if the create request did not specify that | |||
| when allowed by "ipp-attribute-fidelity" being 'false') and no value was | attribute (or it was ignored when allowed by "ipp-attribute-fidelity" | |||
| provided within the content of the document data. | being 'false') and no value was provided within the content of the | |||
| document data. | ||||
| If the client does not supply a value for some Job Template attribute, | If the client does not supply a value for some Job Template | |||
| and the Printer does not support that attribute, as far as IPP is | attribute, and the Printer does not support that attribute, as far as | |||
| concerned, the result of processing that Job (with respect to the | IPP is concerned, the result of processing that Job (with respect to | |||
| missing attribute) is undefined. | the missing attribute) is undefined. | |||
| 3.1.2.3.5 Return one of the success status codes | 3.1.2.3.5 Return one of the success status codes | |||
| Once the Job object has been created, the Printer object accepts the | Once the Job object has been created, the Printer object accepts the | |||
| request and returns to the client: | request and returns to the client: | |||
| 1. the 'successful-ok' status code, if there are no unsupported or | ||||
| conflicting Job Template attributes or values. | ||||
| 2. the 'successful-ok-conflicting-attributes' status code, if there | ||||
| are any conflicting Job Template attribute or values. | ||||
| Expires November 30, 2000 | ||||
| 3. the 'successful-ok-ignored-or-substituted-attributes' status code, | 1. the 'successful-ok' status code, if there are no unsupported or | |||
| if there are only unsupported Job Template attributes or values. | conflicting Job Template attributes or values. | |||
| 2. the 'successful-ok-conflicting-attributes' status code, if there | ||||
| are any conflicting Job Template attribute or values. | ||||
| 3. the 'successful-ok-ignored-or-substituted-attributes' status | ||||
| code, if there are only unsupported Job Template attributes or | ||||
| values. | ||||
| Note: Unsupported Operation attributes or values that are returned do | Note: Unsupported Operation attributes or values that are returned | |||
| not affect the status returned in this step. If the unsupported | do not affect the status returned in this step. If the unsupported | |||
| Operation attribute was a serious error, the above already rejected the | Operation attribute was a serious error, the above already rejected | |||
| request in a previous step. If control gets to this step with | the request in a previous step. If control gets to this step with | |||
| unsupported Operation attributes being returned, they are not serious | unsupported Operation attributes being returned, they are not serious | |||
| errors. | errors. | |||
| The Printer object also returns Job status attributes that indicate the | The Printer object also returns Job status attributes that indicate | |||
| initial state of the Job ('pending', 'pending-held', 'processing', | the initial state of the Job ('pending', 'pending-held', | |||
| etc.), etc. See Print-Job Response, [IPP-MOD] section 3.2.1.2. | 'processing', etc.), etc. See Print-Job Response, [RFC2911] section | |||
| 3.2.1.2. | ||||
| 3.1.2.3.6 Accept appended Document Content | 3.1.2.3.6 Accept appended Document Content | |||
| The Printer object accepts the appended Document Content data and either | The Printer object accepts the appended Document Content data and | |||
| starts it printing, or spools it for later processing. | either starts it printing, or spools it for later processing. | |||
| 3.1.2.3.7 Scheduling and Starting to Process the Job | 3.1.2.3.7 Scheduling and Starting to Process the Job | |||
| The Printer object uses its own configuration and implementation | The Printer object uses its own configuration and implementation | |||
| specific algorithms for scheduling the Job in the correct processing | specific algorithms for scheduling the Job in the correct processing | |||
| order. Once the Printer object begins processing the Job, the Printer | order. Once the Printer object begins processing the Job, the | |||
| changes the Job's state to 'processing'. If the Printer object supports | Printer changes the Job's state to 'processing'. If the Printer | |||
| PDL override (the "pdl-override-supported" attribute set to | object supports PDL override (the "pdl-override-supported" attribute | |||
| 'attempted'), the implementation does its best to see that IPP | set to 'attempted'), the implementation does its best to see that IPP | |||
| attributes take precedence over embedded instructions in the document | attributes take precedence over embedded instructions in the document | |||
| data. | data. | |||
| 3.1.2.3.8 Completing the Job | 3.1.2.3.8 Completing the Job | |||
| The Printer object continues to process the Job until it can move the | The Printer object continues to process the Job until it can move the | |||
| Job into the 'completed' state. If an Cancel-Job operation is received, | Job into the 'completed' state. If an Cancel-Job operation is | |||
| the implementation eventually moves the Job into the 'canceled' state. | received, the implementation eventually moves the Job into the | |||
| If the system encounters errors during processing that do not allow it | 'canceled' state. If the system encounters errors during processing | |||
| to progress the Job into a completed state, the implementation halts all | that do not allow it to progress the Job into a completed state, the | |||
| processing, cleans up any resources, and moves the Job into the | implementation halts all processing, cleans up any resources, and | |||
| 'aborted' state. | moves the Job into the 'aborted' state. | |||
| 3.1.2.3.9 Destroying the Job after completion | 3.1.2.3.9 Destroying the Job after completion | |||
| Once the Job moves to the 'completed', 'aborted', or 'canceled' state, | Once the Job moves to the 'completed', 'aborted', or 'canceled' | |||
| it is an implementation decision as to when to destroy the Job object | state, it is an implementation decision as to when to destroy the Job | |||
| object and release all associated resources. Once the Job has been | ||||
| Expires November 30, 2000 | destroyed, the Printer would return either the "client-error-not- | |||
| and release all associated resources. Once the Job has been destroyed, | found" or "client-error-gone" status codes for operations directed at | |||
| the Printer would return either the "client-error-not-found" or "client- | that Job. | |||
| error-gone" status codes for operations directed at that Job. | ||||
| Note: the Printer object SHOULD NOT re-use a "job-uri" or "job-id" | Note: the Printer object SHOULD NOT re-use a "job-uri" or "job-id" | |||
| value for a sufficiently long time after a job has been destroyed, so | value for a sufficiently long time after a job has been destroyed, so | |||
| that stale references kept by clients are less likely to access the | that stale references kept by clients are less likely to access the | |||
| wrong (newer) job. | wrong (newer) job. | |||
| 3.1.2.3.10 Interaction with "ipp-attribute-fidelity" | 3.1.2.3.10 Interaction with "ipp-attribute-fidelity" | |||
| Some Printer object implementations may support "ipp-attribute-fidelity" | Some Printer object implementations may support "ipp-attribute- | |||
| set to 'true' and "pdl-override-supported" set to 'attempted' and yet | fidelity" set to 'true' and "pdl-override-supported" set to | |||
| still not be able to realize exactly what the client specifies in the | 'attempted' and yet still not be able to realize exactly what the | |||
| create request. This is due to legacy decisions and assumptions that | client specifies in the create request. This is due to legacy | |||
| have been made about the role of job instructions embedded within the | decisions and assumptions that have been made about the role of job | |||
| document data and external job instructions that accompany the document | instructions embedded within the document data and external job | |||
| data and how to handle conflicts between such instructions. The | instructions that accompany the document data and how to handle | |||
| inability to be 100% precise about how a given implementation will | conflicts between such instructions. The inability to be 100% | |||
| behave is also compounded by the fact that the two special attributes, | precise about how a given implementation will behave is also | |||
| "ipp-attribute-fidelity" and "pdl-"override-supported", apply to the | compounded by the fact that the two special attributes, "ipp- | |||
| whole job rather than specific values for each attribute. For example, | attribute-fidelity" and "pdl-"override-supported", apply to the whole | |||
| some implementations may be able to override almost all Job Template | job rather than specific values for each attribute. For example, some | |||
| attributes except for "number-up". Character Sets, natural languages, | implementations may be able to override almost all Job Template | |||
| and internationalization | attributes except for "number-up". Character Sets, natural languages, | |||
| and internationalization | ||||
| This section discusses character set support, natural language support | This section discusses character set support, natural language | |||
| and internationalization. | support and internationalization. | |||
| 3.1.2.3.11 Character set code conversion support | 3.1.2.3.11 Character set code conversion support | |||
| IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY | IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY | |||
| support additional charsets. It is RECOMMENDED that an IPP object also | support additional charsets. It is RECOMMENDED that an IPP object | |||
| support US-ASCII, since many clients support US-ASCII, and indicate that | also support US-ASCII, since many clients support US-ASCII, and | |||
| UTF-8 and US-ASCII are supported by populating the Printer's "charset- | indicate that UTF-8 and US-ASCII are supported by populating the | |||
| supported" with 'utf-8' and 'us-ascii' values. An IPP object is | Printer's "charset-supported" with 'utf-8' and 'us-ascii' values. An | |||
| required to code covert with as little loss as possible between the | IPP object is required to code covert with as little loss as possible | |||
| charsets that it supports, as indicated in the Printer's "charsets- | between the charsets that it supports, as indicated in the Printer's | |||
| supported" attribute. | "charsets-supported" attribute. | |||
| How should the server handle the situation where the "attributes- | How should the server handle the situation where the "attributes- | |||
| charset" of the response itself is "us-ascii", but one or more | charset" of the response itself is "us-ascii", but one or more | |||
| attributes in that response is in the "utf-8" format? | attributes in that response is in the "utf-8" format? | |||
| Expires November 30, 2000 | Example: Consider a case where a client sends a Print-Job request | |||
| Example: Consider a case where a client sends a Print-Job request with | with "utf-8" as the value of "attributes-charset" and with the "job- | |||
| "utf-8" as the value of "attributes-charset" and with the "job-name" | name" attribute supplied. Later another client submits a Get-Job- | |||
| attribute supplied. Later another client submits a Get-Job-Attribute or | Attribute or Get-Jobs request. This second request contains the | |||
| Get-Jobs request. This second request contains the "attributes-charset" | "attributes-charset" with value "us-ascii" and "requested-attributes" | |||
| with value "us-ascii" and "requested-attributes" attribute with exactly | attribute with exactly one value "job-name". | |||
| one value "job-name". | ||||
| According to the IPP-Mod document (section 3.1.4.2), the value of the | According to the RFC2911 document (section 3.1.4.2), the value of the | |||
| "attributes-charset" for the response of the second request must be "us- | "attributes-charset" for the response of the second request must be | |||
| ascii" since that is the charset specified in the request. The "job- | "us-ascii" since that is the charset specified in the request. The | |||
| name" value, however, is in "utf-8" format. Should the request be | "job-name" value, however, is in "utf-8" format. Should the request | |||
| rejected even though both "utf-8" and "us-ascii" charsets are supported | be rejected even though both "utf-8" and "us-ascii" charsets are | |||
| by the server? or should the "job-name" value be converted to "us-ascii" | supported by the server? or should the "job-name" value be converted | |||
| and return "successful-ok-conflicting-attributes" (0x0002) as the | to "us-ascii" and return "successful-ok-conflicting-attributes" | |||
| status code? | (0x0002) as the status code? | |||
| Answer: An IPP object that supports both utf-8 (REQUIRED) and us-ascii, | Answer: An IPP object that supports both utf-8 (REQUIRED) and us- | |||
| the second paragraph of section 3.1.4.2 applies so that the IPP object | ascii, the second paragraph of section 3.1.4.2 applies so that the | |||
| MUST accept the request, perform code set conversion between these two | IPP object MUST accept the request, perform code set conversion | |||
| charsets with "the highest fidelity possible" and return 'successful- | between these two charsets with "the highest fidelity possible" and | |||
| ok', rather than a warning 'successful-ok-conflicting-attributes, or an | return 'successful-ok', rather than a warning 'successful-ok- | |||
| error. The printer will do the best it can to convert between each of | conflicting-attributes, or an error. The printer will do the best it | |||
| the character sets that it supports--even if that means providing a | can to convert between each of the character sets that it supports-- | |||
| string of question marks because none of the characters are | even if that means providing a string of question marks because none | |||
| representable in US ASCII. If it can't perform such conversion, it MUST | of the characters are representable in US ASCII. If it can't perform | |||
| NOT advertise us-ascii as a value of its "attributes-charset-supported" | such conversion, it MUST NOT advertise us-ascii as a value of its | |||
| and MUST reject any request that requests 'us-ascii'. | "attributes-charset-supported" and MUST reject any request that | |||
| requests 'us-ascii'. | ||||
| One IPP object implementation strategy is to convert all request text | One IPP object implementation strategy is to convert all request text | |||
| and name values to a Unicode internal representation. This is 16-bit | and name values to a Unicode internal representation. This is 16-bit | |||
| and virtually universal. Then convert to the specified operation | and virtually universal. Then convert to the specified operation | |||
| attributes-charset on output. | attributes-charset on output. | |||
| Also it would be smarter for a client to ask for 'utf-8', rather than | Also it would be smarter for a client to ask for 'utf-8', rather than | |||
| 'us-ascii' and throw away characters that it doesn't understand, rather | 'us-ascii' and throw away characters that it doesn't understand, | |||
| than depending on the code conversion of the IPP object. | rather than depending on the code conversion of the IPP object. | |||
| 3.1.2.3.12 What charset to return when an unsupported charset is | 3.1.2.3.12 What charset to return when an unsupported charset is | |||
| requested (Issue 1.19)? | requested (Issue 1.19)? | |||
| Section 3.1.4.1 Request Operation attributes was clarified in November | Section 3.1.4.1 Request Operation attributes was clarified in | |||
| 1998 as follows: | November 1998 as follows: | |||
| All clients and IPP objects MUST support the 'utf-8' charset [RFC2044] | ||||
| and MAY support additional charsets provided that they are registered | ||||
| with IANA [IANA-CS]. If the Printer object does not support the client | ||||
| supplied charset value, the Printer object MUST reject the request, set | ||||
| Expires November 30, 2000 | All clients and IPP objects MUST support the 'utf-8' charset | |||
| the "attributes-charset" to 'utf-8' in the response, and return the | [RFC2044] and MAY support additional charsets provided that they are | |||
| 'client-error-charset-not-supported' status code and any 'text' or | registered with IANA [IANA-CS]. If the Printer object does not | |||
| 'name' attributes using the 'utf-8' charset. | support the client supplied charset value, the Printer object MUST | |||
| reject the request, set the "attributes-charset" to 'utf-8' in the | ||||
| response, and return the 'client-error-charset-not-supported' status | ||||
| code and any 'text' or 'name' attributes using the 'utf-8' charset. | ||||
| Since the client and IPP object MUST support UTF-8, returning any text | Since the client and IPP object MUST support UTF-8, returning any | |||
| or name attributes in UTF-8 when the client requests a charset that is | text or name attributes in UTF-8 when the client requests a charset | |||
| not supported should allow the client to display the text or name. | that is not supported should allow the client to display the text or | |||
| name. | ||||
| Since such an error is a client error, rather than a user error, the | Since such an error is a client error, rather than a user error, the | |||
| client should check the status code first so that it can avoid | client should check the status code first so that it can avoid | |||
| displaying any other returned 'text' and 'name' attributes that are not | displaying any other returned 'text' and 'name' attributes that are | |||
| in the charset requested. | not in the charset requested. | |||
| Furthermore, [ipp-mod] section 14.1.4.14 client-error-charset-not- | Furthermore, [RFC2911] section 14.1.4.14 client-error-charset-not- | |||
| supported (0x040D) was clarified in November 1998 as follows: | supported (0x040D) was clarified in November 1998 as follows: | |||
| For any operation, if the IPP Printer does not support the charset | For any operation, if the IPP Printer does not support the charset | |||
| supplied by the client in the "attributes-charset" operation attribute, | supplied by the client in the "attributes-charset" operation | |||
| the Printer MUST reject the operation and return this status and any | attribute, the Printer MUST reject the operation and return this | |||
| 'text' or 'name' attributes using the 'utf-8' charset (see Section | status and any 'text' or 'name' attributes using the 'utf-8' charset | |||
| 3.1.4.1). | (see Section 3.1.4.1). | |||
| 3.1.2.3.13 Natural Language Override (NLO) | 3.1.2.3.13 Natural Language Override (NLO) | |||
| The 'text' and 'name' attributes each have two forms. One has an | The 'text' and 'name' attributes each have two forms. One has an | |||
| implicit natural language, and the other has an explicit natural | implicit natural language, and the other has an explicit natural | |||
| language. The 'textWithoutLanguage' and 'textWithLanguage' are the two | language. The 'textWithoutLanguage' and 'textWithLanguage' are the | |||
| 'text' forms. The 'nameWithoutLanguage" and 'nameWithLanguage are the | two 'text' forms. The 'nameWithoutLanguage" and 'nameWithLanguage | |||
| two 'name' forms. If a receiver (IPP object or IPP client) supports an | are the two 'name' forms. If a receiver (IPP object or IPP client) | |||
| attribute with attribute syntax 'text', it MUST support both forms in a | supports an attribute with attribute syntax 'text', it MUST support | |||
| request and a response. A sender (IPP client or IPP object) MAY send | both forms in a request and a response. A sender (IPP client or IPP | |||
| either form for any such attribute. When a sender sends a | object) MAY send either form for any such attribute. When a sender | |||
| WithoutLanguage form, the implicit natural language is specified in the | sends a WithoutLanguage form, the implicit natural language is | |||
| "attributes-natural-language" operation attribute, which all senders | specified in the "attributes-natural-language" operation attribute, | |||
| MUST include in every request and response. | which all senders MUST include in every request and response. | |||
| When a sender sends a WithLanguage form, it MAY be different from the | ||||
| implicit natural language supplied by the sender or it MAY be the same. | ||||
| The receiver MUST treat either form equivalently. | ||||
| There is an implementation decision for senders, whether to always send | When a sender sends a WithLanguage form, it MAY be different from the | |||
| the WithLanguage forms or use the WithoutLanguage form when the | implicit natural language supplied by the sender or it MAY be the | |||
| attribute's natural language is the same as the request or response. | same. The receiver MUST treat either form equivalently. | |||
| The former approach makes the sender implementation simpler. The latter | ||||
| approach is more efficient on the wire and allows inter-working with | ||||
| non-conforming receivers that fail to support the WithLanguage forms. | ||||
| Expires November 30, 2000 | There is an implementation decision for senders, whether to always | |||
| As each approach have advantages, the choice is completely up to the | send the WithLanguage forms or use the WithoutLanguage form when the | |||
| implementer of the sender. | attribute's natural language is the same as the request or response. | |||
| The former approach makes the sender implementation simpler. The | ||||
| latter approach is more efficient on the wire and allows inter- | ||||
| working with non-conforming receivers that fail to support the | ||||
| WithLanguage forms. As each approach have advantages, the choice is | ||||
| completely up to the implementer of the sender. | ||||
| Furthermore, when a client receives a 'text' or 'name' job attribute | Furthermore, when a client receives a 'text' or 'name' job attribute | |||
| that it had previously supplied, that client MUST NOT expect to see the | that it had previously supplied, that client MUST NOT expect to see | |||
| attribute in the same form, i.e., in the same WithoutLanguage or | the attribute in the same form, i.e., in the same WithoutLanguage or | |||
| WithLanguage form as the client supplied when it created the job. The | WithLanguage form as the client supplied when it created the job. | |||
| IPP object is free to transform the attribute from the WithLanguage form | The IPP object is free to transform the attribute from the | |||
| to the WithoutLanguage form and vice versa, as long as the natural | WithLanguage form to the WithoutLanguage form and vice versa, as long | |||
| language is preserved. However, in order to meet this latter | as the natural language is preserved. However, in order to meet this | |||
| requirement, it is usually simpler for the IPP object implementation to | latter requirement, it is usually simpler for the IPP object | |||
| store the natural language explicitly with the attribute value, i.e., to | implementation to store the natural language explicitly with the | |||
| store using an internal representation that resembles the WithLanguage | attribute value, i.e., to store using an internal representation that | |||
| form. | resembles the WithLanguage form. | |||
| The IPP Printer MUST copy the natural language of a job, i.e., the value | The IPP Printer MUST copy the natural language of a job, i.e., the | |||
| of the "attributes-natural-language" operation attribute supplied by the | value of the "attributes-natural-language" operation attribute | |||
| client in the create operation, to the Job object as a Job Description | supplied by the client in the create operation, to the Job object as | |||
| attribute, so that a client is able to query it. In returning a Get- | a Job Description attribute, so that a client is able to query it. | |||
| Job-Attributes response, the IPP object MAY return one of three natural | In returning a Get-Job-Attributes response, the IPP object MAY return | |||
| language values in the response's "attributes-natural-language" | one of three natural language values in the response's "attributes- | |||
| operation attribute: (1) that requested by the requester, (2) the | natural-language" operation attribute: (1) that requested by the | |||
| natural language of the job, or (3) the configured natural language of | requester, (2) the natural language of the job, or (3) the configured | |||
| the IPP Printer, if the requested language is not supported by the IPP | natural language of the IPP Printer, if the requested language is not | |||
| Printer. | supported by the IPP Printer. | |||
| This "attributes-natural-language" Job Description attribute is useful | This "attributes-natural-language" Job Description attribute is | |||
| for an IPP object implementation that prints start sheets in the | useful for an IPP object implementation that prints start sheets in | |||
| language of the user who submitted the job. This same Job Description | the language of the user who submitted the job. This same Job | |||
| attribute is useful to a multi-lingual operator who has to communicate | Description attribute is useful to a multi-lingual operator who has | |||
| with different job submitters in different natural languages. This same | to communicate with different job submitters in different natural | |||
| Job Description attribute is expected to be used in the future to | languages. This same Job Description attribute is expected to be | |||
| generate notification messages in the natural language of the job | used in the future to generate notification messages in the natural | |||
| submitter. | language of the job submitter. | |||
| Early drafts of [IPP-MOD] contained a job-level natural language | Early drafts of [RFC2911] contained a job-level natural language | |||
| override (NLO) for the Get-Jobs response. A job-level (NLO) is an | override (NLO) for the Get-Jobs response. A job-level (NLO) is an | |||
| (unrequested) Job Attribute which then specified the implicit natural | (unrequested) Job Attribute which then specified the implicit natural | |||
| language for any other WithoutLanguage job attributes returned in the | language for any other WithoutLanguage job attributes returned in the | |||
| response for that job. Interoperability testing of early | response for that job. Interoperability testing of early | |||
| implementations showed that no one was implementing the job-level NLO in | implementations showed that no one was implementing the job-level NLO | |||
| Get-Job responses. So the job-level NLO was eliminated from the Get- | in Get-Job responses. So the job-level NLO was eliminated from the | |||
| Jobs response. This simplification makes all requests and responses | Get-Jobs response. This simplification makes all requests and | |||
| consistent in that the implicit natural language for any WithoutLanguage | responses consistent in that the implicit natural language for any | |||
| 'text' or 'name' form is always supplied in the request's or response's | WithoutLanguage 'text' or 'name' form is always supplied in the | |||
| "attributes-natural-language" operation attribute. | request's or response's "attributes-natural-language" operation | |||
| attribute. | ||||
| Expires November 30, 2000 | 3.1.3 Status codes returned by operation | |||
| 3.1.3 Status codes returned by operation | ||||
| This section corresponds to [IPP-MOD] section 3.1.6 "Operation Response | This section corresponds to [RFC2911] section 3.1.6 "Operation | |||
| Status Codes and Status Messages". This section lists all status codes | Response Status Codes and Status Messages". This section lists all | |||
| once in the first operation (Print-Job). Then it lists the status codes | status codes once in the first operation (Print-Job). Then it lists | |||
| that are different or specialized for subsequent operations under each | the status codes that are different or specialized for subsequent | |||
| operation. | operations under each operation. | |||
| 3.1.3.1 Printer Operations | 3.1.3.1 Printer Operations | |||
| 3.1.3.1.1 Print-Job | 3.1.3.1.1 Print-Job | |||
| The Printer object MUST return one of the following "status-code" values | The Printer object MUST return one of the following "status-code" | |||
| for the indicated reason. Whether all of the document data has been | values for the indicated reason. Whether all of the document data | |||
| accepted or not before returning the success or error response depends | has been accepted or not before returning the success or error | |||
| on implementation. See Section 13 in [IPP-MOD] for a more complete | response depends on implementation. See Section 13 in [RFC2911] for | |||
| description of each status code. | a more complete description of each status code. | |||
| For the following success status codes, the Job object has been created | For the following success status codes, the Job object has been | |||
| and the "job-id", and "job-uri" assigned and returned in the response: | created and the "job-id", and "job-uri" assigned and returned in the | |||
| response: | ||||
| successful-ok: no request attributes were substituted or ignored. | successful-ok: no request attributes were substituted or ignored. | |||
| successful-ok-ignored-or-substituted-attributes: some supplied (1) | successful-ok-ignored-or-substituted-attributes: some supplied (1) | |||
| attributes were ignored or (2) unsupported attribute syntaxes or | attributes were ignored or (2) unsupported attribute syntaxes or | |||
| values were substituted with supported values or were ignored. | values were substituted with supported values or were ignored. | |||
| Unsupported attributes, attribute syntax's, or values MUST be | Unsupported attributes, attribute syntax's, or values MUST be | |||
| returned in the Unsupported Attributes group of the response. | returned in the Unsupported Attributes group of the response. | |||
| successful-ok-conflicting-attributes: some supplied attribute values | successful-ok-conflicting-attributes: some supplied attribute | |||
| conflicted with the values of other supplied attributes and were | values conflicted with the values of other supplied attributes | |||
| either substituted or ignored. Attributes or values which conflict | and were either substituted or ignored. Attributes or values | |||
| with other attributes and have been substituted or ignored MUST be | which conflict with other attributes and have been substituted | |||
| returned in the Unsupported Attributes group of the response as | or ignored MUST be returned in the Unsupported Attributes group | |||
| supplied by the client. | of the response as supplied by the client. | |||
| [ipp-mod] section 3.1.6 Operation Status Codes and Messages states: | [RFC2911] section 3.1.6 Operation Status Codes and Messages states: | |||
| If the Printer object supports the "status-message" operation attribute, | If the Printer object supports the "status-message" operation | |||
| it SHOULD use the REQUIRED 'utf-8' charset to return a status message | attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a | |||
| for the following error status codes (see section 13 in [IPP-MOD]): | status message for the following error status codes (see section 13 | |||
| 'client-error-bad-request', 'client-error-charset-not-supported', | in [RFC2911]): 'client-error-bad-request', 'client-error-charset- | |||
| 'server-error-internal-error', 'server-error-operation-not-supported', | not-supported', 'server-error-internal-error', 'server-error- | |||
| and 'server-error-version-not-supported'. In this case, it MUST set the | operation-not-supported', and 'server-error-version-not-supported'. | |||
| value of the "attributes-charset" operation attribute to 'utf-8' in the | In this case, it MUST set the value of the "attributes-charset" | |||
| error response. | operation attribute to 'utf-8' in the error response. | |||
| Expires November 30, 2000 | For the following error status codes, no job is created and no | |||
| For the following error status codes, no job is created and no "job-id" | "job-id" or "job-uri" is returned: | |||
| or "job-uri" is returned: | ||||
| client-error-bad-request: The request syntax does not conform to the | client-error-bad-request: The request syntax does not conform | |||
| specification. | to the specification. | |||
| client-error-forbidden: The request is being refused for | client-error-forbidden: The request is being refused for | |||
| authorization or authentication reasons. The implementation | authorization or authentication reasons. The implementation | |||
| security policy is to not reveal whether the failure is one of | security policy is to not reveal whether the failure is one of | |||
| authentication or authorization. | authentication or authorization. | |||
| client-error-not-authenticated: Either the request requires | client-error-not-authenticated: Either the request requires | |||
| authentication information to be supplied or the authentication | authentication information to be supplied or the | |||
| information is not sufficient for authorization. | authentication information is not sufficient for | |||
| client-error-not-authorized: The requester is not authorized to | authorization. | |||
| perform the request on the target object. | client-error-not-authorized: The requester is not authorized to | |||
| client-error-not-possible: The request cannot be carried out because | perform the request on the target object. | |||
| of the state of the system. See also 'server-error-not-accepting- | client-error-not-possible: The request cannot be carried out | |||
| jobs' status code, which MUST take precedence if the Printer | because of the state of the system. See also 'server-error- | |||
| object's "printer-accepting-jobs" attribute is 'false'. | not-accepting-jobs' status code, which MUST take precedence if | |||
| client-error-timeout: not applicable. | the Printer object's "printer-accepting-jobs" attribute is | |||
| client-error-not-found: the target object does not exist. | 'false'. | |||
| client-error-gone: the target object no longer exists and no | client-error-timeout: not applicable. | |||
| forwarding address is known. | client-error-not-found: the target object does not exist. | |||
| client-error-request-entity-too-large: the size of the request | client-error-gone: the target object no longer exists and no | |||
| and/or print data exceeds the capacity of the IPP Printer to | forwarding address is known. | |||
| process it. | client-error-request-entity-too-large: the size of the request | |||
| client-error-request-value-too-long: the size of request variable | and/or print data exceeds the capacity of the IPP Printer to | |||
| length attribute values, such as 'text' and 'name' attribute | process it. | |||
| syntax's, exceed the maximum length specified in [IPP-MOD] for the | client-error-request-value-too-long: the size of request | |||
| attribute and MUST be returned in the Unsupported Attributes Group. | variable length attribute values, such as 'text' and 'name' | |||
| client-error-document-format-not-supported: the document format | attribute syntax's, exceed the maximum length specified in | |||
| supplied is not supported. The "document-format" attribute with | [RFC2911] for the attribute and MUST be returned in the | |||
| the unsupported value MUST be returned in the Unsupported | Unsupported Attributes Group. | |||
| Attributes Group. This error SHOULD take precedence over any other | client-error-document-format-not-supported: the document format | |||
| 'xxx-not-supported' error, except 'client-error-charset-not- | supplied is not supported. The "document-format" attribute | |||
| supported'. | with the unsupported value MUST be returned in the Unsupported | |||
| client-error-attributes-or-values-not-supported: one or more | Attributes Group. This error SHOULD take precedence over any | |||
| supplied attributes, attribute syntax's, or values are not | other 'xxx-not-supported' error, except 'client-error-charset- | |||
| supported and the client supplied the "ipp-attributes-fidelity" | not-supported'. | |||
| operation attribute with a 'true' value. They MUST be returned in | client-error-attributes-or-values-not-supported: one or more | |||
| the Unsupported Attributes Group as explained below. | supplied attributes, attribute syntax's, or values are not | |||
| client-error-uri-scheme-not-supported: not applicable. | supported and the client supplied the "ipp-attributes- | |||
| client-error-charset-not-supported: the charset supplied in the | fidelity" operation attribute with a 'true' value. They MUST | |||
| "attributes-charset" operation attribute is not supported. The | be returned in the Unsupported Attributes Group as explained | |||
| Printer's "configured-charset" MUST be returned in the response as | below. | |||
| the value of the "attributes-charset" operation attribute and used | client-error-uri-scheme-not-supported: not applicable. | |||
| for any 'text' and 'name' attributes returned in the error | ||||
| response. This error SHOULD take precedence over any other error, | ||||
| Expires November 30, 2000 | client-error-charset-not-supported: the charset supplied in the | |||
| unless the request syntax is so bad that the client's supplied | "attributes-charset" operation attribute is not supported. | |||
| "attributes-charset" cannot be determined. | The Printer's "configured-charset" MUST be returned in the | |||
| client-error-conflicting-attributes: one or more supplied attribute | response as the value of the "attributes-charset" operation | |||
| values conflicted with each other and the client supplied the "ipp- | attribute and used for any 'text' and 'name' attributes | |||
| attributes-fidelity" operation attribute with a 'true' value. They | returned in the error response. This error SHOULD take | |||
| MUST be returned in the Unsupported Attributes Group as explained | precedence over any other error, unless the request syntax is | |||
| below. | so bad that the client's supplied "attributes-charset" cannot | |||
| server-error-internal-error: an unexpected condition prevents the | be determined. | |||
| request from being fulfilled. | client-error-conflicting-attributes: one or more supplied | |||
| server-error-operation-not-supported: not applicable (since Print- | attribute values conflicted with each other and the client | |||
| Job is REQUIRED). | supplied the "ipp-attributes-fidelity" operation attribute | |||
| server-error-service-unavailable: the service is temporarily | with a 'true' value. They MUST be returned in the Unsupported | |||
| overloaded. | Attributes Group as explained below. | |||
| server-error-version-not-supported: the version in the request is | server-error-internal-error: an unexpected condition prevents | |||
| not supported. The "closest" version number supported MUST be | the request from being fulfilled. | |||
| returned in the response. | server-error-operation-not-supported: not applicable (since | |||
| server-error-device-error: a device error occurred while receiving | Print-Job is REQUIRED). | |||
| or spooling the request or document data or the IPP Printer object | server-error-service-unavailable: the service is temporarily | |||
| can only accept one job at a time. | overloaded. | |||
| server-error-temporary-error: a temporary error such as a buffer | server-error-version-not-supported: the version in the request | |||
| full write error, a memory overflow, or a disk full condition | is not supported. The "closest" version number supported MUST | |||
| occurred while receiving the request and/or the document data. | be returned in the response. | |||
| server-error-not-accepting-jobs: the Printer object's "printer-is- | server-error-device-error: a device error occurred while | |||
| not-accepting-jobs" attribute is 'false'. | receiving or spooling the request or document data or the IPP | |||
| server-error-busy: the Printer is too busy processing jobs to accept | Printer object can only accept one job at a time. | |||
| another job at this time. | server-error-temporary-error: a temporary error such as a | |||
| server-error-job-canceled: the job has been canceled by an operator | buffer full write error, a memory overflow, or a disk full | |||
| or the system while the client was transmitting the document data. | condition occurred while receiving the request and/or the | |||
| document data. | ||||
| server-error-not-accepting-jobs: the Printer object's "printer- | ||||
| is-not-accepting-jobs" attribute is 'false'. | ||||
| server-error-busy: the Printer is too busy processing jobs to | ||||
| accept another job at this time. | ||||
| server-error-job-canceled: the job has been canceled by an | ||||
| operator or the system while the client was transmitting the | ||||
| document data. | ||||
| 3.1.3.1.2 Print-URI | 3.1.3.1.2 Print-URI | |||
| All of the Print-Job status codes described in Section 3.1.3.1.1 Print- | All of the Print-Job status codes described in Section 3.1.3.1.1 | |||
| Job Response are applicable to Print-URI with the following | Print-Job Response are applicable to Print-URI with the following | |||
| specializations and differences. See Section 14 for a more complete | specializations and differences. See Section 14 for a more complete | |||
| description of each status code. | description of each status code. | |||
| client-error-uri-scheme-not-supported: the URI scheme supplied in | client-error-uri-scheme-not-supported: the URI scheme supplied in | |||
| the "document-uri" operation attribute is not supported and is | the "document-uri" operation attribute is not supported and is | |||
| returned in the Unsupported Attributes group. | returned in the Unsupported Attributes group. | |||
| server-error-operation-not-supported: the Print-URI operation is not | server-error-operation-not-supported: the Print-URI operation is | |||
| supported. | not supported. | |||
| 3.1.3.1.3 Validate-Job | 3.1.3.1.3 Validate-Job | |||
| Expires November 30, 2000 | All of the Print-Job status codes described in Section 3.1.3.1.1 | |||
| All of the Print-Job status codes described in Section 3.1.3.1.1 Print- | Print-Job Response are applicable to Validate-Job. See Section 13 in | |||
| Job Response are applicable to Validate-Job. See Section 13 in [IPP- | [RFC2911] for a more complete description of each status code. | |||
| MOD] for a more complete description of each status code. | ||||
| 3.1.3.1.4 Create-Job | 3.1.3.1.4 Create-Job | |||
| All of the Print-Job status codes described in Section 3.1.3.1.1 Print- | All of the Print-Job status codes described in Section 3.1.3.1.1 | |||
| Job Response are applicable to Create-Job with the following | Print-Job Response are applicable to Create-Job with the following | |||
| specializations and differences. See Section 13 in [IPP-MOD] for a more | specializations and differences. See Section 13 in [RFC2911] for a | |||
| complete description of each status code. | more complete description of each status code. | |||
| server-error-operation-not-supported: the Create-Job operation is | server-error-operation-not-supported: the Create-Job operation is | |||
| not supported. | not supported. | |||
| client-error-multiple-document-jobs-not-supported: while the Create- | client-error-multiple-document-jobs-not-supported: while the | |||
| Job and Send-Document operations are supported, this implementation | Create-Job and Send-Document operations are supported, this | |||
| doesn't support more than one document with data. | implementation doesn't support more than one document with data. | |||
| 3.1.3.1.5 Get-Printer-Attributes | 3.1.3.1.5 Get-Printer-Attributes | |||
| All of the Print-Job status codes described in Section 3.1.3.1.1 Print- | All of the Print-Job status codes described in Section 3.1.3.1.1 | |||
| Job Response are applicable to the Get-Printer-Attributes operation with | Print-Job Response are applicable to the Get-Printer-Attributes | |||
| the following specialization's and differences. See Section 13 in | operation with the following specialization's and differences. See | |||
| [IPP-MOD] for a more complete description of each status code. | Section 13 in [RFC2911] for a more complete description of each | |||
| status code. | ||||
| For the following success status codes, the requested attributes are | ||||
| returned in Group 3 in the response: | ||||
| successful-ok: no request attributes were substituted or ignored | For the following success status codes, the requested attributes are | |||
| (same as Print-Job) and no requested attributes were unsupported. | returned in Group 3 in the response: | |||
| successful-ok-ignored-or-substituted-attributes: same as Print-Job, | ||||
| except the "requested-attributes" operation attribute MAY, but NEED | ||||
| NOT, be returned with the unsupported values. | ||||
| successful-ok-conflicting-attributes: same as Print-Job. | ||||
| For the error status codes, Group 3 is returned containing no attributes | successful-ok: no operation attributes or values were substituted | |||
| or is not returned at all: | or ignored (same as Print-Job) and no requested attributes were | |||
| unsupported. | ||||
| successful-ok-ignored-or-substituted-attributes: The "requested- | ||||
| attributes" operation attribute MAY, but NEED NOT, be returned | ||||
| with the unsupported values. | ||||
| successful-ok-conflicting-attributes: same as Print-Job. | ||||
| client-error-not-possible: Same as Print-Job, in addition the | For the error status codes, Group 3 is returned containing no | |||
| Printer object is not accepting any requests. | attributes or is not returned at all: | |||
| client-error-request-entity-too-large: same as Print-job, except | ||||
| that no print data is involved. | ||||
| client-error-attributes-or-values-not-supported: not applicable, | ||||
| since unsupported operation attributes MUST be ignored and | ||||
| 'successful-ok-ignored-or-substituted-attributes' returned. | ||||
| client-error-conflicting-attributes: same as Print-Job, except that | ||||
| "ipp-attribute-fidelity" is not involved. | ||||
| server-error-operation-not-supported: not applicable (since Get- | ||||
| Printer-Attributes is REQUIRED). | ||||
| Expires November 30, 2000 | client-error-not-possible: Same as Print-Job, in addition the | |||
| Printer object is not accepting any requests. | ||||
| client-error-request-entity-too-large: same as Print-job, except | ||||
| that no print data is involved. | ||||
| server-error-device-error: same as Print-Job, except that no | client-error-attributes-or-values-not-supported: not applicable, | |||
| document data is involved. | since unsupported operation attributes and/or values MUST be | |||
| server-error-temporary-error: same as Print-Job, except that no | ignored and an appropriate success code returned (see above). | |||
| document data is involved. | client-error-conflicting-attributes: same as Print-Job, except | |||
| server-error-not-accepting-jobs: not applicable.. | that "ipp-attribute-fidelity" is not involved. | |||
| server-error-busy: same as Print-Job, except the IPP object is too | server-error-operation-not-supported: not applicable (since Get- | |||
| busy to accept even query requests. | Printer-Attributes is REQUIRED). | |||
| server-error-job-canceled: not applicable.. | server-error-device-error: same as Print-Job, except that no | |||
| document data is involved. | ||||
| server-error-temporary-error: same as Print-Job, except that no | ||||
| document data is involved. | ||||
| server-error-not-accepting-jobs: not applicable. | ||||
| server-error-busy: same as Print-Job, except the IPP object is too | ||||
| busy to accept even query requests. | ||||
| server-error-job-canceled: not applicable. | ||||
| 3.1.3.1.6 Get-Jobs | 3.1.3.1.6 Get-Jobs | |||
| All of the Print-Job status codes described in Section 3.1.3.1.1 Print- | All of the Print-Job status codes described in Section 3.1.3.1.1 | |||
| Job Response are applicable to the Get-Jobs operation with the following | Print-Job Response are applicable to the Get-Jobs operation with the | |||
| specialization's and differences. See Section 13 in [IPP-MOD] for a | following specialization's and differences. See Section 13 in | |||
| more complete description of each status code. | [RFC2911] for a more complete description of each status code. | |||
| For the following success status codes, the requested attributes are | For the following success status codes, the requested attributes are | |||
| returned in Group 3 in the response: | returned in Group 3 in the response: | |||
| successful-ok: no request attributes were substituted or ignored | successful-ok: same as Get-Printer-Attributes (see section | |||
| (same as Print-Job) and no requested attributes were unsupported. | 3.1.3.1.5). | |||
| successful-ok-ignored-or-substituted-attributes: same as Print-Job, | successful-ok-ignored-or-substituted-attributes: same as Get- | |||
| except the "requested-attributes" operation attribute MAY, but NEED | Printer-Attributes (see section 3.1.3.1.5). | |||
| NOT, be returned with the unsupported values. | successful-ok-conflicting-attributes: same as Get-Printer- | |||
| successful-ok-conflicting-attributes: same as Print-Job. | Attributes (see section 3.1.3.1.5). | |||
| For any error status codes, Group 3 is returned containing no attributes | For any error status codes, Group 3 is returned containing no | |||
| or is not returned at all. The following brief error status code | attributes or is not returned at all. The following brief error | |||
| descriptions contain unique information for use with Get-Jobs operation. | status code descriptions contain unique information for use with Get- | |||
| See section 14 for the other error status codes that apply uniformly to | Jobs operation. See section 14 for the other error status codes that | |||
| all operations: | apply uniformly to all operations: | |||
| client-error-not-possible: Same as Print-Job, in addition the | client-error-not-possible: Same as Print-Job, in addition the | |||
| Printer object is not accepting any requests. | Printer object is not accepting any requests. | |||
| client-error-request-entity-too-large: same as Print-job, except | client-error-request-entity-too-large: same as Print-job, | |||
| that no print data is involved. | except that no print data is involved. | |||
| client-error-document-format-not-supported: not applicable. | client-error-document-format-not-supported: not applicable. | |||
| client-error-attributes-or-values-not-supported: not applicable, | client-error-attributes-or-values-not-supported: not | |||
| since unsupported operation attributes MUST be ignored and | applicable, since unsupported operation attributes and/or | |||
| 'successful-ok-ignored-or-substituted-attributes' returned. | values MUST be ignored and an appropriate success code | |||
| client-error-conflicting-attributes: same as Print-Job, except that | returned (see above). | |||
| "ipp-attribute-fidelity" is not involved. | client-error-conflicting-attributes: same as Print-Job, except | |||
| server-error-operation-not-supported: not applicable (since Get-Jobs | that "ipp-attribute-fidelity" is not involved. | |||
| is REQUIRED). | ||||
| server-error-device-error: same as Print-Job, except that no | ||||
| document data is involved. | ||||
| server-error-temporary-error: same as Print-Job, except that no | ||||
| document data is involved. | ||||
| server-error-not-accepting-jobs: not applicable. | ||||
| Expires November 30, 2000 | server-error-operation-not-supported: not applicable (since | |||
| server-error-job-canceled: not applicable. | Get-Jobs is REQUIRED). | |||
| server-error-device-error: same as Print-Job, except that no | ||||
| document data is involved. | ||||
| server-error-temporary-error: same as Print-Job, except that no | ||||
| document data is involved. | ||||
| server-error-not-accepting-jobs: not applicable. | ||||
| server-error-job-canceled: not applicable. | ||||
| 3.1.3.1.7 Pause-Printer | 3.1.3.1.7 Pause-Printer | |||
| All of the Print-Job status codes described in Section 3.1.3.1.1 Print- | All of the Print-Job status codes described in Section 3.1.3.1.1 | |||
| Job Response are applicable to Pause-Printer with the following | Print-Job Response are applicable to Pause-Printer with the following | |||
| specializations and differences. See Section 13 in [IPP-MOD] for a more | specializations and differences. See Section 13 in [RFC2911] for a | |||
| complete description of each status code. | more complete description of each status code. | |||
| For the following success status codes, the Printer object is being | For the following success status codes, the Printer object is being | |||
| stopped from scheduling jobs on all its devices. | stopped from scheduling jobs on all its devices. | |||
| successful-ok: no request attributes were substituted or ignored | successful-ok: no request attributes were substituted or | |||
| (same as Print-Job). | ignored (same as Print-Job). | |||
| successful-ok-ignored-or-substituted-attributes: same as Print-Job. | successful-ok-ignored-or-substituted-attributes: same as | |||
| successful-ok-conflicting-attributes: same as Print-Job. | Print-Job. | |||
| successful-ok-conflicting-attributes: same as Print-Job. | ||||
| For any of the error status codes, the Printer object has not been | For any of the error status codes, the Printer object has not been | |||
| stopped from scheduling jobs on all its devices. | stopped from scheduling jobs on all its devices. | |||
| client-error-not-possible: not applicable. | client-error-not-possible: not applicable. | |||
| client-error-not-found: the target Printer object does not exist. | client-error-not-found: the target Printer object does not | |||
| client-error-gone: the target Printer object no longer exists and no | exist. | |||
| forwarding address is known. | client-error-gone: the target Printer object no longer exists | |||
| client-error-request-entity-too-large: same as Print-Job, except no | and no forwarding address is known. | |||
| document data is involved. | client-error-request-entity-too-large: same as Print-Job, | |||
| client-error-document-format-not-supported: not applicable. | except no document data is involved. | |||
| client-error-conflicting-attributes: same as Print-Job, except that | client-error-document-format-not-supported: not applicable. | |||
| the Printer's "printer-is-accepting-jobs" attribute is not | client-error-conflicting-attributes: same as Print-Job, except | |||
| involved. | that the Printer's "printer-is-accepting-jobs" attribute is | |||
| server-error-operation-not-supported: the Pause-Printer operation is | not involved. | |||
| not supported. | server-error-operation-not-supported: the Pause-Printer | |||
| server-error-device-error: not applicable. | operation is not supported. | |||
| server-error-temporary-error: same as Print-Job, except no document | server-error-device-error: not applicable. | |||
| data is involved. | server-error-temporary-error: same as Print-Job, except no | |||
| server-error-not-accepting-jobs: not applicable. | document data is involved. | |||
| server-error-job-canceled: not applicable. | server-error-not-accepting-jobs: not applicable. | |||
| server-error-job-canceled: not applicable. | ||||
| 3.1.3.1.8 Resume-Printer | 3.1.3.1.8 Resume-Printer | |||
| All of the Print-Job status code descriptions in Section 3.1.3.1.1 | All of the Print-Job status code descriptions in Section 3.1.3.1.1 | |||
| Print-Job Response with the specialization's described for Pause-Printer | Print-Job Response with the specialization's described for Pause- | |||
| are applicable to Resume-Printer. See Section 13 in [IPP-MOD] for a | Printer are applicable to Resume-Printer. See Section 13 in | |||
| more complete description of each status code. | [RFC2911] for a more complete description of each status code. | |||
| For the following success status codes, the Printer object resumes | For the following success status codes, the Printer object resumes | |||
| scheduling jobs on all its devices. | scheduling jobs on all its devices. | |||
| Expires November 30, 2000 | successful-ok: no request attributes were substituted or | |||
| successful-ok: no request attributes were substituted or ignored | ignored (same as Print-Job). | |||
| (same as Print-Job). | successful-ok-ignored-or-substituted-attributes: same as | |||
| successful-ok-ignored-or-substituted-attributes: same as Print-Job. | Print-Job. | |||
| successful-ok-conflicting-attributes: same as Print-Job. | successful-ok-conflicting-attributes: same as Print-Job. | |||
| For any of the error status codes, the Printer object does not resume | For any of the error status codes, the Printer object does not resume | |||
| scheduling jobs. | scheduling jobs. | |||
| server-error-operation-not-supported: the Resume-Printer operation is | server-error-operation-not-supported: the Resume-Printer | |||
| not supported. | operation is not supported. | |||
| 3.1.3.1.8.1 What about Printers unable to change state due to an error | 3.1.3.1.8.1 What about Printers unable to change state due to an error | |||
| condition? | condition? | |||
| If, in case, the IPP printer is unable to change its state due to | ||||
| some problem with the actual printer device (say, it is shut down or | ||||
| there is a media-jam as indicated in [RFC2911]), what should be the | ||||
| result of the "Resume-Printer" operation? Should it still change the | ||||
| 'printer-state-reasons' and return success or should it fail ? | ||||
| If, in case, the IPP printer is unable to change its state due to some | The Resume-Printer operation must clear the 'paused' or 'moving-to- | |||
| problem with the actual printer device (say, it is shut down or there is | paused' 'printer-state-message'. The operation must return a | |||
| a media-jam as indicated in [ipp-mod]), what should be the result of the | 'successful-ok' status code. | |||
| "Resume-printer" operation? Should it still change the 'printer-state- | ||||
| reasons' and return success or should it fail ? | ||||
| The 'resume-printer' operation must clear the 'paused' or 'moving-to- | ||||
| paused' 'printer-state-message'. The operation must return a | ||||
| 'successful-ok' status code. | ||||
| 3.1.3.1.8.2 How is 'printer-state' handled on Resume-Printer? | ||||
| If "Resume-Printer" succeeds, what should be the value of 'Printer- | 3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer? | |||
| state' and who should take care of the 'Printer-state' later on ? | ||||
| The "Resume-Printer" operation may change the "printer-state-reasons" | If the Resume-Printer operation succeeds, what should be the value of | |||
| value. | "printer-state" and who should take care of the "printer-state" | |||
| attribute value later on ? | ||||
| The "printer-state" will change to one of three states: | The Resume-Printer operation may change the "printer-state-reasons" | |||
| value. | ||||
| 1. 'idle' - no additional jobs and no error conditions present | The "printer-state" will change to one of three states: | |||
| 2. 'processing' - job available and no error conditions present | 1. 'idle' - no additional jobs and no error conditions present | |||
| 2. 'processing' - job available and no error conditions present | ||||
| 3. current state (i.e. no change) an error condition is present (e.g. | 3. current state (i.e. no change) an error condition is present | |||
| media jam) | (e.g. media jam) | |||
| In the third case the 'printer-state-reason' will be cleared by | In the third case the "printer-state-reason" will be cleared by | |||
| automata when it detects the error condition no longer exists. The | automata when it detects the error condition no longer exists. The | |||
| 'printer-state' will move to 'idle' or 'processing' when conditions | "printer-state" will move to 'idle' or 'processing' when conditions | |||
| permit. (i.e. no more error conditions) | permit. (i.e. no more error conditions) | |||
| Expires November 30, 2000 | ||||
| 3.1.3.1.9 Purge-Printer | 3.1.3.1.9 Purge-Printer | |||
| All of the Print-Job status code descriptions in Section 3.1.3.1.1 | All of the Print-Job status code descriptions in Section 3.1.3.1.1 | |||
| Print-Job Response with the specialization's described for Pause-Printer | Print-Job Response with the specialization's described for Pause- | |||
| are applicable to Purge-Printer. See Section 13 in [IPP-MOD] for a more | Printer are applicable to Purge-Printer. See Section 13 in [RFC2911] | |||
| complete description of each status code. | for a more complete description of each status code. | |||
| For the following success status codes, the Printer object purges all | For the following success status codes, the Printer object purges all | |||
| it's jobs. | it's jobs. | |||
| successful-ok: no request attributes were substituted or ignored | successful-ok: no request attributes were substituted or | |||
| (same as Print-Job). | ignored (same as Print-Job). | |||
| successful-ok-ignored-or-substituted-attributes: same as Print-Job. | successful-ok-ignored-or-substituted-attributes: same as | |||
| successful-ok-conflicting-attributes: same as Print-Job. | Print-Job. | |||
| successful-ok-conflicting-attributes: same as Print-Job. | ||||
| For any of the error status codes, the Printer object does not purge any | For any of the error status codes, the Printer object does not purge | |||
| jobs. | any jobs. | |||
| server-error-operation-not-supported: the Purge-Printer operation is | server-error-operation-not-supported: the Purge-Printer | |||
| not supported. | operation is not supported. | |||
| 3.1.3.2 Job Operations | 3.1.3.2 Job Operations | |||
| 3.1.3.2.1 Send-Document | 3.1.3.2.1 Send-Document | |||
| All of the Print-Job status codes described in Section 3.1.3.1.1 Print- | All of the Print-Job status codes described in Section 3.1.3.1.1 | |||
| Job Response are applicable to the Get-Printer-Attributes operation with | Print-Job Response are applicable to the Get-Printer-Attributes | |||
| the following specialization's and differences. See Section 13 in | operation with the following specialization's and differences. See | |||
| [IPP-MOD] for a more complete description of each status code. | Section 13 in [RFC2911] for a more complete description of each | |||
| status code. | ||||
| For the following success status codes, the document has been added to | For the following success status codes, the document has been added | |||
| the specified Job object and the job's "number-of-documents" attribute | to the specified Job object and the job's "number-of-documents" | |||
| has been incremented: | attribute has been incremented: | |||
| successful-ok: no request attributes were substituted or ignored | successful-ok: no request attributes were substituted or | |||
| (same as Print-Job). | ignored (same as Print-Job). | |||
| successful-ok-ignored-or-substituted-attributes: same as Print-Job. | ||||
| successful-ok-conflicting-attributes: same as Print-Job. | ||||
| For the error status codes, no document has been added to the Job object | successful-ok-ignored-or-substituted-attributes: same as Print- | |||
| and the job's "number-of-documents" attribute has not been incremented: | Job. | |||
| successful-ok-conflicting-attributes: same as Print-Job. | ||||
| client-error-not-possible: Same as Print-Job, except that the | For the error status codes, no document has been added to the Job | |||
| Printer's "printer-is-accepting-jobs" attribute is not involved, so | object and the job's "number-of-documents" attribute has not been | |||
| that the client is able to finish submitting a job that was created | incremented: | |||
| with a Create-Job operation after this attribute has been set to | ||||
| 'true'. Another condition is that the state of the job precludes | ||||
| Send-Document, i.e., the job has already been closed out by the | ||||
| client. However, if the IPP Printer closed out the job due to | ||||
| Expires November 30, 2000 | client-error-not-possible: Same as Print-Job, except that the | |||
| timeout, the 'client-error-timeout' error status SHOULD be | Printer's "printer-is-accepting-jobs" attribute is not | |||
| returned instead. | involved, so that the client is able to finish submitting a | |||
| client-error-timeout: This request was sent after the Printer closed | job that was created with a Create-Job operation after this | |||
| the job, because it has not received a Send-Document or Send-URI | attribute has been set to 'true'. Another condition is that | |||
| operation within the Printer's "multiple-operation-time-out" period | the state of the job precludes Send-Document, i.e., the job | |||
| . | has already been closed out by the client. However, if the | |||
| client-error-request-entity-too-large: same as Print-Job. | IPP Printer closed out the job due to timeout, the 'client- | |||
| client-error-conflicting-attributes: same as Print-Job, except that | error-timeout' error status SHOULD be returned instead. | |||
| "ipp-attributes-fidelity" operation attribute is not involved.. | client-error-timeout: This request was sent after the Printer | |||
| server-error-operation-not-supported: the Send-Document request is | closed the job, because it has not received a Send-Document or | |||
| not supported. | Send-URI operation within the Printer's "multiple-operation- | |||
| server-error-not-accepting-jobs: not applicable. | time-out" period . | |||
| server-error-job-canceled: the job has been canceled by an operator | client-error-request-entity-too-large: same as Print-Job. | |||
| or the system while the client was transmitting the data. | client-error-conflicting-attributes: same as Print-Job, except | |||
| that "ipp-attributes-fidelity" operation attribute is not | ||||
| involved.. | ||||
| server-error-operation-not-supported: the Send-Document request | ||||
| is not supported. | ||||
| server-error-not-accepting-jobs: not applicable. | ||||
| server-error-job-canceled: the job has been canceled by an | ||||
| operator or the system while the client was transmitting the | ||||
| data. | ||||
| 3.1.3.2.2 Send-URI | 3.1.3.2.2 Send-URI | |||
| All of the Print-Job status code descriptions in Section 3.1.3.1.1 | All of the Print-Job status code descriptions in Section 3.1.3.1.1 | |||
| Print-Job Response with the specialization's described for Send-Document | Print-Job Response with the specialization's described for Send- | |||
| are applicable to Send-URI. See Section 13 in [IPP-MOD] for a more | Document are applicable to Send-URI. See Section 13 in [RFC2911] for | |||
| complete description of each status code. | a more complete description of each status code. | |||
| client-error-uri-scheme-not-supported: the URI scheme supplied in | client-error-uri-scheme-not-supported: the URI scheme supplied | |||
| the "document-uri" operation attribute is not supported and the | in the "document-uri" operation attribute is not supported and | |||
| "document-uri" attribute MUST be returned in the Unsupported | the "document-uri" attribute MUST be returned in the | |||
| Attributes group. | Unsupported Attributes group. | |||
| server-error-operation-not-supported: the Send-URI operation is not | server-error-operation-not-supported: the Send-URI operation is | |||
| supported. | not supported. | |||
| 3.1.3.2.3 Cancel-Job | 3.1.3.2.3 Cancel-Job | |||
| All of the Print-Job status codes described in Section 3.1.3.1.1 Print- | All of the Print-Job status codes described in Section 3.1.3.1.1 | |||
| Job Response are applicable to Cancel-Job with the following | Print-Job Response are applicable to Cancel-Job with the following | |||
| specializations and differences. See Section 13 in [IPP-MOD] for a more | specializations and differences. See Section 13 in [RFC2911] for a | |||
| complete description of each status code. | more complete description of each status code. | |||
| For the following success status codes, the Job object is being canceled | For the following success status codes, the Job object is being | |||
| or has been canceled: | canceled or has been canceled: | |||
| successful-ok: no request attributes were substituted or ignored | successful-ok: no request attributes were substituted or | |||
| (same as Print-Job). | ignored (same as Print-Job). | |||
| successful-ok-ignored-or-substituted-attributes: same as Print-Job. | successful-ok-ignored-or-substituted-attributes: same as | |||
| successful-ok-conflicting-attributes: same as Print-Job. | Print-Job. | |||
| successful-ok-conflicting-attributes: same as Print-Job. | ||||
| For any of the error status codes, the Job object has not been canceled | For any of the error status codes, the Job object has not been | |||
| or was previously canceled. | canceled or was previously canceled. | |||
| Expires November 30, 2000 | client-error-not-possible: The request cannot be carried out | |||
| client-error-not-possible: The request cannot be carried out because | because of the state of the Job object ('completed', | |||
| of the state of the Job object ('completed', 'canceled', or | 'canceled', or 'aborted') or the state of the system. | |||
| 'aborted') or the state of the system. | client-error-not-found: the target Printer and/or Job object | |||
| client-error-not-found: the target Printer and/or Job object does | does not exist. | |||
| not exist. | client-error-gone: the target Printer and/or Job object no | |||
| client-error-gone: the target Printer and/or Job object no longer | longer exists and no forwarding address is known. | |||
| exists and no forwarding address is known. | client-error-request-entity-too-large: same as Print-Job, | |||
| client-error-request-entity-too-large: same as Print-Job, except no | except no document data is involved. | |||
| document data is involved. | client-error-document-format-not-supported: not applicable. | |||
| client-error-document-format-not-supported: not applicable. | client-error-attributes-or-values-not-supported: not | |||
| client-error-attributes-or-values-not-supported: not applicable, | applicable, since unsupported operation attributes and values | |||
| since unsupported operation attributes and values MUST be ignored. | MUST be ignored. | |||
| client-error-conflicting-attributes: same as Print-Job, except that | client-error-conflicting-attributes: same as Print-Job, except | |||
| the Printer's "printer-is-accepting-jobs" attribute is not | that the Printer's "printer-is-accepting-jobs" attribute is | |||
| involved. | not involved. | |||
| server-error-operation-not-supported: not applicable (Cancel-Job is | server-error-operation-not-supported: not applicable (Cancel- | |||
| REQUIRED). | Job is REQUIRED). | |||
| server-error-device-error: same as Print-Job, except no document | server-error-device-error: same as Print-Job, except no | |||
| data is involved. | document data is involved. | |||
| server-error-temporary-error: same as Print-Job, except no document | server-error-temporary-error: same as Print-Job, except no | |||
| data is involved. | document data is involved. | |||
| server-error-not-accepting-jobs: not applicable.. | server-error-not-accepting-jobs: not applicable.. | |||
| server-error-job-canceled: not applicable. | server-error-job-canceled: not applicable. | |||
| 3.1.3.2.4 Get-Job-Attributes | 3.1.3.2.4 Get-Job-Attributes | |||
| All of the Print-Job status codes described in Section 3.1.3.1.1 Print- | All of the Print-Job status codes described in Section 3.1.3.1.1 | |||
| Job Response are applicable to Get-Job-Attributes with the following | Print-Job Response are applicable to Get-Job-Attributes with the | |||
| specializations and differences. See Section 13 in [IPP-MOD] for a more | following specializations and differences. See Section 13 in | |||
| complete description of each status code. | [RFC2911] for a more complete description of each status code. | |||
| For the following success status codes, the requested attributes are | ||||
| returned in Group 3 in the response: | ||||
| successful-ok: no request attributes were substituted or ignored | For the following success status codes, the requested attributes are | |||
| (same as Print-Job) and no requested attributes were unsupported. | returned in Group 3 in the response: | |||
| successful-ok-ignored-or-substituted-attributes: same as Print-Job, | ||||
| except the "requested-attributes" operation attribute MAY, but NEED | ||||
| NOT, be returned with the unsupported values. | ||||
| successful-ok-conflicting-attributes: same as Print-Job. | ||||
| For the error status codes, Group 3 is returned containing no attributes | successful-ok: same as Get-Printer-Attributes (see section | |||
| or is not returned at all. | 3.1.3.1.5). | |||
| successful-ok-ignored-or-substituted-attributes: same as Get- | ||||
| Printer-Attributes (see section 3.1.3.1.5). | ||||
| successful-ok-conflicting-attributes: same as Get-Printer- | ||||
| Attributes (see section 3.1.3.1.5). | ||||
| client-error-not-possible: Same as Print-Job, in addition the | For the error status codes, Group 3 is returned containing no | |||
| Printer object is not accepting any requests. | attributes or is not returned at all. | |||
| client-error-document-format-not-supported: not applicable. | ||||
| client-error-attributes-or-values-not-supported: not applicable. | ||||
| client-error-uri-scheme-not-supported: not applicable. | ||||
| Expires November 30, 2000 | client-error-not-possible: Same as Print-Job, in addition the | |||
| client-error-conflicting-attributes: not applicable | Printer object is not accepting any requests. | |||
| server-error-operation-not-supported: not applicable (since Get-Job- | client-error-document-format-not-supported: not applicable. | |||
| Attributes is REQUIRED). | client-error-attributes-or-values-not-supported: not | |||
| server-error-device-error: same as Print-Job, except no document | applicable. | |||
| data is involved. | client-error-uri-scheme-not-supported: not applicable. | |||
| server-error-temporary-error: sane as Print-Job, except no document | client-error-attributes-or-values-not-supported: not | |||
| data is involved.. | applicable, since unsupported operation attributes and/or | |||
| server-error-not-accepting-jobs: not applicable. | values MUST be ignored and an appropriate success code | |||
| server-error-job-canceled: not applicable. | returned (see above). | |||
| client-error-conflicting-attributes: not applicable | ||||
| server-error-operation-not-supported: not applicable (since | ||||
| Get-Job-Attributes is REQUIRED). | ||||
| server-error-device-error: same as Print-Job, except no | ||||
| document data is involved. | ||||
| server-error-temporary-error: sane as Print-Job, except no | ||||
| document data is involved.. | ||||
| server-error-not-accepting-jobs: not applicable. | ||||
| server-error-job-canceled: not applicable. | ||||
| 3.1.3.2.5 Hold-Job | 3.1.3.2.5 Hold-Job | |||
| All of the Print-Job status codes described in Section 3.1.3.1.1 Print- | All of the Print-Job status codes described in Section 3.1.3.1.1 | |||
| Job Response are applicable to Hold-Job with the following | Print-Job Response are applicable to Hold-Job with the following | |||
| specializations and differences. See Section 13 in [IPP-MOD] for a more | specializations and differences. See Section 13 in [RFC2911] for a | |||
| complete description of each status code. | more complete description of each status code. | |||
| For the following success status codes, the Job object is being held or | ||||
| has been held: | ||||
| successful-ok: no request attributes were substituted or ignored | For the following success status codes, the Job object is being held | |||
| (same as Print-Job). | or has been held: | |||
| successful-ok-ignored-or-substituted-attributes: same as Print-Job. | ||||
| successful-ok-conflicting-attributes: same as Print-Job. | ||||
| For any of the error status codes, the Job object has not been held or | successful-ok: no request attributes were substituted or | |||
| was previously held. | ignored (same as Print-Job). | |||
| successful-ok-ignored-or-substituted-attributes: same as | ||||
| Print-Job. | ||||
| successful-ok-conflicting-attributes: same as Print-Job. | ||||
| client-error-not-possible: The request cannot be carried out because | For any of the error status codes, the Job object has not been held | |||
| of the state of the Job object ('completed', 'canceled', or | or was previously held. | |||
| 'aborted') or the state of the system. | ||||
| client-error-not-found: the target Printer and/or Job object does | ||||
| not exist. | ||||
| client-error-gone: the target Printer and/or Job object no longer | ||||
| exists and no forwarding address is known. | ||||
| client-error-request-entity-too-large: same as Print-Job, except no | ||||
| document data is involved. | ||||
| client-error-document-format-not-supported: not applicable. | ||||
| client-error-conflicting-attributes: same as Print-Job, except that | ||||
| the Printer's "printer-is-accepting-jobs" attribute is not | ||||
| involved. | ||||
| server-error-operation-not-supported: the Hold-Job operation is not | ||||
| supported. | ||||
| server-error-device-error: not applicable. | ||||
| server-error-temporary-error: same as Print-Job, except no document | ||||
| data is involved. | ||||
| server-error-not-accepting-jobs: not applicable. | ||||
| server-error-job-canceled: not applicable. | ||||
| Expires November 30, 2000 | client-error-not-possible: The request cannot be carried out | |||
| because of the state of the Job object ('completed', | ||||
| 'canceled', or 'aborted') or the state of the system. | ||||
| client-error-not-found: the target Printer and/or Job object | ||||
| does not exist. | ||||
| client-error-gone: the target Printer and/or Job object no | ||||
| longer exists and no forwarding address is known. | ||||
| client-error-request-entity-too-large: same as Print-Job, | ||||
| except no document data is involved. | ||||
| client-error-document-format-not-supported: not applicable. | ||||
| client-error-conflicting-attributes: same as Print-Job, except | ||||
| that the Printer's "printer-is-accepting-jobs" attribute is | ||||
| not involved. | ||||
| server-error-operation-not-supported: the Hold-Job operation is | ||||
| not supported. | ||||
| server-error-device-error: not applicable. | ||||
| server-error-temporary-error: same as Print-Job, except no | ||||
| document data is involved. | ||||
| server-error-not-accepting-jobs: not applicable. | ||||
| server-error-job-canceled: not applicable. | ||||
| 3.1.3.2.6 Release-Job | 3.1.3.2.6 Release-Job | |||
| All of the Print-Job status code descriptions in Section 3.1.3.1.1 | All of the Print-Job status code descriptions in Section 3.1.3.1.1 | |||
| Print-Job Response with the specialization's described for Hold-Job are | Print-Job Response with the specialization's described for Hold-Job | |||
| applicable to Release-Job. See Section 13 in [IPP-MOD] for a more | are applicable to Release-Job. See Section 13 in [RFC2911] for a | |||
| complete description of each status code. | more complete description of each status code. | |||
| server-error-operation-not-supported: the Release-Job operation is | server-error-operation-not-supported: the Release-Job operation | |||
| not supported. | is not supported. | |||
| 3.1.3.2.7 Restart-Job | 3.1.3.2.7 Restart-Job | |||
| All of the Print-Job status code descriptions in Section 3.1.3.1.1 | All of the Print-Job status code descriptions in Section 3.1.3.1.1 | |||
| Print-Job Response with the specialization's described for Hold-Job are | Print-Job Response with the specialization's described for Hold-Job | |||
| applicable to Restart-Job. See Section 13 in [IPP-MOD] for a more | are applicable to Restart-Job. See Section 13 in [RFC2911] for a | |||
| complete description of each status code. | more complete description of each status code. | |||
| server-error-operation-not-supported: the Restart-Job operation is | server-error-operation-not-supported: the Restart-Job operation | |||
| not supported. | is not supported. | |||
| 3.1.3.2.7.1 Can documents be added to a restarted job? | 3.1.3.2.7.1 Can documents be added to a restarted job? | |||
| Assume I give a Create-Job request along with a set of 5 documents . | ||||
| All the documents get printed and the job state is moved to completed | ||||
| . I issue a Restart-Job request on the job. Now the issue is that, if | ||||
| I try to add new documents to the restarted job, will the IPP Server | ||||
| permit me to do so or return "client-error-not-possible " and again | ||||
| print those 5 jobs? | ||||
| Assume I give a Create-Job request along with a set of 5 documents . All | A job can not move to the 'completed' state until all the documents | |||
| the documents get printed and the job state is moved to completed . I | have been processed. The 'last-document' flag indicates when the | |||
| issue a Restart-Job request on the job. Now the issue is that, if I try | last document for a job is being sent from the client. This is the | |||
| to add new documents to the restarted job, will the IPP Server permit | semantic equivalent of closing a job. No documents may be added once | |||
| me to do so or return "client-error-not-possible " and again print | a job is closed. Section 3.3.7 of the IPP/1.1 model states "The job | |||
| those 5 jobs? | is moved to the 'pending' job state and restarts the beginning on the | |||
| same IPP Printer object with the same attribute values." 'number-of- | ||||
| A job can not move to the 'completed' state until all the documents have | documents' is a job attribute. | |||
| been processed. The 'last-document' flag indicates when the last | ||||
| document for a job is being sent from the client. This is the semantic | ||||
| equivalent of closing a job. No documents may be added once a job is | ||||
| closed. Section 3.3.7 of the IPP/1.1 model states "The job is moved to | ||||
| the 'pending' job state and restarts the beginning on the same IPP | ||||
| Printer object with the same attribute values." 'number-of-documents' is | ||||
| a job attribute. | ||||
| 3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue | ||||
| 1.18) | ||||
| In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes | 3.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue | |||
| responses, the client cannot depend on getting unsupported attributes | 1.18) | |||
| returned in the Unsupported Attributes group that the client requested, | ||||
| Expires November 30, 2000 | In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes | |||
| but are not supported by the IPP object. However, such unsupported | responses, the client cannot depend on getting unsupported attributes | |||
| requested attributes will not be returned in the Job Attributes or | returned in the Unsupported Attributes group that the client | |||
| Printer Attributes group (since they are unsupported). Furthermore, the | requested, but are not supported by the IPP object. However, such | |||
| IPP object is REQUIRED to return the 'successful-ok-ignored-or- | unsupported requested attributes will not be returned in the Job | |||
| substituted-attributes' status code, so that the client knows that not | Attributes or Printer Attributes group (since they are unsupported). | |||
| all that was requested has been returned. | Furthermore, the IPP object is REQUIRED to return the 'successful-ok- | |||
| ignored-or-substituted-attributes' status code, so that the client | ||||
| knows that not all that was requested has been returned. | ||||
| 3.1.5 Sending empty attribute groups | 3.1.5 Sending empty attribute groups | |||
| The [IPP-MOD] and [IPP-PRO] specifications RECOMMEND that a sender not | The [RFC2911] and [RFC2910] specifications RECOMMEND that a sender | |||
| send an empty attribute group in a request or a response. However, they | not send an empty attribute group in a request or a response. | |||
| REQUIRE a receiver to accept an empty attribute group as equivalent to | However, they REQUIRE a receiver to accept an empty attribute group | |||
| the omission of that group. So a client SHOULD omit the Job Template | as equivalent to the omission of that group. So a client SHOULD omit | |||
| Attributes group entirely in a create operation that is not supplying | the Job Template Attributes group entirely in a create operation that | |||
| any Job Template attributes. Similarly, an IPP object SHOULD omit an | is not supplying any Job Template attributes. Similarly, an IPP | |||
| empty Unsupported Attributes group if there are no unsupported | object SHOULD omit an empty Unsupported Attributes group if there are | |||
| attributes to be returned in a response. | no unsupported attributes to be returned in a response. | |||
| The [IPP-PRO] specification REQUIRES a receiver to be able to receive | The [RFC2910] specification REQUIRES a receiver to be able to receive | |||
| either an empty attribute group or an omitted attribute group and treat | either an empty attribute group or an omitted attribute group and | |||
| them equivalently. The term "receiver" means an IPP object for a | treat them equivalently. The term "receiver" means an IPP object for | |||
| request and a client for a response. The term "sender' means a client | a request and a client for a response. The term "sender' means a | |||
| for a request and an IPP object for a response. | client for a request and an IPP object for a response. | |||
| There is an exception to the rule for Get-Jobs when there are no | There is an exception to the rule for Get-Jobs when there are no | |||
| attributes to be returned. [IPP-PRO] contains the following paragraph: | attributes to be returned. [RFC2910] contains the following | |||
| paragraph: | ||||
| The syntax allows an xxx-attributes-tag to be present when the xxx- | The syntax allows an xxx-attributes-tag to be present when the xxx- | |||
| attribute-sequence that follows is empty. The syntax is defined this way | attribute-sequence that follows is empty. The syntax is defined this | |||
| to allow for the response of Get-Jobs where no attributes are returned | way to allow for the response of Get-Jobs where no attributes are | |||
| for some job-objects. Although it is RECOMMENDED that the sender not | returned for some job-objects. Although it is RECOMMENDED that the | |||
| send an xxx-attributes-tag if there are no attributes (except in the | sender not send an xxx-attributes-tag if there are no attributes | |||
| Get-Jobs response just mentioned), the receiver MUST be able to decode | (except in the Get-Jobs response just mentioned), the receiver MUST | |||
| such syntax. | be able to decode such syntax. | |||
| 3.2 Printer Operations | 3.2 Printer Operations | |||
| 3.2.1 Print-Job operation | 3.2.1 Print-Job operation | |||
| 3.2.1.1 Flow controlling the data portion of a Print-Job request | 3.2.1.1 Flow controlling the data portion of a Print-Job request | |||
| (Issue 1.22) | (Issue 1.22) | |||
| A paused printer, or one that is stopped due to paper out or jam or | A paused printer, or one that is stopped due to paper out or jam or | |||
| spool space full or buffer space full, may flow control the data of a | spool space full or buffer space full, may flow control the data of a | |||
| Print-Job operation (at the TCP/IP layer), so that the client is not | Print-Job operation (at the TCP/IP layer), so that the client is not | |||
| able to send all the document data. Consequently, the Printer will | ||||
| Expires November 30, 2000 | not return a response until the condition is changed. | |||
| able to send all the document data. Consequently, the Printer will not | ||||
| return a response until the condition is changed. | ||||
| The Printer should not return a Print-Job response with an error code in | The Printer should not return a Print-Job response with an error code | |||
| any of these conditions, since either the printer will be resumed and/or | in any of these conditions, since either the printer will be resumed | |||
| the condition will be freed either by human intervention or as jobs | and/or the condition will be freed either by human intervention or as | |||
| print. | jobs print. | |||
| In writing test scripts to test IPP Printers, the script must also be | In writing test scripts to test IPP Printers, the script must also be | |||
| written not to expect a response, if the printer has been paused, until | written not to expect a response, if the printer has been paused, | |||
| the printer is resumed, in order to work with all possible | until the printer is resumed, in order to work with all possible | |||
| implementations. | implementations. | |||
| 3.2.1.2 Returning job-state in Print-Job response (Issue 1.30) | 3.2.1.2 Returning job-state in Print-Job response (Issue 1.30) | |||
| An IPP client submits a small job via Print-Job. By the time the IPP | An IPP client submits a small job via Print-Job. By the time the IPP | |||
| printer/print server is putting together a response to the operation, | printer/print server is putting together a response to the operation, | |||
| the job has finished printing and been removed as an object from the | the job has finished printing and been removed as an object from the | |||
| print system. What should the job-state be in the response? | print system. What should the job-state be in the response? | |||
| The Model suggests that the Printer return a response before it even | ||||
| accepts the document content. The Job Object Attributes are returned | ||||
| only if the IPP object returns one of the success status codes. Then the | ||||
| job-state would always be "pending" or "pending-held". | ||||
| This issue comes up for the implementation of an IPP Printer object as a | The Model suggests that the Printer return a response before it even | |||
| server that forwards jobs to devices that do not provide job status back | accepts the document content. The Job Object Attributes are returned | |||
| to the server. If the server is reasonably certain that the job | only if the IPP object returns one of the success status codes. Then | |||
| completed successfully, then it should return the job-state as | the job-state would always be "pending" or "pending-held". | |||
| 'completed'. Also the server can keep the job in its "job history" long | ||||
| after the job is no longer in the device. Then a user could query the | ||||
| server and see that the job was in the 'completed' state and completed | ||||
| as specified by the jobs "time-at-completed" time, which would be the | ||||
| same as the server submitted the job to the device. | ||||
| An alternative is for the server to respond to the client before or | This issue comes up for the implementation of an IPP Printer object | |||
| while sending the job to the device, instead of waiting until the server | as a server that forwards jobs to devices that do not provide job | |||
| has finished sending the job to the device. In this case, the server | status back to the server. If the server is reasonably certain that | |||
| can return the job's state as 'pending' with the 'job-outgoing' value in | the job completed successfully, then it should return the job-state | |||
| the job's "job-state-reasons" attribute. | as 'completed'. Also the server can keep the job in its "job | |||
| history" long after the job is no longer in the device. Then a user | ||||
| could query the server and see that the job was in the 'completed' | ||||
| state and completed as specified by the jobs "time-at-completed" | ||||
| time, which would be the same as the server submitted the job to the | ||||
| device. | ||||
| If the server doesn't know for sure whether the job completed | An alternative is for the server to respond to the client before or | |||
| successfully (or at all), it could return the (out-of-band) 'unknown' | while sending the job to the device, instead of waiting until the | |||
| value. | server has finished sending the job to the device. In this case, the | |||
| server can return the job's state as 'pending' with the 'job- | ||||
| outgoing' value in the job's "job-state-reasons" attribute. | ||||
| On the other hand, if the server is able to query the device and/or | If the server doesn't know for sure whether the job completed | |||
| setup some sort of event notification that the device initiates when the | successfully (or at all), it could return the (out-of-band) 'unknown' | |||
| job makes state transitions, then the server can return the current job | value. | |||
| Expires November 30, 2000 | On the other hand, if the server is able to query the device and/or | |||
| state in the Print-Job response and in subsequent queries because the | setup some sort of event notification that the device initiates when | |||
| server knows what the job state is in the device (or can query the | the job makes state transitions, then the server can return the | |||
| device). | current job state in the Print-Job response and in subsequent queries | |||
| because the server knows what the job state is in the device (or can | ||||
| query the device). | ||||
| All of these alternatives depend on implementation of the server and the | All of these alternatives depend on implementation of the server and | |||
| device. | the device. | |||
| 3.2.2 Get-Printer-Attributes operation | 3.2.2 Get-Printer-Attributes operation | |||
| If a Printer supports the "printer-make-and-model" attribute and returns | If a Printer supports the "printer-make-and-model" attribute and | |||
| the .INF file model name of the printer in that attribute, the Microsoft | returns the .INF file model name of the printer in that attribute, | |||
| client will automatically install the correct driver (if available). | the Microsoft client will automatically install the correct driver | |||
| (if available). | ||||
| Clients which poll periodically for printer status or queued-job-count | Clients which poll periodically for printer status or queued-job- | |||
| should use the "requested-attributes" operation attribute to limit the | count should use the "requested-attributes" operation attribute to | |||
| scope of the query in order to save Printer and network resources. | limit the scope of the query in order to save Printer and network | |||
| resources. | ||||
| 3.2.3 Get-Jobs operation | 3.2.3 Get-Jobs operation | |||
| 3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue | 3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue | |||
| 1.39)? | 1.39)? | |||
| In [IPP-MOD] section 3.2.6.1 'Get-Jobs Request', if the attribute 'my- | In [RFC2911] section 3.2.6.1 'Get-Jobs Request', if the attribute | |||
| jobs' is present and set to TRUE, MUST the 'requesting-user-name' | 'my-jobs' is present and set to TRUE, MUST the 'requesting-user-name' | |||
| attribute be there too, and if it's not present what should the IPP | attribute be there too, and if it's not present what should the IPP | |||
| printer do? | printer do? | |||
| [IPP-MOD] Section 8.3 describes the various cases of "requesting-user- | [RFC2911] Section 8.3 describes the various cases of "requesting- | |||
| name" being present or not for any operation. If the client does not | user-name" being present or not for any operation. If the client | |||
| supply a value for "requesting-user-name", the printer MUST assume that | does not supply a value for "requesting-user-name", the printer MUST | |||
| the client is supplying some anonymous name, such as "anonymous". | assume that the client is supplying some anonymous name, such as | |||
| "anonymous". | ||||
| 3.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation? | 3.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation? | |||
| When using the Get-Jobs operation a client implementer might choose to | When using the Get-Jobs operation a client implementer might choose | |||
| limit the number of jobs that the client shows on the first screenful. | to limit the number of jobs that the client shows on the first | |||
| For example, if its UI can only display 50 jobs, it can defend itself | screenful. For example, if its UI can only display 50 jobs, it can | |||
| against a printer that would otherwise return 500 jobs, perhaps taking a | defend itself against a printer that would otherwise return 500 jobs, | |||
| long time on a slow dial-up line. The client can then go and ask for a | perhaps taking a long time on a slow dial-up line. The client can | |||
| larger number of jobs in the background, while showing the user the | then go and ask for a larger number of jobs in the background, while | |||
| first 50 jobs. Since the job history is returned in reverse order, | showing the user the first 50 jobs. Since the job history is returned | |||
| namely the most recently completed jobs are returned first, the user is | in reverse order, namely the most recently completed jobs are | |||
| most likely interested in the first jobs that are returned. Limiting the | returned first, the user is most likely interested in the first jobs | |||
| number of jobs may be especially useful for a client that is requesting | that are returned. Limiting the number of jobs may be especially | |||
| 'completed' jobs from a printer that keeps a long job history. Clients | useful for a client that is requesting 'completed' jobs from a | |||
| printer that keeps a long job history. Clients that don't mind | ||||
| Expires November 30, 2000 | sometimes getting very large responses, can omit the "limit" | |||
| that don't mind sometimes getting very large responses, can omit the | attribute in their Get-Jobs requests. | |||
| "limit" attribute in their Get-Jobs requests. | ||||
| 3.2.4 Create-Job operation | ||||
| A Printer may respond to a Create-Job operation with "job-state" | 3.2.4 Create-Job operation | |||
| 'pending' or 'pending-held' and " job-state-reason" 'job-data- | ||||
| insufficient' to indicate that operation has been accepted by the | ||||
| Printer, but the Printer is expecting additional document data before it | ||||
| can move the job into the 'processing' state. Alternatively, it may | ||||
| respond with "job-state" 'processing' and "job-state-reason" 'job- | ||||
| incoming' to indicate that the Create-Job operation has been accepted | ||||
| by the Printer, but the Printer is expecting additional Send-Document | ||||
| and/or Send-URI operations and/or is accessing/accepting document data. | ||||
| The second alternative is for non-spooling Printers that don't implement | ||||
| the 'pending' state. | ||||
| Should the server wait for the "last-document" operation attribute set | A Printer may respond to a Create-Job operation with "job-state" | |||
| to 'true' before starting to "process" the job? | 'pending' or 'pending-held' and " job-state-reason" 'job-data- | |||
| insufficient' to indicate that operation has been accepted by the | ||||
| Printer, but the Printer is expecting additional document data before | ||||
| it can move the job into the 'processing' state. Alternatively, it | ||||
| may respond with "job-state" 'processing' and "job-state-reason" | ||||
| 'job-incoming' to indicate that the Create-Job operation has been | ||||
| accepted by the Printer, but the Printer is expecting additional | ||||
| Send-Document and/or Send-URI operations and/or is | ||||
| accessing/accepting document data. The second alternative is for | ||||
| non-spooling Printers that don't implement the 'pending' state. | ||||
| It depends on implementation. Some servers spool the entire job, | Should the server wait for the "last-document" operation attribute | |||
| including all document data, before starting to process, so such an | set to 'true' before starting to "process" the job? | |||
| implementation would wait for the "last-document" before starting to | It depends on implementation. Some servers spool the entire job, | |||
| process the job. If the time-out occurs without the "last-document", | including all document data, before starting to process, so such an | |||
| then the server takes one of the indicated actions in section 3.3.1 in | implementation would wait for the "last-document" before starting to | |||
| the [IPP-MOD] document. Other servers will start to process document | process the job. If the time-out occurs without the "last-document", | |||
| data as soon as they have some. These are the so-called "non-spooling" | then the server takes one of the indicated actions in section 3.3.1 | |||
| printers. Currently, there isn't a way for a client to determine whether | in the [RFC2911] document. Other servers will start to process | |||
| the Printer will spool all the data or will start to process (and print) | document data as soon as they have some. These are the so-called | |||
| as soon as it has some data. | "non-spooling" printers. Currently, there isn't a way for a client to | |||
| determine whether the Printer will spool all the data or will start | ||||
| to process (and print) as soon as it has some data. | ||||
| 3.3 Job Operations | 3.3 Job Operations | |||
| 3.3.1 Validate-Job | 3.3.1 Validate-Job | |||
| The Validate-Job operation has been designed so that its implementation | The Validate-Job operation has been designed so that its | |||
| may be a part of the Print-Job operation. Therefore, requiring | implementation may be a part of the Print-Job operation. Therefore, | |||
| Validate-Job is not a burden on implementers. Also it is useful for | requiring Validate-Job is not a burden on implementers. Also it is | |||
| client's to be able to count on its presence in all conformance | useful for client's to be able to count on its presence in all | |||
| implementations, so that the client can determine before sending a long | conformance implementations, so that the client can determine before | |||
| document, whether the job will be accepted by the IPP Printer or not. | sending a long document, whether the job will be accepted by the IPP | |||
| Printer or not. | ||||
| 3.3.2 Restart-Job | 3.3.2 Restart-Job | |||
| Expires November 30, 2000 | The Restart-Job operation allows the reprocessing of a completed job. | |||
| The Restart-Job operation allows the reprocessing of a completed job. | Some jobs store the document data on the printer. Jobs created using | |||
| Some jobs store the document data on the printer. Jobs created using | the Print-Job operation are an example. It is required that the | |||
| the Print-Job operation are an example. It is required that the printer | printer retains the job data after the job has moved to a 'completed | |||
| retains the job data after the job has moved to a 'completed state' in | state' in order for the Restart-Job operation to succeed. | |||
| order for the Restart-Job operation to succeed. | ||||
| Some jobs contain only a reference to the job data. A job created using | Some jobs contain only a reference to the job data. A job created | |||
| the Print-URI is an example of such a job. When the Restart-Job | using the Print-URI is an example of such a job. When the Restart- | |||
| operation is issued the job is reprocessed. The job data MUST be | Job operation is issued the job is reprocessed. The job data MUST be | |||
| retrieved again to print the job. | retrieved again to print the job. | |||
| It is possible that a job fails while attempting to access the print | It is possible that a job fails while attempting to access the print | |||
| data. When such a job is the target of a Restart-Job the Printer SHALL | data. When such a job is the target of a Restart-Job the Printer | |||
| attempt to retrieve the job data again. | SHALL attempt to retrieve the job data again. | |||
| 4 Object Attributes | 4 Object Attributes | |||
| 4.1 Attribute Syntax's | 4.1 Attribute Syntax's | |||
| 4.1.1 The 'none' value for empty sets (Issue 1.37) | 4.1.1 The 'none' value for empty sets (Issue 1.37) | |||
| [IPP-MOD] states that the 'none' value should be used as the value of a | ||||
| 1setOf when the set is empty. In most cases, sets that are potentially | ||||
| empty contain keywords so the keyword 'none' is used, but for the 3 | ||||
| finishings attributes, the values are enums and thus the empty set is | ||||
| represented by the enum 3. Currently there are no other attributes with | ||||
| 1setOf values, which can be empty and can contain values that are not | ||||
| keywords. This exception requires special code and is a potential place | ||||
| for bugs. It would have been better if we had chosen an out-of-band | ||||
| value, either "no-value" or some new value, such as 'none'. Since we | ||||
| didn't, implementations have to deal with the different representations | ||||
| of 'none', depending on the attribute syntax. | ||||
| 4.1.2 Multi-valued attributes (Issue 1.31) | [RFC2911] states that the 'none' value should be used as the value of | |||
| a 1setOf when the set is empty. In most cases, sets that are | ||||
| potentially empty contain keywords so the keyword 'none' is used, but | ||||
| for the 3 finishings attributes, the values are enums and thus the | ||||
| empty set is represented by the enum 3. Currently there are no other | ||||
| attributes with 1setOf values, which can be empty and can contain | ||||
| values that are not keywords. This exception requires special code | ||||
| and is a potential place for bugs. It would have been better if we | ||||
| had chosen an out-of-band value, either "no-value" or some new value, | ||||
| such as 'none'. Since we didn't, implementations have to deal with | ||||
| the different representations of 'none', depending on the attribute | ||||
| syntax. | ||||
| What is the attribute syntax for a multi-valued attribute? Since some | 4.1.2 Multi-valued attributes (Issue 1.31) | |||
| attributes support values in more than one data type, such as "media", | ||||
| "job-hold-until", and "job-sheets", IPP semantics associate the | ||||
| attribute syntax with each value, not with the attribute as a whole. | ||||
| The protocol associates the attribute syntax tag with each value. Don't | ||||
| be fooled, just because the attribute syntax tag comes before the | ||||
| attribute keyword. All attribute values after the first have a zero | ||||
| length attribute keyword as the indication of a subsequent value of the | ||||
| same attribute. | ||||
| Expires November 30, 2000 | What is the attribute syntax for a multi-valued attribute? Since | |||
| 4.1.3 Case Sensitivity in URIs (issue 1.6) | some attributes support values in more than one data type, such as | |||
| "media", "job-hold-until", and "job-sheets", IPP semantics associate | ||||
| the attribute syntax with each value, not with the attribute as a | ||||
| whole. The protocol associates the attribute syntax tag with each | ||||
| value. Don't be fooled, just because the attribute syntax tag comes | ||||
| before the attribute keyword. All attribute values after the first | ||||
| have a zero length attribute keyword as the indication of a | ||||
| subsequent value of the same attribute. | ||||
| IPP client and server implementations must be aware of the diverse | 4.1.3 Case Sensitivity in URIs (issue 1.6) | |||
| uppercase/lowercase nature of URIs. RFC 2396 defines URL schemes and | ||||
| Host names as case insensitive but reminds us that the rest of the URL | ||||
| may well demonstrate case sensitivity. When creating URL's for fields | ||||
| where the choice is completely arbitrary, it is probably best to select | ||||
| lower case. However, this cannot be guaranteed and implementations MUST | ||||
| NOT rely on any fields being case-sensitive or case-insensitive in the | ||||
| URL beyond the URL scheme and host name fields. | ||||
| The reason that the IPP specification does not make any restrictions on | IPP client and server implementations must be aware of the diverse | |||
| URIs, is so that implementations of IPP may use off-the-shelf components | uppercase/lowercase nature of URIs. RFC 2396 defines URL schemes and | |||
| that conform to the standards that define URIs, such as RFC 2396 and the | Host names as case insensitive but reminds us that the rest of the | |||
| HTTP/1.1 specifications [RFC2616]. See these specifications for rules | URL may well demonstrate case sensitivity. When creating URL's for | |||
| of matching, comparison, and case-sensitivity. | fields where the choice is completely arbitrary, it is probably best | |||
| to select lower case. However, this cannot be guaranteed and | ||||
| implementations MUST NOT rely on any fields being case-sensitive or | ||||
| case-insensitive in the URL beyond the URL scheme and host name | ||||
| fields. | ||||
| It is also recommended that System Administrators and implementations | The reason that the IPP specification does not make any restrictions | |||
| avoid creating URLs for different printers that differ only in their | on URIs, is so that implementations of IPP may use off-the-shelf | |||
| case. For example, don't have Printer1 and printer1 as two different | components that conform to the standards that define URIs, such as | |||
| IPP Printers. | RFC 2396 and the HTTP/1.1 specifications [RFC2616]. See these | |||
| specifications for rules of matching, comparison, and case- | ||||
| sensitivity. | ||||
| Example of equivalent URI's | It is also recommended that System Administrators and implementations | |||
| avoid creating URLs for different printers that differ only in their | ||||
| case. For example, don't have Printer1 and printer1 as two different | ||||
| IPP Printers. | ||||
| http://abc.com:80/~smith/home.html | Example of equivalent URI's | |||
| http://ABC.com/%7Esmith/home.html | http://abc.com:80/~smith/home.html | |||
| http:/ABC.com:/%7esmith/home.html | http://ABC.com/%7Esmith/home.html | |||
| Example of equivalent URI's using the IPP scheme | http:/ABC.com:/%7esmith/home.html | |||
| ipp://abc.com:631/~smith/home.html | Example of equivalent URI's using the IPP scheme | |||
| ipp://ABC.com/%7Esmith/home.html | ipp://abc.com:631/~smith/home.html | |||
| http:/ABC.com:631/%7esmith/home.html | ipp://ABC.com/%7Esmith/home.html | |||
| The HTTP/1.1 specification [RFC2616] contains more details on comparing | http:/ABC.com:631/%7esmith/home.html | |||
| URLs. | ||||
| 4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage | The HTTP/1.1 specification [RFC2616] contains more details on | |||
| comparing URLs. | ||||
| The 'textWithLanguage' and 'nameWithLanguage' are compound syntaxes that | 4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage | |||
| have two components. The first component is the 'language' component | ||||
| that can contain up to 63 octets. The second component is the 'text' or | ||||
| 'name' component. The maximum length of these are 1023 octets and 255 | ||||
| Expires November 30, 2000 | The 'textWithLanguage' and 'nameWithLanguage' are compound syntaxes | |||
| octets respectively. The definition of attributes with either syntax | that have two components. The first component is the 'language' | |||
| may further restrict the length. (e.g. printer-name (name(127))) | component that can contain up to 63 octets. The second component is | |||
| the 'text' or 'name' component. The maximum length of these are 1023 | ||||
| octets and 255 octets respectively. The definition of attributes | ||||
| with either syntax may further restrict the length. (e.g. printer- | ||||
| name (name(127))) | ||||
| The length of the 'language' component has no effect on the allowable | The length of the 'language' component has no effect on the allowable | |||
| length of 'text' in 'textWithLanguage' or the length of 'name' in | length of 'text' in 'textWithLanguage' or the length of 'name' in | |||
| 'nameWithLanguage' | 'nameWithLanguage' | |||
| 4.2 Job Template Attributes | 4.2 Job Template Attributes | |||
| 4.2.1 multiple-document-handling(type2 keyword) | 4.2.1 multiple-document-handling(type2 keyword) | |||
| 4.2.1.1 Support of multiple document jobs | 4.2.1.1 Support of multiple document jobs | |||
| IPP/1.0 is silent on which of the four effects an implementation would | IPP/1.0 is silent on which of the four effects an implementation | |||
| perform if it supports Create-Job, but does not support "multiple- | would perform if it supports Create-Job, but does not support | |||
| document-handling" or multiple documents per job. IPP/1.1 was changed | "multiple-document-handling" or multiple documents per job. IPP/1.1 | |||
| so that a Printer could support Create-Job without having to support | was changed so that a Printer could support Create-Job without having | |||
| multiple document jobs. The "multiple-document-jobs-supported" | to support multiple document jobs. The "multiple-document-jobs- | |||
| (boolean) Printer description attribute was added to IPP/1.1 along with | supported" (boolean) Printer description attribute was added to | |||
| the 'server-error-multiple-document-jobs-not-supported' status code for | IPP/1.1 along with the 'server-error-multiple-document-jobs-not- | |||
| a Printer to indicate whether or not it supports multiple document jobs, | supported' status code for a Printer to indicate whether or not it | |||
| when it supports the Create-Job operation. Also IPP/1.1 was clarified | supports multiple document jobs, when it supports the Create-Job | |||
| that the Printer MUST support the "multiple-document-handling" (type2 | operation. Also IPP/1.1 was clarified that the Printer MUST support | |||
| keyword) Job Template attribute with at least one value if the Printer | the "multiple-document-handling" (type2 keyword) Job Template | |||
| supports multiple documents per job. | attribute with at least one value if the Printer supports multiple | |||
| documents per job. | ||||
| 4.3 Job Description Attributes | 4.3 Job Description Attributes | |||
| The time-at-creation, time-at-processing, and time-at-completed | 4.3.1 Getting the date and time of day | |||
| attributes may be returned in integer time ticks or absolute dateTime | ||||
| syntax. There are various ways for a Printer to get the time of day. | The "date-time-at-creation", "date-time-at-processing", and "date- | |||
| Some suggestions: | time-at-completed" attributes are returned as dateTime syntax. | |||
| These attributes are OPTIONAL for a Printer to support. However, | ||||
| there are various ways for a Printer to get the date and time of day. | ||||
| Some suggestions: | ||||
| 1. A Printer can get time from an NTP timeserver if there's one | 1. A Printer can get time from an NTP timeserver if there's one | |||
| reachable on the network . See RFC 1305. Also DHCP option 32 in | reachable on the network . See RFC 1305. Also DHCP option 32 in | |||
| RFC 2132 returns the IP address of the NTP server. | RFC 2132 returns the IP address of the NTP server. | |||
| 2. Get the date and time at startup from a human operator | 2. Get the date and time at startup from a human operator | |||
| 3. Have an operator set the date and time using a web | 3. Have an operator set the date and time using a web | |||
| administrative interface | administrative interface | |||
| 4. Get the date and time from incoming HTTP requests, though the | 4. Get the date and time from incoming HTTP requests, though the | |||
| problems of spoofing need to be considered. Perhaps comparing | problems of spoofing need to be considered. Perhaps comparing | |||
| several HTTP requests could reduce the chances of spoofing. | several HTTP requests could reduce the chances of spoofing. | |||
| Expires November 30, 2000 | ||||
| 5. Internal date time clock battery driven. | 5. Internal date time clock battery driven. | |||
| 6. Query "http://tycho.usno.navy.mil/cgi-bin/timer.pl" | 6. Query "http://tycho.usno.navy.mil/cgi-bin/timer.pl" | |||
| 4.4 Printer Description Attributes | 4.4 Printer Description Attributes | |||
| 4.4.1 queued-job-count | 4.4.1 queued-job-count (integer(0:MAX)) | |||
| 4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)? | 4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)? | |||
| The reason that "queued-job-count" is RECOMMENDED, is that some clients | The reason that "queued-job-count" is RECOMMENDED, is that some | |||
| look at that attribute alone when summarizing the status of a list of | clients look at that attribute alone when summarizing the status of a | |||
| printers, instead of doing a Get-Jobs to determine the number of jobs in | list of printers, instead of doing a Get-Jobs to determine the number | |||
| the queue. Implementations that fail to support the "queued-job-count" | of jobs in the queue. Implementations that fail to support the | |||
| will cause that client to display 0 jobs when there are actually queued | "queued-job-count" will cause that client to display 0 jobs when | |||
| jobs. | there are actually queued jobs. | |||
| We would have made it a REQUIRED Printer attribute, but some | We would have made it a REQUIRED Printer attribute, but some | |||
| implementations had already been completed before the issue was raised, | implementations had already been completed before the issue was | |||
| so making it a SHOULD was a compromise. | raised, so making it a SHOULD was a compromise. | |||
| 4.4.1.2 Is "queued-job-count" a good measure of how busy a printer is | 4.4.1.2 Is "queued-job-count" a good measure of how busy a printer is | |||
| (Issue 1.15)? | (Issue 1.15)? | |||
| The "queued-job-count" is not a good measure of how busy the printer is | The "queued-job-count" is not a good measure of how busy the printer | |||
| when there are held jobs. A future registration could be to add a | is when there are held jobs. A future registration could be to add a | |||
| "held-job-count" (or an "active-job-count") Printer Description | "held-job-count" (or an "active-job-count") Printer Description | |||
| attribute if experience shows that such an attribute (combination) is | attribute if experience shows that such an attribute (combination) is | |||
| needed to quickly indicate how busy a printer really is. | needed to quickly indicate how busy a printer really is. | |||
| 4.4.2 printer-current-time (dateTime) | ||||
| A Printer implementation MAY support this attribute by obtaining the | 4.4.2 printer-current-time (dateTime) | |||
| date and time by any number of implementation-dependent means at startup | ||||
| or subsequently. Examples include: | ||||
| 1. an internal date time clock, | A Printer implementation MAY support this attribute by obtaining the | |||
| date and time by any number of implementation-dependent means at | ||||
| startup or subsequently. Examples include: | ||||
| 2. from the operator at startup using the console, | 1. an internal date time clock, | |||
| 3. from an operator using an administrative web page, | 2. from the operator at startup using the console, | |||
| 4. from HTTP headers supplied in client requests, | 3. from an operator using an administrative web page, | |||
| Expires November 30, 2000 | 4. from HTTP headers supplied in client requests, | |||
| 5. use HTTP to query "http://tycho.usno.navy.mil/cgi-bin/timer.pl" | ||||
| 6. from the network, using NTP [RFC1305] or DHCP option 32 [RFC2132] | 5. use HTTP to query "http://tycho.usno.navy.mil/cgi-bin/timer.pl" | |||
| that returns the IP address of the NTP server. | 6. from the network, using NTP [RFC1305] or DHCP option 32 | |||
| [RFC2132] that returns the IP address of the NTP server. | ||||
| If an implementation supports this attribute by obtaining the current | If an implementation supports this attribute by obtaining the current | |||
| time from the network (at startup or later), but the time is not | time from the network (at startup or later), but the time is not | |||
| available, then the implementation MUST return the value of this | available, then the implementation MUST return the value of this | |||
| attribute using the out-of-band 'no-value' meaning not configured. See | attribute using the out-of-band 'no-value' meaning not configured. | |||
| the beginning of section 4.1. | See the beginning of section 4.1. | |||
| Since the new "date-and-time-at-xxx" Job Description attributes refer to | Since the new "date-and-time-at-xxx" Job Description attributes refer | |||
| the "printer-current-time", they will be covered also. | to the "printer-current-time", they will be covered also. | |||
| 4.4.3 'Printer-uri | 4.4.3 Printer-uri | |||
| Must the operational attribute for printer-uri match one of the values | Must the operational attribute for printer-uri match one of the | |||
| in printer-uri-supported? | values in "printer-uri-supported"? | |||
| A forgiving printer implementation would not reject the operation. But | A forgiving printer implementation would not reject the operation. | |||
| the implementation has its rights to reject a printer or job operation | But the implementation has its rights to reject a printer or job | |||
| if the operational attribute printer-uri is not a value of the printer- | operation if the operational attribute printer-uri is not a value of | |||
| uri-supported. The printer may not be improperly configured. The request | the printer-uri-supported. The printer might not be improperly | |||
| obviously reached the printer. The printer could treat the printer-uri | configured. The request obviously reached the printer. The printer | |||
| as the logical equivalent of a value in the printer-uri-supported. It | could treat the printer-uri as the logical equivalent of a value in | |||
| would be implementation dependent for which value, and associated | the printer-uri-supported. It would be implementation dependent for | |||
| security policy, would apply. This does also apply to a job object | which value, and associated security policy, would apply. This does | |||
| specified with a printer-uri and job-id, or with a job-uri. See section | also apply to a job object specified with a printer-uri and job-id, | |||
| 4.1.3 for how to compare URI's. | or with a job-uri. See section 4.1.3 for how to compare URI's. | |||
| 4.5 Empty Jobs | 4.5 Empty Jobs | |||
| The IPP object model does not prohibit a job that contains no documents. | The IPP object model does not prohibit a job that contains no | |||
| Such a job may be created in a number of ways including a 'create-job' | documents. Such a job may be created in a number of ways including a | |||
| followed by an 'add-document' that contains no data and has the 'last- | 'create-job' followed by an 'add-document' that contains no data and | |||
| document' flag set. | has the 'last-document' flag set. | |||
| An empty job is processed just as any other job. The operation that | ||||
| "closes" an empty job is not rejected because the job is empty. If no | ||||
| other conditions exist, other than the job is empty, the response to the | ||||
| operation will indicate success. After the job is scheduled and | ||||
| processed, the job state SHALL be 'completed' | ||||
| There will be some variation in the value(s) of the 'job-state-reasons' | An empty job is processed just as any other job. The operation that | |||
| attribute. It is required that if no conditions, other than the job | "closes" an empty job is not rejected because the job is empty. If | |||
| being empty, exist the 'job-state-reasons' SHALL include the 'completed- | no other conditions exist, other than the job is empty, the response | |||
| to the operation will indicate success. After the job is scheduled | ||||
| and processed, the job state SHALL be 'completed'. | ||||
| Expires November 30, 2000 | There will be some variation in the value(s) of the "job-state- | |||
| successfully'. If other conditions existed, the 'completed-with- | reasons" attribute. It is required that if no conditions, other than | |||
| warnings' or 'completed-with-errors' values may be used." | the job being empty, exist the "job-state-reasons" SHALL include the | |||
| 'completed-successfully'. If other conditions existed, the | ||||
| 'completed-with-warnings' or 'completed-with-errors' values may be | ||||
| used. | ||||
| 5 Directory Considerations | 5 Directory Considerations | |||
| 5.1 General Directory Schema Considerations | 5.1 General Directory Schema Considerations | |||
| The [ipp-mod] document lists RECOMMENDED and OPTIONAL Printer object | The [RFC2911] document lists RECOMMENDED and OPTIONAL Printer object | |||
| attributes for directory schemas. See [ipp-mod] APPENDIX E: Generic | attributes for directory schemas. See [RFC2911] APPENDIX E: Generic | |||
| Directory Schema. | Directory Schema. | |||
| The SLP printer template is defined in the "Definition of the Printer | The SLP printer template is defined in the "Definition of the Printer | |||
| Abstract Service Type v2.0" document [svrloc-printer]. The LDAP printer | Abstract Service Type v2.0" document [svrloc-printer]. The LDAP | |||
| template is defined in the "Internet Printing Protocol (IPP): LDAP | printer template is defined in the "Internet Printing Protocol (IPP): | |||
| Schema for Printer Services" document [ldap-printer]. Both documents | LDAP Schema for Printer Services" document [ldap-printer]. Both | |||
| systematically add "printer-" to any attribute that doesn't already | documents systematically add "printer-" to any attribute that doesn't | |||
| start with "printer-" in order to keep the printer directory attributes | already start with "printer-" in order to keep the printer directory | |||
| distinct from other directory attributes. Also, instead of using | attributes distinct from other directory attributes. Also, instead | |||
| "printer-uri-supported", "uri-authentication-supported", and "uri- | of using "printer-uri-supported", "uri-authentication-supported", and | |||
| security-supported", they use a "printer-xri-supported" attribute with | "uri-security-supported", they use a "printer-xri-supported" | |||
| special syntax to contain all of the same information in a single | attribute with special syntax to contain all of the same information | |||
| attribute. | in a single attribute. | |||
| 5.2 IPP Printer with a DNS name | 5.2 IPP Printer with a DNS name | |||
| If the IPP printer has a DNS name should there be at least two values | If the IPP printer has a DNS name should there be at least two values | |||
| for the printer-uri-supported attribute. One URL with the fully | for the printer-uri-supported attribute. One URL with the fully | |||
| qualified DNS name the other with the IP address in the URL? | qualified DNS name the other with the IP address in the URL? | |||
| The printer may contain one or the other or both. It's up to the | The printer may contain one or the other or both. It's up to the | |||
| administrator to configure this attribute. | administrator to configure this attribute. | |||
| 6 Security Considerations | 6 Security Considerations | |||
| This section corresponds to the IPP-MOD Section 8 "Security | This section corresponds to the RFC2911 Section 8 "Security | |||
| Considerations. | Considerations. | |||
| 6.1 Querying jobs with IPP that were submitted using other job | 6.1 Querying jobs with IPP that were submitted using other job | |||
| submission protocols (Issue 1.32) | submission protocols (Issue 1.32) | |||
| The following clarification was added to [IPP-MOD] section 8.5: | The following clarification was added to [RFC2911] section 8.5: | |||
| 8.5 Queries on jobs submitted using non-IPP protocols | 8.5 Queries on jobs submitted using non-IPP protocols | |||
| If the device that an IPP Printer is representing is able to accept | ||||
| jobs using other job submission protocols in addition to IPP, it is | ||||
| RECOMMEND that such an implementation at least allow such "foreign" | ||||
| jobs to be queried using Get-Jobs returning "job-id" and "job-uri" | ||||
| as 'unknown'. Such an implementation NEED NOT support all of the | ||||
| same IPP job attributes as for IPP jobs. The IPP object returns | ||||
| the 'unknown' out-of-band value for any requested attribute of a | ||||
| foreign job that is supported for IPP jobs, but not for foreign | ||||
| jobs. | ||||
| Expires November 30, 2000 | It is further RECOMMENDED, that the IPP Printer generate "job-id" | |||
| and "job-uri" values for such "foreign jobs", if possible, so that | ||||
| If the device that an IPP Printer is representing is able to accept jobs | they may be targets of other IPP operations, such as Get-Job- | |||
| using other job submission protocols in addition to IPP, it is RECOMMEND | Attributes and Cancel-Job. Such an implementation also needs to | |||
| that such an implementation at least allow such "foreign" jobs to be | deal with the problem of authentication of such foreign jobs. One | |||
| queried using Get-Jobs returning "job-id" and "job-uri" as 'unknown'. | approach would be to treat all such foreign jobs as belonging to | |||
| Such an implementation NEED NOT support all of the same IPP job | users other than the user of the IPP client. Another approach | |||
| attributes as for IPP jobs. The IPP object returns the 'unknown' out- | would be for the foreign job to belong to 'anonymous'. Only if the | |||
| of-band value for any requested attribute of a foreign job that is | IPP client has been authenticated as an operator or administrator | |||
| supported for IPP jobs, but not for foreign jobs. | of the IPP Printer object, could the foreign jobs be queried by an | |||
| IPP request. Alternatively, if the security policy were to allow | ||||
| It is further RECOMMENDED, that the IPP Printer generate "job-id" and | users to query other users' jobs, then the foreign jobs would also | |||
| "job-uri" values for such "foreign jobs", if possible, so that they may | be visible to an end-user IPP client using Get-Jobs and Get-Job- | |||
| be targets of other IPP operations, such as Get-Job-Attributes and | Attributes. | |||
| Cancel-Job. Such an implementation also needs to deal with the problem | ||||
| of authentication of such foreign jobs. One approach would be to treat | ||||
| all such foreign jobs as belonging to users other than the user of the | ||||
| IPP client. Another approach would be for the foreign job to belong to | ||||
| 'anonymous'. Only if the IPP client has been authenticated as an | ||||
| operator or administrator of the IPP Printer object, could the foreign | ||||
| jobs be queried by an IPP request. Alternatively, if the security | ||||
| policy were to allow users to query other users' jobs, then the foreign | ||||
| jobs would also be visible to an end-user IPP client using Get-Jobs and | ||||
| Get-Job-Attributes. | ||||
| Thus IPP MAY be implemented as a "universal" protocol that provides | Thus IPP MAY be implemented as a "universal" protocol that provides | |||
| access to jobs submitted with any job submission protocol. As IPP | access to jobs submitted with any job submission protocol. As IPP | |||
| becomes widely implemented, providing a more universal access makes | becomes widely implemented, providing a more universal access makes | |||
| sense. | sense. | |||
| 7 Encoding and Transport | 7 Encoding and Transport | |||
| This section discusses various aspects of IPP/1.1 Encoding and Transport | This section discusses various aspects of IPP/1.1 Encoding and | |||
| [IPP-PRO]. | Transport [RFC2910]. | |||
| A server is not required to send a response until after it has received | A server is not required to send a response until after it has | |||
| the client's entire request. Hence, a client must not expect a response | received the client's entire request. Hence, a client must not | |||
| until after it has sent the entire request. However, we recommend that | expect a response until after it has sent the entire request. | |||
| the server return a response as soon as possible if an error is detected | However, we recommend that the server return a response as soon as | |||
| while the client is still sending the data, rather than waiting until | possible if an error is detected while the client is still sending | |||
| all of the data is received. Therefore, we also recommend that a client | the data, rather than waiting until all of the data is received. | |||
| listen for an error response that an IPP server MAY send before it | Therefore, we also recommend that a client listen for an error | |||
| receives all the data. In this case a client, if chunking the data, can | response that an IPP server MAY send before it receives all the data. | |||
| send a premature zero-length chunk to end the request before sending all | In this case a client, if chunking the data, can send a premature | |||
| the data (and so the client can keep the connection open for other | zero-length chunk to end the request before sending all the data (and | |||
| requests, rather than closing it). If the request is blocked for some | so the client can keep the connection open for other requests, rather | |||
| reason, a client MAY determine the reason by opening another connection | than closing it). If the request is blocked for some reason, a client | |||
| to query the server using Get-Printer-Attributes. | MAY determine the reason by opening another connection to query the | |||
| server using Get-Printer-Attributes. | ||||
| Expires November 30, 2000 | IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793] | |||
| IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793] to | to throttle clients when Printers are busy. Therefore, it is | |||
| throttle clients when Printers are busy. Therefore, it is perfectly | perfectly normal for an IPP client transmitting a Job to be blocked | |||
| normal for an IPP client transmitting a Job to be blocked for a really | for a really long time. Accordingly, socket timeouts must be | |||
| long time. Accordingly, socket timeouts must be avoided. Some socket | avoided. Some socket implementations have a timeout option, which | |||
| implementations have a timeout option, which specifies how long a write | specifies how long a write operation on a socket can be blocked | |||
| operation on a socket can be blocked before it times out and the | before it times out and the blocking ends. A client should set this | |||
| blocking ends. A client should set this option for infinite timeout | option for infinite timeout when transmitting Job submissions. | |||
| when transmitting Job submissions. | ||||
| Some IPP client applications might be able to perform other useful work | Some IPP client applications might be able to perform other useful | |||
| while a Job transmission is blocked. For example, the client may have | work while a Job transmission is blocked. For example, the client | |||
| other jobs that it could transmit to other Printers simultaneously. A | may have other jobs that it could transmit to other Printers | |||
| client may have a GUI, which must remain responsive to the user while | simultaneously. A client may have a GUI, which must remain | |||
| the Job transmission is blocked. These clients should be designed to | responsive to the user while the Job transmission is blocked. These | |||
| spawn a thread to handle the Job transmission at its own pace, leaving | clients should be designed to spawn a thread to handle the Job | |||
| the main application free to do other work. Alternatively, single- | transmission at its own pace, leaving the main application free to do | |||
| threaded applications could use non-blocking I/O. | other work. Alternatively, single-threaded applications could use | |||
| non-blocking I/O. | ||||
| Some Printer conditions, such as jam or lack of paper, could cause a | Some Printer conditions, such as jam or lack of paper, could cause a | |||
| client to be blocked indefinitely. Clients may open additional | client to be blocked indefinitely. Clients may open additional | |||
| connections to the Printer to Get-Printer-Attributes, determine the | connections to the Printer to Get-Printer-Attributes, determine the | |||
| state of the device, alert a user if the printer is stopped, and let a | state of the device, alert a user if the printer is stopped, and let | |||
| user decide whether to abort the job transmission or not. | a user decide whether to abort the job transmission or not. | |||
| In the following sections, there are tables of all HTTP headers, which | In the following sections, there are tables of all HTTP headers, | |||
| describe their use in an IPP client or server. The following is an | which describe their use in an IPP client or server. The following | |||
| explanation of each column in these tables. | is an explanation of each column in these tables. | |||
| - the "header" column contains the name of a header | - the "header" column contains the name of a header | |||
| - the "request/client" column indicates whether a client sends the | - the "request/client" column indicates whether a client sends the | |||
| header. | header. | |||
| - the "request/ server" column indicates whether a server supports | - the "request/ server" column indicates whether a server supports | |||
| the header when received. | the header when received. | |||
| - the "response/ server" column indicates whether a server sends | - the "response/ server" column indicates whether a server sends | |||
| the header. | the header. | |||
| - the "response /client" column indicates whether a client | - the "response /client" column indicates whether a client | |||
| supports the header when received. | supports the header when received. | |||
| - the "values and conditions" column specifies the allowed header | - the "values and conditions" column specifies the allowed header | |||
| values and the conditions for the header to be present in a | values and the conditions for the header to be present in a | |||
| request/response. | request/response. | |||
| The table for "request headers" does not have columns for responses, and | The table for "request headers" does not have columns for responses, | |||
| the table for "response headers" does not have columns for requests. | and the table for "response headers" does not have columns for | |||
| The following is an explanation of the values in the "request/client" | requests. | |||
| and "response/ server" columns. | ||||
| - must: the client or server MUST send the header, | The following is an explanation of the values in the "request/client" | |||
| and "response/ server" columns. | ||||
| Expires November 30, 2000 | - must: the client or server MUST send the header, | |||
| - must-if: the client or server MUST send the header when the | - must-if: the client or server MUST send the header when the | |||
| condition described in the "values and conditions" column is met, | condition described in the "values and conditions" column is | |||
| - may: the client or server MAY send the header | met, | |||
| - not: the client or server SHOULD NOT send the header. It is not | - may: the client or server MAY send the header | |||
| relevant to an IPP implementation. | - not: the client or server SHOULD NOT send the header. It is not | |||
| relevant to an IPP implementation. | ||||
| The following is an explanation of the values in the "response/client" | The following is an explanation of the values in the | |||
| and "request/ server" columns. | "response/client" and "request/ server" columns. | |||
| - must: the client or server MUST support the header, | ||||
| - may: the client or server MAY support the header | - must: the client or server MUST support the header, | |||
| - not: the client or server SHOULD NOT support the header. It is | - may: the client or server MAY support the header | |||
| - not: the client or server SHOULD NOT support the header. It is | ||||
| not relevant to an IPP implementation. | not relevant to an IPP implementation. | |||
| 7.1 General Headers | 7.1 General Headers | |||
| The following is a table for the general headers. | The following is a table for the general headers. | |||
| General- Request Response Values and Conditions | ||||
| Header | ||||
| Client Server Server Client | ||||
| Cache- must not must not "no-cache" only | General- Request Response Values and Conditions | |||
| Control | Header | |||
| Connection must-if must must- must "close" only. Both | Client Server Server Client | |||
| if client and server | ||||
| SHOULD keep a | ||||
| connection for the | ||||
| duration of a sequence | ||||
| of operations. The | ||||
| client and server MUST | ||||
| include this header | ||||
| for the last operation | ||||
| in such a sequence. | ||||
| Date may may must may per RFC 1123 [RFC1123] | Cache- must not must not "no-cache" only | |||
| from RFC 2616 | Control | |||
| [RFC2616] | ||||
| Pragma must not must not "no-cache" only | Connection must- must must- must "close" only. Both | |||
| if if client and server SHOULD | ||||
| keep a connection for | ||||
| the duration of a | ||||
| sequence of operations. | ||||
| The client and server | ||||
| MUST include this header | ||||
| for the last operation | ||||
| in such a sequence. | ||||
| Transfer- must-if must must- must "chunked" only . | Date may may must may per RFC 1123 [RFC1123] | |||
| Encoding if Header MUST be present | from RFC 2616 [RFC2616] | |||
| if Content-Length is | ||||
| absent. | ||||
| Upgrade not not not not | Pragma must not must not "no-cache" only | |||
| Expires November 30, 2000 | Transfer- must- must must- must "chunked" only . Header | |||
| General- Request Response V alues and Conditions | Encoding if if MUST be present if | |||
| Header | Content-Length is | |||
| absent. | ||||
| Client Server Server Client | Upgrade not not not not | |||
| Via not not not not | Via not not not not | |||
| 7.2 Request Headers | 7.2 Request Headers | |||
| The following is a table for the request headers. | The following is a table for the request headers. | |||
| Request-Header Client Server Request Values and Conditions | Request- Client Server Request Values and Conditions | |||
| Header | ||||
| Request- Client Server Request Values and Conditions | ||||
| Header | ||||
| Accept may must "application/ipp" only. This | Accept may must "application/ipp" only. This | |||
| value is the default if the | value is the default if the client | |||
| client omits it | omits it | |||
| Accept-Charset not not Charset information is within | Accept- not not Charset information is within the | |||
| the application/ipp entity | Charset application/ipp entity | |||
| Accept-Encoding may must empty and per RFC 2616 [RFC2616] | Accept- may must empty and per RFC 2616 [RFC2616] | |||
| and IANA registry for content- | Encoding and IANA registry for content- | |||
| codings | codings | |||
| Accept-Language not not language information is within | Accept- not not language information is within the | |||
| the application/ipp entity | Language application/ipp entity | |||
| Authorization must-if must per RFC 2616. A client MUST send | Authorization must- must per RFC 2616. A client MUST send | |||
| this header when it receives a | if this header when it receives a 401 | |||
| 401 "Unauthorized" response and | "Unauthorized" response and does | |||
| does not receive a "Proxy- | not receive a "Proxy- | |||
| Authenticate" header. | Authenticate" header. | |||
| >From not not per RFC 2616. Because RFC | From not not per RFC 2616. Because RFC | |||
| recommends sending this header | recommends sending this header | |||
| only with the user's approval, it | only with the user's approval, it | |||
| is not very useful | is not very useful | |||
| Host must must per RFC 2616 | Host must must per RFC 2616 | |||
| If-Match not not | If-Match not not | |||
| If-Modified- not not | If-Modified- not not | |||
| Since | Since | |||
| If-None-Match not not | If-None-Match not not | |||
| Expires November 30, 2000 | If-Range not not | |||
| Request-Header Client Server Request Values and Conditions | ||||
| If-Range not not | If- not not | |||
| Unmodified- | ||||
| Since | ||||
| If-Unmodified- not not | Max-Forwards not not | |||
| Since | ||||
| Max-Forwards not not | Proxy- must- not per RFC 2616. A client MUST send | |||
| Authorization if this header when it receives a 401 | ||||
| "Unauthorized" response and a | ||||
| Proxy- must-if not per RFC 2616. A client MUST send | Request- Client Server Request Values and Conditions | |||
| Authorization this header when it receives a | Header | |||
| 401 "Unauthorized" response and a | ||||
| "Proxy-Authenticate" header. | ||||
| Range not not | "Proxy-Authenticate" header. | |||
| Referrer not not | Range not not | |||
| User-Agent not not | Referrer not not | |||
| 7.3 Response Headers | User-Agent not not | |||
| The following is a table for the request headers. | 7.3 Response Headers | |||
| Response- Server Client Response Values and Conditions | The following is a table for the request headers. | |||
| Header | ||||
| Accept-Ranges not not | Response- Server Client Response Values and Conditions | |||
| Header | ||||
| Age not not | Accept-Ranges not not | |||
| Location must-if may per RFC 2616. When URI needs | Age not not | |||
| redirection. | ||||
| Proxy- not must per RFC 2616 | Location must- may per RFC 2616. When URI needs | |||
| Authenticate | if redirection. | |||
| Public may may per RFC 2616 | Proxy- not must per RFC 2616 | |||
| Authenticate | ||||
| Retry-After may may per RFC 2616 | Public may may per RFC 2616 | |||
| Server not not | Retry-After may may per RFC 2616 | |||
| Vary not not | Server not not | |||
| Warning may may per RFC 2616 | Vary not not | |||
| Expires November 30, 2000 | Warning may may per RFC 2616 | |||
| Response- Server Client Response Values and Conditions | ||||
| Header | ||||
| WWW- must-if must per RFC 2616. When a server needs to | WWW- must- must per RFC 2616. When a server needs | |||
| Authenticate authenticate a client. | Authenticate if to authenticate a client. | |||
| 7.4 Entity Headers | 7.4 Entity Headers | |||
| The following is a table for the entity headers. | The following is a table for the entity headers. | |||
| Entity-Header Request Response Values and Conditions | Entity-Header Request Response Values and | |||
| Conditions | ||||
| Client Server Server Client | Client Server Server Client | |||
| Allow not not not not | Allow not not not not | |||
| Content-Base not not not not | Content-Base not not not not | |||
| Content- may must must must per RFC 2616 and IANA | Content- may must must must per RFC 2616 and | |||
| Encoding registry for content | Encoding IANA registry for | |||
| codings. | content codings. | |||
| Content- not not not not Application/ipp | Content- not not not not Application/ipp | |||
| Language handles language | Language handles language | |||
| Content- must-if must must-if must the length of the | Content- must- must must- must the length of the | |||
| Length message-body per RFC | Length if if message-body per | |||
| 2616. Header MUST be | RFC 2616. Header | |||
| present if Transfer- | MUST be present if | |||
| Encoding is absent.. | Transfer-Encoding | |||
| is absent.. | ||||
| Content- not not not not | Content- not not not not | |||
| Location | Location | |||
| Content-MD5 may may may may per RFC 2616 | Content-MD5 may may may may per RFC 2616 | |||
| Content-Range not not not not | Content-Range not not not not | |||
| Content-Type must must must must "application/ipp" | Content-Type must must must must "application/ipp" | |||
| only | only | |||
| ETag not not not not | ETag not not not not | |||
| Expires not not not not | Expires not not not not | |||
| Last-Modified not not not not | Last-Modified not not not not | |||
| Expires November 30, 2000 | ||||
| 7.5 Optional support for HTTP/1.0 | 7.5 Optional support for HTTP/1.0 | |||
| IPP implementations consist of an HTTP layer and an IPP layer. In the | IPP implementations consist of an HTTP layer and an IPP layer. In | |||
| following discussion, the term "client" refers to the HTTP client layer | the following discussion, the term "client" refers to the HTTP client | |||
| and the term "server" refers to the HTTP server layer. The Encoding and | layer and the term "server" refers to the HTTP server layer. The | |||
| Transport document [IPP-PRO] requires that HTTP 1.1 MUST be supported by | Encoding and Transport document [RFC2910] requires that HTTP 1.1 MUST | |||
| all clients and all servers. However, a client and/or a server | be supported by all clients and all servers. However, a client | |||
| implementation may choose to also support HTTP 1.0. | and/or a server implementation may choose to also support HTTP 1.0. | |||
| - This option means that a server may choose to communicate with a | This option means that a server may choose to communicate with a | |||
| (non-conforming) client that only supports HTTP 1.0. In such cases the | (non-conforming) client that only supports HTTP 1.0. In such cases | |||
| server should not use any HTTP 1.1 specific parameters or features and | the server should not use any HTTP 1.1 specific parameters or | |||
| should respond using HTTP version number 1.0. | features and should respond using HTTP version number 1.0. | |||
| - This option also means that a client may choose to communicate with a | This option also means that a client may choose to communicate with a | |||
| (non-conforming) server that only supports HTTP 1.0. In such cases, if | (non-conforming) server that only supports HTTP 1.0. In such cases, | |||
| the server responds with an HTTP 'unsupported version number' to an HTTP | if the server responds with an HTTP 'unsupported version number' to | |||
| 1.1 request, the client should retry using HTTP version number 1.0. | an HTTP 1.1 request, the client should retry using HTTP version | |||
| number 1.0. | ||||
| 7.6 HTTP/1.1 Chunking | 7.6 HTTP/1.1 Chunking | |||
| 7.6.1 Disabling IPP Server Response Chunking | 7.6.1 Disabling IPP Server Response Chunking | |||
| Clients MUST anticipate that the HTTP/1.1 server may chunk responses and | Clients MUST anticipate that the HTTP/1.1 server may chunk responses | |||
| MUST accept them in responses. However, a (non-conforming) HTTP client | and MUST accept them in responses. However, a (non-conforming) HTTP | |||
| that is unable to accept chunked responses may attempt to request an | client that is unable to accept chunked responses may attempt to | |||
| HTTP 1.1 server not to use chunking in its response to an operation by | request an HTTP 1.1 server not to use chunking in its response to an | |||
| using the following HTTP header: | operation by using the following HTTP header: | |||
| TE: identity | TE: identity | |||
| This mechanism should not be used by a server to disable a client from | This mechanism should not be used by a server to disable a client | |||
| chunking a request, since chunking of document data is an important | from chunking a request, since chunking of document data is an | |||
| feature for clients to send long documents. | important feature for clients to send long documents. | |||
| 7.6.2 Warning About the Support of Chunked Requests | ||||
| This section describes some problems with the use of chunked requests | 7.6.2 Warning About the Support of Chunked Requests | |||
| and HTTP/1.1 servers. | ||||
| The HTTP/1.1 standard [RFC2616] requires that conforming servers support | This section describes some problems with the use of chunked requests | |||
| chunked requests for any method. However, in spite of this requirement, | and HTTP/1.1 servers. | |||
| some HTTP/1.1 implementations support chunked responses in the GET | ||||
| method, but do not support chunked POST method requests. Some HTTP/1.1 | ||||
| implementations that support CGI scripts [CGI] and/or servlets [Servlet] | ||||
| Expires November 30, 2000 | The HTTP/1.1 standard [RFC2616] requires that conforming servers | |||
| require that the client supply a Content-Length. These implementations | support chunked requests for any method. However, in spite of this | |||
| might reject a chunked POST method and return a 411 status code (Length | requirement, some HTTP/1.1 implementations support chunked responses | |||
| Required), might attempt to buffer the request and run out of room | in the GET method, but do not support chunked POST method requests. | |||
| returning a 413 status code (Request Entity Too Large), or might | Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or | |||
| successfully accept the chunked request. | servlets [Servlet] require that the client supply a Content-Length. | |||
| These implementations might reject a chunked POST method and return a | ||||
| 411 status code (Length Required), might attempt to buffer the | ||||
| request and run out of room returning a 413 status code (Request | ||||
| Entity Too Large), or might successfully accept the chunked request. | ||||
| Because of this lack of conformance of HTTP servers to the HTTP/1.1 | Because of this lack of conformance of HTTP servers to the HTTP/1.1 | |||
| standard, the IPP standard [IPP-PRO] REQUIRES that a conforming IPP | standard, the IPP standard [RFC2910] REQUIRES that a conforming IPP | |||
| Printer object implementation support chunked requests and that | Printer object implementation support chunked requests and that | |||
| conforming clients accept chunked responses. Therefore, IPP object | conforming clients accept chunked responses. Therefore, IPP object | |||
| implementers are warned to seek HTTP server implementations that support | implementers are warned to seek HTTP server implementations that | |||
| chunked POST requests in order to conform to the IPP standard and/or use | support chunked POST requests in order to conform to the IPP standard | |||
| implementation techniques that support chunked POST requests. | and/or use implementation techniques that support chunked POST | |||
| requests. | ||||
| 8 References | 8 References | |||
| [CGI] | [CGI] | |||
| CGI/1.1 (http://www.ietf.org/internet-drafts/draft-coar-cgi-v11- | CGI/1.1 (http://www.ietf.org/internet-drafts/draft-coar-cgi-v11- | |||
| 00.txt). | 00.txt). | |||
| [IPP-MOD] | [ldap-printer] | |||
| R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, | ||||
| "Internet Printing Protocol/1.0: Model and Semantics", draft-ietf- | ||||
| ipp-model-v11-06.txt, March 1, 2000. | ||||
| [IPP-PRO] | ||||
| Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing | ||||
| Protocol/1.0: Encoding and Transport", draft-ietf-ipp-protocol-v11- | ||||
| 05.txt, March 1, 2000. | ||||
| [ldap-printer] | ||||
| Fleming, P., Jones, K., Lewis, H., McDonald, I., "Internet Printing | Fleming, P., Jones, K., Lewis, H., McDonald, I., "Internet Printing | |||
| Protocol (IPP): LDAP Schema for Printer Services", <draft-ietf-ipp- | Protocol (IPP): LDAP Schema for Printer Services", <draft-ietf-ipp- | |||
| ldap-printer-schema-01.txt>, work in progress, April 27, 2000. | ldap-printer-schema-01.txt>, work in progress, April 27, 2000. | |||
| [RFC793] | [RFC793] | |||
| J. Postel, "Transmission Control Protocol", RFC 793. | J. Postel, "Transmission Control Protocol", RFC 793. | |||
| [RFC1123] | [RFC1123] | |||
| Braden, S., "Requirements for Internet Hosts - Application and | Braden, S., "Requirements for Internet Hosts - Application and | |||
| Support", RFC 1123, October, 1989. | Support", RFC 1123, October, 1989. | |||
| [RFC2026] | [RFC2026] | |||
| S. Bradner, "The Internet Standards Process -- Revision 3", RFC | S. Bradner, "The Internet Standards Process -- Revision 3", RFC | |||
| 2026, October 1996. | 2026, October 1996. | |||
| [RFC2119] | [RFC2119] | |||
| Expires November 30, 2000 | ||||
| S. Bradner, "Key words for use in RFCs to Indicate Requirement | S. Bradner, "Key words for use in RFCs to Indicate Requirement | |||
| Levels", RFC 2119 , March 1997. | Levels", RFC 2119 , March 1997. | |||
| [RFC2396] | [RFC2396] | |||
| Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource | Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource | |||
| Identifiers (URI): Generic Syntax", RFC 2396, August 1998. | Identifiers (URI): Generic Syntax", RFC 2396, August 1998. | |||
| [RFC2565] | [RFC2565] | |||
| R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, | R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, | |||
| "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, | "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, | |||
| April 1999. | April 1999. | |||
| [RFC2566] | [RFC2566] | |||
| Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing | Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing | |||
| Protocol/1.0: Encoding and Transport", RFC 2565, April 1999. | Protocol/1.0: Encoding and Transport", RFC 2565, April 1999. | |||
| [RFC2567] | [RFC2567] | |||
| Wright, D., "Design Goals for an Internet Printing Protocol", | Wright, D., "Design Goals for an Internet Printing Protocol", | |||
| draft-ietf-ipp-req-03.txt, November, 1998. | draft-ietf-ipp-req-03.txt, November, 1998. | |||
| [RFC2568 | [RFC2568 | |||
| Zilles, S., "Rationale for the Structure and Model and Protocol for | Zilles, S., "Rationale for the Structure and Model and Protocol for | |||
| the Internet Printing Protocol", RFC 2568, April 1999. | the Internet Printing Protocol", RFC 2568, April 1999. | |||
| [RFC2569] | [RFC2569] | |||
| Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between | Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between | |||
| LPD and IPP Protocols", RFC 2569, April 1999. | LPD and IPP Protocols", RFC 2569, April 1999. | |||
| [RFC2616] | [RFC2616] | |||
| R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. | R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. | |||
| Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", | Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", | |||
| RFC 2616, June 1999. | RFC 2616, June 1999. | |||
| [Servlet] | [RFC2910] | |||
| Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing | ||||
| Protocol/1.0: Encoding and Transport", RFC 2910, September, 2000. | ||||
| [RFC2911] | ||||
| R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, | ||||
| "Internet Printing Protocol/1.0: Model and Semantics", RFC 2911, | ||||
| September, 2000. | ||||
| [Servlet] | ||||
| Servlet Specification Version 2.1 | Servlet Specification Version 2.1 | |||
| (http://java.sun.com/products/servlet/2.1/index.html). | (http://java.sun.com/products/servlet/2.1/index.html). | |||
| [svrloc-printer] | [svrloc-printer] | |||
| St. Pierre, P., Isaacson, S., McDonald, I., "Definition of the | St. Pierre, P., Isaacson, S., McDonald, I., "Definition of the | |||
| Printer Abstract Service Type v2.0", <draft-ietf-svrloc-printer- | Printer Abstract Service Type v2.0", <draft-ietf-svrloc-printer- | |||
| scheme-06.txt>, work in progress, March 8, 2000. | scheme-06.txt>, work in progress, March 8, 2000. | |||
| [SSL] | [SSL] | |||
| Netscape, The SSL Protocol, Version 3, (Text version 3.02), | Netscape, The SSL Protocol, Version 3, (Text version 3.02), | |||
| November 1996. | November 1996. | |||
| 9 Authors' Address | 9 Authors' Address | |||
| Expires November 30, 2000 | Thomas N. Hastings | |||
| Thomas N. Hastings | Xerox Corporation | |||
| Xerox Corporation | 701 Aviation Blvd. | |||
| 701 Aviation Blvd. | El Segundo, CA 90245 | |||
| El Segundo, CA 90245 | hastings@cp10.es.xerox.com | |||
| hastings@cp10.es.xerox.com | ||||
| Carl-Uno Manros | ||||
| Xerox Corporation | ||||
| 701 Aviation Blvd. | ||||
| El Segundo, CA 90245 | ||||
| manros@cp10.es.xerox.com | ||||
| Carl Kugler | ||||
| Mail Stop 003G | ||||
| IBM Printing Systems Co | ||||
| 6300 Diagonal Hwy | ||||
| Boulder CO 80301 | ||||
| Kugler@us.ibm.com | ||||
| Henrik Holst | Carl-Uno Manros | |||
| i-data Printing Systems | Xerox Corporation | |||
| Vadstrupvej 35-43 | 701 Aviation Blvd. | |||
| 2880 Bagsvaerd, Denmark | El Segundo, CA 90245 | |||
| hh@I-data.com | manros@cp10.es.xerox.com | |||
| Peter Zehler | Carl Kugler | |||
| Xerox Corporation | Mail Stop 003G | |||
| 800 Philips Road | IBM Printing Systems Co | |||
| Webster, NY 14580 | 6300 Diagonal Hwy | |||
| Boulder CO 80301 | ||||
| Kugler@us.ibm.com | ||||
| Phone: 716 265-8755 | Henrik Holst | |||
| peter.zehler@usa.xerox.com | i-data Printing Systems | |||
| Vadstrupvej 35-43 | ||||
| 2880 Bagsvaerd, Denmark | ||||
| hh@I-data.com | ||||
| 10 Notices | Peter Zehler | |||
| Xerox Corporation | ||||
| 800 Philips Road | ||||
| Webster, NY 14580 | ||||
| peter.zehler@usa.xerox.com | ||||
| The IETF takes no position regarding the validity or scope of any | 10 Full Copyright Statement | |||
| intellectual property or other rights that might be claimed to pertain | ||||
| to the implementation or use of the technology described in this | ||||
| document or the extent to which any license under such rights might or | ||||
| might not be available; neither does it represent that it has made any | ||||
| effort to identify any such rights. Information on the IETF's | ||||
| procedures with respect to rights in standards-track and standards- | ||||
| related documentation can be found in BCP-11[BCP-11]. Copies of claims | ||||
| of rights made available for publication and any assurances of licenses | ||||
| to be made available, or the result of an attempt made to obtain a | ||||
| general license or permission for the use of such proprietary rights by | ||||
| implementers or users of this specification can be obtained from the | ||||
| IETF Secretariat. | ||||
| Expires November 30, 2000 | Copyright (C) The Internet Society (1999). All Rights Reserved | |||
| The IETF invites any interested party to bring to its attention any | ||||
| copyrights, patents or patent applications, or other proprietary rights, | ||||
| which may cover technology that may be required to practice this | ||||
| standard. Please address the information to the IETF Executive | ||||
| Director. | ||||
| 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. | ||||
| This document and translations of it may be copied and furnished to | The limited permissions granted above are perpetual and will not be | |||
| others, and derivative works that comment on or otherwise explain it or | revoked by the Internet Society or its successors or assigns. | |||
| 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 | This document and the information contained herein is provided on an | |||
| revoked by the Internet Society or its successors or assigns. | "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. | ||||
| This document and the information contained herein is provided on an "AS | Acknowledgement | |||
| 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. | ||||
| Expires November 30, 2000 | Funding for the RFC Editor function is currently provided by the | |||
| Internet Society. | ||||
| End of changes. 578 change blocks. | ||||
| 2680 lines changed or deleted | 2617 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||