INTERNET-DRAFT Stephen N. Zilles Adobe Systems Inc. July 14, 1997 Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol (IPP) Expires Jan 14, 1998 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol and an interface to Directory Services. This document provides a high level overview of the architecture and provides the rational for the decisions made in structuring the architecture. The full set of IPP documents include: Internet Printing Protocol/1.0: Requirements Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Security Internet Printing Protocol/1.0: Protocol Specification Internet Printing Protocol/1.0: Directory Schema Zilles [Page 1] Rationale for the Structure of the Model and Protocol July 14, 1997 TABLE OF CONTENTS 1. ARCHITECTURAL OVERVIEW..............................................3 2. THE PRINTER.........................................................4 3. RATIONAL FOR THE MODEL..............................................4 4. RATIONAL FOR THE PROTOCOL...........................................5 4.1 The Encoding .....................................................5 4.2 Smission Mechanism ...............................................5 5. RATIONAL FOR THE DIRECTORY SCHEMA...................................6 6. RATIONAL FOR SECURITY...............................................6 7. AUTHOR'S ADDRESSES..................................................7 Zilles [Page 2] Rationale for the Structure of the Model and Protocol July 14, 1997 1 Rationale for the Structure of the Model and Protocol 2 for the Internet Printing Protocol (IPP) 3 1. Architectural Overview 4 The Internet Printing Protocol (IPP) is an application level 5 protocol that can be used for distributed printing on the 6 Internet. This protocol defines interactions between a 7 client and a server. The client is provided the capability 8 to inquire about capabilities of a printer, to submit print 9 jobs and to inquire about and cancel print jobs. The server 10 for these requests is the Printer; the Printer is an 11 abstraction a generic document output device and/or a print 12 service provider. Thus, the Printer could be a real printing 13 device, such as a computer printer or fax output device, or 14 it could be a service that interfaced with output devices. 15 The architecture for IPP defines (in the Model document) an 16 abstract Model for the data which is used to control the 17 printing process and to provide information about the 18 process and the capabilities of the Printer. This abstract 19 Model is hierarchical in nature and reflects the structure 20 of the Printer and the Jobs that may be being processed by 21 the Printer. The Internet provides a channel between the 22 client and the server/Printer. Use of this channel requires 23 flattening and sequencing the hierarchical Model data. 24 Therefore, the IPP also defines (in the Protocol document) 25 an encoding of the data in the model for transfer between 26 the client and server. This transfer of data may be either a 27 request or the response to a request. Finally, the IPP 28 defines (in the Protocol document) a protocol for 29 transfering the encoded request and response data between 30 the client and the server/Printer. 31 An example of a typical interaction would by a request from 32 the client to create a print job. The client would assemble 33 the Model data to be associated with that job, such as the 34 name of the job, the media to use, the number of pages to 35 place on each media instance, etc. This data would then be 36 encoded according to the Protocol and would be transmitted 37 according to the Protocol. The server/Printer would receive 38 the encoded Model data, decode it into a form understood by 39 the server/Printer and, based on that data, do one of two 40 things: (1) accept the job or (2) reject the job. In either 41 case, the server must construct a response in terms of the 42 Model data, encode that response according to the Protocol 43 and transmit that encoded Model data as the response to the 44 request using the Protocol. 45 Another part of the IPP architecture is the Directory 46 Schema. The role of the Directory Schema is to provide a 47 standard set of attributes which might be used to query a 48 directory service for the URI of a Printer that is likely to 49 meet the needs of the client. 50 The IPP architecture also addresses security issues such as 51 control of access to server/Printers and secure 52 transmissions of requests, response and the data to be 53 printed. Zilles [Page 3] Rationale for the Structure of the Model and Protocol July 14, 1997 54 2. The Printer 55 Because the (abstract) server/Printer encompasses a wide 56 range of implementations, it is necessary to make some 57 assumptions about a minimal implementation. The most likely 58 minimal implementation is one that is embedded in an output 59 device running a specialized real time operating system and 60 with limited processing, memory and storage capabilities. 61 This Printer will be connected to the Internet and will have 62 at least a TCP/IP capability with (likely) SNMP support for 63 the Internet connection. In addition, it is likely the the 64 Printer will be an HTML/HTTP server to allow direct user 65 access to information about the printer. 66 3. Rationale For The Model 67 The Model is defined independently of any encoding of the 68 Model data both to support the likely uses of IPP and to be 69 robust with respect to the possibility of alternate 70 encodings. 71 It is expected that a client or server/Printer would 72 represent the Model data in some data structure within the 73 applications/servers that support IPP. Therefore, the Model 74 was designed to make that representation straightforward. 75 Typically, a parser or formatter would be used to convert 76 from or to the encoded data format. Once in an internal form 77 suitable to a product, the data can be manipulated by the 78 product. For example, the data sent with a Print Job can be 79 used to control the processing of that Print Job. 80 The semantics of IPP are attached to the (abstract) Model. 81 Therefore, the application/server is not dependent on the 82 encoding of the Model data, and it is possible to consider 83 alternative mechanisms and formats by which the data could 84 be transmitted from a client to a server; for example, a 85 server could have a direct, client-less GUI interface that 86 might be used to accept some kinds of Print Jobs. This 87 independence would also allow a different encoding and/or 88 transmission mechanism to be used if the ones adopted here 89 were shown to be overly limiting in the future. Such a 90 change could be migrated into new products as an alternate 91 protocol stack/parser for the Model data. 92 Having an abstract Model also allow the Model data to be 93 aligned with the (abstract) model used in the Printer, Job 94 and Host Resources MIBs. This provides consistency in 95 interpretation of the data obtained independently of how the 96 data is accessed, whether via IPP or via SNMP and the 97 Printer/Job MIBs. 98 4. Rationale For The Protocol 99 There are two parts to the Protocol: (1) the encoding of the 100 Model data and (2) the mechanism for transmitting the model 101 data between client and server. 102 4.1 The Encoding 103 The TranTo make it simpler to develop embedded printers, a 104 very simple binary encoding has been chosen. This encoding Zilles [Page 4] Rationale for the Structure of the Model and Protocol July 14, 1997 105 is adequate to represent the kinds of data that occur within 106 the Model. It has a simple structure consisting of name 107 value pairs in which the names are length specified strings 108 constrained to characters from a subset of ASCII and the 109 values are either scalars or a sequence of scalars. Each 110 scalar value has a length specification. 111 A fully encoded request/response has a version number, an 112 operation (for a request) or a status (for a response), 113 associated parameters which are encoded Model data and, 114 optionally, print data following the Model data. 115 [ISSUE: what should be said about Parameters and Attributes] 116 4.2 Smission Mechanism 117 The chosen mechanism for transmitting the encoded Model data 118 is HTTP 1.1 Post (and associated response). No modifications 119 to HTTP 1.1 are proposed or required. 120 The sole role of the Transmission Mechanism is to provide a 121 transfer of encoded Model data from/to the client to/from 122 the server. This could be done using any data delivery 123 mechanism. The key reasons why HTTP 1.1 Post is used are: 124 1. HTTP 1.0 is already widely deployed and, based on the 125 recent evidence, HTTP 1.1 will be widely deployed as the 126 manufactures release new products. The performance 127 benefits of HTTP 1.1 have been shown and manufactures are 128 reacting postively. 129 2. Wide deployment has meant that many of the problems of 130 making a protocol work in a wide range of environments 131 from local net to intranet to internet have been solved 132 and will stay solved with HTTP 1.1 deployment. 133 3. HTTP 1.1 solves most of the problems that might have 134 required a new protocol to be developed. HTTP 1.1 allows 135 persistent connections that make a multi-message protocol 136 be more efficient; for example it is practical to have a 137 separate CreatJob and SendJob messages. Chunking allows 138 the transmission of large print files without having to 139 prescan the file to determine the file length. The accept 140 headers allow the client's protocol and localization 141 desires to be transmitted with the IPP operations and 142 data. The HTTP redirect response allows a client to be 143 informed when a Job he is interested in is moved to 144 another server/Printer for any reason. 145 4. Most network Printers will be implementing HTTP servers 146 for reasons other than IPP. These network attached 147 Printers want to provide information on how to use the 148 printer, its current state, etc. in HTML. This requires 149 having an HTTP server which would be available to do IPP 150 functions as well. 151 5. Most of the complexity of HTTP 1.1 is concerned with the 152 implementation of proxies and not the implementation of 153 clients and/or servers. Work is proceding in the HTTP 154 Working Group to help identify what must be done by a 155 server. As the Protocol document shows, that is not very 156 much. Zilles [Page 5] Rationale for the Structure of the Model and Protocol July 14, 1997 157 6. An HTTP based solution fits will with the Internet 158 security mechanism that are currently deployed or being 159 deployed. HTTP will run over SSL/TLS. The digest 160 authentication mechanism of HTTP 1.1 provides an adequate 161 level of access control (at least for intranet usage). 162 These solutions are deployed and in practical use; a new 163 solution would require extensive use to have the same 164 degree of confidence in its security. 165 5. Rationale For The Directory Schema 166 Successful use of IPP depends on the client finding a 167 suitable IPP enabled Printer to which to send a IPP 168 requests, such as print a job. This task is simplified if 169 there is a Directory Service which can be queried for a 170 suitable Printer. The purpose of the Directory Schema is to 171 have a standard description of Printer attributes that can 172 be associated the the URI for the printer. These attributes 173 are a subset of the Model attributes and can be encoded in 174 the appropriate query syntax for the Directory Service being 175 used by the client. 176 6. Rationale For Security 177 Security is an areas of active work on the Internet. 178 Complete solutions to a wide range of security concerns are 179 not yet available. Therefore, in the design of IPP, the 180 focus has been on identifying a set of security 181 protocols/features that are implemented (or currently 182 implementable) and solve real problems with distributed 183 printing. The two areas that seem appropriate to support 184 are: (1) authorization to use a Printer and (2) secure 185 interaction with a printer. The chosen mechanisms are the 186 digest authentication mechanism of HTTP 1.1 and the SSL/TLS 187 secure communication mechanism, which also includes 188 authorization. 189 7. Author's Addresses 190 Stephen Zilles 191 Adobe Systems Incorporated 192 345 Park Avenue 193 MailStop W14 194 San Jose, CA 95110-2704 195 196 Phone: +1 408 536-4766 197 Fax: +1 408 537-4042 198 Email: szilles@adobe.com 199 Zilles [Page 6]