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

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