standards/rfc2568.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          S. Zilles
   8 Request for Comments: 2568                            Adobe Systems Inc.
   9 Category: Experimental                                        April 1999
  10
  11
  12          Rationale for the Structure of the Model and Protocol
  13                    for the Internet Printing Protocol
  14
  15 Status of this Memo
  16
  17    This memo defines an Experimental Protocol for the Internet
  18    community.  It does not specify an Internet standard of any kind.
  19    Discussion and suggestions for improvement are requested.
  20    Distribution of this memo is unlimited.
  21
  22 Copyright Notice
  23
  24    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  25
  26 IESG Note
  27
  28    This document defines an Experimental protocol for the Internet
  29    community.  The IESG expects that a revised version of this protocol
  30    will be published as Proposed Standard protocol.  The Proposed
  31    Standard, when published, is expected to change from the protocol
  32    defined in this memo.  In particular, it is expected that the
  33    standards-track version of the protocol will incorporate strong
  34    authentication and privacy features, and that an "ipp:" URL type will
  35    be defined which supports those security measures.  Other changes to
  36    the protocol are also possible.  Implementors are warned that future
  37    versions of this protocol may not interoperate with the version of
  38    IPP defined in this document, or if they do interoperate, that some
  39    protocol features may not be available.
  40
  41    The IESG encourages experimentation with this protocol, especially in
  42    combination with Transport Layer Security (TLS) [RFC2246], to help
  43    determine how TLS may effectively be used as a security layer for
  44    IPP.
  45
  46 ABSTRACT
  47
  48    This document is one of a set of documents, which together describe
  49    all aspects of a new Internet Printing Protocol (IPP).  IPP is an
  50    application level protocol that can be used for distributed printing
  51    using Internet tools and technologies. This document describes IPP
  52    from a high level view, defines a roadmap for the various documents
  53    that form the suite of IPP specifications, and gives background and
  54    rationale for the IETF working group's major decisions.
  55
  56
  57
  58 Zilles                        Experimental                      [Page 1]
  59 \f
  60 RFC 2568                   Rationale for IPP                  April 1999
  61
  62
  63    The full set of IPP documents includes:
  64
  65       Design Goals for an Internet Printing Protocol [RFC2567]
  66       Rationale for the Structure and Model and Protocol for the
  67       Internet Printing Protocol (this document)
  68       Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
  69       Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
  70       Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
  71       Mapping between LPD and IPP Protocols [RFC2569]
  72
  73    The "Design Goals for an Internet Printing Protocol" document takes a
  74    broad look at distributed printing functionality, and it enumerates
  75    real-life scenarios that help to clarify the features that need to be
  76    included in a printing protocol for the Internet.  It identifies
  77    requirements for three types of users: end users, operators, and
  78    administrators.  The Design Goals document calls out a subset of end
  79    user requirements that are satisfied in IPP/1.0. Operator and
  80    administrator requirements are out of scope for version 1.0.
  81
  82    The "Internet Printing Protocol/1.0: Model and Semantics" document
  83    describes a simplified model consisting of abstract objects, their
  84    attributes, and their operations that is independent of encoding and
  85    transport.  The model consists of a Printer and a Job object.  The
  86    Job optionally supports multiple documents.  This document also
  87    addresses security, internationalization, and directory issues.
  88
  89    The "Internet Printing Protocol/1.0: Encoding and Transport" document
  90    is a formal mapping of the abstract operations and attributes defined
  91    in the model document onto HTTP/1.1.  It defines the encoding rules
  92    for a new Internet media type called "application/ipp".
  93
  94    The "Internet Printing Protocol/1.0: Implementer's Guide" document
  95    gives insight and advice to implementers of IPP clients and IPP
  96    objects.  It is intended to help them understand IPP/1.0 and some of
  97    the considerations that may assist them in the design of their client
  98    and/or IPP object implementations.  For example, a typical order of
  99    processing requests is given, including error checking.  Motivation
 100    for some of the specification decisions is also included.
 101
 102    The "Mapping between LPD and IPP Protocols" document gives some
 103    advice to implementers of gateways between IPP and LPD (Line Printer
 104    Daemon) implementations.
 105
 106 1.   ARCHITECTURAL OVERVIEW
 107
 108    The Internet Printing Protocol (IPP) is an application level protocol
 109    that can be used for distributed printing on the Internet.  This
 110    protocol defines interactions between a client and a server.  The
 111
 112
 113
 114 Zilles                        Experimental                      [Page 2]
 115 \f
 116 RFC 2568                   Rationale for IPP                  April 1999
 117
 118
 119    protocol allows a client to inquire about capabilities of a printer,
 120    to submit print jobs and to inquire about and cancel print jobs. The
 121    server for these requests is the Printer; the Printer is an
 122    abstraction of a generic document output device and/or a print
 123    service provider. Thus, the Printer could be a real printing device,
 124    such as a computer printer or fax output device, or it could be a
 125    service that interfaced with output devices.
 126
 127    The protocol is heavily influenced by the printing model introduced
 128    in the Document Printing Application (DPA) [ISO10175] standard.
 129    Although DPA specifies both end user and administrative features, IPP
 130    version 1.0 (IPP/1.0) focuses only on end user functionality.
 131
 132    The architecture for IPP defines (in the Model and Semantics document
 133    [RFC2566]) an abstract Model for the data which is used to control
 134    the printing process and to provide information about the process and
 135    the capabilities of the Printer. This abstract Model is hierarchical
 136    in nature and reflects the structure of the Printer and the Jobs that
 137    may be being processed by the Printer.
 138
 139    The Internet provides a channel between the client and the
 140    server/Printer. Use of this channel requires flattening and
 141    sequencing the hierarchical Model data. Therefore, the IPP also
 142    defines (in the Encoding and Transport document [RFC2565]) an
 143    encoding of the data in the model for transfer between the client and
 144    server.  This transfer of data may be either a request or the
 145    response to a request.
 146
 147    Finally, the IPP defines (in the Encoding and Transport document
 148    [RFC2565]) a protocol for transferring the encoded request and
 149    response data between the client and the server/Printer.
 150
 151    An example of a typical interaction would be a request from the
 152    client to create a print job. The client would assemble the Model
 153    data to be associated with that job, such as the name of the job, the
 154    media to use, the number of pages to place on each media instance,
 155    etc. This data would then be encoded according to the Protocol and
 156    would be transmitted according to the Protocol. The server/Printer
 157    would receive the encoded Model data, decode it into a form
 158    understood by the server/Printer and, based on that data, do one of
 159    two things: (1) accept the job or (2) reject the job. In either case,
 160    the server must construct a response in terms of the Model data,
 161    encode that response according to the Protocol and transmit that
 162    encoded Model data as the response to the request using the Protocol.
 163
 164    Another part of the IPP architecture is the Directory Schema
 165    described in the model document. The role of a Directory Schema is to
 166    provide a standard set of attributes which might be used to query a
 167
 168
 169
 170 Zilles                        Experimental                      [Page 3]
 171 \f
 172 RFC 2568                   Rationale for IPP                  April 1999
 173
 174
 175    directory service for the URI of a Printer that is likely to meet the
 176    needs of the client. The IPP architecture also addresses security
 177    issues such as control of access to server/Printers and secure
 178    transmissions of requests, response and the data to be printed.
 179
 180 2. THE PRINTER
 181
 182    Because the (abstract) server/Printer encompasses a wide range of
 183    implementations, it is necessary to make some assumptions about a
 184    minimal implementation. The most likely minimal implementation is one
 185    that is embedded in an output device running a specialized real time
 186    operating system and with limited processing, memory and storage
 187    capabilities. This printer will be connected to the Internet and will
 188    have at least a TCP/IP capability with (likely) SNMP [RFC1905,
 189    RFC1906] support for the Internet connection. In addition, it is
 190    likely the the Printer will be an HTML/HTTP server to allow direct
 191    user access to information about the printer.
 192
 193 3. RATIONALE FOR THE MODEL
 194
 195    The Model [RFC2566] is defined independently of any encoding of the
 196    Model data both to support the likely uses of IPP and to be robust
 197    with respect to the possibility of alternate encoding.
 198
 199    It is expected that a client or server/Printer would represent the
 200    Model data in some data structure within the applications/servers
 201    that support IPP. Therefore, the Model was designed to make that
 202    representation straightforward. Typically a parser or formatter would
 203    be used to convert from or to the encoded data format. Once in an
 204    internal form suitable to a product, the data can be manipulated by
 205    the product. For example, the data sent with a Print Job can be used
 206    to control the processing of that Print Job.
 207
 208    The semantics of IPP are attached to the (abstract) Model.
 209    Therefore, the application/server is not dependent on the encoding of
 210    the Model data, and it is possible to consider alternative mechanisms
 211    and formats by which the data could be transmitted from a client to a
 212    server; for example, a server could have a direct, client-less GUI
 213    interface that might be used to accept some kinds of Print Jobs. This
 214    independence would also allow a different encoding and/or
 215    transmission mechanism to be used if the ones adopted here were shown
 216    to be overly limiting in the future. Such a change could be migrated
 217    into new products as an alternate protocol stack/parser for the Model
 218    data.
 219
 220
 221
 222
 223
 224
 225
 226 Zilles                        Experimental                      [Page 4]
 227 \f
 228 RFC 2568                   Rationale for IPP                  April 1999
 229
 230
 231    Having an abstract Model also allows the Model data to be aligned
 232    with the (abstract) model used in the Printer [RFC1759], Job and Host
 233    Resources MIBs. This provides consistency in interpretation of the
 234    data obtained independently of how the data is accessed, whether via
 235    IPP or via SNMP [RFC1905, RFC1906] and the Printer/Job MIBs.
 236
 237    There is one aspect of the Model that deserves some extra
 238    explanation. There are two ways for identifying a Job object: (a)
 239    with a Job URI and (b) using a combination of the Printer URI and a
 240    Job ID (a 32 bit positive integer). Allowing Job objects to have URIs
 241    allows for flexibility and scalability. For example a job could be
 242    moved from a printer with a large backlog to one with a smaller load
 243    and the job identification, the Job object URI, need not change.
 244    However, many existing printing systems have local models or
 245    interface constraints that force Job objects to be identified using
 246    only a 32-bit positive integer rather than a URI.  This numeric Job
 247    ID is only unique within the context of the Printer object to which
 248    the create request was originally submitted.  In order to allow both
 249    types of client access to Jobs (either by Job URI or by numeric Job
 250    ID), when the Printer object successfully processes a create request
 251    and creates a new Job, the Printer object generates both a Job URI
 252    and a Job ID for the new Job object. This requirement allows all
 253    clients to access Printer objects and Job objects independent of any
 254    local constraints imposed on the client implementation.
 255
 256 4. RATIONALE FOR THE PROTOCOL
 257
 258    There are two parts to the Protocol: (1) the encoding of the Model
 259    data and (2) the mechanism for transmitting the model data between
 260    client and server.
 261
 262 4.1 The Encoding
 263
 264    To make it simpler to develop embedded printers, a very simple binary
 265    encoding has been chosen. This encoding is adequate to represent the
 266    kinds of data that occur within the Model. It has a simple structure
 267    consisting of sequences of attributes. Each attribute has a name,
 268    prefixed by a name length, and a value. The names are strings
 269    constrained to characters from a subset of ASCII.  The values are
 270    either scalars or a sequence of scalars. Each scalar value has a
 271    length specification and a value tag which indicates the type of the
 272    value. The value type has two parts: a major class part, such as
 273    integer or string, and a minor class part which distinguishes the
 274    usage of the major class, such as dateTime string. Tagging of the
 275    values with type information allows for introducing new value types
 276    at some future time.
 277
 278
 279
 280
 281
 282 Zilles                        Experimental                      [Page 5]
 283 \f
 284 RFC 2568                   Rationale for IPP                  April 1999
 285
 286
 287    A fully encoded request/response has a version number, an operation
 288    (for a request) or a status and optionally a status message (for a
 289    response), associated parameters and attributes which are encoded
 290    Model data and, optionally (for a request), print data following the
 291    Model data.
 292
 293 4.2 The Transmission Mechanism
 294
 295    The chosen mechanism for transmitting the encoded Model data is HTTP
 296    1.1 Post (and associated response). No modifications to HTTP 1.1 are
 297    proposed or required. The sole role of the Transmission Mechanism is
 298    to provide a transfer of encoded Model data from/to the client
 299    to/from the server. This could be done using any data delivery
 300    mechanism. The key reasons why HTTP 1.1 Post is used are given below.
 301    The most important of these is the first. With perhaps this
 302    exception, these reasons could be satisfied by other mechanisms.
 303    There is no claim that this list uniquely determines a choice of
 304    mechanism.
 305
 306       1. HTTP 1.0 is already widely deployed and, based on the recent
 307       evidence, HTTP 1.1 is being widely deployed as the manufacturers
 308       release new products. The performance benefits of HTTP 1.1 have
 309       been shown and manufactures are reacting positively.
 310
 311       Wide deployment has meant that many of the problems of making a
 312       protocol work in a wide range of environments from local net to
 313       Intranet to Internet have been solved and will stay solved with
 314       HTTP 1.1 deployment.
 315
 316       2. HTTP 1.1 solves most of the problems that might have required a
 317       new protocol to be developed. HTTP 1.1 allows persistent
 318       connections that make a multi-message protocol be more efficient;
 319       for example it is practical to have separate Create-Job and Send-
 320       Document messages. Chunking allows the transmission of large print
 321       files without having to pre-scan the file to determine the file
 322       length. The accept headers allow the client's protocol and
 323       localization desires to be transmitted with the IPP operations and
 324       data. If the Model were to provide for the redirection of Job
 325       requests, such as Cancel-Job, when a Job is moved, the HTTP
 326       redirect response allows a client to be informed when a Job he is
 327       interested in is moved to another server/Printer for any reason.
 328
 329       3. Most network Printers will be implementing HTTP servers for
 330       reasons other than IPP. These network attached Printers want to
 331       provide information on how to use the printer, its current state,
 332       HELP information, etc. in HTML. This requires having an HTTP
 333       server which would be available to do IPP functions as well.
 334
 335
 336
 337
 338 Zilles                        Experimental                      [Page 6]
 339 \f
 340 RFC 2568                   Rationale for IPP                  April 1999
 341
 342
 343       4.  Most of the complexity of HTTP 1.1 is concerned with the
 344       implementation of HTTP proxies and not the implementation of HTTP
 345       clients and/or servers. Work is proceeding in the HTTP Working
 346       Group to help identify what must be done by a server.  As the
 347       Encoding and Transport document shows, that is not very much.
 348
 349       5. HTTP implementations provide support for handling URLs that
 350       would have to be provided if a new protocol were defined.
 351
 352       6. An HTTP based solution fits well with the Internet security
 353       mechanisms that are currently deployed or being deployed. HTTP
 354       will run over SSL3. The digest access authentication mechanism of
 355       HTTP 1.1 provides an adequate level of access control. These
 356       solutions are deployed and in practical use; a new solution would
 357       require extensive use to have the same degree of confidence in its
 358       security.  Note: SSL3 is not on the IETF standards track.
 359
 360       7. HTTP provides an extensibility model that a new protocol would
 361       have to develop independently. In particular, the headers,
 362       intent-types (via Internet Media Types) and error codes have wide
 363       acceptance and a useful set of definitions and methods for
 364       extension.
 365
 366       8. Although not strictly a reason why IPP should use HTTP as the
 367       transmission protocol, it is extremely helpful that there are many
 368       prototyping tools that work with HTTP and that CGI scripts can be
 369       used to test and debug parts of the protocol.
 370
 371       9. Finally, the POST method was chosen to carry the print data
 372       because its usage for data transmission has been established, it
 373       works and the results are available via CGI scripts or servlets.
 374       Creating a new method would have better identified the intended
 375       use of the POSTed data, but a new method would be more difficult
 376       to deploy. Assigning a new default port for IPP provided the
 377       necessary identification with minimal impact to installed
 378       infrastructure, so was chosen instead.
 379
 380 5. RATIONALE FOR THE DIRECTORY SCHEMA
 381
 382       Successful use of IPP depends on the client finding a suitable IPP
 383       enabled Printer to which to send a IPP requests, such as print a
 384       job. This task is simplified if there is a Directory Service which
 385       can be queried for a suitable Printer. The purpose of the
 386       Directory Schema is to have a standard description of Printer
 387       attributes that can be associated the URI for the printer. These
 388       attributes are a subset of the Model attributes and can be encoded
 389       in the appropriate query syntax for the Directory Service being
 390       used by the client.
 391
 392
 393
 394 Zilles                        Experimental                      [Page 7]
 395 \f
 396 RFC 2568                   Rationale for IPP                  April 1999
 397
 398
 399 6. SECURITY CONSIDERATIONS - RATIONALE FOR SECURITY
 400
 401       Security is an area of active work on the Internet. Complete
 402       solutions to a wide range of security concerns are not yet
 403       available. Therefore, in the design of IPP, the focus has been on
 404       identifying a set of security protocols/features that are
 405       implemented (or currently implementable) and solve real problems
 406       with distributed printing. The two areas that seem appropriate to
 407       support are: (1) authorization to use a Printer and (2) secure
 408       interaction with a printer. The chosen mechanisms are the digest
 409       authentication mechanism of HTTP 1.1 and SSL3 [SSL] secure
 410       communication mechanism.
 411
 412 7. REFERENCES
 413
 414    [ipp-iig]  Hastings, T. and C. Manros, "Internet Printing
 415               Protocol/1.0:Implementer's Guide", Work in Progress.
 416
 417    [RFC2569]  Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
 418               "Mapping between LPD and IPP Protocols", RFC 2569, April
 419               1999.
 420
 421    [RFC2566]  deBry, R., Isaacson, S., Hastings, T., Herriot, R. and P.
 422               Powell, "Internet Printing Protocol/1.0: Model and
 423               Semantics", RFC 2566, April 1999.
 424
 425    [RFC2565]  Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet
 426               Printing Protocol/1.0: Encoding and Transport", RFC 2565,
 427               April 1999.
 428
 429    [RFC2567]  Wright, D., "Design Goals for an Internet Printing
 430               Protocol", RFC 2567, April 1999.
 431
 432    [ISO10175] ISO/IEC 10175 "Document Printing Application (DPA)", June
 433               1996.
 434
 435    [RFC1759]  Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
 436               Gyllenskog, "Printer MIB", RFC 1759, March 1995.
 437
 438    [RFC1905]  Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
 439               "Protocol Operations for Version 2 of the Simple Network
 440               Management Protocol (SNMPv2)", RFC 1905, January 1996.
 441
 442    [RFC1906]  Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
 443               "Transport Mappings for  Version 2 of the Simple Network
 444               Management Protocol (SNMPv2)", RFC 1906, January 1996.
 445
 446
 447
 448
 449
 450 Zilles                        Experimental                      [Page 8]
 451 \f
 452 RFC 2568                   Rationale for IPP                  April 1999
 453
 454
 455    [SSL]      Netscape, The SSL Protocol, Version 3, (Text version
 456               3.02), November 1996.
 457
 458 8. AUTHOR'S ADDRESS
 459
 460    Stephen Zilles
 461    Adobe Systems Incorporated
 462    345 Park Avenue
 463    MailStop W14
 464    San Jose, CA 95110-2704
 465
 466    Phone: +1 408 536-4766
 467    Fax:   +1 408 537-4042
 468    EMail: szilles@adobe.com
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506 Zilles                        Experimental                      [Page 9]
 507 \f
 508 RFC 2568                   Rationale for IPP                  April 1999
 509
 510
 511 9.  Full Copyright Statement
 512
 513    Copyright (C) The Internet Society (1999).  All Rights Reserved.
 514
 515    This document and translations of it may be copied and furnished to
 516    others, and derivative works that comment on or otherwise explain it
 517    or assist in its implementation may be prepared, copied, published
 518    and distributed, in whole or in part, without restriction of any
 519    kind, provided that the above copyright notice and this paragraph are
 520    included on all such copies and derivative works.  However, this
 521    document itself may not be modified in any way, such as by removing
 522    the copyright notice or references to the Internet Society or other
 523    Internet organizations, except as needed for the purpose of
 524    developing Internet standards in which case the procedures for
 525    copyrights defined in the Internet Standards process must be
 526    followed, or as required to translate it into languages other than
 527    English.
 528
 529    The limited permissions granted above are perpetual and will not be
 530    revoked by the Internet Society or its successors or assigns.
 531
 532    This document and the information contained herein is provided on an
 533    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 534    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 535    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 536    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 537    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Zilles                        Experimental                     [Page 10]
 563 \f