idnits 2.17.1 draft-ietf-ipp-protocol-03.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 32 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 80 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There is 1 instance of too long lines in the document, the longest one being 24 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 86 has weird spacing: '...ding of the O...' == Line 129 has weird spacing: '...ists of a mes...' == Line 142 has weird spacing: '...ding of the O...' == Line 148 has weird spacing: '...portant types...' == Line 149 has weird spacing: '...ch most other...' == (75 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 (November 7, 1997) is 9664 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) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 4 Robert Herriot (editor) 5 Sun Microsystems 6 Sylvan Butler 7 Hewlett-Packard 8 Paul Moore 9 Microsoft. 10 Randy Turner 11 Sharp Labs 12 November 7, 1997 14 Internet Printing Protocol/1.0: Protocol Specification 15 draft-ietf-ipp-protocol-03.txt 16 Copyright c The Internet Society (date). All Rights Reserved. 18 Status of this Memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, and 22 its working groups. Note that other groups may also distribute working 23 documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference material 28 or to cite them other than as "work in progress". 30 To learn the current status of any Internet-Draft, please check the 31 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 32 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 33 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 34 ftp.isi.edu (US West Coast). 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.........................................5 88 3.2 Syntax of Encoding..............................................6 89 3.3 Version.........................................................8 90 3.4 Mapping of Operations...........................................8 91 3.5 Mapping of Status-code..........................................8 92 3.6 Tags............................................................. 93 3.6.1 Delimiter Tags.............................................8 94 3.6.2 Value Tags.................................................9 95 3.7 Name-Lengths...................................................11 96 3.8 Mapping of Attribute Names....................................11 97 3.9 Value Lengths..................................................12 98 3.10 Mapping of Attribute Values...................................12 99 3.11 Data............................................................ 100 4. Encoding of Transport Layer........................................14 101 4.1 General Headers................................................15 102 4.2 Request Headers...............................................16 103 4.3 Response Headers...............................................16 104 4.4 Entity Headers................................................17 105 5. Security Considerations............................................17 106 6. Copyright..........................................................18 107 7. References.........................................................19 108 8. Author's Address...................................................20 109 9. Other Participants:................................................20 110 10. Appendix A: Protocol Examples.....................................21 111 10.1 Print-Job Request.............................................21 112 10.2 Print-Job Response (successful)...............................22 113 10.3 Print-Job Response (failure)..................................23 114 10.4 Print-URI Request.............................................24 115 10.5 Create-Job Request............................................25 116 10.6 Get-Jobs Request..............................................25 117 10.7 Get-Jobs Response.............................................26 118 11. Appendix B: Mapping of Each Operation in the Encoding.............27 119 12. Appendix C: Hints to implementors using IPP with SSL3.............32 120 1. Introduction 122 This document contains the rules for encoding IPP operations and 123 describes two layers: the transport layer and the operation layer. 125 The transport layer consists of an HTTP/1.1 request or response. RFC 126 2068 [rfc2068] describes HTTP/1.1. This document specifies the HTTP 127 headers that an IPP implementation supports. 129 The operation layer consists of a message body in an HTTP request or 130 response. The document "Internet Printing Protocol/1.0: Model and 131 Semantics" [ipp-mod] defines the semantics of such a message body and 132 the supported values. This document specifies the encoding of an IPP 133 operation. The aforementioned document [ipp-mod] is henceforth referred 134 to as the "IPP model document" 136 2. Conformance Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [rfc2119]. 142 3. Encoding of the Operation Layer 144 The operation layer SHALL contain a single operation request or 145 operation response. 147 The encoding consists of octets as the most primitive type. There are 148 several types built from octets, but three important types are 149 integers, character strings and octet strings, on which most other 150 data types are built. Every character string in this encoding SHALL be a 151 sequence of characters where the characters are associated with some 152 charset and some natural language. . A character string MUST be in 153 "network byte order" with the first character in the value (according to 154 reading order) being the first character in the encoding. A character 155 string whose associated charset is US-ASCII whose associated natural 156 language is US English is henceforth called a US-ASCII-STRING. A 157 character string whose associated charset and natural language are 158 specified in a request or response as described in the model document is 159 henceforth called a LOCALIZED-STRING. . An octet string MUST be in 160 "network byte order" with the first octet in the value (according to 161 reading order) being the first octet in the encoding Every integer in 162 this encoding SHALL be encoded as a signed integer using two's- 163 complement binary encoding with big-endian format (also known as 164 "network order" and "most significant byte first"). The number of octets 165 for an integer SHALL be 1, 2 or 4, depending on usage in the protocol. 166 Such one-octet integers, henceforth called SIGNED-BYTE, are used for the 167 version and tag fields. Such two-byte integers, henceforth called 168 SIGNED-SHORT are used for the operation, status-code and length fields. 169 Four byte integers, henceforth called SIGNED-INTEGER, are used for 170 values fields. 172 The following two sections present the operation layer in two ways 174 . informally through pictures and description 175 . formally through Augmented Backus-Naur Form (ABNF), as specified by 176 draft-ietf-drums-abnf-02.txt [abnf] 178 3.1 Picture of the Encoding 180 The encoding for an operation request or response consists of: 182 ----------------------------------------------- 183 | version | 2 bytes - required 184 ----------------------------------------------- 185 |operation (request) or status-code (response)| 2 bytes - required 186 ----------------------------------------------------------- 187 | xxx-attributes-tag | 1 byte | 188 ----------------------------------------------- |-0 or more 189 | xxx-attribute-sequence | n bytes | 190 ----------------------------------------------------------- 191 | data-tag | 1 byte - required 192 ----------------------------------------------- 193 | data | q bytes - optional 194 ----------------------------------------------- 196 The xxx-attributes-tag and xxx-attribute-sequence represents four 197 different values of "xxx", namely, operation, job, printer and 198 unsupported-job. The xxx-attributes-tag and xxx-attribute-sequence may 199 be omitted if the operation has no attributes or it may be repeated with 200 the same or different values of "xxx" in ways that are specific to each 201 operation. The data is omitted from some operations, but the data-tag is 202 present even when the data is omitted. Note, the xxx-attributes-tags and 203 data-tag are called `delimiter-tags'. 205 Note: the xxx-attribute-sequence, shown above may consist of 0 bytes, 206 according to the rule below. 208 An xxx-attributes-sequence consists of zero or more compound-attributes. 210 ----------------------------------------------- 211 | compound-attribute | s bytes - 0 or more 212 ----------------------------------------------- 214 A compound-attribute consists of an attribute with a single value 215 followed by zero or more additional values. 217 Note: a `compound-attribute' represents a single attribute in the model 218 document. The `additional value' syntax is for attributes with 2 or 219 more values. 221 Each attribute consists of: 223 ----------------------------------------------- 224 | value-tag | 1 byte 225 ----------------------------------------------- 226 | name-length (value is u) | 2 bytes 227 ----------------------------------------------- 228 | name | u bytes 229 ----------------------------------------------- 230 | value-length (value is v) | 2 bytes 231 ----------------------------------------------- 232 | value | v bytes 233 ----------------------------------------------- 235 An additional value consists of: 237 ----------------------------------------------------------- 238 | value-tag | 1 byte | 239 ----------------------------------------------- | 240 | name-length (value is 0x0000) | 2 bytes | 241 ----------------------------------------------- |-0 or more 242 | value-length (value is w) | 2 bytes | 243 ----------------------------------------------- | 244 | value | w bytes | 245 ----------------------------------------------------------- 247 Note: an additional value is like an attribute whose name-length is 0. 249 From the standpoint of a parsing loop, the encoding consists of: 251 ----------------------------------------------- 252 | version | 2 bytes - required 253 ----------------------------------------------- 254 |operation (request) or status-code (response)| 2 bytes - required 255 ----------------------------------------------------------- 256 | tag (delimiter-tag or value-tag) | 1 byte | 257 ----------------------------------------------- |-0 or more 258 | empty or rest of attribute | x bytes | 259 ----------------------------------------------------------- 260 | data-tag | 2 bytes - required 261 ----------------------------------------------- 262 | data | y bytes - optional 263 ----------------------------------------------- 265 The value of the tag determines whether the bytes following the tag are: 267 . attributes 268 . data 269 . the remainder of a single attribute where the tag specifies the 270 type of the value. 272 3.2 Syntax of Encoding 274 The syntax below is ABNF [abnf] except `strings of literals' SHALL be 275 case sensitive. For example `a' means lower case `a' and not upper case 276 `A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields are represented 277 as `%x' values which show their range of values. 279 ipp-message = ipp-request / ipp-response 280 ipp-request = version operation 281 *(xxx-attributes-tag xxx-attribute-sequence) data-tag data 282 ipp-response = version status-code 283 *(xxx-attributes-tag xxx-attribute-sequence) data-tag data 284 xxx-attribute-sequence = *compound-attribute 285 ; where "xxx" in the three rules above stands for any of the 286 following 287 ; values: "operation", "job", "printer" or "unsupported-job". 289 version = major-version minor-version 290 major-version = SIGNED-BYTE ; initially %d1 291 minor-version = SIGNED-BYTE ; initially %d0 293 operation = SIGNED-SHORT ; mapping from model defined below 294 status-code = SIGNED-SHORT ; mapping from model defined below 296 compound-attribute = attribute *additional-values 298 attribute = value-tag name-length name value-length value 299 additional-values = value-tag zero-name-length value-length value 301 name-length = SIGNED-SHORT ; number of octets of `name' 302 name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." ) 303 value-length = SIGNED-SHORT ; number of octets of `value' 304 value = OCTET-STRING 306 data = OCTET-STRING 308 zero-name-length = %x00.00 ; name-length of 0 309 operation-attributes-tag = %x01 ; tag of 1 310 job-attributes-tag = %x02 ; tag of 2 311 printer-attributes-tag = %x04 ; tag of 4 312 unsupported-job-attributes-tag = %x05 ; tag of 5 313 data-tag = %x03 ; 314 tag of 3 315 value-tag = %x10-FF 317 SIGNED-BYTE = BYTE 318 SIGNED-SHORT = 2BYTE 319 DIGIT = %x30-39 ; "0" to "9" 320 LALPHA = %x61-7A ; "a" to "z" 321 BYTE = %x00-FF 322 OCTET-STRING = *BYTE 324 The syntax allows an xxx-attributes-tag to be present when the xxx- 325 attribute-sequence that follows is empty. The syntax is defined this way 326 to allow for the response of Get-Jobs where no attributes are returned 327 for some job-objects. Although it is RECOMMENDED that the sender not 328 send an xxx-attributes-tag if there are no attributes (except in the 329 Get-Jobs response just mentioned), the receiver MUST be able to decode 330 such syntax. 332 3.3 Version 334 The version SHALL consist of a major and minor version, each of which 335 SHALL be represented by a SIGNED-BYTE. The protocol described in this 336 document SHALL have a major version of 1 (0x01) and a minor version of 337 0 (0x00). The ABNF for these two bytes SHALL be %x01.00. 339 3.4 Mapping of Operations 341 Operations are defined as enums in the model document. An operations 342 enum value SHALL be encoded as a SIGNED-SHORT 344 Note: the values 0x4000 to 0xFFFF are reserved for private extensions. 346 3.5 Mapping of Status-code 348 Status-codes are defined as enums in the model document. A status-code 349 enum value SHALL be encoded as a SIGNED-SHORT 351 If an IPP status-code is returned, then the HTTP Status-Code MUST be 200 352 (OK). With any other HTTP Status-Code value, the HTTP response SHALL NOT 353 contain an IPP message-body, and thus no IPP status-code is returned. 355 3.6 Tags 357 There are two kinds of tags: 359 . delimiter tags: delimit major sections of the protocol, namely 360 attributes and data 361 . value tags: specify the type of each attribute value 363 3.6.1 Delimiter Tags 365 The following table specifies the values for the delimiter tags: 367 Tag Value (Hex) Delimiter 369 0x00 reserved 370 0x01 operation-attributes-tag 371 0x02 job-attributes-tag 372 0x03 data-tag 373 0x04 printer-attributes-tag 374 0x05 unsupported-job-attributes-tag 375 0x06-0x0F reserved for future delimiters 377 When an xxx-attributes-tag occurs in the protocol, it SHALL mean that 378 the zero or more following attributes up to the next delimiter tag are 379 xxx attributes as defined in the model document, where xxx is operation, 380 job, printer, unsupported-job. 382 Doing substitution for xxx in the above paragraph, this means the 383 following. When an operation-attributes-tag occurs in the protocol, it 384 SHALL mean that the zero or more following attributes up to the next 385 delimiter tag are operation attributes as defined in the model document. 386 When an job-attributes-tag occurs in the protocol, it SHALL mean that 387 the zero or more following attributes up to the next delimiter tag are 388 job attributes as defined in the model document. When an printer- 389 attributes-tag occurs in the protocol, it SHALL mean that the zero or 390 more following attributes up to the next delimiter tag are printer 391 attributes as defined in the model document. When an unsupported-job- 392 attributes-tag occurs in the protocol, it SHALL mean that the zero or 393 more following attributes up to the next delimiter tag are unsupported- 394 job attributes as defined in the model document. 396 The operation-attributes-tag and data-tag SHALL each occur exactly once 397 in an operation. The operation-attributes-tag SHALL be the first tag 398 delimiter, and the data-tag SHALL be the last tag delimiter. 400 Each of the other three xxx-attributes-tags defined above is OPTIONAL 401 in an operation and each SHALL occur at most once in an operation, 402 except for job-attributes-tag in a Get-Jobs response which may occur 403 zero or more times. 405 The order and presence of delimiter tags for each operation request and 406 each operation response SHALL be that defined in the model document. For 407 further details, see Section 3.8 Mapping of Attribute Names and 408 Appendix B: Mapping of Each Operation in the Encoding. 410 3.6.2 Value Tags 412 The remaining tables show values for the value-tag, which is the first 413 octet of an attribute. The value-tag specifies the type of the value of 414 the attribute. If the value-tag specifies a type of compoundValue, it 415 represents a compound value whose type is the that of the last member of 416 the compound value. The following table specifies the "out-of-band" 417 values for the value-tag. 419 Tag Value (Hex) Meaning 421 0x10 unsupported 422 0x11 reserved for future `default' 423 0x12 unknown 424 0x13 compoundValue 425 0x14-0x1F reserved for future "out-of-band" values. 427 The "unsupported" value SHALL be used in the attribute-sequence of an 428 error response for those attributes which the printer does not support. 430 The "default" value is reserved for future use of setting value back to 431 their default value. The "unknown" value is used for the value of a 432 supported attribute when its value is temporarily unknown. . The 433 "compoundValue" SHALL be used to form a single value from a collection 434 of values, and its value is the number of members forming the compound 435 value, excluding the compoundValue. For example, a text value with a 436 naturalLanguage override consists of 3 "values": a compoundValue with 437 value 2, a naturalLanguage value and a text value. 439 The following table specifies the integer values for the value-tag 441 Tag Value (Hex) Meaning 443 0x20 reserved 444 0x21 integer 445 0x22 boolean 446 0x23 enum 447 0x24-0x2F reserved for future integer types 449 NOTE: 0x20 is reserved for "generic integer" if should ever be needed. 451 The following table specifies the octetString values for the value-tag 453 Tag Value (Hex) Meaning 455 0x30 octetString with an unspecified format 456 0x31 dateTime 457 0x32 resolution 458 0x33 rangeOfInteger 459 0x34 reserved for dictionary (in the future) 460 0x35-0x3F reserved for future octetString types 462 The following table specifies the character-string values for the value- 463 tag 465 Tag Value (Hex) Meaning 467 0x40 reserved 468 0x41 text 469 0x42 name 470 0x43 reserved 471 0x44 keyword 472 0x45 uri 473 0x46 uriScheme 474 0x47 charset 475 0x48 naturalLanguage 476 0x49 mimeMediaType 477 0x4A-0x5F reserved for future character string types 479 NOTE: 0x40 is reserved for "generic character-string" if should ever be 480 needed. 482 The values 0x60-0xFF are reserved for future types. There are no values 483 allocated for private extensions. A new type must be registered via the 484 type 2 process. 486 3.7 Name-Lengths 488 The name-length field SHALL consist of a SIGNED-SHORT. This field SHALL 489 specify the number of octets in the name field which follows the name- 490 length field, excluding the two bytes of the name-length field. 492 If a name-length field has a value of zero, the following name field 493 SHALL be empty, and the following value SHALL be treated as an 494 additional value for the preceding attribute. Within an attribute- 495 sequence, if two attributes have the same name, the first occurrence 496 SHALL be ignored. The zero-length name is the only mechanism for multi- 497 valued attributes. 499 3.8 Mapping of Attribute Names 501 Some attributes are encoded in a special position. These attribute are: 503 . "printer-uri": The target printer-uri of each operation in the IPP 504 model document SHALL be specified outside of the operation layer 505 as the request-URI on the Request-Line at the HTTP level. 506 . "job-uri": The target job-uri of each operation in the IPP model 507 document SHALL be specified outside of the operation layer as the 508 request-URI on the Request-Line at the HTTP level. 509 . "document-content": The attribute named "document-content" in the 510 IPP model document SHALL become the "data" in the operation layer. 511 . "status-code": The attribute named "status-code" in the IPP model 512 document SHALL become the "status-code" field in the operation 513 layer response. 515 The model document arranges the remaining attributes into groups for 516 each operation request and response. Each such group SHALL be 517 represented in the protocol by an xxx-attribute-sequence preceded by the 518 appropriate xxx-attributes-tag (See the table below and Appendix B: 519 Mapping of Each Operation in the Encoding). In addition, the order of 520 these xxx-attributes-tags and xxx-attribute-sequences in the protocol 521 SHALL be the same as in the model document, but the order of attributes 522 within each xxx-attribute-sequence SHALL be unspecified. The table below 523 maps the model document group name to xxx-attributes-sequence 525 Model Document Group xxx-attributes-sequence 527 Operation Attributes operations-attributes-sequence 528 Job Template Attributes job-attributes-sequence 529 Job Object Attributes job-attributes-sequence 530 Unsupported Attributes unsupported-job-attributes-sequence 531 Requested Attributes (Get- job-attributes-sequence 532 Attributes of job object) 533 Requested Attributes (Get- printer-attributes-sequence 534 Attributes of printer object) 535 Document Content in a special position as described above 536 ISSUE: coordinate this with the model document. 538 If an operation contains attributes from more than one job object (e.g. 539 Get-Jobs response), the attributes from each job object SHALL be in a 540 separate job-attribute-sequence, such that the attributes from the ith 541 job object are in the ith job-attribute-sequence. See Section 11 542 "Appendix B: Mapping of Each Operation in the Encoding" for table 543 showing the application of the rules above. 545 3.9 Value Lengths 547 Each attribute value SHALL be preceded by a SIGNED-SHORT which SHALL 548 specify the number of octets in the value which follows this length, 549 exclusive of the two bytes specifying the length. 551 For any of the types represented by binary signed integers, the sender 552 MUST encode the value in exactly four octets.. 554 For any of the types represented by character-strings, the sender MUST 555 encode the value with all the characters of the string and without any 556 padding characters. 558 If a value-tag contains an "out-of-band" value which is not 559 compoundValue, such as "unsupported", the value-length SHALL be 0 and 560 the value empty " the value has no meaning when the value-tag has an 561 "out-of-band" value. If a printer or client receives an operation with a 562 nonzero value-length in this case, it SHALL ignore the value field. 564 3.10 Mapping of Attribute Values 566 The syntax types and most of the details of their representation are 567 defined in the IPP model document. The table below augments the 568 information in the model document, and defines the syntax types from the 569 model document in terms of the 5 basic types defined in section 3 570 Encoding of the Operation Layer. The 5 types are US-ASCII-STRING, 571 LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET- 572 STRING. 574 Syntax of Encoding 575 Attribute Value 577 text, name LOCALIZED-STRING. 578 The override natural language mechanism is 579 encoded by syntactically preceding the text or 580 name value by two values: first a value of type 581 compoundValue whose value is 2 and second a value 582 of type naturalLanguage whose value is the 583 language override. From a protocol syntax view, 585 Syntax of Encoding 586 Attribute Value 588 there are three separate values: the 589 compoundValue, the naturalLanguage value and the 590 text or name value, but from a semantic view, the 591 Printer treats them as a single value where the 592 naturalLanguage value overrides the language of 593 the immediately following text or name value in 594 the attribute. The override applies to just the 595 text or name within the compound value. Other 596 text or name values needing an override must be 597 overridden with additional compoundValues. 598 charset, US-ASCII-STRING 599 naturalLanguage, 600 mimeMediaType, 601 keyword, uri, 602 and uriScheme 603 boolean SIGNED-BYTE where 0x00 is `false' and 0x01 is 604 `true' 605 integer and enum a SIGNED-INTEGER 606 compoundValue a SIGNED-INTEGER with a special meaning. 607 If the value of a compoundValue is n, then the n 608 following values of the attribute form a single 609 value whose type is that of the last member of 610 the compound value. For example, if an attribute 611 has 3 successive values: compoundValue of 2, 612 naturalLanguage of `fr-CA' and name of `chien', 613 then these three "values" form a single value 614 which is a name of `chien' in Canadian French.. 615 dateTime OCTET-STRING consisting of eleven octets whose 616 contents are defined by "DateAndTime" in RFC 1903 617 [rfc1903]. Although RFC 1903 also defines an 618 eight octet format which omits the time zone, a 619 value of this type in the IPP protocol MUST use 620 the eleven octet format. [ transfer to model]. 621 resolution OCTET"STRING consisting of nine octets of 2 622 SIGNED-INTEGERs followed by a SIGNED-BYTE. The 623 first SIGNED-INTEGER contains the value of cross 624 feed direction resolution . The second SIGNED- 625 INTEGER contains the value of feed direction 626 resolution. The SIGNED-BYTE contains the unts 627 value. 628 rangeOfInteger Eight octets consisting of 2 SIGNED-INTEGERs. The 629 first SIGNED-INTEGERs contains the lower bound 630 and the second SIGNED-INTEGERs contains the upper 631 bound 632 1setOf X encoding according to the rules for an attribute 633 with more than 1 value. Each value X is encoded 634 according to the rules for encoding its type. 635 octetString OCTET-STRING 637 The type of the value in the model document determines the encoding in 638 the value and the value of the value-tag. 640 3.11 Data 642 The data part SHALL include any data required by the operation 644 4. Encoding of Transport Layer 646 HTTP/1.1 shall be the transport layer for this protocol. 648 The operation layer has been designed with the assumption that the 649 transport layer contains the following information: 651 . the URI of the target job or printer operation 652 . the total length of the data in the operation layer, either as a 653 single length or as a sequence of chunks each with a length. 654 It is REQUIRED that a printer support HTTP over port 80, though a 655 printer may support HTTP over port 516 or some other port. In addition, 656 a printer may have to support another port for secure connections. 658 Note: Consistent with RFC 2068 (HTTP/1.1), HTTP URI's for IPP implicitly 659 reference port 80. If a URI references some other port, the port number 660 must be explicitly specified in the URI. 662 Each HTTP operation shall use the POST method where the request-URI is 663 the object target of the operation, and where the "Content-Type" of the 664 message-body in each request and response shall be "application/ipp". 665 The message-body shall contain the operation layer and shall have the 666 syntax described in section 3.2 "Syntax of Encoding". A client 667 implementation SHALL adhere to the rules for a client described in RFC 668 2068 [rfc2068]. A printer (server) implementation SHALL adhere the rules 669 for an origin server described in RFC 2068.In the following sections, 670 there are a tables of all HTTP headers which describe their use in an 671 IPP client or server. The following is an explanation of each column in 672 these tables. 674 . the "header" column contains the name of a header 675 . the "request/client" column indicates whether a client sends the 676 header. 677 . the "request/ server" column indicates whether a server supports 678 the header when received. 679 . the "response/ server" column indicates whether a server sends the 680 header. 681 . the "response /client" column indicates whether a client supports 682 the header when received. 683 . the "values and conditions" column specifies the allowed header 684 values and the conditions for the header to be present in a 685 request/response. 687 The table for "request headers" does not have columns for responses, and 688 the table for "response headers" does not have columns for requests. 690 The following is an explanation of the values in the "request/client" 691 and "response/ server" columns. 693 . must: the client or server MUST send the header, 694 . must-if: the client or server MUST send the header when the 695 condition described in the "values and conditions" column is met, 696 . may: the client or server MAY send the header 697 . not: the client or server SHOULD NOT send the header. It is not 698 relevant to an IPP implementation. 700 The following is an explanation of the values in the "response/client" 701 and "request/ server" columns. 703 . must: the client or server MUST support the header, 704 . may: the client or server MAY support the header 705 . not: the client or server SHOULD NOT support the header. It is not 706 relevant to an IPP implementation. 708 4.1 General Headers 710 The following is a table for the general headers. 712 ISSUE: an HTTP expert should review these tables for accuracy. 714 General- Request Response Values and Conditions 715 Header 717 Client Server Server Client 719 Cache- must not must not "no-cache" only 720 Control 721 Connection must-if must must- must "close" only. Both 722 if client and server 723 SHOULD keep a 724 connection for the 725 duration of a sequence 726 of operations. The 727 client and server MUST 728 include this header 729 for the last operation 730 in such a sequence. 731 Date may may must may per RFC 1123 [rfc1123] 732 Pragma` must not must not "no-cache" only 733 Transfer- must-if must must- must "chunked" only . 734 Encoding if Header MUST be present 735 if Content-Length is 736 absent. 737 Upgrade not not not not 738 Via not not not not 739 4.2 Request Headers 741 The following is a table for the request headers. 743 Request-Header Client Server Request Values and Conditions 745 Accept may must "application/ipp" only. This 746 value is the default if the 747 client omits it 748 Accept-Charset not not Charset information is within 749 the application/ipp entity 750 Accept-Encoding may must empty and per RFC 2068 [rfc2068] 751 and IANA registry for content- 752 codings 753 Accept-Language not not . language information is within 754 the application/ipp entity 755 Authorization must-if must per RFC 2068. A client MUST send 756 this header when it receives a 757 401 "Unauthorized" response and 758 does not receive a "Proxy- 759 Authenticate" header. 760 From not not per RFC 2068. Because RFC 761 recommends sending this header 762 only with the user's approval, it 763 is not very useful 764 Host must must per RFC 2068 765 If-Match not not 766 If-Modified- not not 767 Since 768 If-None-Match not not 769 If-Range not not 770 If-Unmodified- not not 771 Since 772 Max-Forwards not not 773 Proxy- must-if not per RFC 2068. A client MUST send 774 Authorization this header when it receives a 775 401 "Unauthorized" response and a 776 "Proxy-Authenticate" header. 777 Range not not 778 Referer not not 779 User-Agent not not 781 4.3 Response Headers 783 The following is a table for the request headers. 785 Response- Server Client Response Values and Conditions 786 Header 788 Accept-Ranges not not 789 Age not not 790 Location must-if may per RFC 2068. When URI needs 791 Response- Server Client Response Values and Conditions 792 Header 794 redirection. 795 Proxy- not must per RFC 2068 796 Authenticate 797 Public may may per RFC 2068 798 Retry-After may may per RFC 2068 799 Server not not 800 Vary not not 801 Warning may may per RFC 2068 802 WWW- must-if must per RFC 2068. When a server needs to 803 Authenticate authenticate a client. 805 4.4 Entity Headers 807 The following is a table for the entity headers. 809 Entity-Header Request Response Values and Conditions 811 Client Server Server Client 813 Allow not not not not 814 Content-Base not not not not 815 Content- may must must must per RFC 2068 and IANA 816 Encoding registry for content 817 codings. 818 Content- not not not not Application/ipp 819 Language handles language 820 Content- must-if must must-if must the length of the 821 Length message-body per RFC 822 2068. Header MUST be 823 present if Transfer- 824 Encoding is absent.. 825 Content- not not not not 826 Location 827 Content-MD5 may may may may per RFC 2068 828 Content-Range not not not not 829 Content-Type must must must must "application/ipp" 830 only 831 ETag not not not not 832 Expires not not not not 833 Last-Modified not not not not 835 5. Security Considerations 837 When utilizing HTTP 1.1 as a transport of IPP, the security 838 considerations outlined in RFC 2068 [rfc2068] apply. Specifically, IPP 839 servers can generate a 401 "Unauthorized" response code to request 840 client authentication and IPP clients should correctly respond with the 841 proper "Authorization" header. Both Basic Authentication (RFC 2068) and 842 Digest Authentication (RFC 2069) [rfc2069] flavors of authentication 843 SHALL be supported. The server chooses which type(s) of authentication 844 to accept. Digest Authentication is a more secure method, and is always 845 preferred to Basic Authentication. 847 For secure communication (privacy in particular), IPP SHOULD be run 848 using a secure communications channel. For this purpose it is the 849 intention to define standardization of IPP in combination with Transport 850 Layer Security (TLS), currently under development in the IETF, when the 851 TLS specifications are agreed and on the IETF standards track. 853 As an intercept solution for secure communication, the Secure Socket 854 Layer 3.0 (SSL3) could be used, but be warned that such implementations 855 may not be able to interoperate with a future standardized IPP and TLS 856 solution. Appendix C gives some hints to implementors wanting to use 857 SSL3 as intercept solution. 859 It is possible to combine the techniques, HTTP 1.1 client authentication 860 (either basic or digest) with a secure communications channel. Together 861 the two are more secure than client authentication and they perform user 862 authentication. 864 See further discussion of IPP security concepts in the model document 865 [ipp-mod]. 867 6. Copyright 869 This document and translations of it may be copied and furnished to 870 others, and derivative works that comment on or otherwise explain it or 871 assist in its implementation may be prepared, copied, published and 872 distributed, in whole or in part, without restriction of any kind, 873 provided that the above copyright notice and this paragraph are included 874 on all such copies and derivative works. However, this document itself 875 may not be modified in any way, such as by removing the copyright notice 876 or references to the Internet Society or other Internet organizations, 877 except as needed for the purpose of developing Internet standards in 878 which case the procedures for copyrights defined in the Internet 879 Standards process must be followed, or as required to translate it into 880 languages other than English. 882 The limited permissions granted above are perpetual and will not be 883 revoked by the Internet Society or its successors or assigns. 885 This document and the information contained herein is provided on an "AS 886 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 887 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 888 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 889 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 890 FITNESS FOR A PARTICULAR PURPOSE. 892 7. References 894 [rfc822] Crocker, D., "Standard for the Format of ARPA 895 Internet Text Messages", RFC 822, August 1982. 897 [rfc1123] Braden, S., "Requirements for Internet Hosts - 898 Application and Support", RFC 1123, October, 1989, 900 [rfc1179] McLaughlin, L. III, (editor), "Line Printer Daemon 901 Protocol" RFC 1179, August 1990. 903 [rfc1630] T. Berners-Lee, "Universal Resource Identifiers in WWW: 904 A Unifying Syntax for the Expression of Names and Addresses of 905 Objects on the Network as used in the Word-Wide Web", RFC 1630, 906 June 1994. 908 [rfc1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and 909 Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. 911 [rfc1738] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform 912 Resource Locators (URL)", RFC 1738, December, 1994. 914 [rfc1543] Postel, J., "Instructions to RFC Authors", RFC 1543, 915 October 1993. 917 [rfc1766] H. Alvestrand, " Tags for the Identification of 918 Languages", RFC 1766, March 1995. 920 [rfc1903} J. Case, et al. "Textual Conventions for Version 2 of 921 the Simple Network Management Protocol (SNMPv2)", RFC 1903, 922 January 1996. 924 [rfc2046] N. Freed & N. Borenstein, Multipurpose Internet Mail 925 Extensions (MIME) Part Two: Media Types. November 1996. 926 (Obsoletes RFC1521, RFC1522, RFC1590), RFC 2046. 928 [rfc2048] N. Freed, J. Klensin & J. Postel. Multipurpose Internet 929 Mail Extension (MIME) Part Four: Registration Procedures. 930 November 1996. (Format: TXT=45033 bytes) (Obsoletes RFC1521, 931 RFC1522, RFC1590) (Also BCP0013), RFC 2048. 933 [rfc2068] R Fielding, et al, "Hypertext Transfer Protocol " 934 HTTP/1.1" RFC 2068, January 1997 936 [rfc2069] J. Franks, et al, "An Extension to HTTP: Digest Access 937 Authentication" RFC 2069, January 1997 939 [rfc2119] S. Bradner, "Key words for use in RFCs to Indicate 940 Requirement Levels", RFC 2119 , March 1997 942 [rfc2184] N. Freed, K. Moore, "MIME Parameter Value and Encoded 943 Word Extensions: Character Sets, Languages, and Continuations", 944 RFC 2184, August 1997, 946 [abnf] D. Crocker et al., "Augmented BNF for Syntax Specifications: 947 ABNF", draft-ietf-drums-abnf-04.txt. 949 [char] N. Freed, J. Postel: IANA Charset Registration Procedures, Work 950 in Progress (draft-freed-charset-reg-02.txt). 952 [dpa] ISO/IEC 10175 Document Printing Application (DPA), June 1996. 954 [iana] IANA Registry of Coded Character Sets: ftp://ftp.isi.edu/in- 955 notes/iana/assignments/character-sets 957 [ipp-req] Wright, F. D., "Requirements for an Internet Printing 958 Protocol:" 960 [ipp-mod] Isaacson, S, deBry, R, Hastings, T, Herriot, R, Powell, 961 P, "Internet Printing Protocol/1.0: Model and Semantics" 963 [ssl] Netscape, The SSL Protocol, Version 3, (Text version 3.02) 964 November 1996. 966 8. Author's Address 968 Robert Herriot (editor) Paul Moore 969 Sun Microsystems Inc. Microsoft 970 901 San Antonio Road, MPK-17 One Microsoft Way 971 Palo Alto, CA 94303 Redmond, WA 98053 973 Phone: 650-786-8995 Phone: 425-936-0908 974 Fax: 650-786-7077 Fax: 425-93MS-FAX 975 Email: robert.herriot@eng.sun.com Email: paulmo@microsoft.com 977 Sylvan Butler Randy Turner 978 Hewlett-Packard Sharp Laboratories 979 11311 Chinden Blvd. 5750 NW Pacific Rim Blvd 980 Boise, ID 83714 Camas, WA 98607 982 Phone: 208-396-6000 Phone: 360-817-8456 983 Fax: 208-396-3457 Fax: : 360-817-8436 984 Email: sbutler@boi.hp.com Email: rturner@sharplabs.com 986 IPP Mailing List: ipp@pwg.org 987 IPP Mailing List Subscription: ipp-request@pwg.org 988 IPP Web Page: http://www.pwg.org/ipp/ 990 9. Other Participants: 992 Chuck Adams - Tektronix Harry Lewis - IBM 993 Ron Bergman - Data Products Tony Liao - Vivid Image 994 Keith Carter - IBM David Manchala - Xerox 995 Angelo Caruso - Xerox Carl-Uno Manros - Xerox 996 Jeff Copeland - QMS Jay Martin - Underscore 997 Roger Debry - IBM Larry Masinter - Xerox 998 Lee Farrell - Canon Ira McDonald, Xerox 999 Sue Gleeson - Digital Bob Pentecost - Hewlett-Packard 1000 Charles Gordon - Osicom Patrick Powell - SDSU 1001 Brian Grimshaw - Apple Jeff Rackowitz - Intermec 1002 Jerry Hadsell - IBM Xavier Riley - Xerox 1003 Richard Hart - Digital Gary Roberts - Ricoh 1004 Tom Hastings - Xerox Stuart Rowley - Kyocera 1005 Stephen Holmstead Richard Schneider - Epson 1006 Zhi-Hong Huang - Zenographics Shigern Ueda - Canon 1007 Scott Isaacson - Novell Bob Von Andel - Allegro Software 1008 Rich Lomicka - Digital William Wagner - Digital Products 1009 David Kellerman - Northlake Jasper Wong - Xionics 1010 Software 1011 Robert Kline - TrueSpectra Don Wright - Lexmark 1012 Dave Kuntz - Hewlett-Packard Rick Yardumian - Xerox 1013 Takami Kurono - Brother Lloyd Young - Lexmark 1014 Rich Landau - Digital Peter Zehler - Xerox 1015 Greg LeClair - Epson Frank Zhao - Panasonic 1016 Steve Zilles - Adobe 1018 10. Appendix A: Protocol Examples 1020 10.1 Print-Job Request 1022 The following is an example of a Print-Job request with job-name, 1023 copies, and sides specified. 1025 Octets Symbolic Value Protocol field 1027 0x0100 1.0 version 1028 0x0002 PrintJob operation 1029 0x01 start operation- operation-attributestag 1030 attributes 1031 0x47 charset type value-tag 1032 0x0012 name-length 1033 attributes-charset attributes-charset name 1034 0x0008 value-length 1035 US-ASCII US-ASCII value 1036 0x48 natural-language value-tag 1037 type 1038 0x001B name-length 1039 attributes-natural- attributes-natural- name 1040 language language 1041 0x0005 value-length 1042 en-US en-US value 1043 0x42 name type value-tag 1044 0x0008 name-length 1045 job-name job-name name 1046 0x0006 value-length 1047 foobar foobar value 1048 Octets Symbolic Value Protocol field 1050 0x02 start job- job-attributes-tag 1051 attributes 1052 0x21 integer type value-tag 1053 0x0005 name-length 1054 copies copies name 1055 0x0004 value-length 1056 0x00000014 20 value 1057 0x44 keyword type value-tag 1058 0x0005 name-length 1059 sides sides name 1060 0x0013 value-length 1061 two-sided-long-edge two-sided-long-edge value 1062 0x03 start-data data-tag 1063 %!PS... data 1065 10.2 Print-Job Response (successful) 1067 Here is an example of a Print-Job response which is successful: 1069 Octets Symbolic Value Protocol field 1071 0x0100 1.0 version 1072 0x0000 OK (successful) status-code 1073 0x01 start operation- operation-attributes-tag 1074 attributes 1075 0x47 charset type value-tag 1076 0x0012 name-length 1077 attributes- attributes- name 1078 charset charset 1079 0x0008 value-length 1080 US-ASCII US-ASCII value 1081 0x48 natural-language value-tag 1082 type 1083 0x001B name-length 1084 attributes- attributes- name 1085 natural- natural-language 1086 language 1087 0x0005 value-length 1088 en-US en-US value 1089 0x41 text type value-tag 1090 0x000E name-length 1091 status-message status-message name 1092 0x0002 value-length 1093 OK OK value 1094 0x02 start job- job-attributes-tag 1095 attributes 1096 0x21 integer value-tag 1097 0x0007 name-length 1098 job-id job-id name 1099 0x0004 value-length 1100 Octets Symbolic Value Protocol field 1102 147 147 value 1103 0x45 uri type value-tag 1104 0x0008 name-length 1105 job-uri job-uri name 1106 0x000E value-length 1107 http://foo/123 http://foo/123 value 1108 0x25 name type value-tag 1109 0x0008 name-length 1110 job-state job-state name 1111 0x0001 value-length 1112 0x03 pending value 1113 0x03 start-data data-tag 1115 10.3 Print-Job Response (failure) 1117 Here is an example of a Print-Job response which fails because the 1118 printer does not support sides and because the value 20 for copies is 1119 not supported: 1121 Octets Symbolic Value Protocol field 1123 0x0100 1.0 version 1124 0x0400 client-error-bad-request status-code 1125 0x01 start operation- operation-attribute tag 1126 attributes 1127 0x47 charset type value-tag 1128 0x0012 name-length 1129 attributes- attributes-charset name 1130 charset 1131 0x0008 value-length 1132 US-ASCII US-ASCII value 1133 0x48 natural-language type value-tag 1134 0x001B name-length 1135 attributes- attributes-natural- name 1136 natural- language 1137 language 1138 0x0005 value-length 1139 en-US en-US value 1140 0x41 text type value-tag 1141 0x000E name-length 1142 status-message status-message name 1143 0x000D value-length 1144 bad-request bad-request value 1145 0x04 start unsupported-job- unsupported-job- 1146 attributes attributes-tag 1147 0x21 integer type value-tag 1148 0x0005 name-length 1149 copies copies name 1150 0x0004 value-length 1151 0x00000014 20 value 1152 Octets Symbolic Value Protocol field 1154 0x10 unsupported (type) value-tag 1155 0x0005 name-length 1156 sides sides name 1157 0x0000 value-length 1158 0x03 start-data data-tag 1160 10.4 Print-URI Request 1162 The following is an example of Print-URI request with copies and job- 1163 name parameters. 1165 Octets Symbolic Value Protocol field 1166 0x0100 1.0 version 1167 0x0003 Print-URI operation 1168 0x01 start operation- operation-attributes-tag 1169 attributes 1170 0x47 charset type value-tag 1171 0x0012 name-length 1172 attributes-charset attributes-charset name 1173 0x0008 value-length 1174 US-ASCII US-ASCII value 1175 0x48 natural-language value-tag 1176 type 1177 0x001B name-length 1178 attributes-natural- attributes- name 1179 language natural-language 1180 0x0005 value-length 1181 en-US en-US value 1182 0x45 uri type value-tag 1183 0x000A name-length 1184 document-uri document-uri name 1185 0x11 value-length 1186 ftp://foo.com/foo ftp://foo.com/foo value 1187 0x42 name type value-tag 1188 0x0008 name-length 1189 job-name job-name name 1190 0x0006 value-length 1191 foobar foobar value 1192 0x02 start job- job-attributes-tag 1193 attributes 1194 0x21 integer type value-tag 1195 0x0005 name-length 1196 copies copies name 1197 0x0004 value-length 1198 0x00000001 1 value 1199 0x03 start-data data-tag 1200 %!PS... data 1201 10.5 Create-Job Request 1203 The following is an example of Create-Job request with no parameters and 1204 no attributes 1206 Octets Symbolic Value Protocol field 1207 0x0100 1.0 version 1208 0x0005 Create-Job operation 1209 0x01 start operation-attributes-tag 1210 operation- 1211 attributes 1212 0x47 charset type value-tag 1213 0x0012 name-length 1214 attributes- attributes- name 1215 charset charset 1216 0x0008 value-length 1217 US-ASCII US-ASCII value 1218 0x48 natural- value-tag 1219 language type 1220 0x001B name-length 1221 attributes- attributes- name 1222 natural- natural- 1223 language language 1224 0x0005 value-length 1225 en-US en-US value 1226 0x03 start-data data-tag 1228 10.6 Get-Jobs Request 1230 The following is an example of Get-Jobs request with parameters but no 1231 attributes. 1233 Octets Symbolic Value Protocol field 1234 0x0100 1.0 version 1235 0x000A Get-Jobs operation 1236 0x01 start operation- operation-attributes- 1237 attributes tag 1238 0x47 charset type value-tag 1239 0x0012 name-length 1240 attributes-charset attributes-charset name 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-natural- name 1247 language language 1248 0x0005 value-length 1249 en-US en-US value 1250 0x21 integer type value-tag 1251 0x0005 name-length 1252 limit limit name 1253 0x0004 value-length 1254 0x00000032 50 value 1255 Octets Symbolic Value Protocol field 1256 0x44 keyword type value-tag 1257 0x0014 name-length 1258 requested-attributes requested-attributes name 1259 0x0006 value-length 1260 job-id job-id value 1261 0x44 keyword type value-tag 1262 0x0000 additional value name-length 1263 0x0008 value-length 1264 job-name job-name value 1265 0x03 start-data data-tag 1267 10.7 Get-Jobs Response 1269 The following is an of Get-Jobs response from previous request with 3 1270 jobs. The Printer returns no information about the second job. 1272 Octets Symbolic Value Protocol field 1273 0x0100 1.0 version 1274 0x0000 OK (successful) status-code 1275 0x01 start operation- operation-attribute-tag 1276 attributes 1277 0x47 charset type value-tag 1278 0x0012 name-length 1279 attributes- attributes-charset name 1280 charset 1281 0x0008 value-length 1282 ISO-8859-1 ISO-8859-1 value 1283 0x48 natural-language value-tag 1284 type 1285 0x001B name-length 1286 attributes- attributes-natural- name 1287 natural-language language 1288 0x0005 value-length 1289 en-US en-US value 1290 0x41 text type value-tag 1291 0x000E name-length 1292 status-message status-message name 1293 0x0002 value-length 1294 OK OK value 1295 0x02 start job-attributes job-attributes-tag 1296 (1st object) 1297 0x48 natural-language value-tag 1298 type 1299 0x001B name-length 1300 attributes- attributes-natural- name 1301 natural-language language 1302 0x0005 value-length 1303 fr-CA fr-CA value 1304 0x21 integer type value-tag 1305 0x0006 name-length 1306 job-id job-id name 1307 0x0004 value-length 1308 147 147 value 1309 Octets Symbolic Value Protocol field 1310 0x42 name type value-tag 1311 0x0008 name-length 1312 job-name job-name name 1313 0x0003 name-length 1314 fou fou name 1315 0x02 start job-attributes job-attributes-tag 1316 (2nd object) 1317 0x02 start job-attributes job-attributes-tag 1318 (3rd object) 1319 0x21 integer type value-tag 1320 0x0006 name-length 1321 job-id job-id name 1322 0x0004 value-length 1323 148 148 value 1324 0x13 compoundValue value-tag 1325 0x0008 name-length 1326 job-name job-name name 1327 0x0004 value-length 1328 0x0002 2 value (number of values) 1329 0x48 naturalLanguage value-tag 1330 0x0000 multi-value marker name-length 1331 0x0005 value-length 1332 de-CH de-CH value 1333 0x42 name type value-tag 1334 0x0000 multi-value marker name-length 1335 0x0003 name-length 1336 isch guet isch guet name 1337 0x03 start-data data-tag 1339 11. Appendix B: Mapping of Each Operation in the Encoding 1341 The next three tables show the results of applying the rules above to 1342 the operations defined in the IPP model document. There is no 1343 information in these tables that cannot be derived from the rules 1344 presented in Section 3.8 "Mapping of Attribute Names". 1346 The following table shows the mapping of all IPP model-document request 1347 attributes to an appropriate xxx-attribute-sequence or special position 1348 in the protocol. 1350 The table below shows the attributes for operations sent to a Printer 1351 URI. 1353 Operation operation job attributes special position 1354 attributes 1356 Print-Job attributes- job-template document-content 1357 charset attributes 1358 attributes- 1359 natural- 1360 language 1361 job-name 1363 Operation operation job attributes special position 1364 attributes 1366 document-name 1367 ipp-attribute- 1368 fidelity 1370 document- 1371 natural- 1372 language 1373 Create-Job or attributes- job-template 1374 Validate-Job charset attributes 1375 attributes- 1376 natural- 1377 language job- 1378 name 1379 ipp-attribute- 1380 fidelity 1381 Print-URI attributes- job-template 1382 charset attributes 1383 attributes- 1384 natural- 1385 language job- 1386 name 1387 ipp-attribute- 1388 fidelity 1389 document-uri 1391 document- 1392 natural- 1393 language 1394 Send-Document attributes- document-content 1395 charset 1396 attributes- 1397 natural- 1398 language job-id 1399 last-document 1400 document-name 1402 document- 1403 natural- 1404 language 1405 Send-URI attributes- 1406 charset 1407 attributes- 1408 natural- 1409 language job-id 1410 last-document 1411 document-name 1412 document-uri 1414 document- 1415 natural- 1417 Operation operation job attributes special position 1418 attributes 1420 language 1421 Cancel-Job attributes- 1422 charset 1423 attributes- 1424 natural- 1425 language job-id 1426 message 1427 Get-Attributes attributes- 1428 (for a Printer) charset 1429 attributes- 1430 natural- 1431 language 1432 requested- 1433 attributes 1434 document-format 1435 Get-Attributes attributes- 1436 (for a Job) charset 1437 attributes- 1438 natural- 1439 language job-id 1440 requested- 1441 attributes 1442 Get-Jobs attributes- 1443 charset 1444 attributes- 1445 natural- 1446 language limit 1447 requested- 1448 attributes 1449 which-jobs 1451 The table below shows the attributes for operations sent to a Job URI. 1453 Operation operation job attributes special position 1454 attributes 1456 Send-Document attributes- document-content 1457 charset 1458 attributes- 1459 natural- 1460 language last- 1461 document 1462 document-name 1464 document- 1465 natural- 1466 language 1467 Send-URI attributes- 1468 charset 1470 Operation operation job attributes special position 1471 attributes 1473 attributes- 1474 natural- 1475 language last- 1476 document 1477 document-name 1478 document-uri 1480 document- 1481 natural- 1482 language 1483 Cancel-Job attributes- 1484 charset 1485 attributes- 1486 natural- 1487 language 1488 message 1489 Get-Attributes attributes- 1490 (for a Job) charset 1491 attributes- 1492 natural- 1493 language 1494 requested- 1495 attributes 1497 The following two tables shows the mapping of all IPP model-document 1498 response attributes to an appropriate xxx-attribute-sequence or special 1499 position in the protocol. 1501 Operation operation job- unsupported-job- special 1502 attributes attributes attributes position 1504 Print-Job, attributes- job-id unsupported status- 1505 Print-URI, charset job-uri attributes code 1506 Create-Job, attributes- job-state 1507 Send-Document natural- job-state- 1508 or Send-URI language reasons 1509 status- job-state- 1510 message message 1511 number-of- 1512 intervening 1513 -jobs 1515 Validate-Job attributes- unsupported status- 1516 charset attributes code 1517 attributes- 1518 natural- 1519 language 1520 status- 1522 Operation operation job- unsupported-job- special 1523 attributes attributes attributes position 1525 message 1527 Note: the unsupported-job-attributes are present only if the client 1528 included some job attributes that the Printer doesn't support. 1530 Note: the job-attributes are present only if the server returns the 1531 status code of successful-ok or successful-ok-ignored-or-substituted- 1532 attributes. 1534 Operation operation job- printer- special 1535 attributes attributes attributes position 1537 Cancel-Job attributes- 1538 charset 1539 attributes- 1540 natural- 1541 language 1542 status- status-code 1543 message 1545 Get-Attributes attributes- requested status-code 1546 (of a job) charset attributes 1547 attributes- 1548 natural- 1549 language 1550 status- 1551 message 1553 Get-Attributes attributes- requested status-code 1554 (of a printer) charset attributes 1555 attributes- 1556 natural- 1557 language 1558 status- 1559 message 1561 Get-Jobs attributes- requested status-code 1562 charset attributes 1563 attributes- (see the 1564 natural- Note below) 1565 language 1566 status- 1567 message 1569 Note for Get-Jobs: there is a separate job-attribute-sequence containing 1570 requested-attributes for each job object in the response 1571 12. Appendix C: Hints to implementors using IPP with SSL3 1573 WARNING: Clients and IPP objects using intermediate secure connection 1574 protocol solutions such as IPP in combination with Secure Socket Layer 1575 Version 3 (SSL3), which are developed in advance of IPP and TLS 1576 standardization, might not be interoperable with IPP and TLS standards- 1577 conforming clients and IPP objects. 1579 An assumption is that the URI for a secure IPP Printer object has been 1580 found by means outside the IPP printing protocol, via a directory 1581 service, web site or other means. 1583 IPP provides a transparent connection to SSL by calling the 1584 corresponding URL (a https URI connects by default to port 443). 1585 However, the following functions can be provided to ease the integration 1586 of IPP with SSL during implementation. 1588 connect (URI), returns a status. 1590 "connect" makes an https call and returns the immediate status of 1591 the connection as returned by SSL to the user. The status values are 1592 explained in section 5.4.2 of the SSL document [ssl]. 1594 A session-id may also be retained to later resume a session. The SSL 1595 handshake protocol may also require the cipher specifications 1596 supported by the client, key length of the ciphers, compression 1597 methods, certificates, etc. These should be sent to the server and 1598 hence should be available to the IPP client (although as part of 1599 administration features). 1601 disconnect (session) 1603 to disconnect a particular session. 1605 The session-id available from the "connect" could be used. 1607 resume (session) 1609 to reconnect using a previous session-id. 1611 The availability of this information as administration features are left 1612 for implementors, and need not be standardized at this time