idnits 2.17.1 draft-ietf-ipp-protocol-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 25 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 66 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 80 has weird spacing: '...ding of the O...' == Line 121 has weird spacing: '...ists of a mes...' == Line 134 has weird spacing: '...ding of the O...' == Line 140 has weird spacing: '...portant types...' == Line 141 has weird spacing: '...ch most other...' == (61 more instances...) -- 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 (July 30, 1997) is 9757 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) == Unused Reference: '1' is defined on line 873, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 876, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 879, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 882, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 884, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 886, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 889, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 892, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 899, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 902, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 905, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 910, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 912, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 915, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 927, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1759 (ref. '1') (Obsoleted by RFC 3805) ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '2') ** Obsolete normative reference: RFC 822 (ref. '3') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1543 (ref. '4') (Obsoleted by RFC 2223) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 1521 (ref. '8') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Downref: Normative reference to an Informational RFC: RFC 1179 (ref. '10') ** Obsolete normative reference: RFC 1738 (ref. '11') (Obsoleted by RFC 4248, RFC 4266) -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' -- Possible downref: Non-RFC (?) normative reference: ref. '23' -- Possible downref: Non-RFC (?) normative reference: ref. '24' ** Obsolete normative reference: RFC 1766 (ref. '26') (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2068 (ref. '27') (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 1903 (ref. '28') (Obsoleted by RFC 2579) == Outdated reference: A later version (-04) exists of draft-ietf-drums-abnf-03 == Outdated reference: A later version (-15) exists of draft-ietf-printmib-mib-info-02 Summary: 18 errors (**), 0 flaws (~~), 25 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 3 Robert Herriot (editor) 4 Sun Microsystems 5 Sylvan Butler 6 Hewlett-Packard 7 Paul Moore 8 Microsoft. 9 Randy Turner 10 Sharp Labs 11 July 30, 1997 13 Internet Printing Protocol/1.0: Protocol Specification 14 draft-ietf-ipp-protocol-01.txt 16 Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, and 20 its working groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference material 26 or to cite them other than as "work in progress". 28 To learn the current status of any Internet-Draft, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Abstract 36 This document is one of a set of documents, which together describe all 37 aspects of a new Internet Printing Protocol (IPP). IPP is an 38 application level protocol that can be used for distributed printing 39 using Internet tools and technology. The protocol is heavily influenced 40 by the printing model introduced in the Document Printing Application 41 (ISO/IEC 10175 DPA) standard. Although DPA specifies both end user and 42 administrative features, IPP version 1.0 is focused only on end user 43 functionality. 45 The full set of IPP documents includes: 47 Internet Printing Protocol: Requirements 48 Internet Printing Protocol/1.0: Model and Semantics 49 Internet Printing Protocol/1.0: Security 50 Internet Printing Protocol/1.0: Protocol Specification 51 Internet Printing Protocol/1.0: Directory Schema 53 The requirements document takes a broad look at distributed printing 54 functionality, and it enumerates real-life scenarios that help to 55 clarify the features that need to be included in a printing protocol for 56 the Internet. It identifies requirements for three types of users: end 57 users, operators, and administrators. The requirements document calls 58 out a subset of end user requirements that MUST be satisfied in the 59 first version of IPP. Operator and administrator requirements are out 60 of scope for v1.0. The model and semantics document describes a 61 simplified model with abstract objects, their attributes, and their 62 operations. The model introduces a Printer object and a Job object. The 63 Job object supports multiple documents per job. The security document 64 covers potential threats and proposed counters to those threats. The 65 protocol specification is formal document which incorporates the ideas 66 in all the other documents into a concrete mapping using clearly defined 67 data representations and transport protocol mappings that real 68 implementers can use to develop interoperable client and server side 69 components. Finally, the directory schema document shows a generic 70 schema for directory service entries that represent instances of IPP 71 Printers. 73 This document is the "Internet Printing Protocol/1.0: Protocol 74 Specification" document. 76 Table of Contents 78 1. Introduction........................................................4 79 2. Conformance Terminology.............................................4 80 3. Encoding of the Operation Layer....................................4 81 3.1 Picture of the Encoding.........................................5 82 3.2 Syntax of Encoding..............................................7 83 3.3 Version.........................................................8 84 3.4 Mapping of Operations...........................................8 85 3.5 Mapping of Status-code..........................................8 86 3.6 Tags............................................................9 87 3.6.1 Delimiter Tags.............................................9 88 3.6.2 Value Tags................................................10 89 3.7 Name-Lengths...................................................11 90 3.8 Mapping of Parameter Names.....................................11 91 3.9 Value Lengths..................................................13 92 3.10 Mapping of Attribute and Parameter Values.....................13 93 3.11 Data..........................................................14 94 4. Encoding of Transport Layer........................................14 95 4.1 General Headers................................................15 96 4.2 Request Headers...............................................16 97 4.3 Response Headers...............................................17 98 4.4 Entity Headers................................................17 99 5. Security Considerations............................................18 100 6. References.........................................................19 101 7. Author's Address...................................................20 102 8. Other Participants:................................................20 103 9. Appendix A: Protocol Examples......................................21 104 9.1 Print-Job Request..............................................21 105 9.2 Print-Job Response (successful)................................21 106 9.3 Print-Job Response (failure)...................................22 107 9.4 Print-URI Request..............................................23 108 9.5 Create-Job Request.............................................23 109 9.6 Get-Jobs Request...............................................23 110 9.7 Get-Jobs Response..............................................24 111 10. Appendix B: Mapping of Each Operation in the Encoding.............25 112 1. Introduction 114 This document contains the rules for encoding IPP operations and 115 describes two layers: the transport layer and the operation layer. 117 The transport layer consists of an HTTP/1.1 request or response. RFC 118 2068 [27] describes HTTP/1.1. This document specifies the HTTP headers 119 that an IPP implementation supports. 121 The operation layer consists of a message body in an HTTP request or 122 response. The document "Internet Printing Protocol/1.0: Model and 123 Semantics" [21] defines the semantics of such a message body and the 124 supported values. This document specifies the encoding of an IPP 125 operation. The aforementioned document [21] is henceforth referred to as 126 the "IPP model document" 128 2. Conformance Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [25]. 134 3. Encoding of the Operation Layer 136 The operation layer SHALL contain a single operation request or 137 operation response. 139 The encoding consists of octet as the most primitive type. There are 140 several types built from octets, but two important types are integers 141 and characters, on which most other data types are built. Every 142 character in this encoding SHALL be a member of the UCS-2 coded 143 character set and SHALL be encoded using UTF-8 which uses 1 to 3 octets 144 per character. Every integer in this encoding SHALL be encoded as a 145 signed integer using two's-complement binary encoding with big-endian 146 format (also known as "network order" and "most significant byte 147 first"). The number of octets for an integer SHALL be 1, 2 or 4, 148 depending on usage in the protocol. Such one-octet integers, henceforth 149 called SIGNED-BYTE, are used for the version and tag fields. Such two- 150 byte integers, henceforth called SIGNED-SHORT are used for the 151 operation, status-code and length fields. Four byte integers, henceforth 152 called SIGNED-INTEGER, are used for values fields. 154 The following two sections present the operation layer in two ways 156 . informally through pictures and description 157 . formally through Augmented Backus-Naur Form (ABNF), as specified by 158 draft-ietf-drums-abnf-02.txt [29] 160 3.1 Picture of the Encoding 162 The encoding for an operation request or response consists of: 164 ----------------------------------------------- 165 | version | 2 bytes - required 166 ----------------------------------------------- 167 |operation (request) or status-code (response)| 2 bytes - required 168 ----------------------------------------------------------- 169 | parameter-tag | 1 byte | 170 ----------------------------------------------- |- optional 171 | parameter-sequence | m bytes | 172 ----------------------------------------------------------- 173 | attribute-tag | 1 byte | 174 ----------------------------------------------- |-0 or more 175 | attribute-sequence | n bytes | 176 ----------------------------------------------------------- 177 | data-tag | 1 byte - required 178 ----------------------------------------------- 179 | data | q bytes - optional 180 ----------------------------------------------- 182 The parameter-tag and parameter-sequence may be omitted if the operation 183 has no parameters. The attribute-tag and attribute-sequence may be 184 omitted if the operation has no attributes or it may be replicated for 185 an operation that contains attributes for multiple objects. The data is 186 omitted from some operations, but the data-tag is present even when the 187 data is omitted. Note, the parameter-tag, attribute-tag and data-tag are 188 called `delimiter-tags'. 190 A parameter-sequence consists of a sequence of zero or more compound- 191 parameters. 193 ----------------------------------------------- 194 | compound-parameter | r bytes - 0 or more 195 ----------------------------------------------- 197 An attributes-sequence consists of zero or more compound-attributes. 199 ----------------------------------------------- 200 | compound-attribute | s bytes - 0 or more 201 ----------------------------------------------- 203 A compound-parameter consists of a parameter with a single value 204 optionally followed by zero or more additional values. A compound- 205 attribute consists an attribute with a single value followed by zero or 206 more additional values. 208 Each parameter or attribute consists of: 210 ----------------------------------------------- 211 | value-tag | 1 byte 212 ----------------------------------------------- 213 | name-length (value is u) | 2 bytes 214 ----------------------------------------------- 215 | name | u bytes 216 ----------------------------------------------- 217 | value-length (value is v) | 2 bytes 218 ----------------------------------------------- 219 | value | v bytes 220 ----------------------------------------------- 222 An additional value consists of: 224 ----------------------------------------------------------- 225 | value-tag | 1 byte | 226 ----------------------------------------------- | 227 | name-length (value is 0x0000) | 2 bytes | 228 ----------------------------------------------- |-0 or more 229 | value-length (value is w) | 2 bytes | 230 ----------------------------------------------- | 231 | value | w bytes | 232 ----------------------------------------------------------- 234 Note: an additional value is like a parameter or attribute whose name- 235 length is 0. 237 From the standpoint of a parsing loop, the encoding consists of: 239 ----------------------------------------------- 240 | version | 2 bytes - required 241 ----------------------------------------------- 242 |operation (request) or status-code (response)| 2 bytes - required 243 ----------------------------------------------------------- 244 | tag (delimiter-tag or value-tag) | 1 byte | 245 ----------------------------------------------- |-0 or more 246 | empty or rest of parameter/attribute | x bytes | 247 ----------------------------------------------------------- 248 | data-tag | 2 bytes - required 249 ----------------------------------------------- 250 | data | y bytes - optional 251 ----------------------------------------------- 253 The value of the tag determines whether the bytes following the tag are: 255 . parameters 256 . attributes 257 . data 258 . the remainder of a single parameter or attribute where the tag 259 specifies the type of the value. 261 3.2 Syntax of Encoding 263 The syntax below is ABNF except `strings of literals' SHALL be case 264 sensitive. For example `a' means lower case `a' and not upper case `A'. 265 In addition, SIGNED-BYTE and SIGNED-SHORT fields are represented as `%x' 266 values which show their range of values. 268 ipp-message = ipp-request / ipp-response 269 ipp-request = version operation 270 [parameter-tag parameter-sequence ] 271 *(attribute-tag attribute-sequence) data-tag data 272 ipp-response = version status-code 273 [parameter-tag parameter-sequence ] 274 *(attribute-tag attribute-sequence) data-tag data 276 version = major-version minor-version 277 major-version = SIGNED-BYTE ; initially %d1 278 minor-version = SIGNED-BYTE ; initially %d0 280 operation = SIGNED-SHORT ; mapping from model defined below 281 status-code = SIGNED-SHORT ; mapping from model defined below 283 parameter-sequence = *compound-parameter 284 attribute-sequence = *compound-attribute 285 compound-parameter = parameter *additional-values 286 compound-attribute = attribute *additional-values 288 parameter = value-tag name-length name value-length value 289 attribute = value-tag name-length name value-length value 290 additional-values = value-tag zero-name-length value-length value 292 name-length = SIGNED-SHORT ; number of octets of `name' 293 name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." ) 294 value-length = SIGNED-SHORT ; number of octets of `value' 295 value = OCTET-STRING 297 data = OCTET-STRING 299 zero-name-length = %x00.00 ; name-length of 0 300 parameter-tag = %x01 ; tag of 1 301 attribute-tag = %x02 ; tag of 2 302 data-tag = %x03 ; tag of 3 303 value-tag = %x10-FF 305 SIGNED-BYTE = BYTE 306 SIGNED-SHORT = 2BYTE 307 DIGIT = %x30-39 ; "0" to "9" 308 LALPHA = %x61-7A ; "a" to "z" 309 BYTE = %x00-FF 310 OCTET-STRING = *BYTE 312 The syntax allows a parameter-tag to be present when the parameter- 313 sequence that follows is empty. The same is true for the attribute-tag 314 and the attribute-sequence that follows. The syntax is defined this way 315 to allow for the response of Get-Jobs where no attributes are returned 316 for some job-objects. Although it is RECOMMENDED that the sender not 317 send a parameter-tag if there are no parameters and not send an 318 attribute-tag if there are no attributes (except in the Get-Jobs 319 response just mentioned), the receiver MUST be able to decode such 320 syntax. 322 3.3 Version 324 The version SHALL consist of a major and minor version, each of which 325 SHALL be represented by a SIGNED-BYTE. The protocol described in this 326 document SHALL have a major version of 1 (0x01) and a minor version of 327 0 (0x00). The ABNF for these two bytes SHALL be %x01.00. 329 3.4 Mapping of Operations 331 The following SHALL be the mapping of operations names to integer values 332 which are encoded as a SIGNED-SHORT. The operations are defined in the 333 IPP model document The table below includes a range of values for 334 future extensions to the protocol and a separate range for private 335 extensions. It is RECOMMENDED that the private extension values be used 336 for temporary experimental implementations and not for deployed 337 products. 339 Encoding (hex) Operation 341 0x0 reserved (not used) 342 0x1 Get-Operations 343 0x2 Print-Job 344 0x3 Print-URI 345 0x4 Validate-Job 346 0x5 Create-Job 347 0x6 Send-Document 348 0x7 Send-URI 349 0x8 Cancel-Job 350 0x9 Get-Attributes 351 0xA Get-Jobs 352 0xB-0x3FFF reserved for future operations 353 0x4000-0xFFFF reserved for private extensions 355 3.5 Mapping of Status-code 357 The following SHALL be the mapping of status-code names to integer 358 values which are encoded as a SIGNED-SHORT. The status-code names are 359 defined in the IPP model document. 361 If an IPP status-code is returned, then the HTTP Status-Code MUST be 200 362 (OK). With any other HTTP Status-Code value, the HTTP response SHALL NOT 363 contain an IPP message-body, and thus no IPP status-code is returned. 365 Note: the integer encodings below were chosen to be similar to 366 corresponding Status-Code values in HTTP. The IPP client and server 367 errors have the same relative offset to their base as corresponding HTTP 368 errors, but the IPP base is a multiple of 0x100 whereas the HTTP base is 369 a multiple of 100. Despite this similarity, the Status-Code returned at 370 the HTTP level will always be different except in the case where `OK' is 371 returned at both levels, 200 (OK) in HTTP and 0 (successful-OK) in IPP. 373 Note: some status-code values, such as client-error-unauthorized, may 374 be returned at the transport (HTTP) level rather than the operation 375 level. 377 ISSUE: as implementations proceed, we will learn what error code need to 378 be supported at the IPP level. 380 Encoding (hex) Status-Code Name 382 0 successful-OK 383 0x400 client-error-bad-request 384 0x401 client-error-unauthorized 385 0x403 client-error-forbidden 386 0x404 client-error-not-found 387 0x405 client-error-method-not-allowed 388 0x408 client-error-timeout 389 0x40A client-error-gone 390 0x40D client-error-request-entity-too-large 391 0x40E client-error-request-URI-too-long 392 0x40F client-error-unsupported-document-format 393 0x410 client-error-attribute-not-supported 394 0x500 server-error-internal-server-error 395 0x501 server-error-operation-not-implemented 396 0x503 server-error-service-unavailable 397 0x504 server-error-timeout 398 0x505 server-error-version-not-supported 399 0x506 server-error-printer-error 400 0x507 server-error-temporary-error 402 3.6 Tags 404 There are two kinds of tags: 406 . delimiter tags: delimit major sections of the protocol, namely 407 parameters, attributes and data 408 . value tags: specify the type of each parameter or attribute value 410 3.6.1 Delimiter Tags 412 The following table specifies the values for the delimiter tags: 414 Tag Value (Hex) Delimiter 415 Tag Value (Hex) Delimiter 417 0x00 reserved 418 0x01 parameter-tag 419 0x02 attribute-tag 420 0x03 data-tag 421 0x04-0x0F reserved for future delimiters 423 3.6.2 Value Tags 425 The remaining tables show values for the value-tag, which is the first 426 octet of a parameter or attribute. The value-tag specifies the type of 427 the value of the parameter or attribute. The value of the value-tag of a 428 parameter or attribute SHALL either be a type value specified in the 429 model document or an "out-of-band" value, such as "unsupported" or 430 "default". If the value of value-tag for a attribute or parameter is 431 not "out-of-band" and differs from the value type specified by the model 432 document, then a server receiving such a request MAY reject it, and a 433 client receiving such a response MAY ignore the attribute or parameter. 435 The following table specifies the "out-of-band" values for the value- 436 tag. 438 Tag Value (Hex) Meaning 440 0x10 unsupported 441 0x11 default 442 0x12 no-value 443 0x13-0x1F reserved for future "out-of-band" values. 445 The "unsupported" value SHALL be used in the attribute-sequence of an 446 error response for those attributes which the server does not support. 447 The "default" value is reserved for future use of setting value back to 448 their default value. The "no-value" value is used for the "no-value" 449 value in model, e.g. when a document-attribute is returned as a set of 450 values and an attribute has no specified value for one or more of the 451 documents. 453 The following table specifies the integer values for the value-tag 455 Tag Value (Hex) Meaning 457 0x20 reserved 458 0x21 integer 459 0x22 boolean 460 0x23 enum 461 0x24-0x2F reserved for future integer types 463 NOTE: 0x20 is reserved for "generic integer" if should ever be needed. 465 The following table specifies the octet-string values for the value-tag 467 Tag Value (Hex) Meaning 469 0x30 reserved 470 0x31 dateTime 471 0x32 resolution 472 0x33-0x3F reserved for future octet-string types 474 The following table specifies the character-string values for the value- 475 tag 477 Tag Value (Hex) Meaning 479 0x40 reserved 480 0x41 text 481 0x42 name 482 0x43 language 483 0x44 keyword 484 0x45 uri 485 0x46 uriScheme 486 0x47-0x5F reserved for future character string types 488 NOTE: 0x40 is reserved for "generic character-string" if should ever be 489 needed. 491 The values 0x60-0xFF are reserved for future types. There are no values 492 allocated for private extensions. A new type must be registered via the 493 type 2 process. 495 Issue: should this be a type 1 process. 497 3.7 Name-Lengths 499 The name-length field SHALL consist of a SIGNED-SHORT. This field SHALL 500 specify the number of octets in the name field which follows the name- 501 length field, excluding the two bytes of the name-length field. 503 If a name-length field has a value of zero, the following name field 504 SHALL be empty, and the following value SHALL be treated as an 505 additional value for the preceding parameter. Within a parameter- 506 sequence, if two parameters have the same name, the first occurrence 507 SHALL be ignored. Within an attribute-sequence, if two attributes have 508 the same name, the first occurrence SHALL be ignored. The zero-length 509 name is the only mechanism for multi-valued parameters and attributes. 511 3.8 Mapping of Parameter Names 513 Some parameters are encoded in a special position. These parameters 514 are: 516 . "printer-uri": The printer-uri of each printer object operation in 517 the IPP model document SHALL be specified both as a parameter named 518 "printer-uri" in the operation layer ,and outside of the operation 519 layer as the request-URI on the Request-Line at the HTTP level,. 520 . "job-uri": The job -uri of each job object operation in the IPP 521 model document SHALL be specified both as a parameter named "job - 522 uri" in the operation layer ,and outside of the operation layer as 523 the request-URI on the Request-Line at the HTTP level,. 524 . 525 . "document-content": The parameter named "document-content" in the 526 IPP model document SHALL become the "data" in the operation layer. 527 . "status-code": The parameter named "status-code" in the IPP model 528 document SHALL become the "status-code" field in the operation 529 layer response. 531 The remaining parameters are encoded in the parameter-sequence or the 532 attribute-sequence. The parameter-sequence is for actual operation 533 parameters and the attribute-sequence is for object attributes. Of the 534 parameters defined in the IPP model document, some represent an actual 535 operation parameters and others represent a collection of object 536 attributes. 538 A parameter in the IPP model document SHALL represent a collection of 539 object attributes if its name contains the word "attributes" 540 immediately preceded by a space; otherwise it SHALL represent an actual 541 operation parameter. Note, some actual operation parameters contain the 542 word "attributes" preceded by a hyphen ("-"). They are not a collection 543 of attributes. 545 If a parameter in IPP model document represents an actual operation 546 parameter and is not in a special position, it SHALL be encoded in the 547 parameter-sequence using the text name of the parameter specified in the 548 IPP model document. 550 If a parameter in IPP model document represents a collection of object 551 attributes, the attributes SHALL be encoded in the attribute-sequence 552 using the text names of the attributes specified in the IPP model 553 document. The IPP model document specifies the members of such attribute 554 collections, but does not require that all members of a collection be 555 present in an operation. 557 If an operation contain attributes from exactly one object, there SHALL 558 be exactly one attribute-sequence. If an operation contains attributes 559 from more than one object (e.g. Get-Jobs response), the attributes from 560 each object SHALL be in a separate attribute-sequence, such that the 561 attributes from the ith object are in the ith attribute-sequence. 563 See Section 10 "Appendix B: Mapping of Each Operation in the Encoding" 564 for table showing the application of the rules above. 566 3.9 Value Lengths 568 Each parameter value SHALL be preceded by a SIGNED-SHORT which SHALL 569 specify the number of octets in the value which follows this length, 570 exclusive of the two bytes specifying the length. 572 For any of the types represented by binary signed integers, the sender 573 MUST encode the value in exactly four octets.. 575 For any of the types represented by character-strings, the sender MUST 576 encode the value with all the characters of the string and without any 577 padding characters. 579 If a value-tag contains an "out-of-band" value, such as "unsupported", 580 the value-length SHALL be 0 and the value empty " the value has no 581 meaning when the value-tag has an "out-of-band" value. If a server or 582 client receives an operation with a nonzero value-length in this case, 583 it SHALL ignore the value field. 585 3.10 Mapping of Attribute and Parameter Values 587 The following SHALL be the mapping of attribute and parameter values to 588 their IPP encoding in the value field. The syntax types are defined in 589 the IPP model document. 591 Syntax of Encoding 592 Attribute Value 594 text an octet string where each character is a member 595 of the UCS-2 coded character set and is encoded 596 using UTF-8. The text is encoded in "network byte 597 order" with the first character in the text 598 (according to reading order) being the first 599 character in the encoding. 600 name same as text 601 language same as text but with a syntax specified by RFC 602 1766 603 keyword same as text. Allowed text values are defined in 604 the IPP model document 605 uri same as text 606 uriScheme same as text 607 boolean one binary octet where 0x00 is `false' and 0x01 608 is `true' 609 integer a SIGNED-INTEGER, defined previously as a signed 610 integer using two's-complement binary encoding in 611 four octets with big-endian format (also known as 612 "network order" and "most significant byte 613 first"). 614 enum same as integer. Allowed integer values are 615 defined in the IPP model document 616 dateTime eleven octets whose contents are defined by 617 "DateAndTime" in RFC 1903. Although RFC 1903 also 619 Syntax of Encoding 620 Attribute Value 622 defines an eight octet format which omits the 623 time zone, a value of this type in the IPP 624 protocol MUST use the eleven octet format. 625 resolution nine octets consisting of 2 SIGNED-INTEGERs 626 followed by a SIGNED-BYTE. The values are the 627 same as those specified in draft-ietf-printmib- 628 mib-info-02.txt [30]. The first SIGNED-INTEGER 629 contains the value of 630 prtMarkerAddressabilityXFeedDir. The second 631 SIGNED-INTEGER contains the value of 632 prtMarkerAddressabilityFeedDir. The SIGNED-BYTE 633 contains the value of 634 prtMarkerAddressabilityUnit. Note: the latter 635 value is either 3 (tenThousandsOfInches) or 4 636 (micrometers) and the addressability is in 10,000 637 units of measure. Thus the SIGNED-INTEGERS 638 represent integral values in either dots-per-inch 639 or dots-per-centimeter. 640 1setOf X encoding according to the rules for a parameter 641 with more than more value. Each value X is 642 encoded according to the rules for encoding its 643 type. 644 rangeOf X same 1setOf X where the number of values is 2. 646 The type of the value in the model document determines the encoding in 647 the value and the value of the value-tag. 649 3.11 Data 651 The data part SHALL include any data required by the operation 653 4. Encoding of Transport Layer 655 HTTP/1.1 shall be the transport layer for this protocol. 657 The operation layer has been designed with the assumption that the 658 transport layer contains the following information: 660 . the URI of the target job or printer operation 661 . the total length of the data in the operation layer, either as a 662 single length or as a sequence of chunks each with a length. 663 . the client's language, the character-set and the transport 664 encoding. 666 Each HTTP operation shall use the POST method where the request-URI is 667 the object target of the operation, and where the "Content-Type" of the 668 message-body in each request and response shall be "application/ipp". 669 The message-body shall contain the operation layer and shall have the 670 syntax described in section 3.2 "Syntax of Encoding". A client 671 implementation SHALL adhere to the rules for a client described in RFC 672 2068. A server implementation SHALL adhere the rules for an origin 673 server described in RFC 2068.In the following sections, there are a 674 tables of all HTTP headers which describe their use in an IPP client or 675 server. The following is an explanation of each column in these tables. 677 . the "header" column contains the name of a header 678 . the "request/client" column indicates whether a client sends the 679 header. 680 . the "request/server" column indicates whether a server supports the 681 header when received. 682 . the "response/server" column indicates whether a server sends the 683 header. 684 . the "response /client" column indicates whether a client supports 685 the header when received. 686 . the "values and conditions" column specifies the allowed header 687 values and the conditions for the header to be present in a 688 request/response. 690 The table for "request headers" does not have columns for responses, and 691 the table for "response headers" does not have columns for requests. 693 The following is an explanation of the values in the "request/client" 694 and "response/server" columns. 696 . must: the client or server MUST send the header, 697 . must-if: the client or server MUST send the header when the 698 condition described in the "values and conditions" column is met, 699 . may: the client or server MAY send the header 700 . not: the client or server SHOULD NOT send the header. It is not 701 relevant to an IPP implementation. 703 The following is an explanation of the values in the "response/client" 704 and "request/server" columns. 706 . must: the client or server MUST support the header, 707 . may: the client or server MAY support the header 708 . not: the client or server SHOULD NOT support the header. It is not 709 relevant to an IPP implementation. 711 4.1 General Headers 713 The following is a table for the general headers. 715 ISSUE: an HTTP expert should review these tables for accuracy. 717 General- Request Response Values and Conditions 718 Header 720 Client Server Server Client 722 General- Request Response Values and Conditions 723 Header 725 Client Server Server Client 727 Cache- must not must not "no-cache" only 728 Control 729 Connection must-if must must- must "close" only. Both 730 if client and server 731 SHOULD keep a 732 connection for the 733 duration of a sequence 734 of operations. The 735 client and server MUST 736 include this header 737 for the last operation 738 in such a sequence. 739 Date may may must may per RFC 1123 [9] 740 Pragma` must not must not "no-cache" only 741 Transfer- must-if must must- must "chunked" only . 742 Encoding if Header MUST be present 743 if Content-Length is 744 absent. 745 Upgrade not not not not 746 Via not not not not 748 4.2 Request Headers 750 The following is a table for the request headers. 752 Request-Header Client Server Request Values and Conditions 754 Accept may must "application/ipp" only. This 755 value is the default if the 756 client omits it 757 Accept-Charset may must per IANA Character Set registry. 758 ISSUE: is this useful for IPP? 759 Accept-Encoding may must empty and per RFC 2068 [27] and 760 IANA registry for content-codings 761 Accept-Language may must see RFC 1766 [26]. A server 762 SHOULD honor language requested 763 by returning the values status- 764 message, job-state-message and 765 printer-state-reason in one of 766 requested languages. 767 Authorization must-if must per RFC 2068. A client MUST send 768 this header when it receives a 769 401 "Unauthorized" response and 770 does not receive a "Proxy- 771 Authenticate" header. 773 Request-Header Client Server Request Values and Conditions 775 From not not per RFC 2068. Because RFC 776 recommends sending this header 777 only with the user's approval, it 778 is not very useful 779 Host must must per RFC 2068 780 If-Match not not 781 If-Modified- not not 782 Since 783 If-None-Match not not 784 If-Range not not 785 If-Unmodified- not not 786 Since 787 Max-Forwards not not 788 Proxy- must-if not per RFC 2068. A client MUST send 789 Authorization this header when it receives a 790 401 "Unauthorized" response and a 791 "Proxy-Authenticate" header. 792 Range not not 793 Referer not not 794 User-Agent not not 796 4.3 Response Headers 798 The following is a table for the request headers. 800 Response- Server Client Response Values and Conditions 801 Header 803 Accept-Ranges not not 804 Age not not 805 Location must-if may per RFC 2068. When URI needs 806 redirection. 807 Proxy- not must per RFC 2068 808 Authenticate 809 Public may may per RFC 2068 810 Retry-After may may per RFC 2068 811 Server not not 812 Vary not not 813 Warning may may per RFC 2068 814 WWW- must-if must per RFC 2068. When a server needs to 815 Authenticate authenticate a client. 817 4.4 Entity Headers 819 The following is a table for the entity headers. 821 Entity-Header Request Response Values and Conditions 822 Client Server Server Client 824 Allow not not not not 825 Content-Base not not not not 826 Content- may must must must per RFC 2068 and IANA 827 Encoding registry for content 828 codings. 829 Content- may must must must see RFC 1766 [26]. 830 Language 831 Content- must-if must must-if must the length of the 832 Length message-body per RFC 833 2068. Header MUST be 834 present if Transfer- 835 Encoding is absent.. 836 Content- not not not not 837 Location 838 Content-MD5 may may may may per RFC 2068 839 Content-Range not not not not 840 Content-Type must must must must "application/ipp" 841 only 842 ETag not not not not 843 Expires not not not not 844 Last-Modified not not not not 846 5. Security Considerations 848 When utilizing HTTP 1.1 as a transport of IPP, the security 849 considerations outlined in RFC 2068 apply. Specifically, IPP servers 850 can generate a 401 "Unauthorized" response code to request client 851 authentication and IPP clients should correctly respond with the proper 852 "Authorization" header. Both Basic Authentication (RFC 2068) and Digest 853 Authentication (RFC 2069) flavors of authentication should be supported. 854 The server chooses which type(s) of authentication to accept. Digest 855 Authentication is a more secure method, and is always preferred to Basic 856 Authentication. 858 For secure communication (privacy in particular), IPP should be run 859 using a secure communications channel. Both Transport Layer Security - 860 TLS (draft-ietf-tls-protocol-03) and IPSec (RFC 1825) provide necessary 861 features for security. It is possible to combine the two techniques, 862 HTTP 1.1 client authentication (either basic or digest) with secure 863 communications channel (either TLS or IPSec). Together the two are more 864 secure than client authentication and they perform user authentication. 866 Complete discussion of IPP security considerations can be found in the 867 IPP Security document 869 ISSUE: how does each security mechanism supply the job-originating-user 870 and job-originating-host values? 871 6. References 873 [1] Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, 874 J., "Printer MIB", RFC 1759, March 1995. 876 [2] Berners-Lee, T, Fielding, R., and Nielsen, H., "Hypertext Transfer 877 Protocol - HTTP/1.0", RFC 1945, August 1995. 879 [3] Crocker, D., "Standard for the Format of ARPA Internet Text 880 Messages", RFC 822, August 1982. 882 [4] Postel, J., "Instructions to RFC Authors", RFC 1543, October 1993. 884 [5] ISO/IEC 10175 Document Printing Application (DPA), June 1996. 886 [6] Herriot, R. (editor), X/Open A Printing System Interoperability 887 Specification (PSIS), August 1995. 889 [7] Kirk, M. (editor), POSIX System Administration - Part 4: Printing 890 Interfaces, POSIX 1387.4 D8, 1994. 892 [8] Borenstein, N., and Freed, N., "MIME (Multi-purpose Internet Mail 893 Extensions) Part One: Mechanism for Specifying and Describing the 894 Format of Internet Message Bodies", RFC 1521, September, 1993. 896 [9] Braden, S., "Requirements for Internet Hosts - Application and 897 Support", RFC 1123, October, 1989, 899 [10] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" RFC 900 1179, August 1990. 902 [11] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform Resource 903 Locators (URL)", RFC 1738, December, 1994. 905 [20] Wright, F. D., "Requirements for an Internet Printing Protocol:" 907 [21] Isaacson, S, deBry, R, Hasting, T, Herriot, R, Powell, P, "Internet 908 Printing Protocol/1.0: Model and Semantics" 910 [22] Internet Printing Protocol/1.0: Security 912 [23] Herriot, R, Butler, S, Moore, P, Turner, R, "Internet Printing 913 Protocol/1.0: Protocol Specification" (This document) 915 [24] Carter, K, Isaacson, S, "Internet Printing Protocol/1.0: Directory 916 Schema" 918 [25] S. Bradner, "Key words for use in RFCs to Indicate Requirement 919 Levels", RFC 2119 , March 1997 921 [26] H. Alvestrand, " Tags for the Identification of Languages", RFC 922 1766, March 1995. 924 [27] R Fielding, et al, "Hypertext Transfer Protocol " HTTP/1.1" 925 RFC 2068, January 1997 927 [28] J. Case, et al. "Textual Conventions for Version 2 of the 928 Simple Network Managment Protocol (SNMPv2)", RFC 1903, January 929 1996. 931 [29] D. Crocker et al., "Augmented BNF for Syntax Specifications: ABNF", 932 draft-ietf-drums-abnf-03.txt. 934 [30] R. Turner, "Printer MIB", draft-ietf-printmib-mib-info- 935 02.txt, July 12, 1997. 937 7. Author's Address 939 Robert Herriot (editor) Paul Moore 940 Sun Microsystems Inc. Microsoft 941 901 San Antonio.Road, MPK-17 One Microsoft Way 942 Palo Alto, CA 94303 Redmond, WA 98053 944 Phone: 650-786-8995 Phone: 425-936-0908 945 Fax: 650-786-7077 Fax: 425-93MS-FAX 946 Email: robert.herriot@eng.sun.com Email: paulmo@microsoft.com 948 Sylvan Butler Randy Turner 949 Hewlett-Packard Sharp Laboratories 950 11311 Chinden Blvd. 5750 NW Pacific Rim Blvd 951 Boise, ID 83714 Camas, WA 98607 953 Phone: 208-396-6000 Phone: 360-817-8456 954 Fax: 208-396-3457 Fax: : 360-817-8436 955 Email: sbutler@boi.hp.com Email: rturner@sharplabs.com 957 IPP Mailing List: ipp@pwg.org 958 IPP Mailing List Subscription: ipp-request@pwg.org 959 IPP Web Page: http://www.pwg.org/ipp/ 961 8. Other Participants: 963 Chuck Adams - Tektronix Harry Lewis - IBM 964 Ron Bergman - Data Products Tony Liao - Vivid Image 965 Keith Carter - IBM David Manchala - Xerox 966 Angelo Caruso - Xerox Carl-Uno Manros - Xerox 967 Jeff Copeland - QMS Jay Martin - Underscore 968 Roger Debry - IBM Larry Masinter - Xerox 969 Lee Farrell - Canon Bob Pentecost - Hewlett-Packard 970 Sue Gleeson - Digital Patrick Powell - SDSU 971 Charles Gordon - Osicom Jeff Rackowitz - Intermec 972 Brian Grimshaw - Apple Xavier Riley - Xerox 973 Jerry Hadsell - IBM Gary Roberts - Ricoh 974 Richard Hart - Digital Stuart Rowley - Kyocera 975 Tom Hastings - Xerox Richard Schneider - Epson 976 Stephen Holmstead Shigern Ueda - Canon 977 Zhi-Hong Huang - Zenographics Bob Von Andel - Allegro Software 978 Scott Isaacson - Novell William Wagner - Digital Products 979 Rich Lomicka - Digital Jasper Wong - Xionics 980 David Kellerman - Northlake Don Wright - Lexmark 981 Software 982 Robert Kline - TrueSpectra Rick Yardumian - Xerox 983 Dave Kuntz - Hewlett-Packard Lloyd Young - Lexmark 984 Takami Kurono - Brother Peter Zehler - Xerox 985 Rich Landau - Digital Frank Zhao - Panasonic 986 Greg LeClair - Epson Steve Zilles - Adobe 988 9. Appendix A: Protocol Examples 990 9.1 Print-Job Request 992 The following is an example of a Print-Job request with job-name, 993 copies, and sides specified. 995 Octets Symbolic Value Protocol field 997 0x0100 1.0 version 998 0x0002 PrintJob operation 999 0x02 start attributes attribute tag 1000 0x42 name type value-tag 1001 0x0008 name-length 1002 job-name job-name name 1003 0x0006 value-length 1004 foobar foobar value 1005 0x21 integer type value-tag 1006 0x0005 name-length 1007 copies copies name 1008 0x0004 value-length 1009 0x00000014 20 value 1010 0x44 keyword type value-tag 1011 0x0005 name-length 1012 sides sides name 1013 0x0001 value-length 1014 two-sided-long-edge two-sided-long-edge value 1015 0x03 start-data data-tag 1016 %!PS... data 1018 9.2 Print-Job Response (successful) 1020 Here is an example of a Print-Job response which is successful: 1022 Octets Symbolic Value Protocol field 1024 0x0100 1.0 version 1025 Octets Symbolic Value Protocol field 1027 0x0000 OK (successful) status-code 1028 0x01 start parameters parameter tag 1029 0x41 text type value-tag 1030 0x000E name-length 1031 status-message status-message name 1032 0x0002 value-length 1033 OK OK value 1034 0x45 uri type value-tag 1035 0x0008 name-length 1036 job-uri job-uri name 1037 0x000E value-length 1038 http://foo/123 http://foo/123 value 1039 0x02 start attributes attribute tag 1040 0x25 name type value-tag 1041 0x0008 name-length 1042 job-state job-state name 1043 0x0001 value-length 1044 0x03 pending value 1045 0x03 start-data data-tag 1047 9.3 Print-Job Response (failure) 1049 Here is an example of a Print-Job response which fails because the 1050 printer does not support sides and because the value 20 for copies is 1051 not supported: 1053 Octets Symbolic Value Protocol field 1055 0x0100 1.0 version 1056 0x0400 client-error-bad-request status-code 1057 0x01 start parameters parameter tag 1058 0x41 text type value-tag 1059 0x000E name-length 1060 status-message status-message name 1061 0x000D value-length 1062 bad-request bad-request value 1063 0x02 start attributes attribute tag 1064 0x21 integer type value-tag 1065 0x0005 name-length 1066 copies copies name 1067 0x0004 value-length 1068 0x00000014 20 value 1069 0x10 unsupported (type) value-tag 1070 0x0005 name-length 1071 sides sides name 1072 0x0000 value-length 1073 0x03 start-data data-tag 1074 9.4 Print-URI Request 1076 The following is an example of Print-URI request with copies and job- 1077 name parameters. 1079 Octets Symbolic Value Protocol field 1080 0x0100 1.0 version 1081 0x0003 Print-URI operation 1082 0x01 start-parameters parameter tag 1083 0x45 uri type value-tag 1084 0x000A name-length 1085 document-uri document-uri name 1086 0x11 value-length 1087 ftp://foo.com/foo ftp://foo.com/foo value 1088 0x02 start-attributes attribute tag 1089 0x42 name type value-tag 1090 0x0008 name-length 1091 job-name job-name name 1092 0x0006 value-length 1093 foobar foobar value 1094 0x21 integer type value-tag 1095 0x0005 name-length 1096 copies copies name 1097 0x0004 value-length 1098 0x00000001 1 value 1099 0x03 start-data data-tag 1100 %!PS... data 1102 9.5 Create-Job Request 1104 The following is an example of Create-Job request with no parameters and 1105 no attributes 1107 Octets Symbolic Protocol field 1108 Value 1109 0x0100 1.0 version 1110 0x0005 Create-Job operation 1111 0x03 start-data data-tag 1113 9.6 Get-Jobs Request 1115 The following is an example of Get-Jobs request with parameters but no 1116 attributes. 1118 Octets Symbolic Value Protocol field 1119 0x0100 1.0 version 1120 0x000A Get-Jobs operation 1121 0x01 start-parameters parameter-tag 1122 0x21 integer type value-tag 1123 0x0005 name-length 1124 limit limit name 1125 0x0004 value-length 1126 0x00000032 50 value 1127 0x44 keyword type value-tag 1128 Octets Symbolic Value Protocol field 1129 0x0014 name-length 1130 requested-attributes requested-attributes name 1131 0x0007 value-length 1132 job-uri job-uri value 1133 0x44 keyword type value-tag 1134 0x0000 additional value name-length 1135 0x0008 value-length 1136 job-name job-name value 1137 0x03 start-data data-tag 1139 9.7 Get-Jobs Response 1141 The following is an of Get-Jobs response from previous request with 3 1142 jobs. The Printer returns no information about the second job. 1144 Octets Symbolic Value Protocol field 1145 0x0100 1.0 version 1146 0x0000 OK (successful) status-code 1147 0x01 start-parameters parameter-tag 1148 0x41 text type value-tag 1149 0x000E name-length 1150 status-message status-message name 1151 0x0002 value-length 1152 OK OK value 1153 0x02 start-attributes attribute-tag 1154 (1st object) 1155 0x45 uri type value-tag 1156 0x0007 name-length 1157 job-uri job-uri name 1158 0x000E value-length 1159 http://foo/123 http://foo/123 value 1160 0x42 name type value-tag 1161 0x0008 name-length 1162 job-name job-name name 1163 0x0003 name-length 1164 foo foo name 1165 0x02 start-attributes attribute-tag 1166 (2nd object) 1167 0x02 start-attributes attribute-tag 1168 (3rd object) 1169 0x45 uri type value-tag 1170 0x0007 name-length 1171 job-uri job-uri name 1172 0x000E value-length 1173 http://foo/124 http://foo/124 value 1174 0x42 name type value-tag 1175 0x0008 name-length 1176 job-name job-name name 1177 0x0003 name-length 1178 bar bar name 1179 0x03 start-data data-tag 1180 10. Appendix B: Mapping of Each Operation in the Encoding 1182 The next three tables show the results of applying the rules above to 1183 the operations defined in the IPP model document. There is no 1184 information in these tables that cannot be derived from the rules 1185 presented in Section 3.8 "Mapping of Parameter Names". 1187 The following table shows the mapping of all IPP model document request 1188 parameters to a parameter-sequence, attribute-sequence or special 1189 position in the protocol. 1191 Operation parameter- attribute- special position 1192 sequence sequence 1194 Get-Operations printer-uri 1195 Print-Job printer-uri job-template document-content 1196 best-effort attributes 1197 job-name document 1198 attributes 1199 Print-URI printer-uri job-template 1200 best-effort attributes 1201 job-name document 1202 document-uri attributes 1203 Validate-Job or printer-uri job-template 1204 Create-Job best-effort attributes 1205 job-name 1206 Send-Document job-uri document document-content 1207 last-document attributes 1208 Send-URI job-uri document 1209 last-document attributes 1210 document-uri 1211 Cancel-Job job-uri 1212 message 1213 Get-Attributes printer-uri 1214 (for a Printer) document- 1215 format 1216 requested- 1217 attributes 1218 Get-Attributes job-uri 1219 (for a Job) document- 1220 format 1221 requested- 1222 attributes 1223 Get-Jobs printer-uri 1224 limit 1225 requested- 1226 attributes 1228 The following table shows the mapping of all IPP model document response 1229 parameters to a parameter-sequence, attribute-sequence or special 1230 position in the protocol. 1232 Operation parameter-sequence attribute-sequence special 1233 position 1235 Get-Operations status-message status-code 1236 supported-operations 1238 Print-Job, status-message job-status status-code 1239 Print-URI or job-uri attributes 1240 Create-Job 1242 Send-Document status-message job-status status-code 1243 or Send-URI attributes 1245 Validate-Job status-message status-code 1247 Cancel-Job status-message status-code 1249 Get-Attributes status-message requested attributes status-code 1251 Get-Jobs status-message requested attributes status-code 1252 (see the Note below) 1254 Note for Get-Jobs: there is a separate attribute-sequence containing 1255 requested-attributes for each job object in the response 1257 The following table shows the mapping of all IPP model document error 1258 response parameters to a parameter-sequence, attribute-sequence or 1259 special position in the protocol. Those operations omitted don't have 1260 special parameters for an error return. 1262 Operation parameter- attribute-sequence special 1263 sequence position 1265 Print-Job, status-message unsupported attributes status-code 1266 Print-URI, 1267 Validate-Job, 1268 Create-Job, 1269 Send-Document or 1270 Send-URI