draft-ietf-ipp-protocol-v11-02.txt   draft-ietf-ipp-protocol-v11-03.txt 
INTERNET-DRAFT Robert Herriot (editor) INTERNET-DRAFT Robert Herriot (editor)
<draft-ietf-ipp-protocol-v11-02.txt> Xerox Corporation <draft-ietf-ipp-protocol-v11-03.txt> Xerox Corporation
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
June 11, 1999 June 23, 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 1, line 49 skipping to change at page 1, line 49
Abstract Abstract
This document is one of a set of documents, which together describe all 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 aspects of a new Internet Printing Protocol (IPP). IPP is an application
level protocol that can be used for distributed printing using Internet level protocol that can be used for distributed printing using Internet
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.
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 [RFC2569]
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. A few OPTIONAL operator operations have been added satisfied in IPP/1.1. A few OPTIONAL operator operations have been added
to IPP/1.1. to IPP/1.1.
skipping to change at page 3, line 31 skipping to change at page 3, line 31
3.10Value Length..................................................14 3.10Value Length..................................................14
3.11(Attribute) Value.............................................15 3.11(Attribute) Value.............................................15
3.12Data..........................................................17 3.12Data..........................................................17
4. Encoding of Transport Layer........................................17 4. Encoding of Transport Layer........................................17
5. IPP URL Scheme.....................................................18 5. IPP URL Scheme.....................................................18
6. Security Considerations............................................19 6. Security Considerations............................................19
6.1 Security Conformance Requirements.............................20 6.1 Security Conformance Requirements.............................20
6.1.1 Digest Authentication...................................20 6.1.1 Digest Authentication...................................20
6.1.2 Transport Layer Security (TLS)..........................20 6.1.2 Transport Layer Security (TLS)..........................20
6.2 Using IPP with TLS............................................21 6.2 Using IPP with TLS............................................21
7. Interoperability with IPP/1.0 Implementations......................22 7. Interoperability with IPP/1.0 Implementations......................21
7.1 The "version-number" Parameter................................22 7.1 The "version-number" Parameter................................21
7.2 Security and URL Schemes......................................22 7.2 Security and URL Schemes......................................22
8. References.........................................................23 8. References.........................................................23
9. Author's Address...................................................25 9. Author's Address...................................................24
10.Other Participants:...............................................25 10.Other Participants:...............................................25
11.Appendix A: Protocol Examples.....................................26 11.Appendix A: Protocol Examples.....................................26
11.1Print-Job Request.............................................26 11.1Print-Job Request.............................................26
11.2Print-Job Response (successful)...............................27 11.2Print-Job Response (successful)...............................27
11.3Print-Job Response (failure)..................................28 11.3Print-Job Response (failure)..................................28
11.4Print-Job Response (success with attributes ignored)..........29 11.4Print-Job Response (success with attributes ignored)..........29
11.5Print-URI Request.............................................32 11.5Print-URI Request.............................................32
11.6Create-Job Request............................................33 11.6Create-Job Request............................................33
11.7Get-Jobs Request..............................................34 11.7Get-Jobs Request..............................................34
11.8Get-Jobs Response.............................................35 11.8Get-Jobs Response.............................................35
skipping to change at page 4, line 11 skipping to change at page 4, line 11
"application/ipp".....................................................37 "application/ipp".....................................................37
13.Appendix D: Changes from IPP /1.0.................................38 13.Appendix D: Changes from IPP /1.0.................................38
14.Full Copyright Statement..........................................39 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 2616 [RFC2616] 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
skipping to change at page 10, line 49 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 0 " further details, see section 3.9 "(Attribute) Name" and 11 "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
skipping to change at page 14, line 16 skipping to change at page 14, line 16
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 0 " xxx-attributes-tag (See the table below and section 11 "Appendix A:
Protocol Examples"). In addition, the order of these xxx-attributes-tags
Appendix A: Protocol Examples"). In addition, the order of these xxx- and xxx-attribute-sequences in the protocol MUST be the same as in the
attributes-tags and xxx-attribute-sequences in the protocol MUST be the model document, but the order of attributes within each xxx-attribute-
same as in the model document, but the order of attributes within each sequence MUST be unspecified. The table below maps the model document
xxx-attribute-sequence MUST be unspecified. The table below maps the group name to xxx-attributes-sequence:
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- job-attributes-sequence Requested Attributes (Get-Job- job-attributes-sequence
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 Document Content in a special position as described
above 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 0 " job object are in the ith job-attribute-sequence. See Section 11
"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 17, line 25 skipping to change at page 17, line 25
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 [RFC2616] 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 [RFC2616] .
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 [RFC2616].
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 [RFC2616].
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[RFC2616].
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 document defines a new scheme 'ipp' as the value of a URL The IPP/1.1 document defines a new scheme 'ipp' as the value of a URL
that identifies either an IPP printer object or an IPP job object. The that identifies either an IPP printer object or an IPP job object. The
IPP attributes using the 'ipp' scheme are specified below. Because the IPP attributes using the 'ipp' scheme are specified below. Because the
HTTP layer does not support the 'ipp' scheme, a client MUST map 'ipp' HTTP layer does not support the 'ipp' scheme, a client MUST map 'ipp'
URLs to 'http' URLs, and then follows the HTTP [RFC2068][RFC2069] rules URLs to 'http' URLs, and then follows the HTTP [RFC2616][RFC2617] rules
for constructing a Request-Line and HTTP headers. The mapping is simple for constructing a Request-Line and HTTP headers. The mapping is simple
because the 'ipp' scheme implies all of the same protocol semantics as because the 'ipp' scheme implies all of the same protocol semantics as
that of the 'http' scheme [RFC2068], except that it represents a print that of the 'http' scheme [RFC2616], except that it represents a print
service and the implicit (default) port number that clients use to service and the implicit (default) port number that 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.
skipping to change at page 19, line 13 skipping to change at page 19, line 13
human user, it is REQUIRED that the human see the ipp-URL as is. human user, it is REQUIRED that the human see the ipp-URL as is.
When a client sends a request, it MUST convert a target ipp-URL to a When a client sends a request, it MUST convert a target ipp-URL to a
target http-URL for the HTTP layer according to the following rules: target http-URL for the HTTP layer according to the following rules:
1. change the 'ipp' scheme to 'http' 1. change the 'ipp' scheme to 'http'
2. add an explicit port 631 if the URL does not contain an explicit 2. add an explicit port 631 if the URL does not contain an explicit
port. Note: port 631 is the IANA assigned Well Known Port for the port. Note: port 631 is the IANA assigned Well Known Port for the
'ipp' scheme. 'ipp' scheme.
The client MUST use the target http-URL in both the HTTP Request-Line The client MUST use the target http-URL in both the HTTP Request-Line
and HTTP headers, as specified by HTTP[RFC2068][RFC2069] . However, the and HTTP headers, as specified by HTTP[RFC2616][RFC2617] . However, the
client MUST use the target ipp-URL for the value of the "printer-uri" or client MUST use the target ipp-URL for the value of the "printer-uri" or
"job-uri" operation attribute within the application/ipp body of the "job-uri" operation attribute within the application/ipp body of the
request. The server MUST use the ipp-URL for the value of the "printer- request. The server MUST use the ipp-URL for the value of the "printer-
uri", "job-uri" or "printer-uri-supported" attributes within the uri", "job-uri" or "printer-uri-supported" attributes within the
application/ipp body of the response. application/ipp body of the response.
For example, when an IPP client sends a request directly (i.e. no proxy) For example, when an IPP client sends a request directly (i.e. no proxy)
to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a TCP to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a TCP
connection to port 631 (the ipp implicit port) on the host "myhost.com" connection to port 631 (the ipp implicit port) on the host "myhost.com"
and sends the following data: and sends the following data:
skipping to change at page 20, line 14 skipping to change at page 20, line 14
6.1 Security Conformance Requirements 6.1 Security Conformance Requirements
This section defines the security requirements for IPP clients and IPP This section defines the security requirements for IPP clients and IPP
objects. objects.
6.1.1 Digest Authentication 6.1.1 Digest Authentication
IPP clients MUST support: IPP clients MUST support:
Digest Authentication [RFC2069]. Digest Authentication [RFC2617].
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: IPP Printers SHOULD support:
Digest Authentication [RFC2069]. Digest Authentication [RFC2617].
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.
The reasons that IPP Printers SHOULD (rather than MUST) support Digest The reasons that IPP Printers SHOULD (rather than MUST) support Digest
Authentication are: Authentication are:
1.While Client Authentication is important, there is a certain class of 1.While Client Authentication is important, there is a certain class of
printer devices where it does not make sense. Specifically, a low- printer devices where it does not make sense. Specifically, a low-
skipping to change at page 21, line 7 skipping to change at page 21, line 7
6.1.2 Transport Layer Security (TLS) 6.1.2 Transport Layer Security (TLS)
IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246] for IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246] for
Server Authentication and Operation Privacy. IPP Printers MAY also Server Authentication and Operation Privacy. IPP Printers MAY also
support TLS for Client Authentication. If an IPP Printer supports TLS, 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 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. mandated by RFC 2246 [RFC2246]. All other cipher suites are OPTIONAL.
An IPP Printer MAY support Basic Authentication (described in HTTP/1.1 An IPP Printer MAY support Basic Authentication (described in HTTP/1.1
[RFC2068]) for Client Authentication if the channel is secure. TLS with [RFC2617]) for Client Authentication if the channel is secure. TLS with
the above mandated cipher suite can provide such a secure channel. the above mandated cipher suite can provide such a secure channel.
If a IPP client supports TLS, it MUST support the 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 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246
[RFC2246]. All other cipher suites are OPTIONAL. [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 itself. For backward compatibility with IPP version 1.0, IPP protocol itself. For backward compatibility with IPP version 1.0,
IPP clients and printers MAY also support SSL3. This is in addition to IPP clients and printers may also support SSL3. This is in addition to
the security required in this document. the security required in this document.
6.2 Using IPP with TLS 6.2 Using IPP with TLS
An initial IPP request never uses TLS. The switch to TLS occurs either IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism [http-
because the server grants the client's request to upgrade to TLS, or a tls]. An initial IPP request never uses TLS. The client requests a
secure TLS connection by using the HTTP .Upgrade. header, while the
server agrees in the HTTP response. The switch to TLS occurs either
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.
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)
to establish a secure connection before sending any sensitive data.
During the TLS handshake, the original session is preserved.
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.
"Upgrade: TLS/1.0" (see rfc2068 section 14.42). If the origin-server
grants the upgrade request, it MUST respond with "101 Switching
Protocols", and it MUST include the header "Upgrade: TLS/1.0" to
indicate what it is switching to. An IPP client MUST be ready to react
appropriately if the server does not grant the upgrade request. Note:
the 'Upgrade header' mechanism allows unsecured and secured traffic to
share the same port (in this case, 631).
With current technology, an IPP server can indicate that it wants an
upgrade only by returning "401 unauthorized" or "403 forbidden". A
server MAY give the client an additional hint by including an "Upgrade:
TLS" header in the response. When an IPP client receives such a
response, it can perform the request again with an Upgrade header with
the "TLS/1.0" value.
If a server supports TLS, it SHOULD include the "Upgrade" header with
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 7. Interoperability with IPP/1.0 Implementations
intervening proxy which supports TLS MUST also request the same version
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
requested (although clients are still recommended to explicitly include It is beyond the scope of this specification to mandate conformance with
"Cache-control: no-cache"). previous versions. IPP/1.1 was deliberately designed, however, to make
supporting previous versions easy. It is worth noting that, at the time
of composing this specification (1999), we would expect IPP/1.1 Printer
implementations to:
Note: proxy servers may be able to request or initiate a TLS-secured understand any valid request in the format of IPP/1.0, or 1.1;
connection, e.g. the outgoing or incoming firewall of a trusted
subnetwork.
7. Interoperability with IPP/1.0 Implementations respond appropriately with a response containing the same "version-
number" parameter value used by the client in the request.
For interoperability with IPP/1.0 servers, IPP/1.1 clients SHOULD also And we would expect IPP/1.1 clients to:
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 understand any valid response in the format of IPP/1.0, or 1.1.
meet the conformance requirements for IPP objects as specified in
[RFC2565] and [RFC2566].
7.1 The "version-number" Parameter 7.1 The "version-number" Parameter
The following are rules regarding the "version-number" parameter (see The following are rules regarding the "version-number" parameter (see
section 3.3): section 3.3):
1. Clients MUST send requests containing a "version-number" parameter 1. Clients MUST send requests containing a "version-number" parameter
with a '1.1' value and SHOULD try supplying alternate version with a '1.1' value and SHOULD try supplying alternate version
numbers if they receive a 'server-error-version-not-supported' numbers if they receive a 'server-error-version-not-supported'
error return in a response. error return in a response.
2. IPP objects MUST accept requests containing a "version-number" 2. IPP objects MUST accept requests containing a "version-number"
parameter with a '1.1' value (or reject the request for reasons parameter with a '1.1' value (or reject the request for reasons
other than 'server-error-version-not-supported'). other than 'server-error-version-not-supported').
3. IPP objects SHOULD accept any request with the major version '1' 3. It is recommended that IPP objects accept any request with the
(or reject the request for reasons other than 'server-error- major version '1' (or reject the request for reasons other than
version-not-supported'). See [ipp-mod] "versions" sub-section. 'server-error-version-not-supported'). See [ipp-mod] "versions"
sub-section.
4. In any case, security MUST NOT be compromised when a client 4. In any case, security MUST NOT be compromised when a client
supplies a lower "version-number" parameter in a request. For supplies a lower "version-number" parameter in a request. For
example, if an IPP/1.1 conforming Printer object accepts version example, if an IPP/1.1 conforming Printer object accepts version
'1.0' requests and is configured to enforce Digest Authentication, '1.0' requests and is configured to enforce Digest Authentication,
it MUST do the same for a version '1.0' request. it MUST do the same for a version '1.0' request.
7.2 Security and URL Schemes 7.2 Security and URL Schemes
The following are rules regarding security, the "version-number" The following are rules regarding security, the "version-number"
skipping to change at page 23, line 16 skipping to change at page 22, line 47
Description attributes, it SHOULD return the same scheme ('ipp', Description attributes, it SHOULD return the same scheme ('ipp',
'https', 'http', etc.) that the client supplied in the "printer- 'https', 'http', etc.) that the client supplied in the "printer-
uri" or "job-uri" target operation attributes in the Get-Job- uri" or "job-uri" target operation attributes in the Get-Job-
Attributes or Get-Jobs request, rather than the scheme used when Attributes or Get-Jobs request, rather than the scheme used when
the job was created. However, when a client requests job the job was created. However, when a client requests job
attributes using the Get-Job-Attributes or Get-Jobs operations, the attributes using the Get-Job-Attributes or Get-Jobs operations, the
jobs and job attributes that the server returns depends on: (1) 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 security in effect when the job was created, (2) the security in
effect in the query request, and (3) the security policy in force. 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 3. It is recommended that if a server registers a non-secure ipp-URL
(see [IPP-MOD] "Generic Directory Schema" Appendix), then it SHOULD with a directory service (see [IPP-MOD] "Generic Directory Schema"
also register an http-URL for interoperability with IPP/1.0 clients Appendix), then it also register an http-URL for interoperability
(see section 7). with IPP/1.0 clients (see section 7).
4. In any case, security MUST NOT be compromised when a client 4. In any case, security MUST NOT be compromised when a client
supplies an 'http' or other non-secure URL scheme in the target supplies an 'http' or other non-secure URL scheme in the target
"printer-uri" and "job-uri" operation attributes in a request. "printer-uri" and "job-uri" operation attributes in a request.
8. References 8. References
[dpa] ISO/IEC 10175 Document Printing Application (DPA), June 1996. [dpa] ISO/IEC 10175 Document Printing Application (DPA), June 1996.
[http-tls]R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1",
<draft-ietf-tls-http-upgrade-02>, June 1999.
[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", work in progress. Implementer's Guide", work in progress.
[ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, [ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
"Internet Printing Protocol/1.0: Model and Semantics", <draft- "Internet Printing Protocol/1.0: Model and Semantics", <draft-
ietf-ipp-model-v11-03.txt>, June, 1999. ietf-ipp-model-v11-03.txt>, June, 1999.
skipping to change at page 24, line 25 skipping to change at page 24, line 9
Simple Network Management Protocol (SNMPv2)", RFC 1903, January Simple Network Management Protocol (SNMPv2)", RFC 1903, 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 Mail [RFC2048] N. Freed, J. Klensin & J. Postel. Multipurpose Internet Mail
Extension (MIME) Part Four: Registration Procedures. November Extension (MIME) Part Four: Registration Procedures. November
1996 (Also BCP0013), RFC 2048. 1996 (Also BCP0013), RFC 2048.
[RFC2068] R Fielding, et al, "Hypertext Transfer Protocol . HTTP/1.1"
RFC 2068, January 1997.
[RFC2069] J. Franks, et al, "An Extension to HTTP: Digest Access
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 Word [RFC2184] N. Freed, K. Moore, "MIME Parameter Value and Encoded Word
Extensions: Character Sets, Languages, and Continuations", RFC Extensions: Character Sets, Languages, and Continuations", RFC
2184, August 1997. 2184, August 1997.
[RFC2234] D. Crocker et al., "Augmented BNF for Syntax Specifications: [RFC2234] D. Crocker et al., "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234. November 1997. ABNF", RFC 2234. November 1997.
skipping to change at page 25, line 11 skipping to change at page 24, line 42
[RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", [RFC2567] Wright, D., "Design Goals for an Internet Printing 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 1999. Protocol for the Internet Printing Protocol", RC 2568,April 1999.
[RFC2569] Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping [RFC2569] Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping
between LPD and IPP Protocols RFC 2569, April 1999. between LPD and IPP Protocols RFC 2569, April 1999.
[RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
RFC 2616, June 1999.
[RFC2069] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P.
Leach, A. Luotonen, L. Stewart, "HTTP Authentication: Basic and
Digest Access Authentication", RFC 2617, June 1999.
9. Author's Address 9. Author's Address
Robert Herriot (editor) Paul Moore Robert Herriot (editor) Paul Moore
Xerox Corporation Microsoft Xerox Corporation Microsoft
3400 Hillview Ave., Bldg #1 One Microsoft Way 3400 Hillview Ave., Bldg #1 One Microsoft Way
Palo Alto, CA 94304 Redmond, WA 98053 Palo Alto, CA 94304 Redmond, WA 98053
Phone: 650-813-7696 Phone: 425-936-0908 Phone: 650-813-7696 Phone: 425-936-0908
Fax: 650-813-6860 Fax: 425-93MS-FAX Fax: 650-813-6860 Fax: 425-93MS-FAX
Email: Email: paulmo@microsoft.com Email: Email: paulmo@microsoft.com
skipping to change at page 39, line 8 skipping to change at page 39, line 8
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.Clients MUST support of Digest Authentication, IPP Printers SHOULD 2.Clients MUST support of Digest Authentication, IPP Printers SHOULD
support Digest Authentication. See Section 6.1.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 6.1.2 supported for backward compatibility. See Section 6.1.2
4.For interoperability with IPP/1.0, IPP/1.1 Clients SHOULD support 4.It is recommended that IPP/1.1 objects accept any request with major
IPP/1.0 conformance requirements. IPP/1.1 Printers SHOULD support version number '1'. See section 7.1.
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- 5.IPP objects SHOULD return the URL scheme requested for "job-printer-
uri" and "job-uri" Job Attributes, rather than the URL scheme used to uri" and "job-uri" Job Attributes, rather than the URL scheme used to
create the job. See section 7.2 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
 End of changes. 

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