idnits 2.17.1 draft-ietf-ipp-protocol-v11-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 43 longer pages, the longest (page 21) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 44 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 91 has weird spacing: '...ding of the O...' == Line 143 has weird spacing: '...ists of a mes...' == Line 156 has weird spacing: '...ding of the O...' == Line 165 has weird spacing: '...portant types...' == Line 166 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 (March 1, 2000) is 8814 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 23, but not defined == Missing Reference: 'IANA-CON' is mentioned on line 936, but not defined == Missing Reference: 'IPP-MOD' is mentioned on line 1105, but not defined == Missing Reference: 'IPP-PRO' is mentioned on line 1793, but not defined == Unused Reference: 'RFC822' is defined on line 1135, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 1138, but no explicit reference was found in the text == Unused Reference: 'RFC1179' is defined on line 1141, but no explicit reference was found in the text == Unused Reference: 'RFC1543' is defined on line 1144, but no explicit reference was found in the text == Unused Reference: 'RFC1759' is defined on line 1150, but no explicit reference was found in the text == Unused Reference: 'RFC1766' is defined on line 1153, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 1163, but no explicit reference was found in the text == Unused Reference: 'RFC2048' is defined on line 1166, but no explicit reference was found in the text == Unused Reference: 'RFC2184' is defined on line 1173, but no explicit reference was found in the text == Unused Reference: 'RFC2566' is defined on line 1190, but no explicit reference was found in the text == Unused Reference: 'SSL' is defined on line 1214, 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 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Possible downref: Non-RFC (?) normative reference: ref. 'SSL' Summary: 27 errors (**), 0 flaws (~~), 26 warnings (==), 3 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 Peerless Systems Networking 7 Randy Turner 8 2wire.com 9 John Wenn 10 Xerox Corporation 11 March 1, 2000 13 Internet Printing Protocol/1.1: Encoding and Transport 14 Copyright (C) The Internet Society (2000). All Rights Reserved. 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of [RFC2026]. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, and 21 its working groups. Note that other groups may also distribute working 22 documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed as 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document is one of a set of documents, which together describe all 38 aspects of a new Internet Printing Protocol (IPP). IPP is an application 39 level protocol that can be used for distributed printing using Internet 40 tools and technologies. This document defines the rules for encoding IPP 41 operations and IPP attributes into a new Internet mime media type called 42 "application/ipp". This document also defines the rules for 43 transporting over HTTP a message body whose Content-Type is 44 "application/ipp". This document defines a new scheme named 'ipp' for 45 identifying IPP printers and jobs. 47 The full set of IPP documents includes: 49 Design Goals for an Internet Printing Protocol [RFC2567] 50 Rationale for the Structure and Model and Protocol for the Internet 51 Printing Protocol [RFC2568] 52 Internet Printing Protocol/1.1: Model and Semantics [ipp-mod] 53 Internet Printing Protocol/1.1: Encoding and Transport (this 54 document) 55 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 56 Mapping between LPD and IPP Protocols [RFC2569] 58 The document, "Design Goals for an Internet Printing Protocol", takes a 59 broad look at distributed printing functionality, and it enumerates 60 real-life scenarios that help to clarify the features that need to be 61 included in a printing protocol for the Internet. It identifies 62 requirements for three types of users: end users, operators, and 63 administrators. It calls out a subset of end user requirements that are 64 satisfied in IPP/1.1. A few OPTIONAL operator operations have been added 65 to IPP/1.1. 67 The document, "Rationale for the Structure and Model and Protocol for 68 the Internet Printing Protocol", describes IPP from a high level view, 69 defines a roadmap for the various documents that form the suite of IPP 70 specification documents, and gives background and rationale for the IETF 71 working group's major decisions. 73 The document, "Internet Printing Protocol/1.1: Model and Semantics", 74 describes a simplified model with abstract objects, their attributes, 75 and their operations that are independent of encoding and transport. It 76 introduces a Printer and a Job object. The Job object optionally 77 supports multiple documents per Job. It also addresses security, 78 internationalization, and directory issues. 80 The document "Internet Printing Protocol/1.1: Implementer's Guide", 81 gives advice to implementers of IPP clients and IPP objects. 83 The document "Mapping between LPD and IPP Protocols" gives some advice 84 to implementers of gateways between IPP and LPD (Line Printer Daemon) 85 implementations. 87 Table of Contents 89 1. Introduction........................................................4 90 2. Conformance Terminology.............................................4 91 3. Encoding of the Operation Layer....................................4 92 3.1 Picture of the Encoding........................................5 93 3.2 Syntax of Encoding.............................................7 94 3.3 Version-number.................................................8 95 3.4 Operation-id...................................................8 96 3.5 Status-code....................................................9 97 3.6 Request-id.....................................................9 98 3.7 Tags...........................................................9 99 3.7.1 Delimiter Tags...........................................9 100 3.7.2 Value Tags..............................................11 101 3.8 Name-Length...................................................13 102 3.9 (Attribute) Name..............................................13 103 3.10Value Length..................................................15 104 3.11(Attribute) Value.............................................15 105 3.12Data..........................................................17 106 4. Encoding of Transport Layer........................................18 107 5. IPP URL Scheme.....................................................18 108 6. IANA Considerations................................................20 109 7. Internationalization Considerations................................20 110 8. Security Considerations............................................21 111 8.1 Security Conformance Requirements.............................21 112 8.1.1 Digest Authentication...................................21 113 8.1.2 Transport Layer Security (TLS)..........................22 114 8.2 Using IPP with TLS............................................22 115 9. Interoperability with IPP/1.0 Implementations......................22 116 9.1 The "version-number" Parameter................................23 117 9.2 Security and URL Schemes......................................23 118 10.References........................................................24 119 11.Author's Address..................................................26 120 12.Other Participants:...............................................27 121 13.Appendix A: Protocol Examples.....................................29 122 13.1Print-Job Request.............................................29 123 13.2Print-Job Response (successful)...............................31 124 13.3Print-Job Response (failure)..................................32 125 13.4Print-Job Response (success with attributes ignored)..........33 126 13.5Print-URI Request.............................................36 127 13.6Create-Job Request............................................37 128 13.7Get-Jobs Request..............................................38 129 13.8Get-Jobs Response.............................................39 130 14.Appendix B: Registration of MIME Media Type Information for 131 "application/ipp".....................................................41 132 15.Appendix C: Changes from IPP/1.0..................................42 133 16.Full Copyright Statement..........................................43 134 1. Introduction 136 This document contains the rules for encoding IPP operations and 137 describes two layers: the transport layer and the operation layer. 139 The transport layer consists of an HTTP/1.1 request or response. RFC 140 2616 [RFC2616] describes HTTP/1.1. This document specifies the HTTP 141 headers that an IPP implementation supports. 143 The operation layer consists of a message body in an HTTP request or 144 response. The document "Internet Printing Protocol/1.1: Model and 145 Semantics" [ipp-mod] defines the semantics of such a message body and 146 the supported values. This document specifies the encoding of an IPP 147 operation. The aforementioned document [ipp-mod] is henceforth referred 148 to as the "IPP model document" 150 2. Conformance Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 153 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 154 interpreted as described in RFC 2119 [RFC2119]. 156 3. Encoding of the Operation Layer 158 The operation layer MUST contain a single operation request or operation 159 response. Each request or response consists of a sequence of values and 160 attribute groups. Attribute groups consist of a sequence of attributes 161 each of which is a name and value. Names and values are ultimately 162 sequences of octets 164 The encoding consists of octets as the most primitive type. There are 165 several types built from octets, but three important types are 166 integers, character strings and octet strings, on which most other 167 data types are built. Every character string in this encoding MUST be a 168 sequence of characters where the characters are associated with some 169 charset and some natural language. A character string MUST be in 170 "reading order" with the first character in the value (according to 171 reading order) being the first character in the encoding. A character 172 string whose associated charset is US-ASCII whose associated natural 173 language is US English is henceforth called a US-ASCII-STRING. A 174 character string whose associated charset and natural language are 175 specified in a request or response as described in the model document is 176 henceforth called a LOCALIZED-STRING. An octet string MUST be in "IPP 177 model document order" with the first octet in the value (according to 178 the IPP model document order) being the first octet in the encoding 179 Every integer in this encoding MUST be encoded as a signed integer using 180 two's-complement binary encoding with big-endian format (also known as 181 "network order" and "most significant byte first"). The number of octets 182 for an integer MUST be 1, 2 or 4, depending on usage in the protocol. 183 Such one-octet integers, henceforth called SIGNED-BYTE, are used for the 184 version-number and tag fields. Such two-byte integers, henceforth called 185 SIGNED-SHORT are used for the operation-id, status-code and length 186 fields. Four byte integers, henceforth called SIGNED-INTEGER, are used 187 for values fields and the sequence number. 189 The following two sections present the operation layer in two ways 191 - informally through pictures and description 193 - formally through Augmented Backus-Naur Form (ABNF), as specified by 194 RFC 2234 [RFC2234] 196 3.1 Picture of the Encoding 198 The encoding for an operation request or response consists of: 200 ----------------------------------------------- 201 | version-number | 2 bytes - required 202 ----------------------------------------------- 203 | operation-id (request) | 204 | or | 2 bytes - required 205 | status-code (response) | 206 ----------------------------------------------- 207 | request-id | 4 bytes - required 208 ----------------------------------------------------------- 209 | xxx-attributes-tag | 1 byte | 210 ----------------------------------------------- |-0 or more 211 | xxx-attribute-sequence | n bytes | 212 ----------------------------------------------------------- 213 | end-of-attributes-tag | 1 byte - required 214 ----------------------------------------------- 215 | data | q bytes - optional 216 ----------------------------------------------- 218 The xxx-attributes-tag and xxx-attribute-sequence represents four 219 different values of "xxx", namely, operation, job, printer and 220 unsupported. The xxx-attributes-tag and an xxx-attribute-sequence 221 represent attribute groups in the model document. The xxx-attributes-tag 222 identifies the attribute group and the xxx-attribute-sequence contains 223 the attributes. 225 The expected sequence of xxx-attributes-tag and xxx-attribute-sequence 226 is specified in the IPP model document for each operation request and 227 operation response. 229 A request or response SHOULD contain each xxx-attributes-tag defined for 230 that request or response even if there are no attributes except for the 231 unsupported-attributes-tag which SHOULD be present only if the 232 unsupported-attribute-sequence is non-empty. A receiver of a request 233 MUST be able to process as equivalent empty attribute groups: 235 a) an xxx-attributes-tag with an empty xxx-attribute-sequence, 236 b) an expected but missing xxx-attributes-tag. 238 The data is omitted from some operations, but the end-of-attributes-tag 239 is present even when the data is omitted. Note, the xxx-attributes-tags 240 and end-of-attributes-tag are called 'delimiter-tags'. Note: the xxx- 241 attribute-sequence, shown above may consist of 0 bytes, according to the 242 rule below. 244 An xxx-attributes-sequence consists of zero or more compound-attributes. 246 ----------------------------------------------- 247 | compound-attribute | s bytes - 0 or more 248 ----------------------------------------------- 250 A compound-attribute consists of an attribute with a single value 251 followed by zero or more additional values. 253 Note: a 'compound-attribute' represents a single attribute in the model 254 document. The 'additional value' syntax is for attributes with 2 or 255 more values. 257 Each attribute consists of: 259 ----------------------------------------------- 260 | value-tag | 1 byte 261 ----------------------------------------------- 262 | name-length (value is u) | 2 bytes 263 ----------------------------------------------- 264 | name | u bytes 265 ----------------------------------------------- 266 | value-length (value is v) | 2 bytes 267 ----------------------------------------------- 268 | value | v bytes 269 ----------------------------------------------- 271 An additional value consists of: 273 ----------------------------------------------------------- 274 | value-tag | 1 byte | 275 ----------------------------------------------- | 276 | name-length (value is 0x0000) | 2 bytes | 277 ----------------------------------------------- |-0 or more 278 | value-length (value is w) | 2 bytes | 279 ----------------------------------------------- | 280 | value | w bytes | 281 ----------------------------------------------------------- 283 Note: an additional value is like an attribute whose name-length is 0. 285 >From the standpoint of a parsing loop, the encoding consists of: 287 ----------------------------------------------- 288 | version-number | 2 bytes - required 289 ----------------------------------------------- 290 | operation-id (request) | 291 | or | 2 bytes - required 292 | status-code (response) | 293 ----------------------------------------------- 294 | request-id | 4 bytes - required 295 ----------------------------------------------------------- 296 | tag (delimiter-tag or value-tag) | 1 byte | 297 ----------------------------------------------- |-0 or more 298 | empty or rest of attribute | x bytes | 299 ----------------------------------------------------------- 300 | end-of-attributes-tag | 2 bytes - required 301 ----------------------------------------------- 302 | data | y bytes - optional 303 ----------------------------------------------- 305 The value of the tag determines whether the bytes following the tag are: 307 - attributes 309 - data 311 - the remainder of a single attribute where the tag specifies the 312 type of the value. 314 3.2 Syntax of Encoding 316 The syntax below is ABNF [RFC2234] except 'strings of literals' MUST be 317 case sensitive. For example 'a' means lower case 'a' and not upper case 318 'A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields are represented 319 as '%x' values which show their range of values. 321 ipp-message = ipp-request / ipp-response 322 ipp-request = version-number operation-id request-id 323 *(xxx-attributes-tag xxx-attribute-sequence) end-of- 324 attributes-tag data 325 ipp-response = version-number status-code request-id 326 *(xxx-attributes-tag xxx-attribute-sequence) end-of- 327 attributes-tag data 328 xxx-attribute-sequence = *compound-attribute 330 xxx-attributes-tag = operation-attributes-tag / job-attributes-tag / 331 printer-attributes-tag / unsupported-attributes-tag 333 version-number = major-version-number minor-version-number 334 major-version-number = SIGNED-BYTE ; initially %d1 335 minor-version-number = SIGNED-BYTE ; initially %d0 337 operation-id = SIGNED-SHORT ; mapping from model defined below 338 status-code = SIGNED-SHORT ; mapping from model defined below 339 request-id = SIGNED-INTEGER ; whose value is > 0 341 compound-attribute = attribute *additional-values 343 attribute = value-tag name-length name value-length value 344 additional-values = value-tag zero-name-length value-length value 346 name-length = SIGNED-SHORT ; number of octets of 'name' 347 name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." ) 348 value-length = SIGNED-SHORT ; number of octets of 'value' 349 value = OCTET-STRING 351 data = OCTET-STRING 353 zero-name-length = %x00.00 ; name-length of 0 354 operation-attributes-tag = %x01 ; tag of 1 355 job-attributes-tag = %x02 ; tag of 2 356 printer-attributes-tag = %x04 ; tag of 4 357 unsupported- attributes-tag = %x05 ; tag of 5 358 end-of-attributes-tag = %x03 ; tag of 3 359 value-tag = %x10-FF 361 SIGNED-BYTE = BYTE 362 SIGNED-SHORT = 2BYTE 363 SIGNED-INTEGER = 4BYTE 364 DIGIT = %x30-39 ; "0" to "9" 365 LALPHA = %x61-7A ; "a" to "z" 366 BYTE = %x00-FF 367 OCTET-STRING = *BYTE 369 The syntax allows an xxx-attributes-tag to be present when the xxx- 370 attribute-sequence that follows is empty. The syntax is defined this way 371 to allow for the response of Get-Jobs where no attributes are returned 372 for some job-objects. Although it is RECOMMENDED that the sender not 373 send an xxx-attributes-tag if there are no attributes (except in the 374 Get-Jobs response just mentioned), the receiver MUST be able to decode 375 such syntax. 377 3.3 Version-number 379 The version-number MUST consist of a major and minor version-number, 380 each of which MUST be represented by a SIGNED-BYTE. The protocol 381 described in this document MUST have a major version-number of 1 (0x01) 382 and a minor version-number of 1 (0x01). The ABNF for these two bytes 383 MUST be %x01.01. 385 3.4 Operation-id 387 Operation-ids are defined as enums in the model document. An operation- 388 ids enum value MUST be encoded as a SIGNED-SHORT. 390 3.5 Status-code 392 Status-codes are defined as enums in the model document. A status-code 393 enum value MUST be encoded as a SIGNED-SHORT. 395 The status-code is an operation attribute in the model document. In the 396 protocol, the status-code is in a special position, outside of the 397 operation attributes. 399 If an IPP status-code is returned, then the HTTP Status-Code MUST be 200 400 (successful-ok). With any other HTTP Status-Code value, the HTTP 401 response MUST NOT contain an IPP message-body, and thus no IPP status- 402 code is returned. 404 3.6 Request-id 406 The request-id allows a client to match a response with a request. This 407 mechanism is unnecessary in HTTP, but may be useful when application/ipp 408 entity bodies are used in another context. 410 The request-id in a response MUST be the value of the request-id 411 received in the corresponding request. A client can set the request-id 412 in each request to a unique value or a constant value, such as 1, 413 depending on what the client does with the request-id returned in the 414 response. The value of the request-id MUST be greater than zero. 416 3.7 Tags 418 There are two kinds of tags: 420 - delimiter tags: delimit major sections of the protocol, namely 421 attributes and data 423 - value tags: specify the type of each attribute value 425 3.7.1 Delimiter Tags 427 The following table specifies the values for the delimiter tags: 429 Tag Value (Hex) Delimiter 431 0x00 reserved for definition in a future IETF 432 standards track document 433 0x01 operation-attributes-tag 434 0x02 job-attributes-tag 435 0x03 end-of-attributes-tag 436 0x04 printer-attributes-tag 437 0x05 unsupported-attributes-tag 438 0x06-0x0e reserved for future delimiters in IETF 439 standards track documents 440 0x0F reserved for future chunking-end-of-attributes- 441 tag for definition in a future IETF standards 442 track document 444 When an xxx-attributes-tag occurs in the protocol, it MUST mean that 445 zero or more following attributes up to the next delimiter tag are 446 attributes belonging to group xxx as defined in the model document, 447 where xxx is operation, job, printer, unsupported. 449 Doing substitution for xxx in the above paragraph, this means the 450 following. When an operation-attributes-tag occurs in the protocol, it 451 MUST mean that the zero or more following attributes up to the next 452 delimiter tag are operation attributes as defined in the model document. 453 When an job-attributes-tag occurs in the protocol, it MUST mean that the 454 zero or more following attributes up to the next delimiter tag are job 455 attributes or job template attributes as defined in the model document. 456 When a printer-attributes-tag occurs in the protocol, it MUST mean that 457 the zero or more following attributes up to the next delimiter tag are 458 printer attributes as defined in the model document. When an 459 unsupported-attributes-tag occurs in the protocol, it MUST mean that the 460 zero or more following attributes up to the next delimiter tag are 461 unsupported attributes as defined in the model document. 463 The operation-attributes-tag and end-of-attributes-tag MUST each occur 464 exactly once in an operation. The operation-attributes-tag MUST be the 465 first tag delimiter, and the end-of-attributes-tag MUST be the last tag 466 delimiter. If the operation has a document-content group, the document 467 data in that group MUST follow the end-of-attributes-tag. 469 Each of the other three xxx-attributes-tags defined above is OPTIONAL 470 in an operation and each MUST occur at most once in an operation, except 471 for job-attributes-tag in a Get-Jobs response which may occur zero or 472 more times. 474 The order and presence of delimiter tags for each operation request and 475 each operation response MUST be that defined in the model document. For 476 further details, see section 3.9 "(Attribute) Name" and 13 "Appendix A: 477 Protocol Examples". 479 A Printer MUST treat the reserved delimiter tags differently from 480 reserved value tags so that the Printer knows that there is an entire 481 attribute group that it doesn't understand as opposed to a single value 482 that it doesn't understand. 484 3.7.2 Value Tags 486 The remaining tables show values for the value-tag, which is the first 487 octet of an attribute. The value-tag specifies the type of the value of 488 the attribute. The following table specifies the "out-of-band" values 489 for the value-tag. 491 Tag Value (Hex) Meaning 493 0x10 unsupported 494 0x11 reserved for 'default' for definition in a future 495 IETF standards track document 496 0x12 unknown 497 0x13 no-value 498 0x14-0x1F reserved for "out-of-band" values in future IETF 499 standards track documents. 501 The "unsupported" value MUST be used in the attribute-sequence of an 502 error response for those attributes which the printer does not support. 503 The "default" value is reserved for future use of setting value back to 504 their default value. The "unknown" value is used for the value of a 505 supported attribute when its value is temporarily unknown. The "no- 506 value" value is used for a supported attribute to which no value has 507 been assigned, e.g. "job-k-octets-supported" has no value if an 508 implementation supports this attribute, but an administrator has not 509 configured the printer to have a limit. 511 The following table specifies the integer values for the value-tag: 513 Tag Value (Hex) Meaning 515 0x20 reserved for definition in a future IETF 516 standards track document 517 0x21 integer 518 0x22 boolean 519 0x23 enum 520 0x24-0x2F reserved for integer types for definition in 521 future IETF standards track documents 523 NOTE: 0x20 is reserved for "generic integer" if it should ever be 524 needed. 526 The following table specifies the octetString values for the value-tag: 528 Tag Value (Hex) Meaning 530 0x30 octetString with an unspecified format 531 0x31 dateTime 532 0x32 resolution 533 0x33 rangeOfInteger 534 0x34 reserved for definition in a future IETF 535 standards track document 536 0x35 textWithLanguage 537 0x36 nameWithLanguage 538 0x37-0x3F reserved for octetString type definitions in 539 future IETF standards track documents 541 The following table specifies the character-string values for the value- 542 tag: 544 Tag Value (Hex) Meaning 546 0x40 reserved for definition in a future IETF 547 standards track document 548 0x41 textWithoutLanguage 549 0x42 nameWithoutLanguage 550 0x43 reserved for definition in a future IETF 551 standards track document 552 0x44 keyword 553 0x45 uri 554 0x46 uriScheme 555 0x47 charset 556 0x48 naturalLanguage 557 0x49 mimeMediaType 558 0x4A-0x5F reserved for character string type definitions 559 in future IETF standards track documents 561 NOTE: 0x40 is reserved for "generic character-string" if it should ever 562 be needed. 564 NOTE: an attribute value always has a type, which is explicitly 565 specified by its tag; one such tag value is "nameWithoutLanguage". An 566 attribute's name has an implicit type, which is keyword. 568 The values 0x60-0xFF are reserved for future type definations in IETF 569 standards track documents. 571 The tag 0x7F is reserved for extending types beyond the 255 values 572 available with a single byte. A tag value of 0x7F MUST signify that the 573 first 4 bytes of the value field are interpreted as the tag value. 574 Note, this future extension doesn't affect parsers that are unaware of 575 this special tag. The tag is like any other unknown tag, and the value 576 length specifies the length of a value which contains a value that the 577 parser treats atomically. Values from 0x00 to 0x37777777 are reserved 578 for definition in future IETF standard track documents. The values 579 0x40000000 to0x7FFFFFFF are reserved for vendor extensions. 581 3.8 Name-Length 583 The name-length field MUST consist of a SIGNED-SHORT. This field MUST 584 specify the number of octets in the name field which follows the name- 585 length field, excluding the two bytes of the name-length field. 587 If a name-length field has a value of zero, the following name field 588 MUST be empty, and the following value MUST be treated as an additional 589 value for the preceding attribute. Within an attribute-sequence, if two 590 or more attributes have the same name, the attribute-sequence is mal- 591 formed (see [ipp-mod] section 3.1.3). The zero-length name is the only 592 mechanism for multi-valued attributes. 594 3.9 (Attribute) Name 596 Some operation elements are called parameters in the model document 597 [ipp-mod]. They MUST be encoded in a special position and they MUST NOT 598 appear as operation attributes. These parameters are: 600 - "version-number": The parameter named "version-number" in the IPP 601 model document MUST become the "version-number" field in the 602 operation layer request or response. 604 - "operation-id": The parameter named "operation-id" in the IPP model 605 document MUST become the "operation-id" field in the operation 606 layer request. 608 - "status-code": The parameter named "status-code" in the IPP model 609 document MUST become the "status-code" field in the operation layer 610 response. 612 - "request-id": The parameter named "request-id" in the IPP model 613 document MUST become the "request-id" field in the operation layer 614 request or response. 616 All Printer and Job objects are identified by a Uniform Resource 617 Identifier (URI) [RFC2396] so that they can be persistently and 618 unambiguously referenced. The notion of a URI is a useful concept, 619 however, until the notion of URI is more stable (i.e., defined more 620 completely and deployed more widely), it is expected that the URIs used 621 for IPP objects will actually be URLs [RFC1738] [RFC1808]. Since every 622 URL is a specialized form of a URI, even though the more generic term 623 URI is used throughout the rest of this document, its usage is intended 624 to cover the more specific notion of URL as well. 626 Some operation elements are encoded twice, once as the request-URI on 627 the HTTP Request-Line and a second time as a REQUIRED operation 628 attribute in the application/ipp entity. These attributes are the 629 target URI for the operation and are called printer-uri and job-uri. 630 Note: The target URI is included twice in an operation referencing the 631 same IPP object, but the two URIs NEED NOT be literally identical. One 632 can be a relative URI and the other can be an absolute URI. HTTP/1.1 633 allows clients to generate and send a relative URI rather than an 634 absolute URI. A relative URI identifies a resource with the scope of 635 the HTTP server, but does not include scheme, host or port. The 636 following statements characterize how URLs should be used in the mapping 637 of IPP onto HTTP/1.1: 639 1. Although potentially redundant, a client MUST supply the target of 640 the operation both as an operation attribute and as a URI at the 641 HTTP layer. The rationale for this decision is to maintain a 642 consistent set of rules for mapping application/ipp to possibly 643 many communication layers, even where URLs are not used as the 644 addressing mechanism in the transport layer. 645 2. Even though these two URLs might not be literally identical (one 646 being relative and the other being absolute), they MUST both 647 reference the same IPP object. 648 3. The URI in the HTTP layer is either relative or absolute and is 649 used by the HTTP server to route the HTTP request to the correct 650 resource relative to that HTTP server. The HTTP server need not be 651 aware of the URI within the operation request. 652 4. Once the HTTP server resource begins to process the HTTP request, 653 it might get the reference to the appropriate IPP Printer object 654 from either the HTTP URI (using to the context of the HTTP server 655 for relative URLs) or from the URI within the operation request; 656 the choice is up to the implementation. 657 5. HTTP URIs can be relative or absolute, but the target URI in the 658 operation MUST be an absolute URI. 660 The model document arranges the remaining attributes into groups for 661 each operation request and response. Each such group MUST be represented 662 in the protocol by an xxx-attribute-sequence preceded by the appropriate 663 xxx-attributes-tag (See the table below and section 13 "Appendix A: 664 Protocol Examples"). In addition, the order of these xxx-attributes-tags 665 and xxx-attribute-sequences in the protocol MUST be the same as in the 666 model document, but the order of attributes within each xxx-attribute- 667 sequence MUST be unspecified. The table below maps the model document 668 group name to xxx-attributes-sequence: 670 Model Document Group xxx-attributes-sequence 672 Operation Attributes operations-attributes-sequence 673 Job Template Attributes job-attributes-sequence 674 Job Object Attributes job-attributes-sequence 675 Unsupported Attributes unsupported- attributes-sequence 676 Requested Attributes (Get-Job- job-attributes-sequence 677 Attributes) 678 Requested Attributes (Get- printer-attributes-sequence 679 Printer-Attributes) 680 Document Content in a special position as described 681 above 683 If an operation contains attributes from more than one job object (e.g. 684 Get-Jobs response), the attributes from each job object MUST be in a 685 separate job-attribute-sequence, such that the attributes from the ith 686 job object are in the ith job-attribute-sequence. See Section 13 687 "Appendix A: Protocol Examples" for table showing the application of the 688 rules above. 690 3.10 Value Length 692 Each attribute value MUST be preceded by a SIGNED-SHORT, which MUST 693 specify the number of octets in the value which follows this length, 694 exclusive of the two bytes specifying the length. 696 For any of the types represented by binary signed integers, the sender 697 MUST encode the value in exactly four octets. 699 For any of the types represented by character-strings, the sender MUST 700 encode the value with all the characters of the string and without any 701 padding characters. 703 If a value-tag contains an "out-of-band" value defined in this document, 704 such as "unsupported", the value-length MUST be 0 and the value empty; 705 the value has no meaning when the value-tag has one of these "out-of- 706 band" values. However, the definitions of additional "out-of-band" 707 values in future documents are able to explicitly use the value field 708 and have a value-length that is non-zero, if there is a need for 709 additional information to be associated with the out-of-band value. 710 Unless the definition of an "out-of-band" value explicitly allows for a 711 value, the value-length MUST be 0 and the value empty. 713 3.11 (Attribute) Value 715 The syntax types and most of the details of the representation of 716 attribute values are defined in the IPP model document. The table below 717 augments the information in the model document, and defines the syntax 718 types from the model document in terms of the 5 basic types defined in 719 section 3 "Encoding of the Operation Layer". The 5 types are US-ASCII- 720 STRING, LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and 721 OCTET-STRING. 723 Syntax of Attribute Encoding 724 Value 726 textWithoutLanguage, LOCALIZED-STRING. 727 nameWithoutLanguage 729 textWithLanguage OCTET_STRING consisting of 4 fields: 730 a. a SIGNED-SHORT which is the number of 731 octets in the following field 732 b a value of type natural-language, 733 c. a SIGNED-SHORT which is the number of 734 octets in the following field, 735 d. a value of type textWithoutLanguage. 736 The length of a textWithLanguage value MUST be 4 737 + the value of field a + the value of field c. 739 nameWithLanguage OCTET_STRING consisting of 4 fields: 740 a. a SIGNED-SHORT which is the number of 741 octets in the following field 742 b. a value of type natural-language, 743 c. a SIGNED-SHORT which is the number of 744 octets in the following field 745 d. a value of type nameWithoutLanguage. 746 The length of a nameWithLanguage value MUST be 4 747 + the value of field a + the value of field c. 749 charset, US-ASCII-STRING. 750 naturalLanguage, 751 mimeMediaType, 752 keyword, uri, and 753 uriScheme 755 boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is 756 'true'. 758 integer and enum a SIGNED-INTEGER. 760 dateTime OCTET-STRING consisting of eleven octets whose 761 contents are defined by "DateAndTime" in RFC 762 1903 [RFC1903]. 764 resolution OCTET_STRING consisting of nine octets of 2 765 SIGNED-INTEGERs followed by a SIGNED-BYTE. The 766 first SIGNED-INTEGER contains the value of cross 767 feed direction resolution. The second SIGNED- 768 INTEGER contains the value of feed direction 769 resolution. The SIGNED-BYTE contains the units 770 value. 772 rangeOfInteger Eight octets consisting of 2 SIGNED-INTEGERs. 773 The first SIGNED-INTEGER contains the lower 774 bound and the second SIGNED-INTEGER contains the 775 upper bound. 777 Syntax of Attribute Encoding 778 Value 780 1setOf X Encoding according to the rules for an attribute 781 with more than 1 value. Each value X is encoded 782 according to the rules for encoding its type. 784 octetString OCTET-STRING 786 The type of the value in the model document determines the encoding in 787 the value and the value of the value-tag. 789 3.12 Data 791 The data part MUST include any data required by the operation 792 4. Encoding of Transport Layer 794 HTTP/1.1 [RFC2616] is the transport layer for this protocol. 796 The operation layer has been designed with the assumption that the 797 transport layer contains the following information: 799 - the URI of the target job or printer operation 801 - the total length of the data in the operation layer, either as a 802 single length or as a sequence of chunks each with a length. 804 It is REQUIRED that a printer implementation support HTTP over the IANA 805 assigned Well Known Port 631 (the IPP default port), though a printer 806 implementation may support HTTP over some other port as well. 808 Each HTTP operation MUST use the POST method where the request-URI is 809 the object target of the operation, and where the "Content-Type" of the 810 message-body in each request and response MUST be "application/ipp". The 811 message-body MUST contain the operation layer and MUST have the syntax 812 described in section 3.2 "Syntax of Encoding". A client implementation 813 MUST adhere to the rules for a client described for HTTP1.1 [RFC2616] . 814 A printer (server) implementation MUST adhere the rules for an origin 815 server described for HTTP1.1 [RFC2616]. 817 An IPP server sends a response for each request that it receives. If an 818 IPP server detects an error, it MAY send a response before it has read 819 the entire request. If the HTTP layer of the IPP server completes 820 processing the HTTP headers successfully, it MAY send an intermediate 821 response, such as "100 Continue", with no IPP data before sending the 822 IPP response. A client MUST expect such a variety of responses from an 823 IPP server. For further information on HTTP/1.1, consult the HTTP 824 documents [RFC2616]. 826 An HTTP server MUST support chunking for IPP requests, and an IPP client 827 MUST support chunking for IPP responses according to HTTP/1.1[RFC2616]. 828 Note: this rule causes a conflict with non-compliant implementations of 829 HTTP/1.1 that don't support chunking for POST methods, and this rule may 830 cause a conflict with non-compliant implementations of HTTP/1.1 that 831 don't support chunking for CGI scripts 833 5. IPP URL Scheme 835 The IPP/1.1 document defines a new scheme 'ipp' as the value of a URL 836 that identifies either an IPP printer object or an IPP job object. The 837 IPP attributes using the 'ipp' scheme are specified below. Because the 838 HTTP layer does not support the 'ipp' scheme, a client MUST map 'ipp' 839 URLs to 'http' URLs, and then follows the HTTP [RFC2616][RFC2617] rules 840 for constructing a Request-Line and HTTP headers. The mapping is simple 841 because the 'ipp' scheme implies all of the same protocol semantics as 842 that of the 'http' scheme [RFC2616], except that it represents a print 843 service and the implicit (default) port number that clients use to 844 connect to a server is port 631. 846 In the remainder of this section the term 'ipp-URL' means a URL whose 847 scheme is 'ipp' and whose implicit (default) port is 631. The term 848 'http-URL' means a URL whose scheme is 'http', and the term 'https-URL' 849 means a URL whose scheme is 'https', 851 A client and an IPP object (i.e. the server) MUST support the ipp-URL 852 value in the following IPP attributes. 853 job attributes: 854 job-uri 855 job-printer-uri 856 printer attributes: 857 printer-uri-supported 858 operation attributes: 859 job-uri 860 printer-uri 862 Each of the above attributes identifies a printer or job object. The 863 ipp-URL is intended as the value of the attributes in this list, and for 864 no other attributes. All of these attributes have a syntax type of 865 'uri', but there are attributes with a syntax type of 'uri' that do not 866 use the 'ipp' scheme, e.g. 'job-more-info'. 868 If a printer registers its URL with a directory service, the printer 869 MUST register an ipp-URL. 871 User interfaces are beyond the scope of this document. But if software 872 exposes the ipp-URL values of any of the above five attributes to a 873 human user, it is REQUIRED that the human see the ipp-URL as is. 875 When a client sends a request, it MUST convert a target ipp-URL to a 876 target http-URL for the HTTP layer according to the following rules: 877 1. change the 'ipp' scheme to 'http' 878 2. add an explicit port 631 if the URL does not contain an explicit 879 port. Note: port 631 is the IANA assigned Well Known Port for the 880 'ipp' scheme. 882 The client MUST use the target http-URL in both the HTTP Request-Line 883 and HTTP headers, as specified by HTTP[RFC2616][RFC2617] . However, the 884 client MUST use the target ipp-URL for the value of the "printer-uri" or 885 "job-uri" operation attribute within the application/ipp body of the 886 request. The server MUST use the ipp-URL for the value of the "printer- 887 uri", "job-uri" or "printer-uri-supported" attributes within the 888 application/ipp body of the response. 890 For example, when an IPP client sends a request directly (i.e. no proxy) 891 to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a TCP 892 connection to port 631 (the ipp implicit port) on the host "myhost.com" 893 and sends the following data: 895 POST /myprinter/myqueue HTTP/1.1 896 Host: myhost.com:631 897 Content-type: application/ipp 898 Transfer-Encoding: chunked 899 ... 900 "printer-uri" "ipp://myhost.com/myprinter/myqueue" 901 (encoded in application/ipp message body) 902 ... 904 As another example, when an IPP client sends the same request as above 905 via a proxy "myproxy.com", it opens a TCP connection to the proxy port 906 8080 on the proxy host "myproxy.com" and sends the following data: 908 POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 909 Host: myhost.com:631 910 Content-type: application/ipp 911 Transfer-Encoding: chunked 912 ... 913 "printer-uri" "ipp://myhost.com/myprinter/myqueue" 914 (encoded in application/ipp message body) 915 ... 917 The proxy then connects to the IPP origin server with headers that are 918 the same as the "no-proxy" example above. 920 6. IANA Considerations 922 This section describes the procedures for allocating encoding for the 923 following IETF standards track extensions and vendor extensions to the 924 IPP/1.1 Encoding and Transport document: 926 1. attribute syntaxes - see [ipp-mod] section 6.3 927 2. attribute groups - see [ipp-mod] section 6.5 928 3. out-of-band attribute values - see [ipp-mod] section 6.7 930 These extensions follow the "type2" registration procedures defined in 931 [ipp-mod] section 6. Extensions registered for use with IPP/1.1 are 932 OPTIONAL for client and IPP object conformance to the IPP/1.1 Encoding 933 and Transport document. 935 These extension procedures are aligned with the guidelines as set forth 936 by the IESG [IANA-CON]. The [ipp-mod] Section 11 describes how to 937 propose new registrations for consideration. IANA will reject 938 registration proposals that leave out required information or do not 939 follow the appropriate format described in [ipp-mod] Section 11. The 940 IPP/1.1 Encoding and Transport document may also be extended by an 941 appropriate RFC that specifies any of the above extensions. 943 7. Internationalization Considerations 945 See the section on "Internationalization Considerations" in the document 946 "Internet Printing Protocol/1.1: Model and Semantics" [ipp-mod] for 947 information on internationalization. This document adds no additional 948 issues. 950 8. Security Considerations 952 The IPP Model and Semantics document [ipp-mod] discusses high level 953 security requirements (Client Authentication, Server Authentication and 954 Operation Privacy). Client Authentication is the mechanism by which the 955 client proves its identity to the server in a secure manner. Server 956 Authentication is the mechanism by which the server proves its identity 957 to the client in a secure manner. Operation Privacy is defined as a 958 mechanism for protecting operations from eavesdropping. 960 8.1 Security Conformance Requirements 962 This section defines the security requirements for IPP clients and IPP 963 objects. 965 8.1.1 Digest Authentication 967 IPP clients MUST support: 969 Digest Authentication [RFC2617]. 971 MD5 and MD5-sess MUST be implemented and supported. 973 The Message Integrity feature NEED NOT be used. 975 IPP Printers SHOULD support: 977 Digest Authentication [RFC2617]. 979 MD5 and MD5-sess MUST be implemented and supported. 981 The Message Integrity feature NEED NOT be used. 983 The reasons that IPP Printers SHOULD (rather than MUST) support Digest 984 Authentication are: 986 1.While Client Authentication is important, there is a certain class of 987 printer devices where it does not make sense. Specifically, a low- 988 end device with limited ROM space and low paper throughput may not 989 need Client Authentication. This class of device typically requires 990 firmware designers to make trade-offs between protocols and 991 functionality to arrive at the lowest-cost solution possible. 992 Factored into the designer's decisions is not just the size of the 993 code, but also the testing, maintenance, usefulness, and time-to- 994 market impact for each feature delivered to the customer. Forcing 995 such low-end devices to provide security in order to claim IPP/1.1 996 conformance would not make business sense and could potentially stall 997 the adoption of the standard. 999 2.Print devices that have high-volume throughput and have available ROM 1000 space have a compelling argument to provide support for Client 1001 Authentication that safeguards the device from unauthorized access. 1002 These devices are prone to a high loss of consumables and paper if 1003 unauthorized access should occur. 1005 8.1.2 Transport Layer Security (TLS) 1007 IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246] for 1008 Server Authentication and Operation Privacy. IPP Printers MAY also 1009 support TLS for Client Authentication. If an IPP Printer supports TLS, 1010 it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as 1011 mandated by RFC 2246 [RFC2246]. All other cipher suites are OPTIONAL. 1012 An IPP Printer MAY support Basic Authentication (described in HTTP/1.1 1013 [RFC2617]) for Client Authentication if the channel is secure. TLS with 1014 the above mandated cipher suite can provide such a secure channel. 1016 If a IPP client supports TLS, it MUST support the 1017 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246 1018 [RFC2246]. All other cipher suites are OPTIONAL. 1020 The IPP Model and Semantics document defines two printer attributes 1021 ("uri-authentication-supported" and "uri-security-supported") that the 1022 client can use to discover the security policy of a printer. That 1023 document also outlines IPP-specific security considerations and should 1024 be the primary reference for security implications with regard to the 1025 IPP protocol itself. For backward compatibility with IPP version 1.0, 1026 IPP clients and printers may also support SSL3 [ssl]. This is in 1027 addition to the security required in this document. 1029 8.2 Using IPP with TLS 1031 IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism [http- 1032 tls]. An initial IPP request never uses TLS. The client requests a 1033 secure TLS connection by using the HTTP "Upgrade" header, while the 1034 server agrees in the HTTP response. The switch to TLS occurs either 1035 because the server grants the client's request to upgrade to TLS, or a 1036 server asks to switch to TLS in its response. Secure communication 1037 begins with a server's response to switch to TLS. 1039 9. Interoperability with IPP/1.0 Implementations 1041 It is beyond the scope of this specification to mandate conformance with 1042 previous versions. IPP/1.1 was deliberately designed, however, to make 1043 supporting previous versions easy. It is worth noting that, at the time 1044 of composing this specification (1999), we would expect IPP/1.1 Printer 1045 implementations to: 1047 understand any valid request in the format of IPP/1.0, or 1.1; 1049 respond appropriately with a response containing the same "version- 1050 number" parameter value used by the client in the request. 1052 And we would expect IPP/1.1 clients to: 1054 understand any valid response in the format of IPP/1.0, or 1.1. 1056 9.1 The "version-number" Parameter 1058 The following are rules regarding the "version-number" parameter (see 1059 section 3.3): 1061 1. Clients MUST send requests containing a "version-number" parameter 1062 with a '1.1' value and SHOULD try supplying alternate version 1063 numbers if they receive a 'server-error-version-not-supported' 1064 error return in a response. 1066 2. IPP objects MUST accept requests containing a "version-number" 1067 parameter with a '1.1' value (or reject the request for reasons 1068 other than 'server-error-version-not-supported'). 1070 3. It is recommended that IPP objects accept any request with the 1071 major version '1' (or reject the request for reasons other than 1072 'server-error-version-not-supported'). See [ipp-mod] "versions" 1073 sub-section. 1075 4. In any case, security MUST NOT be compromised when a client 1076 supplies a lower "version-number" parameter in a request. For 1077 example, if an IPP/1.1 conforming Printer object accepts version 1078 '1.0' requests and is configured to enforce Digest Authentication, 1079 it MUST do the same for a version '1.0' request. 1081 9.2 Security and URL Schemes 1083 The following are rules regarding security, the "version-number" 1084 parameter, and the URL scheme supplied in target attributes and 1085 responses: 1087 1. When a client supplies a request, the "printer-uri" or "job-uri" 1088 target operation attribute MUST have the same scheme as that 1089 indicated in one of the values of the "printer-uri-supported" 1090 Printer attribute. 1092 2. When the server returns the "job-printer-uri" or "job-uri" Job 1093 Description attributes, it SHOULD return the same scheme ('ipp', 1094 'https', 'http', etc.) that the client supplied in the "printer- 1095 uri" or "job-uri" target operation attributes in the Get-Job- 1096 Attributes or Get-Jobs request, rather than the scheme used when 1097 the job was created. However, when a client requests job 1098 attributes using the Get-Job-Attributes or Get-Jobs operations, 1099 the jobs and job attributes that the server returns depends on: 1100 (1) the security in effect when the job was created, (2) the 1101 security in effect in the query request, and (3) the security 1102 policy in force. 1104 3. It is recommended that if a server registers a non-secure ipp-URL 1105 with a directory service (see [IPP-MOD] "Generic Directory Schema" 1106 Appendix), then it also register an http-URL for interoperability 1107 with IPP/1.0 clients (see section 9). 1109 4. In any case, security MUST NOT be compromised when a client 1110 supplies an 'http' or other non-secure URL scheme in the target 1111 "printer-uri" and "job-uri" operation attributes in a request. 1113 10. References 1115 [dpa] ISO/IEC 10175 Document Printing Application (DPA), June 1996. 1117 [http-tls]R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1", 1118 , June 1999. 1120 [iana]IANA Registry of Coded Character Sets: ftp://ftp.isi.edu/in- 1121 notes/iana/assignments/character-sets. 1123 [ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.1: 1124 Implementer's Guide", draft-ietf-ipp-implementers-guide-v11- 1125 00.txt, work in progress, September 27, 1999. 1127 [ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1128 "Internet Printing Protocol/1.1: Model and Semantics", , March 1, 2000. 1131 [ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet 1132 Printing Protocol/1.1: Encoding and Transport", draft-ietf-ipp- 1133 protocol-v11-05.txt, March 1, 2000. 1135 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text 1136 Messages", RFC 822, August 1982. 1138 [RFC1123] Braden, S., "Requirements for Internet Hosts - Application 1139 and Support", RFC 1123, October, 1989. 1141 [RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" 1142 RFC 1179, August 1990. 1144 [RFC1543] Postel, J., "Instructions to RFC Authors", RFC 1543, October 1145 1993. 1147 [RFC1738] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform 1148 Resource Locators (URL)", RFC 1738, December, 1994. 1150 [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and 1151 Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. 1153 [RFC1766] H. Alvestrand, " Tags for the Identification of Languages", 1154 RFC 1766, March 1995. 1156 [RFC1808] R. Fielding, "Relative Uniform Resource Locators", RFC1808, 1157 June 1995. 1159 [RFC1903] J. Case, et al. "Textual Conventions for Version 2 of the 1160 Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1161 1996. 1163 [RFC2046] N. Freed & N. Borenstein, Multipurpose Internet Mail 1164 Extensions (MIME) Part Two: Media Types. November 1996, RFC 2046. 1166 [RFC2048] N. Freed, J. Klensin & J. Postel. Multipurpose Internet Mail 1167 Extension (MIME) Part Four: Registration Procedures. November 1168 1996 (Also BCP0013), RFC 2048. 1170 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1171 Requirement Levels", RFC 2119 , March 1997. 1173 [RFC2184] N. Freed, K. Moore, "MIME Parameter Value and Encoded Word 1174 Extensions: Character Sets, Languages, and Continuations", RFC 1175 2184, August 1997. 1177 [RFC2234] D. Crocker et al., "Augmented BNF for Syntax Specifications: 1178 ABNF", RFC 2234. November 1997. 1180 [RFC2246] T. Dierks et al., "The TLS Protocol", RFC 2246. January 1999. 1182 [RFC2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform 1183 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1184 1998. 1186 [RFC2565] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet 1187 Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1188 1999. 1190 [RFC2566] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1191 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, 1192 April, 1999. 1194 [RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", 1195 RFC2567, April 1999. 1197 [RFC2568] Zilles, S., "Rationale for the Structure and Model and 1198 Protocol for the Internet Printing Protocol", RC 2568, April 1199 1999. 1201 [RFC2569] Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping 1202 between LPD and IPP Protocols RFC 2569, April 1999. 1204 [RFC2616] 1205 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1206 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 1207 RFC 2616, June 1999. 1209 [RFC2617] 1210 J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, 1211 A. Luotonen, L. Stewart, "HTTP Authentication: Basic and Digest 1212 Access Authentication", RFC 2617, June 1999. 1214 [SSL] 1215 Netscape, The SSL Protocol, Version 3, (Text version 3.02), 1216 November 1996. 1218 11. Author's Address 1220 Robert Herriot (editor) Paul Moore 1221 Xerox Corporation Peerless Systems Networking 1222 3400 Hillview Ave., Bldg #1 10900 NE 8th St #900 1223 Palo Alto, CA 94304 Bellevue, WA 98004 1225 Phone: 650-813-7696 Phone: 425-462-5852 1226 Fax: 650-813-6860 1227 Email: Email: pmoore@peerless.com 1228 robert.herriot@pahv.xerox.com 1230 Sylvan Butler Randy Turner 1231 Hewlett-Packard 2Wire, Inc. 1232 11311 Chinden Blvd. 694 Tasman Dr. 1233 Boise, ID 83714 Milpitas, CA 95035 1235 Phone: 208-396-6000 Phone: 408-546-1273 1236 Fax: 208-396-3457 1237 Email: sbutler@boi.hp.com 1239 John Wenn 1240 Xerox Corporation 1241 737 Hawaii St 1242 El Segundo, CA 90245 1244 IPP Mailing List: ipp@pwg.org Phone: 310-333-5764 1245 IPP Mailing List Subscription: Fax: 310-333-5514 1246 ipp-request@pwg.org 1247 IPP Web Page: Email: jwenn@cp10.es.xerox.com 1248 http://www.pwg.org/ipp/ 1249 12. Other Participants: 1251 Chuck Adams - Tektronix Shivaun Albright - HP 1252 Stefan Andersson - Axis Jeff Barnett - IBM 1253 Ron Bergman - Hitachi Koki Imaging Dennis Carney - IBM 1254 Systems 1255 Keith Carter - IBM Angelo Caruso - Xerox 1256 Rajesh Chawla - TR Computing Nancy Chen - Okidata 1257 Solutions 1258 Josh Cohen - Microsoft Jeff Copeland - QMS 1259 Andy Davidson - Tektronix Roger deBry - IBM 1260 Maulik Desai - Auco Mabry Dozier - QMS 1261 Lee Farrell - Canon Information Satoshi Fujitami - Ricoh 1262 Systems 1263 Steve Gebert - IBM Sue Gleeson - Digital 1264 Charles Gordon - Osicom Brian Grimshaw - Apple 1265 Jerry Hadsell - IBM Richard Hart - Digital 1266 Tom Hastings - Xerox Henrik Holst - I-data 1267 Stephen Holmstead Zhi-Hong Huang - Zenographics 1268 Scott Isaacson - Novell Babek Jahromi - Microsoft 1269 Swen Johnson - Xerox David Kellerman - Northlake 1270 Software 1271 Robert Kline - TrueSpectra Charles Kong - Panasonic 1272 Carl Kugler - IBM Dave Kuntz - Hewlett-Packard 1273 Takami Kurono - Brother Rick Landau - Digital 1274 Scott Lawrence - Agranot Systems Greg LeClair - Epson 1275 Dwight Lewis - Lexmark Harry Lewis - IBM 1276 Tony Liao - Vivid Image Roy Lomicka - Digital 1277 Pete Loya - HP Ray Lutz - Cognisys 1278 Mike MacKay - Novell, Inc. David Manchala - Xerox 1279 Carl-Uno Manros - Xerox Jay Martin - Underscore 1280 Stan McConnell - Xerox Larry Masinter - Xerox 1281 Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft 1282 Ira McDonald - High North Inc. Mike Moldovan - G3 Nova 1283 Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh 1284 Pat Nogay - IBM Ron Norton - Printronics 1285 Hugo Parra, Novell Bob Pentecost - Hewlett-Packard 1286 Patrick Powell - Astart Jeff Rackowitz - Intermec 1287 Technologies 1288 Eric Random - Peerless Rob Rhoads - Intel 1289 Xavier Riley - Xerox Gary Roberts - Ricoh 1290 David Roach - Unisys Stuart Rowley - Kyocera 1291 Yuji Sasaki - Japan Computer Richard Schneider - Epson 1292 Industry 1293 Kris Schoff - HP Katsuaki Sekiguchi - Canon 1294 Information Systems 1295 Bob Setterbo - Adobe Gail Songer - Peerless 1296 Hideki Tanaka - Cannon Information Devon Taylor - Novell, Inc. 1297 Systems 1298 Mike Timperman - Lexmark Atsushi Uchino - Epson 1299 Shigeru Ueda - Canon Bob Von Andel - Allegro Software 1300 William Wagner - NetSilicon/DPI Jim Walker - DAZEL 1301 Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard 1302 Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc. 1304 Jasper Wong - Xionics Don Wright - Lexmark 1305 Michael Wu - Heidelberg Digital Rick Yardumian - Xerox 1306 Michael Yeung - Canon Information Lloyd Young - Lexmark 1307 Systems 1308 Atsushi Yuki - Kyocera Peter Zehler - Xerox 1309 William Zhang- Canon Information Frank Zhao - Panasonic 1310 Systems 1311 Steve Zilles - Adobe Rob Zirnstein - Canon Information 1312 Systems 1314 13. Appendix A: Protocol Examples 1316 13.1 Print-Job Request 1318 The following is an example of a Print-Job request with job-name, 1319 copies, and sides specified. The "ipp-attribute-fidelity" attribute is 1320 set to 'true' so that the print request will fail if the "copies" or the 1321 "sides" attribute are not supported or their values are not supported. 1323 Octets Symbolic Value Protocol field 1325 0x0101 1.1 version-number 1326 0x0002 Print-Job operation-id 1327 0x00000001 1 request-id 1328 0x01 start operation-attributes operation-attributes-tag 1329 0x47 charset type value-tag 1330 0x0012 name-length 1331 attributes- attributes-charset name 1332 charset 1333 0x0008 value-length 1334 us-ascii US-ASCII value 1335 0x48 natural-language type value-tag 1336 0x001B name-length 1337 attributes- attributes-natural-language name 1338 natural- 1339 language 1340 0x0005 value-length 1341 en-us en-US value 1342 0x45 uri type value-tag 1343 0x000B name-length 1344 printer-uri printer-uri name 1345 0x0015 value-length 1346 ipp://forest/p printer pinetree value 1347 inetree 1348 0x42 nameWithoutLanguage type value-tag 1349 0x0008 name-length 1350 job-name job-name name 1351 0x0006 value-length 1352 foobar foobar value 1353 0x22 boolean type value-tag 1354 0x0016 name-length 1355 ipp-attribute- ipp-attribute-fidelity name 1356 fidelity 1357 0x0001 value-length 1358 0x01 true value 1359 0x02 start job-attributes job-attributes-tag 1360 0x21 integer type value-tag 1361 0x0006 name-length 1362 copies copies name 1363 0x0004 value-length 1364 0x00000014 20 value 1365 0x44 keyword type value-tag 1366 0x0005 name-length 1367 sides sides name 1368 0x0013 value-length 1369 two-sided- two-sided-long-edge value 1370 long-edge 1371 0x03 end-of-attributes end-of-attributes-tag 1372 %!PS... data 1373 13.2 Print-Job Response (successful) 1375 Here is an example of a successful Print-Job response to the previous 1376 Print-Job request. The printer supported the "copies" and "sides" 1377 attributes and their supplied values. The status code returned is 1378 'successful-ok'. 1380 Octets Symbolic Value Protocol field 1382 0x0101 1.1 version-number 1383 0x0000 successful-ok status-code 1384 0x00000001 1 request-id 1385 0x01 start operation-attributes operation-attributes-tag 1386 0x47 charset type value-tag 1387 0x0012 name-length 1388 attributes- attributes-charset name 1389 charset 1390 0x0008 value-length 1391 us-ascii US-ASCII value 1392 0x48 natural-language type value-tag 1393 0x001B name-length 1394 attributes- attributes-natural- name 1395 natural-language language 1396 0x0005 value-length 1397 en-us en-US value 1398 0x41 textWithoutLanguage type value-tag 1399 0x000E name-length 1400 status-message status-message name 1401 0x000D value-length 1402 successful-ok successful-ok value 1403 0x02 start job-attributes job-attributes-tag 1404 0x21 integer value-tag 1405 0x0006 name-length 1406 job-id job-id name 1407 0x0004 value-length 1408 147 147 value 1409 0x45 uri type value-tag 1410 0x0007 name-length 1411 job-uri job-uri name 1412 0x0019 value-length 1413 ipp://forest/pin job 123 on pinetree value 1414 etree/123 1415 0x23 enum type value-tag 1416 0x0009 name-length 1417 job-state job-state name 1418 0x0004 value-length 1419 0x0003 pending value 1420 0x03 end-of-attributes end-of-attributes-tag 1421 13.3 Print-Job Response (failure) 1423 Here is an example of an unsuccessful Print-Job response to the previous 1424 Print-Job request. It fails because, in this case, the printer does not 1425 support the "sides" attribute and because the value '20' for the 1426 "copies" attribute is not supported. Therefore, no job is created, and 1427 neither a "job-id" nor a "job-uri" operation attribute is returned. The 1428 error code returned is 'client-error-attributes-or-values-not-supported' 1429 (0x040B). 1431 Octets Symbolic Value Protocol field 1433 0x0101 1.1 version-number 1434 0x040B client-error-attributes-or- status-code 1435 values-not-supported 1436 0x00000001 1 request-id 1437 0x01 start operation-attributes operation-attribute tag 1438 0x47 charset type value-tag 1439 0x0012 name-length 1440 attributes- attributes-charset name 1441 charset 1442 0x0008 value-length 1443 us-ascii US-ASCII value 1444 0x48 natural-language type value-tag 1445 0x001B name-length 1446 attributes- attributes-natural-language name 1447 natural- 1448 language 1449 0x0005 value-length 1450 en-us en-US value 1451 0x41 textWithoutLanguage type value-tag 1452 0x000E name-length 1453 status- status-message name 1454 message 1455 0x002F value-length 1456 client-error- client-error-attributes-or- value 1457 attributes- values-not-supported 1458 or-values- 1459 not-supported 1460 0x05 start unsupported-attributes unsupported-attributes tag 1461 0x21 integer type value-tag 1462 0x0006 name-length 1463 copies copies name 1464 0x0004 value-length 1465 0x00000014 20 value 1466 0x10 unsupported (type) value-tag 1467 0x0005 name-length 1468 sides sides name 1469 0x0000 value-length 1470 0x03 end-of-attributes end-of-attributes-tag 1471 13.4 Print-Job Response (success with attributes ignored) 1473 Here is an example of a successful Print-Job response to a Print-Job 1474 request like the previous Print-Job request, except that the value of 1475 'ipp-attribute-fidelity' is false. The print request succeeds, even 1476 though, in this case, the printer supports neither the "sides" attribute 1477 nor the value '20' for the "copies" attribute. Therefore, a job is 1478 created, and both a "job-id" and a "job-uri" operation attribute are 1479 returned. The unsupported attributes are also returned in an Unsupported 1480 Attributes Group. The error code returned is 'successful-ok-ignored-or- 1481 substituted-attributes' (0x0001). 1483 Octets Symbolic Value Protocol field 1485 0x0101 1.1 version-number 1486 0x0001 successful-ok-ignored-or- status-code 1487 substituted-attributes 1488 0x00000001 1 request-id 1489 0x01 start operation-attributes operation-attributes-tag 1490 0x47 charset type value-tag 1491 0x0012 name-length 1492 attributes- attributes-charset name 1493 charset 1494 0x0008 value-length 1495 us-ascii US-ASCII value 1496 0x48 natural-language type value-tag 1497 0x001B name-length 1498 attributes- attributes-natural- name 1499 natural-language language 1500 0x0005 value-length 1501 en-us en-US value 1502 0x41 textWithoutLanguage type value-tag 1503 0x000E name-length 1504 status-message status-message name 1505 0x002F value-length 1506 successful-ok- successful-ok-ignored-or- value 1507 ignored-or- substituted-attributes 1508 substituted- 1509 attributes 1510 0x05 start unsupported- unsupported-attributes 1511 attributes tag 1512 0x21 integer type value-tag 1513 0x0006 name-length 1514 copies copies name 1515 0x0004 value-length 1516 0x00000014 20 value 1517 0x10 unsupported (type) value-tag 1518 0x0005 name-length 1519 sides sides name 1520 0x0000 value-length 1521 0x02 start job-attributes job-attributes-tag 1522 0x21 integer value-tag 1523 0x0006 name-length 1524 job-id job-id name 1525 0x0004 value-length 1526 147 147 value 1527 0x45 uri type value-tag 1528 0x0007 name-length 1529 job-uri job-uri name 1530 0x0019 value-length 1531 ipp://forest/pin job 123 on pinetree value 1532 etree/123 1533 0x23 enum type value-tag 1534 0x0009 name-length 1535 job-state job-state name 1536 0x0004 value-length 1537 Octets Symbolic Value Protocol field 1539 0x0003 pending value 1540 0x03 end-of-attributes end-of-attributes-tag 1541 13.5 Print-URI Request 1543 The following is an example of Print-URI request with copies and job- 1544 name parameters: 1546 Octets Symbolic Value Protocol field 1547 0x0101 1.1 version-number 1548 0x0003 Print-URI operation-id 1549 0x00000001 1 request-id 1550 0x01 start operation-attributes operation-attributes-tag 1551 0x47 charset type value-tag 1552 0x0012 name-length 1553 attributes- attributes-charset name 1554 charset 1555 0x0008 value-length 1556 us-ascii US-ASCII value 1557 0x48 natural-language type value-tag 1558 0x001B name-length 1559 attributes- attributes-natural-language name 1560 natural- 1561 language 1562 0x0005 value-length 1563 en-us en-US value 1564 0x45 uri type value-tag 1565 0x000B name-length 1566 printer-uri printer-uri name 1567 0x0015 value-length 1568 ipp://forest/ printer pinetree value 1569 pinetree 1570 0x45 uri type value-tag 1571 0x000C name-length 1572 document-uri document-uri name 1573 0x0011 value-length 1574 ftp://foo.com ftp://foo.com/foo value 1575 /foo 1576 0x42 nameWithoutLanguage type value-tag 1577 0x0008 name-length 1578 job-name job-name name 1579 0x0006 value-length 1580 foobar foobar value 1581 0x02 start job-attributes job-attributes-tag 1582 0x21 integer type value-tag 1583 0x0006 name-length 1584 copies copies name 1585 0x0004 value-length 1586 0x00000001 1 value 1587 0x03 end-of-attributes end-of-attributes-tag 1588 13.6 Create-Job Request 1590 The following is an example of Create-Job request with no parameters and 1591 no attributes: 1593 Octets Symbolic Value Protocol field 1594 0x0101 1.1 version-number 1595 0x0005 Create-Job operation-id 1596 0x00000001 1 request-id 1597 0x01 start operation-attributes operation-attributes-tag 1598 0x47 charset type value-tag 1599 0x0012 name-length 1600 attributes- attributes-charset name 1601 charset 1602 0x0008 value-length 1603 us-ascii US-ASCII value 1604 0x48 natural-language type value-tag 1605 0x001B name-length 1606 attributes- attributes-natural-language name 1607 natural- 1608 language 1609 0x0005 value-length 1610 en-us en-US value 1611 0x45 uri type value-tag 1612 0x000B name-length 1613 printer-uri printer-uri name 1614 0x0015 value-length 1615 ipp://forest/p printer pinetree value 1616 inetree 1617 0x03 end-of-attributes end-of-attributes-tag 1618 13.7 Get-Jobs Request 1620 The following is an example of Get-Jobs request with parameters but no 1621 attributes: 1623 Octets Symbolic Value Protocol field 1624 0x0101 1.1 version-number 1625 0x000A Get-Jobs operation-id 1626 0x00000123 0x123 request-id 1627 0x01 start operation-attributes operation-attributes-tag 1628 0x47 charset type value-tag 1629 0x0012 name-length 1630 attributes- attributes-charset name 1631 charset 1632 0x0008 value-length 1633 us-ascii US-ASCII value 1634 0x48 natural-language type value-tag 1635 0x001B name-length 1636 attributes- attributes-natural-language name 1637 natural- 1638 language 1639 0x0005 value-length 1640 en-us en-US value 1641 0x45 uri type value-tag 1642 0x000B name-length 1643 printer-uri printer-uri name 1644 0x0015 value-length 1645 ipp://forest/pi printer pinetree value 1646 netree 1647 0x21 integer type value-tag 1648 0x0005 name-length 1649 limit limit name 1650 0x0004 value-length 1651 0x00000032 50 value 1652 0x44 keyword type value-tag 1653 0x0014 name-length 1654 requested- requested-attributes name 1655 attributes 1656 0x0006 value-length 1657 job-id job-id value 1658 0x44 keyword type value-tag 1659 0x0000 additional value name-length 1660 0x0008 value-length 1661 job-name job-name value 1662 0x44 keyword type value-tag 1663 0x0000 additional value name-length 1664 0x000F value-length 1665 document-format document-format value 1666 0x03 end-of-attributes end-of-attributes-tag 1667 13.8 Get-Jobs Response 1669 The following is an of Get-Jobs response from previous request with 3 1670 jobs. The Printer returns no information about the second job (because 1671 of security reasons): 1673 Octets Symbolic Value Protocol field 1674 0x0101 1.1 version-number 1675 0x0000 successful-ok status-code 1676 0x00000123 0x123 request-id (echoed 1677 back) 1678 0x01 start operation-attributes operation-attribute-tag 1679 0x47 charset type value-tag 1680 0x0012 name-length 1681 attributes- attributes-charset name 1682 charset 1683 0x000A value-length 1684 ISO-8859-1 ISO-8859-1 value 1685 0x48 natural-language type value-tag 1686 0x001B name-length 1687 attributes- attributes-natural-language name 1688 natural- 1689 language 1690 0x0005 value-length 1691 en-us en-US value 1692 0x41 textWithoutLanguage type value-tag 1693 0x000E name-length 1694 status-message status-message name 1695 0x000D value-length 1696 successful-ok successful-ok value 1697 0x02 start job-attributes (1st job-attributes-tag 1698 object) 1699 0x21 integer type value-tag 1700 0x0006 name-length 1701 job-id job-id name 1702 0x0004 value-length 1703 147 147 value 1704 0x36 nameWithLanguage value-tag 1705 0x0008 name-length 1706 job-name job-name name 1707 0x000C value-length 1708 0x0005 sub-value-length 1709 fr-ca fr-CA value 1710 0x0003 sub-value-length 1711 fou fou name 1712 0x02 start job-attributes (2nd job-attributes-tag 1713 object) 1714 0x02 start job-attributes (3rd job-attributes-tag 1715 object) 1716 0x21 integer type value-tag 1717 0x0006 name-length 1718 job-id job-id name 1719 0x0004 value-length 1720 148 149 value 1721 0x36 nameWithLanguage value-tag 1722 0x0008 name-length 1723 job-name job-name name 1724 0x0012 value-length 1725 0x0005 sub-value-length 1726 de-CH de-CH value 1727 Octets Symbolic Value Protocol field 1728 0x0009 sub-value-length 1729 isch guet isch guet name 1730 0x03 end-of-attributes end-of-attributes-tag 1732 14. Appendix B: Registration of MIME Media Type Information for 1733 "application/ipp" 1735 This appendix contains the information that IANA requires for 1736 registering a MIME media type. The information following this paragraph 1737 will be forwarded to IANA to register application/ipp whose contents are 1738 defined in Section 3 "Encoding of the Operation Layer" in this 1739 document: 1741 MIME type name: application 1743 MIME subtype name: ipp 1745 A Content-Type of "application/ipp" indicates an Internet Printing 1746 Protocol message body (request or response). Currently there is one 1747 version: IPP/1.1, whose syntax is described in Section 3 "Encoding of 1748 the Operation Layer" of [ipp-pro], and whose semantics are described in 1749 [ipp-mod]. 1751 Required parameters: none 1753 Optional parameters: none 1755 Encoding considerations: 1757 IPP/1.1 protocol requests/responses MAY contain long lines and ALWAYS 1758 contain binary data (for example attribute value lengths). 1760 Security considerations: 1762 IPP/1.1 protocol requests/responses do not introduce any security risks 1763 not already inherent in the underlying transport protocols. Protocol 1764 mixed-version interworking rules in [ipp-mod] as well as protocol 1765 encoding rules in [ipp-pro] are complete and unambiguous. 1767 Interoperability considerations: 1769 IPP/1.1 requests (generated by clients) and responses (generated by 1770 servers) MUST comply with all conformance requirements imposed by the 1771 normative specifications [ipp-mod] and [ipp-pro]. Protocol encoding 1772 rules specified in [ipp-pro] are comprehensive, so that interoperability 1773 between conforming implementations is guaranteed (although support for 1774 specific optional features is not ensured). Both the "charset" and 1775 "natural-language" of all IPP/1.1 attribute values which are a 1776 LOCALIZED-STRING are explicit within IPP protocol requests/responses 1777 (without recourse to any external information in HTTP, SMTP, or other 1778 message transport headers). 1780 Published specifications: 1782 [ipp-mod] Isaacson, S., deBry, R., Hastings, T., Herriot, R., 1783 Powell, P., "Internet Printing Protocol/1.1: Model and 1784 Semantics" draft-ietf-ipp-model-v11-06.txt, March 1, 2000. 1786 [ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., 1787 "Internet Printing Protocol/1.1: Encoding and Transport", draft- 1788 ietf-ipp-protocol-v11-05.txt, March 1, 2000. 1790 Applications which use this media type: 1792 Internet Printing Protocol (IPP) print clients and print servers, 1793 communicating using HTTP/1.1 (see [IPP-PRO]), SMTP/ESMTP, FTP, or other 1794 transport protocol. Messages of type "application/ipp" are self- 1795 contained and transport-independent, including "charset" and "natural- 1796 language" context for any LOCALIZED-STRING value. 1798 Person & email address to contact for further information: 1800 Tom Hastings 1801 Xerox Corporation 1802 737 Hawaii St. ESAE-231 1803 El Segundo, CA 1805 Phone: 310-333-6413 1806 Fax: 310-333-5514 1807 Email: hastings@cp10.es.xerox.com 1809 or 1811 Robert Herriot 1812 Xerox Corporation 1813 3400 Hillview Ave., Bldg #1 1814 Palo Alto, CA 94304 1816 Phone: 650-813-7696 1817 Fax: 650-813-6860 1818 Email: robert.herriot@pahv.xerox.com 1820 Intended usage: 1822 COMMON 1824 15. Appendix C: Changes from IPP/1.0 1826 IPP/1.1 is identical to IPP/1.0 [RFC2565] with the follow changes: 1828 1.Attributes values that identify a printer or job object use a new 1829 'ipp' scheme. The 'http' and 'https' schemes are supported only for 1830 backward compatibility. See section 5. 1832 2.Clients MUST support of Digest Authentication, IPP Printers SHOULD 1833 support Digest Authentication. See Section 8.1.1 1835 3.TLS is recommended for channel security. In addition, SSL3 may be 1836 supported for backward compatibility. See Section 8.1.2 1838 4.It is recommended that IPP/1.1 objects accept any request with major 1839 version number '1'. See section 9.1. 1841 5.IPP objects SHOULD return the URL scheme requested for "job-printer- 1842 uri" and "job-uri" Job Attributes, rather than the URL scheme used to 1843 create the job. See section 9.2. 1845 6.The IANA and Internationalization sections have been added. The 1846 terms "private use" and "experimental" have been changed to "vendor 1847 extension". The reserved allocations for attribute group tags, 1848 attribute syntax tags, and out-of-band attribute values have been 1849 clarified as to which are reserved to future IETF standards track 1850 documents and which are reserved to vendor extension. Both kinds of 1851 extensions use the type2 registration procedures as defined in [ipp- 1852 mod]. 1854 7.Clarified that future "out-of-band" value definitions may use the 1855 value field if additional information is needed. 1857 16. Full Copyright Statement 1859 The IETF takes no position regarding the validity or scope of any 1860 intellectual property or other rights that might be claimed to pertain 1861 to the implementation or use of the technology described in this 1862 document or the extent to which any license under such rights might or 1863 might not be available; neither does it represent that it has made any 1864 effort to identify any such rights. Information on the IETF's 1865 procedures with respect to rights in standards-track and standards- 1866 related documentation can be found in BCP-11[BCP-11]. Copies of claims 1867 of rights made available for publication and any assurances of licenses 1868 to be made available, or the result of an attempt made to obtain a 1869 general license or permission for the use of such proprietary rights by 1870 implementers or users of this specification can be obtained from the 1871 IETF Secretariat. 1873 The IETF invites any interested party to bring to its attention any 1874 copyrights, patents or patent applications, or other proprietary rights 1875 which may cover technology that may be required to practice this 1876 standard. Please address the information to the IETF Executive 1877 Director. 1879 Copyright (C) The Internet Society (2000). All Rights Reserved 1881 This document and translations of it may be copied and furnished to 1882 others, and derivative works that comment on or otherwise explain it or 1883 assist in its implementation may be prepared, copied, published and 1884 distributed, in whole or in part, without restriction of any kind, 1885 provided that the above copyright notice and this paragraph are included 1886 on all such copies and derivative works. However, this document itself 1887 may not be modified in any way, such as by removing the copyright notice 1888 or references to the Internet Society or other Internet organizations, 1889 except as needed for the purpose of developing Internet standards in 1890 which case the procedures for copyrights defined in the Internet 1891 Standards process must be followed, or as required to translate it into 1892 languages other than English. 1894 The limited permissions granted above are perpetual and will not be 1895 revoked by the Internet Society or its successors or assigns. 1897 This document and the information contained herein is provided on an "AS 1898 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1899 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1900 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1901 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1902 FITNESS FOR A PARTICULAR PURPOSE.