draft-ietf-ipp-rat-04.txt   rfc2568.txt 
INTERNET DRAFT Stephen N. Zilles Network Working Group S. Zilles
<draft-ietf-ipp-rat-04.txt> Adobe Systems Inc. Request for Comments: 2568 Adobe Systems Inc.
Category: Experimental April 1999
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 memo defines an Experimental Protocol for the Internet
documents of the Internet Engineering Task Force (IETF), its areas, community. It does not specify an Internet standard of any kind.
and its working groups. Note that other groups may also distribute Discussion and suggestions for improvement are requested.
working documents as Internet-Drafts. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six Copyright Notice
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
To learn the current status of any Internet-Draft, please check the Copyright (C) The Internet Society (1999). All Rights Reserved.
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
directories on ftp.is.co.za (Africa), nic.nordu.net Europe), IESG Note
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast). This document defines an Experimental protocol for the Internet
community. The IESG expects that a revised version of this protocol
will be published as Proposed Standard protocol. The Proposed
Standard, when published, is expected to change from the protocol
defined in this memo. In particular, it is expected that the
standards-track version of the protocol will incorporate strong
authentication and privacy features, and that an "ipp:" URL type will
be defined which supports those security measures. Other changes to
the protocol are also possible. Implementors are warned that future
versions of this protocol may not interoperate with the version of
IPP defined in this document, or if they do interoperate, that some
protocol features may not be available.
The IESG encourages experimentation with this protocol, especially in
combination with Transport Layer Security (TLS) [RFC2246], to help
determine how TLS may effectively be used as a security layer for
IPP.
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
printing using Internet tools and technologies. This document describes using Internet tools and technologies. This document describes IPP
IPP from a high level view, defines a roadmap for the various documents from a high level view, defines a roadmap for the various documents
that form the suite of IPP specifications, and gives background and that form the suite of IPP specifications, and gives background and
rationale for the IETF working group's major decisions. rationale for the IETF working group's major decisions.
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 [RFC2567]
Rationale for the Structure and Model and Protocol for the Rationale for the Structure and Model and Protocol for the
Internet Printing Protocol (this document) Internet Printing Protocol (this document)
Internet Printing Protocol/1.0: Model and Semantics [IPP-MOD] Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
Internet Printing Protocol/1.0: Encoding and Transport [IPP-PRO] Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
Internet Printing Protocol/1.0: Implementer's Guide [IPP-IIG] Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
Mapping between LPD and IPP Protocols [IPP-LPD] Mapping between LPD and IPP Protocols [RFC2569]
The "Design Goals for an Internet Printing The "Design Goals for an Internet Printing Protocol" document takes a
Protocol" document takes a broad look at distributed printing broad look at distributed printing functionality, and it enumerates
functionality, and it enumerates real-life scenarios that help to real-life scenarios that help to clarify the features that need to be
clarify the features that need to be included in a printing included in a printing protocol for the Internet. It identifies
protocol for the Internet. It identifies requirements for three requirements for three types of users: end users, operators, and
types of users: end users, operators, and administrators. The administrators. The Design Goals document calls out a subset of end
requirements document calls out a subset of end user requirements user requirements that are satisfied in IPP/1.0. Operator and
that are satisfied in IPP/1.0. Operator and administrator administrator requirements are out of scope for version 1.0.
requirements are out of scope for version 1.0.
The "Internet Printing Protocol/1.0: Model and Semantics" document The "Internet Printing Protocol/1.0: Model and Semantics" document
describes a simplified model consisting of abstract objects, their describes a simplified model consisting of abstract objects, their
attributes, and their operations that is independent of encoding and attributes, and their operations that is independent of encoding and
transport. The model consists of a Printer and a Job object. The Job transport. The model consists of a Printer and a Job object. The
optionally supports multiple documents. This document also addresses Job optionally supports multiple documents. This document also
security, internationalization, and directory issues. addresses security, internationalization, and directory issues.
The "Internet Printing Protocol/1.0: Encoding and Transport" document is The "Internet Printing Protocol/1.0: Encoding and Transport" document
a formal mapping of the abstract operations and attributes defined in is a formal mapping of the abstract operations and attributes defined
the model document onto HTTP/1.1. It defines the encoding rules for a in the model document onto HTTP/1.1. It defines the encoding rules
new Internet media type called "application/ipp". for a new Internet media type called "application/ipp".
The "Internet Printing Protocol/1.0: Implementer's Guide" document gives The "Internet Printing Protocol/1.0: Implementer's Guide" document
insight and advice to implementers of IPP clients and IPP objects. It gives insight and advice to implementers of IPP clients and IPP
is intended to help them understand IPP/1.0 and some of the objects. It is intended to help them understand IPP/1.0 and some of
considerations that may assist them in the design of their client and/or the considerations that may assist them in the design of their client
IPP object implementations. For example, a typical order of processing and/or IPP object implementations. For example, a typical order of
requests is given, including error checking. Motivation for some of the processing requests is given, including error checking. Motivation
specification decisions is also included. for some of the specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice The "Mapping between LPD and IPP Protocols" document gives some
to implementers of gateways between IPP and LPD (Line Printer Daemon) advice to implementers of gateways between IPP and LPD (Line Printer
implementations. Daemon) 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
protocol that can be used for distributed printing on the Internet. that can be used for distributed printing on the Internet. This
This protocol defines interactions between a client and a server. protocol defines interactions between a client and a server. The
The protocol allows a client to inquire about capabilities of a protocol allows a client to inquire about capabilities of a printer,
printer, to submit print jobs and to inquire about and cancel print to submit print jobs and to inquire about and cancel print jobs. The
jobs. The server for these requests is the Printer; the Printer is server for these requests is the Printer; the Printer is an
an abstraction of a generic document output device and/or a print 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,
device, such as a computer printer or fax output device, or it such as a computer printer or fax output device, or it could be a
could be a service that interfaced with output devices. 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 protocol is heavily influenced by the printing model introduced
an abstract Model for the data which is used to control the in the Document Printing Application (DPA) [ISO10175] standard.
printing process and to provide information about the process and Although DPA specifies both end user and administrative features, IPP
the capabilities of the Printer. This abstract Model is version 1.0 (IPP/1.0) focuses only on end user functionality.
hierarchical in nature and reflects the structure of the Printer
and the Jobs that may be being processed by the Printer.
The Internet provides a channel between the client and the The architecture for IPP defines (in the Model and Semantics document
server/Printer. Use of this channel requires flattening and [RFC2566]) an abstract Model for the data which is used to control
sequencing the hierarchical Model data. Therefore, the IPP also the printing process and to provide information about the process and
defines (in the Encoding and Transport document [IPP-PRO]) an encoding the capabilities of the Printer. This abstract Model is hierarchical
of the data in the model for transfer between the client and server. in nature and reflects the structure of the Printer and the Jobs that
This transfer of data may be either a request or the response to a may be being processed by the Printer.
request.
Finally, the IPP defines (in the Encoding and Transport document [IPP- The Internet provides a channel between the client and the
PRO]) a protocol for transferring the encoded request and response data server/Printer. Use of this channel requires flattening and
between the client and the server/Printer. sequencing the hierarchical Model data. Therefore, the IPP also
defines (in the Encoding and Transport document [RFC2565]) an
encoding of the data in the model for transfer between the client and
server. This transfer of data may be either a request or the
response to a request.
An example of a typical interaction would be a request from the Finally, the IPP defines (in the Encoding and Transport document
client to create a print job. The client would assemble the Model [RFC2565]) a protocol for transferring the encoded request and
data to be associated with that job, such as the name of the job, response data between the client and the server/Printer.
the media to use, the number of pages to place on each media
instance, etc. This data would then be encoded according to the
Protocol and would be transmitted according to the Protocol. The
server/Printer would receive the encoded Model data, decode it into
a form understood by the server/Printer and, based on that data, do
one of two things: (1) accept the job or (2) reject the job. In
either case, the server must construct a response in terms of the
Model data, encode that response according to the Protocol and
transmit that encoded Model data as the response to the request
using the Protocol.
Another part of the IPP architecture is the Directory Schema An example of a typical interaction would be a request from the
described in the model document). The role of a Directory Schema is client to create a print job. The client would assemble the Model
data to be associated with that job, such as the name of the job, the
media to use, the number of pages to place on each media instance,
etc. This data would then be encoded according to the Protocol and
would be transmitted according to the Protocol. The server/Printer
would receive the encoded Model data, decode it into a form
understood by the server/Printer and, based on that data, do one of
two things: (1) accept the job or (2) reject the job. In either case,
the server must construct a response in terms of the Model data,
encode that response according to the Protocol and transmit that
encoded Model data as the response to the request using the Protocol.
Expires May 16, 1999 Another part of the IPP architecture is the Directory Schema
to provide a standard set of attributes which might be used to described in the model document. The role of a Directory Schema is to
query a directory service for the URI of a Printer that is likely provide a standard set of attributes which might be used to query a
to meet the needs of the client. The IPP architecture also directory service for the URI of a Printer that is likely to meet the
addresses security issues such as control of access to needs of the client. The IPP architecture also addresses security
server/Printers and secure transmissions of requests, response and issues such as control of access to server/Printers and secure
the data to be printed. transmissions 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 range of
of implementations, it is necessary to make some assumptions implementations, it is necessary to make some assumptions about a
about a minimal implementation. The most likely minimal minimal implementation. The most likely minimal implementation is one
implementation is one that is embedded in an output device that is embedded in an output device running a specialized real time
running a specialized real time operating system and with limited operating system and with limited processing, memory and storage
processing, memory and storage capabilities. This printer will be capabilities. This printer will be connected to the Internet and will
connected to the Internet and will have at least a TCP/IP have at least a TCP/IP capability with (likely) SNMP [RFC1905,
capability with (likely) SNMP [RFC1905, RFC1906] support for the RFC1906] support for the Internet connection. In addition, it is
Internet connection. In addition, it is likely the the Printer will likely the the Printer will be an HTML/HTTP server to allow direct
be an HTML/HTTP server to allow direct user access to information 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 [RFC2566] 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
the Model data in some data structure within the
applications/servers that support IPP. Therefore, the Model was
designed to make that representation straightforward. Typically a
parser or formatter would be used to convert from or to the encoded
data format. Once in an internal form suitable to a product, the
data can be manipulated by the product. For example, the data sent
with a Print Job can be used to control the processing of that
Print Job.
The semantics of IPP are attached to the (abstract) Model. It is expected that a client or server/Printer would represent the
Therefore, the application/server is not dependent on the encoding Model data in some data structure within the applications/servers
of the Model data, and it is possible to consider alternative that support IPP. Therefore, the Model was designed to make that
mechanisms and formats by which the data could be transmitted from representation straightforward. Typically a parser or formatter would
a client to a server; for example, a server could have a direct, be used to convert from or to the encoded data format. Once in an
client-less GUI interface that might be used to accept some kinds internal form suitable to a product, the data can be manipulated by
of Print Jobs. This independence would also allow a different the product. For example, the data sent with a Print Job can be used
encoding and/or transmission mechanism to be used if the ones to control the processing of that Print Job.
adopted here were shown to be overly limiting in the future. Such a
change could be migrated into new products as an alternate protocol
stack/parser for the Model data.
Having an abstract Model also allows the Model data to be aligned The semantics of IPP are attached to the (abstract) Model.
with the (abstract) model used in the Printer [RFC1759], Job and Therefore, the application/server is not dependent on the encoding of
the Model data, and it is possible to consider alternative mechanisms
and formats by which the data could be transmitted from 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 of Print Jobs. This
independence would also allow a different encoding and/or
transmission mechanism to be used if the ones adopted here were shown
to be overly limiting in the future. Such a change could be migrated
into new products as an alternate protocol stack/parser for the Model
data.
Expires May 16, 1999 Having an abstract Model also allows the Model data to be aligned
Host Resources MIBs. This provides consistency in interpretation of with the (abstract) model used in the Printer [RFC1759], Job and Host
the data obtained independently of how the data is accessed, Resources MIBs. This provides consistency in interpretation of the
whether via IPP or via SNMP [RFC1905, RFC1906] and the Printer/Job data obtained independently of how the data is accessed, whether via
MIBs. IPP or via SNMP [RFC1905, RFC1906] and the Printer/Job 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
URIs allows for flexibility and scalability. For example a job allows for flexibility and scalability. For example a job could be
could be moved from a printer with a large backlog to one with a moved from a printer with a large backlog to one with a smaller load
smaller load and the job identification, the Job object URI, and the job identification, the Job object URI, need not change.
need not change. However, many existing printing systems have local However, many existing printing systems have local models or
models or interface constraints that force Job objects to be interface constraints that force Job objects to be identified using
identified using only a 32-bit positive integer rather than a URI. only a 32-bit positive integer rather than a URI. This numeric Job
This numeric Job ID is only unique within the context of the ID is only unique within the context of the Printer object to which
Printer object to which the create request was originally the create request was originally submitted. In order to allow both
submitted. In order to allow both types of client access to Jobs types of client access to Jobs (either by Job URI or by numeric Job
(either by Job URI or by numeric Job ID), when the Printer object ID), when the Printer object successfully processes a create request
successfully processes a create request and creates a new Job, the and creates a new Job, the Printer object generates both a Job URI
Printer object SHALL generate both a Job URI and a Job ID for the and a Job ID for the new Job object. This requirement allows all
new Job object. This requirement allows all clients to access clients to access Printer objects and Job objects independent of any
Printer objects and Job objects independent of any local local constraints imposed on the client implementation.
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 Model There are two parts to the Protocol: (1) the encoding of the Model
data and (2) the mechanism for transmitting the model data between data and (2) the mechanism for transmitting the model data between
client and server. client and server.
4.1 The Encoding 4.1 The Encoding
To make it simpler to develop embedded printers, a very simple To make it simpler to develop embedded printers, a very simple binary
binary encoding has been chosen. This encoding is adequate to encoding has been chosen. This encoding is adequate to represent the
represent the kinds of data that occur within the Model. It has a kinds of data that occur within the Model. It has a simple structure
simple structure consisting of sequences of attributes. Each consisting of sequences of attributes. Each attribute has a name,
attribute has a name, prefixed by a name length, and a value. The prefixed by a name length, and a value. The names are strings
names are strings constrained to characters from a subset of ASCII. constrained to characters from a subset of ASCII. The values are
The values are either scalars or a sequence of scalars. Each scalar either scalars or a sequence of scalars. Each scalar value has a
value has a length specification and a value tag which length specification and a value tag which indicates the type of the
indicates the type of the value. The value type has two parts: a value. The value type has two parts: a major class part, such as
major class part, such as integer or string, and a minor class part integer or string, and a minor class part which distinguishes the
which distinguishes the usage of the major class, such as dateTime usage of the major class, such as dateTime string. Tagging of the
string. Tagging of the values with type information allows for values with type information allows for introducing new value types
introducing new value types at some future time. 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
the Model data. 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
HTTP 1.1 Post (and associated response). No modifications to HTTP 1.1 Post (and associated response). No modifications to HTTP 1.1 are
1.1 are proposed or required. The sole role of the Transmission proposed or required. The sole role of the Transmission Mechanism is
Mechanism is to provide a transfer of encoded Model data from/to to provide a transfer of encoded Model data from/to the client
the client to/from the server. This could be done using any data to/from the server. This could be done using any data delivery
delivery mechanism. The key reasons why HTTP 1.1 Post is used are mechanism. The key reasons why HTTP 1.1 Post is used are given below.
given below. The most important of these is the first. With perhaps The most important of these is the first. With perhaps this
this exception, these reasons could be satisfied by other exception, these reasons could be satisfied by other mechanisms.
mechanisms. There is no claim that this list uniquely determines a There is no claim that this list uniquely determines a choice of
choice of mechanism. 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
recent evidence, HTTP 1.1 is being widely deployed as the evidence, HTTP 1.1 is being widely deployed as the manufacturers
manufacturers release new products. The performance benefits release new products. The performance benefits of HTTP 1.1 have
of HTTP 1.1 have been shown and manufactures are reacting 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
a protocol work in a wide range of environments from local net protocol work in a wide range of environments from local net to
to Intranet to Internet have been solved and will stay solved Intranet to Internet have been solved and will stay solved with
with HTTP 1.1 deployment. 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
required a new protocol to be developed. HTTP 1.1 allows new protocol to be developed. HTTP 1.1 allows persistent
persistent connections that make a multi-message protocol be connections that make a multi-message protocol be more efficient;
more efficient; for example it is practical to have separate for example it is practical to have separate Create-Job and Send-
Create-Job and Send-Document messages. Chunking allows the Document messages. Chunking allows the transmission of large print
transmission of large print files without having to pre-scan files without having to pre-scan the file to determine the file
the file to determine the file length. The accept headers length. The accept headers allow the client's protocol and
allow the client's protocol and localization desires to be localization desires to be transmitted with the IPP operations and
transmitted with the IPP operations and data. If the Model data. If the Model were to provide for the redirection of Job
were to provide for the redirection of Job requests, such as requests, such as Cancel-Job, when a Job is moved, the HTTP
Cancel-Job, when a Job is moved, the HTTP redirect response redirect response allows a client to be informed when a Job he is
allows a client to be informed when a Job he is interested in interested in is moved to another server/Printer for any reason.
is moved to another server/Printer for any reason.
3. Most network Printers will be implementing HTTP servers for 3. Most network Printers will be implementing HTTP servers for
reasons other than IPP. These network attached Printers want reasons other than IPP. These network attached Printers want to
to provide information on how to use the printer, its current provide information on how to use the printer, its current state,
state, HELP information, etc. in HTML. This requires having an HELP information, etc. in HTML. This requires having an HTTP
HTTP server which would be available to do IPP functions as 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
HTTP clients and/or servers. Work is proceeding in the HTTP clients and/or servers. Work is proceeding in the HTTP Working
Working Group to help identify what must be done by a server. Group to help identify what must be done by a server. As the
As the Encoding and Transport document shows, that is not 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 SSL3. The digest access authentication mechanism will run over SSL3. The digest access authentication mechanism of
of HTTP 1.1 provides an adequate level of access control. These HTTP 1.1 provides an adequate level of access control. These
solutions are deployed and in practical use; a new solution would solutions are deployed and in practical use; a new solution would
require extensive use to have the same degree of confidence in its require extensive use to have the same degree of confidence in its
security. Note: SSL3 is not on the IETF standards track. 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
would have to develop independently. In particular, the have to develop independently. In particular, the headers,
headers, intent-types (via Internet Media Types) and error intent-types (via Internet Media Types) and error codes have wide
codes have wide acceptance and a useful set of definitions and acceptance and a useful set of definitions and methods for
methods for extension. 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
the transmission protocol, it is extremely helpful that there transmission protocol, it is extremely helpful that there are many
are many prototyping tools that work with HTTP and that CGI prototyping tools that work with HTTP and that CGI scripts can be
scripts can be used to test and debug parts of the protocol. 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
because its usage for data transmission has been established, because its usage for data transmission has been established, it
it works and the results are available via CGI scripts or works and the results are available via CGI scripts or servlets.
servlets. Creating a new method would have better identified Creating a new method would have better identified the intended
the intended use of the POSTed data, but a new method would be use of the POSTed data, but a new method would be more difficult
more difficult to deploy. Assigning a new default port for to deploy. Assigning a new default port for IPP provided the
IPP provided the necessary identification with minimal impact necessary identification with minimal impact to installed
to installed infrastructure, so was chosen instead. infrastructure, so was chosen instead.
5. RATIONALE FOR THE DIRECTORY SCHEMA 5. RATIONALE FOR THE DIRECTORY SCHEMA
Successful use of IPP depends on the client finding a suitable IPP Successful use of IPP depends on the client finding a suitable IPP
enabled Printer to which to send a IPP requests, such as print a enabled Printer to which to send a IPP requests, such as print a
job. This task is simplified if there is a Directory Service which job. This task is simplified if there is a Directory Service which
can be queried for a suitable Printer. The purpose of the Directory can be queried for a suitable Printer. The purpose of the
Schema is to have a standard description of Printer attributes that Directory Schema is to have a standard description of Printer
can be associated the URI for the printer. These attributes are a attributes that can be associated the URI for the printer. These
subset of the Model attributes and can be encoded in the attributes are a subset of the Model attributes and can be encoded
appropriate query syntax for the Directory Service being used by in the appropriate query syntax for the Directory Service being
the client. used by the client.
6. RATIONALE FOR SECURITY
Security is an areas of active work on the Internet. Complete
solutions to a wide range of security concerns are not yet
available. Therefore, in the design of IPP, the focus has been on
identifying a set of security protocols/features that are
implemented (or currently implementable) and solve real problems
with distributed printing. The two areas that seem appropriate to
Expires May 16, 1999 6. SECURITY CONSIDERATIONS - RATIONALE FOR SECURITY
support are: (1) authorization to use a Printer and (2) secure
interaction with a printer. The chosen mechanisms are the digest
authentication mechanism of HTTP 1.1 and SSL3 [SSL] secure
communication mechanism.
7. COPYRIGHT Security is an area of active work on the Internet. Complete
solutions to a wide range of security concerns are not yet
available. Therefore, in the design of IPP, the focus has been on
identifying a set of security protocols/features that are
implemented (or currently implementable) and solve real problems
with distributed printing. The two areas that seem appropriate to
support are: (1) authorization to use a Printer and (2) secure
interaction with a printer. The chosen mechanisms are the digest
authentication mechanism of HTTP 1.1 and SSL3 [SSL] secure
communication mechanism.
Copyright (C) The Internet Society (1998) All Rights Reserved. 7. REFERENCES
This document and translations of it may be copied and furnished to [ipp-iig] Hastings, T. and C. Manros, "Internet Printing
others, and derivative works that comment on or otherwise explain Protocol/1.0:Implementer's Guide", Work in Progress.
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. The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns.
This document and the information contained herein is provided on [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET "Mapping between LPD and IPP Protocols", RFC 2569, April
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1999.
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.
8. REFERENCES [RFC2566] deBry, R., Isaacson, S., Hastings, T., Herriot, R. and P.
Powell, "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2566, April 1999.
[IPP-IIG] [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet
Hastings, T., Manros, C., "Internet Printing Protocol/1.0: Printing Protocol/1.0: Encoding and Transport", RFC 2565,
Implementer's Guide", draft-ietf-ipp-implementors-guide-00.txt, November April 1999.
1998, work in progress.
[IPP LPD] [RFC2567] Wright, D., "Design Goals for an Internet Printing
Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between LPD Protocol", RFC 2567, April 1999.
and IPP Protocols", draft-ietf-ipp-lpd-ipp-map-05.txt, November 1998.
[IPP-MOD] [ISO10175] ISO/IEC 10175 "Document Printing Application (DPA)", June
deBry, R., Isaacson, S., Hastings, T., Herriot, R., Powell, 1996.
P. "Internet Printing Protocol/1.0: Model and Semantics"
draft-ietf-ipp-mod-11.txt, November, 1998.
[IPP-PRO] [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing Gyllenskog, "Printer MIB", RFC 1759, March 1995.
Protocol/1.0: Encoding and Transport", draft-ietf-ipp-pro-07.txt,
Expires May 16, 1999 [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
November, 1998. "Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1905, January 1996.
[IPP-REQ] [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
Wright, D., "Design Goals for an Internet Printing Protocol", "Transport Mappings for Version 2 of the Simple Network
draft-ietf-ipp-req-03.txt, November, 1998. Management Protocol (SNMPv2)", RFC 1906, January 1996.
[ISO10175] [SSL] Netscape, The SSL Protocol, Version 3, (Text version
ISO/IEC 10175 "Document Printing Application (DPA)", June 1996 3.02), November 1996.
[RFC1759] 8. AUTHOR'S ADDRESS
Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog,
J., "Printer MIB", RFC 1759, March 1995.
[RFC1905] Stephen Zilles
J. Case, et al. "Protocol Operations for Version 2 of the Simple Adobe Systems Incorporated
Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 345 Park Avenue
MailStop W14
San Jose, CA 95110-2704
[RFC1906] Phone: +1 408 536-4766
J. Case, et al. "Transport Mappings for Version 2 of the Simple Fax: +1 408 537-4042
Network Management Protocol (SNMPv2)", RFC 1906, January 1996. EMail: szilles@adobe.com
[SSL] 9. Full Copyright Statement
Netscape, The SSL Protocol, Version 3, (Text version 3.02), November
1996.
9. AUTHORS ADDRESS Copyright (C) The Internet Society (1999). All Rights Reserved.
Stephen Zilles This document and translations of it may be copied and furnished to
Adobe Systems Incorporated others, and derivative works that comment on or otherwise explain it
345 Park Avenue or assist in its implementation may be prepared, copied, published
MailStop W14 and distributed, in whole or in part, without restriction of any
San Jose, CA 95110-2704 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.
Phone: +1 408 536-4766 The limited permissions granted above are perpetual and will not be
Fax: +1 408 537-4042 revoked by the Internet Society or its successors or assigns.
Email: szilles@adobe.com
Expires May 16, 1999 This document and the information contained herein is 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.
 End of changes. 64 change blocks. 
360 lines changed or deleted 336 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/