< 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		Internet Printing Protocol/1.0: Model and Semantics [IPP-MOD]
	Printing Protocol (this document) (informational)		Internet Printing Protocol/1.0: Encoding and Transport [IPP-PRO]
	Internet Printing Protocol/1.0: Model and Semantics [IPP-MOD]		Internet Printing Protocol/1.0: Implementer's Guide [IPP-IIG]
	Internet Printing Protocol/1.0: Encoding and Transport [IPP-PRO]		Mapping between LPD and IPP Protocols [IPP-LPD]
	Mapping between LPD and IPP Protocols [IPP-LPD] (informational)
	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 39 ¶		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 42 ¶		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 31 ¶		skipping to change at page 8, line 40 ¶
	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. 34 change blocks.
	86 lines changed or deleted		99 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/