idnits 2.17.1 draft-ietf-ipp-rat-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. RATIONALE FOR THE MODEL' ) ** 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. ** There are 11 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 section? '1' on line 287 looks like a reference -- Missing reference section? '2' on line 290 looks like a reference -- Missing reference section? '3' on line 293 looks like a reference -- Missing reference section? '4' on line 295 looks like a reference -- Missing reference section? '5' on line 298 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 1 warning (==), 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 July 30, 1997 Expires: Jan 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 14 areas, and its working groups. Note that other groups may also 15 distribute 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- 20 Drafts as reference material or to cite them other than as ''work 21 in progress.'' 23 To learn the current status of any Internet-Draft, please check 24 the ''1id-abstracts.txt'' listing contained in the Internet- 25 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 26 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 27 Coast), or ftp.isi.edu (US West Coast). 29 ABSTRACT 31 This document is one of a set of documents which together 32 describe all aspects of a new Internet Printing Protocol (IPP). 33 IPP is an application level protocol that can be used for 34 distributed printing on the Internet. There are multiple parts 35 to IPP, but the primary architectural components are the Model, 36 the Protocol and an interface to Directory Services. This 37 document provides a high level overview of the architecture 38 and provides the rationale for the decisions made in 39 structuring the architecture. 41 The full set of IPP documents include: 43 Internet Printing Protocol/1.0: Requirements for an Internet 44 Printing Protocol 45 Internet Printing Protocol/1.0: Model and Semantics 46 Internet Printing Protocol/1.0: Security 47 Internet Printing Protocol/1.0: Protocol Specification 48 Internet Printing Protocol/1.0: Directory Schema 50 Expires: Jan 30, 1998 51 1. ARCHITECTURAL OVERVIEW 53 The Internet Printing Protocol (IPP) is an application level 54 protocol that can be used for distributed printing on the 55 Internet. This protocol defines interactions between a client 56 and a server. The client is provided the capability to inquire 57 about capabilities of a printer, to submit print jobs and to 58 inquire about and cancel print jobs. The server for these 59 requests is the Printer; the Printer is an abstraction a 60 generic document output device and/or a print service 61 provider. Thus, the Printer could be a real printing device, 62 such as a computer printer or fax output device, or it could 63 be a service that interfaced with output devices. 65 The architecture for IPP defines (in the Model document) an 66 abstract Model for the data which is used to control the 67 printing process and to provide information about the process 68 and the capabilities of the Printer. This abstract Model is 69 hierarchical in nature and reflects the structure of the 70 Printer and the Jobs that may be being processed by the 71 Printer. 73 The Internet provides a channel between the client and the 74 server/Printer. Use of this channel requires flattening and 75 sequencing the hierarchical Model data. Therefore, the IPP 76 also defines (in the Protocol document) an encoding of the 77 data in the model for transfer between the client and server. 78 This transfer of data may be either a request or the response 79 to a request. 81 Finally, the IPP defines (in the Protocol document) a protocol 82 for transfering the encoded request and response data between 83 the client and the server/Printer. 85 An example of a typical interaction would be a request from 86 the client to create a print job. The client would assemble 87 the Model data to be associated with that job, such as the 88 name of the job, the media to use, the number of pages to 89 place on each media instance, etc. This data would then be 90 encoded according to the Protocol and would be transmitted 91 according to the Protocol. The server/Printer would receive 92 the encoded Model data, decode it into a form understood by 93 the server/Printer and, based on that data, do one of two 94 things: (1) accept the job or (2) reject the job. In either 95 case, the server must construct a response in terms of the 96 Model data, encode that response according to the Protocol and 97 transmit that encoded Model data as the response to the 98 request using the Protocol. 100 Expires: Jan 30, 1998 101 Another part of the IPP architecture is the Directory Schema. 102 The role of the Directory Schema is to provide a standard set 103 of attributes which might be used to query a directory service 104 for the URI of a Printer that is likely to meet the needs of 105 the client. 107 The IPP architecture also addresses security issues such as 108 control of access to server/Printers and secure transmissions 109 of requests, response and the data to be printed. 111 2. THE PRINTER 113 Because the (abstract) server/Printer encompasses a wide range 114 of implementations, it is necessary to make some assumptions 115 about a minimal implementation. The most likely minimal 116 implementation is one that is embedded in an output device 117 running a specialized real time operating system and with 118 limited processing, memory and storage capabilities. This 119 Printer will be connected to the Internet and will have at 120 least a TCP/IP capability with (likely) SNMP support for the 121 Internet connection. In addition, it is likely the the Printer 122 will be an HTML/HTTP server to allow direct user access to 123 information about the printer. 125 3. RATIONALE FOR THE MODEL 127 The Model is defined independently of any encoding of the 128 Model data both to support the likely uses of IPP and to be 129 robust with respect to the possibility of alternate 130 encodings. 132 It is expected that a client or server/Printer would represent 133 the Model data in some data structure within the 134 applications/servers that support IPP. Therefore, the Model 135 was designed to make that representation 136 straightforward. Typically, a parser or formatter would be 137 used to convert from or to the encoded data format. Once in an 138 internal form suitable to a product, the data can be 139 manipulated by the product. For example, the data sent with a 140 Print Job can be used to control the processing of that Print 141 Job. 143 The semantics of IPP are attached to the (abstract) 144 Model. Therefore, the application/server is not dependent on 145 the encoding of the Model data, and it is possible to consider 146 alternative mechanisms and formats by which the data could be 147 transmitted from a client to a server; for example, a server 149 Expires: Jan 30, 1998 150 could have a direct, client-less GUI interface that might be 151 used to accept some kinds of Print Jobs. This independence 152 would also allow a different encoding and/or transmission 153 mechanism to be used if the ones adopted here were shown to be 154 overly limiting in the future. Such a change could be migrated 155 into new products as an alternate protocol stack/parser for 156 the Model data. 158 Having an abstract Model also allows the Model data to be 159 aligned with the (abstract) model used in the Printer, Job and 160 Host Resources MIBs. This provides consistency in 161 interpretation of the data obtained independently of how the 162 data is accessed, whether via IPP or via SNMP and the 163 Printer/Job MIBs. 165 4. RATIONALE FOR THE PROTOCOL 167 There are two parts to the Protocol: (1) the encoding of the 168 Model data and (2) the mechanism for transmitting the model 169 data between client and server. 171 4.1 The Encoding 173 To make it simpler to develop embedded printers, a very 174 simple binary encoding has been chosen. This encoding is 175 adequate to represent the kinds of data that occur within the 176 Model. It has a simple structure consisting of name value 177 pairs in which the names are length specified strings 178 constrained to characters from a subset of ASCII and the values 179 are either scalars or a sequence of scalars. Each scalar value 180 has a length specification and is represented either as an 4 181 byte integer or a string. 183 A fully encoded request/response has a version number, an 184 operation (for a request) or a status and optionally a status 185 message (for a response), associated parameters and attributes 186 which are encoded Model data and, optionally (for a request), 187 print data following the Model data. 189 4.2 The Transmission Mechanism 191 The chosen mechanism for transmitting the encoded Model data 192 is HTTP 1.1 Post (and associated response). No modifications 193 to HTTP 1.1 are proposed or required. 195 The sole role of the Transmission Mechanism is to provide a 196 transfer of encoded Model data from/to the client to/from the 197 server. This could be done using any data delivery mechanism. 198 The key reasons why HTTP 1.1 Post is used are given below. The 200 Expires: Jan 30, 1998 201 most important of these is the first. With perhaps this 202 exception, these reasons could be satisfied by other 203 mechanisms. There is no claim that this list uniquely 204 determines a choice of mechanism. 206 1. HTTP 1.0 is already widely deployed and, based on the 207 recent evidence, HTTP 1.1 will be widely deployed as the 208 manufacturers release new products. The performance 209 benefits of HTTP 1.1 have been shown and manufactures 210 are reacting postively. 212 Wide deployment has meant that many of the problems of 213 making a protocol work in a wide range of environments 214 from local net to intranet to internet have been solved 215 and will stay solved with HTTP 1.1 deployment. 217 2. HTTP 1.1 solves most of the problems that might have 218 required a new protocol to be developed. HTTP 1.1 allows 219 persistent connections that make a multi-message 220 protocol be more efficient; for example it is practical 221 to have a separate CreatJob and SendJob 222 messages. Chunking allows the transmission of large 223 print files without having to prescan the file to 224 determine the file length. The accept headers allow the 225 client's protocol and localization desires to be 226 transmitted with the IPP operations and data. If the 227 Model were to provide for the redirection of Job 228 requests, such as Cancel-Job, when a Job is moved, the 229 HTTP redirect response allows a client to be informed 230 when a Job he is interested in is moved to another 231 server/Printer for any reason. 233 3. Most network Printers will be implementing HTTP servers 234 for reasons other than IPP. These network attached 235 Printers want to provide information on how to use the 236 printer, its current state, etc. in HTML. This requires 237 having an HTTP server which would be available to do IPP 238 functions as well. 240 4. Most of the complexity of HTTP 1.1 is concerned with the 241 implementation of proxies and not the implementation of 242 clients and/or servers. Work is proceding in the HTTP 243 Working Group to help identify what must be done by a 244 server. As the Protocol document shows, that is not very 245 much. 247 5. An HTTP based solution fits well with the Internet 248 security mechanism that are currently deployed or being 249 deployed. HTTP will run over SSL/TLS. The digest 251 Expires: Jan 30, 1998 252 authentication mechanism of HTTP 1.1 provides an 253 adequate level of access control (at least for intranet 254 usage). These solutions are deployed and in practical 255 use; a new solution would require extensive use to have 256 the same degree of confidence in its security. 258 5. RATIONALE FOR THE DIRECTORY SCHEMA 260 Successful use of IPP depends on the client finding a 261 suitable IPP enabled Printer to which to send a IPP requests, 262 such as print a job. This task is simplified if there is a 263 Directory Service which can be queried for a suitable 264 Printer. The purpose of the Directory Schema is to have a 265 standard description of Printer attributes that can be 266 associated the the URI for the printer. These attributes are a 267 subset of the Model attributes and can be encoded in the 268 appropriate query syntax for the Directory Service being used 269 by the client. 271 6. RATIONALE FOR SECURITY 273 Security is an areas of active work on the Internet. Complete 274 solutions to a wide range of security concerns are not yet 275 available. Therefore, in the design of IPP, the focus has been 276 on identifying a set of security protocols/features that are 277 implemented (or currently implementable) and solve real 278 problems with distributed printing. The two areas that seem 279 appropriate to support are: (1) authorization to use a Printer 280 and (2) secure interaction with a printer. The chosen 281 mechanisms are the digest authentication mechanism of HTTP 1.1 282 and the SSL/TLS secure communication mechanism, which also 283 includes authorization. 285 7. REFERENCES 287 [1] Wright, F. D., "Requirements for an Internet Printing 288 Protocol:" 290 [2] Isaacson, S, deBry, R, Hasting, T, Herriot, R, Powell, P, 291 "Internet Printing Protocol/1.0: Model and Semantics" 293 [3] Internet Printing Protocol/1.0: Security 295 [4] Herriot, R, Butler, S, Moore, P, Turner, R, "Internet 296 Printing Protocol/1.0: Protocol Specification" 298 [5] Carter, K, Isaacson, S, "Internet Printing Protocol/1.0: 299 Directory Schema" 301 Expires: Jan 30, 1998 303 8. AUTHORS ADDRESS 305 Stephen Zilles 306 Adobe Systems Incorporated 307 345 Park Avenue 308 MailStop W14 309 San Jose, CA 95110-2704 311 Phone: +1 408 536-4766 312 Fax: +1 408 537-4042 313 Email: szilles@adobe.com 315 + 317 Expires: Jan 30, 1998