idnits 2.17.1 draft-ietf-ipp-protocol-v11-02.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 39 longer pages, the longest (page 11) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 40 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 52 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([RFC2069], [RFC2568], [RFC2567]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 95 has weird spacing: '...ding of the O...' == Line 145 has weird spacing: '...ists of a mes...' == Line 158 has weird spacing: '...ding of the O...' == Line 167 has weird spacing: '...portant types...' == Line 168 has weird spacing: '...ch most other...' == (47 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 11, 1999) is 9085 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2026' is mentioned on line 22, but not defined == Missing Reference: 'IPP-MOD' is mentioned on line 1093, but not defined == Missing Reference: 'IPP-PRO' is mentioned on line 1755, but not defined == Unused Reference: 'RFC822' is defined on line 1119, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 1122, but no explicit reference was found in the text == Unused Reference: 'RFC1179' is defined on line 1125, but no explicit reference was found in the text == Unused Reference: 'RFC1543' is defined on line 1128, but no explicit reference was found in the text == Unused Reference: 'RFC1759' is defined on line 1134, but no explicit reference was found in the text == Unused Reference: 'RFC1766' is defined on line 1137, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 1147, but no explicit reference was found in the text == Unused Reference: 'RFC2048' is defined on line 1150, but no explicit reference was found in the text == Unused Reference: 'RFC2184' is defined on line 1163, but no explicit reference was found in the text == Unused Reference: 'RFC2569' is defined on line 1190, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 1179 ** Obsolete normative reference: RFC 1543 (Obsoleted by RFC 2223) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1759 (Obsoleted by RFC 3805) ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 1808 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 2069 (Obsoleted by RFC 2617) ** Obsolete normative reference: RFC 2184 (Obsoleted by RFC 2231) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2565 (Obsoleted by RFC 2910) ** Obsolete normative reference: RFC 2566 (Obsoleted by RFC 2911) ** Downref: Normative reference to an Experimental RFC: RFC 2567 ** Downref: Normative reference to an Experimental RFC: RFC 2568 ** Downref: Normative reference to an Experimental RFC: RFC 2569 Summary: 29 errors (**), 0 flaws (~~), 23 warnings (==), 2 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 June 11, 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. A few OPTIONAL operator operations have been added 69 to IPP/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 specification documents, and gives background and rationale for the IETF 75 working 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........................................................4 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..............................................11 105 3.8 Name-Length...................................................12 106 3.9 (Attribute) Name..............................................12 107 3.10Value Length..................................................14 108 3.11(Attribute) Value.............................................15 109 3.12Data..........................................................17 110 4. Encoding of Transport Layer........................................17 111 5. IPP URL Scheme.....................................................18 112 6. Security Considerations............................................19 113 6.1 Security Conformance Requirements.............................20 114 6.1.1 Digest Authentication...................................20 115 6.1.2 Transport Layer Security (TLS)..........................20 116 6.2 Using IPP with TLS............................................21 117 7. Interoperability with IPP/1.0 Implementations......................22 118 7.1 The "version-number" Parameter................................22 119 7.2 Security and URL Schemes......................................22 120 8. References.........................................................23 121 9. Author's Address...................................................25 122 10.Other Participants:...............................................25 123 11.Appendix A: Protocol Examples.....................................26 124 11.1Print-Job Request.............................................26 125 11.2Print-Job Response (successful)...............................27 126 11.3Print-Job Response (failure)..................................28 127 11.4Print-Job Response (success with attributes ignored)..........29 128 11.5Print-URI Request.............................................32 129 11.6Create-Job Request............................................33 130 11.7Get-Jobs Request..............................................34 131 11.8Get-Jobs Response.............................................35 132 12.Appendix C: Registration of MIME Media Type Information for 133 "application/ipp".....................................................37 134 13.Appendix D: Changes from IPP /1.0.................................38 135 14.Full Copyright Statement..........................................39 136 1. Introduction 138 This document contains the rules for encoding IPP operations and 139 describes two layers: the transport layer and the operation layer. 141 The transport layer consists of an HTTP/1.1 request or response. RFC 142 2068 [RFC2068] describes HTTP/1.1. This document specifies the HTTP 143 headers that an IPP implementation supports. 145 The operation layer consists of a message body in an HTTP request or 146 response. The document "Internet Printing Protocol/1.1: Model and 147 Semantics" [ipp-mod] defines the semantics of such a message body and 148 the supported values. This document specifies the encoding of an IPP 149 operation. The aforementioned document [ipp-mod] is henceforth referred 150 to as the "IPP model document" 152 2. Conformance Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 155 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 156 interpreted as described in RFC 2119 [RFC2119]. 158 3. Encoding of the Operation Layer 160 The operation layer MUST contain a single operation request or operation 161 response. Each request or response consists of a sequence of values and 162 attribute groups. Attribute groups consist of a sequence of attributes 163 each of which is a name and value. Names and values are ultimately 164 sequences of octets 166 The encoding consists of octets as the most primitive type. There are 167 several types built from octets, but three important types are 168 integers, character strings and octet strings, on which most other 169 data types are built. Every character string in this encoding MUST be a 170 sequence of characters where the characters are associated with some 171 charset and some natural language. A character string MUST be in 172 "reading order" with the first character in the value (according to 173 reading order) being the first character in the encoding. A character 174 string whose associated charset is US-ASCII whose associated natural 175 language is US English is henceforth called a US-ASCII-STRING. A 176 character string whose associated charset and natural language are 177 specified in a request or response as described in the model document is 178 henceforth called a LOCALIZED-STRING. An octet string MUST be in "IPP 179 model document order" with the first octet in the value (according to 180 the IPP model document order) being the first octet in the encoding 181 Every integer in this encoding MUST be encoded as a signed integer using 182 two's-complement binary encoding with big-endian format (also known as 183 "network order" and "most significant byte first"). The number of octets 184 for an integer MUST be 1, 2 or 4, depending on usage in the protocol. 185 Such one-octet integers, henceforth called SIGNED-BYTE, are used for the 186 version-number and tag fields. Such two-byte integers, henceforth called 187 SIGNED-SHORT are used for the operation-id, status-code and length 188 fields. Four byte integers, henceforth called SIGNED-INTEGER, are used 189 for values fields and the sequence number. 191 The following two sections present the operation layer in two ways 193 - informally through pictures and description 195 - formally through Augmented Backus-Naur Form (ABNF), as specified by 196 RFC 2234 [RFC2234] 198 3.1 Picture of the Encoding 200 The encoding for an operation request or response consists of: 202 ----------------------------------------------- 203 | version-number | 2 bytes - required 204 ----------------------------------------------- 205 | operation-id (request) | 206 | or | 2 bytes - required 207 | status-code (response) | 208 ----------------------------------------------- 209 | request-id | 4 bytes - required 210 ----------------------------------------------------------- 211 | xxx-attributes-tag | 1 byte | 212 ----------------------------------------------- |-0 or more 213 | xxx-attribute-sequence | n bytes | 214 ----------------------------------------------------------- 215 | end-of-attributes-tag | 1 byte - required 216 ----------------------------------------------- 217 | data | q bytes - optional 218 ----------------------------------------------- 220 The xxx-attributes-tag and xxx-attribute-sequence represents four 221 different values of "xxx", namely, operation, job, printer and 222 unsupported. The xxx-attributes-tag and an xxx-attribute-sequence 223 represent attribute groups in the model document. The xxx-attributes-tag 224 identifies the attribute group and the xxx-attribute-sequence contains 225 the attributes. 227 The expected sequence of xxx-attributes-tag and xxx-attribute-sequence 228 is specified in the IPP model document for each operation request and 229 operation response. 231 A request or response SHOULD contain each xxx-attributes-tag defined for 232 that request or response even if there are no attributes except for the 233 unsupported-attributes-tag which SHOULD be present only if the 234 unsupported-attribute-sequence is non-empty. A receiver of a request 235 MUST be able to process as equivalent empty attribute groups: 237 a) an xxx-attributes-tag with an empty xxx-attribute-sequence, 239 b) an expected but missing xxx-attributes-tag. 241 The data is omitted from some operations, but the end-of-attributes-tag 242 is present even when the data is omitted. Note, the xxx-attributes-tags 243 and end-of-attributes-tag are called 'delimiter-tags'. Note: the xxx- 244 attribute-sequence, shown above may consist of 0 bytes, according to the 245 rule below. 247 An xxx-attributes-sequence consists of zero or more compound-attributes. 249 ----------------------------------------------- 250 | compound-attribute | s bytes - 0 or more 251 ----------------------------------------------- 253 A compound-attribute consists of an attribute with a single value 254 followed by zero or more additional values. 256 Note: a 'compound-attribute' represents a single attribute in the model 257 document. The 'additional value' syntax is for attributes with 2 or 258 more values. 260 Each attribute consists of: 262 ----------------------------------------------- 263 | value-tag | 1 byte 264 ----------------------------------------------- 265 | name-length (value is u) | 2 bytes 266 ----------------------------------------------- 267 | name | u bytes 268 ----------------------------------------------- 269 | value-length (value is v) | 2 bytes 270 ----------------------------------------------- 271 | value | v bytes 272 ----------------------------------------------- 274 An additional value consists of: 276 ----------------------------------------------------------- 277 | value-tag | 1 byte | 278 ----------------------------------------------- | 279 | name-length (value is 0x0000) | 2 bytes | 280 ----------------------------------------------- |-0 or more 281 | value-length (value is w) | 2 bytes | 282 ----------------------------------------------- | 283 | value | w bytes | 284 ----------------------------------------------------------- 286 Note: an additional value is like an attribute whose name-length is 0. 288 >From the standpoint of a parsing loop, the encoding consists of: 290 ----------------------------------------------- 291 | version-number | 2 bytes - required 292 ----------------------------------------------- 293 | operation-id (request) | 294 | or | 2 bytes - required 295 | status-code (response) | 296 ----------------------------------------------- 297 | request-id | 4 bytes - required 298 ----------------------------------------------------------- 299 | tag (delimiter-tag or value-tag) | 1 byte | 300 ----------------------------------------------- |-0 or more 301 | empty or rest of attribute | x bytes | 302 ----------------------------------------------------------- 303 | end-of-attributes-tag | 2 bytes - required 304 ----------------------------------------------- 305 | data | y bytes - optional 306 ----------------------------------------------- 308 The value of the tag determines whether the bytes following the tag are: 310 - attributes 312 - data 314 - the remainder of a single attribute where the tag specifies the 315 type of the value. 317 3.2 Syntax of Encoding 319 The syntax below is ABNF [RFC2234] except 'strings of literals' MUST be 320 case sensitive. For example 'a' means lower case 'a' and not upper case 321 'A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields are represented 322 as '%x' values which show their range of values. 324 ipp-message = ipp-request / ipp-response 325 ipp-request = version-number operation-id request-id 326 *(xxx-attributes-tag xxx-attribute-sequence) end-of- 327 attributes-tag data 328 ipp-response = version-number status-code request-id 329 *(xxx-attributes-tag xxx-attribute-sequence) end-of- 330 attributes-tag data 331 xxx-attribute-sequence = *compound-attribute 333 xxx-attributes-tag = operation-attributes-tag / job-attributes-tag / 334 printer-attributes-tag / unsupported-attributes-tag 336 version-number = major-version-number minor-version-number 337 major-version-number = SIGNED-BYTE ; initially %d1 338 minor-version-number = SIGNED-BYTE ; initially %d0 340 operation-id = SIGNED-SHORT ; mapping from model defined below 341 status-code = SIGNED-SHORT ; mapping from model defined below 342 request-id = SIGNED-INTEGER ; whose value is > 0 344 compound-attribute = attribute *additional-values 346 attribute = value-tag name-length name value-length value 347 additional-values = value-tag zero-name-length value-length value 349 name-length = SIGNED-SHORT ; number of octets of 'name' 350 name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." ) 351 value-length = SIGNED-SHORT ; number of octets of 'value' 352 value = OCTET-STRING 354 data = OCTET-STRING 356 zero-name-length = %x00.00 ; name-length of 0 357 operation-attributes-tag = %x01 ; tag of 1 358 job-attributes-tag = %x02 ; tag of 2 359 printer-attributes-tag = %x04 ; tag of 4 360 unsupported- attributes-tag = %x05 ; tag of 5 361 end-of-attributes-tag = %x03 ; tag of 3 362 value-tag = %x10-FF 364 SIGNED-BYTE = BYTE 365 SIGNED-SHORT = 2BYTE 366 SIGNED-INTEGER = 4BYTE 367 DIGIT = %x30-39 ; "0" to "9" 368 LALPHA = %x61-7A ; "a" to "z" 369 BYTE = %x00-FF 370 OCTET-STRING = *BYTE 372 The syntax allows an xxx-attributes-tag to be present when the xxx- 373 attribute-sequence that follows is empty. The syntax is defined this way 374 to allow for the response of Get-Jobs where no attributes are returned 375 for some job-objects. Although it is RECOMMENDED that the sender not 376 send an xxx-attributes-tag if there are no attributes (except in the 377 Get-Jobs response just mentioned), the receiver MUST be able to decode 378 such syntax. 380 3.3 Version-number 382 The version-number MUST consist of a major and minor version-number, 383 each of which MUST be represented by a SIGNED-BYTE. The protocol 384 described in this document MUST have a major version-number of 1 (0x01) 385 and a minor version-number of 1 (0x01). The ABNF for these two bytes 386 MUST be %x01.01. 388 3.4 Operation-id 390 Operation-ids are defined as enums in the model document. An operation- 391 ids enum value MUST be encoded as a SIGNED-SHORT. 393 Note: the values 0x4000 to 0xFFFF are reserved for private extensions. 395 3.5 Status-code 397 Status-codes are defined as enums in the model document. A status-code 398 enum value MUST be encoded as a SIGNED-SHORT. 400 The status-code is an operation attribute in the model document. In the 401 protocol, the status-code is in a special position, outside of the 402 operation attributes. 404 If an IPP status-code is returned, then the HTTP Status-Code MUST be 200 405 (successful-ok). With any other HTTP Status-Code value, the HTTP 406 response MUST NOT contain an IPP message-body, and thus no IPP status- 407 code is returned. 409 3.6 Request-id 411 The request-id allows a client to match a response with a request. This 412 mechanism is unnecessary in HTTP, but may be useful when application/ipp 413 entity bodies are used in another context. 415 The request-id in a response MUST be the value of the request-id 416 received in the corresponding request. A client can set the request-id 417 in each request to a unique value or a constant value, such as 1, 418 depending on what the client does with the request-id returned in the 419 response. The value of the request-id MUST be greater than zero. 421 3.7 Tags 423 There are two kinds of tags: 425 - delimiter tags: delimit major sections of the protocol, namely 426 attributes and data 428 - value tags: specify the type of each attribute value 430 3.7.1 Delimiter Tags 432 The following table specifies the values for the delimiter tags: 434 Tag Value (Hex) Delimiter 436 0x00 reserved 437 0x01 operation-attributes-tag 438 0x02 job-attributes-tag 439 0x03 end-of-attributes-tag 440 0x04 printer-attributes-tag 441 0x05 unsupported-attributes-tag 442 0x06-0x0e reserved for future delimiters 443 0x0F reserved for future chunking-end-of-attributes- 444 tag 446 When an xxx-attributes-tag occurs in the protocol, it MUST mean that 447 zero or more following attributes up to the next delimiter tag are 448 attributes belonging to group xxx as defined in the model document, 449 where xxx is operation, job, printer, unsupported. 451 Doing substitution for xxx in the above paragraph, this means the 452 following. When an operation-attributes-tag occurs in the protocol, it 453 MUST mean that the zero or more following attributes up to the next 454 delimiter tag are operation attributes as defined in the model document. 455 When an job-attributes-tag occurs in the protocol, it MUST mean that the 456 zero or more following attributes up to the next delimiter tag are job 457 attributes or job template attributes as defined in the model document. 458 When a printer-attributes-tag occurs in the protocol, it MUST mean that 459 the zero or more following attributes up to the next delimiter tag are 460 printer attributes as defined in the model document. When an 461 unsupported-attributes-tag occurs in the protocol, it MUST mean that the 462 zero or more following attributes up to the next delimiter tag are 463 unsupported attributes as defined in the model document. 465 The operation-attributes-tag and end-of-attributes-tag MUST each occur 466 exactly once in an operation. The operation-attributes-tag MUST be the 467 first tag delimiter, and the end-of-attributes-tag MUST be the last tag 468 delimiter. If the operation has a document-content group, the document 469 data in that group MUST follow the end-of-attributes-tag. 471 Each of the other three xxx-attributes-tags defined above is OPTIONAL 472 in an operation and each MUST occur at most once in an operation, except 473 for job-attributes-tag in a Get-Jobs response which may occur zero or 474 more times. 476 The order and presence of delimiter tags for each operation request and 477 each operation response MUST be that defined in the model document. For 478 further details, see section 3.9 "(Attribute) Name" and section 0 " 480 Appendix A: Protocol Examples". 482 A Printer MUST treat the reserved delimiter tags differently from 483 reserved value tags so that the Printer knows that there is an entire 484 attribute group that it doesn't understand as opposed to a single value 485 that it doesn't understand. 487 3.7.2 Value Tags 489 The remaining tables show values for the value-tag, which is the first 490 octet of an attribute. The value-tag specifies the type of the value of 491 the attribute. The following table specifies the "out-of-band" values 492 for the value-tag. 494 Tag Value (Hex) Meaning 496 0x10 unsupported 497 0x11 reserved for future 'default' 498 0x12 unknown 499 0x13 no-value 500 0x14-0x1F reserved for future "out-of-band" values. 502 The "unsupported" value MUST be used in the attribute-sequence of an 503 error response for those attributes which the printer does not support. 504 The "default" value is reserved for future use of setting value back to 505 their default value. The "unknown" value is used for the value of a 506 supported attribute when its value is temporarily unknown. The "no- 507 value" value is used for a supported attribute to which no value has 508 been assigned, e.g. "job-k-octets-supported" has no value if an 509 implementation supports this attribute, but an administrator has not 510 configured the printer to have a limit. 512 The following table specifies the integer values for the value-tag: 514 Tag Value (Hex) Meaning 516 0x20 reserved 517 0x21 integer 518 0x22 boolean 519 0x23 enum 520 0x24-0x2F reserved for future integer types 522 NOTE: 0x20 is reserved for "generic integer" if it should ever be 523 needed. 525 The following table specifies the octetString values for the value-tag: 527 Tag Value (Hex) Meaning 529 0x30 octetString with an unspecified format 530 0x31 dateTime 531 0x32 resolution 532 0x33 rangeOfInteger 533 0x34 reserved for collection (in the future) 534 0x35 textWithLanguage 535 0x36 nameWithLanguage 536 0x37-0x3F reserved for future octetString types 538 The following table specifies the character-string values for the value- 539 tag: 541 Tag Value (Hex) Meaning 543 0x40 reserved 544 0x41 textWithoutLanguage 545 0x42 nameWithoutLanguage 546 0x43 reserved 547 0x44 keyword 548 0x45 uri 549 0x46 uriScheme 550 0x47 charset 551 0x48 naturalLanguage 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. 610 All Printer and Job objects are identified by a Uniform Resource 611 Identifier (URI) [RFC2396] so that they can be persistently and 612 unambiguously referenced. The notion of a URI is a useful concept, 613 however, until the notion of URI is more stable (i.e., defined more 614 completely and deployed more widely), it is expected that the URIs used 615 for IPP objects will actually be URLs [RFC1738] [RFC1808]. Since every 616 URL is a specialized form of a URI, even though the more generic term 617 URI is used throughout the rest of this document, its usage is intended 618 to cover the more specific notion of URL as well. 620 Some operation elements are encoded twice, once as the request-URI on 621 the HTTP Request-Line and a second time as a REQUIRED operation 622 attribute in the application/ipp entity. These attributes are the 623 target URI for the operation and are called printer-uri and job-uri. 624 Note: The target URI is included twice in an operation referencing the 625 same IPP object, but the two URIs NEED NOT be literally identical. One 626 can be a relative URI and the other can be an absolute URI. HTTP/1.1 627 allows clients to generate and send a relative URI rather than an 628 absolute URI. A relative URI identifies a resource with the scope of 629 the HTTP server, but does not include scheme, host or port. The 630 following statements characterize how URLs should be used in the mapping 631 of IPP onto HTTP/1.1: 633 1. Although potentially redundant, a client MUST supply the target of 634 the operation both as an operation attribute and as a URI at the 635 HTTP layer. The rationale for this decision is to maintain a 636 consistent set of rules for mapping application/ipp to possibly 637 many communication layers, even where URLs are not used as the 638 addressing mechanism in the transport layer. 639 2. Even though these two URLs might not be literally identical (one 640 being relative and the other being absolute), they MUST both 641 reference the same IPP object. 642 3. The URI in the HTTP layer is either relative or absolute and is 643 used by the HTTP server to route the HTTP request to the correct 644 resource relative to that HTTP server. The HTTP server need not be 645 aware of the URI within the operation request. 647 4. Once the HTTP server resource begins to process the HTTP request, 648 it might get the reference to the appropriate IPP Printer object 649 from either the HTTP URI (using to the context of the HTTP server 650 for relative URLs) or from the URI within the operation request; 651 the choice is up to the implementation. 652 5. HTTP URIs can be relative or absolute, but the target URI in the 653 operation MUST be an absolute URI. 655 The model document arranges the remaining attributes into groups for 656 each operation request and response. Each such group MUST be represented 657 in the protocol by an xxx-attribute-sequence preceded by the appropriate 658 xxx-attributes-tag (See the table below and section 0 " 660 Appendix A: Protocol Examples"). In addition, the order of these xxx- 661 attributes-tags and xxx-attribute-sequences in the protocol MUST be the 662 same as in the model document, but the order of attributes within each 663 xxx-attribute-sequence MUST be unspecified. The table below maps the 664 model document group name to xxx-attributes-sequence: 666 Model Document Group xxx-attributes-sequence 668 Operation Attributes operations-attributes-sequence 669 Job Template Attributes job-attributes-sequence 670 Job Object Attributes job-attributes-sequence 671 Unsupported Attributes unsupported- attributes-sequence 672 Requested Attributes (Get-Job- job-attributes-sequence 673 Attributes) 674 Requested Attributes (Get- printer-attributes-sequence 675 Printer-Attributes) 676 Document Content in a special position as described 677 above 679 If an operation contains attributes from more than one job object (e.g. 680 Get-Jobs response), the attributes from each job object MUST be in a 681 separate job-attribute-sequence, such that the attributes from the ith 682 job object are in the ith job-attribute-sequence. See Section 0 " 684 Appendix A: Protocol Examples" for table showing the application of the 685 rules above. 687 3.10 Value Length 689 Each attribute value MUST be preceded by a SIGNED-SHORT, which MUST 690 specify the number of octets in the value which follows this length, 691 exclusive of the two bytes specifying the length. 693 For any of the types represented by binary signed integers, the sender 694 MUST encode the value in exactly four octets. 696 For any of the types represented by character-strings, the sender MUST 697 encode the value with all the characters of the string and without any 698 padding characters. 700 If a value-tag contains an "out-of-band" value, such as "unsupported", 701 the value-length MUST be 0 and the value empty . the value has no 702 meaning when the value-tag has an "out-of-band" value. 704 3.11 (Attribute) Value 706 The syntax types and most of the details of their representation are 707 defined in the IPP model document. The table below augments the 708 information in the model document, and defines the syntax types from the 709 model document in terms of the 5 basic types defined in section 3 710 "Encoding of the Operation Layer". The 5 types are US-ASCII-STRING, 711 LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET- 712 STRING. 714 Syntax of Attribute Encoding 715 Value 717 textWithoutLanguage, LOCALIZED-STRING. 718 nameWithoutLanguage 720 textWithLanguage OCTET_STRING consisting of 4 fields: 721 a) a SIGNED-SHORT which is the number of octets 722 in the following field 723 b) a value of type natural-language, 724 c) a SIGNED-SHORT which is the number of octets 725 in the following field, 726 d) a value of type textWithoutLanguage. 728 The length of a textWithLanguage value MUST be 4 729 + the value of field a + the value of field c. 731 nameWithLanguage OCTET_STRING consisting of 4 fields: 732 a) a SIGNED-SHORT which is the number of octets 733 in the following field 734 b) a value of type natural-language, 735 c) a SIGNED-SHORT which is the number of octets 736 in the following field 737 d) a value of type nameWithoutLanguage. 739 The length of a nameWithLanguage value MUST be 4 740 + the value of field a + the value of field c. 742 charset, US-ASCII-STRING. 743 naturalLanguage, 744 mimeMediaType, 745 keyword, uri, and 746 uriScheme 748 boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is 749 'true'. 751 integer and enum a SIGNED-INTEGER. 753 dateTime OCTET-STRING consisting of eleven octets whose 754 contents are defined by "DateAndTime" in RFC 755 1903 [RFC1903]. 757 resolution OCTET_STRING consisting of nine octets of 2 758 SIGNED-INTEGERs followed by a SIGNED-BYTE. The 759 first SIGNED-INTEGER contains the value of cross 760 feed direction resolution. The second SIGNED- 761 INTEGER contains the value of feed direction 762 resolution. The SIGNED-BYTE contains the units 763 value. 765 rangeOfInteger Eight octets consisting of 2 SIGNED-INTEGERs. 766 The first SIGNED-INTEGER contains the lower 767 bound and the second SIGNED-INTEGER contains the 769 Syntax of Attribute Encoding 770 Value 772 upper bound. 774 1setOf X Encoding according to the rules for an attribute 775 with more than 1 value. Each value X is encoded 776 according to the rules for encoding its type. 778 octetString OCTET-STRING 780 The type of the value in the model document determines the encoding in 781 the value and the value of the value-tag. 783 3.12 Data 785 The data part MUST include any data required by the operation 787 4. Encoding of Transport Layer 789 HTTP/1.1 [RFC2068] is the transport layer for this protocol. 791 The operation layer has been designed with the assumption that the 792 transport layer contains the following information: 794 - the URI of the target job or printer operation 796 - the total length of the data in the operation layer, either as a 797 single length or as a sequence of chunks each with a length. 799 It is REQUIRED that a printer implementation support HTTP over the IANA 800 assigned Well Known Port 631 (the IPP default port), though a printer 801 implementation may support HTTP over some other port as well. 803 Each HTTP operation MUST use the POST method where the request-URI is 804 the object target of the operation, and where the "Content-Type" of the 805 message-body in each request and response MUST be "application/ipp". The 806 message-body MUST contain the operation layer and MUST have the syntax 807 described in section 3.2 "Syntax of Encoding". A client implementation 808 MUST adhere to the rules for a client described for HTTP1.1 [RFC2068] . 809 A printer (server) implementation MUST adhere the rules for an origin 810 server described for HTTP1.1 [RFC2068]. 812 An IPP server sends a response for each request that it receives. If an 813 IPP server detects an error, it MAY send a response before it has read 814 the entire request. If the HTTP layer of the IPP server completes 815 processing the HTTP headers successfully, it MAY send an intermediate 816 response, such as "100 Continue", with no IPP data before sending the 817 IPP response. A client MUST expect such a variety of responses from an 818 IPP server. For further information on HTTP/1.1, consult the HTTP 819 documents [RFC2068]. 821 An HTTP server MUST support chunking for IPP requests, and an IPP client 822 MUST support chunking for IPP responses according to HTTP/1.1[RFC2068]. 823 Note: this rule causes a conflict with non-compliant implementations of 824 HTTP/1.1 that don't support chunking for POST methods, and this rule may 825 cause a conflict with non-compliant implementations of HTTP/1.1 that 826 don't support chunking for CGI scripts 828 5. IPP URL Scheme 830 The IPP/1.1 document defines a new scheme 'ipp' as the value of a URL 831 that identifies either an IPP printer object or an IPP job object. The 832 IPP attributes using the 'ipp' scheme are specified below. Because the 833 HTTP layer does not support the 'ipp' scheme, a client MUST map 'ipp' 834 URLs to 'http' URLs, and then follows the HTTP [RFC2068][RFC2069] rules 835 for constructing a Request-Line and HTTP headers. The mapping is simple 836 because the 'ipp' scheme implies all of the same protocol semantics as 837 that of the 'http' scheme [RFC2068], except that it represents a print 838 service and the implicit (default) port number that clients use to 839 connect to a server is port 631. 841 In the remainder of this section the term 'ipp-URL' means a URL whose 842 scheme is 'ipp' and whose implicit (default) port is 631. The term 843 'http-URL' means a URL whose scheme is 'http', and the term 'https-URL' 844 means a URL whose scheme is 'https', 846 A client and an IPP object (i.e. the server) MUST support the ipp-URL 847 value in the following IPP attributes. 848 job attributes: 849 job-uri 850 job-printer-uri 851 printer attributes: 852 printer-uri-supported 853 operation attributes: 854 job-uri 855 printer-uri 857 Each of the above attributes identifies a printer or job object. The 858 ipp-URL is intended as the value of the attributes in this list, and for 859 no other attributes. All of these attributes have a syntax type of 860 'uri', but there are attributes with a syntax type of 'uri' that do not 861 use the 'ipp' scheme, e.g. 'job-more-info'. 863 If a printer registers its URL with a directory service, the printer 864 MUST register an ipp-URL. 866 User interfaces are beyond the scope of this document. But if software 867 exposes the ipp-URL values of any of the above five attributes to a 868 human user, it is REQUIRED that the human see the ipp-URL as is. 870 When a client sends a request, it MUST convert a target ipp-URL to a 871 target http-URL for the HTTP layer according to the following rules: 872 1. change the 'ipp' scheme to 'http' 873 2. add an explicit port 631 if the URL does not contain an explicit 874 port. Note: port 631 is the IANA assigned Well Known Port for the 875 'ipp' scheme. 877 The client MUST use the target http-URL in both the HTTP Request-Line 878 and HTTP headers, as specified by HTTP[RFC2068][RFC2069] . However, the 879 client MUST use the target ipp-URL for the value of the "printer-uri" or 880 "job-uri" operation attribute within the application/ipp body of the 881 request. The server MUST use the ipp-URL for the value of the "printer- 882 uri", "job-uri" or "printer-uri-supported" attributes within the 883 application/ipp body of the response. 885 For example, when an IPP client sends a request directly (i.e. no proxy) 886 to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a TCP 887 connection to port 631 (the ipp implicit port) on the host "myhost.com" 888 and sends the following data: 890 POST /myprinter/myqueue HTTP/1.1 891 Host: myhost.com:631 892 Content-type: application/ipp 893 Transfer-Encoding: chunked 894 ... 895 "printer-uri" "ipp://myhost.com/myprinter/myqueue" 896 (encoded in application/ipp message body) 897 ... 899 As another example, when an IPP client sends the same request as above 900 via a proxy "myproxy.com", it opens a TCP connection to the proxy port 901 8080 on the proxy host "myproxy.com" and sends the following data: 903 POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 904 Host: myhost.com:631 905 Content-type: application/ipp 906 Transfer-Encoding: chunked 907 ... 908 "printer-uri" "ipp://myhost.com/myprinter/myqueue" 909 (encoded in application/ipp message body) 910 ... 912 The proxy then connects to the IPP origin server with headers that are 913 the same as the "no-proxy" example above. 915 6. Security Considerations 917 The IPP Model and Semantics document [ipp-mod] discusses high level 918 security requirements (Client Authentication, Server Authentication and 919 Operation Privacy). Client Authentication is the mechanism by which the 920 client proves its identity to the server in a secure manner. Server 921 Authentication is the mechanism by which the server proves its identity 922 to the client in a secure manner. Operation Privacy is defined as a 923 mechanism for protecting operations from eavesdropping. 925 6.1 Security Conformance Requirements 927 This section defines the security requirements for IPP clients and IPP 928 objects. 930 6.1.1 Digest Authentication 932 IPP clients MUST support: 934 Digest Authentication [RFC2069]. 936 MD5 and MD5-sess MUST be implemented and supported. 938 The Message Integrity feature NEED NOT be used. 940 IPP Printers SHOULD support: 942 Digest Authentication [RFC2069]. 944 MD5 and MD5-sess MUST be implemented and supported. 946 The Message Integrity feature NEED NOT be used. 948 The reasons that IPP Printers SHOULD (rather than MUST) support Digest 949 Authentication are: 951 1.While Client Authentication is important, there is a certain class of 952 printer devices where it does not make sense. Specifically, a low- 953 end device with limited ROM space and low paper throughput may not 954 need Client Authentication. This class of device typically requires 955 firmware designers to make trade-offs between protocols and 956 functionality to arrive at the lowest-cost solution possible. 957 Factored into the designer.s decisions is not just the size of the 958 code, but also the testing, maintenance, usefulness, and time-to- 959 market impact for each feature delivered to the customer. Forcing 960 such low-end devices to provide security in order to claim IPP/1.1 961 conformance would not make business sense and could potentially stall 962 the adoption of the standard. 964 2.Print devices that have high-volume throughput and have available ROM 965 space have a compelling argument to provide support for Client 966 Authentication that safeguards the device from unauthorized access. 967 These devices are prone to a high loss of consumables and paper if 968 unauthorized access should occur. 970 6.1.2 Transport Layer Security (TLS) 972 IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246] for 973 Server Authentication and Operation Privacy. IPP Printers MAY also 974 support TLS for Client Authentication. If an IPP Printer supports TLS, 975 it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as 976 mandated by RFC 2246 [RFC2246]. All other cipher suites are OPTIONAL. 977 An IPP Printer MAY support Basic Authentication (described in HTTP/1.1 978 [RFC2068]) for Client Authentication if the channel is secure. TLS with 979 the above mandated cipher suite can provide such a secure channel. 981 If a IPP client supports TLS, it MUST support the 982 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246 983 [RFC2246]. All other cipher suites are OPTIONAL. 985 The IPP Model and Semantics document defines two printer attributes 986 ("uri-authentication-supported" and "uri-security-supported") that the 987 client can use to discover the security policy of a printer. That 988 document also outlines IPP-specific security considerations and should 989 be the primary reference for security implications with regard to the 990 IPP protocol itself. For backward compatibility with IPP version 1.0, 991 IPP clients and printers MAY also support SSL3. This is in addition to 992 the security required in this document. 994 6.2 Using IPP with TLS 996 An initial IPP request never uses TLS. The switch to TLS occurs either 997 because the server grants the client's request to upgrade to TLS, or a 998 server asks to switch to TLS in its response. Secure communication 999 begins with a server's response to switch to TLS. The initial connection 1000 is not secure. Any client expecting a secure connection should first use 1001 a non-sensitive operation (e.g. an HTTP POST with an empty message body) 1002 to establish a secure connection before sending any sensitive data. 1003 During the TLS handshake, the original session is preserved. 1005 An IPP client that wants a secure connection MUST send "TLS/1.0" as one 1006 of the field-values of the HTTP/1.1 Upgrade request header, e.g. 1007 "Upgrade: TLS/1.0" (see rfc2068 section 14.42). If the origin-server 1008 grants the upgrade request, it MUST respond with "101 Switching 1009 Protocols", and it MUST include the header "Upgrade: TLS/1.0" to 1010 indicate what it is switching to. An IPP client MUST be ready to react 1011 appropriately if the server does not grant the upgrade request. Note: 1012 the 'Upgrade header' mechanism allows unsecured and secured traffic to 1013 share the same port (in this case, 631). 1015 With current technology, an IPP server can indicate that it wants an 1016 upgrade only by returning "401 unauthorized" or "403 forbidden". A 1017 server MAY give the client an additional hint by including an "Upgrade: 1018 TLS" header in the response. When an IPP client receives such a 1019 response, it can perform the request again with an Upgrade header with 1020 the "TLS/1.0" value. 1022 If a server supports TLS, it SHOULD include the "Upgrade" header with 1023 the value "TLS/1.0" in response to any OPTIONS request. 1025 Upgrade is a hop-by-hop header (rfc2068, section 13.5.1), so each 1026 intervening proxy which supports TLS MUST also request the same version 1027 of TLS/1.0 on its subsequent request. Furthermore, any caching proxy 1028 which supports TLS MUST NOT reply from its cache when TLS/1.0 has been 1029 requested (although clients are still recommended to explicitly include 1030 "Cache-control: no-cache"). 1032 Note: proxy servers may be able to request or initiate a TLS-secured 1033 connection, e.g. the outgoing or incoming firewall of a trusted 1034 subnetwork. 1036 7. Interoperability with IPP/1.0 Implementations 1038 For interoperability with IPP/1.0 servers, IPP/1.1 clients SHOULD also 1039 meet the conformance requirements for clients as specified in [RFC2566] 1040 and [RFC2565]. 1042 For interoperability with IPP/1.0 clients, IPP/1.1 objects SHOULD also 1043 meet the conformance requirements for IPP objects as specified in 1044 [RFC2565] and [RFC2566]. 1046 7.1 The "version-number" Parameter 1048 The following are rules regarding the "version-number" parameter (see 1049 section 3.3): 1051 1. Clients MUST send requests containing a "version-number" parameter 1052 with a '1.1' value and SHOULD try supplying alternate version 1053 numbers if they receive a 'server-error-version-not-supported' 1054 error return in a response. 1056 2. IPP objects MUST accept requests containing a "version-number" 1057 parameter with a '1.1' value (or reject the request for reasons 1058 other than 'server-error-version-not-supported'). 1060 3. IPP objects SHOULD accept any request with the major version '1' 1061 (or reject the request for reasons other than 'server-error- 1062 version-not-supported'). See [ipp-mod] "versions" sub-section. 1064 4. In any case, security MUST NOT be compromised when a client 1065 supplies a lower "version-number" parameter in a request. For 1066 example, if an IPP/1.1 conforming Printer object accepts version 1067 '1.0' requests and is configured to enforce Digest Authentication, 1068 it MUST do the same for a version '1.0' request. 1070 7.2 Security and URL Schemes 1072 The following are rules regarding security, the "version-number" 1073 parameter, and the URL scheme supplied in target attributes and 1074 responses: 1076 1. When a client supplies a request, the "printer-uri" or "job-uri" 1077 target operation attribute MUST have the same scheme as that 1078 indicated in one of the values of the "printer-uri-supported" 1079 Printer attribute. 1081 2. When the server returns the "job-printer-uri" or "job-uri" Job 1082 Description attributes, it SHOULD return the same scheme ('ipp', 1083 'https', 'http', etc.) that the client supplied in the "printer- 1084 uri" or "job-uri" target operation attributes in the Get-Job- 1085 Attributes or Get-Jobs request, rather than the scheme used when 1086 the job was created. However, when a client requests job 1087 attributes using the Get-Job-Attributes or Get-Jobs operations, the 1088 jobs and job attributes that the server returns depends on: (1) the 1089 security in effect when the job was created, (2) the security in 1090 effect in the query request, and (3) the security policy in force. 1092 3. If a server registers a non-secure ipp-URL with a directory service 1093 (see [IPP-MOD] "Generic Directory Schema" Appendix), then it SHOULD 1094 also register an http-URL for interoperability with IPP/1.0 clients 1095 (see section 7). 1097 4. In any case, security MUST NOT be compromised when a client 1098 supplies an 'http' or other non-secure URL scheme in the target 1099 "printer-uri" and "job-uri" operation attributes in a request. 1101 8. References 1103 [dpa] ISO/IEC 10175 Document Printing Application (DPA), June 1996. 1105 [iana]IANA Registry of Coded Character Sets: ftp://ftp.isi.edu/in- 1106 notes/iana/assignments/character-sets. 1108 [ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.1: 1109 Implementer's Guide", work in progress. 1111 [ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1112 "Internet Printing Protocol/1.0: Model and Semantics", , June, 1999. 1115 [ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet 1116 Printing Protocol/1.1: Encoding and Transport", draft-ietf-ipp- 1117 protocol-v11-02-.txt, June 1999. 1119 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text 1120 Messages", RFC 822, August 1982. 1122 [RFC1123] Braden, S., "Requirements for Internet Hosts - Application 1123 and Support", RFC 1123, October, 1989. 1125 [RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" 1126 RFC 1179, August 1990. 1128 [RFC1543] Postel, J., "Instructions to RFC Authors", RFC 1543, October 1129 1993. 1131 [RFC1738] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform 1132 Resource Locators (URL)", RFC 1738, December, 1994. 1134 [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and 1135 Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. 1137 [RFC1766] H. Alvestrand, " Tags for the Identification of Languages", 1138 RFC 1766, March 1995. 1140 [RFC1808] R. Fielding, "Relative Uniform Resource Locators", RFC1808, 1141 June 1995. 1143 [RFC1903] J. Case, et al. "Textual Conventions for Version 2 of the 1144 Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1145 1996. 1147 [RFC2046] N. Freed & N. Borenstein, Multipurpose Internet Mail 1148 Extensions (MIME) Part Two: Media Types. November 1996, RFC 2046. 1150 [RFC2048] N. Freed, J. Klensin & J. Postel. Multipurpose Internet Mail 1151 Extension (MIME) Part Four: Registration Procedures. November 1152 1996 (Also BCP0013), RFC 2048. 1154 [RFC2068] R Fielding, et al, "Hypertext Transfer Protocol . HTTP/1.1" 1155 RFC 2068, January 1997. 1157 [RFC2069] J. Franks, et al, "An Extension to HTTP: Digest Access 1158 Authentication" RFC 2069, January 1997. 1160 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1161 Requirement Levels", RFC 2119 , March 1997. 1163 [RFC2184] N. Freed, K. Moore, "MIME Parameter Value and Encoded Word 1164 Extensions: Character Sets, Languages, and Continuations", RFC 1165 2184, August 1997. 1167 [RFC2234] D. Crocker et al., "Augmented BNF for Syntax Specifications: 1168 ABNF", RFC 2234. November 1997. 1170 [RFC2246] T. Dierks et al., "The TLS Protocol", RFC 2246. January 1999. 1172 [RFC2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform 1173 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1174 1998. 1176 [RFC2565] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet 1177 Printing Protocol/1.0: Encoding and Transport", rfc 2565, April 1178 1999. 1180 [RFC2566] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1181 "Internet Printing Protocol/1.0: Model and Semantics", rfc 2566, 1182 April, 1999. 1184 [RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", 1185 RFC2567, April 1999. 1187 [RFC2568] Zilles, S., "Rationale for the Structure and Model and 1188 Protocol for the Internet Printing Protocol", RC 2568,April 1999. 1190 [RFC2569] Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping 1191 between LPD and IPP Protocols RFC 2569, April 1999. 1193 9. Author's Address 1195 Robert Herriot (editor) Paul Moore 1196 Xerox Corporation Microsoft 1197 3400 Hillview Ave., Bldg #1 One Microsoft Way 1198 Palo Alto, CA 94304 Redmond, WA 98053 1200 Phone: 650-813-7696 Phone: 425-936-0908 1201 Fax: 650-813-6860 Fax: 425-93MS-FAX 1202 Email: Email: paulmo@microsoft.com 1203 robert.herriot@pahv.xerox.com 1205 Sylvan Butler Randy Turner 1206 Hewlett-Packard 2Wire, Inc. 1207 11311 Chinden Blvd. 694 Tasman Dr. 1208 Boise, ID 83714 Milpitas, CA 95035 1210 Phone: 208-396-6000 Phone: 408-546-1273 1211 Fax: 208-396-3457 1212 Email: sbutler@boi.hp.com 1214 John Wenn 1215 Xerox Corporation 1216 737 Hawaii St 1217 El Segundo, CA 90245 1219 IPP Mailing List: ipp@pwg.org Phone: 310-333-5764 1220 IPP Mailing List Subscription: Fax: 310-333-5514 1221 ipp-request@pwg.org 1222 IPP Web Page: Email: jwenn@cp10.es.xerox.com 1223 http://www.pwg.org/ipp/ 1225 10. Other Participants: 1227 Chuck Adams - Tektronix Shivaun Albright - HP 1228 Jeff Barnett - IBM Ron Bergman - Dataproducts 1229 Keith Carter - IBM Angelo Caruso - Xerox 1230 Rajesh Chawla - TR Computing Josh Cohen - Microsoft 1231 Solutions 1232 Jeff Copeland - QMS Andy Davidson - Tektronix 1233 Roger deBry - IBM Mabry Dozier - QMS 1234 Lee Farrell - Canon Steve Gebert - IBM 1235 Sue Gleeson - Digital Charles Gordon - Osicom 1236 Brian Grimshaw - Apple Jerry Hadsell - IBM 1237 Richard Hart - Digital Tom Hastings - Xerox 1238 Stephen Holmstead Zhi-Hong Huang - Zenographics 1239 Scott Isaacson - Novell Babek Jahromi - Microsoft 1240 Swen Johnson - Xerox David Kellerman - Northlake 1241 Software 1242 Robert Kline - TrueSpectra Carl Kugler - IBM 1243 Dave Kuntz - Hewlett-Packard Takami Kurono - Brother 1244 Rick Landau - Digital Scott Lawrence - Agranot Systems 1245 Greg LeClair - Epson Harry Lewis - IBM 1246 Tony Liao - Vivid Image Roy Lomicka - Digital 1247 Pete Loya - HP Ray Lutz - Cognisys 1248 Mike MacKay - Novell, Inc. David Manchala - Xerox 1249 Carl-Uno Manros - Xerox Jay Martin - Underscore 1250 Larry Masinter - Xerox Stan McConnell - Xerox 1251 Ira McDonald - High North Inc. Peter Michalek - Shinesoft 1252 Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh 1253 Pat Nogay - IBM Ron Norton - Printronics 1254 Bob Pentecost - Hewlett-Packard Patrick Powell - Astart 1255 Technologies 1256 Jeff Rackowitz - Intermec Rob Rhoads - Intel 1257 Xavier Riley - Xerox Gary Roberts - Ricoh 1258 David Roach - Unisys Stuart Rowley - Kyocera 1259 Richard Schneider - Epson Kris Schoff - HP 1260 Bob Setterbo - Adobe Devon Taylor - Novell, Inc. 1261 Mike Timperman - Lexmark Shigern Ueda - Canon 1262 Bob Von Andel - Allegro Software William Wagner - Osicom 1263 Jim Walker - DAZEL Chris Wellens - Interworking Labs 1264 Rob Whittle - Novell, Inc. Jasper Wong - Xionics 1265 Don Wright - Lexmark Rick Yardumian - Xerox 1266 Lloyd Young - Lexmark Atsushi Yuki - Kyocera 1267 Peter Zehler - Xerox Frank Zhao - Panasonic 1268 Steve Zilles - Adobe 1270 11. Appendix A: Protocol Examples 1272 11.1 Print-Job Request 1274 The following is an example of a Print-Job request with job-name, 1275 copies, and sides specified. The "ipp-attribute-fidelity" attribute is 1276 set to 'true' so that the print request will fail if the "copies" or the 1277 "sides" attribute are not supported or their values are not supported. 1279 Octets Symbolic Value Protocol field 1281 0x0101 1.1 version-number 1282 0x0002 Print-Job operation-id 1283 0x00000001 1 request-id 1284 0x01 start operation-attributes operation-attributes-tag 1285 0x47 charset type value-tag 1286 0x0012 name-length 1287 attributes- attributes-charset name 1288 charset 1289 0x0008 value-length 1290 us-ascii US-ASCII value 1291 0x48 natural-language type value-tag 1292 0x001B name-length 1293 attributes- attributes-natural-language name 1294 natural- 1295 language 1296 0x0005 value-length 1297 en-us en-US value 1298 0x45 uri type value-tag 1299 0x000B name-length 1300 printer-uri printer-uri name 1301 0x0015 value-length 1302 ipp://forest/p printer pinetree value 1303 inetree 1304 0x42 nameWithoutLanguage type value-tag 1305 0x0008 name-length 1306 job-name job-name name 1307 0x0006 value-length 1308 foobar foobar value 1309 0x22 boolean type value-tag 1310 0x0016 name-length 1311 ipp-attribute- ipp-attribute-fidelity name 1312 fidelity 1313 0x0001 value-length 1314 0x01 true value 1315 0x02 start job-attributes job-attributes-tag 1316 0x21 integer type value-tag 1317 0x0006 name-length 1318 copies copies name 1319 0x0004 value-length 1320 0x00000014 20 value 1321 0x44 keyword type value-tag 1322 0x0005 name-length 1323 sides sides name 1324 0x0013 value-length 1325 two-sided- two-sided-long-edge value 1326 long-edge 1327 0x03 end-of-attributes end-of-attributes-tag 1328 %!PS... data 1330 11.2 Print-Job Response (successful) 1331 Here is an example of a successful Print-Job response to the previous 1332 Print-Job request. The printer supported the "copies" and "sides" 1333 attributes and their supplied values. The status code returned is 1334 'successful-ok'. 1336 Octets Symbolic Value Protocol field 1338 0x0101 1.1 version-number 1339 0x0000 successful-ok status-code 1340 0x00000001 1 request-id 1341 0x01 start operation-attributes operation-attributes-tag 1342 0x47 charset type value-tag 1343 0x0012 name-length 1344 attributes- attributes-charset name 1345 charset 1346 0x0008 value-length 1347 us-ascii US-ASCII value 1348 0x48 natural-language type value-tag 1349 0x001B name-length 1350 attributes- attributes-natural- name 1351 natural-language language 1352 0x0005 value-length 1353 en-us en-US value 1354 0x41 textWithoutLanguage type value-tag 1355 0x000E name-length 1356 status-message status-message name 1357 0x000D value-length 1358 successful-ok successful-ok value 1359 0x02 start job-attributes job-attributes-tag 1360 0x21 integer value-tag 1361 0x0006 name-length 1362 job-id job-id name 1363 0x0004 value-length 1364 147 147 value 1365 0x45 uri type value-tag 1366 0x0007 name-length 1367 job-uri job-uri name 1368 0x0019 value-length 1369 ipp://forest/pin job 123 on pinetree value 1370 etree/123 1371 0x23 enum type value-tag 1372 0x0009 name-length 1373 job-state job-state name 1374 0x0004 value-length 1375 0x0003 pending value 1376 0x03 end-of-attributes end-of-attributes-tag 1378 11.3 Print-Job Response (failure) 1380 Here is an example of an unsuccessful Print-Job response to the previous 1381 Print-Job request. It fails because, in this case, the printer does not 1382 support the "sides" attribute and because the value '20' for the 1383 "copies" attribute is not supported. Therefore, no job is created, and 1384 neither a "job-id" nor a "job-uri" operation attribute is returned. The 1385 error code returned is 'client-error-attributes-or-values-not-supported' 1386 (0x040B). 1388 Octets Symbolic Value Protocol field 1390 0x0101 1.1 version-number 1391 0x040B client-error-attributes-or- status-code 1392 values-not-supported 1393 0x00000001 1 request-id 1394 0x01 start operation-attributes operation-attribute tag 1395 0x47 charset type value-tag 1396 0x0012 name-length 1397 attributes- attributes-charset name 1398 charset 1399 0x0008 value-length 1400 us-ascii US-ASCII value 1401 0x48 natural-language type value-tag 1402 0x001B name-length 1403 attributes- attributes-natural-language name 1404 natural- 1405 language 1406 0x0005 value-length 1407 en-us en-US value 1408 0x41 textWithoutLanguage type value-tag 1409 0x000E name-length 1410 status- status-message name 1411 message 1412 0x002F value-length 1413 client-error- client-error-attributes-or- value 1414 attributes- values-not-supported 1415 or-values- 1416 not-supported 1417 0x05 start unsupported-attributes unsupported-attributes tag 1418 0x21 integer type value-tag 1419 0x0006 name-length 1420 copies copies name 1421 0x0004 value-length 1422 0x00000014 20 value 1423 0x10 unsupported (type) value-tag 1424 0x0005 name-length 1425 sides sides name 1426 0x0000 value-length 1427 0x03 end-of-attributes end-of-attributes-tag 1429 11.4 Print-Job Response (success with attributes ignored) 1431 Here is an example of a successful Print-Job response to a Print-Job 1432 request like the previous Print-Job request, except that the value of 1433 'ipp-attribute-fidelity' is false. The print request succeeds, even 1434 though, in this case, the printer supports neither the "sides" attribute 1435 nor the value '20' for the "copies" attribute. Therefore, a job is 1436 created, and both a "job-id" and a "job-uri" operation attribute are 1437 returned. The unsupported attributes are also returned in an Unsupported 1438 Attributes Group. The error code returned is 'successful-ok-ignored-or- 1439 substituted-attributes' (0x0001). 1441 Octets Symbolic Value Protocol field 1443 0x0101 1.1 version-number 1444 0x0001 successful-ok-ignored-or- status-code 1445 substituted-attributes 1446 0x00000001 1 request-id 1447 0x01 start operation-attributes operation-attributes-tag 1448 0x47 charset type value-tag 1449 0x0012 name-length 1450 attributes- attributes-charset name 1451 charset 1452 0x0008 value-length 1453 us-ascii US-ASCII value 1454 0x48 natural-language type value-tag 1455 0x001B name-length 1456 attributes- attributes-natural- name 1457 natural-language language 1458 0x0005 value-length 1459 en-us en-US value 1460 0x41 textWithoutLanguage type value-tag 1461 0x000E name-length 1462 status-message status-message name 1463 0x002F value-length 1464 successful-ok- successful-ok-ignored-or- value 1465 ignored-or- substituted-attributes 1466 substituted- 1467 attributes 1468 0x05 start unsupported- unsupported-attributes 1469 attributes tag 1470 0x21 integer type value-tag 1471 0x0006 name-length 1472 copies copies name 1473 0x0004 value-length 1474 0x00000014 20 value 1475 0x10 unsupported (type) value-tag 1476 0x0005 name-length 1477 sides sides name 1478 0x0000 value-length 1479 0x02 start job-attributes job-attributes-tag 1480 0x21 integer value-tag 1481 0x0006 name-length 1482 job-id job-id name 1483 0x0004 value-length 1484 147 147 value 1485 0x45 uri type value-tag 1486 0x0007 name-length 1487 job-uri job-uri name 1488 0x0019 value-length 1489 ipp://forest/pin job 123 on pinetree value 1490 etree/123 1491 0x23 enum type value-tag 1492 0x0009 name-length 1493 job-state job-state name 1494 0x0004 value-length 1495 Octets Symbolic Value Protocol field 1497 0x0003 pending value 1498 0x03 end-of-attributes end-of-attributes-tag 1500 11.5 Print-URI Request 1502 The following is an example of Print-URI request with copies and job- 1503 name parameters: 1505 Octets Symbolic Value Protocol field 1506 0x0101 1.1 version-number 1507 0x0003 Print-URI operation-id 1508 0x00000001 1 request-id 1509 0x01 start operation-attributes operation-attributes-tag 1510 0x47 charset type value-tag 1511 0x0012 name-length 1512 attributes- attributes-charset name 1513 charset 1514 0x0008 value-length 1515 us-ascii US-ASCII value 1516 0x48 natural-language type value-tag 1517 0x001B name-length 1518 attributes- attributes-natural-language name 1519 natural- 1520 language 1521 0x0005 value-length 1522 en-us en-US value 1523 0x45 uri type value-tag 1524 0x000B name-length 1525 printer-uri printer-uri name 1526 0x0015 value-length 1527 ipp://forest/ printer pinetree value 1528 pinetree 1529 0x45 uri type value-tag 1530 0x000C name-length 1531 document-uri document-uri name 1532 0x0011 value-length 1533 ftp://foo.com ftp://foo.com/foo value 1534 /foo 1535 0x42 nameWithoutLanguage type value-tag 1536 0x0008 name-length 1537 job-name job-name name 1538 0x0006 value-length 1539 foobar foobar value 1540 0x02 start job-attributes job-attributes-tag 1541 0x21 integer type value-tag 1542 0x0006 name-length 1543 copies copies name 1544 0x0004 value-length 1545 0x00000001 1 value 1546 0x03 end-of-attributes end-of-attributes-tag 1548 11.6 Create-Job Request 1550 The following is an example of Create-Job request with no parameters and 1551 no attributes: 1553 Octets Symbolic Value Protocol field 1554 0x0101 1.1 version-number 1555 0x0005 Create-Job operation-id 1556 0x00000001 1 request-id 1557 0x01 start operation-attributes operation-attributes-tag 1558 0x47 charset type value-tag 1559 0x0012 name-length 1560 attributes- attributes-charset name 1561 charset 1562 0x0008 value-length 1563 us-ascii US-ASCII value 1564 0x48 natural-language type value-tag 1565 0x001B name-length 1566 attributes- attributes-natural-language name 1567 natural- 1568 language 1569 0x0005 value-length 1570 en-us en-US value 1571 0x45 uri type value-tag 1572 0x000B name-length 1573 printer-uri printer-uri name 1574 0x0015 value-length 1575 ipp://forest/p printer pinetree value 1576 inetree 1577 0x03 end-of-attributes end-of-attributes-tag 1579 11.7 Get-Jobs Request 1581 The following is an example of Get-Jobs request with parameters but no 1582 attributes: 1584 Octets Symbolic Value Protocol field 1585 0x0101 1.1 version-number 1586 0x000A Get-Jobs operation-id 1587 0x00000123 0x123 request-id 1588 0x01 start operation-attributes operation-attributes-tag 1589 0x47 charset type value-tag 1590 0x0012 name-length 1591 attributes- attributes-charset name 1592 charset 1593 0x0008 value-length 1594 us-ascii US-ASCII value 1595 0x48 natural-language type value-tag 1596 0x001B name-length 1597 attributes- attributes-natural-language name 1598 natural- 1599 language 1600 0x0005 value-length 1601 en-us en-US value 1602 0x45 uri type value-tag 1603 0x000B name-length 1604 printer-uri printer-uri name 1605 0x0015 value-length 1606 ipp://forest/pi printer pinetree value 1607 netree 1608 0x21 integer type value-tag 1609 0x0005 name-length 1610 limit limit name 1611 0x0004 value-length 1612 0x00000032 50 value 1613 0x44 keyword type value-tag 1614 0x0014 name-length 1615 requested- requested-attributes name 1616 attributes 1617 0x0006 value-length 1618 job-id job-id value 1619 0x44 keyword type value-tag 1620 0x0000 additional value name-length 1621 0x0008 value-length 1622 job-name job-name value 1623 0x44 keyword type value-tag 1624 0x0000 additional value name-length 1625 0x000F value-length 1626 document-format document-format value 1627 0x03 end-of-attributes end-of-attributes-tag 1629 11.8 Get-Jobs Response 1631 The following is an of Get-Jobs response from previous request with 3 1632 jobs. The Printer returns no information about the second job (because 1633 of security reasons): 1635 Octets Symbolic Value Protocol field 1636 0x0101 1.1 version-number 1637 0x0000 successful-ok status-code 1638 0x00000123 0x123 request-id (echoed 1639 back) 1640 0x01 start operation-attributes operation-attribute-tag 1641 0x47 charset type value-tag 1642 0x0012 name-length 1643 attributes- attributes-charset name 1644 charset 1645 0x000A value-length 1646 ISO-8859-1 ISO-8859-1 value 1647 0x48 natural-language type value-tag 1648 0x001B name-length 1649 attributes- attributes-natural-language name 1650 natural- 1651 language 1652 0x0005 value-length 1653 en-us en-US value 1654 0x41 textWithoutLanguage type value-tag 1655 0x000E name-length 1656 status-message status-message name 1657 0x000D value-length 1658 successful-ok successful-ok value 1659 0x02 start job-attributes (1st job-attributes-tag 1660 object) 1661 0x21 integer type value-tag 1662 0x0006 name-length 1663 job-id job-id name 1664 0x0004 value-length 1665 147 147 value 1666 0x36 nameWithLanguage value-tag 1667 0x0008 name-length 1668 job-name job-name name 1669 0x000C value-length 1670 0x0005 sub-value-length 1671 fr-ca fr-CA value 1672 0x0003 sub-value-length 1673 fou fou name 1674 0x02 start job-attributes (2nd job-attributes-tag 1675 object) 1676 0x02 start job-attributes (3rd job-attributes-tag 1677 object) 1678 0x21 integer type value-tag 1679 0x0006 name-length 1680 job-id job-id name 1681 0x0004 value-length 1682 148 149 value 1683 0x36 nameWithLanguage value-tag 1684 0x0008 name-length 1685 job-name job-name name 1686 0x0012 value-length 1687 0x0005 sub-value-length 1688 de-CH de-CH value 1689 Octets Symbolic Value Protocol field 1690 0x0009 sub-value-length 1691 isch guet isch guet name 1692 0x03 end-of-attributes end-of-attributes-tag 1694 12. Appendix C: Registration of MIME Media Type Information for 1695 "application/ipp" 1697 This appendix contains the information that IANA requires for 1698 registering a MIME media type. The information following this paragraph 1699 will be forwarded to IANA to register application/ipp whose contents are 1700 defined in Section 3 "Encoding of the Operation Layer" in this 1701 document: 1703 MIME type name: application 1705 MIME subtype name: ipp 1707 A Content-Type of "application/ipp" indicates an Internet Printing 1708 Protocol message body (request or response). Currently there is one 1709 version: IPP/1.1, whose syntax is described in Section 3 "Encoding of 1710 the Operation Layer" of [ipp-pro], and whose semantics are described in 1711 [ipp-mod]. 1713 Required parameters: none 1715 Optional parameters: none 1717 Encoding considerations: 1719 IPP/1.1 protocol requests/responses MAY contain long lines and ALWAYS 1720 contain binary data (for example attribute value lengths). 1722 Security considerations: 1724 IPP/1.1 protocol requests/responses do not introduce any security risks 1725 not already inherent in the underlying transport protocols. Protocol 1726 mixed-version interworking rules in [ipp-mod] as well as protocol 1727 encoding rules in [ipp-pro] are complete and unambiguous. 1729 Interoperability considerations: 1731 IPP/1.1 requests (generated by clients) and responses (generated by 1732 servers) MUST comply with all conformance requirements imposed by the 1733 normative specifications [ipp-mod] and [ipp-pro]. Protocol encoding 1734 rules specified in [ipp-pro] are comprehensive, so that interoperability 1735 between conforming implementations is guaranteed (although support for 1736 specific optional features is not ensured). Both the "charset" and 1737 "natural-language" of all IPP/1.1 attribute values which are a 1738 LOCALIZED-STRING are explicit within IPP protocol requests/responses 1739 (without recourse to any external information in HTTP, SMTP, or other 1740 message transport headers). 1742 Published specifications: 1744 [ipp-mod] Isaacson, S., deBry, R., Hastings, T., Herriot, R., 1745 Powell, P., "Internet Printing Protocol/1.1: Model and 1746 Semantics" draft-ietf-ipp-model-v11-03.txt, June, 1999. 1748 [ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., 1749 "Internet Printing Protocol/1.1: Encoding and Transport", draft- 1750 ietf-ipp-protocol-v11-02.txt, June, 1999. 1752 Applications which use this media type: 1754 Internet Printing Protocol (IPP) print clients and print servers, 1755 communicating using HTTP/1.1 (see [IPP-PRO]), SMTP/ESMTP, FTP, or other 1756 transport protocol. Messages of type "application/ipp" are self- 1757 contained and transport-independent, including "charset" and "natural- 1758 language" context for any LOCALIZED-STRING value. 1760 Person & email address to contact for further information: 1762 Tom Hastings 1763 Xerox Corporation 1764 737 Hawaii St. ESAE-231 1765 El Segundo, CA 1767 Phone: 310-333-6413 1768 Fax: 310-333-5514 1769 Email: thastings@cp10.es.xerox.com 1771 or 1773 Robert Herriot 1774 Xerox Corporation 1775 3400 Hillview Ave., Bldg #1 1776 Palo Alto, CA 94304 1778 Phone: 650-813-7696 1779 Fax: 650-813-6860 1780 Email: robert.herriot@pahv.xerox.com 1782 Intended usage: 1784 COMMON 1786 13. Appendix D: Changes from IPP/1.0 1788 IPP/1.1 is identical to IPP/1.0 [RFC2565] with the follow changes: 1790 1.Attributes values that identify a printer or job object use a new 1791 'ipp' scheme. The 'http' and 'https' schemes are supported only for 1792 backward compatibility. See section 5. 1794 2.Clients MUST support of Digest Authentication, IPP Printers SHOULD 1795 support Digest Authentication. See Section 6.1.1 1797 3.TLS is recommended for channel security. In addition, SSL3 may be 1798 supported for backward compatibility. See Section 6.1.2 1800 4.For interoperability with IPP/1.0, IPP/1.1 Clients SHOULD support 1801 IPP/1.0 conformance requirements. IPP/1.1 Printers SHOULD support 1802 IPP/1.0 conformance requirements. See section 7.1. 1804 5.IPP/1.1 objects SHOULD accept any request with major version number 1805 '1'. See section 7.1. 1807 6.IPP objects SHOULD return the URL scheme requested for "job-printer- 1808 uri" and "job-uri" Job Attributes, rather than the URL scheme used to 1809 create the job. See section 7.2 1811 14. Full Copyright Statement 1813 The IETF takes no position regarding the validity or scope of any 1814 intellectual property or other rights that might be claimed to pertain 1815 to the implementation or use of the technology described in this 1816 document or the extent to which any license under such rights might or 1817 might not be available; neither does it represent that it has made any 1818 effort to identify any such rights. Information on the IETF's 1819 procedures with respect to rights in standards-track and standards- 1820 related documentation can be found in BCP-11[BCP-11]. Copies of claims 1821 of rights made available for publication and any assurances of licenses 1822 to be made available, or the result of an attempt made to obtain a 1823 general license or permission for the use of such proprietary rights by 1824 implementers or users of this specification can be obtained from the 1825 IETF Secretariat. 1827 The IETF invites any interested party to bring to its attention any 1828 copyrights, patents or patent applications, or other proprietary rights 1829 which may cover technology that may be required to practice this 1830 standard. Please address the information to the IETF Executive 1831 Director. 1833 Copyright (C)The Internet Society (1999). All Rights Reserved 1835 This document and translations of it may be copied and furnished to 1836 others, and derivative works that comment on or otherwise explain it or 1837 assist in its implementation may be prepared, copied, published and 1838 distributed, in whole or in part, without restriction of any kind, 1839 provided that the above copyright notice and this paragraph are included 1840 on all such copies and derivative works. However, this document itself 1841 may not be modified in any way, such as by removing the copyright notice 1842 or references to the Internet Society or other Internet organizations, 1843 except as needed for the purpose of developing Internet standards in 1844 which case the procedures for copyrights defined in the Internet 1845 Standards process must be followed, or as required to translate it into 1846 languages other than English. 1848 The limited permissions granted above are perpetual and will not be 1849 revoked by the Internet Society or its successors or assigns. 1851 This document and the information contained herein is provided on an "AS 1852 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1853 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1854 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1855 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1856 FITNESS FOR A PARTICULAR PURPOSE.