draft-ietf-ipp-protocol-v11-01.txt   draft-ietf-ipp-protocol-v11-02.txt 
INTERNET-DRAFT Robert Herriot (editor) INTERNET-DRAFT Robert Herriot (editor)
Xerox Corporation <draft-ietf-ipp-protocol-v11-02.txt> Xerox Corporation
<draft-ietf-ipp-protocol-v11-01.txt> Sylvan Butler Sylvan Butler
Hewlett-Packard Hewlett-Packard
Paul Moore Paul Moore
Microsoft Microsoft
Randy Turner Randy Turner
2wire.com 2wire.com
John Wenn John Wenn
Xerox Corporation Xerox Corporation
May 10, 1999 June 11, 1999
Internet Printing Protocol/1.1: Encoding and Transport Internet Printing Protocol/1.1: Encoding and Transport
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC2026]. Internet-Drafts are working provisions of Section 10 of [RFC2026]. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
tools and technologies. This document defines the rules for encoding IPP tools and technologies. This document defines the rules for encoding IPP
operations and IPP attributes into a new Internet mime media type called operations and IPP attributes into a new Internet mime media type called
"application/ipp". This document also defines the rules for "application/ipp". This document also defines the rules for
transporting over HTTP a message body whose Content-Type is transporting over HTTP a message body whose Content-Type is
"application/ipp". This document defines a new scheme named 'ipp' for "application/ipp". This document defines a new scheme named 'ipp' for
identifying IPP printers and jobs. Finally, this document defines rules identifying IPP printers and jobs. Finally, this document defines rules
for supporting IPP/1.0 Clients and Printers. for supporting IPP/1.0 Clients and Printers.
The full set of IPP documents includes: The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [rfc2567] Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [rfc2568] Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics [ipp-mod] Internet Printing Protocol/1.1: Model and Semantics [ipp-mod]
Internet Printing Protocol/1.1: Encoding and Transport (this Internet Printing Protocol/1.1: Encoding and Transport (this
document) document)
Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
Mapping between LPD and IPP Protocols [rfc2069] Mapping between LPD and IPP Protocols [RFC2069]
The document, "Design Goals for an Internet Printing Protocol", takes a The document, "Design Goals for an Internet Printing Protocol", takes a
broad look at distributed printing functionality, and it enumerates broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet. It identifies included in a printing protocol for the Internet. It identifies
requirements for three types of users: end users, operators, and requirements for three types of users: end users, operators, and
administrators. It calls out a subset of end user requirements that are administrators. It calls out a subset of end user requirements that are
satisfied in IPP/1.1. Operator and administrator requirements are out of satisfied in IPP/1.1. A few OPTIONAL operator operations have been added
scope for version 1.1. to IPP/1.1.
The document, "Rationale for the Structure and Model and Protocol for The document, "Rationale for the Structure and Model and Protocol for
the Internet Printing Protocol", describes IPP from a high level view, the Internet Printing Protocol", describes IPP from a high level view,
defines a roadmap for the various documents that form the suite of IPP defines a roadmap for the various documents that form the suite of IPP
specifications, and gives background and rationale for the IETF working specification documents, and gives background and rationale for the IETF
group's major decisions. working group's major decisions.
The document, "Internet Printing Protocol/1.1: Model and Semantics", The document, "Internet Printing Protocol/1.1: Model and Semantics",
describes a simplified model with abstract objects, their attributes, describes a simplified model with abstract objects, their attributes,
and their operations that are independent of encoding and transport. It and their operations that are independent of encoding and transport. It
introduces a Printer and a Job object. The Job object optionally introduces a Printer and a Job object. The Job object optionally
supports multiple documents per Job. It also addresses security, supports multiple documents per Job. It also addresses security,
internationalization, and directory issues. internationalization, and directory issues.
The document "Internet Printing Protocol/1.1: Implementer's Guide", The document "Internet Printing Protocol/1.1: Implementer's Guide",
gives advice to implementers of IPP clients and IPP objects. gives advice to implementers of IPP clients and IPP objects.
The document "Mapping between LPD and IPP Protocols" gives some advice The document "Mapping between LPD and IPP Protocols" gives some advice
to implementers of gateways between IPP and LPD (Line Printer Daemon) to implementers of gateways between IPP and LPD (Line Printer Daemon)
implementations. implementations.
Table of Contents Table of Contents
1. Introduction........................................................3 1. Introduction........................................................4
2. Conformance Terminology.............................................4 2. Conformance Terminology.............................................4
3. Encoding of the Operation Layer....................................4 3. Encoding of the Operation Layer....................................4
3.1 Picture of the Encoding.......................................5 3.1 Picture of the Encoding........................................5
3.2 Syntax of Encoding............................................7 3.2 Syntax of Encoding.............................................7
3.3 Version-number................................................8 3.3 Version-number.................................................8
3.4 Operation-id..................................................8 3.4 Operation-id...................................................8
3.5 Status-code...................................................9 3.5 Status-code....................................................9
3.6 Request-id....................................................9 3.6 Request-id.....................................................9
3.7 Tags..........................................................9 3.7 Tags...........................................................9
3.7.1 Delimiter Tags...........................................9 3.7.1 Delimiter Tags...........................................9
3.7.2 Value Tags..............................................10 3.7.2 Value Tags..............................................11
3.8 Name-Length..................................................12 3.8 Name-Length...................................................12
3.9 (Attribute) Name.............................................12 3.9 (Attribute) Name..............................................12
3.10 Value Length.................................................14 3.10Value Length..................................................14
3.11 (Attribute) Value............................................14 3.11(Attribute) Value.............................................15
3.12 Data.........................................................16 3.12Data..........................................................17
4. Encoding of Transport Layer........................................16 4. Encoding of Transport Layer........................................17
5. IPP URL Scheme.....................................................17 5. IPP URL Scheme.....................................................18
6. Compatibility with IPP/1.0 Implementations.........................18 6. Security Considerations............................................19
7. Security Considerations............................................20 6.1 Security Conformance Requirements.............................20
7.1 Security Conformance.........................................20 6.1.1 Digest Authentication...................................20
7.2 Using IPP with TLS...........................................20 6.1.2 Transport Layer Security (TLS)..........................20
8. References.........................................................21 6.2 Using IPP with TLS............................................21
9. Author's Address...................................................23 7. Interoperability with IPP/1.0 Implementations......................22
10.Other Participants:...............................................24 7.1 The "version-number" Parameter................................22
11.Appendix A: Protocol Examples.....................................24 7.2 Security and URL Schemes......................................22
11.1 Print-Job Request............................................24 8. References.........................................................23
11.2 Print-Job Response (successful)..............................26 9. Author's Address...................................................25
11.3 Print-Job Response (failure).................................26 10.Other Participants:...............................................25
11.4 Print-Job Response (success with attributes ignored).........27 11.Appendix A: Protocol Examples.....................................26
11.5 Print-URI Request............................................29 11.1Print-Job Request.............................................26
11.6 Create-Job Request...........................................30 11.2Print-Job Response (successful)...............................27
11.7 Get-Jobs Request.............................................30 11.3Print-Job Response (failure)..................................28
11.8 Get-Jobs Response............................................31 11.4Print-Job Response (success with attributes ignored)..........29
11.5Print-URI Request.............................................32
11.6Create-Job Request............................................33
11.7Get-Jobs Request..............................................34
11.8Get-Jobs Response.............................................35
12.Appendix C: Registration of MIME Media Type Information for 12.Appendix C: Registration of MIME Media Type Information for
"application/ipp".....................................................32 "application/ipp".....................................................37
13.Appendix D: Changes from IPP /1.0.................................34 13.Appendix D: Changes from IPP /1.0.................................38
14.Full Copyright Statement..........................................34 14.Full Copyright Statement..........................................39
1. Introduction 1. Introduction
This document contains the rules for encoding IPP operations and This document contains the rules for encoding IPP operations and
describes two layers: the transport layer and the operation layer. describes two layers: the transport layer and the operation layer.
The transport layer consists of an HTTP/1.1 request or response. RFC The transport layer consists of an HTTP/1.1 request or response. RFC
2068 [rfc2068] describes HTTP/1.1. This document specifies the HTTP 2068 [RFC2068] describes HTTP/1.1. This document specifies the HTTP
headers that an IPP implementation supports. headers that an IPP implementation supports.
The operation layer consists of a message body in an HTTP request or The operation layer consists of a message body in an HTTP request or
response. The document "Internet Printing Protocol/1.1: Model and response. The document "Internet Printing Protocol/1.1: Model and
Semantics" [ipp-mod] defines the semantics of such a message body and Semantics" [ipp-mod] defines the semantics of such a message body and
the supported values. This document specifies the encoding of an IPP the supported values. This document specifies the encoding of an IPP
operation. The aforementioned document [ipp-mod] is henceforth referred operation. The aforementioned document [ipp-mod] is henceforth referred
to as the "IPP model document" to as the "IPP model document"
2. Conformance Terminology 2. Conformance Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119 [rfc2119]. interpreted as described in RFC 2119 [RFC2119].
3. Encoding of the Operation Layer 3. Encoding of the Operation Layer
The operation layer MUST contain a single operation request or operation The operation layer MUST contain a single operation request or operation
response. Each request or response consists of a sequence of values and response. Each request or response consists of a sequence of values and
attribute groups. Attribute groups consist of a sequence of attributes attribute groups. Attribute groups consist of a sequence of attributes
each of which is a name and value. Names and values are ultimately each of which is a name and value. Names and values are ultimately
sequences of octets sequences of octets
The encoding consists of octets as the most primitive type. There are The encoding consists of octets as the most primitive type. There are
skipping to change at page 4, line 53 skipping to change at page 5, line 15
version-number and tag fields. Such two-byte integers, henceforth called version-number and tag fields. Such two-byte integers, henceforth called
SIGNED-SHORT are used for the operation-id, status-code and length SIGNED-SHORT are used for the operation-id, status-code and length
fields. Four byte integers, henceforth called SIGNED-INTEGER, are used fields. Four byte integers, henceforth called SIGNED-INTEGER, are used
for values fields and the sequence number. for values fields and the sequence number.
The following two sections present the operation layer in two ways The following two sections present the operation layer in two ways
- informally through pictures and description - informally through pictures and description
- formally through Augmented Backus-Naur Form (ABNF), as specified by - formally through Augmented Backus-Naur Form (ABNF), as specified by
RFC 2234 [rfc2234] RFC 2234 [RFC2234]
3.1 Picture of the Encoding 3.1 Picture of the Encoding
The encoding for an operation request or response consists of: The encoding for an operation request or response consists of:
----------------------------------------------- -----------------------------------------------
| version-number | 2 bytes - required | version-number | 2 bytes - required
----------------------------------------------- -----------------------------------------------
| operation-id (request) | | operation-id (request) |
| or | 2 bytes - required | or | 2 bytes - required
skipping to change at page 7, line 34 skipping to change at page 7, line 34
- attributes - attributes
- data - data
- the remainder of a single attribute where the tag specifies the - the remainder of a single attribute where the tag specifies the
type of the value. type of the value.
3.2 Syntax of Encoding 3.2 Syntax of Encoding
The syntax below is ABNF [rfc2234] except 'strings of literals' MUST be The syntax below is ABNF [RFC2234] except 'strings of literals' MUST be
case sensitive. For example 'a' means lower case 'a' and not upper case case sensitive. For example 'a' means lower case 'a' and not upper case
'A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields are represented 'A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields are represented
as '%x' values which show their range of values. as '%x' values which show their range of values.
ipp-message = ipp-request / ipp-response ipp-message = ipp-request / ipp-response
ipp-request = version-number operation-id request-id ipp-request = version-number operation-id request-id
*(xxx-attributes-tag xxx-attribute-sequence) end-of- *(xxx-attributes-tag xxx-attribute-sequence) end-of-
attributes-tag data attributes-tag data
ipp-response = version-number status-code request-id ipp-response = version-number status-code request-id
*(xxx-attributes-tag xxx-attribute-sequence) end-of- *(xxx-attributes-tag xxx-attribute-sequence) end-of-
skipping to change at page 10, line 37 skipping to change at page 10, line 49
delimiter. If the operation has a document-content group, the document delimiter. If the operation has a document-content group, the document
data in that group MUST follow the end-of-attributes-tag. data in that group MUST follow the end-of-attributes-tag.
Each of the other three xxx-attributes-tags defined above is OPTIONAL Each of the other three xxx-attributes-tags defined above is OPTIONAL
in an operation and each MUST occur at most once in an operation, except in an operation and each MUST occur at most once in an operation, except
for job-attributes-tag in a Get-Jobs response which may occur zero or for job-attributes-tag in a Get-Jobs response which may occur zero or
more times. more times.
The order and presence of delimiter tags for each operation request and The order and presence of delimiter tags for each operation request and
each operation response MUST be that defined in the model document. For each operation response MUST be that defined in the model document. For
further details, see section 3.9 "(Attribute) Name" and section 11 further details, see section 3.9 "(Attribute) Name" and section 0 "
"Appendix A: Protocol Examples".
Appendix A: Protocol Examples".
A Printer MUST treat the reserved delimiter tags differently from A Printer MUST treat the reserved delimiter tags differently from
reserved value tags so that the Printer knows that there is an entire reserved value tags so that the Printer knows that there is an entire
attribute group that it doesn't understand as opposed to a single value attribute group that it doesn't understand as opposed to a single value
that it doesn't understand. that it doesn't understand.
3.7.2 Value Tags 3.7.2 Value Tags
The remaining tables show values for the value-tag, which is the first The remaining tables show values for the value-tag, which is the first
octet of an attribute. The value-tag specifies the type of the value of octet of an attribute. The value-tag specifies the type of the value of
the attribute. The following table specifies the "out-of-band" values the attribute. The following table specifies the "out-of-band" values
for the value-tag. for the value-tag.
Tag Value (Hex) Meaning Tag Value (Hex) Meaning
0x10 unsupported 0x10 unsupported
0x11 reserved for future 'default' 0x11 reserved for future 'default'
0x12 unknown 0x12 unknown
0x13 no-value 0x13 no-value
Tag Value (Hex) Meaning
0x14-0x1F reserved for future "out-of-band" values. 0x14-0x1F reserved for future "out-of-band" values.
The "unsupported" value MUST be used in the attribute-sequence of an The "unsupported" value MUST be used in the attribute-sequence of an
error response for those attributes which the printer does not support. error response for those attributes which the printer does not support.
The "default" value is reserved for future use of setting value back to The "default" value is reserved for future use of setting value back to
their default value. The "unknown" value is used for the value of a their default value. The "unknown" value is used for the value of a
supported attribute when its value is temporarily unknown. The "no- supported attribute when its value is temporarily unknown. The "no-
value" value is used for a supported attribute to which no value has value" value is used for a supported attribute to which no value has
been assigned, e.g. "job-k-octets-supported" has no value if an been assigned, e.g. "job-k-octets-supported" has no value if an
implementation supports this attribute, but an administrator has not implementation supports this attribute, but an administrator has not
skipping to change at page 12, line 4 skipping to change at page 12, line 16
0x40 reserved 0x40 reserved
0x41 textWithoutLanguage 0x41 textWithoutLanguage
0x42 nameWithoutLanguage 0x42 nameWithoutLanguage
0x43 reserved 0x43 reserved
0x44 keyword 0x44 keyword
0x45 uri 0x45 uri
0x46 uriScheme 0x46 uriScheme
0x47 charset 0x47 charset
0x48 naturalLanguage 0x48 naturalLanguage
Tag Value (Hex) Meaning
0x49 mimeMediaType 0x49 mimeMediaType
0x4A-0x5F reserved for future character string types 0x4A-0x5F reserved for future character string types
NOTE: 0x40 is reserved for "generic character-string" if it should ever NOTE: 0x40 is reserved for "generic character-string" if it should ever
be needed. be needed.
NOTE: an attribute value always has a type, which is explicitly NOTE: an attribute value always has a type, which is explicitly
specified by its tag; one such tag value is "nameWithoutLanguage". An specified by its tag; one such tag value is "nameWithoutLanguage". An
attribute's name has an implicit type, which is keyword. attribute's name has an implicit type, which is keyword.
skipping to change at page 13, line 12 skipping to change at page 13, line 20
document MUST become the "operation-id" field in the operation document MUST become the "operation-id" field in the operation
layer request. layer request.
- "status-code": The parameter named "status-code" in the IPP model - "status-code": The parameter named "status-code" in the IPP model
document MUST become the "status-code" field in the operation layer document MUST become the "status-code" field in the operation layer
response. response.
- "request-id": The parameter named "request-id" in the IPP model - "request-id": The parameter named "request-id" in the IPP model
document MUST become the "request-id" field in the operation layer document MUST become the "request-id" field in the operation layer
request or response. request or response.
All Printer and Job objects are identified by a Uniform Resource All Printer and Job objects are identified by a Uniform Resource
Identifier (URI) [rfc2396] so that they can be persistently and Identifier (URI) [RFC2396] so that they can be persistently and
unambiguously referenced. The notion of a URI is a useful concept, unambiguously referenced. The notion of a URI is a useful concept,
however, until the notion of URI is more stable (i.e., defined more however, until the notion of URI is more stable (i.e., defined more
completely and deployed more widely), it is expected that the URIs used completely and deployed more widely), it is expected that the URIs used
for IPP objects will actually be URLs [rfc1738] [rfc1808]. Since every for IPP objects will actually be URLs [RFC1738] [RFC1808]. Since every
URL is a specialized form of a URI, even though the more generic term URL is a specialized form of a URI, even though the more generic term
URI is used throughout the rest of this document, its usage is intended URI is used throughout the rest of this document, its usage is intended
to cover the more specific notion of URL as well. to cover the more specific notion of URL as well.
Some operation elements are encoded twice, once as the request-URI on Some operation elements are encoded twice, once as the request-URI on
the HTTP Request-Line and a second time as a REQUIRED operation the HTTP Request-Line and a second time as a REQUIRED operation
attribute in the application/ipp entity. These attributes are the attribute in the application/ipp entity. These attributes are the
target URI for the operation and are called printer-uri and job-uri. target URI for the operation and are called printer-uri and job-uri.
Note: The target URI is included twice in an operation referencing the Note: The target URI is included twice in an operation referencing the
same IPP object, but the two URIs NEED NOT be literally identical. One same IPP object, but the two URIs NEED NOT be literally identical. One
skipping to change at page 14, line 4 skipping to change at page 14, line 15
4. Once the HTTP server resource begins to process the HTTP request, 4. Once the HTTP server resource begins to process the HTTP request,
it might get the reference to the appropriate IPP Printer object it might get the reference to the appropriate IPP Printer object
from either the HTTP URI (using to the context of the HTTP server from either the HTTP URI (using to the context of the HTTP server
for relative URLs) or from the URI within the operation request; for relative URLs) or from the URI within the operation request;
the choice is up to the implementation. the choice is up to the implementation.
5. HTTP URIs can be relative or absolute, but the target URI in the 5. HTTP URIs can be relative or absolute, but the target URI in the
operation MUST be an absolute URI. operation MUST be an absolute URI.
The model document arranges the remaining attributes into groups for The model document arranges the remaining attributes into groups for
each operation request and response. Each such group MUST be represented each operation request and response. Each such group MUST be represented
in the protocol by an xxx-attribute-sequence preceded by the appropriate in the protocol by an xxx-attribute-sequence preceded by the appropriate
xxx-attributes-tag (See the table below and section 11 "Appendix A: xxx-attributes-tag (See the table below and section 0 "
Protocol Examples"). In addition, the order of these xxx-attributes-tags
and xxx-attribute-sequences in the protocol MUST be the same as in the Appendix A: Protocol Examples"). In addition, the order of these xxx-
model document, but the order of attributes within each xxx-attribute- attributes-tags and xxx-attribute-sequences in the protocol MUST be the
sequence MUST be unspecified. The table below maps the model document same as in the model document, but the order of attributes within each
group name to xxx-attributes-sequence: xxx-attribute-sequence MUST be unspecified. The table below maps the
model document group name to xxx-attributes-sequence:
Model Document Group xxx-attributes-sequence Model Document Group xxx-attributes-sequence
Operation Attributes operations-attributes-sequence Operation Attributes operations-attributes-sequence
Job Template Attributes job-attributes-sequence Job Template Attributes job-attributes-sequence
Job Object Attributes job-attributes-sequence Job Object Attributes job-attributes-sequence
Unsupported Attributes unsupported- attributes-sequence Unsupported Attributes unsupported- attributes-sequence
Requested Attributes (Get- job-attributes-sequence Requested Attributes (Get-Job- job-attributes-sequence
Job-Attributes) Attributes)
Requested Attributes (Get- printer-attributes-sequence Requested Attributes (Get- printer-attributes-sequence
Printer-Attributes) Printer-Attributes)
Document Content in a special position as described above Document Content in a special position as described
above
If an operation contains attributes from more than one job object (e.g. If an operation contains attributes from more than one job object (e.g.
Get-Jobs response), the attributes from each job object MUST be in a Get-Jobs response), the attributes from each job object MUST be in a
separate job-attribute-sequence, such that the attributes from the ith separate job-attribute-sequence, such that the attributes from the ith
job object are in the ith job-attribute-sequence. See Section 11 job object are in the ith job-attribute-sequence. See Section 0 "
"Appendix A: Protocol Examples" for table showing the application of the
Appendix A: Protocol Examples" for table showing the application of the
rules above. rules above.
3.10 Value Length 3.10 Value Length
Each attribute value MUST be preceded by a SIGNED-SHORT, which MUST Each attribute value MUST be preceded by a SIGNED-SHORT, which MUST
specify the number of octets in the value which follows this length, specify the number of octets in the value which follows this length,
exclusive of the two bytes specifying the length. exclusive of the two bytes specifying the length.
For any of the types represented by binary signed integers, the sender For any of the types represented by binary signed integers, the sender
MUST encode the value in exactly four octets. MUST encode the value in exactly four octets.
skipping to change at page 15, line 49 skipping to change at page 16, line 46
keyword, uri, and keyword, uri, and
uriScheme uriScheme
boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is
'true'. 'true'.
integer and enum a SIGNED-INTEGER. integer and enum a SIGNED-INTEGER.
dateTime OCTET-STRING consisting of eleven octets whose dateTime OCTET-STRING consisting of eleven octets whose
contents are defined by "DateAndTime" in RFC contents are defined by "DateAndTime" in RFC
1903 [rfc1903]. 1903 [RFC1903].
resolution OCTET_STRING consisting of nine octets of 2 resolution OCTET_STRING consisting of nine octets of 2
SIGNED-INTEGERs followed by a SIGNED-BYTE. The SIGNED-INTEGERs followed by a SIGNED-BYTE. The
first SIGNED-INTEGER contains the value of cross first SIGNED-INTEGER contains the value of cross
feed direction resolution. The second SIGNED- feed direction resolution. The second SIGNED-
INTEGER contains the value of feed direction INTEGER contains the value of feed direction
resolution. The SIGNED-BYTE contains the units resolution. The SIGNED-BYTE contains the units
value. value.
Syntax of Attribute Encoding
Value
rangeOfInteger Eight octets consisting of 2 SIGNED-INTEGERs. rangeOfInteger Eight octets consisting of 2 SIGNED-INTEGERs.
The first SIGNED-INTEGER contains the lower The first SIGNED-INTEGER contains the lower
bound and the second SIGNED-INTEGER contains the bound and the second SIGNED-INTEGER contains the
Syntax of Attribute Encoding
Value
upper bound. upper bound.
1setOf X Encoding according to the rules for an attribute 1setOf X Encoding according to the rules for an attribute
with more than 1 value. Each value X is encoded with more than 1 value. Each value X is encoded
according to the rules for encoding its type. according to the rules for encoding its type.
octetString OCTET-STRING octetString OCTET-STRING
The type of the value in the model document determines the encoding in The type of the value in the model document determines the encoding in
the value and the value of the value-tag. the value and the value of the value-tag.
3.12 Data 3.12 Data
The data part MUST include any data required by the operation The data part MUST include any data required by the operation
4. Encoding of Transport Layer 4. Encoding of Transport Layer
HTTP/1.1 [rfc2068] is the transport layer for this protocol. HTTP/1.1 [RFC2068] is the transport layer for this protocol.
The operation layer has been designed with the assumption that the The operation layer has been designed with the assumption that the
transport layer contains the following information: transport layer contains the following information:
- the URI of the target job or printer operation - the URI of the target job or printer operation
- the total length of the data in the operation layer, either as a - the total length of the data in the operation layer, either as a
single length or as a sequence of chunks each with a length. single length or as a sequence of chunks each with a length.
It is REQUIRED that a printer implementation support HTTP over the IANA It is REQUIRED that a printer implementation support HTTP over the IANA
assigned Well Known Port 631 (the IPP default port), though a printer assigned Well Known Port 631 (the IPP default port), though a printer
implementation may support HTTP over some other port as well. implementation may support HTTP over some other port as well.
Each HTTP operation MUST use the POST method where the request-URI is Each HTTP operation MUST use the POST method where the request-URI is
the object target of the operation, and where the "Content-Type" of the the object target of the operation, and where the "Content-Type" of the
message-body in each request and response MUST be "application/ipp". The message-body in each request and response MUST be "application/ipp". The
message-body MUST contain the operation layer and MUST have the syntax message-body MUST contain the operation layer and MUST have the syntax
described in section 3.2 "Syntax of Encoding". A client implementation described in section 3.2 "Syntax of Encoding". A client implementation
MUST adhere to the rules for a client described for HTTP1.1 [rfc2068] . MUST adhere to the rules for a client described for HTTP1.1 [RFC2068] .
A printer (server) implementation MUST adhere the rules for an origin A printer (server) implementation MUST adhere the rules for an origin
server described for HTTP1.1 [rfc2068]. server described for HTTP1.1 [RFC2068].
An IPP server sends a response for each request that it receives. If an An IPP server sends a response for each request that it receives. If an
IPP server detects an error, it MAY send a response before it has read IPP server detects an error, it MAY send a response before it has read
the entire request. If the HTTP layer of the IPP server completes the entire request. If the HTTP layer of the IPP server completes
processing the HTTP headers successfully, it MAY send an intermediate processing the HTTP headers successfully, it MAY send an intermediate
response, such as "100 Continue", with no IPP data before sending the response, such as "100 Continue", with no IPP data before sending the
IPP response. A client MUST expect such a variety of responses from an IPP response. A client MUST expect such a variety of responses from an
IPP server. For further information on HTTP/1.1, consult the HTTP IPP server. For further information on HTTP/1.1, consult the HTTP
documents [rfc2068]. documents [RFC2068].
An HTTP server MUST support chunking for IPP requests, and an IPP client An HTTP server MUST support chunking for IPP requests, and an IPP client
MUST support chunking for IPP responses according to HTTP/1.1[rfc2068]. MUST support chunking for IPP responses according to HTTP/1.1[RFC2068].
Note: this rule causes a conflict with non-compliant implementations of Note: this rule causes a conflict with non-compliant implementations of
HTTP/1.1 that don't support chunking for POST methods, and this rule may HTTP/1.1 that don't support chunking for POST methods, and this rule may
cause a conflict with non-compliant implementations of HTTP/1.1 that cause a conflict with non-compliant implementations of HTTP/1.1 that
don't support chunking for CGI scripts don't support chunking for CGI scripts
5. IPP URL Scheme 5. IPP URL Scheme
The IPP/1.1 specification defines a new scheme 'ipp' as the value of a The IPP/1.1 document defines a new scheme 'ipp' as the value of a URL
URL that identifies either an IPP printer object or an IPP job object. that identifies either an IPP printer object or an IPP job object. The
The IPP attributes using the 'ipp' scheme are specified below. Because IPP attributes using the 'ipp' scheme are specified below. Because the
the HTTP layer does not support the 'ipp' scheme, a client MUST map HTTP layer does not support the 'ipp' scheme, a client MUST map 'ipp'
'ipp' URLs to 'http' URLs, and then follows the HTTP [RFC2068][RFC2069] URLs to 'http' URLs, and then follows the HTTP [RFC2068][RFC2069] rules
rules for constructing a Request-Line and HTTP headers. The mapping is for constructing a Request-Line and HTTP headers. The mapping is simple
simple because the 'ipp' scheme implies all of the same protocol because the 'ipp' scheme implies all of the same protocol semantics as
semantics as that of the 'http' scheme [RFC2068], except that it that of the 'http' scheme [RFC2068], except that it represents a print
represents a print service and the implicit (default) port number that service and the implicit (default) port number that clients use to
clients use to connect to a server is port 631. connect to a server is port 631.
In the remainder of this section the term 'ipp-URL' means a URL whose In the remainder of this section the term 'ipp-URL' means a URL whose
scheme is 'ipp' and whose implicit (default) port is 631. The term scheme is 'ipp' and whose implicit (default) port is 631. The term
'http-URL' means a URL whose scheme is 'http', and the term 'https-URL' 'http-URL' means a URL whose scheme is 'http', and the term 'https-URL'
means a URL whose scheme is 'https', means a URL whose scheme is 'https',
A client and an IPP object (i.e. the server) MUST support the ipp-URL A client and an IPP object (i.e. the server) MUST support the ipp-URL
value in the following IPP attributes. value in the following IPP attributes.
job attributes: job attributes:
job-uri job-uri
skipping to change at page 18, line 50 skipping to change at page 19, line 50
Content-type: application/ipp Content-type: application/ipp
Transfer-Encoding: chunked Transfer-Encoding: chunked
... ...
"printer-uri" "ipp://myhost.com/myprinter/myqueue" "printer-uri" "ipp://myhost.com/myprinter/myqueue"
(encoded in application/ipp message body) (encoded in application/ipp message body)
... ...
The proxy then connects to the IPP origin server with headers that are The proxy then connects to the IPP origin server with headers that are
the same as the "no-proxy" example above. the same as the "no-proxy" example above.
6. Compatibility with IPP/1.0 Implementations 6. Security Considerations
IPP/1.1 server implementations SHOULD interoperate with IPP/1.0 client
implementations, as defined in [rfc 2565] and [rfc 2566] documents. If
an IPP/1.1 server implementation does not support an IPP/1.0 client, it
MUST return the error 'server-error-version-not-supported' and the
version in the response MUST be a version that the server supports and
SHOULD be a version that is closest to the clients version in the
request.
The following are specific rules of interoperability for an IPP/1.1
server that supports IPP/1.0 clients.
- If a server receives an IPP/1.0 request, it MUST return an IPP/1.0
response. That is, it MUST support both an http-URL and an https-
URL in the target "printer-uri" and "job-uri" operation attributes
in a request. The rules for attributes in a response is covered in
the next two bullet items.
- When a server returns the printer attribute "printer-uri-
supported", it MUST return all values of the attribute for an
IPP/1.1 request. For an IPP/1.0 request, a server MUST return a
subset of the attribute values, excluding those that are ipp-URLs,
and including those that are http-URLs and https-URLs..
- The table below shows the type of URL that a server returns for the
"job-uri" and "job-printer-uri" job attributes for all operations
based on how the job was created.
Operation Job created via
attribute
s for a
ipp secure ipp http https
request
ipp ipp No URL ipp No URL
returned returned
secure ipp ipp ipp ipp
ipp
http http No URL http No URL
returned returned
https http https http https
- If a server registers a nonsecure ipp-URL with a name service, then
it MUST also register an http-URL. If a printer supports a secure
connection using SSL3, then it MUST register an https-URL.
IPP/1.1 client implementations SHOULD interoperate with IPP/1.0 server
implementations. If an IPP/1.1 client receives an error 'server-error-
version-not-supported' and the version in the response is 1.0 and the
client supports IPP/1.0, the IPP/1.1 client MUST convert the target URI
(as defined in Section 4 of this document) and act as an IPP/1.0 client
[rfc 2565 and rfc 2566]. If the IPP/1.1 operation was intended to be
secure, the target conversion MUST result in an 'https' scheme;
otherwise it is an 'http' scheme.
7. Security Considerations
The IPP Model and Semantics document [ipp-mod] discusses high level The IPP Model and Semantics document [ipp-mod] discusses high level
security requirements (Client Authentication, Server Authentication and security requirements (Client Authentication, Server Authentication and
Operation Privacy). Client Authentication is the mechanism by which the Operation Privacy). Client Authentication is the mechanism by which the
client proves its identity to the server in a secure manner. Server client proves its identity to the server in a secure manner. Server
Authentication is the mechanism by which the server proves its identity Authentication is the mechanism by which the server proves its identity
to the client in a secure manner. Operation Privacy is defined as a to the client in a secure manner. Operation Privacy is defined as a
mechanism for protecting operations from eavesdropping. mechanism for protecting operations from eavesdropping.
7.1 Security Conformance 6.1 Security Conformance Requirements
IPP clients MUST/SHOULD [which is to be determined in consultation with This section defines the security requirements for IPP clients and IPP
the Area Director] support: objects.
Digest Authentication [rfc2069]. 6.1.1 Digest Authentication
IPP clients MUST support:
Digest Authentication [RFC2069].
MD5 and MD5-sess MUST be implemented and supported. MD5 and MD5-sess MUST be implemented and supported.
The Message Integrity feature NEED NOT be used. The Message Integrity feature NEED NOT be used.
IPP Printers MUST/SHOULD [which is to be determined in consultation with IPP Printers SHOULD support:
the Area Director] support:
Digest Authentication [rfc2069]. Digest Authentication [RFC2069].
MD5 and MD5-sess MUST be implemented and supported. MD5 and MD5-sess MUST be implemented and supported.
The Message Integrity feature NEED NOT be used. The Message Integrity feature NEED NOT be used.
IPP Printers SHOULD support TLS for client authentication, server The reasons that IPP Printers SHOULD (rather than MUST) support Digest
authentication and operation privacy. If an IPP Printer supports TLS, it Authentication are:
MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as
mandated by RFC 2246 [rfc2246]. All other cipher suites are OPTIONAL. An 1.While Client Authentication is important, there is a certain class of
IPP Printer MAY support Basic Authentication (described in HTTP/1.1 [ printer devices where it does not make sense. Specifically, a low-
rfc 2068]) for client authentication if the channel is secure. TLS end device with limited ROM space and low paper throughput may not
with the above mandated cipher suite can provide such a secure channel. need Client Authentication. This class of device typically requires
firmware designers to make trade-offs between protocols and
functionality to arrive at the lowest-cost solution possible.
Factored into the designer.s decisions is not just the size of the
code, but also the testing, maintenance, usefulness, and time-to-
market impact for each feature delivered to the customer. Forcing
such low-end devices to provide security in order to claim IPP/1.1
conformance would not make business sense and could potentially stall
the adoption of the standard.
2.Print devices that have high-volume throughput and have available ROM
space have a compelling argument to provide support for Client
Authentication that safeguards the device from unauthorized access.
These devices are prone to a high loss of consumables and paper if
unauthorized access should occur.
6.1.2 Transport Layer Security (TLS)
IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246] for
Server Authentication and Operation Privacy. IPP Printers MAY also
support TLS for Client Authentication. If an IPP Printer supports TLS,
it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as
mandated by RFC 2246 [RFC2246]. All other cipher suites are OPTIONAL.
An IPP Printer MAY support Basic Authentication (described in HTTP/1.1
[RFC2068]) for Client Authentication if the channel is secure. TLS with
the above mandated cipher suite can provide such a secure channel.
If a IPP client supports TLS, it MUST support the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246
[RFC2246]. All other cipher suites are OPTIONAL.
The IPP Model and Semantics document defines two printer attributes The IPP Model and Semantics document defines two printer attributes
("uri-authentication-supported" and "uri-security-supported") that the ("uri-authentication-supported" and "uri-security-supported") that the
client can use to discover the security policy of a printer. That client can use to discover the security policy of a printer. That
document also outlines IPP-specific security considerations and should document also outlines IPP-specific security considerations and should
be the primary reference for security implications with regard to the be the primary reference for security implications with regard to the
IPP protocol itselfFor backward compatibility with IPP version 1.0, IPP IPP protocol itself. For backward compatibility with IPP version 1.0,
clients and printers MAY also support SSL3. This is in addition to the IPP clients and printers MAY also support SSL3. This is in addition to
security required in this document. the security required in this document.
7.2 Using IPP with TLS 6.2 Using IPP with TLS
An initial IPP request never uses TLS. The switch to TLS occurs either An initial IPP request never uses TLS. The switch to TLS occurs either
because the server grants the client's request to upgrade to TLS, or a because the server grants the client's request to upgrade to TLS, or a
server asks to switch to TLS in its response. Secure communication server asks to switch to TLS in its response. Secure communication
begins with a server's response to switch to TLS. The initial connection begins with a server's response to switch to TLS. The initial connection
is not secure. Any client expecting a secure connection should first use is not secure. Any client expecting a secure connection should first use
a non-sensitive operation (e.g. an HTTP POST with an empty message body) a non-sensitive operation (e.g. an HTTP POST with an empty message body)
to establish a secure connection before sending any sensitive data. to establish a secure connection before sending any sensitive data.
During the TLS handshake, the original session is preserved. During the TLS handshake, the original session is preserved.
An IPP client that wants a secure connection MUST send "TLS/1.0" as one An IPP client that wants a secure connection MUST send "TLS/1.0" as one
of the field-values of the HTTP/1.1 Upgrade request header, e.g. of the field-values of the HTTP/1.1 Upgrade request header, e.g.
"Upgrade: TLS/1.0" (see rfc2068 section 14.42). If the origin-server "Upgrade: TLS/1.0" (see rfc2068 section 14.42). If the origin-server
skipping to change at page 21, line 36 skipping to change at page 22, line 4
response, it can perform the request again with an Upgrade header with response, it can perform the request again with an Upgrade header with
the "TLS/1.0" value. the "TLS/1.0" value.
If a server supports TLS, it SHOULD include the "Upgrade" header with If a server supports TLS, it SHOULD include the "Upgrade" header with
the value "TLS/1.0" in response to any OPTIONS request. the value "TLS/1.0" in response to any OPTIONS request.
Upgrade is a hop-by-hop header (rfc2068, section 13.5.1), so each Upgrade is a hop-by-hop header (rfc2068, section 13.5.1), so each
intervening proxy which supports TLS MUST also request the same version intervening proxy which supports TLS MUST also request the same version
of TLS/1.0 on its subsequent request. Furthermore, any caching proxy of TLS/1.0 on its subsequent request. Furthermore, any caching proxy
which supports TLS MUST NOT reply from its cache when TLS/1.0 has been which supports TLS MUST NOT reply from its cache when TLS/1.0 has been
requested (although clients are still recommended to explicitly include requested (although clients are still recommended to explicitly include
"Cache-control: no-cache"). "Cache-control: no-cache").
Note: proxy servers may be able to request or initiate a TLS-secured Note: proxy servers may be able to request or initiate a TLS-secured
connection, e.g. the outgoing or incoming firewall of a trusted connection, e.g. the outgoing or incoming firewall of a trusted
subnetwork. subnetwork.
8. References 7. Interoperability with IPP/1.0 Implementations
[char] N. Freed, J. Postel: IANA Charset Registration Procedures, Work For interoperability with IPP/1.0 servers, IPP/1.1 clients SHOULD also
in Progress (draft-freed-charset-reg-02.txt). meet the conformance requirements for clients as specified in [RFC2566]
and [RFC2565].
For interoperability with IPP/1.0 clients, IPP/1.1 objects SHOULD also
meet the conformance requirements for IPP objects as specified in
[RFC2565] and [RFC2566].
7.1 The "version-number" Parameter
The following are rules regarding the "version-number" parameter (see
section 3.3):
1. Clients MUST send requests containing a "version-number" parameter
with a '1.1' value and SHOULD try supplying alternate version
numbers if they receive a 'server-error-version-not-supported'
error return in a response.
2. IPP objects MUST accept requests containing a "version-number"
parameter with a '1.1' value (or reject the request for reasons
other than 'server-error-version-not-supported').
3. IPP objects SHOULD accept any request with the major version '1'
(or reject the request for reasons other than 'server-error-
version-not-supported'). See [ipp-mod] "versions" sub-section.
4. In any case, security MUST NOT be compromised when a client
supplies a lower "version-number" parameter in a request. For
example, if an IPP/1.1 conforming Printer object accepts version
'1.0' requests and is configured to enforce Digest Authentication,
it MUST do the same for a version '1.0' request.
7.2 Security and URL Schemes
The following are rules regarding security, the "version-number"
parameter, and the URL scheme supplied in target attributes and
responses:
1. When a client supplies a request, the "printer-uri" or "job-uri"
target operation attribute MUST have the same scheme as that
indicated in one of the values of the "printer-uri-supported"
Printer attribute.
2. When the server returns the "job-printer-uri" or "job-uri" Job
Description attributes, it SHOULD return the same scheme ('ipp',
'https', 'http', etc.) that the client supplied in the "printer-
uri" or "job-uri" target operation attributes in the Get-Job-
Attributes or Get-Jobs request, rather than the scheme used when
the job was created. However, when a client requests job
attributes using the Get-Job-Attributes or Get-Jobs operations, the
jobs and job attributes that the server returns depends on: (1) the
security in effect when the job was created, (2) the security in
effect in the query request, and (3) the security policy in force.
3. If a server registers a non-secure ipp-URL with a directory service
(see [IPP-MOD] "Generic Directory Schema" Appendix), then it SHOULD
also register an http-URL for interoperability with IPP/1.0 clients
(see section 7).
4. In any case, security MUST NOT be compromised when a client
supplies an 'http' or other non-secure URL scheme in the target
"printer-uri" and "job-uri" operation attributes in a request.
8. References
[dpa] ISO/IEC 10175 Document Printing Application (DPA), June 1996. [dpa] ISO/IEC 10175 Document Printing Application (DPA), June 1996.
[iana] IANA Registry of Coded Character Sets: ftp://ftp.isi.edu/in- [iana] IANA Registry of Coded Character Sets: ftp://ftp.isi.edu/in-
notes/iana/assignments/character-sets. notes/iana/assignments/character-sets.
[ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.1: [ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.1:
Implementer's Guide", draft-ietf-ipp-implementers-guide-01.txt, Implementer's Guide", work in progress.
February 1999, work in progress.
[ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. [ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
Powell, "Internet Printing Protocol/1.0: Model and Semantics", "Internet Printing Protocol/1.0: Model and Semantics", <draft-
<draft-ietf-ipp-model-v11-02.txt>, May, 1999. ietf-ipp-model-v11-03.txt>, June, 1999.
[ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., [ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet
"Internet Printing Protocol/1.1: Encoding and Transport", draft- Printing Protocol/1.1: Encoding and Transport", draft-ietf-ipp-
ietf-ipp-protocol-v11-00-.txt, February 1999. protocol-v11-02-.txt, June 1999.
[rfc822] Crocker, D., "Standard for the Format of ARPA [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
Internet Text Messages", RFC 822, August 1982. Messages", RFC 822, August 1982.
[rfc1123] Braden, S., "Requirements for Internet Hosts - [RFC1123] Braden, S., "Requirements for Internet Hosts - Application
Application and Support", RFC 1123, October, 1989. and Support", RFC 1123, October, 1989.
[rfc1179] McLaughlin, L. III, (editor), "Line Printer Daemon [RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol"
Protocol" RFC 1179, August 1990. RFC 1179, August 1990.
[rfc1543] Postel, J., "Instructions to RFC Authors", RFC 1543, [RFC1543] Postel, J., "Instructions to RFC Authors", RFC 1543, October
October 1993. 1993.
[rfc1738] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform [RFC1738] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform
Resource Locators (URL)", RFC 1738, December, 1994. Resource Locators (URL)", RFC 1738, December, 1994.
[rfc1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and
Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. Gyllenskog, J., "Printer MIB", RFC 1759, March 1995.
[rfc1766] H. Alvestrand, " Tags for the Identification of [RFC1766] H. Alvestrand, " Tags for the Identification of Languages",
Languages", RFC 1766, March 1995. RFC 1766, March 1995.
[rfc1808] R. Fielding, "Relative Uniform Resource Locators", [RFC1808] R. Fielding, "Relative Uniform Resource Locators", RFC1808,
RFC1808, June 1995. June 1995.
[rfc1903] J. Case, et al. "Textual Conventions for Version 2 of [RFC1903] J. Case, et al. "Textual Conventions for Version 2 of the
the Simple Network Management Protocol (SNMPv2)", RFC 1903, Simple Network Management Protocol (SNMPv2)", RFC 1903, January
January 1996. 1996.
[rfc2046] N. Freed & N. Borenstein, Multipurpose Internet Mail [RFC2046] N. Freed & N. Borenstein, Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types. November 1996, RFC 2046. Extensions (MIME) Part Two: Media Types. November 1996, RFC 2046.
[rfc2048] N. Freed, J. Klensin & J. Postel. Multipurpose Internet [RFC2048] N. Freed, J. Klensin & J. Postel. Multipurpose Internet Mail
Mail Extension (MIME) Part Four: Registration Procedures. Extension (MIME) Part Four: Registration Procedures. November
November 1996 (Also BCP0013), RFC 2048. 1996 (Also BCP0013), RFC 2048.
[rfc2068] R Fielding, et al, "Hypertext Transfer Protocol . [RFC2068] R Fielding, et al, "Hypertext Transfer Protocol . HTTP/1.1"
HTTP/1.1" RFC 2068, January 1997. RFC 2068, January 1997.
[rfc2069] J. Franks, et al, "An Extension to HTTP: Digest Access [RFC2069] J. Franks, et al, "An Extension to HTTP: Digest Access
Authentication" RFC 2069, January 1997. Authentication" RFC 2069, January 1997.
[rfc2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119 , March 1997. Requirement Levels", RFC 2119 , March 1997.
[rfc2184] N. Freed, K. Moore, "MIME Parameter Value and Encoded [RFC2184] N. Freed, K. Moore, "MIME Parameter Value and Encoded Word
Word Extensions: Character Sets, Languages, and Continuations", Extensions: Character Sets, Languages, and Continuations", RFC
RFC 2184, August 1997. 2184, August 1997.
[rfc2234] D. Crocker et al., "Augmented BNF for Syntax [RFC2234] D. Crocker et al., "Augmented BNF for Syntax Specifications:
Specifications: ABNF", RFC 2234. November 1997. ABNF", RFC 2234. November 1997.
[rfc2246] T. Dierks et al., "The TLS Protocol", RFC 2246. January [RFC2246] T. Dierks et al., "The TLS Protocol", RFC 2246. January 1999.
1999.
[rfc2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform [RFC2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998. 1998.
[rfc2565] Herriot, R., Butler, S., Moore, P., Turner, R., [RFC2565] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet
"Internet Printing Protocol/1.0: Encoding and Transport", rfc Printing Protocol/1.0: Encoding and Transport", rfc 2565, April
2565, April 1999. 1999.
[rfc 2566] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. [RFC2566] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
Powell, "Internet Printing Protocol/1.0: Model and Semantics", "Internet Printing Protocol/1.0: Model and Semantics", rfc 2566,
rfc 2566, April, 1999. April, 1999.
[rfc2567] Wright, D., "Design Goals for an Internet Printing [RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol",
Protocol", RFC2567,April 1999. RFC2567, April 1999.
[rfc2568] Zilles, S., "Rationale for the Structure and Model and [RFC2568] Zilles, S., "Rationale for the Structure and Model and
Protocol for the Internet Printing Protocol", RC 2568,April Protocol for the Internet Printing Protocol", RC 2568,April 1999.
1999.
[rfc2569] Herriot, R., Hastings, T., Jacobs, N., Martin, J., [RFC2569] Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping
"Mapping between LPD and IPP Protocols RFC 2569, April 1999. between LPD and IPP Protocols RFC 2569, April 1999.
9. Author's Address 9. Author's Address
Paul Moore Robert Herriot (editor) Paul Moore
Robert Herriot (editor) Xerox Corporation Microsoft
Microsoft 3400 Hillview Ave., Bldg #1 One Microsoft Way
Xerox Corporation Palo Alto, CA 94304 Redmond, WA 98053
One Microsoft Way
3400 Hillview Ave., Bldg #1
Redmond, WA 98053
Palo Alto, CA 94304
Phone: 425-936-0908 Phone: 650-813-7696 Phone: 425-936-0908
Phone: 650-813-7696 Fax: 650-813-6860 Fax: 425-93MS-FAX
Fax: 425-93MS-FAX Email: Email: paulmo@microsoft.com
Fax: 650-813-6860
Email: paulmo@microsoft.com
Email:
robert.herriot@pahv.xerox.com robert.herriot@pahv.xerox.com
Randy Turner Sylvan Butler Randy Turner
Sylvan Butler Hewlett-Packard 2Wire, Inc.
Hewlett-Packard 11311 Chinden Blvd. 694 Tasman Dr.
11311 Chinden Blvd. Boise, ID 83714 Milpitas, CA 95035
Boise, ID 83714
Email: rturner@2wire.com Phone: 208-396-6000 Phone: 408-546-1273
Phone: 208-396-6000
Fax: 208-396-3457 Fax: 208-396-3457
Email: sbutler@boi.hp.com Email: sbutler@boi.hp.com
John Wenn John Wenn
Xerox Corporation Xerox Corporation
737 Hawaii St 737 Hawaii St
El Segundo, CA 90245 El Segundo, CA 90245
IPP Mailing List: ipp@pwg.org Phone: 310-333-5764 IPP Mailing List: ipp@pwg.org Phone: 310-333-5764
IPP Mailing List Subscription: Fax: 310-333-5514 IPP Mailing List Subscription: Fax: 310-333-5514
ipp-request@pwg.org ipp-request@pwg.org
IPP Web Page: Email: jwenn@cp10.es.xerox.com IPP Web Page: Email: jwenn@cp10.es.xerox.com
http://www.pwg.org/ipp/ http://www.pwg.org/ipp/
skipping to change at page 24, line 17 skipping to change at page 25, line 45
El Segundo, CA 90245 El Segundo, CA 90245
IPP Mailing List: ipp@pwg.org Phone: 310-333-5764 IPP Mailing List: ipp@pwg.org Phone: 310-333-5764
IPP Mailing List Subscription: Fax: 310-333-5514 IPP Mailing List Subscription: Fax: 310-333-5514
ipp-request@pwg.org ipp-request@pwg.org
IPP Web Page: Email: jwenn@cp10.es.xerox.com IPP Web Page: Email: jwenn@cp10.es.xerox.com
http://www.pwg.org/ipp/ http://www.pwg.org/ipp/
10. Other Participants: 10. Other Participants:
Chuck Adams - Tektronix Harry Lewis - IBM Chuck Adams - Tektronix Shivaun Albright - HP
Ron Bergman - Dataproducts Tony Liao - Vivid Image Jeff Barnett - IBM Ron Bergman - Dataproducts
Keith Carter - IBM David Manchala - Xerox Keith Carter - IBM Angelo Caruso - Xerox
Angelo Caruso - Xerox Carl-Uno Manros - Xerox Rajesh Chawla - TR Computing Josh Cohen - Microsoft
Jeff Copeland - QMS Jay Martin - Underscore Solutions
Roger deBry - IBM Larry Masinter - Xerox Jeff Copeland - QMS Andy Davidson - Tektronix
Lee Farrell - Canon Ira McDonald - High North Inc. Roger deBry - IBM Mabry Dozier - QMS
Sue Gleeson - Digital Bob Pentecost - Hewlett-Packard Lee Farrell - Canon Steve Gebert - IBM
Charles Gordon - Osicom Patrick Powell - Astart Sue Gleeson - Digital Charles Gordon - Osicom
Technologies Brian Grimshaw - Apple Jerry Hadsell - IBM
Brian Grimshaw - Apple Jeff Rackowitz - Intermec Richard Hart - Digital Tom Hastings - Xerox
Jerry Hadsell - IBM Xavier Riley - Xerox
Richard Hart - Digital Gary Roberts - Ricoh Stephen Holmstead Zhi-Hong Huang - Zenographics
Tom Hastings - Xerox Stuart Rowley - Kyocera Scott Isaacson - Novell Babek Jahromi - Microsoft
Stephen Holmstead Richard Schneider - Epson Swen Johnson - Xerox David Kellerman - Northlake
Zhi-Hong Huang - Zenographics Shigern Ueda - Canon
Scott Isaacson - Novell Bob Von Andel - Allegro Software
Rich Lomicka - Digital William Wagner - Digital Products
David Kellerman - Northlake Jasper Wong - Xionics
Software Software
Robert Kline - TrueSpectra Don Wright - Lexmark Robert Kline - TrueSpectra Carl Kugler - IBM
Dave Kuntz - Hewlett-Packard Rick Yardumian - Xerox Dave Kuntz - Hewlett-Packard Takami Kurono - Brother
Takami Kurono - Brother Lloyd Young - Lexmark Rick Landau - Digital Scott Lawrence - Agranot Systems
Rich Landau - Digital Peter Zehler - Xerox Greg LeClair - Epson Harry Lewis - IBM
Greg LeClair - Epson Frank Zhao - Panasonic Tony Liao - Vivid Image Roy Lomicka - Digital
Pete Loya - HP Ray Lutz - Cognisys
Mike MacKay - Novell, Inc. David Manchala - Xerox
Carl-Uno Manros - Xerox Jay Martin - Underscore
Larry Masinter - Xerox Stan McConnell - Xerox
Ira McDonald - High North Inc. Peter Michalek - Shinesoft
Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
Pat Nogay - IBM Ron Norton - Printronics
Bob Pentecost - Hewlett-Packard Patrick Powell - Astart
Technologies
Jeff Rackowitz - Intermec Rob Rhoads - Intel
Xavier Riley - Xerox Gary Roberts - Ricoh
David Roach - Unisys Stuart Rowley - Kyocera
Richard Schneider - Epson Kris Schoff - HP
Bob Setterbo - Adobe Devon Taylor - Novell, Inc.
Mike Timperman - Lexmark Shigern Ueda - Canon
Bob Von Andel - Allegro Software William Wagner - Osicom
Jim Walker - DAZEL Chris Wellens - Interworking Labs
Rob Whittle - Novell, Inc. Jasper Wong - Xionics
Don Wright - Lexmark Rick Yardumian - Xerox
Lloyd Young - Lexmark Atsushi Yuki - Kyocera
Peter Zehler - Xerox Frank Zhao - Panasonic
Steve Zilles - Adobe Steve Zilles - Adobe
11. Appendix A: Protocol Examples 11. Appendix A: Protocol Examples
11.1 Print-Job Request 11.1 Print-Job Request
The following is an example of a Print-Job request with job-name, The following is an example of a Print-Job request with job-name,
copies, and sides specified. The "ipp-attribute-fidelity" attribute is copies, and sides specified. The "ipp-attribute-fidelity" attribute is
set to 'true' so that the print request will fail if the "copies" or the set to 'true' so that the print request will fail if the "copies" or the
"sides" attribute are not supported or their values are not supported. "sides" attribute are not supported or their values are not supported.
Octets Symbolic Value Protocol field Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
0x0101 1.1 version-number 0x0101 1.1 version-number
0x0002 Print-Job operation-id 0x0002 Print-Job operation-id
0x00000001 1 request-id 0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag 0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag 0x47 charset type value-tag
0x0012 name-length 0x0012 name-length
attributes- attributes-charset name attributes- attributes-charset name
charset charset
0x0008 value-length 0x0008 value-length
us-ascii US-ASCII value us-ascii US-ASCII value
skipping to change at page 29, line 4 skipping to change at page 31, line 55
0x0006 name-length 0x0006 name-length
job-id job-id name job-id job-id name
0x0004 value-length 0x0004 value-length
147 147 value 147 147 value
0x45 uri type value-tag 0x45 uri type value-tag
0x0007 name-length 0x0007 name-length
job-uri job-uri name job-uri job-uri name
0x0019 value-length 0x0019 value-length
ipp://forest/pin job 123 on pinetree value ipp://forest/pin job 123 on pinetree value
etree/123 etree/123
Octets Symbolic Value Protocol field
0x23 enum type value-tag 0x23 enum type value-tag
0x0009 name-length 0x0009 name-length
job-state job-state name job-state job-state name
0x0004 value-length 0x0004 value-length
Octets Symbolic Value Protocol field
0x0003 pending value 0x0003 pending value
0x03 end-of-attributes end-of-attributes-tag 0x03 end-of-attributes end-of-attributes-tag
11.5 Print-URI Request 11.5 Print-URI Request
The following is an example of Print-URI request with copies and job- The following is an example of Print-URI request with copies and job-
name parameters: name parameters:
Octets Symbolic Value Protocol field Octets Symbolic Value Protocol field
0x0101 1.1 version-number 0x0101 1.1 version-number
skipping to change at page 30, line 4 skipping to change at page 33, line 43
ftp://foo.com ftp://foo.com/foo value ftp://foo.com ftp://foo.com/foo value
/foo /foo
0x42 nameWithoutLanguage type value-tag 0x42 nameWithoutLanguage type value-tag
0x0008 name-length 0x0008 name-length
job-name job-name name job-name job-name name
0x0006 value-length 0x0006 value-length
foobar foobar value foobar foobar value
0x02 start job-attributes job-attributes-tag 0x02 start job-attributes job-attributes-tag
0x21 integer type value-tag 0x21 integer type value-tag
0x0006 name-length 0x0006 name-length
Octets Symbolic Value Protocol field
copies copies name copies copies name
0x0004 value-length 0x0004 value-length
0x00000001 1 value 0x00000001 1 value
0x03 end-of-attributes end-of-attributes-tag 0x03 end-of-attributes end-of-attributes-tag
11.6 Create-Job Request 11.6 Create-Job Request
The following is an example of Create-Job request with no parameters and The following is an example of Create-Job request with no parameters and
no attributes: no attributes:
skipping to change at page 31, line 4 skipping to change at page 35, line 17
0x000A Get-Jobs operation-id 0x000A Get-Jobs operation-id
0x00000123 0x123 request-id 0x00000123 0x123 request-id
0x01 start operation-attributes operation-attributes-tag 0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag 0x47 charset type value-tag
0x0012 name-length 0x0012 name-length
attributes- attributes-charset name attributes- attributes-charset name
charset charset
0x0008 value-length 0x0008 value-length
us-ascii US-ASCII value us-ascii US-ASCII value
0x48 natural-language type value-tag 0x48 natural-language type value-tag
Octets Symbolic Value Protocol field
0x001B name-length 0x001B name-length
attributes- attributes-natural-language name attributes- attributes-natural-language name
natural- natural-
language language
0x0005 value-length 0x0005 value-length
en-us en-US value en-us en-US value
0x45 uri type value-tag 0x45 uri type value-tag
0x000B name-length 0x000B name-length
printer-uri printer-uri name printer-uri printer-uri name
0x0015 value-length 0x0015 value-length
skipping to change at page 32, line 4 skipping to change at page 36, line 19
back) back)
0x01 start operation-attributes operation-attribute-tag 0x01 start operation-attributes operation-attribute-tag
0x47 charset type value-tag 0x47 charset type value-tag
0x0012 name-length 0x0012 name-length
attributes- attributes-charset name attributes- attributes-charset name
charset charset
0x000A value-length 0x000A value-length
ISO-8859-1 ISO-8859-1 value ISO-8859-1 ISO-8859-1 value
0x48 natural-language type value-tag 0x48 natural-language type value-tag
0x001B name-length 0x001B name-length
Octets Symbolic Value Protocol field
attributes- attributes-natural-language name attributes- attributes-natural-language name
natural- natural-
language language
0x0005 value-length 0x0005 value-length
en-us en-US value en-us en-US value
0x41 textWithoutLanguage type value-tag 0x41 textWithoutLanguage type value-tag
0x000E name-length 0x000E name-length
status-message status-message name status-message status-message name
0x000D value-length 0x000D value-length
successful-ok successful-ok value successful-ok successful-ok value
skipping to change at page 32, line 46 skipping to change at page 37, line 4
0x0006 name-length 0x0006 name-length
job-id job-id name job-id job-id name
0x0004 value-length 0x0004 value-length
148 149 value 148 149 value
0x36 nameWithLanguage value-tag 0x36 nameWithLanguage value-tag
0x0008 name-length 0x0008 name-length
job-name job-name name job-name job-name name
0x0012 value-length 0x0012 value-length
0x0005 sub-value-length 0x0005 sub-value-length
de-CH de-CH value de-CH de-CH value
Octets Symbolic Value Protocol field
0x0009 sub-value-length 0x0009 sub-value-length
isch guet isch guet name isch guet isch guet name
0x03 end-of-attributes end-of-attributes-tag 0x03 end-of-attributes end-of-attributes-tag
12. Appendix C: Registration of MIME Media Type Information for 12. Appendix C: Registration of MIME Media Type Information for
"application/ipp" "application/ipp"
This appendix contains the information that IANA requires for This appendix contains the information that IANA requires for
registering a MIME media type. The information following this paragraph registering a MIME media type. The information following this paragraph
will be forwarded to IANA to register application/ipp whose contents are will be forwarded to IANA to register application/ipp whose contents are
skipping to change at page 33, line 44 skipping to change at page 37, line 58
servers) MUST comply with all conformance requirements imposed by the servers) MUST comply with all conformance requirements imposed by the
normative specifications [ipp-mod] and [ipp-pro]. Protocol encoding normative specifications [ipp-mod] and [ipp-pro]. Protocol encoding
rules specified in [ipp-pro] are comprehensive, so that interoperability rules specified in [ipp-pro] are comprehensive, so that interoperability
between conforming implementations is guaranteed (although support for between conforming implementations is guaranteed (although support for
specific optional features is not ensured). Both the "charset" and specific optional features is not ensured). Both the "charset" and
"natural-language" of all IPP/1.1 attribute values which are a "natural-language" of all IPP/1.1 attribute values which are a
LOCALIZED-STRING are explicit within IPP protocol requests/responses LOCALIZED-STRING are explicit within IPP protocol requests/responses
(without recourse to any external information in HTTP, SMTP, or other (without recourse to any external information in HTTP, SMTP, or other
message transport headers). message transport headers).
Published specification: Published specifications:
[ipp-mod] Isaacson, S., deBry, R., Hastings, T., Herriot, R., [ipp-mod] Isaacson, S., deBry, R., Hastings, T., Herriot, R.,
Powell, P., "Internet Printing Protocol/1.1: Model and Powell, P., "Internet Printing Protocol/1.1: Model and
Semantics" draft-ietf-ipp-model-v11-00.txt, February, 1999. Semantics" draft-ietf-ipp-model-v11-03.txt, June, 1999.
[ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., [ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R.,
"Internet Printing Protocol/1.1: Encoding and Transport", draft- "Internet Printing Protocol/1.1: Encoding and Transport", draft-
ietf-ipp-protocol-v11-00.txt, February, 1999. ietf-ipp-protocol-v11-02.txt, June, 1999.
Applications which use this media type: Applications which use this media type:
Internet Printing Protocol (IPP) print clients and print servers, Internet Printing Protocol (IPP) print clients and print servers,
communicating using HTTP/1.1 (see [IPP-PRO]), SMTP/ESMTP, FTP, or other communicating using HTTP/1.1 (see [IPP-PRO]), SMTP/ESMTP, FTP, or other
transport protocol. Messages of type "application/ipp" are self- transport protocol. Messages of type "application/ipp" are self-
contained and transport-independent, including "charset" and "natural- contained and transport-independent, including "charset" and "natural-
language" context for any LOCALIZED-STRING value. language" context for any LOCALIZED-STRING value.
Person & email address to contact for further information: Person & email address to contact for further information:
Tom Hastings Tom Hastings
Xerox Corporation Xerox Corporation
737 Hawaii St. ESAE-231 737 Hawaii St. ESAE-231
El Segundo, CA El Segundo, CA
skipping to change at page 34, line 36 skipping to change at page 38, line 49
Phone: 650-813-7696 Phone: 650-813-7696
Fax: 650-813-6860 Fax: 650-813-6860
Email: robert.herriot@pahv.xerox.com Email: robert.herriot@pahv.xerox.com
Intended usage: Intended usage:
COMMON COMMON
13. Appendix D: Changes from IPP /1.0 13. Appendix D: Changes from IPP /1.0
IPP/1.1 is identical to IPP/1.0 with the follow changes: IPP/1.1 is identical to IPP/1.0 [RFC2565] with the follow changes:
1.Attributes values that identify a printer or job object use a new 1.Attributes values that identify a printer or job object use a new
'ipp' scheme. The 'http' and 'https' schemes are supported only for 'ipp' scheme. The 'http' and 'https' schemes are supported only for
backward compatibility. See section 5. backward compatibility. See section 5.
2.New requirement for support of Digest Authentication. See Section 2.Clients MUST support of Digest Authentication, IPP Printers SHOULD
7.1 support Digest Authentication. See Section 6.1.1
3.TLS is recommended for channel security. In addition, SSL3 may be 3.TLS is recommended for channel security. In addition, SSL3 may be
supported for backward compatibility. See Section 7.2 supported for backward compatibility. See Section 6.1.2
4.For interoperability with IPP/1.0, IPP/1.1 Clients SHOULD support
IPP/1.0 conformance requirements. IPP/1.1 Printers SHOULD support
IPP/1.0 conformance requirements. See section 7.1.
5.IPP/1.1 objects SHOULD accept any request with major version number
'1'. See section 7.1.
6.IPP objects SHOULD return the URL scheme requested for "job-printer-
uri" and "job-uri" Job Attributes, rather than the URL scheme used to
create the job. See section 7.2
14. Full Copyright Statement 14. Full Copyright Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards- procedures with respect to rights in standards-track and standards-
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/