Network Working Group R. Herriot, Ed. Request for Comments: 2565 Xerox Corporation Category: Experimental S. Butler Hewlett-Packard P. Moore Microsoft R. Turner Sharp Labs April 1999 Internet Printing Protocol/1.0: Encoding and Transport 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) [RFC 2246], to help determine how TLS may effectively be used as a security layer for IPP. Herriot, et al. Experimental [Page 1] RFC 2565 IPP/1.0: Encoding and Transport April 1999 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 defines the rules for encoding IPP operations and IPP attributes into a new Internet mime media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp". 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 [RFC2568] Internet Printing Protocol/1.0: Model and Semantics [RFC2566] Internet Printing Protocol/1.0: Encoding and Transport (this document) Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig] Mapping between LPD and IPP Protocols [RFC2569] The document, "Design Goals for an Internet Printing Protocol", 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. It 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 document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", 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 document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations that are independent of encoding and transport. It introduces a Printer and a Job object. The Job object optionally supports multiple documents per Job. It also addresses security, internationalization, and directory issues. This document "Internet Printing Protocol/1.0: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects. Herriot, et al. Experimental [Page 2] RFC 2565 IPP/1.0: Encoding and Transport April 1999 The document "Mapping between LPD and IPP Protocols" gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations. Table of Contents 1. Introduction.....................................................4 2. Conformance Terminology..........................................4 3. Encoding of the Operation Layer.................................4 3.1 Picture of the Encoding.....................................5 3.2 Syntax of Encoding..........................................7 3.3 Version-number..............................................9 3.4 Operation-id................................................9 3.5 Status-code.................................................9 3.6 Request-id..................................................9 3.7 Tags.......................................................10 3.7.1 Delimiter Tags.........................................10 3.7.2 Value Tags.............................................11 3.8 Name-Length................................................13 3.9 (Attribute) Name...........................................13 3.10 Value Length...............................................16 3.11 (Attribute) Value..........................................16 3.12 Data.......................................................18 4. Encoding of Transport Layer.....................................18 5. Security Considerations.........................................19 5.1 Using IPP with SSL3........................................19 6. References......................................................20 7. Authors' Addresses..............................................22 8. Other Participants:.............................................24 9. Appendix A: Protocol Examples...................................25 9.1 Print-Job Request..........................................25 9.2 Print-Job Response (successful)............................26 9.3 Print-Job Response (failure)...............................27 9.4 Print-Job Response (success with attributes ignored).......28 9.5 Print-URI Request..........................................30 9.6 Create-Job Request.........................................31 9.7 Get-Jobs Request...........................................31 9.8 Get-Jobs Response..........................................32 10. Appendix C: Registration of MIME Media Type Information for "application/ipp"..............................................35 11. Full Copyright Statement.......................................37 Herriot, et al. Experimental [Page 3] RFC 2565 IPP/1.0: Encoding and Transport April 1999 1. Introduction This document contains the rules for encoding IPP operations and describes two layers: the transport layer and the operation layer. The transport layer consists of an HTTP/1.1 request or response. RFC 2068 [RFC2068] describes HTTP/1.1. This document specifies the HTTP headers that an IPP implementation supports. The operation layer consists of a message body in an HTTP request or response. The document "Internet Printing Protocol/1.0: Model and Semantics" [RFC2566] defines the semantics of such a message body and the supported values. This document specifies the encoding of an IPP operation. The aforementioned document [RFC2566] is henceforth referred to as the "IPP model document" 2. Conformance Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Encoding of the Operation Layer The operation layer MUST contain a single operation request or operation response. Each request or response consists of a sequence of values and attribute groups. Attribute groups consist of a sequence of attributes each of which is a name and value. Names and values are ultimately sequences of octets The encoding consists of octets as the most primitive type. There are several types built from octets, but three important types are integers, character strings and octet strings, on which most other data types are built. Every character string in this encoding MUST be a sequence of characters where the characters are associated with some charset and some natural language. A character string MUST be in "reading order" with the first character in the value (according to reading order) being the first character in the encoding. A character string whose associated charset is US-ASCII whose associated natural language is US English is henceforth called a US-ASCII-STRING. A character string whose associated charset and natural language are specified in a request or response as described in the model document is henceforth called a LOCALIZED-STRING. An octet string MUST be in "IPP model document order" with the first octet in the value (according to the IPP model document order) being the first octet in the encoding Every integer in this encoding MUST be encoded as a signed integer using two's-complement binary encoding with big-endian format (also known as "network order" and "most significant byte Herriot, et al. Experimental [Page 4] RFC 2565 IPP/1.0: Encoding and Transport April 1999 first"). The number of octets for an integer MUST be 1, 2 or 4, depending on usage in the protocol. Such one-octet integers, henceforth called SIGNED-BYTE, are used for the version-number and tag fields. Such two-byte integers, henceforth called SIGNED-SHORT are used for the operation-id, status-code and length fields. Four byte integers, henceforth called SIGNED-INTEGER, are used for values fields and the sequence number. The following two sections present the operation layer in two ways - informally through pictures and description - formally through Augmented Backus-Naur Form (ABNF), as specified by RFC 2234 [RFC2234] 3.1 Picture of the Encoding The encoding for an operation request or response consists of: ----------------------------------------------- | version-number | 2 bytes - required ----------------------------------------------- | operation-id (request) | | or | 2 bytes - required | status-code (response) | ----------------------------------------------- | request-id | 4 bytes - required ----------------------------------------------------------- | xxx-attributes-tag | 1 byte | ----------------------------------------------- |-0 or more | xxx-attribute-sequence | n bytes | ----------------------------------------------------------- | end-of-attributes-tag | 1 byte - required ----------------------------------------------- | data | q bytes - optional ----------------------------------------------- The xxx-attributes-tag and xxx-attribute-sequence represents four different values of "xxx", namely, operation, job, printer and unsupported. The xxx-attributes-tag and an xxx-attribute-sequence represent attribute groups in the model document. The xxx- attributes-tag identifies the attribute group and the xxx-attribute- sequence contains the attributes. The expected sequence of xxx-attributes-tag and xxx-attribute- sequence is specified in the IPP model document for each operation request and operation response. Herriot, et al. Experimental [Page 5] RFC 2565 IPP/1.0: Encoding and Transport April 1999 A request or response SHOULD contain each xxx-attributes-tag defined for that request or response even if there are no attributes except for the unsupported-attributes-tag which SHOULD be present only if the unsupported-attribute-sequence is non-empty. A receiver of a request MUST be able to process as equivalent empty attribute groups: a) an xxx-attributes-tag with an empty xxx-attribute-sequence, b) an expected but missing xxx-attributes-tag. The data is omitted from some operations, but the end-of-attributes- tag is present even when the data is omitted. Note, the xxx- attributes-tags and end-of-attributes-tag are called 'delimiter- tags'. Note: the xxx-attribute-sequence, shown above may consist of 0 bytes, according to the rule below. An xxx-attributes-sequence consists of zero or more compound- attributes. ----------------------------------------------- | compound-attribute | s bytes - 0 or more ----------------------------------------------- A compound-attribute consists of an attribute with a single value followed by zero or more additional values. Note: a 'compound-attribute' represents a single attribute in the model document. The 'additional value' syntax is for attributes with 2 or more values. Each attribute consists of: ----------------------------------------------- | value-tag | 1 byte ----------------------------------------------- | name-length (value is u) | 2 bytes ----------------------------------------------- | name | u bytes ----------------------------------------------- | value-length (value is v) | 2 bytes ----------------------------------------------- | value | v bytes ----------------------------------------------- Herriot, et al. Experimental [Page 6] RFC 2565 IPP/1.0: Encoding and Transport April 1999 An additional value consists of: ----------------------------------------------------------- | value-tag | 1 byte | ----------------------------------------------- | | name-length (value is 0x0000) | 2 bytes | ----------------------------------------------- |-0 or more | value-length (value is w) | 2 bytes | ----------------------------------------------- | | value | w bytes | ----------------------------------------------------------- Note: an additional value is like an attribute whose name-length is 0. From the standpoint of a parsing loop, the encoding consists of: ----------------------------------------------- | version-number | 2 bytes - required ----------------------------------------------- | operation-id (request) | | or | 2 bytes - required | status-code (response) | ----------------------------------------------- | request-id | 4 bytes - required -----------------------------------------------