]>
Commit | Line | Data |
---|---|---|
ef416fc2 | 1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group S. Zilles | |
8 | Request for Comments: 2568 Adobe Systems Inc. | |
9 | Category: Experimental April 1999 | |
10 | ||
11 | ||
12 | Rationale for the Structure of the Model and Protocol | |
13 | for the Internet Printing Protocol | |
14 | ||
15 | Status of this Memo | |
16 | ||
17 | This memo defines an Experimental Protocol for the Internet | |
18 | community. It does not specify an Internet standard of any kind. | |
19 | Discussion and suggestions for improvement are requested. | |
20 | Distribution of this memo is unlimited. | |
21 | ||
22 | Copyright Notice | |
23 | ||
24 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
25 | ||
26 | IESG Note | |
27 | ||
28 | This document defines an Experimental protocol for the Internet | |
29 | community. The IESG expects that a revised version of this protocol | |
30 | will be published as Proposed Standard protocol. The Proposed | |
31 | Standard, when published, is expected to change from the protocol | |
32 | defined in this memo. In particular, it is expected that the | |
33 | standards-track version of the protocol will incorporate strong | |
34 | authentication and privacy features, and that an "ipp:" URL type will | |
35 | be defined which supports those security measures. Other changes to | |
36 | the protocol are also possible. Implementors are warned that future | |
37 | versions of this protocol may not interoperate with the version of | |
38 | IPP defined in this document, or if they do interoperate, that some | |
39 | protocol features may not be available. | |
40 | ||
41 | The IESG encourages experimentation with this protocol, especially in | |
42 | combination with Transport Layer Security (TLS) [RFC2246], to help | |
43 | determine how TLS may effectively be used as a security layer for | |
44 | IPP. | |
45 | ||
46 | ABSTRACT | |
47 | ||
48 | This document is one of a set of documents, which together describe | |
49 | all aspects of a new Internet Printing Protocol (IPP). IPP is an | |
50 | application level protocol that can be used for distributed printing | |
51 | using Internet tools and technologies. This document describes IPP | |
52 | from a high level view, defines a roadmap for the various documents | |
53 | that form the suite of IPP specifications, and gives background and | |
54 | rationale for the IETF working group's major decisions. | |
55 | ||
56 | ||
57 | ||
58 | Zilles Experimental [Page 1] | |
59 | \f | |
60 | RFC 2568 Rationale for IPP April 1999 | |
61 | ||
62 | ||
63 | The full set of IPP documents includes: | |
64 | ||
65 | Design Goals for an Internet Printing Protocol [RFC2567] | |
66 | Rationale for the Structure and Model and Protocol for the | |
67 | Internet Printing Protocol (this document) | |
68 | Internet Printing Protocol/1.0: Model and Semantics [RFC2566] | |
69 | Internet Printing Protocol/1.0: Encoding and Transport [RFC2565] | |
70 | Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig] | |
71 | Mapping between LPD and IPP Protocols [RFC2569] | |
72 | ||
73 | The "Design Goals for an Internet Printing Protocol" document takes a | |
74 | broad look at distributed printing functionality, and it enumerates | |
75 | real-life scenarios that help to clarify the features that need to be | |
76 | included in a printing protocol for the Internet. It identifies | |
77 | requirements for three types of users: end users, operators, and | |
78 | administrators. The Design Goals document calls out a subset of end | |
79 | user requirements that are satisfied in IPP/1.0. Operator and | |
80 | administrator requirements are out of scope for version 1.0. | |
81 | ||
82 | The "Internet Printing Protocol/1.0: Model and Semantics" document | |
83 | describes a simplified model consisting of abstract objects, their | |
84 | attributes, and their operations that is independent of encoding and | |
85 | transport. The model consists of a Printer and a Job object. The | |
86 | Job optionally supports multiple documents. This document also | |
87 | addresses security, internationalization, and directory issues. | |
88 | ||
89 | The "Internet Printing Protocol/1.0: Encoding and Transport" document | |
90 | is a formal mapping of the abstract operations and attributes defined | |
91 | in the model document onto HTTP/1.1. It defines the encoding rules | |
92 | for a new Internet media type called "application/ipp". | |
93 | ||
94 | The "Internet Printing Protocol/1.0: Implementer's Guide" document | |
95 | gives insight and advice to implementers of IPP clients and IPP | |
96 | objects. It is intended to help them understand IPP/1.0 and some of | |
97 | the considerations that may assist them in the design of their client | |
98 | and/or IPP object implementations. For example, a typical order of | |
99 | processing requests is given, including error checking. Motivation | |
100 | for some of the specification decisions is also included. | |
101 | ||
102 | The "Mapping between LPD and IPP Protocols" document gives some | |
103 | advice to implementers of gateways between IPP and LPD (Line Printer | |
104 | Daemon) implementations. | |
105 | ||
106 | 1. ARCHITECTURAL OVERVIEW | |
107 | ||
108 | The Internet Printing Protocol (IPP) is an application level protocol | |
109 | that can be used for distributed printing on the Internet. This | |
110 | protocol defines interactions between a client and a server. The | |
111 | ||
112 | ||
113 | ||
114 | Zilles Experimental [Page 2] | |
115 | \f | |
116 | RFC 2568 Rationale for IPP April 1999 | |
117 | ||
118 | ||
119 | protocol allows a client to inquire about capabilities of a printer, | |
120 | to submit print jobs and to inquire about and cancel print jobs. The | |
121 | server for these requests is the Printer; the Printer is an | |
122 | abstraction of a generic document output device and/or a print | |
123 | service provider. Thus, the Printer could be a real printing device, | |
124 | such as a computer printer or fax output device, or it could be a | |
125 | service that interfaced with output devices. | |
126 | ||
127 | The protocol is heavily influenced by the printing model introduced | |
128 | in the Document Printing Application (DPA) [ISO10175] standard. | |
129 | Although DPA specifies both end user and administrative features, IPP | |
130 | version 1.0 (IPP/1.0) focuses only on end user functionality. | |
131 | ||
132 | The architecture for IPP defines (in the Model and Semantics document | |
133 | [RFC2566]) an abstract Model for the data which is used to control | |
134 | the printing process and to provide information about the process and | |
135 | the capabilities of the Printer. This abstract Model is hierarchical | |
136 | in nature and reflects the structure of the Printer and the Jobs that | |
137 | may be being processed by the Printer. | |
138 | ||
139 | The Internet provides a channel between the client and the | |
140 | server/Printer. Use of this channel requires flattening and | |
141 | sequencing the hierarchical Model data. Therefore, the IPP also | |
142 | defines (in the Encoding and Transport document [RFC2565]) an | |
143 | encoding of the data in the model for transfer between the client and | |
144 | server. This transfer of data may be either a request or the | |
145 | response to a request. | |
146 | ||
147 | Finally, the IPP defines (in the Encoding and Transport document | |
148 | [RFC2565]) a protocol for transferring the encoded request and | |
149 | response data between the client and the server/Printer. | |
150 | ||
151 | An example of a typical interaction would be a request from the | |
152 | client to create a print job. The client would assemble the Model | |
153 | data to be associated with that job, such as the name of the job, the | |
154 | media to use, the number of pages to place on each media instance, | |
155 | etc. This data would then be encoded according to the Protocol and | |
156 | would be transmitted according to the Protocol. The server/Printer | |
157 | would receive the encoded Model data, decode it into a form | |
158 | understood by the server/Printer and, based on that data, do one of | |
159 | two things: (1) accept the job or (2) reject the job. In either case, | |
160 | the server must construct a response in terms of the Model data, | |
161 | encode that response according to the Protocol and transmit that | |
162 | encoded Model data as the response to the request using the Protocol. | |
163 | ||
164 | Another part of the IPP architecture is the Directory Schema | |
165 | described in the model document. The role of a Directory Schema is to | |
166 | provide a standard set of attributes which might be used to query a | |
167 | ||
168 | ||
169 | ||
170 | Zilles Experimental [Page 3] | |
171 | \f | |
172 | RFC 2568 Rationale for IPP April 1999 | |
173 | ||
174 | ||
175 | directory service for the URI of a Printer that is likely to meet the | |
176 | needs of the client. The IPP architecture also addresses security | |
177 | issues such as control of access to server/Printers and secure | |
178 | transmissions of requests, response and the data to be printed. | |
179 | ||
180 | 2. THE PRINTER | |
181 | ||
182 | Because the (abstract) server/Printer encompasses a wide range of | |
183 | implementations, it is necessary to make some assumptions about a | |
184 | minimal implementation. The most likely minimal implementation is one | |
185 | that is embedded in an output device running a specialized real time | |
186 | operating system and with limited processing, memory and storage | |
187 | capabilities. This printer will be connected to the Internet and will | |
188 | have at least a TCP/IP capability with (likely) SNMP [RFC1905, | |
189 | RFC1906] support for the Internet connection. In addition, it is | |
190 | likely the the Printer will be an HTML/HTTP server to allow direct | |
191 | user access to information about the printer. | |
192 | ||
193 | 3. RATIONALE FOR THE MODEL | |
194 | ||
195 | The Model [RFC2566] is defined independently of any encoding of the | |
196 | Model data both to support the likely uses of IPP and to be robust | |
197 | with respect to the possibility of alternate encoding. | |
198 | ||
199 | It is expected that a client or server/Printer would represent the | |
200 | Model data in some data structure within the applications/servers | |
201 | that support IPP. Therefore, the Model was designed to make that | |
202 | representation straightforward. Typically a parser or formatter would | |
203 | be used to convert from or to the encoded data format. Once in an | |
204 | internal form suitable to a product, the data can be manipulated by | |
205 | the product. For example, the data sent with a Print Job can be used | |
206 | to control the processing of that Print Job. | |
207 | ||
208 | The semantics of IPP are attached to the (abstract) Model. | |
209 | Therefore, the application/server is not dependent on the encoding of | |
210 | the Model data, and it is possible to consider alternative mechanisms | |
211 | and formats by which the data could be transmitted from a client to a | |
212 | server; for example, a server could have a direct, client-less GUI | |
213 | interface that might be used to accept some kinds of Print Jobs. This | |
214 | independence would also allow a different encoding and/or | |
215 | transmission mechanism to be used if the ones adopted here were shown | |
216 | to be overly limiting in the future. Such a change could be migrated | |
217 | into new products as an alternate protocol stack/parser for the Model | |
218 | data. | |
219 | ||
220 | ||
221 | ||
222 | ||
223 | ||
224 | ||
225 | ||
226 | Zilles Experimental [Page 4] | |
227 | \f | |
228 | RFC 2568 Rationale for IPP April 1999 | |
229 | ||
230 | ||
231 | Having an abstract Model also allows the Model data to be aligned | |
232 | with the (abstract) model used in the Printer [RFC1759], Job and Host | |
233 | Resources MIBs. This provides consistency in interpretation of the | |
234 | data obtained independently of how the data is accessed, whether via | |
235 | IPP or via SNMP [RFC1905, RFC1906] and the Printer/Job MIBs. | |
236 | ||
237 | There is one aspect of the Model that deserves some extra | |
238 | explanation. There are two ways for identifying a Job object: (a) | |
239 | with a Job URI and (b) using a combination of the Printer URI and a | |
240 | Job ID (a 32 bit positive integer). Allowing Job objects to have URIs | |
241 | allows for flexibility and scalability. For example a job could be | |
242 | moved from a printer with a large backlog to one with a smaller load | |
243 | and the job identification, the Job object URI, need not change. | |
244 | However, many existing printing systems have local models or | |
245 | interface constraints that force Job objects to be identified using | |
246 | only a 32-bit positive integer rather than a URI. This numeric Job | |
247 | ID is only unique within the context of the Printer object to which | |
248 | the create request was originally submitted. In order to allow both | |
249 | types of client access to Jobs (either by Job URI or by numeric Job | |
250 | ID), when the Printer object successfully processes a create request | |
251 | and creates a new Job, the Printer object generates both a Job URI | |
252 | and a Job ID for the new Job object. This requirement allows all | |
253 | clients to access Printer objects and Job objects independent of any | |
254 | local constraints imposed on the client implementation. | |
255 | ||
256 | 4. RATIONALE FOR THE PROTOCOL | |
257 | ||
258 | There are two parts to the Protocol: (1) the encoding of the Model | |
259 | data and (2) the mechanism for transmitting the model data between | |
260 | client and server. | |
261 | ||
262 | 4.1 The Encoding | |
263 | ||
264 | To make it simpler to develop embedded printers, a very simple binary | |
265 | encoding has been chosen. This encoding is adequate to represent the | |
266 | kinds of data that occur within the Model. It has a simple structure | |
267 | consisting of sequences of attributes. Each attribute has a name, | |
268 | prefixed by a name length, and a value. The names are strings | |
269 | constrained to characters from a subset of ASCII. The values are | |
270 | either scalars or a sequence of scalars. Each scalar value has a | |
271 | length specification and a value tag which indicates the type of the | |
272 | value. The value type has two parts: a major class part, such as | |
273 | integer or string, and a minor class part which distinguishes the | |
274 | usage of the major class, such as dateTime string. Tagging of the | |
275 | values with type information allows for introducing new value types | |
276 | at some future time. | |
277 | ||
278 | ||
279 | ||
280 | ||
281 | ||
282 | Zilles Experimental [Page 5] | |
283 | \f | |
284 | RFC 2568 Rationale for IPP April 1999 | |
285 | ||
286 | ||
287 | A fully encoded request/response has a version number, an operation | |
288 | (for a request) or a status and optionally a status message (for a | |
289 | response), associated parameters and attributes which are encoded | |
290 | Model data and, optionally (for a request), print data following the | |
291 | Model data. | |
292 | ||
293 | 4.2 The Transmission Mechanism | |
294 | ||
295 | The chosen mechanism for transmitting the encoded Model data is HTTP | |
296 | 1.1 Post (and associated response). No modifications to HTTP 1.1 are | |
297 | proposed or required. The sole role of the Transmission Mechanism is | |
298 | to provide a transfer of encoded Model data from/to the client | |
299 | to/from the server. This could be done using any data delivery | |
300 | mechanism. The key reasons why HTTP 1.1 Post is used are given below. | |
301 | The most important of these is the first. With perhaps this | |
302 | exception, these reasons could be satisfied by other mechanisms. | |
303 | There is no claim that this list uniquely determines a choice of | |
304 | mechanism. | |
305 | ||
306 | 1. HTTP 1.0 is already widely deployed and, based on the recent | |
307 | evidence, HTTP 1.1 is being widely deployed as the manufacturers | |
308 | release new products. The performance benefits of HTTP 1.1 have | |
309 | been shown and manufactures are reacting positively. | |
310 | ||
311 | Wide deployment has meant that many of the problems of making a | |
312 | protocol work in a wide range of environments from local net to | |
313 | Intranet to Internet have been solved and will stay solved with | |
314 | HTTP 1.1 deployment. | |
315 | ||
316 | 2. HTTP 1.1 solves most of the problems that might have required a | |
317 | new protocol to be developed. HTTP 1.1 allows persistent | |
318 | connections that make a multi-message protocol be more efficient; | |
319 | for example it is practical to have separate Create-Job and Send- | |
320 | Document messages. Chunking allows the transmission of large print | |
321 | files without having to pre-scan the file to determine the file | |
322 | length. The accept headers allow the client's protocol and | |
323 | localization desires to be transmitted with the IPP operations and | |
324 | data. If the Model were to provide for the redirection of Job | |
325 | requests, such as Cancel-Job, when a Job is moved, the HTTP | |
326 | redirect response allows a client to be informed when a Job he is | |
327 | interested in is moved to another server/Printer for any reason. | |
328 | ||
329 | 3. Most network Printers will be implementing HTTP servers for | |
330 | reasons other than IPP. These network attached Printers want to | |
331 | provide information on how to use the printer, its current state, | |
332 | HELP information, etc. in HTML. This requires having an HTTP | |
333 | server which would be available to do IPP functions as well. | |
334 | ||
335 | ||
336 | ||
337 | ||
338 | Zilles Experimental [Page 6] | |
339 | \f | |
340 | RFC 2568 Rationale for IPP April 1999 | |
341 | ||
342 | ||
343 | 4. Most of the complexity of HTTP 1.1 is concerned with the | |
344 | implementation of HTTP proxies and not the implementation of HTTP | |
345 | clients and/or servers. Work is proceeding in the HTTP Working | |
346 | Group to help identify what must be done by a server. As the | |
347 | Encoding and Transport document shows, that is not very much. | |
348 | ||
349 | 5. HTTP implementations provide support for handling URLs that | |
350 | would have to be provided if a new protocol were defined. | |
351 | ||
352 | 6. An HTTP based solution fits well with the Internet security | |
353 | mechanisms that are currently deployed or being deployed. HTTP | |
354 | will run over SSL3. The digest access authentication mechanism of | |
355 | HTTP 1.1 provides an adequate level of access control. These | |
356 | solutions are deployed and in practical use; a new solution would | |
357 | require extensive use to have the same degree of confidence in its | |
358 | security. Note: SSL3 is not on the IETF standards track. | |
359 | ||
360 | 7. HTTP provides an extensibility model that a new protocol would | |
361 | have to develop independently. In particular, the headers, | |
362 | intent-types (via Internet Media Types) and error codes have wide | |
363 | acceptance and a useful set of definitions and methods for | |
364 | extension. | |
365 | ||
366 | 8. Although not strictly a reason why IPP should use HTTP as the | |
367 | transmission protocol, it is extremely helpful that there are many | |
368 | prototyping tools that work with HTTP and that CGI scripts can be | |
369 | used to test and debug parts of the protocol. | |
370 | ||
371 | 9. Finally, the POST method was chosen to carry the print data | |
372 | because its usage for data transmission has been established, it | |
373 | works and the results are available via CGI scripts or servlets. | |
374 | Creating a new method would have better identified the intended | |
375 | use of the POSTed data, but a new method would be more difficult | |
376 | to deploy. Assigning a new default port for IPP provided the | |
377 | necessary identification with minimal impact to installed | |
378 | infrastructure, so was chosen instead. | |
379 | ||
380 | 5. RATIONALE FOR THE DIRECTORY SCHEMA | |
381 | ||
382 | Successful use of IPP depends on the client finding a suitable IPP | |
383 | enabled Printer to which to send a IPP requests, such as print a | |
384 | job. This task is simplified if there is a Directory Service which | |
385 | can be queried for a suitable Printer. The purpose of the | |
386 | Directory Schema is to have a standard description of Printer | |
387 | attributes that can be associated the URI for the printer. These | |
388 | attributes are a subset of the Model attributes and can be encoded | |
389 | in the appropriate query syntax for the Directory Service being | |
390 | used by the client. | |
391 | ||
392 | ||
393 | ||
394 | Zilles Experimental [Page 7] | |
395 | \f | |
396 | RFC 2568 Rationale for IPP April 1999 | |
397 | ||
398 | ||
399 | 6. SECURITY CONSIDERATIONS - RATIONALE FOR SECURITY | |
400 | ||
401 | Security is an area of active work on the Internet. Complete | |
402 | solutions to a wide range of security concerns are not yet | |
403 | available. Therefore, in the design of IPP, the focus has been on | |
404 | identifying a set of security protocols/features that are | |
405 | implemented (or currently implementable) and solve real problems | |
406 | with distributed printing. The two areas that seem appropriate to | |
407 | support are: (1) authorization to use a Printer and (2) secure | |
408 | interaction with a printer. The chosen mechanisms are the digest | |
409 | authentication mechanism of HTTP 1.1 and SSL3 [SSL] secure | |
410 | communication mechanism. | |
411 | ||
412 | 7. REFERENCES | |
413 | ||
414 | [ipp-iig] Hastings, T. and C. Manros, "Internet Printing | |
415 | Protocol/1.0:Implementer's Guide", Work in Progress. | |
416 | ||
417 | [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin, | |
418 | "Mapping between LPD and IPP Protocols", RFC 2569, April | |
419 | 1999. | |
420 | ||
421 | [RFC2566] deBry, R., Isaacson, S., Hastings, T., Herriot, R. and P. | |
422 | Powell, "Internet Printing Protocol/1.0: Model and | |
423 | Semantics", RFC 2566, April 1999. | |
424 | ||
425 | [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet | |
426 | Printing Protocol/1.0: Encoding and Transport", RFC 2565, | |
427 | April 1999. | |
428 | ||
429 | [RFC2567] Wright, D., "Design Goals for an Internet Printing | |
430 | Protocol", RFC 2567, April 1999. | |
431 | ||
432 | [ISO10175] ISO/IEC 10175 "Document Printing Application (DPA)", June | |
433 | 1996. | |
434 | ||
435 | [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J. | |
436 | Gyllenskog, "Printer MIB", RFC 1759, March 1995. | |
437 | ||
438 | [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, | |
439 | "Protocol Operations for Version 2 of the Simple Network | |
440 | Management Protocol (SNMPv2)", RFC 1905, January 1996. | |
441 | ||
442 | [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, | |
443 | "Transport Mappings for Version 2 of the Simple Network | |
444 | Management Protocol (SNMPv2)", RFC 1906, January 1996. | |
445 | ||
446 | ||
447 | ||
448 | ||
449 | ||
450 | Zilles Experimental [Page 8] | |
451 | \f | |
452 | RFC 2568 Rationale for IPP April 1999 | |
453 | ||
454 | ||
455 | [SSL] Netscape, The SSL Protocol, Version 3, (Text version | |
456 | 3.02), November 1996. | |
457 | ||
458 | 8. AUTHOR'S ADDRESS | |
459 | ||
460 | Stephen Zilles | |
461 | Adobe Systems Incorporated | |
462 | 345 Park Avenue | |
463 | MailStop W14 | |
464 | San Jose, CA 95110-2704 | |
465 | ||
466 | Phone: +1 408 536-4766 | |
467 | Fax: +1 408 537-4042 | |
468 | EMail: szilles@adobe.com | |
469 | ||
470 | ||
471 | ||
472 | ||
473 | ||
474 | ||
475 | ||
476 | ||
477 | ||
478 | ||
479 | ||
480 | ||
481 | ||
482 | ||
483 | ||
484 | ||
485 | ||
486 | ||
487 | ||
488 | ||
489 | ||
490 | ||
491 | ||
492 | ||
493 | ||
494 | ||
495 | ||
496 | ||
497 | ||
498 | ||
499 | ||
500 | ||
501 | ||
502 | ||
503 | ||
504 | ||
505 | ||
506 | Zilles Experimental [Page 9] | |
507 | \f | |
508 | RFC 2568 Rationale for IPP April 1999 | |
509 | ||
510 | ||
511 | 9. Full Copyright Statement | |
512 | ||
513 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
514 | ||
515 | This document and translations of it may be copied and furnished to | |
516 | others, and derivative works that comment on or otherwise explain it | |
517 | or assist in its implementation may be prepared, copied, published | |
518 | and distributed, in whole or in part, without restriction of any | |
519 | kind, provided that the above copyright notice and this paragraph are | |
520 | included on all such copies and derivative works. However, this | |
521 | document itself may not be modified in any way, such as by removing | |
522 | the copyright notice or references to the Internet Society or other | |
523 | Internet organizations, except as needed for the purpose of | |
524 | developing Internet standards in which case the procedures for | |
525 | copyrights defined in the Internet Standards process must be | |
526 | followed, or as required to translate it into languages other than | |
527 | English. | |
528 | ||
529 | The limited permissions granted above are perpetual and will not be | |
530 | revoked by the Internet Society or its successors or assigns. | |
531 | ||
532 | This document and the information contained herein is provided on an | |
533 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
534 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
535 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
536 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
537 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
538 | ||
539 | ||
540 | ||
541 | ||
542 | ||
543 | ||
544 | ||
545 | ||
546 | ||
547 | ||
548 | ||
549 | ||
550 | ||
551 | ||
552 | ||
553 | ||
554 | ||
555 | ||
556 | ||
557 | ||
558 | ||
559 | ||
560 | ||
561 | ||
562 | Zilles Experimental [Page 10] | |
563 | \f |