As per Relevance of the word document, we have this rfc below:
Network Working Group S.
Request for Comments: 2568 Adobe Systems Inc
Category: Experimental April 1999
Rationale for the Structure of the Model and
for the Internet Printing
Status of this
This memo defines an Experimental Protocol for the
community. It does not specify an Internet standard of any kind
Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
IESG
This document defines an Experimental protocol for the
community. The IESG expects that a revised version of this
will be published as Proposed Standard protocol. The
Standard, when published, is expected to change from the
defined in this memo. In particular, it is expected that
standards-track version of the protocol will incorporate
authentication and privacy features, and that an "ipp:" URL type
be defined which supports those security measures. Other changes
the protocol are also possible. Implementors are warned that
versions of this protocol may not interoperate with the version
IPP defined in this document, or if they do interoperate, that
protocol features may not be available
The IESG encourages experimentation with this protocol, especially
combination with Transport Layer Security (TLS) [RFC2246], to
determine how TLS may effectively be used as a security layer
IPP
This document is one of a set of documents, which together
all aspects of a new Internet Printing Protocol (IPP). IPP is
application level protocol that can be used for distributed
using Internet tools and technologies. This document describes
from a high level view, defines a roadmap for the various
that form the suite of IPP specifications, and gives background
rationale for the IETF working group's major decisions
Zilles Experimental [Page 1]
RFC 2568 Rationale for IPP April 1999
The full set of IPP documents includes
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for
Internet Printing Protocol (this document
Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig
Mapping between LPD and IPP Protocols [RFC2569]
The "Design Goals for an Internet Printing Protocol" document takes
broad look at distributed printing functionality, and it
real-life scenarios that help to clarify the features that need to
included in a printing protocol for the Internet. It
requirements for three types of users: end users, operators,
administrators. The Design Goals document calls out a subset of
user requirements that are satisfied in IPP/1.0. Operator
administrator requirements are out of scope for version 1.0.
The "Internet Printing Protocol/1.0: Model and Semantics"
describes a simplified model consisting of abstract objects,
attributes, and their operations that is independent of encoding
transport. The model consists of a Printer and a Job object.
Job optionally supports multiple documents. This document
addresses security, internationalization, and directory issues
The "Internet Printing Protocol/1.0: Encoding and Transport"
is a formal mapping of the abstract operations and attributes
in the model document onto HTTP/1.1. It defines the encoding
for a new Internet media type called "application/ipp".
The "Internet Printing Protocol/1.0: Implementer's Guide"
gives insight and advice to implementers of IPP clients and
objects. It is intended to help them understand IPP/1.0 and some
the considerations that may assist them in the design of their
and/or IPP object implementations. For example, a typical order
processing requests is given, including error checking.
for some of the specification decisions is also included
The "Mapping between LPD and IPP Protocols" document gives
advice to implementers of gateways between IPP and LPD (Line
Daemon) implementations
1. ARCHITECTURAL
The Internet Printing Protocol (IPP) is an application level
that can be used for distributed printing on the Internet.
protocol defines interactions between a client and a server.
Zilles Experimental [Page 2]
RFC 2568 Rationale for IPP April 1999
protocol allows a client to inquire about capabilities of a printer
to submit print jobs and to inquire about and cancel print jobs.
server for these requests is the Printer; the Printer is
abstraction of a generic document output device and/or a
service provider. Thus, the Printer could be a real printing device
such as a computer printer or fax output device, or it could be
service that interfaced with output devices
The protocol is heavily influenced by the printing model
in the Document Printing Application (DPA) [ISO10175] standard
Although DPA specifies both end user and administrative features,
version 1.0 (IPP/1.0) focuses only on end user functionality
The architecture for IPP defines (in the Model and Semantics
[RFC2566]) an abstract Model for the data which is used to
the printing process and to provide information about the process
the capabilities of the Printer. This abstract Model is
in nature and reflects the structure of the Printer and the Jobs
may be being processed by the Printer
The Internet provides a channel between the client and
server/Printer. Use of this channel requires flattening
sequencing the hierarchical Model data. Therefore, the IPP
defines (in the Encoding and Transport document [RFC2565])
encoding of the data in the model for transfer between the client
server. This transfer of data may be either a request or
response to a request
Finally, the IPP defines (in the Encoding and Transport
[RFC2565]) a protocol for transferring the encoded request
response data between the client and the server/Printer
An example of a typical interaction would be a request from
client to create a print job. The client would assemble the
data to be associated with that job, such as the name of the job,
media to use, the number of pages to place on each media instance
etc. This data would then be encoded according to the Protocol
would be transmitted according to the Protocol. The server/
would receive the encoded Model data, decode it into a
understood by the server/Printer and, based on that data, do one
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
encoded Model data as the response to the request using the Protocol
Another part of the IPP architecture is the Directory
described in the model document. The role of a Directory Schema is
provide a standard set of attributes which might be used to query
Zilles Experimental [Page 3]
RFC 2568 Rationale for IPP April 1999
directory service for the URI of a Printer that is likely to meet
needs of the client. The IPP architecture also addresses
issues such as control of access to server/Printers and
transmissions of requests, response and the data to be printed
2. THE
Because the (abstract) server/Printer encompasses a wide range
implementations, it is necessary to make some assumptions about
minimal implementation. The most likely minimal implementation is
that is embedded in an output device running a specialized real
operating system and with limited processing, memory and
capabilities. This printer will be connected to the Internet and
have at least a TCP/IP capability with (likely) SNMP [RFC1905,
RFC1906] support for the Internet connection. In addition, it
likely the the Printer will be an HTML/HTTP server to allow
user access to information about the printer
3. RATIONALE FOR THE
The Model [RFC2566] is defined independently of any encoding of
Model data both to support the likely uses of IPP and to be
with respect to the possibility of alternate encoding
It is expected that a client or server/Printer would represent
Model data in some data structure within the applications/
that support IPP. Therefore, the Model was designed to make
representation straightforward. Typically a parser or formatter
be used to convert from or to the encoded data format. Once in
internal form suitable to a product, the data can be manipulated
the product. For example, the data sent with a Print Job can be
to control the processing of that Print Job
The semantics of IPP are attached to the (abstract) Model
Therefore, the application/server is not dependent on the encoding
the Model data, and it is possible to consider alternative
and formats by which the data could be transmitted from a client to
server; for example, a server could have a direct, client-less
interface that might be used to accept some kinds of Print Jobs.
independence would also allow a different encoding and/
transmission mechanism to be used if the ones adopted here were
to be overly limiting in the future. Such a change could be
into new products as an alternate protocol stack/parser for the
data
Zilles Experimental [Page 4]
RFC 2568 Rationale for IPP April 1999
Having an abstract Model also allows the Model data to be
with the (abstract) model used in the Printer [RFC1759], Job and
Resources MIBs. This provides consistency in interpretation of
data obtained independently of how the data is accessed, whether
IPP or via SNMP [RFC1905, RFC1906] and the Printer/Job MIBs
There is one aspect of the Model that deserves some
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
Job ID (a 32 bit positive integer). Allowing Job objects to have
allows for flexibility and scalability. For example a job could
moved from a printer with a large backlog to one with a smaller
and the job identification, the Job object URI, need not change
However, many existing printing systems have local models
interface constraints that force Job objects to be identified
only a 32-bit positive integer rather than a URI. This numeric
ID is only unique within the context of the Printer object to
the create request was originally submitted. In order to allow
types of client access to Jobs (either by Job URI or by numeric
ID), when the Printer object successfully processes a create
and creates a new Job, the Printer object generates both a Job
and a Job ID for the new Job object. This requirement allows
clients to access Printer objects and Job objects independent of
local constraints imposed on the client implementation
4. RATIONALE FOR THE
There are two parts to the Protocol: (1) the encoding of the
data and (2) the mechanism for transmitting the model data
client and server
4.1 The
To make it simpler to develop embedded printers, a very simple
encoding has been chosen. This encoding is adequate to represent
kinds of data that occur within the Model. It has a simple
consisting of sequences of attributes. Each attribute has a name
prefixed by a name length, and a value. The names are
constrained to characters from a subset of ASCII. The values
either scalars or a sequence of scalars. Each scalar value has
length specification and a value tag which indicates the type of
value. The value type has two parts: a major class part, such
integer or string, and a minor class part which distinguishes
usage of the major class, such as dateTime string. Tagging of
values with type information allows for introducing new value
at some future time
Zilles Experimental [Page 5]
RFC 2568 Rationale for IPP April 1999
A fully encoded request/response has a version number, an
(for a request) or a status and optionally a status message (for
response), associated parameters and attributes which are
Model data and, optionally (for a request), print data following
Model data
4.2 The Transmission
The chosen mechanism for transmitting the encoded Model data is
1.1 Post (and associated response). No modifications to HTTP 1.1
proposed or required. The sole role of the Transmission Mechanism
to provide a transfer of encoded Model data from/to the
to/from the server. This could be done using any data
mechanism. The key reasons why HTTP 1.1 Post is used are given below
The most important of these is the first. With perhaps
exception, these reasons could be satisfied by other mechanisms
There is no claim that this list uniquely determines a choice
mechanism
1. HTTP 1.0 is already widely deployed and, based on the
evidence, HTTP 1.1 is being widely deployed as the
release new products. The performance benefits of HTTP 1.1
been shown and manufactures are reacting positively
Wide deployment has meant that many of the problems of making
protocol work in a wide range of environments from local net
Intranet to Internet have been solved and will stay solved
HTTP 1.1 deployment
2. HTTP 1.1 solves most of the problems that might have required
new protocol to be developed. HTTP 1.1 allows
connections that make a multi-message protocol be more efficient
for example it is practical to have separate Create-Job and Send
Document messages. Chunking allows the transmission of large
files without having to pre-scan the file to determine the
length. The accept headers allow the client's protocol
localization desires to be transmitted with the IPP operations
data. If the Model were to provide for the redirection of
requests, such as Cancel-Job, when a Job is moved, the
redirect response allows a client to be informed when a Job he
interested in is moved to another server/Printer for any reason
3. Most network Printers will be implementing HTTP servers
reasons other than IPP. These network attached Printers want
provide information on how to use the printer, its current state
HELP information, etc. in HTML. This requires having an
server which would be available to do IPP functions as well
Zilles Experimental [Page 6]
RFC 2568 Rationale for IPP April 1999
4. Most of the complexity of HTTP 1.1 is concerned with
implementation of HTTP proxies and not the implementation of
clients and/or servers. Work is proceeding in the HTTP
Group to help identify what must be done by a server. As
Encoding and Transport document shows, that is not very much
5. HTTP implementations provide support for handling URLs
would have to be provided if a new protocol were defined
6. An HTTP based solution fits well with the Internet
mechanisms that are currently deployed or being deployed.
will run over SSL3. The digest access authentication mechanism
HTTP 1.1 provides an adequate level of access control.
solutions are deployed and in practical use; a new solution
require extensive use to have the same degree of confidence in
security. Note: SSL3 is not on the IETF standards track
7. HTTP provides an extensibility model that a new protocol
have to develop independently. In particular, the headers
intent-types (via Internet Media Types) and error codes have
acceptance and a useful set of definitions and methods
extension
8. Although not strictly a reason why IPP should use HTTP as
transmission protocol, it is extremely helpful that there are
prototyping tools that work with HTTP and that CGI scripts can
used to test and debug parts of the protocol
9. Finally, the POST method was chosen to carry the print
because its usage for data transmission has been established,
works and the results are available via CGI scripts or servlets
Creating a new method would have better identified the
use of the POSTed data, but a new method would be more
to deploy. Assigning a new default port for IPP provided
necessary identification with minimal impact to
infrastructure, so was chosen instead
5. RATIONALE FOR THE DIRECTORY
Successful use of IPP depends on the client finding a suitable
enabled Printer to which to send a IPP requests, such as print
job. This task is simplified if there is a Directory Service
can be queried for a suitable Printer. The purpose of
Directory Schema is to have a standard description of
attributes that can be associated the URI for the printer.
attributes are a subset of the Model attributes and can be
in the appropriate query syntax for the Directory Service
used by the client
Zilles Experimental [Page 7]
RFC 2568 Rationale for IPP April 1999
6. SECURITY CONSIDERATIONS - RATIONALE FOR
Security is an area of active work on the Internet.
solutions to a wide range of security concerns are not
available. Therefore, in the design of IPP, the focus has been
identifying a set of security protocols/features that
implemented (or currently implementable) and solve real
with distributed printing. The two areas that seem appropriate
support are: (1) authorization to use a Printer and (2)
interaction with a printer. The chosen mechanisms are the
authentication mechanism of HTTP 1.1 and SSL3 [SSL]
communication mechanism
7.
[ipp-iig] Hastings, T. and C. Manros, "Internet
Protocol/1.0:Implementer's Guide", Work in Progress
[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin
"Mapping between LPD and IPP Protocols", RFC 2569,
1999.
[RFC2566] deBry, R., Isaacson, S., Hastings, T., Herriot, R. and P
Powell, "Internet Printing Protocol/1.0: Model
Semantics", RFC 2566, April 1999.
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "
Printing Protocol/1.0: Encoding and Transport", RFC 2565,
April 1999.
[RFC2567] Wright, D., "Design Goals for an Internet
Protocol", RFC 2567, April 1999.
[ISO10175] ISO/IEC 10175 "Document Printing Application (DPA)",
1996.
[RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J
Gyllenskog, "Printer MIB", RFC 1759, March 1995.
[RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser
"Protocol Operations for Version 2 of the Simple
Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser
"Transport Mappings for Version 2 of the Simple
Management Protocol (SNMPv2)", RFC 1906, January 1996.
Zilles Experimental [Page 8]
RFC 2568 Rationale for IPP April 1999
[SSL] Netscape, The SSL Protocol, Version 3, (Text
3.02), November 1996.
8. AUTHOR'S
Stephen
Adobe Systems
345 Park
MailStop W14
San Jose, CA 95110-2704
Phone: +1 408 536-4766
Fax: +1 408 537-4042
EMail: szilles@adobe.
Zilles Experimental [Page 9]
RFC 2568 Rationale for IPP April 1999
9. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Zilles Experimental [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
