idnits 2.17.1 draft-ietf-ipp-protocol-05.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: ---------------------------------------------------------------------------- ** 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 31 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 71 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 8 instances of too long lines in the document, the longest one being 28 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 86 has weird spacing: '...ding of the O...' == Line 131 has weird spacing: '...ists of a mes...' == Line 144 has weird spacing: '...ding of the O...' == Line 153 has weird spacing: '...portant types...' == Line 154 has weird spacing: '...ch most other...' == (66 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 (January 9, 1998) is 9575 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 section? 'IPP-PRO' on line 1514 looks like a reference -- Missing reference section? 'IPP-MOD' on line 1503 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Robert Herriot (editor) 3 Sun Microsystems 4 Sylvan Butler 5 Hewlett-Packard 6 Paul Moore 7 Microsoft 8 Randy Turner 9 Sharp Labs 10 January 9, 1998 12 Internet Printing Protocol/1.0: Protocol Specification 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, and 18 its working groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference material 24 or to cite them other than as "work in progress". 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Copyright Notice 34 Copyright (C)The Internet Society (1998). All Rights Reserved. 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 40 application level protocol that can be used for distributed printing 41 using Internet tools and technology. The protocol is heavily influenced 42 by the printing model introduced in the Document Printing Application 43 (ISO/IEC 10175 DPA) standard [dpa]. Although DPA specifies both end 44 user and administrative features, IPP version 1.0 is focused only on end 45 user functionality. 47 The full set of IPP documents includes: 49 Requirements for an Internet Printing Protocol [ipp-req] 50 Internet Printing Protocol/1.0: Model and Semantics [ipp-mod] 51 Internet Printing Protocol/1.0: Protocol Specification (this 52 document) 54 The requirements document takes a broad look at distributed printing 55 functionality, and it enumerates real-life scenarios that help to 56 clarify the features that need to be included in a printing protocol for 57 the Internet. It identifies requirements for three types of users: end 58 users, operators, and administrators. The requirements document calls 59 out a subset of end user requirements that MUST be satisfied in the 60 first version of IPP. Operator and administrator requirements are out 61 of scope for v1.0. The model and semantics document describes a 62 simplified model with abstract objects, their attributes, and their 63 operations. The model introduces a Printer object and a Job object. The 64 Job object supports multiple documents per job. The protocol 65 specification is formal document which incorporates the ideas in all the 66 other documents into a concrete mapping using clearly defined data 67 representations and transport protocol mappings that real implementers 68 can use to develop interoperable client and printer (server) side 69 components. 71 This document is the ''Internet Printing Protocol/1.0: Protocol 72 Specification'' document. 74 Notice 76 The IETF invites any interested party to bring to its attention any 77 copyrights, patents or patent applications, or other proprietary rights 78 which may cover technology that may be required to practice this 79 standard. Please address the information to the IETF Executive 80 Director. 82 Table of Contents 84 1. Introduction........................................................4 85 2. Conformance Terminology.............................................4 86 3. Encoding of the Operation Layer....................................4 87 3.1 Picture of the Encoding.........................................4 88 3.2 Syntax of Encoding..............................................7 89 3.3 Version-number..................................................8 90 3.4 Operation-id....................................................8 91 3.5 Status-code.....................................................8 92 3.6 Request-id......................................................8 93 3.7 Tags............................................................. 94 3.7.1 Delimiter Tags.............................................8 95 3.7.2 Value Tags.................................................9 96 3.8 Name-Length....................................................11 97 3.9 (Attribute) Name...............................................11 98 3.10 Value Length..................................................12 99 3.11 (Attribute) Value.............................................12 100 3.12 Data............................................................ 101 4. Encoding of Transport Layer........................................13 102 4.1 General Headers................................................14 103 4.2 Request Headers...............................................14 104 4.3 Response Headers...............................................14 105 4.4 Entity Headers................................................14 106 5. Security Considerations............................................16 107 6. References.........................................................16 108 7. Author's Address...................................................17 109 8. Other Participants:................................................18 110 9. Appendix A: Protocol Examples......................................18 111 9.1 Print-Job Request..............................................18 112 9.2 Print-Job Response (successful)................................19 113 9.3 Print-Job Response (failure)...................................20 114 9.4 Print-URI Request..............................................21 115 9.5 Create-Job Request.............................................22 116 9.6 Get-Jobs Request...............................................22 117 9.7 Get-Jobs Response..............................................23 118 10. Appendix B: Hints to implementors using IPP with SSL3.............24 119 11. Appendix C: Registration of MIME Media Type Information for 120 "application/ipp".....................................................25 121 12. Appendix D: Full Copyright Statement..............................26 122 1. Introduction 124 This document contains the rules for encoding IPP operations and 125 describes two layers: the transport layer and the operation layer. 127 The transport layer consists of an HTTP/1.1 request or response. RFC 128 2068 [rfc2068] describes HTTP/1.1. This document specifies the HTTP 129 headers that an IPP implementation supports. 131 The operation layer consists of a message body in an HTTP request or 132 response. The document "Internet Printing Protocol/1.0: Model and 133 Semantics" [ipp-mod] defines the semantics of such a message body and 134 the supported values. This document specifies the encoding of an IPP 135 operation. The aforementioned document [ipp-mod] is henceforth referred 136 to as the "IPP model document" 138 2. Conformance Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [rfc2119]. 144 3. Encoding of the Operation Layer 146 The operation layer SHALL contain a single operation request or 147 operation response. Each request or response consists of a sequence of 148 values and attribute groups. Attribute groups consist of a sequence of 149 attributes each of which is a name and value. Names and values are 150 ultimately sequences of octets 152 The encoding consists of octets as the most primitive type. There are 153 several types built from octets, but three important types are 154 integers, character strings and octet strings, on which most other 155 data types are built. Every character string in this encoding SHALL be a 156 sequence of characters where the characters are associated with some 157 charset and some natural language. . A character string MUST be in 158 "reading order" with the first character in the value (according to 159 reading order) being the first character in the encoding. A character 160 string whose associated charset is US-ASCII whose associated natural 161 language is US English is henceforth called a US-ASCII-STRING. A 162 character string whose associated charset and natural language are 163 specified in a request or response as described in the model document is 164 henceforth called a LOCALIZED-STRING. An octet string MUST be in "IPP 165 model document order" with the first octet in the value (according to 166 the IPP model document order) being the first octet in the encoding 167 Every integer in this encoding SHALL be encoded as a signed integer 168 using two's-complement binary encoding with big-endian format (also 169 known as "network order" and "most significant byte first"). The number 170 of octets for an integer SHALL be 1, 2 or 4, depending on usage in the 171 protocol. Such one-octet integers, henceforth called SIGNED-BYTE, are 172 used for the version-number and tag fields. Such two-byte integers, 173 henceforth called SIGNED-SHORT are used for the operation-id, status- 174 code and length fields. Four byte integers, henceforth called SIGNED- 175 INTEGER, are used for values fields and the sequence number. 177 The following two sections present the operation layer in two ways 179 . informally through pictures and description 180 . formally through Augmented Backus-Naur Form (ABNF), as specified by 181 RFC 2234 [rfc2234] 183 3.1 Picture of the Encoding 185 The encoding for an operation request or response consists of: 187 ----------------------------------------------- 188 | version-number | 2 bytes - required 189 ----------------------------------------------- 190 | operation-id (request) | 191 | or | 2 bytes - required 192 | status-code (response) | 193 ----------------------------------------------- 194 | request-id | 4 bytes - required 195 ----------------------------------------------------------- 196 | xxx-attributes-tag | 1 byte | 197 ----------------------------------------------- |-0 or more 198 | xxx-attribute-sequence | n bytes | 199 ----------------------------------------------------------- 200 | end-of-attributes-tag | 1 byte - required 201 ----------------------------------------------- 202 | data | q bytes - optional 203 ----------------------------------------------- 205 The xxx-attributes-tag and xxx-attribute-sequence represents four 206 different values of "xxx", namely, operation, job, printer and 207 unsupported. The xxx-attributes-tag and an xxx-attribute-sequence 208 represent attribute groups in the model document. The xxx-attributes-tag 209 identifies the attribute group and the xxx-attribute-sequence contains 210 the attributes. 212 The expected sequence of xxx-attributes-tag and xxx-attribute-sequence 213 is specified in the IPP model document for each operation request and 214 operation response. 216 A request or response SHOULD contain each xxx-attributes-tag defined for 217 that request or response even if there are no attributes except for the 218 unsupported-attributes-tag which SHOULD be present only if the 219 unsupported-attribute-sequence is non-empty. A receiver of a request 220 SHALL be able to process as equivalent empty attribute groups: 222 a) an xxx-attributes-tag with an empty xxx-attribute-sequence, 224 b) an expected but missing xxx-attributes-tag. 226 The data is omitted from some operations, but the end-of-attributes-tag 227 is present even when the data is omitted. Note, the xxx-attributes-tags 228 and end-of-attributes-tag are called `delimiter-tags'. Note: the xxx- 229 attribute-sequence, shown above may consist of 0 bytes, according to the 230 rule below. 232 An xxx-attributes-sequence consists of zero or more compound-attributes. 234 ----------------------------------------------- 235 | compound-attribute | s bytes - 0 or more 236 ----------------------------------------------- 238 A compound-attribute consists of an attribute with a single value 239 followed by zero or more additional values. 241 Note: a `compound-attribute' represents a single attribute in the model 242 document. The `additional value' syntax is for attributes with 2 or 243 more values. 245 Each attribute consists of: 247 ----------------------------------------------- 248 | value-tag | 1 byte 249 ----------------------------------------------- 250 | name-length (value is u) | 2 bytes 251 ----------------------------------------------- 252 | name | u bytes 253 ----------------------------------------------- 254 | value-length (value is v) | 2 bytes 255 ----------------------------------------------- 256 | value | v bytes 257 ----------------------------------------------- 259 An additional value consists of: 261 ----------------------------------------------------------- 262 | value-tag | 1 byte | 263 ----------------------------------------------- | 264 | name-length (value is 0x0000) | 2 bytes | 265 ----------------------------------------------- |-0 or more 266 | value-length (value is w) | 2 bytes | 267 ----------------------------------------------- | 268 | value | w bytes | 269 ----------------------------------------------------------- 271 Note: an additional value is like an attribute whose name-length is 0. 273 From the standpoint of a parsing loop, the encoding consists of: 275 ----------------------------------------------- 276 | version-number | 2 bytes - required 277 ----------------------------------------------- 278 | operation-id (request) | 279 | or | 2 bytes - required 280 | status-code (response) | 281 ----------------------------------------------- 282 | request-id | 4 bytes - required 283 ----------------------------------------------------------- 284 | tag (delimiter-tag or value-tag) | 1 byte | 285 ----------------------------------------------- |-0 or more 286 | empty or rest of attribute | x bytes | 287 ----------------------------------------------------------- 288 | end-of-attributes-tag | 2 bytes - required 289 ----------------------------------------------- 290 | data | y bytes - optional 291 ----------------------------------------------- 293 The value of the tag determines whether the bytes following the tag are: 295 . attributes 296 . data 297 . the remainder of a single attribute where the tag specifies the 298 type of the value. 300 3.2 Syntax of Encoding 302 The syntax below is ABNF [rfc2234] except `strings of literals' SHALL be 303 case sensitive. For example `a' means lower case `a' and not upper case 304 `A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields are represented 305 as `%x' values which show their range of values. 307 ipp-message = ipp-request / ipp-response 308 ipp-request = version-number operation-id request-id 309 *(xxx-attributes-tag xxx-attribute-sequence) end-of- 310 attributes-tag data 311 ipp-response = version-number status-code request-id 312 *(xxx-attributes-tag xxx-attribute-sequence) end-of- 313 attributes-tag data 314 xxx-attribute-sequence = *compound-attribute 316 xxx-attributes-tag = operation-attributes-tag / job-attributes-tag / 317 printer-attributes-tag / unsupported-attributes-tag 319 version-number = major-version-number minor-version-number 320 major-version-number = SIGNED-BYTE ; initially %d1 321 minor-version-number = SIGNED-BYTE ; initially %d0 323 operation-id = SIGNED-SHORT ; mapping from model defined below 324 status-code = SIGNED-SHORT ; mapping from model defined below 325 request-id = SIGNED-INTEGER ; whose value is > 0 327 compound-attribute = attribute *additional-values 328 attribute = value-tag name-length name value-length value 329 additional-values = value-tag zero-name-length value-length value 331 name-length = SIGNED-SHORT ; number of octets of `name' 332 name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." ) 333 value-length = SIGNED-SHORT ; number of octets of `value' 334 value = OCTET-STRING 336 data = OCTET-STRING 338 zero-name-length = %x00.00 ; name-length of 0 339 operation-attributes-tag = %x01 ; tag of 1 340 job-attributes-tag = %x02 ; tag of 2 341 printer-attributes-tag = %x04 ; tag of 4 342 unsupported- attributes-tag = %x05 ; tag of 5 343 end-of-attributes-tag = %x03 344 ; tag of 3 345 value-tag = %x10-FF 347 SIGNED-BYTE = BYTE 348 SIGNED-SHORT = 2BYTE 349 DIGIT = %x30-39 ; "0" to "9" 350 LALPHA = %x61-7A ; "a" to "z" 351 BYTE = %x00-FF 352 OCTET-STRING = *BYTE 354 The syntax allows an xxx-attributes-tag to be present when the xxx- 355 attribute-sequence that follows is empty. The syntax is defined this way 356 to allow for the response of Get-Jobs where no attributes are returned 357 for some job-objects. Although it is RECOMMENDED that the sender not 358 send an xxx-attributes-tag if there are no attributes (except in the 359 Get-Jobs response just mentioned), the receiver MUST be able to decode 360 such syntax. 362 3.3 Version-number 364 The version-number SHALL consist of a major and minor version-number, 365 each of which SHALL be represented by a SIGNED-BYTE. The protocol 366 described in this document SHALL have a major version-number of 1 (0x01) 367 and a minor version-number of 0 (0x00). The ABNF for these two bytes 368 SHALL be %x01.00. 370 3.4 Operation-id 372 Operation-ids are defined as enums in the model document. An operation- 373 ids enum value SHALL be encoded as a SIGNED-SHORT 375 Note: the values 0x4000 to 0xFFFF are reserved for private extensions. 377 3.5 Status-code 379 Status-codes are defined as enums in the model document. A status-code 380 enum value SHALL be encoded as a SIGNED-SHORT 382 The status-code is an operation attribute in the model document. In the 383 protocol, the status-code is in a special position, outside of the 384 operation attributes. 386 If an IPP status-code is returned, then the HTTP Status-Code MUST be 200 387 (OK). With any other HTTP Status-Code value, the HTTP response SHALL NOT 388 contain an IPP message-body, and thus no IPP status-code is returned. 390 3.6 Request-id 392 The request-id allows a client to match a response with a request. This 393 mechanism is unnecessary in HTTP, but may be useful when application/ipp 394 entity bodies are used in another context. 396 The request-id in a response SHALL be the value of the request-id 397 received in the corresponding request. A client can set the request-id 398 in each request to a unique value or a constant value, such as 1, 399 depending on what the client does with the request-id returned in the 400 response. The value of the request-id MUST be greater than zero. 402 3.7 Tags 404 There are two kinds of tags: 406 . delimiter tags: delimit major sections of the protocol, namely 407 attributes and data 408 . value tags: specify the type of each attribute value 410 3.7.1 Delimiter Tags 412 The following table specifies the values for the delimiter tags: 414 Tag Value (Hex) Delimiter 416 0x00 reserved 417 0x01 operation-attributes-tag 418 0x02 job-attributes-tag 419 0x03 end-of-attributes-tag 420 0x04 printer-attributes-tag 421 0x05 unsupported-attributes-tag 422 0x06-0x0e reserved for future delimiters 423 0x0F reserved for future chunking-end-of-attributes- 424 tag 426 When an xxx-attributes-tag occurs in the protocol, it SHALL mean that 427 zero or more following attributes up to the next delimiter tag are 428 attributes belonging to group xxx as defined in the model document, 429 where xxx is operation, job, printer, unsupported. 431 Doing substitution for xxx in the above paragraph, this means the 432 following. When an operation-attributes-tag occurs in the protocol, it 433 SHALL mean that the zero or more following attributes up to the next 434 delimiter tag are operation attributes as defined in the model document. 435 When an job-attributes-tag occurs in the protocol, it SHALL mean that 436 the zero or more following attributes up to the next delimiter tag are 437 job attributes as defined in the model document. When an printer- 438 attributes-tag occurs in the protocol, it SHALL mean that the zero or 439 more following attributes up to the next delimiter tag are printer 440 attributes as defined in the model document. When an unsupported- 441 attributes-tag occurs in the protocol, it SHALL mean that the zero or 442 more following attributes up to the next delimiter tag are unsupported 443 attributes as defined in the model document. 445 The operation-attributes-tag and end-of-attributes-tag SHALL each occur 446 exactly once in an operation. The operation-attributes-tag SHALL be the 447 first tag delimiter, and the end-of-attributes-tag SHALL be the last 448 tag delimiter. If the operation has a document-content group, the 449 document data in that group SHALL follow the end-of-attributes-tag 451 Each of the other three xxx-attributes-tags defined above is OPTIONAL 452 in an operation and each SHALL occur at most once in an operation, 453 except for job-attributes-tag in a Get-Jobs response which may occur 454 zero or more times. 456 The order and presence of delimiter tags for each operation request and 457 each operation response SHALL be that defined in the model document. For 458 further details, see section 3.9 "(Attribute) Name" and .section 9 459 "Appendix A: Protocol Examples" 461 A Printer SHALL treat the reserved delimiter tags differently from 462 reserved value tags so that the Printer knows that there is an entire 463 attribute group that it doesn't understand as opposed to a single value 464 that it doesn't understand. 466 3.7.2 Value Tags 468 The remaining tables show values for the value-tag, which is the first 469 octet of an attribute. The value-tag specifies the type of the value of 470 the attribute. The following table specifies the "out-of-band" values 471 for the value-tag. 473 Tag Value (Hex) Meaning 475 0x10 unsupported 476 0x11 reserved for future `default' 477 0x12 unknown 478 Tag Value (Hex) Meaning 480 0x13 no-value 481 0x14-0x1F reserved for future "out-of-band" values. 483 The "unsupported" value SHALL be used in the attribute-sequence of an 484 error response for those attributes which the printer does not support. 485 The "default" value is reserved for future use of setting value back to 486 their default value. The "unknown" value is used for the value of a 487 supported attribute when its value is temporarily unknown. . The "no- 488 value" value is used for a supported attribute to which no value has 489 been assigned, e.g. "job-k-octets-supported" has no value if an 490 implementation supports this attribute, but an administrator has not 491 configured the printer to have a limit. 493 The following table specifies the integer values for the value-tag 495 Tag Value (Hex) Meaning 497 0x20 reserved 498 0x21 integer 499 0x22 boolean 500 0x23 enum 501 0x24-0x2F reserved for future integer types 503 NOTE: 0x20 is reserved for "generic integer" if should ever be needed. 505 The following table specifies the octetString values for the value-tag 507 Tag Value (Hex) Meaning 509 0x30 octetString with an unspecified format 510 0x31 dateTime 511 0x32 resolution 512 0x33 rangeOfInteger 513 0x34 reserved for dictionary (in the future) 514 0x35 textWithLanguage 515 0x36 nameWithLanguage 516 0x37-0x3F reserved for future octetString types 518 The following table specifies the character-string values for the value- 519 tag 521 Tag Value (Hex) Meaning 523 0x40 reserved 524 0x41 text 525 0x42 name 526 0x43 reserved 527 0x44 keyword 528 Tag Value (Hex) Meaning 530 0x45 uri 531 0x46 uriScheme 532 0x47 charset 533 0x48 naturalLanguage 534 0x49 mimeMediaType 535 0x4A-0x5F reserved for future character string types 537 NOTE: 0x40 is reserved for "generic character-string" if should ever be 538 needed. 540 The values 0x60-0xFF are reserved for future types. There are no values 541 allocated for private extensions. A new type must be registered via the 542 type 2 process. 544 3.8 Name-Length 546 The name-length field SHALL consist of a SIGNED-SHORT. This field SHALL 547 specify the number of octets in the name field which follows the name- 548 length field, excluding the two bytes of the name-length field. 550 If a name-length field has a value of zero, the following name field 551 SHALL be empty, and the following value SHALL be treated as an 552 additional value for the preceding attribute. Within an attribute- 553 sequence, if two attributes have the same name, the first occurrence 554 SHALL be ignored. The zero-length name is the only mechanism for multi- 555 valued attributes. 557 3.9 (Attribute) Name 559 Some attributes are encoded in a special position. These attribute are: 561 . "printer-uri": When the target is a printer and the transport is 562 HTTP or HTTP (for TLS), the target printer-uri defined in each 563 operation in the IPP model document SHALL be an operation attribute 564 called "printer-uri" and it SHALL also be specified outside of the 565 operation layer as the request-URI on the Request-Line at the HTTP 566 level. This 567 . "job-uri": When the target is a job and the transport is HTTP or 568 HTTPS (for TLS), the target job-uri of each operation in the IPP 569 model document SHALL be an operation attribute called "job-uri" and 570 it SHALL also be specified outside of the operation layer as the 571 request-URI on the Request-Line at the HTTP level. 572 . "version-number": The attribute named "version-number" in the IPP 573 model document SHALL become the "version-number" field in the 574 operation layer request or response. It SHALL NOT appear as an 575 operation attribute. 576 . "operation-id": The attribute named "operation-id" in the IPP model 577 document SHALL become the "operation-id" field in the operation 578 layer request. It SHALL NOT appear as an operation attribute. 580 . "status-code": The attribute named "status-code" in the IPP model 581 document SHALL become the "status-code" field in the operation 582 layer response. It SHALL NOT appear as an operation attribute. 583 . "request-id": The attribute named "request-id" in the IPP model 584 document SHALL become the "request-id" field in the operation layer 585 request or response. It SHALL NOT appear as an operation attribute. 587 The model document arranges the remaining attributes into groups for 588 each operation request and response. Each such group SHALL be 589 represented in the protocol by an xxx-attribute-sequence preceded by the 590 appropriate xxx-attributes-tag (See the table below and section 9 591 "Appendix A: Protocol Examples"). In addition, the order of these xxx- 592 attributes-tags and xxx-attribute-sequences in the protocol SHALL be the 593 same as in the model document, but the order of attributes within each 594 xxx-attribute-sequence SHALL be unspecified. The table below maps the 595 model document group name to xxx-attributes-sequence 597 Model Document Group xxx-attributes-sequence 599 Operation Attributes operations-attributes-sequence 600 Job Template Attributes job-attributes-sequence 601 Job Object Attributes job-attributes-sequence 602 Unsupported Attributes unsupported- attributes-sequence 603 Requested Attributes (Get- job-attributes-sequence 604 Job-Attributes) 605 Requested Attributes (Get- printer-attributes-sequence 606 Printer-Attributes) 607 Document Content in a special position as described above 609 If an operation contains attributes from more than one job object (e.g. 610 Get-Jobs response), the attributes from each job object SHALL be in a 611 separate job-attribute-sequence, such that the attributes from the ith 612 job object are in the ith job-attribute-sequence. See Section 9 613 "Appendix A: Protocol Examples" for table showing the application of the 614 rules above. 616 3.10 Value Length 618 Each attribute value SHALL be preceded by a SIGNED-SHORT which SHALL 619 specify the number of octets in the value which follows this length, 620 exclusive of the two bytes specifying the length. 622 For any of the types represented by binary signed integers, the sender 623 MUST encode the value in exactly four octets.. 625 For any of the types represented by character-strings, the sender MUST 626 encode the value with all the characters of the string and without any 627 padding characters. 629 If a value-tag contains an "out-of-band" value, such as "unsupported", 630 the value-length SHALL be 0 and the value empty " the value has no 631 meaning when the value-tag has an "out-of-band" value. If a client 632 receives a response with a nonzero value-length in this case, it SHALL 633 ignore the value field. If a printer receives a request with a nonzero 634 value-length in this case, it SHALL reject the request. 636 3.11 (Attribute) Value 638 The syntax types and most of the details of their representation are 639 defined in the IPP model document. The table below augments the 640 information in the model document, and defines the syntax types from the 641 model document in terms of the 5 basic types defined in section 3 642 "Encoding of the Operation Layer". The 5 types are US-ASCII-STRING, 643 LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET- 644 STRING. 646 Syntax of Encoding 647 Attribute Value 649 text, name LOCALIZED-STRING. 651 textWithLanguage OCTET"STRING consisting of 4 fields: 652 a) a SIGNED-SHORT which is the number of octets 653 in the following field 654 b) a value of type natural-language, 655 c) a SIGNED-SHORT which is the number of octets 656 in the following field, 657 d) a value of type text. 658 The length of a textWithLanguage value SHALL be 659 4 + the value of field a + the value of field c. 660 nameWithLanguage OCTET"STRING consisting of 4 fields: 661 a) a SIGNED-SHORT which is the number of octets 662 in the following field 663 b) a value of type natural-language, 664 c) a SIGNED-SHORT which is the number of octets 665 in the following field 666 d) a value of type name. 667 The length of a nameWithLanguage value SHALL be 668 4 + the value of field a + the value of field c. 669 charset, US-ASCII-STRING 670 naturalLanguage, 671 mimeMediaType, 672 keyword, uri, 673 and uriScheme 674 boolean SIGNED-BYTE where 0x00 is `false' and 0x01 is 675 `true' 676 integer and enum a SIGNED-INTEGER 677 dateTime OCTET-STRING consisting of eleven octets whose 678 contents are defined by "DateAndTime" in RFC 1903 679 [rfc1903]. 680 resolution OCTET"STRING consisting of nine octets of 2 681 SIGNED-INTEGERs followed by a SIGNED-BYTE. The 682 first SIGNED-INTEGER contains the value of cross 683 feed direction resolution . The second SIGNED- 685 Syntax of Encoding 686 Attribute Value 688 INTEGER contains the value of feed direction 689 resolution. The SIGNED-BYTE contains the units 690 value. 691 rangeOfInteger Eight octets consisting of 2 SIGNED-INTEGERs. The 692 first SIGNED-INTEGERs contains the lower bound 693 and the second SIGNED-INTEGERs contains the upper 694 bound 695 1setOf X encoding according to the rules for an attribute 696 with more than 1 value. Each value X is encoded 697 according to the rules for encoding its type. 698 octetString OCTET-STRING 700 The type of the value in the model document determines the encoding in 701 the value and the value of the value-tag. 703 3.12 Data 705 The data part SHALL include any data required by the operation 707 4. Encoding of Transport Layer 709 HTTP/1.1 shall be the transport layer for this protocol. 711 The operation layer has been designed with the assumption that the 712 transport layer contains the following information: 714 . the URI of the target job or printer operation 715 . the total length of the data in the operation layer, either as a 716 single length or as a sequence of chunks each with a length. 718 It is REQUIRED that a printer support HTTP over port 80, though a 719 printer may support HTTP over port some other port. In addition, a 720 printer may have to support another port for privacy (See Section 5 721 "Security Considerations". 723 Note: Consistent with RFC 2068 (HTTP/1.1), HTTP URI's for IPP implicitly 724 reference port 80. If a URI references some other port, the port number 725 must be explicitly specified in the URI. 727 Each HTTP operation shall use the POST method where the request-URI is 728 the object target of the operation, and where the "Content-Type" of the 729 message-body in each request and response shall be "application/ipp". 730 The message-body shall contain the operation layer and shall have the 731 syntax described in section 3.2 "Syntax of Encoding". A client 732 implementation SHALL adhere to the rules for a client described in RFC 733 2068 [rfc2068]. A printer (server) implementation SHALL adhere the rules 734 for an origin server described in RFC 2068. 736 The IPP layer doesn't have to deal with chunking. In the context of CGI 737 scripts, the HTTP layer removes any chunking information in the received 738 data. 740 A client SHALL NOT expect a response from an IPP server until after the 741 client has sent the entire response. But a client MAY listen for an 742 error response that an IPP server MAY send before it receives all the 743 data. In this case a client, if chunking the data, can send a premature 744 zero-length chunk to end the request before sending all the data. If the 745 request is blocked for some reason, a client MAY determine the reason by 746 opening another connection to query the server. 748 In the following sections, there are a tables of all HTTP headers which 749 describe their use in an IPP client or server. The following is an 750 explanation of each column in these tables. 752 . the "header" column contains the name of a header 753 . the "request/client" column indicates whether a client sends the 754 header. 755 . the "request/ server" column indicates whether a server supports 756 the header when received. 757 . the "response/ server" column indicates whether a server sends the 758 header. 759 . the "response /client" column indicates whether a client supports 760 the header when received. 761 . the "values and conditions" column specifies the allowed header 762 values and the conditions for the header to be present in a 763 request/response. 765 The table for "request headers" does not have columns for responses, and 766 the table for "response headers" does not have columns for requests. 768 The following is an explanation of the values in the "request/client" 769 and "response/ server" columns. 771 . must: the client or server MUST send the header, 772 . must-if: the client or server MUST send the header when the 773 condition described in the "values and conditions" column is met, 774 . may: the client or server MAY send the header 775 . not: the client or server SHOULD NOT send the header. It is not 776 relevant to an IPP implementation. 778 The following is an explanation of the values in the "response/client" 779 and "request/ server" columns. 781 . must: the client or server MUST support the header, 782 . may: the client or server MAY support the header 783 . not: the client or server SHOULD NOT support the header. It is not 784 relevant to an IPP implementation. 786 4.1 General Headers 788 The following is a table for the general headers. 790 General- Request Response Values and Conditions 791 Header 793 Client Server Server Client 795 Cache- must not must not "no-cache" only 796 Control 797 Connection must-if must must- must "close" only. Both 798 if client and server 799 SHOULD keep a 800 connection for the 801 duration of a sequence 802 of operations. The 803 client and server MUST 804 include this header 805 for the last operation 806 in such a sequence. 807 Date may may must may per RFC 1123 [rfc1123] 808 from RFC 2068 809 Pragma` must not must not "no-cache" only 810 Transfer- must-if must must- must "chunked" only . 811 Encoding if Header MUST be present 812 if Content-Length is 813 absent. 814 Upgrade not not not not 815 Via not not not not 817 4.2 Request Headers 819 The following is a table for the request headers. 821 Request-Header Client Server Request Values and Conditions 823 Accept may must "application/ipp" only. This 824 value is the default if the 825 client omits it 826 Accept-Charset not not Charset information is within 827 the application/ipp entity 828 Accept-Encoding may must empty and per RFC 2068 [rfc2068] 829 and IANA registry for content- 830 codings 831 Accept-Language not not . language information is within 832 the application/ipp entity 833 Authorization must-if must per RFC 2068. A client MUST send 834 this header when it receives a 835 401 "Unauthorized" response and 836 does not receive a "Proxy- 837 Authenticate" header. 839 Request-Header Client Server Request Values and Conditions 841 From not not per RFC 2068. Because RFC 842 recommends sending this header 843 only with the user's approval, it 844 is not very useful 845 Host must must per RFC 2068 846 If-Match not not 847 If-Modified- not not 848 Since 849 If-None-Match not not 850 If-Range not not 851 If-Unmodified- not not 852 Since 853 Max-Forwards not not 854 Proxy- must-if not per RFC 2068. A client MUST send 855 Authorization this header when it receives a 856 401 "Unauthorized" response and a 857 "Proxy-Authenticate" header. 858 Range not not 859 Referer not not 860 User-Agent not not 862 4.3 Response Headers 864 The following is a table for the request headers. 866 Response- Server Client Response Values and Conditions 867 Header 869 Accept-Ranges not not 870 Age not not 871 Location must-if may per RFC 2068. When URI needs 872 redirection. 873 Proxy- not must per RFC 2068 874 Authenticate 875 Public may may per RFC 2068 876 Retry-After may may per RFC 2068 877 Server not not 878 Vary not not 879 Warning may may per RFC 2068 880 WWW- must-if must per RFC 2068. When a server needs to 881 Authenticate authenticate a client. 883 4.4 Entity Headers 885 The following is a table for the entity headers. 887 Entity-Header Request Response Values and Conditions 888 Client Server Server Client 890 Allow not not not not 891 Content-Base not not not not 892 Content- may must must must per RFC 2068 and IANA 893 Encoding registry for content 894 codings. 895 Content- not not not not Application/ipp 896 Language handles language 897 Content- must-if must must-if must the length of the 898 Length message-body per RFC 899 2068. Header MUST be 900 present if Transfer- 901 Encoding is absent.. 902 Content- not not not not 903 Location 904 Content-MD5 may may may may per RFC 2068 905 Content-Range not not not not 906 Content-Type must must must must "application/ipp" 907 only 908 ETag not not not not 909 Expires not not not not 910 Last-Modified not not not not 912 5. Security Considerations 914 The IPP Model document defines an IPP implementation with "privacy" as 915 one that implements Transport Layer Security (TLS) Version 1.0. TLS 916 meets the requirements for IPP security with regards to features such as 917 mutual authentication and privacy (via encryption). The IPP Model 918 document also outlines IPP-specific security considerations and should 919 be the primary reference for security implications with regards to the 920 IPP protocol itself. 922 The IPP Model document defines an IPP implementation with 923 "authentication" as one that implements the standard way for 924 transporting IPP messages within HTTP 1.1. , These include the security 925 considerations outlined in the HTTP 1.1 standard document [rfc2068] and 926 Digest Authentication extension [rfc2069].. 928 The current HTTP infrastructure supports HTTP over TCP port 80. IPP 929 servers MUST offer IPP services using HTTP over this port. IPP servers 930 are free to advertise services over other ports, in addition to this 931 port, but TCP port 80 MUST minimally be supported for IPP-over-HTTP 932 services. 934 When IPP-over-HTTP-with-privacy implementations are deployed, these IPP 935 implementations MUST use TCP port 443, and MUST advertise their IPP 936 service URI using an "HTTPS" URI scheme. 938 See further discussion of IPP security concepts in the model document 939 6. References 941 [rfc822] Crocker, D., "Standard for the Format of ARPA 942 Internet Text Messages", RFC 822, August 1982. 944 [rfc1123] Braden, S., "Requirements for Internet Hosts - 945 Application and Support", RFC 1123, October, 1989, 947 [rfc1179] McLaughlin, L. III, (editor), "Line Printer Daemon 948 Protocol" RFC 1179, August 1990. 950 [rfc1630] T. Berners-Lee, "Universal Resource Identifiers in WWW: 951 A Unifying Syntax for the Expression of Names and Addresses of 952 Objects on the Network as used in the Word-Wide Web", RFC 1630, 953 June 1994. 955 [rfc1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and 956 Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. 958 [rfc1738] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform 959 Resource Locators (URL)", RFC 1738, December, 1994. 961 [rfc1543] Postel, J., "Instructions to RFC Authors", RFC 1543, 962 October 1993. 964 [rfc1766] H. Alvestrand, " Tags for the Identification of 965 Languages", RFC 1766, March 1995. 967 [rfc1903} J. Case, et al. "Textual Conventions for Version 2 of 968 the Simple Network Management Protocol (SNMPv2)", RFC 1903, 969 January 1996. 971 [rfc2046] N. Freed & N. Borenstein, Multipurpose Internet Mail 972 Extensions (MIME) Part Two: Media Types. November 1996. 973 (Obsoletes RFC1521, RFC1522, RFC1590), RFC 2046. 975 [rfc2048] N. Freed, J. Klensin & J. Postel. Multipurpose Internet 976 Mail Extension (MIME) Part Four: Registration Procedures. 977 November 1996. (Format: TXT=45033 bytes) (Obsoletes RFC1521, 978 RFC1522, RFC1590) (Also BCP0013), RFC 2048. 980 [rfc2068] R Fielding, et al, "Hypertext Transfer Protocol " 981 HTTP/1.1" RFC 2068, January 1997 983 [rfc2069] J. Franks, et al, "An Extension to HTTP: Digest Access 984 Authentication" RFC 2069, January 1997 986 [rfc2119] S. Bradner, "Key words for use in RFCs to Indicate 987 Requirement Levels", RFC 2119 , March 1997 989 [rfc2184] N. Freed, K. Moore, "MIME Parameter Value and Encoded 990 Word Extensions: Character Sets, Languages, and Continuations", 991 RFC 2184, August 1997, 993 [rfc2234] D. Crocker et al., "Augmented BNF for Syntax 994 Specifications: ABNF", RFC 2234. November 1997. 996 [char] N. Freed, J. Postel: IANA Charset Registration Procedures, Work 997 in Progress (draft-freed-charset-reg-02.txt). 999 [dpa] ISO/IEC 10175 Document Printing Application (DPA), June 1996. 1001 [iana] IANA Registry of Coded Character Sets: ftp://ftp.isi.edu/in- 1002 notes/iana/assignments/character-sets 1004 [ipp-req] Wright, F. D., "Requirements for an Internet Printing 1005 Protocol:", draft-ietf-ipp-req-01.txt 1007 [ipp-mod] Isaacson, S, deBry, R, Hastings, T, Herriot, R, Powell, 1008 P, "Internet Printing Protocol/1.0: Model and Semantics" , draft- 1009 ietf-ipp-model-09.txt 1011 [ssl] Netscape, The SSL Protocol, Version 3, (Text version 3.02) 1012 November 1996. 1014 7. Author's Address 1016 Robert Herriot (editor) Paul Moore 1017 Sun Microsystems Inc. Microsoft 1018 901 San Antonio Road, MPK-17 One Microsoft Way 1019 Palo Alto, CA 94303 Redmond, WA 98053 1021 Phone: 650-786-8995 Phone: 425-936-0908 1022 Fax: 650-786-7077 Fax: 425-93MS-FAX 1023 Email: robert.herriot@eng.sun.com Email: paulmo@microsoft.com 1025 Sylvan Butler Randy Turner 1026 Hewlett-Packard Sharp Laboratories 1027 11311 Chinden Blvd. 5750 NW Pacific Rim Blvd 1028 Boise, ID 83714 Camas, WA 98607 1030 Phone: 208-396-6000 Phone: 360-817-8456 1031 Fax: 208-396-3457 Fax: : 360-817-8436 1032 Email: sbutler@boi.hp.com Email: rturner@sharplabs.com 1034 IPP Mailing List: ipp@pwg.org 1035 IPP Mailing List Subscription: ipp-request@pwg.org 1036 IPP Web Page: http://www.pwg.org/ipp/ 1038 8. Other Participants: 1040 Chuck Adams - Tektronix Harry Lewis - IBM 1041 Ron Bergman - Dataproducts Tony Liao - Vivid Image 1042 Keith Carter - IBM David Manchala - Xerox 1043 Angelo Caruso - Xerox Carl-Uno Manros - Xerox 1044 Jeff Copeland - QMS Jay Martin - Underscore 1045 Roger Debry - IBM Larry Masinter - Xerox 1046 Lee Farrell - Canon Ira McDonald, Xerox 1047 Sue Gleeson - Digital Bob Pentecost - Hewlett-Packard 1048 Charles Gordon - Osicom Patrick Powell - SDSU 1049 Brian Grimshaw - Apple Jeff Rackowitz - Intermec 1050 Jerry Hadsell - IBM Xavier Riley - Xerox 1051 Richard Hart - Digital Gary Roberts - Ricoh 1052 Tom Hastings - Xerox Stuart Rowley - Kyocera 1053 Stephen Holmstead Richard Schneider - Epson 1054 Zhi-Hong Huang - Zenographics Shigern Ueda - Canon 1055 Scott Isaacson - Novell Bob Von Andel - Allegro Software 1056 Rich Lomicka - Digital William Wagner - Digital Products 1057 David Kellerman - Northlake Jasper Wong - Xionics 1058 Software 1059 Robert Kline - TrueSpectra Don Wright - Lexmark 1060 Dave Kuntz - Hewlett-Packard Rick Yardumian - Xerox 1061 Takami Kurono - Brother Lloyd Young - Lexmark 1062 Rich Landau - Digital Peter Zehler - Xerox 1063 Greg LeClair - Epson Frank Zhao - Panasonic 1064 Steve Zilles - Adobe 1066 9. Appendix A: Protocol Examples 1068 9.1 Print-Job Request 1070 The following is an example of a Print-Job request with job-name, 1071 copies, and sides specified. 1073 Octets Symbolic Value Protocol field 1075 0x0100 1.0 version-number 1076 0x0002 PrintJob operation-id 1077 0x00000001 1 request-id 1078 0x01 start operation- operation-attributes-tag 1079 attributes 1080 0x47 charset type value-tag 1081 0x0012 name-length 1082 attributes-charset attributes-charset name 1083 0x0008 value-length 1084 US-ASCII US-ASCII value 1085 0x48 natural-language value-tag 1086 type 1087 0x001B name-length 1088 attributes-natural- attributes-natural- name 1089 language language 1090 0x0005 value-length 1091 en-US en-US value 1092 0x42 name type value-tag 1093 0x0008 name-length 1094 job-name job-name name 1095 Octets Symbolic Value Protocol field 1097 0x0006 value-length 1098 foobar foobar value 1099 0x02 start job- job-attributes-tag 1100 attributes 1101 0x21 integer type value-tag 1102 0x0005 name-length 1103 copies copies name 1104 0x0004 value-length 1105 0x00000014 20 value 1106 0x44 keyword type value-tag 1107 0x0005 name-length 1108 sides sides name 1109 0x0013 value-length 1110 two-sided-long-edge two-sided-long-edge value 1111 0x03 end-of-attributes end-of-attributes-tag 1112 %!PS... data 1114 9.2 Print-Job Response (successful) 1116 Here is an example of a Print-Job response which is successful: 1118 Octets Symbolic Protocol field 1119 Value 1121 0x0100 1.0 version-number 1122 0x0000 OK status-code 1123 (successful) 1124 0x00000001 1 request-id 1125 0x01 start operation-attributes-tag 1126 operation- 1127 attributes 1128 0x47 charset type value-tag 1129 0x0012 name-length 1130 attributes- attributes- name 1131 charset charset 1132 0x0008 value-length 1133 US-ASCII US-ASCII value 1134 0x48 natural- value-tag 1135 language 1136 type 1137 0x001B name-length 1138 attributes- attributes- name 1139 natural- natural- 1140 language language 1141 0x0005 value-length 1142 en-US en-US value 1143 0x41 text type value-tag 1144 0x000E name-length 1145 status-message status- name 1146 message 1148 Octets Symbolic Protocol field 1149 Value 1151 0x0002 value-length 1152 OK OK value 1153 0x02 start job- job-attributes-tag 1154 attributes 1155 0x21 integer value-tag 1156 0x0007 name-length 1157 job-id job-id name 1158 0x0004 value-length 1159 147 147 value 1160 0x45 uri type value-tag 1161 0x0008 name-length 1162 job-uri job-uri name 1163 0x000E value-length 1164 http://foo/123 http://foo/1 value 1165 23 1166 0x25 name type value-tag 1167 0x0008 name-length 1168 job-state job-state name 1169 0x0001 value-length 1170 0x03 pending value 1171 0x03 end-of- end-of-attributes-tag 1172 attributes 1174 9.3 Print-Job Response (failure) 1176 Here is an example of a Print-Job response which fails because the 1177 printer does not support sides and because the value 20 for copies is 1178 not supported: 1180 Octets Symbolic Value Protocol field 1182 0x0100 1.0 version-number 1183 0x0400 client-error-bad- status-code 1184 request 1185 0x00000001 1 request-id 1186 0x01 start operation- operation-attribute tag 1187 attributes 1188 0x47 charset type value-tag 1189 0x0012 name-length 1190 attributes- attributes-charset name 1191 charset 1192 0x0008 value-length 1193 US-ASCII US-ASCII value 1194 0x48 natural-language type value-tag 1195 0x001B name-length 1196 attributes- attributes-natural- name 1197 natural- language 1198 language 1199 0x0005 value-length 1200 Octets Symbolic Value Protocol field 1202 en-US en-US value 1203 0x41 text type value-tag 1204 0x000E name-length 1205 status-message status-message name 1206 0x000D value-length 1207 bad-request bad-request value 1208 0x04 start unsupported- unsupported- attributes-tag 1209 attributes 1210 0x21 integer type value-tag 1211 0x000C name-length 1212 job-k-octets job-k-octets name 1213 0x0004 value-length 1214 0x001000000 16777216 value 1215 0x21 integer type value-tag 1216 0x0005 name-length 1217 copies copies name 1218 0x0004 value-length 1219 0x00000014 20 value 1220 0x10 unsupported (type) value-tag 1221 0x0005 name-length 1222 sides sides name 1223 0x0000 value-length 1224 0x03 end-of-attributes end-of-attributes-tag 1226 9.4 Print-URI Request 1228 The following is an example of Print-URI request with copies and job- 1229 name parameters. 1231 Octets Symbolic Value Protocol field 1232 0x0100 1.0 version-number 1233 0x0003 Print-URI operation-id 1234 0x00000001 1 request-id 1235 0x01 start operation- operation-attributes-tag 1236 attributes 1237 0x47 charset type value-tag 1238 0x0012 name-length 1239 attributes-charset attributes- name 1240 charset 1241 0x0008 value-length 1242 US-ASCII US-ASCII value 1243 0x48 natural-language value-tag 1244 type 1245 0x001B name-length 1246 attributes-natural- attributes- name 1247 language natural-language 1248 0x0005 value-length 1249 en-US en-US value 1250 0x45 uri type value-tag 1251 0x000A name-length 1252 document-uri document-uri name 1253 Octets Symbolic Value Protocol field 1254 0x11 value-length 1255 ftp://foo.com/foo ftp://foo.com/foo value 1256 0x42 name type value-tag 1257 0x0008 name-length 1258 job-name job-name name 1259 0x0006 value-length 1260 foobar foobar value 1261 0x02 start job- job-attributes-tag 1262 attributes 1263 0x21 integer type value-tag 1264 0x0005 name-length 1265 copies copies name 1266 0x0004 value-length 1267 0x00000001 1 value 1268 0x03 end-of-attributes end-of-attributes-tag 1269 %!PS... data 1271 9.5 Create-Job Request 1273 The following is an example of Create-Job request with no parameters and 1274 no attributes 1276 Octets Symbolic Value Protocol field 1277 0x0100 1.0 version-number 1278 0x0005 Create-Job operation-id 1279 0x00000001 1 request-id 1280 0x01 start operation-attributes-tag 1281 operation- 1282 attributes 1283 0x47 charset type value-tag 1284 0x0012 name-length 1285 attributes- attributes- name 1286 charset charset 1287 0x0008 value-length 1288 US-ASCII US-ASCII value 1289 0x48 natural- value-tag 1290 language type 1291 0x001B name-length 1292 attributes- attributes- name 1293 natural- natural- 1294 language language 1295 0x0005 value-length 1296 en-US en-US value 1297 0x03 end-of- end-of-attributes-tag 1298 attributes 1300 9.6 Get-Jobs Request 1302 The following is an example of Get-Jobs request with parameters but no 1303 attributes. 1305 Octets Symbolic Value Protocol field 1306 0x0100 1.0 version-number 1307 Octets Symbolic Value Protocol field 1308 0x000A Get-Jobs operation-id 1309 0x00000123 0x123 request-id 1310 0x01 start operation- operation-attributes- 1311 attributes tag 1312 0x47 charset type value-tag 1313 0x0012 name-length 1314 attributes-charset attributes-charset name 1315 0x0008 value-length 1316 US-ASCII US-ASCII value 1317 0x48 natural-language value-tag 1318 type 1319 0x001B name-length 1320 attributes-natural- attributes-natural- name 1321 language language 1322 0x0005 value-length 1323 en-US en-US value 1324 0x21 integer type value-tag 1325 0x0005 name-length 1326 limit limit name 1327 0x0004 value-length 1328 0x00000032 50 value 1329 0x44 keyword type value-tag 1330 0x0014 name-length 1331 requested-attributes requested-attributes name 1332 0x0006 value-length 1333 job-id job-id value 1334 0x44 keyword type value-tag 1335 0x0000 additional value name-length 1336 0x0008 value-length 1337 job-name job-name value 1338 0x44 keyword type value-tag 1339 0x0000 additional value name-length 1340 0x000F value-length 1341 document-format document-format value 1342 0x03 end-of-attributes end-of-attributes-tag 1344 9.7 Get-Jobs Response 1346 The following is an of Get-Jobs response from previous request with 3 1347 jobs. The Printer returns no information about the second job. 1349 Octets Symbolic Value Protocol field 1350 0x0100 1.0 version-number 1351 0x0000 OK (successful) status-code 1352 0x00000123 0x123 request-id (echoed back) 1353 0x01 start operation- operation-attribute-tag 1354 attributes 1355 0x47 charset type value-tag 1356 0x0012 name-length 1357 attributes- attributes-charset name 1358 charset 1359 0x0008 value-length 1360 ISO-8859-1 ISO-8859-1 value 1361 Octets Symbolic Value Protocol field 1362 0x48 natural-language value-tag 1363 type 1364 0x001B name-length 1365 attributes- attributes-natural- name 1366 natural-language language 1367 0x0005 value-length 1368 en-US en-US value 1369 0x41 text type value-tag 1370 0x000E name-length 1371 status-message status-message name 1372 0x0002 value-length 1373 OK OK value 1374 0x02 start job-attributes job-attributes-tag 1375 (1st object) 1376 0x48 natural-language value-tag 1377 type 1378 0x001B name-length 1379 attributes- attributes-natural- name 1380 natural-language language 1381 0x0005 value-length 1382 fr-CA fr-CA value 1383 0x21 integer type value-tag 1384 0x0006 name-length 1385 job-id job-id name 1386 0x0004 value-length 1387 147 147 value 1388 0x42 name type value-tag 1389 0x0008 name-length 1390 job-name job-name name 1391 0x0003 name-length 1392 fou fou name 1393 0x02 start job-attributes job-attributes-tag 1394 (2nd object) 1395 0x02 start job-attributes job-attributes-tag 1396 (3rd object) 1397 0x21 integer type value-tag 1398 0x0006 name-length 1399 job-id job-id name 1400 0x0004 value-length 1401 148 148 value 1402 0x35 nameWithLanguage value-tag 1403 0x0008 name-length 1404 job-name job-name name 1405 0x0012 value-length 1406 0x0005 sub-value-length 1407 de-CH de-CH value 1408 0x0009 sub-value-length 1409 isch guet isch guet name 1410 0x03 end-of-attributes end-of-attributes-tag 1411 10. Appendix B: Hints to implementors using IPP with SSL3 1413 WARNING: Clients and IPP objects using intermediate secure connection 1414 protocol solutions such as IPP in combination with Secure Socket Layer 1415 Version 3 (SSL3), which are developed in advance of IPP and TLS 1416 standardization, might not be interoperable with IPP and TLS standards- 1417 conforming clients and IPP objects. 1419 An assumption is that the URI for a secure IPP Printer object has been 1420 found by means outside the IPP printing protocol, via a directory 1421 service, web site or other means. 1423 IPP provides a transparent connection to SSL by calling the 1424 corresponding URL (a https URI connects by default to port 443). 1425 However, the following functions can be provided to ease the integration 1426 of IPP with SSL during implementation. 1428 connect (URI), returns a status. 1430 "connect" makes an https call and returns the immediate status of 1431 the connection as returned by SSL to the user. The status values are 1432 explained in section 5.4.2 of the SSL document [ssl]. 1434 A session-id may also be retained to later resume a session. The SSL 1435 handshake protocol may also require the cipher specifications 1436 supported by the client, key length of the ciphers, compression 1437 methods, certificates, etc. These should be sent to the server and 1438 hence should be available to the IPP client (although as part of 1439 administration features). 1441 disconnect (session) 1443 to disconnect a particular session. 1445 The session-id available from the "connect" could be used. 1447 resume (session) 1449 to reconnect using a previous session-id. 1451 The availability of this information as administration features are left 1452 for implementors, and need not be standardized at this time 1454 11. Appendix C: Registration of MIME Media Type Information for 1455 "application/ipp" 1457 This appendix contains the information that IANA requires for 1458 registering a MIME media type. The information following this paragraph 1459 will be forwarded to IANA to register application/ipp whose contents are 1460 defined in Section 3 "Encoding of the Operation Layer" in this 1461 document. 1463 MIME type name: application 1464 MIME subtype name: ipp 1466 A Content-Type of "application/ipp" indicates an Internet Printing 1467 Protocol message body (request or response). Currently there is one 1468 version: IPP/1.0, whose syntax is described in Section 3 "Encoding of 1469 the Operation Layer" of [IPP-PRO], and whose semantics are described in 1470 [IPP-MOD] 1472 Required parameters: none 1474 Optional parameters: none 1476 Encoding considerations: 1478 IPP/1.0 protocol requests/responses MAY contain long lines and ALWAYS 1479 contain binary data (for example attribute value lengths). 1481 Security considerations: 1483 IPP/1.0 protocol requests/responses do not introduce any security risks 1484 not already inherent in the underlying transport protocols. Protocol 1485 mixed-version interworking rules in [IPP-MOD] as well as protocol 1486 encoding rules in [IPP-PRO] are complete and unambiguous. 1488 Interoperability considerations: 1490 IPP/1.0 requests (generated by clients) and responses (generated by 1491 servers) MUST comply with all conformance requirements imposed by the 1492 normative specifications [IPP-MOD] and [IPP-PRO]. Protocol encoding 1493 rules specified in [IPP-PRO] are comprehensive, so that interoperability 1494 between conforming implementations is guaranteed (although support for 1495 specific optional features is not ensured). Both the "charset" and 1496 "natural-language" of all IPP/1.0 attribute values of syntax "text" or 1497 "name" are explicit within IPP protocol requests/responses (without 1498 recourse to any external information in HTTP, SMTP, or other message 1499 transport headers). 1501 Published specification: 1503 [IPP-MOD] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1504 "Internet Printing Protocol/1.0: Model and Semantics", work in progress 1505 , January 1998. 1507 [IPP-PRO] R. Herriot , S. Butler, P. Moore, R. Turner, "Internet 1508 Printing Protocol/1.0: Protocol Specification", work in progress , January 1998. 1511 Applications which use this media type: 1513 Internet Printing Protocol (IPP) print clients and print servers, 1514 communicating using HTTP/1.1 (see [IPP-PRO]), SMTP/ESMTP, FTP, or other 1515 transport protocol. Messages of type "application/ipp" are self- 1516 contained and transport-independent, including "charset" and "natural- 1517 language" context for any "text" or "name" attributes. 1519 Person & email address to contact for further information: 1521 Scott A. Isaacson 1522 Novell, Inc. 1523 122 E 1700 S 1524 Provo, UT 84606 1526 Phone: 801-861-7366 1527 Fax: 801-861-4025 1528 Email: sisaacson@novell.com 1530 or 1532 Robert Herriot 1533 Sun Microsystems Inc. 1534 901 San Antonio Road, MPK-17 1535 Palo Alto, CA 94303 1537 Phone: 650-786-8995 1538 Fax: 650-786-7077 1539 Email: robert.herriot@eng.sun.com 1541 Intended usage: 1543 COMMON 1545 12. Appendix D: Full Copyright Statement 1547 Copyright (C)The Internet Society (1998). All Rights Reserved 1549 This document and translations of it may be copied and furnished to 1550 others, and derivative works that comment on or otherwise explain it or 1551 assist in its implementation may be prepared, copied, published and 1552 distributed, in whole or in part, without restriction of any kind, 1553 provided that the above copyright notice and this paragraph are included 1554 on all such copies and derivative works. However, this document itself 1555 may not be modified in any way, such as by removing the copyright notice 1556 or references to the Internet Society or other Internet organizations, 1557 except as needed for the purpose of developing Internet standards in 1558 which case the procedures for copyrights defined in the Internet 1559 Standards process must be followed, or as required to translate it into 1560 languages other than English. 1562 The limited permissions granted above are perpetual and will not be 1563 revoked by the Internet Society or its successors or assigns. 1565 This document and the information contained herein is provided on an "AS 1566 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1567 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1568 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1569 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1570 FITNESS FOR A PARTICULAR PURPOSE.