RFC 2568

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

📅 published April 1999, from ietf

RFC 2568 🎀 Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol

Part 1 of 2 💖

  • Network Working Group 🧚 Request for Comments: 2568
  • Author: S. Zilles, Adobe Systems Inc. ✨
  • Category: Experimental 🔬
  • Date: April 1999 📅
  • Obsoletes / Updates: this header doesn't list any RFCs being obsoleted or updated 🦋

Status of This Memo 💅

okay bestie, first things first 🫶 this memo defines an Experimental Protocol for the Internet community. it does not specify an Internet standard of any kind, so it's not one 🙈 they're literally asking for discussion and suggestions for improvement, so share your thoughts! 💜 distribution of this memo is unlimited 🌈

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

IESG Note 📝

so the IESG (the Internet Engineering Steering Group, the adults in the room 👑) wants you to know this doc defines an Experimental protocol for the Internet community 💅 they expect a revised version to get published as a Proposed Standard protocol later, and that version is expected to change from what's in this memo 😭 specifically, the standards-track version is expected to bring in strong authentication and privacy features, plus an ipp: URL type that supports those security measures 🔐 other changes are possible too, so chill 🍓

implementers, listen up 🚨 future versions of this protocol may not interoperate with the version of IPP defined here. and if they do interoperate, some protocol features might not be available. literally be careful 💀

the IESG also encourages experimenting with this protocol, especially together with Transport Layer Security (TLS) [RFC2246]. the goal is to figure out how TLS can effectively work as a security layer for IPP ✨ so go test it, bestie 🧪

ABSTRACT ✨

this document is one of a whole set of documents that together describe all aspects of the new Internet Printing Protocol (IPP) 🖨️ IPP is an application level protocol you can use for distributed printing with Internet tools and technologies. this doc gives a high level view of IPP, maps out a roadmap for the various documents in the suite, and explains the background and rationale behind the IETF working group's major decisions 🧠

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 doc takes a broad look at distributed printing and lists real-life scenarios that help clarify which features a printing protocol for the Internet needs 🌍 it identifies requirements for three types of users: end users, operators, and administrators 👀 that doc calls out a subset of the end user requirements that IPP/1.0 satisfies. operator and administrator requirements are out of scope for version 1.0, so don't stress 🫠

the Model and Semantics doc describes a simplified model made of abstract objects, their attributes, and their operations. it's independent of encoding and transport, which is so smart 🧩 the model has a Printer and a Job object, and the Job optionally supports multiple documents 📄 this doc also covers security, internationalization, and directory issues 🌐

the Encoding and Transport doc is a formal mapping of the abstract operations and attributes from the model onto HTTP/1.1 🔗 it defines the encoding rules for a brand new Internet media type called application/ipp 🎀

the Implementer's Guide gives insight and advice to implementers of IPP clients and IPP objects 🛠️ it's meant to help them understand IPP/1.0 and some of the things that can help them design their client and/or IPP object implementations. for example, it gives a typical order of processing requests, including error checking. it also includes motivation for some of the specification decisions 💡

the Mapping between LPD and IPP Protocols doc gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations 🦖

1. ARCHITECTURAL OVERVIEW 🏗️

IPP is an application level protocol for distributed printing on the Internet 🌐 this protocol defines interactions between a client and a server. it lets a client ask about a printer's capabilities, submit print jobs, and 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. so the Printer could be a real printing device, like a computer printer or fax output device, or it could be a service that interfaces with output devices. it's giving abstraction, but make it make sense 🧃

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

the IPP architecture defines an abstract Model for the data that controls the printing process and provides information about that process and the Printer's capabilities 📊 (that's in the Model and Semantics doc [RFC2566]). this abstract Model is hierarchical and reflects the structure of the Printer and the Jobs that the Printer may be processing 🪆

the Internet gives you a channel between the client and the server/Printer. but using that channel means flattening and sequencing the hierarchical Model data, so IPP also defines an encoding of the model data for transfer between client and server 📦 (that's in the Encoding and Transport doc [RFC2565]). this transfer can be either a request or the response to a request 💌

finally, IPP defines a protocol for transferring the encoded request and response data between the client and the server/Printer 🚚 (also in [RFC2565]) bestie, that's the whole pipeline 🫶

here's a typical interaction. the client makes a request to create a print job. the client assembles the Model data for that job, like the job's name, the media to use, the number of pages to place on each media instance, and so on. then the data gets encoded according to the Protocol and transmitted according to the Protocol 📤 the server/Printer receives the encoded Model data and decodes it into a form it understands. based on that data, it does one of two things: (1) accepts the job or (2) rejects the job 🎉🙅‍♀️ either way, 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 back as the response to the request using the Protocol 🔁

there's another piece of the IPP architecture: the Directory Schema, described in the model doc 📂 a Directory Schema gives a standard set of attributes that might be used to query a directory service for the URI of a Printer likely to meet the client's needs 🔍 the IPP architecture also addresses security issues, like controlling access to server/Printers and securing transmissions of requests, responses, and the data to be printed 🔐

2. THE PRINTER 🖨️

the (abstract) server/Printer covers a wide range of implementations, so it's necessary to make some assumptions about a minimal implementation 🤏 the most likely minimal version is one embedded in an output device running a specialized real time operating system, with limited processing, memory, and storage 🧸 this printer will be connected to the Internet and will have at least a TCP/IP capability, plus (likely) SNMP [RFC1905, RFC1906] support for the Internet connection 📡 on top of that, it's likely the Printer will be an HTML/HTTP server, so users can directly access information about the printer 💻✨

4.1 The Encoding 🎀

okay so, to make life easier for people building tiny embedded printers, the spec picked a super simple binary encoding 🤖💖. It's totally enough to represent everything in the Model. The structure is just sequences of attributes. Each attribute has a name (prefixed by its name length) and a value. Names are strings limited to a subset of ASCII, and values are either a single scalar or a sequence of scalars. Every scalar has a length spec and a value tag that says what type it is 🧠. The type has two parts: a major class (like integer or string) and a minor class that tells you how that major class is being used, like a dateTime string. Tagging the values with type info means new value types can be added later on without breaking everything 🦋✨.

A fully encoded request or response has a version number, plus an operation (for a request) or a status and optionally a status message (for a response). It also carries the associated parameters and attributes, which are encoded Model data. And for a request, there can optionally be print data sitting after the Model data 📄🌸.

4.2 The Transmission Mechanism 🚚

The transmission mechanism of choice for moving that encoded Model data is an HTTP 1.1 Post (plus its response) 💌. Nothing about HTTP 1.1 gets modified or required, bestie, zero changes needed 🙌. The transmission mechanism's whole job is just to shuttle encoded Model data from the client to the server and back. Honestly, any data delivery mechanism could do this 🤷‍♀️. Here are the big reasons HTTP 1.1 Post made the cut. The first one is the MVP, and maybe it's the only one that's truly special, since the rest could probably be covered by other mechanisms too. And no, this list doesn't claim to be the only possible way to pick a mechanism 💅.

  1. HTTP 1.0 is already widely deployed, and based on recent evidence, HTTP 1.1 is getting widely deployed as manufacturers ship new products 📈. The performance wins of HTTP 1.1 have been shown, and manufacturers are reacting super positively 🔥.

Wide deployment means a lot of the problems you hit when making a protocol work across local nets, intranets, and the Internet have already been solved, and they'll stay solved with HTTP 1.1 out in the wild 🌍💜.

  1. HTTP 1.1 covers most of the stuff that would have needed a brand-new protocol 🙌. Persistent connections make multi-message protocols way more efficient. For example, it's practical to have separate Create-Job and Send-Document messages. Chunking lets you send big print files without pre-scanning them to figure out the file length 📦. The accept headers let the client send its protocol and localization preferences along with the IPP operations and data 🌐. And if the Model were to support redirecting Job requests (like Cancel-Job) when a Job moves, the HTTP redirect response can tell a client when a Job they care about gets moved to another server or Printer, for any reason 🦋📬.
  2. Most network Printers will be running HTTP servers for reasons unrelated to IPP 🖨️. These network-attached Printers want to share info on how to use them, their current state, HELP info, and so on, all in HTML 💻. That means they need an HTTP server anyway, and that same server could handle IPP functions too 🎀.
  3. Most of HTTP 1.1's complexity is about implementing HTTP proxies, not about HTTP clients and servers 🧩. Work in the HTTP Working Group is helping pin down what a server has to do. As the Encoding and Transport document shows, that's not very much at all 💅✨.
  4. HTTP implementations already support handling URLs, which is stuff you'd have to provide if you defined a new protocol from scratch 🔗.
  5. An HTTP-based solution fits well with the Internet security mechanisms that are deployed now or being deployed 🔐. HTTP will run over SSL3. The digest access authentication mechanism of HTTP 1.1 gives an adequate level of access control 🛡️. These solutions are already deployed and in real use. A new solution would need extensive use before anyone could have the same confidence in its security 🥹. Note: SSL3 is not on the IETF standards track.
  6. HTTP already has an extensibility model that a new protocol would have to build from zero 🧱. In particular, the headers, intent-types (via Internet Media Types), and error codes are widely accepted and come with a useful set of definitions and methods for extension 🌈.
  7. This isn't strictly a reason why IPP should use HTTP as its transmission protocol, but it's super helpful that there are tons of prototyping tools that work with HTTP, and that CGI scripts can be used to test and debug parts of the protocol 🧪🍓.
  8. Finally, the POST method was picked to carry the print data because its use for data transmission is already 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 harder to deploy 🙈. Assigning a new default port for IPP gave the necessary identification with minimal impact on installed infrastructure, so that's what got chosen instead 🧚✨.

5. RATIONALE FOR THE DIRECTORY SCHEMA 📇

Successful use of IPP depends on the client finding a suitable IPP enabled Printer to send IPP requests to, like when it wants to print a job 🖨️💨. This gets way easier if there's a Directory Service that can be queried for a suitable Printer 🔍. The whole point of the Directory Schema is to have a standard description of Printer attributes that can be associated with the URI for the printer 🏷️. These attributes are a subset of the Model attributes, and they can be encoded in whatever query syntax the client's Directory Service uses 💜.

6. SECURITY CONSIDERATIONS - RATIONALE FOR SECURITY 🔐

⚠️ Security is an area of active work on the Internet, and complete solutions to a wide range of security concerns are not yet available. Like, not even close yet, bestie 😭.

So in designing IPP, the focus was on finding a set of security protocols and features that are already implemented (or could be implemented right now) and that actually solve real problems with distributed printing 🎯. Two areas seemed worth supporting: (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 the 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.
  • [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

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

Okay, the legal bit, and it matters 📜. You're allowed to copy and hand out this document and translations of it 💖. You can also write derivative works that comment on or explain it, or that help with implementing it, and prepare, copy, publish, and distribute those, in whole or in part, with no restrictions of any kind 🌷. The one condition is that the copyright notice and this paragraph have to be included on all such copies and derivative works 🎀.

This document itself can't be modified in any way. That includes removing the copyright notice or the references to the Internet Society or other Internet organizations 🚫. There are two exceptions. The first is when it's needed for developing Internet standards, and then the copyright procedures defined in the Internet Standards process must be followed. The second is when it's needed to translate it into languages other than English 🌍.

The limited permissions above are perpetual, and the Internet Society or its successors or assigns won't revoke them 🦋♾️.

This document and the information in it are 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 💀.

📦 where this page comes from