draft-ietf-ipp-rat-00.txt   draft-ietf-ipp-rat-01.txt 
Adobe Systems Inc.
July 14, 1997 INTERNET DRAFT Stephen N. Zilles
<draft-ietf-ipp-rat-01.txt> Adobe Systems Inc.
July 30, 1997 Expires: Jan 30, 1998
Rationale for the Structure of the Model and Protocol Rationale for the Structure of the Model and Protocol
for the Internet Printing Protocol (IPP) for the Internet Printing Protocol
<draft-ietf-ipp-rat-00.txt>
Expires Jan 14, 1998 STATUS OF THIS MEMO
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its
and its working groups. Note that other groups may also distribute areas, and its working groups. Note that other groups may also
working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-
as reference material or to cite them other than as "work in Drafts as reference material or to cite them other than as ''work
progress." 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 To learn the current status of any Internet-Draft, please check
This document is one of a set of documents which together describe all the ''1id-abstracts.txt'' listing contained in the Internet-
aspects of a new Internet Printing Protocol (IPP). IPP is an application Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
level protocol that can be used for distributed printing on the (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Internet. There are multiple parts to IPP, but the primary architectural Coast), or ftp.isi.edu (US West Coast).
components are the Model, the Protocol and an interface to Directory
Services. This document provides a high level overview of the ABSTRACT
architecture and provides the rational for the decisions made in
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 rationale for the decisions made in
structuring the architecture. structuring the architecture.
The full set of IPP documents include: The full set of IPP documents include:
Internet Printing Protocol/1.0: Requirements
Internet Printing Protocol/1.0: Requirements for an Internet
Printing Protocol
Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Model and Semantics
Internet Printing Protocol/1.0: Security Internet Printing Protocol/1.0: Security
Internet Printing Protocol/1.0: Protocol Specification Internet Printing Protocol/1.0: Protocol Specification
Internet Printing Protocol/1.0: Directory Schema Internet Printing Protocol/1.0: Directory Schema
Rationale for the Structure of the Model and Protocol July 14, 1997
TABLE OF CONTENTS Expires: Jan 30, 1998
1. ARCHITECTURAL OVERVIEW
1. ARCHITECTURAL OVERVIEW..............................................3 The Internet Printing Protocol (IPP) is an application level
protocol that can be used for distributed printing on the
Internet. This protocol defines interactions between a client
and a server. The client is provided the capability to inquire
about capabilities of a printer, to submit print jobs and to
inquire about and cancel print jobs. The server for these
requests is the Printer; the Printer is an abstraction a
generic document output device and/or a print service
provider. Thus, the Printer could be a real printing device,
such as a computer printer or fax output device, or it could
be a service that interfaced with output devices.
2. THE PRINTER.........................................................4 The architecture for IPP defines (in the Model document) an
abstract Model for the data which is used to control the
printing process and to provide information about the process
and the capabilities of the Printer. This abstract Model is
hierarchical in nature and reflects the structure of the
Printer and the Jobs that may be being processed by the
Printer.
3. RATIONAL FOR THE MODEL..............................................4 The Internet provides a channel between the client and the
server/Printer. Use of this channel requires flattening and
sequencing the hierarchical Model data. Therefore, the IPP
also defines (in the Protocol document) an encoding of the
data in the model for transfer between the client and server.
This transfer of data may be either a request or the response
to a request.
4. RATIONAL FOR THE PROTOCOL...........................................5 Finally, the IPP defines (in the Protocol document) a protocol
for transfering the encoded request and response data between
the client and the server/Printer.
4.1 The Encoding .....................................................5 An example of a typical interaction would be a request from
the client to create a print job. The client would assemble
the Model data to be associated with that job, such as the
name of the job, the media to use, the number of pages to
place on each media instance, etc. This data would then be
encoded according to the Protocol and would be transmitted
according to the Protocol. The server/Printer would receive
the encoded Model data, decode it into a form understood by
the server/Printer and, based on that data, do one of two
things: (1) accept the job or (2) reject the job. In either
case, the server must construct a response in terms of the
Model data, encode that response according to the Protocol and
transmit that encoded Model data as the response to the
request using the Protocol.
4.2 Smission Mechanism ...............................................5 Expires: Jan 30, 1998
Another part of the IPP architecture is the Directory Schema.
The role of the Directory Schema is to provide a standard set
of attributes which might be used to query a directory service
for the URI of a Printer that is likely to meet the needs of
the client.
5. RATIONAL FOR THE DIRECTORY SCHEMA...................................6 The IPP architecture also addresses security issues such as
control of access to server/Printers and secure transmissions
of requests, response and the data to be printed.
6. RATIONAL FOR SECURITY...............................................6 2. THE PRINTER
7. AUTHOR'S ADDRESSES..................................................7 Because the (abstract) server/Printer encompasses a wide range
Rationale for the Structure of the Model and Protocol July 14, 1997 of implementations, it is necessary to make some assumptions
about a minimal implementation. The most likely minimal
implementation is one that is embedded in an output device
running a specialized real time operating system and with
limited processing, memory and storage capabilities. This
Printer will be connected to the Internet and will have at
least a TCP/IP capability with (likely) SNMP support for the
Internet connection. In addition, it is likely the the Printer
will be an HTML/HTTP server to allow direct user access to
information about the printer.
1 Rationale for the Structure of the Model and Protocol 3. RATIONALE FOR THE MODEL
2 for the Internet Printing Protocol (IPP)
3 1. Architectural Overview The Model is defined independently of any encoding of the
4 The Internet Printing Protocol (IPP) is an application level Model data both to support the likely uses of IPP and to be
5 protocol that can be used for distributed printing on the robust with respect to the possibility of alternate
6 Internet. This protocol defines interactions between a encodings.
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.
Rationale for the Structure of the Model and Protocol July 14, 1997 It is expected that a client or server/Printer would represent
the Model data in some data structure within the
applications/servers that support IPP. Therefore, the Model
was designed to make that representation
straightforward. Typically, a parser or formatter would be
used to convert from or to the encoded data format. Once in an
internal form suitable to a product, the data can be
manipulated by the product. For example, the data sent with a
Print Job can be used to control the processing of that Print
Job.
54 2. The Printer The semantics of IPP are attached to the (abstract)
55 Because the (abstract) server/Printer encompasses a wide Model. Therefore, the application/server is not dependent on
56 range of implementations, it is necessary to make some the encoding of the Model data, and it is possible to consider
57 assumptions about a minimal implementation. The most likely alternative mechanisms and formats by which the data could be
58 minimal implementation is one that is embedded in an output transmitted from a client to a server; for example, a server
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 Expires: Jan 30, 1998
67 The Model is defined independently of any encoding of the could have a direct, client-less GUI interface that might be
68 Model data both to support the likely uses of IPP and to be used to accept some kinds of Print Jobs. This independence
69 robust with respect to the possibility of alternate would also allow a different encoding and/or transmission
70 encodings. mechanism to be used if the ones adopted here were shown to be
71 It is expected that a client or server/Printer would overly limiting in the future. Such a change could be migrated
72 represent the Model data in some data structure within the into new products as an alternate protocol stack/parser for
73 applications/servers that support IPP. Therefore, the Model the Model data.
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 Having an abstract Model also allows the Model data to be
99 There are two parts to the Protocol: (1) the encoding of the aligned with the (abstract) model used in the Printer, Job and
100 Model data and (2) the mechanism for transmitting the model Host Resources MIBs. This provides consistency in
101 data between client and server. interpretation of the data obtained independently of how the
data is accessed, whether via IPP or via SNMP and the
Printer/Job MIBs.
102 4.1 The Encoding 4. RATIONALE FOR THE PROTOCOL
103 The TranTo make it simpler to develop embedded printers, a
104 very simple binary encoding has been chosen. This encoding
Rationale for the Structure of the Model and Protocol July 14, 1997
105 is adequate to represent the kinds of data that occur within There are two parts to the Protocol: (1) the encoding of the
106 the Model. It has a simple structure consisting of name Model data and (2) the mechanism for transmitting the model
107 value pairs in which the names are length specified strings data between client and server.
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 4.1 The Encoding
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.
Rationale for the Structure of the Model and Protocol July 14, 1997 To make it simpler to develop embedded printers, a very
simple binary encoding has been chosen. This encoding is
adequate to represent the kinds of data that occur within the
Model. It has a simple structure consisting of name value
pairs in which the names are length specified strings
constrained to characters from a subset of ASCII and the values
are either scalars or a sequence of scalars. Each scalar value
has a length specification and is represented either as an 4
byte integer or a string.
157 6. An HTTP based solution fits will with the Internet A fully encoded request/response has a version number, an
158 security mechanism that are currently deployed or being operation (for a request) or a status and optionally a status
159 deployed. HTTP will run over SSL/TLS. The digest message (for a response), associated parameters and attributes
160 authentication mechanism of HTTP 1.1 provides an adequate which are encoded Model data and, optionally (for a request),
161 level of access control (at least for intranet usage). print data following the Model data.
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 4.2 The Transmission Mechanism
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 The chosen mechanism for transmitting the encoded Model data
177 Security is an areas of active work on the Internet. is HTTP 1.1 Post (and associated response). No modifications
178 Complete solutions to a wide range of security concerns are to HTTP 1.1 are proposed or required.
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 The sole role of the Transmission Mechanism is to provide a
190 Stephen Zilles transfer of encoded Model data from/to the client to/from the
191 Adobe Systems Incorporated server. This could be done using any data delivery mechanism.
192 345 Park Avenue The key reasons why HTTP 1.1 Post is used are given below. The
193 MailStop W14
194 San Jose, CA 95110-2704 Expires: Jan 30, 1998
195 most important of these is the first. With perhaps this
196 Phone: +1 408 536-4766 exception, these reasons could be satisfied by other
197 Fax: +1 408 537-4042 mechanisms. There is no claim that this list uniquely
198 Email: szilles@adobe.com determines a choice of mechanism.
199
1. HTTP 1.0 is already widely deployed and, based on the
recent evidence, HTTP 1.1 will be widely deployed as the
manufacturers release new products. The performance
benefits of HTTP 1.1 have been shown and manufactures
are reacting postively.
Wide deployment has meant that many of the problems of
making a protocol work in a wide range of environments
from local net to intranet to internet have been solved
and will stay solved with HTTP 1.1 deployment.
2. HTTP 1.1 solves most of the problems that might have
required a new protocol to be developed. HTTP 1.1 allows
persistent connections that make a multi-message
protocol be more efficient; for example it is practical
to have a separate CreatJob and SendJob
messages. Chunking allows the transmission of large
print files without having to prescan the file to
determine the file length. The accept headers allow the
client's protocol and localization desires to be
transmitted with the IPP operations and data. If the
Model were to provide for the redirection of Job
requests, such as Cancel-Job, when a Job is moved, the
HTTP redirect response allows a client to be informed
when a Job he is interested in is moved to another
server/Printer for any reason.
3. Most network Printers will be implementing HTTP servers
for reasons other than IPP. These network attached
Printers want to provide information on how to use the
printer, its current state, etc. in HTML. This requires
having an HTTP server which would be available to do IPP
functions as well.
4. Most of the complexity of HTTP 1.1 is concerned with the
implementation of proxies and not the implementation of
clients and/or servers. Work is proceding in the HTTP
Working Group to help identify what must be done by a
server. As the Protocol document shows, that is not very
much.
5. An HTTP based solution fits well with the Internet
security mechanism that are currently deployed or being
deployed. HTTP will run over SSL/TLS. The digest
Expires: Jan 30, 1998
authentication mechanism of HTTP 1.1 provides an
adequate level of access control (at least for intranet
usage). These solutions are deployed and in practical
use; a new solution would require extensive use to have
the same degree of confidence in its security.
5. RATIONALE FOR THE DIRECTORY SCHEMA
Successful use of IPP depends on the client finding a
suitable IPP enabled Printer to which to send a IPP requests,
such as print a job. This task is simplified if there is a
Directory Service which can be queried for a suitable
Printer. The purpose of the Directory Schema is to have a
standard description of Printer attributes that can be
associated the the URI for the printer. These attributes are a
subset of the Model attributes and can be encoded in the
appropriate query syntax for the Directory Service being used
by the client.
6. RATIONALE FOR SECURITY
Security is an areas of active work on the Internet. Complete
solutions to a wide range of security concerns are not yet
available. Therefore, in the design of IPP, the focus has been
on identifying a set of security protocols/features that are
implemented (or currently implementable) and solve real
problems with distributed printing. The two areas that seem
appropriate to support are: (1) authorization to use a Printer
and (2) secure interaction with a printer. The chosen
mechanisms are the digest authentication mechanism of HTTP 1.1
and the SSL/TLS secure communication mechanism, which also
includes authorization.
7. REFERENCES
[1] Wright, F. D., "Requirements for an Internet Printing
Protocol:"
[2] Isaacson, S, deBry, R, Hasting, T, Herriot, R, Powell, P,
"Internet Printing Protocol/1.0: Model and Semantics"
[3] Internet Printing Protocol/1.0: Security
[4] Herriot, R, Butler, S, Moore, P, Turner, R, "Internet
Printing Protocol/1.0: Protocol Specification"
[5] Carter, K, Isaacson, S, "Internet Printing Protocol/1.0:
Directory Schema"
Expires: Jan 30, 1998
8. AUTHORS ADDRESS
Stephen Zilles
Adobe Systems Incorporated
345 Park Avenue
MailStop W14
San Jose, CA 95110-2704
Phone: +1 408 536-4766
Fax: +1 408 537-4042
Email: szilles@adobe.com
+
Expires: Jan 30, 1998
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/