draft-ietf-ipp-rat-01.txt   draft-ietf-ipp-rat-02.txt 
INTERNET DRAFT Stephen N. Zilles INTERNET DRAFT Stephen N. Zilles
<draft-ietf-ipp-rat-01.txt> Adobe Systems Inc. <draft-ietf-ipp-rat-02.txt> Adobe Systems Inc.
July 30, 1997 Expires: Jan 30, 1998 November 21, 1997 Expires: May 21, 1998
Rationale for the Structure of the Model and Protocol Rationale for the Structure of the Model and Protocol
for the Internet Printing Protocol for the Internet Printing Protocol
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 documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute 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- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as ''work Drafts as reference material or to cite them other than as
in progress.'' ''work in progress.''
To learn the current status of any Internet-Draft, please check To learn the current status of any Internet-Draft, please check
the ''1id-abstracts.txt'' listing contained in the Internet- the ''1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast). Coast), or ftp.isi.edu (US West Coast).
ABSTRACT ABSTRACT
This document is one of a set of documents which together This document is one of a set of documents which together
skipping to change at page 1, line 44 skipping to change at page 1, line 44
IPP is an application level protocol that can be used for IPP is an application level protocol that can be used for
distributed printing on the Internet. There are multiple parts distributed printing on the Internet. There are multiple parts
to IPP, but the primary architectural components are the Model, to IPP, but the primary architectural components are the Model,
the Protocol and an interface to Directory Services. This the Protocol and an interface to Directory Services. This
document provides a high level overview of the architecture document provides a high level overview of the architecture
and provides the rationale for the decisions made in 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 for an Internet Requirements for an Internet Printing Protocol
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: Protocol Specification Internet Printing Protocol/1.0: Protocol Specification
Internet Printing Protocol/1.0: Directory Schema Rationale for the Structure of the Model and Protocol for
the Internet Printing Protocol
Expires: Jan 30, 1998 Expires: May 21, 1998
1. ARCHITECTURAL OVERVIEW 1. ARCHITECTURAL OVERVIEW
The Internet Printing Protocol (IPP) is an application level The Internet Printing Protocol (IPP) is an application level
protocol that can be used for distributed printing on the protocol that can be used for distributed printing on the
Internet. This protocol defines interactions between a client Internet. This protocol defines interactions between a
and a server. The client is provided the capability to inquire client and a server. The protocol allows a client to inquire
about capabilities of a printer, to submit print jobs and to about capabilities of a printer, to submit print jobs and to
inquire about and cancel print jobs. The server for these inquire about and cancel print jobs. The server for these
requests is the Printer; the Printer is an abstraction a requests is the Printer; the Printer is an abstraction of a
generic document output device and/or a print service generic document output device and/or a print service
provider. Thus, the Printer could be a real printing device, provider. Thus, the Printer could be a real printing device,
such as a computer printer or fax output device, or it could such as a computer printer or fax output device, or it could
be a service that interfaced with output devices. be a service that interfaced with output devices.
The architecture for IPP defines (in the Model document) an The architecture for IPP defines (in the Model document
abstract Model for the data which is used to control the [IPP-MOD]) an abstract Model for the data which is used to
printing process and to provide information about the process control the printing process and to provide information
and the capabilities of the Printer. This abstract Model is about the process and the capabilities of the Printer. This
hierarchical in nature and reflects the structure of the abstract Model is hierarchical in nature and reflects the
Printer and the Jobs that may be being processed by the structure of the Printer and the Jobs that may be being
Printer. processed by the Printer.
The Internet provides a channel between the client and the The Internet provides a channel between the client and the
server/Printer. Use of this channel requires flattening and server/Printer. Use of this channel requires flattening and
sequencing the hierarchical Model data. Therefore, the IPP sequencing the hierarchical Model data. Therefore, the IPP
also defines (in the Protocol document) an encoding of the also defines (in the Protocol document [IPP-PRO]) an
data in the model for transfer between the client and server. encoding of the data in the model for transfer between the
This transfer of data may be either a request or the response client and server. This transfer of data may be either a
to a request. request or the response to a request.
Finally, the IPP defines (in the Protocol document) a protocol Finally, the IPP defines (in the Protocol document
for transfering the encoded request and response data between [IPP-PRO]) a protocol for transfering the encoded request
the client and the server/Printer. and response data between the client and the server/Printer.
An example of a typical interaction would be a request from An example of a typical interaction would be a request from
the client to create a print job. The client would assemble the client to create a print job. The client would assemble
the Model data to be associated with that job, such as the 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 name of the job, the media to use, the number of pages to
place on each media instance, etc. This data would then be place on each media instance, etc. This data would then be
encoded according to the Protocol and would be transmitted encoded according to the Protocol and would be transmitted
according to the Protocol. The server/Printer would receive according to the Protocol. The server/Printer would receive
the encoded Model data, decode it into a form understood by the encoded Model data, decode it into a form understood by
the server/Printer and, based on that data, do one of two the server/Printer and, based on that data, do one of two
things: (1) accept the job or (2) reject the job. In either things: (1) accept the job or (2) reject the job. In either
case, the server must construct a response in terms of the case, the server must construct a response in terms of the
Model data, encode that response according to the Protocol and Model data, encode that response according to the Protocol and
transmit that encoded Model data as the response to the transmit that encoded Model data as the response to the
request using the Protocol. request using the Protocol.
Expires: Jan 30, 1998 Another part of the IPP architecture is the Directory Schema
Another part of the IPP architecture is the Directory Schema. (described in the model document).. The role of the
The role of the Directory Schema is to provide a standard set
of attributes which might be used to query a directory service Expires: May 21, 1998
for the URI of a Printer that is likely to meet the needs of Directory Schema is to provide a standard set of attributes
the client. 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.
The IPP architecture also addresses security issues such as The IPP architecture also addresses security issues such as
control of access to server/Printers and secure transmissions control of access to server/Printers and secure transmissions
of requests, response and the data to be printed. of requests, response and the data to be printed.
2. THE PRINTER 2. THE PRINTER
Because the (abstract) server/Printer encompasses a wide range Because the (abstract) server/Printer encompasses a wide
of implementations, it is necessary to make some assumptions range of implementations, it is necessary to make some
about a minimal implementation. The most likely minimal assumptions about a minimal implementation. The most likely
implementation is one that is embedded in an output device minimal implementation is one that is embedded in an output
running a specialized real time operating system and with device running a specialized real time operating system and
limited processing, memory and storage capabilities. This with limited processing, memory and storage capabilities.
Printer will be connected to the Internet and will have at This Printer will be connected to the Internet and will have
least a TCP/IP capability with (likely) SNMP support for the at least a TCP/IP capability with (likely) SNMP [RFC1905,
Internet connection. In addition, it is likely the the Printer RFC1906] support for the Internet connection. In addition,
will be an HTML/HTTP server to allow direct user access to it is likely the the Printer will be an HTML/HTTP server to
information about the printer. allow direct user access to information about the printer.
3. RATIONALE FOR THE MODEL 3. RATIONALE FOR THE MODEL
The Model is defined independently of any encoding of the The Model [IPP-MOD] is defined independently of any encoding
Model data both to support the likely uses of IPP and to be of the Model data both to support the likely uses of IPP and
robust with respect to the possibility of alternate to be robust with respect to the possibility of alternate
encodings. encodings.
It is expected that a client or server/Printer would represent It is expected that a client or server/Printer would
the Model data in some data structure within the represent the Model data in some data structure within the
applications/servers that support IPP. Therefore, the Model applications/servers that support IPP. Therefore, the Model
was designed to make that representation was designed to make that representation straightforward.
straightforward. Typically, a parser or formatter would be Typically, a parser or formatter would be used to convert
used to convert from or to the encoded data format. Once in an from or to the encoded data format. Once in an internal form
internal form suitable to a product, the data can be suitable to a product, the data can be manipulated by the
manipulated by the product. For example, the data sent with a product. For example, the data sent with a Print Job can be
Print Job can be used to control the processing of that Print used to control the processing of that Print Job.
Job.
The semantics of IPP are attached to the (abstract) The semantics of IPP are attached to the (abstract)
Model. Therefore, the application/server is not dependent on Model. Therefore, the application/server is not dependent on
the encoding of the Model data, and it is possible to consider the encoding of the Model data, and it is possible to consider
alternative mechanisms and formats by which the data could be alternative mechanisms and formats by which the data could be
transmitted from a client to a server; for example, a server transmitted from a client to a server; for example, a server
Expires: Jan 30, 1998
could have a direct, client-less GUI interface that might be could have a direct, client-less GUI interface that might be
used to accept some kinds of Print Jobs. This independence used to accept some kinds of Print Jobs. This independence
would also allow a different encoding and/or transmission would also allow a different encoding and/or transmission
Expires: May 21, 1998
mechanism to be used if the ones adopted here were shown to be mechanism to be used if the ones adopted here were shown to be
overly limiting in the future. Such a change could be migrated overly limiting in the future. Such a change could be migrated
into new products as an alternate protocol stack/parser for into new products as an alternate protocol stack/parser for
the Model data. the Model data.
Having an abstract Model also allows the Model data to be Having an abstract Model also allows the Model data to be
aligned with the (abstract) model used in the Printer, Job and aligned with the (abstract) model used in the Printer
Host Resources MIBs. This provides consistency in [RFC1759], Job and Host Resources MIBs. This provides
interpretation of the data obtained independently of how the consistency in interpretation of the data obtained
data is accessed, whether via IPP or via SNMP and the independently of how the data is accessed, whether via IPP
Printer/Job MIBs. or via SNMP [RFC1905, RFC1906] and the Printer/Job MIBs.
There is one aspect of the Model that deserves some extra
explanation. There are two ways for identifying a Job
object: (a) with a Job URI and (b) using a combination of
the Printer URI and a Job ID (a 32 bit positive integer).
Allowing Job objects to have URIs allows for flexibility and
scalability. For example a job could be moved from a printer
with a large backlog to one with a smaller load and the job
identification, the Job object URI, need not change.
However, many existing printing systems have local models or
interface constraints that force Job objects to be
identified using only a 32-bit positive integer rather than
a URI. This numeric Job ID is only unique within the
context of the Printer object to which the create request
was originally submitted. In order to allow both types of
client access to Jobs (either by Job URI or bynumeric Job
ID), when the Printer object successfully processes a create
request and creates a new Job, the Printer object SHALL
generate both a Job URI and a Job ID for the new Job object.
This requirement allows all clients to access Printer
objects and Job objects no matter the local constraints
imposed on the client implementation.
4. RATIONALE FOR THE PROTOCOL 4. RATIONALE FOR THE PROTOCOL
There are two parts to the Protocol: (1) the encoding of the There are two parts to the Protocol: (1) the encoding of the
Model data and (2) the mechanism for transmitting the model Model data and (2) the mechanism for transmitting the model
data between client and server. data between client and server.
4.1 The Encoding 4.1 The Encoding
To make it simpler to develop embedded printers, a very To make it simpler to develop embedded printers, a very
simple binary encoding has been chosen. This encoding is simple binary encoding has been chosen. This encoding is
adequate to represent the kinds of data that occur within the adequate to represent the kinds of data that occur within
Model. It has a simple structure consisting of name value the Model. It has a simple structure consisting of sequences
pairs in which the names are length specified strings of attributes. Each attribute has a name, prefixed by a name
constrained to characters from a subset of ASCII and the values length, and a value.. The names are strings constrained to
are either scalars or a sequence of scalars. Each scalar value characters from a subset of ASCII. The values are either
has a length specification and is represented either as an 4
byte integer or a string. Expires: May 21, 1998
scalars or a sequence of scalars. Each scalar value has a
length specification and a value tag which indicates the
type of the value. The value type has two parts: a major
class part, such as integer or string, and a minor class
part which distinguishes the usage of the major class, such
as dateTime string. Tagging of the values with type
information allows for introducing new value types at some
future time.
A fully encoded request/response has a version number, an A fully encoded request/response has a version number, an
operation (for a request) or a status and optionally a status operation (for a request) or a status and optionally a status
message (for a response), associated parameters and attributes message (for a response), associated parameters and attributes
which are encoded Model data and, optionally (for a request), which are encoded Model data and, optionally (for a request),
print data following the Model data. print data following the Model data.
4.2 The Transmission Mechanism 4.2 The Transmission Mechanism
The chosen mechanism for transmitting the encoded Model data The chosen mechanism for transmitting the encoded Model data
is HTTP 1.1 Post (and associated response). No modifications is HTTP 1.1 Post (and associated response). No modifications
to HTTP 1.1 are proposed or required. to HTTP 1.1 are proposed or required.
The sole role of the Transmission Mechanism is to provide a The sole role of the Transmission Mechanism is to provide a
transfer of encoded Model data from/to the client to/from the transfer of encoded Model data from/to the client to/from the
server. This could be done using any data delivery mechanism. server. This could be done using any data delivery mechanism.
The key reasons why HTTP 1.1 Post is used are given below. The The key reasons why HTTP 1.1 Post is used are given below. The
Expires: Jan 30, 1998
most important of these is the first. With perhaps this most important of these is the first. With perhaps this
exception, these reasons could be satisfied by other exception, these reasons could be satisfied by other
mechanisms. There is no claim that this list uniquely mechanisms. There is no claim that this list uniquely
determines a choice of mechanism. determines a choice of mechanism.
1. HTTP 1.0 is already widely deployed and, based on the 1. HTTP 1.0 is already widely deployed and, based on the
recent evidence, HTTP 1.1 will be widely deployed as the recent evidence, HTTP 1.1 is being widely deployed as the
manufacturers release new products. The performance manufacturers release new products. The performance
benefits of HTTP 1.1 have been shown and manufactures benefits of HTTP 1.1 have been shown and manufactures
are reacting postively. are reacting postively.
Wide deployment has meant that many of the problems of Wide deployment has meant that many of the problems of
making a protocol work in a wide range of environments making a protocol work in a wide range of environments
from local net to intranet to internet have been solved from local net to intranet to internet have been solved
and will stay solved with HTTP 1.1 deployment. and will stay solved with HTTP 1.1 deployment.
2. HTTP 1.1 solves most of the problems that might have 2. HTTP 1.1 solves most of the problems that might have
required a new protocol to be developed. HTTP 1.1 allows required a new protocol to be developed. HTTP 1.1 allows
persistent connections that make a multi-message persistent connections that make a multi-message
protocol be more efficient; for example it is practical protocol be more efficient; for example it is practical
to have a separate CreatJob and SendJob to have a separate CreatJob and SendJob
messages. Chunking allows the transmission of large messages. Chunking allows the transmission of large
print files without having to prescan the file to print files without having to prescan the file to
determine the file length. The accept headers allow the determine the file length. The accept headers allow the
Expires: May 21, 1998
client's protocol and localization desires to be client's protocol and localization desires to be
transmitted with the IPP operations and data. If the transmitted with the IPP operations and data. If the
Model were to provide for the redirection of Job Model were to provide for the redirection of Job
requests, such as Cancel-Job, when a Job is moved, the requests, such as Cancel-Job, when a Job is moved, the
HTTP redirect response allows a client to be informed HTTP redirect response allows a client to be informed
when a Job he is interested in is moved to another when a Job he is interested in is moved to another
server/Printer for any reason. server/Printer for any reason.
3. Most network Printers will be implementing HTTP servers 3. Most network Printers will be implementing HTTP
for reasons other than IPP. These network attached servers for reasons other than IPP. These network
Printers want to provide information on how to use the attached Printers want to provide information on how
printer, its current state, etc. in HTML. This requires to use the printer, its current state, HELP
having an HTTP server which would be available to do IPP information, etc. in HTML. This requires having an
HTTP server which would be available to do IPP
functions as well. functions as well.
4. Most of the complexity of HTTP 1.1 is concerned with the 4. Most of the complexity of HTTP 1.1 is concerned with
implementation of proxies and not the implementation of the implementation of HTTP proxies and not the
clients and/or servers. Work is proceding in the HTTP implementation of HTTP clients and/or servers. Work is
Working Group to help identify what must be done by a proceding in the HTTP Working Group to help identify
server. As the Protocol document shows, that is not very what must be done by a server. As the Protocol
much. document shows, that is not very much.
5. An HTTP based solution fits well with the Internet 5. HTTP implementations provide support for handling URLs
security mechanism that are currently deployed or being that would have to be provided if a new protocol were
deployed. HTTP will run over SSL/TLS. The digest defined.
Expires: Jan 30, 1998 6. An HTTP based solution fits well with the Internet
security mechanism that are currently deployed or being
deployed. HTTP will run over TLS/SSL. The digest
authentication mechanism of HTTP 1.1 provides an authentication mechanism of HTTP 1.1 provides an
adequate level of access control (at least for intranet adequate level of access control (at least for intranet
usage). These solutions are deployed and in practical usage). These solutions are deployed and in practical
use; a new solution would require extensive use to have use; a new solution would require extensive use to have
the same degree of confidence in its security. the same degree of confidence in its security.
7. HTTP provides an extensibility model that a new
protocol would have to develop independently. In
particular, the headers, content-types (via Internet
Media Types) and error codes have wide acceptance and
a useful set of definitions and methods for extension.
8. Although not strictly a reason why IPP should use HTTP
as the transmission protocol, it is extremely helpful
that there are many prototyping tools that work with
HTTP and that CGI scripts can be used to test and
debug parts of the protocol.
Expires: May 21, 1998
9. Finally, the POST method was chosen to carry the print
data because its usage for data transmission has been
established, it works and the results are available
via CGI scripts where that is relevant. Creating a new
method would have better identified the intended use
of the POSTed data, but a new method would be more
difficult to deploy. Because there were no strong
arguments for or against using a new method, the POST
method was used.
5. RATIONALE FOR THE DIRECTORY SCHEMA 5. RATIONALE FOR THE DIRECTORY SCHEMA
Successful use of IPP depends on the client finding a Successful use of IPP depends on the client finding a
suitable IPP enabled Printer to which to send a IPP requests, suitable IPP enabled Printer to which to send a IPP requests,
such as print a job. This task is simplified if there is a such as print a job. This task is simplified if there is a
Directory Service which can be queried for a suitable Directory Service which can be queried for a suitable
Printer. The purpose of the Directory Schema is to have a Printer. The purpose of the Directory Schema is to have a
standard description of Printer attributes that can be standard description of Printer attributes that can be
associated the the URI for the printer. These attributes are a associated the the URI for the printer. These attributes are a
subset of the Model attributes and can be encoded in the subset of the Model attributes and can be encoded in the
skipping to change at page 6, line 36 skipping to change at page 7, line 40
Security is an areas of active work on the Internet. Complete Security is an areas of active work on the Internet. Complete
solutions to a wide range of security concerns are not yet solutions to a wide range of security concerns are not yet
available. Therefore, in the design of IPP, the focus has been available. Therefore, in the design of IPP, the focus has been
on identifying a set of security protocols/features that are on identifying a set of security protocols/features that are
implemented (or currently implementable) and solve real implemented (or currently implementable) and solve real
problems with distributed printing. The two areas that seem problems with distributed printing. The two areas that seem
appropriate to support are: (1) authorization to use a Printer appropriate to support are: (1) authorization to use a Printer
and (2) secure interaction with a printer. The chosen and (2) secure interaction with a printer. The chosen
mechanisms are the digest authentication mechanism of HTTP 1.1 mechanisms are the digest authentication mechanism of HTTP 1.1
and the SSL/TLS secure communication mechanism, which also and the TLS/SSL [TLS-PRO] secure communication mechanism.
includes authorization.
7. REFERENCES To provide access to both HTTP security and TLS security,
IPP Printers provide two URLs for accessing the Printer
object: one URL for which the scheme is HTTP for normal HTTP
1.1 access and one URL for which the scheme is HTTPS for
access to the Printer using TLS/SSL protected communication.
Two URLs are necessary because all allowed modes of TLS
require some level of security beyond HTTP security so a TLS
capable URL cannot be used to negotiate down to HTTP
security.
[1] Wright, F. D., "Requirements for an Internet Printing 7. COPYRIGHT
Protocol:"
[2] Isaacson, S, deBry, R, Hasting, T, Herriot, R, Powell, P, This document and translations of it may be copied and
"Internet Printing Protocol/1.0: Model and Semantics" furnished to others, and derivative works that comment on or
[3] Internet Printing Protocol/1.0: Security Expires: May 21, 1998
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on
all such copies and derivative works. However, this
document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to
translate it into languages other than English.
[4] Herriot, R, Butler, S, Moore, P, Turner, R, "Internet The limited permissions granted above are perpetual and will
Printing Protocol/1.0: Protocol Specification" not be revoked by the Internet Society or its successors or
assigns.
[5] Carter, K, Isaacson, S, "Internet Printing Protocol/1.0: This document and the information contained herein is
Directory Schema" provided on an "AS IS" basis and THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expires: Jan 30, 1998 8. REFERENCES
8. AUTHORS ADDRESS
[RFC1759]
Smith, R., Wright, F., Hastings, T., Zilles, S., and
Gyllenskog, J., "Printer MIB", RFC 1759, March 1995.
[RFC1905]
J. Case, et al. "Protocol Operations for Version 2 of
the Simple Network Management Protocol (SNMPv2)", RFC 1905,
January 1996.
[RFC1906]
J. Case, et al. "Transport Mappings for Version 2 of
the Simple Network Management Protocol (SNMPv2)", RFC 1906,
January 1996.
[IPP-MOD]
Isaacson, S, deBry, R, Hastings, T, Herriot, R, Powell,
P, "Internet Printing Protocol/1.0: Model and Semantics"
draft-ipp-mod-07.txt, November, 1997.
Expires: May 21, 1998
[IPP-PRO]
Herriot, R., Butler, S., Moore, P., Tuner, R., " Internet
Printing Protocol/1.0: Protocol Specifications", draft-ipp-pro-
03.txt, November, 1997.
[IPP-REQ]
Wright, D., "Requirements for an Internet Printing Protocol",
draft-ipp-req-01.txt, November, 1997.
[TLS-PRO]
Dierks, T., Allen, C., "The TLS Protocol Version 1.0",
<draft-ietf-tls-protocol-05.txt>, November, 1997
9. AUTHORS ADDRESS
Stephen Zilles Stephen Zilles
Adobe Systems Incorporated Adobe Systems Incorporated
345 Park Avenue 345 Park Avenue
MailStop W14 MailStop W14
San Jose, CA 95110-2704 San Jose, CA 95110-2704
Phone: +1 408 536-4766 Phone: +1 408 536-4766
Fax: +1 408 537-4042 Fax: +1 408 537-4042
Email: szilles@adobe.com Email: szilles@adobe.com
+ Expires: May 21, 1998
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/