idnits 2.17.1 draft-ietf-ipp-install-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? 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. ** The abstract seems to contain references ([RFC2911,RFC2910], [RFC2566,RFC2565]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 126: '... Table 3 - REQUIRED "client-print-su...' RFC 2119 keyword, line 157: '... MAY have multiple sets of Client Pr...' RFC 2119 keyword, line 169: '...d terms, such as MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 170: '... NOT, MAY, NEED NOT, and OPTIONAL, h...' RFC 2119 keyword, line 179: '...his document, it MUST support a REQUIR...' (86 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 382 has weird spacing: '...gnature mecha...' == Line 483 has weird spacing: '... scheme str...' == 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 'MUST not' in this paragraph: "file- One OPTIONAL CASE-SENSITIVE human readable 'text' string info" describing this set of Client Print Support Files. The natural language for this value MUST be the natural language indicated by the Printer's "natural-language-configured" attribute. To avoid exceeding the maximum limit imposed on IPP attributes and to increase interoperability with other systems, the length of this field value MUST not exceed 127 characters. == Unrecognized Status in '[Target category: standards track]', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (April 5, 2001) is 8415 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: 'RFC2119' is mentioned on line 173, but not defined ** Obsolete normative reference: RFC 1991 (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) ** 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 2910 (Obsoleted by RFC 8010) ** Obsolete normative reference: RFC 2911 (Obsoleted by RFC 8011) Summary: 17 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 3 4 [Target category: standards track] Hugo Parra 5 Novell, Inc. 6 Ted Tronson 7 Novell, Inc. 8 Tom Hastings 9 Xerox Corp. 10 April 5, 2001 11 Internet Printing Protocol (IPP): 12 Printer Installation Extension 14 Copyright (C) The Internet Society (2001). All Rights Reserved. 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of [RFC2026]. Internet-Drafts are 20 working documents of the Internet Engineering Task Force (IETF), its 21 areas, and its working groups. Note that other groups may also 22 distribute working 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 27 material 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 describes an extension to the Internet Printing 38 Protocol/1.0 (IPP) [RFC2566, RFC2565] and IPP/1.1 [RFC2911, RFC2910]. 39 Various client platforms require that some setting up take place at 40 the workstation before the client can properly submit jobs to a 41 specific printer. This setup process is sometimes referred to as 42 printer installation. Most clients need some information about the 43 printer being installed as well as support files to complete the 44 printer installation. The nature of these "Client Print Support 45 Files" varies depending on the specific client platform, from simple 46 configuration files to highly sophisticated printer drivers. The 47 selection and installation process can be simplified and even 48 automated if the workstation can learn some key information about the 49 printer and which sets of Client Print Support Files are available. 50 Such key information includes: operating system type, CPU type, 51 document-format (PDL), natural language, compression mechanism, file 52 type, client file name, policy for automatic loading, file size, file 53 version, file date and time, file information description, and 54 digital signature. 56 Table of Contents 58 1 Introduction....................................................5 60 2 Terminology.....................................................5 62 3 Model Extensions................................................6 64 3.1 client-print-support-files-supported (1setOf octetString(MAX)) 66 ..........................................................6 67 3.1.1 Use of Keyword Values in fields.............................11 69 3.1.2 Use of the Special Keyword Value: 'unknown'.................11 71 3.1.3 Examples of "client-print-support-files-supported" attribute 73 values.................................................11 75 3.2 Get-Printer-Attributes Operation Extension..................12 77 3.2.1 Get-Printer-Attributes Request..............................12 79 3.2.1.1 client-print-support-files-filter (octetString(MAX)) 81 operation attribute..................................12 83 3.2.1.1.1 Filter matching rules.................................14 85 3.2.2 Get-Printer-Attributes Response.............................15 87 3.3 Get-Client-Print-Support-Files..............................16 89 3.3.1 Get-Client-Print-Support-Files Request......................16 91 3.3.2 Get-Client-Print-Support-Files Response.....................17 93 4 Conformance....................................................18 95 4.1 Printer Conformane Requirements.............................18 97 4.2 Client Conformance Requirements.............................18 98 5 Encoding of the Operation Layer................................19 100 6 Encoding of Transport Layer....................................19 102 7 IANA Considerations............................................19 104 7.1 Attribute Registrations.....................................20 106 7.2 Operation Registrations.....................................21 108 8 Internationalization Considerations............................21 110 9 Security Considerations........................................21 112 10 References.....................................................22 114 11 Author's Addresses.............................................24 116 12 Description of the Base IPP Documents..........................24 118 13 Full Copyright Statement.......................................25 120 Tables 122 Table 1 - "client-print-support-files-supported" attribute fields..8 124 Table 2 - "client-print-support-files-filter" attribute fields....13 126 Table 3 - REQUIRED "client-print-support-files-filter" fields.....13 128 1 Introduction 130 A common configuration for printing from a workstation requires that 131 some Client Print Support Files (e.g., PPD, printer driver files) 132 specific to the target printer be installed on that workstation. 133 Selection and configuration of the appropriate Client Print Support 134 Files can be simplified and even automated if the workstation can 135 obtain some key information about the printer and which sets of 136 Client Print Support Files are available. Such key information 137 includes: operating system type, CPU type, document-format (PDL), 138 natural language, compression mechanism, file type, client file name, 139 policy for automatic loading, file size, file version, file date and 140 time, file information description, and digital signature. The IPP 141 extension defined in this document provides a simple and reliable 142 vehicle for printers to convey this information to interested 143 workstations. This extension enables a flexible solution for 144 installing Client Print Support Files on workstations running 145 different operating systems and for printers of all makes and models. 146 It allows Client Print Support Files to be downloaded from 147 repositories of different sorts. A possible repository for the files 148 is the printer itself. The extensions necessary for getting Client 149 Print Support Files from the printer are included in this document, 150 including security for downloading executable code and data. 152 2 Terminology 154 Client Print Support Files - a set of files, such as a printer 155 driver, font metric file, printer configuration file (PPD, GPD, etc.) 156 that support a client printing to a particular Printer. A Printer 157 MAY have multiple sets of Client Print Support Files that work for 158 different operating systems, document formats, natural languages, 159 CPUs, etc. 161 This document uses terms such as "attributes", "keywords", and 162 "support". These terms have special meaning and are defined in the 163 model terminology [RFC2911] section 12.2. This document also uses 164 the terms "IPP Printer", "Printer" and "Printer object" 165 interchangeably as in [RFC2911] to mean the software entity that 166 accepts IPP operation requests and returns IPP operation responses 167 (see [RFC2911] section 2). 169 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD 170 NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to 171 conformance. These terms are defined in [RFC2911] section 12.1 on 172 conformance terminology, most of which is taken from RFC 2119 173 [RFC2119]. 175 This section defines the following additional terms that are used 176 throughout this document: 178 REQUIRED: if an implementation supports the extensions described 179 in this document, it MUST support a REQUIRED feature. 180 OPTIONAL: if an implementation supports the extensions described 181 in this document, it MAY support an OPTIONAL feature. 183 3 Model Extensions 185 To assist workstations in the printer installation process, an IPP 186 printer needs to provide the workstation with information about the 187 Client Print Support Files, such as the their name and location/s. 188 This information needs to match the workstation's specific 189 environment, such as its operating system, preferred natural 190 language, and preferred document format. 192 The following extensions to the IPP model enable assisted or 193 automated printer installation. This section describes each 194 extension in detail. 196 - A new REQUIRED Printer Description attribute: "client-print- 197 support-files-supported" (1setOf octetString(MAX)). 198 - A new REQUIRED Get-Printer-Attributes operation attribute: 199 "client-print-support-files-filter" (octetString(MAX)). 200 - A new RECOMMENDED printer operation: Get-Client-Print-Support- 201 Files. 203 3.1 client-print-support-files-supported (1setOf octetString(MAX)) 205 An IPP Printer uses the REQUIRED Printer Description attribute 206 "client-print-support-files-supported" to represent relevant 207 information about all of the Client Print Support Files it supports. 208 Each value is a composite UTF-8 string with well-defined fields (see 209 Table 1). Each value string MUST be formatted as follows: 211 "uri=val1< field-name2=val21,...,val2p< ... < field- 212 namen=valn1,...,valnq<" 214 The first field MUST be the "uri" field. The remaining fields MAY be 215 in any order. 217 The string MUST NOT include any control characters (hex 00 to 1F), 218 even the so-called white space control characters (TAB, CR, and LF) 219 anywhere. Only zero or more UTF-8 SPACE characters (hex 20) can be 220 included and they can be included only IMMEDIATELY AFTER the 221 delimiter character: "<", but NOT anywhere else, including after "=" 222 and ",". However, if the UTF-8 SPACE character is needed in a 223 client-file-name value, then each occurrence is included directly, 224 without escaping (see example). On the other hand, if the UTF-8 225 SPACE character is needed in a URL value, then each occurrence is 226 escaped as: "%20" (URI conventions - see [RFC2396]). 228 Table 1 lists the REQUIRED fields that a Printer MUST support and the 229 OPTIONAL fields that a Printer MAY support in the "client-print- 230 support-files-supported" (1setOf octetString(MAX)) Printer 231 Description attribute. A Printer implementation MAY support 232 additional fields using the same syntax. Values are defined to be 233 either CASE-SENSITIVE or ALL-LOWER-CASE according to the definitions 234 for the attribute syntaxes from [RFC2911] (set off by single quotes 235 in the table). The CASE-SENSITIVE values MAY have upper and lower 236 case letters as for the corresponding attribute syntaxes in 237 [RFC2911]. The LOWER-CASE values MUST have all lower case alphabetic 238 letters. Additional characters, such as digits, hyphen-minus (-), 239 period (.), and slash (/) are according to the corresponding 240 attribute syntaxes in [RFC2911]. Additional values for these fields 241 can be registered with IANA according to the procedures in [RFC2911] 242 for registering additional values of attributes. Additional fields 243 can be registered with IANA according to the procedures defined in 244 [RFC2911] for registering attributes. See section 7. 246 Clients SHOULD ignore fields they don't recognize in a given value. 247 This allows for future extensions to the format of the string without 248 breaking compatibility with earlier clients. 250 Table 1 - "client-print-support-files-supported" attribute fields 252 Field Field value 253 name 255 "uri" One REQUIRED CASE-SENSITIVE 'uri' string identifying the 256 uri where to obtain the support files for each OS 257 platform, document format, and natural language the 258 printer supports. This MUST be the first field in each 259 value. Examples of uri schemes that MAY be found here 260 are 'ftp', 'http', and 'ipp'. The 'ftp' and 'http' 261 schemed URIs identify the archive file that contains all 262 the necessary client support files. 264 The 'ipp' schemed URIs identify the archive file that 265 clients MAY obtain from the Printer using the Get- 266 Client-Print-Support-Files operation (see section 3.3). 267 The URI MUST be a valid URI to the same Printer object, 268 i.e., one of the values of the Printer's "printer-uri- 269 supported" attribute. The 'ipp' URI is used to 270 distinguish between multiple Client Print Support Files 271 in an implementation dependent manner using the URL 272 query syntax (e.g., "?drv-id=xxx") [RFC2396]. The 273 query part MUST NOT exceed 127 octets, not counting the 274 "?" character that begins the query part. A Printer 275 SHOULD support the 'ipp' scheme. 277 "os-type" One or more REQUIRED comma-separated LOWER-CASE 278 'keyword' strings identifying the operating system types 279 supported by this set of Client Print Support Files. 280 Valid values are the operating system names defined in 281 the IANA document [os-names] and the special keyword 282 value: 'unknown'. Although the IANA registry requires 283 that the names be all upper-case, the values MUST be all 284 lower case in this field (plus hyphen-minus (-), period 285 (.), and slash (/)). Examples: 'linux', 'linux-2.2', 286 'os/2', 'sun-os-4.0', 'unix', 'unix-bsd', 'win32', 287 'windows-95', 'windows-98', 'windows-ce', 'windows-nt', 288 'windows-nt-4', 'windows-nt-5', 'unknown'. 290 "cpu- One or more REQUIRED comma-separated LOWER-CASE 291 type" 'keyword' strings identifying the CPU types supported by 292 this set of Client Print Support Files. The values 293 indicate the CPU family independent of the CPU 294 manufacturer. Standard keyword values are: 'x86-16', 295 'x86-32', 'x86-64', 'dec-vax', 'alpha', 'power-pc', 'm- 296 68000, 'sparc', 'itantium', 'mips', 'arm' and will be 298 Field Field value 299 name 301 used as the initial value for the "cpu-type" IANA 302 registry. In addition, the special keyword value: 303 'unknown' is valid. 305 "document One or more REQUIRED comma-separated CASE-SENSITIVE 306 -format" 'mimeMediaType' strings identifying the document formats 307 supported by this set of Client Print Support Files. 308 Valid values are the string representation of the IPP 309 mimeMediaType attribute syntax (see [RFC2911] section 310 4.1.9), for example 'application/postscript'. In 311 addition, the special keyword value: 'unknown' is valid. 313 "natural- One or more REQUIRED comma-separated LOWER-CASE 314 language" 'naturalLanguage' strings identifying the natural 315 language used by this set of Client Print Support Files. 316 Valid values are the string representation of the IPP 317 'naturalLanguage' attribute syntax (see [RFC2911] 318 section 4.1.8), for example 'en' and 'en-us'. In 319 addition, the special keyword value: 'unknown' is valid. 321 "compress One REQUIRED LOWER-CASE 'keyword' string identifying the 322 ion" mechanism used to compress this set of Client Print 323 Support Files. All files needed for the installation of 324 a printer driver MUST be compressed into a single file. 325 Valid keyword values are the keywords defined by 326 [RFC2911] or registered with IANA for use in the IPP 327 "compression" and "compression-supported" attributes. 328 See [RFC2911] section 4.4.32), for example 'gzip'. The 329 'none' value limits the uncompressed Client Print 330 Support File to a single file. The values for the 331 "compression" field that a Printer supports NEED NOT be 332 the same values that the Printer is configured to 333 support in Job Creation operations as indicated in the 334 Printer's "compressions-supported" attribute. 336 "file- One or more REQUIRED comma-separated LOWER-CASE 337 type" 'keyword' strings identifying the type of the Client 338 Print Support Files. Standard keyword values are: 339 'printer-driver', 'ppd', 'updf', 'gpd'. 341 "client- One REQUIRED CASE-SENSITIVE string identifying the name 342 file- by which the Client Print Support Files will be 343 name" installed on the workstation. For Client Print Support 344 Files of type 'printer-driver', this is also the name 346 Field Field value 347 name 349 that identifies this printer driver in an .inf file. 351 "policy" One OPTIONAL LOWER-CASE 'keyword' string indicating the 352 policy for automatic loading. Standard keyword values 353 are: 'manufacturer-recommended', 'administrator- 354 recommended', 'manufacturer-experimental, 355 'administrator-experimental'. The experimental values 356 are for beta test. 358 "file- One OPTIONAL file size in octets represented as ASCII 359 size" decimal digits. 361 "file- One OPTIONAL LOWER-CASE version number. Recommended to 362 version" be of the form "Major.minor[.revision]" where "Major" is 363 the major version number, "minor" is the minor version 364 number and "revision" is an optional revision number. 366 "file- One OPTIONAL File CASE-SENSITIVE creation date and time 367 date- according to ISO 8601 where all fields are fixed length 368 time" with leading zeroes (see [RFC2518] Appendix 2). 369 Examples: 2000-01-01T23:09:05Z and 2000-01-01T02:59:59- 370 04.00 372 "file- One OPTIONAL CASE-SENSITIVE human readable 'text' string 373 info" describing this set of Client Print Support Files. The 374 natural language for this value MUST be the natural 375 language indicated by the Printer's "natural-language- 376 configured" attribute. To avoid exceeding the maximum 377 limit imposed on IPP attributes and to increase 378 interoperability with other systems, the length of this 379 field value MUST not exceed 127 characters. 381 "digital- One REQUIRED LOWER-CASE 'keyword' string identifying the 382 signature mechanism used to ensure the integrity and authenticity 383 " of this set of Client Print Support Files. Standard 384 values are: 'smime', 'pgp', 'dss', and 'xmldsig' which 385 are defined in [RFC2634], [RFC1991], [dss], and 386 [xmldsig], respectively. In addition, the special 387 keyword value: 'none' is valid. 389 Each value MUST refer to one and only one set of Client Print Support 390 Files, even if the files are downloadable from various repositories 391 (i.e., even if they are associated with multiple URIs). 393 3.1.1 Use of Keyword Values in fields 395 A number of the fields in Table 1 use keyword strings as values. The 396 syntax of these keywords is the same as in [RFC2911], including the 397 use of private keywords. See [RFC2911] sections 4.1.3 and 6.1. 398 Printer implementers are strongly RECOMMENDED to submit additional 399 keyword values for registration with IANA according to the procedures 400 for registering attributes. See section 7 and [RFC2911] section 6.1. 402 3.1.2 Use of the Special Keyword Value: 'unknown' 404 A number of REQUIRED 'keyword' value fields have a special keyword 405 value: 'unknown' defined. This value is intended for use when the 406 actual value is not known, such as by an administrator automatic 407 software configuring the IPP Printer object. However, it is strongly 408 RECOMMENDED that other more meaningful values be used, instead of the 409 'unknown' value whenever possible. 411 3.1.3 Examples of "client-print-support-files-supported" attribute 412 values 414 The following illustrates what two valid values of the "client-print- 415 support-files-supported" (1setOf octetString(MAX)) Printer 416 Description attribute might look like: 418 uri=ipp://mycompany.com/myprinter?drv-id=ModelY.gz< 419 os-type=windows-95< cpu-type=x86-32< 420 document-format=application/postscript< 421 natural-language=en< compression=gzip< 422 file-type=printer-driver< 423 client-file-name=CompanyX-ModelY-driver.gz< 424 policy=manufacturer-recommended< 426 uri=ftp://mycompany.com/root/drivers/win95/CompanyX/ModelY.gz< 427 os-type=windows-95< cpu-type=x86-32< 428 document-format=application/postscript,application/vnd.hp-PCL< 429 natural-language=en,fr< compression=gzip< 430 file-type=printer-driver< 431 client-file-name=Company T Model Z driver.gz< 432 policy=manufacturer-recommended< 434 The above examples have been broken onto separate lines for 435 readability in this document. However, there MUST NOT be any line 436 breaks in the actual values. 438 The "client-print-support-files-supported" Printer Description 439 attribute MAY be preset at manufacturing time or through 440 administrative means outside the scope of this document. 442 3.2 Get-Printer-Attributes Operation Extension 444 The "client-print-support-files-supported" Printer Description 445 attribute defined in section 3.1 contains information, such as 446 operating system, natural language, and document format, about all of 447 the sets of Client Print Support Files. This section defines an 448 extension to the Get-Printer-Attributes operation that allows a 449 workstation to filter out all but the Client Print Support Files of 450 interest. 452 3.2.1 Get-Printer-Attributes Request 454 A Printer MAY contain information about multiple sets of Client Print 455 Support Files to match the different operating systems, natural 456 languages and document formats it supports. A workstation MAY query 457 this information by including the 'client-print-support-files- 458 supported' keyword as a value of the "requested-attributes" operation 459 attribute of the Get-Printer-Attributes operation. 461 3.2.1.1 client-print-support-files-filter (octetString(MAX)) operation 462 attribute 464 The client can request a subset of the values of the "client-print- 465 support-files-supported" Printer attribute by supplying the "client- 466 print-support-files-filter" (octetString(MAX)) operation attribute in 467 the request as a filter. The filter value indicates in which Client 468 Print Support Files the client is interested. The client MAY supply 469 this attribute. The Printer MUST support this attribute. 471 The filter value of the "client-print-support-files-filter" attribute 472 is a composite string with the same format as that of "client-print- 473 support-files-supported" (see Table 1 - "client-print-support-files- 474 supported" attribute fields in section 3.1) with the following 475 exceptions: 477 Table 2 - "client-print-support-files-filter" attribute fields 479 Field Field Value in the "client-print-support-files-filter" 480 Name attribute 482 uri- One or more comma-separated LOWER-CASE 'uriScheme' 483 scheme string values identifying the uri scheme to be 484 filtered on. Valid values are the string 485 representation of the IPP 'uriScheme' attribute syntax 486 (see [RFC2911] section 4.1.6). Example URI schemes 487 are: 'ftp', 'http', and 'ipp'. The Printer SHOULD 488 support the 'ipp' scheme. If supplied by the client, 489 this field NEED NOT be first. If this field is 490 omitted by the client, the Printer returns all 491 schemes. 493 xxx One or more comma-separated values for any of the 494 fields defined in Table 1, with the single exception 495 of the "uri" field which a client MUST NOT supply and 496 a Printer MUST NOT support. 497 The Printer MUST support any filter field having more 498 than one value separated by a COMMA (,), including the 499 fields that Table 1 indicates MUST BE single valued. 501 Printer implementations MUST support the "client-print-support-files- 502 filter" operation attribute in a Get-Printer-Attributes request with 503 the member fields listed Table 3. Printers MAY support any 504 additional filter fields listed in Table 2. 506 Client implementations MAY supply any filter fields listed in Table 2 507 in the "client-print-support-files-filter" operation attribute of a 508 Get-Printer-Attributes request. 510 Table 3 - REQUIRED "client-print-support-files-filter" fields 512 uri-scheme 514 os-type 516 cpu-type 518 document-format 520 natural-language 522 3.2.1.1.1 Filter matching rules 524 The Printer returns only the values of the "client-print-support- 525 files-supported" Printer Description attribute that match the filter 526 in the "client-print-support-files-filter" operation attribute. The 527 following filter matching rules are defined: 529 1. A match occurs if at least one value of each field supplied by 530 the client in the filter matches a Client Print Support File 531 value. Printers MUST ignore a filter field supplied by a client 532 that the Printer does not support and return a match if all 533 supported fields do match, no matter what value the client 534 supplied for that unsupported field. Similarly, Printers MUST 535 ignore a filter field supplied by a client that the Printer does 536 support, but which the field has not been populated for a Client 537 Print Support Files and return a match if all supported and 538 populated fields do match, no matter what value the client 539 supplied for that unpopulated field. 541 2. A match for a CASE-INSENSITIVE field occurs independent of the 542 case of the letters supplied by the client and those stored by 543 the Printer, while a match for a LOWER-CASE field is a strict 544 character for character match. 546 3. A match for a 'keyword' Printer field that is populated with the 547 'unknown' special keyword value occurs for any value supplied by 548 the client for that field. 550 4. If the "client-print-support-files-filter" operation attribute 551 filter is not supplied by the client, the printer SHOULD behave 552 as if the attribute had been provided with all fields left empty 553 (i.e., return an unfiltered list). 555 The following are two examples of a "client-print-support-files- 556 filter" filter value: 558 os-type=windows-95< cpu-type=x86-32< 559 document-format=application-postscript< natural-language=en,de< 561 uri-scheme=ipp< os-type=windows-95< cpu-type=x86-32< 562 document-format=application-postscript< natural-language=en,de< 564 See section 3.2.2 for example matching responses. 566 It is RECOMMENDED that workstations first use the Get-Printer- 567 Attributes operation in combination with "client-print-support-files- 568 filter" operation attribute filter to get a list of the potential 569 Client Print Support Files that meet the workstation's requirements. 570 The workstation can then choose from the returned list which Client 571 Print Support Files to use and where to get them. If one of the URIs 572 returned is an IPP uri, the workstation can retrieve the Client Print 573 Support Files from an IPP printer via the Get-Client-Print-Support- 574 Files operation (see section 3.3). 576 3.2.2 Get-Printer-Attributes Response 578 A Printer MUST return the "client-print-support-files-supported" 579 (1setOf octetString(MAX)) attribute in the Printer Object Attributes 580 group (group 3) when requested by a client. Each returned attribute 581 value MUST satisfy the criteria specified by the client in the 582 request. 584 For example, if the request contains the following "client-print- 585 support-files-filter" filter: 587 os-type=windows-95< cpu-type=x86-32< 588 document-format=application-postscript< 589 natural-language=en,de< 591 A conforming response is the following two octet String values: 593 uri=ipp://mycompany.com/myprinter?drv-id=ModelY.gz< 594 os-type=windows-95< cpu-type=x86-32< 595 document-format=application/postscript< 596 natural-language=en< compression=gzip< 597 file-type=printer-driver< 598 client-file-name=CompanyX-ModelY-driver.gz< 599 policy=manufacturer-recommended< 600 digital-signature=smime< 602 uri=ftp://mycompany.com/root/drivers/win95/CompanyX/ModelY.gz< 603 os-type=windows-95< cpu-type=x86-32< 604 document-format=application/postscript,application/vnd.hp-PCL< 605 natural-language=en,fr< compression=gzip< 606 file-type=printer-driver< 607 client-file-name=CompanyX-ModelY-driver.gz< 608 policy=manufacturer-recommended< 609 digital-signature=smime< 611 These examples have been broken onto separate lines for readability 612 in this document. However, there MUST NOT be any line breaks in the 613 actual values. 615 As another example, if the above request had also contained the "uri- 616 scheme" field in the following "client-print-support-files-filter" 617 filter: 619 uri-scheme=ipp< os-type=windows-95< cpu-type=x86-32< 620 document-format=application-postscript< 621 natural-language=en,de< 623 Then only the first value would have been returned as a single 624 octetString value: 626 uri=ipp://mycompany.com/myprinter?drv-id=ModelY.gz< 627 os-type=windows-95< cpu-type=x86-32< 628 document-format=application/postscript< 629 natural-language=en< compression=gzip< 630 file-type=printer-driver< 631 client-file-name=CompanyX-ModelY-driver.gz< 632 policy=manufacturer-recommended< 633 digital-signature=smime< 635 3.3 Get-Client-Print-Support-Files 637 This RECOMMENDED operation allows a client to download Client Print 638 Support Files from an IPP Printer. 640 3.3.1 Get-Client-Print-Support-Files Request 642 The following sets of attributes are part of the Get-Client-Print- 643 Support-Files request: 645 Group 1: Operation Attributes 647 Natural Language and Character Set: 648 The "attributes-charset" and "attributes-natural-language" 649 attributes as described in [RFC2911], section 3.1.4.1. 651 Target: 652 The "printer-uri" (uri) operation attribute which is the target 653 for this operation as described in [RFC2911], section 3.1.5. 654 The client MUST use the URI value as the target of this 655 operation that the Printer returns in the "uri" field (see Table 656 1) in the Get-Printer-Attributes response. Furthermore, the 657 client MUST use the appropriate authorization and security 658 mechanism for this URI as indicated by the Printer's "printer- 659 uri-supported", "uri-authentication-supported" and "uri- 660 security-supported" attributes (see [RFC2911] sections 4.4.1, 661 4.4.2, and 4.4.3). Only if the URI returned in the "uri" field 662 matches the URI that the client used for the Get-Printer- 663 Attributes request MAY the client use the same HTTP connection. 664 The 'ipp' URL matching rules are defined in [ipp-url] and do not 665 include the query part. 667 Requesting User Name: 668 The "requesting-user-name" (name(MAX)) attribute SHOULD be 669 supplied by the client as described in [RFC2911], section 8.3. 671 "client-print-support-files-query" (text(127)): 672 The client MUST supply this attribute specifying the query part 673 [RFC2396] of the ipp uri for the desired Client Print Support 674 Files not including the "?" character that starts the query 675 part, i.e., the value of the "uri" field following the "?" 676 character returned by the Get-Printer-Attributes in one of the 677 values of the "client-print-support-files-supported" (1setOf 678 octetString(MAX)) Printer attribute (see Table 1) that had an 679 'ipp' scheme. 681 3.3.2 Get-Client-Print-Support-Files Response 683 The Printer object returns the following sets of attributes as part 684 of the Get-Client-Print-Support-Files Response: 686 Group 1: Operation Attributes 688 Status Message: 689 In addition to the REQUIRED status code returned in every 690 response, the response OPTIONALLY includes a "status-message" 691 (text(255)) operation attribute as described in [RFC2911], 692 sections 13 and 3.1.6. 694 Natural Language and Character Set: 695 The "attributes-charset" and "attributes-natural-language" 696 attributes as described in [RFC2911], section 3.1.4.2. 698 Group 2: Unsupported Attributes 699 See [RFC2911], section 3.1.7 for details on returning Unsupported 700 Attributes. 702 Group 3: Printer Object Attributes 703 "client-print-support-files-supported" (octetString(MAX)). 704 This attribute identifies the properties of the returned Client 705 Print Support Files. The Printer object MUST return this 706 attribute if the response includes Group 4 (i.e., if a set of 707 Client Print Support Files identified by the supplied "client- 708 print-support-files-query" operation attribute was found). The 709 Printer MUST return all configured fields for the selected 710 Client Print Support Files in the format shown in section 3.1. 712 Group 4: Client Print Support Files 713 The printer MUST supply the Client Print Support Files that match 714 the client's criteria following the "end-of-attributes" tag. All 715 necessary files MUST be compressed into a single transferred file. 717 4 Conformance 719 4.1 Printer Conformane Requirements 721 A Printer conforming to this specification: 723 1.MUST support the "client-print-support-files-supported" Printer 724 Description attribute as defined in section 3.1, including all 725 of the REQUIRED fields defined in Table 1 and MAY support the 726 OPTIONAL fields defined in Table 1. 728 2.MUST support the "client-print-support-files-filter" operation 729 attribute in the Get-Printer-Attributes request as defined in 730 section 3.2, including all of the fields listed in Table 3 and 731 ignoring any fields not recognized. 733 3.MUST support at least one of the following URI schemes that 734 identify the support files: 'ftp', 'http', or 'ipp', of which 735 the 'ipp' scheme is the RECOMMENDED one. 737 4.SHOULD support the Get-Client-Print-Support-Files operation as 738 described in section 3.3. If this operation is supported, then 739 one of the supported schemes MUST be 'ipp'. 741 5.SHOULD support TLS as described in section 9. 743 6.SHOULD support at least one method for the downloading of Client 744 Print Support Files that have been digitally signed as described 745 in section 9. 747 4.2 Client Conformance Requirements 749 A client conforming to this specification: 751 1.MUST ignore any fields returned by the Printer in the "client- 752 print-support-files-supported" Printer Description attribute 753 that the client does not recognize or support. 755 2.SHOULD be able to retrieve Client Print Support Files by either 756 FTP Get or HTTP Get operations. 758 3.MUST be able to retrieve Client Print Support Files using the 759 Get-Client-Print-Support-Files operation, i.e., support the 760 'ipp' scheme. 762 4.MUST supply the proper URI value for the "printer-uri" operation 763 attribute as specified in section 3.3.1 under Target:. 765 5.MUST validate that files that are supposed to be digitally 766 signed are done with the indicated mechanism as described in 767 section 9. 769 6.SHOULD support TLS as described in section 9. 771 5 Encoding of the Operation Layer 773 This extension uses the operation layer encoding described in 774 [RFC2910]. 776 6 Encoding of Transport Layer 778 This specification uses the transport layer encoding described in 779 [RFC2910] with the following extensions. 781 New Error codes: 783 0x0417 client-error-client-print-support-file-not-found 785 New Operation code 787 0x0021 Get-Client-Print-Support-Files 789 7 IANA Considerations 791 The IANA-registered operating system names that IANA has registered 792 [os-names] are required by this spec for use in the "os-type" field 793 (see Table 1). 795 Table 1 of this document defines possible 'keyword' values for the 796 "cpu-type" field. However, the existing IANA machine registration 797 [cpu-names] is inadequate for two reasons: a) it is really a machine 798 model number, not a CPU type, and b) it doesn't express whether a 799 CPU is 16-bit, 32-bit, or 64-bit which needs to be indicated in the 800 keyword value. Therefore, the "os-type" field will be a new 801 registration with initial values assigned. 803 Implementers may register additional values for the fields defined in 804 Table 1 with IANA according to the procedures in [RFC2911] for 805 registering additional values of attributes. Implementers may 806 register additional fields with IANA according to the procedures 807 defined in [RFC2911] for registering attributes. 809 The rest of this section contains the exact information for IANA to 810 add to the IPP Registries according to the procedures defined in RFC 811 2911 [RFC2911] section 6. 813 Note to RFC Editors: Replace RFC NNNN below with the RFC number 814 for this document, so that it accurately reflects the content of 815 the information for the IANA Registry. 817 7.1 Attribute Registrations 819 The attributes and fields defined in this document will be published 820 by IANA according to the procedures in RFC 2911 [RFC2911] section 6.2 821 with the following path: 823 ftp.isi.edu/iana/assignments/ipp/attributes/ 825 The registry entry will contain the following information: 827 Printer Description Attributes: Ref: Section: 828 client-print-support-files-supported (1setOf octetString(MAX)) 829 RFC NNNN 3.1 831 For purposes of IANA attribute registration, the following fields of 832 the "client-print-support-files-supported" and the "client-print- 833 support-files-filter" attributes are registered following the 834 procedures for IPP attribute registration: 835 Ref: Section: 836 uri (uri) RFC NNNN 3.1 837 os-type (type2 keyword) RFC NNNN 3.1 838 cpu-type (type2 keyword) RFC NNNN 3.1 839 document-format (mimeMediaType) RFC NNNN 3.1 840 natural-language (naturalLanguage) RFC NNNN 3.1 841 compression (type2 keyword) RFC NNNN 3.1 842 file-type (type2 keyword) RFC NNNN 3.1 843 client-file-name (name(MAX)) RFC NNNN 3.1 844 policy (type2 keyword) RFC NNNN 3.1 845 file-size (integer(0:MAX)) RFC NNNN 3.1 846 file-version (name(MAX)) RFC NNNN 3.1 847 file-date-time (text(25)) RFC NNNN 3.1 848 file-info (text(127)) RFC NNNN 3.1 849 digital-signature (type2 keyword) RFC NNNN 3.1 851 uri-scheme (uriScheme) RFC NNNN 3.2 852 Operation Attributes: Ref: Section: 853 client-print-support-files-filter (octetString(MAX))RFC NNNN 3.2 855 7.2 Operation Registrations 857 The operations defined in this document will be published by IANA 858 according to the procedures in RFC 2911 [RFC2911] section 6.4 with 859 the following path: 861 ftp.isi.edu/iana/assignments/ipp/operations/ 863 The registry entry will contain the following information: 865 Operations: Ref. Section: 866 Get-Client-Print-Support-Files RFC NNNN 3.3 868 8 Internationalization Considerations 870 All text representations introduced by this specification adhere to 871 the internationalization-friendly representation supported by IPP. 872 This work is also accommodates the use of Client Print Support Files 873 of different languages. 875 9 Security Considerations 877 The IPP Model and Semantics document [RFC2911] discusses high-level 878 security requirements (Client Authentication, Server Authentication 879 and Operation Privacy). Client Authentication is the mechanism by 880 which the client proves its identity to the server in a secure 881 manner. Server Authentication is the mechanism by which the server 882 proves its identity to the client in a secure manner. Operation 883 Privacy is defined as a mechanism for protecting operations from 884 eavesdropping. 886 Only operators of a printer SHOULD be allowed to set the "client- 887 print-support-files-supported" attribute and only users of the 888 printer SHOULD be allowed to query that information. 890 The IPP extension described in this document introduces the potential 891 for a security threat previously not encountered by IPP. As Client 892 Print Support Files might exist in the form of executable objects (as 893 is the case with printer drivers, for example), additional provisions 894 are needed to prevent the distribution of malicious code through this 895 mechanism. Digital signatures provide the message level security 896 commonly used to help consumers of network resources verify the 897 authenticity and integrity of those resources. Specifically, digital 898 signatures help defend against security threats such as message 899 insertion, message deletion, and message modification, and their 900 combined use into man-in-the-middle attacks. 902 This document identifies some commonly used signing mechanisms (SMIME 903 [RFC2634], PGP [RFC1991], DSS [dss], and XML Digital Signatures 904 [xmldsig]), though any others MAY be used. Of course, it is assumed 905 that once end-users know the identity of the provider of Client Print 906 Support Files, they can make the correct determination as to whether 907 it is safe to use those files. 909 Printers that support the Get-Client-Print-Support-Files operation 910 SHOULD support the downloading of Client Print Support Files that 911 have been digitally signed. Clients that invoke the Get-Client- 912 Print-Support-Files operation MUST make sure that Client Print 913 Support Files that are supposed to be signed (i.e., whose client- 914 print-support-files-supported attribute value includes the "digital- 915 signature" field) are indeed signed via the specified mechanism when 916 downloaded from the printer. 918 Furthermore, printers that support the Get-Client-Print-Support-Files 919 operation SHOULD implement TLS to provide application level channel 920 security and enable users to reliably authenticate the source of the 921 Client Print Support Files. 923 10 References 925 [cpu-names] 926 IANA Registry of CPU Names at ftp://ftp.isi.edu/in- 927 notes/iana/assignments/XXX. 929 [dss] 930 U.S. Department of Commerce, "Digital Signature Standard (DDS)", 931 Federal Information Processing Standards Publication 186-1 (FIPS 932 PUB 186-1), December 15, 1998. 934 [ipp-url] 935 Herriot, R., McDonald, I., "Internet Printing Protocol (IPP): IPP 936 URL Scheme." , February 14, 937 2001. 939 [os-names] 940 IANA Registry of Operating System Names at ftp://ftp.isi.edu/in- 941 notes/iana/assignments/operating-system-names. 943 [RFC1991] 944 D. Atkins, W. Stallings, P. Zimmermann, "PGP Message Exchange 945 Formats", RFC 1991, August, 1996. 947 [RFC2026] 948 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 949 2026, October 1996. 951 [RFC2396] 952 Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource 953 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 955 [RFC2518] 956 Goland, Y., et al, "HTTP Extensions for Distributed Authoring -- 957 WEBDAV", RFC 2518, February 1999. 959 [RFC2565] 960 Herriot, R., Butler, S., Moore, P., and R. Turner, "Internet 961 Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 962 1999. 964 [RFC2566] 965 R. deBry, T. Hastings, R. Herriot, S. Isaacson, and P. Powell, 966 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, 967 April 1999. 969 [RFC2567] 970 Wright, D., "Design Goals for an Internet Printing Protocol", RFC 971 2567, April 1999. 973 [RFC2568] 974 Zilles, S., "Rationale for the Structure and Model and Protocol for 975 the Internet Printing Protocol", RFC 2568, April 1999. 977 [RFC2569] 978 Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between 979 LPD and IPP Protocols", RFC 2569, April 1999. 981 [RFC2616] 982 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 983 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 984 RFC 2616, June 1999. 986 [RFC2634] 987 P. Hoffman, "Enhanced Security Services for S/MIME", RFC 2634, June 988 1999. 990 [RFC2910] 991 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 992 Protocol/1.1: Encoding and Transport", RFC 2910, September 2000. 994 [RFC2911] 995 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 996 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2911, 997 September 2000. 999 [xmldsig] 1000 D. Eastlake, J. Reagle, D. Solo "XML-Signature Syntax and 1001 Processing", , October 31, 2000. 1003 11 Author's Addresses 1005 Hugo Parra 1006 Novell, Inc. 1007 1800 South Novell Place 1008 Provo, UT 84606 1010 Phone: 801-861-3307 1011 Fax: 801-861-4025 1012 e-mail: hparra@novell.com 1014 Ted Tronson 1015 Novell, Inc. 1016 1800 South Novell Place 1017 Provo, UT 84606 1019 Phone: 801-861-3338 1020 Fax: 801-861-4025 1021 e-mail: ttronson@novell.com 1023 Thomas N. Hastings 1024 Xerox Corp. 1025 737 Hawaii St. ESAE 231 1026 El Segundo, CA 90245 1028 Phone: 310-333-6413 1029 Fax: 310-333-5514 1030 e-mail: hastings@cp10.es.xerox.com 1032 12 Description of the Base IPP Documents 1034 The base set of IPP documents includes: 1036 Design Goals for an Internet Printing Protocol [RFC2567] 1037 Rationale for the Structure and Model and Protocol for the 1038 Internet Printing Protocol [RFC2568] 1039 Internet Printing Protocol/1.1: Model and Semantics [RFC2911] 1040 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] 1041 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 1042 Mapping between LPD and IPP Protocols [RFC2569] 1044 The "Design Goals for an Internet Printing Protocol" document takes a 1045 broad look at distributed printing functionality, and it enumerates 1046 real-life scenarios that help to clarify the features that need to be 1047 included in a printing protocol for the Internet. It identifies 1048 requirements for three types of users: end users, operators, and 1049 administrators. It calls out a subset of end user requirements that 1050 are satisfied in IPP/1.0 [RFC2566, RFC2565]. A few OPTIONAL operator 1051 operations have been added to IPP/1.1 [RFC2911, RFC2910]. 1053 The "Rationale for the Structure and Model and Protocol for the 1054 Internet Printing Protocol" document describes IPP from a high level 1055 view, defines a roadmap for the various documents that form the suite 1056 of IPP specification documents, and gives background and rationale 1057 for the IETF working group's major decisions. 1059 The "Internet Printing Protocol/1.1: Encoding and Transport" document 1060 is a formal mapping of the abstract operations and attributes defined 1061 in the model document onto HTTP/1.1 [RFC2616]. It defines the 1062 encoding rules for a new Internet MIME media type called 1063 "application/ipp". This document also defines the rules for 1064 transporting a message body over HTTP whose Content-Type is 1065 "application/ipp". This document defines the 'ipp' scheme for 1066 identifying IPP printers and jobs. 1068 The "Internet Printing Protocol/1.1: Implementer's Guide" document 1069 gives insight and advice to implementers of IPP clients and IPP 1070 objects. It is intended to help them understand IPP/1.1 and some of 1071 the considerations that may assist them in the design of their client 1072 and/or IPP object implementations. For example, a typical order of 1073 processing requests is given, including error checking. Motivation 1074 for some of the specification decisions is also included. 1076 The "Mapping between LPD and IPP Protocols" document gives some 1077 advice to implementers of gateways between IPP and LPD (Line Printer 1078 Daemon) implementations. 1080 13 Full Copyright Statement 1082 Copyright (C) The Internet Society (2001). All Rights Reserved. 1084 This document and translations of it may be copied and furnished to 1085 others, and derivative works that comment on or otherwise explain it 1086 or assist in its implementation may be prepared, copied, published 1087 and distributed, in whole or in part, without restriction of any 1088 kind, provided that the above copyright notice and this paragraph are 1089 included on all such copies and derivative works. However, this 1090 document itself may not be modified in any way, such as by removing 1091 the copyright notice or references to the Internet Society or other 1092 Internet organizations, except as needed for the purpose of 1093 developing Internet standards in which case the procedures for 1094 copyrights defined in the Internet Standards process must be 1095 followed, or as required to translate it into languages other than 1096 English. 1098 The limited permissions granted above are perpetual and will not be 1099 revoked by the Internet Society or its successors or assigns. 1101 This document and the information contained herein is provided on an 1102 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1103 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1104 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1105 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1106 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1108 Acknowledgement 1110 Funding for the RFC Editor function is currently provided by the 1111 Internet Society. 1113 Trade Marks 1115 Trademarks within this document are the property of their owners.