draft-ietf-ipp-protocol-v11-04.txt   draft-ietf-ipp-protocol-v11-05.txt 
INTERNET-DRAFT Robert Herriot (editor) INTERNET-DRAFT Robert Herriot (editor)
<draft-ietf-ipp-protocol-v11-04.txt> Xerox Corporation <draft-ietf-ipp-protocol-v11-05.txt> Xerox Corporation
Sylvan Butler Sylvan Butler
Hewlett-Packard Hewlett-Packard
Paul Moore Paul Moore
Peerless Systems Networking Peerless Systems Networking
Randy Turner Randy Turner
2wire.com 2wire.com
John Wenn John Wenn
Xerox Corporation Xerox Corporation
February 23, 2000 March 1, 2000
Internet Printing Protocol/1.1: Encoding and Transport Internet Printing Protocol/1.1: Encoding and Transport
Copyright (C)The Internet Society (2000). All Rights Reserved. Copyright (C)The Internet Society (2000). All Rights Reserved.
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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
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..............................................11 3.7.2 Value Tags..............................................11
3.8 Name-Length...................................................13 3.8 Name-Length...................................................13
3.9 (Attribute) Name..............................................13 3.9 (Attribute) Name..............................................13
3.10Value Length..................................................15 3.10Value Length..................................................15
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........................................18
5. IPP URL Scheme.....................................................18 5. IPP URL Scheme.....................................................18
6. IANA Considerations................................................19 6. IANA Considerations................................................20
7. Internationalization Considerations................................20 7. Internationalization Considerations................................20
8. Security Considerations............................................20 8. Security Considerations............................................21
8.1 Security Conformance Requirements.............................20 8.1 Security Conformance Requirements.............................21
8.1.1 Digest Authentication...................................20 8.1.1 Digest Authentication...................................21
8.1.2 Transport Layer Security (TLS)..........................21 8.1.2 Transport Layer Security (TLS)..........................22
8.2 Using IPP with TLS............................................22 8.2 Using IPP with TLS............................................22
9. Interoperability with IPP/1.0 Implementations......................22 9. Interoperability with IPP/1.0 Implementations......................22
9.1 The "version-number" Parameter................................22 9.1 The "version-number" Parameter................................23
9.2 Security and URL Schemes......................................23 9.2 Security and URL Schemes......................................23
10.References........................................................23 10.References........................................................24
11.Author's Address..................................................25 11.Author's Address..................................................26
12.Other Participants:...............................................27 12.Other Participants:...............................................27
13.Appendix A: Protocol Examples.....................................28 13.Appendix A: Protocol Examples.....................................29
13.1Print-Job Request.............................................28 13.1Print-Job Request.............................................29
13.2Print-Job Response (successful)...............................29 13.2Print-Job Response (successful)...............................31
13.3Print-Job Response (failure)..................................30 13.3Print-Job Response (failure)..................................32
13.4Print-Job Response (success with attributes ignored)..........31 13.4Print-Job Response (success with attributes ignored)..........33
13.5Print-URI Request.............................................34 13.5Print-URI Request.............................................36
13.6Create-Job Request............................................35 13.6Create-Job Request............................................37
13.7Get-Jobs Request..............................................36 13.7Get-Jobs Request..............................................38
13.8Get-Jobs Response.............................................37 13.8Get-Jobs Response.............................................39
14.Appendix B: Registration of MIME Media Type Information for 14.Appendix B: Registration of MIME Media Type Information for
"application/ipp".....................................................39 "application/ipp".....................................................41
15.Appendix C: Changes from IPP/1.0..................................40 15.Appendix C: Changes from IPP/1.0..................................42
16.Full Copyright Statement..........................................41 16.Full Copyright Statement..........................................43
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
2616 [RFC2616] 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.
skipping to change at page 10, line 52 skipping to change at page 10, line 52
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 "Operation Requests and Responses" and further details, see section 3.9 "(Attribute) Name" and 13 "Appendix A:
13 "Appendix A: Protocol Examples". 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 13, line 18 skipping to change at page 13, line 18
specify the number of octets in the name field which follows the name- specify the number of octets in the name field which follows the name-
length field, excluding the two bytes of the name-length field. length field, excluding the two bytes of the name-length field.
If a name-length field has a value of zero, the following name field If a name-length field has a value of zero, the following name field
MUST be empty, and the following value MUST be treated as an additional MUST be empty, and the following value MUST be treated as an additional
value for the preceding attribute. Within an attribute-sequence, if two value for the preceding attribute. Within an attribute-sequence, if two
or more attributes have the same name, the attribute-sequence is mal- or more attributes have the same name, the attribute-sequence is mal-
formed (see [ipp-mod] section 3.1.3). The zero-length name is the only formed (see [ipp-mod] section 3.1.3). The zero-length name is the only
mechanism for multi-valued attributes. mechanism for multi-valued attributes.
3.9 Operation Requests and Responses 3.9 (Attribute) Name
Some operation elements are called parameters in the model document Some operation elements are called parameters in the model document
[ipp-mod]. They MUST be encoded in a special position and they MUST NOT [ipp-mod]. They MUST be encoded in a special position and they MUST NOT
appear as an operation attributes. These parameters are: appear as operation attributes. These parameters are:
- "version-number": The parameter named "version-number" in the IPP - "version-number": The parameter named "version-number" in the IPP
model document MUST become the "version-number" field in the model document MUST become the "version-number" field in the
operation layer request or response. operation layer request or response.
- "operation-id": The parameter named "operation-id" in the IPP model - "operation-id": The parameter named "operation-id" in the IPP model
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
skipping to change at page 15, line 23 skipping to change at page 15, line 23
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.
For any of the types represented by character-strings, the sender MUST For any of the types represented by character-strings, the sender MUST
encode the value with all the characters of the string and without any encode the value with all the characters of the string and without any
padding characters. padding characters.
If a value-tag contains an "out-of-band" value, such as "unsupported", If a value-tag contains an "out-of-band" value defined in this document,
the value-length MUST be 0 and the value empty ¨ the value has no such as "unsupported", the value-length MUST be 0 and the value empty;
meaning when the value-tag has an "out-of-band" value. the value has no meaning when the value-tag has one of these "out-of-
band" values. However, the definitions of additional "out-of-band"
values in future documents are able to explicitly use the value field
and have a value-length that is non-zero, if there is a need for
additional information to be associated with the out-of-band value.
Unless the definition of an "out-of-band" value explicitly allows for a
value, the value-length MUST be 0 and the value empty.
3.11 Attribute Value 3.11 (Attribute) Value
The syntax types and most of the details of the representation of The syntax types and most of the details of the representation of
attribute values are defined in the IPP model document. The table below attribute values are defined in the IPP model document. The table below
augments the information in the model document, and defines the syntax augments the information in the model document, and defines the syntax
types from the model document in terms of the 5 basic types defined in types from the model document in terms of the 5 basic types defined in
section 3 "Encoding of the Operation Layer". The 5 types are US-ASCII- section 3 "Encoding of the Operation Layer". The 5 types are US-ASCII-
STRING, LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and STRING, LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and
OCTET-STRING. OCTET-STRING.
Syntax of Attribute Encoding Syntax of Attribute Encoding
Value Value
textWithoutLanguage, LOCALIZED-STRING. textWithoutLanguage, LOCALIZED-STRING.
nameWithoutLanguage nameWithoutLanguage
textWithLanguage OCTET_STRING consisting of 4 fields: textWithLanguage OCTET_STRING consisting of 4 fields:
a) a. a SIGNED-SHORT which is the number of
a SIGNED-SHORT which is the number of octets octets in the following field
in the following field b a value of type natural-language,
b) c. a SIGNED-SHORT which is the number of
a value of type natural-language, octets in the following field,
c) d. a value of type textWithoutLanguage.
a SIGNED-SHORT which is the number of octets
in the following field,
d)
a value of type textWithoutLanguage.
The length of a textWithLanguage value MUST be 4 The length of a textWithLanguage value MUST be 4
+ the value of field a + the value of field c. + the value of field a + the value of field c.
nameWithLanguage OCTET_STRING consisting of 4 fields: nameWithLanguage OCTET_STRING consisting of 4 fields:
a) a. a SIGNED-SHORT which is the number of
a SIGNED-SHORT which is the number of octets octets in the following field
in the following field b. a value of type natural-language,
b) c. a SIGNED-SHORT which is the number of
a value of type natural-language, octets in the following field
c) d. a value of type nameWithoutLanguage.
a SIGNED-SHORT which is the number of octets
in the following field
d)
a value of type nameWithoutLanguage.
The length of a nameWithLanguage value MUST be 4 The length of a nameWithLanguage value MUST be 4
+ the value of field a + the value of field c. + the value of field a + the value of field c.
charset, US-ASCII-STRING. charset, US-ASCII-STRING.
naturalLanguage, naturalLanguage,
mimeMediaType, mimeMediaType,
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
skipping to change at page 18, line 56 skipping to change at page 19, line 41
If a printer registers its URL with a directory service, the printer If a printer registers its URL with a directory service, the printer
MUST register an ipp-URL. MUST register an ipp-URL.
User interfaces are beyond the scope of this document. But if software User interfaces are beyond the scope of this document. But if software
exposes the ipp-URL values of any of the above five attributes to a exposes the ipp-URL values of any of the above five attributes to a
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. 1. change the 'ipp' scheme to 'http'
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[RFC2616][RFC2617] . 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.
skipping to change at page 20, line 20 skipping to change at page 20, line 55
These extension procedures are aligned with the guidelines as set forth These extension procedures are aligned with the guidelines as set forth
by the IESG [IANA-CON]. The [ipp-mod] Section 11 describes how to by the IESG [IANA-CON]. The [ipp-mod] Section 11 describes how to
propose new registrations for consideration. IANA will reject propose new registrations for consideration. IANA will reject
registration proposals that leave out required information or do not registration proposals that leave out required information or do not
follow the appropriate format described in [ipp-mod] Section 11. The follow the appropriate format described in [ipp-mod] Section 11. The
IPP/1.1 Encoding and Transport document may also be extended by an IPP/1.1 Encoding and Transport document may also be extended by an
appropriate RFC that specifies any of the above extensions. appropriate RFC that specifies any of the above extensions.
7. Internationalization Considerations 7. Internationalization Considerations
See the section on ˘Internationalization Considerations÷ in the document See the section on "Internationalization Considerations" in the document
"Internet Printing Protocol/1.1: Model and Semantics" [ipp-mod] for "Internet Printing Protocol/1.1: Model and Semantics" [ipp-mod] for
information on internationalization. This document adds no additional information on internationalization. This document adds no additional
issues. issues.
8. Security Considerations 8. 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
skipping to change at page 21, line 10 skipping to change at page 21, line 44
Digest Authentication [RFC2617]. 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. 1.While Client Authentication is important, there is a certain class of
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-
end device with limited ROM space and low paper throughput may not end device with limited ROM space and low paper throughput may not
need Client Authentication. This class of device typically requires need Client Authentication. This class of device typically requires
firmware designers to make trade-offs between protocols and firmware designers to make trade-offs between protocols and
functionality to arrive at the lowest-cost solution possible. functionality to arrive at the lowest-cost solution possible.
Factored into the designerĂs decisions is not just the size of the Factored into the designer's decisions is not just the size of the
code, but also the testing, maintenance, usefulness, and time-to- code, but also the testing, maintenance, usefulness, and time-to-
market impact for each feature delivered to the customer. Forcing market impact for each feature delivered to the customer. Forcing
such low-end devices to provide security in order to claim IPP/1.1 such low-end devices to provide security in order to claim IPP/1.1
conformance would not make business sense and could potentially stall conformance would not make business sense and could potentially stall
the adoption of the standard. the adoption of the standard.
2. 2.Print devices that have high-volume throughput and have available ROM
Print devices that have high-volume throughput and have available ROM
space have a compelling argument to provide support for Client space have a compelling argument to provide support for Client
Authentication that safeguards the device from unauthorized access. Authentication that safeguards the device from unauthorized access.
These devices are prone to a high loss of consumables and paper if These devices are prone to a high loss of consumables and paper if
unauthorized access should occur. unauthorized access should occur.
8.1.2 Transport Layer Security (TLS) 8.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,
skipping to change at page 22, line 9 skipping to change at page 22, line 41
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 [ssl]. This is in IPP clients and printers may also support SSL3 [ssl]. This is in
addition to the security required in this document. addition to the security required in this document.
8.2 Using IPP with TLS 8.2 Using IPP with TLS
IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism [http- IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism [http-
tls]. An initial IPP request never uses TLS. The client requests a tls]. An initial IPP request never uses TLS. The client requests a
secure TLS connection by using the HTTP ˘Upgrade÷ header, while the secure TLS connection by using the HTTP "Upgrade" header, while the
server agrees in the HTTP response. The switch to TLS occurs either 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 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. begins with a server's response to switch to TLS.
9. Interoperability with IPP/1.0 Implementations 9. Interoperability with IPP/1.0 Implementations
It is beyond the scope of this specification to mandate conformance with It is beyond the scope of this specification to mandate conformance with
previous versions. IPP/1.1 was deliberately designed, however, to make previous versions. IPP/1.1 was deliberately designed, however, to make
supporting previous versions easy. It is worth noting that, at the time supporting previous versions easy. It is worth noting that, at the time
of composing this specification (1999), we would expect IPP/1.1 Printer of composing this specification (1999), we would expect IPP/1.1 Printer
implementations to: implementations to:
understand any valid request in the format of IPP/1.0, or 1.1; understand any valid request in the format of IPP/1.0, or 1.1;
skipping to change at page 22, line 37 skipping to change at page 23, line 19
And we would expect IPP/1.1 clients to: And we would expect IPP/1.1 clients to:
understand any valid response in the format of IPP/1.0, or 1.1. understand any valid response in the format of IPP/1.0, or 1.1.
9.1 The "version-number" Parameter 9.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. 1. Clients MUST send requests containing a "version-number" parameter
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. 2. IPP objects MUST accept requests containing a "version-number"
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. 3. It is recommended that IPP objects accept any request with the
It is recommended that IPP objects accept any request with the
major version '1' (or reject the request for reasons other than major version '1' (or reject the request for reasons other than
'server-error-version-not-supported'). See [ipp-mod] "versions" 'server-error-version-not-supported'). See [ipp-mod] "versions"
sub-section. sub-section.
4. 4. In any case, security MUST NOT be compromised when a client
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.
9.2 Security and URL Schemes 9.2 Security and URL Schemes
The following are rules regarding security, the "version-number" The following are rules regarding security, the "version-number"
parameter, and the URL scheme supplied in target attributes and parameter, and the URL scheme supplied in target attributes and
responses: responses:
1. 1. When a client supplies a request, the "printer-uri" or "job-uri"
When a client supplies a request, the "printer-uri" or "job-uri"
target operation attribute MUST have the same scheme as that target operation attribute MUST have the same scheme as that
indicated in one of the values of the "printer-uri-supported" indicated in one of the values of the "printer-uri-supported"
Printer attribute. Printer attribute.
2. 2. When the server returns the "job-printer-uri" or "job-uri" Job
When the server returns the "job-printer-uri" or "job-uri" Job
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,
jobs and job attributes that the server returns depends on: (1) the the jobs and job attributes that the server returns depends on:
security in effect when the job was created, (2) the security in (1) the security in effect when the job was created, (2) the
effect in the query request, and (3) the security policy in force. security in effect in the query request, and (3) the security
policy in force.
3. 3. It is recommended that if a server registers a non-secure ipp-URL
It is recommended that if a server registers a non-secure ipp-URL
with a directory service (see [IPP-MOD] "Generic Directory Schema" with a directory service (see [IPP-MOD] "Generic Directory Schema"
Appendix), then it also register an http-URL for interoperability Appendix), then it also register an http-URL for interoperability
with IPP/1.0 clients (see section 9). with IPP/1.0 clients (see section 9).
4. 4. In any case, security MUST NOT be compromised when a client
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.
10. References 10. 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", [http-tls]R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1",
<draft-ietf-tls-http-upgrade-02>, June 1999. <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", draft-ietf-ipp-implementers-guide-v11- Implementer's Guide", draft-ietf-ipp-implementers-guide-v11-
00.txt, work in progress, September 27, 1999. 00.txt, work in progress, September 27, 1999.
[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.1: Model and Semantics", <draft- "Internet Printing Protocol/1.1: Model and Semantics", <draft-
ietf-ipp-model-v11-05.txt>, February 23, 2000. ietf-ipp-model-v11-06.txt>, March 1, 2000.
[ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet [ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet
Printing Protocol/1.1: Encoding and Transport", draft-ietf-ipp- Printing Protocol/1.1: Encoding and Transport", draft-ietf-ipp-
protocol-v11-04-.txt, February 23, 2000. protocol-v11-05.txt, March 1, 2000.
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", RFC 822, August 1982. Messages", RFC 822, August 1982.
[RFC1123] Braden, S., "Requirements for Internet Hosts - Application [RFC1123] Braden, S., "Requirements for Internet Hosts - Application
and Support", RFC 1123, October, 1989. and Support", RFC 1123, October, 1989.
[RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" [RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol"
RFC 1179, August 1990. RFC 1179, August 1990.
skipping to change at page 25, line 6 skipping to change at page 25, line 43
[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., "Internet [RFC2565] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet
Printing Protocol/1.0: Encoding and Transport", RFC 2565, April Printing Protocol/1.0: Encoding and Transport", RFC 2565, April
1999. 1999.
[RFC2566] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, [RFC2566] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
"Internet Printing Protocol/1.0: Model and Semantics", rfc 2566, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
April, 1999. April, 1999.
[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 Protocol for the Internet Printing Protocol", RC 2568, April
1999. 1999.
[RFC2569] Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping [RFC2569] Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping
skipping to change at page 40, line 7 skipping to change at page 42, line 7
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 specifications: 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-05.txt, February 23, 2000. Semantics" draft-ietf-ipp-model-v11-06.txt, March 1, 2000.
[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-04.txt, February 23, 2000. ietf-ipp-protocol-v11-05.txt, March 1, 2000.
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:
skipping to change at page 40, line 51 skipping to change at page 42, line 51
Email: robert.herriot@pahv.xerox.com Email: robert.herriot@pahv.xerox.com
Intended usage: Intended usage:
COMMON COMMON
15. Appendix C: Changes from IPP/1.0 15. Appendix C: Changes from IPP/1.0
IPP/1.1 is identical to IPP/1.0 [RFC2565] with the follow changes: IPP/1.1 is identical to IPP/1.0 [RFC2565] with the follow changes:
1. 1.Attributes values that identify a printer or job object use a new
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. 2.Clients MUST support of Digest Authentication, IPP Printers SHOULD
Clients MUST support of Digest Authentication, IPP Printers SHOULD
support Digest Authentication. See Section 8.1.1 support Digest Authentication. See Section 8.1.1
3. 3.TLS is recommended for channel security. In addition, SSL3 may be
TLS is recommended for channel security. In addition, SSL3 may be
supported for backward compatibility. See Section 8.1.2 supported for backward compatibility. See Section 8.1.2
4. 4.It is recommended that IPP/1.1 objects accept any request with major
It is recommended that IPP/1.1 objects accept any request with major
version number '1'. See section 9.1. version number '1'. See section 9.1.
5. 5.IPP objects SHOULD return the URL scheme requested for "job-printer-
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 9.2. create the job. See section 9.2.
6. 6.The IANA and Internationalization sections have been added. The
The IANA and Internationalization sections have been added. The
terms "private use" and "experimental" have been changed to "vendor terms "private use" and "experimental" have been changed to "vendor
extension". The reserved allocations for attribute group tags, extension". The reserved allocations for attribute group tags,
attribute syntax tags, and out-of-band attribute values have been attribute syntax tags, and out-of-band attribute values have been
clarified as to which are reserved to future IETF standards track clarified as to which are reserved to future IETF standards track
documents and which are reserved to vendor extension. Both kinds of documents and which are reserved to vendor extension. Both kinds of
extensions use the type2 registration procedures as defined in [ipp- extensions use the type2 registration procedures as defined in [ipp-
mod]. mod].
7.Clarified that future "out-of-band" value definitions may use the
value field if additional information is needed.
16. Full Copyright Statement 16. 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-
related documentation can be found in BCP-11[BCP-11]. Copies of claims related documentation can be found in BCP-11[BCP-11]. Copies of claims
skipping to change at page 41, line 50 skipping to change at page 43, line 49
general license or permission for the use of such proprietary rights by general license or permission for the use of such proprietary rights by
implementers or users of this specification can be obtained from the implementers or users of this specification can be obtained from the
IETF Secretariat. IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive standard. Please address the information to the IETF Executive
Director. Director.
Copyright (C)The Internet Society (1999). All Rights Reserved Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations, or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into Standards process must be followed, or as required to translate it into
languages other than English. languages other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
 End of changes. 

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