idnits 2.17.1 draft-ietf-ipp-protocol-v11-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC2568], [RFC2569], [RFC2567]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 92 has weird spacing: '...ding of the O...' == Line 170 has weird spacing: '...ding of the O...' == Line 387 has weird spacing: '... or an "a...' == Line 402 has weird spacing: '...tes-tag data...' == Line 644 has weird spacing: '...with an unspe...' == (36 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 30, 2000) is 8704 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: 'RFC2026' is mentioned on line 24, but not defined == Missing Reference: 'IANA-CON' is mentioned on line 1009, but not defined == Missing Reference: 'IPP-MOD' is mentioned on line 1178, but not defined == Missing Reference: 'IPP-PRO' is mentioned on line 1891, but not defined == Unused Reference: 'RFC822' is defined on line 1205, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 1208, but no explicit reference was found in the text == Unused Reference: 'RFC1179' is defined on line 1211, but no explicit reference was found in the text == Unused Reference: 'RFC1543' is defined on line 1214, but no explicit reference was found in the text == Unused Reference: 'RFC1759' is defined on line 1220, but no explicit reference was found in the text == Unused Reference: 'RFC1766' is defined on line 1223, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 1233, but no explicit reference was found in the text == Unused Reference: 'RFC2048' is defined on line 1236, but no explicit reference was found in the text == Unused Reference: 'RFC2184' is defined on line 1243, but no explicit reference was found in the text == Unused Reference: 'RFC2566' is defined on line 1260, but no explicit reference was found in the text == Unused Reference: 'SSL' is defined on line 1287, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 1179 ** Obsolete normative reference: RFC 1543 (Obsoleted by RFC 2223) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1759 (Obsoleted by RFC 3805) ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 1808 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2184 (Obsoleted by RFC 2231) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2565 (Obsoleted by RFC 2910) ** Obsolete normative reference: RFC 2566 (Obsoleted by RFC 2911) ** Downref: Normative reference to an Experimental RFC: RFC 2567 ** Downref: Normative reference to an Experimental RFC: RFC 2568 ** Downref: Normative reference to an Experimental RFC: RFC 2569 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Possible downref: Non-RFC (?) normative reference: ref. 'SSL' Summary: 27 errors (**), 0 flaws (~~), 24 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Robert Herriot (editor) 3 Xerox Corporation 4 Sylvan Butler 5 Hewlett-Packard 6 Paul Moore 7 Peerless Systems Networking 8 Randy Turner 9 2wire.com 10 John Wenn 11 Xerox Corporation 12 May 30, 2000 14 Internet Printing Protocol/1.1: Encoding and Transport 15 Copyright (C) The Internet Society (2000). All Rights Reserved. 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with all 20 provisions of Section 10 of [RFC2026]. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, and 22 its working groups. Note that other groups may also distribute working 23 documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference material 28 or to cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed as 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document is one of a set of documents, which together describe all 39 aspects of a new Internet Printing Protocol (IPP). IPP is an application 40 level protocol that can be used for distributed printing using Internet 41 tools and technologies. This document defines the rules for encoding IPP 42 operations and IPP attributes into a new Internet mime media type called 43 "application/ipp". This document also defines the rules for 44 transporting over HTTP a message body whose Content-Type is 45 "application/ipp". This document defines a new scheme named 'ipp' for 46 identifying IPP printers and jobs. 48 The full set of IPP documents includes: 50 Design Goals for an Internet Printing Protocol [RFC2567] 51 Rationale for the Structure and Model and Protocol for the Internet 52 Printing Protocol [RFC2568] 53 Internet Printing Protocol/1.1: Model and Semantics [ipp-mod] 54 Internet Printing Protocol/1.1: Encoding and Transport (this 55 document) 56 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 57 Mapping between LPD and IPP Protocols [RFC2569] 59 The document, "Design Goals for an Internet Printing Protocol", takes a 60 broad look at distributed printing functionality, and it enumerates 61 real-life scenarios that help to clarify the features that need to be 62 included in a printing protocol for the Internet. It identifies 63 requirements for three types of users: end users, operators, and 64 administrators. It calls out a subset of end user requirements that are 65 satisfied in IPP/1.1. A few OPTIONAL operator operations have been added 66 to IPP/1.1. 68 The document, "Rationale for the Structure and Model and Protocol for 69 the Internet Printing Protocol", describes IPP from a high level view, 70 defines a roadmap for the various documents that form the suite of IPP 71 specification documents, and gives background and rationale for the IETF 72 working group's major decisions. 74 The document, "Internet Printing Protocol/1.1: Model and Semantics", 75 describes a simplified model with abstract objects, their attributes, 76 and their operations that are independent of encoding and transport. It 77 introduces a Printer and a Job object. The Job object optionally 78 supports multiple documents per Job. It also addresses security, 79 internationalization, and directory issues. 81 The document "Internet Printing Protocol/1.1: Implementer's Guide", 82 gives advice to implementers of IPP clients and IPP objects. 84 The document "Mapping between LPD and IPP Protocols" gives some advice 85 to implementers of gateways between IPP and LPD (Line Printer Daemon) 86 implementations. 88 Table of Contents 90 1. Introduction .......................................................5 91 2. Conformance Terminology ............................................5 92 3. Encoding of the Operation Layer ...................................5 93 3.1 Picture of the Encoding .......................................6 94 3.1.1 Request and Response.......................................6 95 3.1.2 Attribute Group............................................7 96 3.1.3 Attribute..................................................8 97 3.1.4 Picture of the Encoding of an Attribute-with-one-value.....8 98 3.1.5 Additional-value...........................................9 99 3.1.6 Alternative Picture of the Encoding of a Request Or a 100 Response.........................................................9 101 3.2 Syntax of Encoding ...........................................10 102 3.3 Attribute-group ..............................................12 103 3.4 Required Parameters ..........................................13 104 3.4.1 Version-number............................................13 105 3.4.2 Operation-id..............................................13 106 3.4.3 Status-code...............................................13 107 3.4.4 Request-id................................................14 108 3.5 Tags .........................................................14 109 3.5.1 Delimiter Tags............................................14 110 3.5.2 Value Tags................................................15 111 3.6 Name-Length ..................................................17 112 3.7 (Attribute) Name .............................................18 113 3.8 Value Length .................................................18 114 3.9 (Attribute) Value ............................................18 115 3.10 Data .........................................................20 116 4. Encoding of Transport Layer .......................................20 117 4.1 Printer-uri and job-uri ......................................21 118 5. IPP URL Scheme ....................................................22 119 6. IANA Considerations ...............................................24 120 7. Internationalization Considerations ...............................24 121 8. Security Considerations ...........................................24 122 8.1 Security Conformance Requirements ............................25 123 8.1.1 Digest Authentication.....................................25 124 8.1.2 Transport Layer Security (TLS)............................26 125 8.2 Using IPP with TLS ...........................................26 126 9. Interoperability with IPP/1.0 Implementations .....................26 127 9.1 The "version-number" Parameter ...............................27 128 9.2 Security and URL Schemes .....................................27 129 10. References .......................................................28 130 11. Author's Address .................................................31 131 12. Other Participants: ..............................................31 132 13. Appendix A: Protocol Examples ....................................33 133 13.1 Print-Job Request ............................................33 134 13.2 Print-Job Response (successful) ..............................34 135 13.3 Print-Job Response (failure) .................................35 136 13.4 Print-Job Response (success with attributes ignored) .........36 137 13.5 Print-URI Request ............................................38 138 13.6 Create-Job Request ...........................................39 139 13.7 Get-Jobs Request .............................................40 140 13.8 Get-Jobs Response ............................................41 141 14. Appendix B: Registration of MIME Media Type Information for 142 "application/ipp".....................................................42 143 15. Appendix C: Changes from IPP/1.0 .................................44 144 16. Full Copyright Statement .........................................45 145 1. Introduction 147 This document contains the rules for encoding IPP operations and 148 describes two layers: the transport layer and the operation layer. 150 The transport layer consists of an HTTP/1.1 request or response. RFC 151 2616 [RFC2616] describes HTTP/1.1. This document specifies the HTTP 152 headers that an IPP implementation supports. 154 The operation layer consists of a message body in an HTTP request or 155 response. The document "Internet Printing Protocol/1.1: Model and 156 Semantics" [ipp-mod] defines the semantics of such a message body and 157 the supported values. This document specifies the encoding of an IPP 158 operation. The aforementioned document [ipp-mod] is henceforth referred 159 to as the "IPP model document" or simply "model document." 161 Note: the version number of IPP (1.1) and HTTP (1.1) are not linked. 162 They both just happen to be 1.1. 164 2. Conformance Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 167 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 168 interpreted as described in RFC 2119 [RFC2119]. 170 3. Encoding of the Operation Layer 172 The operation layer is the message body part of the HTTP request or 173 response and it MUST contain a single IPP operation request or IPP 174 operation response. Each request or response consists of a sequence of 175 values and attribute groups. Attribute groups consist of a sequence of 176 attributes each of which is a name and value. Names and values are 177 ultimately sequences of octets. 179 The encoding consists of octets as the most primitive type. There are 180 several types built from octets, but three important types are integers, 181 character strings and octet strings, on which most other data types are 182 built. Every character string in this encoding MUST be a sequence of 183 characters where the characters are associated with some charset and 184 some natural language. A character string MUST be in "reading order" 185 with the first character in the value (according to reading order) being 186 the first character in the encoding. A character string whose associated 187 charset is US-ASCII whose associated natural language is US English is 188 henceforth called a US-ASCII-STRING. A character string whose associated 189 charset and natural language are specified in a request or response as 190 described in the model document is henceforth called a LOCALIZED-STRING. 191 An octet string MUST be in "IPP model document order" with the first 192 octet in the value (according to the IPP model document order) being the 193 first octet in the encoding. Every integer in this encoding MUST be 194 encoded as a signed integer using two's-complement binary encoding with 195 big-endian format (also known as "network order" and "most significant 196 byte first"). The number of octets for an integer MUST be 1, 2 or 4, 197 depending on usage in the protocol. Such one-octet integers, henceforth 198 called SIGNED-BYTE, are used for the version-number and tag fields. Such 199 two-byte integers, henceforth called SIGNED-SHORT are used for the 200 operation-id, status-code and length fields. Four byte integers, 201 henceforth called SIGNED-INTEGER, are used for value fields and the 202 request-id. 204 The following two sections present the encoding of the operation layer 205 in two ways: 207 - informally through pictures and description 208 - formally through Augmented Backus-Naur Form (ABNF), as specified by 209 RFC 2234 [RFC2234] 211 An operation request or response MUST use the encoding described in 212 these two sections. 214 3.1 Picture of the Encoding 216 3.1.1 Request and Response 218 An operation request or response is encoded as follows: 220 ----------------------------------------------- 221 | version-number | 2 bytes - required 222 ----------------------------------------------- 223 | operation-id (request) | 224 | or | 2 bytes - required 225 | status-code (response) | 226 ----------------------------------------------- 227 | request-id | 4 bytes - required 228 ----------------------------------------------- 229 | attribute-group | n bytes - 0 or more 230 ----------------------------------------------- 231 | end-of-attributes-tag | 1 byte - required 232 ----------------------------------------------- 233 | data | q bytes - optional 234 ----------------------------------------------- 236 The first three fields in the above diagram contain the value of 237 attributes described in section 3.1.1 of the Model document. 239 The fourth field is the "attribute-group" field, and it occurs 0 or more 240 times. Each "attribute-group" field represents a single group of 241 attributes, such as an Operation Attributes group or a Job Attributes 242 group (see the Model document). The IPP model document specifies the 243 required attribute groups and their order for each operation request and 244 response. 246 The "end-of-attributes-tag" field is always present, even when the 247 "data" is not present. The Model document specifies for each operation 248 request and response whether the "data" field is present or absent. 250 3.1.2 Attribute Group 252 Each "attribute-group" field is encoded as follows: 254 ----------------------------------------------- 255 | begin-attribute-group-tag | 1 byte 256 ---------------------------------------------------------- 257 | attribute | p bytes |- 0 or more 258 ---------------------------------------------------------- 260 The "begin-attribute-group-tag" field marks the beginning of an 261 "attribute-group" field and its value identifies the type of attribute 262 group, e.g. Operations Attributes group versus a Job Attributes group. 263 The "begin-attribute-group-tag" field also marks the end of the previous 264 attribute group except for the "begin-attribute-group-tag" field in the 265 first "attribute-group" field of a request or response. The "begin- 266 attribute-group-tag" field acts as an "attribute-group" terminator 267 because an "attribute-group" field cannot nest inside another 268 "attribute-group" field. 270 An "attribute-group" field contains zero or more "attribute" fields. 272 Note, the values of the "begin-attribute-group-tag" field and the "end- 273 of-attributes-tag" field are called "delimiter-tags". 275 3.1.3 Attribute 277 An "attribute" field is encoded as follows: 279 ----------------------------------------------- 280 | attribute-with-one-value | q bytes 281 ---------------------------------------------------------- 282 | additional-value | r bytes |- 0 or more 283 ---------------------------------------------------------- 285 When an attribute is single valued (e.g. "copies" with value of 10) or 286 multi-valued with one value (e.g. "sides-supported" with just the value 287 'one-sided') it is encoded with just an "attribute-with-one-value" 288 field. When an attribute is multi-valued with n values (e.g. "sides- 289 supported" with the values 'one-sided' and 'two-sided-long-edge'), it is 290 encoded with an "attribute-with-one-value" field followed by n-1 291 "additional-value" fields. 293 3.1.4 Picture of the Encoding of an Attribute-with-one-value 295 Each "attribute-with-one-value" field is encoded as follows: 297 ----------------------------------------------- 298 | value-tag | 1 byte 299 ----------------------------------------------- 300 | name-length (value is u) | 2 bytes 301 ----------------------------------------------- 302 | name | u bytes 303 ----------------------------------------------- 304 | value-length (value is v) | 2 bytes 305 ----------------------------------------------- 306 | value | v bytes 307 ----------------------------------------------- 309 An "attribute-with-one-value" field is encoded with five subfields: 311 The "value-tag" field specifies the attribute syntax, e.g. 0x44 for 312 the attribute syntax 'keyword'. 314 The "name-length" field specifies the length of the "name" field in 315 bytes, e.g. u in the above diagram or 15 for the name "sides- 316 supported ". 318 The "name" field contains the textual name of the attribute, e.g. 319 "sides-supported". 321 The "value-length" field specifies the length of the "value" field in 322 bytes, e.g. v in the above diagram or 9 for the (keyword) value 'one- 323 sided'. 325 The "value" field contains the value of the attribute, e.g. the 326 textual value 'one-sided'. 328 3.1.5 Additional-value 330 Each "additional-value" field is encoded as follows: 332 ----------------------------------------------- 333 | value-tag | 1 byte 334 ----------------------------------------------- 335 | name-length (value is 0x0000) | 2 bytes 336 ----------------------------------------------- 337 | value-length (value is w) | 2 bytes 338 ----------------------------------------------- 339 | value | w bytes 340 ----------------------------------------------- 342 An "additional-value" is encoded with four subfields: 344 The "value-tag" field specifies the attribute syntax, e.g. 0x44 for 345 the attribute syntax 'keyword'. 347 The "name-length" field has the value of 0 in order to signify that 348 it is an "additional-value". The value of the "name-length" field 349 distinguishes an "additional-value" field ("name-length" is 0) from 350 an "attribute-with-one-value" field ("name-length" is not 0). 352 The "value-length" field specifies the length of the "value" field in 353 bytes, e.g. w in the above diagram or 19 for the (keyword) value 354 'two-sided-long-edge'. 356 The "value" field contains the value of the attribute, e.g. the 357 textual value 'two-sided-long-edge'. 359 3.1.6 Alternative Picture of the Encoding of a Request Or a Response 361 >From the standpoint of a parser that performs an action based on a "tag" 362 value, the encoding consists of: 364 ----------------------------------------------- 365 | version-number | 2 bytes - required 366 ----------------------------------------------- 367 | operation-id (request) | 368 | or | 2 bytes - required 369 | status-code (response) | 370 ----------------------------------------------- 371 | request-id | 4 bytes - required 372 ----------------------------------------------------------- 373 | tag (delimiter-tag or value-tag) | 1 byte | 374 ----------------------------------------------- |-0 or more 375 | empty or rest of attribute | x bytes | 376 ----------------------------------------------------------- 377 | end-of-attributes-tag | 1 byte - required 378 ----------------------------------------------- 379 | data | y bytes - optional 380 ----------------------------------------------- 382 The following show what fields the parser would expect after each type 383 of "tag": 385 - "begin-attribute-group-tag": expect zero or more "attribute"s 386 - "value-tag": expect the remainder of an "attribute-with-one-value" 387 or an "additional-value". 388 - "end-of-attributes-tag": expect that "attribute"s are complete and 389 there is optional "data" 391 3.2 Syntax of Encoding 393 The syntax below is ABNF [RFC2234] except 'strings of literals' MUST be 394 case sensitive. For example 'a' means lower case 'a' and not upper case 395 'A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields are represented 396 as '%x' values which show their range of values. 398 ipp-message = ipp-request / ipp-response 399 ipp-request = version-number operation-id request-id 400 *attribute-group end-of-attributes-tag data 401 ipp-response = version-number status-code request-id 402 *attribute-group end-of-attributes-tag data 403 attribute-group = begin-attribute-group-tag attribute 405 version-number = major-version-number minor-version-number 406 major-version-number = SIGNED-BYTE 407 minor-version-number = SIGNED-BYTE 408 operation-id = SIGNED-SHORT ; mapping from model defined below 409 status-code = SIGNED-SHORT ; mapping from model defined below 410 request-id = SIGNED-INTEGER ; whose value is > 0 412 attribute = attribute-with-one-value *additional-value 414 attribute-with-one-value = value-tag name-length name 415 value-length value 416 additional-value = value-tag zero-name-length value-length value 418 name-length = SIGNED-SHORT ; number of octets of 'name' 419 name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." ) 420 value-length = SIGNED-SHORT ; number of octets of 'value' 421 value = OCTET-STRING 423 data = OCTET-STRING 425 zero-name-length = %x00.00 ; name-length of 0 426 value-tag = %x10-FF ;see section 3.7.2 427 begin-attribute-group-tag = %x00-02 / %04-0F ; see section 3.7.1 428 end-of-attributes-tag = %x03 ; tag of 3 429 ; see section 3.7.1 430 SIGNED-BYTE = BYTE 431 SIGNED-SHORT = 2BYTE 432 SIGNED-INTEGER = 4BYTE 433 DIGIT = %x30-39 ; "0" to "9" 434 LALPHA = %x61-7A ; "a" to "z" 435 BYTE = %x00-FF 436 OCTET-STRING = *BYTE 438 The syntax below defines additional terms that are referenced in this 439 document. This syntax provides an alternate grouping of the delimiter 440 tags. 442 delimiter-tag = begin-attribute-group-tag / ; see section 3.7.1 443 end-of-attributes-tag 444 delimiter-tag = %x00-0F ; see section 3.7.1 446 begin-attribute-group-tag = %x00 / operation-attributes-tag / 447 job-attributes-tag / printer-attributes-tag / 448 unsupported-attributes-tag / %x06-0F 449 operation-attributes-tag = %x01 ; tag of 1 450 job-attributes-tag = %x02 ; tag of 2 451 printer-attributes-tag = %x04 ; tag of 4 452 unsupported-attributes-tag = %x05 ; tag of 5 454 3.3 Attribute-group 456 Each "attribute-group" field MUST be encoded with the "begin-attribute- 457 group-tag" field followed by zero or more "attribute" sub-fields. 459 The table below maps the model document group name to value of the 460 "begin-attribute-group-tag" field: 462 Model Document Group "begin-attribute-group-tag" field 463 values 465 Operation Attributes "operations-attributes-tag" 466 Job Template Attributes "job-attributes-tag" 467 Job Object Attributes "job-attributes-tag" 468 Unsupported Attributes "unsupported-attributes-tag" 469 Requested Attributes "job-attributes-tag" 470 (Get-Job-Attributes) 471 Requested Attributes "printer-attributes-tag" 472 (Get-Printer-Attributes) 473 Document Content in a special position as described 474 above 476 For each operation request and response, the model document prescribes 477 the required and optional attribute groups, along with their order. 478 Within each attribute group, the model document prescribes the required 479 and optional attributes, along with their order. 481 When the Model document requires an attribute group in a request or 482 response and the attribute group contains zero attributes, a request or 483 response SHOULD encode the attribute group with the "begin-attribute- 484 group-tag" field followed by zero "attribute" fields. For example, if 485 the client requests a single unsupported attribute with the Get-Printer- 486 Attributes operation, the Printer MUST return no "attribute" fields, and 487 it SHOULD return a "begin-attribute-group-tag" field for the Printer 488 Attributes Group. The Unsupported Attributes group is not such an 489 example. According to the model document, the Unsupported Attributes 490 Group SHOULD be present only if the unsupported attributes group 491 contains at least one attribute. 493 A receiver of a request MUST be able to process the following as 494 equivalent empty attribute groups: 496 a) A "begin-attribute-group-tag" field with zero following 497 "attribute" fields. 499 b) An expected but missing "begin-attribute-group-tag" field. 501 When the Model document requires a sequence of an unknown number of 502 attribute groups, each of the same type, the encoding MUST contain one 503 "begin-attribute-group-tag" field for each attribute group even when an 504 "attribute-group" field contains zero "attribute" sub-fields. For 505 example, for the Get-Jobs operation may return zero attributes for some 506 jobs and not others. The "begin-attribute-group-tag" field followed by 507 zero "attribute" fields tells the recipient that there is a job in queue 508 for which no information is available except that it is in the queue. 510 3.4 Required Parameters 512 Some operation elements are called parameters in the model document 513 [ipp-mod]. They MUST be encoded in a special position and they MUST NOT 514 appear as operation attributes. These parameters are described in the 515 subsections below. 517 3.4.1 Version-number 519 The "version-number" field MUST consist of a major and minor version- 520 number, each of which MUST be represented by a SIGNED-BYTE. The major 521 version-number MUST be the first byte of the encoding and the minor 522 version-number MUST be the second byte of the encoding. The protocol 523 described in this document MUST have a major version-number of 1 (0x01) 524 and a minor version-number of 1 (0x01). The ABNF for these two bytes 525 MUST be %x01.01. 527 3.4.2 Operation-id 529 The "operation-id" field MUST contain an operation-id value defined in 530 the model document. The value MUST be encoded as a SIGNED-SHORT and it 531 MUST be in the third and fourth bytes of the encoding of an operation 532 request. 534 3.4.3 Status-code 536 The "status-code" field MUST contain a status-code value defined in the 537 model document. The value MUST be encoded as a SIGNED-SHORT and it MUST 538 be in the third and fourth bytes of the encoding of an operation 539 response. 541 The status-code is an operation attribute in the model document. In the 542 protocol, the status-code is in a special position, outside of the 543 operation attributes. 545 If an IPP status-code is returned, then the HTTP Status-Code MUST be 200 546 (successful-ok). With any other HTTP Status-Code value, the HTTP 547 response MUST NOT contain an IPP message-body, and thus no IPP status- 548 code is returned. 550 3.4.4 Request-id 552 The "request-id" field MUST contain a request-id value as defined in the 553 model document. The value MUST be encoded as a SIGNED- INTEGER and it 554 MUST be in the fifth through eighth bytes of the encoding. 556 3.5 Tags 558 There are two kinds of tags: 560 - delimiter tags: delimit major sections of the protocol, namely 561 attributes and data 562 - value tags: specify the type of each attribute value 564 3.5.1 Delimiter Tags 566 The following table specifies the values for the delimiter tags: 568 Tag Value (Hex) Meaning 570 0x00 reserved for definition in a future IETF 571 standards track document 572 0x01 "operation-attributes-tag" 573 0x02 "job-attribute-tag" 574 0x03 "end-of-attributes-tag" 575 0x04 "printer-attribute-tag" 576 0x05 "unsupported-attribute-tag" 577 0x06-0x0f reserved for future delimiters in IETF 578 standards track documents 580 When a "begin-attribute-group-tag" field occurs in the protocol, it 581 means that zero or more following attributes up to the next delimiter 582 tag MUST be attributes belonging to the attribute group specified by the 583 value of the "begin-attribute-group-tag". For example, if the value of 584 "begin-attribute-group-tag" is 0x01, the following attributes MUST be 585 members of the Operations Attributes group. 587 The "end-of-attributes-tag" (value 0x03) MUST occur exactly once in an 588 operation. It MUST be the last "delimiter-tag". If the operation has a 589 document-content group, the document data in that group MUST follow the 590 "end-of-attributes-tag". 592 The order and presence of "attribute-group" fields (whose beginning is 593 marked by the "begin-attribute-group-tag" subfield) for each operation 594 request and each operation response MUST be that defined in the model 595 document. For further details, see section 3.7 "(Attribute) Name" and 13 596 "Appendix A: Protocol Examples". 598 A Printer MUST treat a "delimiter-tag" (values from 0x00 through 0x0F) 599 differently from a "value-tag" (values from 0x10 through 0xFF) so that 600 the Printer knows that there is an entire attribute group that it 601 doesn't understand as opposed to a single value that it doesn't 602 understand. 604 3.5.2 Value Tags 606 The remaining tables show values for the "value-tag" field, which is the 607 first octet of an attribute. The "value-tag" field specifies the type of 608 the value of the attribute. 610 The following table specifies the "out-of-band" values for the "value- 611 tag" field. 613 Tag Value (Hex) Meaning 615 0x10 unsupported 616 0x11 reserved for 'default' for definition in a future 617 IETF standards track document 618 0x12 unknown 619 0x13 no-value 620 0x14-0x1F reserved for "out-of-band" values in future IETF 621 standards track documents. 623 The following table specifies the integer values for the "value-tag" 624 field: 626 Tag Value (Hex) Meaning 628 0x20 reserved for definition in a future IETF 629 standards track document 630 0x21 integer 631 0x22 boolean 632 0x23 enum 633 0x24-0x2F reserved for integer types for definition in 634 future IETF standards track documents 636 NOTE: 0x20 is reserved for "generic integer" if it should ever be 637 needed. 639 The following table specifies the octetString values for the "value-tag" 640 field: 642 Tag Value (Hex) Meaning 644 0x30 octetString with an unspecified format 645 0x31 dateTime 646 0x32 resolution 647 0x33 rangeOfInteger 648 0x34 reserved for definition in a future IETF 649 standards track document 650 0x35 textWithLanguage 651 0x36 nameWithLanguage 652 0x37-0x3F reserved for octetString type definitions in 653 future IETF standards track documents 655 The following table specifies the character-string values for the 656 "value-tag" field: 658 Tag Value (Hex) Meaning 660 0x40 reserved for definition in a future IETF 661 standards track document 662 0x41 textWithoutLanguage 663 0x42 nameWithoutLanguage 664 0x43 reserved for definition in a future IETF 665 standards track document 666 0x44 keyword 667 0x45 uri 668 0x46 uriScheme 669 0x47 charset 670 0x48 naturalLanguage 671 0x49 mimeMediaType 672 0x4A-0x5F reserved for character string type definitions 673 in future IETF standards track documents 675 NOTE: 0x40 is reserved for "generic character-string" if it should ever 676 be needed. 678 NOTE: an attribute value always has a type, which is explicitly 679 specified by its tag; one such tag value is "nameWithoutLanguage". An 680 attribute's name has an implicit type, which is keyword. 682 The values 0x60-0xFF are reserved for future type definitions in IETF 683 standards track documents. 685 The tag 0x7F is reserved for extending types beyond the 255 values 686 available with a single byte. A tag value of 0x7F MUST signify that the 687 first 4 bytes of the value field are interpreted as the tag value. Note 688 this future extension doesn't affect parsers that are unaware of this 689 special tag. The tag is like any other unknown tag, and the value length 690 specifies the length of a value, which contains a value that the parser 691 treats atomically. Values from 0x00 to 0x37777777 are reserved for 692 definition in future IETF standard track documents. The values 693 0x40000000 to 0x7FFFFFFF are reserved for vendor extensions. 695 3.6 Name-Length 697 The "name-length" field MUST consist of a SIGNED-SHORT. This field MUST 698 specify the number of octets in the immediately following "name" field. 699 The value of this field excludes the two bytes of the "name-length" 700 field. For example, if the "name" field contains "sides", the value of 701 this field is 5. 703 If a "name-length" field has a value of zero, the following "name" field 704 MUST be empty, and the following value MUST be treated as an additional 705 value for the attribute encoded in the nearest preceding "attribute- 706 with-one-value" field. Within an attribute group, if two or more 707 attributes have the same name, the attribute group is mal-formed (see 708 [ipp-mod] section 3.1.3). The zero-length name is the only mechanism for 709 multi-valued attributes. 711 3.7 (Attribute) Name 713 The "name " field MUST contain the name of an attribute. The model 714 document [ipp-mod] specifies such names. 716 3.8 Value Length 718 The "value-length" field MUST consist of a SIGNED-SHORT. This field MUST 719 specify the number of octets in the immediately following "value" field. 720 The value of this field excludes the two bytes of the "value-length" 721 field. For example, if the "value" field contains the keyword (text) 722 value 'one-sided', the value of this field is 9. 724 For any of the types represented by binary signed integers, the sender 725 MUST encode the value in exactly four octets. 727 For any of the types represented by character-strings, the sender MUST 728 encode the value with all the characters of the string and without any 729 padding characters. 731 For "out-of-band" "value-tag"s defined in this document, such as 732 "unsupported", the "value-length" MUST be 0 and the "value" empty; the 733 "value" has no meaning when the "value-tag" has one of these "out-of- 734 band" values. For future "out-of-band" "value-tag"s, the same rule holds 735 unless the definition explicitly states that the "value-length" MAY be 736 non-zero and the "value" non-empty 738 3.9 (Attribute) Value 740 The syntax types (specified by the "value-tag" field) and most of the 741 details of the representation of attribute values are defined in the IPP 742 model document. The table below augments the information in the model 743 document, and defines the syntax types from the model document in terms 744 of the 5 basic types defined in section 3 "Encoding of the Operation 745 Layer". The 5 types are US-ASCII-STRING, LOCALIZED-STRING, SIGNED- 746 INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET-STRING. 748 Syntax of Attribute Encoding 749 Value 751 textWithoutLanguage, LOCALIZED-STRING. 752 nameWithoutLanguage 754 textWithLanguage OCTET_STRING consisting of 4 fields: 755 a. a SIGNED-SHORT which is the number of 756 octets in the following field 757 b. a value of type natural-language, 758 c. a SIGNED-SHORT which is the number of 759 octets in the following field, 760 d. a value of type textWithoutLanguage. 761 The length of a textWithLanguage value MUST be 4 762 + the value of field a + the value of field c. 764 nameWithLanguage OCTET_STRING consisting of 4 fields: 765 a. a SIGNED-SHORT which is the number of 766 octets in the following field 767 b. a value of type natural-language, 768 c. a SIGNED-SHORT which is the number of 769 octets in the following field 770 d. a value of type nameWithoutLanguage. 771 The length of a nameWithLanguage value MUST be 4 772 + the value of field a + the value of field c. 774 charset, US-ASCII-STRING. 775 naturalLanguage, 776 mimeMediaType, 777 keyword, uri, and 778 uriScheme 780 boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is 781 'true'. 783 integer and enum a SIGNED-INTEGER. 785 dateTime OCTET-STRING consisting of eleven octets whose 786 contents are defined by "DateAndTime" in RFC 787 1903 [RFC1903]. 789 resolution OCTET_STRING consisting of nine octets of 2 790 SIGNED-INTEGERs followed by a SIGNED-BYTE. The 791 first SIGNED-INTEGER contains the value of cross 792 feed direction resolution. The second SIGNED- 793 INTEGER contains the value of feed direction 794 resolution. The SIGNED-BYTE contains the units 796 Syntax of Attribute Encoding 797 Value 799 value. 801 rangeOfInteger Eight octets consisting of 2 SIGNED-INTEGERs. 802 The first SIGNED-INTEGER contains the lower 803 bound and the second SIGNED-INTEGER contains the 804 upper bound. 806 1setOf X Encoding according to the rules for an attribute 807 with more than 1 value. Each value X is encoded 808 according to the rules for encoding its type. 810 octetString OCTET-STRING 812 The attribute syntax type of the value determines its encoding and the 813 value of its "value-tag". 815 3.10 Data 817 The "data" field MUST include any data required by the operation 819 4. Encoding of Transport Layer 821 HTTP/1.1 [RFC2616] is the transport layer for this protocol. 823 The operation layer has been designed with the assumption that the 824 transport layer contains the following information: 826 - the URI of the target job or printer operation 827 - the total length of the data in the operation layer, either as a 828 single length or as a sequence of chunks each with a length. 830 It is REQUIRED that a printer implementation support HTTP over the IANA 831 assigned Well Known Port 631 (the IPP default port), though a printer 832 implementation may support HTTP over some other port as well. 834 Each HTTP operation MUST use the POST method where the request-URI is 835 the object target of the operation, and where the "Content-Type" of the 836 message-body in each request and response MUST be "application/ipp". The 837 message-body MUST contain the operation layer and MUST have the syntax 838 described in section 3.2 "Syntax of Encoding". A client implementation 839 MUST adhere to the rules for a client described for HTTP1.1 [RFC2616] . 840 A printer (server) implementation MUST adhere the rules for an origin 841 server described for HTTP1.1 [RFC2616]. 843 An IPP server sends a response for each request that it receives. If an 844 IPP server detects an error, it MAY send a response before it has read 845 the entire request. If the HTTP layer of the IPP server completes 846 processing the HTTP headers successfully, it MAY send an intermediate 847 response, such as "100 Continue", with no IPP data before sending the 848 IPP response. A client MUST expect such a variety of responses from an 849 IPP server. For further information on HTTP/1.1, consult the HTTP 850 documents [RFC2616]. 852 An HTTP server MUST support chunking for IPP requests, and an IPP client 853 MUST support chunking for IPP responses according to HTTP/1.1[RFC2616]. 854 Note: this rule causes a conflict with non-compliant implementations of 855 HTTP/1.1 that don't support chunking for POST methods, and this rule may 856 cause a conflict with non-compliant implementations of HTTP/1.1 that 857 don't support chunking for CGI scripts 859 4.1 Printer-uri and job-uri 861 All Printer and Job objects are identified by a Uniform Resource 862 Identifier (URI) [RFC2396] so that they can be persistently and 863 unambiguously referenced. The notion of a URI is a useful concept, 864 however, until the notion of URI is more stable (i.e., defined more 865 completely and deployed more widely), it is expected that the URIs used 866 for IPP objects will actually be URLs [RFC1738] [RFC1808]. Since every 867 URL is a specialized form of a URI, even though the more generic term 868 URI is used throughout the rest of this document, its usage is intended 869 to cover the more specific notion of URL as well. 871 Some operation elements are encoded twice, once as the request-URI on 872 the HTTP Request-Line and a second time as a REQUIRED operation 873 attribute in the application/ipp entity. These attributes are the 874 target URI for the operation and are called printer-uri and job-uri. 875 Note: The target URI is included twice in an operation referencing the 876 same IPP object, but the two URIs NEED NOT be literally identical. One 877 can be a relative URI and the other can be an absolute URI. HTTP/1.1 878 allows clients to generate and send a relative URI rather than an 879 absolute URI. A relative URI identifies a resource with the scope of 880 the HTTP server, but does not include scheme, host or port. The 881 following statements characterize how URLs should be used in the mapping 882 of IPP onto HTTP/1.1: 884 1. Although potentially redundant, a client MUST supply the target of 885 the operation both as an operation attribute and as a URI at the 886 HTTP layer. The rationale for this decision is to maintain a 887 consistent set of rules for mapping application/ipp to possibly 888 many communication layers, even where URLs are not used as the 889 addressing mechanism in the transport layer. 890 2. Even though these two URLs might not be literally identical (one 891 being relative and the other being absolute), they MUST both 892 reference the same IPP object. However, a Printer NEED NOT verify 893 that the two URLs reference the same IPP object, and NEED NOT take 894 any action if it determines the two URLs to be different. 895 3. The URI in the HTTP layer is either relative or absolute and is 896 used by the HTTP server to route the HTTP request to the correct 897 resource relative to that HTTP server. The HTTP server need not 898 be aware of the URI within the operation request. 899 4. Once the HTTP server resource begins to process the HTTP request, 900 it might get the reference to the appropriate IPP Printer object 901 from either the HTTP URI (using to the context of the HTTP server 902 for relative URLs) or from the URI within the operation request; 903 the choice is up to the implementation. 904 5. HTTP URIs can be relative or absolute, but the target URI in the 905 operation MUST be an absolute URI. 907 5. IPP URL Scheme 909 The IPP/1.1 document defines a new scheme 'ipp' as the value of a URL 910 that identifies either an IPP printer object or an IPP job object. The 911 IPP attributes using the 'ipp' scheme are specified below. Because the 912 HTTP layer does not support the 'ipp' scheme, a client MUST map 'ipp' 913 URLs to 'http' URLs, and then follows the HTTP [RFC2616][RFC2617] rules 914 for constructing a Request-Line and HTTP headers. The mapping is simple 915 because the 'ipp' scheme implies all of the same protocol semantics as 916 that of the 'http' scheme [RFC2616], except that it represents a print 917 service and the implicit (default) port number that clients use to 918 connect to a server is port 631. 920 In the remainder of this section the term 'ipp-URL' means a URL whose 921 scheme is 'ipp' and whose implicit (default) port is 631. The term 922 'http-URL' means a URL whose scheme is 'http', and the term 'https-URL' 923 means a URL whose scheme is 'https', 925 A client and an IPP object (i.e. the server) MUST support the ipp-URL 926 value in the following IPP attributes. 927 job attributes: 928 job-uri 929 job-printer-uri 930 printer attributes: 931 printer-uri-supported 932 operation attributes: 933 job-uri 934 printer-uri 935 Each of the above attributes identifies a printer or job object. The 936 ipp-URL is intended as the value of the attributes in this list, and for 937 no other attributes. All of these attributes have a syntax type of 938 'uri', but there are attributes with a syntax type of 'uri' that do not 939 use the 'ipp' scheme, e.g. 'job-more-info'. 941 If a printer registers its URL with a directory service, the printer 942 MUST register an ipp-URL. 944 User interfaces are beyond the scope of this document. But if software 945 exposes the ipp-URL values of any of the above five attributes to a 946 human user, it is REQUIRED that the human see the ipp-URL as is. 948 When a client sends a request, it MUST convert a target ipp-URL to a 949 target http-URL for the HTTP layer according to the following rules: 950 1. change the 'ipp' scheme to 'http' 951 2. add an explicit port 631 if the URL does not contain an explicit 952 port. Note: port 631 is the IANA assigned Well Known Port for the 953 'ipp' scheme. 955 The client MUST use the target http-URL in both the HTTP Request-Line 956 and HTTP headers, as specified by HTTP[RFC2616][RFC2617] . However, the 957 client MUST use the target ipp-URL for the value of the "printer-uri" or 958 "job-uri" operation attribute within the application/ipp body of the 959 request. The server MUST use the ipp-URL for the value of the "printer- 960 uri", "job-uri" or "printer-uri-supported" attributes within the 961 application/ipp body of the response. 963 For example, when an IPP client sends a request directly (i.e. no proxy) 964 to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a TCP 965 connection to port 631 (the ipp implicit port) on the host "myhost.com" 966 and sends the following data: 968 POST /myprinter/myqueue HTTP/1.1 969 Host: myhost.com:631 970 Content-type: application/ipp 971 Transfer-Encoding: chunked 972 ... 973 "printer-uri" "ipp://myhost.com/myprinter/myqueue" 974 (encoded in application/ipp message body) 975 ... 977 As another example, when an IPP client sends the same request as above 978 via a proxy "myproxy.com", it opens a TCP connection to the proxy port 979 8080 on the proxy host "myproxy.com" and sends the following data: 981 POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 982 Host: myhost.com:631 983 Content-type: application/ipp 984 Transfer-Encoding: chunked 985 ... 986 "printer-uri" "ipp://myhost.com/myprinter/myqueue" 987 (encoded in application/ipp message body) 988 ... 990 The proxy then connects to the IPP origin server with headers that are 991 the same as the "no-proxy" example above. 993 6. IANA Considerations 995 This section describes the procedures for allocating encoding for the 996 following IETF standards track extensions and vendor extensions to the 997 IPP/1.1 Encoding and Transport document: 999 1. attribute syntaxes - see [ipp-mod] section 6.3 1000 2. attribute groups - see [ipp-mod] section 6.5 1001 3. out-of-band attribute values - see [ipp-mod] section 6.7 1003 These extensions follow the "type2" registration procedures defined in 1004 [ipp-mod] section 6. Extensions registered for use with IPP/1.1 are 1005 OPTIONAL for client and IPP object conformance to the IPP/1.1 Encoding 1006 and Transport document. 1008 These extension procedures are aligned with the guidelines as set forth 1009 by the IESG [IANA-CON]. The [ipp-mod] Section 11 describes how to 1010 propose new registrations for consideration. IANA will reject 1011 registration proposals that leave out required information or do not 1012 follow the appropriate format described in [ipp-mod] Section 11. The 1013 IPP/1.1 Encoding and Transport document may also be extended by an 1014 appropriate RFC that specifies any of the above extensions. 1016 7. Internationalization Considerations 1018 See the section on "Internationalization Considerations" in the document 1019 "Internet Printing Protocol/1.1: Model and Semantics" [ipp-mod] for 1020 information on internationalization. This document adds no additional 1021 issues. 1023 8. Security Considerations 1025 The IPP Model and Semantics document [ipp-mod] discusses high level 1026 security requirements (Client Authentication, Server Authentication and 1027 Operation Privacy). Client Authentication is the mechanism by which the 1028 client proves its identity to the server in a secure manner. Server 1029 Authentication is the mechanism by which the server proves its identity 1030 to the client in a secure manner. Operation Privacy is defined as a 1031 mechanism for protecting operations from eavesdropping. 1033 8.1 Security Conformance Requirements 1035 This section defines the security requirements for IPP clients and IPP 1036 objects. 1038 8.1.1 Digest Authentication 1040 IPP clients MUST support: 1042 Digest Authentication [RFC2617]. 1044 MD5 and MD5-sess MUST be implemented and supported. 1046 The Message Integrity feature NEED NOT be used. 1048 IPP Printers SHOULD support: 1050 Digest Authentication [RFC2617]. 1052 MD5 and MD5-sess MUST be implemented and supported. 1054 The Message Integrity feature NEED NOT be used. 1056 The reasons that IPP Printers SHOULD (rather than MUST) support Digest 1057 Authentication are: 1059 1.While Client Authentication is important, there is a certain class of 1060 printer devices where it does not make sense. Specifically, a low- 1061 end device with limited ROM space and low paper throughput may not 1062 need Client Authentication. This class of device typically requires 1063 firmware designers to make trade-offs between protocols and 1064 functionality to arrive at the lowest-cost solution possible. 1065 Factored into the designer's decisions is not just the size of the 1066 code, but also the testing, maintenance, usefulness, and time-to- 1067 market impact for each feature delivered to the customer. Forcing 1068 such low-end devices to provide security in order to claim IPP/1.1 1069 conformance would not make business sense and could potentially stall 1070 the adoption of the standard. 1072 2.Print devices that have high-volume throughput and have available ROM 1073 space have a compelling argument to provide support for Client 1074 Authentication that safeguards the device from unauthorized access. 1075 These devices are prone to a high loss of consumables and paper if 1076 unauthorized access should occur. 1078 8.1.2 Transport Layer Security (TLS) 1080 IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246] for 1081 Server Authentication and Operation Privacy. IPP Printers MAY also 1082 support TLS for Client Authentication. If an IPP Printer supports TLS, 1083 it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as 1084 mandated by RFC 2246 [RFC2246]. All other cipher suites are OPTIONAL. 1085 An IPP Printer MAY support Basic Authentication (described in HTTP/1.1 1086 [RFC2617]) for Client Authentication if the channel is secure. TLS with 1087 the above mandated cipher suite can provide such a secure channel. 1089 If a IPP client supports TLS, it MUST support the 1090 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246 1091 [RFC2246]. All other cipher suites are OPTIONAL. 1093 The IPP Model and Semantics document defines two printer attributes 1094 ("uri-authentication-supported" and "uri-security-supported") that the 1095 client can use to discover the security policy of a printer. That 1096 document also outlines IPP-specific security considerations and should 1097 be the primary reference for security implications with regard to the 1098 IPP protocol itself. For backward compatibility with IPP version 1.0, 1099 IPP clients and printers may also support SSL3 [ssl]. This is in 1100 addition to the security required in this document. 1102 8.2 Using IPP with TLS 1104 IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism [RFC2817]. 1105 An initial IPP request never uses TLS. The client requests a secure TLS 1106 connection by using the HTTP "Upgrade" header, while the server agrees 1107 in the HTTP response. The switch to TLS occurs either because the 1108 server grants the client's request to upgrade to TLS, or a server asks 1109 to switch to TLS in its response. Secure communication begins with a 1110 server's response to switch to TLS. 1112 9. Interoperability with IPP/1.0 Implementations 1114 It is beyond the scope of this specification to mandate conformance with 1115 previous versions. IPP/1.1 was deliberately designed, however, to make 1116 supporting previous versions easy. It is worth noting that, at the time 1117 of composing this specification (1999), we would expect IPP/1.1 Printer 1118 implementations to: 1120 understand any valid request in the format of IPP/1.0, or 1.1; 1122 respond appropriately with a response containing the same "version- 1123 number" parameter value used by the client in the request. 1125 And we would expect IPP/1.1 clients to: 1127 understand any valid response in the format of IPP/1.0, or 1.1. 1129 9.1 The "version-number" Parameter 1131 The following are rules regarding the "version-number" parameter (see 1132 section 3.3): 1134 1. Clients MUST send requests containing a "version-number" parameter 1135 with a '1.1' value and SHOULD try supplying alternate version 1136 numbers if they receive a 'server-error-version-not-supported' 1137 error return in a response. 1139 2. IPP objects MUST accept requests containing a "version-number" 1140 parameter with a '1.1' value (or reject the request for reasons 1141 other than 'server-error-version-not-supported'). 1143 3. It is recommended that IPP objects accept any request with the 1144 major version '1' (or reject the request for reasons other than 1145 'server-error-version-not-supported'). See [ipp-mod] "versions" 1146 sub-section. 1148 4. In any case, security MUST NOT be compromised when a client 1149 supplies a lower "version-number" parameter in a request. For 1150 example, if an IPP/1.1 conforming Printer object accepts version 1151 '1.0' requests and is configured to enforce Digest Authentication, 1152 it MUST do the same for a version '1.0' request. 1154 9.2 Security and URL Schemes 1156 The following are rules regarding security, the "version-number" 1157 parameter, and the URL scheme supplied in target attributes and 1158 responses: 1160 1. When a client supplies a request, the "printer-uri" or "job-uri" 1161 target operation attribute MUST have the same scheme as that 1162 indicated in one of the values of the "printer-uri-supported" 1163 Printer attribute. 1165 2. When the server returns the "job-printer-uri" or "job-uri" Job 1166 Description attributes, it SHOULD return the same scheme ('ipp', 1167 'https', 'http', etc.) that the client supplied in the "printer- 1168 uri" or "job-uri" target operation attributes in the Get-Job- 1169 Attributes or Get-Jobs request, rather than the scheme used when 1170 the job was created. However, when a client requests job 1171 attributes using the Get-Job-Attributes or Get-Jobs operations, 1172 the jobs and job attributes that the server returns depends on: 1173 (1) the security in effect when the job was created, (2) the 1174 security in effect in the query request, and (3) the security 1175 policy in force. 1177 3. It is recommended that if a server registers a non-secure ipp-URL 1178 with a directory service (see [IPP-MOD] "Generic Directory Schema" 1179 Appendix), then it also register an http-URL for interoperability 1180 with IPP/1.0 clients (see section 9). 1182 4. In any case, security MUST NOT be compromised when a client 1183 supplies an 'http' or other non-secure URL scheme in the target 1184 "printer-uri" and "job-uri" operation attributes in a request. 1186 10. References 1188 [dpa] ISO/IEC 10175 Document Printing Application (DPA), June 1996. 1190 [iana]IANA Registry of Coded Character Sets: ftp://ftp.isi.edu/in- 1191 notes/iana/assignments/character-sets. 1193 [ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.1: 1194 Implementer's Guide", draft-ietf-ipp-implementers-guide-v11- 1195 00.txt, work in progress, September 27, 1999. 1197 [ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1198 "Internet Printing Protocol/1.1: Model and Semantics", , May 22, 2000. 1201 [ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet 1202 Printing Protocol/1.1: Encoding and Transport", draft-ietf-ipp- 1203 protocol-v11-06.txt, May 30, 2000. 1205 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text 1206 Messages", RFC 822, August 1982. 1208 [RFC1123] Braden, S., "Requirements for Internet Hosts - Application 1209 and Support", RFC 1123, October, 1989. 1211 [RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" 1212 RFC 1179, August 1990. 1214 [RFC1543] Postel, J., "Instructions to RFC Authors", RFC 1543, October 1215 1993. 1217 [RFC1738] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform 1218 Resource Locators (URL)", RFC 1738, December, 1994. 1220 [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and 1221 Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. 1223 [RFC1766] H. Alvestrand, " Tags for the Identification of Languages", 1224 RFC 1766, March 1995. 1226 [RFC1808] R. Fielding, "Relative Uniform Resource Locators", RFC1808, 1227 June 1995. 1229 [RFC1903] J. Case, et al. "Textual Conventions for Version 2 of the 1230 Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1231 1996. 1233 [RFC2046] N. Freed & N. Borenstein, Multipurpose Internet Mail 1234 Extensions (MIME) Part Two: Media Types. November 1996, RFC 2046. 1236 [RFC2048] N. Freed, J. Klensin & J. Postel. Multipurpose Internet Mail 1237 Extension (MIME) Part Four: Registration Procedures. November 1238 1996 (Also BCP0013), RFC 2048. 1240 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1241 Requirement Levels", RFC 2119 , March 1997. 1243 [RFC2184] N. Freed, K. Moore, "MIME Parameter Value and Encoded Word 1244 Extensions: Character Sets, Languages, and Continuations", RFC 1245 2184, August 1997. 1247 [RFC2234] D. Crocker et al., "Augmented BNF for Syntax Specifications: 1248 ABNF", RFC 2234. November 1997. 1250 [RFC2246] T. Dierks et al., "The TLS Protocol", RFC 2246. January 1999. 1252 [RFC2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform 1253 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1254 1998. 1256 [RFC2565] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet 1257 Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1258 1999. 1260 [RFC2566] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1261 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, 1262 April, 1999. 1264 [RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", 1265 RFC2567, April 1999. 1267 [RFC2568] Zilles, S., "Rationale for the Structure and Model and 1268 Protocol for the Internet Printing Protocol", RC 2568, April 1269 1999. 1271 [RFC2569] Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping 1272 between LPD and IPP Protocols RFC 2569, April 1999. 1274 [RFC2616] 1275 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1276 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 1277 RFC 2616, June 1999. 1279 [RFC2617] 1280 J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, 1281 A. Luotonen, L. Stewart, "HTTP Authentication: Basic and Digest 1282 Access Authentication", RFC 2617, June 1999. 1284 [RFC2817] R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1", 1285 RFC 2817, May 2000. 1287 [SSL] 1288 Netscape, The SSL Protocol, Version 3, (Text version 3.02), 1289 November 1996. 1291 11. Author's Address 1293 Robert Herriot (editor) Paul Moore 1294 Xerox Corporation Peerless Systems Networking 1295 3400 Hillview Ave., Bldg #1 10900 NE 8th St #900 1296 Palo Alto, CA 94304 Bellevue, WA 98004 1298 Phone: 650-813-7696 Phone: 425-462-5852 1299 Fax: 650-813-6860 1300 Email: Email: pmoore@peerless.com 1301 robert.herriot@pahv.xerox.com 1303 Sylvan Butler Randy Turner 1304 Hewlett-Packard 2Wire, Inc. 1305 11311 Chinden Blvd. 694 Tasman Dr. 1306 Boise, ID 83714 Milpitas, CA 95035 1308 Phone: 208-396-6000 Phone: 408-546-1273 1309 Fax: 208-396-3457 1310 Email: sbutler@boi.hp.com 1312 John Wenn 1313 Xerox Corporation 1314 737 Hawaii St 1315 El Segundo, CA 90245 1317 IPP Mailing List: ipp@pwg.org Phone: 310-333-5764 1318 IPP Mailing List Subscription: Fax: 310-333-5514 1319 ipp-request@pwg.org 1320 IPP Web Page: Email: jwenn@cp10.es.xerox.com 1321 http://www.pwg.org/ipp/ 1323 12. Other Participants: 1325 Chuck Adams - Tektronix Shivaun Albright - HP 1326 Stefan Andersson - Axis Jeff Barnett - IBM 1327 Ron Bergman - Hitachi Koki Imaging Dennis Carney - IBM 1328 Systems 1329 Keith Carter - IBM Angelo Caruso - Xerox 1330 Rajesh Chawla - TR Computing Nancy Chen - Okidata 1331 Solutions 1332 Josh Cohen - Microsoft Jeff Copeland - QMS 1333 Andy Davidson - Tektronix Roger deBry - IBM 1334 Maulik Desai - Auco Mabry Dozier - QMS 1335 Lee Farrell - Canon Information Satoshi Fujitami - Ricoh 1336 Systems 1337 Steve Gebert - IBM Sue Gleeson - Digital 1338 Charles Gordon - Osicom Brian Grimshaw - Apple 1339 Jerry Hadsell - IBM Richard Hart - Digital 1340 Tom Hastings - Xerox Henrik Holst - I-data 1341 Stephen Holmstead Zhi-Hong Huang - Zenographics 1342 Scott Isaacson - Novell Babek Jahromi - Microsoft 1343 Swen Johnson - Xerox David Kellerman - Northlake 1344 Software 1345 Robert Kline - TrueSpectra Charles Kong - Panasonic 1346 Carl Kugler - IBM Dave Kuntz - Hewlett-Packard 1347 Takami Kurono - Brother Rick Landau - Digital 1348 Scott Lawrence - Agranot Systems Greg LeClair - Epson 1349 Dwight Lewis - Lexmark Harry Lewis - IBM 1350 Tony Liao - Vivid Image Roy Lomicka - Digital 1351 Pete Loya - HP Ray Lutz - Cognisys 1352 Mike MacKay - Novell, Inc. David Manchala - Xerox 1353 Carl-Uno Manros - Xerox Jay Martin - Underscore 1354 Stan McConnell - Xerox Larry Masinter - Xerox 1355 Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft 1356 Ira McDonald - High North Inc. Mike Moldovan - G3 Nova 1357 Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh 1358 Pat Nogay - IBM Ron Norton - Printronics 1359 Hugo Parra, Novell Bob Pentecost - Hewlett-Packard 1360 Patrick Powell - Astart Jeff Rackowitz - Intermec 1361 Technologies 1362 Eric Random - Peerless Rob Rhoads - Intel 1363 Xavier Riley - Xerox Gary Roberts - Ricoh 1364 David Roach - Unisys Stuart Rowley - Kyocera 1365 Yuji Sasaki - Japan Computer Richard Schneider - Epson 1366 Industry 1367 Kris Schoff - HP Katsuaki Sekiguchi - Canon 1368 Information Systems 1369 Bob Setterbo - Adobe Gail Songer - Peerless 1370 Hideki Tanaka - Cannon Information Devon Taylor - Novell, Inc. 1371 Systems 1372 Mike Timperman - Lexmark Atsushi Uchino - Epson 1373 Shigeru Ueda - Canon Bob Von Andel - Allegro Software 1374 William Wagner - NetSilicon/DPI Jim Walker - DAZEL 1375 Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard 1376 Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc. 1377 Jasper Wong - Xionics Don Wright - Lexmark 1378 Michael Wu - Heidelberg Digital Rick Yardumian - Xerox 1379 Michael Yeung - Canon Information Lloyd Young - Lexmark 1380 Systems 1381 Atsushi Yuki - Kyocera Peter Zehler - Xerox 1382 William Zhang- Canon Information Frank Zhao - Panasonic 1383 Systems 1384 Steve Zilles - Adobe Rob Zirnstein - Canon Information 1385 Systems 1387 13. Appendix A: Protocol Examples 1389 13.1 Print-Job Request 1391 The following is an example of a Print-Job request with job-name, 1392 copies, and sides specified. The "ipp-attribute-fidelity" attribute is 1393 set to 'true' so that the print request will fail if the "copies" or the 1394 "sides" attribute are not supported or their values are not supported. 1396 Octets Symbolic Value Protocol field 1398 0x0101 1.1 version-number 1399 0x0002 Print-Job operation-id 1400 0x00000001 1 request-id 1401 0x01 start operation-attributes operation-attributes-tag 1402 0x47 charset type value-tag 1403 0x0012 name-length 1404 attributes- attributes-charset name 1405 charset 1406 0x0008 value-length 1407 us-ascii US-ASCII value 1408 0x48 natural-language type value-tag 1409 0x001B name-length 1410 attributes- name 1411 natural- attributes-natural-language 1412 language 1413 0x0005 value-length 1414 en-us en-US value 1415 0x45 uri type value-tag 1416 0x000B name-length 1417 printer-uri printer-uri name 1418 0x0015 value-length 1419 ipp://forest/p printer pinetree value 1420 inetree 1421 0x42 nameWithoutLanguage type value-tag 1422 0x0008 name-length 1423 job-name job-name name 1424 0x0006 value-length 1425 foobar foobar value 1426 0x22 boolean type value-tag 1427 0x0016 name-length 1428 ipp-attribute- ipp-attribute-fidelity name 1429 fidelity 1430 0x0001 value-length 1431 0x01 true value 1432 Octets Symbolic Value Protocol field 1434 0x02 start job-attributes job-attributes-tag 1435 0x21 integer type value-tag 1436 0x0006 name-length 1437 copies copies name 1438 0x0004 value-length 1439 0x00000014 20 value 1440 0x44 keyword type value-tag 1441 0x0005 name-length 1442 sides sides name 1443 0x0013 value-length 1444 two-sided- two-sided-long-edge value 1445 long-edge 1446 0x03 end-of-attributes end-of-attributes-tag 1447 %!PS... data 1449 13.2 Print-Job Response (successful) 1451 Here is an example of a successful Print-Job response to the previous 1452 Print-Job request. The printer supported the "copies" and "sides" 1453 attributes and their supplied values. The status code returned is 1454 'successful-ok'. 1456 Octets Symbolic Value Protocol field 1458 0x0101 1.1 version-number 1459 0x0000 successful-ok status-code 1460 0x00000001 1 request-id 1461 0x01 start operation-attributes operation-attributes-tag 1462 0x47 charset type value-tag 1463 0x0012 name-length 1464 attributes- attributes-charset name 1465 charset 1466 0x0008 value-length 1467 us-ascii US-ASCII value 1468 0x48 natural-language type value-tag 1469 0x001B name-length 1470 attributes- attributes-natural- name 1471 natural-language language 1472 0x0005 value-length 1473 en-us en-US value 1474 0x41 textWithoutLanguage type value-tag 1475 0x000E name-length 1476 status-message status-message name 1477 0x000D value-length 1478 Octets Symbolic Value Protocol field 1480 successful-ok successful-ok value 1481 0x02 start job-attributes job-attributes-tag 1482 0x21 integer value-tag 1483 0x0006 name-length 1484 job-id job-id name 1485 0x0004 value-length 1486 147 147 value 1487 0x45 uri type value-tag 1488 0x0007 name-length 1489 job-uri job-uri name 1490 0x0019 value-length 1491 ipp://forest/pin job 123 on pinetree value 1492 etree/123 1493 0x23 enum type value-tag 1494 0x0009 name-length 1495 job-state job-state name 1496 0x0004 value-length 1497 0x0003 pending value 1498 0x03 end-of-attributes end-of-attributes-tag 1500 13.3 Print-Job Response (failure) 1502 Here is an example of an unsuccessful Print-Job response to the previous 1503 Print-Job request. It fails because, in this case, the printer does not 1504 support the "sides" attribute and because the value '20' for the 1505 "copies" attribute is not supported. Therefore, no job is created, and 1506 neither a "job-id" nor a "job-uri" operation attribute is returned. The 1507 error code returned is 'client-error-attributes-or-values-not-supported' 1508 (0x040B). 1510 Octets Symbolic Value Protocol field 1512 0x0101 1.1 version-number 1513 0x040B client-error-attributes-or- status-code 1514 values-not-supported 1515 0x00000001 1 request-id 1516 0x01 start operation-attributes operation-attribute tag 1517 0x47 charset type value-tag 1518 0x0012 name-length 1519 attributes- attributes-charset name 1520 charset 1521 0x0008 value-length 1522 us-ascii US-ASCII value 1523 Octets Symbolic Value Protocol field 1525 0x48 natural-language type value-tag 1526 0x001B name-length 1527 attributes- attributes-natural-language name 1528 natural- 1529 language 1530 0x0005 value-length 1531 en-us en-US value 1532 0x41 textWithoutLanguage type value-tag 1533 0x000E name-length 1534 status- status-message name 1535 message 1536 0x002F value-length 1537 client-error- value 1538 attributes- values-not-supported 1539 or-values- client-error-attributes-or- 1540 not-supported 1541 0x05 start unsupported-attributes unsupported-attributes tag 1542 0x21 integer type value-tag 1543 0x0006 name-length 1544 copies copies name 1545 0x0004 value-length 1546 0x00000014 20 value 1547 0x10 unsupported (type) value-tag 1548 0x0005 name-length 1549 sides sides name 1550 0x0000 value-length 1551 0x03 end-of-attributes end-of-attributes-tag 1553 13.4 Print-Job Response (success with attributes ignored) 1555 Here is an example of a successful Print-Job response to a Print-Job 1556 request like the previous Print-Job request, except that the value of 1557 'ipp-attribute-fidelity' is false. The print request succeeds, even 1558 though, in this case, the printer supports neither the "sides" attribute 1559 nor the value '20' for the "copies" attribute. Therefore, a job is 1560 created, and both a "job-id" and a "job-uri" operation attribute are 1561 returned. The unsupported attributes are also returned in an Unsupported 1562 Attributes Group. The error code returned is 'successful-ok-ignored-or- 1563 substituted-attributes' (0x0001). 1565 Octets Symbolic Value Protocol field 1567 0x0101 1.1 version-number 1568 0x0001 successful-ok-ignored-or- status-code 1569 Octets Symbolic Value Protocol field 1571 substituted-attributes 1572 0x00000001 1 request-id 1573 0x01 start operation-attributes operation-attributes-tag 1574 0x47 charset type value-tag 1575 0x0012 name-length 1576 attributes- attributes-charset name 1577 charset 1578 0x0008 value-length 1579 us-ascii US-ASCII value 1580 0x48 natural-language type value-tag 1581 0x001B name-length 1582 attributes- attributes-natural- name 1583 natural-language language 1584 0x0005 value-length 1585 en-us en-US value 1586 0x41 textWithoutLanguage type value-tag 1587 0x000E name-length 1588 status-message status-message name 1589 0x002F value-length 1590 successful-ok- successful-ok-ignored-or- value 1591 ignored-or- substituted-attributes 1592 substituted- 1593 attributes 1594 0x05 start unsupported- unsupported-attributes 1595 attributes tag 1596 0x21 integer type value-tag 1597 0x0006 name-length 1598 copies copies name 1599 0x0004 value-length 1600 0x00000014 20 value 1601 0x10 unsupported (type) value-tag 1602 0x0005 name-length 1603 sides sides name 1604 0x0000 value-length 1605 0x02 start job-attributes job-attributes-tag 1606 0x21 integer value-tag 1607 0x0006 name-length 1608 job-id job-id name 1609 0x0004 value-length 1610 147 147 value 1611 0x45 uri type value-tag 1612 0x0007 name-length 1613 job-uri job-uri name 1614 0x0019 value-length 1615 ipp://forest/pin job 123 on pinetree value 1616 Octets Symbolic Value Protocol field 1618 etree/123 1619 0x23 enum type value-tag 1620 0x0009 name-length 1621 job-state job-state name 1622 0x0004 value-length 1623 0x0003 pending value 1624 0x03 end-of-attributes end-of-attributes-tag 1626 13.5 Print-URI Request 1628 The following is an example of Print-URI request with copies and job- 1629 name parameters: 1631 Octets Symbolic Value Protocol field 1633 0x0101 1.1 version-number 1634 0x0003 Print-URI operation-id 1635 0x00000001 1 request-id 1636 0x01 start operation-attributes operation-attributes-tag 1637 0x47 charset type value-tag 1638 0x0012 name-length 1639 attributes- attributes-charset name 1640 charset 1641 0x0008 value-length 1642 us-ascii US-ASCII value 1643 0x48 natural-language type value-tag 1644 0x001B name-length 1645 attributes- attributes-natural-language name 1646 natural- 1647 language 1648 0x0005 value-length 1649 en-us en-US value 1650 0x45 uri type value-tag 1651 0x000B name-length 1652 printer-uri printer-uri name 1653 0x0015 value-length 1654 ipp://forest/ printer pinetree value 1655 pinetree 1656 0x45 uri type value-tag 1657 0x000C name-length 1658 document-uri document-uri name 1659 0x0011 value-length 1660 ftp://foo.com ftp://foo.com/foo value 1661 Octets Symbolic Value Protocol field 1663 /foo 1664 0x42 nameWithoutLanguage type value-tag 1665 0x0008 name-length 1666 job-name job-name name 1667 0x0006 value-length 1668 foobar foobar value 1669 0x02 start job-attributes job-attributes-tag 1670 0x21 integer type value-tag 1671 0x0006 name-length 1672 copies copies name 1673 0x0004 value-length 1674 0x00000001 1 value 1675 0x03 end-of-attributes end-of-attributes-tag 1677 13.6 Create-Job Request 1679 The following is an example of Create-Job request with no parameters and 1680 no attributes: 1682 Octets Symbolic Value Protocol field 1684 0x0101 1.1 version-number 1685 0x0005 Create-Job operation-id 1686 0x00000001 1 request-id 1687 0x01 start operation-attributes operation-attributes-tag 1688 0x47 charset type value-tag 1689 0x0012 name-length 1690 attributes- attributes-charset name 1691 charset 1692 0x0008 value-length 1693 us-ascii US-ASCII value 1694 0x48 natural-language type value-tag 1695 0x001B name-length 1696 attributes- attributes-natural-language name 1697 natural- 1698 language 1699 0x0005 value-length 1700 en-us en-US value 1701 0x45 uri type value-tag 1702 0x000B name-length 1703 printer-uri printer-uri name 1704 0x0015 value-length 1705 ipp://forest/p printer pinetree value 1706 Octets Symbolic Value Protocol field 1708 inetree 1709 0x03 end-of-attributes end-of-attributes-tag 1711 13.7 Get-Jobs Request 1713 The following is an example of Get-Jobs request with parameters but no 1714 attributes: 1716 Octets Symbolic Value Protocol field 1718 0x0101 1.1 version-number 1719 0x000A Get-Jobs operation-id 1720 0x00000123 0x123 request-id 1721 0x01 start operation-attributes operation-attributes-tag 1722 0x47 charset type value-tag 1723 0x0012 name-length 1724 attributes- attributes-charset name 1725 charset 1726 0x0008 value-length 1727 us-ascii US-ASCII value 1728 0x48 natural-language type value-tag 1729 0x001B name-length 1730 attributes- attributes-natural-language name 1731 natural- 1732 language 1733 0x0005 value-length 1734 en-us en-US value 1735 0x45 uri type value-tag 1736 0x000B name-length 1737 printer-uri printer-uri name 1738 0x0015 value-length 1739 ipp://forest/pi printer pinetree value 1740 netree 1741 0x21 integer type value-tag 1742 0x0005 name-length 1743 limit limit name 1744 0x0004 value-length 1745 0x00000032 50 value 1746 0x44 keyword type value-tag 1747 0x0014 name-length 1748 requested- requested-attributes name 1749 attributes 1750 0x0006 value-length 1751 Octets Symbolic Value Protocol field 1753 job-id job-id value 1754 0x44 keyword type value-tag 1755 0x0000 additional value name-length 1756 0x0008 value-length 1757 job-name job-name value 1758 0x44 keyword type value-tag 1759 0x0000 additional value name-length 1760 0x000F value-length 1761 document-format document-format value 1762 0x03 end-of-attributes end-of-attributes-tag 1764 13.8 Get-Jobs Response 1766 The following is an of Get-Jobs response from previous request with 3 1767 jobs. The Printer returns no information about the second job (because 1768 of security reasons): 1770 Octets Symbolic Value Protocol field 1772 0x0101 1.1 version-number 1773 0x0000 successful-ok status-code 1774 0x00000123 0x123 request-id (echoed 1775 back) 1776 0x01 start operation-attributes operation-attribute-tag 1777 0x47 charset type value-tag 1778 0x0012 name-length 1779 attributes- attributes-charset name 1780 charset 1781 0x000A value-length 1782 ISO-8859-1 ISO-8859-1 value 1783 0x48 natural-language type value-tag 1784 0x001B name-length 1785 attributes- attributes-natural-language name 1786 natural- 1787 language 1788 0x0005 value-length 1789 en-us en-US value 1790 0x41 textWithoutLanguage type value-tag 1791 0x000E name-length 1792 status-message status-message name 1793 0x000D value-length 1794 successful-ok successful-ok value 1795 0x02 start job-attributes (1st job-attributes-tag 1796 Octets Symbolic Value Protocol field 1798 object) 1799 0x21 integer type value-tag 1800 0x0006 name-length 1801 job-id job-id name 1802 0x0004 value-length 1803 147 147 value 1804 0x36 nameWithLanguage value-tag 1805 0x0008 name-length 1806 job-name job-name name 1807 0x000C value-length 1808 0x0005 sub-value-length 1809 fr-ca fr-CA value 1810 0x0003 sub-value-length 1811 fou fou name 1812 0x02 start job-attributes (2nd job-attributes-tag 1813 object) 1814 0x02 start job-attributes (3rd job-attributes-tag 1815 object) 1816 0x21 integer type value-tag 1817 0x0006 name-length 1818 job-id job-id name 1819 0x0004 value-length 1820 148 149 value 1821 0x36 nameWithLanguage value-tag 1822 0x0008 name-length 1823 job-name job-name name 1824 0x0012 value-length 1825 0x0005 sub-value-length 1826 de-CH de-CH value 1827 0x0009 sub-value-length 1828 isch guet isch guet name 1829 0x03 end-of-attributes end-of-attributes-tag 1831 14. Appendix B: Registration of MIME Media Type Information for 1832 "application/ipp" 1834 This appendix contains the information that IANA requires for 1835 registering a MIME media type. The information following this paragraph 1836 will be forwarded to IANA to register application/ipp whose contents are 1837 defined in Section 3 "Encoding of the Operation Layer" in this 1838 document: 1840 MIME type name: application 1842 MIME subtype name: ipp 1843 A Content-Type of "application/ipp" indicates an Internet Printing 1844 Protocol message body (request or response). Currently there is one 1845 version: IPP/1.1, whose syntax is described in Section 3 "Encoding of 1846 the Operation Layer" of [ipp-pro], and whose semantics are described in 1847 [ipp-mod]. 1849 Required parameters: none 1851 Optional parameters: none 1853 Encoding considerations: 1855 IPP/1.1 protocol requests/responses MAY contain long lines and ALWAYS 1856 contain binary data (for example attribute value lengths). 1858 Security considerations: 1860 IPP/1.1 protocol requests/responses do not introduce any security risks 1861 not already inherent in the underlying transport protocols. Protocol 1862 mixed-version interworking rules in [ipp-mod] as well as protocol 1863 encoding rules in [ipp-pro] are complete and unambiguous. 1865 Interoperability considerations: 1867 IPP/1.1 requests (generated by clients) and responses (generated by 1868 servers) MUST comply with all conformance requirements imposed by the 1869 normative specifications [ipp-mod] and [ipp-pro]. Protocol encoding 1870 rules specified in [ipp-pro] are comprehensive, so that interoperability 1871 between conforming implementations is guaranteed (although support for 1872 specific optional features is not ensured). Both the "charset" and 1873 "natural-language" of all IPP/1.1 attribute values which are a 1874 LOCALIZED-STRING are explicit within IPP protocol requests/responses 1875 (without recourse to any external information in HTTP, SMTP, or other 1876 message transport headers). 1878 Published specifications: 1880 [ipp-mod] Isaacson, S., deBry, R., Hastings, T., Herriot, R., 1881 Powell, P., "Internet Printing Protocol/1.1: Model and 1882 Semantics" draft-ietf-ipp-model-v11-07.txt, May 22, 2000. 1884 [ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., 1885 "Internet Printing Protocol/1.1: Encoding and Transport", draft- 1886 ietf-ipp-protocol-v11-06.txt, May 30, 2000. 1888 Applications which use this media type: 1890 Internet Printing Protocol (IPP) print clients and print servers, 1891 communicating using HTTP/1.1 (see [IPP-PRO]), SMTP/ESMTP, FTP, or other 1892 transport protocol. Messages of type "application/ipp" are self- 1893 contained and transport-independent, including "charset" and "natural- 1894 language" context for any LOCALIZED-STRING value. 1896 Person & email address to contact for further information: 1898 Tom Hastings 1899 Xerox Corporation 1900 737 Hawaii St. ESAE-231 1901 El Segundo, CA 1903 Phone: 310-333-6413 1904 Fax: 310-333-5514 1905 Email: hastings@cp10.es.xerox.com 1907 or 1909 Robert Herriot 1910 Xerox Corporation 1911 3400 Hillview Ave., Bldg #1 1912 Palo Alto, CA 94304 1914 Phone: 650-813-7696 1915 Fax: 650-813-6860 1916 Email: robert.herriot@pahv.xerox.com 1918 Intended usage: 1920 COMMON 1922 15. Appendix C: Changes from IPP/1.0 1924 IPP/1.1 is identical to IPP/1.0 [RFC2565] with the follow changes: 1926 1.Attributes values that identify a printer or job object use a new 1927 'ipp' scheme. The 'http' and 'https' schemes are supported only for 1928 backward compatibility. See section 5. 1930 2.Clients MUST support of Digest Authentication, IPP Printers SHOULD 1931 support Digest Authentication. See Section 8.1.1 1933 3.TLS is recommended for channel security. In addition, SSL3 may be 1934 supported for backward compatibility. See Section 8.1.2 1936 4.It is recommended that IPP/1.1 objects accept any request with major 1937 version number '1'. See section 9.1. 1939 5.IPP objects SHOULD return the URL scheme requested for "job-printer- 1940 uri" and "job-uri" Job Attributes, rather than the URL scheme used to 1941 create the job. See section 9.2. 1943 6.The IANA and Internationalization sections have been added. The 1944 terms "private use" and "experimental" have been changed to "vendor 1945 extension". The reserved allocations for attribute group tags, 1946 attribute syntax tags, and out-of-band attribute values have been 1947 clarified as to which are reserved to future IETF standards track 1948 documents and which are reserved to vendor extension. Both kinds of 1949 extensions use the type2 registration procedures as defined in [ipp- 1950 mod]. 1952 7.Clarified that future "out-of-band" value definitions may use the 1953 value field if additional information is needed. 1955 16. Full Copyright Statement 1957 The IETF takes no position regarding the validity or scope of any 1958 intellectual property or other rights that might be claimed to pertain 1959 to the implementation or use of the technology described in this 1960 document or the extent to which any license under such rights might or 1961 might not be available; neither does it represent that it has made any 1962 effort to identify any such rights. Information on the IETF's 1963 procedures with respect to rights in standards-track and standards- 1964 related documentation can be found in BCP-11[BCP-11]. Copies of claims 1965 of rights made available for publication and any assurances of licenses 1966 to be made available, or the result of an attempt made to obtain a 1967 general license or permission for the use of such proprietary rights by 1968 implementers or users of this specification can be obtained from the 1969 IETF Secretariat. 1971 The IETF invites any interested party to bring to its attention any 1972 copyrights, patents or patent applications, or other proprietary rights 1973 which may cover technology that may be required to practice this 1974 standard. Please address the information to the IETF Executive 1975 Director. 1977 Copyright (C) The Internet Society (2000). All Rights Reserved 1979 This document and translations of it may be copied and furnished to 1980 others, and derivative works that comment on or otherwise explain it or 1981 assist in its implementation may be prepared, copied, published and 1982 distributed, in whole or in part, without restriction of any kind, 1983 provided that the above copyright notice and this paragraph are included 1984 on all such copies and derivative works. However, this document itself 1985 may not be modified in any way, such as by removing the copyright notice 1986 or references to the Internet Society or other Internet organizations, 1987 except as needed for the purpose of developing Internet standards in 1988 which case the procedures for copyrights defined in the Internet 1989 Standards process must be followed, or as required to translate it into 1990 languages other than English. 1992 The limited permissions granted above are perpetual and will not be 1993 revoked by the Internet Society or its successors or assigns. 1995 This document and the information contained herein is provided on an "AS 1996 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1997 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1998 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1999 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2000 FITNESS FOR A PARTICULAR PURPOSE.