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