rfc2568.txt

RFC 的详细文档！

Network Working Group                                          S. Zilles
Request for Comments: 2568                            Adobe Systems Inc.
Category: Experimental                                        April 1999


         Rationale for the Structure of the Model and Protocol
                   for the Internet Printing Protocol

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   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 Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

IESG Note

   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

   This document is one of a set of documents, which together describe
   all aspects of a new Internet Printing Protocol (IPP).  IPP is an
   application level protocol that can be used for distributed printing
   using Internet tools and technologies. This document describes IPP
   from a high level view, defines a roadmap for the various documents
   that form the suite of IPP specifications, and gives background and
   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 the
      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 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 Design Goals 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.

   The "Internet Printing Protocol/1.0: Model and Semantics" document
   describes a simplified model consisting of abstract objects, their
   attributes, and their operations that is independent of encoding and
   transport.  The model consists of a Printer and a Job object.  The
   Job optionally supports multiple documents.  This document also
   addresses security, internationalization, and directory issues.

   The "Internet Printing Protocol/1.0: Encoding and Transport" document
   is a formal mapping of the abstract operations and attributes defined
   in the model document onto HTTP/1.1.  It defines the encoding rules
   for a new Internet media type called "application/ipp".

   The "Internet Printing Protocol/1.0: Implementer's Guide" document
   gives insight and advice to implementers of IPP clients and IPP
   objects.  It is intended to help them understand IPP/1.0 and some of
   the considerations that may assist them in the design of their client
   and/or IPP object implementations.  For example, a typical order of
   processing requests is given, including error checking.  Motivation
   for some of the specification decisions is also included.

   The "Mapping between LPD and IPP Protocols" document gives some
   advice to implementers of gateways between IPP and LPD (Line Printer
   Daemon) implementations.

1.   ARCHITECTURAL OVERVIEW

   The Internet Printing Protocol (IPP) is an application level protocol
   that can be used for distributed printing on the Internet.  This
   protocol defines interactions between a client and a server.  The



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. The
   server for these requests is the Printer; the Printer is an
   abstraction of a generic document output device and/or a print
   service provider. Thus, the Printer could be a real printing device,
   such as a computer printer or fax output device, or it could be a
   service that interfaced with output devices.

   The protocol is heavily influenced by the printing model introduced
   in the Document Printing Application (DPA) [ISO10175] standard.
   Although DPA specifies both end user and administrative features, IPP
   version 1.0 (IPP/1.0) focuses only on end user functionality.

   The architecture for IPP defines (in the Model and Semantics document
   [RFC2566]) an abstract Model for the data which is used to control
   the printing process and to provide information about the process and
   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
   server/Printer. Use of this channel requires flattening and
   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.

   Finally, the IPP defines (in the Encoding and Transport document
   [RFC2565]) a protocol for transferring the encoded request and
   response data between the client and the server/Printer.

   An example of a typical interaction would be a request from the
   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.

   Another part of the IPP architecture is the Directory Schema
   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



Zilles                        Experimental                      [Page 3]

RFC 2568                   Rationale for IPP                  April 1999


   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.

2. THE PRINTER

   Because the (abstract) server/Printer encompasses a wide range of
   implementations, it is necessary to make some 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

   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
   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.
   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.







Zilles                        Experimental                      [Page 4]

RFC 2568                   Rationale for IPP                  April 1999


   Having an abstract Model also allows the Model data to be aligned
   with the (abstract) model used in the Printer [RFC1759], Job and Host
   Resources MIBs. This provides consistency in interpretation of the
   data obtained independently of how the data is accessed, whether via
   IPP or via SNMP [RFC1905, RFC1906] and the Printer/Job MIBs.

   There is one aspect of the Model that deserves some extra
   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
   Job ID (a 32 bit positive integer). Allowing Job objects to have URIs
   allows for flexibility and scalability. For example a job could be
   moved from a printer with a large backlog to one with a smaller load
   and the job identification, the Job object URI, need not change.
   However, many existing printing systems have local models or
   interface constraints that force Job objects to be identified using
   only a 32-bit positive integer rather than a URI.  This numeric Job
   ID is only unique within the context of the Printer object to which
   the create request was originally submitted.  In order to allow both
   types of client access to Jobs (either by Job URI or by numeric Job
   ID), when the Printer object successfully processes a create request
   and creates a new Job, the Printer object generates both a Job URI
   and a Job ID for the new Job object. This requirement allows all
   clients to access Printer objects and Job objects independent of any
   local constraints imposed on the client implementation.

4. RATIONALE FOR THE PROTOCOL

   There are two parts to the Protocol: (1) the encoding of the Model
   data and (2) the mechanism for transmitting the model data between
   client and server.

4.1 The Encoding

   To make it simpler to develop embedded printers, a very simple binary
   encoding has been chosen. This encoding is adequate to represent the
   kinds of data that occur within the Model. It has a simple structure
   consisting of sequences of attributes. Each attribute has a name,
   prefixed by a name length, and a value. The names are strings
   constrained to characters from a subset of ASCII.  The values are
   either scalars or a sequence of scalars. Each scalar value has a
   length specification and a value tag which indicates the type of the
   value. The value type has two parts: a major class part, such as
   integer or string, and a minor class 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.





Zilles                        Experimental                      [Page 5]