idnits 2.17.1 draft-ietf-ipp-protocol-v11-04.txt: -(952): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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. == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 41 longer pages, the longest (page 16) being 74 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 42 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: ---------------------------------------------------------------------------- == Line 91 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 (February 23, 2000) is 8821 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 943, but not defined == Missing Reference: 'IPP-MOD' is mentioned on line 1120, but not defined == Missing Reference: 'IPP-PRO' is mentioned on line 1814, but not defined == Unused Reference: 'RFC822' is defined on line 1151, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 1154, but no explicit reference was found in the text == Unused Reference: 'RFC1179' is defined on line 1157, but no explicit reference was found in the text == Unused Reference: 'RFC1543' is defined on line 1160, but no explicit reference was found in the text == Unused Reference: 'RFC1759' is defined on line 1166, but no explicit reference was found in the text == Unused Reference: 'RFC1766' is defined on line 1169, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 1179, but no explicit reference was found in the text == Unused Reference: 'RFC2048' is defined on line 1182, but no explicit reference was found in the text == Unused Reference: 'RFC2184' is defined on line 1189, but no explicit reference was found in the text == Unused Reference: 'RFC2566' is defined on line 1206, but no explicit reference was found in the text == Unused Reference: 'SSL' is defined on line 1230, 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 February 23, 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........................................................3 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........................................17 107 5. IPP URL Scheme.....................................................18 108 6. IANA Considerations................................................19 109 7. Internationalization Considerations................................20 110 8. Security Considerations............................................20 111 8.1 Security Conformance Requirements.............................20 112 8.1.1 Digest Authentication...................................20 113 8.1.2 Transport Layer Security (TLS)..........................21 114 8.2 Using IPP with TLS............................................22 115 9. Interoperability with IPP/1.0 Implementations......................22 116 9.1 The "version-number" Parameter................................22 117 9.2 Security and URL Schemes......................................23 118 10.References........................................................23 119 11.Author's Address..................................................25 120 12.Other Participants:...............................................27 121 13.Appendix A: Protocol Examples.....................................28 122 13.1Print-Job Request.............................................28 123 13.2Print-Job Response (successful)...............................29 124 13.3Print-Job Response (failure)..................................30 125 13.4Print-Job Response (success with attributes ignored)..........31 126 13.5Print-URI Request.............................................34 127 13.6Create-Job Request............................................35 128 13.7Get-Jobs Request..............................................36 129 13.8Get-Jobs Response.............................................37 130 14.Appendix B: Registration of MIME Media Type Information for 131 "application/ipp".....................................................39 132 15.Appendix C: Changes from IPP/1.0..................................40 133 16.Full Copyright Statement..........................................41 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 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, 237 b) an expected but missing xxx-attributes-tag. 239 The data is omitted from some operations, but the end-of-attributes-tag 240 is present even when the data is omitted. Note, the xxx-attributes-tags 241 and end-of-attributes-tag are called 'delimiter-tags'. Note: the xxx- 242 attribute-sequence, shown above may consist of 0 bytes, according to the 243 rule below. 245 An xxx-attributes-sequence consists of zero or more compound-attributes. 247 ----------------------------------------------- 248 | compound-attribute | s bytes - 0 or more 249 ----------------------------------------------- 251 A compound-attribute consists of an attribute with a single value 252 followed by zero or more additional values. 254 Note: a 'compound-attribute' represents a single attribute in the model 255 document. The 'additional value' syntax is for attributes with 2 or 256 more values. 258 Each attribute consists of: 260 ----------------------------------------------- 261 | value-tag | 1 byte 262 ----------------------------------------------- 263 | name-length (value is u) | 2 bytes 264 ----------------------------------------------- 265 | name | u bytes 266 ----------------------------------------------- 267 | value-length (value is v) | 2 bytes 268 ----------------------------------------------- 269 | value | v bytes 270 ----------------------------------------------- 272 An additional value consists of: 274 ----------------------------------------------------------- 275 | value-tag | 1 byte | 276 ----------------------------------------------- | 277 | name-length (value is 0x0000) | 2 bytes | 278 ----------------------------------------------- |-0 or more 279 | value-length (value is w) | 2 bytes | 280 ----------------------------------------------- | 281 | value | w bytes | 282 ----------------------------------------------------------- 284 Note: an additional value is like an attribute whose name-length is 0. 286 >From the standpoint of a parsing loop, the encoding consists of: 288 ----------------------------------------------- 289 | version-number | 2 bytes - required 290 ----------------------------------------------- 291 | operation-id (request) | 292 | or | 2 bytes - required 293 | status-code (response) | 294 ----------------------------------------------- 295 | request-id | 4 bytes - required 296 ----------------------------------------------------------- 297 | tag (delimiter-tag or value-tag) | 1 byte | 298 ----------------------------------------------- |-0 or more 299 | empty or rest of attribute | x bytes | 300 ----------------------------------------------------------- 301 | end-of-attributes-tag | 2 bytes - required 302 ----------------------------------------------- 303 | data | y bytes - optional 304 ----------------------------------------------- 306 The value of the tag determines whether the bytes following the tag are: 308 - attributes 310 - data 312 - the remainder of a single attribute where the tag specifies the 313 type of the value. 315 3.2 Syntax of Encoding 317 The syntax below is ABNF [RFC2234] except 'strings of literals' MUST be 318 case sensitive. For example 'a' means lower case 'a' and not upper case 319 'A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields are represented 320 as '%x' values which show their range of values. 322 ipp-message = ipp-request / ipp-response 323 ipp-request = version-number operation-id request-id 324 *(xxx-attributes-tag xxx-attribute-sequence) end-of- 325 attributes-tag data 326 ipp-response = version-number status-code request-id 327 *(xxx-attributes-tag xxx-attribute-sequence) end-of- 328 attributes-tag data 329 xxx-attribute-sequence = *compound-attribute 331 xxx-attributes-tag = operation-attributes-tag / job-attributes-tag / 332 printer-attributes-tag / unsupported-attributes-tag 334 version-number = major-version-number minor-version-number 335 major-version-number = SIGNED-BYTE ; initially %d1 336 minor-version-number = SIGNED-BYTE ; initially %d0 338 operation-id = SIGNED-SHORT ; mapping from model defined below 339 status-code = SIGNED-SHORT ; mapping from model defined below 340 request-id = SIGNED-INTEGER ; whose value is > 0 342 compound-attribute = attribute *additional-values 344 attribute = value-tag name-length name value-length value 345 additional-values = value-tag zero-name-length value-length value 347 name-length = SIGNED-SHORT ; number of octets of 'name' 348 name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." ) 349 value-length = SIGNED-SHORT ; number of octets of 'value' 350 value = OCTET-STRING 352 data = OCTET-STRING 354 zero-name-length = %x00.00 ; name-length of 0 355 operation-attributes-tag = %x01 ; tag of 1 356 job-attributes-tag = %x02 ; tag of 2 357 printer-attributes-tag = %x04 ; tag of 4 358 unsupported- attributes-tag = %x05 ; tag of 5 359 end-of-attributes-tag = %x03 ; tag of 3 360 value-tag = %x10-FF 362 SIGNED-BYTE = BYTE 363 SIGNED-SHORT = 2BYTE 364 SIGNED-INTEGER = 4BYTE 365 DIGIT = %x30-39 ; "0" to "9" 366 LALPHA = %x61-7A ; "a" to "z" 367 BYTE = %x00-FF 368 OCTET-STRING = *BYTE 370 The syntax allows an xxx-attributes-tag to be present when the xxx- 371 attribute-sequence that follows is empty. The syntax is defined this way 372 to allow for the response of Get-Jobs where no attributes are returned 373 for some job-objects. Although it is RECOMMENDED that the sender not 374 send an xxx-attributes-tag if there are no attributes (except in the 375 Get-Jobs response just mentioned), the receiver MUST be able to decode 376 such syntax. 378 3.3 Version-number 380 The version-number MUST consist of a major and minor version-number, 381 each of which MUST be represented by a SIGNED-BYTE. The protocol 382 described in this document MUST have a major version-number of 1 (0x01) 383 and a minor version-number of 1 (0x01). The ABNF for these two bytes 384 MUST be %x01.01. 386 3.4 Operation-id 388 Operation-ids are defined as enums in the model document. An operation- 389 ids enum value MUST be encoded as a SIGNED-SHORT. 391 3.5 Status-code 393 Status-codes are defined as enums in the model document. A status-code 394 enum value MUST be encoded as a SIGNED-SHORT. 396 The status-code is an operation attribute in the model document. In the 397 protocol, the status-code is in a special position, outside of the 398 operation attributes. 400 If an IPP status-code is returned, then the HTTP Status-Code MUST be 200 401 (successful-ok). With any other HTTP Status-Code value, the HTTP 402 response MUST NOT contain an IPP message-body, and thus no IPP status- 403 code is returned. 405 3.6 Request-id 407 The request-id allows a client to match a response with a request. This 408 mechanism is unnecessary in HTTP, but may be useful when application/ipp 409 entity bodies are used in another context. 411 The request-id in a response MUST be the value of the request-id 412 received in the corresponding request. A client can set the request-id 413 in each request to a unique value or a constant value, such as 1, 414 depending on what the client does with the request-id returned in the 415 response. The value of the request-id MUST be greater than zero. 417 3.7 Tags 419 There are two kinds of tags: 421 - delimiter tags: delimit major sections of the protocol, namely 422 attributes and data 424 - value tags: specify the type of each attribute value 426 3.7.1 Delimiter Tags 428 The following table specifies the values for the delimiter tags: 430 Tag Value (Hex) Delimiter 432 0x00 reserved for definition in a future IETF 433 standards track document 434 0x01 operation-attributes-tag 435 0x02 job-attributes-tag 436 0x03 end-of-attributes-tag 437 0x04 printer-attributes-tag 438 0x05 unsupported-attributes-tag 439 0x06-0x0e reserved for future delimiters in IETF 440 standards track documents 441 0x0F reserved for future chunking-end-of-attributes- 442 tag for definition in a future IETF standards 443 track document 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 "Operation Requests and Responses" and 478 13 "Appendix A: 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 'default' for definition in a future 496 IETF standards track document 497 0x12 unknown 498 0x13 no-value 499 0x14-0x1F reserved for "out-of-band" values in future IETF 500 standards track documents. 502 The "unsupported" value MUST be used in the attribute-sequence of an 503 error response for those attributes which the printer does not support. 504 The "default" value is reserved for future use of setting value back to 505 their default value. The "unknown" value is used for the value of a 506 supported attribute when its value is temporarily unknown. The "no- 507 value" value is used for a supported attribute to which no value has 508 been assigned, e.g. "job-k-octets-supported" has no value if an 509 implementation supports this attribute, but an administrator has not 510 configured the printer to have a limit. 512 The following table specifies the integer values for the value-tag: 514 Tag Value (Hex) Meaning 516 0x20 reserved for definition in a future IETF 517 standards track document 518 0x21 integer 519 0x22 boolean 520 0x23 enum 521 0x24-0x2F reserved for integer types for definition in 522 future IETF standards track documents 524 NOTE: 0x20 is reserved for "generic integer" if it should ever be 525 needed. 527 The following table specifies the octetString values for the value-tag: 529 Tag Value (Hex) Meaning 531 0x30 octetString with an unspecified format 532 0x31 dateTime 533 0x32 resolution 534 0x33 rangeOfInteger 535 0x34 reserved for definition in a future IETF 536 standards track document 537 0x35 textWithLanguage 538 0x36 nameWithLanguage 539 0x37-0x3F reserved for octetString type definitions in 540 future IETF standards track documents 542 The following table specifies the character-string values for the value- 543 tag: 545 Tag Value (Hex) Meaning 547 0x40 reserved for definition in a future IETF 548 standards track document 549 0x41 textWithoutLanguage 550 0x42 nameWithoutLanguage 551 0x43 reserved for definition in a future IETF 552 standards track document 553 0x44 keyword 554 0x45 uri 555 0x46 uriScheme 556 0x47 charset 557 0x48 naturalLanguage 558 0x49 mimeMediaType 559 0x4A-0x5F reserved for character string type definitions 560 in future IETF standards track documents 562 NOTE: 0x40 is reserved for "generic character-string" if it should ever 563 be needed. 565 NOTE: an attribute value always has a type, which is explicitly 566 specified by its tag; one such tag value is "nameWithoutLanguage". An 567 attribute's name has an implicit type, which is keyword. 569 The values 0x60-0xFF are reserved for future type definations in IETF 570 standards track documents. 572 The tag 0x7F is reserved for extending types beyond the 255 values 573 available with a single byte. A tag value of 0x7F MUST signify that the 574 first 4 bytes of the value field are interpreted as the tag value. 575 Note, this future extension doesn't affect parsers that are unaware of 576 this special tag. The tag is like any other unknown tag, and the value 577 length specifies the length of a value which contains a value that the 578 parser treats atomically. Values from 0x00 to 0x37777777 are reserved 579 for definition in future IETF standard track documents. The values 580 0x40000000 to0x7FFFFFFF are reserved for vendor extensions. 582 3.8 Name-Length 584 The name-length field MUST consist of a SIGNED-SHORT. This field MUST 585 specify the number of octets in the name field which follows the name- 586 length field, excluding the two bytes of the name-length field. 588 If a name-length field has a value of zero, the following name field 589 MUST be empty, and the following value MUST be treated as an additional 590 value for the preceding attribute. Within an attribute-sequence, if two 591 or more attributes have the same name, the attribute-sequence is mal- 592 formed (see [ipp-mod] section 3.1.3). The zero-length name is the only 593 mechanism for multi-valued attributes. 595 3.9 Operation Requests and Responses 597 Some operation elements are called parameters in the model document 598 [ipp-mod]. They MUST be encoded in a special position and they MUST NOT 599 appear as an operation attributes. These parameters are: 601 - "version-number": The parameter named "version-number" in the IPP 602 model document MUST become the "version-number" field in the 603 operation layer request or response. 605 - "operation-id": The parameter named "operation-id" in the IPP model 606 document MUST become the "operation-id" field in the operation 607 layer request. 609 - "status-code": The parameter named "status-code" in the IPP model 610 document MUST become the "status-code" field in the operation layer 611 response. 613 - "request-id": The parameter named "request-id" in the IPP model 614 document MUST become the "request-id" field in the operation layer 615 request or response. 617 All Printer and Job objects are identified by a Uniform Resource 618 Identifier (URI) [RFC2396] so that they can be persistently and 619 unambiguously referenced. The notion of a URI is a useful concept, 620 however, until the notion of URI is more stable (i.e., defined more 621 completely and deployed more widely), it is expected that the URIs used 622 for IPP objects will actually be URLs [RFC1738] [RFC1808]. Since every 623 URL is a specialized form of a URI, even though the more generic term 624 URI is used throughout the rest of this document, its usage is intended 625 to cover the more specific notion of URL as well. 627 Some operation elements are encoded twice, once as the request-URI on 628 the HTTP Request-Line and a second time as a REQUIRED operation 629 attribute in the application/ipp entity. These attributes are the 630 target URI for the operation and are called printer-uri and job-uri. 631 Note: The target URI is included twice in an operation referencing the 632 same IPP object, but the two URIs NEED NOT be literally identical. One 633 can be a relative URI and the other can be an absolute URI. HTTP/1.1 634 allows clients to generate and send a relative URI rather than an 635 absolute URI. A relative URI identifies a resource with the scope of 636 the HTTP server, but does not include scheme, host or port. The 637 following statements characterize how URLs should be used in the mapping 638 of IPP onto HTTP/1.1: 640 1. Although potentially redundant, a client MUST supply the target of 641 the operation both as an operation attribute and as a URI at the 642 HTTP layer. The rationale for this decision is to maintain a 643 consistent set of rules for mapping application/ipp to possibly 644 many communication layers, even where URLs are not used as the 645 addressing mechanism in the transport layer. 646 2. Even though these two URLs might not be literally identical (one 647 being relative and the other being absolute), they MUST both 648 reference the same IPP object. 649 3. The URI in the HTTP layer is either relative or absolute and is 650 used by the HTTP server to route the HTTP request to the correct 651 resource relative to that HTTP server. The HTTP server need not be 652 aware of the URI within the operation request. 653 4. Once the HTTP server resource begins to process the HTTP request, 654 it might get the reference to the appropriate IPP Printer object 655 from either the HTTP URI (using to the context of the HTTP server 656 for relative URLs) or from the URI within the operation request; 657 the choice is up to the implementation. 658 5. HTTP URIs can be relative or absolute, but the target URI in the 659 operation MUST be an absolute URI. 661 The model document arranges the remaining attributes into groups for 662 each operation request and response. Each such group MUST be represented 663 in the protocol by an xxx-attribute-sequence preceded by the appropriate 664 xxx-attributes-tag (See the table below and section 13 "Appendix A: 665 Protocol Examples"). In addition, the order of these xxx-attributes-tags 666 and xxx-attribute-sequences in the protocol MUST be the same as in the 667 model document, but the order of attributes within each xxx-attribute- 668 sequence MUST be unspecified. The table below maps the model document 669 group name to xxx-attributes-sequence: 671 Model Document Group xxx-attributes-sequence 673 Operation Attributes operations-attributes-sequence 674 Job Template Attributes job-attributes-sequence 675 Job Object Attributes job-attributes-sequence 676 Unsupported Attributes unsupported- attributes-sequence 677 Requested Attributes (Get-Job- job-attributes-sequence 678 Attributes) 679 Requested Attributes (Get- printer-attributes-sequence 680 Printer-Attributes) 681 Document Content in a special position as described 682 above 684 If an operation contains attributes from more than one job object (e.g. 685 Get-Jobs response), the attributes from each job object MUST be in a 686 separate job-attribute-sequence, such that the attributes from the ith 687 job object are in the ith job-attribute-sequence. See Section 13 688 "Appendix A: Protocol Examples" for table showing the application of the 689 rules above. 691 3.10 Value Length 693 Each attribute value MUST be preceded by a SIGNED-SHORT, which MUST 694 specify the number of octets in the value which follows this length, 695 exclusive of the two bytes specifying the length. 697 For any of the types represented by binary signed integers, the sender 698 MUST encode the value in exactly four octets. 700 For any of the types represented by character-strings, the sender MUST 701 encode the value with all the characters of the string and without any 702 padding characters. 704 If a value-tag contains an "out-of-band" value, such as "unsupported", 705 the value-length MUST be 0 and the value empty � the value has no 706 meaning when the value-tag has an "out-of-band" value. 708 3.11 Attribute Value 710 The syntax types and most of the details of the representation of 711 attribute values are defined in the IPP model document. The table below 712 augments the information in the model document, and defines the syntax 713 types from the model document in terms of the 5 basic types defined in 714 section 3 "Encoding of the Operation Layer". The 5 types are US-ASCII- 715 STRING, LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and 716 OCTET-STRING. 718 Syntax of Attribute Encoding 719 Value 721 textWithoutLanguage, LOCALIZED-STRING. 722 nameWithoutLanguage 724 textWithLanguage OCTET_STRING consisting of 4 fields: 725 a) 726 a SIGNED-SHORT which is the number of octets 727 in the following field 728 b) 729 a value of type natural-language, 730 c) 731 a SIGNED-SHORT which is the number of octets 732 in the following field, 733 d) 734 a value of type textWithoutLanguage. 735 The length of a textWithLanguage value MUST be 4 736 + the value of field a + the value of field c. 738 nameWithLanguage OCTET_STRING consisting of 4 fields: 739 a) 740 a SIGNED-SHORT which is the number of octets 741 in the following field 742 b) 743 a value of type natural-language, 744 c) 745 a SIGNED-SHORT which is the number of octets 746 in the following field 747 d) 748 a value of type nameWithoutLanguage. 749 The length of a nameWithLanguage value MUST be 4 750 + the value of field a + the value of field c. 752 charset, US-ASCII-STRING. 753 naturalLanguage, 754 mimeMediaType, 755 keyword, uri, and 756 uriScheme 758 boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is 759 'true'. 761 integer and enum a SIGNED-INTEGER. 763 dateTime OCTET-STRING consisting of eleven octets whose 764 contents are defined by "DateAndTime" in RFC 765 1903 [RFC1903]. 767 resolution OCTET_STRING consisting of nine octets of 2 768 SIGNED-INTEGERs followed by a SIGNED-BYTE. The 769 first SIGNED-INTEGER contains the value of cross 770 feed direction resolution. The second SIGNED- 771 INTEGER contains the value of feed direction 772 resolution. The SIGNED-BYTE contains the units 773 value. 775 rangeOfInteger Eight octets consisting of 2 SIGNED-INTEGERs. 776 The first SIGNED-INTEGER contains the lower 777 bound and the second SIGNED-INTEGER contains the 778 upper bound. 780 Syntax of Attribute Encoding 781 Value 783 1setOf X Encoding according to the rules for an attribute 784 with more than 1 value. Each value X is encoded 785 according to the rules for encoding its type. 787 octetString OCTET-STRING 789 The type of the value in the model document determines the encoding in 790 the value and the value of the value-tag. 792 3.12 Data 794 The data part MUST include any data required by the operation 796 4. Encoding of Transport Layer 798 HTTP/1.1 [RFC2616] is the transport layer for this protocol. 800 The operation layer has been designed with the assumption that the 801 transport layer contains the following information: 803 - the URI of the target job or printer operation 805 - the total length of the data in the operation layer, either as a 806 single length or as a sequence of chunks each with a length. 808 It is REQUIRED that a printer implementation support HTTP over the IANA 809 assigned Well Known Port 631 (the IPP default port), though a printer 810 implementation may support HTTP over some other port as well. 812 Each HTTP operation MUST use the POST method where the request-URI is 813 the object target of the operation, and where the "Content-Type" of the 814 message-body in each request and response MUST be "application/ipp". The 815 message-body MUST contain the operation layer and MUST have the syntax 816 described in section 3.2 "Syntax of Encoding". A client implementation 817 MUST adhere to the rules for a client described for HTTP1.1 [RFC2616] . 818 A printer (server) implementation MUST adhere the rules for an origin 819 server described for HTTP1.1 [RFC2616]. 821 An IPP server sends a response for each request that it receives. If an 822 IPP server detects an error, it MAY send a response before it has read 823 the entire request. If the HTTP layer of the IPP server completes 824 processing the HTTP headers successfully, it MAY send an intermediate 825 response, such as "100 Continue", with no IPP data before sending the 826 IPP response. A client MUST expect such a variety of responses from an 827 IPP server. For further information on HTTP/1.1, consult the HTTP 828 documents [RFC2616]. 830 An HTTP server MUST support chunking for IPP requests, and an IPP client 831 MUST support chunking for IPP responses according to HTTP/1.1[RFC2616]. 832 Note: this rule causes a conflict with non-compliant implementations of 833 HTTP/1.1 that don't support chunking for POST methods, and this rule may 834 cause a conflict with non-compliant implementations of HTTP/1.1 that 835 don't support chunking for CGI scripts 837 5. IPP URL Scheme 839 The IPP/1.1 document defines a new scheme 'ipp' as the value of a URL 840 that identifies either an IPP printer object or an IPP job object. The 841 IPP attributes using the 'ipp' scheme are specified below. Because the 842 HTTP layer does not support the 'ipp' scheme, a client MUST map 'ipp' 843 URLs to 'http' URLs, and then follows the HTTP [RFC2616][RFC2617] rules 844 for constructing a Request-Line and HTTP headers. The mapping is simple 845 because the 'ipp' scheme implies all of the same protocol semantics as 846 that of the 'http' scheme [RFC2616], except that it represents a print 847 service and the implicit (default) port number that clients use to 848 connect to a server is port 631. 850 In the remainder of this section the term 'ipp-URL' means a URL whose 851 scheme is 'ipp' and whose implicit (default) port is 631. The term 852 'http-URL' means a URL whose scheme is 'http', and the term 'https-URL' 853 means a URL whose scheme is 'https', 855 A client and an IPP object (i.e. the server) MUST support the ipp-URL 856 value in the following IPP attributes. 857 job attributes: 858 job-uri 859 job-printer-uri 860 printer attributes: 861 printer-uri-supported 862 operation attributes: 863 job-uri 864 printer-uri 866 Each of the above attributes identifies a printer or job object. The 867 ipp-URL is intended as the value of the attributes in this list, and for 868 no other attributes. All of these attributes have a syntax type of 869 'uri', but there are attributes with a syntax type of 'uri' that do not 870 use the 'ipp' scheme, e.g. 'job-more-info'. 872 If a printer registers its URL with a directory service, the printer 873 MUST register an ipp-URL. 875 User interfaces are beyond the scope of this document. But if software 876 exposes the ipp-URL values of any of the above five attributes to a 877 human user, it is REQUIRED that the human see the ipp-URL as is. 879 When a client sends a request, it MUST convert a target ipp-URL to a 880 target http-URL for the HTTP layer according to the following rules: 881 1. 882 change the 'ipp' scheme to 'http' 884 2. 885 add an explicit port 631 if the URL does not contain an explicit 886 port. Note: port 631 is the IANA assigned Well Known Port for the 887 'ipp' scheme. 889 The client MUST use the target http-URL in both the HTTP Request-Line 890 and HTTP headers, as specified by HTTP[RFC2616][RFC2617] . However, the 891 client MUST use the target ipp-URL for the value of the "printer-uri" or 892 "job-uri" operation attribute within the application/ipp body of the 893 request. The server MUST use the ipp-URL for the value of the "printer- 894 uri", "job-uri" or "printer-uri-supported" attributes within the 895 application/ipp body of the response. 897 For example, when an IPP client sends a request directly (i.e. no proxy) 898 to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a TCP 899 connection to port 631 (the ipp implicit port) on the host "myhost.com" 900 and sends the following data: 902 POST /myprinter/myqueue HTTP/1.1 903 Host: myhost.com:631 904 Content-type: application/ipp 905 Transfer-Encoding: chunked 906 ... 907 "printer-uri" "ipp://myhost.com/myprinter/myqueue" 908 (encoded in application/ipp message body) 909 ... 911 As another example, when an IPP client sends the same request as above 912 via a proxy "myproxy.com", it opens a TCP connection to the proxy port 913 8080 on the proxy host "myproxy.com" and sends the following data: 915 POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 916 Host: myhost.com:631 917 Content-type: application/ipp 918 Transfer-Encoding: chunked 919 ... 920 "printer-uri" "ipp://myhost.com/myprinter/myqueue" 921 (encoded in application/ipp message body) 922 ... 924 The proxy then connects to the IPP origin server with headers that are 925 the same as the "no-proxy" example above. 927 6. IANA Considerations 929 This section describes the procedures for allocating encoding for the 930 following IETF standards track extensions and vendor extensions to the 931 IPP/1.1 Encoding and Transport document: 933 1. attribute syntaxes - see [ipp-mod] section 6.3 934 2. attribute groups - see [ipp-mod] section 6.5 935 3. out-of-band attribute values - see [ipp-mod] section 6.7 937 These extensions follow the "type2" registration procedures defined in 938 [ipp-mod] section 6. Extensions registered for use with IPP/1.1 are 939 OPTIONAL for client and IPP object conformance to the IPP/1.1 Encoding 940 and Transport document. 942 These extension procedures are aligned with the guidelines as set forth 943 by the IESG [IANA-CON]. The [ipp-mod] Section 11 describes how to 944 propose new registrations for consideration. IANA will reject 945 registration proposals that leave out required information or do not 946 follow the appropriate format described in [ipp-mod] Section 11. The 947 IPP/1.1 Encoding and Transport document may also be extended by an 948 appropriate RFC that specifies any of the above extensions. 950 7. Internationalization Considerations 952 See the section on �Internationalization Considerations� in the document 953 "Internet Printing Protocol/1.1: Model and Semantics" [ipp-mod] for 954 information on internationalization. This document adds no additional 955 issues. 957 8. Security Considerations 959 The IPP Model and Semantics document [ipp-mod] discusses high level 960 security requirements (Client Authentication, Server Authentication and 961 Operation Privacy). Client Authentication is the mechanism by which the 962 client proves its identity to the server in a secure manner. Server 963 Authentication is the mechanism by which the server proves its identity 964 to the client in a secure manner. Operation Privacy is defined as a 965 mechanism for protecting operations from eavesdropping. 967 8.1 Security Conformance Requirements 969 This section defines the security requirements for IPP clients and IPP 970 objects. 972 8.1.1 Digest Authentication 974 IPP clients MUST support: 976 Digest Authentication [RFC2617]. 978 MD5 and MD5-sess MUST be implemented and supported. 980 The Message Integrity feature NEED NOT be used. 982 IPP Printers SHOULD support: 984 Digest Authentication [RFC2617]. 986 MD5 and MD5-sess MUST be implemented and supported. 988 The Message Integrity feature NEED NOT be used. 990 The reasons that IPP Printers SHOULD (rather than MUST) support Digest 991 Authentication are: 993 1. 994 While Client Authentication is important, there is a certain class of 995 printer devices where it does not make sense. Specifically, a low- 996 end device with limited ROM space and low paper throughput may not 997 need Client Authentication. This class of device typically requires 998 firmware designers to make trade-offs between protocols and 999 functionality to arrive at the lowest-cost solution possible. 1000 Factored into the designer�s decisions is not just the size of the 1001 code, but also the testing, maintenance, usefulness, and time-to- 1002 market impact for each feature delivered to the customer. Forcing 1003 such low-end devices to provide security in order to claim IPP/1.1 1004 conformance would not make business sense and could potentially stall 1005 the adoption of the standard. 1007 2. 1008 Print devices that have high-volume throughput and have available ROM 1009 space have a compelling argument to provide support for Client 1010 Authentication that safeguards the device from unauthorized access. 1011 These devices are prone to a high loss of consumables and paper if 1012 unauthorized access should occur. 1014 8.1.2 Transport Layer Security (TLS) 1016 IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246] for 1017 Server Authentication and Operation Privacy. IPP Printers MAY also 1018 support TLS for Client Authentication. If an IPP Printer supports TLS, 1019 it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as 1020 mandated by RFC 2246 [RFC2246]. All other cipher suites are OPTIONAL. 1021 An IPP Printer MAY support Basic Authentication (described in HTTP/1.1 1022 [RFC2617]) for Client Authentication if the channel is secure. TLS with 1023 the above mandated cipher suite can provide such a secure channel. 1025 If a IPP client supports TLS, it MUST support the 1026 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246 1027 [RFC2246]. All other cipher suites are OPTIONAL. 1029 The IPP Model and Semantics document defines two printer attributes 1030 ("uri-authentication-supported" and "uri-security-supported") that the 1031 client can use to discover the security policy of a printer. That 1032 document also outlines IPP-specific security considerations and should 1033 be the primary reference for security implications with regard to the 1034 IPP protocol itself. For backward compatibility with IPP version 1.0, 1035 IPP clients and printers may also support SSL3 [ssl]. This is in 1036 addition to the security required in this document. 1038 8.2 Using IPP with TLS 1040 IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism [http- 1041 tls]. An initial IPP request never uses TLS. The client requests a 1042 secure TLS connection by using the HTTP �Upgrade� header, while the 1043 server agrees in the HTTP response. The switch to TLS occurs either 1044 because the server grants the client�s request to upgrade to TLS, or a 1045 server asks to switch to TLS in its response. Secure communication 1046 begins with a server�s response to switch to TLS. 1048 9. Interoperability with IPP/1.0 Implementations 1050 It is beyond the scope of this specification to mandate conformance with 1051 previous versions. IPP/1.1 was deliberately designed, however, to make 1052 supporting previous versions easy. It is worth noting that, at the time 1053 of composing this specification (1999), we would expect IPP/1.1 Printer 1054 implementations to: 1056 understand any valid request in the format of IPP/1.0, or 1.1; 1058 respond appropriately with a response containing the same "version- 1059 number" parameter value used by the client in the request. 1061 And we would expect IPP/1.1 clients to: 1063 understand any valid response in the format of IPP/1.0, or 1.1. 1065 9.1 The "version-number" Parameter 1067 The following are rules regarding the "version-number" parameter (see 1068 section 3.3): 1070 1. 1071 Clients MUST send requests containing a "version-number" parameter 1072 with a '1.1' value and SHOULD try supplying alternate version 1073 numbers if they receive a 'server-error-version-not-supported' 1074 error return in a response. 1076 2. 1077 IPP objects MUST accept requests containing a "version-number" 1078 parameter with a '1.1' value (or reject the request for reasons 1079 other than 'server-error-version-not-supported'). 1081 3. 1082 It is recommended that IPP objects accept any request with the 1083 major version '1' (or reject the request for reasons other than 1084 'server-error-version-not-supported'). See [ipp-mod] "versions" 1085 sub-section. 1087 4. 1088 In any case, security MUST NOT be compromised when a client 1089 supplies a lower "version-number" parameter in a request. For 1090 example, if an IPP/1.1 conforming Printer object accepts version 1091 '1.0' requests and is configured to enforce Digest Authentication, 1092 it MUST do the same for a version '1.0' request. 1094 9.2 Security and URL Schemes 1096 The following are rules regarding security, the "version-number" 1097 parameter, and the URL scheme supplied in target attributes and 1098 responses: 1100 1. 1101 When a client supplies a request, the "printer-uri" or "job-uri" 1102 target operation attribute MUST have the same scheme as that 1103 indicated in one of the values of the "printer-uri-supported" 1104 Printer attribute. 1106 2. 1107 When the server returns the "job-printer-uri" or "job-uri" Job 1108 Description attributes, it SHOULD return the same scheme ('ipp', 1109 'https', 'http', etc.) that the client supplied in the "printer- 1110 uri" or "job-uri" target operation attributes in the Get-Job- 1111 Attributes or Get-Jobs request, rather than the scheme used when 1112 the job was created. However, when a client requests job 1113 attributes using the Get-Job-Attributes or Get-Jobs operations, the 1114 jobs and job attributes that the server returns depends on: (1) the 1115 security in effect when the job was created, (2) the security in 1116 effect in the query request, and (3) the security policy in force. 1118 3. 1119 It is recommended that if a server registers a non-secure ipp-URL 1120 with a directory service (see [IPP-MOD] "Generic Directory Schema" 1121 Appendix), then it also register an http-URL for interoperability 1122 with IPP/1.0 clients (see section 9). 1124 4. 1125 In any case, security MUST NOT be compromised when a client 1126 supplies an 'http' or other non-secure URL scheme in the target 1127 "printer-uri" and "job-uri" operation attributes in a request. 1129 10. References 1131 [dpa] ISO/IEC 10175 Document Printing Application (DPA), June 1996. 1133 [http-tls]R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1", 1134 , June 1999. 1136 [iana]IANA Registry of Coded Character Sets: ftp://ftp.isi.edu/in- 1137 notes/iana/assignments/character-sets. 1139 [ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.1: 1140 Implementer's Guide", draft-ietf-ipp-implementers-guide-v11- 1141 00.txt, work in progress, September 27, 1999. 1143 [ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1144 "Internet Printing Protocol/1.1: Model and Semantics", , February 23, 2000. 1147 [ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet 1148 Printing Protocol/1.1: Encoding and Transport", draft-ietf-ipp- 1149 protocol-v11-04-.txt, February 23, 2000. 1151 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text 1152 Messages", RFC 822, August 1982. 1154 [RFC1123] Braden, S., "Requirements for Internet Hosts - Application 1155 and Support", RFC 1123, October, 1989. 1157 [RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" 1158 RFC 1179, August 1990. 1160 [RFC1543] Postel, J., "Instructions to RFC Authors", RFC 1543, October 1161 1993. 1163 [RFC1738] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform 1164 Resource Locators (URL)", RFC 1738, December, 1994. 1166 [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and 1167 Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. 1169 [RFC1766] H. Alvestrand, " Tags for the Identification of Languages", 1170 RFC 1766, March 1995. 1172 [RFC1808] R. Fielding, "Relative Uniform Resource Locators", RFC1808, 1173 June 1995. 1175 [RFC1903] J. Case, et al. "Textual Conventions for Version 2 of the 1176 Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1177 1996. 1179 [RFC2046] N. Freed & N. Borenstein, Multipurpose Internet Mail 1180 Extensions (MIME) Part Two: Media Types. November 1996, RFC 2046. 1182 [RFC2048] N. Freed, J. Klensin & J. Postel. Multipurpose Internet Mail 1183 Extension (MIME) Part Four: Registration Procedures. November 1184 1996 (Also BCP0013), RFC 2048. 1186 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1187 Requirement Levels", RFC 2119 , March 1997. 1189 [RFC2184] N. Freed, K. Moore, "MIME Parameter Value and Encoded Word 1190 Extensions: Character Sets, Languages, and Continuations", RFC 1191 2184, August 1997. 1193 [RFC2234] D. Crocker et al., "Augmented BNF for Syntax Specifications: 1194 ABNF", RFC 2234. November 1997. 1196 [RFC2246] T. Dierks et al., "The TLS Protocol", RFC 2246. January 1999. 1198 [RFC2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform 1199 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1200 1998. 1202 [RFC2565] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet 1203 Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1204 1999. 1206 [RFC2566] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1207 "Internet Printing Protocol/1.0: Model and Semantics", rfc 2566, 1208 April, 1999. 1210 [RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", 1211 RFC2567, April 1999. 1213 [RFC2568] Zilles, S., "Rationale for the Structure and Model and 1214 Protocol for the Internet Printing Protocol", RC 2568, April 1215 1999. 1217 [RFC2569] Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping 1218 between LPD and IPP Protocols RFC 2569, April 1999. 1220 [RFC2616] 1221 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1222 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 1223 RFC 2616, June 1999. 1225 [RFC2617] 1226 J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, 1227 A. Luotonen, L. Stewart, "HTTP Authentication: Basic and Digest 1228 Access Authentication", RFC 2617, June 1999. 1230 [SSL] 1231 Netscape, The SSL Protocol, Version 3, (Text version 3.02), 1232 November 1996. 1234 11. Author's Address 1235 Robert Herriot (editor) Paul Moore 1236 Xerox Corporation Peerless Systems Networking 1237 3400 Hillview Ave., Bldg #1 10900 NE 8th St #900 1238 Palo Alto, CA 94304 Bellevue, WA 98004 1240 Phone: 650-813-7696 Phone: 425-462-5852 1241 Fax: 650-813-6860 1242 Email: Email: pmoore@peerless.com 1243 robert.herriot@pahv.xerox.com 1245 Sylvan Butler Randy Turner 1246 Hewlett-Packard 2Wire, Inc. 1247 11311 Chinden Blvd. 694 Tasman Dr. 1248 Boise, ID 83714 Milpitas, CA 95035 1250 Phone: 208-396-6000 Phone: 408-546-1273 1251 Fax: 208-396-3457 1252 Email: sbutler@boi.hp.com 1254 John Wenn 1255 Xerox Corporation 1256 737 Hawaii St 1257 El Segundo, CA 90245 1259 IPP Mailing List: ipp@pwg.org Phone: 310-333-5764 1260 IPP Mailing List Subscription: Fax: 310-333-5514 1261 ipp-request@pwg.org 1262 IPP Web Page: Email: jwenn@cp10.es.xerox.com 1263 http://www.pwg.org/ipp/ 1264 12. Other Participants: 1266 Chuck Adams - Tektronix Shivaun Albright - HP 1267 Stefan Andersson - Axis Jeff Barnett - IBM 1268 Ron Bergman - Hitachi Koki Imaging Dennis Carney - IBM 1269 Systems 1270 Keith Carter - IBM Angelo Caruso - Xerox 1271 Rajesh Chawla - TR Computing Nancy Chen - Okidata 1272 Solutions 1273 Josh Cohen - Microsoft Jeff Copeland - QMS 1274 Andy Davidson - Tektronix Roger deBry - IBM 1275 Maulik Desai - Auco Mabry Dozier - QMS 1276 Lee Farrell - Canon Information Satoshi Fujitami - Ricoh 1277 Systems 1278 Steve Gebert - IBM Sue Gleeson - Digital 1279 Charles Gordon - Osicom Brian Grimshaw - Apple 1280 Jerry Hadsell - IBM Richard Hart - Digital 1281 Tom Hastings - Xerox Henrik Holst - I-data 1282 Stephen Holmstead Zhi-Hong Huang - Zenographics 1283 Scott Isaacson - Novell Babek Jahromi - Microsoft 1284 Swen Johnson - Xerox David Kellerman - Northlake 1285 Software 1286 Robert Kline - TrueSpectra Charles Kong - Panasonic 1287 Carl Kugler - IBM Dave Kuntz - Hewlett-Packard 1288 Takami Kurono - Brother Rick Landau - Digital 1289 Scott Lawrence - Agranot Systems Greg LeClair - Epson 1290 Dwight Lewis - Lexmark Harry Lewis - IBM 1291 Tony Liao - Vivid Image Roy Lomicka - Digital 1292 Pete Loya - HP Ray Lutz - Cognisys 1293 Mike MacKay - Novell, Inc. David Manchala - Xerox 1294 Carl-Uno Manros - Xerox Jay Martin - Underscore 1295 Stan McConnell - Xerox Larry Masinter - Xerox 1296 Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft 1297 Ira McDonald - High North Inc. Mike Moldovan - G3 Nova 1298 Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh 1299 Pat Nogay - IBM Ron Norton - Printronics 1300 Hugo Parra, Novell Bob Pentecost - Hewlett-Packard 1301 Patrick Powell - Astart Jeff Rackowitz - Intermec 1302 Technologies 1303 Eric Random - Peerless Rob Rhoads - Intel 1304 Xavier Riley - Xerox Gary Roberts - Ricoh 1305 David Roach - Unisys Stuart Rowley - Kyocera 1306 Yuji Sasaki - Japan Computer Richard Schneider - Epson 1307 Industry 1308 Kris Schoff - HP Katsuaki Sekiguchi - Canon 1309 Information Systems 1310 Bob Setterbo - Adobe Gail Songer - Peerless 1311 Hideki Tanaka - Cannon Information Devon Taylor - Novell, Inc. 1312 Systems 1313 Mike Timperman - Lexmark Atsushi Uchino - Epson 1314 Shigeru Ueda - Canon Bob Von Andel - Allegro Software 1315 William Wagner - NetSilicon/DPI Jim Walker - DAZEL 1316 Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard 1317 Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc. 1319 Jasper Wong - Xionics Don Wright - Lexmark 1320 Michael Wu - Heidelberg Digital Rick Yardumian - Xerox 1321 Michael Yeung - Canon Information Lloyd Young - Lexmark 1322 Systems 1323 Atsushi Yuki - Kyocera Peter Zehler - Xerox 1324 William Zhang- Canon Information Frank Zhao - Panasonic 1325 Systems 1326 Steve Zilles - Adobe Rob Zirnstein - Canon Information 1327 Systems 1329 13. Appendix A: Protocol Examples 1331 13.1 Print-Job Request 1333 The following is an example of a Print-Job request with job-name, 1334 copies, and sides specified. The "ipp-attribute-fidelity" attribute is 1335 set to 'true' so that the print request will fail if the "copies" or the 1336 "sides" attribute are not supported or their values are not supported. 1338 Octets Symbolic Value Protocol field 1340 0x0101 1.1 version-number 1341 0x0002 Print-Job operation-id 1342 0x00000001 1 request-id 1343 0x01 start operation-attributes operation-attributes-tag 1344 0x47 charset type value-tag 1345 0x0012 name-length 1346 attributes- attributes-charset name 1347 charset 1348 0x0008 value-length 1349 us-ascii US-ASCII value 1350 0x48 natural-language type value-tag 1351 0x001B name-length 1352 attributes- attributes-natural-language name 1353 natural- 1354 language 1355 0x0005 value-length 1356 en-us en-US value 1357 0x45 uri type value-tag 1358 0x000B name-length 1359 printer-uri printer-uri name 1360 0x0015 value-length 1361 ipp://forest/p printer pinetree value 1362 inetree 1363 0x42 nameWithoutLanguage type value-tag 1364 0x0008 name-length 1365 job-name job-name name 1366 0x0006 value-length 1367 foobar foobar value 1368 0x22 boolean type value-tag 1369 0x0016 name-length 1370 ipp-attribute- ipp-attribute-fidelity name 1371 fidelity 1372 0x0001 value-length 1373 0x01 true value 1374 0x02 start job-attributes job-attributes-tag 1375 0x21 integer type value-tag 1376 0x0006 name-length 1377 copies copies name 1378 0x0004 value-length 1379 0x00000014 20 value 1380 0x44 keyword type value-tag 1381 0x0005 name-length 1382 sides sides name 1383 0x0013 value-length 1384 two-sided- two-sided-long-edge value 1385 long-edge 1386 0x03 end-of-attributes end-of-attributes-tag 1387 %!PS... data 1389 13.2 Print-Job Response (successful) 1390 Here is an example of a successful Print-Job response to the previous 1391 Print-Job request. The printer supported the "copies" and "sides" 1392 attributes and their supplied values. The status code returned is 1393 'successful-ok'. 1395 Octets Symbolic Value Protocol field 1397 0x0101 1.1 version-number 1398 0x0000 successful-ok status-code 1399 0x00000001 1 request-id 1400 0x01 start operation-attributes operation-attributes-tag 1401 0x47 charset type value-tag 1402 0x0012 name-length 1403 attributes- attributes-charset name 1404 charset 1405 0x0008 value-length 1406 us-ascii US-ASCII value 1407 0x48 natural-language type value-tag 1408 0x001B name-length 1409 attributes- attributes-natural- name 1410 natural-language language 1411 0x0005 value-length 1412 en-us en-US value 1413 0x41 textWithoutLanguage type value-tag 1414 0x000E name-length 1415 status-message status-message name 1416 0x000D value-length 1417 successful-ok successful-ok value 1418 0x02 start job-attributes job-attributes-tag 1419 0x21 integer value-tag 1420 0x0006 name-length 1421 job-id job-id name 1422 0x0004 value-length 1423 147 147 value 1424 0x45 uri type value-tag 1425 0x0007 name-length 1426 job-uri job-uri name 1427 0x0019 value-length 1428 ipp://forest/pin job 123 on pinetree value 1429 etree/123 1430 0x23 enum type value-tag 1431 0x0009 name-length 1432 job-state job-state name 1433 0x0004 value-length 1434 0x0003 pending value 1435 0x03 end-of-attributes end-of-attributes-tag 1437 13.3 Print-Job Response (failure) 1439 Here is an example of an unsuccessful Print-Job response to the previous 1440 Print-Job request. It fails because, in this case, the printer does not 1441 support the "sides" attribute and because the value '20' for the 1442 "copies" attribute is not supported. Therefore, no job is created, and 1443 neither a "job-id" nor a "job-uri" operation attribute is returned. The 1444 error code returned is 'client-error-attributes-or-values-not-supported' 1445 (0x040B). 1447 Octets Symbolic Value Protocol field 1449 0x0101 1.1 version-number 1450 0x040B client-error-attributes-or- status-code 1451 values-not-supported 1452 0x00000001 1 request-id 1453 0x01 start operation-attributes operation-attribute tag 1454 0x47 charset type value-tag 1455 0x0012 name-length 1456 attributes- attributes-charset name 1457 charset 1458 0x0008 value-length 1459 us-ascii US-ASCII value 1460 0x48 natural-language type value-tag 1461 0x001B name-length 1462 attributes- attributes-natural-language name 1463 natural- 1464 language 1465 0x0005 value-length 1466 en-us en-US value 1467 0x41 textWithoutLanguage type value-tag 1468 0x000E name-length 1469 status- status-message name 1470 message 1471 0x002F value-length 1472 client-error- client-error-attributes-or- value 1473 attributes- values-not-supported 1474 or-values- 1475 not-supported 1476 0x05 start unsupported-attributes unsupported-attributes tag 1477 0x21 integer type value-tag 1478 0x0006 name-length 1479 copies copies name 1480 0x0004 value-length 1481 0x00000014 20 value 1482 0x10 unsupported (type) value-tag 1483 0x0005 name-length 1484 sides sides name 1485 0x0000 value-length 1486 0x03 end-of-attributes end-of-attributes-tag 1488 13.4 Print-Job Response (success with attributes ignored) 1490 Here is an example of a successful Print-Job response to a Print-Job 1491 request like the previous Print-Job request, except that the value of 1492 'ipp-attribute-fidelity' is false. The print request succeeds, even 1493 though, in this case, the printer supports neither the "sides" attribute 1494 nor the value '20' for the "copies" attribute. Therefore, a job is 1495 created, and both a "job-id" and a "job-uri" operation attribute are 1496 returned. The unsupported attributes are also returned in an Unsupported 1497 Attributes Group. The error code returned is 'successful-ok-ignored-or- 1498 substituted-attributes' (0x0001). 1500 Octets Symbolic Value Protocol field 1502 0x0101 1.1 version-number 1503 0x0001 successful-ok-ignored-or- status-code 1504 substituted-attributes 1505 0x00000001 1 request-id 1506 0x01 start operation-attributes operation-attributes-tag 1507 0x47 charset type value-tag 1508 0x0012 name-length 1509 attributes- attributes-charset name 1510 charset 1511 0x0008 value-length 1512 us-ascii US-ASCII value 1513 0x48 natural-language type value-tag 1514 0x001B name-length 1515 attributes- attributes-natural- name 1516 natural-language language 1517 0x0005 value-length 1518 en-us en-US value 1519 0x41 textWithoutLanguage type value-tag 1520 0x000E name-length 1521 status-message status-message name 1522 0x002F value-length 1523 successful-ok- successful-ok-ignored-or- value 1524 ignored-or- substituted-attributes 1525 substituted- 1526 attributes 1527 0x05 start unsupported- unsupported-attributes 1528 attributes tag 1529 0x21 integer type value-tag 1530 0x0006 name-length 1531 copies copies name 1532 0x0004 value-length 1533 0x00000014 20 value 1534 0x10 unsupported (type) value-tag 1535 0x0005 name-length 1536 sides sides name 1537 0x0000 value-length 1538 0x02 start job-attributes job-attributes-tag 1539 0x21 integer value-tag 1540 0x0006 name-length 1541 job-id job-id name 1542 0x0004 value-length 1543 147 147 value 1544 0x45 uri type value-tag 1545 0x0007 name-length 1546 job-uri job-uri name 1547 0x0019 value-length 1548 ipp://forest/pin job 123 on pinetree value 1549 etree/123 1550 0x23 enum type value-tag 1551 0x0009 name-length 1552 job-state job-state name 1553 0x0004 value-length 1554 Octets Symbolic Value Protocol field 1556 0x0003 pending value 1557 0x03 end-of-attributes end-of-attributes-tag 1559 13.5 Print-URI Request 1561 The following is an example of Print-URI request with copies and job- 1562 name parameters: 1564 Octets Symbolic Value Protocol field 1565 0x0101 1.1 version-number 1566 0x0003 Print-URI operation-id 1567 0x00000001 1 request-id 1568 0x01 start operation-attributes operation-attributes-tag 1569 0x47 charset type value-tag 1570 0x0012 name-length 1571 attributes- attributes-charset name 1572 charset 1573 0x0008 value-length 1574 us-ascii US-ASCII value 1575 0x48 natural-language type value-tag 1576 0x001B name-length 1577 attributes- attributes-natural-language name 1578 natural- 1579 language 1580 0x0005 value-length 1581 en-us en-US value 1582 0x45 uri type value-tag 1583 0x000B name-length 1584 printer-uri printer-uri name 1585 0x0015 value-length 1586 ipp://forest/ printer pinetree value 1587 pinetree 1588 0x45 uri type value-tag 1589 0x000C name-length 1590 document-uri document-uri name 1591 0x0011 value-length 1592 ftp://foo.com ftp://foo.com/foo value 1593 /foo 1594 0x42 nameWithoutLanguage type value-tag 1595 0x0008 name-length 1596 job-name job-name name 1597 0x0006 value-length 1598 foobar foobar value 1599 0x02 start job-attributes job-attributes-tag 1600 0x21 integer type value-tag 1601 0x0006 name-length 1602 copies copies name 1603 0x0004 value-length 1604 0x00000001 1 value 1605 0x03 end-of-attributes end-of-attributes-tag 1607 13.6 Create-Job Request 1609 The following is an example of Create-Job request with no parameters and 1610 no attributes: 1612 Octets Symbolic Value Protocol field 1613 0x0101 1.1 version-number 1614 0x0005 Create-Job operation-id 1615 0x00000001 1 request-id 1616 0x01 start operation-attributes operation-attributes-tag 1617 0x47 charset type value-tag 1618 0x0012 name-length 1619 attributes- attributes-charset name 1620 charset 1621 0x0008 value-length 1622 us-ascii US-ASCII 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 0x45 uri type value-tag 1631 0x000B name-length 1632 printer-uri printer-uri name 1633 0x0015 value-length 1634 ipp://forest/p printer pinetree value 1635 inetree 1636 0x03 end-of-attributes end-of-attributes-tag 1638 13.7 Get-Jobs Request 1640 The following is an example of Get-Jobs request with parameters but no 1641 attributes: 1643 Octets Symbolic Value Protocol field 1644 0x0101 1.1 version-number 1645 0x000A Get-Jobs operation-id 1646 0x00000123 0x123 request-id 1647 0x01 start operation-attributes operation-attributes-tag 1648 0x47 charset type value-tag 1649 0x0012 name-length 1650 attributes- attributes-charset name 1651 charset 1652 0x0008 value-length 1653 us-ascii US-ASCII value 1654 0x48 natural-language type value-tag 1655 0x001B name-length 1656 attributes- attributes-natural-language name 1657 natural- 1658 language 1659 0x0005 value-length 1660 en-us en-US value 1661 0x45 uri type value-tag 1662 0x000B name-length 1663 printer-uri printer-uri name 1664 0x0015 value-length 1665 ipp://forest/pi printer pinetree value 1666 netree 1667 0x21 integer type value-tag 1668 0x0005 name-length 1669 limit limit name 1670 0x0004 value-length 1671 0x00000032 50 value 1672 0x44 keyword type value-tag 1673 0x0014 name-length 1674 requested- requested-attributes name 1675 attributes 1676 0x0006 value-length 1677 job-id job-id value 1678 0x44 keyword type value-tag 1679 0x0000 additional value name-length 1680 0x0008 value-length 1681 job-name job-name value 1682 0x44 keyword type value-tag 1683 0x0000 additional value name-length 1684 0x000F value-length 1685 document-format document-format value 1686 0x03 end-of-attributes end-of-attributes-tag 1688 13.8 Get-Jobs Response 1690 The following is an of Get-Jobs response from previous request with 3 1691 jobs. The Printer returns no information about the second job (because 1692 of security reasons): 1694 Octets Symbolic Value Protocol field 1695 0x0101 1.1 version-number 1696 0x0000 successful-ok status-code 1697 0x00000123 0x123 request-id (echoed 1698 back) 1699 0x01 start operation-attributes operation-attribute-tag 1700 0x47 charset type value-tag 1701 0x0012 name-length 1702 attributes- attributes-charset name 1703 charset 1704 0x000A value-length 1705 ISO-8859-1 ISO-8859-1 value 1706 0x48 natural-language type value-tag 1707 0x001B name-length 1708 attributes- attributes-natural-language name 1709 natural- 1710 language 1711 0x0005 value-length 1712 en-us en-US value 1713 0x41 textWithoutLanguage type value-tag 1714 0x000E name-length 1715 status-message status-message name 1716 0x000D value-length 1717 successful-ok successful-ok value 1718 0x02 start job-attributes (1st job-attributes-tag 1719 object) 1720 0x21 integer type value-tag 1721 0x0006 name-length 1722 job-id job-id name 1723 0x0004 value-length 1724 147 147 value 1725 0x36 nameWithLanguage value-tag 1726 0x0008 name-length 1727 job-name job-name name 1728 0x000C value-length 1729 0x0005 sub-value-length 1730 fr-ca fr-CA value 1731 0x0003 sub-value-length 1732 fou fou name 1733 0x02 start job-attributes (2nd job-attributes-tag 1734 object) 1735 0x02 start job-attributes (3rd job-attributes-tag 1736 object) 1737 0x21 integer type value-tag 1738 0x0006 name-length 1739 job-id job-id name 1740 0x0004 value-length 1741 148 149 value 1742 0x36 nameWithLanguage value-tag 1743 0x0008 name-length 1744 job-name job-name name 1745 0x0012 value-length 1746 0x0005 sub-value-length 1747 de-CH de-CH value 1748 Octets Symbolic Value Protocol field 1749 0x0009 sub-value-length 1750 isch guet isch guet name 1751 0x03 end-of-attributes end-of-attributes-tag 1753 14. Appendix B: Registration of MIME Media Type Information for 1754 "application/ipp" 1756 This appendix contains the information that IANA requires for 1757 registering a MIME media type. The information following this paragraph 1758 will be forwarded to IANA to register application/ipp whose contents are 1759 defined in Section 3 "Encoding of the Operation Layer" in this 1760 document: 1762 MIME type name: application 1764 MIME subtype name: ipp 1766 A Content-Type of "application/ipp" indicates an Internet Printing 1767 Protocol message body (request or response). Currently there is one 1768 version: IPP/1.1, whose syntax is described in Section 3 "Encoding of 1769 the Operation Layer" of [ipp-pro], and whose semantics are described in 1770 [ipp-mod]. 1772 Required parameters: none 1774 Optional parameters: none 1776 Encoding considerations: 1778 IPP/1.1 protocol requests/responses MAY contain long lines and ALWAYS 1779 contain binary data (for example attribute value lengths). 1781 Security considerations: 1783 IPP/1.1 protocol requests/responses do not introduce any security risks 1784 not already inherent in the underlying transport protocols. Protocol 1785 mixed-version interworking rules in [ipp-mod] as well as protocol 1786 encoding rules in [ipp-pro] are complete and unambiguous. 1788 Interoperability considerations: 1790 IPP/1.1 requests (generated by clients) and responses (generated by 1791 servers) MUST comply with all conformance requirements imposed by the 1792 normative specifications [ipp-mod] and [ipp-pro]. Protocol encoding 1793 rules specified in [ipp-pro] are comprehensive, so that interoperability 1794 between conforming implementations is guaranteed (although support for 1795 specific optional features is not ensured). Both the "charset" and 1796 "natural-language" of all IPP/1.1 attribute values which are a 1797 LOCALIZED-STRING are explicit within IPP protocol requests/responses 1798 (without recourse to any external information in HTTP, SMTP, or other 1799 message transport headers). 1801 Published specifications: 1803 [ipp-mod] Isaacson, S., deBry, R., Hastings, T., Herriot, R., 1804 Powell, P., "Internet Printing Protocol/1.1: Model and 1805 Semantics" draft-ietf-ipp-model-v11-05.txt, February 23, 2000. 1807 [ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., 1808 "Internet Printing Protocol/1.1: Encoding and Transport", draft- 1809 ietf-ipp-protocol-v11-04.txt, February 23, 2000. 1811 Applications which use this media type: 1813 Internet Printing Protocol (IPP) print clients and print servers, 1814 communicating using HTTP/1.1 (see [IPP-PRO]), SMTP/ESMTP, FTP, or other 1815 transport protocol. Messages of type "application/ipp" are self- 1816 contained and transport-independent, including "charset" and "natural- 1817 language" context for any LOCALIZED-STRING value. 1819 Person & email address to contact for further information: 1821 Tom Hastings 1822 Xerox Corporation 1823 737 Hawaii St. ESAE-231 1824 El Segundo, CA 1826 Phone: 310-333-6413 1827 Fax: 310-333-5514 1828 Email: hastings@cp10.es.xerox.com 1830 or 1832 Robert Herriot 1833 Xerox Corporation 1834 3400 Hillview Ave., Bldg #1 1835 Palo Alto, CA 94304 1837 Phone: 650-813-7696 1838 Fax: 650-813-6860 1839 Email: robert.herriot@pahv.xerox.com 1841 Intended usage: 1843 COMMON 1845 15. Appendix C: Changes from IPP/1.0 1847 IPP/1.1 is identical to IPP/1.0 [RFC2565] with the follow changes: 1849 1. 1850 Attributes values that identify a printer or job object use a new 1851 'ipp' scheme. The 'http' and 'https' schemes are supported only for 1852 backward compatibility. See section 5. 1854 2. 1855 Clients MUST support of Digest Authentication, IPP Printers SHOULD 1856 support Digest Authentication. See Section 8.1.1 1858 3. 1859 TLS is recommended for channel security. In addition, SSL3 may be 1860 supported for backward compatibility. See Section 8.1.2 1862 4. 1863 It is recommended that IPP/1.1 objects accept any request with major 1864 version number '1'. See section 9.1. 1866 5. 1867 IPP objects SHOULD return the URL scheme requested for "job-printer- 1868 uri" and "job-uri" Job Attributes, rather than the URL scheme used to 1869 create the job. See section 9.2. 1871 6. 1872 The IANA and Internationalization sections have been added. The 1873 terms "private use" and "experimental" have been changed to "vendor 1874 extension". The reserved allocations for attribute group tags, 1875 attribute syntax tags, and out-of-band attribute values have been 1876 clarified as to which are reserved to future IETF standards track 1877 documents and which are reserved to vendor extension. Both kinds of 1878 extensions use the type2 registration procedures as defined in [ipp- 1879 mod]. 1881 16. Full Copyright Statement 1883 The IETF takes no position regarding the validity or scope of any 1884 intellectual property or other rights that might be claimed to pertain 1885 to the implementation or use of the technology described in this 1886 document or the extent to which any license under such rights might or 1887 might not be available; neither does it represent that it has made any 1888 effort to identify any such rights. Information on the IETF's 1889 procedures with respect to rights in standards-track and standards- 1890 related documentation can be found in BCP-11[BCP-11]. Copies of claims 1891 of rights made available for publication and any assurances of licenses 1892 to be made available, or the result of an attempt made to obtain a 1893 general license or permission for the use of such proprietary rights by 1894 implementers or users of this specification can be obtained from the 1895 IETF Secretariat. 1897 The IETF invites any interested party to bring to its attention any 1898 copyrights, patents or patent applications, or other proprietary rights 1899 which may cover technology that may be required to practice this 1900 standard. Please address the information to the IETF Executive 1901 Director. 1903 Copyright (C)The Internet Society (1999). All Rights Reserved 1905 This document and translations of it may be copied and furnished to 1906 others, and derivative works that comment on or otherwise explain it or 1907 assist in its implementation may be prepared, copied, published and 1908 distributed, in whole or in part, without restriction of any kind, 1909 provided that the above copyright notice and this paragraph are included 1910 on all such copies and derivative works. However, this document itself 1911 may not be modified in any way, such as by removing the copyright notice 1912 or references to the Internet Society or other Internet organizations, 1913 except as needed for the purpose of developing Internet standards in 1914 which case the procedures for copyrights defined in the Internet 1915 Standards process must be followed, or as required to translate it into 1916 languages other than English. 1918 The limited permissions granted above are perpetual and will not be 1919 revoked by the Internet Society or its successors or assigns. 1921 This document and the information contained herein is provided on an "AS 1922 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1923 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1924 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1925 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1926 FITNESS FOR A PARTICULAR PURPOSE.