idnits 2.17.1 draft-ietf-ipp-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 30 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 68 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 81 has weird spacing: '...ding of the O...' == Line 125 has weird spacing: '...ists of a mes...' == Line 138 has weird spacing: '...ding of the O...' == Line 187 has weird spacing: '...ists of a seq...' == Line 268 has weird spacing: '...ute-tag attri...' == (63 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: . "request-URI": The request-URI of each operation in the IPP model document SHALL be specified outside of the operation layer as the request-URI on the Request-Line at the HTTP level, and SHALL not be specified within the operation layer. . "document-content": The parameter named "document-content" in the IPP model document SHALL become the "data" in the operation layer. . "status-code": The parameter named "status-code" in the IPP model document SHALL become the "status-code" field in the operation layer response. -- 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 (July 14, 1997) is 9775 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) == Unused Reference: '1' is defined on line 1299, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1302, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1305, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1308, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1310, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1312, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1315, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1318, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1325, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1328, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1331, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 1336, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 1338, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 1341, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 1353, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1759 (ref. '1') (Obsoleted by RFC 3805) ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '2') ** Obsolete normative reference: RFC 822 (ref. '3') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1543 (ref. '4') (Obsoleted by RFC 2223) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 1521 (ref. '8') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Downref: Normative reference to an Informational RFC: RFC 1179 (ref. '10') ** Obsolete normative reference: RFC 1738 (ref. '11') (Obsoleted by RFC 4248, RFC 4266) -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' -- Possible downref: Non-RFC (?) normative reference: ref. '23' -- Possible downref: Non-RFC (?) normative reference: ref. '24' ** Obsolete normative reference: RFC 1766 (ref. '26') (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2068 (ref. '27') (Obsoleted by RFC 2616) -- Possible downref: Non-RFC (?) normative reference: ref. '28' == Outdated reference: A later version (-04) exists of draft-ietf-drums-abnf-02 Summary: 17 errors (**), 0 flaws (~~), 25 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 4 Robert Herriot (editor) 5 Sun Microsystems 6 Sylvan Butler 7 Hewlett-Packard 8 Paul Moore 9 Microsoft. 10 Randy Turner 11 Sharp Labs 12 July 14, 1997 14 Internet Printing Protocol/1.0: Protocol Specification 15 draft-ietf-ipp-protocol-00.txt 17 Status of this Memo 19 This document is an Internet-Draft. 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 To learn the current status of any Internet-Draft, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 32 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 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 39 application level protocol that can be used for distributed printing 40 using Internet tools and technology. The protocol is heavily influenced 41 by the printing model introduced in the Document Printing Application 42 (ISO/IEC 10175 DPA) standard. Although DPA specifies both end user and 43 administrative features, IPP version 1.0 is focused only on end user 44 functionality. 46 The full set of IPP documents includes: 48 Internet Printing Protocol: Requirements 49 Internet Printing Protocol/1.0: Model and Semantics 50 Internet Printing Protocol/1.0: Security 51 Internet Printing Protocol/1.0: Protocol Specification 52 Internet Printing Protocol/1.0: Directory Schema 54 The requirements document takes a broad look at distributed printing 55 functionality, and it enumerates real-life scenarios that help to 56 clarify the features that need to be included in a printing protocol for 57 the Internet. It identifies requirements for three types of users: end 58 users, operators, and administrators. The requirements document calls 59 out a subset of end user requirements that MUST be satisfied in the 60 first version of IPP. Operator and administrator requirements are out 61 of scope for v1.0. The model and semantics document describes a 62 simplified model with abstract objects, their attributes, and their 63 operations. The model introduces a Printer object and a Job object. The 64 Job object supports multiple documents per job. The security document 65 covers potential threats and proposed counters to those threats. The 66 protocol specification is formal document which incorporates the ideas 67 in all the other documents into a concrete mapping using clearly defined 68 data representations and transport protocol mappings that real 69 implementers can use to develop interoperable client and server side 70 components. Finally, the directory schema document shows a generic 71 schema for directory service entries that represent instances of IPP 72 Printers. 74 This document is the "Internet Printing Protocol/1.0: Protocol 75 Specification" document. 77 Table of Contents 79 1. Introduction........................................................4 80 2. Conformance Terminology.............................................4 81 3. Encoding of the Operation Layer....................................4 82 3.1 Picture of the Encoding.........................................4 83 3.2 Syntax of Encoding..............................................7 84 3.3 Version.........................................................8 85 3.4 Mapping of Operations...........................................8 86 3.5 Mapping of Status-code..........................................8 87 3.6 Tags............................................................9 88 3.7 Name-Lengths...................................................11 89 3.8 Mapping of Parameter Names.....................................11 90 3.9 Value Lengths..................................................12 91 3.10 Mapping of Attribute and Parameter Values.....................13 92 3.11 Data..........................................................14 93 4. Encoding of Transport Layer........................................14 94 4.1 General Headers................................................15 95 4.2 Request Headers...............................................16 96 4.3 Response Headers...............................................17 97 4.4 Entity Headers................................................17 98 5. Security Considerations............................................18 99 6. Appendix A: Protocol Examples......................................18 100 6.1 Print-Job Request..............................................18 101 6.2 Print-Job Response (successful)................................19 102 6.3 Print-Job Response (failure)...................................19 103 6.4 Print-URI Request..............................................20 104 6.5 Create-Job Request.............................................20 105 6.6 Get-Jobs Request...............................................21 106 6.7 Get-Jobs Response..............................................21 107 7. Appendix B: Requirements without HTTP/1.1 as a Transport Layer.....22 108 7.1 Additional Parameter-group for HTTP header information.........22 109 7.2 Chunking of Data...............................................23 110 7.3 Revised Picture for the Operation Layer........................24 111 7.4 Revised Syntax for the Operation Layer.........................24 112 8. Appendix C: Mapping of Each Operation in the Encoding..............25 113 9. References.........................................................27 114 10. Author's Address..................................................28 115 11. Other Participants:...............................................29 116 1. Introduction 118 This document contains the rules for encoding IPP operations and 119 describes two layers: the transport layer and the operation layer. 121 The transport layer consists of an HTTP/1.1 request or response. RFC 122 2068 [27] describes HTTP/1.1. This document specifies the HTTP headers 123 that an IPP implementation supports. 125 The operation layer consists of a message body in an HTTP request or 126 response. The document "Internet Printing Protocol/1.0: Model and 127 Semantics" [21] defines the semantics of such a message body and the 128 supported values. This document specifies the encoding of an IPP 129 operation. The aforementioned document [21] is henceforth referred to as 130 the "IPP model document" 132 2. Conformance Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [25]. 138 3. Encoding of the Operation Layer 140 The operation layer SHALL contain a single operation request or 141 operation response. 143 The encoding consists of two primitive types. integers and characters, 144 on which all other data types are built. Every character in this 145 encoding SHALL be a member of the UCS-2 coded character set and SHALL be 146 encoded using UTF-8 Every integer in this encoding SHALL be encoded in 147 binary as a signed integer with big-endian format (also known as 148 "network order" and "most significant byte first"). The number of bytes 149 for an integer SHALL be a power of 2, that is, 1, 2 and 4. 151 The following two sections present the operation layer in two ways 153 . informally through pictures and description 154 . formally through Augmented Backus-Naur Form (ABNF), as specified by 155 draft-ietf-drums-abnf-02.txt [29] 157 3.1 Picture of the Encoding 159 The encoding for an operation request or response consists of: 161 ----------------------------------------------- 162 | version | 2 bytes - required 163 ----------------------------------------------- 164 |operation (request) or status-code (response)| 2 bytes - required 165 ----------------------------------------------------------- 166 | parameter-tag | 1 byte | 167 ----------------------------------------------- |- optional 168 | parameter-sequence | m bytes | 169 ----------------------------------------------------------- 170 | attribute-tag | 1 byte | 171 ----------------------------------------------- |-0 or more 172 | attribute-sequence | n bytes | 173 ----------------------------------------------------------- 174 | data-tag | 1 byte - required 175 ----------------------------------------------- 176 | data | q bytes - optional 177 ----------------------------------------------- 179 The parameter-tag and parameter-sequence may be omitted if the operation 180 has no parameters. The attribute-tag and attribute-sequence may be 181 omitted if the operation has no attributes or it may be replicated for 182 an operation that contains attributes for multiple objects. The data is 183 omitted from some operations, but the data-tag is present even when the 184 data is omitted. Note, the parameter-tag, attribute-tag and data-tag are 185 called `delimiter-tags'. 187 A parameter-sequence consists of a sequence of zero or more compound- 188 parameters. 190 ----------------------------------------------- 191 | compound-parameter | r bytes - 0 or more 192 ----------------------------------------------- 194 An attributes-sequence consists of zero or more compound-attributes. 196 ----------------------------------------------- 197 | compound-attribute | s bytes - 0 or more 198 ----------------------------------------------- 200 A compound-parameter consists of a parameter with a single value 201 optionally followed by zero or more additional values. A compound- 202 attribute consists an attribute with a single value followed by zero or 203 more additional values. 205 Each parameter or attribute consists of: 207 ----------------------------------------------- 208 | value-tag | 1 byte 209 ----------------------------------------------- 210 | name-length (value is u) | 2 bytes 211 ----------------------------------------------- 212 | name | u bytes 213 ----------------------------------------------- 214 | value-length (value is v) | 2 bytes 215 ----------------------------------------------- 216 | value | v bytes 217 ----------------------------------------------- 219 An additional value consists of: 221 ----------------------------------------------------------- 222 | value-tag | 1 byte | 223 ----------------------------------------------- | 224 | name-length (value is 0x0000) | 2 bytes | 225 ----------------------------------------------- |-0 or more 226 | value-length (value is w) | 2 bytes | 227 ----------------------------------------------- | 228 | value | w bytes | 229 ----------------------------------------------------------- 231 Note: an additional value is like a parameter or attribute whose name- 232 length is 0. 234 From the standpoint of a parsing loop, the encoding consists of: 236 ----------------------------------------------- 237 | version | 2 bytes - required 238 ----------------------------------------------- 239 |operation (request) or status-code (response)| 2 bytes - required 240 ----------------------------------------------------------- 241 | tag (delimiter-tag or value-tag) | 1 byte | 242 ----------------------------------------------- |-0 or more 243 | empty or rest of parameter/attribute | x bytes | 244 ----------------------------------------------------------- 245 | data-tag | 2 bytes - required 246 ----------------------------------------------- 247 | data | y bytes - optional 248 ----------------------------------------------- 250 The value of the tag determines whether the bytes following the tag are: 252 . parameters 253 . attributes 254 . data 255 . the remainder of a single parameter or attribute where the tag 256 specifies the type of the value. 258 3.2 Syntax of Encoding 260 The syntax below is ABNF except `strings of literals' SHALL be case 261 sensitive. For example `a' means lower case `a' and not upper case `A'. 262 In addition, two-byte binary signed integer fields are represented as 263 `%x' values which show their range of values. 265 ipp-message = ipp-request / ipp-response 266 ipp-request = version operation 267 [parameter-tag parameter-sequence ] 268 *(attribute-tag attribute-sequence) data-tag data 269 ipp-response = version status-code 270 [parameter-tag parameter-sequence ] 271 *(attribute-tag attribute-sequence) data-tag data 273 version = major-version minor-version 274 major-version = SIGNED-BYTE ; initially %d1 275 minor-version = SIGNED-BYTE ; initially %d0 277 operation = SIGNED-SHORT ; mapping from model defined below 278 status-code = SIGNED-SHORT ; mapping from model defined below 280 parameter-sequence = *compound-parameter 281 attribute-sequence = *compound-attribute 282 compound-parameter = parameter *additional-values 283 compound-attribute = attribute *additional-values 285 parameter = value-tag name-length name value-length value 286 attribute = value-tag name-length name value-length value 287 additional-values = value-tag zero-name-length value-length value 289 name-length = SIGNED-SHORT ; number of octets of `name' 290 name = LALPHA *( LALPHA / DIGIT / "-" / "_" ) 291 value-length = SIGNED-SHORT ; number of octets of `value' 292 value = OCTET-STRING 294 data = OCTET-STRING 296 zero-name-length = %x00.00 ; name-length of 0 297 parameter-tag = %x01 ; tag of 1 298 attribute-tag = %x02 ; tag of 2 299 data-tag = %x03 ; tag of 3 300 value-tag = %x10..%xFF 302 SIGNED-BYTE = %x00..%xFF 303 SIGNED-SHORT = %x00..%xFF %x00..%xFF 304 DIGIT = "0".."9" 305 LALPHA = "a".."z" 306 BYTE = %x00..%xFF 307 OCTET-STRING = *BYTE 309 The syntax allows a parameter-tag to be present when the parameter- 310 sequence that follows is empty. The same is true for the attribute-tag 311 and the attribute-sequence that follows. The syntax is defined this way 312 to allow for the response of Get-Jobs where no attributes are returned 313 for some job-objects. Although it is RECOMMENDED that the sender not 314 send a parameter-tag if there are no parameters and not send an 315 attribute-tag if there are no attributes (except in the Get-Jobs 316 response just mentioned), the receiver MUST be able to decode such 317 syntax. 319 3.3 Version 321 The version SHALL consist of a major and minor version, each of which 322 SHALL be represented by a one byte signed integer. The protocol 323 described in this document SHALL have a major version of 1 (0x01) and a 324 minor version of 0 (0x00). The ABNF for these two bytes SHALL be 325 %x01.00. 327 3.4 Mapping of Operations 329 The following SHALL be the mapping of operations names to integer values 330 which are encoded as two byte binary signed integers. The operations are 331 defined in the IPP model document The table below includes a range of 332 values for future extensions to the protocol and a separate range for 333 private extensions. It is RECOMMENDED that the private extension values 334 be used for temporary experimental implementations and not for deployed 335 products. 337 Encoding (hex) Operation 339 0x0 reserved (not used) 340 0x1 Get-Operations 341 0x2 Print-Job 342 0x3 Print-URI 343 0x4 Validate-Job 344 0x5 Create-Job 345 0x6 Send-Document 346 0x7 Send-URI 347 0x8 Cancel-Job 348 0x9 Get-Attributes 349 0xA Get-Jobs 350 0xB-0x3FFF reserved for future operations 351 0x4000-0xFFFF reserved for private extensions 353 3.5 Mapping of Status-code 355 The following SHALL be the mapping of status-code names to integer 356 values which are encoded as two byte binary signed integers. The status- 357 code names are defined in the IPP model document. 359 If an IPP status-code is returned, then the HTTP Status-Code MUST be 200 360 (OK). With any other HTTP Status-Code value, the HTTP response SHALL NOT 361 contain an IPP message-body, and thus no IPP status-code is returned. 363 Note: the integer encodings below were chosen to be similar to 364 corresponding Status-Code values in HTTP. The IPP client and server 365 errors have the same relative offset to their base as corresponding HTTP 366 errors, but the IPP base is a multiple of 0x100 whereas the HTTP base is 367 a multiple of 100. Despite this similarity, the Status-Code returned at 368 the HTTP level will always be different except in the case where `OK' is 369 returned at both levels, 200 (OK) in HTTP and 0 (successful-OK) in IPP. 371 Note: some status-code values, such as client-error-unauthorized, may 372 be returned at the transport (HTTP) level rather than the operation 373 level. 375 ISSUE: as implementations proceed, we will learn what error code need to 376 be supported at the IPP level. 378 Encoding (hex) Status-Code Name 380 0 successful-OK 381 0x400 client-error-bad-request 382 0x401 client-error-unauthorized 383 0x403 client-error-forbidden 384 0x404 client-error-not-found 385 0x405 client-error-method-not-allowed 386 0x408 client-error-timeout 387 0x40A client-error-gone 388 0x40D client-error-request-entity-too-large 389 0x40E client-error-request-URI-too-long 390 0x40F client-error-unsupported-document-format 391 0x410 client-error-attribute-not-supported 392 0x500 server-error-internal-server-error 393 0x501 server-error-operation-not-implemented 394 0x503 server-error-service-unavailable 395 0x504 server-error-timeout 396 0x505 server-error-version-not-supported 397 0x506 server-error-printer-error 398 0x507 server-error-temporary-error 400 3.6 Tags 402 There are two kinds of tags: 404 . delimiter tags: delimit major sections of the protocol, namely 405 parameters, attributes and data 406 . value tags: specify the type of each parameter or attribute value 408 The following table specifies the values for the delimiter tags: 410 Tag Value (Hex) Delimiter 412 0x00 reserved 413 0x01 parameter-tag 414 0x02 attribute-tag 415 0x03 data-tag 416 0x04-0x0F reserved for future delimiters 418 The remaining tables show values for the value-tag, which is the first 419 octet of a parameter or attribute. The value-tag specifies the type of 420 the value of the parameter or attribute. The value of the value-tag of a 421 parameter or attribute SHALL either be a type value specified in the 422 model document or an "out-of-band" value, such as "unsupported" or 423 "default". If the value of value-tag for a attribute or parameter is 424 not "out-of-band" and differs from the value type specified by the model 425 document, then a server receiving such a request MAY reject it, and a 426 client receiving such a response MAY ignore the attribute or parameter. 428 The following table specifies the "out-of-band" values for the value- 429 tag. 431 Tag Value (Hex) Meaning 433 0x10 unsupported 434 0x11 default 435 0x12-0x1F reserved for future "out-of-band" values. 437 The "unsupported" value SHALL be used in the attribute-sequence of an 438 error response for those attributes which the server does not support. 439 The "default" value is reserved for future use of setting value back to 440 their default value. 442 The following table specifies the integer values for the value-tag 444 Tag Value (Hex) Meaning 446 0x20 reserved 447 0x21 integer (up to 4 bytes) 448 0x22 boolean 449 0x23 seconds 450 0x24 milliseconds 451 0x25 enum 452 0x26-0x3F reserved for future integer types 454 NOTE: 0x20 is reserved for "generic integer" if should ever be needed. 456 The following table specifies the character-string values for the value- 457 tag 458 Tag Value (Hex) Meaning 460 0x40 reserved 461 0x41 text 462 0x42 name 463 0x43 filename 464 0x44 keyword 465 0x45 uri 466 0x46 uriScheme 467 0x47 dateTime 468 0x48-0x7F reserved for future character string types 470 NOTE: 0x40 is reserved for "generic character-string" if should ever be 471 needed. 473 The values 0x80-0xFF are reserved for future types. 475 3.7 Name-Lengths 477 The name-length field SHALL consist of a two byte binary signed integer 478 in big endian order. This field SHALL specify the number of octets in 479 the name field which follows the name-length field, excluding the two 480 bytes of the name-length field. 482 If a name-length field has a value of zero, the following name field 483 SHALL be empty, and the following value SHALL be treated as an 484 additional value for the preceding parameter. Within a parameter- 485 sequence, if two parameters have the same name, the first occurrence 486 SHALL be ignored. Within an attribute-sequence, if two attributes have 487 the same name, the first occurrence SHALL be ignored. The zero-length 488 name is the only mechanism for multi-valued parameters and attributes. 490 3.8 Mapping of Parameter Names 492 Some parameters are encoded in a special position. These parameters 493 are: 495 . "request-URI": The request-URI of each operation in the IPP model 496 document SHALL be specified outside of the operation layer as the 497 request-URI on the Request-Line at the HTTP level, and SHALL not be 498 specified within the operation layer. 499 . "document-content": The parameter named "document-content" in the 500 IPP model document SHALL become the "data" in the operation layer. 501 . "status-code": The parameter named "status-code" in the IPP model 502 document SHALL become the "status-code" field in the operation 503 layer response. 505 ISSUE: Should the request-URI that is the target object of the operation 506 be outside the operation layer, or should it be inside as a parameter 507 and a separate print server URI outside in the HTTP Request-Line? 508 The remaining parameters are encoded in the parameter-sequence or the 509 attribute-sequence. The parameter-sequence is for actual operation 510 parameters and the attribute-sequence is for object attributes. Of the 511 parameters defined in the IPP model document, some represent an actual 512 operation parameters and others represent a collection of object 513 attributes. 515 A parameter in the IPP model document SHALL represent a collection of 516 object attributes if its name contains the word "attributes" 517 immediately preceded by a space; otherwise it SHALL represent an actual 518 operation parameter. Note, some actual operation parameters contain the 519 word "attributes" preceded by a hyphen ("-"). They are not a collection 520 of attributes. 522 If a parameter in IPP model document represents an actual operation 523 parameter and is not in a special position, it SHALL be encoded in the 524 parameter-sequence using the text name of the parameter specified in the 525 IPP model document. 527 If a parameter in IPP model document represents a collection of object 528 attributes, the attributes SHALL be encoded in the attribute-sequence 529 using the text names of the attributes specified in the IPP model 530 document. The IPP model document specifies the members of such attribute 531 collections, but does not require that all members of a collection be 532 present in an operation. 534 If an operation contain attributes from exactly one object, there SHALL 535 be exactly one attribute-sequence. If an operation contains attributes 536 from more than one object (e.g. Get-Jobs response), the attributes from 537 each object SHALL be in a separate attribute-sequence, such that the 538 attributes from the ith object are in the ith attribute-sequence. 540 See Section 8 "Appendix C: Mapping of Each Operation in the Encoding" 541 for table showing the application of the rules above. 543 3.9 Value Lengths 545 Each parameter value SHALL be preceded by a two byte binary signed 546 integer in big endian order which SHALL specify the number of octets in 547 the value which follows this length, exclusive of the two bytes 548 specifying the length. 550 For any of the types represented by binary signed integers, the sender 551 MAY encode the value in fewer than the maximum 4 bytes, but the number 552 of bytes for the encoding MUST be a power of two, i.e. 1, 2 or 4, and 553 representation MUST be as a signed integer in the fewer bytes. 555 ISSUE: allowing 4 byte integers to be transmitted in 1 or 2 bytes, at 556 client discretion, may be more trouble than the saved bytes are worth. 557 Do we really want this? 558 For any of the types represented by character-strings, the sender MUST 559 encode the value with all the characters of the string and without any 560 padding characters. 562 If a value-tag contains an "out-of-band" value, such as "unsupported", 563 the value-length SHALL be 0 and the value empty -- the value has no 564 meaning when the value-tag has an "out-of-band" value. If a server or 565 client receives an operation with a nonzero value-length in this case, 566 it SHALL ignore the value field. 568 3.10 Mapping of Attribute and Parameter Values 570 The following SHALL be the mapping of attribute and parameter values to 571 their IPP encoding in the value field. The syntax types are defined in 572 the IPP model document. 574 Syntax of 575 Attribute Value Encoding 577 text an octet string where each character is 578 a member of the UCS-2 coded character 579 set and is encoded using UTF-8. The 580 text is encoded in "network byte order" 581 with the first character in the text 582 (according to reading order) being the 583 first character in the encoding. 584 name same as text 585 fileName same as text 586 keyword same as text. Allowed text values are 587 defined in the IPP model document 588 uri same as text 589 uriScheme same as text 590 boolean one binary octet where 0x00 is `false' 591 and 0x01 is `true' 592 integer number of octets is a power of 2 (i.e. 593 1, 2 or 4). These octets represent a 594 binary signed integer in big endian 595 order (also known as "network byte 596 order" and MSB first). 597 enum same as integer. Allowed integer values 598 are defined in the IPP model document 599 dateTime same as text. Syntax of data and time 600 is defined by ISO 8601 601 ISSUE: should ISO 8601 be called out in 602 the IPP model document? 603 seconds same as integer 604 milliseconds same as integer 605 1setOf X encoding according to the rules for a 606 parameter with more than more value. 607 Each value X is encoded according to 608 the rules for encoding its type. 609 rangeOf X same 1setOf X where the number of 610 Syntax of 611 Attribute Value Encoding 613 values is 2. 615 The type of the value in the model document determines the encoding in 616 the value and the value of the value-tag. 618 3.11 Data 620 The data part SHALL include any data required by the operation 622 4. Encoding of Transport Layer 624 HTTP/1.1 shall be the transport layer for this protocol. 626 The operation layer has been designed with the assumption that the 627 transport layer contains the following information: 629 . the URI of the target job or printer operation 630 . the total length of the data in the operation layer, either as a 631 single length or as a sequence of chunks each with a length. 632 . the client's language, the character-set and the transport 633 encoding. 635 Each HTTP operation shall use the POST method where the request-URI is 636 the object target of the operation, and where the "Content-Type" of the 637 message-body in each request and response shall be "application/ipp". 638 The message-body shall contain the operation layer and shall have the 639 syntax described in section 3.2 "Syntax of Encoding". 641 A client implementation SHALL adhere to the rules for a client described 642 in RFC 2068. A server implementation SHALL adhere the rules for an 643 origin server described in RFC 2068. 645 In the following sections, there are a tables of all HTTP headers which 646 describe their use in an IPP client or server. The following is an 647 explanation of each column in these tables. 649 . the "header" column contains the name of a header 650 . the "request/client" column indicates whether a client sends the 651 header. 652 . the "request/server" column indicates whether a server supports the 653 header when received. 654 . the "response/server" column indicates whether a server sends the 655 header. 656 . the "response /client" column indicates whether a client supports 657 the header when received. 658 . the "values and conditions" column specifies the allowed header 659 values and the conditions for the header to be present in a 660 request/response. 662 The table for "request headers" does not have columns for responses, and 663 the table for "response headers" does not have columns for requests. 665 The following is an explanation of the values in the "request/client" 666 and "response/server" columns. 668 . must: the client or server MUST send the header, 669 . must-if: the client or server MUST send the header when the 670 condition described in the "values and conditions" column is met, 671 . may: the client or server MAY send the header 672 . not: the client or server SHOULD NOT send the header. It is not 673 relevant to an IPP implementation. 675 The following is an explanation of the values in the "response/client" 676 and "request/server" columns. 678 . must: the client or server MUST support the header, 679 . may: the client or server MAY support the header 680 . not: the client or server SHOULD NOT support the header. It is not 681 relevant to an IPP implementation. 683 4.1 General Headers 685 The following is a table for the general headers. 687 ISSUE: an HTTP expert should review these tables for accuracy. 689 General- Request Response Values and Conditions 690 Header 692 Client Server Server Client 694 Cache- must not must not "no-cache" only 695 Control 696 Connection must-if must must-if must "close" only. Both 697 client and server 698 SHOULD keep a 699 connection for the 700 duration of a sequence 701 of operations. The 702 client and server MUST 703 include this header 704 for the last operation 705 in such a sequence. 706 Date may may must may per RFC 1123 [9] 707 Pragma` must not must not "no-cache" only 708 Transfer- must-if must must-if must "chunked" only . 709 Encoding Header MUST be present 710 if Content-Length is 711 absent. 712 Upgrade not not not not 713 General- Request Response Values and Conditions 714 Header 716 Client Server Server Client 718 Via not not not not 720 4.2 Request Headers 722 The following is a table for the request headers. 724 Request-Header Client Server Request Values and Conditions 726 Accept may must "application/ipp" only. This value 727 is the default if the client omits it 728 Accept-Charset may must per IANA Character Set registry. 729 ISSUE: is this useful for IPP? 730 Accept- may must empty and per RFC 2068 [27] and IANA 731 Encoding registry for content-codings 732 Accept- may must see RFC 1766 [26]. A server SHOULD 733 Language honor language requested by returning 734 the values status-message, job-state- 735 message and printer-state-reason in 736 one of requested languages. 737 Authorization must- must per RFC 2068. A client MUST send this 738 if header when it receives a 401 739 "Unauthorized" response and does not 740 receive a "Proxy-Authenticate" 741 header. 742 From not not per RFC 2068. Because RFC recommends 743 sending this header only with the 744 user's approval, it is not very 745 useful 746 Host must must per RFC 2068 747 If-Match not not 748 If-Modified- not not 749 Since 750 If-None-Match not not 751 If-Range not not 752 If-Unmodified- not not 753 Since 754 Max-Forwards not not 755 Proxy- must- not per RFC 2068. A client MUST send this 756 Authorization if header when it receives a 401 757 "Unauthorized" response and a "Proxy- 758 Authenticate" header. 759 Range not not 760 Referer not not 761 User-Agent not not 762 4.3 Response Headers 764 The following is a table for the request headers. 766 Response- Server Client Response Values and Conditions 767 Header 769 Accept-Ranges not not 770 Age not not 771 Location must-if may per RFC 2068. When URI needs 772 redirection. 773 Proxy- not must per RFC 2068 774 Authenticate 775 Public may may per RFC 2068 776 Retry-After may may per RFC 2068 777 Server not not 778 Vary not not 779 Warning may may per RFC 2068 780 WWW- must-if must per RFC 2068. When a server needs 781 Authenticate to authenticate a client. 783 4.4 Entity Headers 785 The following is a table for the entity headers. 787 Entity-Header Request Response Values and Conditions 789 Client Server Server Client 791 Allow not not not not 792 Content-Base not not not not 793 Content- may must must must per RFC 2068 and IANA 794 Encoding registry for content 795 codings. 796 Content- may must must must see RFC 1766 [26]. 797 Language 798 Content- must-if must must-if must the length of the 799 Length message-body per RFC 800 2068. Header MUST be 801 present if Transfer- 802 Encoding is absent.. 803 Content- not not not not 804 Location 805 Content-MD5 may may may may per RFC 2068 806 Content-Range not not not not 807 Content-Type must must must must "application/ipp" 808 only 809 ETag not not not not 810 Expires not not not not 811 Last-Modified not not not not 812 5. Security Considerations 814 When utilizing HTTP 1.1 as a transport of IPP, the security 815 considerations outlined in RFC 2068 apply. Specifically, IPP servers 816 can generate a 401 "Unauthorized" response code to request client 817 authentication and IPP clients should correctly respond with the proper 818 "Authorization" header. Both Basic Authentication (RFC 2068) and Digest 819 Authentication (RFC 2069) flavors of authentication should be supported. 820 The server chooses which type(s) of authentication to accept. Digest 821 Authentication is a more secure method, and is always preferred to Basic 822 Authentication. 824 For secure communication (privacy in particular), IPP should be run 825 using a secure communications channel. Both Transport Layer Security - 826 TLS (draft-ietf-tls-protocol-03) and IPSec (RFC 1825) provide necessary 827 features for security. It is possible to combine the two techniques, 828 HTTP 1.1 client authentication (either basic or digest) with secure 829 communications channel (either TLS or IPSec). Together the two are more 830 secure than client authentication and they perform user authentication. 832 Complete discussion of IPP security considerations can be found in the 833 IPP Security document 835 6. Appendix A: Protocol Examples 837 6.1 Print-Job Request 839 The following is an example of a Print-Job request with job-name, 840 copies, and sides specified. 842 Octets Symbolic Value Protocol field 844 0x0100 1.0 version 845 0x0002 PrintJob operation 846 0x02 start attributes attribute tag 847 0x42 name type value-tag 848 0x0008 name-length 849 job-name job-name name 850 0x0006 value-length 851 foobar foobar value 852 0x21 integer type value-tag 853 0x0005 name-length 854 copies copies name 855 0x0001 value-length 856 0x14 20 value 857 0x44 keyword type value-tag 858 0x0005 name-length 859 copies sides name 860 0x0001 value-length 861 two-sided-long-edge two-sided-long-edge value 862 Octets Symbolic Value Protocol field 864 0x03 start-data data-tag 865 %!PS... data 867 6.2 Print-Job Response (successful) 869 Here is an example of a Print-Job response which is successful: 871 Octets Symbolic Value Protocol field 873 0x0100 1.0 version 874 0x0000 OK (successful) status-code 875 0x01 start parameters parameter tag 876 0x41 text type value-tag 877 0x000E name-length 878 status-message status-message name 879 0x0002 value-length 880 OK OK value 881 0x45 uri type value-tag 882 0x0008 name-length 883 job-uri job-uri name 884 0x000E value-length 885 http://foo/123 http://foo/123 value 886 0x02 start attributes attribute tag 887 0x25 name type value-tag 888 0x0008 name-length 889 job-state job-state name 890 0x0001 value-length 891 0x03 pending value 892 0x03 start-data data-tag 894 6.3 Print-Job Response (failure) 896 Here is an example of a Print-Job response which fails because the 897 printer does not support sides and because the value 20 for copies is 898 not supported: 900 Octets Symbolic Value Protocol field 902 0x0100 1.0 version 903 0x0400 client-error-bad-request status-code 904 0x01 start parameters parameter tag 905 0x41 text type value-tag 906 0x000E name-length 907 status-message status-message name 908 0x000D value-length 909 bad-request bad-request value 910 0x02 start attributes attribute tag 911 0x21 integer type value-tag 912 Octets Symbolic Value Protocol field 914 0x0005 name-length 915 copies copies name 916 0x0001 value-length 917 0x14 20 value 918 0x10 unsupported (type) value-tag 919 0x0005 name-length 920 sides sides name 921 0x0000 value-length 922 0x03 start-data data-tag 924 6.4 Print-URI Request 926 The following is an example of Print-URI request with copies and job- 927 name parameters. 929 Octets Symbolic Value Protocol field 930 0x0100 1.0 version 931 0x0003 Print-URI operation 932 0x01 start-parameters parameter tag 933 0x45 uri type value-tag 934 0x000A name-length 935 document-uri document-uri name 936 0x11 value-length 937 ftp://foo.com/foo ftp://foo.com/foo value 938 0x02 start-attributes attribute tag 939 0x42 name type value-tag 940 0x0008 name-length 941 job-name job-name name 942 0x0006 value-length 943 foobar foobar value 944 0x21 integer type value-tag 945 0x0005 name-length 946 copies copies name 947 0x0001 value-length 948 0x01 1 value 949 0x03 start-data data-tag 950 %!PS... data 952 6.5 Create-Job Request 954 The following is an example of Create-Job request with no parameters and 955 no attributes 957 Octets Symbolic Value Protocol field 958 0x0100 1.0 version 959 0x0005 Create-Job operation 960 0x03 start-data data-tag 961 6.6 Get-Jobs Request 963 The following is an example of Get-Jobs request with parameters but no 964 attributes. 966 Octets Symbolic Value Protocol field 967 0x0100 1.0 version 968 0x000A Get-Jobs operation 969 0x01 start-parameters parameter-tag 970 0x21 integer type value-tag 971 0x0005 name-length 972 limit limit name 973 0x0001 value-length 974 0x32 50 value 975 0x44 keyword type value-tag 976 0x0014 name-length 977 requested-attributes requested-attributes name 978 0x0007 value-length 979 job-uri job-uri value 980 0x44 keyword type value-tag 981 0x0000 additional value name-length 982 0x0008 value-length 983 job-name job-name value 984 0x03 start-data data-tag 986 6.7 Get-Jobs Response 988 The following is an of Get-Jobs response from previous request with 3 989 jobs. The Printer returns no information about the second job. 991 Octets Symbolic Value Protocol field 992 0x0100 1.0 version 993 0x0000 OK (successful) status-code 994 0x01 start-parameters parameter-tag 995 0x41 text type value-tag 996 0x000E name-length 997 status-message status-message name 998 0x0002 value-length 999 OK OK value 1000 0x02 start-attributes (1st object) attribute-tag 1001 0x45 uri type value-tag 1002 0x0007 name-length 1003 job-uri job-uri name 1004 0x000E value-length 1005 http://foo/123 http://foo/123 value 1006 0x42 name type value-tag 1007 0x0008 name-length 1008 job-name job-name name 1009 0x0003 name-length 1010 foo foo name 1011 0x02 start-attributes (2nd object) attribute-tag 1012 0x02 start-attributes (3rd object) attribute-tag 1013 0x45 uri type value-tag 1014 Octets Symbolic Value Protocol field 1015 0x0007 name-length 1016 job-uri job-uri name 1017 0x000E value-length 1018 http://foo/124 http://foo/124 value 1019 0x42 name type value-tag 1020 0x0008 name-length 1021 job-name job-name name 1022 0x0003 name-length 1023 bar bar name 1024 0x03 start-data data-tag 1026 7. Appendix B: Requirements without HTTP/1.1 as a Transport Layer 1028 The operation layer defined above assumed certain services would be 1029 provided by the HTTP transport layer. Without that layer, information, 1030 such as length, request-URI and Content-Encoding are absent. 1032 This section specifies the modifications to the operation-layer encoding 1033 for raw TCP/IP. The following changes would have to made. All of these 1034 changes are upward compatible with the encoding defined in section 3 1035 "Encoding of the Operation Layer". 1037 7.1 Additional Parameter-group for HTTP header information 1039 There is an additional header-sequence which is like a parameter- 1040 sequence. The header-sequence SHALL appear the before the parameter- 1041 sequence, and it SHALL contain the "request-URI" along with relevant 1042 HTTP header information, including those shown below. This header- 1043 sequence SHALL be preceded by a header-tag to mark that a header- 1044 sequence follows. 1046 The following table shows the mapping of HTTP headers to parameters in 1047 the operation layer. 1049 HTTP header or other IPP header name Syntax Type of header 1050 concept 1052 URI request-URI uri 1053 Connection Close-Connection Boolean 1054 Accept-Charset Accept-Charset keyword 1055 Accept-Encoding Accept-Encoding keyword 1056 Accept-Language Accept-Language keyword 1057 Content-Encoding Content-Encoding keyword 1058 Content-Language Content-Language keyword 1059 charset parameter Content-Charset keyword 1060 miscellaneous security if needed at this level 1062 The first parameter in the header-sequence for a request SHALL be the 1063 attribute "request-URI" which is the target object of the operation. 1065 Except for Content-Encoding, the headers SHALL take effect at the 1066 beginning of the parameter-sequence and apply to the rest of the 1067 operation. If a header is Content-Encoding, then the encoding SHALL 1068 apply only to the `full-data' or `data-segment's as defined by the 1069 syntax below and the resulting decoded data SHALL have the syntax of all 1070 octets that follow a header-sequence. The syntax in a section below 1071 defines the syntax following a header-sequence to be: 1073 [ parameter-tag parameter-sequence ] 1074 *(attribute-tag attribute-sequence) data 1076 From a decoding point of view, if Content-Encoding is specified, the 1077 operation's data is decoded using the algorithm specified by Content- 1078 Encoding. The resulting octet stream is parsed as if it were the octets 1079 following a header-sequence. 1081 NOTE: This rule for Content-Encoding allows a client or server to encode 1082 the parameter-sequence and attribute-sequences or to transmit them un- 1083 encoded. 1085 ISSUE: should the status-message be in the header-sequence instead of 1086 the parameter-group for responses? 1088 7.2 Chunking of Data 1090 There is a new delimiter-tag called `chunked-data-tag' which denotes 1091 that the following data is chunked. Chunked data consists of a sequence 1092 of data-segment-lengths and data-segments. A data-segment-length of 0 1093 denotes the end of the data. 1095 The following is the informal picture of chunked-data: 1097 ----------------------------------------------------------- 1098 | data-segment-length | 2 bytes | 1099 ----------------------------------------------- |-0 or more 1100 | data-segment | n bytes | 1101 ----------------------------------------------------------- 1102 | 0x0000 (end-of-data) | 2 bytes - required 1103 ----------------------------------------------- 1105 The syntax for the chunked-data using ABNF is: 1107 chunked-data = *data-chunk end-of-data 1108 data-chunk = data-segment-length data-segment 1110 data-segment-length = SIGNED-SHORT ; number of octets 1111 ; of the data in binary 1112 data-segment = OCTET-STRING 1114 end-of-data = %x00.00 1116 A data-segment contains fragments of the data. When all the data- 1117 segments are concatenated together, they form the complete data. 1119 7.3 Revised Picture for the Operation Layer 1121 The encoding for an operation request or response consists of: 1123 ----------------------------------------------- 1124 | version | 2 bytes - required 1125 ----------------------------------------------- 1126 |operation (request) or status-code (response)| 2 bytes - required 1127 ----------------------------------------------------------- 1128 | header-tag | 1 byte | 1129 ----------------------------------------------- |- optional 1130 | header-sequence | k bytes | 1131 ----------------------------------------------------------- 1132 | parameter-tag | 1 byte | 1133 ----------------------------------------------- |- optional 1134 | parameter-sequence | m bytes | 1135 ----------------------------------------------------------- 1136 | attribute-tag | 1 byte | 1137 ----------------------------------------------- |-0 or more 1138 | attribute-sequence | n bytes | 1139 ----------------------------------------------------------- 1140 | data-tag | 1 byte - required 1141 ----------------------------------------------- 1142 | data | q bytes - optional 1143 ----------------------------------------------- 1145 The definition of all fields above is the same as defined in section 3.1 1146 "Picture of the Encoding" except 1148 . `data' which either has the form defined in the preceding section 1149 (7.3 "Revised Picture for the Operation Layer") or the form 1150 described in section 3.1 "Picture of the Encoding". 1151 . `header-tag' which is new and defined like parameter-tag. 1152 . `header-sequence' which is new and defined like parameter-sequence. 1154 7.4 Revised Syntax for the Operation Layer 1156 The following is the revised syntax for the operation layer. 1158 ipp-message = ipp-request / ipp-response 1159 ipp-request = version operation 1160 [ header-tag header-sequence ] 1161 [ parameter-tag parameter-sequence ] 1162 *(attribute-tag attribute-sequence) data 1163 ipp-response = version status-code 1164 [ header-tag header-sequence ] 1165 [ parameter-tag parameter-sequence ] 1166 *(attribute-tag attribute-sequence) data 1168 version = major-version minor-version 1169 major-version = SIGNED-BYTE ; initially %d1 1170 minor-version = SIGNED-BYTE ; initially %d0 1172 operation = SIGNED-SHORT ; mapping from model defined below 1173 status-code = SIGNED-SHORT ; mapping from model defined below 1175 header-sequence = *compound-header 1176 parameter-sequence = *compound-parameter 1177 attribute-sequence = *compound-attribute 1179 compound-header = header *(additional-values) 1180 compound-parameter = parameter *(additional-values) 1181 compound-attribute = attribute *(additional -values) 1183 header = value-tag name-length name value-length value 1184 parameter = value-tag name-length name value-length value 1185 attribute = value-tag name-length name value-length value 1186 additional-values = value-tag zero-name-length value-length value 1188 name-length = SIGNED-SHORT ; number of octets of `name' 1189 name = LALPHA *( LALPHA / DIGIT / "-" / "_" ) 1190 value-length = SIGNED-SHORT ; number of octets of `value' 1191 value = OCTET-STRING 1193 data = (data-tag full-data ) / (chunked-data-tag chunked-data ) 1194 full-data = OCTET-STRING 1195 chunked-data = *data-chunk END-OF-DATA 1196 data-chunk = data-segment-length data-segment 1197 data-segment-length = SIGNED-SHORT ; number of octets of the data 1198 in binary 1199 data-segment = OCTET-STRING 1201 zero-name-length = %x00.00 ; name-length of 0 1202 parameter-tag = %x01 ; tag of 1 1203 attribute-tag = %x02 ; tag of 2 1204 data-tag = %x03 ; tag of 3 1205 chunked-data-tag = %x04 ; tag of 4 1206 header-tag = %x05 ; tag of 5 1207 value-tag = %x10..%xFF 1208 end-of-data = %x00.00 1210 SIGNED-BYTE = %x00..%xFF 1211 SIGNED-SHORT = %x00..%xFF %x00..%xFF 1212 DIGIT = "0".."9" 1213 LALPHA = "a".."z" 1214 BYTE = %x00..%xFF 1215 OCTET-STRING = *BYTE 1217 8. Appendix C: Mapping of Each Operation in the Encoding 1219 The next three tables show the results of applying the rules above to 1220 the operations defined in the IPP model document. There is no 1221 information in these tables that cannot be derived from the rules 1222 presented in Section 3.8 "Mapping of Parameter Names". 1224 The following table shows the mapping of all IPP model document request 1225 parameters (except request-URI) to a parameter-sequence, attribute- 1226 sequence or special position in the protocol. 1228 Operation parameter- attribute- special position 1229 sequence sequence 1231 Get-Operations 1232 Print-Job job-template document-content 1233 attributes 1234 Validate-Job job-template 1235 or Create-Job attributes 1236 Print-URI document-uri job-template 1237 attributes 1238 Send-Document last-document document document-content 1239 attributes 1240 Send-URI last-document document 1241 document-uri attributes 1242 Cancel-Job message 1243 Get-Attributes document-format 1244 requested- 1245 attributes 1246 Get-Jobs limit 1247 requested- 1248 attributes 1250 The following table shows the mapping of all IPP model document response 1251 parameters to a parameter-sequence, attribute-sequence or special 1252 position in the protocol. 1254 Operation parameter-sequence attribute-sequence special 1255 position 1257 Get-Operations status-message status-code 1258 supported- 1259 operations 1261 Print-Job, status-message job-status status-code 1262 Print-URI or job-uri attributes 1263 Create-Job 1265 Send-Document status-message job-status status-code 1266 or Send-URI attributes 1268 Validate-Job status-message status-code 1269 Operation parameter-sequence attribute-sequence special 1270 position 1272 Cancel-Job status-message status-code 1274 Get-Attributes status-message requested attributes status-code 1276 Get-Jobs status-message requested attributes status-code 1277 (see the Note below) 1279 Note for Get-Jobs: there is a separate attribute-sequence containing 1280 requested-attributes for each job object in the response 1282 The following table shows the mapping of all IPP model document error 1283 response parameters to a parameter-sequence, attribute-sequence or 1284 special position in the protocol. Those operations omitted don't have 1285 special parameters for an error return. 1287 Operation parameter- attribute- special position 1288 sequence sequence 1290 Print-Job, status-message unsupported status-code 1291 Print-URI, attributes 1292 Validate-Job, 1293 Create-Job, 1294 Send-Document 1295 or Send-URI 1297 9. References 1299 [1] Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, 1300 J., "Printer MIB", RFC 1759, March 1995. 1302 [2] Berners-Lee, T, Fielding, R., and Nielsen, H., "Hypertext Transfer 1303 Protocol - HTTP/1.0", RFC 1945, August 1995. 1305 [3] Crocker, D., "Standard for the Format of ARPA Internet Text 1306 Messages", RFC 822, August 1982. 1308 [4] Postel, J., "Instructions to RFC Authors", RFC 1543, October 1993. 1310 [5] ISO/IEC 10175 Document Printing Application (DPA), June 1996. 1312 [6] Herriot, R. (editor), X/Open A Printing System Interoperability 1313 Specification (PSIS), August 1995. 1315 [7] Kirk, M. (editor), POSIX System Administration - Part 4: Printing 1316 Interfaces, POSIX 1387.4 D8, 1994. 1318 [8] Borenstein, N., and Freed, N., "MIME (Multi-purpose Internet Mail 1319 Extensions) Part One: Mechanism for Specifying and Describing the 1320 Format of Internet Message Bodies", RFC 1521, September, 1993. 1322 [9] Braden, S., "Requirements for Internet Hosts - Application and 1323 Support", RFC 1123, October, 1989, 1325 [10] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" RFC 1326 1179, August 1990. 1328 [11] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform Resource 1329 Locators (URL)", RFC 1738, December, 1994. 1331 [20] Wright, F. D., "Internet Printing Protocol: Requirements" 1333 [21] Isaacson, S, deBry, R, Hasting, T, Herriot, R, Powell, P, "Internet 1334 Printing Protocol/1.0: Model and Semantics" 1336 [22] Internet Printing Protocol/1.0: Security 1338 [23] Herriot, R, Butler, S, Moore, P, Turner, R, "Internet Printing 1339 Protocol/1.0: Protocol Specification" (This document) 1341 [24] Carter, K, Isaacson, S, "Internet Printing Protocol/1.0: Directory 1342 Schema" 1344 [25] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1345 Levels", RFC 2119 , March 1997 1347 [26] H. Alvestrand, " Tags for the Identification of Languages", RFC 1348 1766, March 1995. 1350 [27] R Fielding, et al, "Hypertext Transfer Protocol " HTTP/1.1" 1351 RFC 2068, January 1997 1353 [28] Marcus Kuhn, "International Standard Date and Time Notation", 1354 ISO 8601, 1355 http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html 1357 [29] D. Crocker et al., "Augmented BNF for Syntax Specifications: ABNF", 1358 draft-ietf-drums-abnf-02.txt. 1360 10. Author's Address 1362 Robert Herriot (editor) 1363 Sun Microsystems Inc. 1364 901 San Antonio.Road, MPK-17 1365 Palo Alto, CA 94303 1367 Phone: 415-786-8995 1368 Fax: 415-786-7077 1369 Email: robert.herriot@eng.sun.com 1370 Sylvan Butler 1371 Hewlett-Packard 1372 11311 Chinden Blvd. 1373 Boise, ID 83714 1375 Phone: 208-396-6000 1376 Fax: 208-396-3457 1377 Email: sbutler@boi.hp.com 1379 Paul Moore 1380 Microsoft 1381 One Microsoft Way 1382 Redmond, WA 98053 1384 Phone: 425-936-0908 1385 Fax: 425-93MS-FAX 1386 Email: paulmo@microsoft.com 1388 Randy Turner 1389 Sharp Laboratories 1390 5750 NW Pacific Rim Blvd 1391 Camas, WA 98607 1393 Phone: 360-817-8456 1394 Fax: : 360-817-8436 1395 Email: rturner@sharplabs.com 1397 IPP Mailing List: ipp@pwg.org 1398 IPP Mailing List Subscription: ipp-request@pwg.org 1399 IPP Web Page: http://www.pwg.org/ipp/ 1401 11. Other Participants: 1403 Chuck Adams - Tektronix 1404 Ron Bergman - Data Products 1405 Keith Carter - IBM 1406 Angelo Caruso - Xerox 1407 Jeff Copeland - QMS 1408 Roger Debry - IBM 1409 Lee Farrell - Canon 1410 Sue Gleeson - Digital 1411 Charles Gordon - Osicom 1412 Brian Grimshaw - Apple 1413 Jerry Hadsell - IBM 1414 Richard Hart - Digital 1415 Tom Hastings - Xerox 1416 Stephen Holmstead 1417 Zhi-Hong Huang - Zenographics 1418 Scott Isaacson - Novell 1419 Rich Lomicka - Digital 1420 David Kellerman - Northlake Software 1421 Robert Kline - TrueSpectra 1422 Dave Kuntz - Hewlett-Packard 1423 Takami Kurono - Brother 1424 Rich Landau - Digital 1425 Greg LeClair - Epson 1426 Harry Lewis - IBM 1427 Tony Liao - Vivid Image 1428 David Manchala - Xerox 1429 Carl-Uno Manros - Xerox 1430 Jay Martin - Underscore 1431 Larry Masinter - Xerox 1432 Bob Pentecost - Hewlett-Packard 1433 Patrick Powell - SDSU 1434 Jeff Rackowitz - Intermec 1435 Xavier Riley - Xerox 1436 Gary Roberts - Ricoh 1437 Stuart Rowley - Kyocera 1438 Richard Schneider - Epson 1439 Shigern Ueda - Canon 1440 Bob Von Andel - Allegro Software 1441 William Wagner - Digital Products 1442 Jasper Wong - Xionics 1443 Don Wright - Lexmark 1444 Rick Yardumian - Xerox 1445 Lloyd Young - Lexmark 1446 Peter Zehler - Xerox 1447 Frank Zhao - Panasonic 1448 Steve Zilles - Adobe