idnits 2.17.1 draft-ietf-ipp-protocol-v11-01.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 Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 34 longer pages, the longest (page 23) being 72 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 35 pages 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 54 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 157: '... operation layer MUST contain a single...' RFC 2119 keyword, line 166: '...cter string in this encoding MUST be a...' RFC 2119 keyword, line 168: '...anguage. A character string MUST be in...' RFC 2119 keyword, line 175: '...TRING. An octet string MUST be in "IPP...' RFC 2119 keyword, line 178: '...in this encoding MUST be encoded as a ...' (95 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 95 has weird spacing: '...ding of the O...' == Line 142 has weird spacing: '...ists of a mes...' == Line 155 has weird spacing: '...ding of the O...' == Line 164 has weird spacing: '...portant types...' == Line 165 has weird spacing: '...ch most other...' == (49 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 (May 10, 1999) is 9118 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? 'RFC2026' on line 22 looks like a reference -- Missing reference section? 'RFC2068' on line 871 looks like a reference -- Missing reference section? 'RFC2069' on line 871 looks like a reference -- Missing reference section? 'IPP-PRO' on line 1710 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Robert Herriot (editor) 2 Xerox Corporation 3 Sylvan Butler 4 Hewlett-Packard 5 Paul Moore 6 Microsoft 7 Randy Turner 8 2wire.com 9 John Wenn 10 Xerox Corporation 11 May 10, 1999 13 Internet Printing Protocol/1.1: Encoding and Transport 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with all 18 provisions of Section 10 of [RFC2026]. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, and 20 its working groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference material 26 or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed as 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C)The Internet Society (1998, 1999). All Rights Reserved. 38 Abstract 40 This document is one of a set of documents, which together describe all 41 aspects of a new Internet Printing Protocol (IPP). IPP is an application 42 level protocol that can be used for distributed printing using Internet 43 tools and technologies. This document defines the rules for encoding IPP 44 operations and IPP attributes into a new Internet mime media type called 45 "application/ipp". This document also defines the rules for 46 transporting over HTTP a message body whose Content-Type is 47 "application/ipp". This document defines a new scheme named 'ipp' for 48 identifying IPP printers and jobs. Finally, this document defines rules 49 for supporting IPP/1.0 Clients and Printers. 51 The full set of IPP documents includes: 53 Design Goals for an Internet Printing Protocol [rfc2567] 54 Rationale for the Structure and Model and Protocol for the Internet 55 Printing Protocol [rfc2568] 56 Internet Printing Protocol/1.1: Model and Semantics [ipp-mod] 57 Internet Printing Protocol/1.1: Encoding and Transport (this 58 document) 59 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 60 Mapping between LPD and IPP Protocols [rfc2069] 62 The document, "Design Goals for an Internet Printing Protocol", takes a 63 broad look at distributed printing functionality, and it enumerates 64 real-life scenarios that help to clarify the features that need to be 65 included in a printing protocol for the Internet. It identifies 66 requirements for three types of users: end users, operators, and 67 administrators. It calls out a subset of end user requirements that are 68 satisfied in IPP/1.1. Operator and administrator requirements are out of 69 scope for version 1.1. 71 The document, "Rationale for the Structure and Model and Protocol for 72 the Internet Printing Protocol", describes IPP from a high level view, 73 defines a roadmap for the various documents that form the suite of IPP 74 specifications, and gives background and rationale for the IETF working 75 group's major decisions. 77 The document, "Internet Printing Protocol/1.1: Model and Semantics", 78 describes a simplified model with abstract objects, their attributes, 79 and their operations that are independent of encoding and transport. It 80 introduces a Printer and a Job object. The Job object optionally 81 supports multiple documents per Job. It also addresses security, 82 internationalization, and directory issues. 84 The document "Internet Printing Protocol/1.1: Implementer's Guide", 85 gives advice to implementers of IPP clients and IPP objects. 87 The document "Mapping between LPD and IPP Protocols" gives some advice 88 to implementers of gateways between IPP and LPD (Line Printer Daemon) 89 implementations. 91 Table of Contents 93 1. Introduction........................................................3 94 2. Conformance Terminology.............................................4 95 3. Encoding of the Operation Layer....................................4 96 3.1 Picture of the Encoding.......................................5 97 3.2 Syntax of Encoding............................................7 98 3.3 Version-number................................................8 99 3.4 Operation-id..................................................8 100 3.5 Status-code...................................................9 101 3.6 Request-id....................................................9 102 3.7 Tags..........................................................9 103 3.7.1 Delimiter Tags...........................................9 104 3.7.2 Value Tags..............................................10 105 3.8 Name-Length..................................................12 106 3.9 (Attribute) Name.............................................12 107 3.10 Value Length.................................................14 108 3.11 (Attribute) Value............................................14 109 3.12 Data.........................................................16 110 4. Encoding of Transport Layer........................................16 111 5. IPP URL Scheme.....................................................17 112 6. Compatibility with IPP/1.0 Implementations.........................18 113 7. Security Considerations............................................20 114 7.1 Security Conformance.........................................20 115 7.2 Using IPP with TLS...........................................20 116 8. References.........................................................21 117 9. Author's Address...................................................23 118 10.Other Participants:...............................................24 119 11.Appendix A: Protocol Examples.....................................24 120 11.1 Print-Job Request............................................24 121 11.2 Print-Job Response (successful)..............................26 122 11.3 Print-Job Response (failure).................................26 123 11.4 Print-Job Response (success with attributes ignored).........27 124 11.5 Print-URI Request............................................29 125 11.6 Create-Job Request...........................................30 126 11.7 Get-Jobs Request.............................................30 127 11.8 Get-Jobs Response............................................31 128 12.Appendix C: Registration of MIME Media Type Information for 129 "application/ipp".....................................................32 130 13.Appendix D: Changes from IPP /1.0.................................34 131 14.Full Copyright Statement..........................................34 133 1. Introduction 135 This document contains the rules for encoding IPP operations and 136 describes two layers: the transport layer and the operation layer. 138 The transport layer consists of an HTTP/1.1 request or response. RFC 139 2068 [rfc2068] describes HTTP/1.1. This document specifies the HTTP 140 headers that an IPP implementation supports. 142 The operation layer consists of a message body in an HTTP request or 143 response. The document "Internet Printing Protocol/1.1: Model and 144 Semantics" [ipp-mod] defines the semantics of such a message body and 145 the supported values. This document specifies the encoding of an IPP 146 operation. The aforementioned document [ipp-mod] is henceforth referred 147 to as the "IPP model document" 149 2. Conformance Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 152 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 153 interpreted as described in RFC 2119 [rfc2119]. 155 3. Encoding of the Operation Layer 157 The operation layer MUST contain a single operation request or operation 158 response. Each request or response consists of a sequence of values and 159 attribute groups. Attribute groups consist of a sequence of attributes 160 each of which is a name and value. Names and values are ultimately 161 sequences of octets 163 The encoding consists of octets as the most primitive type. There are 164 several types built from octets, but three important types are 165 integers, character strings and octet strings, on which most other 166 data types are built. Every character string in this encoding MUST be a 167 sequence of characters where the characters are associated with some 168 charset and some natural language. A character string MUST be in 169 "reading order" with the first character in the value (according to 170 reading order) being the first character in the encoding. A character 171 string whose associated charset is US-ASCII whose associated natural 172 language is US English is henceforth called a US-ASCII-STRING. A 173 character string whose associated charset and natural language are 174 specified in a request or response as described in the model document is 175 henceforth called a LOCALIZED-STRING. An octet string MUST be in "IPP 176 model document order" with the first octet in the value (according to 177 the IPP model document order) being the first octet in the encoding 178 Every integer in this encoding MUST be encoded as a signed integer using 179 two's-complement binary encoding with big-endian format (also known as 180 "network order" and "most significant byte first"). The number of octets 181 for an integer MUST be 1, 2 or 4, depending on usage in the protocol. 182 Such one-octet integers, henceforth called SIGNED-BYTE, are used for the 183 version-number and tag fields. Such two-byte integers, henceforth called 184 SIGNED-SHORT are used for the operation-id, status-code and length 185 fields. Four byte integers, henceforth called SIGNED-INTEGER, are used 186 for values fields and the sequence number. 188 The following two sections present the operation layer in two ways 190 - informally through pictures and description 192 - formally through Augmented Backus-Naur Form (ABNF), as specified by 193 RFC 2234 [rfc2234] 195 3.1 Picture of the Encoding 197 The encoding for an operation request or response consists of: 199 ----------------------------------------------- 200 | version-number | 2 bytes - required 201 ----------------------------------------------- 202 | operation-id (request) | 203 | or | 2 bytes - required 204 | status-code (response) | 205 ----------------------------------------------- 206 | request-id | 4 bytes - required 207 ----------------------------------------------------------- 208 | xxx-attributes-tag | 1 byte | 209 ----------------------------------------------- |-0 or more 210 | xxx-attribute-sequence | n bytes | 211 ----------------------------------------------------------- 212 | end-of-attributes-tag | 1 byte - required 213 ----------------------------------------------- 214 | data | q bytes - optional 215 ----------------------------------------------- 217 The xxx-attributes-tag and xxx-attribute-sequence represents four 218 different values of "xxx", namely, operation, job, printer and 219 unsupported. The xxx-attributes-tag and an xxx-attribute-sequence 220 represent attribute groups in the model document. The xxx-attributes-tag 221 identifies the attribute group and the xxx-attribute-sequence contains 222 the attributes. 224 The expected sequence of xxx-attributes-tag and xxx-attribute-sequence 225 is specified in the IPP model document for each operation request and 226 operation response. 228 A request or response SHOULD contain each xxx-attributes-tag defined for 229 that request or response even if there are no attributes except for the 230 unsupported-attributes-tag which SHOULD be present only if the 231 unsupported-attribute-sequence is non-empty. A receiver of a request 232 MUST be able to process as equivalent empty attribute groups: 234 a) an xxx-attributes-tag with an empty xxx-attribute-sequence, 236 b) an expected but missing xxx-attributes-tag. 238 The data is omitted from some operations, but the end-of-attributes-tag 239 is present even when the data is omitted. Note, the xxx-attributes-tags 240 and end-of-attributes-tag are called 'delimiter-tags'. Note: the xxx- 241 attribute-sequence, shown above may consist of 0 bytes, according to the 242 rule below. 244 An xxx-attributes-sequence consists of zero or more compound-attributes. 246 ----------------------------------------------- 247 | compound-attribute | s bytes - 0 or more 248 ----------------------------------------------- 250 A compound-attribute consists of an attribute with a single value 251 followed by zero or more additional values. 253 Note: a 'compound-attribute' represents a single attribute in the model 254 document. The 'additional value' syntax is for attributes with 2 or 255 more values. 257 Each attribute consists of: 259 ----------------------------------------------- 260 | value-tag | 1 byte 261 ----------------------------------------------- 262 | name-length (value is u) | 2 bytes 263 ----------------------------------------------- 264 | name | u bytes 265 ----------------------------------------------- 266 | value-length (value is v) | 2 bytes 267 ----------------------------------------------- 268 | value | v bytes 269 ----------------------------------------------- 271 An additional value consists of: 273 ----------------------------------------------------------- 274 | value-tag | 1 byte | 275 ----------------------------------------------- | 276 | name-length (value is 0x0000) | 2 bytes | 277 ----------------------------------------------- |-0 or more 278 | value-length (value is w) | 2 bytes | 279 ----------------------------------------------- | 280 | value | w bytes | 281 ----------------------------------------------------------- 283 Note: an additional value is like an attribute whose name-length is 0. 285 >From the standpoint of a parsing loop, the encoding consists of: 287 ----------------------------------------------- 288 | version-number | 2 bytes - required 289 ----------------------------------------------- 290 | operation-id (request) | 291 | or | 2 bytes - required 292 | status-code (response) | 293 ----------------------------------------------- 294 | request-id | 4 bytes - required 295 ----------------------------------------------------------- 296 | tag (delimiter-tag or value-tag) | 1 byte | 297 ----------------------------------------------- |-0 or more 298 | empty or rest of attribute | x bytes | 299 ----------------------------------------------------------- 300 | end-of-attributes-tag | 2 bytes - required 301 ----------------------------------------------- 302 | data | y bytes - optional 303 ----------------------------------------------- 305 The value of the tag determines whether the bytes following the tag are: 307 - attributes 309 - data 311 - the remainder of a single attribute where the tag specifies the 312 type of the value. 314 3.2 Syntax of Encoding 316 The syntax below is ABNF [rfc2234] except 'strings of literals' MUST be 317 case sensitive. For example 'a' means lower case 'a' and not upper case 318 'A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields are represented 319 as '%x' values which show their range of values. 321 ipp-message = ipp-request / ipp-response 322 ipp-request = version-number operation-id request-id 323 *(xxx-attributes-tag xxx-attribute-sequence) end-of- 324 attributes-tag data 325 ipp-response = version-number status-code request-id 326 *(xxx-attributes-tag xxx-attribute-sequence) end-of- 327 attributes-tag data 328 xxx-attribute-sequence = *compound-attribute 330 xxx-attributes-tag = operation-attributes-tag / job-attributes-tag / 331 printer-attributes-tag / unsupported-attributes-tag 333 version-number = major-version-number minor-version-number 334 major-version-number = SIGNED-BYTE ; initially %d1 335 minor-version-number = SIGNED-BYTE ; initially %d0 337 operation-id = SIGNED-SHORT ; mapping from model defined below 338 status-code = SIGNED-SHORT ; mapping from model defined below 339 request-id = SIGNED-INTEGER ; whose value is > 0 341 compound-attribute = attribute *additional-values 343 attribute = value-tag name-length name value-length value 344 additional-values = value-tag zero-name-length value-length value 346 name-length = SIGNED-SHORT ; number of octets of 'name' 347 name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." ) 348 value-length = SIGNED-SHORT ; number of octets of 'value' 349 value = OCTET-STRING 351 data = OCTET-STRING 353 zero-name-length = %x00.00 ; name-length of 0 354 operation-attributes-tag = %x01 ; tag of 1 355 job-attributes-tag = %x02 ; tag of 2 356 printer-attributes-tag = %x04 ; tag of 4 357 unsupported- attributes-tag = %x05 ; tag of 5 358 end-of-attributes-tag = %x03 ; tag of 3 359 value-tag = %x10-FF 361 SIGNED-BYTE = BYTE 362 SIGNED-SHORT = 2BYTE 363 SIGNED-INTEGER = 4BYTE 364 DIGIT = %x30-39 ; "0" to "9" 365 LALPHA = %x61-7A ; "a" to "z" 366 BYTE = %x00-FF 367 OCTET-STRING = *BYTE 369 The syntax allows an xxx-attributes-tag to be present when the xxx- 370 attribute-sequence that follows is empty. The syntax is defined this way 371 to allow for the response of Get-Jobs where no attributes are returned 372 for some job-objects. Although it is RECOMMENDED that the sender not 373 send an xxx-attributes-tag if there are no attributes (except in the 374 Get-Jobs response just mentioned), the receiver MUST be able to decode 375 such syntax. 377 3.3 Version-number 379 The version-number MUST consist of a major and minor version-number, 380 each of which MUST be represented by a SIGNED-BYTE. The protocol 381 described in this document MUST have a major version-number of 1 (0x01) 382 and a minor version-number of 1 (0x01). The ABNF for these two bytes 383 MUST be %x01.01. 385 3.4 Operation-id 387 Operation-ids are defined as enums in the model document. An operation- 388 ids enum value MUST be encoded as a SIGNED-SHORT. 390 Note: the values 0x4000 to 0xFFFF are reserved for private extensions. 392 3.5 Status-code 394 Status-codes are defined as enums in the model document. A status-code 395 enum value MUST be encoded as a SIGNED-SHORT. 397 The status-code is an operation attribute in the model document. In the 398 protocol, the status-code is in a special position, outside of the 399 operation attributes. 401 If an IPP status-code is returned, then the HTTP Status-Code MUST be 200 402 (successful-ok). With any other HTTP Status-Code value, the HTTP 403 response MUST NOT contain an IPP message-body, and thus no IPP status- 404 code is returned. 406 3.6 Request-id 408 The request-id allows a client to match a response with a request. This 409 mechanism is unnecessary in HTTP, but may be useful when application/ipp 410 entity bodies are used in another context. 412 The request-id in a response MUST be the value of the request-id 413 received in the corresponding request. A client can set the request-id 414 in each request to a unique value or a constant value, such as 1, 415 depending on what the client does with the request-id returned in the 416 response. The value of the request-id MUST be greater than zero. 418 3.7 Tags 420 There are two kinds of tags: 422 - delimiter tags: delimit major sections of the protocol, namely 423 attributes and data 425 - value tags: specify the type of each attribute value 427 3.7.1 Delimiter Tags 429 The following table specifies the values for the delimiter tags: 431 Tag Value (Hex) Delimiter 433 0x00 reserved 434 0x01 operation-attributes-tag 435 0x02 job-attributes-tag 436 0x03 end-of-attributes-tag 437 0x04 printer-attributes-tag 438 0x05 unsupported-attributes-tag 439 0x06-0x0e reserved for future delimiters 440 0x0F reserved for future chunking-end-of-attributes- 441 tag 443 When an xxx-attributes-tag occurs in the protocol, it MUST mean that 444 zero or more following attributes up to the next delimiter tag are 445 attributes belonging to group xxx as defined in the model document, 446 where xxx is operation, job, printer, unsupported. 448 Doing substitution for xxx in the above paragraph, this means the 449 following. When an operation-attributes-tag occurs in the protocol, it 450 MUST mean that the zero or more following attributes up to the next 451 delimiter tag are operation attributes as defined in the model document. 452 When an job-attributes-tag occurs in the protocol, it MUST mean that the 453 zero or more following attributes up to the next delimiter tag are job 454 attributes or job template attributes as defined in the model document. 455 When a printer-attributes-tag occurs in the protocol, it MUST mean that 456 the zero or more following attributes up to the next delimiter tag are 457 printer attributes as defined in the model document. When an 458 unsupported-attributes-tag occurs in the protocol, it MUST mean that the 459 zero or more following attributes up to the next delimiter tag are 460 unsupported attributes as defined in the model document. 462 The operation-attributes-tag and end-of-attributes-tag MUST each occur 463 exactly once in an operation. The operation-attributes-tag MUST be the 464 first tag delimiter, and the end-of-attributes-tag MUST be the last tag 465 delimiter. If the operation has a document-content group, the document 466 data in that group MUST follow the end-of-attributes-tag. 468 Each of the other three xxx-attributes-tags defined above is OPTIONAL 469 in an operation and each MUST occur at most once in an operation, except 470 for job-attributes-tag in a Get-Jobs response which may occur zero or 471 more times. 473 The order and presence of delimiter tags for each operation request and 474 each operation response MUST be that defined in the model document. For 475 further details, see section 3.9 "(Attribute) Name" and section 11 476 "Appendix A: Protocol Examples". 478 A Printer MUST treat the reserved delimiter tags differently from 479 reserved value tags so that the Printer knows that there is an entire 480 attribute group that it doesn't understand as opposed to a single value 481 that it doesn't understand. 483 3.7.2 Value Tags 485 The remaining tables show values for the value-tag, which is the first 486 octet of an attribute. The value-tag specifies the type of the value of 487 the attribute. The following table specifies the "out-of-band" values 488 for the value-tag. 490 Tag Value (Hex) Meaning 492 0x10 unsupported 493 0x11 reserved for future 'default' 494 0x12 unknown 495 0x13 no-value 496 Tag Value (Hex) Meaning 498 0x14-0x1F reserved for future "out-of-band" values. 500 The "unsupported" value MUST be used in the attribute-sequence of an 501 error response for those attributes which the printer does not support. 502 The "default" value is reserved for future use of setting value back to 503 their default value. The "unknown" value is used for the value of a 504 supported attribute when its value is temporarily unknown. The "no- 505 value" value is used for a supported attribute to which no value has 506 been assigned, e.g. "job-k-octets-supported" has no value if an 507 implementation supports this attribute, but an administrator has not 508 configured the printer to have a limit. 510 The following table specifies the integer values for the value-tag: 512 Tag Value (Hex) Meaning 514 0x20 reserved 515 0x21 integer 516 0x22 boolean 517 0x23 enum 518 0x24-0x2F reserved for future integer types 520 NOTE: 0x20 is reserved for "generic integer" if it should ever be 521 needed. 523 The following table specifies the octetString values for the value-tag: 525 Tag Value (Hex) Meaning 527 0x30 octetString with an unspecified format 528 0x31 dateTime 529 0x32 resolution 530 0x33 rangeOfInteger 531 0x34 reserved for collection (in the future) 532 0x35 textWithLanguage 533 0x36 nameWithLanguage 534 0x37-0x3F reserved for future octetString types 536 The following table specifies the character-string values for the value- 537 tag: 539 Tag Value (Hex) Meaning 541 0x40 reserved 542 0x41 textWithoutLanguage 543 0x42 nameWithoutLanguage 544 0x43 reserved 545 0x44 keyword 546 0x45 uri 547 0x46 uriScheme 548 0x47 charset 549 0x48 naturalLanguage 550 Tag Value (Hex) Meaning 552 0x49 mimeMediaType 553 0x4A-0x5F reserved for future character string types 555 NOTE: 0x40 is reserved for "generic character-string" if it should ever 556 be needed. 558 NOTE: an attribute value always has a type, which is explicitly 559 specified by its tag; one such tag value is "nameWithoutLanguage". An 560 attribute's name has an implicit type, which is keyword. 562 The values 0x60-0xFF are reserved for future types. There are no values 563 allocated for private extensions. A new type MUST be registered via the 564 type 2 registration process [ipp-mod]. 566 The tag 0x7F is reserved for extending types beyond the 255 values 567 available with a single byte. A tag value of 0x7F MUST signify that the 568 first 4 bytes of the value field are interpreted as the tag value. 569 Note, this future extension doesn't affect parsers that are unaware of 570 this special tag. The tag is like any other unknown tag, and the value 571 length specifies the length of a value which contains a value that the 572 parser treats atomically. All these 4 byte tag values are currently 573 unallocated except that the values 0x40000000-0x7FFFFFFF are reserved 574 for experimental use. 576 3.8 Name-Length 578 The name-length field MUST consist of a SIGNED-SHORT. This field MUST 579 specify the number of octets in the name field which follows the name- 580 length field, excluding the two bytes of the name-length field. 582 If a name-length field has a value of zero, the following name field 583 MUST be empty, and the following value MUST be treated as an additional 584 value for the preceding attribute. Within an attribute-sequence, if two 585 attributes have the same name, the first occurrence MUST be ignored. The 586 zero-length name is the only mechanism for multi-valued attributes. 588 3.9 (Attribute) Name 590 Some operation elements are called parameters in the model document 591 [ipp-mod]. They MUST be encoded in a special position and they MUST NOT 592 appear as an operation attributes. These parameters are: 594 - "version-number": The parameter named "version-number" in the IPP 595 model document MUST become the "version-number" field in the 596 operation layer request or response. 598 - "operation-id": The parameter named "operation-id" in the IPP model 599 document MUST become the "operation-id" field in the operation 600 layer request. 602 - "status-code": The parameter named "status-code" in the IPP model 603 document MUST become the "status-code" field in the operation layer 604 response. 606 - "request-id": The parameter named "request-id" in the IPP model 607 document MUST become the "request-id" field in the operation layer 608 request or response. 609 All Printer and Job objects are identified by a Uniform Resource 610 Identifier (URI) [rfc2396] so that they can be persistently and 611 unambiguously referenced. The notion of a URI is a useful concept, 612 however, until the notion of URI is more stable (i.e., defined more 613 completely and deployed more widely), it is expected that the URIs used 614 for IPP objects will actually be URLs [rfc1738] [rfc1808]. Since every 615 URL is a specialized form of a URI, even though the more generic term 616 URI is used throughout the rest of this document, its usage is intended 617 to cover the more specific notion of URL as well. 619 Some operation elements are encoded twice, once as the request-URI on 620 the HTTP Request-Line and a second time as a REQUIRED operation 621 attribute in the application/ipp entity. These attributes are the 622 target URI for the operation and are called printer-uri and job-uri. 623 Note: The target URI is included twice in an operation referencing the 624 same IPP object, but the two URIs NEED NOT be literally identical. One 625 can be a relative URI and the other can be an absolute URI. HTTP/1.1 626 allows clients to generate and send a relative URI rather than an 627 absolute URI. A relative URI identifies a resource with the scope of 628 the HTTP server, but does not include scheme, host or port. The 629 following statements characterize how URLs should be used in the mapping 630 of IPP onto HTTP/1.1: 632 1. Although potentially redundant, a client MUST supply the target of 633 the operation both as an operation attribute and as a URI at the 634 HTTP layer. The rationale for this decision is to maintain a 635 consistent set of rules for mapping application/ipp to possibly 636 many communication layers, even where URLs are not used as the 637 addressing mechanism in the transport layer. 638 2. Even though these two URLs might not be literally identical (one 639 being relative and the other being absolute), they MUST both 640 reference the same IPP object. 641 3. The URI in the HTTP layer is either relative or absolute and is 642 used by the HTTP server to route the HTTP request to the correct 643 resource relative to that HTTP server. The HTTP server need not be 644 aware of the URI within the operation request. 645 4. Once the HTTP server resource begins to process the HTTP request, 646 it might get the reference to the appropriate IPP Printer object 647 from either the HTTP URI (using to the context of the HTTP server 648 for relative URLs) or from the URI within the operation request; 649 the choice is up to the implementation. 650 5. HTTP URIs can be relative or absolute, but the target URI in the 651 operation MUST be an absolute URI. 653 The model document arranges the remaining attributes into groups for 654 each operation request and response. Each such group MUST be represented 655 in the protocol by an xxx-attribute-sequence preceded by the appropriate 656 xxx-attributes-tag (See the table below and section 11 "Appendix A: 657 Protocol Examples"). In addition, the order of these xxx-attributes-tags 658 and xxx-attribute-sequences in the protocol MUST be the same as in the 659 model document, but the order of attributes within each xxx-attribute- 660 sequence MUST be unspecified. The table below maps the model document 661 group name to xxx-attributes-sequence: 663 Model Document Group xxx-attributes-sequence 665 Operation Attributes operations-attributes-sequence 666 Job Template Attributes job-attributes-sequence 667 Job Object Attributes job-attributes-sequence 668 Unsupported Attributes unsupported- attributes-sequence 669 Requested Attributes (Get- job-attributes-sequence 670 Job-Attributes) 671 Requested Attributes (Get- printer-attributes-sequence 672 Printer-Attributes) 673 Document Content in a special position as described above 675 If an operation contains attributes from more than one job object (e.g. 676 Get-Jobs response), the attributes from each job object MUST be in a 677 separate job-attribute-sequence, such that the attributes from the ith 678 job object are in the ith job-attribute-sequence. See Section 11 679 "Appendix A: Protocol Examples" for table showing the application of the 680 rules above. 682 3.10 Value Length 684 Each attribute value MUST be preceded by a SIGNED-SHORT, which MUST 685 specify the number of octets in the value which follows this length, 686 exclusive of the two bytes specifying the length. 688 For any of the types represented by binary signed integers, the sender 689 MUST encode the value in exactly four octets. 691 For any of the types represented by character-strings, the sender MUST 692 encode the value with all the characters of the string and without any 693 padding characters. 695 If a value-tag contains an "out-of-band" value, such as "unsupported", 696 the value-length MUST be 0 and the value empty . the value has no 697 meaning when the value-tag has an "out-of-band" value. 699 3.11 (Attribute) Value 701 The syntax types and most of the details of their representation are 702 defined in the IPP model document. The table below augments the 703 information in the model document, and defines the syntax types from the 704 model document in terms of the 5 basic types defined in section 3 705 "Encoding of the Operation Layer". The 5 types are US-ASCII-STRING, 706 LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET- 707 STRING. 709 Syntax of Attribute Encoding 710 Value 712 textWithoutLanguage, LOCALIZED-STRING. 713 nameWithoutLanguage 715 textWithLanguage OCTET_STRING consisting of 4 fields: 716 a) a SIGNED-SHORT which is the number of octets 717 in the following field 718 b) a value of type natural-language, 719 c) a SIGNED-SHORT which is the number of octets 720 in the following field, 721 d) a value of type textWithoutLanguage. 723 The length of a textWithLanguage value MUST be 4 724 + the value of field a + the value of field c. 726 nameWithLanguage OCTET_STRING consisting of 4 fields: 727 a) a SIGNED-SHORT which is the number of octets 728 in the following field 729 b) a value of type natural-language, 730 c) a SIGNED-SHORT which is the number of octets 731 in the following field 732 d) a value of type nameWithoutLanguage. 734 The length of a nameWithLanguage value MUST be 4 735 + the value of field a + the value of field c. 737 charset, US-ASCII-STRING. 738 naturalLanguage, 739 mimeMediaType, 740 keyword, uri, and 741 uriScheme 743 boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is 744 'true'. 746 integer and enum a SIGNED-INTEGER. 748 dateTime OCTET-STRING consisting of eleven octets whose 749 contents are defined by "DateAndTime" in RFC 750 1903 [rfc1903]. 752 resolution OCTET_STRING consisting of nine octets of 2 753 SIGNED-INTEGERs followed by a SIGNED-BYTE. The 754 first SIGNED-INTEGER contains the value of cross 755 feed direction resolution. The second SIGNED- 756 INTEGER contains the value of feed direction 757 resolution. The SIGNED-BYTE contains the units 758 value. 760 Syntax of Attribute Encoding 761 Value 763 rangeOfInteger Eight octets consisting of 2 SIGNED-INTEGERs. 764 The first SIGNED-INTEGER contains the lower 765 bound and the second SIGNED-INTEGER contains the 766 upper bound. 768 1setOf X Encoding according to the rules for an attribute 769 with more than 1 value. Each value X is encoded 770 according to the rules for encoding its type. 772 octetString OCTET-STRING 774 The type of the value in the model document determines the encoding in 775 the value and the value of the value-tag. 777 3.12 Data 779 The data part MUST include any data required by the operation 781 4. Encoding of Transport Layer 783 HTTP/1.1 [rfc2068] is the transport layer for this protocol. 785 The operation layer has been designed with the assumption that the 786 transport layer contains the following information: 788 - the URI of the target job or printer operation 790 - the total length of the data in the operation layer, either as a 791 single length or as a sequence of chunks each with a length. 792 It is REQUIRED that a printer implementation support HTTP over the IANA 793 assigned Well Known Port 631 (the IPP default port), though a printer 794 implementation may support HTTP over some other port as well. 796 Each HTTP operation MUST use the POST method where the request-URI is 797 the object target of the operation, and where the "Content-Type" of the 798 message-body in each request and response MUST be "application/ipp". The 799 message-body MUST contain the operation layer and MUST have the syntax 800 described in section 3.2 "Syntax of Encoding". A client implementation 801 MUST adhere to the rules for a client described for HTTP1.1 [rfc2068] . 802 A printer (server) implementation MUST adhere the rules for an origin 803 server described for HTTP1.1 [rfc2068]. 805 An IPP server sends a response for each request that it receives. If an 806 IPP server detects an error, it MAY send a response before it has read 807 the entire request. If the HTTP layer of the IPP server completes 808 processing the HTTP headers successfully, it MAY send an intermediate 809 response, such as "100 Continue", with no IPP data before sending the 810 IPP response. A client MUST expect such a variety of responses from an 811 IPP server. For further information on HTTP/1.1, consult the HTTP 812 documents [rfc2068]. 814 An HTTP server MUST support chunking for IPP requests, and an IPP client 815 MUST support chunking for IPP responses according to HTTP/1.1[rfc2068]. 816 Note: this rule causes a conflict with non-compliant implementations of 817 HTTP/1.1 that don't support chunking for POST methods, and this rule may 818 cause a conflict with non-compliant implementations of HTTP/1.1 that 819 don't support chunking for CGI scripts 821 5. IPP URL Scheme 823 The IPP/1.1 specification defines a new scheme 'ipp' as the value of a 824 URL that identifies either an IPP printer object or an IPP job object. 825 The IPP attributes using the 'ipp' scheme are specified below. Because 826 the HTTP layer does not support the 'ipp' scheme, a client MUST map 827 'ipp' URLs to 'http' URLs, and then follows the HTTP [RFC2068][RFC2069] 828 rules for constructing a Request-Line and HTTP headers. The mapping is 829 simple because the 'ipp' scheme implies all of the same protocol 830 semantics as that of the 'http' scheme [RFC2068], except that it 831 represents a print service and the implicit (default) port number that 832 clients use to connect to a server is port 631. 834 In the remainder of this section the term 'ipp-URL' means a URL whose 835 scheme is 'ipp' and whose implicit (default) port is 631. The term 836 'http-URL' means a URL whose scheme is 'http', and the term 'https-URL' 837 means a URL whose scheme is 'https', 839 A client and an IPP object (i.e. the server) MUST support the ipp-URL 840 value in the following IPP attributes. 841 job attributes: 842 job-uri 843 job-printer-uri 844 printer attributes: 845 printer-uri-supported 846 operation attributes: 847 job-uri 848 printer-uri 850 Each of the above attributes identifies a printer or job object. The 851 ipp-URL is intended as the value of the attributes in this list, and for 852 no other attributes. All of these attributes have a syntax type of 853 'uri', but there are attributes with a syntax type of 'uri' that do not 854 use the 'ipp' scheme, e.g. 'job-more-info'. 856 If a printer registers its URL with a directory service, the printer 857 MUST register an ipp-URL. 859 User interfaces are beyond the scope of this document. But if software 860 exposes the ipp-URL values of any of the above five attributes to a 861 human user, it is REQUIRED that the human see the ipp-URL as is. 863 When a client sends a request, it MUST convert a target ipp-URL to a 864 target http-URL for the HTTP layer according to the following rules: 865 1. change the 'ipp' scheme to 'http' 866 2. add an explicit port 631 if the URL does not contain an explicit 867 port. Note: port 631 is the IANA assigned Well Known Port for the 868 'ipp' scheme. 870 The client MUST use the target http-URL in both the HTTP Request-Line 871 and HTTP headers, as specified by HTTP[RFC2068][RFC2069] . However, the 872 client MUST use the target ipp-URL for the value of the "printer-uri" or 873 "job-uri" operation attribute within the application/ipp body of the 874 request. The server MUST use the ipp-URL for the value of the "printer- 875 uri", "job-uri" or "printer-uri-supported" attributes within the 876 application/ipp body of the response. 878 For example, when an IPP client sends a request directly (i.e. no proxy) 879 to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a TCP 880 connection to port 631 (the ipp implicit port) on the host "myhost.com" 881 and sends the following data: 883 POST /myprinter/myqueue HTTP/1.1 884 Host: myhost.com:631 885 Content-type: application/ipp 886 Transfer-Encoding: chunked 887 ... 888 "printer-uri" "ipp://myhost.com/myprinter/myqueue" 889 (encoded in application/ipp message body) 890 ... 892 As another example, when an IPP client sends the same request as above 893 via a proxy "myproxy.com", it opens a TCP connection to the proxy port 894 8080 on the proxy host "myproxy.com" and sends the following data: 896 POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 897 Host: myhost.com:631 898 Content-type: application/ipp 899 Transfer-Encoding: chunked 900 ... 901 "printer-uri" "ipp://myhost.com/myprinter/myqueue" 902 (encoded in application/ipp message body) 903 ... 905 The proxy then connects to the IPP origin server with headers that are 906 the same as the "no-proxy" example above. 908 6. Compatibility with IPP/1.0 Implementations 910 IPP/1.1 server implementations SHOULD interoperate with IPP/1.0 client 911 implementations, as defined in [rfc 2565] and [rfc 2566] documents. If 912 an IPP/1.1 server implementation does not support an IPP/1.0 client, it 913 MUST return the error 'server-error-version-not-supported' and the 914 version in the response MUST be a version that the server supports and 915 SHOULD be a version that is closest to the clients version in the 916 request. 918 The following are specific rules of interoperability for an IPP/1.1 919 server that supports IPP/1.0 clients. 921 - If a server receives an IPP/1.0 request, it MUST return an IPP/1.0 922 response. That is, it MUST support both an http-URL and an https- 923 URL in the target "printer-uri" and "job-uri" operation attributes 924 in a request. The rules for attributes in a response is covered in 925 the next two bullet items. 927 - When a server returns the printer attribute "printer-uri- 928 supported", it MUST return all values of the attribute for an 929 IPP/1.1 request. For an IPP/1.0 request, a server MUST return a 930 subset of the attribute values, excluding those that are ipp-URLs, 931 and including those that are http-URLs and https-URLs.. 933 - The table below shows the type of URL that a server returns for the 934 "job-uri" and "job-printer-uri" job attributes for all operations 935 based on how the job was created. 937 Operation Job created via 938 attribute 939 s for a 940 ipp secure ipp http https 941 request 943 ipp ipp No URL ipp No URL 944 returned returned 946 secure ipp ipp ipp ipp 947 ipp 949 http http No URL http No URL 950 returned returned 952 https http https http https 954 - If a server registers a nonsecure ipp-URL with a name service, then 955 it MUST also register an http-URL. If a printer supports a secure 956 connection using SSL3, then it MUST register an https-URL. 957 IPP/1.1 client implementations SHOULD interoperate with IPP/1.0 server 958 implementations. If an IPP/1.1 client receives an error 'server-error- 959 version-not-supported' and the version in the response is 1.0 and the 960 client supports IPP/1.0, the IPP/1.1 client MUST convert the target URI 961 (as defined in Section 4 of this document) and act as an IPP/1.0 client 962 [rfc 2565 and rfc 2566]. If the IPP/1.1 operation was intended to be 963 secure, the target conversion MUST result in an 'https' scheme; 964 otherwise it is an 'http' scheme. 966 7. Security Considerations 968 The IPP Model and Semantics document [ipp-mod] discusses high level 969 security requirements (Client Authentication, Server Authentication and 970 Operation Privacy). Client Authentication is the mechanism by which the 971 client proves its identity to the server in a secure manner. Server 972 Authentication is the mechanism by which the server proves its identity 973 to the client in a secure manner. Operation Privacy is defined as a 974 mechanism for protecting operations from eavesdropping. 976 7.1 Security Conformance 978 IPP clients MUST/SHOULD [which is to be determined in consultation with 979 the Area Director] support: 981 Digest Authentication [rfc2069]. 983 MD5 and MD5-sess MUST be implemented and supported. 985 The Message Integrity feature NEED NOT be used. 987 IPP Printers MUST/SHOULD [which is to be determined in consultation with 988 the Area Director] support: 990 Digest Authentication [rfc2069]. 992 MD5 and MD5-sess MUST be implemented and supported. 994 The Message Integrity feature NEED NOT be used. 996 IPP Printers SHOULD support TLS for client authentication, server 997 authentication and operation privacy. If an IPP Printer supports TLS, it 998 MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as 999 mandated by RFC 2246 [rfc2246]. All other cipher suites are OPTIONAL. An 1000 IPP Printer MAY support Basic Authentication (described in HTTP/1.1 [ 1001 rfc 2068]) for client authentication if the channel is secure. TLS 1002 with the above mandated cipher suite can provide such a secure channel. 1004 The IPP Model and Semantics document defines two printer attributes 1005 ("uri-authentication-supported" and "uri-security-supported") that the 1006 client can use to discover the security policy of a printer. That 1007 document also outlines IPP-specific security considerations and should 1008 be the primary reference for security implications with regard to the 1009 IPP protocol itselfFor backward compatibility with IPP version 1.0, IPP 1010 clients and printers MAY also support SSL3. This is in addition to the 1011 security required in this document. 1013 7.2 Using IPP with TLS 1015 An initial IPP request never uses TLS. The switch to TLS occurs either 1016 because the server grants the client's request to upgrade to TLS, or a 1017 server asks to switch to TLS in its response. Secure communication 1018 begins with a server's response to switch to TLS. The initial connection 1019 is not secure. Any client expecting a secure connection should first use 1020 a non-sensitive operation (e.g. an HTTP POST with an empty message body) 1021 to establish a secure connection before sending any sensitive data. 1022 During the TLS handshake, the original session is preserved. 1024 An IPP client that wants a secure connection MUST send "TLS/1.0" as one 1025 of the field-values of the HTTP/1.1 Upgrade request header, e.g. 1026 "Upgrade: TLS/1.0" (see rfc2068 section 14.42). If the origin-server 1027 grants the upgrade request, it MUST respond with "101 Switching 1028 Protocols", and it MUST include the header "Upgrade: TLS/1.0" to 1029 indicate what it is switching to. An IPP client MUST be ready to react 1030 appropriately if the server does not grant the upgrade request. Note: 1031 the 'Upgrade header' mechanism allows unsecured and secured traffic to 1032 share the same port (in this case, 631). 1034 With current technology, an IPP server can indicate that it wants an 1035 upgrade only by returning "401 unauthorized" or "403 forbidden". A 1036 server MAY give the client an additional hint by including an "Upgrade: 1037 TLS" header in the response. When an IPP client receives such a 1038 response, it can perform the request again with an Upgrade header with 1039 the "TLS/1.0" value. 1041 If a server supports TLS, it SHOULD include the "Upgrade" header with 1042 the value "TLS/1.0" in response to any OPTIONS request. 1044 Upgrade is a hop-by-hop header (rfc2068, section 13.5.1), so each 1045 intervening proxy which supports TLS MUST also request the same version 1046 of TLS/1.0 on its subsequent request. Furthermore, any caching proxy 1047 which supports TLS MUST NOT reply from its cache when TLS/1.0 has been 1048 requested (although clients are still recommended to explicitly include 1049 "Cache-control: no-cache"). 1051 Note: proxy servers may be able to request or initiate a TLS-secured 1052 connection, e.g. the outgoing or incoming firewall of a trusted 1053 subnetwork. 1055 8. References 1057 [char] N. Freed, J. Postel: IANA Charset Registration Procedures, Work 1058 in Progress (draft-freed-charset-reg-02.txt). 1060 [dpa] ISO/IEC 10175 Document Printing Application (DPA), June 1996. 1062 [iana] IANA Registry of Coded Character Sets: ftp://ftp.isi.edu/in- 1063 notes/iana/assignments/character-sets. 1065 [ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.1: 1066 Implementer's Guide", draft-ietf-ipp-implementers-guide-01.txt, 1067 February 1999, work in progress. 1069 [ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. 1070 Powell, "Internet Printing Protocol/1.0: Model and Semantics", 1071 , May, 1999. 1073 [ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., 1074 "Internet Printing Protocol/1.1: Encoding and Transport", draft- 1075 ietf-ipp-protocol-v11-00-.txt, February 1999. 1077 [rfc822] Crocker, D., "Standard for the Format of ARPA 1078 Internet Text Messages", RFC 822, August 1982. 1080 [rfc1123] Braden, S., "Requirements for Internet Hosts - 1081 Application and Support", RFC 1123, October, 1989. 1083 [rfc1179] McLaughlin, L. III, (editor), "Line Printer Daemon 1084 Protocol" RFC 1179, August 1990. 1086 [rfc1543] Postel, J., "Instructions to RFC Authors", RFC 1543, 1087 October 1993. 1089 [rfc1738] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform 1090 Resource Locators (URL)", RFC 1738, December, 1994. 1092 [rfc1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and 1093 Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. 1095 [rfc1766] H. Alvestrand, " Tags for the Identification of 1096 Languages", RFC 1766, March 1995. 1098 [rfc1808] R. Fielding, "Relative Uniform Resource Locators", 1099 RFC1808, June 1995. 1101 [rfc1903] J. Case, et al. "Textual Conventions for Version 2 of 1102 the Simple Network Management Protocol (SNMPv2)", RFC 1903, 1103 January 1996. 1105 [rfc2046] N. Freed & N. Borenstein, Multipurpose Internet Mail 1106 Extensions (MIME) Part Two: Media Types. November 1996, RFC 2046. 1108 [rfc2048] N. Freed, J. Klensin & J. Postel. Multipurpose Internet 1109 Mail Extension (MIME) Part Four: Registration Procedures. 1110 November 1996 (Also BCP0013), RFC 2048. 1112 [rfc2068] R Fielding, et al, "Hypertext Transfer Protocol . 1113 HTTP/1.1" RFC 2068, January 1997. 1115 [rfc2069] J. Franks, et al, "An Extension to HTTP: Digest Access 1116 Authentication" RFC 2069, January 1997. 1118 [rfc2119] S. Bradner, "Key words for use in RFCs to Indicate 1119 Requirement Levels", RFC 2119 , March 1997. 1121 [rfc2184] N. Freed, K. Moore, "MIME Parameter Value and Encoded 1122 Word Extensions: Character Sets, Languages, and Continuations", 1123 RFC 2184, August 1997. 1125 [rfc2234] D. Crocker et al., "Augmented BNF for Syntax 1126 Specifications: ABNF", RFC 2234. November 1997. 1128 [rfc2246] T. Dierks et al., "The TLS Protocol", RFC 2246. January 1129 1999. 1131 [rfc2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform 1132 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1133 1998. 1135 [rfc2565] Herriot, R., Butler, S., Moore, P., Turner, R., 1136 "Internet Printing Protocol/1.0: Encoding and Transport", rfc 1137 2565, April 1999. 1139 [rfc 2566] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. 1140 Powell, "Internet Printing Protocol/1.0: Model and Semantics", 1141 rfc 2566, April, 1999. 1143 [rfc2567] Wright, D., "Design Goals for an Internet Printing 1144 Protocol", RFC2567,April 1999. 1146 [rfc2568] Zilles, S., "Rationale for the Structure and Model and 1147 Protocol for the Internet Printing Protocol", RC 2568,April 1148 1999. 1150 [rfc2569] Herriot, R., Hastings, T., Jacobs, N., Martin, J., 1151 "Mapping between LPD and IPP Protocols RFC 2569, April 1999. 1153 9. Author's Address 1155 Paul Moore 1156 Robert Herriot (editor) 1157 Microsoft 1158 Xerox Corporation 1159 One Microsoft Way 1160 3400 Hillview Ave., Bldg #1 1161 Redmond, WA 98053 1162 Palo Alto, CA 94304 1164 Phone: 425-936-0908 1165 Phone: 650-813-7696 1166 Fax: 425-93MS-FAX 1167 Fax: 650-813-6860 1168 Email: paulmo@microsoft.com 1169 Email: 1170 robert.herriot@pahv.xerox.com 1172 Randy Turner 1173 Sylvan Butler 1174 Hewlett-Packard 1175 11311 Chinden Blvd. 1176 Boise, ID 83714 1178 Email: rturner@2wire.com 1179 Phone: 208-396-6000 1180 Fax: 208-396-3457 1181 Email: sbutler@boi.hp.com 1182 John Wenn 1183 Xerox Corporation 1184 737 Hawaii St 1185 El Segundo, CA 90245 1187 IPP Mailing List: ipp@pwg.org Phone: 310-333-5764 1188 IPP Mailing List Subscription: Fax: 310-333-5514 1189 ipp-request@pwg.org 1190 IPP Web Page: Email: jwenn@cp10.es.xerox.com 1191 http://www.pwg.org/ipp/ 1193 10. Other Participants: 1195 Chuck Adams - Tektronix Harry Lewis - IBM 1196 Ron Bergman - Dataproducts Tony Liao - Vivid Image 1197 Keith Carter - IBM David Manchala - Xerox 1198 Angelo Caruso - Xerox Carl-Uno Manros - Xerox 1199 Jeff Copeland - QMS Jay Martin - Underscore 1200 Roger deBry - IBM Larry Masinter - Xerox 1201 Lee Farrell - Canon Ira McDonald - High North Inc. 1202 Sue Gleeson - Digital Bob Pentecost - Hewlett-Packard 1203 Charles Gordon - Osicom Patrick Powell - Astart 1204 Technologies 1205 Brian Grimshaw - Apple Jeff Rackowitz - Intermec 1206 Jerry Hadsell - IBM Xavier Riley - Xerox 1207 Richard Hart - Digital Gary Roberts - Ricoh 1208 Tom Hastings - Xerox Stuart Rowley - Kyocera 1209 Stephen Holmstead Richard Schneider - Epson 1210 Zhi-Hong Huang - Zenographics Shigern Ueda - Canon 1211 Scott Isaacson - Novell Bob Von Andel - Allegro Software 1212 Rich Lomicka - Digital William Wagner - Digital Products 1213 David Kellerman - Northlake Jasper Wong - Xionics 1214 Software 1215 Robert Kline - TrueSpectra Don Wright - Lexmark 1216 Dave Kuntz - Hewlett-Packard Rick Yardumian - Xerox 1217 Takami Kurono - Brother Lloyd Young - Lexmark 1218 Rich Landau - Digital Peter Zehler - Xerox 1219 Greg LeClair - Epson Frank Zhao - Panasonic 1220 Steve Zilles - Adobe 1222 11. Appendix A: Protocol Examples 1224 11.1 Print-Job Request 1226 The following is an example of a Print-Job request with job-name, 1227 copies, and sides specified. The "ipp-attribute-fidelity" attribute is 1228 set to 'true' so that the print request will fail if the "copies" or the 1229 "sides" attribute are not supported or their values are not supported. 1231 Octets Symbolic Value Protocol field 1232 Octets Symbolic Value Protocol field 1234 0x0101 1.1 version-number 1235 0x0002 Print-Job operation-id 1236 0x00000001 1 request-id 1237 0x01 start operation-attributes operation-attributes-tag 1238 0x47 charset type value-tag 1239 0x0012 name-length 1240 attributes- attributes-charset name 1241 charset 1242 0x0008 value-length 1243 us-ascii US-ASCII value 1244 0x48 natural-language type value-tag 1245 0x001B name-length 1246 attributes- attributes-natural-language name 1247 natural- 1248 language 1249 0x0005 value-length 1250 en-us en-US value 1251 0x45 uri type value-tag 1252 0x000B name-length 1253 printer-uri printer-uri name 1254 0x0015 value-length 1255 ipp://forest/p printer pinetree value 1256 inetree 1257 0x42 nameWithoutLanguage type value-tag 1258 0x0008 name-length 1259 job-name job-name name 1260 0x0006 value-length 1261 foobar foobar value 1262 0x22 boolean type value-tag 1263 0x0016 name-length 1264 ipp-attribute- ipp-attribute-fidelity name 1265 fidelity 1266 0x0001 value-length 1267 0x01 true value 1268 0x02 start job-attributes job-attributes-tag 1269 0x21 integer type value-tag 1270 0x0006 name-length 1271 copies copies name 1272 0x0004 value-length 1273 0x00000014 20 value 1274 0x44 keyword type value-tag 1275 0x0005 name-length 1276 sides sides name 1277 0x0013 value-length 1278 two-sided- two-sided-long-edge value 1279 long-edge 1280 0x03 end-of-attributes end-of-attributes-tag 1281 %!PS... data 1282 11.2 Print-Job Response (successful) 1284 Here is an example of a successful Print-Job response to the previous 1285 Print-Job request. The printer supported the "copies" and "sides" 1286 attributes and their supplied values. The status code returned is 1287 'successful-ok'. 1289 Octets Symbolic Value Protocol field 1291 0x0101 1.1 version-number 1292 0x0000 successful-ok status-code 1293 0x00000001 1 request-id 1294 0x01 start operation-attributes operation-attributes-tag 1295 0x47 charset type value-tag 1296 0x0012 name-length 1297 attributes- attributes-charset name 1298 charset 1299 0x0008 value-length 1300 us-ascii US-ASCII value 1301 0x48 natural-language type value-tag 1302 0x001B name-length 1303 attributes- attributes-natural- name 1304 natural-language language 1305 0x0005 value-length 1306 en-us en-US value 1307 0x41 textWithoutLanguage type value-tag 1308 0x000E name-length 1309 status-message status-message name 1310 0x000D value-length 1311 successful-ok successful-ok value 1312 0x02 start job-attributes job-attributes-tag 1313 0x21 integer value-tag 1314 0x0006 name-length 1315 job-id job-id name 1316 0x0004 value-length 1317 147 147 value 1318 0x45 uri type value-tag 1319 0x0007 name-length 1320 job-uri job-uri name 1321 0x0019 value-length 1322 ipp://forest/pin job 123 on pinetree value 1323 etree/123 1324 0x23 enum type value-tag 1325 0x0009 name-length 1326 job-state job-state name 1327 0x0004 value-length 1328 0x0003 pending value 1329 0x03 end-of-attributes end-of-attributes-tag 1331 11.3 Print-Job Response (failure) 1333 Here is an example of an unsuccessful Print-Job response to the previous 1334 Print-Job request. It fails because, in this case, the printer does not 1335 support the "sides" attribute and because the value '20' for the 1336 "copies" attribute is not supported. Therefore, no job is created, and 1337 neither a "job-id" nor a "job-uri" operation attribute is returned. The 1338 error code returned is 'client-error-attributes-or-values-not-supported' 1339 (0x040B). 1341 Octets Symbolic Value Protocol field 1343 0x0101 1.1 version-number 1344 0x040B client-error-attributes-or- status-code 1345 values-not-supported 1346 0x00000001 1 request-id 1347 0x01 start operation-attributes operation-attribute tag 1348 0x47 charset type value-tag 1349 0x0012 name-length 1350 attributes- attributes-charset name 1351 charset 1352 0x0008 value-length 1353 us-ascii US-ASCII value 1354 0x48 natural-language type value-tag 1355 0x001B name-length 1356 attributes- attributes-natural-language name 1357 natural- 1358 language 1359 0x0005 value-length 1360 en-us en-US value 1361 0x41 textWithoutLanguage type value-tag 1362 0x000E name-length 1363 status- status-message name 1364 message 1365 0x002F value-length 1366 client-error- client-error-attributes-or- value 1367 attributes- values-not-supported 1368 or-values- 1369 not-supported 1370 0x05 start unsupported-attributes unsupported-attributes tag 1371 0x21 integer type value-tag 1372 0x0006 name-length 1373 copies copies name 1374 0x0004 value-length 1375 0x00000014 20 value 1376 0x10 unsupported (type) value-tag 1377 0x0005 name-length 1378 sides sides name 1379 0x0000 value-length 1380 0x03 end-of-attributes end-of-attributes-tag 1382 11.4 Print-Job Response (success with attributes ignored) 1384 Here is an example of a successful Print-Job response to a Print-Job 1385 request like the previous Print-Job request, except that the value of 1386 'ipp-attribute-fidelity' is false. The print request succeeds, even 1387 though, in this case, the printer supports neither the "sides" attribute 1388 nor the value '20' for the "copies" attribute. Therefore, a job is 1389 created, and both a "job-id" and a "job-uri" operation attribute are 1390 returned. The unsupported attributes are also returned in an Unsupported 1391 Attributes Group. The error code returned is 'successful-ok-ignored-or- 1392 substituted-attributes' (0x0001). 1394 Octets Symbolic Value Protocol field 1396 0x0101 1.1 version-number 1397 0x0001 successful-ok-ignored-or- status-code 1398 substituted-attributes 1399 0x00000001 1 request-id 1400 0x01 start operation-attributes operation-attributes-tag 1401 0x47 charset type value-tag 1402 0x0012 name-length 1403 attributes- attributes-charset name 1404 charset 1405 0x0008 value-length 1406 us-ascii US-ASCII value 1407 0x48 natural-language type value-tag 1408 0x001B name-length 1409 attributes- attributes-natural- name 1410 natural-language language 1411 0x0005 value-length 1412 en-us en-US value 1413 0x41 textWithoutLanguage type value-tag 1414 0x000E name-length 1415 status-message status-message name 1416 0x002F value-length 1417 successful-ok- successful-ok-ignored-or- value 1418 ignored-or- substituted-attributes 1419 substituted- 1420 attributes 1421 0x05 start unsupported- unsupported-attributes 1422 attributes tag 1423 0x21 integer type value-tag 1424 0x0006 name-length 1425 copies copies name 1426 0x0004 value-length 1427 0x00000014 20 value 1428 0x10 unsupported (type) value-tag 1429 0x0005 name-length 1430 sides sides name 1431 0x0000 value-length 1432 0x02 start job-attributes job-attributes-tag 1433 0x21 integer value-tag 1434 0x0006 name-length 1435 job-id job-id name 1436 0x0004 value-length 1437 147 147 value 1438 0x45 uri type value-tag 1439 0x0007 name-length 1440 job-uri job-uri name 1441 0x0019 value-length 1442 ipp://forest/pin job 123 on pinetree value 1443 etree/123 1444 Octets Symbolic Value Protocol field 1446 0x23 enum type value-tag 1447 0x0009 name-length 1448 job-state job-state name 1449 0x0004 value-length 1450 0x0003 pending value 1451 0x03 end-of-attributes end-of-attributes-tag 1453 11.5 Print-URI Request 1455 The following is an example of Print-URI request with copies and job- 1456 name parameters: 1458 Octets Symbolic Value Protocol field 1459 0x0101 1.1 version-number 1460 0x0003 Print-URI operation-id 1461 0x00000001 1 request-id 1462 0x01 start operation-attributes operation-attributes-tag 1463 0x47 charset type value-tag 1464 0x0012 name-length 1465 attributes- attributes-charset name 1466 charset 1467 0x0008 value-length 1468 us-ascii US-ASCII value 1469 0x48 natural-language type value-tag 1470 0x001B name-length 1471 attributes- attributes-natural-language name 1472 natural- 1473 language 1474 0x0005 value-length 1475 en-us en-US value 1476 0x45 uri type value-tag 1477 0x000B name-length 1478 printer-uri printer-uri name 1479 0x0015 value-length 1480 ipp://forest/ printer pinetree value 1481 pinetree 1482 0x45 uri type value-tag 1483 0x000C name-length 1484 document-uri document-uri name 1485 0x0011 value-length 1486 ftp://foo.com ftp://foo.com/foo value 1487 /foo 1488 0x42 nameWithoutLanguage type value-tag 1489 0x0008 name-length 1490 job-name job-name name 1491 0x0006 value-length 1492 foobar foobar value 1493 0x02 start job-attributes job-attributes-tag 1494 0x21 integer type value-tag 1495 0x0006 name-length 1496 Octets Symbolic Value Protocol field 1497 copies copies name 1498 0x0004 value-length 1499 0x00000001 1 value 1500 0x03 end-of-attributes end-of-attributes-tag 1502 11.6 Create-Job Request 1504 The following is an example of Create-Job request with no parameters and 1505 no attributes: 1507 Octets Symbolic Value Protocol field 1508 0x0101 1.1 version-number 1509 0x0005 Create-Job operation-id 1510 0x00000001 1 request-id 1511 0x01 start operation-attributes operation-attributes-tag 1512 0x47 charset type value-tag 1513 0x0012 name-length 1514 attributes- attributes-charset name 1515 charset 1516 0x0008 value-length 1517 us-ascii US-ASCII value 1518 0x48 natural-language type value-tag 1519 0x001B name-length 1520 attributes- attributes-natural-language name 1521 natural- 1522 language 1523 0x0005 value-length 1524 en-us en-US value 1525 0x45 uri type value-tag 1526 0x000B name-length 1527 printer-uri printer-uri name 1528 0x0015 value-length 1529 ipp://forest/p printer pinetree value 1530 inetree 1531 0x03 end-of-attributes end-of-attributes-tag 1533 11.7 Get-Jobs Request 1535 The following is an example of Get-Jobs request with parameters but no 1536 attributes: 1538 Octets Symbolic Value Protocol field 1539 0x0101 1.1 version-number 1540 0x000A Get-Jobs operation-id 1541 0x00000123 0x123 request-id 1542 0x01 start operation-attributes operation-attributes-tag 1543 0x47 charset type value-tag 1544 0x0012 name-length 1545 attributes- attributes-charset name 1546 charset 1547 0x0008 value-length 1548 us-ascii US-ASCII value 1549 0x48 natural-language type value-tag 1550 Octets Symbolic Value Protocol field 1551 0x001B name-length 1552 attributes- attributes-natural-language name 1553 natural- 1554 language 1555 0x0005 value-length 1556 en-us en-US value 1557 0x45 uri type value-tag 1558 0x000B name-length 1559 printer-uri printer-uri name 1560 0x0015 value-length 1561 ipp://forest/pi printer pinetree value 1562 netree 1563 0x21 integer type value-tag 1564 0x0005 name-length 1565 limit limit name 1566 0x0004 value-length 1567 0x00000032 50 value 1568 0x44 keyword type value-tag 1569 0x0014 name-length 1570 requested- requested-attributes name 1571 attributes 1572 0x0006 value-length 1573 job-id job-id value 1574 0x44 keyword type value-tag 1575 0x0000 additional value name-length 1576 0x0008 value-length 1577 job-name job-name value 1578 0x44 keyword type value-tag 1579 0x0000 additional value name-length 1580 0x000F value-length 1581 document-format document-format value 1582 0x03 end-of-attributes end-of-attributes-tag 1584 11.8 Get-Jobs Response 1586 The following is an of Get-Jobs response from previous request with 3 1587 jobs. The Printer returns no information about the second job (because 1588 of security reasons): 1590 Octets Symbolic Value Protocol field 1591 0x0101 1.1 version-number 1592 0x0000 successful-ok status-code 1593 0x00000123 0x123 request-id (echoed 1594 back) 1595 0x01 start operation-attributes operation-attribute-tag 1596 0x47 charset type value-tag 1597 0x0012 name-length 1598 attributes- attributes-charset name 1599 charset 1600 0x000A value-length 1601 ISO-8859-1 ISO-8859-1 value 1602 0x48 natural-language type value-tag 1603 0x001B name-length 1604 Octets Symbolic Value Protocol field 1605 attributes- attributes-natural-language name 1606 natural- 1607 language 1608 0x0005 value-length 1609 en-us en-US value 1610 0x41 textWithoutLanguage type value-tag 1611 0x000E name-length 1612 status-message status-message name 1613 0x000D value-length 1614 successful-ok successful-ok value 1615 0x02 start job-attributes (1st job-attributes-tag 1616 object) 1617 0x21 integer type value-tag 1618 0x0006 name-length 1619 job-id job-id name 1620 0x0004 value-length 1621 147 147 value 1622 0x36 nameWithLanguage value-tag 1623 0x0008 name-length 1624 job-name job-name name 1625 0x000C value-length 1626 0x0005 sub-value-length 1627 fr-ca fr-CA value 1628 0x0003 sub-value-length 1629 fou fou name 1630 0x02 start job-attributes (2nd job-attributes-tag 1631 object) 1632 0x02 start job-attributes (3rd job-attributes-tag 1633 object) 1634 0x21 integer type value-tag 1635 0x0006 name-length 1636 job-id job-id name 1637 0x0004 value-length 1638 148 149 value 1639 0x36 nameWithLanguage value-tag 1640 0x0008 name-length 1641 job-name job-name name 1642 0x0012 value-length 1643 0x0005 sub-value-length 1644 de-CH de-CH value 1645 0x0009 sub-value-length 1646 isch guet isch guet name 1647 0x03 end-of-attributes end-of-attributes-tag 1649 12. Appendix C: Registration of MIME Media Type Information for 1650 "application/ipp" 1652 This appendix contains the information that IANA requires for 1653 registering a MIME media type. The information following this paragraph 1654 will be forwarded to IANA to register application/ipp whose contents are 1655 defined in Section 3 "Encoding of the Operation Layer" in this 1656 document: 1658 MIME type name: application 1660 MIME subtype name: ipp 1662 A Content-Type of "application/ipp" indicates an Internet Printing 1663 Protocol message body (request or response). Currently there is one 1664 version: IPP/1.1, whose syntax is described in Section 3 "Encoding of 1665 the Operation Layer" of [ipp-pro], and whose semantics are described in 1666 [ipp-mod]. 1668 Required parameters: none 1670 Optional parameters: none 1672 Encoding considerations: 1674 IPP/1.1 protocol requests/responses MAY contain long lines and ALWAYS 1675 contain binary data (for example attribute value lengths). 1677 Security considerations: 1679 IPP/1.1 protocol requests/responses do not introduce any security risks 1680 not already inherent in the underlying transport protocols. Protocol 1681 mixed-version interworking rules in [ipp-mod] as well as protocol 1682 encoding rules in [ipp-pro] are complete and unambiguous. 1684 Interoperability considerations: 1686 IPP/1.1 requests (generated by clients) and responses (generated by 1687 servers) MUST comply with all conformance requirements imposed by the 1688 normative specifications [ipp-mod] and [ipp-pro]. Protocol encoding 1689 rules specified in [ipp-pro] are comprehensive, so that interoperability 1690 between conforming implementations is guaranteed (although support for 1691 specific optional features is not ensured). Both the "charset" and 1692 "natural-language" of all IPP/1.1 attribute values which are a 1693 LOCALIZED-STRING are explicit within IPP protocol requests/responses 1694 (without recourse to any external information in HTTP, SMTP, or other 1695 message transport headers). 1697 Published specification: 1699 [ipp-mod] Isaacson, S., deBry, R., Hastings, T., Herriot, R., 1700 Powell, P., "Internet Printing Protocol/1.1: Model and 1701 Semantics" draft-ietf-ipp-model-v11-00.txt, February, 1999. 1703 [ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., 1704 "Internet Printing Protocol/1.1: Encoding and Transport", draft- 1705 ietf-ipp-protocol-v11-00.txt, February, 1999. 1707 Applications which use this media type: 1709 Internet Printing Protocol (IPP) print clients and print servers, 1710 communicating using HTTP/1.1 (see [IPP-PRO]), SMTP/ESMTP, FTP, or other 1711 transport protocol. Messages of type "application/ipp" are self- 1712 contained and transport-independent, including "charset" and "natural- 1713 language" context for any LOCALIZED-STRING value. 1715 Person & email address to contact for further information: 1717 Tom Hastings 1718 Xerox Corporation 1719 737 Hawaii St. ESAE-231 1720 El Segundo, CA 1722 Phone: 310-333-6413 1723 Fax: 310-333-5514 1724 Email: thastings@cp10.es.xerox.com 1726 or 1728 Robert Herriot 1729 Xerox Corporation 1730 3400 Hillview Ave., Bldg #1 1731 Palo Alto, CA 94304 1733 Phone: 650-813-7696 1734 Fax: 650-813-6860 1735 Email: robert.herriot@pahv.xerox.com 1737 Intended usage: 1739 COMMON 1741 13. Appendix D: Changes from IPP /1.0 1743 IPP/1.1 is identical to IPP/1.0 with the follow changes: 1745 1.Attributes values that identify a printer or job object use a new 1746 'ipp' scheme. The 'http' and 'https' schemes are supported only for 1747 backward compatibility. See section 5. 1749 2.New requirement for support of Digest Authentication. See Section 1750 7.1 1752 3.TLS is recommended for channel security. In addition, SSL3 may be 1753 supported for backward compatibility. See Section 7.2 1755 14. Full Copyright Statement 1757 The IETF takes no position regarding the validity or scope of any 1758 intellectual property or other rights that might be claimed to pertain 1759 to the implementation or use of the technology described in this 1760 document or the extent to which any license under such rights might or 1761 might not be available; neither does it represent that it has made any 1762 effort to identify any such rights. Information on the IETF's 1763 procedures with respect to rights in standards-track and standards- 1764 related documentation can be found in BCP-11[BCP-11]. Copies of claims 1765 of rights made available for publication and any assurances of licenses 1766 to be made available, or the result of an attempt made to obtain a 1767 general license or permission for the use of such proprietary rights by 1768 implementers or users of this specification can be obtained from the 1769 IETF Secretariat. 1771 The IETF invites any interested party to bring to its attention any 1772 copyrights, patents or patent applications, or other proprietary rights 1773 which may cover technology that may be required to practice this 1774 standard. Please address the information to the IETF Executive 1775 Director. 1777 Copyright (C)The Internet Society (1999). All Rights Reserved 1779 This document and translations of it may be copied and furnished to 1780 others, and derivative works that comment on or otherwise explain it or 1781 assist in its implementation may be prepared, copied, published and 1782 distributed, in whole or in part, without restriction of any kind, 1783 provided that the above copyright notice and this paragraph are included 1784 on all such copies and derivative works. However, this document itself 1785 may not be modified in any way, such as by removing the copyright notice 1786 or references to the Internet Society or other Internet organizations, 1787 except as needed for the purpose of developing Internet standards in 1788 which case the procedures for copyrights defined in the Internet 1789 Standards process must be followed, or as required to translate it into 1790 languages other than English. 1792 The limited permissions granted above are perpetual and will not be 1793 revoked by the Internet Society or its successors or assigns. 1795 This document and the information contained herein is provided on an "AS 1796 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1797 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1798 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1799 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1800 FITNESS FOR A PARTICULAR PURPOSE.