| < draft-sweet-rfc2911bis-09.txt | draft-sweet-rfc2911bis-11.txt > | |||
|---|---|---|---|---|
| IPP WG M. Sweet | IPP WG M. Sweet | |||
| Internet-Draft Apple Inc. | Internet-Draft Apple Inc. | |||
| Obsoletes: 2911,3381,3382 (if approved) I. McDonald | Obsoletes: 2911,3381,3382 (if approved) I. McDonald | |||
| Intended status: Standards Track High North, Inc. | Intended status: Standards Track High North, Inc. | |||
| Expires: October 22, 2016 April 20, 2016 | Expires: February 26, 2017 August 25, 2016 | |||
| Internet Printing Protocol/1.1: Model and Semantics | Internet Printing Protocol/1.1: Model and Semantics | |||
| draft-sweet-rfc2911bis-09 | draft-sweet-rfc2911bis-11 | |||
| Abstract | Abstract | |||
| This document is one of a set of documents, which together describe | The Internet Printing Protocol (IPP) is an application level protocol | |||
| all aspects of the Internet Printing Protocol (IPP). IPP is an | for distributed printing using Internet tools and technologies. This | |||
| application level protocol that can be used for distributed printing | document describes a simplified model consisting of abstract objects, | |||
| using Internet tools and technologies. This document describes a | attributes, and operations that is independent of encoding and | |||
| simplified model consisting of abstract objects, their attributes, | transport. The model consists of several objects including Printers | |||
| and their operations that is independent of encoding and transport. | and Jobs. Jobs optionally support multiple Documents. | |||
| The model consists of several objects including Printers and Jobs. | ||||
| Jobs optionally support multiple Documents. IPP 1.1 semantics allow | ||||
| End Users and Operators to query Printer capabilities, submit print | ||||
| jobs, inquire about the status of print Jobs and printers, and | ||||
| cancel, hold, and release print Jobs. IPP 1.1 semantics allow | ||||
| Operators to pause and resume (Jobs from) Printer objects. This | ||||
| document also addresses security, internationalization, and directory | ||||
| issues. | ||||
| Editor's Note | IPP semantics allow End Users and Operators to query Printer | |||
| capabilities, submit print Jobs, inquire about the status of print | ||||
| Jobs and Printers, and cancel, hold, and release print Jobs. IPP | ||||
| semantics also allow Operators to pause and resume Jobs and Printers. | ||||
| Security, internationalization, and directory issues are also | ||||
| addressed by the model and semantics. The IPP message encoding and | ||||
| transport are described in IPP/1.1: Encoding and Transport | ||||
| [RFC2910bis]. | ||||
| This document obsoletes RFCs 2911, 3381, and 3382. | ||||
| Editor's Note (To Be Removed by RFC Editor) | ||||
| This draft is being submitted as an AD-sponsored replacement of RFCs | This draft is being submitted as an AD-sponsored replacement of RFCs | |||
| 2911, 3381, and 3382, with drafts being reviewed and edited by the | 2911, 3381, and 3382, with drafts being reviewed and edited by the | |||
| IEEE-ISTO's Printer Working Group IPP WG. The initial goal is to | IEEE-ISTO's Printer Working Group IPP WG. The initial goal is to | |||
| have an clean version of IPP/1.1 as an IETF Proposed Standard. The | have an clean version of IPP/1.1 as an IETF Proposed Standard. The | |||
| long-term goal is to advance IPP/1.1 to IETF Internet Standard. | long-term goal is to advance IPP/1.1 to IETF Internet Standard. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| skipping to change at page 2, line 7 ¶ | skipping to change at page 2, line 10 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| 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 | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on October 22, 2016. | This Internet-Draft will expire on February 26, 2017. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 1.1. Simplified Printing Model . . . . . . . . . . . . . . . . . 11 | 1.1. Simplified Printing Model . . . . . . . . . . . . . . . . . 11 | |||
| 2. Conventions Used in This Document . . . . . . . . . . . . . . 13 | 2. Conventions Used in This Document . . . . . . . . . . . . . . 14 | |||
| 2.1. Requirements Language . . . . . . . . . . . . . . . . . . . 13 | 2.1. Requirements Language . . . . . . . . . . . . . . . . . . . 14 | |||
| 2.2. Printing Terminology . . . . . . . . . . . . . . . . . . . 14 | 2.2. Printing Terminology . . . . . . . . . . . . . . . . . . . 14 | |||
| 2.3. Model Terminology . . . . . . . . . . . . . . . . . . . . . 14 | 2.3. Model Terminology . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 2.3.1. Administrator . . . . . . . . . . . . . . . . . . . . . . 14 | 2.3.1. Administrator . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 2.3.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . 15 | 2.3.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 2.3.2.1. Attribute Group Name . . . . . . . . . . . . . . . . . 15 | 2.3.2.1. Attribute Group Name . . . . . . . . . . . . . . . . . 15 | |||
| 2.3.2.2. Attribute Name . . . . . . . . . . . . . . . . . . . . 15 | 2.3.2.2. Attribute Name . . . . . . . . . . . . . . . . . . . . 15 | |||
| 2.3.2.3. Attribute Syntax . . . . . . . . . . . . . . . . . . . 15 | 2.3.2.3. Attribute Syntax . . . . . . . . . . . . . . . . . . . 15 | |||
| 2.3.2.4. Attribute Value . . . . . . . . . . . . . . . . . . . . 15 | 2.3.2.4. Attribute Value . . . . . . . . . . . . . . . . . . . . 16 | |||
| 2.3.3. End User . . . . . . . . . . . . . . . . . . . . . . . . 16 | 2.3.3. End User . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 2.3.4. Impression . . . . . . . . . . . . . . . . . . . . . . . 16 | 2.3.4. Impression . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 2.3.5. Input Page . . . . . . . . . . . . . . . . . . . . . . . 16 | 2.3.5. Input Page . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 2.3.6. Job Creation Operation . . . . . . . . . . . . . . . . . 16 | 2.3.6. Job Creation Operation . . . . . . . . . . . . . . . . . 16 | |||
| 2.3.7. Keyword . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 2.3.7. Keyword . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 2.3.8. Media Sheet . . . . . . . . . . . . . . . . . . . . . . . 16 | 2.3.8. Media Sheet . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 2.3.9. Operator . . . . . . . . . . . . . . . . . . . . . . . . 16 | 2.3.9. Operator . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 2.3.10. Set . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 2.3.10. Set . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 2.3.11. Supports . . . . . . . . . . . . . . . . . . . . . . . . 17 | 2.3.11. Supports . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 2.3.12. Terminating State . . . . . . . . . . . . . . . . . . . . 19 | 2.3.12. Terminating State . . . . . . . . . . . . . . . . . . . . 19 | |||
| 2.4. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 19 | 2.4. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 3. IPP Objects . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 3. IPP Objects . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 3.1. Printer Object . . . . . . . . . . . . . . . . . . . . . . 21 | 3.1. Printer Object . . . . . . . . . . . . . . . . . . . . . . 21 | |||
| 3.2. Job Object . . . . . . . . . . . . . . . . . . . . . . . . 23 | 3.2. Job Object . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 3.3. Object Relationships . . . . . . . . . . . . . . . . . . . 24 | 3.3. Object Relationships . . . . . . . . . . . . . . . . . . . 24 | |||
| 3.4. Object Identity . . . . . . . . . . . . . . . . . . . . . . 25 | 3.4. Object Identity . . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 4. IPP Operations . . . . . . . . . . . . . . . . . . . . . . . 27 | 4. IPP Operations . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 4.1. Common Semantics . . . . . . . . . . . . . . . . . . . . . 29 | 4.1. Common Semantics . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 4.1.1. Required Parameters . . . . . . . . . . . . . . . . . . . 29 | 4.1.1. Required Parameters . . . . . . . . . . . . . . . . . . . 29 | |||
| 4.1.2. Operation IDs and Request IDs . . . . . . . . . . . . . . 29 | 4.1.2. Operation IDs and Request IDs . . . . . . . . . . . . . . 29 | |||
| 4.1.3. Attributes . . . . . . . . . . . . . . . . . . . . . . . 30 | 4.1.3. Attributes . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 4.1.4. Character Set and Natural Language Operation Attributes . 32 | 4.1.4. Character Set and Natural Language Operation Attributes . 32 | |||
| 4.1.4.1. Request Operation Attributes . . . . . . . . . . . . . 33 | 4.1.4.1. Request Operation Attributes . . . . . . . . . . . . . 33 | |||
| 4.1.4.2. Response Operation Attributes . . . . . . . . . . . . . 36 | 4.1.4.2. Response Operation Attributes . . . . . . . . . . . . . 36 | |||
| 4.1.5. Operation Targets . . . . . . . . . . . . . . . . . . . . 38 | 4.1.5. Operation Targets . . . . . . . . . . . . . . . . . . . . 37 | |||
| 4.1.6. Operation Response Status Codes and Status Messages . . . 39 | 4.1.6. Operation Response Status Codes and Status Messages . . . 39 | |||
| 4.1.6.1. "status-code" (type2 enum) . . . . . . . . . . . . . . 39 | 4.1.6.1. "status-code" (type2 enum) . . . . . . . . . . . . . . 39 | |||
| 4.1.6.2. "status-message" (text(255)) . . . . . . . . . . . . . 40 | 4.1.6.2. "status-message" (text(255)) . . . . . . . . . . . . . 40 | |||
| 4.1.6.3. "detailed-status-message" (text(MAX)) . . . . . . . . . 41 | 4.1.6.3. "detailed-status-message" (text(MAX)) . . . . . . . . . 41 | |||
| 4.1.6.4. "document-access-error" (text(MAX)) . . . . . . . . . . 42 | 4.1.6.4. "document-access-error" (text(MAX)) . . . . . . . . . . 41 | |||
| 4.1.7. Unsupported Attributes . . . . . . . . . . . . . . . . . 42 | 4.1.7. Unsupported Attributes . . . . . . . . . . . . . . . . . 42 | |||
| 4.1.8. Versions . . . . . . . . . . . . . . . . . . . . . . . . 43 | 4.1.8. Versions . . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
| 4.1.9. Job Creation Operations . . . . . . . . . . . . . . . . . 46 | 4.1.9. Job Creation Operations . . . . . . . . . . . . . . . . . 46 | |||
| 4.2. Printer Operations . . . . . . . . . . . . . . . . . . . . 49 | 4.2. Printer Operations . . . . . . . . . . . . . . . . . . . . 48 | |||
| 4.2.1. Print-Job Operation . . . . . . . . . . . . . . . . . . . 49 | 4.2.1. Print-Job Operation . . . . . . . . . . . . . . . . . . . 48 | |||
| 4.2.1.1. Print-Job Request . . . . . . . . . . . . . . . . . . . 49 | 4.2.1.1. Print-Job Request . . . . . . . . . . . . . . . . . . . 49 | |||
| 4.2.1.2. Print-Job Response . . . . . . . . . . . . . . . . . . 54 | 4.2.1.2. Print-Job Response . . . . . . . . . . . . . . . . . . 54 | |||
| 4.2.2. Print-URI Operation . . . . . . . . . . . . . . . . . . . 56 | 4.2.2. Print-URI Operation . . . . . . . . . . . . . . . . . . . 56 | |||
| 4.2.3. Validate-Job Operation . . . . . . . . . . . . . . . . . 56 | 4.2.3. Validate-Job Operation . . . . . . . . . . . . . . . . . 56 | |||
| 4.2.4. Create-Job Operation . . . . . . . . . . . . . . . . . . 57 | 4.2.4. Create-Job Operation . . . . . . . . . . . . . . . . . . 57 | |||
| 4.2.5. Get-Printer-Attributes Operation . . . . . . . . . . . . 58 | 4.2.5. Get-Printer-Attributes Operation . . . . . . . . . . . . 58 | |||
| 4.2.5.1. Get-Printer-Attributes Request . . . . . . . . . . . . 59 | 4.2.5.1. Get-Printer-Attributes Request . . . . . . . . . . . . 59 | |||
| 4.2.5.2. Get-Printer-Attributes Response . . . . . . . . . . . . 61 | 4.2.5.2. Get-Printer-Attributes Response . . . . . . . . . . . . 61 | |||
| 4.2.6. Get-Jobs Operation . . . . . . . . . . . . . . . . . . . 62 | 4.2.6. Get-Jobs Operation . . . . . . . . . . . . . . . . . . . 62 | |||
| 4.2.6.1. Get-Jobs Request . . . . . . . . . . . . . . . . . . . 62 | 4.2.6.1. Get-Jobs Request . . . . . . . . . . . . . . . . . . . 62 | |||
| skipping to change at page 4, line 25 ¶ | skipping to change at page 4, line 27 ¶ | |||
| 5.1.2. 'text' . . . . . . . . . . . . . . . . . . . . . . . . . 89 | 5.1.2. 'text' . . . . . . . . . . . . . . . . . . . . . . . . . 89 | |||
| 5.1.2.1. 'textWithoutLanguage' . . . . . . . . . . . . . . . . . 90 | 5.1.2.1. 'textWithoutLanguage' . . . . . . . . . . . . . . . . . 90 | |||
| 5.1.2.2. 'textWithLanguage' . . . . . . . . . . . . . . . . . . 90 | 5.1.2.2. 'textWithLanguage' . . . . . . . . . . . . . . . . . . 90 | |||
| 5.1.3. 'name' . . . . . . . . . . . . . . . . . . . . . . . . . 91 | 5.1.3. 'name' . . . . . . . . . . . . . . . . . . . . . . . . . 91 | |||
| 5.1.3.1. 'nameWithoutLanguage' . . . . . . . . . . . . . . . . . 92 | 5.1.3.1. 'nameWithoutLanguage' . . . . . . . . . . . . . . . . . 92 | |||
| 5.1.3.2. 'nameWithLanguage' . . . . . . . . . . . . . . . . . . 92 | 5.1.3.2. 'nameWithLanguage' . . . . . . . . . . . . . . . . . . 92 | |||
| 5.1.3.3. Matching 'name' attribute values . . . . . . . . . . . 93 | 5.1.3.3. Matching 'name' attribute values . . . . . . . . . . . 93 | |||
| 5.1.4. 'keyword' . . . . . . . . . . . . . . . . . . . . . . . . 94 | 5.1.4. 'keyword' . . . . . . . . . . . . . . . . . . . . . . . . 94 | |||
| 5.1.5. 'enum' . . . . . . . . . . . . . . . . . . . . . . . . . 95 | 5.1.5. 'enum' . . . . . . . . . . . . . . . . . . . . . . . . . 95 | |||
| 5.1.6. 'uri' . . . . . . . . . . . . . . . . . . . . . . . . . . 95 | 5.1.6. 'uri' . . . . . . . . . . . . . . . . . . . . . . . . . . 95 | |||
| 5.1.7. 'uriScheme' . . . . . . . . . . . . . . . . . . . . . . . 95 | 5.1.7. 'uriScheme' . . . . . . . . . . . . . . . . . . . . . . . 96 | |||
| 5.1.8. 'charset' . . . . . . . . . . . . . . . . . . . . . . . . 96 | 5.1.8. 'charset' . . . . . . . . . . . . . . . . . . . . . . . . 96 | |||
| 5.1.9. 'naturalLanguage' . . . . . . . . . . . . . . . . . . . . 97 | 5.1.9. 'naturalLanguage' . . . . . . . . . . . . . . . . . . . . 97 | |||
| 5.1.10. 'mimeMediaType' . . . . . . . . . . . . . . . . . . . . . 98 | 5.1.10. 'mimeMediaType' . . . . . . . . . . . . . . . . . . . . . 98 | |||
| 5.1.10.1. Application/octet-stream -- Auto-Sensing the Document | 5.1.10.1. Application/octet-stream -- Auto-Sensing the Document | |||
| format . . . . . . . . . . . . . . . . . . . . . . . . 98 | format . . . . . . . . . . . . . . . . . . . . . . . . 99 | |||
| 5.1.11. 'octetString' . . . . . . . . . . . . . . . . . . . . . . 99 | 5.1.11. 'octetString' . . . . . . . . . . . . . . . . . . . . . . 100 | |||
| 5.1.12. 'boolean' . . . . . . . . . . . . . . . . . . . . . . . . 100 | 5.1.12. 'boolean' . . . . . . . . . . . . . . . . . . . . . . . . 100 | |||
| 5.1.13. 'integer' . . . . . . . . . . . . . . . . . . . . . . . . 100 | 5.1.13. 'integer' . . . . . . . . . . . . . . . . . . . . . . . . 100 | |||
| 5.1.14. 'rangeOfInteger' . . . . . . . . . . . . . . . . . . . . 100 | 5.1.14. 'rangeOfInteger' . . . . . . . . . . . . . . . . . . . . 100 | |||
| 5.1.15. 'dateTime' . . . . . . . . . . . . . . . . . . . . . . . 100 | 5.1.15. 'dateTime' . . . . . . . . . . . . . . . . . . . . . . . 100 | |||
| 5.1.16. 'resolution' . . . . . . . . . . . . . . . . . . . . . . 100 | 5.1.16. 'resolution' . . . . . . . . . . . . . . . . . . . . . . 101 | |||
| 5.1.17. 'collection' . . . . . . . . . . . . . . . . . . . . . . 101 | 5.1.17. 'collection' . . . . . . . . . . . . . . . . . . . . . . 101 | |||
| 5.1.18. '1setOf X' . . . . . . . . . . . . . . . . . . . . . . . 101 | 5.1.18. '1setOf X' . . . . . . . . . . . . . . . . . . . . . . . 101 | |||
| 5.2. Job Template Attributes . . . . . . . . . . . . . . . . . . 101 | 5.2. Job Template Attributes . . . . . . . . . . . . . . . . . . 102 | |||
| 5.2.1. job-priority (integer(1:100)) . . . . . . . . . . . . . . 105 | 5.2.1. job-priority (integer(1:100)) . . . . . . . . . . . . . . 105 | |||
| 5.2.2. job-hold-until (type2 keyword | name (MAX)) . . . . . . . 106 | 5.2.2. job-hold-until (type2 keyword | name (MAX)) . . . . . . . 106 | |||
| 5.2.3. job-sheets (type2 keyword | name(MAX)) . . . . . . . . . 107 | 5.2.3. job-sheets (type2 keyword | name(MAX)) . . . . . . . . . 108 | |||
| 5.2.4. multiple-document-handling (type2 keyword) . . . . . . . 108 | 5.2.4. multiple-document-handling (type2 keyword) . . . . . . . 108 | |||
| 5.2.5. copies (integer(1:MAX)) . . . . . . . . . . . . . . . . . 109 | 5.2.5. copies (integer(1:MAX)) . . . . . . . . . . . . . . . . . 110 | |||
| 5.2.6. finishings (1setOf type2 enum) . . . . . . . . . . . . . 110 | 5.2.6. finishings (1setOf type2 enum) . . . . . . . . . . . . . 110 | |||
| 5.2.7. page-ranges (1setOf rangeOfInteger (1:MAX)) . . . . . . . 112 | 5.2.7. page-ranges (1setOf rangeOfInteger (1:MAX)) . . . . . . . 113 | |||
| 5.2.8. sides (type2 keyword) . . . . . . . . . . . . . . . . . . 113 | 5.2.8. sides (type2 keyword) . . . . . . . . . . . . . . . . . . 114 | |||
| 5.2.9. number-up (integer(1:MAX)) . . . . . . . . . . . . . . . 114 | 5.2.9. number-up (integer(1:MAX)) . . . . . . . . . . . . . . . 114 | |||
| 5.2.10. orientation-requested (type2 enum) . . . . . . . . . . . 115 | 5.2.10. orientation-requested (type2 enum) . . . . . . . . . . . 115 | |||
| 5.2.11. media (type2 keyword | name(MAX)) . . . . . . . . . . . . 116 | 5.2.11. media (type2 keyword | name(MAX)) . . . . . . . . . . . . 116 | |||
| 5.2.12. printer-resolution (resolution) . . . . . . . . . . . . . 117 | 5.2.12. printer-resolution (resolution) . . . . . . . . . . . . . 117 | |||
| 5.2.13. print-quality (type2 enum) . . . . . . . . . . . . . . . 118 | 5.2.13. print-quality (type2 enum) . . . . . . . . . . . . . . . 118 | |||
| 5.3. Job Description and Status Attributes . . . . . . . . . . . 118 | 5.3. Job Description and Status Attributes . . . . . . . . . . . 118 | |||
| 5.3.1. job-id (integer(1:MAX)) . . . . . . . . . . . . . . . . . 120 | 5.3.1. job-id (integer(1:MAX)) . . . . . . . . . . . . . . . . . 120 | |||
| 5.3.2. job-uri (uri) . . . . . . . . . . . . . . . . . . . . . . 120 | 5.3.2. job-uri (uri) . . . . . . . . . . . . . . . . . . . . . . 120 | |||
| 5.3.3. job-printer-uri (uri) . . . . . . . . . . . . . . . . . . 120 | 5.3.3. job-printer-uri (uri) . . . . . . . . . . . . . . . . . . 120 | |||
| 5.3.4. job-more-info (uri) . . . . . . . . . . . . . . . . . . . 121 | 5.3.4. job-more-info (uri) . . . . . . . . . . . . . . . . . . . 121 | |||
| skipping to change at page 6, line 44 ¶ | skipping to change at page 6, line 46 ¶ | |||
| 6.2. IPP Object Conformance Requirements . . . . . . . . . . . . 159 | 6.2. IPP Object Conformance Requirements . . . . . . . . . . . . 159 | |||
| 6.2.1. Objects . . . . . . . . . . . . . . . . . . . . . . . . . 159 | 6.2.1. Objects . . . . . . . . . . . . . . . . . . . . . . . . . 159 | |||
| 6.2.2. Operations . . . . . . . . . . . . . . . . . . . . . . . 159 | 6.2.2. Operations . . . . . . . . . . . . . . . . . . . . . . . 159 | |||
| 6.2.3. IPP Object Attributes . . . . . . . . . . . . . . . . . . 161 | 6.2.3. IPP Object Attributes . . . . . . . . . . . . . . . . . . 161 | |||
| 6.2.4. Versions . . . . . . . . . . . . . . . . . . . . . . . . 161 | 6.2.4. Versions . . . . . . . . . . . . . . . . . . . . . . . . 161 | |||
| 6.2.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . 162 | 6.2.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . 162 | |||
| 6.2.6. Attribute Syntaxes . . . . . . . . . . . . . . . . . . . 162 | 6.2.6. Attribute Syntaxes . . . . . . . . . . . . . . . . . . . 162 | |||
| 6.2.7. Security . . . . . . . . . . . . . . . . . . . . . . . . 162 | 6.2.7. Security . . . . . . . . . . . . . . . . . . . . . . . . 162 | |||
| 6.3. Charset and Natural Language Requirements . . . . . . . . . 163 | 6.3. Charset and Natural Language Requirements . . . . . . . . . 163 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 163 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 163 | |||
| 7.1. Typed 'keyword' and 'enum' Extensions . . . . . . . . . . . 164 | 7.1. Object Extensions . . . . . . . . . . . . . . . . . . . . . 164 | |||
| 7.2. Attribute Extensibility . . . . . . . . . . . . . . . . . . 165 | 7.2. Attribute Extensibility . . . . . . . . . . . . . . . . . . 164 | |||
| 7.3. Attribute Syntax Extensibility . . . . . . . . . . . . . . 166 | 7.3. Keyword Extensibility . . . . . . . . . . . . . . . . . . . 165 | |||
| 7.4. Operation Extensibility . . . . . . . . . . . . . . . . . . 166 | 7.4. Enum Extensibility . . . . . . . . . . . . . . . . . . . . 166 | |||
| 7.5. Attribute Group Extensibility . . . . . . . . . . . . . . . 166 | 7.5. Attribute Group Extensibility . . . . . . . . . . . . . . . 166 | |||
| 7.6. Status Code Extensibility . . . . . . . . . . . . . . . . . 166 | 7.6. Out-of-band Attribute Value Extensibility . . . . . . . . . 167 | |||
| 7.7. Out-of-band Attribute Value Extensibility . . . . . . . . . 167 | 7.7. Attribute Syntax Extensibility . . . . . . . . . . . . . . 167 | |||
| 7.8. Registration of MIME types/sub-types for Document formats . 167 | 7.8. Operation Extensibility . . . . . . . . . . . . . . . . . . 167 | |||
| 7.9. Registration of charsets for use in 'charset' attribute | 7.9. Status Code Extensibility . . . . . . . . . . . . . . . . . 168 | |||
| values . . . . . . . . . . . . . . . . . . . . . . . . . . 167 | ||||
| 8. Internationalization Considerations . . . . . . . . . . . . . 168 | 8. Internationalization Considerations . . . . . . . . . . . . . 168 | |||
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 171 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 172 | |||
| 9.1. Security Scenarios . . . . . . . . . . . . . . . . . . . . 172 | 9.1. Security Scenarios . . . . . . . . . . . . . . . . . . . . 173 | |||
| 9.1.1. Client and Server in the Same Security Domain . . . . . . 172 | 9.1.1. Client and Server in the Same Security Domain . . . . . . 173 | |||
| 9.1.2. Client and Server in Different Security Domains . . . . . 173 | 9.1.2. Client and Server in Different Security Domains . . . . . 173 | |||
| 9.1.3. Print by Reference . . . . . . . . . . . . . . . . . . . 173 | 9.1.3. Print by Reference . . . . . . . . . . . . . . . . . . . 174 | |||
| 9.2. URIs in Operation, Job, and Printer attributes . . . . . . 173 | 9.2. URIs in Operation, Job, and Printer attributes . . . . . . 174 | |||
| 9.3. URIs for each authentication mechanisms . . . . . . . . . . 174 | 9.3. URIs for each authentication mechanisms . . . . . . . . . . 174 | |||
| 9.4. Restricted Queries . . . . . . . . . . . . . . . . . . . . 175 | 9.4. Restricted Queries . . . . . . . . . . . . . . . . . . . . 175 | |||
| 9.5. Operations performed by Operators and Adminstrators . . . . 175 | 9.5. Operations performed by Operators and Administrators . . . 176 | |||
| 9.6. Queries on Jobs submitted using non-IPP protocols . . . . . 175 | 9.6. Queries on Jobs submitted using non-IPP protocols . . . . . 176 | |||
| 10. Changes Since RFC 2911 . . . . . . . . . . . . . . . . . . . 176 | 10. Changes Since RFC 2911 . . . . . . . . . . . . . . . . . . . 176 | |||
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 177 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 178 | |||
| 11.1. Normative References . . . . . . . . . . . . . . . . . . . 177 | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 178 | |||
| 11.2. Informative References . . . . . . . . . . . . . . . . . . 182 | 11.2. Informative References . . . . . . . . . . . . . . . . . . 183 | |||
| 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 | Appendix A. Formats for IPP Registration Proposals . . . . . . . 185 | |||
| Appendix A. Formats for IPP Registration Proposals . . . . . . . 183 | A.1. Attribute Registration . . . . . . . . . . . . . . . . . . 185 | |||
| A.1. Type2 keyword attribute values registration . . . . . . . . 184 | A.2. Type2 Keyword Attribute Value Registration . . . . . . . . 186 | |||
| A.2. Type2 enum attribute values registration . . . . . . . . . 184 | A.3. Type2 Enum Attribute Value Registration . . . . . . . . . . 187 | |||
| A.3. Attribute registration . . . . . . . . . . . . . . . . . . 185 | A.4. Operation Registration . . . . . . . . . . . . . . . . . . 187 | |||
| A.4. Attribute Syntax registration . . . . . . . . . . . . . . . 186 | A.5. Status code registration . . . . . . . . . . . . . . . . . 188 | |||
| A.5. Operation registration . . . . . . . . . . . . . . . . . . 186 | ||||
| A.6. Attribute Group registration . . . . . . . . . . . . . . . 187 | ||||
| A.7. Status code registration . . . . . . . . . . . . . . . . . 187 | ||||
| A.8. Out-of-band Attribute Value registration . . . . . . . . . 188 | ||||
| Appendix B. Status Codes and Suggested Status Code Messages . . 188 | Appendix B. Status Codes and Suggested Status Code Messages . . 188 | |||
| B.1. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 190 | B.1. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 189 | |||
| B.1.1. Informational . . . . . . . . . . . . . . . . . . . . . . 190 | B.1.1. Informational . . . . . . . . . . . . . . . . . . . . . . 189 | |||
| B.1.2. Successful Status Codes . . . . . . . . . . . . . . . . . 190 | B.1.2. Successful Status Codes . . . . . . . . . . . . . . . . . 190 | |||
| B.1.2.1. successful-ok (0x0000) . . . . . . . . . . . . . . . . 190 | B.1.2.1. successful-ok (0x0000) . . . . . . . . . . . . . . . . 190 | |||
| B.1.2.2. successful-ok-ignored-or-substituted-attributes | B.1.2.2. successful-ok-ignored-or-substituted-attributes | |||
| (0x0001) . . . . . . . . . . . . . . . . . . . . . . . 190 | (0x0001) . . . . . . . . . . . . . . . . . . . . . . . 190 | |||
| B.1.2.3. successful-ok-conflicting-attributes (0x0002) . . . . . 191 | B.1.2.3. successful-ok-conflicting-attributes (0x0002) . . . . . 190 | |||
| B.1.3. Redirection Status Codes . . . . . . . . . . . . . . . . 191 | B.1.3. Redirection Status Codes . . . . . . . . . . . . . . . . 190 | |||
| B.1.4. Client Error Status Codes . . . . . . . . . . . . . . . . 191 | B.1.4. Client Error Status Codes . . . . . . . . . . . . . . . . 191 | |||
| B.1.4.1. client-error-bad-request (0x0400) . . . . . . . . . . . 191 | B.1.4.1. client-error-bad-request (0x0400) . . . . . . . . . . . 191 | |||
| B.1.4.2. client-error-forbidden (0x0401) . . . . . . . . . . . . 191 | B.1.4.2. client-error-forbidden (0x0401) . . . . . . . . . . . . 191 | |||
| B.1.4.3. client-error-not-authenticated (0x0402) . . . . . . . . 191 | B.1.4.3. client-error-not-authenticated (0x0402) . . . . . . . . 191 | |||
| B.1.4.4. client-error-not-authorized (0x0403) . . . . . . . . . 192 | B.1.4.4. client-error-not-authorized (0x0403) . . . . . . . . . 191 | |||
| B.1.4.5. client-error-not-possible (0x0404) . . . . . . . . . . 192 | B.1.4.5. client-error-not-possible (0x0404) . . . . . . . . . . 192 | |||
| B.1.4.6. client-error-timeout (0x0405) . . . . . . . . . . . . . 192 | B.1.4.6. client-error-timeout (0x0405) . . . . . . . . . . . . . 192 | |||
| B.1.4.7. client-error-not-found (0x0406) . . . . . . . . . . . . 192 | B.1.4.7. client-error-not-found (0x0406) . . . . . . . . . . . . 192 | |||
| B.1.4.8. client-error-gone (0x0407) . . . . . . . . . . . . . . 193 | B.1.4.8. client-error-gone (0x0407) . . . . . . . . . . . . . . 192 | |||
| B.1.4.9. client-error-request-entity-too-large (0x0408) . . . . 193 | B.1.4.9. client-error-request-entity-too-large (0x0408) . . . . 193 | |||
| B.1.4.10. client-error-request-value-too-long (0x0409) . . . . . 193 | B.1.4.10. client-error-request-value-too-long (0x0409) . . . . . 193 | |||
| B.1.4.11. client-error-document-format-not-supported (0x040A) . . 194 | B.1.4.11. client-error-document-format-not-supported (0x040A) . . 193 | |||
| B.1.4.12. client-error-attributes-or-values-not-supported | B.1.4.12. client-error-attributes-or-values-not-supported | |||
| (0x040B) . . . . . . . . . . . . . . . . . . . . . . . 194 | (0x040B) . . . . . . . . . . . . . . . . . . . . . . . 194 | |||
| B.1.4.13. client-error-uri-scheme-not-supported (0x040C) . . . . 195 | B.1.4.13. client-error-uri-scheme-not-supported (0x040C) . . . . 194 | |||
| B.1.4.14. client-error-charset-not-supported (0x040D) . . . . . . 195 | B.1.4.14. client-error-charset-not-supported (0x040D) . . . . . . 194 | |||
| B.1.4.15. client-error-conflicting-attributes (0x040E) . . . . . 195 | B.1.4.15. client-error-conflicting-attributes (0x040E) . . . . . 195 | |||
| B.1.4.16. client-error-compression-not-supported (0x040F) . . . . 195 | B.1.4.16. client-error-compression-not-supported (0x040F) . . . . 195 | |||
| B.1.4.17. client-error-compression-error (0x0410) . . . . . . . . 195 | B.1.4.17. client-error-compression-error (0x0410) . . . . . . . . 195 | |||
| B.1.4.18. client-error-document-format-error (0x0411) . . . . . . 195 | B.1.4.18. client-error-document-format-error (0x0411) . . . . . . 195 | |||
| B.1.4.19. client-error-document-access-error (0x0412) . . . . . . 196 | B.1.4.19. client-error-document-access-error (0x0412) . . . . . . 195 | |||
| B.1.5. Server Error Status Codes . . . . . . . . . . . . . . . . 196 | B.1.5. Server Error Status Codes . . . . . . . . . . . . . . . . 196 | |||
| B.1.5.1. server-error-internal-error (0x0500) . . . . . . . . . 196 | B.1.5.1. server-error-internal-error (0x0500) . . . . . . . . . 196 | |||
| B.1.5.2. server-error-operation-not-supported (0x0501) . . . . . 196 | B.1.5.2. server-error-operation-not-supported (0x0501) . . . . . 196 | |||
| B.1.5.3. server-error-service-unavailable (0x0502) . . . . . . . 197 | B.1.5.3. server-error-service-unavailable (0x0502) . . . . . . . 196 | |||
| B.1.5.4. server-error-version-not-supported (0x0503) . . . . . . 197 | B.1.5.4. server-error-version-not-supported (0x0503) . . . . . . 197 | |||
| B.1.5.5. server-error-device-error (0x0504) . . . . . . . . . . 197 | B.1.5.5. server-error-device-error (0x0504) . . . . . . . . . . 197 | |||
| B.1.5.6. server-error-temporary-error (0x0505) . . . . . . . . . 198 | B.1.5.6. server-error-temporary-error (0x0505) . . . . . . . . . 197 | |||
| B.1.5.7. server-error-not-accepting-Jobs (0x0506) . . . . . . . 198 | B.1.5.7. server-error-not-accepting-Jobs (0x0506) . . . . . . . 198 | |||
| B.1.5.8. server-error-busy (0x0507) . . . . . . . . . . . . . . 198 | B.1.5.8. server-error-busy (0x0507) . . . . . . . . . . . . . . 198 | |||
| B.1.5.9. server-error-job-canceled (0x0508) . . . . . . . . . . 198 | B.1.5.9. server-error-job-canceled (0x0508) . . . . . . . . . . 198 | |||
| B.1.5.10. server-error-multiple-document-jobs-not-supported | B.1.5.10. server-error-multiple-document-jobs-not-supported | |||
| (0x0509) . . . . . . . . . . . . . . . . . . . . . . . 198 | (0x0509) . . . . . . . . . . . . . . . . . . . . . . . 198 | |||
| B.2. Status Codes for IPP Operations . . . . . . . . . . . . . . 199 | B.2. Status Codes for IPP Operations . . . . . . . . . . . . . . 198 | |||
| Appendix C. Processing IPP Attributes . . . . . . . . . . . . . 200 | Appendix C. Processing IPP Attributes . . . . . . . . . . . . . 200 | |||
| C.1. Fidelity . . . . . . . . . . . . . . . . . . . . . . . . . 201 | C.1. Fidelity . . . . . . . . . . . . . . . . . . . . . . . . . 201 | |||
| C.2. Page Description Language (PDL) Override . . . . . . . . . 202 | C.2. Page Description Language (PDL) Override . . . . . . . . . 202 | |||
| C.3. Using Job Template Attributes During Document Processing. . 204 | C.3. Using Job Template Attributes During Document Processing. . 204 | |||
| Appendix D. Generic Directory Schema . . . . . . . . . . . . . . 206 | Appendix D. Generic Directory Schema . . . . . . . . . . . . . . 205 | |||
| Appendix E. Change History . . . . . . . . . . . . . . . . . . . 208 | Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 208 | |||
| E.1. Changes In -09 . . . . . . . . . . . . . . . . . . . . . . 208 | Appendix F. Change History . . . . . . . . . . . . . . . . . . . 208 | |||
| E.2. Changes In -08 . . . . . . . . . . . . . . . . . . . . . . 209 | F.1. Changes In -11 . . . . . . . . . . . . . . . . . . . . . . 208 | |||
| E.3. Changes In -07 . . . . . . . . . . . . . . . . . . . . . . 209 | F.2. Changes In -10 . . . . . . . . . . . . . . . . . . . . . . 208 | |||
| E.4. Changes In -06 . . . . . . . . . . . . . . . . . . . . . . 210 | F.3. Changes In -09 . . . . . . . . . . . . . . . . . . . . . . 210 | |||
| E.5. Changes In -05 . . . . . . . . . . . . . . . . . . . . . . 213 | F.4. Changes In -08 . . . . . . . . . . . . . . . . . . . . . . 211 | |||
| E.6. Changes In -04 . . . . . . . . . . . . . . . . . . . . . . 215 | F.5. Changes In -07 . . . . . . . . . . . . . . . . . . . . . . 212 | |||
| E.7. Changes In -03 . . . . . . . . . . . . . . . . . . . . . . 215 | F.6. Changes In -06 . . . . . . . . . . . . . . . . . . . . . . 212 | |||
| E.8. Changes In -02 . . . . . . . . . . . . . . . . . . . . . . 216 | F.7. Changes In -05 . . . . . . . . . . . . . . . . . . . . . . 215 | |||
| E.9. Changes In -01 . . . . . . . . . . . . . . . . . . . . . . 216 | F.8. Changes In -04 . . . . . . . . . . . . . . . . . . . . . . 217 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 217 | F.9. Changes In -03 . . . . . . . . . . . . . . . . . . . . . . 218 | |||
| F.10. Changes In -02 . . . . . . . . . . . . . . . . . . . . . . 218 | ||||
| F.11. Changes In -01 . . . . . . . . . . . . . . . . . . . . . . 219 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 219 | ||||
| 1. Introduction | 1. Introduction | |||
| The Internet Printing Protocol (IPP) is an application level protocol | The Internet Printing Protocol (IPP) is an application level protocol | |||
| that can be used for distributed printing using Internet tools and | for distributed printing using Internet tools and technologies. IPP | |||
| technologies. IPP version 1.1 (IPP/1.1) focuses primarily on End | version 1.1 (IPP/1.1) focuses primarily on End User functionality | |||
| User functionality with a few administrative operations included. | with a few administrative operations included. IPP versions 2.0, | |||
| 2.1, and 2.2 provide many new operations and are defined separately. | ||||
| This document is just one of a suite of documents that fully define | This document is just one of a suite of documents that fully define | |||
| IPP. The full set of IETF IPP documents includes: | IPP. The full set of IETF 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 | Rationale for the Structure and Model and Protocol for the | |||
| Internet Printing Protocol [RFC2568] | Internet Printing Protocol [RFC2568] | |||
| Internet Printing Protocol/1.1: Model and Semantics (this | Internet Printing Protocol/1.1: Model and Semantics (this | |||
| document) | document) | |||
| skipping to change at page 9, line 45 ¶ | skipping to change at page 9, line 48 ¶ | |||
| Subscriptions [RFC3995] | Subscriptions [RFC3995] | |||
| Internet Printing Protocol/1.1: The 'ippget' Delivery Method for | Internet Printing Protocol/1.1: The 'ippget' Delivery Method for | |||
| Event Notifications [RFC3996] | Event Notifications [RFC3996] | |||
| Mapping between LPD and IPP Protocols [RFC2569] | Mapping between LPD and IPP Protocols [RFC2569] | |||
| Anyone reading these documents for the first time is strongly | Anyone reading these documents for the first time is strongly | |||
| encouraged to read the IPP documents in the above order. Additional | encouraged to read the IPP documents in the above order. Additional | |||
| IPP specifications have been published by the IEEE-ISTO Printer | IPP specifications have been published by the IEEE-ISTO Printer | |||
| Working Group's [1] IPP Workgroup [2]. The following standards are | Working Group's IPP Workgroup [PWG-IPP-WG]. The following standards | |||
| highly recommended reading: | are highly recommended reading: | |||
| PWG Media Standardized Names 2.0 (MSN2) [PWG5101.1] | PWG Media Standardized Names 2.0 (MSN2) [PWG5101.1] | |||
| IPP Finishings 2.0 [PWG5100.1] | IPP Finishings 2.0 [PWG5100.1] | |||
| IPP: "output-bin" attribute extension [PWG5100.2] | IPP: "output-bin" attribute extension [PWG5100.2] | |||
| IPP: Production Printing Attributes - Set 1 [PWG5100.3] (for | IPP: Production Printing Attributes - Set 1 [PWG5100.3] (for | |||
| "media-col" Job Template attribute) | "media-col" Job Template attribute) | |||
| IPP: Document Object [PWG5100.5] | IPP: Document Object [PWG5100.5] | |||
| IPP: Page Overrides [PWG5100.6] | IPP: Page Overrides [PWG5100.6] | |||
| IPP: Job Extensions [PWG5100.7] | IPP: Job Extensions [PWG5100.7] | |||
| IPP: "-actual" attributes [PWG5100.8] | IPP: "-actual" attributes [PWG5100.8] | |||
| skipping to change at page 11, line 29 ¶ | skipping to change at page 11, line 36 ¶ | |||
| protocol for the Internet, the Internet Printing Protocol (IPP) is | protocol for the Internet, the Internet Printing Protocol (IPP) is | |||
| based on a simplified printing model that abstracts the many | based on a simplified printing model that abstracts the many | |||
| components of real world printing solutions. The Internet is a | components of real world printing solutions. The Internet is a | |||
| distributed computing environment where requesters of print services | distributed computing environment where requesters of print services | |||
| (clients, applications, printer drivers, etc.) cooperate and interact | (clients, applications, printer drivers, etc.) cooperate and interact | |||
| with print service providers. This model and semantics document | with print service providers. This model and semantics document | |||
| describes a simple, abstract model for IPP even though the underlying | describes a simple, abstract model for IPP even though the underlying | |||
| configurations can be complex "n-tier" client/server systems. An | configurations can be complex "n-tier" client/server systems. An | |||
| important simplifying step in the IPP model is to expose only the key | important simplifying step in the IPP model is to expose only the key | |||
| objects and interfaces required for printing. The model described in | objects and interfaces required for printing. The model described in | |||
| this model document does not include features, interfaces, and | this document does not include features, interfaces, and | |||
| relationships that are beyond the scope of IPP/1.1. IPP/1.1 | relationships that are beyond the scope of IPP/1.1. IPP/1.1 | |||
| incorporates many of the relevant ideas and lessons learned from | incorporates many of the relevant ideas and lessons learned from | |||
| other specification and development efforts [HTPP] [ISO10175] [LDPA] | other specification and development efforts [HTPP] [ISO10175] [LDPA] | |||
| [P1387.4] [PSIS] [RFC1179] [SWP]. IPP is heavily influenced by the | [P1387.4] [PSIS] [RFC1179] [SWP]. IPP is heavily influenced by the | |||
| printing model introduced in the Document Printing Application (DPA) | printing model introduced in the Document Printing Application (DPA) | |||
| [ISO10175] standard. Although DPA specifies both End User and | [ISO10175] standard. Although DPA specifies both End User and | |||
| administrative features, IPP version 1.1 (IPP/1.1) focuses primarily | administrative features, IPP version 1.1 (IPP/1.1) focuses primarily | |||
| on End User functionality with a few additional OPTIONAL operations | on End User functionality with a few additional OPTIONAL operations | |||
| for Adminstrators and Operators. | for Administrators and Operators. | |||
| The IPP model encapsulates the important components of distributed | The IPP model encapsulates the important components of distributed | |||
| printing into the following object types: | printing into the following IPP object types: | |||
| o Printer (Section 3.1) | o Printer (Section 3.1) | |||
| o Job (Section 3.2) | o Job (Section 3.2) | |||
| o Document (See [PWG5100.5]) | o Document (See [PWG5100.5]) | |||
| o Subscription (See [RFC3995]) | o Subscription (See [RFC3995]) | |||
| Each object type has an associated set of operations (see Section 4) | Each object type has an associated set of operations (see Section 4) | |||
| and attributes (see Section 5). | and attributes (see Section 5). | |||
| It is important, however, to understand that in real system | It is important, however, to understand that in real system | |||
| implementations (which lie underneath the abstracted IPP model), | implementations (which lie underneath the abstracted IPP model), | |||
| there are other components of a print service which are not | there are other components of a print service which are not | |||
| skipping to change at page 12, line 41 ¶ | skipping to change at page 12, line 47 ¶ | |||
| I +--------+--------+ | | I +--------+--------+ | | |||
| O | | | O | | | |||
| N +-----------------+ | IPP Printer | N +-----------------+ | IPP Printer | |||
| | Print Service | | | | Print Service | | | |||
| +-----------------+ | | +-----------------+ | | |||
| | --+ | | --+ | |||
| +-----------------+ | +-----------------+ | |||
| | Output Device(s)| | | Output Device(s)| | |||
| +-----------------+ | +-----------------+ | |||
| Figure 1 - IPP Model | Figure 1: IPP Model | |||
| An IPP Printer object encapsulates the functions normally associated | An IPP Printer object ("Printer") encapsulates the functions normally | |||
| with physical Output Devices along with the spooling, scheduling and | associated with physical Output Devices along with the spooling, | |||
| multiple device management functions often associated with a print | scheduling and multiple device management functions often associated | |||
| server. Printers are optionally registered as entries in a directory | with a print server. Printers are optionally registered as entries | |||
| where End Users find and select them based on some sort of filtered | in a directory where End Users find and select them based on some | |||
| and context based searching mechanism (see Appendix D). The | sort of filtered context-based searching mechanism (see Appendix D). | |||
| directory is used to store relatively static information about the | The directory is used to store relatively static information about | |||
| Printer, allowing End Users to search for and find Printers that | the Printer, allowing End Users to search for and find Printers that | |||
| match their search criteria, for example: name, location, context, | match their search criteria, for example: name, location, context, | |||
| printer capabilities, etc. The more dynamic information, such as | printer capabilities, etc. The more dynamic information, such as | |||
| state, currently loaded and ready media, number of Jobs at the | state, currently loaded and ready media, number of Jobs at the | |||
| Printer, errors, warnings, and so forth, is directly associated with | Printer, errors, warnings, and so forth, is directly associated with | |||
| the Printer itself rather than with the entry in the directory which | the Printer itself rather than with the entry in the directory which | |||
| only references the Printer. | only references the Printer. | |||
| IPP Clients implement the IPP protocol on the Client side and give | IPP Clients ("Clients") implement the IPP protocol on the Client side | |||
| End Users (or programs running on behalf of End Users) the ability to | and give End Users (or programs running on behalf of End Users) the | |||
| query Printers and submit and manage print Jobs. An IPP server is | ability to query Printers and submit and manage print Jobs. An IPP | |||
| just that part of the Printer object that implements the server-side | server is just that part of the Printer object that implements the | |||
| protocol. The rest of the Printer object implements (or gateways | server-side protocol. The rest of the Printer object implements (or | |||
| into) the application semantics of the print service itself. | gateways into) the application semantics of the print service itself. | |||
| Printers can be embedded in an Output Device or can be implemented on | Printers can be embedded in an Output Device or can be implemented on | |||
| a host on the network that communicates with an Output Device. | a host on the network that communicates with an Output Device. | |||
| When a Job is submitted to the Printer and the Printer has validated | When a Job is submitted to the Printer and the Printer has validated | |||
| the attributes in the submission request, the Printer creates a new | the attributes in the submission request, the Printer creates a new | |||
| IPP Job object. The End User then interacts with this new Job to | IPP Job object ("Job"). The End User then interacts with this new | |||
| query its status and monitor the progress of the Job. An End User can | Job to query its status and monitor the progress of the Job. An End | |||
| also cancel their print Jobs by using the Job's Cancel-Job operation. | User can also cancel their print Jobs by using the Job's Cancel-Job | |||
| An End User can also hold, release, and restart their print Jobs | operation. An End User can also hold, release, and restart their | |||
| using the Job's OPTIONAL Hold-Job, Release-Job, and Restart-Job | print Jobs using the Job's OPTIONAL Hold-Job, Release-Job, and | |||
| operations, if implemented. | Restart-Job operations, if implemented. | |||
| A privileged Operator or Adminstrator of a Printer can cancel, hold, | A privileged Operator or Adminstrator of a Printer can cancel, hold, | |||
| release, and restart any user's Job using the REQUIRED Cancel-Job and | release, and restart any user's Job using the REQUIRED Cancel-Job and | |||
| the OPTIONAL Hold-Job, Release-Job, and Restart-Job operations. In | the OPTIONAL Hold-Job, Release-Job, and Restart-Job operations. In | |||
| addition, a privileged Operator or Adminstrator of a Printer can | addition, a privileged Operator or Adminstrator of a Printer can | |||
| pause, resume, or purge (Jobs from) a Printer using the OPTIONAL | pause, resume, or purge (Jobs from) a Printer using the OPTIONAL | |||
| Pause-Printer, Resume-Printer, and Purge-Jobs operations, if | Pause-Printer, Resume-Printer, and Purge-Jobs operations, if | |||
| implemented. | implemented. | |||
| The notification service is defined in IPP: Event Notifications and | The notification service is defined in IPP: Event Notifications and | |||
| skipping to change at page 15, line 8 ¶ | skipping to change at page 15, line 17 ¶ | |||
| 2.3.1. Administrator | 2.3.1. Administrator | |||
| An End User who is also authorized to manage all aspects of an Output | An End User who is also authorized to manage all aspects of an Output | |||
| Device or Printer, including creating the printer instances and | Device or Printer, including creating the printer instances and | |||
| controlling the authorization of other End Users and Operators | controlling the authorization of other End Users and Operators | |||
| [RFC2567]. | [RFC2567]. | |||
| 2.3.2. Attributes | 2.3.2. Attributes | |||
| An attribute is an item of information that is associated with an | An attribute is an item of information that is associated with an | |||
| instance of an IPP object. An attribute consists of an attribute | instance of an IPP object (Printer, Job, etc.) An attribute consists | |||
| name and one or more attribute values. Each attribute has a specific | of an attribute name and one or more attribute values. Each | |||
| attribute syntax. All object attributes are defined in Section 5 and | attribute has a specific attribute syntax. All object attributes are | |||
| all operation attributes are defined in Section 4. | defined in Section 5 and all operation attributes are defined in | |||
| Section 4. | ||||
| Job Template Attributes are described in Section 5.2. The Client | Job Template Attributes are described in Section 5.2. The Client | |||
| optionally supplies Job Template attributes in a Job Creation request | optionally supplies Job Template attributes in a Job Creation request | |||
| (operation requests that create Job objects). The Printer object has | (operation requests that create Job objects). The Printer object has | |||
| associated attributes which define supported and default values for | associated attributes which define supported and default values for | |||
| the Printer. | the Printer. | |||
| 2.3.2.1. Attribute Group Name | 2.3.2.1. Attribute Group Name | |||
| Related attributes are grouped into named groups. The name of the | Related attributes are grouped into named groups. The name of the | |||
| skipping to change at page 17, line 30 ¶ | skipping to change at page 17, line 38 ¶ | |||
| attribute. A Printer supports an attribute value if the value is one | attribute. A Printer supports an attribute value if the value is one | |||
| of the Printer's "supported values" attributes. The device behind a | of the Printer's "supported values" attributes. The device behind a | |||
| Printer can exhibit a behavior that corresponds to some IPP | Printer can exhibit a behavior that corresponds to some IPP | |||
| attribute, but if the Printer, when queried for that attribute, | attribute, but if the Printer, when queried for that attribute, | |||
| doesn't respond with the attribute, then as far as IPP is concerned, | doesn't respond with the attribute, then as far as IPP is concerned, | |||
| that implementation does not support that feature. If the Printer's | that implementation does not support that feature. If the Printer's | |||
| "xxx-supported" attribute is not populated with a particular value | "xxx-supported" attribute is not populated with a particular value | |||
| (even if that value is a legal value for that attribute), then that | (even if that value is a legal value for that attribute), then that | |||
| Printer does not support that particular value. | Printer does not support that particular value. | |||
| A conforming implementation MUST support all REQUIRED attributes. | A conforming implementation supports all REQUIRED attributes. | |||
| However, even for REQUIRED attributes, conformance to IPP does not | However, even for REQUIRED attributes, conformance to IPP does not | |||
| mandate that all implementations support all possible values | mandate that all implementations support all possible values | |||
| representing all possible Job processing behaviors and features. For | representing all possible Job processing behaviors and features. For | |||
| example, if a given instance of a Printer supports only certain | example, if a given instance of a Printer supports only certain | |||
| Document formats, then that Printer responds with the "document- | Document formats, then that Printer responds with the "document- | |||
| format-supported" attribute populated with a set of values, possibly | format-supported" attribute populated with a set of values, possibly | |||
| only one, taken from the entire set of possible values defined for | only one, taken from the entire set of possible values defined for | |||
| that attribute. This limited set of values represents the Printer's | that attribute. This limited set of values represents the Printer's | |||
| set of supported Document formats. Supporting an attribute and some | set of supported Document formats. Supporting an attribute and some | |||
| set of values for that attribute enables IPP End Users to be aware of | set of values for that attribute enables IPP End Users to be aware of | |||
| skipping to change at page 17, line 45 ¶ | skipping to change at page 18, line 4 ¶ | |||
| Document formats, then that Printer responds with the "document- | Document formats, then that Printer responds with the "document- | |||
| format-supported" attribute populated with a set of values, possibly | format-supported" attribute populated with a set of values, possibly | |||
| only one, taken from the entire set of possible values defined for | only one, taken from the entire set of possible values defined for | |||
| that attribute. This limited set of values represents the Printer's | that attribute. This limited set of values represents the Printer's | |||
| set of supported Document formats. Supporting an attribute and some | set of supported Document formats. Supporting an attribute and some | |||
| set of values for that attribute enables IPP End Users to be aware of | set of values for that attribute enables IPP End Users to be aware of | |||
| and make use of those features associated with that attribute and | and make use of those features associated with that attribute and | |||
| those values. If an implementation chooses to not support an | those values. If an implementation chooses to not support an | |||
| attribute or some specific value, then IPP End Users would have no | attribute or some specific value, then IPP End Users would have no | |||
| ability to make use of that feature within the context of IPP itself. | ability to make use of that feature within the context of IPP itself. | |||
| However, due to existing practice and legacy systems which are not | However, due to existing practice and legacy systems which are not | |||
| IPP aware, there might be some other mechanism outside the scope of | IPP aware, there might be some other mechanism outside the scope of | |||
| IPP to control or request the "unsupported" feature (such as embedded | IPP to control or request the "unsupported" feature (such as embedded | |||
| instructions within the Document data itself). | instructions within the Document data itself). | |||
| For example, consider the "finishings-supported" attribute. | For example, consider the "finishings-supported" attribute. | |||
| 1) If a Printer is not physically capable of stapling, the | 1) If a Printer is not physically capable of stapling, the | |||
| "finishings-supported" attribute MUST NOT be populated with the value | "finishings-supported" attribute MUST NOT be populated with the value | |||
| of 'staple'. | of 'staple'. | |||
| 2) A Printer is physically capable of stapling, however an | 2) A Printer is physically capable of stapling, however an | |||
| implementation chooses not to support stapling in the IPP | implementation chooses not to support stapling in the IPP | |||
| "finishings" attribute. In this case, 'staple' MUST NOT be a value | "finishings" attribute. In this case, 'staple' MUST NOT be a value | |||
| in the "finishings-supported" Printer object attribute. Without | in the "finishings-supported" Printer Description attribute. Without | |||
| support for the value 'staple', an IPP End User would have no means | support for the value 'staple', an IPP End User would have no means | |||
| within the protocol itself to request that a Job be stapled. | within the protocol itself to request that a Job be stapled. | |||
| However, an existing Document data formatter might be able to request | However, an existing Document data formatter might be able to request | |||
| that the Document be stapled directly with an embedded instruction | that the Document be stapled directly with an embedded instruction | |||
| within the Document data. In this case, the IPP implementation does | within the Document data. In this case, the IPP implementation does | |||
| not "support" stapling, however the End User is still able to have | not "support" stapling, however the End User is still able to have | |||
| some control over the stapling of the completed Job. | some control over the stapling of the completed Job. | |||
| 3) A Printer is physically capable of stapling, and an implementation | 3) A Printer is physically capable of stapling, and an implementation | |||
| chooses to support stapling in the IPP "finishings" attribute. In | chooses to support stapling in the IPP "finishings" attribute. In | |||
| skipping to change at page 19, line 42 ¶ | skipping to change at page 19, line 50 ¶ | |||
| 2.3.12. Terminating State | 2.3.12. Terminating State | |||
| The final state for a Job or other object is called its Terminating | The final state for a Job or other object is called its Terminating | |||
| State. For example, the 'aborted', 'canceled', and 'completed' Job | State. For example, the 'aborted', 'canceled', and 'completed' Job | |||
| states are Terminating States. | states are Terminating States. | |||
| 2.4. Abbreviations | 2.4. Abbreviations | |||
| ABNF: Augmented Backus-Naur Form [RFC5234] | ABNF: Augmented Backus-Naur Form [RFC5234] | |||
| ASCII: American Standard Code for Information Interchange [ASCII] | ASCII: American Standard Code for Information Interchange [RFC20] | |||
| HTTP: HyperText Transfer Protocol [RFC7230] | HTTP: HyperText Transfer Protocol [RFC7230] | |||
| HTTPS: HTTP over TLS [RFC2818] | HTTPS: HTTP over TLS [RFC2818] | |||
| IANA: Internet Assigned Numbers Authority | IANA: Internet Assigned Numbers Authority | |||
| IEEE: Institute of Electrical and Electronics Engineers | IEEE: Institute of Electrical and Electronics Engineers | |||
| IESG: Internet Engineering Steering Group | IESG: Internet Engineering Steering Group | |||
| IPP: Internet Printing Protocol (this document, [RFC2910bis], and | IPP: Internet Printing Protocol (this document, [RFC2910bis], and | |||
| [PWG5100.12]) | [PWG5100.12]) | |||
| ISTO: IEEE Industry Standards and Technology Organization | ISTO: IEEE Industry Standards and Technology Organization | |||
| LPD: Line Printer Daemon Protocol [RFC1179] | LPD: Line Printer Daemon Protocol [RFC1179] | |||
| PWG: IEEE-ISTO Printer Working Group [3] | PWG: IEEE-ISTO Printer Working Group | |||
| RFC: Request for Comments | RFC: Request for Comments | |||
| TCP: Transmission Control Protocol [RFC793] | TCP: Transmission Control Protocol [RFC793] | |||
| TLS: Transport Layer Security [RFC5246] | TLS: Transport Layer Security [RFC5246] | |||
| URI: Uniform Resource Identifier [RFC3986] | URI: Uniform Resource Identifier [RFC3986] | |||
| URL: Uniform Resource Locator [RFC3986] | URL: Uniform Resource Locator [RFC3986] | |||
| UTF-8: Unicode Transformation Format - 8-bit [RFC3629] | UTF-8: Unicode Transformation Format - 8-bit [RFC3629] | |||
| 3. IPP Objects | 3. IPP Objects | |||
| This document defines objects of type Printer and Job. Each type of | This document defines IPP objects of type Printer and Job. Each type | |||
| object models relevant aspects of a real-world entity such as a real | of object models relevant aspects of a real-world entity such as a | |||
| Printer or real print Job. Each object type is defined as a set of | real Printer or real print Job. Each object type is defined as a set | |||
| possible attributes that can be supported by instances of that object | of possible attributes that can be supported by instances of that | |||
| type. For each object (instance), the actual set of supported | object type. For each object (instance), the actual set of supported | |||
| attributes and values describe a specific implementation. The | attributes and values describe a specific implementation. The | |||
| object's attributes and values describe its state, capabilities, | object's attributes and values describe its state, capabilities, | |||
| realizable features, Job processing functions, and default behaviors | realizable features, Job processing functions, and default behaviors | |||
| and characteristics. For example, the Printer object type is defined | and characteristics. For example, the Printer object type is defined | |||
| as a set of attributes that each Printer object potentially supports. | as a set of attributes that each Printer object potentially supports. | |||
| In the same manner, the Job object type is defined as a set of | In the same manner, the Job object type is defined as a set of | |||
| attributes that are potentially supported by each Job object. | attributes that are potentially supported by each Job object. | |||
| Each attribute included in the set of attributes defining an object | Each attribute included in the set of attributes defining an object | |||
| type is labeled as: | type is labeled as: | |||
| skipping to change at page 21, line 42 ¶ | skipping to change at page 22, line 4 ¶ | |||
| Device and print service provider, a Printer object could be used to | Device and print service provider, a Printer object could be used to | |||
| represent any real or virtual device with semantics consistent with | represent any real or virtual device with semantics consistent with | |||
| the Printer object, such as a fax device, an imager, or even a CD | the Printer object, such as a fax device, an imager, or even a CD | |||
| writer. | writer. | |||
| Some examples of configurations supporting a Printer object include: | Some examples of configurations supporting a Printer object include: | |||
| 1. An Output Device with no spooling capabilities | 1. An Output Device with no spooling capabilities | |||
| 2. An Output Device with a built-in spooler | 2. An Output Device with a built-in spooler | |||
| 3. A print server supporting IPP with one or more associated Output | 3. A print server supporting IPP with one or more associated Output | |||
| Devices | Devices | |||
| 3a. The associated Output Devices are or are not capable of | 3a. The associated Output Devices are or are not capable of | |||
| spooling jobs | spooling jobs | |||
| 3b. The associated Output Devices possibly support IPP | 3b. The associated Output Devices possibly support IPP | |||
| The following figures show some examples of how Printers can be | Figure 2 shows some examples of how Printers can be realized on top | |||
| realized on top of various distributed printing configurations. The | of various distributed printing configurations. The embedded case | |||
| embedded case below represents configurations 1 and 2. The hosted | below represents configurations 1 and 2. The hosted and fan-out | |||
| and fan-out figures below represent configurations 3a and 3b. | figures below represent configurations 3a and 3b. | |||
| In this document the term "client" refers to a software entity that | In this document the term "client" refers to a software entity that | |||
| sends IPP operation requests to an IPP Printer and accepts IPP | sends IPP operation requests to an IPP Printer and accepts IPP | |||
| operation responses. A Client MAY be: | operation responses. A Client MAY be: | |||
| 1. contained within software controlled by an End User, e.g. | 1. contained within software controlled by an End User, e.g. | |||
| activated by the "Print" menu item in an application; or | activated by the "Print" menu item in an application; or | |||
| 2. the print server component that sends IPP requests to either an | 2. the print server component that sends IPP requests to either an | |||
| Output Device or another "downstream" print server. | Output Device or another "downstream" print server. | |||
| skipping to change at page 23, line 38 ¶ | skipping to change at page 23, line 38 ¶ | |||
| +-->| Output Device | | +-->| Output Device | | |||
| any/ | | | any/ | | | |||
| O +--------+ ########### / +---------------+ | O +--------+ ########### / +---------------+ | |||
| /|\ | Client |-IPP-># Printer #--* | /|\ | Client |-IPP-># Printer #--* | |||
| / \ +--------+ # Object # \ +---------------+ | / \ +--------+ # Object # \ +---------------+ | |||
| ########### any\ | | | ########### any\ | | | |||
| +-->| Output Device | | +-->| Output Device | | |||
| | | | | | | |||
| +---------------+ | +---------------+ | |||
| Figure 2 - IPP Printer Object Architecture | Figure 2: IPP Printer Object Architecture | |||
| 3.2. Job Object | 3.2. Job Object | |||
| A Job object is used to model a print Job. A Job object contains zero | A Job object is used to model a print Job. A Job object contains zero | |||
| or more Documents. The information required to create a Job object | or more Documents. The information required to create a Job object | |||
| is sent in a Job Creation request from the End User via an IPP Client | is sent in a Job Creation request from the End User via an IPP Client | |||
| to the Printer. The Printer validates the Job Creation request, and | to the Printer. The Printer validates the Job Creation request, and | |||
| if the Printer accepts the request, the Printer creates the new Job | if the Printer accepts the request, the Printer creates the new Job | |||
| object. Section 4 describes each of the Job operations in detail. | object. Section 4 describes each of the Job operations in detail. | |||
| skipping to change at page 25, line 9 ¶ | skipping to change at page 25, line 9 ¶ | |||
| contains one or more Documents. If the contained Document is a | contains one or more Documents. If the contained Document is a | |||
| stream of Document data, that stream can be contained in only one | stream of Document data, that stream can be contained in only one | |||
| Document. However, there can be identical copies of the stream in | Document. However, there can be identical copies of the stream in | |||
| other Documents in the same or different Jobs. If the contained | other Documents in the same or different Jobs. If the contained | |||
| Document is just a reference to a stream of Document data, other | Document is just a reference to a stream of Document data, other | |||
| Documents (in the same or different Job(s)) contain the same | Documents (in the same or different Job(s)) contain the same | |||
| reference. | reference. | |||
| 3.4. Object Identity | 3.4. Object Identity | |||
| All Printer and Job objects are identified by a Uniform Resource | All IPP objects (Printers, Jobs, etc.) are identified by a Uniform | |||
| Identifier (URI) [RFC3986] so that they can be persistently and | Resource Identifier (URI) [RFC3986] so that they can be persistently | |||
| unambiguously referenced. Since every URL is a specialized form of a | and unambiguously referenced. Since every URL is a specialized form | |||
| URI, even though the more generic term URI is used throughout the | of a URI, even though the more generic term URI is used throughout | |||
| rest of this document, its usage is intended to cover the more | the rest of this document, its usage is intended to cover the more | |||
| specific notion of URL as well. | specific notion of URL as well. | |||
| An Adminstrator configures Printers to either support or not support | An Adminstrator configures Printers to either support or not support | |||
| authentication and/or message privacy using Transport Layer Security | authentication and/or message privacy using Transport Layer Security | |||
| (TLS) [RFC5246]; the mechanism for security configuration is outside | (TLS) [RFC5246]; the mechanism for security configuration is outside | |||
| the scope of this IPP/1.1 document. In some situations, both types | the scope of this document. In some situations, both types of | |||
| of connections (both authenticated and unauthenticated) can be | connections (both authenticated and unauthenticated) can be | |||
| established using a single communication channel that has some sort | established using a single communication channel that has some sort | |||
| of negotiation mechanism. In other situations, multiple | of negotiation mechanism. In other situations, multiple | |||
| communication channels are used, one for each type of security | communication channels are used, one for each type of security | |||
| configuration. Section 9 provides a full description of all security | configuration. Section 9 provides a full description of all security | |||
| considerations and configurations. | considerations and configurations. | |||
| If a Printer supports more than one communication channel, some or | If a Printer supports more than one communication channel, some or | |||
| all of those channels might support and/or require different security | all of those channels might support and/or require different security | |||
| mechanisms. In such cases, an Adminstrator could expose the | mechanisms. In such cases, an Adminstrator could expose the | |||
| simultaneous support for these multiple communication channels as | simultaneous support for these multiple communication channels as | |||
| skipping to change at page 26, line 29 ¶ | skipping to change at page 26, line 29 ¶ | |||
| Job attribute. Both the numeric identifier and URI can then be used | Job attribute. Both the numeric identifier and URI can then be used | |||
| by Clients as the target for subsequent Job operations; the numeric | by Clients as the target for subsequent Job operations; the numeric | |||
| identifier is preferred. The Printer generates the Job numeric | identifier is preferred. The Printer generates the Job numeric | |||
| identifier and URI based on its configured security policy and the | identifier and URI based on its configured security policy and the | |||
| URI used by the Client in the Job Creation request. | URI used by the Client in the Job Creation request. | |||
| For example, consider a Printer that supports both a communication | For example, consider a Printer that supports both a communication | |||
| channel secured by the use of TLS (using HTTP over TLS with an | channel secured by the use of TLS (using HTTP over TLS with an | |||
| "https" schemed URI) and another open communication channel that is | "https" schemed URI) and another open communication channel that is | |||
| not secured with TLS (using a simple "http" schemed URI). If a | not secured with TLS (using a simple "http" schemed URI). If a | |||
| Client were to submit a Job using the secure URI, the Printer might | Client submits a Job using the secure URI, the Printer assigns the | |||
| assign the new Job a secure URI as well. If a Client were to submit | new Job a secure URI as well. If a Client were to submit a Job using | |||
| a Job using the open-channel URI, the Printer might assign the new | the open-channel URI, the Printer might assign the new Job an open- | |||
| Job an open-channel URI. Clients SHOULD use the "printer-uri" and | channel URI. Clients SHOULD use the "printer-uri" and "job-id" | |||
| "job-id" attributes to target a Job to avoid any ambiguity about the | attributes to target a Job to avoid any ambiguity about the | |||
| communication channel security. | communication channel security. | |||
| In addition, the Printer also populates the Job's "job-printer-uri" | In addition, the Printer also populates the Job's "job-printer-uri" | |||
| attribute. This is a reference back to the Printer that created the | attribute. This is a reference back to the Printer that created the | |||
| Job. If a Client only has access to a Job's "job-uri" identifier, the | Job. If a Client only has access to a Job's "job-uri" identifier, the | |||
| Client can query the Job's "job-printer-uri" attribute in order to | Client can query the Job's "job-printer-uri" attribute in order to | |||
| determine which Printer created the Job. If the Printer supports more | determine which Printer created the Job. If the Printer supports more | |||
| than one URI, the Printer picks the one URI supplied by the Client | than one URI, the Printer picks the one URI supplied by the Client | |||
| when creating the Job to build the value for and to populate the | when creating the Job to build the value for and to populate the | |||
| Job's "job-printer-uri" attribute. | Job's "job-printer-uri" attribute. | |||
| In addition to identifiers, Printer objects and Job objects have | In addition to identifiers, IPP objects have names - "printer-name" | |||
| names ("printer-name" and "job-name"). An object name is not | for Printers and "job-name" for Jobs. An object name is not | |||
| guaranteed to be unique across all instances of all objects. A | guaranteed to be unique across all instances of all objects. A | |||
| Printer's name is chosen and set by an Adminstrator through some | Printer's name is chosen and set by an Adminstrator through some | |||
| mechanism outside the scope of this IPP/1.1 document. A Job's name | mechanism outside the scope of this document. A Job's name can be | |||
| can be chosen and supplied by the IPP Client submitting the Job. If | chosen and supplied by the Client submitting the Job. If the Client | |||
| the Client does not supply a Job name, the Printer generates a name | does not supply a Job name, the Printer generates a name for the new | |||
| for the new Job. In all cases, the name only has local meaning. | Job. In all cases, the name only has local meaning. | |||
| To summarize: | To summarize: | |||
| o Each Printer is identified by one or more URIs. The Printer's | o Each Printer is identified by one or more URIs. The Printer's | |||
| "printer-uri-supported" attribute contains the URI(s). | "printer-uri-supported" attribute contains the URI(s). | |||
| o The Printer's "uri-security-supported" attribute identifies the | o The Printer's "uri-security-supported" attribute identifies the | |||
| communication channel security protocols that have been configured | communication channel security protocols that have been configured | |||
| for the various Printer URIs (e.g., 'tls' or 'none'). | for the various Printer URIs (e.g., 'tls' or 'none'). | |||
| skipping to change at page 27, line 46 ¶ | skipping to change at page 27, line 46 ¶ | |||
| outside the scope of this IPP/1.1 document. The Printer's | outside the scope of this IPP/1.1 document. The Printer's | |||
| "printer-name" attribute contains the name. | "printer-name" attribute contains the name. | |||
| o Each Job has a name which is not necessarily unique. The Client | o Each Job has a name which is not necessarily unique. The Client | |||
| optionally supplies this name in the Job Creation request. If the | optionally supplies this name in the Job Creation request. If the | |||
| Client does not supply this name, the Printer generates a name for | Client does not supply this name, the Printer generates a name for | |||
| the Job. The Job's "job-name" attribute contains the name. | the Job. The Job's "job-name" attribute contains the name. | |||
| 4. IPP Operations | 4. IPP Operations | |||
| IPP objects support operations. An operation consists of a request | IPP objects (Printers, Jobs, etc.) support operations. An operation | |||
| and a response. When a Client communicates with a Printer, the | consists of a request and a response. When a Client communicates | |||
| Client issues an operation request to the Printer URI and object's | with a Printer or its Jobs, the Client issues an operation request to | |||
| numeric identifier, if needed. Operation requests and responses have | the Printer URI and object's numeric identifier, if needed. | |||
| parameters that identify the operation. Operations also have | Operation requests and responses have parameters that identify the | |||
| attributes that affect the run-time characteristics of the operation | operation. Operations also have attributes that affect the run-time | |||
| (the intended target, localization information, etc.). These | characteristics of the operation (the intended target, localization | |||
| operation-specific attributes are called operation attributes (as | information, etc.). These operation-specific attributes are called | |||
| compared to object attributes such as Printer attributes or Job | operation attributes (as compared to object attributes such as | |||
| attributes). Each request carries along with it any operation | Printer attributes or Job attributes). Each request carries along | |||
| attributes, object attributes, and/or Document data required to | with it any operation attributes, object attributes, and/or Document | |||
| perform the operation. Each request requires a response from the | data required to perform the operation. Each request requires a | |||
| object. Each response indicates success or failure of the operation | response from the object. Each response indicates success or failure | |||
| with a status code as a response parameter. The response contains | of the operation with a status code as a response parameter. The | |||
| any operation attributes, object attributes, and/or status messages | response contains any operation attributes, object attributes, and/or | |||
| generated during the execution of the operation request. | status messages generated during the execution of the operation | |||
| request. | ||||
| This section describes the semantics of the IPP operations, both | This section describes the semantics of the IPP operations, both | |||
| requests and responses, in terms of the parameters, attributes, and | requests and responses, in terms of the parameters, attributes, and | |||
| other data associated with each operation. | other data associated with each operation. | |||
| The Printer operations defined in this document are: | The Printer operations defined in this document are: | |||
| Print-Job (Section 4.2.1) | Print-Job (Section 4.2.1) | |||
| Print-URI (Section 4.2.2) | Print-URI (Section 4.2.2) | |||
| skipping to change at page 30, line 10 ¶ | skipping to change at page 30, line 10 ¶ | |||
| value. Valid values are defined in the "operations-supported" | value. Valid values are defined in the "operations-supported" | |||
| Printer attribute section (see Section 5.4.15). The Client specifies | Printer attribute section (see Section 5.4.15). The Client specifies | |||
| which operation is being requested by supplying the correct | which operation is being requested by supplying the correct | |||
| "operation-id" value. | "operation-id" value. | |||
| In addition, every invocation of an operation is identified by a | In addition, every invocation of an operation is identified by a | |||
| "request-id" value. For each request, the Client chooses the | "request-id" value. For each request, the Client chooses the | |||
| "request-id" which MUST be an integer (possibly unique depending on | "request-id" which MUST be an integer (possibly unique depending on | |||
| Client requirements) in the range from 1 to 2**31 - 1 (inclusive). | Client requirements) in the range from 1 to 2**31 - 1 (inclusive). | |||
| This "request-id" allows Clients to manage multiple outstanding | This "request-id" allows Clients to manage multiple outstanding | |||
| requests. The receiving IPP object copies all 32-bits of the Client- | requests. The receiving IPP object (Printer, Job, etc.) copies all | |||
| supplied "request-id" attribute into the response so that the Client | 32-bits of the Client-supplied "request-id" attribute into the | |||
| can match the response with the correct outstanding request, even if | response so that the Client can match the response with the correct | |||
| the "request-id" is out of range. If the request is terminated | outstanding request, even if the "request-id" is out of range. If | |||
| before the complete "request-id" is received, the IPP object rejects | the request is terminated before the complete "request-id" is | |||
| the request and returns a response with a "request-id" of 0. | received, the IPP object rejects the request and returns a response | |||
| with a "request-id" of 0. | ||||
| Note: In some cases, the transport protocol underneath IPP might be a | Note: In some cases, the transport protocol underneath IPP might be a | |||
| connection oriented protocol that would make it impossible for a | connection oriented protocol that would make it impossible for a | |||
| Client to receive responses in any order other than the order in | Client to receive responses in any order other than the order in | |||
| which the corresponding requests were sent. In such cases, the | which the corresponding requests were sent. In such cases, the | |||
| "request-id" attribute would not be essential for correct protocol | "request-id" attribute would not be essential for correct protocol | |||
| operation. However, in other transport mappings the operation | operation. However, in other transport mappings the operation | |||
| responses could come back in any order so the "request-id" is | responses could come back in any order so the "request-id" is | |||
| essential. | essential. | |||
| skipping to change at page 31, line 7 ¶ | skipping to change at page 31, line 8 ¶ | |||
| receive all supported attributes. The Job object can later be | receive all supported attributes. The Job object can later be | |||
| queried to find out what Job Template attributes were originally | queried to find out what Job Template attributes were originally | |||
| requested in the Job Creation request, and such attributes are | requested in the Job Creation request, and such attributes are | |||
| returned in the response as Job Object Attributes. The Printer | returned in the response as Job Object Attributes. The Printer | |||
| object can be queried about its Job Template attributes to find | object can be queried about its Job Template attributes to find | |||
| out what type of Job processing capabilities are supported and/or | out what type of Job processing capabilities are supported and/or | |||
| what the default Job processing behaviors are, though such | what the default Job processing behaviors are, though such | |||
| attributes are returned in the response as Printer Object | attributes are returned in the response as Printer Object | |||
| Attributes. The "ipp-attribute-fidelity" operation attribute | Attributes. The "ipp-attribute-fidelity" operation attribute | |||
| affects processing of all Client-supplied Job Template attributes | affects processing of all Client-supplied Job Template attributes | |||
| - see Sections 4.2.1.2 and C for a full description of "ipp- | - see Section 4.2.1.2 and Appendix C for a full description of | |||
| attribute-fidelity" and its relationship to other attributes. | "ipp-attribute-fidelity" and its relationship to other attributes. | |||
| o Job Object Attributes: These attributes are returned in response | o Job Object Attributes: These attributes are returned in response | |||
| to a query operation directed at a Job object. | to a query operation directed at a Job object. | |||
| o Printer Object Attributes: These attributes are returned in | o Printer Object Attributes: These attributes are returned in | |||
| response to a query operation directed at a Printer object. | response to a query operation directed at a Printer object. | |||
| o Unsupported Attributes: In a Job Creation request, the Client | o Unsupported Attributes: In a Job Creation request, the Client | |||
| supplies a set of Operation and Job Template attributes. If any | supplies a set of Operation and Job Template attributes. If any | |||
| of these attributes or their values is unsupported by the Printer | of these attributes or their values is unsupported by the Printer | |||
| object, the Printer object SHOULD return the set of unsupported | object, the Printer object SHOULD return the set of unsupported | |||
| attributes in the response. Sections 4.1.7, 4.2.1.2, and C give a | attributes in the response. Sections 4.1.7 and 4.2.1.2, and | |||
| full description of how Job Template attributes supplied by the | Appendix C give a full description of how Job Template attributes | |||
| Client in a Job Creation request are processed by the Printer | supplied by the Client in a Job Creation request are processed by | |||
| object and how unsupported attributes are returned to the Client. | the Printer object and how unsupported attributes are returned to | |||
| Because of extensibility, any IPP object might receive a request | the Client. Because of extensibility, any IPP object might | |||
| that contains new or unknown attributes or values for which it has | receive a request that contains new or unknown attributes or | |||
| no support. In such cases, the IPP object processes what it can | values for which it has no support. In such cases, the IPP object | |||
| and returns the unsupported attributes in the response. The | processes what it can and returns the unsupported attributes in | |||
| Unsupported Attribute group is defined for all operation responses | the response. The Unsupported Attribute group is defined for all | |||
| for returning unsupported attributes that the Client supplied in | operation responses for returning unsupported attributes that the | |||
| the request. | Client supplied in the request. | |||
| Later in this section, each operation is formally defined by | Later in this section, each operation is formally defined by | |||
| identifying the allowed and expected groups of attributes for each | identifying the allowed and expected groups of attributes for each | |||
| request and response. The model identifies a specific order for each | request and response. The model identifies a specific order for each | |||
| group in each request or response, but the attributes within each | group in each request or response, but the attributes within each | |||
| group can be in any order, unless specified otherwise. | group can be in any order, unless specified otherwise. | |||
| The attributes within a group MUST be unique; if an attribute with | The attributes within a group MUST be unique; if an attribute with | |||
| the same name occurs more than once, the group is malformed. Clients | the same name occurs more than once, the group is malformed. Clients | |||
| MUST NOT submit such malformed requests and Printers MUST NOT return | MUST NOT submit such malformed requests and Printers MUST NOT return | |||
| skipping to change at page 33, line 28 ¶ | skipping to change at page 33, line 28 ¶ | |||
| and encoding method) used by any 'text' and 'name' attributes that | and encoding method) used by any 'text' and 'name' attributes that | |||
| the Client is supplying in this request. It also identifies the | the Client is supplying in this request. It also identifies the | |||
| charset that the Printer object MUST use (if supported) for all | charset that the Printer object MUST use (if supported) for all | |||
| 'text' and 'name' attributes and status messages that the Printer | 'text' and 'name' attributes and status messages that the Printer | |||
| object returns in the response to this request. See Sections 5.1.2 | object returns in the response to this request. See Sections 5.1.2 | |||
| and 5.1.3 for the definition of the 'text' and 'name' attribute | and 5.1.3 for the definition of the 'text' and 'name' attribute | |||
| syntaxes. | syntaxes. | |||
| All Clients and IPP objects MUST support the 'utf-8' charset | All Clients and IPP objects MUST support the 'utf-8' charset | |||
| [RFC3629] and MAY support additional charsets provided that they are | [RFC3629] and MAY support additional charsets provided that they are | |||
| registered with IANA [IANA-CS]. If the Printer object does not | registered with IANA [RFC2978] [IANA-CS]. If the Printer object does | |||
| support the Client supplied charset value, the Printer object MUST | not support the Client supplied charset value, the Printer object | |||
| reject the request, set the "attributes-charset" to 'utf-8' in the | MUST reject the request, set the "attributes-charset" to 'utf-8' in | |||
| response, and return the 'client-error-charset-not-supported' status | the response, and return the 'client-error-charset-not-supported' | |||
| code and any 'text' or 'name' attributes using the 'utf-8' charset. | status code and any 'text' or 'name' attributes using the 'utf-8' | |||
| The Printer MAY return any attributes in the Unsupported Attributes | charset. The Printer MAY return any attributes in the Unsupported | |||
| group (see Sections 4.1.7 and 4.2.1.2). The Printer object MUST | Attributes group (see Sections 4.1.7 and 4.2.1.2). The Printer | |||
| indicate the charset(s) supported as the values of the "charset- | object MUST indicate the charset(s) supported as the values of the | |||
| supported" Printer attribute (see Section 5.4.18), so that the Client | "charset-supported" Printer attribute (see Section 5.4.18), so that | |||
| can query to determine which charset(s) are supported. | the Client can query to determine which charset(s) are supported. | |||
| Note to Client implementers: Since IPP objects are only required to | Note to Client implementers: Since IPP objects are only required to | |||
| support the 'utf-8' charset, in order to maximize interoperability | support the 'utf-8' charset, in order to maximize interoperability | |||
| with multiple IPP object implementations, a Client SHOULD supply | with multiple IPP object implementations, a Client SHOULD supply | |||
| 'utf-8' in the "attributes-charset" operation attribute, even though | 'utf-8' in the "attributes-charset" operation attribute, even though | |||
| the Client is only passing and able to present a simpler charset, | the Client is only passing and able to present a simpler charset, | |||
| such as US-ASCII [ASCII] or ISO-8859-1 [ISO8859-1]. Then the Client | such as US-ASCII [RFC20] or ISO-8859-1 [ISO8859-1]. Then the Client | |||
| will have to filter out (or charset convert) those characters that | will have to filter out, charset convert, or replace those characters | |||
| are returned in the response that it cannot present to its user. On | that are returned in the response that it cannot present to its user. | |||
| the other hand, if both the Client and the IPP objects also support a | On the other hand, if both the Client and the IPP objects also | |||
| charset in common besides 'utf-8', the Client can use that charset in | support a charset in common besides 'utf-8', the Client can use that | |||
| order to avoid charset conversion or data loss. | charset in order to avoid charset conversion or data loss. | |||
| See the 'charset' attribute syntax description in Section 5.1.8 for | See the 'charset' attribute syntax description in Section 5.1.8 for | |||
| the syntax and semantic interpretation of the values of this | the syntax and semantic interpretation of the values of this | |||
| attribute and for example values. | attribute and for example values. | |||
| "attributes-natural-language" (naturalLanguage): | "attributes-natural-language" (naturalLanguage): | |||
| This operation attribute identifies the natural language used by any | This operation attribute identifies the natural language [RFC5646] | |||
| 'text' and 'name' attributes that the Client is supplying in this | used by any 'text' and 'name' attributes that the Client is supplying | |||
| request. This attribute also identifies the natural language that | in this request. This attribute also identifies the natural language | |||
| the Printer object SHOULD use for all 'text' and 'name' attributes | that the Printer object SHOULD use for all 'text' and 'name' | |||
| and status messages that the Printer object returns in the response | attributes and status messages that the Printer object returns in the | |||
| to this request. See the 'naturalLanguage' attribute syntax | response to this request. See the 'naturalLanguage' attribute syntax | |||
| description in Section 5.1.9 for the syntax and semantic | description in Section 5.1.9 for the syntax and semantic | |||
| interpretation of the values of this attribute and for example | interpretation of the values of this attribute and for example | |||
| values. | values. | |||
| There are no REQUIRED natural languages required for the Printer | There are no REQUIRED natural languages required for the Printer | |||
| object to support. However, the Printer's "generated-natural- | object to support. However, the Printer's "generated-natural- | |||
| language-supported" attribute identifies the natural languages | language-supported" attribute identifies the natural languages | |||
| supported by the Printer object and any contained Jobs for all text | supported by the Printer object and any contained Jobs for all text | |||
| strings generated by the IPP object. A Client MAY query this | strings generated by the IPP object. A Client MAY query this | |||
| attribute to determine which natural language(s) are supported for | attribute to determine which natural language(s) are supported for | |||
| skipping to change at page 36, line 9 ¶ | skipping to change at page 36, line 9 ¶ | |||
| natural-language" operation attribute of the response. The IPP | natural-language" operation attribute of the response. The IPP | |||
| object MAY use the Natural Language Override mechanism redundantly, | object MAY use the Natural Language Override mechanism redundantly, | |||
| i.e., use it even when the value is in the same natural language as | i.e., use it even when the value is in the same natural language as | |||
| the value supplied in the "attributes-natural-language" operation | the value supplied in the "attributes-natural-language" operation | |||
| attribute of the response. | attribute of the response. | |||
| An IPP object MUST NOT reject a request based on a supplied natural | An IPP object MUST NOT reject a request based on a supplied natural | |||
| language in an "attributes-natural-language" operation attribute or | language in an "attributes-natural-language" operation attribute or | |||
| in any attribute that uses the Natural Language Override. | in any attribute that uses the Natural Language Override. | |||
| Clients SHOULD NOT supply 'text' or 'name' attributes that use an | Note: Supplying 'text' or 'name' attributes with an incompatible | |||
| illegal combination of natural language and charset. For example, | combination of natural language and charset can cause undesired | |||
| suppose a Printer object supports charsets 'utf-8', 'iso-8859-1', and | behavior. For example, suppose a Printer supports charsets 'utf-8', | |||
| 'iso-8859-7'. Suppose also, that it supports natural languages 'en' | 'iso-8859-1', and 'iso-8859-7'. Suppose also, that it supports | |||
| (English), 'fr' (French), and 'el' (Greek). Although the Printer | natural languages 'en' (English), 'fr' (French), and 'el' (Greek). | |||
| object supports the charset 'iso-8859-1' and natural language 'el', | Although the Printer supports the charset 'iso-8859-1' and natural | |||
| it probably does not support the combination of Greek text strings | language 'el', it probably does not support the combination of Greek | |||
| using the 'iso-8859-1' charset. The Printer object handles this | text strings using the 'iso-8859-1' charset. The Printer handles | |||
| apparent incompatibility differently depending on the context in | this apparent incompatibility differently depending on the context in | |||
| which it occurs: | which it occurs: | |||
| o In a Job Creation request: If the Client supplies a text or name | o In a Job Creation request: If the Client supplies a text or name | |||
| attribute (for example, the "job-name" operation attribute) that | attribute (for example, the "job-name" operation attribute) that | |||
| uses an apparently incompatible combination, it is a Client choice | uses an apparently incompatible combination, it is a Client choice | |||
| that does not affect the Printer object or its correct operation. | that does not affect the Printer or its correct operation. | |||
| Therefore, the Printer object simply accepts the Client supplied | Therefore, the Printer simply accepts the Client supplied value, | |||
| value, stores it with the Job object, and responds back with the | stores it with the Job, and responds back with the same | |||
| same combination whenever the Client (or any client) queries for | combination whenever the Client (or any Client) queries for that | |||
| that attribute. | attribute. | |||
| o In a query-type operation, like Get-Printer-Attributes: If the | o In a query-type operation, like Get-Printer-Attributes: If the | |||
| Client requests an apparently incompatible combination, the | Client requests an apparently incompatible combination, the | |||
| Printer object responds (as described in Section 4.1.4.2) using | Printer responds (as described in Section 4.1.4.2) using the | |||
| the Printer's configured natural language rather than the natural | Printer's configured natural language rather than the natural | |||
| language requested by the Client. | language requested by the Client. | |||
| In either case, the Printer object does not reject the request | In either case, the Printer does not reject the request because of | |||
| because of the apparent incompatibility. The potential incompatible | the apparent incompatibility. The potential incompatible combination | |||
| combination of charset and natural language can occur either at the | of charset and natural language can occur either at the global | |||
| global operation level or at the Natural Language Override attribute- | operation level or at the Natural Language Override attribute-by- | |||
| by-attribute level. In addition, since the response always includes | attribute level. In addition, since the response always includes | |||
| explicit charset and natural language information, there is never any | explicit charset and natural language information, there is never any | |||
| question or ambiguity in how the Client interprets the response. | question or ambiguity in how the Client interprets the response. | |||
| 4.1.4.2. Response Operation Attributes | 4.1.4.2. Response Operation Attributes | |||
| The Printer object MUST supply and the Client MUST support the | The Printer MUST supply and the Client MUST support the following | |||
| following REQUIRED operation attributes in every IPP/1.1 operation | REQUIRED operation attributes in every IPP/1.1 operation response: | |||
| response: | ||||
| "attributes-charset" (charset): | "attributes-charset" (charset): | |||
| This operation attribute identifies the charset used by any 'text' | This operation attribute identifies the charset used by any 'text' | |||
| and 'name' attributes that the Printer object is returning in this | and 'name' attributes that the Printer object is returning in this | |||
| response. The value in this response MUST be the same value as the | response. The value in this response MUST be the same value as the | |||
| "attributes-charset" operation attribute supplied by the Client in | "attributes-charset" operation attribute supplied by the Client in | |||
| the request. If this is not possible (i.e., the charset requested is | the request. If this is not possible (i.e., the charset requested is | |||
| not supported), the request would have been rejected. See | not supported), the request would have been rejected. See | |||
| "attributes-charset" described in Section 4.1.4.1 above. | "attributes-charset" described in Section 4.1.4.1 above. | |||
| If the Printer object supports more than just the 'utf-8' charset, | If the Printer object supports more than just the 'utf-8' charset, | |||
| the Printer object MUST be able to code convert between each of the | the Printer object MUST be able to code convert between each of the | |||
| charsets supported on a highest fidelity possible basis in order to | charsets supported on a highest fidelity possible basis in order to | |||
| return the 'text' and 'name' attributes in the charset requested by | return the 'text' and 'name' attributes in the charset requested by | |||
| the Client. However, some information loss MAY occur during the | the Client. However, some information loss can occur during the | |||
| charset conversion depending on the charsets involved. For example, | charset conversion depending on the charsets involved. For example, | |||
| the Printer object Clients convert from a UTF-8 'a' to a US-ASCII 'a' | the Printer object Clients convert from a UTF-8 'a' to a US-ASCII 'a' | |||
| (with no loss of information), from an ISO Latin 1 CAPITAL LETTER A | (with no loss of information), from an ISO Latin 1 CAPITAL LETTER A | |||
| WITH ACUTE ACCENT to US-ASCII 'A' (losing the accent), or from a | WITH ACUTE ACCENT to US-ASCII 'A' (losing the accent), or from a | |||
| UTF-8 Japanese Kanji character to some ISO Latin 1 error character | UTF-8 Japanese Kanji character to some ISO Latin 1 error character | |||
| indication such as '?', decimal code equivalent, or to the absence of | indication such as '?', decimal code equivalent, or to the absence of | |||
| a character, depending on implementation. | a character, depending on implementation. | |||
| Whether an implementation that supports more than one charset stores | Whether an implementation that supports more than one charset stores | |||
| the data in the charset supplied by the Client or code converts to | the data in the charset supplied by the Client or code converts to | |||
| skipping to change at page 38, line 37 ¶ | skipping to change at page 38, line 31 ¶ | |||
| in the "job-uri (uri)" operation attribute. | in the "job-uri (uri)" operation attribute. | |||
| Clients SHOULD send the "printer-uri" and "job-id" operation | Clients SHOULD send the "printer-uri" and "job-id" operation | |||
| attributes in Job operations. | attributes in Job operations. | |||
| If the operation is directed at the Job object directly using the | If the operation is directed at the Job object directly using the | |||
| Job's URI, the Client MUST NOT include the redundant "job-id" | Job's URI, the Client MUST NOT include the redundant "job-id" | |||
| operation attribute. | operation attribute. | |||
| The operation target attributes are REQUIRED operation attributes | The operation target attributes are REQUIRED operation attributes | |||
| that MUST be included in every operation request. Like the charset | that are included in every operation request. Like the charset and | |||
| and natural language attributes (see Section 4.1.4), the operation | natural language attributes (see Section 4.1.4), the operation target | |||
| target attributes are specially ordered operation attributes. In all | attributes are specially ordered operation attributes. In all cases, | |||
| cases, the operation target attributes immediately follow the | the operation target attributes immediately follow the "attributes- | |||
| "attributes-charset" and "attributes-natural-language" attributes | charset" and "attributes-natural-language" attributes within the | |||
| within the operation attribute group, however the specific ordering | operation attribute group, however the specific ordering rules are: | |||
| rules are: | ||||
| o In the case where there is only one operation target attribute | o In the case where there is only one operation target attribute | |||
| (i.e., either only the "printer-uri" attribute or only the "job- | (i.e., either only the "printer-uri" attribute or only the "job- | |||
| uri" attribute), that attribute MUST be the third attribute in the | uri" attribute), that attribute MUST be the third attribute in the | |||
| operation attributes group. | operation attributes group. | |||
| o In the case where Job operations use two operation target | o In the case where Job operations use two operation target | |||
| attributes (i.e., the "printer-uri" and "job-id" attributes), the | attributes (i.e., the "printer-uri" and "job-id" attributes), the | |||
| "printer-uri" attribute MUST be the third attribute and the "job- | "printer-uri" attribute MUST be the third attribute and the "job- | |||
| id" attribute MUST be the fourth attribute. | id" attribute MUST be the fourth attribute. | |||
| skipping to change at page 39, line 37 ¶ | skipping to change at page 39, line 30 ¶ | |||
| that URI MUST be used by the Client to contact the IPP object. | that URI MUST be used by the Client to contact the IPP object. | |||
| Note: The Internet Printing Protocol/1.1: IPP URL Scheme [RFC3510] | Note: The Internet Printing Protocol/1.1: IPP URL Scheme [RFC3510] | |||
| and Internet Printing Protocol (IPP) over HTTPS Transport Binding and | and Internet Printing Protocol (IPP) over HTTPS Transport Binding and | |||
| the 'ipps' URI Scheme [RFC7472] documents define the mapping of IPP | the 'ipps' URI Scheme [RFC7472] documents define the mapping of IPP | |||
| onto HTTP and HTTPS, respectively, and define and register a default | onto HTTP and HTTPS, respectively, and define and register a default | |||
| port number. | port number. | |||
| 4.1.6. Operation Response Status Codes and Status Messages | 4.1.6. Operation Response Status Codes and Status Messages | |||
| Every operation response includes a REQUIRED "status-code" parameter | Every operation response includes a REQUIRED "status-code" parameter, | |||
| and MAY include the RECOMMENDED "status-message" and OPTIONAL | SHOULD include the "status-message" operation attribute, and MAY | |||
| "detailed-status-message" operation attributes. The Print-URI and | include the "detailed-status-message" operation attribute. The | |||
| Send-URI response MAY include an OPTIONAL "document-access-error" | Print-URI and Send-URI response MAY also include the "document- | |||
| operation attribute. | access-error" operation attribute. | |||
| 4.1.6.1. "status-code" (type2 enum) | 4.1.6.1. "status-code" (type2 enum) | |||
| The REQUIRED "status-code" parameter provides information on the | The REQUIRED "status-code" parameter provides information on the | |||
| processing of a request. | processing of a request. | |||
| The status code is intended for use by automata. A Client | The status code is intended for use by automata. A Client | |||
| implementation of IPP SHOULD convert status code values into any | implementation of IPP SHOULD convert status code values into any | |||
| localized message that has semantic meaning to the End User. | localized message that has semantic meaning to the End User. | |||
| skipping to change at page 41, line 4 ¶ | skipping to change at page 40, line 45 ¶ | |||
| unsupported attributes, the Printer returns the status code defined | unsupported attributes, the Printer returns the status code defined | |||
| in Section 4.1.7 on Unsupported Attributes. | in Section 4.1.7 on Unsupported Attributes. | |||
| 4.1.6.2. "status-message" (text(255)) | 4.1.6.2. "status-message" (text(255)) | |||
| The RECOMMENDED "status-message" operation attribute provides a short | The RECOMMENDED "status-message" operation attribute provides a short | |||
| textual description of the status of the operation. The "status- | textual description of the status of the operation. The "status- | |||
| message" attribute's syntax is "text(255)", so the maximum length is | message" attribute's syntax is "text(255)", so the maximum length is | |||
| 255 octets (see Section 5.1.2). The status message is intended for | 255 octets (see Section 5.1.2). The status message is intended for | |||
| the human End User. If a response does include a "status-message" | the human End User. If a response does include a "status-message" | |||
| attribute, an IPP Client SHOULD examine or display the messages in | attribute, an IPP Client can examine or display the messages in some | |||
| some implementation specific manner. The "status-message" is | implementation specific manner. The "status-message" is especially | |||
| especially useful for a later version of a Printer to return as | useful for a later version of a Printer to return as supplemental | |||
| supplemental information for the human user to accompany a status | information for the human user to accompany a status code that an | |||
| code that an earlier version of a Client might not understand. | earlier version of a Client might not understand. | |||
| If the Printer supports the "status-message" operation attribute, it | If the Printer supports the "status-message" operation attribute, it | |||
| MUST be able to generate this message in any of the natural languages | MUST be able to generate this message in any of the natural languages | |||
| identified by the Printer's "generated-natural-language-supported" | identified by the Printer's "generated-natural-language-supported" | |||
| attribute and MUST honor any supported value for the "attributes- | attribute and MUST honor any supported value for the "attributes- | |||
| natural-language" operation attribute (Section 4.1.4.1) of the Client | natural-language" operation attribute (Section 4.1.4.1) of the Client | |||
| request. Appendix B suggests the text for the status message | request. Appendix B suggests the text for the status message | |||
| returned by the Printer for use with the English natural language. | returned by the Printer for use with the English natural language. | |||
| As described in Section 4.1.4.1 for any returned 'text' attribute, if | As described in Section 4.1.4.1 for any returned 'text' attribute, if | |||
| skipping to change at page 41, line 38 ¶ | skipping to change at page 41, line 30 ¶ | |||
| bad-request', 'client-error-charset-not-supported', 'server-error- | bad-request', 'client-error-charset-not-supported', 'server-error- | |||
| internal-error', 'server-error-operation-not-supported', and 'server- | internal-error', 'server-error-operation-not-supported', and 'server- | |||
| error-version-not-supported'. In this case, it MUST set the value of | error-version-not-supported'. In this case, it MUST set the value of | |||
| the "attributes-charset" operation attribute to 'utf-8' in the error | the "attributes-charset" operation attribute to 'utf-8' in the error | |||
| response. | response. | |||
| 4.1.6.3. "detailed-status-message" (text(MAX)) | 4.1.6.3. "detailed-status-message" (text(MAX)) | |||
| The OPTIONAL "detailed-status-message" operation attribute provides | The OPTIONAL "detailed-status-message" operation attribute provides | |||
| additional more detailed technical and implementation-specific | additional more detailed technical and implementation-specific | |||
| information about the operation for Adminstrators or other | information about the operation for Administrators or other | |||
| experienced technical people. The "detailed-status-message" | experienced technical people. The "detailed-status-message" | |||
| attribute's syntax is "text(MAX)", so the maximum length is 1023 | attribute's syntax is "text(MAX)", so the maximum length is 1023 | |||
| octets (see Section 5.1.2). If the Printer supports the "detailed- | octets (see Section 5.1.2). If the Printer supports the "detailed- | |||
| status-message" operation attribute, the Printer SHOULD localize the | status-message" operation attribute, the Printer SHOULD localize the | |||
| message unless such localization would obscure the technical meaning | message unless such localization would obscure the technical meaning | |||
| of the message. Clients MUST NOT attempt to parse the value of this | of the message. Clients MUST NOT attempt to parse the value of this | |||
| attribute. See the "document-access-error" operation attribute | attribute. See the "document-access-error" operation attribute | |||
| (Section 4.1.6.4) for additional errors that a program can process. | (Section 4.1.6.4) for additional errors that a program can process. | |||
| 4.1.6.4. "document-access-error" (text(MAX)) | 4.1.6.4. "document-access-error" (text(MAX)) | |||
| This OPTIONAL operation attribute provides additional information | This OPTIONAL operation attribute provides additional information | |||
| about any Document access errors encountered by the Printer before it | about any Document access errors encountered by the Printer before it | |||
| returned a response to the Print-URI (Section 4.2.2) or Send-URI | returned a response to the Print-URI (Section 4.2.2) or Send-URI | |||
| (Section 4.3.1) operation. For errors in the protocol identified by | (Section 4.3.1) operation. For errors in the protocol identified by | |||
| the URI scheme in the "document-uri" operation attribute, such as | the URI scheme in the "document-uri" operation attribute, such as | |||
| 'http:' or 'ftp:', the error code is returned in parentheses, | 'http:' or 'ftp:', the error code is returned in parentheses, | |||
| followed by the URI. For example: | followed by the URI. For example: | |||
| (404) http://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11-990510.pdf | (404) http://www.example.com/filename.pdf | |||
| Most Internet protocols use decimal error codes (unlike IPP), so the | Most Internet protocols use decimal error codes (unlike IPP), so the | |||
| ASCII error code representation is in decimal. | ASCII error code representation is in decimal. | |||
| 4.1.7. Unsupported Attributes | 4.1.7. Unsupported Attributes | |||
| The Unsupported Attributes group contains attributes that are not | The Unsupported Attributes group contains attributes that are not | |||
| supported by the operation. This group is primarily for the Job | supported by the operation. This group is primarily for the Job | |||
| Creation operations, but all operations can return this group. | Creation operations, but all operations can return this group. | |||
| A Printer MUST include an Unsupported Attributes group in a response | A Printer MUST include an Unsupported Attributes group in a response | |||
| skipping to change at page 43, line 24 ¶ | skipping to change at page 43, line 12 ¶ | |||
| 3. The Printer does support the attributes and values supplied, but | 3. The Printer does support the attributes and values supplied, but | |||
| the particular values are in conflict with one another, because | the particular values are in conflict with one another, because | |||
| they violate a constraint, such as not being able to staple | they violate a constraint, such as not being able to staple | |||
| transparencies. | transparencies. | |||
| In the case of an unsupported attribute name, the Printer returns the | In the case of an unsupported attribute name, the Printer returns the | |||
| Client-supplied attribute with a substituted value of 'unsupported'. | Client-supplied attribute with a substituted value of 'unsupported'. | |||
| This value's syntax type is "out-of-band" and its encoding is defined | This value's syntax type is "out-of-band" and its encoding is defined | |||
| by special rules for "out-of-band" values in the "Encoding and | by special rules for "out-of-band" values in the "Encoding and | |||
| Transport" document [RFC2910bis]. Its value indicates no support for | Transport" document [RFC2910bis]. Its value indicates no support for | |||
| the attribute itself - see the beginning of Section 5.1. | the attribute itself - see the beginning of Section 5.1 in this | |||
| document. | ||||
| In the case of a supported attribute with one or more unsupported | In the case of a supported attribute with one or more unsupported | |||
| attribute syntaxes or values, the Printer simply returns the Client- | attribute syntaxes or values, the Printer simply returns the Client- | |||
| supplied attribute with the unsupported attribute syntaxes or values | supplied attribute with the unsupported attribute syntaxes or values | |||
| as supplied by the Client. This indicates support for the attribute, | as supplied by the Client. This indicates support for the attribute, | |||
| but no support for that particular attribute syntax or value. If the | but no support for that particular attribute syntax or value. If the | |||
| Client supplies a multi-valued attribute with more than one value and | Client supplies a multi-valued attribute with more than one value and | |||
| the Printer supports the attribute but only supports a subset of the | the Printer supports the attribute but only supports a subset of the | |||
| Client-supplied attribute syntaxes or values, the Printer MUST return | Client-supplied attribute syntaxes or values, the Printer MUST return | |||
| only those attribute syntaxes or values that are unsupported. | only those attribute syntaxes or values that are unsupported. | |||
| skipping to change at page 47, line 31 ¶ | skipping to change at page 47, line 20 ¶ | |||
| 1. Process the Client supplied attributes and either accept or | 1. Process the Client supplied attributes and either accept or | |||
| reject the request | reject the request | |||
| 2. Validate the syntax of and support for the scheme of any Client | 2. Validate the syntax of and support for the scheme of any Client | |||
| supplied URI | supplied URI | |||
| At Job submission time the Printer MUST validate whether the supplied | At Job submission time the Printer MUST validate whether the supplied | |||
| attributes, attribute syntaxes, and values are supported by matching | attributes, attribute syntaxes, and values are supported by matching | |||
| them with the Printer's corresponding "xxx-supported" attributes. | them with the Printer's corresponding "xxx-supported" attributes. | |||
| See Section 4.1.7 for details. [RFC3196] and [PWG5100.19] present | See Section 4.1.7 for details. See the Implementor's Guides | |||
| suggested steps for an IPP object to either accept or reject any | [RFC3196] [PWG5100.19] for guidance on processing Job Creation | |||
| request and additional steps for processing Job Creation requests. | requests. | |||
| At Job submission time the Printer MAY perform the validation checks | At Job submission time the Printer MAY perform the validation checks | |||
| reserved for Job processing time such as: | reserved for Job processing time such as: | |||
| 1. Validating the format of the Document data | 1. Validating the format of the Document data | |||
| 2. Validating the actual contents of any Client supplied URI | 2. Validating the actual contents of any Client supplied URI | |||
| (resolve the reference and follow the link to the Document data) | (resolve the reference and follow the link to the Document data) | |||
| At Job submission time, these additional Job processing time | At Job submission time, these additional Job processing time | |||
| skipping to change at page 54, line 35 ¶ | skipping to change at page 54, line 28 ¶ | |||
| In addition to the REQUIRED status code returned in every | In addition to the REQUIRED status code returned in every | |||
| response, the response MAY include a "status-message" | response, the response MAY include a "status-message" | |||
| (text(255)) and/or a "detailed-status-message" (text(MAX)) | (text(255)) and/or a "detailed-status-message" (text(MAX)) | |||
| operation attribute as described in Appendix B and | operation attribute as described in Appendix B and | |||
| Section 4.1.6. If the Client supplies unsupported or | Section 4.1.6. If the Client supplies unsupported or | |||
| conflicting Job Template attributes or values, the Printer MUST | conflicting Job Template attributes or values, the Printer MUST | |||
| reject or accept the Print-Job request depending on the whether | reject or accept the Print-Job request depending on the whether | |||
| the Client supplied a 'true' or 'false' value for the "ipp- | the Client supplied a 'true' or 'false' value for the "ipp- | |||
| attribute-fidelity" operation attribute. See the Implementor's | attribute-fidelity" operation attribute. See the Implementor's | |||
| Guides [RFC3196] [PWG5100.19] for a complete description of the | Guides [RFC3196] [PWG5100.19] for guidance on processing Job | |||
| suggested steps for processing a Job Creation request. | Creation requests. | |||
| Group 2: Unsupported Attributes | Group 2: Unsupported Attributes | |||
| See Section 4.1.7 for details on returning Unsupported Attributes. | See Section 4.1.7 for details on returning Unsupported Attributes. | |||
| The value of the "ipp-attribute-fidelity" supplied by the Client | The value of the "ipp-attribute-fidelity" supplied by the Client | |||
| does not affect what attributes the Printer returns in this group. | does not affect what attributes the Printer returns in this group. | |||
| The value of "ipp-attribute-fidelity" only affects whether the | The value of "ipp-attribute-fidelity" only affects whether the | |||
| Print-Job operation is accepted or rejected. If the Job is | Print-Job operation is accepted or rejected. If the Job is | |||
| accepted, the Client can query the Job using the Get-Job- | accepted, the Client can query the Job using the Get-Job- | |||
| skipping to change at page 56, line 38 ¶ | skipping to change at page 56, line 32 ¶ | |||
| reject the request and return the 'client-error-document-access- | reject the request and return the 'client-error-document-access- | |||
| error' status code. The Printer MAY also return a specific Document | error' status code. The Printer MAY also return a specific Document | |||
| access error code using the "document-access-error" operation | access error code using the "document-access-error" operation | |||
| attribute (see Section 4.1.6.4). | attribute (see Section 4.1.6.4). | |||
| If the Printer discovers this Document accessibility problem after | If the Printer discovers this Document accessibility problem after | |||
| accepting the request and returning an operation response with one of | accepting the request and returning an operation response with one of | |||
| the successful status codes, the Printer MUST add the 'document- | the successful status codes, the Printer MUST add the 'document- | |||
| access-error' value to the Job's "job-state-reasons" attribute and | access-error' value to the Job's "job-state-reasons" attribute and | |||
| MAY populate the Job's "job-document-access-errors" Job Status | MAY populate the Job's "job-document-access-errors" Job Status | |||
| attribute (see Section 5.3.11). See The Implementor's Guides | attribute (see Section 5.3.11). See the Implementor's Guides | |||
| [RFC3196] [PWG5100.19] for suggested additional checks. | [RFC3196] [PWG5100.19] for guidance on processing Job Creation | |||
| requests. | ||||
| If the Printer supports this operation, it MUST support the | If the Printer supports this operation, it MUST support the | |||
| "reference-uri-schemes-supported" Printer attribute (see | "reference-uri-schemes-supported" Printer attribute (see | |||
| Section 5.4.27). | Section 5.4.27). | |||
| It is up to the Printer to interpret the URI and subsequently "pull" | It is up to the Printer to interpret the URI and subsequently "pull" | |||
| the Document data from the source referenced by the URI string. | the Document data from the source referenced by the URI string. | |||
| 4.2.3. Validate-Job Operation | 4.2.3. Validate-Job Operation | |||
| skipping to change at page 88, line 35 ¶ | skipping to change at page 88, line 35 ¶ | |||
| defined as having an attribute syntax that is a set of keywords. | defined as having an attribute syntax that is a set of keywords. | |||
| 5.1. Attribute Syntaxes | 5.1. Attribute Syntaxes | |||
| This section defines the basic attribute syntax types that all | This section defines the basic attribute syntax types that all | |||
| Clients and IPP objects MUST be able to accept in responses and | Clients and IPP objects MUST be able to accept in responses and | |||
| accept in requests, respectively. Each attribute description in | accept in requests, respectively. Each attribute description in | |||
| Section 4 and Section 5 includes the name of attribute syntax(es) in | Section 4 and Section 5 includes the name of attribute syntax(es) in | |||
| the heading (in parentheses). A conforming implementation of an | the heading (in parentheses). A conforming implementation of an | |||
| attribute MUST include the semantics of the attribute syntax(es) so | attribute MUST include the semantics of the attribute syntax(es) so | |||
| identified. Section 7.3 describes how the protocol can be extended | identified. Section 7.7 describes how the protocol can be extended | |||
| with new attribute syntaxes. | with new attribute syntaxes. | |||
| The attribute syntaxes are specified in the following sub-sections, | The attribute syntaxes are specified in the following sub-sections, | |||
| where the sub-section heading is the keyword name of the attribute | where the sub-section heading is the keyword name of the attribute | |||
| syntax inside the single quotes. In operation requests and responses | syntax inside the single quotes. In operation requests and responses | |||
| each attribute value MUST be represented as one of the attribute | each attribute value MUST be represented as one of the attribute | |||
| syntaxes specified in the sub-section heading for the attribute. In | syntaxes specified in the sub-section heading for the attribute. In | |||
| addition, the value of an attribute in a response (but not in a | addition, the value of an attribute in a response (but not in a | |||
| request) MAY be one of the "out-of-band" values (Section 5.1.1) whose | request) MAY be one of the "out-of-band" values (Section 5.1.1) whose | |||
| special encoding rules are defined in the "Encoding and Transport" | special encoding rules are defined in the "Encoding and Transport" | |||
| skipping to change at page 93, line 43 ¶ | skipping to change at page 93, line 43 ¶ | |||
| match rules apply: | match rules apply: | |||
| 1. 'keyword' values never match 'name' values. | 1. 'keyword' values never match 'name' values. | |||
| 2. 'name' (nameWithoutLanguage and nameWithLanguage) values match if | 2. 'name' (nameWithoutLanguage and nameWithLanguage) values match if | |||
| (1) the name parts match and (2) the Associated Natural-Language | (1) the name parts match and (2) the Associated Natural-Language | |||
| parts (see Section 4.1.4.1) match. The matching rules are: | parts (see Section 4.1.4.1) match. The matching rules are: | |||
| 2a. the name parts match if the two names are identical | 2a. the name parts match if the two names are identical | |||
| character by character, except it is RECOMMENDED that case | character by character, except it is RECOMMENDED that case | |||
| be ignored. For example: 'Ajax-letter-head-white' MUST | be ignored as defined in i;unicode-casemap - Simple Unicode | |||
| match 'Ajax-letter-head-white' and SHOULD match 'ajax- | Collation Algorithm [RFC5051]. For example: 'Ajax-letter- | |||
| letter-head-white' and 'AJAX-LETTER-HEAD-WHITE'. | head-white' MUST match 'Ajax-letter-head-white' and SHOULD | |||
| match 'ajax-letter-head-white' and 'AJAX-LETTER-HEAD-WHITE'. | ||||
| 2b. the Associated Natural-Language parts match if the shorter | 2b. the Associated Natural-Language parts match if the shorter | |||
| of the two meets the syntactic requirements of RFC 1766 | of the two meets the syntactic requirements defined in | |||
| [RFC5646] and matches byte for byte with the longer. For | Section 2.1 of RFC 5646 [RFC5646] and matches (byte for byte | |||
| since IPP language tags are lowercase) with the longer. For | ||||
| example, 'en' matches 'en', 'en-us' and 'en-gb', but matches | example, 'en' matches 'en', 'en-us' and 'en-gb', but matches | |||
| neither 'fr' nor 'e'. | neither 'fr' nor 'e'. | |||
| 5.1.4. 'keyword' | 5.1.4. 'keyword' | |||
| The 'keyword' attribute syntax is a sequence of characters, length: 1 | The 'keyword' attribute syntax is a sequence of characters, length: 1 | |||
| to 255, containing only the US-ASCII [ASCII] encoded values for | to 255, containing only the US-ASCII [RFC20] encoded values for | |||
| lowercase letters ("a" - "z"), digits ("0" - "9"), hyphen ("-"), dot | lowercase letters ("a" - "z"), digits ("0" - "9"), hyphen ("-"), dot | |||
| ("."), and underscore ("_"). The first character MUST be a lowercase | ("."), and underscore ("_"). The first character MUST be a lowercase | |||
| letter. Furthermore, keywords MUST be in U.S. English. | letter. Furthermore, keywords MUST be in U.S. English. | |||
| This syntax type is used for enumerating semantic identifiers of | This syntax type is used for enumerating semantic identifiers of | |||
| entities in the abstract protocol, i.e., entities identified in this | entities in the abstract protocol, i.e., entities identified in this | |||
| document. Keywords are used as attribute names or values of | document. Keywords are used as attribute names or values of | |||
| attributes. Unlike 'text' and 'name' attribute values, 'keyword' | attributes. Unlike 'text' and 'name' attribute values, 'keyword' | |||
| values MUST NOT use the Natural Language Override mechanism, since | values MUST NOT use the Natural Language Override mechanism, since | |||
| they MUST always be US-ASCII and U.S. English. | they MUST always be US-ASCII and U.S. English. | |||
| skipping to change at page 94, line 41 ¶ | skipping to change at page 94, line 43 ¶ | |||
| The IANA IPP registry will always contain the complete and current | The IANA IPP registry will always contain the complete and current | |||
| list of keyword values for the attribute. | list of keyword values for the attribute. | |||
| When a keyword is used to represent an attribute (its name), it MUST | When a keyword is used to represent an attribute (its name), it MUST | |||
| be unique within the full scope of all IPP objects and attributes. | be unique within the full scope of all IPP objects and attributes. | |||
| When a keyword is used to represent a value of an attribute, it MUST | When a keyword is used to represent a value of an attribute, it MUST | |||
| be unique just within the scope of that attribute. That is, the same | be unique just within the scope of that attribute. That is, the same | |||
| keyword MUST NOT be used for two different values within the same | keyword MUST NOT be used for two different values within the same | |||
| attribute to mean two different semantic ideas. However, the same | attribute to mean two different semantic ideas. However, the same | |||
| keyword MAY be used across two or more attributes, representing | keyword MAY be used across two or more attributes, representing | |||
| different semantic ideas for each attribute. Section 7.1 describes | different semantic ideas for each attribute. Section 7.3 describes | |||
| how the protocol can be extended with new keyword values. Examples | how the protocol can be extended with new keyword values. Examples | |||
| of attribute name keywords: | of attribute name keywords: | |||
| "job-name" | "job-name" | |||
| "attributes-charset" | "attributes-charset" | |||
| Note: This document uses "type1" and "type2" prefixes to the | Note: This document uses "type1" and "type2" prefixes to the | |||
| "keyword" basic syntax to indicate different levels of review for | "keyword" basic syntax to indicate different levels of review for | |||
| extensions (see Section 7.1). | extensions (see Section 7.3). | |||
| 5.1.5. 'enum' | 5.1.5. 'enum' | |||
| The 'enum' attribute syntax is an enumerated integer value that is in | The 'enum' attribute syntax is an enumerated integer value that is in | |||
| the range from 1 to 2**31 - 1 (MAX). Each value has an associated | the range from 1 to 2**31 - 1 (MAX). Each value has an associated | |||
| 'keyword' name. In the definition for each attribute of this syntax | 'keyword' name. In the definition for each attribute of this syntax | |||
| type, the full set of possible values for that attribute are listed. | type, the full set of possible values for that attribute are listed. | |||
| This syntax type is used for attributes for which there are enum | This syntax type is used for attributes for which there are enum | |||
| values assigned by other standards, such as SNMP MIBs. A number of | values assigned by other standards, such as SNMP MIBs. A number of | |||
| attribute enum values in this document are also used for | attribute enum values in this document are also used for | |||
| corresponding attributes in other standards [RFC3805]. This syntax | corresponding attributes in other standards [RFC3805]. This syntax | |||
| type is not used for attributes to which the Adminstrator can assign | type is not used for attributes to which the Adminstrator can assign | |||
| values. Section 7.1 describes how the protocol can be extended with | values. Section 7.4 describes how the protocol can be extended with | |||
| new enum values. | new enum values. | |||
| Enum values are for use in the protocol. A user interface will | Enum values are for use in the protocol. A user interface will | |||
| provide a mapping between protocol enum values and displayable user- | provide a mapping between protocol enum values and displayable user- | |||
| friendly words and phrases which are localized to the natural | friendly words and phrases which are localized to the natural | |||
| language of the user. While the enum symbols specified in this | language of the user. While the enum symbols specified in this | |||
| document MAY be displayed to users whose natural language is U.S. | document MAY be displayed to users whose natural language is U.S. | |||
| English, they MAY be mapped to other U.S. English words for U.S. | English, they MAY be mapped to other U.S. English words for U.S. | |||
| English users, since the user interface is outside the scope of this | English users, since the user interface is outside the scope of this | |||
| document. | document. | |||
| Note: Some SNMP MIBs use '2' for 'unknown' which corresponds to the | Note: Some SNMP MIBs use '2' for 'unknown' which corresponds to the | |||
| IPP "out-of-band" value 'unknown'. See the description of the "out- | IPP "out-of-band" value 'unknown'. See the description of the "out- | |||
| of-band" values at the beginning of Section 5.1. Therefore, | of-band" values at the beginning of Section 5.1. Therefore, | |||
| attributes of type 'enum' typically start at '3'. | attributes of type 'enum' typically start at '3'. | |||
| Note: This document uses "type1" and "type2" prefixes to the "enum" | Note: This document uses "type1" and "type2" prefixes to the "enum" | |||
| basic syntax to indicate different levels of review for extensions | basic syntax to indicate different levels of review for extensions | |||
| (see Section 7.1). | (see Section 7.4). | |||
| 5.1.6. 'uri' | 5.1.6. 'uri' | |||
| The 'uri' attribute syntax is any valid Uniform Resource Identifier | The 'uri' attribute syntax is any valid Uniform Resource Identifier | |||
| or URI [RFC3986]. Most often, URIs are simply Uniform Resource | or URI [RFC3986]. Most often, URIs are simply Uniform Resource | |||
| Locators or URLs. The maximum length of URIs used as values of IPP | Locators or URLs. The maximum length of URIs used as values of IPP | |||
| attributes is 1023 octets. Although most other IPP attribute syntax | attributes is 1023 octets. Although most other IPP attribute syntax | |||
| types allow for only lowercased values, this attribute syntax type | types allow for only lowercased values, this attribute syntax type | |||
| conforms to the case-sensitive and case-insensitive rules specified | conforms to the case-sensitive and case-insensitive rules specified | |||
| in [RFC3986]. See also [RFC3196] and [PWG5100.19] for discussion of | in [RFC3986]. See also [RFC3196] and [PWG5100.19] for discussion of | |||
| skipping to change at page 96, line 10 ¶ | skipping to change at page 96, line 16 ¶ | |||
| The 'uriScheme' attribute syntax is a sequence of characters | The 'uriScheme' attribute syntax is a sequence of characters | |||
| representing a URI scheme according to RFC 3986 [RFC3986]. Though | representing a URI scheme according to RFC 3986 [RFC3986]. Though | |||
| RFC 3986 requires that the values be case-insensitive, IPP requires | RFC 3986 requires that the values be case-insensitive, IPP requires | |||
| all lowercase values in IPP attributes to simplify comparing by IPP | all lowercase values in IPP attributes to simplify comparing by IPP | |||
| Clients and Printers. | Clients and Printers. | |||
| Standard values for this syntax type include the following keywords: | Standard values for this syntax type include the following keywords: | |||
| o 'ipp': for IPP schemed URIs, e.g., "ipp://example.com/ipp/..." | o 'ipp': for IPP schemed URIs, e.g., "ipp://example.com/ipp/..." | |||
| [RFC3510] | ||||
| o 'ipps': for IPPS schemed URIs, e.g., "ipps://example.com/ipp/..." | o 'ipps': for IPPS schemed URIs, e.g., "ipps://example.com/ipp/..." | |||
| [RFC7472] | ||||
| o 'http': for HTTP schemed URIs, e.g., "http://example.com/path/to/ | o 'http': for HTTP schemed URIs, e.g., "http://example.com/path/to/ | |||
| filename" | filename" [RFC7230] | |||
| o 'https': for HTTPS schemed URIs, e.g., | o 'https': for HTTPS schemed URIs, e.g., | |||
| "https://example.com/path/to/filename" | "https://example.com/path/to/filename" [RFC7230] | |||
| o 'ftp': for FTP schemed URIs, e.g., "ftp://example.com/path/to/ | o 'ftp': for FTP schemed URIs, e.g., "ftp://example.com/path/to/ | |||
| filename" | filename" [RFC1738] | |||
| o 'mailto': for SMTP schemed URIs, e.g., "mailto:user@example.com" | o 'mailto': for SMTP schemed URIs, e.g., "mailto:user@example.com" | |||
| [RFC6068] | ||||
| o 'file': for file schemed URIs, e.g., "file:///path/to/filename" | o 'file': for file schemed URIs, e.g., "file:///path/to/filename" | |||
| [RFC1738] | ||||
| o 'urn': for Uniform Resource Name schemed URIs, e.g., | o 'urn': for Uniform Resource Name schemed URIs, e.g., | |||
| "urn:uuid:01234567-89ab-cdef-fedc-ba9876543210" | "urn:uuid:01234567-89ab-cdef-fedc-ba9876543210" [RFC4122] | |||
| A Printer MAY support any URI 'scheme' that has been registered with | A Printer MAY support any URI 'scheme' that has been registered with | |||
| IANA [IANA-MT]. The maximum length of URI 'scheme' values used to | IANA [IANA-MT]. The maximum length of URI 'scheme' values used to | |||
| represent IPP attribute values is 63 octets. | represent IPP attribute values is 63 octets. | |||
| 5.1.8. 'charset' | 5.1.8. 'charset' | |||
| The 'charset' attribute syntax is a standard identifier for a | The 'charset' attribute syntax is a standard identifier for a | |||
| charset. A charset is a coded character set and encoding scheme. | charset. A charset is a coded character set and encoding scheme. | |||
| Charsets are used for labeling certain document contents and 'text' | Charsets are used for labeling certain document contents and 'text' | |||
| and 'name' attribute values. The syntax and semantics of this | and 'name' attribute values. The syntax and semantics of this | |||
| attribute syntax are specified in RFC 2046 [RFC2046] and contained in | attribute syntax are specified in RFC 2046 [RFC2046] and contained in | |||
| the IANA character-set Registry [IANA-CS] according to the IANA | the IANA character-set Registry [IANA-CS] according to the IANA | |||
| procedures [RFC2978]. Though RFC 2046 requires that the values be | procedures [RFC2978]. Though RFC 2046 requires that the values be | |||
| case-insensitive US-ASCII [ASCII], IPP requires all lowercase values | case-insensitive US-ASCII [RFC20], IPP requires all lowercase values | |||
| in IPP attributes to simplify comparing by IPP Clients and Printers. | in IPP attributes to simplify comparing by IPP Clients and Printers. | |||
| When a character-set in the IANA registry has more than one name | When a character-set in the IANA registry has more than one name | |||
| (alias), the name labeled as "(preferred MIME name)", if present, | (alias), the name labeled as "(preferred MIME name)", if present, | |||
| MUST be used. | MUST be used. | |||
| The maximum length of 'charset' values used to represent IPP | The maximum length of 'charset' values used to represent IPP | |||
| attribute values is 63 octets. | attribute values is 63 octets. | |||
| Some examples are: | Some examples are: | |||
| o 'utf-8': ISO 10646 Universal Multiple-Octet Coded Character Set | o 'utf-8': ISO 10646 Universal Multiple-Octet Coded Character Set | |||
| (UCS) [ISO10646-1] represented as the UTF-8 [RFC3629] transfer | (UCS) [ISO10646-1] represented as the UTF-8 [RFC3629] transfer | |||
| encoding scheme in which US-ASCII [ASCII] is a subset charset. | encoding scheme in which US-ASCII [RFC20] is a subset charset. | |||
| o 'us-ascii': 7-bit American Standard Code for Information | o 'us-ascii': 7-bit American Standard Code for Information | |||
| Interchange (ASCII), ANSI X3.4-1986 [ASCII]. That standard | Interchange (ASCII), ANSI X3.4-1986 [RFC20]. That standard | |||
| defines US-ASCII, but RFC 2045 [RFC2045] eliminates most of the | defines US-ASCII, but RFC 2045 [RFC2045] eliminates most of the | |||
| control characters from conformant usage in MIME and IPP. | control characters from conformant usage in MIME and IPP. | |||
| o 'iso-8859-1': 8-bit One-Byte Coded Character Set, Latin Alphabet | o 'iso-8859-1': 8-bit One-Byte Coded Character Set, Latin Alphabet | |||
| Nr 1 [ISO8859-1]. That standard defines a coded character set | Nr 1 [ISO8859-1]. That standard defines a coded character set | |||
| that is used by Latin languages in the Western Hemisphere and | that is used by Latin languages in the Western Hemisphere and | |||
| Western Europe. US-ASCII is a subset charset. | Western Europe. US-ASCII is a subset charset. | |||
| Some attribute descriptions MAY place additional requirements on | Some attribute descriptions MAY place additional requirements on | |||
| charset values that can be used, such as REQUIRED values that MUST be | charset values that can be used, such as REQUIRED values that MUST be | |||
| skipping to change at page 117, line 36 ¶ | skipping to change at page 117, line 36 ¶ | |||
| depending on implementation. | depending on implementation. | |||
| There is also an additional Printer attribute named "media-ready" | There is also an additional Printer attribute named "media-ready" | |||
| which differs from "media-supported" in that legal values only | which differs from "media-supported" in that legal values only | |||
| include the subset of "media-supported" values that are physically | include the subset of "media-supported" values that are physically | |||
| loaded and ready for printing with no Operator intervention required. | loaded and ready for printing with no Operator intervention required. | |||
| The relationship of this attribute and the other attributes that | The relationship of this attribute and the other attributes that | |||
| control Document processing is described in Appendix C.3. | control Document processing is described in Appendix C.3. | |||
| Note: The "media-col" attribute [PWG5100.3] [PWG5100.13] is an | Note: If supported by the Printer, Clients MAY use the alternative | |||
| alternative to the "media" attribute that allows the Client to | "media-col" attribute [PWG5100.3] [PWG5100.13] to specify medium | |||
| specify medium requirements in greater detail. | requirements in greater detail. | |||
| 5.2.12. printer-resolution (resolution) | 5.2.12. printer-resolution (resolution) | |||
| This RECOMMENDED attribute identifies the output resolution that the | This RECOMMENDED attribute identifies the output resolution that the | |||
| Printer uses for the Job. | Printer uses for the Job. | |||
| Note: This attribute and the "print-quality" attribute | Note: This attribute and the "print-quality" attribute | |||
| (Section 5.2.13) are both used to specify the overall output quality | (Section 5.2.13) are both used to specify the overall output quality | |||
| of the Job. If a Client specifies conflicting "printer-resolution" | of the Job. If a Client specifies conflicting "printer-resolution" | |||
| and "print-quality" values, Printers SHOULD use the "print-quality" | and "print-quality" values, Printers SHOULD use the "print-quality" | |||
| skipping to change at page 122, line 23 ¶ | skipping to change at page 122, line 23 ¶ | |||
| implementation. | implementation. | |||
| Standard enum values are listed in Table 15. | Standard enum values are listed in Table 15. | |||
| The final value for this attribute MUST be one of: 'completed', | The final value for this attribute MUST be one of: 'completed', | |||
| 'canceled', or 'aborted' before the Printer removes the Job | 'canceled', or 'aborted' before the Printer removes the Job | |||
| altogether. The length of time that Jobs remain in the 'canceled', | altogether. The length of time that Jobs remain in the 'canceled', | |||
| 'aborted', and 'completed' states depends on implementation. See | 'aborted', and 'completed' states depends on implementation. See | |||
| Section 5.3.7.2. | Section 5.3.7.2. | |||
| Figure 1 shows the normal Job state transitions. Normally a Job | Figure 3 shows the normal Job state transitions. Normally a Job | |||
| progresses from left to right. Other state transitions are unlikely, | progresses from left to right. Other state transitions are unlikely, | |||
| but are not forbidden. Not shown are the transitions to the | but are not forbidden. Not shown are the transitions to the | |||
| 'canceled' state from the 'pending', 'pending-held', and 'processing- | 'canceled' state from the 'pending', 'pending-held', and 'processing- | |||
| stopped' states. | stopped' states. | |||
| +----> canceled | +----> canceled | |||
| / | / | |||
| +----> pending -------> processing ---------+------> completed | +----> pending -------> processing ---------+------> completed | |||
| | ^ ^ \ | | ^ ^ \ | |||
| --->+ | | +----> aborted | --->+ | | +----> aborted | |||
| | v v / | | v v / | |||
| +----> pending-held processing-stopped ---+ | +----> pending-held processing-stopped ---+ | |||
| Figure 1: Figure 3 - IPP Job Life Cycle | Figure 3: IPP Job Life Cycle | |||
| Jobs reach one of the three terminal states: 'completed', 'canceled', | Jobs reach one of the three terminal states: 'completed', 'canceled', | |||
| or 'aborted', after the Jobs have completed all activity, including | or 'aborted', after the Jobs have completed all activity, including | |||
| stacking output media, after the Jobs have completed all activity, | stacking output media, after the Jobs have completed all activity, | |||
| and all Job status attributes have reached their final values for the | and all Job status attributes have reached their final values for the | |||
| Job. | Job. | |||
| +--------+----------------------------------------------------------+ | +--------+----------------------------------------------------------+ | |||
| | Values | Symbolic Name and Description | | | Values | Symbolic Name and Description | | |||
| +--------+----------------------------------------------------------+ | +--------+----------------------------------------------------------+ | |||
| skipping to change at page 131, line 30 ¶ | skipping to change at page 131, line 30 ¶ | |||
| This attribute provides additional information about each document | This attribute provides additional information about each document | |||
| access error for this Job encountered by the Printer after it | access error for this Job encountered by the Printer after it | |||
| returned a response to the Print-URI or Send-URI operation and | returned a response to the Print-URI or Send-URI operation and | |||
| subsequently attempted to access document(s) supplied in the Print- | subsequently attempted to access document(s) supplied in the Print- | |||
| URI or Send-URI operation. For errors in the protocol that is | URI or Send-URI operation. For errors in the protocol that is | |||
| identified by the URI scheme in the "document-uri" operation | identified by the URI scheme in the "document-uri" operation | |||
| attribute, such as 'http:' or 'ftp:', the error code is returned in | attribute, such as 'http:' or 'ftp:', the error code is returned in | |||
| parentheses, followed by the URI. For example: | parentheses, followed by the URI. For example: | |||
| (404) http://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11-990510.pdf | (404) http://www.example.com/filename.pdf | |||
| Most Internet protocols use decimal error codes (unlike IPP), so the | Most Internet protocols use decimal error codes (unlike IPP), so the | |||
| ASCII error code representation is in decimal. | ASCII error code representation is in decimal. | |||
| 5.3.12. number-of-documents (integer(0:MAX)) | 5.3.12. number-of-documents (integer(0:MAX)) | |||
| This attribute indicates the number of documents in the job, i.e., | This attribute indicates the number of documents in the job, i.e., | |||
| the number of Send-Document, Send-URI, Print-Job, or Print-URI | the number of Send-Document, Send-URI, Print-Job, or Print-URI | |||
| operations that the Printer has accepted for this job, regardless of | operations that the Printer has accepted for this job, regardless of | |||
| whether the Document data has reached the Printer. | whether the Document data has reached the Printer. | |||
| skipping to change at page 140, line 46 ¶ | skipping to change at page 140, line 46 ¶ | |||
| o 'digest': When a Client performs an operation whose target is the | o 'digest': When a Client performs an operation whose target is the | |||
| associated URI, the Printer challenges the Client with HTTP Digest | associated URI, the Printer challenges the Client with HTTP Digest | |||
| authentication [RFC7616]. The Printer assumes that the | authentication [RFC7616]. The Printer assumes that the | |||
| authenticated user is the name received via the Digest | authenticated user is the name received via the Digest | |||
| authentication mechanism. | authentication mechanism. | |||
| o 'certificate': When a Client performs an operation whose target is | o 'certificate': When a Client performs an operation whose target is | |||
| the associated URI, the Printer expects the Client to provide an | the associated URI, the Printer expects the Client to provide an | |||
| X.509 certificate. The Printer assumes that the authenticated | X.509 certificate. The Printer assumes that the authenticated | |||
| user is the textual name (Common Name) contained within the | user is one of the textual names (Common Name or Subject Alternate | |||
| certificate. | Names) contained within the certificate. | |||
| 5.4.3. uri-security-supported (1setOf type2 keyword) | 5.4.3. uri-security-supported (1setOf type2 keyword) | |||
| This REQUIRED Printer attribute MUST have the same cardinality | This REQUIRED Printer attribute MUST have the same cardinality | |||
| (contain the same number of values) as the "printer-uri-supported" | (contain the same number of values) as the "printer-uri-supported" | |||
| attribute. This attribute identifies the security mechanisms used | attribute. This attribute identifies the security mechanisms used | |||
| for each URI listed in the "printer-uri-supported" attribute. The "i | for each URI listed in the "printer-uri-supported" attribute. The "i | |||
| th" value in "uri-security-supported" corresponds to the "i th" value | th" value in "uri-security-supported" corresponds to the "i th" value | |||
| in "printer-uri-supported" and it describes the security mechanisms | in "printer-uri-supported" and it describes the security mechanisms | |||
| used for accessing the Printer via that URI. See [RFC2910bis] for | used for accessing the Printer via that URI. See [RFC2910bis] for | |||
| more details on security mechanisms. | more details on security mechanisms. | |||
| The following standard keyword values are defined: | The following standard keyword values are defined: | |||
| o 'none': There are no secure communication channel protocols in use | o 'none': There are no secure communication channel protocols in use | |||
| for the given URI. | for the given URI. | |||
| o 'tls': TLS [RFC5246] is the secure communications channel protocol | o 'tls': TLS [RFC5246] [RFC7525] is the secure communications | |||
| in use for the given URI. | channel protocol in use for the given URI. | |||
| This attribute is orthogonal to the definition of a Client | This attribute is orthogonal to the definition of a Client | |||
| Authentication mechanism. Specifically, 'none' does not exclude | Authentication mechanism. Specifically, 'none' does not exclude | |||
| Client Authentication. See Section 5.4.2. | Client Authentication. See Section 5.4.2. | |||
| Consider the following example. For a single Printer, an | Consider the following example. For a single Printer, an | |||
| Adminstrator configures the "printer-uri-supported", "uri- | Adminstrator configures the "printer-uri-supported", "uri- | |||
| authentication-supported" and "uri-security-supported" attributes as | authentication-supported" and "uri-security-supported" attributes as | |||
| follows: | follows: | |||
| skipping to change at page 150, line 47 ¶ | skipping to change at page 150, line 47 ¶ | |||
| +---------------+---------------------------------------------------+ | +---------------+---------------------------------------------------+ | |||
| | 0x000F | reserved for a future operation | | | 0x000F | reserved for a future operation | | |||
| +---------------+---------------------------------------------------+ | +---------------+---------------------------------------------------+ | |||
| | 0x0010 | Pause-Printer | | | 0x0010 | Pause-Printer | | |||
| +---------------+---------------------------------------------------+ | +---------------+---------------------------------------------------+ | |||
| | 0x0011 | Resume-Printer | | | 0x0011 | Resume-Printer | | |||
| +---------------+---------------------------------------------------+ | +---------------+---------------------------------------------------+ | |||
| | 0x0012 | Purge-Jobs | | | 0x0012 | Purge-Jobs | | |||
| +---------------+---------------------------------------------------+ | +---------------+---------------------------------------------------+ | |||
| | 0x0013-0x3FFF | reserved for future standards track operations | | | 0x0013-0x3FFF | reserved for future standards track operations | | |||
| | | (see Section 7.4) | | | | (see Section 7.8) | | |||
| +---------------+---------------------------------------------------+ | +---------------+---------------------------------------------------+ | |||
| | 0x4000-0x7FFF | reserved for vendor extensions (see Section 7.4) | | | 0x4000-0x7FFF | reserved for vendor extensions (see Section 7.8) | | |||
| +---------------+---------------------------------------------------+ | +---------------+---------------------------------------------------+ | |||
| Table 19: "operations-supported" and "operation-id" Enum Values | Table 19: "operations-supported" and "operation-id" Enum Values | |||
| 5.4.16. multiple-document-jobs-supported (boolean) | 5.4.16. multiple-document-jobs-supported (boolean) | |||
| This RECOMMENDED Printer attribute indicates whether the Printer | This RECOMMENDED Printer attribute indicates whether the Printer | |||
| supports more than one Document per Job, i.e., more than one Send- | supports more than one Document per Job, i.e., more than one Send- | |||
| Document operation with Document data and/or Send-URI operation. If | Document operation with Document data and/or Send-URI operation. If | |||
| the Printer supports the Create-Job and Send-Document operations (see | the Printer supports the Create-Job and Send-Document operations (see | |||
| skipping to change at page 158, line 17 ¶ | skipping to change at page 158, line 17 ¶ | |||
| This section describes the conformance requirements for a Client (see | This section describes the conformance requirements for a Client (see | |||
| Section 3.1), whether it be: | Section 3.1), whether it be: | |||
| 1. contained within software controlled by an End User, e.g. | 1. contained within software controlled by an End User, e.g. | |||
| activated by the "Print" menu item in an application that sends | activated by the "Print" menu item in an application that sends | |||
| IPP requests or | IPP requests or | |||
| 2. the print server component that sends IPP requests to either an | 2. the print server component that sends IPP requests to either an | |||
| Output Device or another "downstream" print server. | Output Device or another "downstream" print server. | |||
| A conforming Client MUST support all REQUIRED operations as defined | A conforming Client supports all REQUIRED operations as defined in | |||
| in this document. For each attribute included in an operation | this document. For each attribute included in an operation request, | |||
| request, a conforming Client MUST supply a value whose type and value | a conforming Client MUST supply a value whose type and value syntax | |||
| syntax conforms to the requirements of the Model document as | conforms to the requirements of the Model document as specified in | |||
| specified in Sections 4 and 5. A conforming Client MAY supply any | Sections 4 and 5. A conforming Client MAY supply any standards track | |||
| standards track extensions and/or vendor extensions in an operation | extensions and/or vendor extensions in an operation request, as long | |||
| request, as long as the extensions meet the requirements in | as the extensions meet the requirements in Section 7. | |||
| Section 7. | ||||
| While this document does not define conformance requirements for the | While this document does not define conformance requirements for the | |||
| user interfaces provided by IPP Clients or their applications, best | user interfaces provided by IPP Clients or their applications, best | |||
| practices for user interfaces are defined in [PWG5100.19]. | practices for user interfaces are defined in [PWG5100.19]. | |||
| A Client MUST be able to accept any of the attribute syntaxes defined | A Client MUST be able to accept any of the attribute syntaxes defined | |||
| in Section 5.1, including their full range, that can be returned to | in Section 5.1, including their full range, that can be returned to | |||
| it in a response from a Printer. In particular for each attribute | it in a response from a Printer. In particular for each attribute | |||
| that the Client supports whose attribute syntax is 'text', the Client | that the Client supports whose attribute syntax is 'text', the Client | |||
| MUST accept and process both the 'textWithoutLanguage' and | MUST accept and process both the 'textWithoutLanguage' and | |||
| skipping to change at page 163, line 27 ¶ | skipping to change at page 163, line 27 ¶ | |||
| uses the "attributes-natural-language" operation attribute or the | uses the "attributes-natural-language" operation attribute or the | |||
| Natural Language Override mechanism on any individual attribute | Natural Language Override mechanism on any individual attribute | |||
| whether or not the natural language is supported by the IPP object. | whether or not the natural language is supported by the IPP object. | |||
| If an IPP object supports a natural language, then it MUST be able to | If an IPP object supports a natural language, then it MUST be able to | |||
| translate (perhaps by table lookup) all generated 'text' or 'name' | translate (perhaps by table lookup) all generated 'text' or 'name' | |||
| attribute values into one of the supported languages (see | attribute values into one of the supported languages (see | |||
| Section 4.1.4). | Section 4.1.4). | |||
| 7. IANA Considerations | 7. IANA Considerations | |||
| This section describes the procedures for defining semantics for the | This section describes the procedures for defining standards track | |||
| following standards track extensions and vendor extensions to the | and vendor extensions to this document: | |||
| IPP/1.1 Model and Semantics document: | ||||
| 1. keyword attribute values | 1. Objects | |||
| 2. enum attribute values | 2. Attributes | |||
| 3. attributes | 3. Keyword Attribute Values | |||
| 4. attribute syntaxes | 4. Enum Attribute Values | |||
| 5. operations | 5. Attribute Group Tags | |||
| 6. attribute groups | 6. Out-of-Band Attribute Value Tags | |||
| 7. status codes | 7. Attribute syntaxes | |||
| 8. out-of-band attribute values | 8. Operations | |||
| Extensions registered for use with IPP/1.1 are OPTIONAL for Client | 9. Status Codes | |||
| and IPP object conformance to the IPP/1.1 "Model and Semantics" | ||||
| document (this document). | Extensions registered for use with IPP are OPTIONAL for Client and | |||
| IPP object conformance to the IPP/1.1 "Model and Semantics" document | ||||
| (this document). | ||||
| These extension procedures are aligned with the guidelines as set | These extension procedures are aligned with the guidelines as set | |||
| forth by the IESG [IANA-CON]. Appendix A describes how to propose | forth in Guidelines for Writing an IANA Considerations Section in | |||
| new registrations for consideration. IANA will reject registration | RFCs [RFC5226]. Appendix A describes how to propose new | |||
| registrations for consideration. IANA will reject registration | ||||
| proposals that leave out required information or do not follow the | proposals that leave out required information or do not follow the | |||
| appropriate format described in Appendix A. The IPP/1.1 Model and | appropriate format described in Appendix A. The IPP/1.1 Model and | |||
| Semantics document can also be extended by an appropriate standards | Semantics document can also be extended by an appropriate standards | |||
| track document that specifies any of the above extensions. | track document that specifies any of the above extensions. | |||
| 7.1. Typed 'keyword' and 'enum' Extensions | The IANA policy (using terms defined in [RFC5226]) for all extensions | |||
| is Specification Required, Expert Review, or First Come First Served | ||||
| as documented in the following subsections. Registrations submitted | ||||
| to IANA are forwarded to the IPP Designated Expert(s) who review the | ||||
| proposal on a mailing list that the Designated Expert(s) keep for | ||||
| this purpose. Initially, that list is the mailing list used by the | ||||
| PWG IPP WG: | ||||
| IPP allows for 'keyword' and 'enum' extensions (see Sections 5.1.3.3 | ipp@pwg.org | |||
| and 5.1.5). This document uses prefixes to the 'keyword' and 'enum' | ||||
| basic attribute syntax type in order to communicate extra information | ||||
| to the reader through its name. This extra information is not | ||||
| represented in the protocol because it is unimportant to a Client or | ||||
| Printer. The list below describes the prefixes and their meaning. | ||||
| "type1": This IPP specification document MUST be revised (or another | The IPP Designated Expert(s) are appointed by the IESG Area Director | |||
| standards track document which augments this document) to add a new | responsible for IPP, according to [RFC5226]. | |||
| keyword or a new enum. No vendor defined keywords or enums are | ||||
| allowed. | ||||
| "type2": Implementors can, at any time, add new keyword or enum | 7.1. Object Extensions | |||
| values by proposing the complete specification to IANA: | ||||
| iana@iana.org | The IANA policy (using terms defined in [RFC5226]) for object | |||
| extensions was formerly Expert Review; this document changes the | ||||
| policy to Specification Required. | ||||
| IANA will forward the registration proposal to the IPP Designated | 7.2. Attribute Extensibility | |||
| Expert(s) who will review the proposal with a mailing list that the | ||||
| Designated Expert(s) keep for this purpose. Initially, that list | ||||
| will be the mailing list used by the PWG IPP WG: | ||||
| ipp@pwg.org | Since attribute names are type2 keywords (see Section 5.1.4), the | |||
| IANA policy (using terms defined in [RFC5226]) for attribute | ||||
| extensions is Expert Review. | ||||
| The IPP Designated Expert(s) are appointed by the IESG Area Director | For vendor attribute extensions, implementers SHOULD use keywords | |||
| responsible for IPP, according to [IANA-CON]. | with a suitable distinguishing prefix such as 'smiNNN-' where NNN is | |||
| a SMI Private Enterprise Number (PEN) [IANA-PEN]. For example, if | ||||
| the company Example Corp. had obtained the SMI PEN 32473, then a | ||||
| vendor attribute 'foo' would be: 'smi32473-foo'. | ||||
| When a type2 keyword or enum is approved, the IPP Designated | Note: Prior versions of this document recommended using a fully | |||
| Expert(s) become the points of contact for any future maintenance | qualified domain name [RFC1035] as the prefix ('example.com-foo') | |||
| that might be required for that registration. | and many IPP implementations have also used reversed domain names | |||
| ('com.example-foo'). Domain names have proven problematic due to | ||||
| the length of some domain names, parallel use of country-specific | ||||
| domain names ('example.co.jp-foo'), and changes in ownership of | ||||
| domain names. | ||||
| For type2 keywords, the proposer includes the name of the keyword in | If a new Printer attribute is defined and its values can be affected | |||
| the registration proposal and the name is part of the technical | by a specific Document format, its specification needs to contain the | |||
| review. | following sentence: | |||
| After type2 enum specifications are approved, the IPP Designated | "The value of this attribute returned in a Get-Printer-Attributes | |||
| Expert(s), in consultation with IANA, assign the next available enum | response MAY depend on the "document-format" attribute supplied | |||
| number for each enum value. | (see Section 4.2.5.1) of the IPP/1.1 Model and Semantics." | |||
| This document defines keyword and enum values for all of the above | If the specification does not, then its value in the Get-Printer- | |||
| types. | Attributes response MUST NOT depend on the "document-format" supplied | |||
| in the request. | ||||
| When a new Job Template attribute is registered, the value of the | ||||
| Printer attributes MAY vary with "document-format" supplied in the | ||||
| request without the specification having to indicate so. | ||||
| 7.3. Keyword Extensibility | ||||
| The IANA policy (using terms defined in [RFC5226]) for type1 keyword | ||||
| extensions is Specification Required. The IANA policy for type2 | ||||
| keyword extensions is Expert Review. The IANA policy for vendor | ||||
| keyword extensions is First Come First Served. Only attributes using | ||||
| the type1 and type2 keyword syntax can be registered in the IANA IPP | ||||
| registry. | ||||
| Note: The type1 or type2 prefix on the basic attribute syntax is | ||||
| provided only to communicate the IANA policy required for | ||||
| registration and is not represented in IPP messages. Both type1 | ||||
| and type2 keyword values are represented using the same keyword | ||||
| value tag. | ||||
| For type1 and type2 keywords, the proposer includes the name of the | ||||
| keyword in the registration proposal and the name is part of the | ||||
| technical review. | ||||
| For vendor keyword extensions, implementers SHOULD either: | For vendor keyword extensions, implementers SHOULD either: | |||
| a. follow attribute-specific guidance such as defined in | a. follow attribute-specific guidance such as defined in | |||
| [PWG5101.1]; or | [PWG5101.1]; or | |||
| b. use keywords with a suitable distinguishing prefix, such as | b. use keywords with a suitable distinguishing prefix, such as | |||
| "xxx-" where xxx follows the syntax rules for keywords (see | 'smiNNN-' where NNN is a SMI Private Enterprise Number (PEN) | |||
| Section 5.1.4) and is the reversed (lowercase) fully qualified | [IANA-PEN]. | |||
| company name registered with IANA for use in domain names | ||||
| [RFC1035]. | ||||
| For example, if the company Example Corp. had obtained the domain | For example, if the company Example Corp. had obtained the SMI PEN | |||
| name "example.com", then a vendor keyword 'abc' would be: | 32473, then a vendor keyword 'foo' would be: 'smi32473-foo'. | |||
| 'com.example-abc'. | ||||
| Note: Prior versions of this document recommended using a fully | ||||
| qualified domain name [RFC1035] as the prefix ('example.com-foo') | ||||
| and many IPP implementations have also used reversed domain names | ||||
| ('com.example-foo'). Domain names have proven problematic due to | ||||
| the length of some domain names, parallel use of country-specific | ||||
| domain names ('example.co.jp-foo'), and changes in ownership of | ||||
| domain names. | ||||
| When a type2 keyword extension is approved, the IPP Designated | ||||
| Expert(s) become the points of contact for any future maintenance | ||||
| that might be required for that registration. | ||||
| 7.4. Enum Extensibility | ||||
| The IANA policy (using terms defined in [RFC5226]) for type1 enum | ||||
| extensions is Specification Required. The IANA policy for type2 enum | ||||
| extensions is Expert Review. The IANA policy for vendor enum | ||||
| extensions is First Come First Served. Only attributes using the | ||||
| type1 and type2 enum syntax can be registered in the IANA IPP | ||||
| registry. | ||||
| Note: The type1 or type2 prefix on the basic attribute syntax is | ||||
| provided only to communicate the IANA policy required for | ||||
| registration and is not represented in IPP messages. Both type1 | ||||
| and type2 enum values are represented using the same enum value | ||||
| tag. | ||||
| For vendor enum extensions, implementers MUST use values in the | For vendor enum extensions, implementers MUST use values in the | |||
| reserved integer range which is 0x4000000 to 0x7fffffff. | reserved integer range which is 0x4000000 to 0x7fffffff. | |||
| Implementors SHOULD consult with the IPP Designated Expert(s) to | ||||
| reserve vendor extension value(s) for their usage. | ||||
| 7.2. Attribute Extensibility | When a type1 or type2 enum extension is approved, the IPP Designated | |||
| Expert(s), in consultation with IANA, assign the next available enum | ||||
| number for each enum value. | ||||
| Attribute names (see Section 5.1.4) are type2 keywords. Therefore, | When a type2 enum extension is approved, the IPP Designated Expert(s) | |||
| new attributes can be registered and have the same status as | become the points of contact for any future maintenance that might be | |||
| attributes in this document by following the type2 extension rules. | required for that registration. | |||
| For vendor attribute extensions, implementers SHOULD use keywords | ||||
| with a suitable distinguishing prefix as described in Section 7.1. | ||||
| If a new Printer attribute is defined and its values can be affected | 7.5. Attribute Group Extensibility | |||
| by a specific Document format, its specification needs to contain the | ||||
| following sentence: | ||||
| "The value of this attribute returned in a Get-Printer-Attributes | The IANA policy (using terms defined in [RFC5226]) for attribute | |||
| response MAY depend on the "document-format" attribute supplied (see | group extensions was formerly Expert Review; this document changes | |||
| Section 4.2.5.1)." | the policy to Specification Required. | |||
| If the specification does not, then its value in the Get-Printer- | For attribute groups, the IPP Designated Expert(s), in consultation | |||
| Attributes response MUST NOT depend on the "document-format" supplied | with IANA, assign the next attribute group tag code in the | |||
| in the request. When a new Job Template attribute is registered, the | appropriate range as specified in [RFC2910bis]. | |||
| value of the Printer attributes MAY vary with "document-format" | ||||
| supplied in the request without the specification having to indicate | ||||
| so. | ||||
| 7.3. Attribute Syntax Extensibility | 7.6. Out-of-band Attribute Value Extensibility | |||
| Attribute syntaxes (see Section 5.1) are like type2 enums. | The IANA policy (using terms defined in [RFC5226]) for out-of-band | |||
| Therefore, new attribute syntaxes can be registered and have the same | attribute value extensions was formerly Expert Review; this document | |||
| status as attribute syntaxes in this document by following the type2 | changes the policy to Specification Required. | |||
| extension rules described in Section 7.1. The initial set of value | ||||
| codes that identify each of the attribute syntaxes have been assigned | ||||
| in the "Encoding and Transport" document [RFC2910bis], including a | ||||
| designated range for vendor extension. | ||||
| For attribute syntaxes, the IPP Designated Expert(s), in consultation | For out-of-band attribute value tags, the IPP Designated Expert(s), | |||
| with IANA, assign the next attribute syntax code in the appropriate | in consultation with IANA, assign the next out-of-band attribute | |||
| range as specified in [RFC2910bis]. | value tag code in the appropriate range as specified in [RFC2910bis]. | |||
| 7.4. Operation Extensibility | 7.7. Attribute Syntax Extensibility | |||
| Operations (see Section 4) can also be registered following the type2 | The IANA policy (using terms defined in [RFC5226]) for attribute | |||
| procedures described in Section 7.1, though major new operations will | syntax extensions was formerly Expert Review; this document changes | |||
| usually be done by a new standards track document that augments this | the policy to Specification Required. The IANA policy for vendor | |||
| document. For vendor operation extensions, implementers MUST use the | attribute syntax extensions (tags 0x40000000 to 0x7fffffff) is First | |||
| range for the "operation-id" in requests specified in Section 5.4.15 | Come First Served. Only attribute syntaxes in the range of | |||
| "operations-supported" Printer attribute. | 0x00000000 to 0x3fffffff can be registered in the IANA IPP registry. | |||
| For operations, the IPP Designated Expert(s), in consultation with | For vendor attribute syntax extensions, implementers MUST use values | |||
| IANA, assign the next "operation-id" code as specified in | in the reserved integer range which is 0x4000000 to 0x7fffffff. | |||
| Section 5.4.15. | Implementors SHOULD consult with the IPP Designated Expert(s) to | |||
| reserve vendor extension value(s) for their usage. | ||||
| 7.5. Attribute Group Extensibility | For registered attribute syntaxes, the IPP Designated Expert(s), in | |||
| consultation with IANA, assign the next attribute syntax tag in the | ||||
| appropriate range as specified in [RFC2910bis]. | ||||
| Attribute groups (see Section 4.1.3) passed in requests and responses | 7.8. Operation Extensibility | |||
| can be registered following the type2 procedures described in | ||||
| Section 7.1. The initial set of attribute group tags have been | ||||
| assigned in the "Encoding and Transport" document [RFC2910bis], | ||||
| including a designated range for vendor extension. | ||||
| For attribute groups, the IPP Designated Expert(s), in consultation | The IANA policy (using terms defined in [RFC5226]) for operation | |||
| with IANA, assign the next attribute group tag code in the | extensions is Expert Review. The IANA policy for vendor operation | |||
| appropriate range as specified in [RFC2910bis]. | extensions (values 0x40000000 to 0x7fffffff) is First Come First | |||
| Served. Only operation codes in the range of 0x00000000 to | ||||
| 0x3fffffff can be registered in the IANA IPP registry. | ||||
| 7.6. Status Code Extensibility | For vendor operation extensions, implementers MUST use values in the | |||
| reserved integer range which is 0x4000000 to 0x7fffffff. | ||||
| Implementors SHOULD consult with the IPP Designated Expert(s) to | ||||
| reserve vendor extension value(s) for their usage. | ||||
| Operation status codes (see Section 4.1.6.1) can also be registered | For registered operation extensions, the IPP Designated Expert(s), in | |||
| following the type2 procedures described in Section 7.1. The values | consultation with IANA, assign the next "operation-id" code as | |||
| for status codes are allocated in ranges as specified in Appendix B | specified in Section 5.4.15. | |||
| for each status code class: | ||||
| 7.9. Status Code Extensibility | ||||
| The IANA policy (using terms defined in [RFC5226]) for status code | ||||
| extensions is Expert Review. The IANA policy for vendor status code | ||||
| extensions (codes 0x0n80 to 0x0nff) is First Come First Served. Only | ||||
| status codes in the range of 0x0n00 to 0x0nff can be registered in | ||||
| the IANA IPP registry. | ||||
| The values for status codes are allocated in ranges as specified in | ||||
| Appendix B for each status code class: | ||||
| "informational" - Request received, continuing process | "informational" - Request received, continuing process | |||
| "successful" - The action was successfully received, understood, and | "successful" - The action was successfully received, understood, and | |||
| accepted | accepted | |||
| "redirection" - Further action is taken in order to complete the | "redirection" - Further action is taken in order to complete the | |||
| request | request | |||
| "client-error" - The request contains bad syntax or cannot be | "client-error" - The request contains bad syntax or cannot be | |||
| fulfilled | fulfilled | |||
| "server-error" - The IPP object failed to fulfill an apparently valid | "server-error" - The IPP object failed to fulfill an apparently valid | |||
| request | request | |||
| For vendor operation status code extensions, implementers MUST use | For vendor operation status code extensions, implementers MUST use | |||
| the top of each range as specified in Appendix B. | the top of each range (0x0n80 to 0x0nff) as specified in Appendix B. | |||
| Implementors SHOULD consult with the IPP Designated Expert(s) to | ||||
| reserve vendor extension value(s) for their usage. | ||||
| For operation status codes, the IPP Designated Expert(s), in | For registered operation status codes, the IPP Designated Expert(s), | |||
| consultation with IANA, assign the next status code in the | in consultation with IANA, assign the next status code in the | |||
| appropriate class range as specified in Appendix B. | appropriate class range as specified in Appendix B. | |||
| 7.7. Out-of-band Attribute Value Extensibility | ||||
| Out-of-band attribute values (see the beginning of Section 5.1) | ||||
| passed in requests and responses can be registered following the | ||||
| type2 procedures described in Section 7.1. The initial set of out- | ||||
| of-band attribute value tags have been assigned in the "Encoding and | ||||
| Transport" document [RFC2910bis]. | ||||
| For out-of-band attribute value tags, the IPP Designated Expert(s), | ||||
| in consultation with IANA, assign the next out-of-band attribute | ||||
| value tag code in the appropriate range as specified in [RFC2910bis]. | ||||
| 7.8. Registration of MIME types/sub-types for Document formats | ||||
| The "document-format" attribute's syntax is 'mimeMediaType'. This | ||||
| means that valid values are Internet Media Types (see | ||||
| Section 5.1.10). RFC 2045 [RFC2045] defines the syntax for valid | ||||
| Internet media types. IANA is the registry for all Internet media | ||||
| types. | ||||
| 7.9. Registration of charsets for use in 'charset' attribute values | ||||
| The "attributes-charset" attribute's syntax is 'charset'. This means | ||||
| that valid values are charsets names. When a charset in the IANA | ||||
| registry has more than one name (alias), the name labeled as | ||||
| "(preferred MIME name)", if present, MUST be used (see | ||||
| Section 5.1.8). IANA is the registry for charsets following the | ||||
| procedures of [RFC2978]. | ||||
| 8. Internationalization Considerations | 8. Internationalization Considerations | |||
| Some of the attributes have values that are text strings and names | Some of the attributes have values that are text strings and names | |||
| which are intended for human understanding rather than machine | which are intended for human understanding rather than machine | |||
| understanding (see the 'text' and 'name' attribute syntaxes in | understanding (see the 'text' and 'name' attribute syntaxes in | |||
| Sections 5.1.2 and 5.1.3). | Sections 5.1.2 and 5.1.3). | |||
| In each operation request, the Client | In each operation request, the Client | |||
| o identifies the charset and natural language of the request which | o identifies the charset and natural language of the request which | |||
| skipping to change at page 171, line 47 ¶ | skipping to change at page 172, line 34 ¶ | |||
| Table 22: 'name' and 'text' Attributes | Table 22: 'name' and 'text' Attributes | |||
| Note 1: Neither the Printer nor the Client localizes these message | Note 1: Neither the Printer nor the Client localizes these message | |||
| attributes, since they are intended for use by the Adminstrator or | attributes, since they are intended for use by the Adminstrator or | |||
| other experienced technical persons. | other experienced technical persons. | |||
| 9. Security Considerations | 9. Security Considerations | |||
| It is difficult to anticipate the security risks that might exist in | It is difficult to anticipate the security risks that might exist in | |||
| any given IPP environment. For example, if IPP is used within a | any given IPP environment. For example, if IPP is used within a | |||
| given small business over a private network, the risks of exposing | given small business over a private LAN with physical security, the | |||
| Document data can be low enough that the business will choose not to | risks of exposing Document data can be low enough that the business | |||
| use encryption on that data. However, if the connection between the | will choose not to use encryption on that data. However, if the | |||
| Client and the IPP object is over a public network, the Client can | connection between the Client and the IPP object is over a public | |||
| protect the content of the information during transmission through | network, the Client can protect the content of the information during | |||
| the network with encryption. | transmission through the network with encryption. | |||
| Furthermore, the value of the information being printed can vary from | Furthermore, the value of the information being printed can vary from | |||
| one IPP environment to the next. Printing payroll checks, for | one IPP environment to the next. Printing payroll checks, for | |||
| example, would have a different value than printing public | example, would have a different value than printing public | |||
| information from a file. There is also the possibly of denial-of- | information from a file. There is also the possibly of denial-of- | |||
| service attacks, but denial-of-service attacks against printing | service attacks, but denial-of-service attacks against printing | |||
| resources are not well understood and there is no published | resources are not well understood and there is no published | |||
| precedents regarding this scenario. | precedents regarding this scenario. | |||
| Once the authenticated identity of the requester has been supplied to | Once the authenticated identity of the requester has been supplied to | |||
| skipping to change at page 172, line 31 ¶ | skipping to change at page 173, line 17 ¶ | |||
| via some other type of administrative or access control framework. | via some other type of administrative or access control framework. | |||
| However, there are operation status codes that allow an IPP server to | However, there are operation status codes that allow an IPP server to | |||
| return information back to a Client about any potential access | return information back to a Client about any potential access | |||
| control violations for an IPP object. | control violations for an IPP object. | |||
| During a Job Creation request, the client's identity is recorded in | During a Job Creation request, the client's identity is recorded in | |||
| the Job object in an implementation-defined attribute. This | the Job object in an implementation-defined attribute. This | |||
| information can be used to verify a client's identity for subsequent | information can be used to verify a client's identity for subsequent | |||
| operations on that Job object in order to enforce any access control | operations on that Job object in order to enforce any access control | |||
| policy that might be in effect. See Section 9.3 below for more | policy that might be in effect. See Section 9.3 below for more | |||
| details. | details. This and other information stored in the Job object can | |||
| also be considered personal or sensitive in nature and can be | ||||
| filtered out as part of a configured privacy policy (Section 9.4). | ||||
| Since the security levels or the specific threats that an | Since the security levels or the specific threats that an | |||
| Adminstrator can be concerned with cannot be anticipated, IPP | Adminstrator can be concerned with cannot be anticipated, IPP | |||
| implementations MUST be capable of operating with different security | implementations MUST be capable of operating with different security | |||
| mechanisms and security policies as required by the individual | mechanisms and security policies as required by the individual | |||
| installation. Security policies might vary from very strong, to very | installation. Security policies might vary from very strong, to very | |||
| weak, to none at all, and corresponding security mechanisms will be | weak, to none at all, and corresponding security mechanisms will be | |||
| required. | required. | |||
| 9.1. Security Scenarios | 9.1. Security Scenarios | |||
| skipping to change at page 173, line 5 ¶ | skipping to change at page 173, line 41 ¶ | |||
| The following sections describe specific security attacks for IPP | The following sections describe specific security attacks for IPP | |||
| environments. Where examples are provided they are illustrative of | environments. Where examples are provided they are illustrative of | |||
| the environment and not an exhaustive set. | the environment and not an exhaustive set. | |||
| 9.1.1. Client and Server in the Same Security Domain | 9.1.1. Client and Server in the Same Security Domain | |||
| This environment is typical of internal networks where traditional | This environment is typical of internal networks where traditional | |||
| office workers print the output of personal productivity applications | office workers print the output of personal productivity applications | |||
| on shared workgroup printers, or where batch applications print their | on shared workgroup printers, or where batch applications print their | |||
| output on large production printers. Although the identity of the | output on large production printers. Although the identity of the | |||
| user can be trusted in this environment, a user might want to protect | user has been authenticated and can be trusted in this environment, a | |||
| the content of a document against such attacks as eavesdropping, | user might want to protect the content of a document against such | |||
| replaying or tampering. | attacks as eavesdropping, replaying or tampering by using a secure | |||
| transport such as TLS [RFC5246]. | ||||
| 9.1.2. Client and Server in Different Security Domains | 9.1.2. Client and Server in Different Security Domains | |||
| Examples of this environment include printing a document created by | Examples of this environment include printing a document created by | |||
| the Client on a publicly available printer, such as at a commercial | the Client on a publicly available printer, such as at a commercial | |||
| print shop; or printing a document remotely on a business associate's | print shop; or printing a document remotely on a business associate's | |||
| printer. This latter operation is functionally equivalent to sending | printer. This latter operation is functionally equivalent to sending | |||
| the document to the business associate as a facsimile. Printing | the document to the business associate as a facsimile. Printing | |||
| sensitive information on a Printer in a different security domain | sensitive information on a Printer in a different security domain | |||
| requires strong security measures. In this environment | requires strong security measures. In this environment | |||
| authentication of the Printer is required as well as protection | authentication of the Printer is required as well as protection | |||
| against unauthorized use of print resources. Since the document | against unauthorized use of print resources. Since the document | |||
| crosses security domains, protection against eavesdropping and | crosses security domains, protection against eavesdropping and | |||
| document tampering are also required. It will also be important in | document tampering are also required. It will also be important in | |||
| this environment to protect Printers against "spamming" and malicious | this environment to protect Printers against "spamming" and malicious | |||
| document content. | document content - authentication and document data pre-scanning can | |||
| be used to minimize those threats. | ||||
| 9.1.3. Print by Reference | 9.1.3. Print by Reference | |||
| When the document is not stored on the Client, printing can be done | When the document is not stored on the Client, printing can be done | |||
| by reference. That is, the print request can contain a reference, or | by reference. That is, the print request can contain a reference, or | |||
| pointer, to the document instead of the actual document itself - see | pointer, to the document instead of the actual document itself - see | |||
| Sections 4.2.2 and 4.3.2. Standard methods currently do not exist | Sections 4.2.2 and 4.3.2. Standard methods currently do not exist | |||
| for remote entities to "assume" the credentials of a Client for | for remote entities to "assume" the credentials of a Client for | |||
| forwarding requests to a 3rd party. It is anticipated that Print-By- | forwarding requests to a 3rd party. It is anticipated that Print-By- | |||
| Reference will be used to access "public" documents and that | Reference will be used to access "public" documents and that | |||
| sophisticated methods for authenticating "proxies" is not specified | sophisticated methods for authenticating "proxies" is not specified | |||
| in this document. | in this document. Because Printers typically process Jobs serially, | |||
| print by reference is not seen as a serious denial-of-service threat | ||||
| to the referenced servers. | ||||
| 9.2. URIs in Operation, Job, and Printer attributes | 9.2. URIs in Operation, Job, and Printer attributes | |||
| The "printer-uri-supported" attribute contains the Printer's URI(s). | The "printer-uri-supported" attribute contains the Printer's URI(s). | |||
| Its companion attribute, "uri-security-supported", identifies the | Its companion attribute, "uri-security-supported", identifies the | |||
| security mechanism used for each URI listed in the "printer-uri- | security mechanism used for each URI listed in the "printer-uri- | |||
| supported" attribute. For each Printer operation request, a Client | supported" attribute. For each Printer operation request, a Client | |||
| MUST supply only one URI in the "printer-uri" operation attribute. | MUST supply only one URI in the "printer-uri" operation attribute. | |||
| In other words, even though the Printer supports more than one URI, | In other words, even though the Printer supports more than one URI, | |||
| the Client only interacts with the Printer using one if its URIs. | the Client only interacts with the Printer using one if its URIs. | |||
| skipping to change at page 175, line 17 ¶ | skipping to change at page 176, line 5 ¶ | |||
| In many IPP operations, a Client supplies a list of attributes to be | In many IPP operations, a Client supplies a list of attributes to be | |||
| returned in the response. For security reasons, an IPP object can be | returned in the response. For security reasons, an IPP object can be | |||
| configured not to return all attributes (or all values) that a Client | configured not to return all attributes (or all values) that a Client | |||
| requests. The Job attributes returned MAY depend on whether the | requests. The Job attributes returned MAY depend on whether the | |||
| requesting user is the same as the user that submitted the Job. The | requesting user is the same as the user that submitted the Job. The | |||
| IPP object MAY even return none of the requested attributes. In such | IPP object MAY even return none of the requested attributes. In such | |||
| cases, the status returned is the same as if the object had returned | cases, the status returned is the same as if the object had returned | |||
| all requested attributes. The Client cannot tell by such a response | all requested attributes. The Client cannot tell by such a response | |||
| whether the requested attribute was present or absent on the object. | whether the requested attribute was present or absent on the object. | |||
| 9.5. Operations performed by Operators and Adminstrators | 9.5. Operations performed by Operators and Administrators | |||
| For the three Printer operations Pause-Printer, Resume-Printer, and | For the three Printer operations Pause-Printer, Resume-Printer, and | |||
| Purge-Jobs (see Sections 4.2.7, 4.2.8, and 4.2.9), the requesting | Purge-Jobs (see Sections 4.2.7, 4.2.8, and 4.2.9), the requesting | |||
| user is intended to be an Operator or Adminstrator of the Printer | user is intended to be an Operator or Adminstrator of the Printer | |||
| (see Section 1). Otherwise, the IPP Printer MUST reject the | (see Section 1). Otherwise, the IPP Printer MUST reject the | |||
| operation and return 'client-error-forbidden', 'client-error-not- | operation and return 'client-error-forbidden', 'client-error-not- | |||
| authenticated', or 'client-error-not-authorized' as appropriate. For | authenticated', or 'client-error-not-authorized' as appropriate. For | |||
| operations on Jobs, the requesting user is intended to be the Job | operations on Jobs, the requesting user is intended to be the Job | |||
| owner or can be an Operator or Adminstrator of the Printer. The | owner or can be an Operator or Adminstrator of the Printer. The | |||
| means for authorizing an Operator or Adminstrator of the Printer are | means for authorizing an Operator or Adminstrator of the Printer are | |||
| skipping to change at page 175, line 49 ¶ | skipping to change at page 176, line 37 ¶ | |||
| for IPP Jobs, but not for foreign Jobs. | for IPP Jobs, but not for foreign Jobs. | |||
| IPP Printers SHOULD also generate "job-id" and "job-uri" values for | IPP Printers SHOULD also generate "job-id" and "job-uri" values for | |||
| such "foreign jobs", if possible, so that they can be targets of | such "foreign jobs", if possible, so that they can be targets of | |||
| other IPP operations, such as Get-Job-Attributes and Cancel-Job. Such | other IPP operations, such as Get-Job-Attributes and Cancel-Job. Such | |||
| an implementation also needs to deal with the problem of | an implementation also needs to deal with the problem of | |||
| authentication of such foreign Jobs. One approach would be to treat | authentication of such foreign Jobs. One approach would be to treat | |||
| all such foreign Jobs as belonging to users other than the user of | 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 | the IPP Client. Another approach would be for the foreign Job to | |||
| belong to 'anonymous' - then only authenticated Operators or | belong to 'anonymous' - then only authenticated Operators or | |||
| Adminstrators of the IPP Printer could query the foreign Jobs by an | Administrators of the IPP Printer could query the foreign Jobs by an | |||
| IPP request. Alternatively, if the security policy is to allow users | IPP request. Alternatively, if the security policy is to allow users | |||
| to query other users' jobs, then the foreign Jobs would also be | 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- | visible to an End User IPP Client using Get-Jobs and Get-Job- | |||
| Attributes. | Attributes. | |||
| 10. Changes Since RFC 2911 | 10. Changes Since RFC 2911 | |||
| The following changes have been made since RFC 2911: | The following changes have been made since RFC 2911: | |||
| o Errata ID 364: Fixed range of "redirection" status codes (to | o Errata ID 364: Fixed range of "redirection" status codes (to | |||
| skipping to change at page 176, line 44 ¶ | skipping to change at page 177, line 32 ¶ | |||
| o Obsoleted all attributes and values defined in RFC 3381, as they | o Obsoleted all attributes and values defined in RFC 3381, as they | |||
| do not interact well with the "finishings" attribute and have | do not interact well with the "finishings" attribute and have | |||
| never been widely implemented. | never been widely implemented. | |||
| o Deprecated the Purge-Jobs and Restart-Job operations which destroy | o Deprecated the Purge-Jobs and Restart-Job operations which destroy | |||
| accounting information. | accounting information. | |||
| o Dropped type3 registration procedures. | o Dropped type3 registration procedures. | |||
| o Changed the vendor attribute and keyword naming recommendations to | ||||
| use SMI Private Enterprise Numbers ("smiNNN-foo") instead of | ||||
| domain names. | ||||
| o Split READ-ONLY Job Description and Printer Description attributes | o Split READ-ONLY Job Description and Printer Description attributes | |||
| into Job Status and Printer Status attributes to match the current | into Job Status and Printer Status attributes to match the current | |||
| IANA IPP registry organization. | IANA IPP registry organization. | |||
| o Referenced all IETF and PWG IPP standards. | o Referenced all IETF and PWG IPP standards. | |||
| o Updated OPTIONAL operations, attributes, and values to RECOMMENDED | o Updated OPTIONAL operations, attributes, and values to RECOMMENDED | |||
| for consistency with IPP 2.0, IPP Everywhere, and the IPP | for consistency with IPP 2.0, IPP Everywhere, and the IPP | |||
| Implementor's Guide v2.0 (IG). | Implementor's Guide v2.0 (IG). | |||
| o The appendix on media names has been removed. Readers are | o The appendix on media names has been removed. Readers are | |||
| directed to the PWG Media Standardized Names 2.0 (MSN) | directed to the PWG Media Standardized Names 2.0 (MSN) | |||
| [PWG5101.1]. | [PWG5101.1]. | |||
| 11. References | 11. References | |||
| 11.1. Normative References | 11.1. Normative References | |||
| [ASCII] ANSI, "Information Systems - Coded Character Sets - 7-Bit | ||||
| American National Standard Code for Information | ||||
| Interchange (7-Bit ASCII)", June 2007. | ||||
| [ASME-Y14.1M] | [ASME-Y14.1M] | |||
| "ASME Y14.1M-1995: Metric Drawing Sheet Size and Format", | "ASME Y14.1M-1995: Metric Drawing Sheet Size and Format", | |||
| 1995. | 1995. | |||
| [ISO10175] | [ISO10175] | |||
| "ISO/IEC 10175 Document Printing Application (DPA)", June | "ISO/IEC 10175 Document Printing Application (DPA)", June | |||
| 1996. | 1996. | |||
| [ISO10646-1] | [ISO10646-1] | |||
| "ISO/IEC 10646-1:1993, "Information technology -- | "ISO/IEC 10646-1:1993, "Information technology -- | |||
| skipping to change at page 180, line 12 ¶ | skipping to change at page 181, line 5 ¶ | |||
| [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification | |||
| version 1.3", RFC 1951, May 1996. | version 1.3", RFC 1951, May 1996. | |||
| [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. | |||
| Randers-Pehrson, "GZIP file format specification version | Randers-Pehrson, "GZIP file format specification version | |||
| 4.3", RFC 1952, May 1996. | 4.3", RFC 1952, May 1996. | |||
| [RFC1977] Schryver, V., "PPP BSD Compression Protocol", RFC 1977, | [RFC1977] Schryver, V., "PPP BSD Compression Protocol", RFC 1977, | |||
| August 1996. | August 1996. | |||
| [RFC20] Cerf, V., "ASCII format for network interchange", STD 80, | ||||
| RFC 20, DOI 10.17487/RFC0020, October 1969, | ||||
| <http://www.rfc-editor.org/info/rfc20>. | ||||
| [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
| Extensions (MIME) Part One: Format of Internet Message | Extensions (MIME) Part One: Format of Internet Message | |||
| Bodies", RFC 2045, November 1996. | Bodies", RFC 2045, November 1996. | |||
| [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
| Extensions (MIME) Part Two: Media Types", RFC 2046, | Extensions (MIME) Part Two: Media Types", RFC 2046, | |||
| November 1996. | November 1996. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. | [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. | |||
| [RFC2910bis] | [RFC2910bis] | |||
| Sweet, M. and I. McDonald, "Internet Printing | Sweet, M. and I. McDonald, "Internet Printing | |||
| Protocol/1.1: Encoding and Transport", December 2015, | Protocol/1.1: Encoding and Transport", July 2016, | |||
| <http://tools.ietf.org/html/draft-sweet-rfc2910bis>. | <http://tools.ietf.org/html/draft-sweet-rfc2910bis>. | |||
| [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. | [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. | |||
| Holst, "Internet Printing Protocol/1.1: Implementor's | Holst, "Internet Printing Protocol/1.1: Implementor's | |||
| Guide", RFC 3196, November 2001. | Guide", RFC 3196, November 2001. | |||
| [RFC3239] Kugler, C., Lewis, H., and T. Hastings, "Internet Printing | ||||
| Protocol (IPP): Requirements for Job, Printer, and Device | ||||
| Administrative Operations", RFC 3239, February 2002. | ||||
| [RFC3380] Hastings, T., Herriot, R., Kugler, C., and H. Lewis, | [RFC3380] Hastings, T., Herriot, R., Kugler, C., and H. Lewis, | |||
| "Internet Printing Protocol (IPP): Job and Printer Set | "Internet Printing Protocol (IPP): Job and Printer Set | |||
| Operations", RFC 3380, September 2002. | Operations", RFC 3380, September 2002. | |||
| [RFC3510] Herriot, R. and I. McDonald, "Internet Printing | [RFC3510] Herriot, R. and I. McDonald, "Internet Printing | |||
| Protocol/1.1: IPP URL Scheme", RFC 3510, April 2003. | Protocol/1.1: IPP URL Scheme", RFC 3510, April 2003. | |||
| [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO | [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO | |||
| 10646", STD 63, RFC 3629, November 2003. | 10646", STD 63, RFC 3629, November 2003. | |||
| skipping to change at page 181, line 17 ¶ | skipping to change at page 182, line 9 ¶ | |||
| 3986, January 2005. | 3986, January 2005. | |||
| [RFC3995] Herriot, R. and T. Hastings, "Internet Printing Protocol | [RFC3995] Herriot, R. and T. Hastings, "Internet Printing Protocol | |||
| (IPP): Event Notifications and Subscriptions", RFC 3995, | (IPP): Event Notifications and Subscriptions", RFC 3995, | |||
| March 2005. | March 2005. | |||
| [RFC3996] Herriot, R., Hastings, T., and H. Lewis, "Internet | [RFC3996] Herriot, R., Hastings, T., and H. Lewis, "Internet | |||
| Printing Protocol (IPP): The 'ippget' Delivery Method for | Printing Protocol (IPP): The 'ippget' Delivery Method for | |||
| Event Notifications", RFC 3996, March 2005. | Event Notifications", RFC 3996, March 2005. | |||
| [RFC3997] Hastings, T., deBry, R., and H. Lewis, "Internet Printing | ||||
| Protocol (IPP): Requirements for IPP Notifications", RFC | ||||
| 3997, March 2005. | ||||
| [RFC3998] Kugler, C., Lewis, H., and T. Hastings, "Internet Printing | [RFC3998] Kugler, C., Lewis, H., and T. Hastings, "Internet Printing | |||
| Protocol (IPP): Job and Printer Administrative | Protocol (IPP): Job and Printer Administrative | |||
| Operations", RFC 3998, March 2005. | Operations", RFC 3998, March 2005. | |||
| [RFC5051] Crispin, M., "i;unicode-casemap - Simple Unicode Collation | ||||
| Algorithm", RFC 5051, DOI 10.17487/RFC5051, October 2007, | ||||
| <http://www.rfc-editor.org/info/rfc5051>. | ||||
| [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax | [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax | |||
| Specifications: ABNF", STD 68, RFC 5234, January 2008. | Specifications: ABNF", STD 68, RFC 5234, January 2008. | |||
| [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | |||
| (TLS) Protocol Version 1.2", RFC 5246, August 2008. | (TLS) Protocol Version 1.2", RFC 5246, August 2008. | |||
| [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying | [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying | |||
| Languages", BCP 47, RFC 5646, September 2009. | Languages", BCP 47, RFC 5646, September 2009. | |||
| [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type | [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type | |||
| skipping to change at page 182, line 18 ¶ | skipping to change at page 183, line 12 ¶ | |||
| [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC | [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC | |||
| 793, September 1981. | 793, September 1981. | |||
| 11.2. Informative References | 11.2. Informative References | |||
| [HTPP] Barnett, J., Carter, K., and R. DeBry, "Initial Draft - | [HTPP] Barnett, J., Carter, K., and R. DeBry, "Initial Draft - | |||
| Hypertext Printing Protocol - HTPP/1.0", 10 1996, | Hypertext Printing Protocol - HTPP/1.0", 10 1996, | |||
| <ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/ | <ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/ | |||
| overview.ps.gz>. | overview.ps.gz>. | |||
| [IANA-CON] | ||||
| Narten, T. and H. Alvestrand, "Guidelines for Writing an | ||||
| IANA Considerations Section in RFCs", BCP 26, RFC 5226, | ||||
| May 2008. | ||||
| [IANA-CS] "IANA Registry of Coded Character Sets", | [IANA-CS] "IANA Registry of Coded Character Sets", | |||
| <ftp://ftp.isi.edu/in-notes/iana/assignments/character- | <http://www.iana.org/assignments/character-sets/ | |||
| sets>. | character-sets.xhtml>. | |||
| [IANA-MT] "IANA Registry of Media Types", <ftp://ftp.isi.edu/in- | [IANA-MT] "IANA Registry of Media Types", | |||
| notes/iana/assignments/media-types/>. | <http://www.iana.org/assignments/media-types/ | |||
| media-types.xhtml>. | ||||
| [IANA-PEN] | ||||
| "IANA Registry of Private Enterprise Numbers", | ||||
| <http://www.iana.org/assignments/enterprise-numbers/ | ||||
| enterprise-numbers>. | ||||
| [ISO32000] | [ISO32000] | |||
| "Document management -- Portable document format -- Part | "Document management -- Portable document format -- Part | |||
| 1: PDF 1.7", 7 2008, | 1: PDF 1.7", 7 2008, | |||
| <http://www.adobe.com/devnet/acrobat/pdfs/ | <http://www.adobe.com/devnet/acrobat/pdfs/ | |||
| PDF32000_2008.pdf>. | PDF32000_2008.pdf>. | |||
| [LDPA] Hastings, T., Isaacson, S., MacKay, M., Manros, C., | [LDPA] Hastings, T., Isaacson, S., MacKay, M., Manros, C., | |||
| Taylor, D., and P. Zehler, "LDPA - Lightweight Document | Taylor, D., and P. Zehler, "LDPA - Lightweight Document | |||
| Printing Application", October 1996, | Printing Application", October 1996, | |||
| <ftp://ftp.pwg.org/pub/pwg/ipp/historic/ldpa/ | <ftp://ftp.pwg.org/pub/pwg/ipp/historic/ldpa/ | |||
| ldpa8.pdf.gz>. | ldpa8.pdf.gz>. | |||
| [P1387.4] Kirk, M., "POSIX System Administration - Part 4: Printing | [P1387.4] Kirk, M., "POSIX System Administration - Part 4: Printing | |||
| Interfaces, POSIX 1387.4 D8", 1998. | Interfaces, POSIX 1387.4 D8", 1998. | |||
| [PSIS] Herriot, R., "X/Open: A Printing System Interoperability | [PSIS] Herriot, R., "X/Open: A Printing System Interoperability | |||
| Specification (PSIS)", August 1995. | Specification (PSIS)", August 1995. | |||
| [PWG-IPP-WG] | ||||
| "IEEE-ISTO Printer Working Group: Internet Printing | ||||
| Protocol Workgroup", <http://www.pwg.org/ipp>. | ||||
| [RFC1179] McLaughlin, L., "Line printer daemon protocol", RFC 1179, | [RFC1179] McLaughlin, L., "Line printer daemon protocol", RFC 1179, | |||
| August 1990. | August 1990. | |||
| [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform | ||||
| Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, | ||||
| December 1994, <http://www.rfc-editor.org/info/rfc1738>. | ||||
| [RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228, October | [RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228, October | |||
| 1997. | 1997. | |||
| [RFC2316] Bellovin, S., "Report of the IAB Security Architecture | [RFC2316] Bellovin, S., "Report of the IAB Security Architecture | |||
| Workshop", RFC 2316, April 1998. | Workshop", RFC 2316, April 1998. | |||
| [RFC2565] Herriot, R., Butler, S., Moore, P., and R. Turner, | [RFC2565] Herriot, R., Butler, S., Moore, P., and R. Turner, | |||
| "Internet Printing Protocol/1.0: Encoding and Transport", | "Internet Printing Protocol/1.0: Encoding and Transport", | |||
| RFC 2565, April 1999. | RFC 2565, April 1999. | |||
| skipping to change at page 183, line 34 ¶ | skipping to change at page 184, line 37 ¶ | |||
| "Mapping between LPD and IPP Protocols", RFC 2569, April | "Mapping between LPD and IPP Protocols", RFC 2569, April | |||
| 1999. | 1999. | |||
| [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. | [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. | |||
| Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD | Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD | |||
| 58, RFC 2579, April 1999. | 58, RFC 2579, April 1999. | |||
| [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration | [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration | |||
| Procedures", BCP 19, RFC 2978, October 2000. | Procedures", BCP 19, RFC 2978, October 2000. | |||
| [SWP] Moore, P., Jahromi, B., and S. Butler, "Simple Web | [RFC3239] Kugler, C., Lewis, H., and T. Hastings, "Internet Printing | |||
| Printing SWP/1.0", May 1997, | Protocol (IPP): Requirements for Job, Printer, and Device | |||
| <ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/swp9705.pdf>. | Administrative Operations", RFC 3239, February 2002. | |||
| 11.3. URIs | [RFC3997] Hastings, T., deBry, R., and H. Lewis, "Internet Printing | |||
| Protocol (IPP): Requirements for IPP Notifications", RFC | ||||
| 3997, March 2005. | ||||
| [1] http://www.pwg.org/ | [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally | |||
| Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI | ||||
| 10.17487/RFC4122, July 2005, | ||||
| <http://www.rfc-editor.org/info/rfc4122>. | ||||
| [2] http://www.pwg.org/ipp/ | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
| IANA Considerations Section in RFCs", BCP 26, RFC 5226, | ||||
| DOI 10.17487/RFC5226, May 2008, | ||||
| <http://www.rfc-editor.org/info/rfc5226>. | ||||
| [3] http://www.pwg.org/ | [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' | |||
| URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, | ||||
| <http://www.rfc-editor.org/info/rfc6068>. | ||||
| [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, | ||||
| "Recommendations for Secure Use of Transport Layer | ||||
| Security (TLS) and Datagram Transport Layer Security | ||||
| (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May | ||||
| 2015, <http://www.rfc-editor.org/info/rfc7525>. | ||||
| [SWP] Moore, P., Jahromi, B., and S. Butler, "Simple Web | ||||
| Printing SWP/1.0", May 1997, | ||||
| <ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/swp9705.pdf>. | ||||
| Appendix A. Formats for IPP Registration Proposals | Appendix A. Formats for IPP Registration Proposals | |||
| In order to propose an IPP extension for registration, the proposer | In order to propose an IPP extension for registration, the proposer | |||
| must submit an application to IANA by email to "iana@iana.org" or by | must submit an application to IANA by email to "iana@iana.org" or by | |||
| filling out the appropriate form on the IANA web pages | filling out the appropriate form on the IANA web pages | |||
| (http://www.iana.org). This section specifies the required | (http://www.iana.org). This section specifies the required | |||
| information and the formats for proposing registrations of extensions | information and the formats for proposing registrations of extensions | |||
| to IPP as provided in Section 7 for: | to IPP as provided in Section 7 for: | |||
| 1. type2 'keyword' attribute values | 1. attributes | |||
| 2. type2 'enum' attribute values | ||||
| 3. attributes | ||||
| 4. attribute syntaxes | ||||
| 5. operations | ||||
| 6. status codes | ||||
| 7. out-of-band attribute values | ||||
| A.1. Type2 keyword attribute values registration | ||||
| Type of registration: type2 keyword attribute value | ||||
| Name of attribute to which this keyword specification is to be added: | ||||
| Proposed keyword name of this keyword value: | ||||
| Specification of this keyword value (follow the style of IPP Model | ||||
| Section 5.1.3.3): | ||||
| Name of proposer: | ||||
| Address of proposer: | ||||
| Email address of proposer: | ||||
| Note: For type2 keywords, the Designated Expert will be the point of | ||||
| contact for the approved registration specification, if any | ||||
| maintenance of the registration specification is needed. | ||||
| A.2. Type2 enum attribute values registration | ||||
| Type of registration: type2 enum attribute value | ||||
| Name of attribute to which this enum specification is to be added: | ||||
| Keyword symbolic name of this enum value: | ||||
| Numeric value (to be assigned by the IPP Designated Expert in | ||||
| consultation with IANA): | ||||
| Specification of this enum value (follow the style of IPP Model | ||||
| Section 5.1.5): | ||||
| Name of proposer: | 2. type2 'keyword' attribute values | |||
| Address of proposer: | 3. type2 'enum' attribute values | |||
| Email address of proposer: | 4. operations | |||
| Note: For type2 enums, the Designated Expert will be the point of | 5. status codes | |||
| contact for the approved registration specification, if any | ||||
| maintenance of the registration specification is needed. | ||||
| A.3. Attribute registration | A.1. Attribute Registration | |||
| Type of registration: attribute | Type of registration: attribute | |||
| Proposed keyword name of this attribute: | Proposed keyword name of this attribute: | |||
| Types of attribute (Operation, Job Template, Job Description, Job | Types of attribute (Document Description, Document Status, Document | |||
| Status, Printer Description, Printer Status): | Template, Event Notifications, Job Description, Job Status, Job | |||
| Template, Operation, Printer Description, Printer Status, | ||||
| Subscription Description, Subscription Status, Subscription | ||||
| Template): | ||||
| Operations to be used with if the attribute is an operation | Operations to be used with if the attribute is an operation | |||
| attribute: | attribute: | |||
| Object (Job, Printer, etc. if bound to an object): | Object (Document, Job, Printer, Subscription, etc. if bound to an | |||
| object): | ||||
| Attribute syntax(es) (include 1setOf and range as in Section 5.2): | Attribute syntax(es) (include 1setOf and range as in Section 5.2): | |||
| If attribute syntax is 'keyword' or 'enum', is it type1 or type2: | If attribute syntax is 'keyword' or 'enum', is it type1 or type2: | |||
| If this is a Printer attribute, MAY the value returned depend on | If this is a Printer attribute, MAY the value returned depend on | |||
| "document-format" (See Section 7.2): | "document-format" (See Section 7.2): | |||
| If this is a Job Template attribute, how does its specification | If this is a Job Template attribute, how does its specification | |||
| depend on the value of the "multiple-document-handling" attribute: | depend on the value of the "multiple-document-handling" attribute: | |||
| Specification of this attribute (follow the style of IPP Model | Specification of this attribute (follow the style of Section 5.2): | |||
| Section 5.2): | ||||
| Name of proposer: | Name of proposer: | |||
| Address of proposer: | ||||
| Email address of proposer: | Email address of proposer: | |||
| Note: For attributes, the IPP Designated Expert will be the point of | Note: For attributes, the IPP Designated Expert will be the point of | |||
| contact for the approved registration specification, if any | contact and change controller for the approved registration | |||
| maintenance of the registration specification is needed. | specification, if any maintenance of the registration specification | |||
| is needed. | ||||
| A.4. Attribute Syntax registration | ||||
| Type of registration: attribute syntax | A.2. Type2 Keyword Attribute Value Registration | |||
| Proposed name of this attribute syntax: | Type of registration: type2 keyword attribute value | |||
| Type of attribute syntax (integer, octetString, character-string, see | Name of attribute to which this keyword specification is to be added: | |||
| [RFC2910bis]): | ||||
| Numeric tag according to [RFC2910bis] (to be assigned by the IPP | Proposed keyword name of this keyword value: | |||
| Designated Expert in consultation with IANA): | ||||
| Specification of this attribute (follow the style of IPP Model | Specification of this keyword value (follow the style of | |||
| Section 5.1): | Section 5.1.3.3): | |||
| Name of proposer: | Name of proposer: | |||
| Address of proposer: | ||||
| Email address of proposer: | Email address of proposer: | |||
| Note: For attribute syntaxes, the IPP Designated Expert will be the | Note: For type2 keywords, the Designated Expert will be the point of | |||
| point of contact for the approved registration specification, if any | contact and change controller for the approved registration | |||
| maintenance of the registration specification is needed. | specification, if any maintenance of the registration specification | |||
| is needed. | ||||
| A.5. Operation registration | A.3. Type2 Enum Attribute Value Registration | |||
| Type of registration: operation | Type of registration: type2 enum attribute value | |||
| Proposed name of this operation: | Name of attribute to which this enum specification is to be added: | |||
| Numeric operation-id value according to Section 5.4.15 (to be | Keyword symbolic name of this enum value: | |||
| assigned by the IPP Designated Expert in consultation with IANA): | ||||
| Object Target (Job, Printer, etc. that operation is upon): | Numeric value (to be assigned by the IPP Designated Expert in | |||
| consultation with IANA): | ||||
| Specification of this operation (follow the style of IPP Model | Specification of this enum value (follow the style of Section 5.1.5): | |||
| Section 4): | ||||
| Name of proposer: | Name of proposer: | |||
| Address of proposer: | ||||
| Email address of proposer: | Email address of proposer: | |||
| Note: For operations, the IPP Designated Expert will be the point of | Note: For type2 enums, the Designated Expert will be the point of | |||
| contact for the approved registration specification, if any | contact and change controller for the approved registration | |||
| maintenance of the registration specification is needed. | specification, if any maintenance of the registration specification | |||
| is needed. | ||||
| A.6. Attribute Group registration | ||||
| Type of registration: attribute group | A.4. Operation Registration | |||
| Proposed name of this attribute group: | Type of registration: operation | |||
| Numeric tag according to [RFC2910bis] (to be assigned by the IPP | Proposed name of this operation: | |||
| Designated Expert in consultation with IANA): | ||||
| Operation requests and group number for each operation in which the | Numeric operation-id value according to Section 5.4.15 (to be | |||
| attribute group occurs: | assigned by the IPP Designated Expert in consultation with IANA): | |||
| Operation responses and group number for each operation in which the | Object Target (Document, Job, Printer, Subscription, etc. that | |||
| attribute group occurs: | operation is upon): | |||
| Specification of this attribute group (follow the style of IPP Model | Specification of this operation (follow the style of Section 4): | |||
| Section 4): | ||||
| Name of proposer: | Name of proposer: | |||
| Address of proposer: | ||||
| Email address of proposer: | Email address of proposer: | |||
| Note: For attribute groups, the IPP Designated Expert will be the | Note: For operations, the IPP Designated Expert will be the point of | |||
| point of contact for the approved registration specification, if any | contact and change controller for the approved registration | |||
| maintenance of the registration specification is needed. | specification, if any maintenance of the registration specification | |||
| is needed. | ||||
| A.7. Status code registration | A.5. Status code registration | |||
| Type of registration: status code | Type of registration: status code | |||
| Keyword symbolic name of this status code value: | Keyword symbolic name of this status code value: | |||
| Numeric value (to be assigned by the IPP Designated Expert in | Numeric value (to be assigned by the IPP Designated Expert in | |||
| consultation with IANA): | consultation with IANA): | |||
| Operations that this status code can be used with: | Operations that this status code can be used with: | |||
| Specification of this status code (follow the style of IPP Model | Specification of this status code (follow the style of Appendix B): | |||
| Appendix B APPENDIX B: Status Codes and Suggested Status Code | ||||
| Messages): | ||||
| Name of proposer: | Name of proposer: | |||
| Address of proposer: | ||||
| Email address of proposer: | Email address of proposer: | |||
| Note: For status codes, the Designated Expert will be the point of | Note: For status codes, the Designated Expert will be the point of | |||
| contact for the approved registration specification, if any | contact and change controller for the approved registration | |||
| maintenance of the registration specification is needed. | ||||
| A.8. Out-of-band Attribute Value registration | ||||
| Type of registration: out-of-band attribute value | ||||
| Proposed name of this out-of-band attribute value: | ||||
| Numeric tag according to [RFC2910bis] (to be assigned by the IPP | ||||
| Designated Expert in consultation with IANA): | ||||
| Operations that this out-of-band attribute value can be used with: | ||||
| Attributes that this out-of-band attribute value can be used with: | ||||
| Specification of this out-of-band attribute value (follow the style | ||||
| of the beginning of IPP Model Section 5.1): | ||||
| Name of proposer: | ||||
| Address of proposer: | ||||
| Email address of proposer: | ||||
| Note: For out-of-band attribute values, the IPP Designated Expert | ||||
| will be the point of contact for the approved registration | ||||
| specification, if any maintenance of the registration specification | specification, if any maintenance of the registration specification | |||
| is needed. | is needed. | |||
| Appendix B. Status Codes and Suggested Status Code Messages | Appendix B. Status Codes and Suggested Status Code Messages | |||
| This section defines status code enum keywords and values that are | This section defines status code enum keywords and values that are | |||
| used to provide semantic information on the results of an operation | used to provide semantic information on the results of an operation | |||
| request. Each operation response MUST include a status code. The | request. Each operation response MUST include a status code. The | |||
| response MAY also contain a status message that provides a short | response MAY also contain a status message that provides a short | |||
| textual description of the status. The status code is intended for | textual description of the status. The status code is intended for | |||
| skipping to change at page 190, line 9 ¶ | skipping to change at page 189, line 41 ¶ | |||
| The top half (128 values) of each range (0x0n80 to 0x0nFF, for n = 0 | The top half (128 values) of each range (0x0n80 to 0x0nFF, for n = 0 | |||
| to 5) is reserved for vendor use within each status code class. | to 5) is reserved for vendor use within each status code class. | |||
| Values 0x0600 to 0x7FFF are reserved for future assignment by | Values 0x0600 to 0x7FFF are reserved for future assignment by | |||
| standards track documents and MUST NOT be used. | standards track documents and MUST NOT be used. | |||
| B.1. Status Codes | B.1. Status Codes | |||
| Each status code is described below. Appendix B.1.5.9 contains a | Each status code is described below. Appendix B.1.5.9 contains a | |||
| table that indicates which status codes apply to which operations. | table that indicates which status codes apply to which operations. | |||
| The Implementor's Guides [RFC3196] [PWG5100.19] describe the | The Implementor's Guides [RFC3196] [PWG5100.19] provide guidance for | |||
| suggested steps for processing IPP attributes for all operations, | processing IPP attributes for all operations, including returning | |||
| including returning status codes. | status codes. | |||
| B.1.1. Informational | B.1.1. Informational | |||
| This class of status code indicates a provisional response and is to | This class of status code indicates a provisional response and is to | |||
| be used for informational purposes only. | be used for informational purposes only. | |||
| There are no status codes defined in this document for this class of | There are no status codes defined in this document for this class of | |||
| status code. | status code. | |||
| B.1.2. Successful Status Codes | B.1.2. Successful Status Codes | |||
| skipping to change at page 201, line 49 ¶ | skipping to change at page 201, line 37 ¶ | |||
| In a Job Creation request, "ipp-attribute-fidelity" is a boolean | In a Job Creation request, "ipp-attribute-fidelity" is a boolean | |||
| operation attribute that MAY be supplied by the Client. The value | operation attribute that MAY be supplied by the Client. The value | |||
| 'true' indicates that total fidelity to Client supplied Job Template | 'true' indicates that total fidelity to Client supplied Job Template | |||
| attributes and values is required. The Client is requesting that the | attributes and values is required. The Client is requesting that the | |||
| Job be printed exactly as specified, and if that is not possible then | Job be printed exactly as specified, and if that is not possible then | |||
| the Job MUST be rejected rather than processed incorrectly. The | the Job MUST be rejected rather than processed incorrectly. The | |||
| value 'false' indicates that a reasonable attempt to print the Job is | value 'false' indicates that a reasonable attempt to print the Job is | |||
| acceptable. If a Printer does not support some of the Client | acceptable. If a Printer does not support some of the Client | |||
| supplied Job Template attributes or values, the Printer MUST ignore | supplied Job Template attributes or values, the Printer MUST ignore | |||
| them or substitute any supported value for unsupported values, | or replace them with supported values. The Printer can choose to | |||
| respectively. The Printer can choose to substitute the default value | substitute the default value associated with that attribute, or use | |||
| associated with that attribute, or use some other supported value | some other supported value that is similar to the unsupported | |||
| that is similar to the unsupported requested value. For example, if | requested value. For example, if a Client supplies a "media" value | |||
| a Client supplies a "media" value of 'na_letter_8.5x11in', the | of 'na_letter_8.5x11in', the Printer can choose to substitute | |||
| Printer can choose to substitute 'iso_a4_210x297mm' rather than a | 'iso_a4_210x297mm' rather than a default value of | |||
| default value of 'na_personal_3.625x6.5in'. If the Client does not | 'na_personal_3.625x6.5in'. If the Client does not supply the "ipp- | |||
| supply the "ipp-attribute-fidelity" attribute, the Printer assumes a | attribute-fidelity" attribute, the Printer assumes a value of | |||
| value of 'false'. | 'false'. | |||
| Each Printer implementation MUST support both types of "fidelity" | Each Printer implementation MUST support both types of "fidelity" | |||
| printing (that is whether the Client supplies a value of 'true' or | printing (that is whether the Client supplies a value of 'true' or | |||
| 'false'): | 'false'): | |||
| o If the Client supplies 'false' or does not supply the attribute, | o If the Client supplies 'false' or does not supply the attribute, | |||
| the Printer MUST always accept the request by ignoring unsupported | the Printer MUST always accept the request by ignoring unsupported | |||
| Job Template attributes and by substituting unsupported values of | Job Template attributes and by substituting unsupported values of | |||
| supported Job Template attributes with supported values. | supported Job Template attributes with supported values. | |||
| skipping to change at page 208, line 26 ¶ | skipping to change at page 208, line 11 ¶ | |||
| +------------------------------------+-------------+----------------+ | +------------------------------------+-------------+----------------+ | |||
| | supported | OPTIONAL | Section 5.4.20 | | | supported | OPTIONAL | Section 5.4.20 | | |||
| +------------------------------------+-------------+----------------+ | +------------------------------------+-------------+----------------+ | |||
| | uri-authentication-supported | RECOMMENDED | Section 5.4.2 | | | uri-authentication-supported | RECOMMENDED | Section 5.4.2 | | |||
| +------------------------------------+-------------+----------------+ | +------------------------------------+-------------+----------------+ | |||
| | uri-security-supported | RECOMMENDED | Section 5.4.3 | | | uri-security-supported | RECOMMENDED | Section 5.4.3 | | |||
| +------------------------------------+-------------+----------------+ | +------------------------------------+-------------+----------------+ | |||
| Table 23: Attributes in Directory Entries | Table 23: Attributes in Directory Entries | |||
| Appendix E. Change History | Appendix E. Acknowledgements | |||
| E.1. Changes In -09 | The authors would like to acknowledge the following individuals for | |||
| their contributions to the original IPP/1.1 specifications: | ||||
| Roger deDry, Tom Hastings (original RFC 2911 editor), Robert Herriot, | ||||
| Scott A. Isaacson, Kirk Ocke, Patrick Powell, and Peter Zehler | ||||
| Appendix F. Change History | ||||
| F.1. Changes In -11 | ||||
| The following changes are in draft-sweet-rfc2911bis-11: | ||||
| o Restored the acknowledgements section to include authors from the | ||||
| original RFC 2911 and 3382. | ||||
| o Updated the vendor extension recommendations for keywords and | ||||
| attributes to use SMI Enterprise Number prefixes, per ISTO-PWG IPP | ||||
| workgroup decision on August 23, 2016. | ||||
| F.2. Changes In -10 | ||||
| The following changes are in draft-sweet-rfc2910bis-10: | ||||
| o Abstract: Mention that this document obsoletes RFC 2910 and 3382, | ||||
| and reword for clarity. | ||||
| o Editor's Note: Add parenthetical note to RFC editor to remove | ||||
| before publication. | ||||
| o Acronyms: Drop external reference to PWG web site. | ||||
| o Updated references to ASCII to RFC 20/STD 80. | ||||
| o Updated links to IANA-CS and IANA-MT. | ||||
| o Spelling: Fixed spelling of Administrative. | ||||
| o Clarified that IPP objects are Jobs, Printers, etc., and that IPP | ||||
| Printer object is referred to as "Printer", IPP Job object is | ||||
| "Job", etc. | ||||
| o Fixed figure captions and references. | ||||
| o Fixed references to appendices. | ||||
| o Changed examples using old working draft on ftp.pwg.org to an | ||||
| imaginary file on www.example.com. | ||||
| o Section 1: Change external references to PWG IPP WG so they appear | ||||
| as an informational reference. Also mention IPP 2.0, 2.1, and | ||||
| 2.2. | ||||
| o Section 1.1: Editorial changes. | ||||
| o Section 2.3.11: Reword to avoid duplicate conformance terms. | ||||
| o Section 3.4: Reword use of secure URIs. | ||||
| o Section 4.1.4.1: Added reference to RFC 2978 for charsets, | ||||
| clarified that charset conversion, filtering, and/or replacement | ||||
| might be done on the client side. | ||||
| o Section 4.1.4.1: Added reference to RFC 5646 for language tags, | ||||
| reword section on incompatible combinations of language and | ||||
| charset. | ||||
| o Section 4.1.5: Reword to avoid duplicate conformance terms. | ||||
| o Section 4.1.6: Reword to avoid duplicate conformance terms. | ||||
| o Section 4.1.6.2: an IPP Client CAN examine or display the | ||||
| messages. | ||||
| o Section 4.1.7: Clarified section reference (in this document). | ||||
| o Sections 4.1.9, 4.2.1.2, and 4.2.2: Reworded references to the | ||||
| implementor's guides. | ||||
| o Section 5.1.3.3: Clarified language tag matching, reference RFC | ||||
| 5051. | ||||
| o Section 5.2.11: Reworded "media-col" note to use MAY. | ||||
| o Section 5.4.2: Clarify that the textual name can come from the | ||||
| Common Name or Subject Alternate Name fields in the X.509 | ||||
| certificate. | ||||
| o Section 5.4.3: Added reference to RFC 7525. | ||||
| o Section 6.1: Reword to avoid duplicate conformance terms. | ||||
| o Section 7: Clarify that the IANA IPP registry already exists and | ||||
| only the pointers to the current registration procedures should be | ||||
| updated. Harmonize registration procedures and rules with what is | ||||
| shown in the current IANA IPP Registry. Provide a separate | ||||
| subsection for each sub-registry. | ||||
| o Section 7.1: Reverse domain name for vendor keyword prefixes. | ||||
| o Section 7.8: Updated MIME media type registration RFC | ||||
| o Section 9: Reword small business example as "private LAN with | ||||
| physical security", add reference for private information in Job | ||||
| objects. | ||||
| o Section 9.1.1: Add reference to TLS. | ||||
| o Section 9.1.2: Mention authentication and scanning of document | ||||
| data for mitigation of spamming and malicious content threats. | ||||
| o Section 9.1.3: Mention that print-by-reference is not a DoS | ||||
| threat. | ||||
| o Appendix A: Dropped attribute syntaxes, attribute groups, and out- | ||||
| of-band attribute values which now require a specification. | ||||
| Updated templates to reflect current requirements. IPP Designated | ||||
| Expert(s) are the change controllers. | ||||
| o Appendix C.1: Reword section on substituting unsupported values to | ||||
| avoid confusion. | ||||
| o Moved RFC 3239 and 3997 references to the Informative References | ||||
| section. | ||||
| F.3. Changes In -09 | ||||
| The following changes are in draft-sweet-rfc2911bis-09: | The following changes are in draft-sweet-rfc2911bis-09: | |||
| o Section 2.3.4: Mention imposition of input pages on impressions | o Section 2.3.4: Mention imposition of input pages on impressions | |||
| during processing. | during processing. | |||
| o Section 2.3.8: Mention roll media. | o Section 2.3.8: Mention roll media. | |||
| o Section 4.1.4: Reworded for clarity. | o Section 4.1.4: Reworded for clarity. | |||
| skipping to change at page 209, line 18 ¶ | skipping to change at page 211, line 34 ¶ | |||
| o Section 4.3.3.2: Moved Status Message after Natural Language and | o Section 4.3.3.2: Moved Status Message after Natural Language and | |||
| Character Set. | Character Set. | |||
| o Section 4.3.4.2: Moved Status Message after Natural Language and | o Section 4.3.4.2: Moved Status Message after Natural Language and | |||
| Character Set. | Character Set. | |||
| o Section 5.1: Moved out-of-band syntaxes to their own sub-section. | o Section 5.1: Moved out-of-band syntaxes to their own sub-section. | |||
| o Section 5.2.6: Origin of media sheet is the top left corner. | o Section 5.2.6: Origin of media sheet is the top left corner. | |||
| E.2. Changes In -08 | F.4. Changes In -08 | |||
| The following changes are in draft-sweet-rfc2911bis-08: | The following changes are in draft-sweet-rfc2911bis-08: | |||
| o Section 2.3.3 (End User): Capitalize defined terms. | o Section 2.3.3 (End User): Capitalize defined terms. | |||
| o Section 2.3.11 (Supports): Add a final paragraph on naming | o Section 2.3.11 (Supports): Add a final paragraph on naming | |||
| conventions for xxx-supported, xxx-default, and xxx-configured. | conventions for xxx-supported, xxx-default, and xxx-configured. | |||
| o Section 4.1.3 (Attributes): Updated last paragraph to use | o Section 4.1.3 (Attributes): Updated last paragraph to use | |||
| normative language (IPP object MUST return an error) | normative language (IPP object MUST return an error) | |||
| o Section 4.2.1.2: (Print-Job Response): Reword reference to job- | o Section 4.2.1.2: (Print-Job Response): Reword reference to job- | |||
| state-reasons attribute. | state-reasons attribute. | |||
| o Section 5.4.12 (printer-state-reasons): Added RFC 3805 property | o Section 5.4.12 (printer-state-reasons): Added RFC 3805 property | |||
| values that correspond to each reason, sorted list. | values that correspond to each reason, sorted list. | |||
| o Section 11.1 (Normative References): Fixed title of RFC 7612 | o Section 11.1 (Normative References): Fixed title of RFC 7612 | |||
| reference. | reference. | |||
| E.3. Changes In -07 | F.5. Changes In -07 | |||
| The following changes are in draft-sweet-rfc2911bis-07: | The following changes are in draft-sweet-rfc2911bis-07: | |||
| o Global: Normalize "end-user" as "End User" (defined term). | o Global: Normalize "end-user" as "End User" (defined term). | |||
| o Global: Fix capitalization of "xxx-from-operator" and "xxx-by- | o Global: Fix capitalization of "xxx-from-operator" and "xxx-by- | |||
| operator". | operator". | |||
| o Global: Drop "system" in front of "Administrator". | o Global: Drop "system" in front of "Administrator". | |||
| skipping to change at page 210, line 24 ¶ | skipping to change at page 212, line 42 ¶ | |||
| o Section 9.1: Drop "considered" from "are considered illustrative" | o Section 9.1: Drop "considered" from "are considered illustrative" | |||
| (they are). | (they are). | |||
| o Appendix B: Point to IIG 2.0 for how to display status messages. | o Appendix B: Point to IIG 2.0 for how to display status messages. | |||
| o Appendix D: Add references to LDAP schema and IPP Everywhere. | o Appendix D: Add references to LDAP schema and IPP Everywhere. | |||
| o | o | |||
| E.4. Changes In -06 | F.6. Changes In -06 | |||
| The following changes are in draft-sweet-rfc2911bis-06: | The following changes are in draft-sweet-rfc2911bis-06: | |||
| o Global: Changed "malformed" to "malformed". | o Global: Changed "malformed" to "malformed". | |||
| o Global: Make sure all operations are marked OPTIONAL, RECOMMENDED, | o Global: Make sure all operations are marked OPTIONAL, RECOMMENDED, | |||
| or REQUIRED. | or REQUIRED. | |||
| o Global: Fix spelling: "attribure" to "attribute". | o Global: Fix spelling: "attribure" to "attribute". | |||
| skipping to change at page 213, line 22 ¶ | skipping to change at page 215, line 41 ¶ | |||
| o Appendix B.1.3: "in this document" (not in IPP/1.1). | o Appendix B.1.3: "in this document" (not in IPP/1.1). | |||
| o Appendix C: Deleted this appendix in its entirety since PWG 5101.1 | o Appendix C: Deleted this appendix in its entirety since PWG 5101.1 | |||
| supersedes it and is already referenced. | supersedes it and is already referenced. | |||
| o Appendix D.3: Rewording, fix typos. | o Appendix D.3: Rewording, fix typos. | |||
| o Table 22: Fix (missing cells) | o Table 22: Fix (missing cells) | |||
| E.5. Changes In -05 | F.7. Changes In -05 | |||
| The following changes are in draft-sweet-rfc2911bis-05: | The following changes are in draft-sweet-rfc2911bis-05: | |||
| o Global: Drop use of "OPTIONALLY", use MAY instead. | o Global: Drop use of "OPTIONALLY", use MAY instead. | |||
| o Global: Printers SHOULD return unsupported attributes. | o Global: Printers SHOULD return unsupported attributes. | |||
| o Global: Update use of "need only" to less awkward wording. | o Global: Update use of "need only" to less awkward wording. | |||
| o Global: Reword all usage of "NOT REQUIRED". | o Global: Reword all usage of "NOT REQUIRED". | |||
| skipping to change at page 215, line 19 ¶ | skipping to change at page 217, line 39 ¶ | |||
| o Section B.*: Drop conformance, move the rest to the beginning. | o Section B.*: Drop conformance, move the rest to the beginning. | |||
| o Added references to the IPP Implementor's Guide 2.0, PWG 5101.1 | o Added references to the IPP Implementor's Guide 2.0, PWG 5101.1 | |||
| (MSN2), IPP 2.0, and IPP Everywhere. | (MSN2), IPP 2.0, and IPP Everywhere. | |||
| o Updated PWG 5100.12 reference to current stable draft in formal | o Updated PWG 5100.12 reference to current stable draft in formal | |||
| vote (for full IEEE standard). | vote (for full IEEE standard). | |||
| o Various editorial corrections. | o Various editorial corrections. | |||
| E.6. Changes In -04 | F.8. Changes In -04 | |||
| The following changes are in draft-sweet-rfc2911bis-04: | The following changes are in draft-sweet-rfc2911bis-04: | |||
| o Removed restart and purge from the abstract. | o Removed restart and purge from the abstract. | |||
| o Eliminated use of confusing ISO "NEED NOT" conformance | o Eliminated use of confusing ISO "NEED NOT" conformance | |||
| terminology. | terminology. | |||
| o Added DEPRECATED terminology. | o Added DEPRECATED terminology. | |||
| o Marked Purge-Jobs and Restart-Job as DEPRECATED. | o Marked Purge-Jobs and Restart-Job as DEPRECATED. | |||
| o Added reference to PWG 5100.11 (JPS2) for the Resubmit-Job | o Added reference to PWG 5100.11 (JPS2) for the Resubmit-Job | |||
| operation (safe replacement for Restart-Job) | operation (safe replacement for Restart-Job) | |||
| E.7. Changes In -03 | F.9. Changes In -03 | |||
| The following changes are in draft-sweet-rfc2911bis-03: | The following changes are in draft-sweet-rfc2911bis-03: | |||
| o Submission type is now IETF (AD-sponsored), clarify goals. | o Submission type is now IETF (AD-sponsored), clarify goals. | |||
| o Also obsolete RFC 3381 per PWG IPP WG | o Also obsolete RFC 3381 per PWG IPP WG | |||
| o References to RFC 2617 are updated to the updated drafts in the | o References to RFC 2617 are updated to the updated drafts in the | |||
| RFC editor's queue | RFC editor's queue | |||
| skipping to change at page 216, line 15 ¶ | skipping to change at page 218, line 36 ¶ | |||
| o Section 6.2.4: Reword "understand" -> "decode and process" | o Section 6.2.4: Reword "understand" -> "decode and process" | |||
| o References: Drop SSL reference. | o References: Drop SSL reference. | |||
| o Global: Don't use SSL3 in examples, use TLS | o Global: Don't use SSL3 in examples, use TLS | |||
| o Global: Client, Printer, and Job are defined terms, capitalize | o Global: Client, Printer, and Job are defined terms, capitalize | |||
| o Global: Fix lots of uses of "may" (conformance term) | o Global: Fix lots of uses of "may" (conformance term) | |||
| E.8. Changes In -02 | F.10. Changes In -02 | |||
| The following changes are in draft-sweet-rfc2911bis-02: | The following changes are in draft-sweet-rfc2911bis-02: | |||
| o Section 1: Dropped RFC 3381 reference since we are obsoleting it. | o Section 1: Dropped RFC 3381 reference since we are obsoleting it. | |||
| o Section 4.1.5: Added reference to IPP and IPPS URI scheme RFCs. | o Section 4.1.5: Added reference to IPP and IPPS URI scheme RFCs. | |||
| o Section 4.1.8: Added references to RFC 3510 and 7472 which define | o Section 4.1.8: Added references to RFC 3510 and 7472 which define | |||
| the IPP and IPPS URI schemes and port number. | the IPP and IPPS URI schemes and port number. | |||
| o Added section listing major changes since RFC 2911. | o Added section listing major changes since RFC 2911. | |||
| o Fix all "it is recommended" passive voice conformance | o Fix all "it is recommended" passive voice conformance | |||
| requirements. | requirements. | |||
| E.9. Changes In -01 | F.11. Changes In -01 | |||
| The following changes are in draft-sweet-rfc2911bis-01: | The following changes are in draft-sweet-rfc2911bis-01: | |||
| o Errata ID 364: Fix range of "redirection" status codes (to 0x03xx) | o Errata ID 364: Fix range of "redirection" status codes (to 0x03xx) | |||
| o Errata ID 694: Fix range of vendor status codes (0x0n80 to 0x0nff) | o Errata ID 694: Fix range of vendor status codes (0x0n80 to 0x0nff) | |||
| o Errata ID 3072: Reword multiple-document-handling definition since | o Errata ID 3072: Reword multiple-document-handling definition since | |||
| it also applies to single document Jobs and is the only | it also applies to single document Jobs and is the only | |||
| interoperable way to request uncollated copies. | interoperable way to request uncollated copies. | |||
| End of changes. 234 change blocks. | ||||
| 655 lines changed or deleted | 772 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/ | ||||