rfc2567.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                       F.D. Wright
Request for Comments: 2567                        Lexmark International
Category: Experimental                                       April 1999


             Design Goals for an 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.  Implementers 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 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



Wright                        Experimental                      [Page 1]

RFC 2567             Internet Printing Design Goals           April 1999


   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 full set of IPP documents includes:

   Design Goals for an Internet Printing Protocol (this document)
   Rationale for the Structure and Model and Protocol for the
   Internet Printing Protocol [RFC2568]
   Internet Printing Protocol/1.0: Model and Semantics [RFC2568]
   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 "Rationale for the Structure and Model and Protocol for the
   Internet Printing Protocol" 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.

   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.  IPP 1.0 semantics allow
   end-users and operators to query printer capabilities, submit print
   jobs, inquire about the status of print jobs and printers, and cancel
   print jobs.  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.





Wright                        Experimental                      [Page 2]

RFC 2567             Internet Printing Design Goals           April 1999


TABLE OF CONTENTS

   1. INTRODUCTION.....................................................4
   2. TERMINOLOGY......................................................4
   3. DESIGN GOALS.....................................................6
   3.1. End-user.......................................................6
   3.1.1. Finding or locating a printer................................6
   3.1.2. Create an instance of the printer............................7
   3.1.3. Viewing the status and capabilities of a printer.............7
   3.1.4. Submitting a print job.......................................8
   3.1.5. Viewing the status of a submitted print job..................9
   3.1.6. Canceling a Print Job........................................9
   3.2. Operator (NOT REQUIRED FOR V1.0)...............................9
   3.2.1. Alerting.....................................................9
   3.2.2. Changing Print and Job Status...............................10
   3.3. Administrator (NOT REQUIRED FOR v1.0).........................10
   4. OBJECTIVES OF THE PROTOCOL......................................10
   4.1. SECURITY CONSIDERATIONS.......................................11
   4.2. Interaction with LPD (RFC1179)................................12
   4.3. Extensibility.................................................12
   4.4. Firewalls.....................................................13
   4.5. Internationalization..........................................13
   5. IPP SCENARIOS...................................................13
   5.1. Printer Discovery.............................................14
   5.2. Driver Installation...........................................15
   5.3. Submitting a Print Job........................................15
   5.4. Getting Status/Capabilities...................................16
   5.5. Asynchronous Notification.....................................17
   5.6. Job Canceling.................................................17
   6. Security Considerations.........................................18
   7. REFERENCES......................................................18
   8. ACKNOWLEDGMENTS.................................................19
   9. AUTHOR'S ADDRESS................................................19
   10. APPENDIX - DETAILED SCENARIOS..................................20
   10.1. Printer discovery within an enterprise.......................20
   10.2. Printer discovery across enterprises.........................21
   10.3. Printer discovery on the Internet -logical operations........21
   10.4. Printer discovery on the Internet - authentication...........22
   10.5. Driver Download..............................................23
   10.6. Submitting a print job as a file.............................24
   10.7. Submitting a print job with two documents....................24
   10.8. Submitting a print job as a file, printing fails.............25
   10.9. Submitting a print job with authentication, PRIVACY and
         payment......................................................26
   10.10. Submitting a print job with decryption error................27
   10.11. Submitting a print job with authentication..................28
   10.12. Submitting a print job generated dynamically................29
   10.13. Submitting a print job with a Printer jam - CANCELED........29



Wright                        Experimental                      [Page 3]

RFC 2567             Internet Printing Design Goals           April 1999


   10.14. Submitting a print job with a Printer jam - recovered.......30
   10.15. Submitting a print job with server pull.....................31
   10.16. Submitting a print job with referenced resources............32
   10.17. Getting Capabilities........................................33
   10.17.1. Submission Attributes.....................................33
   10.17.2. Printer Capabilities......................................33
   10.18. Getting Status..............................................34
   10.18.1. Printer State/Status......................................34
   10.18.2. Job Status................................................34
   10.18.3. Status of All My Jobs.....................................34
   10.19. Asynchronous Notification...................................35
   10.19.1. Job Completion............................................35
   10.19.2. Job Complete with Data....................................35
   10.19.3. Print Job Fails...........................................35
   10.20. Cancel a job................................................36
   10.21. End to end Scenario - within an enterprise..................36
   10.22. End to end Scenario - across enterprises....................37
   10.23. End to End Scenario - on the internet.......................40
   11. Full Copyright Statement.......................................43

1. INTRODUCTION

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

2. TERMINOLOGY

   Internet Printing for the purposes of this document is the
   application of Internet tools, programs, servers and networks to
   allow end-users to print to a remote printer using, after initial
   setup or configuration, the same methods, operations and paradigms as
   would be used for a locally attached or a local area network attached
   printer.  This could include the use of HTTP servers and browsers and
   other applications for providing static, dynamic and interactive
   printer locating services, user installation, selection,
   configuration, print job submission, printer capability inquiry and
   status inquiry of remote printers and jobs.

   For the purposes of this document, a WEB Browser is software
   available from a number of sources including but not limited to the
   following:  Microsoft Internet Explorer, NCSA Mosaic, Netscape
   Navigator, Sun Hot Java!.  The major task of these products is to use
   the Hypertext Transport Protocol (HTTP) to retrieve, interpret and
   display Hypertext Markup Language (HTML).  These products are often a
   part of a complete Internet Printing system because they are often



Wright                        Experimental                      [Page 4]

RFC 2567             Internet Printing Design Goals           April 1999


   used as a means of obtaining the status of or more information about
   the printing system; however, they may not be present in all
   implementations.

   Throughout this document, 'printer' shall be interpreted to include
   any device which is capable of marking on a piece of media using any
   available technology.  These design goals do not include support for
   multi-tiered printing solutions involving servers (single or
   multiple) logically in front of the actual printing device yet all
   such configurations shall be supported but shall appear to the end-
   user as only a single device.

   Throughout this document 'driver' refers to the code installed in
   some client operating system to generate the print data stream for
   the intended printer. Some computing environments may not include a
   separate printer driver.  Rather, the generation of the proper print
   data stream is accomplished in an application on that computer. How
   such a computer environment or application is updated to support a
   new printer now made available using IPP is outside the scope of IPP.
   The actual details for installing a printer driver are operating
   system dependent and are also outside the scope of IPP. See also
   section 4.1 (SECURITY CONSIDERATIONS) for security implications of
   driver download and installation.

   The IPP protocol will support the following physical configurations:

   - An IPP client talking to an IPP Printer object imbedded in a
     single, physical output device.
   - An IPP Client talking to a server containing one or more IPP
     Printer objects. Each Printer object is associated with exactly one
     physical output device supported by the server. The protocol
     between the server and the output devices is undefined.
   - An IPP Client talking to an IPP Printer object in a server. The
     Printer object is associated with one or more physical output
     devices, but the client only sees the Printer object, which is an
     abstraction and represents all of the associated physical output
     devices. The protocol between the server and the physical output
     devices is undefined.

   Throughout this document, certain design goals will be identified as
   not being a part of version 1.0 (or V1.0) of the protocol or as being
   satisfied by means outside of IPP.  IPP is assumed to be one part, an
   enabler, of a complete Internet Printing solution.  For example
   printer instance creation is not performed by but is enabled by the
   protocol.  Globally, none of the operator or administrators wants and
   needs are included in the design goals for version 1.0.  Some of the
   end-user wants and needs may also be excluded from version 1.0 and
   will be so noted in the description of them.  Subsequent versions of



Wright                        Experimental                      [Page 5]

RFC 2567             Internet Printing Design Goals           April 1999


   the protocol (e.g. V2.0) may include support for these initially
   excluded wants and needs.

3. DESIGN GOALS

   The next three sections identify the design goals for an Internet
   printing protocol from three roles assumed by humans: end-user,
   operator, and administrator.  The goals defined here are only those
   that need to be addressed by an Internet printing protocol.  Other
   wants and needs, such as that the operator needs physical access to
   the printer (e.g. to be able to load paper or clear jams) are not
   covered by this document.  Section 5 contains scenarios which provide
   more detailed examples of the entire process including discovery,
   status, printing and end-of-job reporting.

3.1. END-USER

   An end-user of a printer accepting jobs through the Internet is one
   of the roles in which humans act.  The end-user is the person that
   will submit a job to be printed on the printer.

   The wants and needs of the end-user are broken down into six
   categories: finding/locating a printer, creating a local instance of
   a printer, viewing printer status, viewing printer capabilities,
   submitting a print job, viewing print job status, altering the
   attributes of a print job.

3.1.1. Finding or locating a printer.

   End-users want to be able to find and locate printers to which they
   are authorized to print.  They want to be able to perform this
   function using a standard WEB browser or other application.  Multiple
   criteria can be applied to find the printers needed.  These criteria
   include but are not limited to:

   - by name (Printer 1, Joes-color-printer, etc.)
   - by geographic location (bldg 1, Kentucky, etc.)
   - by capability or attribute (color, duplex, legal paper, etc.)

   Additionally, while it is outside of scope of IPP, end-users want to
   be able to limit the scope of their searching to:

   - inside a functional sub-domain
   - include only a particular domain (lexmark.com)
   - exclude specified domains