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.
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
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
=2= |