doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc2568.txt b/doc/rfc/rfc2568.txt
new file mode 100644
index 0000000..2d3ae49
--- /dev/null
+++ b/doc/rfc/rfc2568.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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]
+
+RFC 2568                   Rationale for IPP                  April 1999
+
+
+   A fully encoded request/response has a version number, an operation
+   (for a request) or a status and optionally a status message (for a
+   response), associated parameters and attributes which are encoded
+   Model data and, optionally (for a request), print data following the
+   Model data.
+
+4.2 The Transmission Mechanism
+
+   The chosen mechanism for transmitting the encoded Model data is HTTP
+   1.1 Post (and associated response). No modifications to HTTP 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 client
+   to/from the server. This could be done using any data delivery
+   mechanism. The key reasons why HTTP 1.1 Post is used are given below.
+   The most important of these is the first. With perhaps this
+   exception, these reasons could be satisfied by other mechanisms.
+   There is no claim that this list uniquely determines a choice of
+   mechanism.
+
+      1. HTTP 1.0 is already widely deployed and, based on the recent
+      evidence, HTTP 1.1 is being widely deployed as the manufacturers
+      release new products. The performance benefits of HTTP 1.1 have
+      been shown and manufactures are reacting positively.
+
+      Wide deployment has meant that many of the problems of making a
+      protocol work in a wide range of environments from local net to
+      Intranet to Internet have been solved and will stay solved with
+      HTTP 1.1 deployment.
+
+      2. HTTP 1.1 solves most of the problems that might have required a
+      new protocol to be developed. HTTP 1.1 allows persistent
+      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 print
+      files without having to pre-scan the file to determine the file
+      length. The accept headers 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.
+
+      3. Most network Printers will be implementing HTTP servers for
+      reasons other than IPP. These network attached Printers want to
+      provide information on how to use the printer, its current state,
+      HELP information, etc. in HTML. This requires having an HTTP
+      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 the
+      implementation of HTTP proxies and not the implementation of HTTP
+      clients and/or servers. Work is proceeding in the HTTP Working
+      Group to help identify what must be done by a server.  As the
+      Encoding and Transport document shows, that is not very much.
+
+      5. HTTP implementations provide support for handling URLs that
+      would have to be provided if a new protocol were defined.
+
+      6. An HTTP based solution fits well with the Internet security
+      mechanisms that are currently deployed or being deployed. HTTP
+      will run over SSL3. The digest access authentication mechanism of
+      HTTP 1.1 provides an adequate level of access control. 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.  Note: SSL3 is not on the IETF standards track.
+
+      7. HTTP provides an extensibility model that a new protocol would
+      have to develop independently. In particular, the headers,
+      intent-types (via Internet Media Types) and error codes have wide
+      acceptance and a useful set of definitions and methods for
+      extension.
+
+      8. Although not strictly a reason why IPP should use HTTP as the
+      transmission protocol, it is extremely helpful that there are many
+      prototyping tools that work with HTTP and that CGI scripts can be
+      used to test and debug parts of the protocol.
+
+      9. Finally, the POST method was chosen to carry the print data
+      because its usage for data transmission has been established, it
+      works and the results are available via CGI scripts or servlets.
+      Creating a new method would have better identified the intended
+      use of the POSTed data, but a new method would be more difficult
+      to deploy. Assigning a new default port for IPP provided the
+      necessary identification with minimal impact to installed
+      infrastructure, so was chosen instead.
+
+5. RATIONALE FOR THE DIRECTORY SCHEMA
+
+      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
+      job. This task is simplified if there is a Directory Service which
+      can be queried for a suitable Printer. The purpose of the
+      Directory Schema is to have a standard description of Printer
+      attributes that can be associated the URI for the printer. These
+      attributes are a subset of the Model attributes and can be encoded
+      in the appropriate query syntax for the Directory Service being
+      used by the client.
+
+
+
+Zilles                        Experimental                      [Page 7]
+
+RFC 2568                   Rationale for IPP                  April 1999
+
+
+6. SECURITY CONSIDERATIONS - RATIONALE FOR SECURITY
+
+      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.
+
+7. REFERENCES
+
+   [ipp-iig]  Hastings, T. and C. Manros, "Internet Printing
+              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, April
+              1999.
+
+   [RFC2566]  deBry, R., Isaacson, S., Hastings, T., Herriot, R. and P.
+              Powell, "Internet Printing Protocol/1.0: Model and
+              Semantics", RFC 2566, April 1999.
+
+   [RFC2565]  Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet
+              Printing Protocol/1.0: Encoding and Transport", RFC 2565,
+              April 1999.
+
+   [RFC2567]  Wright, D., "Design Goals for an Internet Printing
+              Protocol", RFC 2567, April 1999.
+
+   [ISO10175] ISO/IEC 10175 "Document Printing Application (DPA)", June
+              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 Network
+              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 Network
+              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 version
+              3.02), November 1996.
+
+8. AUTHOR'S ADDRESS
+
+   Stephen Zilles
+   Adobe Systems Incorporated
+   345 Park Avenue
+   MailStop W14
+   San Jose, CA 95110-2704
+
+   Phone: +1 408 536-4766
+   Fax:   +1 408 537-4042
+   EMail: szilles@adobe.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zilles                        Experimental                      [Page 9]
+
+RFC 2568                   Rationale for IPP                  April 1999
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or 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 not be
+   revoked by the Internet Society or its successors or assigns.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zilles                        Experimental                     [Page 10]
+