draft-ietf-ipp-rat-03.txt   draft-ietf-ipp-rat-04.txt 
INTERNET DRAFT Stephen N. Zilles INTERNET DRAFT Stephen N. Zilles
<draft-ietf-ipp-rat-03.txt> Adobe Systems Inc. <draft-ietf-ipp-rat-04.txt> Adobe Systems Inc.
June 30, 1998 Expires: December 30, 1998 November 16, 1998 Expires: May 16, 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 areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. 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-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Shadow directories on ftp.is.co.za (Africa), nic.nordu.net Europe), directories on ftp.is.co.za (Africa), nic.nordu.net Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
ABSTRACT ABSTRACT
This document is one of a set of documents, which together describe This document is one of a set of documents, which together describe
all aspects of a new Internet Printing Protocol (IPP). IPP is an all aspects of a new Internet Printing Protocol (IPP). IPP is an
application level protocol that can be used for distributed application level protocol that can be used for distributed
printing using Internet tools and technologies. The protocol is printing using Internet tools and technologies. This document describes
heavily influenced by the printing model introduced in the Document IPP from a high level view, defines a roadmap for the various documents
Printing Application (DPA) [ISO10175] standard. Although DPA that form the suite of IPP specifications, and gives background and
specifies both end user and administrative features, IPP version rationale for the IETF working group's major decisions.
1.0 (IPP/1.0) focuses only on end user functionality.
The full set of IPP documents includes: The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [IPP-REQ] Design Goals for an Internet Printing Protocol [IPP-REQ]
(informational) Rationale for the Structure and Model and Protocol for the
Internet Printing Protocol (this document)
Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol (this document) (informational)
Internet Printing Protocol/1.0: Model and Semantics [IPP-MOD] Internet Printing Protocol/1.0: Model and Semantics [IPP-MOD]
Internet Printing Protocol/1.0: Encoding and Transport [IPP-PRO] Internet Printing Protocol/1.0: Encoding and Transport [IPP-PRO]
Mapping between LPD and IPP Protocols [IPP-LPD] (informational) Internet Printing Protocol/1.0: Implementer's Guide [IPP-IIG]
Mapping between LPD and IPP Protocols [IPP-LPD]
The design goals document, "Design Goals for an Internet Printing The "Design Goals for an Internet Printing
Protocol", takes a broad look at distributed printing Protocol" document takes a broad look at distributed printing
functionality, and it enumerates real-life scenarios that help to functionality, and it enumerates real-life scenarios that help to
clarify the features that need to be included in a printing clarify the features that need to be included in a printing
protocol for the Internet. It identifies requirements for three protocol for the Internet. It identifies requirements for three
types of users: end users, operators, and administrators. The types of users: end users, operators, and administrators. The
requirements document calls out a subset of end user requirements requirements document calls out a subset of end user requirements
that are satisfied in IPP/1.0. Operator and administrator that are satisfied in IPP/1.0. Operator and administrator
requirements are out of scope for version 1.0. This document, requirements are out of scope for version 1.0.
"Rationale for the Structure and Model and Protocol for
the Internet Printing Protocol", describes IPP from a high level The "Internet Printing Protocol/1.0: Model and Semantics" document
view, defines a road map for the various documents that form the describes a simplified model consisting of abstract objects, their
suite of IPP specifications, and gives background and rationale for attributes, and their operations that is independent of encoding and
the IETF working group's major decisions. The document, "Internet transport. The model consists of a Printer and a Job object. The Job
Printing Protocol/1.0: Model and Semantics", describes a simplified optionally supports multiple documents. This document also addresses
model with abstract objects, their attributes, and their security, internationalization, and directory issues.
operations. The model introduces a Printer and a Job. The Job
supports multiple documents per Job. The model document also The "Internet Printing Protocol/1.0: Encoding and Transport" document is
addresses how security, internationalization, and directory issues a formal mapping of the abstract operations and attributes defined in
are addressed. The protocol specification, "Internet Printing the model document onto HTTP/1.1. It defines the encoding rules for a
Protocol/1.0: Encoding and Transport", is a formal mapping of the new Internet media type called "application/ipp".
abstract operations and attributes defined in the model document
onto HTTP/1.1. The protocol specification defines the encoding The "Internet Printing Protocol/1.0: Implementer's Guide" document gives
rules for a new Internet media type called "application/ipp". The insight and advice to implementers of IPP clients and IPP objects. It
"Mapping between LPD and IPP Protocols" gives some advice to is intended to help them understand IPP/1.0 and some of the
implementors of gateways between IPP and LPD (Line Printer Daemon) considerations that may assist them in the design of their client and/or
IPP object implementations. For example, a typical order of processing
requests is given, including error checking. Motivation for some of the
specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice
to implementers of gateways between IPP and LPD (Line Printer Daemon)
implementations. implementations.
Expires May 16, 1999
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 Internet. protocol that can be used for distributed printing on the Internet.
This protocol defines interactions between a client and a server. This protocol defines interactions between a client and a server.
The protocol allows a client to inquire about capabilities of a The protocol allows a client to inquire about capabilities of a
printer, to submit print jobs and to inquire about and cancel print printer, to submit print jobs and to inquire about and cancel print
jobs. The server for these requests is the Printer; the Printer is jobs. The server for these requests is the Printer; the Printer is
an abstraction of a generic document output device and/or a print an abstraction of a generic document output device and/or a print
service provider. Thus, the Printer could be a real printing service provider. Thus, the Printer could be a real printing
device, such as a computer printer or fax output device, or it device, such as a computer printer or fax output device, or it
could be a service that interfaced with output devices. could be a service that interfaced with output devices.
The protocol is heavily influenced by the printing model introduced in
the Document Printing Application (DPA) [ISO10175] standard. Although
DPA specifies both end user and administrative features, IPP version 1.0
(IPP/1.0) focuses only on end user functionality.
The architecture for IPP defines (in the Model document [IPP-MOD]) The architecture for IPP defines (in the Model document [IPP-MOD])
an abstract Model for the data which is used to control the an abstract Model for the data which is used to control the
printing process and to provide information about the process and printing process and to provide information about the process and
Expires: December 30, 1998
the capabilities of the Printer. This abstract Model is the capabilities of the Printer. This abstract Model is
hierarchical in nature and reflects the structure of the Printer hierarchical in nature and reflects the structure of the Printer
and the Jobs that may be being processed by the Printer. and the Jobs that may be being 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 also sequencing the hierarchical Model data. Therefore, the IPP also
defines (in the Encoding and Transport document [IPP-PRO]) an defines (in the Encoding and Transport document [IPP-PRO]) an encoding
encoding of the data in the model for transfer between the client of the data in the model for transfer between the client and server.
and server. This transfer of data may be either a request or the This transfer of data may be either a request or the response to a
response to a request. request.
Finally, the IPP defines (in the Encoding and Transport document Finally, the IPP defines (in the Encoding and Transport document [IPP-
[IPP-PRO]) a protocol for transferring the encoded request and PRO]) a protocol for transferring the encoded request and response data
response data between the client and the server/Printer. between the client and the server/Printer.
An example of a typical interaction would be a request from the An example of a typical interaction would be a request from the
client to create a print job. The client would assemble the Model 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, 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 the media to use, the number of pages to place on each media
instance, etc. This data would then be encoded according to the instance, etc. This data would then be encoded according to the
Protocol and would be transmitted according to the Protocol. The Protocol and would be transmitted according to the Protocol. The
server/Printer would receive the encoded Model data, decode it into server/Printer would receive the encoded Model data, decode it into
a form understood by the server/Printer and, based on that data, do 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 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 either 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 request transmit that encoded Model data as the response to the request
using the Protocol. using the Protocol.
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 a Directory Schema is described in the model document). The role of a Directory Schema is
Expires May 16, 1999
to provide a standard set of attributes which might be used to 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 query a directory service for the URI of a Printer that is likely
to meet the needs of the client. The IPP architecture also to meet the needs of the client. The IPP architecture also
addresses security issues such as control of access to addresses security issues such as control of access to
server/Printers and secure transmissions of requests, response and server/Printers and secure transmissions of requests, response and
the data to be printed. 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 range
of implementations, it is necessary to make some assumptions of implementations, it is necessary to make some assumptions
about a minimal implementation. The most likely minimal about a minimal implementation. The most likely minimal
implementation is one that is embedded in an output device implementation is one that is embedded in an output device
running a specialized real time operating system and with limited running a specialized real time operating system and with limited
processing, memory and storage capabilities. This printer will be processing, memory and storage capabilities. This printer will be
connected to the Internet and will have at least a TCP/IP connected to the Internet and will have at least a TCP/IP
capability with (likely) SNMP [RFC1905, RFC1906] support for the capability with (likely) SNMP [RFC1905, RFC1906] support for the
Internet connection. In addition, it is likely the the Printer will Internet connection. In addition, it is likely the the Printer will
Expires: December 30, 1998
be an HTML/HTTP server to allow direct user access to information be an HTML/HTTP server to allow direct user access to information
about the printer. about the printer.
3. RATIONALE FOR THE MODEL 3. RATIONALE FOR THE MODEL
The Model [IPP-MOD] is defined independently of any encoding of the The Model [IPP-MOD] is defined independently of any encoding of the
Model data both to support the likely uses of IPP and to be robust Model data both to support the likely uses of IPP and to be robust
with respect to the possibility of alternate encoding. with respect to the possibility of alternate encoding.
It is expected that a client or server/Printer would represent It is expected that a client or server/Printer would represent
skipping to change at page 4, line 40 skipping to change at page 5, line 4
a client to a server; for example, a server could have a direct, a client to a server; for example, a server could have a direct,
client-less GUI interface that might be used to accept some kinds client-less GUI interface that might be used to accept some kinds
of Print Jobs. This independence would also allow a different of Print Jobs. This independence would also allow a different
encoding and/or transmission mechanism to be used if the ones encoding and/or transmission mechanism to be used if the ones
adopted here were shown to be overly limiting in the future. Such a adopted here were shown to be overly limiting in the future. Such a
change could be migrated into new products as an alternate protocol change could be migrated into new products as an alternate protocol
stack/parser for the Model data. stack/parser for the Model data.
Having an abstract Model also allows the Model data to be aligned Having an abstract Model also allows the Model data to be aligned
with the (abstract) model used in the Printer [RFC1759], Job and with the (abstract) model used in the Printer [RFC1759], Job and
Expires May 16, 1999
Host Resources MIBs. This provides consistency in interpretation of Host Resources MIBs. This provides consistency in interpretation of
the data obtained independently of how the data is accessed, the data obtained independently of how the data is accessed,
whether via IPP or via SNMP [RFC1905, RFC1906] and the Printer/Job whether via IPP or via SNMP [RFC1905, RFC1906] and the Printer/Job
MIBs. MIBs.
There is one aspect of the Model that deserves some extra There is one aspect of the Model that deserves some extra
explanation. There are two ways for identifying a Job object: (a) 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 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 Job ID (a 32 bit positive integer). Allowing Job objects to have
URIs allows for flexibility and scalability. For example a job URIs allows for flexibility and scalability. For example a job
could be moved from a printer with a large backlog to one with a could be moved from a printer with a large backlog to one with a
smaller load and the job identification, the Job object URI, smaller load and the job identification, the Job object URI,
need not change. However, many existing printing systems have local need not change. However, many existing printing systems have local
models or interface constraints that force Job objects to be models or interface constraints that force Job objects to be
identified using only a 32-bit positive integer rather than a URI. identified using only a 32-bit positive integer rather than a URI.
This numeric Job ID is only unique within the context of the This numeric Job ID is only unique within the context of the
Printer object to which the create request was originally Printer object to which the create request was originally
Expires: December 30, 1998
submitted. In order to allow both types of client access to Jobs submitted. In order to allow both types of client access to Jobs
(either by Job URI or by numeric Job ID), when the Printer object (either by Job URI or by numeric Job ID), when the Printer object
successfully processes a create request and creates a new Job, the 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 Printer object SHALL generate both a Job URI and a Job ID for the
new Job object. This requirement allows all clients to access new Job object. This requirement allows all clients to access
Printer objects and Job objects independent of any local Printer objects and Job objects independent of any local
constraints imposed on the client implementation. constraints imposed on the client implementation.
4. RATIONALE FOR THE PROTOCOL 4. RATIONALE FOR THE PROTOCOL
skipping to change at page 5, line 43 skipping to change at page 6, line 5
which distinguishes the usage of the major class, such as dateTime which distinguishes the usage of the major class, such as dateTime
string. Tagging of the values with type information allows for string. Tagging of the values with type information allows for
introducing new value types at some future time. introducing new value types at some future time.
A fully encoded request/response has a version number, an operation A fully encoded request/response has a version number, an operation
(for a request) or a status and optionally a status message (for a (for a request) or a status and optionally a status message (for a
response), associated parameters and attributes which are encoded response), associated parameters and attributes which are encoded
Model data and, optionally (for a request), print data following Model data and, optionally (for a request), print data following
the Model data. the Model data.
Expires May 16, 1999
4.2 The Transmission Mechanism 4.2 The Transmission Mechanism
The chosen mechanism for transmitting the encoded Model data is The chosen mechanism for transmitting the encoded Model data is
HTTP 1.1 Post (and associated response). No modifications to HTTP HTTP 1.1 Post (and associated response). No modifications to HTTP
1.1 are proposed or required. The sole role of the Transmission 1.1 are proposed or required. The sole role of the Transmission
Mechanism is to provide a transfer of encoded Model data from/to Mechanism is to provide a transfer of encoded Model data from/to
the client to/from the server. This could be done using any data the client to/from the server. This could be done using any data
delivery mechanism. The key reasons why HTTP 1.1 Post is used are delivery mechanism. The key reasons why HTTP 1.1 Post is used are
given below. The most important of these is the first. With perhaps given below. The most important of these is the first. With perhaps
this exception, these reasons could be satisfied by other this exception, these reasons could be satisfied by other
mechanisms. There is no claim that this list uniquely determines a mechanisms. There is no claim that this list uniquely determines a
choice of mechanism. choice of mechanism.
Expires: December 30, 1998
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 is being widely deployed as the recent evidence, HTTP 1.1 is being widely deployed as the
manufacturers release new products. The performance benefits manufacturers release new products. The performance benefits
of HTTP 1.1 have been shown and manufactures are reacting of HTTP 1.1 have been shown and manufactures are reacting
positively. positively.
Wide deployment has meant that many of the problems of making Wide deployment has meant that many of the problems of making
a protocol work in a wide range of environments from local net a protocol work in a wide range of environments from local net
to Intranet to Internet have been solved and will stay solved to Intranet to Internet have been solved and will stay solved
with HTTP 1.1 deployment. with HTTP 1.1 deployment.
skipping to change at page 6, line 45 skipping to change at page 7, line 5
HTTP server which would be available to do IPP functions as HTTP server which would be available to do IPP functions as
well. 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 the
implementation of HTTP proxies and not the implementation of implementation of HTTP proxies and not the implementation of
HTTP clients and/or servers. Work is proceeding in the HTTP HTTP clients and/or servers. Work is proceeding in the HTTP
Working Group to help identify what must be done by a server. Working Group to help identify what must be done by a server.
As the Encoding and Transport document shows, that is not As the Encoding and Transport document shows, that is not
very much. very much.
Expires May 16, 1999
5. HTTP implementations provide support for handling URLs that 5. HTTP implementations provide support for handling URLs that
would have to be provided if a new protocol were defined. would have to be provided if a new protocol were defined.
6. An HTTP based solution fits well with the Internet security 6. An HTTP based solution fits well with the Internet security
mechanisms that are currently deployed or being deployed. HTTP mechanisms that are currently deployed or being deployed. HTTP
will run over TLS. The digest authentication mechanism of HTTP will run over SSL3. The digest access authentication mechanism
1.1 provides an adequate level of access control (at least for of HTTP 1.1 provides an adequate level of access control. These
Intranet usage). These solutions are deployed and in practical solutions are deployed and in practical use; a new solution would
use; a new solution would require extensive use to have the require extensive use to have the same degree of confidence in its
same degree of confidence in its security. security. Note: SSL3 is not on the IETF standards track.
7. HTTP provides an extensibility model that a new protocol 7. HTTP provides an extensibility model that a new protocol
would have to develop independently. In particular, the would have to develop independently. In particular, the
Expires: December 30, 1998
headers, intent-types (via Internet Media Types) and error headers, intent-types (via Internet Media Types) and error
codes have wide acceptance and a useful set of definitions and codes have wide acceptance and a useful set of definitions and
methods for extension. methods for extension.
8. Although not strictly a reason why IPP should use HTTP as 8. Although not strictly a reason why IPP should use HTTP as
the transmission protocol, it is extremely helpful that there the transmission protocol, it is extremely helpful that there
are many prototyping tools that work with HTTP and that CGI are many prototyping tools that work with HTTP and that CGI
scripts can be used to test and debug parts of the protocol. scripts can be used to test and debug parts of the protocol.
9. Finally, the POST method was chosen to carry the print data 9. Finally, the POST method was chosen to carry the print data
skipping to change at page 7, line 44 skipping to change at page 8, line 4
the client. the client.
6. RATIONALE FOR SECURITY 6. RATIONALE FOR SECURITY
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 on available. Therefore, in the design of IPP, the focus has been on
identifying a set of security protocols/features that are identifying a set of security protocols/features that are
implemented (or currently implementable) and solve real problems implemented (or currently implementable) and solve real problems
with distributed printing. The two areas that seem appropriate to with distributed printing. The two areas that seem appropriate to
Expires May 16, 1999
support are: (1) authorization to use a Printer and (2) secure support are: (1) authorization to use a Printer and (2) secure
interaction with a printer. The chosen mechanisms are the digest interaction with a printer. The chosen mechanisms are the digest
authentication mechanism of HTTP 1.1 and the TLS [TLS-PRO] secure authentication mechanism of HTTP 1.1 and SSL3 [SSL] secure
communication mechanism. communication mechanism.
7. COPYRIGHT 7. COPYRIGHT
Copyright (C) The Internet Society (1998) All Rights Reserved. Copyright (C) The Internet Society (1998) All Rights Reserved.
Expires: December 30, 1998
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works. paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the purpose of developing Internet standards in which case the
skipping to change at page 8, line 32 skipping to change at page 8, line 41
This document and the information contained herein is provided on This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
8. REFERENCES 8. REFERENCES
[RFC1759] [IPP-IIG]
Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, Hastings, T., Manros, C., "Internet Printing Protocol/1.0:
J., "Printer MIB", RFC 1759, March 1995. Implementer's Guide", draft-ietf-ipp-implementors-guide-00.txt, November
1998, work in progress.
[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 LPD] [IPP LPD]
Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between LPD
LPD and IPP Protocols", draft-ietf-ipp-lpd-ipp-map-04.txt, June and IPP Protocols", draft-ietf-ipp-lpd-ipp-map-05.txt, November 1998.
1998.
[IPP-MOD] [IPP-MOD]
Isaacson, S., deBry, R., Hastings, T., Herriot, R., Powell, deBry, R., Isaacson, S., Hastings, T., Herriot, R., Powell,
P. "Internet Printing Protocol/1.0: Model and Semantics" P. "Internet Printing Protocol/1.0: Model and Semantics"
draft-ietf-ipp-mod-10.txt, June, 1998. draft-ietf-ipp-mod-11.txt, November, 1998.
Expires: December 30, 1998
[IPP-PRO] [IPP-PRO]
Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
Protocol/1.0: Encoding and Transport", draft-ietf-ipp-pro-06.txt, Protocol/1.0: Encoding and Transport", draft-ietf-ipp-pro-07.txt,
June, 1998.
Expires May 16, 1999
November, 1998.
[IPP-REQ] [IPP-REQ]
Wright, D., "Design Goals for an Internet Printing Protocol", Wright, D., "Design Goals for an Internet Printing Protocol",
draft-ietf-ipp-req-02.txt, June, 1998. draft-ietf-ipp-req-03.txt, November, 1998.
[ISO10175] [ISO10175]
ISO/IEC 10175 "Document Printing Application (DPA)", June 1996 ISO/IEC 10175 "Document Printing Application (DPA)", June 1996
[TLS-PRO] [RFC1759]
Dirks, T., and Allan, C., "The TLS Protocol", Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog,
draft-ietf-tls-protocol-05.txt 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.
[SSL]
Netscape, The SSL Protocol, Version 3, (Text version 3.02), November
1996.
9. AUTHORS ADDRESS 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: December 30, 1998 Expires May 16, 1999
 End of changes. 

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