< 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/