idnits 2.17.1 draft-ietf-ipp-protocol-v11-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of 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 ([RFC2568], [RFC2569], [RFC2567]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 94 has weird spacing: '...ding of the O...' == Line 144 has weird spacing: '...ists of a mes...' == Line 157 has weird spacing: '...ding of the O...' == Line 166 has weird spacing: '...portant types...' == Line 167 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 23, 1999) is 9068 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: 'RFC2616' is mentioned on line 874, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Missing Reference: 'RFC2617' is mentioned on line 974, but not defined ** Obsolete undefined reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) == Missing Reference: 'IPP-MOD' is mentioned on line 1065, but not defined == Missing Reference: 'IPP-PRO' is mentioned on line 1731, but not defined == Unused Reference: 'RFC822' is defined on line 1094, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 1097, but no explicit reference was found in the text == Unused Reference: 'RFC1179' is defined on line 1100, but no explicit reference was found in the text == Unused Reference: 'RFC1543' is defined on line 1103, but no explicit reference was found in the text == Unused Reference: 'RFC1759' is defined on line 1109, but no explicit reference was found in the text == Unused Reference: 'RFC1766' is defined on line 1112, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 1122, but no explicit reference was found in the text == Unused Reference: 'RFC2048' is defined on line 1125, but no explicit reference was found in the text == Unused Reference: 'RFC2184' is defined on line 1132, but no explicit reference was found in the text == Unused Reference: 'RFC2566' is defined on line 1149, but no explicit reference was found in the text == Unused Reference: 'RFC2068' is defined on line 1162, but no explicit reference was found in the text == Unused Reference: 'RFC2069' is defined on line 1166, 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 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 ** Obsolete normative reference: RFC 2616 (ref. 'RFC2068') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (ref. 'RFC2069') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 31 errors (**), 0 flaws (~~), 27 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 23, 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. 50 The full set of IPP documents includes: 52 Design Goals for an Internet Printing Protocol [RFC2567] 53 Rationale for the Structure and Model and Protocol for the Internet 54 Printing Protocol [RFC2568] 55 Internet Printing Protocol/1.1: Model and Semantics [ipp-mod] 56 Internet Printing Protocol/1.1: Encoding and Transport (this 57 document) 58 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 59 Mapping between LPD and IPP Protocols [RFC2569] 61 The document, "Design Goals for an Internet Printing Protocol", takes a 62 broad look at distributed printing functionality, and it enumerates 63 real-life scenarios that help to clarify the features that need to be 64 included in a printing protocol for the Internet. It identifies 65 requirements for three types of users: end users, operators, and 66 administrators. It calls out a subset of end user requirements that are 67 satisfied in IPP/1.1. A few OPTIONAL operator operations have been added 68 to IPP/1.1. 70 The document, "Rationale for the Structure and Model and Protocol for 71 the Internet Printing Protocol", describes IPP from a high level view, 72 defines a roadmap for the various documents that form the suite of IPP 73 specification documents, and gives background and rationale for the IETF 74 working group's major decisions. 76 The document, "Internet Printing Protocol/1.1: Model and Semantics", 77 describes a simplified model with abstract objects, their attributes, 78 and their operations that are independent of encoding and transport. It 79 introduces a Printer and a Job object. The Job object optionally 80 supports multiple documents per Job. It also addresses security, 81 internationalization, and directory issues. 83 The document "Internet Printing Protocol/1.1: Implementer's Guide", 84 gives advice to implementers of IPP clients and IPP objects. 86 The document "Mapping between LPD and IPP Protocols" gives some advice 87 to implementers of gateways between IPP and LPD (Line Printer Daemon) 88 implementations. 90 Table of Contents 92 1. Introduction........................................................4 93 2. Conformance Terminology.............................................4 94 3. Encoding of the Operation Layer....................................4 95 3.1 Picture of the Encoding........................................5 96 3.2 Syntax of Encoding.............................................7 97 3.3 Version-number.................................................8 98 3.4 Operation-id...................................................8 99 3.5 Status-code....................................................9 100 3.6 Request-id.....................................................9 101 3.7 Tags...........................................................9 102 3.7.1 Delimiter Tags...........................................9 103 3.7.2 Value Tags..............................................11 104 3.8 Name-Length...................................................12 105 3.9 (Attribute) Name..............................................12 106 3.10Value Length..................................................14 107 3.11(Attribute) Value.............................................15 108 3.12Data..........................................................17 109 4. Encoding of Transport Layer........................................17 110 5. IPP URL Scheme.....................................................18 111 6. Security Considerations............................................19 112 6.1 Security Conformance Requirements.............................20 113 6.1.1 Digest Authentication...................................20 114 6.1.2 Transport Layer Security (TLS)..........................20 115 6.2 Using IPP with TLS............................................21 116 7. Interoperability with IPP/1.0 Implementations......................21 117 7.1 The "version-number" Parameter................................21 118 7.2 Security and URL Schemes......................................22 119 8. References.........................................................23 120 9. Author's Address...................................................24 121 10.Other Participants:...............................................25 122 11.Appendix A: Protocol Examples.....................................26 123 11.1Print-Job Request.............................................26 124 11.2Print-Job Response (successful)...............................27 125 11.3Print-Job Response (failure)..................................28 126 11.4Print-Job Response (success with attributes ignored)..........29 127 11.5Print-URI Request.............................................32 128 11.6Create-Job Request............................................33 129 11.7Get-Jobs Request..............................................34 130 11.8Get-Jobs Response.............................................35 131 12.Appendix C: Registration of MIME Media Type Information for 132 "application/ipp".....................................................37 133 13.Appendix D: Changes from IPP /1.0.................................38 134 14.Full Copyright Statement..........................................39 135 1. Introduction 137 This document contains the rules for encoding IPP operations and 138 describes two layers: the transport layer and the operation layer. 140 The transport layer consists of an HTTP/1.1 request or response. RFC 141 2616 [RFC2616] describes HTTP/1.1. This document specifies the HTTP 142 headers that an IPP implementation supports. 144 The operation layer consists of a message body in an HTTP request or 145 response. The document "Internet Printing Protocol/1.1: Model and 146 Semantics" [ipp-mod] defines the semantics of such a message body and 147 the supported values. This document specifies the encoding of an IPP 148 operation. The aforementioned document [ipp-mod] is henceforth referred 149 to as the "IPP model document" 151 2. Conformance Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 154 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 155 interpreted as described in RFC 2119 [RFC2119]. 157 3. Encoding of the Operation Layer 159 The operation layer MUST contain a single operation request or operation 160 response. Each request or response consists of a sequence of values and 161 attribute groups. Attribute groups consist of a sequence of attributes 162 each of which is a name and value. Names and values are ultimately 163 sequences of octets 165 The encoding consists of octets as the most primitive type. There are 166 several types built from octets, but three important types are 167 integers, character strings and octet strings, on which most other 168 data types are built. Every character string in this encoding MUST be a 169 sequence of characters where the characters are associated with some 170 charset and some natural language. A character string MUST be in 171 "reading order" with the first character in the value (according to 172 reading order) being the first character in the encoding. A character 173 string whose associated charset is US-ASCII whose associated natural 174 language is US English is henceforth called a US-ASCII-STRING. A 175 character string whose associated charset and natural language are 176 specified in a request or response as described in the model document is 177 henceforth called a LOCALIZED-STRING. An octet string MUST be in "IPP 178 model document order" with the first octet in the value (according to 179 the IPP model document order) being the first octet in the encoding 180 Every integer in this encoding MUST be encoded as a signed integer using 181 two's-complement binary encoding with big-endian format (also known as 182 "network order" and "most significant byte first"). The number of octets 183 for an integer MUST be 1, 2 or 4, depending on usage in the protocol. 184 Such one-octet integers, henceforth called SIGNED-BYTE, are used for the 185 version-number and tag fields. Such two-byte integers, henceforth called 186 SIGNED-SHORT are used for the operation-id, status-code and length 187 fields. Four byte integers, henceforth called SIGNED-INTEGER, are used 188 for values fields and the sequence number. 190 The following two sections present the operation layer in two ways 192 - informally through pictures and description 194 - formally through Augmented Backus-Naur Form (ABNF), as specified by 195 RFC 2234 [RFC2234] 197 3.1 Picture of the Encoding 199 The encoding for an operation request or response consists of: 201 ----------------------------------------------- 202 | version-number | 2 bytes - required 203 ----------------------------------------------- 204 | operation-id (request) | 205 | or | 2 bytes - required 206 | status-code (response) | 207 ----------------------------------------------- 208 | request-id | 4 bytes - required 209 ----------------------------------------------------------- 210 | xxx-attributes-tag | 1 byte | 211 ----------------------------------------------- |-0 or more 212 | xxx-attribute-sequence | n bytes | 213 ----------------------------------------------------------- 214 | end-of-attributes-tag | 1 byte - required 215 ----------------------------------------------- 216 | data | q bytes - optional 217 ----------------------------------------------- 219 The xxx-attributes-tag and xxx-attribute-sequence represents four 220 different values of "xxx", namely, operation, job, printer and 221 unsupported. The xxx-attributes-tag and an xxx-attribute-sequence 222 represent attribute groups in the model document. The xxx-attributes-tag 223 identifies the attribute group and the xxx-attribute-sequence contains 224 the attributes. 226 The expected sequence of xxx-attributes-tag and xxx-attribute-sequence 227 is specified in the IPP model document for each operation request and 228 operation response. 230 A request or response SHOULD contain each xxx-attributes-tag defined for 231 that request or response even if there are no attributes except for the 232 unsupported-attributes-tag which SHOULD be present only if the 233 unsupported-attribute-sequence is non-empty. A receiver of a request 234 MUST be able to process as equivalent empty attribute groups: 236 a) an xxx-attributes-tag with an empty xxx-attribute-sequence, 238 b) an expected but missing xxx-attributes-tag. 240 The data is omitted from some operations, but the end-of-attributes-tag 241 is present even when the data is omitted. Note, the xxx-attributes-tags 242 and end-of-attributes-tag are called 'delimiter-tags'. Note: the xxx- 243 attribute-sequence, shown above may consist of 0 bytes, according to the 244 rule below. 246 An xxx-attributes-sequence consists of zero or more compound-attributes. 248 ----------------------------------------------- 249 | compound-attribute | s bytes - 0 or more 250 ----------------------------------------------- 252 A compound-attribute consists of an attribute with a single value 253 followed by zero or more additional values. 255 Note: a 'compound-attribute' represents a single attribute in the model 256 document. The 'additional value' syntax is for attributes with 2 or 257 more values. 259 Each attribute consists of: 261 ----------------------------------------------- 262 | value-tag | 1 byte 263 ----------------------------------------------- 264 | name-length (value is u) | 2 bytes 265 ----------------------------------------------- 266 | name | u bytes 267 ----------------------------------------------- 268 | value-length (value is v) | 2 bytes 269 ----------------------------------------------- 270 | value | v bytes 271 ----------------------------------------------- 273 An additional value consists of: 275 ----------------------------------------------------------- 276 | value-tag | 1 byte | 277 ----------------------------------------------- | 278 | name-length (value is 0x0000) | 2 bytes | 279 ----------------------------------------------- |-0 or more 280 | value-length (value is w) | 2 bytes | 281 ----------------------------------------------- | 282 | value | w bytes | 283 ----------------------------------------------------------- 285 Note: an additional value is like an attribute whose name-length is 0. 287 >From the standpoint of a parsing loop, the encoding consists of: 289 ----------------------------------------------- 290 | version-number | 2 bytes - required 291 ----------------------------------------------- 292 | operation-id (request) | 293 | or | 2 bytes - required 294 | status-code (response) | 295 ----------------------------------------------- 296 | request-id | 4 bytes - required 297 ----------------------------------------------------------- 298 | tag (delimiter-tag or value-tag) | 1 byte | 299 ----------------------------------------------- |-0 or more 300 | empty or rest of attribute | x bytes | 301 ----------------------------------------------------------- 302 | end-of-attributes-tag | 2 bytes - required 303 ----------------------------------------------- 304 | data | y bytes - optional 305 ----------------------------------------------- 307 The value of the tag determines whether the bytes following the tag are: 309 - attributes 311 - data 313 - the remainder of a single attribute where the tag specifies the 314 type of the value. 316 3.2 Syntax of Encoding 318 The syntax below is ABNF [RFC2234] except 'strings of literals' MUST be 319 case sensitive. For example 'a' means lower case 'a' and not upper case 320 'A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields are represented 321 as '%x' values which show their range of values. 323 ipp-message = ipp-request / ipp-response 324 ipp-request = version-number operation-id request-id 325 *(xxx-attributes-tag xxx-attribute-sequence) end-of- 326 attributes-tag data 327 ipp-response = version-number status-code request-id 328 *(xxx-attributes-tag xxx-attribute-sequence) end-of- 329 attributes-tag data 330 xxx-attribute-sequence = *compound-attribute 332 xxx-attributes-tag = operation-attributes-tag / job-attributes-tag / 333 printer-attributes-tag / unsupported-attributes-tag 335 version-number = major-version-number minor-version-number 336 major-version-number = SIGNED-BYTE ; initially %d1 337 minor-version-number = SIGNED-BYTE ; initially %d0 339 operation-id = SIGNED-SHORT ; mapping from model defined below 340 status-code = SIGNED-SHORT ; mapping from model defined below 341 request-id = SIGNED-INTEGER ; whose value is > 0 343 compound-attribute = attribute *additional-values 345 attribute = value-tag name-length name value-length value 346 additional-values = value-tag zero-name-length value-length value 348 name-length = SIGNED-SHORT ; number of octets of 'name' 349 name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." ) 350 value-length = SIGNED-SHORT ; number of octets of 'value' 351 value = OCTET-STRING 353 data = OCTET-STRING 355 zero-name-length = %x00.00 ; name-length of 0 356 operation-attributes-tag = %x01 ; tag of 1 357 job-attributes-tag = %x02 ; tag of 2 358 printer-attributes-tag = %x04 ; tag of 4 359 unsupported- attributes-tag = %x05 ; tag of 5 360 end-of-attributes-tag = %x03 ; tag of 3 361 value-tag = %x10-FF 363 SIGNED-BYTE = BYTE 364 SIGNED-SHORT = 2BYTE 365 SIGNED-INTEGER = 4BYTE 366 DIGIT = %x30-39 ; "0" to "9" 367 LALPHA = %x61-7A ; "a" to "z" 368 BYTE = %x00-FF 369 OCTET-STRING = *BYTE 371 The syntax allows an xxx-attributes-tag to be present when the xxx- 372 attribute-sequence that follows is empty. The syntax is defined this way 373 to allow for the response of Get-Jobs where no attributes are returned 374 for some job-objects. Although it is RECOMMENDED that the sender not 375 send an xxx-attributes-tag if there are no attributes (except in the 376 Get-Jobs response just mentioned), the receiver MUST be able to decode 377 such syntax. 379 3.3 Version-number 381 The version-number MUST consist of a major and minor version-number, 382 each of which MUST be represented by a SIGNED-BYTE. The protocol 383 described in this document MUST have a major version-number of 1 (0x01) 384 and a minor version-number of 1 (0x01). The ABNF for these two bytes 385 MUST be %x01.01. 387 3.4 Operation-id 389 Operation-ids are defined as enums in the model document. An operation- 390 ids enum value MUST be encoded as a SIGNED-SHORT. 392 Note: the values 0x4000 to 0xFFFF are reserved for private extensions. 394 3.5 Status-code 396 Status-codes are defined as enums in the model document. A status-code 397 enum value MUST be encoded as a SIGNED-SHORT. 399 The status-code is an operation attribute in the model document. In the 400 protocol, the status-code is in a special position, outside of the 401 operation attributes. 403 If an IPP status-code is returned, then the HTTP Status-Code MUST be 200 404 (successful-ok). With any other HTTP Status-Code value, the HTTP 405 response MUST NOT contain an IPP message-body, and thus no IPP status- 406 code is returned. 408 3.6 Request-id 410 The request-id allows a client to match a response with a request. This 411 mechanism is unnecessary in HTTP, but may be useful when application/ipp 412 entity bodies are used in another context. 414 The request-id in a response MUST be the value of the request-id 415 received in the corresponding request. A client can set the request-id 416 in each request to a unique value or a constant value, such as 1, 417 depending on what the client does with the request-id returned in the 418 response. The value of the request-id MUST be greater than zero. 420 3.7 Tags 422 There are two kinds of tags: 424 - delimiter tags: delimit major sections of the protocol, namely 425 attributes and data 427 - value tags: specify the type of each attribute value 429 3.7.1 Delimiter Tags 431 The following table specifies the values for the delimiter tags: 433 Tag Value (Hex) Delimiter 435 0x00 reserved 436 0x01 operation-attributes-tag 437 0x02 job-attributes-tag 438 0x03 end-of-attributes-tag 439 0x04 printer-attributes-tag 440 0x05 unsupported-attributes-tag 441 0x06-0x0e reserved for future delimiters 442 0x0F reserved for future chunking-end-of-attributes- 443 tag 445 When an xxx-attributes-tag occurs in the protocol, it MUST mean that 446 zero or more following attributes up to the next delimiter tag are 447 attributes belonging to group xxx as defined in the model document, 448 where xxx is operation, job, printer, unsupported. 450 Doing substitution for xxx in the above paragraph, this means the 451 following. When an operation-attributes-tag occurs in the protocol, it 452 MUST mean that the zero or more following attributes up to the next 453 delimiter tag are operation attributes as defined in the model document. 454 When an job-attributes-tag occurs in the protocol, it MUST mean that the 455 zero or more following attributes up to the next delimiter tag are job 456 attributes or job template attributes as defined in the model document. 457 When a printer-attributes-tag occurs in the protocol, it MUST mean that 458 the zero or more following attributes up to the next delimiter tag are 459 printer attributes as defined in the model document. When an 460 unsupported-attributes-tag occurs in the protocol, it MUST mean that the 461 zero or more following attributes up to the next delimiter tag are 462 unsupported attributes as defined in the model document. 464 The operation-attributes-tag and end-of-attributes-tag MUST each occur 465 exactly once in an operation. The operation-attributes-tag MUST be the 466 first tag delimiter, and the end-of-attributes-tag MUST be the last tag 467 delimiter. If the operation has a document-content group, the document 468 data in that group MUST follow the end-of-attributes-tag. 470 Each of the other three xxx-attributes-tags defined above is OPTIONAL 471 in an operation and each MUST occur at most once in an operation, except 472 for job-attributes-tag in a Get-Jobs response which may occur zero or 473 more times. 475 The order and presence of delimiter tags for each operation request and 476 each operation response MUST be that defined in the model document. For 477 further details, see section 3.9 "(Attribute) Name" and 11 "Appendix A: 478 Protocol Examples". 480 A Printer MUST treat the reserved delimiter tags differently from 481 reserved value tags so that the Printer knows that there is an entire 482 attribute group that it doesn't understand as opposed to a single value 483 that it doesn't understand. 485 3.7.2 Value Tags 487 The remaining tables show values for the value-tag, which is the first 488 octet of an attribute. The value-tag specifies the type of the value of 489 the attribute. The following table specifies the "out-of-band" values 490 for the value-tag. 492 Tag Value (Hex) Meaning 494 0x10 unsupported 495 0x11 reserved for future 'default' 496 0x12 unknown 497 0x13 no-value 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 0x49 mimeMediaType 551 0x4A-0x5F reserved for future character string types 553 NOTE: 0x40 is reserved for "generic character-string" if it should ever 554 be needed. 556 NOTE: an attribute value always has a type, which is explicitly 557 specified by its tag; one such tag value is "nameWithoutLanguage". An 558 attribute's name has an implicit type, which is keyword. 560 The values 0x60-0xFF are reserved for future types. There are no values 561 allocated for private extensions. A new type MUST be registered via the 562 type 2 registration process [ipp-mod]. 564 The tag 0x7F is reserved for extending types beyond the 255 values 565 available with a single byte. A tag value of 0x7F MUST signify that the 566 first 4 bytes of the value field are interpreted as the tag value. 567 Note, this future extension doesn't affect parsers that are unaware of 568 this special tag. The tag is like any other unknown tag, and the value 569 length specifies the length of a value which contains a value that the 570 parser treats atomically. All these 4 byte tag values are currently 571 unallocated except that the values 0x40000000-0x7FFFFFFF are reserved 572 for experimental use. 574 3.8 Name-Length 576 The name-length field MUST consist of a SIGNED-SHORT. This field MUST 577 specify the number of octets in the name field which follows the name- 578 length field, excluding the two bytes of the name-length field. 580 If a name-length field has a value of zero, the following name field 581 MUST be empty, and the following value MUST be treated as an additional 582 value for the preceding attribute. Within an attribute-sequence, if two 583 attributes have the same name, the first occurrence MUST be ignored. The 584 zero-length name is the only mechanism for multi-valued attributes. 586 3.9 (Attribute) Name 588 Some operation elements are called parameters in the model document 589 [ipp-mod]. They MUST be encoded in a special position and they MUST NOT 590 appear as an operation attributes. These parameters are: 592 - "version-number": The parameter named "version-number" in the IPP 593 model document MUST become the "version-number" field in the 594 operation layer request or response. 596 - "operation-id": The parameter named "operation-id" in the IPP model 597 document MUST become the "operation-id" field in the operation 598 layer request. 600 - "status-code": The parameter named "status-code" in the IPP model 601 document MUST become the "status-code" field in the operation layer 602 response. 604 - "request-id": The parameter named "request-id" in the IPP model 605 document MUST become the "request-id" field in the operation layer 606 request or response. 608 All Printer and Job objects are identified by a Uniform Resource 609 Identifier (URI) [RFC2396] so that they can be persistently and 610 unambiguously referenced. The notion of a URI is a useful concept, 611 however, until the notion of URI is more stable (i.e., defined more 612 completely and deployed more widely), it is expected that the URIs used 613 for IPP objects will actually be URLs [RFC1738] [RFC1808]. Since every 614 URL is a specialized form of a URI, even though the more generic term 615 URI is used throughout the rest of this document, its usage is intended 616 to cover the more specific notion of URL as well. 618 Some operation elements are encoded twice, once as the request-URI on 619 the HTTP Request-Line and a second time as a REQUIRED operation 620 attribute in the application/ipp entity. These attributes are the 621 target URI for the operation and are called printer-uri and job-uri. 622 Note: The target URI is included twice in an operation referencing the 623 same IPP object, but the two URIs NEED NOT be literally identical. One 624 can be a relative URI and the other can be an absolute URI. HTTP/1.1 625 allows clients to generate and send a relative URI rather than an 626 absolute URI. A relative URI identifies a resource with the scope of 627 the HTTP server, but does not include scheme, host or port. The 628 following statements characterize how URLs should be used in the mapping 629 of IPP onto HTTP/1.1: 631 1. Although potentially redundant, a client MUST supply the target of 632 the operation both as an operation attribute and as a URI at the 633 HTTP layer. The rationale for this decision is to maintain a 634 consistent set of rules for mapping application/ipp to possibly 635 many communication layers, even where URLs are not used as the 636 addressing mechanism in the transport layer. 637 2. Even though these two URLs might not be literally identical (one 638 being relative and the other being absolute), they MUST both 639 reference the same IPP object. 640 3. The URI in the HTTP layer is either relative or absolute and is 641 used by the HTTP server to route the HTTP request to the correct 642 resource relative to that HTTP server. The HTTP server need not be 643 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- job-attributes-sequence 670 Attributes) 671 Requested Attributes (Get- printer-attributes-sequence 672 Printer-Attributes) 673 Document Content in a special position as described 674 above 676 If an operation contains attributes from more than one job object (e.g. 677 Get-Jobs response), the attributes from each job object MUST be in a 678 separate job-attribute-sequence, such that the attributes from the ith 679 job object are in the ith job-attribute-sequence. See Section 11 680 "Appendix A: Protocol Examples" for table showing the application of the 681 rules above. 683 3.10 Value Length 685 Each attribute value MUST be preceded by a SIGNED-SHORT, which MUST 686 specify the number of octets in the value which follows this length, 687 exclusive of the two bytes specifying the length. 689 For any of the types represented by binary signed integers, the sender 690 MUST encode the value in exactly four octets. 692 For any of the types represented by character-strings, the sender MUST 693 encode the value with all the characters of the string and without any 694 padding characters. 696 If a value-tag contains an "out-of-band" value, such as "unsupported", 697 the value-length MUST be 0 and the value empty . the value has no 698 meaning when the value-tag has an "out-of-band" value. 700 3.11 (Attribute) Value 702 The syntax types and most of the details of their representation are 703 defined in the IPP model document. The table below augments the 704 information in the model document, and defines the syntax types from the 705 model document in terms of the 5 basic types defined in section 3 706 "Encoding of the Operation Layer". The 5 types are US-ASCII-STRING, 707 LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET- 708 STRING. 710 Syntax of Attribute Encoding 711 Value 713 textWithoutLanguage, LOCALIZED-STRING. 714 nameWithoutLanguage 716 textWithLanguage OCTET_STRING consisting of 4 fields: 717 a) a SIGNED-SHORT which is the number of octets 718 in the following field 719 b) a value of type natural-language, 720 c) a SIGNED-SHORT which is the number of octets 721 in the following field, 722 d) a value of type textWithoutLanguage. 724 The length of a textWithLanguage value MUST be 4 725 + the value of field a + the value of field c. 727 nameWithLanguage OCTET_STRING consisting of 4 fields: 728 a) a SIGNED-SHORT which is the number of octets 729 in the following field 730 b) a value of type natural-language, 731 c) a SIGNED-SHORT which is the number of octets 732 in the following field 733 d) a value of type nameWithoutLanguage. 735 The length of a nameWithLanguage value MUST be 4 736 + the value of field a + the value of field c. 738 charset, US-ASCII-STRING. 739 naturalLanguage, 740 mimeMediaType, 741 keyword, uri, and 742 uriScheme 744 boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is 745 'true'. 747 integer and enum a SIGNED-INTEGER. 749 dateTime OCTET-STRING consisting of eleven octets whose 750 contents are defined by "DateAndTime" in RFC 751 1903 [RFC1903]. 753 resolution OCTET_STRING consisting of nine octets of 2 754 SIGNED-INTEGERs followed by a SIGNED-BYTE. The 755 first SIGNED-INTEGER contains the value of cross 756 feed direction resolution. The second SIGNED- 757 INTEGER contains the value of feed direction 758 resolution. The SIGNED-BYTE contains the units 759 value. 761 rangeOfInteger Eight octets consisting of 2 SIGNED-INTEGERs. 762 The first SIGNED-INTEGER contains the lower 763 bound and the second SIGNED-INTEGER contains the 765 Syntax of Attribute Encoding 766 Value 768 upper bound. 770 1setOf X Encoding according to the rules for an attribute 771 with more than 1 value. Each value X is encoded 772 according to the rules for encoding its type. 774 octetString OCTET-STRING 776 The type of the value in the model document determines the encoding in 777 the value and the value of the value-tag. 779 3.12 Data 781 The data part MUST include any data required by the operation 783 4. Encoding of Transport Layer 785 HTTP/1.1 [RFC2616] is the transport layer for this protocol. 787 The operation layer has been designed with the assumption that the 788 transport layer contains the following information: 790 - the URI of the target job or printer operation 792 - the total length of the data in the operation layer, either as a 793 single length or as a sequence of chunks each with a length. 795 It is REQUIRED that a printer implementation support HTTP over the IANA 796 assigned Well Known Port 631 (the IPP default port), though a printer 797 implementation may support HTTP over some other port as well. 799 Each HTTP operation MUST use the POST method where the request-URI is 800 the object target of the operation, and where the "Content-Type" of the 801 message-body in each request and response MUST be "application/ipp". The 802 message-body MUST contain the operation layer and MUST have the syntax 803 described in section 3.2 "Syntax of Encoding". A client implementation 804 MUST adhere to the rules for a client described for HTTP1.1 [RFC2616] . 805 A printer (server) implementation MUST adhere the rules for an origin 806 server described for HTTP1.1 [RFC2616]. 808 An IPP server sends a response for each request that it receives. If an 809 IPP server detects an error, it MAY send a response before it has read 810 the entire request. If the HTTP layer of the IPP server completes 811 processing the HTTP headers successfully, it MAY send an intermediate 812 response, such as "100 Continue", with no IPP data before sending the 813 IPP response. A client MUST expect such a variety of responses from an 814 IPP server. For further information on HTTP/1.1, consult the HTTP 815 documents [RFC2616]. 817 An HTTP server MUST support chunking for IPP requests, and an IPP client 818 MUST support chunking for IPP responses according to HTTP/1.1[RFC2616]. 819 Note: this rule causes a conflict with non-compliant implementations of 820 HTTP/1.1 that don't support chunking for POST methods, and this rule may 821 cause a conflict with non-compliant implementations of HTTP/1.1 that 822 don't support chunking for CGI scripts 824 5. IPP URL Scheme 826 The IPP/1.1 document defines a new scheme 'ipp' as the value of a URL 827 that identifies either an IPP printer object or an IPP job object. The 828 IPP attributes using the 'ipp' scheme are specified below. Because the 829 HTTP layer does not support the 'ipp' scheme, a client MUST map 'ipp' 830 URLs to 'http' URLs, and then follows the HTTP [RFC2616][RFC2617] rules 831 for constructing a Request-Line and HTTP headers. The mapping is simple 832 because the 'ipp' scheme implies all of the same protocol semantics as 833 that of the 'http' scheme [RFC2616], except that it represents a print 834 service and the implicit (default) port number that clients use to 835 connect to a server is port 631. 837 In the remainder of this section the term 'ipp-URL' means a URL whose 838 scheme is 'ipp' and whose implicit (default) port is 631. The term 839 'http-URL' means a URL whose scheme is 'http', and the term 'https-URL' 840 means a URL whose scheme is 'https', 842 A client and an IPP object (i.e. the server) MUST support the ipp-URL 843 value in the following IPP attributes. 844 job attributes: 845 job-uri 846 job-printer-uri 847 printer attributes: 848 printer-uri-supported 849 operation attributes: 850 job-uri 851 printer-uri 853 Each of the above attributes identifies a printer or job object. The 854 ipp-URL is intended as the value of the attributes in this list, and for 855 no other attributes. All of these attributes have a syntax type of 856 'uri', but there are attributes with a syntax type of 'uri' that do not 857 use the 'ipp' scheme, e.g. 'job-more-info'. 859 If a printer registers its URL with a directory service, the printer 860 MUST register an ipp-URL. 862 User interfaces are beyond the scope of this document. But if software 863 exposes the ipp-URL values of any of the above five attributes to a 864 human user, it is REQUIRED that the human see the ipp-URL as is. 866 When a client sends a request, it MUST convert a target ipp-URL to a 867 target http-URL for the HTTP layer according to the following rules: 868 1. change the 'ipp' scheme to 'http' 869 2. add an explicit port 631 if the URL does not contain an explicit 870 port. Note: port 631 is the IANA assigned Well Known Port for the 871 'ipp' scheme. 873 The client MUST use the target http-URL in both the HTTP Request-Line 874 and HTTP headers, as specified by HTTP[RFC2616][RFC2617] . However, the 875 client MUST use the target ipp-URL for the value of the "printer-uri" or 876 "job-uri" operation attribute within the application/ipp body of the 877 request. The server MUST use the ipp-URL for the value of the "printer- 878 uri", "job-uri" or "printer-uri-supported" attributes within the 879 application/ipp body of the response. 881 For example, when an IPP client sends a request directly (i.e. no proxy) 882 to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a TCP 883 connection to port 631 (the ipp implicit port) on the host "myhost.com" 884 and sends the following data: 886 POST /myprinter/myqueue HTTP/1.1 887 Host: myhost.com:631 888 Content-type: application/ipp 889 Transfer-Encoding: chunked 890 ... 891 "printer-uri" "ipp://myhost.com/myprinter/myqueue" 892 (encoded in application/ipp message body) 893 ... 895 As another example, when an IPP client sends the same request as above 896 via a proxy "myproxy.com", it opens a TCP connection to the proxy port 897 8080 on the proxy host "myproxy.com" and sends the following data: 899 POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 900 Host: myhost.com:631 901 Content-type: application/ipp 902 Transfer-Encoding: chunked 903 ... 904 "printer-uri" "ipp://myhost.com/myprinter/myqueue" 905 (encoded in application/ipp message body) 906 ... 908 The proxy then connects to the IPP origin server with headers that are 909 the same as the "no-proxy" example above. 911 6. Security Considerations 913 The IPP Model and Semantics document [ipp-mod] discusses high level 914 security requirements (Client Authentication, Server Authentication and 915 Operation Privacy). Client Authentication is the mechanism by which the 916 client proves its identity to the server in a secure manner. Server 917 Authentication is the mechanism by which the server proves its identity 918 to the client in a secure manner. Operation Privacy is defined as a 919 mechanism for protecting operations from eavesdropping. 921 6.1 Security Conformance Requirements 923 This section defines the security requirements for IPP clients and IPP 924 objects. 926 6.1.1 Digest Authentication 928 IPP clients MUST support: 930 Digest Authentication [RFC2617]. 932 MD5 and MD5-sess MUST be implemented and supported. 934 The Message Integrity feature NEED NOT be used. 936 IPP Printers SHOULD support: 938 Digest Authentication [RFC2617]. 940 MD5 and MD5-sess MUST be implemented and supported. 942 The Message Integrity feature NEED NOT be used. 944 The reasons that IPP Printers SHOULD (rather than MUST) support Digest 945 Authentication are: 947 1.While Client Authentication is important, there is a certain class of 948 printer devices where it does not make sense. Specifically, a low- 949 end device with limited ROM space and low paper throughput may not 950 need Client Authentication. This class of device typically requires 951 firmware designers to make trade-offs between protocols and 952 functionality to arrive at the lowest-cost solution possible. 953 Factored into the designer.s decisions is not just the size of the 954 code, but also the testing, maintenance, usefulness, and time-to- 955 market impact for each feature delivered to the customer. Forcing 956 such low-end devices to provide security in order to claim IPP/1.1 957 conformance would not make business sense and could potentially stall 958 the adoption of the standard. 960 2.Print devices that have high-volume throughput and have available ROM 961 space have a compelling argument to provide support for Client 962 Authentication that safeguards the device from unauthorized access. 963 These devices are prone to a high loss of consumables and paper if 964 unauthorized access should occur. 966 6.1.2 Transport Layer Security (TLS) 968 IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246] for 969 Server Authentication and Operation Privacy. IPP Printers MAY also 970 support TLS for Client Authentication. If an IPP Printer supports TLS, 971 it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as 972 mandated by RFC 2246 [RFC2246]. All other cipher suites are OPTIONAL. 973 An IPP Printer MAY support Basic Authentication (described in HTTP/1.1 974 [RFC2617]) for Client Authentication if the channel is secure. TLS with 975 the above mandated cipher suite can provide such a secure channel. 977 If a IPP client supports TLS, it MUST support the 978 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246 979 [RFC2246]. All other cipher suites are OPTIONAL. 981 The IPP Model and Semantics document defines two printer attributes 982 ("uri-authentication-supported" and "uri-security-supported") that the 983 client can use to discover the security policy of a printer. That 984 document also outlines IPP-specific security considerations and should 985 be the primary reference for security implications with regard to the 986 IPP protocol itself. For backward compatibility with IPP version 1.0, 987 IPP clients and printers may also support SSL3. This is in addition to 988 the security required in this document. 990 6.2 Using IPP with TLS 992 IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism [http- 993 tls]. An initial IPP request never uses TLS. The client requests a 994 secure TLS connection by using the HTTP .Upgrade. header, while the 995 server agrees in the HTTP response. The switch to TLS occurs either 996 because the server grants the client.s request to upgrade to TLS, or a 997 server asks to switch to TLS in its response. Secure communication 998 begins with a server.s response to switch to TLS. 1000 7. Interoperability with IPP/1.0 Implementations 1002 It is beyond the scope of this specification to mandate conformance with 1003 previous versions. IPP/1.1 was deliberately designed, however, to make 1004 supporting previous versions easy. It is worth noting that, at the time 1005 of composing this specification (1999), we would expect IPP/1.1 Printer 1006 implementations to: 1008 understand any valid request in the format of IPP/1.0, or 1.1; 1010 respond appropriately with a response containing the same "version- 1011 number" parameter value used by the client in the request. 1013 And we would expect IPP/1.1 clients to: 1015 understand any valid response in the format of IPP/1.0, or 1.1. 1017 7.1 The "version-number" Parameter 1019 The following are rules regarding the "version-number" parameter (see 1020 section 3.3): 1022 1. Clients MUST send requests containing a "version-number" parameter 1023 with a '1.1' value and SHOULD try supplying alternate version 1024 numbers if they receive a 'server-error-version-not-supported' 1025 error return in a response. 1027 2. IPP objects MUST accept requests containing a "version-number" 1028 parameter with a '1.1' value (or reject the request for reasons 1029 other than 'server-error-version-not-supported'). 1031 3. It is recommended that IPP objects accept any request with the 1032 major version '1' (or reject the request for reasons other than 1033 'server-error-version-not-supported'). See [ipp-mod] "versions" 1034 sub-section. 1036 4. In any case, security MUST NOT be compromised when a client 1037 supplies a lower "version-number" parameter in a request. For 1038 example, if an IPP/1.1 conforming Printer object accepts version 1039 '1.0' requests and is configured to enforce Digest Authentication, 1040 it MUST do the same for a version '1.0' request. 1042 7.2 Security and URL Schemes 1044 The following are rules regarding security, the "version-number" 1045 parameter, and the URL scheme supplied in target attributes and 1046 responses: 1048 1. When a client supplies a request, the "printer-uri" or "job-uri" 1049 target operation attribute MUST have the same scheme as that 1050 indicated in one of the values of the "printer-uri-supported" 1051 Printer attribute. 1053 2. When the server returns the "job-printer-uri" or "job-uri" Job 1054 Description attributes, it SHOULD return the same scheme ('ipp', 1055 'https', 'http', etc.) that the client supplied in the "printer- 1056 uri" or "job-uri" target operation attributes in the Get-Job- 1057 Attributes or Get-Jobs request, rather than the scheme used when 1058 the job was created. However, when a client requests job 1059 attributes using the Get-Job-Attributes or Get-Jobs operations, the 1060 jobs and job attributes that the server returns depends on: (1) the 1061 security in effect when the job was created, (2) the security in 1062 effect in the query request, and (3) the security policy in force. 1064 3. It is recommended that if a server registers a non-secure ipp-URL 1065 with a directory service (see [IPP-MOD] "Generic Directory Schema" 1066 Appendix), then it also register an http-URL for interoperability 1067 with IPP/1.0 clients (see section 7). 1069 4. In any case, security MUST NOT be compromised when a client 1070 supplies an 'http' or other non-secure URL scheme in the target 1071 "printer-uri" and "job-uri" operation attributes in a request. 1073 8. References 1075 [dpa] ISO/IEC 10175 Document Printing Application (DPA), June 1996. 1077 [http-tls]R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1", 1078 , June 1999. 1080 [iana]IANA Registry of Coded Character Sets: ftp://ftp.isi.edu/in- 1081 notes/iana/assignments/character-sets. 1083 [ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.1: 1084 Implementer's Guide", work in progress. 1086 [ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1087 "Internet Printing Protocol/1.0: Model and Semantics", , June, 1999. 1090 [ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet 1091 Printing Protocol/1.1: Encoding and Transport", draft-ietf-ipp- 1092 protocol-v11-02-.txt, June 1999. 1094 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text 1095 Messages", RFC 822, August 1982. 1097 [RFC1123] Braden, S., "Requirements for Internet Hosts - Application 1098 and Support", RFC 1123, October, 1989. 1100 [RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" 1101 RFC 1179, August 1990. 1103 [RFC1543] Postel, J., "Instructions to RFC Authors", RFC 1543, October 1104 1993. 1106 [RFC1738] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform 1107 Resource Locators (URL)", RFC 1738, December, 1994. 1109 [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and 1110 Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. 1112 [RFC1766] H. Alvestrand, " Tags for the Identification of Languages", 1113 RFC 1766, March 1995. 1115 [RFC1808] R. Fielding, "Relative Uniform Resource Locators", RFC1808, 1116 June 1995. 1118 [RFC1903] J. Case, et al. "Textual Conventions for Version 2 of the 1119 Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1120 1996. 1122 [RFC2046] N. Freed & N. Borenstein, Multipurpose Internet Mail 1123 Extensions (MIME) Part Two: Media Types. November 1996, RFC 2046. 1125 [RFC2048] N. Freed, J. Klensin & J. Postel. Multipurpose Internet Mail 1126 Extension (MIME) Part Four: Registration Procedures. November 1127 1996 (Also BCP0013), RFC 2048. 1129 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1130 Requirement Levels", RFC 2119 , March 1997. 1132 [RFC2184] N. Freed, K. Moore, "MIME Parameter Value and Encoded Word 1133 Extensions: Character Sets, Languages, and Continuations", RFC 1134 2184, August 1997. 1136 [RFC2234] D. Crocker et al., "Augmented BNF for Syntax Specifications: 1137 ABNF", RFC 2234. November 1997. 1139 [RFC2246] T. Dierks et al., "The TLS Protocol", RFC 2246. January 1999. 1141 [RFC2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform 1142 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1143 1998. 1145 [RFC2565] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet 1146 Printing Protocol/1.0: Encoding and Transport", rfc 2565, April 1147 1999. 1149 [RFC2566] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1150 "Internet Printing Protocol/1.0: Model and Semantics", rfc 2566, 1151 April, 1999. 1153 [RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", 1154 RFC2567, April 1999. 1156 [RFC2568] Zilles, S., "Rationale for the Structure and Model and 1157 Protocol for the Internet Printing Protocol", RC 2568,April 1999. 1159 [RFC2569] Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping 1160 between LPD and IPP Protocols RFC 2569, April 1999. 1162 [RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1163 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 1164 RFC 2616, June 1999. 1166 [RFC2069] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. 1167 Leach, A. Luotonen, L. Stewart, "HTTP Authentication: Basic and 1168 Digest Access Authentication", RFC 2617, June 1999. 1170 9. Author's Address 1171 Robert Herriot (editor) Paul Moore 1172 Xerox Corporation Microsoft 1173 3400 Hillview Ave., Bldg #1 One Microsoft Way 1174 Palo Alto, CA 94304 Redmond, WA 98053 1176 Phone: 650-813-7696 Phone: 425-936-0908 1177 Fax: 650-813-6860 Fax: 425-93MS-FAX 1178 Email: Email: paulmo@microsoft.com 1179 robert.herriot@pahv.xerox.com 1181 Sylvan Butler Randy Turner 1182 Hewlett-Packard 2Wire, Inc. 1183 11311 Chinden Blvd. 694 Tasman Dr. 1184 Boise, ID 83714 Milpitas, CA 95035 1186 Phone: 208-396-6000 Phone: 408-546-1273 1187 Fax: 208-396-3457 1188 Email: sbutler@boi.hp.com 1190 John Wenn 1191 Xerox Corporation 1192 737 Hawaii St 1193 El Segundo, CA 90245 1195 IPP Mailing List: ipp@pwg.org Phone: 310-333-5764 1196 IPP Mailing List Subscription: Fax: 310-333-5514 1197 ipp-request@pwg.org 1198 IPP Web Page: Email: jwenn@cp10.es.xerox.com 1199 http://www.pwg.org/ipp/ 1201 10. Other Participants: 1203 Chuck Adams - Tektronix Shivaun Albright - HP 1204 Jeff Barnett - IBM Ron Bergman - Dataproducts 1205 Keith Carter - IBM Angelo Caruso - Xerox 1206 Rajesh Chawla - TR Computing Josh Cohen - Microsoft 1207 Solutions 1208 Jeff Copeland - QMS Andy Davidson - Tektronix 1209 Roger deBry - IBM Mabry Dozier - QMS 1210 Lee Farrell - Canon Steve Gebert - IBM 1211 Sue Gleeson - Digital Charles Gordon - Osicom 1212 Brian Grimshaw - Apple Jerry Hadsell - IBM 1213 Richard Hart - Digital Tom Hastings - Xerox 1214 Stephen Holmstead Zhi-Hong Huang - Zenographics 1215 Scott Isaacson - Novell Babek Jahromi - Microsoft 1216 Swen Johnson - Xerox David Kellerman - Northlake 1217 Software 1218 Robert Kline - TrueSpectra Carl Kugler - IBM 1219 Dave Kuntz - Hewlett-Packard Takami Kurono - Brother 1220 Rick Landau - Digital Scott Lawrence - Agranot Systems 1221 Greg LeClair - Epson Harry Lewis - IBM 1222 Tony Liao - Vivid Image Roy Lomicka - Digital 1223 Pete Loya - HP Ray Lutz - Cognisys 1224 Mike MacKay - Novell, Inc. David Manchala - Xerox 1225 Carl-Uno Manros - Xerox Jay Martin - Underscore 1226 Larry Masinter - Xerox Stan McConnell - Xerox 1227 Ira McDonald - High North Inc. Peter Michalek - Shinesoft 1228 Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh 1229 Pat Nogay - IBM Ron Norton - Printronics 1230 Bob Pentecost - Hewlett-Packard Patrick Powell - Astart 1231 Technologies 1232 Jeff Rackowitz - Intermec Rob Rhoads - Intel 1233 Xavier Riley - Xerox Gary Roberts - Ricoh 1234 David Roach - Unisys Stuart Rowley - Kyocera 1235 Richard Schneider - Epson Kris Schoff - HP 1236 Bob Setterbo - Adobe Devon Taylor - Novell, Inc. 1237 Mike Timperman - Lexmark Shigern Ueda - Canon 1238 Bob Von Andel - Allegro Software William Wagner - Osicom 1239 Jim Walker - DAZEL Chris Wellens - Interworking Labs 1240 Rob Whittle - Novell, Inc. Jasper Wong - Xionics 1241 Don Wright - Lexmark Rick Yardumian - Xerox 1242 Lloyd Young - Lexmark Atsushi Yuki - Kyocera 1243 Peter Zehler - Xerox Frank Zhao - Panasonic 1244 Steve Zilles - Adobe 1246 11. Appendix A: Protocol Examples 1248 11.1 Print-Job Request 1250 The following is an example of a Print-Job request with job-name, 1251 copies, and sides specified. The "ipp-attribute-fidelity" attribute is 1252 set to 'true' so that the print request will fail if the "copies" or the 1253 "sides" attribute are not supported or their values are not supported. 1255 Octets Symbolic Value Protocol field 1257 0x0101 1.1 version-number 1258 0x0002 Print-Job operation-id 1259 0x00000001 1 request-id 1260 0x01 start operation-attributes operation-attributes-tag 1261 0x47 charset type value-tag 1262 0x0012 name-length 1263 attributes- attributes-charset name 1264 charset 1265 0x0008 value-length 1266 us-ascii US-ASCII value 1267 0x48 natural-language type value-tag 1268 0x001B name-length 1269 attributes- attributes-natural-language name 1270 natural- 1271 language 1272 0x0005 value-length 1273 en-us en-US value 1274 0x45 uri type value-tag 1275 0x000B name-length 1276 printer-uri printer-uri name 1277 0x0015 value-length 1278 ipp://forest/p printer pinetree value 1279 inetree 1280 0x42 nameWithoutLanguage type value-tag 1281 0x0008 name-length 1282 job-name job-name name 1283 0x0006 value-length 1284 foobar foobar value 1285 0x22 boolean type value-tag 1286 0x0016 name-length 1287 ipp-attribute- ipp-attribute-fidelity name 1288 fidelity 1289 0x0001 value-length 1290 0x01 true value 1291 0x02 start job-attributes job-attributes-tag 1292 0x21 integer type value-tag 1293 0x0006 name-length 1294 copies copies name 1295 0x0004 value-length 1296 0x00000014 20 value 1297 0x44 keyword type value-tag 1298 0x0005 name-length 1299 sides sides name 1300 0x0013 value-length 1301 two-sided- two-sided-long-edge value 1302 long-edge 1303 0x03 end-of-attributes end-of-attributes-tag 1304 %!PS... data 1306 11.2 Print-Job Response (successful) 1307 Here is an example of a successful Print-Job response to the previous 1308 Print-Job request. The printer supported the "copies" and "sides" 1309 attributes and their supplied values. The status code returned is 1310 'successful-ok'. 1312 Octets Symbolic Value Protocol field 1314 0x0101 1.1 version-number 1315 0x0000 successful-ok status-code 1316 0x00000001 1 request-id 1317 0x01 start operation-attributes operation-attributes-tag 1318 0x47 charset type value-tag 1319 0x0012 name-length 1320 attributes- attributes-charset name 1321 charset 1322 0x0008 value-length 1323 us-ascii US-ASCII value 1324 0x48 natural-language type value-tag 1325 0x001B name-length 1326 attributes- attributes-natural- name 1327 natural-language language 1328 0x0005 value-length 1329 en-us en-US value 1330 0x41 textWithoutLanguage type value-tag 1331 0x000E name-length 1332 status-message status-message name 1333 0x000D value-length 1334 successful-ok successful-ok value 1335 0x02 start job-attributes job-attributes-tag 1336 0x21 integer value-tag 1337 0x0006 name-length 1338 job-id job-id name 1339 0x0004 value-length 1340 147 147 value 1341 0x45 uri type value-tag 1342 0x0007 name-length 1343 job-uri job-uri name 1344 0x0019 value-length 1345 ipp://forest/pin job 123 on pinetree value 1346 etree/123 1347 0x23 enum type value-tag 1348 0x0009 name-length 1349 job-state job-state name 1350 0x0004 value-length 1351 0x0003 pending value 1352 0x03 end-of-attributes end-of-attributes-tag 1354 11.3 Print-Job Response (failure) 1356 Here is an example of an unsuccessful Print-Job response to the previous 1357 Print-Job request. It fails because, in this case, the printer does not 1358 support the "sides" attribute and because the value '20' for the 1359 "copies" attribute is not supported. Therefore, no job is created, and 1360 neither a "job-id" nor a "job-uri" operation attribute is returned. The 1361 error code returned is 'client-error-attributes-or-values-not-supported' 1362 (0x040B). 1364 Octets Symbolic Value Protocol field 1366 0x0101 1.1 version-number 1367 0x040B client-error-attributes-or- status-code 1368 values-not-supported 1369 0x00000001 1 request-id 1370 0x01 start operation-attributes operation-attribute tag 1371 0x47 charset type value-tag 1372 0x0012 name-length 1373 attributes- attributes-charset name 1374 charset 1375 0x0008 value-length 1376 us-ascii US-ASCII value 1377 0x48 natural-language type value-tag 1378 0x001B name-length 1379 attributes- attributes-natural-language name 1380 natural- 1381 language 1382 0x0005 value-length 1383 en-us en-US value 1384 0x41 textWithoutLanguage type value-tag 1385 0x000E name-length 1386 status- status-message name 1387 message 1388 0x002F value-length 1389 client-error- client-error-attributes-or- value 1390 attributes- values-not-supported 1391 or-values- 1392 not-supported 1393 0x05 start unsupported-attributes unsupported-attributes tag 1394 0x21 integer type value-tag 1395 0x0006 name-length 1396 copies copies name 1397 0x0004 value-length 1398 0x00000014 20 value 1399 0x10 unsupported (type) value-tag 1400 0x0005 name-length 1401 sides sides name 1402 0x0000 value-length 1403 0x03 end-of-attributes end-of-attributes-tag 1405 11.4 Print-Job Response (success with attributes ignored) 1407 Here is an example of a successful Print-Job response to a Print-Job 1408 request like the previous Print-Job request, except that the value of 1409 'ipp-attribute-fidelity' is false. The print request succeeds, even 1410 though, in this case, the printer supports neither the "sides" attribute 1411 nor the value '20' for the "copies" attribute. Therefore, a job is 1412 created, and both a "job-id" and a "job-uri" operation attribute are 1413 returned. The unsupported attributes are also returned in an Unsupported 1414 Attributes Group. The error code returned is 'successful-ok-ignored-or- 1415 substituted-attributes' (0x0001). 1417 Octets Symbolic Value Protocol field 1419 0x0101 1.1 version-number 1420 0x0001 successful-ok-ignored-or- status-code 1421 substituted-attributes 1422 0x00000001 1 request-id 1423 0x01 start operation-attributes operation-attributes-tag 1424 0x47 charset type value-tag 1425 0x0012 name-length 1426 attributes- attributes-charset name 1427 charset 1428 0x0008 value-length 1429 us-ascii US-ASCII value 1430 0x48 natural-language type value-tag 1431 0x001B name-length 1432 attributes- attributes-natural- name 1433 natural-language language 1434 0x0005 value-length 1435 en-us en-US value 1436 0x41 textWithoutLanguage type value-tag 1437 0x000E name-length 1438 status-message status-message name 1439 0x002F value-length 1440 successful-ok- successful-ok-ignored-or- value 1441 ignored-or- substituted-attributes 1442 substituted- 1443 attributes 1444 0x05 start unsupported- unsupported-attributes 1445 attributes tag 1446 0x21 integer type value-tag 1447 0x0006 name-length 1448 copies copies name 1449 0x0004 value-length 1450 0x00000014 20 value 1451 0x10 unsupported (type) value-tag 1452 0x0005 name-length 1453 sides sides name 1454 0x0000 value-length 1455 0x02 start job-attributes job-attributes-tag 1456 0x21 integer value-tag 1457 0x0006 name-length 1458 job-id job-id name 1459 0x0004 value-length 1460 147 147 value 1461 0x45 uri type value-tag 1462 0x0007 name-length 1463 job-uri job-uri name 1464 0x0019 value-length 1465 ipp://forest/pin job 123 on pinetree value 1466 etree/123 1467 0x23 enum type value-tag 1468 0x0009 name-length 1469 job-state job-state name 1470 0x0004 value-length 1471 Octets Symbolic Value Protocol field 1473 0x0003 pending value 1474 0x03 end-of-attributes end-of-attributes-tag 1476 11.5 Print-URI Request 1478 The following is an example of Print-URI request with copies and job- 1479 name parameters: 1481 Octets Symbolic Value Protocol field 1482 0x0101 1.1 version-number 1483 0x0003 Print-URI operation-id 1484 0x00000001 1 request-id 1485 0x01 start operation-attributes operation-attributes-tag 1486 0x47 charset type value-tag 1487 0x0012 name-length 1488 attributes- attributes-charset name 1489 charset 1490 0x0008 value-length 1491 us-ascii US-ASCII value 1492 0x48 natural-language type value-tag 1493 0x001B name-length 1494 attributes- attributes-natural-language name 1495 natural- 1496 language 1497 0x0005 value-length 1498 en-us en-US value 1499 0x45 uri type value-tag 1500 0x000B name-length 1501 printer-uri printer-uri name 1502 0x0015 value-length 1503 ipp://forest/ printer pinetree value 1504 pinetree 1505 0x45 uri type value-tag 1506 0x000C name-length 1507 document-uri document-uri name 1508 0x0011 value-length 1509 ftp://foo.com ftp://foo.com/foo value 1510 /foo 1511 0x42 nameWithoutLanguage type value-tag 1512 0x0008 name-length 1513 job-name job-name name 1514 0x0006 value-length 1515 foobar foobar value 1516 0x02 start job-attributes job-attributes-tag 1517 0x21 integer type value-tag 1518 0x0006 name-length 1519 copies copies name 1520 0x0004 value-length 1521 0x00000001 1 value 1522 0x03 end-of-attributes end-of-attributes-tag 1524 11.6 Create-Job Request 1526 The following is an example of Create-Job request with no parameters and 1527 no attributes: 1529 Octets Symbolic Value Protocol field 1530 0x0101 1.1 version-number 1531 0x0005 Create-Job operation-id 1532 0x00000001 1 request-id 1533 0x01 start operation-attributes operation-attributes-tag 1534 0x47 charset type value-tag 1535 0x0012 name-length 1536 attributes- attributes-charset name 1537 charset 1538 0x0008 value-length 1539 us-ascii US-ASCII value 1540 0x48 natural-language type value-tag 1541 0x001B name-length 1542 attributes- attributes-natural-language name 1543 natural- 1544 language 1545 0x0005 value-length 1546 en-us en-US value 1547 0x45 uri type value-tag 1548 0x000B name-length 1549 printer-uri printer-uri name 1550 0x0015 value-length 1551 ipp://forest/p printer pinetree value 1552 inetree 1553 0x03 end-of-attributes end-of-attributes-tag 1555 11.7 Get-Jobs Request 1557 The following is an example of Get-Jobs request with parameters but no 1558 attributes: 1560 Octets Symbolic Value Protocol field 1561 0x0101 1.1 version-number 1562 0x000A Get-Jobs operation-id 1563 0x00000123 0x123 request-id 1564 0x01 start operation-attributes operation-attributes-tag 1565 0x47 charset type value-tag 1566 0x0012 name-length 1567 attributes- attributes-charset name 1568 charset 1569 0x0008 value-length 1570 us-ascii US-ASCII value 1571 0x48 natural-language type value-tag 1572 0x001B name-length 1573 attributes- attributes-natural-language name 1574 natural- 1575 language 1576 0x0005 value-length 1577 en-us en-US value 1578 0x45 uri type value-tag 1579 0x000B name-length 1580 printer-uri printer-uri name 1581 0x0015 value-length 1582 ipp://forest/pi printer pinetree value 1583 netree 1584 0x21 integer type value-tag 1585 0x0005 name-length 1586 limit limit name 1587 0x0004 value-length 1588 0x00000032 50 value 1589 0x44 keyword type value-tag 1590 0x0014 name-length 1591 requested- requested-attributes name 1592 attributes 1593 0x0006 value-length 1594 job-id job-id value 1595 0x44 keyword type value-tag 1596 0x0000 additional value name-length 1597 0x0008 value-length 1598 job-name job-name value 1599 0x44 keyword type value-tag 1600 0x0000 additional value name-length 1601 0x000F value-length 1602 document-format document-format value 1603 0x03 end-of-attributes end-of-attributes-tag 1605 11.8 Get-Jobs Response 1607 The following is an of Get-Jobs response from previous request with 3 1608 jobs. The Printer returns no information about the second job (because 1609 of security reasons): 1611 Octets Symbolic Value Protocol field 1612 0x0101 1.1 version-number 1613 0x0000 successful-ok status-code 1614 0x00000123 0x123 request-id (echoed 1615 back) 1616 0x01 start operation-attributes operation-attribute-tag 1617 0x47 charset type value-tag 1618 0x0012 name-length 1619 attributes- attributes-charset name 1620 charset 1621 0x000A value-length 1622 ISO-8859-1 ISO-8859-1 value 1623 0x48 natural-language type value-tag 1624 0x001B name-length 1625 attributes- attributes-natural-language name 1626 natural- 1627 language 1628 0x0005 value-length 1629 en-us en-US value 1630 0x41 textWithoutLanguage type value-tag 1631 0x000E name-length 1632 status-message status-message name 1633 0x000D value-length 1634 successful-ok successful-ok value 1635 0x02 start job-attributes (1st job-attributes-tag 1636 object) 1637 0x21 integer type value-tag 1638 0x0006 name-length 1639 job-id job-id name 1640 0x0004 value-length 1641 147 147 value 1642 0x36 nameWithLanguage value-tag 1643 0x0008 name-length 1644 job-name job-name name 1645 0x000C value-length 1646 0x0005 sub-value-length 1647 fr-ca fr-CA value 1648 0x0003 sub-value-length 1649 fou fou name 1650 0x02 start job-attributes (2nd job-attributes-tag 1651 object) 1652 0x02 start job-attributes (3rd job-attributes-tag 1653 object) 1654 0x21 integer type value-tag 1655 0x0006 name-length 1656 job-id job-id name 1657 0x0004 value-length 1658 148 149 value 1659 0x36 nameWithLanguage value-tag 1660 0x0008 name-length 1661 job-name job-name name 1662 0x0012 value-length 1663 0x0005 sub-value-length 1664 de-CH de-CH value 1665 Octets Symbolic Value Protocol field 1666 0x0009 sub-value-length 1667 isch guet isch guet name 1668 0x03 end-of-attributes end-of-attributes-tag 1670 12. Appendix C: Registration of MIME Media Type Information for 1671 "application/ipp" 1673 This appendix contains the information that IANA requires for 1674 registering a MIME media type. The information following this paragraph 1675 will be forwarded to IANA to register application/ipp whose contents are 1676 defined in Section 3 "Encoding of the Operation Layer" in this 1677 document: 1679 MIME type name: application 1681 MIME subtype name: ipp 1683 A Content-Type of "application/ipp" indicates an Internet Printing 1684 Protocol message body (request or response). Currently there is one 1685 version: IPP/1.1, whose syntax is described in Section 3 "Encoding of 1686 the Operation Layer" of [ipp-pro], and whose semantics are described in 1687 [ipp-mod]. 1689 Required parameters: none 1691 Optional parameters: none 1693 Encoding considerations: 1695 IPP/1.1 protocol requests/responses MAY contain long lines and ALWAYS 1696 contain binary data (for example attribute value lengths). 1698 Security considerations: 1700 IPP/1.1 protocol requests/responses do not introduce any security risks 1701 not already inherent in the underlying transport protocols. Protocol 1702 mixed-version interworking rules in [ipp-mod] as well as protocol 1703 encoding rules in [ipp-pro] are complete and unambiguous. 1705 Interoperability considerations: 1707 IPP/1.1 requests (generated by clients) and responses (generated by 1708 servers) MUST comply with all conformance requirements imposed by the 1709 normative specifications [ipp-mod] and [ipp-pro]. Protocol encoding 1710 rules specified in [ipp-pro] are comprehensive, so that interoperability 1711 between conforming implementations is guaranteed (although support for 1712 specific optional features is not ensured). Both the "charset" and 1713 "natural-language" of all IPP/1.1 attribute values which are a 1714 LOCALIZED-STRING are explicit within IPP protocol requests/responses 1715 (without recourse to any external information in HTTP, SMTP, or other 1716 message transport headers). 1718 Published specifications: 1720 [ipp-mod] Isaacson, S., deBry, R., Hastings, T., Herriot, R., 1721 Powell, P., "Internet Printing Protocol/1.1: Model and 1722 Semantics" draft-ietf-ipp-model-v11-03.txt, June, 1999. 1724 [ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., 1725 "Internet Printing Protocol/1.1: Encoding and Transport", draft- 1726 ietf-ipp-protocol-v11-02.txt, June, 1999. 1728 Applications which use this media type: 1730 Internet Printing Protocol (IPP) print clients and print servers, 1731 communicating using HTTP/1.1 (see [IPP-PRO]), SMTP/ESMTP, FTP, or other 1732 transport protocol. Messages of type "application/ipp" are self- 1733 contained and transport-independent, including "charset" and "natural- 1734 language" context for any LOCALIZED-STRING value. 1736 Person & email address to contact for further information: 1738 Tom Hastings 1739 Xerox Corporation 1740 737 Hawaii St. ESAE-231 1741 El Segundo, CA 1743 Phone: 310-333-6413 1744 Fax: 310-333-5514 1745 Email: thastings@cp10.es.xerox.com 1747 or 1749 Robert Herriot 1750 Xerox Corporation 1751 3400 Hillview Ave., Bldg #1 1752 Palo Alto, CA 94304 1754 Phone: 650-813-7696 1755 Fax: 650-813-6860 1756 Email: robert.herriot@pahv.xerox.com 1758 Intended usage: 1760 COMMON 1762 13. Appendix D: Changes from IPP/1.0 1764 IPP/1.1 is identical to IPP/1.0 [RFC2565] with the follow changes: 1766 1.Attributes values that identify a printer or job object use a new 1767 'ipp' scheme. The 'http' and 'https' schemes are supported only for 1768 backward compatibility. See section 5. 1770 2.Clients MUST support of Digest Authentication, IPP Printers SHOULD 1771 support Digest Authentication. See Section 6.1.1 1773 3.TLS is recommended for channel security. In addition, SSL3 may be 1774 supported for backward compatibility. See Section 6.1.2 1776 4.It is recommended that IPP/1.1 objects accept any request with major 1777 version number '1'. See section 7.1. 1779 5.IPP objects SHOULD return the URL scheme requested for "job-printer- 1780 uri" and "job-uri" Job Attributes, rather than the URL scheme used to 1781 create the job. See section 7.2 1783 14. Full Copyright Statement 1785 The IETF takes no position regarding the validity or scope of any 1786 intellectual property or other rights that might be claimed to pertain 1787 to the implementation or use of the technology described in this 1788 document or the extent to which any license under such rights might or 1789 might not be available; neither does it represent that it has made any 1790 effort to identify any such rights. Information on the IETF's 1791 procedures with respect to rights in standards-track and standards- 1792 related documentation can be found in BCP-11[BCP-11]. Copies of claims 1793 of rights made available for publication and any assurances of licenses 1794 to be made available, or the result of an attempt made to obtain a 1795 general license or permission for the use of such proprietary rights by 1796 implementers or users of this specification can be obtained from the 1797 IETF Secretariat. 1799 The IETF invites any interested party to bring to its attention any 1800 copyrights, patents or patent applications, or other proprietary rights 1801 which may cover technology that may be required to practice this 1802 standard. Please address the information to the IETF Executive 1803 Director. 1805 Copyright (C)The Internet Society (1999). All Rights Reserved 1807 This document and translations of it may be copied and furnished to 1808 others, and derivative works that comment on or otherwise explain it or 1809 assist in its implementation may be prepared, copied, published and 1810 distributed, in whole or in part, without restriction of any kind, 1811 provided that the above copyright notice and this paragraph are included 1812 on all such copies and derivative works. However, this document itself 1813 may not be modified in any way, such as by removing the copyright notice 1814 or references to the Internet Society or other Internet organizations, 1815 except as needed for the purpose of developing Internet standards in 1816 which case the procedures for copyrights defined in the Internet 1817 Standards process must be followed, or as required to translate it into 1818 languages other than English. 1820 The limited permissions granted above are perpetual and will not be 1821 revoked by the Internet Society or its successors or assigns. 1823 This document and the information contained herein is provided on an "AS 1824 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1825 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1826 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1827 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1828 FITNESS FOR A PARTICULAR PURPOSE.