idnits 2.17.1 draft-ietf-ipp-install-02.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 ([RFC2568], [RFC2616], [RFC2569], [RFC2910], [RFC2911], [RFC2567]), 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 76: '... IPP/1.0. A few OPTIONAL operator ope...' RFC 2119 keyword, line 170: '... Table 3 - REQUIRED "client-print-su...' RFC 2119 keyword, line 201: '... MAY have multiple sets of Client Pr...' RFC 2119 keyword, line 213: '...d terms, such as MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 214: '... NOT, MAY, NEED NOT, and OPTIONAL, h...' (86 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 421 has weird spacing: '...gnature mecha...' == Line 522 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 (February 28, 2001) is 8457 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: 'RFC2567' is mentioned on line 62, but not defined == Missing Reference: 'RFC2568' is mentioned on line 64, but not defined == Missing Reference: 'RFC2569' is mentioned on line 68, but not defined == Missing Reference: 'RFC2119' is mentioned on line 217, 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 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: 12 errors (**), 0 flaws (~~), 10 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 February 28, 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 Various client platforms require that some setting up take place at 38 the workstation before the client can properly submit jobs to a 39 specific printer. This setup process is sometimes referred to as 40 printer installation. Most clients need some information about the 41 printer being installed as well as support files to complete the 42 printer installation. The nature of the support files varies 43 depending on the specific client platform, from simple configuration 44 files to highly sophisticated printer drivers. This document refers 45 to these support files as "Client Print Support Files". 46 Traditionally, the selection and installation of the correct Client 47 Print Support Files has been error prone. The selection and 48 installation process can be simplified and even automated if the 49 workstation can learn some key information about the printer and 50 which sets of Client Print Support Files are available. Such key 51 information includes: operating system type, CPU type, document- 52 format (PDL), natural language, compression mechanism, file type, 53 client file name, policy for automatic loading, file size, file 54 version, file date and time, file information description, and 55 digital signature. This document describes the IPP extensions that 56 enable workstations to obtain the information needed to perform a 57 proper printer driver installation using IPP, including security for 58 downloading executable code and data. 60 The full set of IPP documents includes: 62 Design Goals for an Internet Printing Protocol [RFC2567] 63 Rationale for the Structure and Model and Protocol for the 64 Internet Printing Protocol [RFC2568] 65 Internet Printing Protocol/1.1: Model and Semantics [RFC2911] 66 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] 67 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 68 Mapping between LPD and IPP Protocols [RFC2569] 70 The "Design Goals for an Internet Printing Protocol" document takes a 71 broad look at distributed printing functionality, and it enumerates 72 real-life scenarios that help to clarify the features that need to be 73 included in a printing protocol for the Internet. It identifies 74 requirements for three types of users: end users, operators, and 75 administrators. It calls out a subset of end user requirements that 76 are satisfied in IPP/1.0. A few OPTIONAL operator operations have 77 been added to IPP/1.1. 79 The "Rationale for the Structure and Model and Protocol for the 80 Internet Printing Protocol" document describes IPP from a high level 81 view, defines a roadmap for the various documents that form the suite 82 of IPP specification documents, and gives background and rationale 83 for the IETF working group's major decisions. 85 The "Internet Printing Protocol/1.1: Encoding and Transport" document 86 is a formal mapping of the abstract operations and attributes defined 87 in the model document onto HTTP/1.1 [RFC2616]. It defines the 88 encoding rules for a new Internet MIME media type called 89 "application/ipp". This document also defines the rules for 90 transporting a message body over HTTP whose Content-Type is 91 "application/ipp". This document defines a new scheme named 'ipp' 92 for identifying IPP printers and jobs. 94 The "Internet Printing Protocol/1.1: Implementer's Guide" document 95 gives insight and advice to implementers of IPP clients and IPP 96 objects. It is intended to help them understand IPP/1.1 and some of 97 the considerations that may assist them in the design of their client 98 and/or IPP object implementations. For example, a typical order of 99 processing requests is given, including error checking. Motivation 100 for some of the specification decisions is also included. 102 The "Mapping between LPD and IPP Protocols" document gives some 103 advice to implementers of gateways between IPP and LPD (Line Printer 104 Daemon) implementations. 106 Table of Contents 108 1 Introduction....................................................6 110 2 Terminology.....................................................6 112 3 Model Extensions................................................7 114 3.1 client-print-support-files-supported (1setOf octetString(MAX)) 116 ..........................................................7 117 3.1.1 Use of Keyword Values in fields.............................12 119 3.1.2 Use of the Special Keyword Value: 'unknown'.................12 121 3.1.3 Examples of "client-print-support-files-supported" attribute 123 values.................................................12 125 3.2 Get-Printer-Attributes Operation Extension..................13 127 3.2.1 Get-Printer-Attributes Request..............................13 129 3.2.1.1 client-print-support-files-filter (octetString(MAX)) 131 operation attribute..................................13 133 3.2.1.1.1 Filter matching rules.................................15 135 3.2.2 Get-Printer-Attributes Response.............................16 137 3.3 Get-Client-Print-Support-Files..............................17 139 3.3.1 Get-Client-Print-Support-Files Request......................17 141 3.3.2 Get-Client-Print-Support-Files Response.....................18 143 4 Conformance....................................................19 145 5 Encoding of the Operation Layer................................20 147 6 Encoding of Transport Layer....................................20 148 7 IANA Considerations............................................20 150 7.1 Attribute Registrations.....................................21 152 7.2 Operation Registrations.....................................22 154 8 Internationalization Considerations............................22 156 9 Security Considerations........................................22 158 10 References.....................................................23 160 11 Author's Addresses.............................................24 162 12 Full Copyright Statement.......................................25 164 Tables 166 Table 1 - "client-print-support-files-supported" attribute fields..9 168 Table 2 - "client-print-support-files-filter" attribute fields....14 170 Table 3 - REQUIRED "client-print-support-files-filter" fields.....14 172 1 Introduction 174 A common configuration for printing from a workstation requires that 175 some Client Print Support Files (e.g., PPD, printer driver files) 176 specific to the target printer be installed on that workstation. 177 Selection and configuration of the appropriate Client Print Support 178 Files can be simplified and even automated if the workstation can 179 obtain some key information about the printer and which sets of 180 Client Print Support Files are available. Such key information 181 includes: operating system type, CPU type, document-format (PDL), 182 natural language, compression mechanism, file type, client file name, 183 policy for automatic loading, file size, file version, file date and 184 time, file information description, and digital signature. With a 185 few extensions, IPP provides a simple and reliable vehicle for 186 printers to convey this information to interested workstations. The 187 IPP extensions described in this document enable a flexible solution 188 for installing Client Print Support Files on workstations running 189 different operating systems and for printers of all makes and models. 190 It allows Client Print Support Files to be downloaded from 191 repositories of different sorts. A possible repository for the files 192 is the printer itself. The extensions necessary for getting Client 193 Print Support Files from the printer are included in this document, 194 including security for downloading executable code and data. 196 2 Terminology 198 Client Print Support Files - a set of files, such as a printer 199 driver, font metric file, printer configuration file (PPD, GPD, etc.) 200 that support a client printing to a particular Printer. A Printer 201 MAY have multiple sets of Client Print Support Files that work for 202 different operating systems, document formats, natural languages, 203 CPUs, etc. 205 This document uses terms such as "attributes", "keywords", and 206 "support". These terms have special meaning and are defined in the 207 model terminology [RFC2911] section 12.2. This document also uses 208 the terms "IPP Printer", "Printer" and "Printer object" 209 interchangeably as in [RFC2911] to mean the software entity that 210 accepts IPP operation requests and returns IPP operation responses 211 (see [RFC2911] section 2). 213 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD 214 NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to 215 conformance. These terms are defined in [RFC2911] section 12.1 on 216 conformance terminology, most of which is taken from RFC 2119 217 [RFC2119]. 219 This section defines the following additional terms that are used 220 throughout this document: 222 REQUIRED: if an implementation supports the extensions described 223 in this document, it MUST support a REQUIRED feature. 224 OPTIONAL: if an implementation supports the extensions described 225 in this document, it MAY support an OPTIONAL feature. 227 3 Model Extensions 229 To assist workstations in the printer installation process, an IPP 230 printer needs to provide the workstation with information about the 231 Client Print Support Files, such as the their name and location/s. 232 This information needs to match the workstation's specific 233 environment, such as its operating system, preferred natural 234 language, and preferred document format. 236 The following extensions to the IPP model enable assisted or 237 automated printer installation. This section describes each 238 extension in detail. 240 - A new REQUIRED Printer Description attribute: "client-print- 241 support-files-supported" (1setOf octetString(MAX)). 242 - A new REQUIRED Get-Printer-Attributes operation attribute: 243 "client-print-support-files-filter" (octetString(MAX)). 244 - A new RECOMMENDED printer operation: Get-Client-Print-Support- 245 Files. 247 3.1 client-print-support-files-supported (1setOf octetString(MAX)) 249 An IPP Printer uses the REQUIRED Printer Description attribute 250 "client-print-support-files-supported" to represent relevant 251 information about all of the Client Print Support Files it supports. 252 Each value is a composite UTF-8 string with well-defined fields (see 253 Table 1). Each value string MUST be formatted as follows: 255 "uri=val1< field-name2=val21,_,val2p< _ < field-namen=valn1,_,valnq<" 257 The first field MUST be the "uri" field. The remaining fields MAY be 258 in any order. 260 The string MUST NOT include any control characters (hex 00 to 1F), 261 even the so-called white space control characters (TAB, CR, and LF) 262 anywhere. Only zero or more UTF-8 SPACE characters (hex 20) can be 263 included and they can be included only IMMEDIATELY AFTER the 264 delimiter character: "<", but NOT anywhere else, including after "=" 265 and ",". However, if the UTF-8 SPACE character is needed in a 266 client-file-name value, then each occurrence is included directly, 267 without escaping (see example). On the other hand, if the UTF-8 268 SPACE character is needed in a URL value, then each occurrence is 269 escaped as: "%20" (URI conventions - see [RFC2396]). 271 Table 1 lists the REQUIRED fields that a Printer MUST support and the 272 OPTIONAL fields that a Printer MAY support in the "client-print- 273 support-files-supported" (1setOf octetString(MAX)) Printer 274 Description attribute. A Printer implementation MAY support 275 additional fields using the same syntax. Values are defined to be 276 either CASE-SENSITIVE or ALL-LOWER-CASE according to the definitions 277 for the attribute syntaxes from [RFC2911] (set off by single quotes 278 in the table). The CASE-SENSITIVE values MAY have upper and lower 279 case letters as for the corresponding attribute syntaxes in 280 [RFC2911]. The LOWER-CASE values MUST have all lower case alphabetic 281 letters. Additional characters, such as digits, hyphen-minus (-), 282 period (.), and slash (/) are according to the corresponding 283 attribute syntaxes in [RFC2911]. 285 Clients SHOULD ignore fields they don't recognize in a given value. 286 This allows for future extensions to the format of the string without 287 breaking compatibility with earlier clients. 289 Table 1 - "client-print-support-files-supported" attribute fields 291 Field Field value 292 name 294 "uri" One REQUIRED CASE-SENSITIVE 'uri' string identifying the 295 uri where to obtain the support files for each OS 296 platform, document format, and natural language the 297 printer supports. This MUST be the first field in each 298 value. Examples of uri schemes that MAY be found here 299 are 'ftp', 'http', and 'ipp'. The 'ftp' and 'http' 300 schemed URIs identify the archive file that contains all 301 the necessary client support files. 303 The 'ipp' schemed URIs identify the archive file that 304 clients MAY obtain from the Printer using the Get- 305 Client-Print-Support-Files operation (see section 3.3). 306 The URI MUST be a valid URI to the same Printer object, 307 i.e., one of the values of the Printer's "printer-uri- 308 supported" attribute. The 'ipp' URI is used to 309 distinguish between multiple Client Print Support Files 310 in an implementation dependent manner using the URL 311 query syntax (e.g., "?drv-id=xxx") [RFC2396]. The 312 query part MUST NOT exceed 127 octets, not counting the 313 "?" character that begins the query part. A Printer 314 SHOULD support the 'ipp' scheme. 316 "os-type" One or more REQUIRED comma-separated LOWER-CASE 317 'keyword' strings identifying the operating system types 318 supported by this set of Client Print Support Files. 319 Valid values are the operating system names defined in 320 the IANA document [os-names] and the special keyword 321 value: 'unknown'. Although the IANA registry requires 322 that the names be all upper-case, the values MUST be all 323 lower case in this field (plus hyphen-minus (-), period 324 (.), and slash (/)). Examples: 'linux', 'linux-2.2', 325 'os/2', 'sun-os-4.0', 'unix', 'unix-bsd', 'win32', 326 'windows-95', 'windows-98', 'windows-ce', 'windows-nt', 327 'windows-nt-4', 'windows-nt-5', 'unknown'. 329 "cpu- One or more REQUIRED comma-separated LOWER-CASE 330 type" 'keyword' strings identifying the CPU types supported by 331 this set of Client Print Support Files. The values 332 indicate the CPU family independent of the CPU 333 manufacturer. Valid keyword values are: 'x86-16', 334 'x86-32', 'x86-64', 'dec-vax', 'alpha', 'power-pc', 'm- 335 68000, 'sparc', 'itantium', 'mips', 'arm' and will be 337 Field Field value 338 name 340 used as the initial value for the "cpu-type" IANA 341 registry. In addition, the special keyword value: 342 'unknown' is valid. 344 "document One or more REQUIRED comma-separated CASE-SENSITIVE 345 -format" 'mimeMediaType' strings identifying the document formats 346 supported by this set of Client Print Support Files. 347 Valid values are the string representation of the IPP 348 mimeMediaType attribute syntax (see [RFC2911] section 349 4.1.9), for example 'application/postscript'. In 350 addition, the special keyword value: 'unknown' is valid. 352 "natural- One or more REQUIRED comma-separated LOWER-CASE 353 language" 'naturalLanguage' strings identifying the natural 354 language used by this set of Client Print Support Files. 355 Valid values are the string representation of the IPP 356 'naturalLanguage' attribute syntax (see [RFC2911] 357 section 4.1.8), for example 'en' and 'en-us'. In 358 addition, the special keyword value: 'unknown' is valid. 360 "compress One REQUIRED LOWER-CASE 'keyword' string identifying the 361 ion" mechanism used to compress this set of Client Print 362 Support Files. All files needed for the installation of 363 a printer driver MUST be compressed into a single file. 364 Valid keyword values are the keywords defined by 365 [RFC2911] or registered with IANA for use in the IPP 366 "compression" and "compression-supported" attributes. 367 See [RFC2911] section 4.4.32), for example 'gzip'. The 368 'none' value limits the uncompressed Client Print 369 Support File to a single file. The values for the 370 "compression" field that a Printer supports NEED NOT be 371 the same values that the Printer is configured to 372 support in Job Creation operations as indicated in the 373 Printer's "compressions-supported" attribute. 375 "file- One or more REQUIRED comma-separated LOWER-CASE 376 type" 'keyword' strings identifying the type of the Client 377 Print Support Files. Valid keyword values are: 378 'printer-driver', 'ppd', 'updf', 'gpd'. 380 "client- One REQUIRED CASE-SENSITIVE string identifying the name 381 file- by which the Client Print Support Files will be 382 name" installed on the workstation. For Client Print Support 383 Files of type 'printer-driver', this is also the name 385 Field Field value 386 name 388 that identifies this printer driver in an .inf file. 390 "policy" One OPTIONAL LOWER-CASE 'keyword' string indicating the 391 policy for automatic loading. Valid keyword values are: 392 'manufacturer-recommended', 'administrator-recommended', 393 'manufacturer-experimental, 'administrator- 394 experimental'. The experimental values are for beta 395 test. 397 "file- One OPTIONAL file size in octets represented as ASCII 398 size" decimal digits. 400 "file- One OPTIONAL LOWER-CASE version number. Recommended to 401 version" be of the form "Major.minor[.revision]" where "Major" is 402 the major version number, "minor" is the minor version 403 number and "revision" is an optional revision number. 405 "file- One OPTIONAL File CASE-SENSITIVE creation date and time 406 date- according to ISO 8601 where all fields are fixed length 407 time" with leading zeroes (see [RFC2518] Appendix 2). 408 Examples: 2000-01-01T23:09:05Z and 2000-01-01T02:59:59- 409 04.00 411 "file- One OPTIONAL CASE-SENSITIVE human readable 'text' string 412 info" describing this set of Client Print Support Files. The 413 natural language for this value MUST be the natural 414 language indicated by the Printer's "natural-language- 415 configured" attribute. To avoid exceeding the maximum 416 limit imposed on IPP attributes and to increase 417 interoperability with other systems, the length of this 418 field value MUST not exceed 127 characters. 420 "digital- One REQUIRED LOWER-CASE 'keyword' string identifying the 421 signature mechanism used to ensure the integrity and authenticity 422 " of this set of Client Print Support Files. Valid values 423 are: 'smime', 'pgp', 'dss', and 'xmldsig' which are 424 defined in [RFC2634], [RFC1991], [dss], and [xmldsig], 425 respectively. In addition, the special keyword value: 426 'none' is valid. 428 Each value MUST refer to one and only one set of Client Print Support 429 Files, even if the files are downloadable from various repositories 430 (i.e., even if they are associated with multiple URIs). 432 3.1.1 Use of Keyword Values in fields 434 A number of the fields in Table 1 use keyword strings as values. The 435 syntax of these keywords is the same as in [RFC2911], including the 436 use of private keywords. See [RFC2911] sections 4.1.3 and 6.1. 437 Printer implementers are strongly RECOMMENDED to submit additional 438 keyword values for registration with IANA according to the procedures 439 for registering attributes. See section 7 and [RFC2911] section 6.1. 441 3.1.2 Use of the Special Keyword Value: 'unknown' 443 A number of REQUIRED 'keyword' value fields have a special keyword 444 value: 'unknown' defined. This value is intended for use when the 445 actual value is not known, such as by an administrator automatic 446 software configuring the IPP Printer object. However, it is strongly 447 RECOMMENDED that other more meaningful values be used, instead of the 448 'unknown' value whenever possible. 450 3.1.3 Examples of "client-print-support-files-supported" attribute 451 values 453 The following illustrates what two valid values of the "client-print- 454 support-files-supported" (1setOf octetString(MAX)) Printer 455 Description attribute might look like: 457 uri=ipp://mycompany.com/myprinter?drv-id=ModelY.gz< 458 os-type=windows-95< cpu-type=x86-32< 459 document-format=application/postscript< 460 natural-language=en< compression=gzip< 461 file-type=printer-driver< 462 client-file-name=CompanyX-ModelY-driver.gz< 463 policy=manufacturer-recommended< 465 uri=ftp://mycompany.com/root/drivers/win95/CompanyX/ModelY.gz< 466 os-type=windows-95< cpu-type=x86-32< 467 document-format=application/postscript,application/vnd.hp-PCL< 468 natural-language=en,fr< compression=gzip< 469 file-type=printer-driver< 470 client-file-name=Company T Model Z driver.gz< 471 policy=manufacturer-recommended< 473 The above examples have been broken onto separate lines for 474 readability in this document. However, there MUST NOT be any line 475 breaks in the actual values. 477 The "client-print-support-files-supported" Printer Description 478 attribute MAY be preset at manufacturing time or through 479 administrative means outside the scope of this document. 481 3.2 Get-Printer-Attributes Operation Extension 483 The "client-print-support-files-supported" Printer Description 484 attribute defined in section 3.1 contains information, such as 485 operating system, natural language, and document format, about all of 486 the sets of Client Print Support Files. This section defines an 487 extension to the Get-Printer-Attributes operation that allows a 488 workstation to filter out all but the Client Print Support Files of 489 interest. 491 3.2.1 Get-Printer-Attributes Request 493 A Printer MAY contain information about multiple sets of Client Print 494 Support Files to match the different operating systems, natural 495 languages and document formats it supports. A workstation MAY query 496 this information by including the 'client-print-support-files- 497 supported' keyword as a value of the "requested-attributes" operation 498 attribute of the Get-Printer-Attributes operation. 500 3.2.1.1 client-print-support-files-filter (octetString(MAX)) operation 501 attribute 503 The client can request a subset of the values of the "client-print- 504 support-files-supported" Printer attribute by supplying the "client- 505 print-support-files-filter" (octetString(MAX)) operation attribute in 506 the request as a filter. The filter value indicates in which Client 507 Print Support Files the client is interested. The client MAY supply 508 this attribute. The Printer MUST support this attribute. 510 The filter value of the "client-print-support-files-filter" attribute 511 is a composite string with the same format as that of "client-print- 512 support-files-supported" (see Table 1 - "client-print-support-files- 513 supported" attribute fields in section 3.1) with the following 514 exceptions: 516 Table 2 - "client-print-support-files-filter" attribute fields 518 Field Field Value in the "client-print-support-files-filter" 519 Name attribute 521 uri- One or more comma-separated LOWER-CASE 'uriScheme' 522 scheme string values identifying the uri scheme to be 523 filtered on. Valid values are the string 524 representation of the IPP 'uriScheme' attribute syntax 525 (see [RFC2911] section 4.1.6). Example URI schemes 526 are: 'ftp', 'http', and 'ipp'. The Printer SHOULD 527 support the 'ipp' scheme. If supplied by the client, 528 this field NEED NOT be first. If this field is 529 omitted by the client, the Printer returns all 530 schemes. 532 xxx One or more comma-separated values for any of the 533 fields defined in Table 1, with the single exception 534 of the "uri" field which a client MUST NOT supply and 535 a Printer MUST NOT support. 536 The Printer MUST support any filter field having more 537 than one value separated by a COMMA (,), including the 538 fields that Table 1 indicates MUST BE single valued. 540 Printer implementations MUST support the "client-print-support-files- 541 filter" operation attribute in a Get-Printer-Attributes request with 542 the member fields listed Table 3. Printers MAY support any 543 additional filter fields listed in Table 2. 545 Client implementations MAY supply any filter fields listed in Table 2 546 in the "client-print-support-files-filter" operation attribute of a 547 Get-Printer-Attributes request. 549 Table 3 - REQUIRED "client-print-support-files-filter" fields 551 uri-scheme 553 os-type 555 cpu-type 557 document-format 559 natural-language 561 3.2.1.1.1 Filter matching rules 563 The Printer returns only the values of the "client-print-support- 564 files-supported" Printer Description attribute that match the filter 565 in the "client-print-support-files-filter" operation attribute. The 566 following filter matching rules are defined: 568 1. A match occurs if at least one value of each field supplied by 569 the client in the filter matches a Client Print Support File 570 value. Printers MUST ignore a filter field supplied by a client 571 that the Printer does not support and return a match if all 572 supported fields do match, no matter what value the client 573 supplied for that unsupported field. Similarly, Printers MUST 574 ignore a filter field supplied by a client that the Printer does 575 support, but which the field has not been populated for a Client 576 Print Support Files and return a match if all supported and 577 populated fields do match, no matter what value the client 578 supplied for that unpopulated field. 580 2. A match for a CASE-INSENSITIVE field occurs independent of the 581 case of the letters supplied by the client and those stored by 582 the Printer, while a match for a LOWER-CASE field is a strict 583 character for character match. 585 3. A match for a 'keyword' Printer field that is populated with the 586 'unknown' special keyword value occurs for any value supplied by 587 the client for that field. 589 4. If the "client-print-support-files-filter" operation attribute 590 filter is not supplied by the client, the printer SHOULD behave 591 as if the attribute had been provided with all fields left empty 592 (i.e., return an unfiltered list). 594 The following are two examples of a "client-print-support-files- 595 filter" filter value: 597 os-type=windows-95< cpu-type=x86-32< 598 document-format=application-postscript< natural-language=en,de< 600 uri-scheme=ipp< os-type=windows-95< cpu-type=x86-32< 601 document-format=application-postscript< natural-language=en,de< 603 See section 3.2.2 for example matching responses. 605 It is RECOMMENDED that workstations first use the Get-Printer- 606 Attributes operation in combination with "client-print-support-files- 607 filter" operation attribute filter to get a list of the potential 608 Client Print Support Files that meet the workstation's requirements. 609 The workstation can then choose from the returned list which Client 610 Print Support Files to use and where to get them. If one of the URIs 611 returned is an IPP uri, the workstation can retrieve the Client Print 612 Support Files from an IPP printer via the Get-Client-Print-Support- 613 Files operation (see section 3.3). 615 3.2.2 Get-Printer-Attributes Response 617 A Printer MUST return the "client-print-support-files-supported" 618 (1setOf octetString(MAX)) attribute in the Printer Object Attributes 619 group (group 3) when requested by a client. Each returned attribute 620 value MUST satisfy the criteria specified by the client in the 621 request. 623 For example, if the request contains the following "client-print- 624 support-files-filter" filter: 626 os-type=windows-95< cpu-type=x86-32< 627 document-format=application-postscript< 628 natural-language=en,de< 630 A conforming response is the following two octet String values: 632 uri=ipp://mycompany.com/myprinter?drv-id=ModelY.gz< 633 os-type=windows-95< cpu-type=x86-32< 634 document-format=application/postscript< 635 natural-language=en< compression=gzip< 636 file-type=printer-driver< 637 client-file-name=CompanyX-ModelY-driver.gz< 638 policy=manufacturer-recommended< 639 digital-signature=smime< 641 uri=ftp://mycompany.com/root/drivers/win95/CompanyX/ModelY.gz< 642 os-type=windows-95< cpu-type=x86-32< 643 document-format=application/postscript,application/vnd.hp-PCL< 644 natural-language=en,fr< compression=gzip< 645 file-type=printer-driver< 646 client-file-name=CompanyX-ModelY-driver.gz< 647 policy=manufacturer-recommended< 648 digital-signature=smime< 650 These examples have been broken onto separate lines for readability 651 in this document. However, there MUST NOT be any line breaks in the 652 actual values. 654 As another example, if the above request had also contained the "uri- 655 scheme" field in the following "client-print-support-files-filter" 656 filter: 658 uri-scheme=ipp< os-type=windows-95< cpu-type=x86-32< 659 document-format=application-postscript< 660 natural-language=en,de< 662 Then only the first value would have been returned as a single 663 octetString value: 665 uri=ipp://mycompany.com/myprinter?drv-id=ModelY.gz< 666 os-type=windows-95< cpu-type=x86-32< 667 document-format=application/postscript< 668 natural-language=en< compression=gzip< 669 file-type=printer-driver< 670 client-file-name=CompanyX-ModelY-driver.gz< 671 policy=manufacturer-recommended< 672 digital-signature=smime< 674 3.3 Get-Client-Print-Support-Files 676 This RECOMMENDED operation allows a client to download Client Print 677 Support Files from an IPP Printer. 679 3.3.1 Get-Client-Print-Support-Files Request 681 The following sets of attributes are part of the Get-Client-Print- 682 Support-Files request: 684 Group 1: Operation Attributes 686 Natural Language and Character Set: 687 The "attributes-charset" and "attributes-natural-language" 688 attributes as described in [RFC2911], section 3.1.4.1. 690 Target: 691 The "printer-uri" (uri) operation attribute which is the target 692 for this operation as described in [RFC2911], section 3.1.5. 693 The client MUST use the URI value as the target of this 694 operation that the Printer returns in the "uri" field (see Table 695 1) in the Get-Printer-Attributes response. Furthermore, the 696 client MUST use the appropriate authorization and security 697 regime for this URI as indicated by the Printer's "printer-uri- 698 supported", "uri-authentication-supported" and "uri-security- 699 supported" attributes (see [RFC2911] sections 4.4.1, 4.4.2, and 700 4.4.3). Only if the URI returned in the "uri" field matches the 701 URI that the client used for the Get-Printer-Attributes request 702 MAY the client use the same HTTP connection. The 'ipp' URL 703 matching rules are defined in [ipp-url] and do not include the 704 query part. 706 Requesting User Name: 707 The "requesting-user-name" (name(MAX)) attribute SHOULD be 708 supplied by the client as described in [RFC2911], section 8.3. 710 "client-print-support-files-query" (text(127)): 711 The client MUST supply this attribute specifying the query part 712 [RFC2396] of the ipp uri for the desired Client Print Support 713 Files not including the "?" character that starts the query 714 part, i.e., the value of the "uri" field following the "?" 715 character returned by the Get-Printer-Attributes in one of the 716 values of the "client-print-support-files-supported" (1setOf 717 octetString(MAX)) Printer attribute (see Table 1) that had an 718 'ipp' scheme. 720 3.3.2 Get-Client-Print-Support-Files Response 722 The Printer object returns the following sets of attributes as part 723 of the Get-Client-Print-Support-Files Response: 725 Group 1: Operation Attributes 727 Status Message: 728 In addition to the REQUIRED status code returned in every 729 response, the response OPTIONALLY includes a "status-message" 730 (text(255)) operation attribute as described in [RFC2911], 731 sections 13 and 3.1.6. 733 Natural Language and Character Set: 734 The "attributes-charset" and "attributes-natural-language" 735 attributes as described in [RFC2911], section 3.1.4.2. 737 Group 2: Unsupported Attributes 738 See [RFC2911], section 3.1.7 for details on returning Unsupported 739 Attributes. 741 Group 3: Printer Object Attributes 742 "client-print-support-files-supported" (octetString(MAX)). 743 This attribute identifies the properties of the returned Client 744 Print Support Files. The Printer object MUST return this 745 attribute if the response includes Group 4 (i.e., if a set of 746 Client Print Support Files identified by the supplied "client- 747 print-support-files-query" operation attribute was found). The 748 Printer MUST return all configured fields for the selected 749 Client Print Support Files in the format shown in section 3.1. 751 Group 4: Client Print Support Files 752 The printer MUST supply the Client Print Support Files that match 753 the client's criteria following the "end-of-attributes" tag. All 754 necessary files MUST be compressed into a single transferred file. 756 4 Conformance 758 A Printer conforming to this specification: 760 1.MUST support the "client-print-support-files-supported" Printer 761 Description attribute as defined in section 3.1, including all 762 of the REQUIRED fields defined in Table 1 and MAY support the 763 OPTIONAL fields defined in Table 1. 765 2.MUST support the "client-print-support-files-filter" operation 766 attribute in the Get-Printer-Attributes request as defined in 767 section 3.2, including all of the fields listed in Table 3 and 768 ignoring any fields not recognized. 770 3.MUST support at least one of the following URI schemes that 771 identify the support files: 'ftp', 'http', or 'ipp', of which 772 the 'ipp' scheme is the RECOMMENDED one. 774 4.SHOULD support the Get-Client-Print-Support-Files operation as 775 described in section 3.3. If this operation is supported, then 776 one of the supported schemes MUST be 'ipp'. 778 5.SHOULD support TLS as described in section 9. 780 6.SHOULD support the downloading of Client Print Support Files 781 that have been digitally signed as described in section 9. 783 A client conforming to this specification: 785 1.MUST ignore any fields returned by the Printer in the "client- 786 print-support-files-supported" Printer Description attribute 787 that the client does not recognize or support. 789 2.SHOULD be able to retrieve Client Print Support Files by either 790 FTP Get or HTTP Get operations. 792 3.MUST be able to retrieve Client Print Support Files using the 793 Get-Client-Print-Support-Files operation, i.e., support the 794 'ipp' scheme. 796 4.MUST supply the proper URI value for the "printer-uri" operation 797 attribute as specified in section 3.3.1 under Target:. 799 5.MUST validate that files that are supposed to be digitally 800 signed are done with the indicated mechanism as described in 801 section 9. 803 6.SHOULD support TLS as described in section 9. 805 5 Encoding of the Operation Layer 807 This extension uses the operation layer encoding described in 808 [RFC2910]. 810 6 Encoding of Transport Layer 812 This specification uses the transport layer encoding described in 813 [RFC2910] with the following extensions. 815 New Error codes: 817 0x0417 client-error-client-print-support-file-not-found 819 New Operation code 821 0x0021 Get-Client-Print-Support-Files 823 7 IANA Considerations 825 The IANA-registered operating system names that IANA has registered 826 [os-names] are required by this spec for use in the "os-type" field 827 (see Table 1). 829 Table 1 of this document defines possible 'keyword' values for the 830 "cpu-type" field. However, the existing IANA machine registration 831 [cpu-names] is inadequate for two reasons: a) it is really a machine 832 model number, not a CPU type, and b) it doesn't express whether a 833 CPU is 16-bit, 32-bit, or 64-bit which needs to be indicated in the 834 keyword value. Therefore, the "os-type" field will be a new 835 registration with initial values assigned. 837 The rest of this section contains the exact information for IANA to 838 add to the IPP Registries according to the procedures defined in RFC 839 2911 [RFC2911] section 6. 841 Note to RFC Editors: Replace RFC NNNN below with the RFC number 842 for this document, so that it accurately reflects the content of 843 the information for the IANA Registry. 845 7.1 Attribute Registrations 847 The attributes and fields defined in this document will be published 848 by IANA according to the procedures in RFC 2911 [RFC2911] section 6.2 849 with the following path: 851 ftp.isi.edu/iana/assignments/ipp/attributes/ 853 The registry entry will contain the following information: 855 Printer Description Attributes: Ref: Section: 856 client-print-support-files-supported (1setOf octetString(MAX)) 857 RFC NNNN 3.1 859 For purposes of IANA attribute registration, the following fields of 860 the "client-print-support-files-supported" and the "client-print- 861 support-files-filter" attributes are registered following the 862 procedures for IPP attribute registration: 863 Ref: Section: 864 uri (uri) RFC NNNN 3.1 865 os-type (type2 keyword) RFC NNNN 3.1 866 cpu-type (type2 keyword) RFC NNNN 3.1 867 document-format (mimeMediaType) RFC NNNN 3.1 868 natural-language (naturalLanguage) RFC NNNN 3.1 869 compression (type2 keyword) RFC NNNN 3.1 870 file-type (type2 keyword) RFC NNNN 3.1 871 client-file-name (name(MAX)) RFC NNNN 3.1 872 policy (type2 keyword) RFC NNNN 3.1 873 file-size (integer(0:MAX)) RFC NNNN 3.1 874 file-version (name(MAX)) RFC NNNN 3.1 875 file-date-time (text(25)) RFC NNNN 3.1 876 file-info (text(127)) RFC NNNN 3.1 877 digital-signature (type2 keyword) RFC NNNN 3.1 879 uri-scheme (uriScheme) RFC NNNN 3.2 881 Operation Attributes: Ref: Section: 882 client-print-support-files-filter (octetString(MAX))RFC NNNN 3.2 884 7.2 Operation Registrations 886 The operations defined in this document will be published by IANA 887 according to the procedures in RFC 2911 [RFC2911] section 6.4 with 888 the following path: 890 ftp.isi.edu/iana/assignments/ipp/operations/ 892 The registry entry will contain the following information: 894 Operations: Ref. Section: 895 Get-Client-Print-Support-Files RFC NNNN 3.3 897 8 Internationalization Considerations 899 All text representations introduced by this specification adhere to 900 the internationalization-friendly representation supported by IPP. 901 This work is also accommodates the use of Client Print Support Files 902 of different languages. 904 9 Security Considerations 906 The IPP Model and Semantics document [RFC2911] discusses high-level 907 security requirements (Client Authentication, Server Authentication 908 and Operation Privacy). Client Authentication is the mechanism by 909 which the client proves its identity to the server in a secure 910 manner. Server Authentication is the mechanism by which the server 911 proves its identity to the client in a secure manner. Operation 912 Privacy is defined as a mechanism for protecting operations from 913 eavesdropping. 915 Only operators of a printer SHOULD be allowed to set the "client- 916 print-support-files-supported" attribute and only users of the 917 printer SHOULD be allowed to query that information. 919 The IPP extension described in this document introduces the potential 920 for a security threat previously not encountered by IPP. As Client 921 Print Support Files might exist in the form of executable objects (as 922 is the case with printer drivers, for example), additional provisions 923 are needed to prevent the distribution of malicious code through this 924 mechanism. Digital signatures provide the message level security 925 commonly used to help consumers of network resources verify the 926 authenticity and integrity of those resources. Specifically, digital 927 signatures help defend against security threats such as message 928 insertion, message deletion, and message modification, and their 929 combined use into man-in-the-middle attacks. 931 This document identifies some commonly used signing mechanisms (SMIME 932 [RFC2634], PGP [RFC1991], DSS [dss], and XML Digital Signatures 933 [xmldsig]), though any others MAY be used. Of course, it is assumed 934 that once end-users know the identity of the provider of Client Print 935 Support Files, they can make the correct determination as to whether 936 it is safe to use those files. 938 Printers that support the Get-Client-Print-Support-Files operation 939 SHOULD support the downloading of Client Print Support Files that 940 have been digitally signed. Clients that invoke the Get-Client- 941 Print-Support-Files operation MUST make sure that Client Print 942 Support Files that are supposed to be signed (i.e., whose client- 943 print-support-files-supported attribute value includes the "digital- 944 signature" field) are indeed signed via the specified mechanism when 945 downloaded from the printer. 947 Furthermore, printers that support the Get-Client-Print-Support-Files 948 operation SHOULD implement TLS to provide application level channel 949 security and enable users to reliably authenticate the source of the 950 Client Print Support Files. 952 10 References 954 [cpu-names] 955 IANA Registry of CPU Names at ftp://ftp.isi.edu/in- 956 notes/iana/assignments/XXX. 958 [dss] 959 U.S. Department of Commerce, "Digital Signature Standard (DDS)", 960 Federal Information Processing Standards Publication 186-1 (FIPS 961 PUB 186-1), December 15, 1998. 963 [ipp-url] 964 Herriot, R., McDonald, I., "Internet Printing Protocol (IPP): IPP 965 URL Scheme." , February 14, 966 2001. 968 [os-names] 969 IANA Registry of Operating System Names at ftp://ftp.isi.edu/in- 970 notes/iana/assignments/operating-system-names. 972 [RFC1991] 973 D. Atkins, W. Stallings, P. Zimmermann, "PGP Message Exchange 974 Formats", RFC 1991, August, 1996. 976 [RFC2026] 977 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 978 2026, October 1996. 980 [RFC2396] 981 Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource 982 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 984 [RFC2518] 985 Goland, Y., et al, "HTTP Extensions for Distributed Authoring -- 986 WEBDAV", RFC 2518, February 1999. 988 [RFC2616] 989 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 990 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 991 RFC 2616, June 1999. 993 [RFC2634] 994 P. Hoffman, "Enhanced Security Services for S/MIME", RFC 2634, June 995 1999. 997 [RFC2910] 998 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 999 Protocol/1.1: Encoding and Transport", RFC 2910, September 2000. 1001 [RFC2911] 1002 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1003 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2911, 1004 September 2000. 1006 [xmldsig] 1007 D. Eastlake, J. Reagle, D. Solo "XML-Signature Syntax and 1008 Processing", , October 31, 2000. 1010 11 Author's Addresses 1012 Hugo Parra 1013 Novell, Inc. 1014 1800 South Novell Place 1015 Provo, UT 84606 1017 Phone: 801-861-3307 1018 Fax: 801-861-4025 1019 e-mail: hparra@novell.com 1021 Ted Tronson 1022 Novell, Inc. 1023 1800 South Novell Place 1024 Provo, UT 84606 1026 Phone: 801-861-3338 1027 Fax: 801-861-4025 1028 e-mail: ttronson@novell.com 1029 Thomas N. Hastings 1030 Xerox Corp. 1031 737 Hawaii St. ESAE 231 1032 El Segundo, CA 90245 1034 Phone: 310-333-6413 1035 Fax: 310-333-5514 1036 e-mail: hastings@cp10.es.xerox.com 1038 12 Full Copyright Statement 1040 Copyright (C) The Internet Society (2001). All Rights Reserved. 1042 This document and translations of it may be copied and furnished to 1043 others, and derivative works that comment on or otherwise explain it 1044 or assist in its implementation may be prepared, copied, published 1045 and distributed, in whole or in part, without restriction of any 1046 kind, provided that the above copyright notice and this paragraph are 1047 included on all such copies and derivative works. However, this 1048 document itself may not be modified in any way, such as by removing 1049 the copyright notice or references to the Internet Society or other 1050 Internet organizations, except as needed for the purpose of 1051 developing Internet standards in which case the procedures for 1052 copyrights defined in the Internet Standards process must be 1053 followed, or as required to translate it into languages other than 1054 English. 1056 The limited permissions granted above are perpetual and will not be 1057 revoked by the Internet Society or its successors or assigns. 1059 This document and the information contained herein is provided on an 1060 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1061 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1062 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1063 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1064 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1066 Acknowledgement 1068 Funding for the RFC Editor function is currently provided by the 1069 Internet Society.