draft-ietf-ipp-protocol-v11-00.txt   draft-ietf-ipp-protocol-v11-01.txt 
INTERNET-DRAFT Robert Herriot (editor) INTERNET-DRAFT Robert Herriot (editor)
Xerox Corporation Xerox Corporation
<draft-ietf-ipp-protocol-v11-00.txt> Sylvan Butler <draft-ietf-ipp-protocol-v11-01.txt> Sylvan Butler
Hewlett-Packard Hewlett-Packard
Paul Moore Paul Moore
Microsoft Microsoft
Randy Turner Randy Turner
Sharp Labs 2wire.com
John Wenn John Wenn
Xerox Corporation Xerox Corporation
February 17, 1998 May 10, 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 51 skipping to change at page 1, line 50
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. Finally, this document defines rules
for supporting IPP/1.0 clients for supporting IPP/1.0 Clients and Printers.
Moore, Turner and Wenn Expires August 17, 1999
The full set of IPP documents includes: The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [ipp-req] 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 [ipp-rat] 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 [ipp-lpd] 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. Operator and administrator requirements are out of
scope for version 1.1. scope for version 1.1.
skipping to change at page 3, line 5 skipping to change at page 3, line 5
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.
Moore , Turner and Wenn Expires August 17, 1999
Table of Contents Table of Contents
1. Introduction.......................................................3 1. Introduction........................................................3
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.......................................4 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...................................................8 3.5 Status-code...................................................9
3.6 Request-id....................................................8 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..............................................10
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.10 Value Length.................................................14
3.11 (Attribute) Value............................................14 3.11 (Attribute) Value............................................14
3.12 Data.........................................................15 3.12 Data.........................................................16
4. Encoding of Transport Layer.......................................16 4. Encoding of Transport Layer........................................16
5. IPP URL Scheme....................................................16 5. IPP URL Scheme.....................................................17
6. Compatibility with IPP/1.0 Implementations........................18 6. Compatibility with IPP/1.0 Implementations.........................18
7. Security Considerations...........................................19 7. Security Considerations............................................20
7.1 Using IPP with TLS...........................................19 7.1 Security Conformance.........................................20
8. References........................................................20 7.2 Using IPP with TLS...........................................20
9. Author's Address..................................................22 8. References.........................................................21
10.Other Participants:...............................................23 9. Author's Address...................................................23
11.Appendix A: Protocol Examples.....................................23 10.Other Participants:...............................................24
11.1 Print-Job Request............................................23 11.Appendix A: Protocol Examples.....................................24
11.2 Print-Job Response (successful)..............................24 11.1 Print-Job Request............................................24
11.3 Print-Job Response (failure).................................25 11.2 Print-Job Response (successful)..............................26
11.4 Print-Job Response (success with attributes ignored).........26 11.3 Print-Job Response (failure).................................26
11.5 Print-URI Request............................................28 11.4 Print-Job Response (success with attributes ignored).........27
11.6 Create-Job Request...........................................29 11.5 Print-URI Request............................................29
11.7 Get-Jobs Request.............................................29 11.6 Create-Job Request...........................................30
11.8 Get-Jobs Response............................................30 11.7 Get-Jobs Request.............................................30
11.8 Get-Jobs Response............................................31
12.Appendix C: Registration of MIME Media Type Information for 12.Appendix C: Registration of MIME Media Type Information for
"application/ipp"....................................................31 "application/ipp".....................................................32
13.Appendix D: Notices...............................................33 13.Appendix D: Changes from IPP /1.0.................................34
14.Appendix E: Changes from IPP /1.0.................................34 14.Full Copyright Statement..........................................34
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
Moore , Turner and Wenn Expires August 17, 1999
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
skipping to change at page 4, line 51 skipping to change at page 4, line 50
"network order" and "most significant byte first"). The number of octets "network order" and "most significant byte first"). The number of octets
for an integer MUST be 1, 2 or 4, depending on usage in the protocol. for an integer MUST be 1, 2 or 4, depending on usage in the protocol.
Such one-octet integers, henceforth called SIGNED-BYTE, are used for the Such one-octet integers, henceforth called SIGNED-BYTE, are used for the
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:
Moore , Turner and Wenn Expires August 17, 1999
----------------------------------------------- -----------------------------------------------
| version-number | 2 bytes - required | version-number | 2 bytes - required
----------------------------------------------- -----------------------------------------------
| operation-id (request) | | operation-id (request) |
| or | 2 bytes - required | or | 2 bytes - required
| status-code (response) | | status-code (response) |
----------------------------------------------- -----------------------------------------------
| request-id | 4 bytes - required | request-id | 4 bytes - required
----------------------------------------------------------- -----------------------------------------------------------
| xxx-attributes-tag | 1 byte | | xxx-attributes-tag | 1 byte |
skipping to change at page 6, line 5 skipping to change at page 6, line 12
An xxx-attributes-sequence consists of zero or more compound-attributes. An xxx-attributes-sequence consists of zero or more compound-attributes.
----------------------------------------------- -----------------------------------------------
| compound-attribute | s bytes - 0 or more | compound-attribute | s bytes - 0 or more
----------------------------------------------- -----------------------------------------------
A compound-attribute consists of an attribute with a single value A compound-attribute consists of an attribute with a single value
followed by zero or more additional values. followed by zero or more additional values.
Moore , Turner and Wenn Expires August 17, 1999
Note: a 'compound-attribute' represents a single attribute in the model Note: a 'compound-attribute' represents a single attribute in the model
document. The 'additional value' syntax is for attributes with 2 or document. The 'additional value' syntax is for attributes with 2 or
more values. more values.
Each attribute consists of: Each attribute consists of:
----------------------------------------------- -----------------------------------------------
| value-tag | 1 byte | value-tag | 1 byte
----------------------------------------------- -----------------------------------------------
| name-length (value is u) | 2 bytes | name-length (value is u) | 2 bytes
skipping to change at page 7, line 5 skipping to change at page 7, line 25
----------------------------------------------- |-0 or more ----------------------------------------------- |-0 or more
| empty or rest of attribute | x bytes | | empty or rest of attribute | x bytes |
----------------------------------------------------------- -----------------------------------------------------------
| end-of-attributes-tag | 2 bytes - required | end-of-attributes-tag | 2 bytes - required
----------------------------------------------- -----------------------------------------------
| data | y bytes - optional | data | y bytes - optional
----------------------------------------------- -----------------------------------------------
The value of the tag determines whether the bytes following the tag are: The value of the tag determines whether the bytes following the tag are:
Moore , Turner and Wenn Expires August 17, 1999 - 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
skipping to change at page 8, line 4 skipping to change at page 8, line 28
zero-name-length = %x00.00 ; name-length of 0 zero-name-length = %x00.00 ; name-length of 0
operation-attributes-tag = %x01 ; tag of 1 operation-attributes-tag = %x01 ; tag of 1
job-attributes-tag = %x02 ; tag of 2 job-attributes-tag = %x02 ; tag of 2
printer-attributes-tag = %x04 ; tag of 4 printer-attributes-tag = %x04 ; tag of 4
unsupported- attributes-tag = %x05 ; tag of 5 unsupported- attributes-tag = %x05 ; tag of 5
end-of-attributes-tag = %x03 ; tag of 3 end-of-attributes-tag = %x03 ; tag of 3
value-tag = %x10-FF value-tag = %x10-FF
SIGNED-BYTE = BYTE SIGNED-BYTE = BYTE
SIGNED-SHORT = 2BYTE SIGNED-SHORT = 2BYTE
Moore , Turner and Wenn Expires August 17, 1999
SIGNED-INTEGER = 4BYTE SIGNED-INTEGER = 4BYTE
DIGIT = %x30-39 ; "0" to "9" DIGIT = %x30-39 ; "0" to "9"
LALPHA = %x61-7A ; "a" to "z" LALPHA = %x61-7A ; "a" to "z"
BYTE = %x00-FF BYTE = %x00-FF
OCTET-STRING = *BYTE OCTET-STRING = *BYTE
The syntax allows an xxx-attributes-tag to be present when the xxx- The syntax allows an xxx-attributes-tag to be present when the xxx-
attribute-sequence that follows is empty. The syntax is defined this way attribute-sequence that follows is empty. The syntax is defined this way
to allow for the response of Get-Jobs where no attributes are returned to allow for the response of Get-Jobs where no attributes are returned
for some job-objects. Although it is RECOMMENDED that the sender not for some job-objects. Although it is RECOMMENDED that the sender not
skipping to change at page 9, line 5 skipping to change at page 9, line 25
(successful-ok). With any other HTTP Status-Code value, the HTTP (successful-ok). With any other HTTP Status-Code value, the HTTP
response MUST NOT contain an IPP message-body, and thus no IPP status- response MUST NOT contain an IPP message-body, and thus no IPP status-
code is returned. code is returned.
3.6 Request-id 3.6 Request-id
The request-id allows a client to match a response with a request. This The request-id allows a client to match a response with a request. This
mechanism is unnecessary in HTTP, but may be useful when application/ipp mechanism is unnecessary in HTTP, but may be useful when application/ipp
entity bodies are used in another context. entity bodies are used in another context.
Moore , Turner and Wenn Expires August 17, 1999
The request-id in a response MUST be the value of the request-id The request-id in a response MUST be the value of the request-id
received in the corresponding request. A client can set the request-id received in the corresponding request. A client can set the request-id
in each request to a unique value or a constant value, such as 1, in each request to a unique value or a constant value, such as 1,
depending on what the client does with the request-id returned in the depending on what the client does with the request-id returned in the
response. The value of the request-id MUST be greater than zero. response. The value of the request-id MUST be greater than zero.
3.7 Tags 3.7 Tags
There are two kinds of tags: There are two kinds of tags:
@ delimiter tags: delimit major sections of the protocol, namely - delimiter tags: delimit major sections of the protocol, namely
attributes and data attributes and data
@ value tags: specify the type of each attribute value
- value tags: specify the type of each attribute value
3.7.1 Delimiter Tags 3.7.1 Delimiter Tags
The following table specifies the values for the delimiter tags: The following table specifies the values for the delimiter tags:
Tag Value (Hex) Delimiter Tag Value (Hex) Delimiter
0x00 reserved 0x00 reserved
0x01 operation-attributes-tag 0x01 operation-attributes-tag
0x02 job-attributes-tag 0x02 job-attributes-tag
skipping to change at page 10, line 4 skipping to change at page 10, line 27
When a printer-attributes-tag occurs in the protocol, it MUST mean that When a printer-attributes-tag occurs in the protocol, it MUST mean that
the zero or more following attributes up to the next delimiter tag are the zero or more following attributes up to the next delimiter tag are
printer attributes as defined in the model document. When an printer attributes as defined in the model document. When an
unsupported-attributes-tag occurs in the protocol, it MUST mean that the unsupported-attributes-tag occurs in the protocol, it MUST mean that the
zero or more following attributes up to the next delimiter tag are zero or more following attributes up to the next delimiter tag are
unsupported attributes as defined in the model document. unsupported attributes as defined in the model document.
The operation-attributes-tag and end-of-attributes-tag MUST each occur The operation-attributes-tag and end-of-attributes-tag MUST each occur
exactly once in an operation. The operation-attributes-tag MUST be the exactly once in an operation. The operation-attributes-tag MUST be the
first tag delimiter, and the end-of-attributes-tag MUST be the last tag first tag delimiter, and the end-of-attributes-tag MUST be the last tag
Moore , Turner and Wenn Expires August 17, 1999
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
skipping to change at page 10, line 38 skipping to change at page 11, line 4
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 11, line 5 skipping to change at page 11, line 28
The following table specifies the integer values for the value-tag: The following table specifies the integer values for the value-tag:
Tag Value (Hex) Meaning Tag Value (Hex) Meaning
0x20 reserved 0x20 reserved
0x21 integer 0x21 integer
0x22 boolean 0x22 boolean
0x23 enum 0x23 enum
0x24-0x2F reserved for future integer types 0x24-0x2F reserved for future integer types
Moore , Turner and Wenn Expires August 17, 1999
NOTE: 0x20 is reserved for "generic integer" if it should ever be NOTE: 0x20 is reserved for "generic integer" if it should ever be
needed. needed.
The following table specifies the octetString values for the value-tag: The following table specifies the octetString values for the value-tag:
Tag Value (Hex) Meaning Tag Value (Hex) Meaning
0x30 octetString with an unspecified format 0x30 octetString with an unspecified format
0x31 dateTime 0x31 dateTime
0x32 resolution 0x32 resolution
skipping to change at page 11, line 37 skipping to change at page 12, line 4
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 12, line 5 skipping to change at page 12, line 30
The tag 0x7F is reserved for extending types beyond the 255 values The tag 0x7F is reserved for extending types beyond the 255 values
available with a single byte. A tag value of 0x7F MUST signify that the available with a single byte. A tag value of 0x7F MUST signify that the
first 4 bytes of the value field are interpreted as the tag value. first 4 bytes of the value field are interpreted as the tag value.
Note, this future extension doesn't affect parsers that are unaware of Note, this future extension doesn't affect parsers that are unaware of
this special tag. The tag is like any other unknown tag, and the value this special tag. The tag is like any other unknown tag, and the value
length specifies the length of a value which contains a value that the length specifies the length of a value which contains a value that the
parser treats atomically. All these 4 byte tag values are currently parser treats atomically. All these 4 byte tag values are currently
unallocated except that the values 0x40000000-0x7FFFFFFF are reserved unallocated except that the values 0x40000000-0x7FFFFFFF are reserved
for experimental use. for experimental use.
Moore , Turner and Wenn Expires August 17, 1999
3.8 Name-Length 3.8 Name-Length
The name-length field MUST consist of a SIGNED-SHORT. This field MUST The name-length field MUST consist of a SIGNED-SHORT. This field MUST
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
attributes have the same name, the first occurrence MUST be ignored. The attributes have the same name, the first occurrence MUST be ignored. The
zero-length name is the only mechanism for multi-valued attributes. zero-length name is the only mechanism for multi-valued attributes.
3.9 (Attribute) Name 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 an 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
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.
skipping to change at page 13, line 4 skipping to change at page 13, line 32
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
can be a relative URI and the other can be an absolute URI. HTTP/1.1 can be a relative URI and the other can be an absolute URI. HTTP/1.1
allows clients to generate and send a relative URI rather than an allows clients to generate and send a relative URI rather than an
absolute URI. A relative URI identifies a resource with the scope of absolute URI. A relative URI identifies a resource with the scope of
the HTTP server, but does not include scheme, host or port. The the HTTP server, but does not include scheme, host or port. The
Moore , Turner and Wenn Expires August 17, 1999
following statements characterize how URLs should be used in the mapping following statements characterize how URLs should be used in the mapping
of IPP onto HTTP/1.1: of IPP onto HTTP/1.1:
1. Although potentially redundant, a client MUST supply the target of 1. Although potentially redundant, a client MUST supply the target of
the operation both as an operation attribute and as a URI at the the operation both as an operation attribute and as a URI at the
HTTP layer. The rationale for this decision is to maintain a HTTP layer. The rationale for this decision is to maintain a
consistent set of rules for mapping application/ipp to possibly consistent set of rules for mapping application/ipp to possibly
many communication layers, even where URLs are not used as the many communication layers, even where URLs are not used as the
addressing mechanism in the transport layer. addressing mechanism in the transport layer.
2. Even though these two URLs might not be literally identical (one 2. Even though these two URLs might not be literally identical (one
skipping to change at page 14, line 5 skipping to change at page 14, line 32
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 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.
Moore , Turner and Wenn Expires August 17, 1999
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.
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, such as "unsupported",
the value-length MUST be 0 and the value empty . the value has no the value-length MUST be 0 and the value empty . the value has no
meaning when the value-tag has an "out-of-band" value. If a client meaning when the value-tag has an "out-of-band" value.
receives a response with a nonzero value-length in this case, it MUST
ignore the value field. If a printer receives a request with a nonzero
value-length in this case, it MUST reject the request.
3.11 (Attribute) Value 3.11 (Attribute) Value
The syntax types and most of the details of their representation are The syntax types and most of the details of their representation are
defined in the IPP model document. The table below augments the defined in the IPP model document. The table below augments the
information in the model document, and defines the syntax types from the information in the model document, and defines the syntax types from the
model document in terms of the 5 basic types defined in section 3 model document in terms of the 5 basic types defined in section 3
"Encoding of the Operation Layer". The 5 types are US-ASCII-STRING, "Encoding of the Operation Layer". The 5 types are US-ASCII-STRING,
LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET- LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET-
STRING. 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:
skipping to change at page 15, line 4 skipping to change at page 15, line 31
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 SIGNED-SHORT which is the number of octets a) a SIGNED-SHORT which is the number of octets
in the following field in the following field
b) a value of type natural-language, b) a value of type natural-language,
c) a SIGNED-SHORT which is the number of octets c) a SIGNED-SHORT which is the number of octets
in the following field in the following field
Moore , Turner and Wenn Expires August 17, 1999
Syntax of Attribute Encoding
Value
d) a value of type nameWithoutLanguage. 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
skipping to change at page 15, line 38 skipping to change at page 16, line 5
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
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
Moore , Turner and Wenn Expires August 17, 1999
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
single length or as a sequence of chunks each with a length.
- 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.
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] .
skipping to change at page 17, line 5 skipping to change at page 17, line 29
URL that identifies either an IPP printer object or an IPP job object. URL 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 the HTTP layer does not support the 'ipp' scheme, a client MUST map
'ipp' URLs to 'http' URLs, and then follows the HTTP [RFC2068][RFC2069] 'ipp' URLs to 'http' URLs, and then follows the HTTP [RFC2068][RFC2069]
rules for constructing a Request-Line and HTTP headers. The mapping is rules for constructing a Request-Line and HTTP headers. The mapping is
simple because the 'ipp' scheme implies all of the same protocol simple because the 'ipp' scheme implies all of the same protocol
semantics as that of the 'http' scheme [RFC2068], except that it semantics as that of the 'http' scheme [RFC2068], except that it
represents a print service and the implicit (default) port number that represents a print service and the implicit (default) port number that
clients use to connect to a server is port 631. clients use to connect to a server is port 631.
Moore , Turner and Wenn Expires August 17, 1999
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
job-printer-uri job-printer-uri
skipping to change at page 18, line 4 skipping to change at page 18, line 30
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:
POST /myprinter/myqueue HTTP/1.1 POST /myprinter/myqueue HTTP/1.1
Host: myhost.com:631 Host: myhost.com:631
Content-type: application/ipp Content-type: application/ipp
Transfer-Encoding: chunked Transfer-Encoding: chunked
... ...
Moore , Turner and Wenn Expires August 17, 1999
"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)
... ...
As another example, when an IPP client sends the same request as above As another example, when an IPP client sends the same request as above
via a proxy "myproxy.com", it opens a TCP connection to the proxy port via a proxy "myproxy.com", it opens a TCP connection to the proxy port
8080 on the proxy host "myproxy.com" and sends the following data: 8080 on the proxy host "myproxy.com" and sends the following data:
POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 POST http://myhost.com:631/myprinter/myqueue HTTP/1.1
Host: myhost.com:631 Host: myhost.com:631
skipping to change at page 18, line 29 skipping to change at page 18, line 52
... ...
"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. Compatibility with IPP/1.0 Implementations
IPP/1.1 implementations must be compatible with IPP 1.0 implementations, IPP/1.1 server implementations SHOULD interoperate with IPP/1.0 client
as defined in [ipp-mod-10] and [ipp-pro-10] documents. For implementations, as defined in [rfc 2565] and [rfc 2566] documents. If
compatibility with IPP/1.0 implementations, IPP objects (i.e. a server) an IPP/1.1 server implementation does not support an IPP/1.0 client, it
MUST support additional schemes when communicating with IPP/1.0 clients MUST return the error 'server-error-version-not-supported' and the
as described in this section: 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.
@ If a server receives an IPP/1.0 request, it MUST return an IPP/1.0 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- response. That is, it MUST support both an http-URL and an https-
URL in the target "printer-uri" and "job-uri" operation attributes URL in the target "printer-uri" and "job-uri" operation attributes
in a request. The rules for attributes in a response is covered in in a request. The rules for attributes in a response is covered in
the next two bullet items. the next two bullet items.
@ When a server returns the printer attribute "printer-uri- - When a server returns the printer attribute "printer-uri-
supported", it MUST return all values of the attribute for an 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 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, subset of the attribute values, excluding those that are ipp-URLs,
and including those that are http-URLs and https-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 - 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 "job-uri" and "job-printer-uri" job attributes for all operations
based on how the job was created. based on how the job was created.
Operation Job created via Operation Job created via
attribute attribute
s for a s for a
ipp secure ipp http https ipp secure ipp http https
request request
ipp ipp No URL ipp No URL ipp ipp No URL ipp No URL
returned returned returned returned
Moore , Turner and Wenn Expires August 17, 1999
secure ipp ipp ipp ipp secure ipp ipp ipp ipp
ipp ipp
http http No URL http No URL http http No URL http No URL
returned returned returned returned
https http https http https https http https http https
@ If a server registers a nonsecure ipp-URL with a name service, then - 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 it MUST also register an http-URL. If a printer supports a secure
connection using SSL3, then it MUST register an https-URL. 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 7. Security Considerations
The IPP Model document defines an IPP implementation with "privacy" as The IPP Model and Semantics document [ipp-mod] discusses high level
one that implements Transport Layer Security (TLS) [rfc2246]. TLS meets security requirements (Client Authentication, Server Authentication and
the requirements for IPP security with regards to features such as Operation Privacy). Client Authentication is the mechanism by which the
mutual authentication and privacy (via encryption). The IPP Model client proves its identity to the server in a secure manner. Server
document also outlines IPP-specific security considerations and should Authentication is the mechanism by which the server proves its identity
be the primary reference for security implications with regards to the to the client in a secure manner. Operation Privacy is defined as a
IPP protocol itself. mechanism for protecting operations from eavesdropping.
The IPP Model document defines an IPP implementation with 7.1 Security Conformance
"authentication" as one that implements the standard way for
transporting IPP messages within HTTP 1.1. These include the security
considerations outlined in the HTTP 1.1 standard document [rfc2068] and
Digest Access Authentication extension [rfc2069].
The current HTTP infrastructure supports HTTP over TCP port 80. IPP IPP clients MUST/SHOULD [which is to be determined in consultation with
server implementations MUST offer IPP services using HTTP over the IANA the Area Director] support:
assigned Well Known Port 631 (the IPP default port). IPP server
implementations may support other ports, in addition to this port.
See further discussion of IPP security concepts in the model document Digest Authentication [rfc2069].
[ipp-mod].
7.1 Using IPP with TLS MD5 and MD5-sess MUST be implemented and supported.
The Message Integrity feature NEED NOT be used.
IPP Printers MUST/SHOULD [which is to be determined in consultation with
the Area Director] support:
Digest Authentication [rfc2069].
MD5 and MD5-sess MUST be implemented and supported.
The Message Integrity feature NEED NOT be used.
IPP Printers SHOULD support TLS for client authentication, server
authentication and operation privacy. 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 [
rfc 2068]) for client authentication if the channel is secure. TLS
with the above mandated cipher suite can provide such a secure channel.
The IPP Model and Semantics document defines two printer attributes
("uri-authentication-supported" and "uri-security-supported") that the
client can use to discover the security policy of a printer. That
document also outlines IPP-specific security considerations and should
be the primary reference for security implications with regard to the
IPP protocol itselfFor backward compatibility with IPP version 1.0, IPP
clients and printers MAY also support SSL3. This is in addition to the
security required in this document.
7.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. During the TLS begins with a server's response to switch to TLS. The initial connection
handshake, the original session is preserved. 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 An IPP client that wants a secure connection MUST send "TLS/1.0" as one
of the field-values of the Upgrade request header, e.g. "Upgrade: of the field-values of the HTTP/1.1 Upgrade request header, e.g.
TLS/1.0" (see rfc2068 section 14.42). If the origin-server grants the "Upgrade: TLS/1.0" (see rfc2068 section 14.42). If the origin-server
upgrade request, it MUST respond with "101 Switching Protocols", and it grants the upgrade request, it MUST respond with "101 Switching
Protocols", and it MUST include the header "Upgrade: TLS/1.0" to
Moore , Turner and Wenn Expires August 17, 1999 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:
MUST include the header "Upgrade: TLS/1.0" to indicate what it is the 'Upgrade header' mechanism allows unsecured and secured traffic to
switching to. An IPP client MUST be ready to react appropriately if the share the same port (in this case, 631).
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 With current technology, an IPP server can indicate that it wants an
upgrade only by returning "401 unauthorized" or "403 forbidden". A upgrade only by returning "401 unauthorized" or "403 forbidden". A
server MAY give the client an additional hint by including an "Upgrade: server MAY give the client an additional hint by including an "Upgrade:
TLS" header in the response. When an IPP client receives such a TLS" header in the response. When an IPP client receives such a
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.
skipping to change at page 20, line 34 skipping to change at page 21, line 43
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.
Note: the initial connection (containing the Upgrade header) 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.
8. References 8. References
[char] N. Freed, J. Postel: IANA Charset Registration Procedures, Work [char] N. Freed, J. Postel: IANA Charset Registration Procedures, Work
in Progress (draft-freed-charset-reg-02.txt). in Progress (draft-freed-charset-reg-02.txt).
[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-00.txt, Implementer's Guide", draft-ietf-ipp-implementers-guide-01.txt,
November 1998, work in progress. February 1999, work in progress.
[ipp-lpd] Herriot, R., Hastings, T., Jacobs, N., Martin, J.,
"Mapping between LPD and IPP Protocols", draft-ietf-ipp-lpd-ipp-
map-05.txt, November 1998.
[ipp-mod-10] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P.
Powell, "Internet Printing Protocol/1.0: Model and Semantics",
<draft-ietf-ipp-model-11.txt>, November, 1998.
Moore , Turner and Wenn Expires August 17, 1999
[ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. [ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P.
Powell, "Internet Printing Protocol/1.0: Model and Semantics", Powell, "Internet Printing Protocol/1.0: Model and Semantics",
<draft-ietf-ipp-model-v11-00.txt>, February, 1999. <draft-ietf-ipp-model-v11-02.txt>, May, 1999.
[ipp-pro-10] Herriot, R., Butler, S., Moore, P., Turner, R.,
"Internet Printing Protocol/1.0: Encoding and Transport", draft-
ietf-ipp-protocol-07.txt, November 1998.
[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-00-.txt, February 1999.
[ipp-rat] Zilles, S., "Rationale for the Structure and Model and
Protocol for the Internet Printing Protocol", draft-ietf-ipp-
rat-04.txt, November 1998.
[ipp-req] Wright, D., "Design Goals for an Internet Printing
Protocol", draft-ietf-ipp-req-03.txt, November, 1998.
[rfc822] Crocker, D., "Standard for the Format of ARPA [rfc822] Crocker, D., "Standard for the Format of ARPA
Internet Text Messages", RFC 822, August 1982. Internet Text Messages", RFC 822, August 1982.
[rfc1123] Braden, S., "Requirements for Internet Hosts - [rfc1123] Braden, S., "Requirements for Internet Hosts -
Application and Support", RFC 1123, October, 1989. Application and Support", RFC 1123, October, 1989.
[rfc1179] McLaughlin, L. III, (editor), "Line Printer Daemon [rfc1179] McLaughlin, L. III, (editor), "Line Printer Daemon
Protocol" RFC 1179, August 1990. Protocol" RFC 1179, August 1990.
[rfc1543] Postel, J., "Instructions to RFC Authors", RFC 1543, [rfc1543] Postel, J., "Instructions to RFC Authors", RFC 1543,
skipping to change at page 22, line 5 skipping to change at page 22, line 48
the Simple Network Management Protocol (SNMPv2)", RFC 1903, the Simple Network Management Protocol (SNMPv2)", RFC 1903,
January 1996. January 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 Extension (MIME) Part Four: Registration Procedures. Mail Extension (MIME) Part Four: Registration Procedures.
November 1996 (Also BCP0013), RFC 2048. November 1996 (Also BCP0013), RFC 2048.
Moore , Turner and Wenn Expires August 17, 1999
[rfc2068] R Fielding, et al, "Hypertext Transfer Protocol . [rfc2068] R Fielding, et al, "Hypertext Transfer Protocol .
HTTP/1.1" RFC 2068, January 1997. HTTP/1.1" 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
skipping to change at page 22, line 30 skipping to change at page 23, line 19
[rfc2234] D. Crocker et al., "Augmented BNF for Syntax [rfc2234] D. Crocker et al., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234. November 1997. Specifications: 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.,
"Internet Printing Protocol/1.0: Encoding and Transport", rfc
2565, April 1999.
[rfc 2566] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P.
Powell, "Internet Printing Protocol/1.0: Model and Semantics",
rfc 2566, April, 1999.
[rfc2567] Wright, D., "Design Goals for an Internet Printing
Protocol", RFC2567,April 1999.
[rfc2568] Zilles, S., "Rationale for the Structure and Model and
Protocol for the Internet Printing Protocol", RC 2568,April
1999.
[rfc2569] Herriot, R., Hastings, T., Jacobs, N., Martin, J.,
"Mapping between LPD and IPP Protocols RFC 2569, April 1999.
9. Author's Address 9. Author's Address
Paul Moore Paul Moore
Robert Herriot (editor) Robert Herriot (editor)
Microsoft Microsoft
Xerox Corporation Xerox Corporation
One Microsoft Way One Microsoft Way
3400 Hillview Ave., Bldg #1 3400 Hillview Ave., Bldg #1
Redmond, WA 98053 Redmond, WA 98053
Palo Alto, CA 94304 Palo Alto, CA 94304
Phone: 425-936-0908 Phone: 425-936-0908
Phone: 650-813-7696 Phone: 650-813-7696
Fax: 425-93MS-FAX Fax: 425-93MS-FAX
Fax: 650-650-813-6860 Fax: 650-813-6860
Email: paulmo@microsoft.com Email: paulmo@microsoft.com
Email: Email:
robert.herriot@pahv.xerox.com robert.herriot@pahv.xerox.com
Randy Turner Randy Turner
Sylvan Butler Sylvan Butler
Sharp Laboratories
Hewlett-Packard Hewlett-Packard
5750 NW Pacific Rim Blvd
11311 Chinden Blvd. 11311 Chinden Blvd.
Camas, WA 98607
Boise, ID 83714 Boise, ID 83714
Phone: 360-817-8456 Email: rturner@2wire.com
Phone: 208-396-6000 Phone: 208-396-6000
Fax: : 360-817-8436
Fax: 208-396-3457 Fax: 208-396-3457
Email: rturner@sharplabs.com
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
Moore , Turner and Wenn Expires August 17, 1999
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 Harry Lewis - IBM
Ron Bergman - Dataproducts Tony Liao - Vivid Image Ron Bergman - Dataproducts Tony Liao - Vivid Image
Keith Carter - IBM David Manchala - Xerox Keith Carter - IBM David Manchala - Xerox
Angelo Caruso - Xerox Carl-Uno Manros - Xerox Angelo Caruso - Xerox Carl-Uno Manros - Xerox
Jeff Copeland - QMS Jay Martin - Underscore Jeff Copeland - QMS Jay Martin - Underscore
skipping to change at page 23, line 50 skipping to change at page 25, line 5
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
Moore , Turner and Wenn Expires August 17, 1999
Octets Symbolic Value Protocol field
us-ascii US-ASCII value us-ascii US-ASCII value
0x48 natural-language type value-tag 0x48 natural-language type value-tag
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
skipping to change at page 25, line 4 skipping to change at page 26, line 17
Here is an example of a successful Print-Job response to the previous Here is an example of a successful Print-Job response to the previous
Print-Job request. The printer supported the "copies" and "sides" Print-Job request. The printer supported the "copies" and "sides"
attributes and their supplied values. The status code returned is attributes and their supplied values. The status code returned is
'successful-ok'. 'successful-ok'.
Octets Symbolic Value Protocol field Octets Symbolic Value Protocol field
0x0101 1.1 version-number 0x0101 1.1 version-number
0x0000 successful-ok status-code 0x0000 successful-ok status-code
0x00000001 1 request-id 0x00000001 1 request-id
Moore , Turner and Wenn Expires August 17, 1999
Octets Symbolic Value Protocol field
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
0x001B name-length 0x001B name-length
attributes- attributes-natural- name attributes- attributes-natural- name
skipping to change at page 25, line 39 skipping to change at page 26, line 47
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
0x23 nameWithoutLanguage 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
0x0003 pending value 0x0003 pending value
0x03 end-of-attributes end-of-attributes-tag 0x03 end-of-attributes end-of-attributes-tag
11.3 Print-Job Response (failure) 11.3 Print-Job Response (failure)
Here is an example of an unsuccessful Print-Job response to the previous Here is an example of an unsuccessful Print-Job response to the previous
Print-Job request. It fails because, in this case, the printer does not Print-Job request. It fails because, in this case, the printer does not
skipping to change at page 26, line 4 skipping to change at page 27, line 15
"copies" attribute is not supported. Therefore, no job is created, and "copies" attribute is not supported. Therefore, no job is created, and
neither a "job-id" nor a "job-uri" operation attribute is returned. The neither a "job-id" nor a "job-uri" operation attribute is returned. The
error code returned is 'client-error-attributes-or-values-not-supported' error code returned is 'client-error-attributes-or-values-not-supported'
(0x040B). (0x040B).
Octets Symbolic Value Protocol field Octets Symbolic Value Protocol field
0x0101 1.1 version-number 0x0101 1.1 version-number
0x040B client-error-attributes-or- status-code 0x040B client-error-attributes-or- status-code
values-not-supported values-not-supported
Moore , Turner and Wenn Expires August 17, 1999
Octets Symbolic Value Protocol field
0x00000001 1 request-id 0x00000001 1 request-id
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
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
0x001B name-length 0x001B name-length
skipping to change at page 26, line 53 skipping to change at page 28, line 4
0x03 end-of-attributes end-of-attributes-tag 0x03 end-of-attributes end-of-attributes-tag
11.4 Print-Job Response (success with attributes ignored) 11.4 Print-Job Response (success with attributes ignored)
Here is an example of a successful Print-Job response to a Print-Job Here is an example of a successful Print-Job response to a Print-Job
request like the previous Print-Job request, except that the value of request like the previous Print-Job request, except that the value of
'ipp-attribute-fidelity' is false. The print request succeeds, even 'ipp-attribute-fidelity' is false. The print request succeeds, even
though, in this case, the printer supports neither the "sides" attribute though, in this case, the printer supports neither the "sides" attribute
nor the value '20' for the "copies" attribute. Therefore, a job is nor the value '20' for the "copies" attribute. Therefore, a job is
created, and both a "job-id" and a "job-uri" operation attribute are created, and both a "job-id" and a "job-uri" operation attribute are
returned. The unsupported attributes are also returned in an Unsupported returned. The unsupported attributes are also returned in an Unsupported
Attributes Group. The error code returned is 'successful-ok-ignored-or- Attributes Group. The error code returned is 'successful-ok-ignored-or-
substituted-attributes' (0x0001). substituted-attributes' (0x0001).
Octets Symbolic Value Protocol field Octets Symbolic Value Protocol field
0x0101 1.1 version-number 0x0101 1.1 version-number
0x0001 successful-ok-ignored-or- status-code 0x0001 successful-ok-ignored-or- status-code
Moore , Turner and Wenn Expires August 17, 1999
Octets Symbolic Value Protocol field
substituted-attributes substituted-attributes
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
0x48 natural-language type value-tag 0x48 natural-language type value-tag
skipping to change at page 27, line 55 skipping to change at page 29, line 4
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
0x23 nameWithoutLanguage type value-tag
Octets Symbolic Value Protocol field
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
0x0003 pending value 0x0003 pending value
0x03 end-of-attributes end-of-attributes-tag 0x03 end-of-attributes end-of-attributes-tag
Moore , Turner and Wenn Expires August 17, 1999
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
0x0003 Print-URI operation-id 0x0003 Print-URI operation-id
0x00000001 1 request-id 0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag 0x01 start operation-attributes operation-attributes-tag
skipping to change at page 28, line 50 skipping to change at page 30, line 4
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
Moore , Turner and Wenn Expires August 17, 1999
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:
Octets Symbolic Value Protocol field Octets Symbolic Value Protocol field
0x0101 1.1 version-number 0x0101 1.1 version-number
0x0005 Create-Job operation-id 0x0005 Create-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
skipping to change at page 29, line 55 skipping to change at page 31, line 4
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
Moore , Turner and Wenn Expires August 17, 1999
Octets Symbolic Value Protocol field
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
ipp://forest/pi printer pinetree value ipp://forest/pi printer pinetree value
netree netree
0x21 integer type value-tag 0x21 integer type value-tag
0x0005 name-length 0x0005 name-length
limit limit name limit limit name
0x0004 value-length 0x0004 value-length
skipping to change at page 30, line 55 skipping to change at page 32, line 4
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
Moore , Turner and Wenn Expires August 17, 1999
Octets Symbolic Value Protocol field
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
0x02 start job-attributes (1st job-attributes-tag 0x02 start job-attributes (1st job-attributes-tag
object) object)
0x21 integer type value-tag 0x21 integer type value-tag
0x0006 name-length 0x0006 name-length
job-id job-id name job-id job-id name
0x0004 value-length 0x0004 value-length
skipping to change at page 31, line 60 skipping to change at page 33, line 10
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
defined in Section 3 "Encoding of the Operation Layer" in this defined in Section 3 "Encoding of the Operation Layer" in this
document: document:
MIME type name: application MIME type name: application
MIME subtype name: ipp MIME subtype name: ipp
A Content-Type of "application/ipp" indicates an Internet Printing A Content-Type of "application/ipp" indicates an Internet Printing
Protocol message body (request or response). Currently there are two Protocol message body (request or response). Currently there is one
version: IPP/1.1, whose syntax is described in Section 3 "Encoding of
Moore , Turner and Wenn Expires August 17, 1999 the Operation Layer" of [ipp-pro], and whose semantics are described in
[ipp-mod].
versions: IPP/1.0, and IPP/1.1, whose syntax is described in Section 3
"Encoding of the Operation Layer" of [ipp-pro-10] and [ipp-pro],
respectively, and whose semantics are described in [ipp-mod-10] and
[ipp-mod], respectively.
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: Encoding considerations:
IPP/1.1 protocol requests/responses MAY contain long lines and ALWAYS IPP/1.1 protocol requests/responses MAY contain long lines and ALWAYS
contain binary data (for example attribute value lengths). contain binary data (for example attribute value lengths).
skipping to change at page 32, line 41 skipping to change at page 33, line 44
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).
IPP/1.1 servers MUST support both IPP/1.0 and IPP/1.1. See the section
in [ipp-pro] entitled "Compatibility with IPP/1.0 Implementations" for a
discussion of compatibility with IPP/1.0.
Published specification: Published specification:
[ipp-mod-10] Isaacson, S., deBry, R., Hastings, T., Herriot, R.,
Powell, P., "Internet Printing Protocol/1.0: Model and
Semantics" draft-ietf-ipp-model-11.txt, November, 1998.
[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-00.txt, February, 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-00.txt, February, 1999.
Applications which use this media type: Applications which use this media type:
Moore , Turner and Wenn Expires August 17, 1999
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 33, line 39 skipping to change at page 34, line 34
Palo Alto, CA 94304 Palo Alto, CA 94304
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: Notices 13. Appendix D: Changes from IPP /1.0
IPP/1.1 is identical to IPP/1.0 with the follow changes:
1.Attributes values that identify a printer or job object use a new
'ipp' scheme. The 'http' and 'https' schemes are supported only for
backward compatibility. See section 5.
2.New requirement for support of Digest Authentication. See Section
7.1
3.TLS is recommended for channel security. In addition, SSL3 may be
supported for backward compatibility. See Section 7.2
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-
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
of rights made available for publication and any assurances of licenses of rights made available for publication and any assurances of licenses
to be made available, or the result of an attempt made to obtain a to be made available, or the result of an attempt made to obtain a
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
skipping to change at page 34, line 5 skipping to change at page 35, line 18
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.
Moore , Turner and Wenn Expires August 17, 1999
Copyright (C)The Internet Society (1999). All Rights Reserved Copyright (C)The Internet Society (1999). 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,
skipping to change at page 34, line 31 skipping to change at line 1816
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
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
14. Appendix E: Changes from IPP /1.0
IPP/1.1 is identical to IPP/1.0 with the follow changes:
1.Attributes values that identify a printer or job object use a new
'ipp' scheme. The 'http' and 'https' schemes are supported only for
backward compatibility.
2.TLS provides security. SSL3 is supported only for backward
compatibility.
Moore , Turner and Wenn Expires August 17, 1999
 End of changes. 

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