idnits 2.17.1 draft-ietf-ipp-rat-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: ---------------------------------------------------------------------------- ** 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 == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 1) being 62 lines 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 abstract seems to contain references ([IPP-PRO], [IPP-IIG], [IPP-MOD], [IPP-LPD], [IPP-REQ]), 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 212: '...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 326 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 47, but not defined == Unused Reference: 'IPP LPD' is defined on line 391, but no explicit reference was found in the text -- No information found for draft-ietf-ipp-implementors-guide - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IPP-IIG' ** 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' ** Downref: Normative reference to an Experimental draft: draft-ietf-ipp-req (ref. 'IPP-REQ') -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10175' ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'SSL' Summary: 16 errors (**), 0 flaws (~~), 6 warnings (==), 10 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 November 16, 1998 Expires: May 16, 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 Shadow 25 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. This document describes 35 IPP from a high level view, defines a roadmap for the various documents 36 that form the suite of IPP specifications, and gives background and 37 rationale for the IETF working group's major decisions. 39 The full set of IPP documents includes: 41 Design Goals for an Internet Printing Protocol [IPP-REQ] 42 Rationale for the Structure and Model and Protocol for the 43 Internet Printing Protocol (this document) 44 Internet Printing Protocol/1.0: Model and Semantics [IPP-MOD] 45 Internet Printing Protocol/1.0: Encoding and Transport [IPP-PRO] 46 Internet Printing Protocol/1.0: Implementer's Guide [IPP-IIG] 47 Mapping between LPD and IPP Protocols [IPP-LPD] 49 The "Design Goals for an Internet Printing 50 Protocol" document takes a broad look at distributed printing 51 functionality, and it enumerates real-life scenarios that help to 52 clarify the features that need to be included in a printing 53 protocol for the Internet. It identifies requirements for three 54 types of users: end users, operators, and administrators. The 55 requirements document calls out a subset of end user requirements 56 that are satisfied in IPP/1.0. Operator and administrator 57 requirements are out of scope for version 1.0. 59 The "Internet Printing Protocol/1.0: Model and Semantics" document 60 describes a simplified model consisting of abstract objects, their 61 attributes, and their operations that is independent of encoding and 62 transport. The model consists of a Printer and a Job object. The Job 63 optionally supports multiple documents. This document also addresses 64 security, internationalization, and directory issues. 66 The "Internet Printing Protocol/1.0: Encoding and Transport" document is 67 a formal mapping of the abstract operations and attributes defined in 68 the model document onto HTTP/1.1. It defines the encoding rules for a 69 new Internet media type called "application/ipp". 71 The "Internet Printing Protocol/1.0: Implementer's Guide" document gives 72 insight and advice to implementers of IPP clients and IPP objects. It 73 is intended to help them understand IPP/1.0 and some of the 74 considerations that may assist them in the design of their client and/or 75 IPP object implementations. For example, a typical order of processing 76 requests is given, including error checking. Motivation for some of the 77 specification decisions is also included. 79 The "Mapping between LPD and IPP Protocols" document gives some advice 80 to implementers of gateways between IPP and LPD (Line Printer Daemon) 81 implementations. 83 Expires May 16, 1999 84 1. ARCHITECTURAL OVERVIEW 86 The Internet Printing Protocol (IPP) is an application level 87 protocol that can be used for distributed printing on the Internet. 88 This protocol defines interactions between a client and a server. 89 The protocol allows a client to inquire about capabilities of a 90 printer, to submit print jobs and to inquire about and cancel print 91 jobs. The server for these requests is the Printer; the Printer is 92 an abstraction of a generic document output device and/or a print 93 service provider. Thus, the Printer could be a real printing 94 device, such as a computer printer or fax output device, or it 95 could be a service that interfaced with output devices. 97 The protocol is heavily influenced by the printing model introduced in 98 the Document Printing Application (DPA) [ISO10175] standard. Although 99 DPA specifies both end user and administrative features, IPP version 1.0 100 (IPP/1.0) focuses only on end user functionality. 102 The architecture for IPP defines (in the Model document [IPP-MOD]) 103 an abstract Model for the data which is used to control the 104 printing process and to provide information about the process and 105 the capabilities of the Printer. This abstract Model is 106 hierarchical in nature and reflects the structure of the Printer 107 and the Jobs that may be being processed by the Printer. 109 The Internet provides a channel between the client and the 110 server/Printer. Use of this channel requires flattening and 111 sequencing the hierarchical Model data. Therefore, the IPP also 112 defines (in the Encoding and Transport document [IPP-PRO]) an encoding 113 of the data in the model for transfer between the client and server. 114 This transfer of data may be either a request or the response to a 115 request. 117 Finally, the IPP defines (in the Encoding and Transport document [IPP- 118 PRO]) a protocol for transferring the encoded request and response data 119 between the client and the server/Printer. 121 An example of a typical interaction would be a request from the 122 client to create a print job. The client would assemble the Model 123 data to be associated with that job, such as the name of the job, 124 the media to use, the number of pages to place on each media 125 instance, etc. This data would then be encoded according to the 126 Protocol and would be transmitted according to the Protocol. The 127 server/Printer would receive the encoded Model data, decode it into 128 a form understood by the server/Printer and, based on that data, do 129 one of two things: (1) accept the job or (2) reject the job. In 130 either case, the server must construct a response in terms of the 131 Model data, encode that response according to the Protocol and 132 transmit that encoded Model data as the response to the request 133 using the Protocol. 135 Another part of the IPP architecture is the Directory Schema 136 described in the model document). The role of a Directory Schema is 138 Expires May 16, 1999 139 to provide a standard set of attributes which might be used to 140 query a directory service for the URI of a Printer that is likely 141 to meet the needs of the client. The IPP architecture also 142 addresses security issues such as control of access to 143 server/Printers and secure transmissions of requests, response and 144 the data to be printed. 146 2. THE PRINTER 148 Because the (abstract) server/Printer encompasses a wide range 149 of implementations, it is necessary to make some assumptions 150 about a minimal implementation. The most likely minimal 151 implementation is one that is embedded in an output device 152 running a specialized real time operating system and with limited 153 processing, memory and storage capabilities. This printer will be 154 connected to the Internet and will have at least a TCP/IP 155 capability with (likely) SNMP [RFC1905, RFC1906] support for the 156 Internet connection. In addition, it is likely the the Printer will 157 be an HTML/HTTP server to allow direct user access to information 158 about the printer. 160 3. RATIONALE FOR THE MODEL 162 The Model [IPP-MOD] is defined independently of any encoding of the 163 Model data both to support the likely uses of IPP and to be robust 164 with respect to the possibility of alternate encoding. 166 It is expected that a client or server/Printer would represent 167 the Model data in some data structure within the 168 applications/servers that support IPP. Therefore, the Model was 169 designed to make that representation straightforward. Typically a 170 parser or formatter would be used to convert from or to the encoded 171 data format. Once in an internal form suitable to a product, the 172 data can be manipulated by the product. For example, the data sent 173 with a Print Job can be used to control the processing of that 174 Print Job. 176 The semantics of IPP are attached to the (abstract) Model. 177 Therefore, the application/server is not dependent on the encoding 178 of the Model data, and it is possible to consider alternative 179 mechanisms and formats by which the data could be transmitted from 180 a client to a server; for example, a server could have a direct, 181 client-less GUI interface that might be used to accept some kinds 182 of Print Jobs. This independence would also allow a different 183 encoding and/or transmission mechanism to be used if the ones 184 adopted here were shown to be overly limiting in the future. Such a 185 change could be migrated into new products as an alternate protocol 186 stack/parser for the Model data. 188 Having an abstract Model also allows the Model data to be aligned 189 with the (abstract) model used in the Printer [RFC1759], Job and 191 Expires May 16, 1999 192 Host Resources MIBs. This provides consistency in interpretation of 193 the data obtained independently of how the data is accessed, 194 whether via IPP or via SNMP [RFC1905, RFC1906] and the Printer/Job 195 MIBs. 197 There is one aspect of the Model that deserves some extra 198 explanation. There are two ways for identifying a Job object: (a) 199 with a Job URI and (b) using a combination of the Printer URI and a 200 Job ID (a 32 bit positive integer). Allowing Job objects to have 201 URIs allows for flexibility and scalability. For example a job 202 could be moved from a printer with a large backlog to one with a 203 smaller load and the job identification, the Job object URI, 204 need not change. However, many existing printing systems have local 205 models or interface constraints that force Job objects to be 206 identified using only a 32-bit positive integer rather than a URI. 207 This numeric Job ID is only unique within the context of the 208 Printer object to which the create request was originally 209 submitted. In order to allow both types of client access to Jobs 210 (either by Job URI or by numeric Job ID), when the Printer object 211 successfully processes a create request and creates a new Job, the 212 Printer object SHALL generate both a Job URI and a Job ID for the 213 new Job object. This requirement allows all clients to access 214 Printer objects and Job objects independent of any local 215 constraints imposed on the client implementation. 217 4. RATIONALE FOR THE PROTOCOL 219 There are two parts to the Protocol: (1) the encoding of the Model 220 data and (2) the mechanism for transmitting the model data between 221 client and server. 223 4.1 The Encoding 225 To make it simpler to develop embedded printers, a very simple 226 binary encoding has been chosen. This encoding is adequate to 227 represent the kinds of data that occur within the Model. It has a 228 simple structure consisting of sequences of attributes. Each 229 attribute has a name, prefixed by a name length, and a value. The 230 names are strings constrained to characters from a subset of ASCII. 231 The values are either scalars or a sequence of scalars. Each scalar 232 value has a length specification and a value tag which 233 indicates the type of the value. The value type has two parts: a 234 major class part, such as integer or string, and a minor class part 235 which distinguishes the usage of the major class, such as dateTime 236 string. Tagging of the values with type information allows for 237 introducing new value types at some future time. 239 A fully encoded request/response has a version number, an operation 240 (for a request) or a status and optionally a status message (for a 241 response), associated parameters and attributes which are encoded 242 Model data and, optionally (for a request), print data following 243 the Model data. 245 Expires May 16, 1999 246 4.2 The Transmission Mechanism 248 The chosen mechanism for transmitting the encoded Model data is 249 HTTP 1.1 Post (and associated response). No modifications to HTTP 250 1.1 are proposed or required. The sole role of the Transmission 251 Mechanism is to provide a transfer of encoded Model data from/to 252 the client to/from the server. This could be done using any data 253 delivery mechanism. The key reasons why HTTP 1.1 Post is used are 254 given below. The most important of these is the first. With perhaps 255 this exception, these reasons could be satisfied by other 256 mechanisms. There is no claim that this list uniquely determines a 257 choice of mechanism. 259 1. HTTP 1.0 is already widely deployed and, based on the 260 recent evidence, HTTP 1.1 is being widely deployed as the 261 manufacturers release new products. The performance benefits 262 of HTTP 1.1 have been shown and manufactures are reacting 263 positively. 265 Wide deployment has meant that many of the problems of making 266 a protocol work in a wide range of environments from local net 267 to Intranet to Internet have been solved and will stay solved 268 with HTTP 1.1 deployment. 270 2. HTTP 1.1 solves most of the problems that might have 271 required a new protocol to be developed. HTTP 1.1 allows 272 persistent connections that make a multi-message protocol be 273 more efficient; for example it is practical to have separate 274 Create-Job and Send-Document messages. Chunking allows the 275 transmission of large print files without having to pre-scan 276 the file to determine the file length. The accept headers 277 allow the client's protocol and localization desires to be 278 transmitted with the IPP operations and data. If the Model 279 were to provide for the redirection of Job requests, such as 280 Cancel-Job, when a Job is moved, the HTTP redirect response 281 allows a client to be informed when a Job he is interested in 282 is moved to another server/Printer for any reason. 284 3. Most network Printers will be implementing HTTP servers for 285 reasons other than IPP. These network attached Printers want 286 to provide information on how to use the printer, its current 287 state, HELP information, etc. in HTML. This requires having an 288 HTTP server which would be available to do IPP functions as 289 well. 291 4. Most of the complexity of HTTP 1.1 is concerned with the 292 implementation of HTTP proxies and not the implementation of 293 HTTP clients and/or servers. Work is proceeding in the HTTP 294 Working Group to help identify what must be done by a server. 295 As the Encoding and Transport document shows, that is not 296 very much. 298 Expires May 16, 1999 299 5. HTTP implementations provide support for handling URLs that 300 would have to be provided if a new protocol were defined. 302 6. An HTTP based solution fits well with the Internet security 303 mechanisms that are currently deployed or being deployed. HTTP 304 will run over SSL3. The digest access authentication mechanism 305 of HTTP 1.1 provides an adequate level of access control. These 306 solutions are deployed and in practical use; a new solution would 307 require extensive use to have the same degree of confidence in its 308 security. Note: SSL3 is not on the IETF standards track. 310 7. HTTP provides an extensibility model that a new protocol 311 would have to develop independently. In particular, the 312 headers, intent-types (via Internet Media Types) and error 313 codes have wide acceptance and a useful set of definitions and 314 methods for extension. 316 8. Although not strictly a reason why IPP should use HTTP as 317 the transmission protocol, it is extremely helpful that there 318 are many prototyping tools that work with HTTP and that CGI 319 scripts can be used to test and debug parts of the protocol. 321 9. Finally, the POST method was chosen to carry the print data 322 because its usage for data transmission has been established, 323 it works and the results are available via CGI scripts or 324 servlets. Creating a new method would have better identified 325 the intended use of the POSTed data, but a new method would be 326 more difficult to deploy. Assigning a new default port for 327 IPP provided the necessary identification with minimal impact 328 to installed infrastructure, so was chosen instead. 330 5. RATIONALE FOR THE DIRECTORY SCHEMA 332 Successful use of IPP depends on the client finding a suitable IPP 333 enabled Printer to which to send a IPP requests, such as print a 334 job. This task is simplified if there is a Directory Service which 335 can be queried for a suitable Printer. The purpose of the Directory 336 Schema is to have a standard description of Printer attributes that 337 can be associated the URI for the printer. These attributes are a 338 subset of the Model attributes and can be encoded in the 339 appropriate query syntax for the Directory Service being used by 340 the client. 342 6. RATIONALE FOR SECURITY 344 Security is an areas of active work on the Internet. Complete 345 solutions to a wide range of security concerns are not yet 346 available. Therefore, in the design of IPP, the focus has been on 347 identifying a set of security protocols/features that are 348 implemented (or currently implementable) and solve real problems 349 with distributed printing. The two areas that seem appropriate to 351 Expires May 16, 1999 352 support are: (1) authorization to use a Printer and (2) secure 353 interaction with a printer. The chosen mechanisms are the digest 354 authentication mechanism of HTTP 1.1 and SSL3 [SSL] secure 355 communication mechanism. 357 7. COPYRIGHT 359 Copyright (C) The Internet Society (1998) All Rights Reserved. 361 This document and translations of it may be copied and furnished to 362 others, and derivative works that comment on or otherwise explain 363 it or assist in its implementation may be prepared, copied, 364 published and distributed, in whole or in part, without restriction 365 of any kind, provided that the above copyright notice and this 366 paragraph are included on all such copies and derivative works. 367 However, this document itself may not be modified in any way, such 368 as by removing the copyright notice or references to the Internet 369 Society or other Internet organizations, except as needed for the 370 purpose of developing Internet standards in which case the 371 procedures for copyrights defined in the Internet Standards process 372 must be followed, or as required to translate it into languages 373 other than English. The limited permissions granted above are 374 perpetual and will not be revoked by the Internet Society or its 375 successors or assigns. 377 This document and the information contained herein is provided on 378 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 379 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 380 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 381 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 382 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 384 8. REFERENCES 386 [IPP-IIG] 387 Hastings, T., Manros, C., "Internet Printing Protocol/1.0: 388 Implementer's Guide", draft-ietf-ipp-implementors-guide-00.txt, November 389 1998, work in progress. 391 [IPP LPD] 392 Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between LPD 393 and IPP Protocols", draft-ietf-ipp-lpd-ipp-map-05.txt, November 1998. 395 [IPP-MOD] 396 deBry, R., Isaacson, S., Hastings, T., Herriot, R., Powell, 397 P. "Internet Printing Protocol/1.0: Model and Semantics" 398 draft-ietf-ipp-mod-11.txt, November, 1998. 400 [IPP-PRO] 401 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 402 Protocol/1.0: Encoding and Transport", draft-ietf-ipp-pro-07.txt, 404 Expires May 16, 1999 405 November, 1998. 407 [IPP-REQ] 408 Wright, D., "Design Goals for an Internet Printing Protocol", 409 draft-ietf-ipp-req-03.txt, November, 1998. 411 [ISO10175] 412 ISO/IEC 10175 "Document Printing Application (DPA)", June 1996 414 [RFC1759] 415 Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, 416 J., "Printer MIB", RFC 1759, March 1995. 418 [RFC1905] 419 J. Case, et al. "Protocol Operations for Version 2 of the Simple 420 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 422 [RFC1906] 423 J. Case, et al. "Transport Mappings for Version 2 of the Simple 424 Network Management Protocol (SNMPv2)", RFC 1906, January 1996. 426 [SSL] 427 Netscape, The SSL Protocol, Version 3, (Text version 3.02), November 428 1996. 430 9. AUTHORS ADDRESS 432 Stephen Zilles 433 Adobe Systems Incorporated 434 345 Park Avenue 435 MailStop W14 436 San Jose, CA 95110-2704 438 Phone: +1 408 536-4766 439 Fax: +1 408 537-4042 440 Email: szilles@adobe.com 442 Expires May 16, 1999