idnits 2.17.1 draft-ietf-ipp-install-00.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 9) being 67 lines 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], [RFC2567]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 70: '... IPP/1.0. A few OPTIONAL operator ope...' RFC 2119 keyword, line 146: '...d terms, such as MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 147: '...Y, NEED NOT, and OPTIONAL, have specia...' RFC 2119 keyword, line 155: '...his document, it MUST support a REQUIR...' RFC 2119 keyword, line 157: '...his document, it MAY support an OPTION...' (32 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2000) is 8659 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 section? 'RFC2567' on line 56 looks like a reference -- Missing reference section? 'RFC2568' on line 58 looks like a reference -- Missing reference section? 'RFC2569' on line 62 looks like a reference -- Missing reference section? 'RFC2616' on line 81 looks like a reference -- Missing reference section? 'RFC2119' on line 149 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT There remains 2 unresolved ISSUES 3 4 Hugo Parra 5 Novell, Inc. 6 Ted Tronson 7 Novell, Inc. 8 July 13, 2000 10 Internet Printing Protocol (IPP): 12 Printer Installation Extension 14 Copyright (C) The Internet Society (2000). All Rights Reserved. 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of [rfc2026]. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, and 21 its working groups. Note that other groups may also distribute working 22 documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed as 33 http://www.ietf.org/shadow.html. 35 Abstract 37 Various client platforms require that some setting up take place at the 38 workstation before the client can properly submit jobs to a specific 39 printer. This setup process is sometimes referred to as printer 40 installation. Most clients need some information about the printer 41 being installed as well as support files to complete the printer 42 installation. The nature of the support files varies depending on the 43 specific client platform, from simple configuration files to highly 44 sophisticated printer drivers. This document refers to these support 45 files as "client print support files". Traditionally, the selection and 46 installation of the correct client print support files has been error 47 prone. The selection and installation process can be simplified and 48 even automated if the workstation can learn some key information about 49 the printer. This document describes the IPP extensions that enable 50 workstations to obtain the information needed to perform a proper 51 printer driver installation using IPP. 53 Expires January 13, 2001 54 The full set of IPP documents includes: 56 Design Goals for an Internet Printing Protocol [RFC2567] 57 Rationale for the Structure and Model and Protocol for the Internet 58 Printing Protocol [RFC2568] 59 Internet Printing Protocol/1.1: Model and Semantics [ipp-mod] 60 Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro] 61 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 62 Mapping between LPD and IPP Protocols [RFC2569] 64 The "Design Goals for an Internet Printing Protocol" document takes a 65 broad look at distributed printing functionality, and it enumerates 66 real-life scenarios that help to clarify the features that need to be 67 included in a printing protocol for the Internet. It identifies 68 requirements for three types of users: end users, operators, and 69 administrators. It calls out a subset of end user requirements that are 70 satisfied in IPP/1.0. A few OPTIONAL operator operations have been 71 added to IPP/1.1. 73 The "Rationale for the Structure and Model and Protocol for the Internet 74 Printing Protocol" document describes IPP from a high level view, 75 defines a roadmap for the various documents that form the suite of IPP 76 specification documents, and gives background and rationale for the IETF 77 working group's major decisions. 79 The "Internet Printing Protocol/1.1: Encoding and Transport" document is 80 a formal mapping of the abstract operations and attributes defined in 81 the model document onto HTTP/1.1 [RFC2616]. It defines the encoding 82 rules for a new Internet MIME media type called "application/ipp". This 83 document also defines the rules for transporting a message body over 84 HTTP whose Content-Type is "application/ipp". This document defines a 85 new scheme named 'ipp' for identifying IPP printers and jobs. 87 The "Internet Printing Protocol/1.1: Implementer's Guide" document gives 88 insight and advice to implementers of IPP clients and IPP objects. It 89 is intended to help them understand IPP/1.1 and some of the 90 considerations that may assist them in the design of their client and/or 91 IPP object implementations. For example, a typical order of processing 92 requests is given, including error checking. Motivation for some of the 93 specification decisions is also included. 95 The "Mapping between LPD and IPP Protocols" document gives some advice 96 to implementers of gateways between IPP and LPD (Line Printer Daemon) 97 implementations. 99 Expires January 13, 2001 100 Table of Contents 102 1 Introduction......................................................4 103 2 Terminology.......................................................4 104 3 Model Extensions..................................................4 105 3.1 "CLIENT-PRINT-SUPPORT-FILES-SUPPORTED" (1SETOF OCTETSTRING(MAX)).5 106 3.2 GET-PRINTER-ATTRIBUTES EXTENSION.................................7 107 3.2.1 Get-Printer-Attributes Request..............................7 108 3.2.2 Get-Printer-Attributes Response.............................9 109 3.3GET-CLIENT-PRINT-SUPPORT-FILES...................................9 110 3.3.1 Get-Client-Print-Support-Files Request.....................10 111 3.3.2 Get-Client-Print-Support-Files Response....................10 112 4 Encoding of the Operation Layer..................................11 113 5 Encoding of Transport Layer......................................11 114 6 IANA Considerations..............................................11 115 7 Internationalization Considerations..............................11 116 8 Security Considerations..........................................11 117 9 References.......................................................12 118 10 Author's Addresses...............................................13 119 11 Full Copyright Statement.........................................13 121 Expires January 13, 2001 122 1 Introduction 124 A common configuration for printing from a workstation requires that 125 some client print support files (e.g., PPD, printer driver files) 126 specific to the target printer be installed on that workstation. 127 Selection and configuration of the appropriate client print support 128 files can be simplified and even automated if the workstation can obtain 129 some key information about the printer. With a few extensions, IPP 130 provides a simple and reliable vehicle for printers to convey this 131 information to interested workstations. The IPP extensions described in 132 this document enable a flexible solution for installing client print 133 support files on workstations running different operating systems and 134 for printers of all makes and models. It allows client print support 135 files to be downloaded from repositories of different sorts. A possible 136 repository for the files is the printer itself. The extensions 137 necessary for getting client print support files from the printer are 138 included in this document. 140 2 Terminology 142 This document uses terms such as "attributes", "keywords", and 143 "support". These terms have special meaning and are defined in the 144 model terminology [ipp-mod] section 12.2. 146 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, 147 MAY, NEED NOT, and OPTIONAL, have special meaning relating to 148 conformance. These terms are defined in [ipp-mod] section 12.1 on 149 conformance terminology, most of which is taken from RFC 2119 [RFC2119]. 151 This section defines the following additional terms that are used 152 throughout this document: 154 REQUIRED: if an implementation supports the extensions described in 155 this document, it MUST support a REQUIRED feature. 156 OPTIONAL: if an implementation supports the extensions described in 157 this document, it MAY support an OPTIONAL feature. 159 3 Model Extensions 161 To assist workstations in the printer installation process, an IPP 162 printer needs to provide the workstation with information about the 163 client print support files, such as the their name and location/s. This 164 information needs to match the workstation's specific environment, such 165 as its operating system, preferred natural language, and preferred 166 document format. 168 The following extensions to the IPP model enable assisted or automated 169 printer installation. This section describes each extension in detail. 171 - A new REQUIRED printer-description attribute: "client-print- 172 support-files-supported". 174 - A new REQUIRED Get-Printer-Attributes operational attribute: 175 "client-print-support-files-request". 177 Expires January 13, 2001 179 - A new OPTIONAL printer operation: Get-Client-Print-Support- 180 Files. 182 3.1 "client-print-support-files-supported" (1setOf octetString(MAX)) 184 An IPP Printer uses the REQUIRED printer-description attribute "client- 185 print-support-files-supported" to represent relevant information about 186 the client print support files it supports. Each value is a composite 187 ASCII string with well-defined fields (see Table 1). Each value string 188 must be formatted as follows: 190 "uri=val < field-name =val ,.,val < . < field-name =val ,.,val <". 191 1 2 21 2p n n1 nq 193 Expires January 13, 2001 195 Field name Field value 197 "uri" One REQUIRED string identifying the uri where to obtain 198 the support files for each OS platform, document format, 199 and natural language the printer supports. This MUST be 200 the first field in each value. Examples of uri types 201 that may be found here are FTP, HTTP, and IPP. FTP and 202 HTTP uri's identify the archive file that contains all 203 the necessary client support files. IPP uri's identify 204 the printer object from which the archive file may be 205 obtained (see section 3.3). 207 "os-type" One or more REQUIRED comma-separated strings identifying 208 the operating system types supported by this set of 209 client print support files. Valid values include the 210 operating system names defined in the IANA document [os- 211 names]. 213 "cpu-type" One or more REQUIRED comma-separated strings identifying 214 the CPU types supported by this set of client print 215 support files. Valid values include the operating system 216 names defined in the IANA document [cpu-names]. 217 "unknown" is a valid value. 219 "document- One or more REQUIRED comma-separated strings identifying 220 format" the document formats supported by this set of client 221 print support files. Valid values are the string 222 representation of the IPP mimeMediaType syntax. 223 "unknown" is a valid value. 225 "natural- One or more REQUIRED comma-separated strings identifying 226 language" the natural language used by this set of client print 227 support files. Valid values are the string 228 representation of the IPP naturalLanguage syntax. 229 "unknown" is a valid value. 231 "compression" One REQUIRED string identifying the mechanism used to 232 compress this set of client print support files. All 233 files needed for the installation of a printer driver 234 MUST be compressed into a single file. Valid values 235 are: "deflate", "gzip", "compress". "none" is allowed 236 but limits the uncompressed client print support file to 237 a single file. 239 "install- One or more REQUIRED comma-separated strings identifying 240 file-type" the type of the client print support files. Valid 241 values are: "printer-driver", "ppd", "updf", "gpd". 243 "install- One REQUIRED string identifying the name by which the 244 file-name" client print support files will be installed on the 245 workstation. For client print support files of type 246 "printer-driver", this is also the name that identifies 247 this printer driver in an .inf file. 249 Table 1. client-print-support-files-supported fields 251 Expires January 13, 2001 252 Each value MUST refer to one and only one set of client print support 253 files, even if the files are downloadable from various repositories 254 (i.e., even if they are associated with multiple uir's). 256 The following illustrates what two valid values of "client-print- 257 support-files-supported" might look like, ISSUE 1: What strings should 258 be used for CPU types in the examples? 260 "uri=ipp://mycompany.com/myprinter< os-type=windows-95< 261 cpu-type=Intell-P5< document- 262 format=application/postscript< 263 natural-language=en< compresion=gzip< install-file- 264 type=printer-driver< 265 install-file-name=ManufacturerName<" 267 "uri=ftp://mycompany.com/root/drivers/win95/CompanyX/ModelY. 268 zip< 269 os-type=windows-95< cpu-type=Intell-P5< 270 document-format=application/postscript,application/vnd.hp- 271 PCL< 272 natural-language=en,fr< compresion=gzip< install-file- 273 type=printer-driver< 274 install-file-name=ManufacturerName<" 276 The "client-print-support-files-supported" printer description attribute 277 may be preset at manufacturing time or set via the IPP set-printer- 278 attribute operation or through administrative means outside the scope of 279 IPP. 281 Clients SHOULD ignore fields they don't recognize in a given value. 282 This allows for feature extensions to the format of the string without 283 breaking compatibility with earlier clients. 285 3.2 Get-Printer-Attributes Extension 287 The following extensions allow a workstation to retrieve information on 288 the client print support files a printer supports using the existing 289 Get-Printer-Attributes operation. 291 3.2.1 Get-Printer-Attributes Request 293 A printer may contain information on multiple client print support files 294 to match the different operating systems, natural languages and document 295 formats it supports. A workstation may query this information by 296 including "client-print-support-files-supported " in the "requested- 297 attributes" operational attribute of the Get-Printer-Attributes 298 operation. The workstation can control what information a printer 299 returns by including the "client-print-support-files-request" 300 operational attribute. 302 Expires January 13, 2001 303 "client-print-support-files-request" (octetString(MAX)) is used as 304 follows. 306 The IPP Printer is REQUIRED to support this operational attribute and 307 all its member fields. An IPP Client MAY supply the attribute if it 308 wishes to restrict the printer driver information it receives from the 309 printer. Its text value is a composite string with the same format as 310 that of "client-print-support-files-supported" (see section 3.1). Table 311 2 describes the fields that may be included in this string. 313 If "client-print-support-files-request" is not specified by the client, 314 the printer should behave as if the attribute had been provided with all 315 fields left empty (i.e., return an unfiltered list). 317 It is recommended that workstations first use Get-Printer-Attributes in 318 combination with "client-print-support-files-request" to get a list of 319 the potential client print support files that meet the workstation's 320 requirements. The workstation can then choose from the returned list 321 which client print support files to use and where to get them. If one 322 of the uri's returned is an IPP uri, the workstation can retrieve the 323 client print support files from an IPP printer via the Get-Client-Print- 324 Support-Files operation (see section 3.3). 326 Expires January 13, 2001 327 Field name Field value 329 "uri-scheme" One or more OPTIONAL strings instructing the printer 330 to only return information on client print support 331 files that can be located at uri's of the specified 332 uri schemes. If not present, the printer does not 333 filter the information it returns based on uri-scheme. 335 "os-type" One or more OPTIONAL strings instructing the printer 336 to only return information on client print support 337 files that support the specified operating systems. 338 If not present, the printer does not filter the 339 information it returns based on os-type. 341 "cpu-type" One or more OPTIONAL strings instructing the printer 342 to only return information on client print support 343 files that support the specified CPU types. If not 344 present, the printer does not filter the information 345 it returns based on cpu-type. 347 "document- One or more OPTIONAL strings instructing the printer 348 format" to only return information on client print support 349 files that support the specified document formats. If 350 not present, the printer does not filter the 351 information it returns based on document format. 353 "natural- One or more OPTIONAL strings instructing the printer 354 language" to only return information on client print support 355 files that support the specified natural languages. 356 If not present, the printer does not filter the 357 information it returns based on natural language. 359 "compression" One or more OPTIONAL strings instructing the printer 360 to only return information on client print support 361 files that use the specified compressions. If not 362 present, the printer does not filter the information 363 it returns based on compression. 365 Table 2. client-print-support-files-request fields 367 3.2.2 Get-Printer-Attributes Response 369 A printer MUST return the "client-print-support-files-supported" 370 attribute in the "printer-object" attribute group when a requested by a 371 client. Each returned attribute value must satisfy the criteria 372 specified by the client in the request. 374 3.3 Get-Client-Print-Support-Files 376 This OPTIONAL operation allows a client to download client print support 377 files from an IPP Printer. 379 Expires January 13, 2001 380 3.3.1 Get-Client-Print-Support-Files Request 382 The following sets of attributes are part of the Get-Client-Print- 383 Support-Files request: 385 Group 1: Operation Attributes 387 Natural Language and Character Set: 388 The "attributes-charset" and "attributes-natural-language" 389 attributes as described in [ipp-mod], section 3.1.4.1. 391 Target: 392 The "printer-uri" (uri) operation attribute which is the target 393 for this operation as described in [ipp-mod], section 3.1.5. 395 Requesting User Name: 396 The "requesting-user-name" (name(MAX)) attribute SHOULD be 397 supplied by the client as described in [ipp-mod], section 8.3. 399 "client-print-support-files-request" (octetString(MAX)) : 400 The client MUST supply this attribute specifying the criteria 401 the returned client print support files should meet. If more 402 than one set of client print support files meet the specified 403 criteria, the printer returns the first one it encounters. The 404 format and semantics of this attribute's value are identical to 405 those of the Get-Printer-Attributes operational attribute of the 406 same name described in section 3.2.1. 408 3.3.2 Get-Client-Print-Support-Files Response 410 The Printer object returns the following sets of attributes as part of 411 the Get-Client-Print-Support-Files Response: 413 Group 1: Operation Attributes 415 Status Message: 416 In addition to the REQUIRED status code returned in every 417 response, the response OPTIONALLY includes a "status-message" 418 (text(255)) operation attribute as described in [ipp-mod], 419 sections 13 and 3.1.6. 421 Natural Language and Character Set: 422 The "attributes-charset" and "attributes-natural-language" 423 attributes as described in [ipp-mod], section 3.1.4.2. 425 Group 2: Unsupported Attributes 426 See [ipp-mod], section 3.1.7 for details on returning Unsupported 427 Attributes. 429 Group 3: Printer Object Attributes 431 Expires January 13, 2001 432 "client-print-support-files-supported" (octetString(MAX)). 433 The Printer object MUST return this attribute if the response 434 includes Group 4 (i.e., if a set of client print support files 435 that meets the client's criteria was found and is included in 436 the response). The provided text string MUST use the format 437 shown in section 3.1. This attribute identifies the properties 438 of the returned client print support files. 440 Group 4: Client Print Support Files 441 The printer MUST supply the client print support files that match 442 the client's criteria following the "end-of-attributes" tag. All 443 necessary files must be compressed into a single file. 445 4 Encoding of the Operation Layer 447 This extension uses the operation layer encoding described in [ipp-pro]. 449 5 Encoding of Transport Layer 451 This specification uses the transport layer encoding described in [ipp- 452 pro] with the following extensions. 454 New Error codes: 456 0x0417 clnt-err-client-print-support-file-not-found 458 New Operation code 460 0x0021 Get-Client-Print-Support-Files 462 6 IANA Considerations 464 IANA-registered operating system names are required by this spec. All 465 other IANA considerations are already addressed by IPP. ISSUE 2: Should 466 mention IANA's future support for CPU types? 468 7 Internationalization Considerations 470 All text representations introduced by this specification adhere to the 471 internationalization-friendly representation supported by IPP. This 472 work is also accommodates the use of client print support files of 473 different languages. 475 8 Security Considerations 477 The IPP Model and Semantics document [ipp-mod] discusses high-level 478 security requirements (Client Authentication, Server Authentication and 479 Operation Privacy). Client Authentication is the mechanism by which the 480 client proves its identity to the server in a secure manner. Server 481 Authentication is the mechanism by which the server proves its identity 483 Expires January 13, 2001 484 to the client in a secure manner. Operation Privacy is defined as a 485 mechanism for protecting operations from eavesdropping. 487 Only operators of a printer should be allowed to set the "printer- 488 driver-supported" attribute and only users of the printer should be 489 allowed to query that information. 491 Printers that support the Get-Client-Print-Support-Files operation are 492 REQUIRED to implement TLS to enable users to reliably authenticate the 493 source of the client print support files. 495 9 References 497 [cpu-names] 498 IANA Registry of CPU Names at ftp://ftp.isi.edu/in- 499 notes/iana/assignments/XXX. 501 [ipp-mod] 502 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 503 "Internet Printing Protocol/1.0: Model and Semantics", , March 1, 2000. 506 [ipp-pro] 507 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 508 Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11- 509 05.txt, March 1, 2000. 511 [os-names] 512 IANA Registry of Operating System Names at ftp://ftp.isi.edu/in- 513 notes/iana/assignments/operating-system-names. 515 [rfc2026] 516 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 517 2026, October 1996. 519 [rfc2616] 520 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 521 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 522 RFC 2616, June 1999. 524 Expires January 13, 2001 526 10 Author's Addresses 528 Hugo Parra 529 Novell, Inc. 530 1800 South Novell Place 531 Provo, UT 84606 532 Phone: 801-861-3307 533 Fax: 801-861-4025 534 e-mail: hparra@novell.com 536 Ted Tronson 537 Novell, Inc. 538 1800 South Novell Place 539 Provo, UT 84606 540 Phone: 801-861-3338 541 Fax: 801-861-4025 542 e-mail: ttronson@novell.com 544 11 Full Copyright Statement 546 Copyright (C) The Internet Society (2000). All Rights Reserved. 548 This document and translations of it may be copied and furnished to 549 others, and derivative works that comment on or otherwise explain it or 550 assist in its implementation may be prepared, copied, published and 551 distributed, in whole or in part, without restriction of any kind, 552 provided that the above copyright notice and this paragraph are included 553 on all such copies and derivative works. However, this document itself 554 may not be modified in any way, such as by removing the copyright notice 555 or references to the Internet Society or other Internet organizations, 556 except as needed for the purpose of developing Internet standards in 557 which case the procedures for copyrights defined in the Internet 558 Standards process must be followed, or as required to translate it into 559 languages other than English. 561 The limited permissions granted above are perpetual and will not be 562 revoked by the Internet Society or its successors or assigns. 564 This document and the information contained herein is provided on an "AS 565 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 566 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 567 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 568 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 569 FITNESS FOR A PARTICULAR PURPOSE. 571 Expires January 13, 2001