idnits 2.17.1 draft-ietf-ipp-rat-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 204: '...Printer object SHALL generate both a J...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 75 has weird spacing: '...Mapping betwe...' == Line 319 has weird spacing: '...g a new defau...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'IPP-LPD' is mentioned on line 49, but not defined == Unused Reference: 'IPP LPD' is defined on line 390, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1759 (Obsoleted by RFC 3805) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) == Outdated reference: A later version (-05) exists of draft-ietf-ipp-lpd-ipp-map-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-ipp-lpd-ipp-map (ref. 'IPP LPD') -- No information found for draft-ietf-ipp-mod - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IPP-MOD' -- No information found for draft-ietf-ipp-pro - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IPP-PRO' == Outdated reference: A later version (-03) exists of draft-ietf-ipp-req-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-ipp-req (ref. 'IPP-REQ') -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10175' == Outdated reference: A later version (-06) exists of draft-ietf-tls-protocol-05 ** Downref: Normative reference to an Historic draft: draft-ietf-tls-protocol (ref. 'TLS-PRO') Summary: 16 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Stephen N. Zilles 3 Adobe Systems Inc. 5 June 30, 1998 Expires: December 30, 1998 7 Rationale for the Structure of the Model and Protocol 8 for the Internet Printing Protocol 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts 20 as reference material or to cite them other than as "work in 21 progress." 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow directories on ftp.is.co.za (Africa), nic.nordu.net Europe), 26 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 ABSTRACT 31 This document is one of a set of documents, which together describe 32 all aspects of a new Internet Printing Protocol (IPP). IPP is an 33 application level protocol that can be used for distributed 34 printing using Internet tools and technologies. The protocol is 35 heavily influenced by the printing model introduced in the Document 36 Printing Application (DPA) [ISO10175] standard. Although DPA 37 specifies both end user and administrative features, IPP version 38 1.0 (IPP/1.0) focuses only on end user functionality. 40 The full set of IPP documents includes: 42 Design Goals for an Internet Printing Protocol [IPP-REQ] 43 (informational) 45 Rationale for the Structure and Model and Protocol for the Internet 46 Printing Protocol (this document) (informational) 47 Internet Printing Protocol/1.0: Model and Semantics [IPP-MOD] 48 Internet Printing Protocol/1.0: Encoding and Transport [IPP-PRO] 49 Mapping between LPD and IPP Protocols [IPP-LPD] (informational) 51 The design goals document, "Design Goals for an Internet Printing 52 Protocol", takes a broad look at distributed printing 53 functionality, and it enumerates real-life scenarios that help to 54 clarify the features that need to be included in a printing 55 protocol for the Internet. It identifies requirements for three 56 types of users: end users, operators, and administrators. The 57 requirements document calls out a subset of end user requirements 58 that are satisfied in IPP/1.0. Operator and administrator 59 requirements are out of scope for version 1.0. This document, 60 "Rationale for the Structure and Model and Protocol for 61 the Internet Printing Protocol", describes IPP from a high level 62 view, defines a road map for the various documents that form the 63 suite of IPP specifications, and gives background and rationale for 64 the IETF working group's major decisions. The document, "Internet 65 Printing Protocol/1.0: Model and Semantics", describes a simplified 66 model with abstract objects, their attributes, and their 67 operations. The model introduces a Printer and a Job. The Job 68 supports multiple documents per Job. The model document also 69 addresses how security, internationalization, and directory issues 70 are addressed. The protocol specification, "Internet Printing 71 Protocol/1.0: Encoding and Transport", is a formal mapping of the 72 abstract operations and attributes defined in the model document 73 onto HTTP/1.1. The protocol specification defines the encoding 74 rules for a new Internet media type called "application/ipp". The 75 "Mapping between LPD and IPP Protocols" gives some advice to 76 implementors of gateways between IPP and LPD (Line Printer Daemon) 77 implementations. 79 1. ARCHITECTURAL OVERVIEW 81 The Internet Printing Protocol (IPP) is an application level 82 protocol that can be used for distributed printing on the Internet. 83 This protocol defines interactions between a client and a server. 84 The protocol allows a client to inquire about capabilities of a 85 printer, to submit print jobs and to inquire about and cancel print 86 jobs. The server for these requests is the Printer; the Printer is 87 an abstraction of a generic document output device and/or a print 88 service provider. Thus, the Printer could be a real printing 89 device, such as a computer printer or fax output device, or it 90 could be a service that interfaced with output devices. 92 The architecture for IPP defines (in the Model document [IPP-MOD]) 93 an abstract Model for the data which is used to control the 94 printing process and to provide information about the process and 96 Expires: December 30, 1998 97 the capabilities of the Printer. This abstract Model is 98 hierarchical in nature and reflects the structure of the Printer 99 and the Jobs that may be being processed by the Printer. 101 The Internet provides a channel between the client and the 102 server/Printer. Use of this channel requires flattening and 103 sequencing the hierarchical Model data. Therefore, the IPP also 104 defines (in the Encoding and Transport document [IPP-PRO]) an 105 encoding of the data in the model for transfer between the client 106 and server. This transfer of data may be either a request or the 107 response to a request. 109 Finally, the IPP defines (in the Encoding and Transport document 110 [IPP-PRO]) a protocol for transferring the encoded request and 111 response data between the client and the server/Printer. 113 An example of a typical interaction would be a request from the 114 client to create a print job. The client would assemble the Model 115 data to be associated with that job, such as the name of the job, 116 the media to use, the number of pages to place on each media 117 instance, etc. This data would then be encoded according to the 118 Protocol and would be transmitted according to the Protocol. The 119 server/Printer would receive the encoded Model data, decode it into 120 a form understood by the server/Printer and, based on that data, do 121 one of two things: (1) accept the job or (2) reject the job. In 122 either case, the server must construct a response in terms of the 123 Model data, encode that response according to the Protocol and 124 transmit that encoded Model data as the response to the request 125 using the Protocol. 127 Another part of the IPP architecture is the Directory Schema 128 described in the model document). The role of a Directory Schema is 129 to provide a standard set of attributes which might be used to 130 query a directory service for the URI of a Printer that is likely 131 to meet the needs of the client. The IPP architecture also 132 addresses security issues such as control of access to 133 server/Printers and secure transmissions of requests, response and 134 the data to be printed. 136 2. THE PRINTER 138 Because the (abstract) server/Printer encompasses a wide range 139 of implementations, it is necessary to make some assumptions 140 about a minimal implementation. The most likely minimal 141 implementation is one that is embedded in an output device 142 running a specialized real time operating system and with limited 143 processing, memory and storage capabilities. This printer will be 144 connected to the Internet and will have at least a TCP/IP 145 capability with (likely) SNMP [RFC1905, RFC1906] support for the 146 Internet connection. In addition, it is likely the the Printer will 148 Expires: December 30, 1998 149 be an HTML/HTTP server to allow direct user access to information 150 about the printer. 152 3. RATIONALE FOR THE MODEL 154 The Model [IPP-MOD] is defined independently of any encoding of the 155 Model data both to support the likely uses of IPP and to be robust 156 with respect to the possibility of alternate encoding. 158 It is expected that a client or server/Printer would represent 159 the Model data in some data structure within the 160 applications/servers that support IPP. Therefore, the Model was 161 designed to make that representation straightforward. Typically a 162 parser or formatter would be used to convert from or to the encoded 163 data format. Once in an internal form suitable to a product, the 164 data can be manipulated by the product. For example, the data sent 165 with a Print Job can be used to control the processing of that 166 Print Job. 168 The semantics of IPP are attached to the (abstract) Model. 169 Therefore, the application/server is not dependent on the encoding 170 of the Model data, and it is possible to consider alternative 171 mechanisms and formats by which the data could be transmitted from 172 a client to a server; for example, a server could have a direct, 173 client-less GUI interface that might be used to accept some kinds 174 of Print Jobs. This independence would also allow a different 175 encoding and/or transmission mechanism to be used if the ones 176 adopted here were shown to be overly limiting in the future. Such a 177 change could be migrated into new products as an alternate protocol 178 stack/parser for the Model data. 180 Having an abstract Model also allows the Model data to be aligned 181 with the (abstract) model used in the Printer [RFC1759], Job and 182 Host Resources MIBs. This provides consistency in interpretation of 183 the data obtained independently of how the data is accessed, 184 whether via IPP or via SNMP [RFC1905, RFC1906] and the Printer/Job 185 MIBs. 187 There is one aspect of the Model that deserves some extra 188 explanation. There are two ways for identifying a Job object: (a) 189 with a Job URI and (b) using a combination of the Printer URI and a 190 Job ID (a 32 bit positive integer). Allowing Job objects to have 191 URIs allows for flexibility and scalability. For example a job 192 could be moved from a printer with a large backlog to one with a 193 smaller load and the job identification, the Job object URI, 194 need not change. However, many existing printing systems have local 195 models or interface constraints that force Job objects to be 196 identified using only a 32-bit positive integer rather than a URI. 197 This numeric Job ID is only unique within the context of the 198 Printer object to which the create request was originally 200 Expires: December 30, 1998 201 submitted. In order to allow both types of client access to Jobs 202 (either by Job URI or by numeric Job ID), when the Printer object 203 successfully processes a create request and creates a new Job, the 204 Printer object SHALL generate both a Job URI and a Job ID for the 205 new Job object. This requirement allows all clients to access 206 Printer objects and Job objects independent of any local 207 constraints imposed on the client implementation. 209 4. RATIONALE FOR THE PROTOCOL 211 There are two parts to the Protocol: (1) the encoding of the Model 212 data and (2) the mechanism for transmitting the model data between 213 client and server. 215 4.1 The Encoding 217 To make it simpler to develop embedded printers, a very simple 218 binary encoding has been chosen. This encoding is adequate to 219 represent the kinds of data that occur within the Model. It has a 220 simple structure consisting of sequences of attributes. Each 221 attribute has a name, prefixed by a name length, and a value. The 222 names are strings constrained to characters from a subset of ASCII. 223 The values are either scalars or a sequence of scalars. Each scalar 224 value has a length specification and a value tag which 225 indicates the type of the value. The value type has two parts: a 226 major class part, such as integer or string, and a minor class part 227 which distinguishes the usage of the major class, such as dateTime 228 string. Tagging of the values with type information allows for 229 introducing new value types at some future time. 231 A fully encoded request/response has a version number, an operation 232 (for a request) or a status and optionally a status message (for a 233 response), associated parameters and attributes which are encoded 234 Model data and, optionally (for a request), print data following 235 the Model data. 237 4.2 The Transmission Mechanism 239 The chosen mechanism for transmitting the encoded Model data is 240 HTTP 1.1 Post (and associated response). No modifications to HTTP 241 1.1 are proposed or required. The sole role of the Transmission 242 Mechanism is to provide a transfer of encoded Model data from/to 243 the client to/from the server. This could be done using any data 244 delivery mechanism. The key reasons why HTTP 1.1 Post is used are 245 given below. The most important of these is the first. With perhaps 246 this exception, these reasons could be satisfied by other 247 mechanisms. There is no claim that this list uniquely determines a 248 choice of mechanism. 250 Expires: December 30, 1998 251 1. HTTP 1.0 is already widely deployed and, based on the 252 recent evidence, HTTP 1.1 is being widely deployed as the 253 manufacturers release new products. The performance benefits 254 of HTTP 1.1 have been shown and manufactures are reacting 255 positively. 257 Wide deployment has meant that many of the problems of making 258 a protocol work in a wide range of environments from local net 259 to Intranet to Internet have been solved and will stay solved 260 with HTTP 1.1 deployment. 262 2. HTTP 1.1 solves most of the problems that might have 263 required a new protocol to be developed. HTTP 1.1 allows 264 persistent connections that make a multi-message protocol be 265 more efficient; for example it is practical to have separate 266 Create-Job and Send-Document messages. Chunking allows the 267 transmission of large print files without having to pre-scan 268 the file to determine the file length. The accept headers 269 allow the client's protocol and localization desires to be 270 transmitted with the IPP operations and data. If the Model 271 were to provide for the redirection of Job requests, such as 272 Cancel-Job, when a Job is moved, the HTTP redirect response 273 allows a client to be informed when a Job he is interested in 274 is moved to another server/Printer for any reason. 276 3. Most network Printers will be implementing HTTP servers for 277 reasons other than IPP. These network attached Printers want 278 to provide information on how to use the printer, its current 279 state, HELP information, etc. in HTML. This requires having an 280 HTTP server which would be available to do IPP functions as 281 well. 283 4. Most of the complexity of HTTP 1.1 is concerned with the 284 implementation of HTTP proxies and not the implementation of 285 HTTP clients and/or servers. Work is proceeding in the HTTP 286 Working Group to help identify what must be done by a server. 287 As the Encoding and Transport document shows, that is not 288 very much. 290 5. HTTP implementations provide support for handling URLs that 291 would have to be provided if a new protocol were defined. 293 6. An HTTP based solution fits well with the Internet security 294 mechanisms that are currently deployed or being deployed. HTTP 295 will run over TLS. The digest authentication mechanism of HTTP 296 1.1 provides an adequate level of access control (at least for 297 Intranet usage). These solutions are deployed and in practical 298 use; a new solution would require extensive use to have the 299 same degree of confidence in its security. 301 7. HTTP provides an extensibility model that a new protocol 302 would have to develop independently. In particular, the 304 Expires: December 30, 1998 305 headers, intent-types (via Internet Media Types) and error 306 codes have wide acceptance and a useful set of definitions and 307 methods for extension. 309 8. Although not strictly a reason why IPP should use HTTP as 310 the transmission protocol, it is extremely helpful that there 311 are many prototyping tools that work with HTTP and that CGI 312 scripts can be used to test and debug parts of the protocol. 314 9. Finally, the POST method was chosen to carry the print data 315 because its usage for data transmission has been established, 316 it works and the results are available via CGI scripts or 317 servlets. Creating a new method would have better identified 318 the intended use of the POSTed data, but a new method would be 319 more difficult to deploy. Assigning a new default port for 320 IPP provided the necessary identification with minimal impact 321 to installed infrastructure, so was chosen instead. 323 5. RATIONALE FOR THE DIRECTORY SCHEMA 325 Successful use of IPP depends on the client finding a suitable IPP 326 enabled Printer to which to send a IPP requests, such as print a 327 job. This task is simplified if there is a Directory Service which 328 can be queried for a suitable Printer. The purpose of the Directory 329 Schema is to have a standard description of Printer attributes that 330 can be associated the URI for the printer. These attributes are a 331 subset of the Model attributes and can be encoded in the 332 appropriate query syntax for the Directory Service being used by 333 the client. 335 6. RATIONALE FOR SECURITY 337 Security is an areas of active work on the Internet. Complete 338 solutions to a wide range of security concerns are not yet 339 available. Therefore, in the design of IPP, the focus has been on 340 identifying a set of security protocols/features that are 341 implemented (or currently implementable) and solve real problems 342 with distributed printing. The two areas that seem appropriate to 343 support are: (1) authorization to use a Printer and (2) secure 344 interaction with a printer. The chosen mechanisms are the digest 345 authentication mechanism of HTTP 1.1 and the TLS [TLS-PRO] secure 346 communication mechanism. 348 7. COPYRIGHT 350 Copyright (C) The Internet Society (1998) All Rights Reserved. 352 Expires: December 30, 1998 353 This document and translations of it may be copied and furnished to 354 others, and derivative works that comment on or otherwise explain 355 it or assist in its implementation may be prepared, copied, 356 published and distributed, in whole or in part, without restriction 357 of any kind, provided that the above copyright notice and this 358 paragraph are included on all such copies and derivative works. 359 However, this document itself may not be modified in any way, such 360 as by removing the copyright notice or references to the Internet 361 Society or other Internet organizations, except as needed for the 362 purpose of developing Internet standards in which case the 363 procedures for copyrights defined in the Internet Standards process 364 must be followed, or as required to translate it into languages 365 other than English. The limited permissions granted above are 366 perpetual and will not be revoked by the Internet Society or its 367 successors or assigns. 369 This document and the information contained herein is provided on 370 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 371 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 372 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 373 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 374 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 376 8. REFERENCES 378 [RFC1759] 379 Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, 380 J., "Printer MIB", RFC 1759, March 1995. 382 [RFC1905] 383 J. Case, et al. "Protocol Operations for Version 2 of the Simple 384 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 386 [RFC1906] 387 J. Case, et al. "Transport Mappings for Version 2 of the Simple 388 Network Management Protocol (SNMPv2)", RFC 1906, January 1996. 390 [IPP LPD] 391 Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between 392 LPD and IPP Protocols", draft-ietf-ipp-lpd-ipp-map-04.txt, June 393 1998. 395 [IPP-MOD] 396 Isaacson, S., deBry, R., Hastings, T., Herriot, R., Powell, 397 P. "Internet Printing Protocol/1.0: Model and Semantics" 398 draft-ietf-ipp-mod-10.txt, June, 1998. 400 Expires: December 30, 1998 401 [IPP-PRO] 402 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 403 Protocol/1.0: Encoding and Transport", draft-ietf-ipp-pro-06.txt, 404 June, 1998. 406 [IPP-REQ] 407 Wright, D., "Design Goals for an Internet Printing Protocol", 408 draft-ietf-ipp-req-02.txt, June, 1998. 410 [ISO10175] 411 ISO/IEC 10175 "Document Printing Application (DPA)", June 1996 413 [TLS-PRO] 414 Dirks, T., and Allan, C., "The TLS Protocol", 415 draft-ietf-tls-protocol-05.txt 417 9. AUTHORS ADDRESS 419 Stephen Zilles 420 Adobe Systems Incorporated 421 345 Park Avenue 422 MailStop W14 423 San Jose, CA 95110-2704 425 Phone: +1 408 536-4766 426 Fax: +1 408 537-4042 427 Email: szilles@adobe.com 429 Expires: December 30, 1998