idnits 2.17.1 draft-ietf-ipp-install-04.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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 36: '...ent describes an OPTIONAL extension to...' RFC 2119 keyword, line 113: '... Table 3 - REQUIRED "client-print-su...' RFC 2119 keyword, line 118: '...cification is an OPTIONAL extension to...' RFC 2119 keyword, line 135: '... The OPTIONAL IPP extension defined ...' RFC 2119 keyword, line 159: '... MAY have multiple sets of Client Pr...' (88 more instances...) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2911, but the abstract doesn't seem to directly say this. It does mention RFC2911 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 379 has weird spacing: '...gnature mecha...' == Line 484 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'.) (Using the creation date from RFC2911, updated by this document, for RFC5378 checks: 1999-02-22) -- 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 17, 2001) is 8319 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 (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Printing Protocol WG Hugo Parra 3 INTERNET-DRAFT Novell, Inc. 4 Ted Tronson 5 Updates: RFC 2911 Novell, Inc. 6 [Target category: standards track] Tom Hastings 7 Expires: January 17, 2002 Xerox Corp 8 July 17, 2001 10 Internet Printing Protocol (IPP): 11 Printer Installation Extension 13 Copyright (C) The Internet Society (2001). All Rights Reserved. 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of [RFC2026]. Internet-Drafts are 19 working documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed as 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes an OPTIONAL extension to the Internet 37 Printing Protocol/1.0 (IPP) [RFC2566, RFC2565] and IPP/1.1 [RFC2911, 38 RFC2910]. Various client platforms require that some setting up take 39 place at the workstation before the client can properly submit jobs 40 to a specific printer. This setup process is sometimes referred to 41 as printer installation. Most clients need some information about 42 the printer being installed as well as support files to complete the 43 printer installation. The nature of these "Client Print Support 44 Files" varies depending on the specific client platform, from simple 45 configuration files to highly sophisticated printer drivers. The 46 selection and installation process can be simplified and even 47 automated if the workstation can learn some key information about the 48 printer and which sets of Client Print Support Files are available. 49 Such key information includes: operating system type, CPU type, 50 document-format (PDL), natural language, compression mechanism, file 51 type, client file name, policy for automatic loading, file size, file 52 version, file date and time, file information description, and 53 digital signature. 55 Table of Contents 57 1 Introduction.....................................................5 59 2 Terminology......................................................5 61 3 Model Extensions.................................................6 62 3.1 client-print-support-files-supported (1setOf octetString(MAX)).6 63 3.1.1 Use of Keyword Values in fields.............................11 64 3.1.2 Use of the Special Keyword Value: 'unknown'.................11 65 3.1.3 Examples of "client-print-support-files-supported" attribute 66 values.................................................11 67 3.2 Get-Printer-Attributes Operation Extension....................12 68 3.2.1 Get-Printer-Attributes Request..............................12 69 3.2.1.1 client-print-support-files-filter (octetString(MAX)) 70 operation attribute..................................12 71 3.2.1.1.1 Filter matching rules...................................14 72 3.2.2 Get-Printer-Attributes Response.............................15 73 3.3 Get-Client-Print-Support-Files................................17 74 3.3.1 Get-Client-Print-Support-Files Request......................17 75 3.3.2 Get-Client-Print-Support-Files Response.....................18 77 4 New Values for Existing Printer Description Attributes..........19 79 5 Conformance.....................................................19 80 5.1 Printer Conformance Requirements..............................19 81 5.2 Client Conformance Requirements...............................20 83 6 Encoding of the Operation Layer.................................20 85 7 IANA Considerations.............................................20 86 7.1 Attribute Registrations.......................................21 87 7.2 Additional Attribute Value Registrationsfor existing attributes21 88 7.2.1 Additional values for the "client-print-support-files-xxx" 89 attributes.............................................21 90 7.2.2 Additional values for the "operations-supported" Printer 91 attribute..............................................23 92 7.3 Operation Registrations.......................................23 93 7.4 Status Code Registrations.....................................23 95 8 Internationalization Considerations.............................24 97 9 Security Considerations.........................................24 99 10 Status Code Extensions.........................................25 100 10.1 client-error-client-print-support-file-not-found (0x0417)....25 101 11 References.....................................................25 103 12 Author's Addresses.............................................27 105 13 Description of the Base IPP Documents..........................28 107 14 Full Copyright Statement.......................................29 109 Tables 111 Table 1 - "client-print-support-files-supported" attribute fields..8 112 Table 2 - "client-print-support-files-filter" attribute fields....13 113 Table 3 - REQUIRED "client-print-support-files-filter" fields.....14 114 Table 4 - Operation-id assignments................................19 116 1 Introduction 118 This IPP notification specification is an OPTIONAL extension to 119 Internet Printing Protocol/1.0 (IPP) [RFC2566, RFC2565] and IPP/1.1 120 [RFC2911, RFC2910]. See section 13 for a brief description of the 121 IPP base documents. 123 A common configuration for printing from a workstation requires that 124 some Client Print Support Files (e.g., PPD, printer driver files) 125 specific to the target printer be installed on that workstation. 126 Selection and configuration of the appropriate Client Print Support 127 Files can be simplified and even automated if the workstation can 128 obtain some key information about the printer and which sets of 129 Client Print Support Files are available. Such key information 130 includes: operating system type, CPU type, document-format (PDL), 131 natural language, compression mechanism, file type, client file name, 132 policy for automatic loading, file size, file version, file date and 133 time, file information description, and digital signature. 135 The OPTIONAL IPP extension defined in this document provides a simple 136 and reliable vehicle for printers to convey this information to 137 interested workstations. This extension enables a flexible solution 138 for installing Client Print Support Files on workstations running 139 different operating systems and for printers of all makes and models. 140 It allows Client Print Support Files to be downloaded from 141 repositories of different sorts. A possible repository for the files 142 is the printer itself. The extensions necessary for getting Client 143 Print Support Files from the printer are included in this document, 144 including security for downloading executable code and data. 146 2 Terminology 148 This section defines the following terms that are used throughout 149 this document: 151 This document uses the same terminology as [RFC2911], such as 152 "attribute", "attribute value", "keyword", "operation", "request", 153 "response", and "support". In addition, the following terms are 154 defined for use in this document and the Delivery Method Documents: 156 Client Print Support Files - a set of files, such as a printer 157 driver, font metric file, printer configuration file (PPD, GPD, etc.) 158 that support a client printing to a particular Printer. A Printer 159 MAY have multiple sets of Client Print Support Files that work for 160 different operating systems, document formats, natural languages, 161 CPUs, etc. 163 This document uses the same terminology as [RFC2911], such as 164 "client", "Printer", "attribute", "attribute value", "keyword", 165 "operation", "request", "response", and "support". This document 166 also uses the terms "IPP Printer", "Printer" and "Printer object" 167 interchangeably as in [RFC2911] to mean the software entity that 168 accepts IPP operation requests and returns IPP operation responses 169 (see [RFC2911] section 2). 171 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, 172 SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have special meaning 173 relating to conformance as define in RFC 2119 [RFC2119] and 174 [RFC2911] section 12.1. If an implementation supports the 175 extension defined in this document, then these terms apply; 176 otherwise, they do not. These terms define conformance to this 177 document only; they do not affect conformance to other 178 documents, unless explicitly stated otherwise. 180 3 Model Extensions 182 To assist workstations in the printer installation process, an IPP 183 printer needs to provide the workstation with information about the 184 Client Print Support Files, such as the their name and location/s. 185 This information needs to match the workstation's specific 186 environment, such as its operating system, preferred natural 187 language, and preferred document format. 189 The following extensions to the IPP model enable assisted or 190 automated printer installation. This section describes each 191 extension in detail. 193 - A new REQUIRED Printer Description attribute: "client-print- 194 support-files-supported" (1setOf octetString(MAX)). 195 - A new REQUIRED Get-Printer-Attributes operation attribute: 196 "client-print-support-files-filter" (octetString(MAX)). 197 - A new RECOMMENDED printer operation: Get-Client-Print-Support- 198 Files. 200 3.1 client-print-support-files-supported (1setOf octetString(MAX)) 202 An IPP Printer uses the REQUIRED Printer Description attribute 203 "client-print-support-files-supported" to represent relevant 204 information about all of the Client Print Support Files it supports. 205 Each value is a composite UTF-8 string with well-defined fields (see 206 Table 1). Each value string MUST be formatted as follows: 208 "uri=val1< field-name2=val21,...,val2p< ... < field- 209 namen=valn1,...,valnq<" 211 The first field MUST be the "uri" field. The remaining fields MAY be 212 in any order. 214 The string MUST NOT include any control characters (hex 00 to 1F), 215 even the so-called white space control characters (TAB, CR, and LF) 216 anywhere. Only zero or more UTF-8 SPACE characters (hex 20) can be 217 included and they can be included only IMMEDIATELY AFTER the 218 delimiter character: "<", but NOT anywhere else, including after "=" 219 and ",". However, if the UTF-8 SPACE character is needed in a 220 client-file-name value, then each occurrence is included directly, 221 without escaping (see example). On the other hand, if the UTF-8 222 SPACE character is needed in a URL value, then each occurrence is 223 escaped as: "%20" (URI conventions - see [RFC2396]). 225 Table 1 lists the REQUIRED fields that a Printer MUST support and the 226 OPTIONAL fields that a Printer MAY support in the "client-print- 227 support-files-supported" (1setOf octetString(MAX)) Printer 228 Description attribute. A Printer implementation MAY support 229 additional fields using the same syntax. Values are defined to be 230 either CASE-SENSITIVE or ALL-LOWER-CASE according to the definitions 231 for the attribute syntaxes from [RFC2911] (set off by single quotes 232 in the table). The CASE-SENSITIVE values MAY have upper and lower 233 case letters as for the corresponding attribute syntaxes in 234 [RFC2911]. The LOWER-CASE values MUST have all lower case alphabetic 235 letters. Additional characters, such as digits, hyphen-minus (-), 236 period (.), and slash (/) are according to the corresponding 237 attribute syntaxes in [RFC2911]. Additional values for these fields 238 can be registered with IANA according to the procedures in [RFC2911] 239 for registering additional values of attributes. Additional fields 240 can be registered with IANA according to the procedures defined in 241 [RFC2911] for registering attributes. See section 7. 243 Clients SHOULD ignore fields they don't recognize in a given value. 244 This allows for future extensions to the format of the string without 245 breaking compatibility with earlier clients. 247 Table 1 - "client-print-support-files-supported" attribute fields 249 Field 250 name Field value 252 "uri" One REQUIRED CASE-SENSITIVE 'uri' string identifying the 253 uri where to obtain the support files for each OS 254 platform, document format, and natural language the 255 printer supports. This MUST be the first field in each 256 value. Examples of uri schemes that MAY be found here 257 are 'ftp', 'http', and 'ipp'. The 'ftp' and 'http' 258 schemed URIs identify the archive file that contains all 259 the necessary client support files. 261 The 'ipp' schemed URIs identify the archive file that 262 clients MAY obtain from the Printer using the Get- 263 Client-Print-Support-Files operation (see section 3.3). 264 The URI MUST be a valid URI to the same Printer object, 265 i.e., one of the values of the Printer's "printer-uri- 266 supported" attribute. The 'ipp' URI is used to 267 distinguish between multiple Client Print Support Files 268 in an implementation dependent manner using the URL 269 query syntax (e.g., "?drv-id=xxx") [RFC2396]. The 270 query part MUST NOT exceed 127 octets, not counting the 271 "?" character that begins the query part. A Printer 272 SHOULD support the 'ipp' scheme. 274 "os-type" One or more REQUIRED comma-separated LOWER-CASE 275 'keyword' strings identifying the operating system types 276 supported by this set of Client Print Support Files. 277 Valid values are the operating system names defined in 278 the IANA document [os-names] and the special keyword 279 value: 'unknown'. Although the IANA registry requires 280 that the names be all upper-case, the values MUST be all 281 lower case in this field (plus hyphen-minus (-), period 282 (.), and slash (/)). Examples: 'linux', 'linux-2.2', 283 'os/2', 'sun-os-4.0', 'unix', 'unix-bsd', 'win32', 284 'windows-95', 'windows-98', 'windows-ce', 'windows-nt', 285 'windows-nt-4', 'windows-nt-5', 'unknown'. 287 "cpu- One or more REQUIRED comma-separated LOWER-CASE 288 type" 'keyword' strings identifying the CPU types supported by 289 this set of Client Print Support Files. The values 290 indicate the CPU family independent of the CPU 291 manufacturer. Standard keyword values are: 'x86-16', 292 'x86-32', 'x86-64', 'dec-vax', 'alpha', 'power-pc', 'm- 294 Field Field value 295 name 297 'x86-32', 'x86-64', 'dec-vax', 'alpha', 'power-pc', 'm- 298 68000, 'sparc', 'itantium', 'mips', 'arm' and will be 299 used as the initial value for the "cpu-type" IANA 300 registry. In addition, the special keyword value: 301 'unknown' is valid. 303 "document One or more REQUIRED comma-separated CASE-SENSITIVE 304 -format" 'mimeMediaType' strings identifying the document formats 305 supported by this set of Client Print Support Files. 306 Valid values are the string representation of the IPP 307 mimeMediaType attribute syntax (see [RFC2911] section 308 4.1.9), for example 'application/postscript'. In 309 addition, the special keyword value: 'unknown' is valid. 311 "natural- One or more REQUIRED comma-separated LOWER-CASE 312 language" 'naturalLanguage' strings identifying the natural 313 language used by this set of Client Print Support Files. 314 Valid values are the string representation of the IPP 315 'naturalLanguage' attribute syntax (see [RFC2911] 316 section 4.1.8), for example 'en' and 'en-us'. In 317 addition, the special keyword value: 'unknown' is valid. 319 "compress One REQUIRED LOWER-CASE 'keyword' string identifying the 320 ion" mechanism used to compress this set of Client Print 321 Support Files. All files needed for the installation of 322 a printer driver MUST be compressed into a single file. 323 Valid keyword values are the keywords defined by 324 [RFC2911] or registered with IANA for use in the IPP 325 "compression" and "compression-supported" attributes. 326 See [RFC2911] section 4.4.32), for example 'gzip'. The 327 'none' value limits the uncompressed Client Print 328 Support File to a single file. The values for the 329 "compression" field that a Printer supports NEED NOT be 330 the same values that the Printer is configured to 331 support in Job Creation operations as indicated in the 332 Printer's "compressions-supported" attribute. 334 "file- One or more REQUIRED comma-separated LOWER-CASE 335 type" 'keyword' strings identifying the type of the Client 336 Print Support Files. Standard keyword values are: 337 'printer-driver', 'ppd', 'updf', 'gpd'. 339 Field Field value 340 name 342 "client- One REQUIRED CASE-SENSITIVE string identifying the name 343 file- by which the Client Print Support Files will be 344 name" installed on the workstation. For Client Print Support 345 Files of type 'printer-driver', this is also the name 346 that identifies this printer driver in an .inf file. 348 "policy" One OPTIONAL LOWER-CASE 'keyword' string indicating the 349 policy for automatic loading. Standard keyword values 350 are: 'manufacturer-recommended', 'administrator- 351 recommended', 'manufacturer-experimental, 352 'administrator-experimental'. The experimental values 353 are for beta test. 355 "file- One OPTIONAL file size in octets represented as ASCII 356 size" decimal digits. 358 "file- One OPTIONAL LOWER-CASE version number. Recommended to 359 version" be of the form "Major.minor[.revision]" where "Major" is 360 the major version number, "minor" is the minor version 361 number and "revision" is an optional revision number. 363 "file- One OPTIONAL File CASE-SENSITIVE creation date and time 364 date- according to ISO 8601 where all fields are fixed length 365 time" with leading zeroes (see [RFC2518] Appendix 2). 366 Examples: 2000-01-01T23:09:05Z and 2000-01-01T02:59:59- 367 04.00 369 "file- One OPTIONAL CASE-SENSITIVE human readable 'text' string 370 info" describing this set of Client Print Support Files. The 371 natural language for this value MUST be the natural 372 language indicated by the Printer's "natural-language- 373 configured" attribute. To avoid exceeding the maximum 374 limit imposed on IPP attributes and to increase 375 interoperability with other systems, the length of this 376 field value MUST not exceed 127 characters. 378 "digital- One REQUIRED LOWER-CASE 'keyword' string identifying the 379 signature mechanism used to ensure the integrity and authenticity 380 " of this set of Client Print Support Files. Standard 381 values are: 'smime', 'pgp', 'dss', and 'xmldsig' which 382 are defined in [RFC2634], [RFC1991], [dss], and 383 [xmldsig], respectively. In addition, the special 384 keyword value: 'none' is valid. 386 Field Field value 387 name 389 keyword value: 'none' is valid. 391 Each value MUST refer to one and only one set of Client Print Support 392 Files, even if the files are downloadable from various repositories 393 (i.e., even if they are associated with multiple URIs). 395 3.1.1 Use of Keyword Values in fields 397 A number of the fields in Table 1 use keyword strings as values. The 398 syntax of these keywords is the same as in [RFC2911], including the 399 use of private keywords. See [RFC2911] sections 4.1.3 and 6.1. 400 Printer implementers are strongly RECOMMENDED to submit additional 401 keyword values for registration with IANA according to the procedures 402 for registering attributes. See section 7 and [RFC2911] section 6.1. 404 3.1.2 Use of the Special Keyword Value: 'unknown' 406 A number of REQUIRED 'keyword' value fields have a special keyword 407 value: 'unknown' defined. This value is intended for use when the 408 actual value is not known, such as by an administrator automatic 409 software configuring the IPP Printer object. However, it is strongly 410 RECOMMENDED that other more meaningful values be used, instead of the 411 'unknown' value whenever possible. 413 3.1.3 Examples of "client-print-support-files-supported" attribute 414 values 416 The following illustrates what two valid values of the "client-print- 417 support-files-supported" (1setOf octetString(MAX)) Printer 418 Description attribute might look like: 420 uri=ipp://mycompany.com/myprinter?drv-id=ModelY.gz< 421 os-type=windows-95< cpu-type=x86-32< 422 document-format=application/postscript< 423 natural-language=en< compression=gzip< 424 file-type=printer-driver< 425 client-file-name=CompanyX-ModelY-driver.gz< 426 policy=manufacturer-recommended< 427 uri=ftp://mycompany.com/root/drivers/win95/CompanyX/ModelY.gz< 428 os-type=windows-95< cpu-type=x86-32< 429 document-format=application/postscript,application/vnd.hp-PCL< 430 natural-language=en,fr< compression=gzip< 431 file-type=printer-driver< 432 client-file-name=Company T Model Z driver.gz< 433 policy=manufacturer-recommended< 435 The above examples have been broken onto separate lines for 436 readability in this document. However, there MUST NOT be any line 437 breaks in the actual values. 439 The "client-print-support-files-supported" Printer Description 440 attribute MAY be preset at manufacturing time or through 441 administrative means outside the scope of this document. 443 3.2 Get-Printer-Attributes Operation Extension 445 The "client-print-support-files-supported" Printer Description 446 attribute defined in section 3.1 contains information, such as 447 operating system, natural language, and document format, about all of 448 the sets of Client Print Support Files. This section defines an 449 extension to the Get-Printer-Attributes operation that allows a 450 workstation to filter out all but the Client Print Support Files of 451 interest. 453 3.2.1 Get-Printer-Attributes Request 455 A Printer MAY contain information about multiple sets of Client Print 456 Support Files to match the different operating systems, natural 457 languages and document formats it supports. A workstation MAY query 458 this information by including the 'client-print-support-files- 459 supported' keyword as a value of the "requested-attributes" operation 460 attribute of the Get-Printer-Attributes operation. 462 3.2.1.1 client-print-support-files-filter (octetString(MAX)) operation 463 attribute 465 The client can request a subset of the values of the "client-print- 466 support-files-supported" Printer attribute by supplying the "client- 467 print-support-files-filter" (octetString(MAX)) operation attribute in 468 the request as a filter. The filter value indicates in which Client 469 Print Support Files the client is interested. The client MAY supply 470 this attribute. The Printer MUST support this attribute. 472 The filter value of the "client-print-support-files-filter" attribute 473 is a composite string with the same format as that of "client-print- 474 support-files-supported" (see Table 1 - "client-print-support-files- 475 supported" attribute fields in section 3.1) with the following 476 exceptions: 478 Table 2 - "client-print-support-files-filter" attribute fields 480 Field Field Value in the "client-print-support-files-filter" 481 Name attribute 483 uri- One or more comma-separated LOWER-CASE 'uriScheme' 484 scheme string values identifying the uri scheme to be 485 filtered on. Valid values are the string 486 representation of the IPP 'uriScheme' attribute syntax 487 (see [RFC2911] section 4.1.6). Example URI schemes 488 are: 'ftp', 'http', and 'ipp'. The Printer SHOULD 489 support the 'ipp' scheme. If supplied by the client, 490 this field NEED NOT be first. If this field is 491 omitted by the client, the Printer returns all 492 schemes. 494 xxx One or more comma-separated values for any of the 495 fields defined in Table 1, with the single exception 496 of the "uri" field which a client MUST NOT supply and 497 a Printer MUST NOT support. 498 The Printer MUST support any filter field having more 499 than one value separated by a COMMA (,), including the 500 fields that Table 1 indicates MUST BE single valued. 502 Printer implementations MUST support the "client-print-support-files- 503 filter" operation attribute in a Get-Printer-Attributes request with 504 the member fields listed Table 3. Printers MAY support any 505 additional filter fields listed in Table 2. 507 Client implementations MAY supply any filter fields listed in Table 2 508 in the "client-print-support-files-filter" operation attribute of a 509 Get-Printer-Attributes request. 511 Table 3 - REQUIRED "client-print-support-files-filter" fields 513 uri-scheme 515 os-type 517 cpu-type 519 document-format 521 natural-language 523 3.2.1.1.1 Filter matching rules 525 The Printer returns only the values of the "client-print-support- 526 files-supported" Printer Description attribute that match the filter 527 in the "client-print-support-files-filter" operation attribute. The 528 following filter matching rules are defined: 530 1. A match occurs if at least one value of each field supplied by 531 the client in the filter matches a Client Print Support File 532 value. Printers MUST ignore a filter field supplied by a client 533 that the Printer does not support and return a match if all 534 supported fields do match, no matter what value the client 535 supplied for that unsupported field. Similarly, Printers MUST 536 ignore a filter field supplied by a client that the Printer does 537 support, but which the field has not been populated for a Client 538 Print Support Files and return a match if all supported and 539 populated fields do match, no matter what value the client 540 supplied for that unpopulated field. 542 2. A match for a CASE-INSENSITIVE field occurs independent of the 543 case of the letters supplied by the client and those stored by 544 the Printer, while a match for a LOWER-CASE field is a strict 545 character for character match. 547 3. A match for a 'keyword' Printer field that is populated with the 548 'unknown' special keyword value occurs for any value supplied by 549 the client for that field. 551 4. If the "client-print-support-files-filter" operation attribute 552 filter is not supplied by the client, the printer SHOULD behave 553 as if the attribute had been provided with all fields left empty 554 (i.e., return an unfiltered list). 556 The following are two examples of a "client-print-support-files- 557 filter" filter value: 559 os-type=windows-95< cpu-type=x86-32< 560 document-format=application-postscript< natural-language=en,de< 562 uri-scheme=ipp< os-type=windows-95< cpu-type=x86-32< 563 document-format=application-postscript< natural-language=en,de< 565 See section 3.2.2 for example matching responses. 567 It is RECOMMENDED that workstations first use the Get-Printer- 568 Attributes operation in combination with "client-print-support-files- 569 filter" operation attribute filter to get a list of the potential 570 Client Print Support Files that meet the workstation's requirements. 571 The workstation can then choose from the returned list which Client 572 Print Support Files to use and where to get them. If one of the URIs 573 returned is an IPP uri, the workstation can retrieve the Client Print 574 Support Files from an IPP printer via the Get-Client-Print-Support- 575 Files operation (see section 3.3). 577 3.2.2 Get-Printer-Attributes Response 579 A Printer MUST return the "client-print-support-files-supported" 580 (1setOf octetString(MAX)) attribute in the Printer Object Attributes 581 group (Group 3) when requested by a client, unless there are no 582 matches, in which case the attribute is not returned in Group 3. 583 Each returned attribute value MUST satisfy the criteria specified by 584 the client in the request. 586 For example, if the request contains the following "client-print- 587 support-files-filter" filter: 589 os-type=windows-95< cpu-type=x86-32< 590 document-format=application-postscript< 591 natural-language=en,de< 593 A conforming response is the following two octet String values: 595 uri=ipp://mycompany.com/myprinter?drv-id=ModelY.gz< 596 os-type=windows-95< cpu-type=x86-32< 597 document-format=application/postscript< 598 natural-language=en< compression=gzip< 599 file-type=printer-driver< 600 client-file-name=CompanyX-ModelY-driver.gz< 601 policy=manufacturer-recommended< 602 digital-signature=smime< 604 uri=ftp://mycompany.com/root/drivers/win95/CompanyX/ModelY.gz< 605 os-type=windows-95< cpu-type=x86-32< 606 document-format=application/postscript,application/vnd.hp-PCL< 607 natural-language=en,fr< compression=gzip< 608 file-type=printer-driver< 609 client-file-name=CompanyX-ModelY-driver.gz< 610 policy=manufacturer-recommended< 611 digital-signature=smime< 613 These examples have been broken onto separate lines for readability 614 in this document. However, there MUST NOT be any line breaks in the 615 actual values. 617 As another example, if the above request had also contained the "uri- 618 scheme" field in the following "client-print-support-files-filter" 619 filter: 621 uri-scheme=ipp< os-type=windows-95< cpu-type=x86-32< 622 document-format=application-postscript< 623 natural-language=en,de< 625 Then only the first value would have been returned as a single 626 octetString value: 628 uri=ipp://mycompany.com/myprinter?drv-id=ModelY.gz< 629 os-type=windows-95< cpu-type=x86-32< 630 document-format=application/postscript< 631 natural-language=en< compression=gzip< 632 file-type=printer-driver< 633 client-file-name=CompanyX-ModelY-driver.gz< 634 policy=manufacturer-recommended< 635 digital-signature=smime< 637 3.3 Get-Client-Print-Support-Files 639 This RECOMMENDED operation allows a client to download Client Print 640 Support Files from an IPP Printer. 642 3.3.1 Get-Client-Print-Support-Files Request 644 The following sets of attributes are part of the Get-Client-Print- 645 Support-Files request: 647 Group 1: Operation Attributes 649 Natural Language and Character Set: 650 The "attributes-charset" and "attributes-natural-language" 651 attributes as described in [RFC2911], section 3.1.4.1. 653 Target: 654 The "printer-uri" (uri) operation attribute which is the target 655 for this operation as described in [RFC2911], section 3.1.5. 656 The client MUST use the URI value as the target of this 657 operation that the Printer returns in the "uri" field (see Table 658 1) in the Get-Printer-Attributes response. Furthermore, the 659 client MUST use the appropriate authorization and security 660 mechanism for this URI as indicated by the Printer's "printer- 661 uri-supported", "uri-authentication-supported" and "uri- 662 security-supported" attributes (see [RFC2911] sections 4.4.1, 663 4.4.2, and 4.4.3). Only if the URI returned in the "uri" field 664 matches the URI that the client used for the Get-Printer- 665 Attributes request MAY the client use the same HTTP connection. 666 The 'ipp' URL matching rules are defined in [ipp-url] and do not 667 include the query part. 669 Requesting User Name: 670 The "requesting-user-name" (name(MAX)) attribute SHOULD be 671 supplied by the client as described in [RFC2911], section 8.3. 673 "client-print-support-files-query" (text(127)): 674 The client MUST supply this attribute specifying the query part 675 [RFC2396] of the ipp uri for the desired Client Print Support 676 Files not including the "?" character that starts the query 677 part, i.e., the value of the "uri" field following the "?" 678 character returned by the Get-Printer-Attributes in one of the 679 values of the "client-print-support-files-supported" (1setOf 680 octetString(MAX)) Printer attribute (see Table 1) that had an 681 'ipp' scheme. If the Printer does not find any Client Print 682 Support Files which match the query, the Printer MUST reject 683 this request with a 'client-error-client-print-support-file-not- 684 found' status code (see section 10.1). 686 3.3.2 Get-Client-Print-Support-Files Response 688 The Printer object returns the following sets of attributes as part 689 of the Get-Client-Print-Support-Files Response: 691 Group 1: Operation Attributes 693 Status Message: 694 In addition to the REQUIRED status code returned in every 695 response, the response OPTIONALLY includes a "status-message" 696 (text(255)) operation attribute as described in [RFC2911], 697 sections 13 and 3.1.6. 699 Natural Language and Character Set: 700 The "attributes-charset" and "attributes-natural-language" 701 attributes as described in [RFC2911], section 3.1.4.2. 703 Group 2: Unsupported Attributes 704 See [RFC2911], section 3.1.7 for details on returning Unsupported 705 Attributes. 707 Group 3: Printer Object Attributes 708 "client-print-support-files-supported" (octetString(MAX)). 709 This attribute identifies the properties of the returned Client 710 Print Support Files. The Printer object MUST return this 711 attribute if the response includes Group 4 (i.e., if a set of 712 Client Print Support Files identified by the supplied "client- 713 print-support-files-query" operation attribute was found). The 714 Printer MUST return all configured fields for the selected 715 Client Print Support Files in the format shown in section 3.1. 717 Group 4: Client Print Support Files 718 The printer MUST supply the Client Print Support Files that match 719 the client's criteria following the "end-of-attributes" tag, same 720 as for the Print-Job request. All necessary files MUST be 721 compressed into a single transferred file. 723 4 New Values for Existing Printer Description Attributes 725 The following "operation-id" value is added in order to support the 726 new operation defined in this document: 728 Table 4 - Operation-id assignments 730 Value Operation Name 732 0x0021 Get-Client-Print-Support-Files 734 5 Conformance 736 5.1 Printer Conformance Requirements 738 A Printer conforming to this specification: 740 1.MUST support the "client-print-support-files-supported" Printer 741 Description attribute as defined in section 3.1, including all 742 of the REQUIRED fields defined in Table 1 and MAY support the 743 OPTIONAL fields defined in Table 1. 745 2.MUST support the "client-print-support-files-filter" operation 746 attribute in the Get-Printer-Attributes request as defined in 747 section 3.2, including all of the fields listed in Table 3 and 748 ignoring any fields not recognized. 750 3.MUST support at least one of the following URI schemes that 751 identify the support files: 'ftp', 'http', or 'ipp', of which 752 the 'ipp' scheme is the RECOMMENDED one. 754 4.SHOULD support the Get-Client-Print-Support-Files operation as 755 described in section 3.3. If this operation is supported, then 756 one of the supported schemes MUST be 'ipp'. 758 5.SHOULD support TLS as described in section 9. 760 6.SHOULD support at least one method for the downloading of Client 761 Print Support Files that have been digitally signed as described 762 in section 9. 764 5.2 Client Conformance Requirements 766 A client conforming to this specification: 768 1.MUST ignore any fields returned by the Printer in the "client- 769 print-support-files-supported" Printer Description attribute 770 that the client does not recognize or support. 772 2.SHOULD be able to retrieve Client Print Support Files by either 773 FTP Get or HTTP Get operations. 775 3.MUST be able to retrieve Client Print Support Files using the 776 Get-Client-Print-Support-Files operation, i.e., support the 777 'ipp' scheme. 779 4.MUST supply the proper URI value for the "printer-uri" operation 780 attribute as specified in section 3.3.1 under Target:. 782 5.MUST validate that files that are supposed to be digitally 783 signed are done with the indicated mechanism as described in 784 section 9. 786 6.SHOULD support TLS as described in section 9. 788 6 Encoding of the Operation Layer 790 This extension uses the operation layer encoding described in 791 [RFC2910]. 793 7 IANA Considerations 795 The IANA-registered operating system names that IANA has registered 796 [os-names] are required by this spec for use in the "os-type" field 797 (see Table 1). 799 Table 1 of this document defines possible 'keyword' values for the 800 "cpu-type" field. However, the existing IANA machine registration 801 [cpu-names] is inadequate for two reasons: a) it is really a machine 802 model number, not a CPU type, and b) it doesn't express whether a 803 CPU is 16-bit, 32-bit, or 64-bit which needs to be indicated in the 804 keyword value. Therefore, the "os-type" field will be a new 805 registration with initial values assigned. 807 Implementers may register additional values for the fields defined in 808 Table 1 with IANA according to the procedures in [RFC2911] for 809 registering additional values of attributes. Implementers may 810 register additional fields with IANA according to the procedures 811 defined in [RFC2911] for registering attribute values, even though 812 fields are more like attributes (see section 7.2.1). 814 The rest of this section contains the registration information for 815 IANA to add to the various IPP Registries according to the procedures 816 defined in RFC 2911 [RFC2911] section 6 to cover the definitions in 817 this document. 819 Note to RFC Editors: Replace RFC NNNN below with the RFC number 820 for this document, so that it accurately reflects the content of 821 the information for the IANA Registry. 823 7.1 Attribute Registrations 825 The following table lists all attributes and fields defined in this 826 document. These are to be registered according to the procedures in 827 RFC 2911 [RFC2911] section 6.2. 829 Printer Description Attributes: Ref: Section: 830 client-print-support-files-supported (1setOf octetString(MAX)) 831 RFC NNNN 3.1 833 Operation Attributes: Ref: Section: 834 client-print-support-files-filter (octetString(MAX)) RFC NNNN 3.2 836 The resulting attribute registrations will be published in the 837 ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attributes/ 838 area. 840 7.2 Additional Attribute Value Registrationsfor existing attributes 842 This section lists additional attribute value registrations for use 843 with existing attributes defined in other documents. 845 7.2.1 Additional values for the "client-print-support-files-xxx" 846 attributes 848 The following table lists the fields defined in this document for use 849 with the "client-print-support-files-supported" Printer Description 850 (defined in section ) attribute and the "client-print-support-files- 851 filter" operation attribute (defined in section ). For purposes of 852 IANA registration, the following fields are registered according to 853 the attribute value procedures in RFC 2911 [RFC2911] section 6.1, 854 even though they are more like attributes and have an attribute 855 syntax and string values. 857 field Attribute Values: Ref: Section: 858 os-type (type2 keyword) RFC NNNN 3.1 859 cpu-type (type2 keyword) RFC NNNN 3.1 860 document-format (mimeMediaType) RFC NNNN 3.1 861 natural-language (naturalLanguage) RFC NNNN 3.1 862 compression (type2 keyword) RFC NNNN 3.1 863 file-type (type2 keyword) RFC NNNN 3.1 864 client-file-name (name(MAX)) RFC NNNN 3.1 865 policy (type2 keyword) RFC NNNN 3.1 866 file-size (integer(0:MAX)) RFC NNNN 3.1 867 file-version (name(MAX)) RFC NNNN 3.1 868 file-date-time (text(25)) RFC NNNN 3.1 869 file-info (text(127)) RFC NNNN 3.1 870 digital-signature (type2 keyword) RFC NNNN 3.1 872 The resulting URI scheme attribute value registration will be 873 published in the 874 ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attribute- 876 values/client-print-support-files-supported/ 877 AND 879 ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attribute- 881 values/client-print-support-files-filter/ 882 areas. 884 uri (uri) RFC NNNN 3.1 886 The resulting URI scheme attribute value registration will be 887 published in the 888 ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attribute- 890 values/client-print-support-files-supported/ 891 area. 893 uri-scheme (uriScheme) RFC NNNN 3.2 894 The resulting URI scheme attribute value registration will be 895 published in the 896 ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attribute- 898 values/client-print-support-files-filter/ 899 area. 901 7.2.2 Additional values for the "operations-supported" Printer attribute 903 The following table lists the enum attribute value defined in this 904 document as an additional type2 enum value for use with the 905 "operations-supported" Printer attribute defined in [RFC2911]. This 906 is to be registered according to the procedures in RFC 2911 [RFC2911] 907 section 6.1. 909 type2 enum Attribute Values: Value Ref. Section: 910 Get-Clint-Print-Support-Files 0x0021 RFC NNNN 4 912 The resulting enum attribute value registration will be published in 913 the 914 ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attribute- 915 values/operations-supported/ 916 area. 918 7.3 Operation Registrations 920 The following table lists the operation defined in this document. 921 This is to be registered according to the procedures in RFC 2911 922 [RFC2911] section 6.4. 924 Operations: Ref. Section: 925 Get-Client-Print-Support-Files RFC NNNN 3.3 927 The resulting operation registration will be published in the 928 ftp://ftp.iana.org/in-notes/iana/assignments/ipp/operations/ 929 area. 931 7.4 Status Code Registrations 933 The following table lists the status code defined in this document. 934 This is to be registered according to the procedures in RFC 2911 935 [RFC2911] section 6.6. 937 Status codes: Ref. Section: 938 client-error-client-print-support-file-not-found (0x0417) 939 RFC NNNN 10.1 941 The resulting status code registration will be published in the 942 ftp://ftp.iana.org/in-notes/iana/assignments/ipp/status-codes/ 943 area. 945 8 Internationalization Considerations 947 All text representations introduced by this specification adhere to 948 the internationalization-friendly representation supported by IPP. 949 This work is also accommodates the use of Client Print Support Files 950 of different languages. 952 9 Security Considerations 954 The IPP Model and Semantics document [RFC2911] discusses high-level 955 security requirements (Client Authentication, Server Authentication 956 and Operation Privacy). Client Authentication is the mechanism by 957 which the client proves its identity to the server in a secure 958 manner. Server Authentication is the mechanism by which the server 959 proves its identity to the client in a secure manner. Operation 960 Privacy is defined as a mechanism for protecting operations from 961 eavesdropping. 963 Only operators of a printer SHOULD be allowed to set the "client- 964 print-support-files-supported" attribute and only users of the 965 printer SHOULD be allowed to query that information. 967 The IPP extension described in this document introduces the potential 968 for a security threat previously not encountered by IPP. As Client 969 Print Support Files might exist in the form of executable objects (as 970 is the case with printer drivers, for example), additional provisions 971 are needed to prevent the distribution of malicious code through this 972 mechanism. Digital signatures provide the message level security 973 commonly used to help consumers of network resources verify the 974 authenticity and integrity of those resources. Specifically, digital 975 signatures help defend against security threats such as message 976 insertion, message deletion, and message modification, and their 977 combined use into man-in-the-middle attacks. 979 This document identifies some commonly used signing mechanisms (SMIME 980 [RFC2634], PGP [RFC1991], DSS [dss], and XML Digital Signatures 981 [xmldsig]), though any others MAY be used. Of course, it is assumed 982 that once end-users know the identity of the provider of Client Print 983 Support Files, they can make the correct determination as to whether 984 it is safe to use those files. 986 Printers that support the Get-Client-Print-Support-Files operation 987 SHOULD support the downloading of Client Print Support Files that 988 have been digitally signed. Clients that invoke the Get-Client- 989 Print-Support-Files operation MUST make sure that Client Print 990 Support Files that are supposed to be signed (i.e., whose client- 991 print-support-files-supported attribute value includes the "digital- 992 signature" field) are indeed signed via the specified mechanism when 993 downloaded from the printer. 995 Furthermore, printers that support the Get-Client-Print-Support-Files 996 operation SHOULD implement TLS to provide application level channel 997 security and enable users to reliably authenticate the source of the 998 Client Print Support Files. 1000 10 Status Code Extensions 1002 The following status code is defined as an extension for Notification 1003 and is returned as the value of the "status-code" parameter in the 1004 Operation Attributes Group of a response (see [RFC2911] section 1005 3.1.6.1). 1007 10.1 client-error-client-print-support-file-not-found (0x0417) 1009 The Printer was unable to match the query in the Get-Client-Print- 1010 Support-Files request with any Client Print Support Files. This 1011 status code is not used with the Get-Printer-Attributes operation. 1013 11 References 1015 [cpu-names] 1016 IANA Registry of CPU Names at ftp://ftp.iana.org/in- 1017 notes/iana/assignments/XXX. 1019 [dss] 1020 U.S. Department of Commerce, "Digital Signature Standard (DDS)", 1021 Federal Information Processing Standards Publication 186-1 (FIPS 1022 PUB 186-1), December 15, 1998. 1024 [ipp-url] 1025 Herriot, R., McDonald, I., "Internet Printing Protocol (IPP): IPP 1026 URL Scheme." , April 2, 2001. 1028 [os-names] 1029 IANA Registry of Operating System Names at ftp://ftp.isi.edu/in- 1030 notes/iana/assignments/operating-system-names. 1032 [RFC1991] 1033 D. Atkins, W. Stallings, P. Zimmermann, "PGP Message Exchange 1034 Formats", RFC 1991, August, 1996. 1036 [RFC2026] 1037 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 1038 2026, October 1996. 1040 [RFC2396] 1041 Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource 1042 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 1044 [RFC2518] 1045 Goland, Y., et al, "HTTP Extensions for Distributed Authoring -- 1046 WEBDAV", RFC 2518, February 1999. 1048 [RFC2565] 1049 Herriot, R., Butler, S., Moore, P., and R. Turner, "Internet 1050 Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1051 1999. 1053 [RFC2566] 1054 R. deBry, T. Hastings, R. Herriot, S. Isaacson, and P. Powell, 1055 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, 1056 April 1999. 1058 [RFC2567] 1059 Wright, D., "Design Goals for an Internet Printing Protocol", RFC 1060 2567, April 1999. 1062 [RFC2568] 1063 Zilles, S., "Rationale for the Structure and Model and Protocol for 1064 the Internet Printing Protocol", RFC 2568, April 1999. 1066 [RFC2569] 1067 Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between 1068 LPD and IPP Protocols", RFC 2569, April 1999. 1070 [RFC2616] 1071 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1072 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 1073 RFC 2616, June 1999. 1075 [RFC2634] 1076 P. Hoffman, "Enhanced Security Services for S/MIME", RFC 2634, June 1077 1999. 1079 [RFC2910] 1080 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 1081 Protocol/1.1: Encoding and Transport", RFC 2910, September 2000. 1083 [RFC2911] 1084 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1085 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2911, 1086 September 2000. 1088 [xmldsig] 1089 D. Eastlake, J. Reagle, D. Solo "XML-Signature Syntax and 1090 Processing", , October 31, 2000. 1092 12 Author's Addresses 1094 Hugo Parra 1095 Novell, Inc. 1096 1800 South Novell Place 1097 Provo, UT 84606 1099 Phone: 801-861-3307 1100 Fax: 801-861-4025 1101 e-mail: hparra@novell.com 1103 Ted Tronson 1104 Novell, Inc. 1105 1800 South Novell Place 1106 Provo, UT 84606 1108 Phone: 801-861-3338 1109 Fax: 801-861-4025 1110 e-mail: ttronson@novell.com 1112 Thomas N. Hastings 1113 Xerox Corp. 1114 737 Hawaii St. ESAE 231 1115 El Segundo, CA 90245 1117 Phone: 310-333-6413 1118 Fax: 310-333-5514 1119 e-mail: hastings@cp10.es.xerox.com 1120 IPP Web Page: http://www.pwg.org/ipp/ 1121 IPP Mailing List: ipp@pwg.org 1123 To subscribe to the ipp mailing list, send the following email: 1124 1) send it to majordomo@pwg.org 1125 2) leave the subject line blank 1126 3) put the following two lines in the message 1127 body: 1128 subscribe ipp 1129 end 1131 Implementers of this specification document are encouraged to join 1132 the IPP Mailing List in order to participate in any discussions of 1133 clarification issues and review of registration proposals for 1134 additional attributes and values. In order to reduce spam the 1135 mailing list rejects mail from non-subscribers, so you must subscribe 1136 to the mailing list in order to send a question or comment to the 1137 mailing list. 1139 13 Description of the Base IPP Documents 1141 The base set of IPP documents includes: 1143 Design Goals for an Internet Printing Protocol [RFC2567] 1144 Rationale for the Structure and Model and Protocol for the 1145 Internet Printing Protocol [RFC2568] 1146 Internet Printing Protocol/1.1: Model and Semantics [RFC2911] 1147 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] 1148 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 1149 Mapping between LPD and IPP Protocols [RFC2569] 1151 The "Design Goals for an Internet Printing Protocol" document takes a 1152 broad look at distributed printing functionality, and it enumerates 1153 real-life scenarios that help to clarify the features that need to be 1154 included in a printing protocol for the Internet. It identifies 1155 requirements for three types of users: end users, operators, and 1156 administrators. It calls out a subset of end user requirements that 1157 are satisfied in IPP/1.0 [RFC2566, RFC2565]. A few OPTIONAL operator 1158 operations have been added to IPP/1.1 [RFC2911, RFC2910]. 1160 The "Rationale for the Structure and Model and Protocol for the 1161 Internet Printing Protocol" document describes IPP from a high level 1162 view, defines a roadmap for the various documents that form the suite 1163 of IPP specification documents, and gives background and rationale 1164 for the IETF working group's major decisions. 1166 The "Internet Printing Protocol/1.1: Encoding and Transport" document 1167 is a formal mapping of the abstract operations and attributes defined 1168 in the model document onto HTTP/1.1 [RFC2616]. It defines the 1169 encoding rules for a new Internet MIME media type called 1170 "application/ipp". This document also defines the rules for 1171 transporting a message body over HTTP whose Content-Type is 1172 "application/ipp". This document defines the 'ipp' scheme for 1173 identifying IPP printers and jobs. 1175 The "Internet Printing Protocol/1.1: Implementer's Guide" document 1176 gives insight and advice to implementers of IPP clients and IPP 1177 objects. It is intended to help them understand IPP/1.1 and some of 1178 the considerations that may assist them in the design of their client 1179 and/or IPP object implementations. For example, a typical order of 1180 processing requests is given, including error checking. Motivation 1181 for some of the specification decisions is also included. 1183 The "Mapping between LPD and IPP Protocols" document gives some 1184 advice to implementers of gateways between IPP and LPD (Line Printer 1185 Daemon) implementations. 1187 14 Full Copyright Statement 1189 Copyright (C) The Internet Society (2001). All Rights Reserved. 1191 This document and translations of it may be copied and furnished to 1192 others, and derivative works that comment on or otherwise explain it 1193 or assist in its implementation may be prepared, copied, published 1194 and distributed, in whole or in part, without restriction of any 1195 kind, provided that the above copyright notice and this paragraph are 1196 included on all such copies and derivative works. However, this 1197 document itself may not be modified in any way, such as by removing 1198 the copyright notice or references to the Internet Society or other 1199 Internet organizations, except as needed for the purpose of 1200 developing Internet standards in which case the procedures for 1201 copyrights defined in the Internet Standards process must be 1202 followed, or as required to translate it into languages other than 1203 English. 1205 The limited permissions granted above are perpetual and will not be 1206 revoked by the Internet Society or its successors or assigns. 1208 This document and the information contained herein is provided on an 1209 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1210 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1211 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1212 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1213 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1215 Acknowledgement 1217 Funding for the RFC Editor function is currently provided by the 1218 Internet Society. 1220 Trade Marks 1222 Trademarks within this document are the property of their owners.