idnits 2.17.1 draft-sweet-rfc2910bis-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2911bis]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC3382, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 604 has weird spacing: '...tes-tag data...' == Line 1664 has weird spacing: '...charset name...' == Line 1670 has weird spacing: '...anguage att...' == Line 1680 has weird spacing: '...anguage value...' == Line 1703 has weird spacing: '...ng-edge value...' == (26 more instances...) -- The document date (August 23, 2016) is 2803 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2910bis' is mentioned on line 1284, but not defined ** Obsolete undefined reference: RFC 2910 (Obsoleted by RFC 8010) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2911 (Obsoleted by RFC 8011) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPP WG M. Sweet 3 Internet-Draft Apple Inc. 4 Obsoletes: 2910,3382 (if approved) I. McDonald 5 Intended status: Standards Track High North, Inc. 6 Expires: February 24, 2017 August 23, 2016 8 Internet Printing Protocol/1.1: Encoding and Transport 9 draft-sweet-rfc2910bis-10 11 Abstract 13 The Internet Printing Protocol (IPP) is an application level protocol 14 for distributed printing using Internet tools and technologies. This 15 document defines the rules for encoding IPP operations, attributes, 16 and values into the Internet MIME media type called "application/ 17 ipp". It also defines the rules for transporting a message body 18 whose Content-Type is "application/ipp" over HTTP and/or HTTPS. The 19 IPP data model and operation semantics are described in IPP/1.1: 20 Model and Semantics [RFC2911bis]. 22 This document obsoletes RFCs 2910 and 3382. 24 Editor's Note (To Be Removed by RFC Editor) 26 This draft is being submitted as an AD-sponsored replacement of RFCs 27 2910 and 3382, with drafts being reviewed and edited by the IEEE- 28 ISTO's Printer Working Group IPP WG. The initial goal is to have an 29 clean version of IPP/1.1 as an IETF Proposed Standard. The long-term 30 goal is to advance IPP/1.1 to IETF Internet Standard. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on February 24, 2017. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 68 2.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 69 2.2. Printing Terminology . . . . . . . . . . . . . . . . . . . 5 70 2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Encoding of the Operation Layer . . . . . . . . . . . . . . . 6 72 3.1. Picture of the Encoding . . . . . . . . . . . . . . . . . . 7 73 3.1.1. Request and Response . . . . . . . . . . . . . . . . . . 7 74 3.1.2. Attribute Group . . . . . . . . . . . . . . . . . . . . . 8 75 3.1.3. Attribute . . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.1.4. Attribute-with-one-value . . . . . . . . . . . . . . . . 9 77 3.1.5. Additional-value . . . . . . . . . . . . . . . . . . . . 9 78 3.1.6. Collection Attribute . . . . . . . . . . . . . . . . . . 10 79 3.1.7. Member Attributes . . . . . . . . . . . . . . . . . . . . 12 80 3.1.8. Alternative Picture of the Encoding of a Request Or a 81 Response . . . . . . . . . . . . . . . . . . . . . . . . 13 82 3.2. Syntax of Encoding . . . . . . . . . . . . . . . . . . . . 14 83 3.3. Attribute-group . . . . . . . . . . . . . . . . . . . . . . 15 84 3.4. Required Parameters . . . . . . . . . . . . . . . . . . . . 17 85 3.4.1. Version-number . . . . . . . . . . . . . . . . . . . . . 17 86 3.4.2. Operation-id . . . . . . . . . . . . . . . . . . . . . . 17 87 3.4.3. Status-code . . . . . . . . . . . . . . . . . . . . . . . 17 88 3.4.4. Request-id . . . . . . . . . . . . . . . . . . . . . . . 18 89 3.5. Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 3.5.1. Delimiter Tags . . . . . . . . . . . . . . . . . . . . . 18 91 3.5.2. Value Tags . . . . . . . . . . . . . . . . . . . . . . . 19 92 3.6. Name-Length . . . . . . . . . . . . . . . . . . . . . . . . 21 93 3.7. (Attribute) Name . . . . . . . . . . . . . . . . . . . . . 22 94 3.8. Value Length . . . . . . . . . . . . . . . . . . . . . . . 22 95 3.9. (Attribute) Value . . . . . . . . . . . . . . . . . . . . . 22 96 3.10. Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 4. Encoding of Transport Layer . . . . . . . . . . . . . . . . . 24 98 4.1. Printer URI, Job URI, and Job ID . . . . . . . . . . . . . 25 99 5. IPP URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 26 100 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 101 7. Internationalization Considerations . . . . . . . . . . . . . 30 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 103 8.1. Security Conformance Requirements . . . . . . . . . . . . . 30 104 8.1.1. Digest Authentication . . . . . . . . . . . . . . . . . . 30 105 8.1.2. Transport Layer Security (TLS) . . . . . . . . . . . . . 31 106 8.2. Using IPP with TLS . . . . . . . . . . . . . . . . . . . . 31 107 9. Interoperability with Other IPP Versions . . . . . . . . . . 32 108 9.1. The "version-number" Parameter . . . . . . . . . . . . . . 32 109 9.2. Security and URI Schemes . . . . . . . . . . . . . . . . . 33 110 10. Changes Since RFC 2910 . . . . . . . . . . . . . . . . . . . 33 111 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 112 11.1. Normative References . . . . . . . . . . . . . . . . . . . 34 113 11.2. Informative References . . . . . . . . . . . . . . . . . . 36 114 Appendix A. Protocol Examples . . . . . . . . . . . . . . . . . 36 115 A.1. Print-Job Request . . . . . . . . . . . . . . . . . . . . . 36 116 A.2. Print-Job Response (successful) . . . . . . . . . . . . . . 38 117 A.3. Print-Job Response (failure) . . . . . . . . . . . . . . . 40 118 A.4. Print-Job Response (success with attributes ignored) . . . 41 119 A.5. Print-URI Request . . . . . . . . . . . . . . . . . . . . . 43 120 A.6. Create-Job Request . . . . . . . . . . . . . . . . . . . . 45 121 A.7. Create-Job Request with Collection Attributes . . . . . . . 45 122 A.8. Get-Jobs Request . . . . . . . . . . . . . . . . . . . . . 47 123 A.9. Get-Jobs Response . . . . . . . . . . . . . . . . . . . . . 49 124 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 50 125 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 50 126 C.1. Changes In -10 . . . . . . . . . . . . . . . . . . . . . . 50 127 C.2. Changes In -09 . . . . . . . . . . . . . . . . . . . . . . 50 128 C.3. Changes In -08 . . . . . . . . . . . . . . . . . . . . . . 51 129 C.4. Changes In -07 . . . . . . . . . . . . . . . . . . . . . . 52 130 C.5. Changes In -06 . . . . . . . . . . . . . . . . . . . . . . 52 131 C.6. Changes In -05 . . . . . . . . . . . . . . . . . . . . . . 53 132 C.7. Changes In -04 . . . . . . . . . . . . . . . . . . . . . . 54 133 C.8. Changes In -03 . . . . . . . . . . . . . . . . . . . . . . 54 134 C.9. Changes In -02 . . . . . . . . . . . . . . . . . . . . . . 54 135 C.10. Changes In -01 . . . . . . . . . . . . . . . . . . . . . . 55 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 138 1. Introduction 140 This document contains the rules for encoding IPP operations and 141 describes two layers: the transport layer and the operation layer. 143 The transport layer consists of an HTTP request and response. All 144 IPP implementations support HTTP/1.1, the relevant parts of which are 145 described in the following RFCs: 147 o Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing 148 [RFC7230] 150 o Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content 151 [RFC7231] 153 o Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests 154 [RFC7232] 156 o Hypertext Transfer Protocol (HTTP/1.1): Caching [RFC7234] 158 o Hypertext Transfer Protocol (HTTP/1.1): Authentication [RFC7235] 160 o The 'Basic' HTTP Authentication Scheme [RFC7617] 162 o HTTP Digest Access Authentication [RFC7616] 164 IPP implementations can support HTTP/2 which is described in the 165 following RFCs: 167 o Hypertext Transfer Protocol Version 2 (HTTP/2) [RFC7540] 169 o HPACK - Header Compression for HTTP/2 [RFC7541] 171 This document specifies the HTTP headers that an IPP implementation 172 supports. 174 The operation layer consists of a message body in an HTTP request or 175 response. The "Internet Printing Protocol/1.1: Model and Semantics" 176 [RFC2911bis] and subsequent extensions (collectively known as the IPP 177 Model) define the semantics of such a message body and the supported 178 values. This document specifies the encoding of an IPP request and 179 response message. 181 2. Conventions Used in This Document 183 2.1. Requirements Language 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [RFC2119]. 189 2.2. Printing Terminology 191 Client: Initiator of outgoing IPP session requests and sender of 192 outgoing IPP operation requests (Hypertext Transfer Protocol -- 193 HTTP/1.1 [RFC7230] User Agent). 195 Document: An object created and managed by a Printer that contains 196 description, processing, and status information. A Document object 197 may have attached data and is bound to a single Job. 199 'ipp' URI: An IPP URI as defined in [RFC3510]. 201 'ipps' URI: An IPPS URI as defined in [RFC7472]. 203 Job: An object created and managed by a Printer that contains 204 description, processing, and status information. The Job also 205 contains zero or more Document objects. 207 Logical Device: A print server, software service, or gateway that 208 processes Jobs and either forwards or stores the processed Job or 209 uses one or more Physical Devices to render output. 211 Model: The semantics of operations, attributes, values, and status 212 codes used in the Internet Printing Protocol as defined in the 213 Internet Printing Protocol/1.1: Model and Semantics [RFC2911bis] and 214 subsequent extensions. 216 Output Device: A single Logical or Physical Device. 218 Physical Device: A hardware implementation of an endpoint device, 219 e.g., a marking engine, a fax modem, etc. 221 Printer: Listener for incoming IPP session requests and receiver of 222 incoming IPP operation requests (Hypertext Transfer Protocol -- 223 HTTP/1.1 [RFC7230] Server) that represents one or more Physical 224 Devices or a Logical Device. 226 2.3. Abbreviations 228 ABNF: Augmented Backus-Naur Form [RFC5234] 230 ASCII: American Standard Code for Information Interchange [RFC20] 232 HTTP: HyperText Transfer Protocol [RFC7230] 234 HTTPS: HTTP over TLS [RFC2818] 236 IANA: Internet Assigned Numbers Authority 237 IEEE: Institute of Electrical and Electronics Engineers 239 IESG: Internet Engineering Steering Group 241 IPP: Internet Printing Protocol (this document and [PWG5100.12]) 243 ISTO: IEEE Industry Standards and Technology Organization 245 LPD: Line Printer Daemon Protocol [RFC1179] 247 PWG: IEEE-ISTO Printer Working Group 249 RFC: Request for Comments 251 TCP: Transmission Control Protocol [RFC793] 253 TLS: Transport Layer Security [RFC5246] 255 URI: Uniform Resource Identifier [RFC3986] 257 URL: Uniform Resource Locator [RFC3986] 259 UTF-8: Unicode Transformation Format - 8-bit [RFC3629] 261 3. Encoding of the Operation Layer 263 The operation layer is the message body part of the HTTP request or 264 response and it MUST contain a single IPP operation request or IPP 265 operation response. Each request or response consists of a sequence 266 of values and attribute groups. Attribute groups consist of a 267 sequence of attributes each of which is a name and value. Names and 268 values are ultimately sequences of octets. 270 The encoding consists of octets as the most primitive type. There 271 are several types built from octets, but three important types are 272 integers, character strings and octet strings, on which most other 273 data types are built. Every character string in this encoding MUST 274 be a sequence of characters where the characters are associated with 275 some charset [RFC2978] and some natural language. A character string 276 MUST be in "reading order" with the first character in the value 277 (according to reading order) being the first character in the 278 encoding. A character string whose associated charset is US-ASCII 279 whose associated natural language is US English is henceforth called 280 a US-ASCII-STRING. A character string whose associated charset and 281 natural language are specified in a request or response as described 282 in the Model is henceforth called a LOCALIZED-STRING. An octet 283 string MUST be in "Model order" with the first octet in the value 284 (according to the Model order) being the first octet in the encoding. 286 Every integer in this encoding MUST be encoded as a signed integer 287 using two's-complement binary encoding with big-endian format (also 288 known as "network order" and "most significant byte first"). The 289 number of octets for an integer MUST be 1, 2 or 4, depending on usage 290 in the protocol. Such one-octet integers, henceforth called SIGNED- 291 BYTE, are used for the version-number and tag fields. Such two-byte 292 integers, henceforth called SIGNED-SHORT are used for the operation- 293 id, status-code and length fields. Four byte integers, henceforth 294 called SIGNED-INTEGER, are used for value fields and the request-id. 296 The following two sections present the encoding of the operation 297 layer in two ways: 299 o informally through pictures and description 301 o formally through Augmented Backus-Naur Form (ABNF), as specified 302 by RFC 5234 [RFC5234] 304 An operation request or response MUST use the encoding described in 305 these two sections. 307 3.1. Picture of the Encoding 309 3.1.1. Request and Response 311 An operation request or response is encoded as follows: 313 ----------------------------------------------- 314 | version-number | 2 bytes - required 315 ----------------------------------------------- 316 | operation-id (request) | 317 | or | 2 bytes - required 318 | status-code (response) | 319 ----------------------------------------------- 320 | request-id | 4 bytes - required 321 ----------------------------------------------- 322 | attribute-group | n bytes - 0 or more 323 ----------------------------------------------- 324 | end-of-attributes-tag | 1 byte - required 325 ----------------------------------------------- 326 | data | q bytes - optional 327 ----------------------------------------------- 329 Figure 1: IPP Message Format 331 The first three fields in the above diagram contain the value of 332 attributes described in Section 4.1.1 of the Model [RFC2911bis]. 334 The fourth field is the "attribute-group" field, and it occurs 0 or 335 more times. Each "attribute-group" field represents a single group 336 of attributes, such as an Operation Attributes group or a Job 337 Attributes group (see the Model). The Model specifies the required 338 attribute groups and their order for each operation request and 339 response. 341 The "end-of-attributes-tag" field is always present, even when the 342 "data" is not present. The Model specifies whether the "data" field 343 is present for each operation request and response. 345 3.1.2. Attribute Group 347 Each "attribute-group" field is encoded as follows: 349 ----------------------------------------------- 350 | begin-attribute-group-tag | 1 byte 351 ---------------------------------------------------------- 352 | attribute | p bytes |- 0 or more 353 ---------------------------------------------------------- 355 Figure 2: Attribute Group Encoding 357 An "attribute-group" field contains zero or more "attribute" fields. 359 Note, the values of the "begin-attribute-group-tag" field and the 360 "end-of-attributes-tag" field are called "delimiter-tags". 362 3.1.3. Attribute 364 An "attribute" field is encoded as follows: 366 ----------------------------------------------- 367 | attribute-with-one-value | q bytes 368 ---------------------------------------------------------- 369 | additional-value | r bytes |- 0 or more 370 ---------------------------------------------------------- 372 Figure 3: Attribute Encoding 374 When an attribute is single valued (e.g. "copies" with value of 10) 375 or multi-valued with one value (e.g. "sides-supported" with just the 376 value 'one-sided') it is encoded with just an "attribute-with-one- 377 value" field. When an attribute is multi-valued with n values (e.g. 378 "sides-supported" with the values 'one-sided' and 'two-sided-long- 379 edge'), it is encoded with an "attribute-with-one-value" field 380 followed by n-1 "additional-value" fields. 382 3.1.4. Attribute-with-one-value 384 Each "attribute-with-one-value" field is encoded as follows: 386 ----------------------------------------------- 387 | value-tag | 1 byte 388 ----------------------------------------------- 389 | name-length (value is u) | 2 bytes 390 ----------------------------------------------- 391 | name | u bytes 392 ----------------------------------------------- 393 | value-length (value is v) | 2 bytes 394 ----------------------------------------------- 395 | value | v bytes 396 ----------------------------------------------- 398 Figure 4: Single Value Attribute Encoding 400 An "attribute-with-one-value" field is encoded with five subfields: 402 o The "value-tag" field specifies the attribute syntax, e.g. 0x44 403 for the attribute syntax 'keyword'. 405 o The "name-length" field specifies the length of the "name" field 406 in bytes, e.g. u in the above diagram or 15 for the name "sides- 407 supported". 409 o The "name" field contains the textual name of the attribute, e.g. 410 "sides-supported". 412 o The "value-length" field specifies the length of the "value" field 413 in bytes, e.g. v in the above diagram or 9 for the (keyword) value 414 'one-sided'. 416 o The "value" field contains the value of the attribute, e.g. the 417 textual value 'one-sided'. 419 3.1.5. Additional-value 421 Each "additional-value" field is encoded as follows: 423 ----------------------------------------------- 424 | value-tag | 1 byte 425 ----------------------------------------------- 426 | name-length (value is 0x0000) | 2 bytes 427 ----------------------------------------------- 428 | value-length (value is w) | 2 bytes 429 ----------------------------------------------- 430 | value | w bytes 431 ----------------------------------------------- 433 Figure 5: Additional Attribute Value Encoding 435 An "additional-value" is encoded with four subfields: 437 o The "value-tag" field specifies the attribute syntax, e.g. 0x44 438 for the attribute syntax 'keyword'. 440 o The "name-length" field has the value of 0 in order to signify 441 that it is an "additional-value". The value of the "name-length" 442 field distinguishes an "additional-value" field ("name-length" is 443 0) from an "attribute-with-one-value" field ("name-length" is not 444 0). 446 o The "value-length" field specifies the length of the "value" field 447 in bytes, e.g. w in the above diagram or 19 for the (keyword) 448 value 'two-sided-long-edge'. 450 o The "value" field contains the value of the attribute, e.g. the 451 textual value 'two-sided-long-edge'. 453 3.1.6. Collection Attribute 455 Collection attributes create a named group containing related 456 "member" attributes. The "attribute-with-one-value" field for a 457 collection attribute is encoded as follows: 459 ----------------------------------------------- 460 | value-tag (value is 0x34) | 1 byte 461 ----------------------------------------------- 462 | name-length (value is u) | 2 bytes 463 ----------------------------------------------- 464 | name | u bytes 465 ----------------------------------------------- 466 | value-length (value is 0x0000) | 2 bytes 467 ----------------------------------------------------------- 468 | member-attribute | q bytes |-0 or more 469 ----------------------------------------------------------- 470 | end-value-tag (value is 0x37) | 1 byte 471 ----------------------------------------------- 472 | end-name-length (value is 0x0000) | 2 bytes 473 ----------------------------------------------- 474 | end-value-length (value is 0x0000) | 2 bytes 475 ----------------------------------------------- 477 Figure 6: Collection Attribute Encoding 479 Collection attribute is encoded with eight subfields: 481 o The "value-tag" field specifies the start attribute syntax: 0x34 482 for the attribute syntax 'begCollection'. 484 o The "name-length" field specifies the length of the "name" field 485 in bytes, e.g. u in the above diagram or 9 for the name "media- 486 col". Additional collection attribute values use a name length of 487 0x0000. 489 o The "name" field contains the textual name of the attribute, e.g. 490 "media-col". 492 o The "value-length" field specifies a length of 0x0000. 494 o The "member-attribute" field contains member attributes encoded as 495 defined in Section 3.1.7. 497 o The "end-value-tag" field specifies the end attribute syntax: 0x37 498 for the attribute syntax 'endCollection'. 500 o The "end-name-length" field specifies a length of 0x0000. 502 o The "end-value-length" field specifies a length of 0x0000. 504 3.1.7. Member Attributes 506 Each "member-attribute" field is encoded as follows: 508 ----------------------------------------------- 509 | value-tag (value is 0x4A) | 1 byte 510 ----------------------------------------------- 511 | name-length (value is 0x0000) | 2 bytes 512 ----------------------------------------------- 513 | value-length (value is w) | 2 bytes 514 ----------------------------------------------- 515 | value (member-name) | w bytes 516 ----------------------------------------------- 517 | member-value-tag | 1 byte 518 ----------------------------------------------- 519 | name-length (value is 0x0000) | 2 bytes 520 ----------------------------------------------- 521 | member-value-length (value is x) | 2 bytes 522 ----------------------------------------------- 523 | member-value | x bytes 524 ----------------------------------------------- 526 Figure 7: Member Attribute Encoding 528 A "member-attribute" is encoded with eight subfields: 530 o The "value-tag" field specifies 0x4A for the attribute syntax 531 'memberAttrName'. 533 o The "name-length" field has the value of 0 in order to signify 534 that it is a "member-attribute" contained in the collection. 536 o The "value-length" field specifies the length of the "value" field 537 in bytes, e.g. w in the above diagram or 10 for the member 538 attribute name 'media-type'. Additional member attribute values 539 are specifies using a value length of 0. 541 o The "value" field contains the name of the member attribute, e.g. 542 the textual value 'media-type'. 544 o The "member-value-tag" field specifies the attribute syntax for 545 the member attribute, e.g. 0x44 for the attribute syntax 546 'keyword'. 548 o The second "name-length" field has the value of 0 in order to 549 signify that it is a "member-attribute" contained in the 550 collection. 552 o The "member-value-length" field specifies the length of the member 553 attribute value, e.g. x in the above diagram or 10 for the value 554 'stationery'. 556 o The "member-value" field contains the value of the attribute, e.g. 557 the textual value 'stationery'. 559 3.1.8. Alternative Picture of the Encoding of a Request Or a Response 561 From the standpoint of a parser that performs an action based on a 562 "tag" value, the encoding consists of: 564 ----------------------------------------------- 565 | version-number | 2 bytes - required 566 ----------------------------------------------- 567 | operation-id (request) | 568 | or | 2 bytes - required 569 | status-code (response) | 570 ----------------------------------------------- 571 | request-id | 4 bytes - required 572 ----------------------------------------------------------- 573 | tag (delimiter-tag or value-tag) | 1 byte | 574 ----------------------------------------------- |-0 or more 575 | empty or rest of attribute | x bytes | 576 ----------------------------------------------------------- 577 | end-of-attributes-tag | 1 byte - required 578 ----------------------------------------------- 579 | data | y bytes - optional 580 ----------------------------------------------- 582 Figure 8: Encoding Based On Value Tags 584 The following show what fields the parser would expect after each 585 type of "tag": 587 o "begin-attribute-group-tag": expect zero or more "attribute" 588 fields 590 o "value-tag": expect the remainder of an "attribute-with-one-value" 591 or an "additional-value". 593 o "end-of-attributes-tag": expect that "attribute" fields are 594 complete and there is optional "data" 596 3.2. Syntax of Encoding 598 The ABNF [RFC5234] syntax for an IPP message is shown in Figure 9. 600 ipp-message = ipp-request / ipp-response 601 ipp-request = version-number operation-id request-id 602 *attribute-group end-of-attributes-tag data 603 ipp-response = version-number status-code request-id 604 *attribute-group end-of-attributes-tag data 606 version-number = major-version-number minor-version-number 607 major-version-number = SIGNED-BYTE 608 minor-version-number = SIGNED-BYTE 610 operation-id = SIGNED-SHORT ; mapping from model 611 status-code = SIGNED-SHORT ; mapping from model 612 request-id = SIGNED-INTEGER ; whose value is > 0 614 attribute-group = begin-attribute-group-tag *attribute 615 attribute = attribute-with-one-value *additional-value 616 attribute-with-one-value = value-tag name-length name 617 value-length value 618 additional-value = value-tag zero-name-length 619 value-length value 621 name-length = SIGNED-SHORT ; number of octets of 'name' 622 name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." ) 623 value-length = SIGNED-SHORT ; number of octets of 'value' 624 value = OCTET-STRING 625 data = OCTET-STRING 627 zero-name-length = %x00.00 ; name-length of 0 628 value-tag = %x10-FF ; see section 3.5.2 629 begin-attribute-group-tag = %x00-02 / %x04-0F ; see section 3.5.1 630 end-of-attributes-tag = %x03 ; tag of 3 631 ; see section 3.5.1 633 SIGNED-BYTE = BYTE 634 SIGNED-SHORT = 2BYTE 635 SIGNED-INTEGER = 4BYTE 636 DIGIT = %x30-39 ; "0" to "9" 637 LALPHA = %x61-7A ; "a" to "z" 638 BYTE = %x00-FF 639 OCTET-STRING = *BYTE 641 Figure 9: ABNF of IPP Message Format 643 Figure 10 defines additional terms that are referenced in this 644 document and provides an alternate grouping of the delimiter tags. 646 delimiter-tag = begin-attribute-group-tag / ; see section 3.5.1 647 end-of-attributes-tag 648 begin-attribute-group-tag = %x00 / operation-attributes-tag / 649 job-attributes-tag / printer-attributes-tag / 650 unsupported-attributes-tag / future-group-tags 651 operation-attributes-tag = %x01 ; tag of 1 652 job-attributes-tag = %x02 ; tag of 2 653 end-of-attributes-tag = %x03 ; tag of 3 654 printer-attributes-tag = %x04 ; tag of 4 655 unsupported-attributes-tag = %x05 ; tag of 5 656 future-group-tags = %x06-0F ; future extensions 658 Figure 10: ABNF for Attribute Group Tags 660 3.3. Attribute-group 662 Each "attribute-group" field MUST be encoded with the "begin- 663 attribute-group-tag" field followed by zero or more "attribute" sub- 664 fields. 666 Table 1 maps the Model group name to value of the "begin-attribute- 667 group-tag" field: 669 +----------------+--------------------------------------------------+ 670 | Model Document | "begin-attribute-group-tag" field values | 671 | Group | | 672 +----------------+--------------------------------------------------+ 673 | Operation | "operations-attributes-tag" | 674 | Attributes | | 675 +----------------+--------------------------------------------------+ 676 | Job Template | "job-attributes-tag" | 677 | Attributes | | 678 +----------------+--------------------------------------------------+ 679 | Job Object | "job-attributes-tag" | 680 | Attributes | | 681 +----------------+--------------------------------------------------+ 682 | Unsupported | "unsupported-attributes-tag" | 683 | Attributes | | 684 +----------------+--------------------------------------------------+ 685 | Requested | (Get-Job-Attributes) "job-attributes-tag" | 686 | Attributes | | 687 +----------------+--------------------------------------------------+ 688 | Requested | (Get-Printer-Attributes)"printer-attributes-tag" | 689 | Attributes | | 690 +----------------+--------------------------------------------------+ 691 | Document | in a special position at the end of the message | 692 | Content | as described in Section 3.1.1. | 693 +----------------+--------------------------------------------------+ 695 Table 1: Group Values 697 For each operation request and response, the Model prescribes the 698 required and optional attribute groups, along with their order. 699 Within each attribute group, the Model prescribes the required and 700 optional attributes, along with their order. 702 When the Model requires an attribute group in a request or response 703 and the attribute group contains zero attributes, a request or 704 response SHOULD encode the attribute group with the "begin-attribute- 705 group-tag" field followed by zero "attribute" fields. For example, 706 if the Client requests a single unsupported attribute with the Get- 707 Printer-Attributes operation, the Printer MUST return no "attribute" 708 fields, and it SHOULD return a "begin-attribute-group-tag" field for 709 the Printer Attributes Group. The Unsupported Attributes group is 710 not such an example. According to the Model, the Unsupported 711 Attributes Group SHOULD be present only if the unsupported attributes 712 group contains at least one attribute. 714 A receiver of a request MUST be able to process the following as 715 equivalent empty attribute groups: 717 a. A "begin-attribute-group-tag" field with zero following 718 "attribute" fields. 720 b. An expected but missing "begin-attribute-group-tag" field. 722 When the Model requires a sequence of an unknown number of attribute 723 groups, each of the same type, the encoding MUST contain one "begin- 724 attribute-group-tag" field for each attribute group even when an 725 "attribute-group" field contains zero "attribute" sub-fields. For 726 example, the Get-Jobs operation may return zero attributes for some 727 jobs and not others. The "begin-attribute-group-tag" field followed 728 by zero "attribute" fields tells the recipient that there is a Job in 729 queue for which no information is available except that it is in the 730 queue. 732 3.4. Required Parameters 734 Some operation elements are called parameters in the Model. They 735 MUST be encoded in a special position and they MUST NOT appear as 736 operation attributes. These parameters are described in the 737 subsections below. 739 3.4.1. Version-number 741 The "version-number" field consists of a major and minor version- 742 number, each of which is represented by a SIGNED-BYTE. The major 743 version-number is the first byte of the encoding and the minor 744 version-number is the second byte of the encoding. The protocol 745 described in [RFC2911bis] has a major version-number of 1 (0x01) and 746 a minor version-number of 1 (0x01). The ABNF for these two bytes is 747 %x01.01. 749 Note: See Section 9 for more information on the "version-number" 750 field and IPP version numbers. 752 3.4.2. Operation-id 754 The "operation-id" field contains an operation-id value as defined in 755 the Model. The value is encoded as a SIGNED-SHORT and is located in 756 the third and fourth bytes of the encoding of an operation request. 758 3.4.3. Status-code 760 The "status-code" field contains a status-code value as defined in 761 the Model. The value is encoded as a SIGNED-SHORT and is located in 762 the third and fourth bytes of the encoding of an operation response. 764 If an IPP status-code is returned, then the HTTP status-code MUST be 765 200 (OK). With any other HTTP status-code value, the HTTP response 766 MUST NOT contain an IPP message body, and thus no IPP status-code is 767 returned. 769 3.4.4. Request-id 771 The "request-id" field contains the request-id value as defined in 772 the Model. The value is encoded as a SIGNED-INTEGER and is located 773 in the fifth through eighth bytes of the encoding. 775 3.5. Tags 777 There are two kinds of tags: 779 o delimiter tags: delimit major sections of the protocol, namely 780 attributes and data 782 o value tags: specify the type of each attribute value 784 Tags are part of the IANA IPP registry [IANA-IPP] 786 3.5.1. Delimiter Tags 788 Table 2 specifies the values for the delimiter tags defined in this 789 document: 791 +---------------+---------------------------------------------------+ 792 | Tag Value | Meaning | 793 | (Hex) | | 794 +---------------+---------------------------------------------------+ 795 | 0x00 | reserved for future delimiters in standards track | 796 | | documents | 797 | 0x01 | "operation-attributes-tag" | 798 | 0x02 | "job-attributes-tag" | 799 | 0x03 | "end-of-attributes-tag" | 800 | 0x04 | "printer-attributes-tag" | 801 | 0x05 | "unsupported-attributes-tag" | 802 | 0x06-0x0f | reserved for future delimiters in standards track | 803 | | documents | 804 +---------------+---------------------------------------------------+ 806 Table 2: Delimiter Tags 808 When a "begin-attribute-group-tag" field occurs in the protocol, it 809 means that zero or more following attributes up to the next delimiter 810 tag are attributes belonging to the attribute group specified by the 811 value of the "begin-attribute-group-tag". For example, if the value 812 of "begin-attribute-group-tag" is 0x01, the following attributes are 813 members of the Operations Attributes group. 815 The "end-of-attributes-tag" (value 0x03) MUST occur exactly once in 816 an operation and MUST be the last "delimiter-tag". If the operation 817 has a document-data group, the Document data in that group follows 818 the "end-of-attributes-tag". 820 The order and presence of "attribute-group" fields (whose beginning 821 is marked by the "begin-attribute-group-tag" subfield) for each 822 operation request and each operation response MUST be that defined in 823 the Model. 825 A Printer MUST treat a "delimiter-tag" (values from 0x00 through 826 0x0F) differently from a "value-tag" (values from 0x10 through 0xFF) 827 so that the Printer knows there is an entire attribute group as 828 opposed to a single value. 830 3.5.2. Value Tags 832 The remaining tables show values for the "value-tag" field, which is 833 the first octet of an attribute. The "value-tag" field specifies the 834 type of the value of the attribute. 836 Table 3 specifies the "out-of-band" values for the "value-tag" field 837 defined in this document: 839 +------------+------------------------------------------------------+ 840 | Tag Value | Meaning | 841 | (Hex) | | 842 +------------+------------------------------------------------------+ 843 | 0x10 | unsupported | 844 | 0x11 | reserved for "out-of-band" value definitions in | 845 | | future standards track documents | 846 | 0x12 | unknown | 847 | 0x13 | no-value | 848 | 0x14-0x1F | reserved for "out-of-band" value definitions in | 849 | | future standards track documents | 850 +------------+------------------------------------------------------+ 852 Table 3: Out of Band Values 854 Table 4 specifies the integer values for the "value-tag" field: 856 +-------------+-----------------------------------------------------+ 857 | Tag Value | Meaning | 858 | (Hex) | | 859 +-------------+-----------------------------------------------------+ 860 | 0x20 | reserved for integer type definitions in future | 861 | | standards track documents | 862 | 0x21 | integer | 863 | 0x22 | boolean | 864 | 0x23 | enum | 865 | 0x24-0x2F | reserved for integer type definitions in future | 866 | | standards track documents | 867 +-------------+-----------------------------------------------------+ 869 Table 4: Integer Tags 871 Table 5 specifies the octetString values for the "value-tag" field 872 defined in this document: 874 +-------------+-----------------------------------------------------+ 875 | Tag Value | Meaning | 876 | (Hex) | | 877 +-------------+-----------------------------------------------------+ 878 | 0x30 | octetString with an unspecified format | 879 | 0x31 | dateTime | 880 | 0x32 | resolution | 881 | 0x33 | rangeOfInteger | 882 | 0x34 | begCollection | 883 | 0x35 | textWithLanguage | 884 | 0x36 | nameWithLanguage | 885 | 0x37 | endCollection | 886 | 0x38-0x3F | reserved for octetString type definitions in future | 887 | | standards track documents | 888 +-------------+-----------------------------------------------------+ 890 Table 5: octetString Tags 892 Table 6 specifies the character-string values for the "value-tag" 893 field defined in this document: 895 +------------+------------------------------------------------------+ 896 | Tag Value | Meaning | 897 | (Hex) | | 898 +------------+------------------------------------------------------+ 899 | 0x40 | reserved for definition in a future standards track | 900 | | document | 901 | 0x41 | textWithoutLanguage | 902 | 0x42 | nameWithoutLanguage | 903 | 0x43 | reserved for definition in a future standards track | 904 | | document | 905 | 0x44 | keyword | 906 | 0x45 | uri | 907 | 0x46 | uriScheme | 908 | 0x47 | charset | 909 | 0x48 | naturalLanguage | 910 | 0x49 | mimeMediaType | 911 | 0x4A | memberAttrName | 912 | 0x4B-0x5F | reserved for character string type definitions in | 913 | | future standards track documents | 914 +------------+------------------------------------------------------+ 916 Table 6: String Tags 918 Note: An attribute value always has a type, which is explicitly 919 specified by its tag; one such tag value is "nameWithoutLanguage". 920 An attribute's name has an implicit type, which is keyword. 922 The values 0x60-0xFF are reserved for future type definitions in 923 standards track documents. 925 The tag 0x7F is reserved for extending types beyond the 255 values 926 available with a single byte. A tag value of 0x7F MUST signify that 927 the first 4 bytes of the value field are interpreted as the tag 928 value. Note this future extension doesn't affect parsers that are 929 unaware of this special tag. The tag is like any other unknown tag, 930 and the value length specifies the length of a value, which contains 931 a value that the parser treats atomically. Values from 0x00000000 to 932 0x3FFFFFFF are reserved for definition in future standards track 933 documents. The values 0x40000000 to 0x7FFFFFFF are reserved for 934 vendor extensions. 936 3.6. Name-Length 938 The "name-length" field consists of a SIGNED-SHORT and specifies the 939 number of octets in the immediately following "name" field. The 940 value of this field excludes the two bytes of the "name-length" 941 field. For example, if the "name" field contains 'sides', the value 942 of this field is 5. 944 If a "name-length" field has a value of zero, the following "name" 945 field is empty and the following value is treated as an additional 946 value for the attribute encoded in the nearest preceding "attribute- 947 with-one-value" field. Within an attribute group, if two or more 948 attributes have the same name, the attribute group is malformed (see 949 [RFC2911bis]). The zero-length name is the only mechanism for multi- 950 valued attributes. 952 3.7. (Attribute) Name 954 The "name" field contains the name of an attribute. The Model 955 specifies such names. 957 3.8. Value Length 959 The "value-length" field consists of a SIGNED-SHORT which specifies 960 the number of octets in the immediately following "value" field. The 961 value of this field excludes the two bytes of the "value-length" 962 field. For example, if the "value" field contains the keyword 963 (string) value 'one-sided', the value of this field is 9. 965 For any of the types represented by binary signed integers, the 966 sender MUST encode the value in exactly four octets. 968 For any of the types represented by binary signed bytes, e.g., the 969 boolean type, the sender MUST encode the value in exactly one octet. 971 For any of the types represented by character-strings, the sender 972 MUST encode the value with all the characters of the string and 973 without any padding characters. 975 For "out-of-band" "value-tag" fields defined in this document, such 976 as 'unsupported', the "value-length" MUST be 0 and the "value" empty; 977 the "value" has no meaning when the "value-tag" has one of these 978 "out-of-band" values. For future "out-of-band" "value-tag" fields, 979 the same rule holds unless the definition explicitly states that the 980 "value-length" MAY be non-zero and the "value" non-empty 982 3.9. (Attribute) Value 984 The syntax types (specified by the "value-tag" field) and most of the 985 details of the representation of attribute values are defined in the 986 Model. Table 7 augments the information in the Model and defines the 987 syntax types from the Model in terms of the 5 basic types defined in 988 Section 3. The 5 types are US-ASCII-STRING, LOCALIZED-STRING, 989 SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET-STRING. 991 +----------------------+--------------------------------------------+ 992 | Syntax of Attribute | Encoding | 993 | Value | | 994 +----------------------+--------------------------------------------+ 995 | textWithoutLanguage, | LOCALIZED-STRING | 996 | nameWithoutLanguage | | 997 +----------------------+--------------------------------------------+ 998 | textWithLanguage | OCTET-STRING consisting of 4 fields: a | 999 | | SIGNED-SHORT which is the number of octets | 1000 | | in the following field, a value of type | 1001 | | natural-language, a SIGNED-SHORT which is | 1002 | | the number of octets in the following | 1003 | | field, and a value of type | 1004 | | textWithoutLanguage. The length of a | 1005 | | textWithLanguage value MUST be 4 + the | 1006 | | value of field a + the value of field c. | 1007 +----------------------+--------------------------------------------+ 1008 | nameWithLanguage | OCTET-STRING consisting of 4 fields: a | 1009 | | SIGNED-SHORT which is the number of octets | 1010 | | in the following field, a value of type | 1011 | | natural-language, a SIGNED-SHORT which is | 1012 | | the number of octets in the following | 1013 | | field, and a value of type | 1014 | | nameWithoutLanguage. The length of a | 1015 | | nameWithLanguage value MUST be 4 + the | 1016 | | value of field a + the value of field c. | 1017 +----------------------+--------------------------------------------+ 1018 | charset, | US-ASCII-STRING | 1019 | naturalLanguage, | | 1020 | mimeMediaType, | | 1021 | keyword, uri, and | | 1022 | uriScheme | | 1023 +----------------------+--------------------------------------------+ 1024 | boolean | SIGNED-BYTE where 0x00 is 'false' and 0x01 | 1025 | | is 'true' | 1026 +----------------------+--------------------------------------------+ 1027 | integer and enum | a SIGNED-INTEGER | 1028 +----------------------+--------------------------------------------+ 1029 | dateTime | OCTET-STRING consisting of eleven octets | 1030 | | whose contents are defined by | 1031 | | "DateAndTime" in RFC 2579 [RFC2579] | 1032 +----------------------+--------------------------------------------+ 1033 | resolution | OCTET-STRING consisting of nine octets of | 1034 | | 2 SIGNED-INTEGERs followed by a SIGNED- | 1035 | | BYTE. The first SIGNED-INTEGER contains | 1036 | | the value of cross feed direction | 1037 | | resolution. The second SIGNED-INTEGER | 1038 | | contains the value of feed direction | 1039 | | resolution. The SIGNED-BYTE contains the | 1040 | | units value. | 1041 +----------------------+--------------------------------------------+ 1042 | rangeOfInteger | Eight octets consisting of 2 SIGNED- | 1043 | | INTEGERs. The first SIGNED-INTEGER | 1044 | | contains the lower bound and the second | 1045 | | SIGNED-INTEGER contains the upper bound. | 1046 +----------------------+--------------------------------------------+ 1047 | 1setOf X | Encoding according to the rules for an | 1048 | | attribute with more than 1 value. Each | 1049 | | value X is encoded according to the rules | 1050 | | for encoding its type. | 1051 +----------------------+--------------------------------------------+ 1052 | octetString | OCTET-STRING | 1053 +----------------------+--------------------------------------------+ 1054 | collection | Encoding as defined in Section 3.1.6. | 1055 +----------------------+--------------------------------------------+ 1057 Table 7: Attribute Value Encoding 1059 The attribute syntax type of the value determines its encoding and 1060 the value of its "value-tag". 1062 3.10. Data 1064 The "data" field MUST include any data required by the operation. 1066 4. Encoding of Transport Layer 1068 HTTP/1.1 [RFC7230] is the REQUIRED transport layer for this protocol. 1069 HTTP/2 [RFC7540] is an OPTIONAL transport layer for this protocol. 1071 The operation layer has been designed with the assumption that the 1072 transport layer contains the following information: 1074 o the target URI for the operation 1076 o the total length of the data in the operation layer, either as a 1077 single length or as a sequence of chunks each with a length. 1079 Printer implementations MUST support HTTP over the IANA assigned Well 1080 Known Port 631 (the IPP default port), although a Printer 1081 implementation can support HTTP over some other port as well. 1083 Each HTTP operation MUST use the POST method where the request-URI is 1084 the object target of the operation, and where the "Content-Type" of 1085 the message body in each request and response MUST be "application/ 1086 ipp". The message body MUST contain the operation layer and MUST 1087 have the syntax described in Section 3.2 "Syntax of Encoding". A 1088 Client implementation MUST adhere to the rules for a Client described 1089 for HTTP [RFC7230]. A Printer (server) implementation MUST adhere 1090 the rules for an origin server described for HTTP [RFC7230]. 1092 An IPP server sends a response for each request that it receives. If 1093 an IPP server detects an error, it MAY send a response before it has 1094 read the entire request. If the HTTP layer of the IPP server 1095 completes processing the HTTP headers successfully, it MAY send an 1096 intermediate response, such as "100 Continue", with no IPP data 1097 before sending the IPP response. A Client MUST expect such a variety 1098 of responses from an IPP server. For further information on HTTP, 1099 consult the HTTP documents [RFC7230]. 1101 An HTTP/1.1 server MUST support chunking for IPP requests, and an IPP 1102 Client MUST support chunking for IPP responses according to HTTP/1.1 1103 [RFC7230]. 1105 4.1. Printer URI, Job URI, and Job ID 1107 All Printer and Job objects are identified by a Uniform Resource 1108 Identifier (URI) [RFC3986] so that they can be persistently and 1109 unambiguously referenced. Jobs can also be identified by a 1110 combination of Printer URI and Job ID. 1112 Some operation elements are encoded twice, once as the request-URI on 1113 the HTTP Request-Line and a second time as a REQUIRED operation 1114 attribute in the application/ipp entity. These attributes are the 1115 target for the operation and are called "printer-uri" and "job-uri". 1117 Note: The target URI is included twice in an operation referencing 1118 the same IPP object, but the two URIs can be different. For 1119 example, the HTTP request URI can be relative while the IPP 1120 request URI is absolute. 1122 HTTP allows Clients to generate and send a relative URI rather than 1123 an absolute URI. A relative URI identifies a resource with the scope 1124 of the HTTP server, but does not include scheme, host or port. The 1125 following statements characterize how URIs are used in the mapping of 1126 IPP onto HTTP: 1128 1. Although potentially redundant, a Client MUST supply the target 1129 of the operation both as an operation attribute and as a URI at 1130 the HTTP layer. The rationale for this decision is to maintain a 1131 consistent set of rules for mapping "application/ipp" to possibly 1132 many communication layers, even where URIs are not used as the 1133 addressing mechanism in the transport layer. 1135 2. Even though these two URIs might not be literally identical (one 1136 being relative and the other being absolute), they MUST both 1137 reference the same IPP object. 1139 3. The URI in the HTTP layer is either relative or absolute and is 1140 used by the HTTP server to route the HTTP request to the correct 1141 resource relative to that HTTP server. 1143 4. Once the HTTP server resource begins to process the HTTP request, 1144 it can get the reference to the appropriate IPP Printer object 1145 from either the HTTP URI (using to the context of the HTTP server 1146 for relative URIs) or from the URI within the operation request; 1147 the choice is up to the implementation. 1149 5. HTTP URIs can be relative or absolute, but the target URI in the 1150 IPP operation attribute MUST be an absolute URI. 1152 5. IPP URI Schemes 1154 The IPP URI schemes are 'ipp' [RFC3510] and 'ipps' [RFC7472]. 1155 Clients and Printers MUST support the ipp-URI value in the following 1156 IPP attributes: 1158 o Job attributes: 1160 * job-uri 1162 * job-printer-uri 1164 o Printer attributes: 1166 * printer-uri-supported 1168 o Operation attributes: 1170 * job-uri 1172 * printer-uri 1174 Each of the above attributes identifies a Printer or Job. The ipp-URI 1175 and ipps-URI are intended as the value of the attributes in this 1176 list. All of these attributes have a syntax type of 'uri', but there 1177 are attributes with a syntax type of 'uri' that do not use the 'ipp' 1178 scheme, e.g., "job-more-info". 1180 If a Printer registers its URI with a directory service, the Printer 1181 MUST register an ipp-URI or ipps-URI. 1183 When a Client sends a request, it MUST convert a target ipp-URI to a 1184 target http-URL (or ipps-URI to a target https-URI) for the HTTP 1185 layer according to the following steps: 1187 1. change the 'ipp' scheme to 'http' or 'ipps' scheme to 'https' 1189 2. add an explicit port 631 if the ipp-URL or ipps-URL does not 1190 contain an explicit port. Note: Port 631 is the IANA assigned 1191 Well Known Port for the 'ipp' and 'ipps' schemes. 1193 The Client MUST use the target http-URL or https-URL in both the HTTP 1194 Request-Line and HTTP headers, as specified by HTTP [RFC7230]. 1195 However, the Client MUST use the target ipp-URI or ipps-URI for the 1196 value of the "printer-uri" or "job-uri" operation attribute within 1197 the application/ipp body of the request. The server MUST use the 1198 ipp-URI or ipps-URI for the value of the "printer-uri", "job-uri" or 1199 "printer-uri-supported" attributes within the application/ipp body of 1200 the response. 1202 For example, when an IPP Client sends a request directly, i.e., no 1203 proxy, to an ipp-URI "ipp://printer.example.com/ipp/print/myqueue", 1204 it opens a TCP connection to port 631 (the IPP implicit port) on the 1205 host "printer.example.com" and sends the following data: 1207 POST /ipp/print/myqueue HTTP/1.1 1208 Host: printer.example.com:631 1209 Content-type: application/ipp 1210 Transfer-Encoding: chunked 1211 ... 1212 "printer-uri" 'ipp://printer.example.com/ipp/print/myqueue' 1213 (encoded in application/ipp message body) 1214 ... 1216 Figure 11: Direct IPP Request 1218 As another example, when an IPP Client sends the same request as 1219 above via a proxy "myproxy.example.com", it opens a TCP connection to 1220 the proxy port 8080 on the proxy host "myproxy.example.com" and sends 1221 the following data: 1223 POST http://printer.example.com:631/ipp/print/myqueue HTTP/1.1 1224 Host: printer.example.com:631 1225 Content-type: application/ipp 1226 Transfer-Encoding: chunked 1227 ... 1228 "printer-uri" 'ipp://printer.example.com/ipp/print/myqueue' 1229 (encoded in application/ipp message body) 1230 ... 1232 Figure 12: Proxied IPP Request 1234 The proxy then connects to the IPP origin server with headers that 1235 are the same as the "no-proxy" example above. 1237 6. IANA Considerations 1239 See the section on "IANA Considerations" in the document "Internet 1240 Printing Protocol/1.1: Model and Semantics" [RFC2911bis] for 1241 information on IANA considerations for IPP extensions. The 1242 information following this paragraph will be forwarded to IANA to 1243 update the existing 'application/ipp' MIME media type registration 1244 whose contents are defined in Section 3 "Encoding of the Operation 1245 Layer" in this document: 1247 Type name: application 1249 Subtype name: ipp 1251 Required parameters: N/A 1253 Optional parameters: N/A 1255 Encoding considerations: IPP protocol requests/responses MAY contain 1256 long lines and ALWAYS contain binary data (for example attribute 1257 value lengths). 1259 Security considerations: IPP protocol requests/responses do not 1260 introduce any security risks not already inherent in the underlying 1261 transport protocols. Protocol mixed-version interworking rules in 1262 [RFC2911bis] as well as protocol encoding rules in this document are 1263 complete and unambiguous. See also the security considerations in 1264 this document and [RFC2911bis]. 1266 Interoperability considerations: IPP requests (generated by clients) 1267 and responses (generated by servers) MUST comply with all conformance 1268 requirements imposed by the normative specifications [RFC2911bis] and 1269 this document. Protocol encoding rules specified in [RFC2910bis] are 1270 comprehensive, so that interoperability between conforming 1271 implementations is guaranteed (although support for specific optional 1272 features is not ensured). Both the "charset" and "natural-language" 1273 of all IPP attribute values which are a LOCALIZED-STRING are explicit 1274 within IPP protocol requests/responses (without recourse to any 1275 external information in HTTP, SMTP, or other message transport 1276 headers). 1278 Published specifications: 1280 [RFC2911bis] Sweet, M., McDonald, I., "Internet Printing 1281 Protocol/1.1: Model and Semantics" draft-sweet-rfc2911bis-10.txt, 1282 August 2016. 1284 [RFC2910bis] Sweet, M., McDonald, I., "Internet Printing 1285 Protocol/1.1: Encoding and Transport", draft-sweet-rfc2910bis- 1286 09.txt, August 2016. 1288 Applications which use this media type: Internet Printing Protocol 1289 (IPP) print clients and print servers, communicating using HTTP/HTTPS 1290 or other transport protocol. Messages of type "application/ipp" are 1291 self-contained and transport-independent, including "charset" and 1292 "natural-language" context for any LOCALIZED-STRING value. 1294 Fragment identifier considerations: N/A 1296 Additional information: 1298 Deprecated alias names for this type: N/A 1300 Magic number(s): 1302 File extension(s): 1304 Macintosh file type code(s): 1306 Person & email address to contact for further information: ISTO PWG 1307 IPP Workgroup 1309 Intended usage: COMMON 1311 Restrictions on usage: N/A 1313 Author: ISTO PWG IPP Workgroup 1315 Change controller: ISTO PWG IPP Workgroup 1317 Provisional registration? (standards tree only): No 1319 7. Internationalization Considerations 1321 See the section on "Internationalization Considerations" in the 1322 document "Internet Printing Protocol/1.1: Model and Semantics" 1323 [RFC2911bis] for information on internationalization. This document 1324 adds no additional issues. 1326 8. Security Considerations 1328 The IPP Model and Semantics document [RFC2911bis] discusses high 1329 level security requirements (Client Authentication, Server 1330 Authentication and Operation Privacy). Client Authentication is the 1331 mechanism by which the Client proves its identity to the server in a 1332 secure manner. Server Authentication is the mechanism by which the 1333 server proves its identity to the Client in a secure manner. 1334 Operation Privacy is defined as a mechanism for protecting operations 1335 from eavesdropping. 1337 Message Integrity is addressed in the Internet Printing Protocol 1338 (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme 1339 [RFC7472]. 1341 8.1. Security Conformance Requirements 1343 This section defines the security requirements for IPP Clients and 1344 IPP objects. 1346 8.1.1. Digest Authentication 1348 IPP Clients and Printers SHOULD support Digest Authentication 1349 [RFC7616]. Use of the Message Integrity feature (qop="auth-int") is 1350 OPTIONAL. 1352 Note: Previous versions of this document required support for the MD5 1353 algorithms, however [RFC7616] makes SHA2-256 mandatory to implement 1354 and deprecates MD5, allowing its use for backwards compatibility 1355 reasons. IPP implementations that support Digest Authentication MUST 1356 support SHA2-256 and SHOULD support MD5 for backwards-compatibility. 1358 Note: The reason that IPP Clients and Printers SHOULD (rather than 1359 MUST) support Digest Authentication is that there is a certain class 1360 of output devices where it does not make sense. Specifically, a low- 1361 end device with limited ROM space and low paper throughput may not 1362 need Client Authentication. This class of device typically requires 1363 firmware designers to make trade-offs between protocols and 1364 functionality to arrive at the lowest-cost solution possible. 1365 Factored into the designer's decisions is not just the size of the 1366 code, but also the testing, maintenance, usefulness, and time-to- 1367 market impact for each feature delivered to the customer. Forcing 1368 such low-end devices to provide security in order to claim IPP/1.1 1369 conformance would not make business sense. Print devices that have 1370 high-volume throughput and have available ROM space will typically 1371 provide support for Client Authentication that safeguards the device 1372 from unauthorized access because these devices are prone to a high 1373 loss of consumables and paper if unauthorized access occurs. 1375 8.1.2. Transport Layer Security (TLS) 1377 IPP Clients and Printers SHOULD support Transport Layer Security 1378 (TLS) [RFC5246] [RFC7525] for Server Authentication and Operation 1379 Privacy. IPP Printers MAY also support TLS for Client 1380 Authentication. IPP Clients and Printers MAY support Basic 1381 Authentication [RFC7617] for User Authentication if the channel is 1382 secure, e.g., IPP over HTTPS [RFC7472]. IPP Clients and Printers 1383 SHOULD NOT support Basic Authentication over insecure channels. 1385 The IPP Model and Semantics document [RFC2911bis] defines two Printer 1386 attributes ("uri-authentication-supported" and "uri-security- 1387 supported") that the Client can use to discover the security policy 1388 of a Printer. That document also outlines IPP-specific security 1389 considerations and is the primary reference for security implications 1390 with regard to the IPP protocol itself. 1392 Note: Because previous versions of this document did not require TLS 1393 support, this version cannot require it for IPP/1.1. However, since 1394 printing often involves a great deal of sensitive or private 1395 information (medical reports, performance reviews, banking 1396 information, etc.) and network monitoring is pervasive ([RFC7258]), 1397 implementors are strongly encouraged to include TLS support. 1399 Note: Because IPP Printers typically use self-signed X.509 1400 certificates, IPP Clients SHOULD support Trust On First Use (defined 1401 in [RFC7435]) in addition to traditional X.509 certificate 1402 validation. 1404 8.2. Using IPP with TLS 1406 IPP uses the "Upgrading to TLS Within HTTP/1.1" mechanism [RFC2817] 1407 for 'ipp' URIs. The Client requests a secure TLS connection by using 1408 the HTTP "Upgrade" header, while the server agrees in the HTTP 1409 response. The switch to TLS occurs either because the server grants 1410 the Client's request to upgrade to TLS, or a server asks to switch to 1411 TLS in its response. Secure communication begins with a server's 1412 response to switch to TLS. 1414 IPP uses the "HTTPS: HTTP over TLS" mechanism [RFC2818] for 'ipps' 1415 URIs. The Client and server negotiate a secure TLS connection 1416 immediately and unconditionally. 1418 9. Interoperability with Other IPP Versions 1420 It is beyond the scope of this specification to mandate conformance 1421 with versions of IPP other than 1.1. IPP was deliberately designed, 1422 however, to make supporting other versions easy. IPP objects 1423 (Printers, Jobs, etc.) SHOULD: 1425 o understand any valid request whose major "version-number" is 1426 greater than 0; 1428 o respond appropriately with a response containing the same 1429 "version-number" parameter value used by the Client in the request 1430 (if the Client-supplied "version-number" is supported) or the 1431 highest "version-number" supported by the Printer (if the Client- 1432 supplied "version-number" is not supported.) 1434 IPP Clients SHOULD: 1436 o understand any valid response whose major "version-number" is 1437 greater than 0. 1439 9.1. The "version-number" Parameter 1441 The following are rules regarding the "version-number" parameter (see 1442 Section 3.3): 1444 1. Clients MUST send requests containing a "version-number" 1445 parameter with the highest supported value, e.g., '1.1', '2.0', 1446 etc., and SHOULD try supplying alternate version numbers if they 1447 receive a 'server-error-version-not-supported' error return in a 1448 response. For example, if a Client sends an IPP/2.0 request that 1449 is rejected with the 'server-error-version-not-supported' error 1450 and an IPP/1.1 "version-number", it SHOULD retry by sending an 1451 IPP/1.1 request. 1453 2. IPP objects (Printers, Jobs, etc.) MUST accept requests 1454 containing a "version-number" parameter with a '1.1' value (or 1455 reject the request for reasons other than 'server-error-version- 1456 not-supported'). 1458 3. IPP objects SHOULD either accept requests whose major version is 1459 greater than 0 or reject such requests with the 'server-error- 1460 version-not-supported' status code. See [RFC2911bis] "Versions" 1461 sub-section. 1463 4. In any case, security MUST NOT be compromised when a Client 1464 supplies a lower "version-number" parameter in a request. For 1465 example, if an IPP/2.0 conforming Printer accepts version '1.1' 1466 requests and is configured to enforce Digest Authentication, it 1467 MUST do the same for a version '1.1' request. 1469 9.2. Security and URI Schemes 1471 The following are rules regarding security, the "version-number" 1472 parameter, and the URI scheme supplied in target attributes and 1473 responses: 1475 1. When a Client supplies a request, the "printer-uri" or "job-uri" 1476 target operation attribute MUST have the same scheme as that 1477 indicated in one of the values of the "printer-uri-supported" 1478 Printer attribute. 1480 2. When the Printer returns the "job-printer-uri" or "job-uri" Job 1481 Description attributes, it SHOULD return the same scheme ('ipp', 1482 'ipps', etc.) that the Client supplied in the "printer-uri" or 1483 "job-uri" target operation attributes in the Get-Job-Attributes 1484 or Get-Jobs request, rather than the scheme used when the Job was 1485 created. However, when a Client requests Job attributes using 1486 the Get-Job-Attributes or Get-Jobs operations, the Jobs and Job 1487 attributes that the Printer returns depends on: (1) the security 1488 in effect when the Job was created, (2) the security in effect in 1489 the query request, and (3) the security policy in force. 1491 3. The Printer MUST enforce its security and privacy policies based 1492 on the owner of the IPP object and the URI scheme and/or 1493 credentials supplied by the Client in the current request. 1495 10. Changes Since RFC 2910 1497 The following changes have been made since the publication of RFC 1498 2910: 1500 o Added references to current IPP extension specifications. 1502 o Added optional support for HTTP/2. 1504 o Added collection attribute syntax from RFC 3382. 1506 o Fixed typographical errors. 1508 o Now reference TLS/1.2 and no longer mandate the TLS/1.0 MTI cipher 1509 suites. 1511 o Updated all references. 1513 o Updated document organization to follow current style. 1515 o Updated example ipp: URIs to follow RFC 7472 guidelines. 1517 o Updated version compatibility for all versions of IPP. 1519 o Updated HTTP Digest authentication to optional for Clients. 1521 o Removed references to (experimental) IPP/1.0 and usage of 1522 http:/https: URLs. 1524 11. References 1526 11.1. Normative References 1528 [PWG5100.12] 1529 Sweet, M. and I. McDonald, "IPP/2.0, 2.1, and 2.2", 1530 October 2015, . 1533 [RFC20] Cerf, V., "ASCII format for network interchange", STD 80, 1534 RFC 20, DOI 10.17487/RFC0020, October 1969, 1535 . 1537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1538 Requirement Levels", BCP 14, RFC 2119, March 1997. 1540 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1541 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1542 STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, 1543 . 1545 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 1546 HTTP/1.1", RFC 2817, May 2000. 1548 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1550 [RFC2911bis] 1551 Sweet, M. and I. McDonald, "Internet Printing 1552 Protocol/1.1: Model and Semantics", July 2016, 1553 . 1555 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 1556 Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, 1557 October 2000, . 1559 [RFC3510] Herriot, R. and I. McDonald, "Internet Printing 1560 Protocol/1.1: IPP URL Scheme", RFC 3510, April 2003. 1562 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1563 10646", STD 63, RFC 3629, November 2003. 1565 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1566 Resource Identifier (URI): Generic Syntax", STD 66, 1567 RFC 3986, January 2005. 1569 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1570 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1572 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1573 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1575 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1576 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 1577 2014. 1579 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1580 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 1582 [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1583 (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 1585 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 1586 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 1587 2014. 1589 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1590 (HTTP/1.1): Authentication", RFC 7235, June 2014. 1592 [RFC7472] McDonald, I. and M. Sweet, "Internet Printing Protocol 1593 (IPP) over HTTPS Transport Binding and the 'ipps' URI 1594 Scheme", RFC 7472, March 2015. 1596 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1597 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1598 DOI 10.17487/RFC7540, May 2015, 1599 . 1601 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 1602 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 1603 . 1605 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 1606 Digest Access Authentication", RFC 7616, 1607 DOI 10.17487/RFC7616, September 2015, 1608 . 1610 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 1611 RFC 7617, DOI 10.17487/RFC7617, September 2015, 1612 . 1614 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, 1615 RFC 793, September 1981. 1617 11.2. Informative References 1619 [IANA-IPP] 1620 "IANA IPP Registry", 1621 . 1623 [PWG5100.3] 1624 Ocke, K. and T. Hastings, "IPP Production Printing 1625 Attributes Set 1", February 2001, 1626 . 1629 [RFC1179] McLaughlin, L., "Line printer daemon protocol", RFC 1179, 1630 August 1990. 1632 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1633 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1634 2014, . 1636 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1637 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1638 December 2014, . 1640 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1641 "Recommendations for Secure Use of Transport Layer 1642 Security (TLS) and Datagram Transport Layer Security 1643 (DTLS)", BCP 195, RFC 7525, May 2015. 1645 Appendix A. Protocol Examples 1647 A.1. Print-Job Request 1649 The following is an example of a Print-Job request with "job-name", 1650 "copies", and "sides" specified. The "ipp-attribute-fidelity" 1651 attribute is set to 'true' so that the print request will fail if the 1652 "copies" or the "sides" attribute are not supported or their values 1653 are not supported. 1655 Octets Symbolic Value Protocol field 1657 0x0101 1.1 version-number 1658 0x0002 Print-Job operation-id 1659 0x00000001 1 request-id 1660 0x01 start operation- operation- 1661 attributes attributes-tag 1662 0x47 charset type value-tag 1663 0x0012 name-length 1664 attributes-charset attributes-charset name 1665 0x0005 value-length 1666 utf-8 UTF-8 value 1667 0x48 natural-language value-tag 1668 type 1669 0x001B name-length 1670 attributes-natural-language attributes-natural- name 1671 language 1672 0x0005 value-length 1673 en-us en-US value 1674 0x45 uri type value-tag 1675 0x000B name-length 1676 printer-uri printer-uri name 1677 0x002C value-length 1678 ipp://printer.example.com/ipp/ printer pinetree value 1679 print/pinetree 1680 0x42 nameWithoutLanguage value-tag 1681 type 1682 0x0008 name-length 1683 job-name job-name name 1684 0x0006 value-length 1685 foobar foobar value 1686 0x22 boolean type value-tag 1687 0x0016 name-length 1688 ipp-attribute-fidelity ipp-attribute- name 1689 fidelity 1690 0x0001 value-length 1691 0x01 true value 1692 0x02 start job-attributes job-attributes- 1693 tag 1694 0x21 integer type value-tag 1695 0x0006 name-length 1696 copies copies name 1697 0x0004 value-length 1698 0x00000014 20 value 1699 0x44 keyword type value-tag 1700 0x0005 name-length 1701 sides sides name 1702 0x0013 value-length 1703 two-sided-long-edge two-sided-long-edge value 1704 0x03 end-of-attributes end-of- 1705 attributes-tag 1706 %!PDF... data 1708 A.2. Print-Job Response (successful) 1710 Here is an example of a successful Print-Job response to the previous 1711 Print-Job request. The Printer supported the "copies" and "sides" 1712 attributes and their supplied values. The status code returned is 1713 'successful-ok'. 1715 Octets Symbolic Value Protocol field 1717 0x0101 1.1 version-number 1718 0x0000 successful-ok status-code 1719 0x00000001 1 request-id 1720 0x01 start operation- operation- 1721 attributes attributes-tag 1722 0x47 charset type value-tag 1723 0x0012 name-length 1724 attributes-charset attributes-charset name 1725 0x0005 value-length 1726 utf-8 UTF-8 value 1727 0x48 natural-language value-tag 1728 type 1729 0x001B name-length 1730 attributes-natural-language attributes- name 1731 natural-language 1732 0x0005 value-length 1733 en-us en-US value 1734 0x41 textWithoutLanguag value-tag 1735 e type 1736 0x000E name-length 1737 status-message status-message name 1738 0x000D value-length 1739 successful-ok successful-ok value 1740 0x02 start job- job-attributes- 1741 attributes tag 1742 0x21 integer value-tag 1743 0x0006 name-length 1744 job-id job-id name 1745 0x0004 value-length 1746 147 147 value 1747 0x45 uri type value-tag 1748 0x0007 name-length 1749 job-uri job-uri name 1750 0x0030 value-length 1751 ipp://printer.example.com/ipp/pr job 147 on value 1752 int/pinetree/147 pinetree 1753 0x23 enum type value-tag 1754 0x0009 name-length 1755 job-state job-state name 1756 0x0004 value-length 1757 0x0003 pending value 1758 0x03 end-of-attributes end-of- 1759 attributes-tag 1761 A.3. Print-Job Response (failure) 1763 Here is an example of an unsuccessful Print-Job response to the 1764 previous Print-Job request. It fails because, in this case, the 1765 Printer does not support the "sides" attribute and because the value 1766 '20' for the "copies" attribute is not supported. Therefore, no Job 1767 is created, and neither a "job-id" nor a "job-uri" operation 1768 attribute is returned. The error code returned is 'client-error- 1769 attributes-or-values-not-supported' (0x040B). 1771 Octets Symbolic Value Protocol 1772 field 1774 0x0101 1.1 version- 1775 number 1776 0x040B client-error-attributes-or- status-code 1777 values-not-supported 1778 0x00000001 1 request-id 1779 0x01 start operation-attributes operation- 1780 attributes 1781 tag 1782 0x47 charset type value-tag 1783 0x0012 name-length 1784 attributes-charset attributes-charset name 1785 0x0005 value-length 1786 utf-8 UTF-8 value 1787 0x48 natural-language type value-tag 1788 0x001B name-length 1789 attributes-natural-language attributes-natural-language name 1790 0x0005 value-length 1791 en-us en-US value 1792 0x41 textWithoutLanguage type value-tag 1793 0x000E name-length 1794 status-message status-message name 1795 0x002F value-length 1796 client-error-attributes-or- client-error-attributes-or- value 1797 values-not-supported values-not-supported 1798 0x05 start unsupported- unsupported- 1799 attributes attributes 1800 tag 1801 0x21 integer type value-tag 1802 0x0006 name-length 1803 copies copies name 1804 0x0004 value-length 1805 0x00000014 20 value 1806 0x10 unsupported (type) value-tag 1807 0x0005 name-length 1808 sides sides name 1809 0x0000 value-length 1810 0x03 end-of-attributes end-of- 1811 attributes- 1812 tag 1814 A.4. Print-Job Response (success with attributes ignored) 1816 Here is an example of a successful Print-Job response to a Print-Job 1817 request like the previous Print-Job request, except that the value of 1818 "ipp-attribute-fidelity" is 'false'. The print request succeeds, 1819 even though, in this case, the Printer supports neither the "sides" 1820 attribute nor the value '20' for the "copies" attribute. Therefore, 1821 a Job is created, and both a "job-id" and a "job-uri" operation 1822 attribute are returned. The unsupported attributes are also returned 1823 in an Unsupported Attributes Group. The error code returned is 1824 'successful-ok-ignored-or-substituted-attributes' (0x0001). 1826 Octets Symbolic Value Protocol field 1828 0x0101 1.1 version-number 1829 0x0001 successful-ok-ignored-or- status-code 1830 substituted-attributes 1831 0x00000001 1 request-id 1832 0x01 start operation-attributes operation- 1833 attributes-tag 1834 0x47 charset type value-tag 1835 0x0012 name-length 1836 attributes-charset attributes-charset name 1837 0x0005 value-length 1838 utf-8 UTF-8 value 1839 0x48 natural-language type value-tag 1840 0x001B name-length 1841 attributes-natural- attributes-natural-language name 1842 language 1843 0x0005 value-length 1844 en-us en-US value 1845 0x41 textWithoutLanguage type value-tag 1846 0x000E name-length 1847 status-message status-message name 1848 0x002F value-length 1849 successful-ok-ignored-or- successful-ok-ignored-or- value 1850 substituted-attributes substituted-attributes 1851 0x05 start unsupported- unsupported- 1852 attributes attributes tag 1853 0x21 integer type value-tag 1854 0x0006 name-length 1855 copies copies name 1856 0x0004 value-length 1857 0x00000014 20 value 1858 0x10 unsupported (type) value-tag 1859 0x0005 name-length 1860 sides sides name 1861 0x0000 value-length 1862 0x02 start job-attributes job- 1863 attributes-tag 1864 0x21 integer value-tag 1865 0x0006 name-length 1866 job-id job-id name 1867 0x0004 value-length 1868 147 147 value 1869 0x45 uri type value-tag 1870 0x0007 name-length 1871 job-uri job-uri name 1872 0x0030 value-length 1873 ipp://printer.example.com/ job 147 on pinetree value 1874 ipp/print/pinetree/147 1875 0x23 enum type value-tag 1876 0x0009 name-length 1877 job-state job-state name 1878 0x0004 value-length 1879 0x0003 pending value 1880 0x03 end-of-attributes end-of- 1881 attributes-tag 1883 A.5. Print-URI Request 1885 The following is an example of Print-URI request with "copies" and 1886 "job-name" parameters: 1888 Octets Symbolic Value Protocol field 1890 0x0101 1.1 version-number 1891 0x0003 Print-URI operation-id 1892 0x00000001 1 request-id 1893 0x01 start operation- operation- 1894 attributes attributes-tag 1895 0x47 charset type value-tag 1896 0x0012 name-length 1897 attributes-charset attributes-charset name 1898 0x0005 value-length 1899 utf-8 UTF-8 value 1900 0x48 natural-language value-tag 1901 type 1902 0x001B name-length 1903 attributes-natural-language attributes-natural- name 1904 language 1905 0x0005 value-length 1906 en-us en-US value 1907 0x45 uri type value-tag 1908 0x000B name-length 1909 printer-uri printer-uri name 1910 0x002C value-length 1911 ipp://printer.example.com/ipp/ printer pinetree value 1912 print/pinetree 1913 0x45 uri type value-tag 1914 0x000C name-length 1915 document-uri document-uri name 1916 0x0019 value-length 1917 ftp://foo.example.com/foo ftp://foo.example.co value 1918 m/foo 1919 0x42 nameWithoutLanguage value-tag 1920 type 1921 0x0008 name-length 1922 job-name job-name name 1923 0x0006 value-length 1924 foobar foobar value 1925 0x02 start job-attributes job-attributes- 1926 tag 1927 0x21 integer type value-tag 1928 0x0006 name-length 1929 copies copies name 1930 0x0004 value-length 1931 0x00000001 1 value 1932 0x03 end-of-attributes end-of- 1933 attributes-tag 1935 A.6. Create-Job Request 1937 The following is an example of Create-Job request with no parameters 1938 and no attributes: 1940 Octets Symbolic Value Protocol field 1942 0x0101 1.1 version-number 1943 0x0005 Create-Job operation-id 1944 0x00000001 1 request-id 1945 0x01 start operation- operation- 1946 attributes attributes-tag 1947 0x47 charset type value-tag 1948 0x0012 name-length 1949 attributes-charset attributes-charset name 1950 0x0005 value-length 1951 utf-8 UTF-8 value 1952 0x48 natural-language value-tag 1953 type 1954 0x001B name-length 1955 attributes-natural-language attributes-natural- name 1956 language 1957 0x0005 value-length 1958 en-us en-US value 1959 0x45 uri type value-tag 1960 0x000B name-length 1961 printer-uri printer-uri name 1962 0x002C value-length 1963 ipp://printer.example.com/ipp/ printer pinetree value 1964 print/pinetree 1965 0x03 end-of-attributes end-of- 1966 attributes-tag 1968 A.7. Create-Job Request with Collection Attributes 1970 The following is an example of Create-Job request with the "media- 1971 col" collection attribute [PWG5100.3] with the value "media- 1972 size={x-dimension=21000 y-dimension=29700} media-type='stationery'": 1974 Octets Symbolic Value Protocol field 1976 0x0101 1.1 version-number 1977 0x0005 Create-Job operation-id 1978 0x00000001 1 request-id 1979 0x01 start operation- operation- 1980 attributes attributes-tag 1981 0x47 charset type value-tag 1982 0x0012 name-length 1983 attributes-charset attributes-charset name 1984 0x0005 value-length 1985 utf-8 UTF-8 value 1986 0x48 natural-language value-tag 1987 type 1988 0x001B name-length 1989 attributes-natural-language attributes-natural- name 1990 language 1991 0x0005 value-length 1992 en-us en-US value 1993 0x45 uri type value-tag 1994 0x000B name-length 1995 printer-uri printer-uri name 1996 0x002C value-length 1997 ipp://printer.example.com/ipp/ printer pinetree value 1998 print/pinetree 1999 0x34 begCollection value-tag 2000 0x0009 9 name-length 2001 media-col media-col name 2002 0x0000 0 value-length 2003 0x4A memberAttrName value-tag 2004 0x0000 0 name-length 2005 0x000A 10 value-length 2006 media-size media-size value (member- 2007 name) 2008 0x34 begCollection member-value-tag 2009 0x0000 0 name-length 2010 0x0000 0 member-value- 2011 length 2012 0x4A memberAttrName value-tag 2013 0x0000 0 name-length 2014 0x000B 11 value-length 2015 x-dimension x-dimension value (member- 2016 name) 2017 0x21 integer member-value-tag 2018 0x0000 0 name-length 2019 0x0004 4 member-value- 2020 length 2021 0x00005208 21000 member-value 2022 0x4A memberAttrName value-tag 2023 0x0000 0 name-length 2024 0x000B 11 value-length 2025 y-dimension y-dimension value (member- 2026 name) 2027 0x21 integer member-value-tag 2028 0x0000 0 name-length 2029 0x0004 4 member-value- 2030 length 2032 0x00007404 29700 member-value 2033 0x37 endCollection end-value-tag 2034 0x0000 0 end-name-length 2035 0x0000 0 end-value-length 2036 0x4A memberAttrName value-tag 2037 0x0000 0 name-length 2038 0x000A 10 value-length 2039 media-type media-type value (member- 2040 name) 2041 0x44 keyword member-value-tag 2042 0x0000 0 name-length 2043 0x000A 10 member-value- 2044 length 2045 stationery stationery member-value 2046 0x37 endCollection end-value-tag 2047 0x0000 0 end-name-length 2048 0x0000 0 end-value-length 2049 0x03 end-of-attributes end-of- 2050 attributes-tag 2052 A.8. Get-Jobs Request 2054 The following is an example of Get-Jobs request with parameters but 2055 no attributes: 2057 Octets Symbolic Value Protocol field 2059 0x0101 1.1 version-number 2060 0x000A Get-Jobs operation-id 2061 0x0000007B 123 request-id 2062 0x01 start operation- operation- 2063 attributes attributes-tag 2064 0x47 charset type value-tag 2065 0x0012 name-length 2066 attributes-charset attributes-charset name 2067 0x0005 value-length 2068 utf-8 UTF-8 value 2069 0x48 natural-language value-tag 2070 type 2071 0x001B name-length 2072 attributes-natural-language attributes-natural- name 2073 language 2074 0x0005 value-length 2075 en-us en-US value 2076 0x45 uri type value-tag 2077 0x000B name-length 2078 printer-uri printer-uri name 2079 0x002C value-length 2080 ipp://printer.example.com/ipp/ printer pinetree value 2081 print/pinetree 2082 0x21 integer type value-tag 2083 0x0005 name-length 2084 limit limit name 2085 0x0004 value-length 2086 0x00000032 50 value 2087 0x44 keyword type value-tag 2088 0x0014 name-length 2089 requested-attributes requested-attributes name 2090 0x0006 value-length 2091 job-id job-id value 2092 0x44 keyword type value-tag 2093 0x0000 additional value name-length 2094 0x0008 value-length 2095 job-name job-name value 2096 0x44 keyword type value-tag 2097 0x0000 additional value name-length 2098 0x000F value-length 2099 document-format document-format value 2100 0x03 end-of-attributes end-of- 2101 attributes-tag 2103 A.9. Get-Jobs Response 2105 The following is an of Get-Jobs response from previous request with 3 2106 jobs. The Printer returns no information about the second Job 2107 (because of security reasons): 2109 Octets Symbolic Value Protocol field 2111 0x0101 1.1 version-number 2112 0x0000 successful-ok status-code 2113 0x0000007B 123 request-id (echoed 2114 back) 2115 0x01 start operation- operation-attributes- 2116 attributes tag 2117 0x47 charset type value-tag 2118 0x0012 name-length 2119 attributes-charset attributes-charset name 2120 0x0005 value-length 2121 utf-8 UTF-8 value 2122 0x48 natural-language type value-tag 2123 0x001B name-length 2124 attributes-natural- attributes-natural- name 2125 language language 2126 0x0005 value-length 2127 en-us en-US value 2128 0x41 textWithoutLanguage value-tag 2129 type 2130 0x000E name-length 2131 status-message status-message name 2132 0x000D value-length 2133 successful-ok successful-ok value 2134 0x02 start job-attributes job-attributes-tag 2135 (1st object) 2136 0x21 integer type value-tag 2137 0x0006 name-length 2138 job-id job-id name 2139 0x0004 value-length 2140 147 147 value 2141 0x36 nameWithLanguage value-tag 2142 0x0008 name-length 2143 job-name job-name name 2144 0x000C value-length 2145 0x0005 sub-value-length 2146 fr-ca fr-CA value 2147 0x0003 sub-value-length 2148 fou fou name 2149 0x02 start job-attributes job-attributes-tag 2150 (2nd object) 2152 0x02 start job-attributes job-attributes-tag 2153 (3rd object) 2154 0x21 integer type value-tag 2155 0x0006 name-length 2156 job-id job-id name 2157 0x0004 value-length 2158 148 149 value 2159 0x36 nameWithLanguage value-tag 2160 0x0008 name-length 2161 job-name job-name name 2162 0x0012 value-length 2163 0x0005 sub-value-length 2164 de-CH de-CH value 2165 0x0009 sub-value-length 2166 isch guet isch guet name 2167 0x03 end-of-attributes end-of-attributes-tag 2169 Appendix B. Acknowledgements 2171 The authors would like to acknowledge the following individuals for 2172 their contributions to the original IPP/1.1 specifications: 2174 Sylvan Butler, Roger deDry, Tom Hastings, Robert Herriot (original 2175 RFC 2910 editor), Paul Moore, Kirk Ocke, Randy Turner, John Wenn, and 2176 Peter Zehler 2178 Appendix C. Change History 2180 C.1. Changes In -10 2182 The following changes are in draft-sweet-rfc2910bis-10: 2184 o Updated the acknowledgements to include authors from the original 2185 RFC 3382. 2187 C.2. Changes In -09 2189 The following changes are in draft-sweet-rfc2910bis-09: 2191 o Abstract: Mention that this document obsoletes RFC 2910 and 3382, 2192 and reword for clarity. 2194 o Editor's Note: Add parenthetical note to RFC editor to remove 2195 before publication. 2197 o Updated reference to ASCII to RFC 20/STD 80. 2199 o Section 1: Removed redundant conformance terminology from the 2200 introduction. 2202 o Section 3.2, Figure 10: Fixed ABNF syntax error. 2204 o Section 3.4: Added reference to 3.1.1 for document content. 2206 o Section 3.5.2: Reworded the (confusing) meanings for reserved 2207 values. 2209 o Section 4: Reword "It is REQUIRED". 2211 o Section 4.1: Reword example without conformance terminology. 2213 o Section 5: Clarify URL rewriting rules. 2215 o Section 6: Updated document pointers in MIME media type 2216 registration. 2218 o Section 8: Mention message integrity, addressed by IPPS. 2220 o Section 8.1.1: Reword and make SHA2-256 required if Digest is 2221 supported. 2223 o Section 8.1.2: Add reference to RFC 7258 to encourage TLS support, 2224 RFC 7435 for TOFU. 2226 o Section 8.2.1: SHOULD NOT support Basic over insecure channels. 2228 o Section 9: Reworded to SHOULD allow version numbers > 0.0. 2230 o Section 9.1: Reworded to SHOULD allow version numbers > 0.0, added 2231 example for client sending a 2.0 request and retrying with a 1.1 2232 request. 2234 C.3. Changes In -08 2236 The following changes are in draft-sweet-rfc2910bis-08: 2238 o Section 3: Added reference to RFC 2978. 2240 o Section 3.1.1: Fix reference to RFC 2910bis. 2242 o Section 3.2: Fix ABNF for begin-attributes-group-tag. 2244 o Section 3.8: Add examples for signed byte types (boolean). 2246 o Section 8.1.2: Add reference to RFC 7472 (IPP over HTTPS) for 2247 example of secure channel. 2249 o Section 9: Reference PWG 5100.12. 2251 o Section 11.1: Added reference to RFC 2978. 2253 o Section 11.2: Removed unused reference to IANA-CON. 2255 o Appendix B: Updated MIME media type registration template and 2256 moved to section 6. 2258 o Updated references to RFC 1903 to 2579. 2260 C.4. Changes In -07 2262 The following changes are in draft-sweet-rfc2910bis-07: 2264 o Global: Drop RFC2911bis references after "Model". 2266 o Section 1.1: Fix typo. 2268 o Section 4: Drop note about non-conforming HTTP/1.1 servers. 2270 C.5. Changes In -06 2272 The following changes are in draft-sweet-rfc2910bis-06: 2274 o Global: "Model" changed to just "Model". 2276 o Global: "message-body" changed to "message body". 2278 o Abstract: "MIME" instead of "mime" plus some minor rewording. 2280 o Section 1: Updated references to HTTP Basic and Digest, clarify 2281 that the semantics/model are defined in both the Model and 2282 subsequent extensions. 2284 o Section 2.2: Fixed some typos and added a definition of Model. 2286 o Section 3.1.1: Reworded paragraph about the data field. 2288 o Section 3.2: Reworded and now use figure references, and fixed 2289 section references in figures. 2291 o Section 3.3: Added table reference, fix typo. 2293 o Section 3.4.1: Replace "this document" with reference to 2911bis. 2295 o Section 3.4.3: HTTP status-code (to be consistent with RFC 7230). 2297 o Section 3.5.1: Add table references, capitalize Document, reword 2298 ordering requirements, reword printer requirements. 2300 o Section 3.5.2: Add table references, dropped notes (15 years 2301 without needing it, we don't need the note...) 2303 o Section 3.6: "mal-formed" changed to "malformed", fix RFC2911bis 2304 reference, single quotes around value. 2306 o Section 3.8: "string" instead of "text", use single quotes for 2307 values. 2309 o Section 3.9: Add table reference. 2311 o Section 4: Fix HTTP references and put Note in a separate 2312 paragraph. 2314 o Section 4.1: Mention the Job ID, clean up Note and get rid of 2315 "NEED NOT" language. 2317 o Section 5: Clients and Printers MUST support, drop "object", use 2318 double quotes around attribute names, drop discussion of UI, fix 2319 typos. 2321 o Section 6: Point to RFC2911bis. 2323 o Section 8.1.1: Update references to HTTP Basic and Digest RFCs. 2325 o Section 9: Allow 1.x and 2.x, fix typos. 2327 o Section 11.1: Updated 5100.12, HTTP Basic and Digest references 2329 o Appendix A: Examples now use UTF-8, fix job-uri to be consistent 2330 with job-id. 2332 o 2334 C.6. Changes In -05 2336 The following changes are in draft-sweet-rfc2910bis-05: 2338 o Submission type is now IETF (AD-sponsored), clarify goals. 2340 o Abstract: This document does not define the 'ipp' URI scheme. 2342 o Section 5: drop reference to RFC 2617 2343 o Section 8.1.1: combine identical Client and Printer requirements 2345 o Section 8.1.2: also applies to clients, HTTP Basic is User 2346 authentication, not Client authentication. 2348 o References to RFC 2617 are updated to the updated drafts in the 2349 RFC editor's queue 2351 o Global: Client, Printer, and Job are defined terms, capitalize 2353 C.7. Changes In -04 2355 The following changes are in draft-sweet-rfc2910bis-04: 2357 o Removed more references to IPP/1.0. 2359 o Section 5: Be explicit about ipp/s-URI and http/s-URL 2361 o Section 9.1: Reword SHOULD recommendation (avoid passive voice) 2363 o Section 9.2: Reword item 3: the server MUST NOT compromise 2364 security... 2366 o Make sure to use URI for generic schemes and URL for HTTP/HTTPS. 2368 o Fixed incorrect usage of lowercase conformance words. 2370 C.8. Changes In -03 2372 The following changes are in draft-sweet-rfc2910bis-03: 2374 o New HTTP/2 RFCs: 7540, 7541 2376 o Added informative reference to UTA BCP (RFC 7525) 2378 o Culled list of people in acknowledgements to the original RFC 2910 2379 editors, per IPP F2F. 2381 C.9. Changes In -02 2383 The following changes are in draft-sweet-rfc2910bis-02: 2385 o Sections 3.1.x: Dropped "Picture of the encoding of" from titles 2387 o Section 3.4.1: Added reference to IPP version interoperability 2388 section. 2390 o Section 3.4.2: Removed paragraph on status-code as operation 2391 attribute (already covered in 3.4 intro) and updated HTTP status 2392 code 200 name (OK) 2394 o Section 3.5: Added reference to IANA IPP registry for tags. 2396 o Section 3.8: Mention SIGNED-BYTE is 1 octet. 2398 o Section 4.1: Drop mention of URIs not being widely implemented, 2399 and that implementations will pass around URLs (not true). Also 2400 remove more "need not" text. 2402 o Section 6: Fixed references. 2404 o Section 8.1.1: Make Digest authentication a SHOULD for clients. 2406 o Section 9: Reworked for generic IPP version compatibility. 2408 o Section 9.1: Reworked for IPP 2.x compatibility. 2410 o Section 9.2: Drop reference to IPP/1.0 and http/https URI schemes. 2412 o Appendix A: Updated example URIs to follow IETF and IPP/IPPS URI 2413 examples 2415 o Global: ipp-URL tp ipp-URI, URL to URI 2417 o Global: Don't use conformance language for statements of fact. 2419 o Global: Change "NOTE:" to "Note:" for consistency. 2421 C.10. Changes In -01 2423 The following changes are in draft-sweet-rfc2910bis-01: 2425 o Errata ID 4100: Cleaned up TLS references and recommendations - no 2426 longer include cipher suites. 2428 o Errata ID 4172: Fixed range of standards-track value tags (to 2429 0x3ffffff not 0x37777777) 2431 o Updated RFC references. 2433 o Added HTTP/2 references, made it clear that only HTTP/1.1 is 2434 required and HTTP/2 is optional. 2436 o Added collection attribute encoding from RFC 3382. 2438 Authors' Addresses 2440 Michael Sweet 2441 Apple Inc. 2442 1 Infinite Loop 2443 MS 111-HOMC 2444 Cupertino, CA 95014 2445 US 2447 Email: msweet@apple.com 2449 Ira McDonald 2450 High North, Inc. 2451 PO Box 221 2452 Grand Marais, MI 49839 2453 US 2455 Phone: +1 906-494-2434 2456 Email: blueroofmusic@gmail.com