draft-ietf-ipp-protocol-07.txt   rfc2565.txt 
INTERNET-DRAFT Robert Herriot (editor) Network Working Group R. Herriot, Ed.
Sun Microsystems Request for Comments: 2565 Xerox Corporation
<draft-ietf-ipp-protocol-07.txt> Sylvan Butler Category: Experimental S. Butler
Hewlett-Packard Hewlett-Packard
Paul Moore P. Moore
Microsoft Microsoft
Randy Turner R. Turner
Sharp Labs Sharp Labs
November 16, 1998 April 1999
Internet Printing Protocol/1.0: Encoding and Transport Internet Printing Protocol/1.0: Encoding and Transport
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This memo defines an Experimental Protocol for the Internet
documents of the Internet Engineering Task Force (IETF), its areas, and community. It does not specify an Internet standard of any kind.
its working groups. Note that other groups may also distribute working Discussion and suggestions for improvement are requested.
documents as Internet-Drafts. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress".
To learn the current status of any Internet-Draft, please check the Copyright (C) The Internet Society (1999). All Rights Reserved.
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Copyright Notice IESG Note
Copyright (C)The Internet Society (1998). All Rights Reserved. This document defines an Experimental protocol for the Internet
community. The IESG expects that a revised version of this protocol
will be published as Proposed Standard protocol. The Proposed
Standard, when published, is expected to change from the protocol
defined in this memo. In particular, it is expected that the
standards-track version of the protocol will incorporate strong
authentication and privacy features, and that an "ipp:" URL type will
be defined which supports those security measures. Other changes to
the protocol are also possible. Implementors are warned that future
versions of this protocol may not interoperate with the version of
IPP defined in this document, or if they do interoperate, that some
protocol features may not be available.
The IESG encourages experimentation with this protocol, especially in
combination with Transport Layer Security (TLS) [RFC 2246], to help
determine how TLS may effectively be used as a security layer for
IPP.
Abstract Abstract
This document is one of a set of documents, which together describe all This document is one of a set of documents, which together describe
aspects of a new Internet Printing Protocol (IPP). IPP is an application all aspects of a new Internet Printing Protocol (IPP). IPP is an
level protocol that can be used for distributed printing using Internet application level protocol that can be used for distributed printing
tools and technologies. This document defines the rules for encoding IPP using Internet tools and technologies. This document defines the
operations and IPP attributes into a new Internet mime media type called rules for encoding IPP operations and IPP attributes into a new
"application/ipp". This document also defines the rules for Internet mime media type called "application/ipp". This document
transporting over HTTP a message body whose Content-Type is also defines the rules for transporting over HTTP a message body
"application/ipp". whose Content-Type is "application/ipp".
Moore and Turner Expires May 16, 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
Printing Protocol [ipp-rat] Internet Printing Protocol [RFC2568]
Internet Printing Protocol/1.0: Model and Semantics [ipp-mod] Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
Internet Printing Protocol/1.0: Encoding and Transport (this Internet Printing Protocol/1.0: Encoding and Transport (this
document) document)
Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig] Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
Mapping between LPD and IPP Protocols [ipp-lpd] Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes a The document, "Design Goals for an Internet Printing Protocol", takes
broad look at distributed printing functionality, and it enumerates a 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
satisfied in IPP/1.0. Operator and administrator requirements are out of are satisfied in IPP/1.0. Operator and administrator requirements are
scope for version 1.0. out of scope for version 1.0.
The document, "Rationale for the Structure and Model and Protocol for The document, "Rationale for the Structure and Model and Protocol for
the Internet Printing Protocol", describes IPP from a high level view, the Internet Printing Protocol", describes IPP from a high level
defines a roadmap for the various documents that form the suite of IPP view, defines a roadmap for the various documents that form the suite
specifications, and gives background and rationale for the IETF working of IPP specifications, and gives background and rationale for the
group's major decisions. IETF working group's major decisions.
The document, "Internet Printing Protocol/1.0: Model and Semantics", The document, "Internet Printing Protocol/1.0: Model and Semantics",
describes a simplified model with abstract objects, their attributes, describes a simplified model with abstract objects, their attributes,
and their operations that are independent of encoding and transport. It and their operations that are independent of encoding and transport.
introduces a Printer and a Job object. The Job object optionally It introduces a Printer and a Job object. The Job object optionally
supports multiple documents per Job. It also addresses security, supports multiple documents per Job. It also addresses security,
internationalization, and directory issues. internationalization, and directory issues.
This document "Internet Printing Protocol/1.0: Implementer's Guide", This document "Internet Printing Protocol/1.0: 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
to implementers of gateways between IPP and LPD (Line Printer Daemon) advice to implementers of gateways between IPP and LPD (Line Printer
implementations. Daemon) implementations.
Moore and Turner Expires May 16, 1999 Table of Contents
Table of Contents
1. Introduction.......................................................4 1. Introduction.....................................................4
2. Conformance Terminology............................................4 2. Conformance Terminology..........................................4
3. Encoding of the Operation Layer...................................4 3. Encoding of the Operation Layer.................................4
3.1 Picture of the Encoding.......................................5 3.1 Picture of the Encoding.....................................5
3.2 Syntax of Encoding............................................7 3.2 Syntax of Encoding..........................................7
3.3 Version-number................................................8 3.3 Version-number..............................................9
3.4 Operation-id..................................................8 3.4 Operation-id................................................9
3.5 Status-code...................................................9 3.5 Status-code.................................................9
3.6 Request-id....................................................9 3.6 Request-id..................................................9
3.7 Tags..........................................................9 3.7 Tags.......................................................10
3.7.1 Delimiter Tags.............................................9 3.7.1 Delimiter Tags.........................................10
3.7.2 Value Tags................................................10 3.7.2 Value Tags.............................................11
3.8 Name-Length..................................................12 3.8 Name-Length................................................13
3.9 (Attribute) Name.............................................12 3.9 (Attribute) Name...........................................13
3.10 Value Length.................................................14 3.10 Value Length...............................................16
3.11 (Attribute) Value............................................15 3.11 (Attribute) Value..........................................16
3.12 Data.........................................................16 3.12 Data.......................................................18
4. Encoding of Transport Layer.......................................16 4. Encoding of Transport Layer.....................................18
5. Security Considerations...........................................17 5. Security Considerations.........................................19
5.1 Using IPP with SSL3..........................................18 5.1 Using IPP with SSL3........................................19
6. References........................................................18 6. References......................................................20
7. Author's Address..................................................20 7. Authors' Addresses..............................................22
8. Other Participants:...............................................20 8. Other Participants:.............................................24
9. Appendix A: Protocol Examples.....................................21 9. Appendix A: Protocol Examples...................................25
9.1 Print-Job Request............................................21 9.1 Print-Job Request..........................................25
9.2 Print-Job Response (successful)..............................22 9.2 Print-Job Response (successful)............................26
9.3 Print-Job Response (failure).................................23 9.3 Print-Job Response (failure)...............................27
9.4 Print-Job Response (success with attributes ignored).........24 9.4 Print-Job Response (success with attributes ignored).......28
9.5 Print-URI Request............................................25 9.5 Print-URI Request..........................................30
9.6 Create-Job Request...........................................26 9.6 Create-Job Request.........................................31
9.7 Get-Jobs Request.............................................27 9.7 Get-Jobs Request...........................................31
9.8 Get-Jobs Response............................................28 9.8 Get-Jobs Response..........................................32
10.Appendix C: Registration of MIME Media Type Information for 10. Appendix C: Registration of MIME Media Type Information for
"application/ipp".....................................................29 "application/ipp"..............................................35
11.Appendix D: Full Copyright Statement..............................31 11. Full Copyright Statement.......................................37
Moore and Turner Expires May 16, 1999
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.0: Model and response. The document "Internet Printing Protocol/1.0: Model and
Semantics" [ipp-mod] defines the semantics of such a message body and Semantics" [RFC2566] defines the semantics of such a message body and
the supported values. This document specifies the encoding of an IPP the supported values. This document specifies the encoding of an IPP
operation. The aforementioned document [ipp-mod] is henceforth referred operation. The aforementioned document [RFC2566] is henceforth
to as the "IPP model document" referred to as the "IPP model document"
2. Conformance Terminology 2. Conformance Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119 [rfc2119]. interpreted as described in RFC 2119 [RFC2119].
3. Encoding of the Operation Layer 3. Encoding of the Operation Layer
The operation layer MUST contain a single operation request or operation The operation layer MUST contain a single operation request or
response. Each request or response consists of a sequence of values and operation response. Each request or response consists of a sequence
attribute groups. Attribute groups consist of a sequence of attributes of values and attribute groups. Attribute groups consist of a
each of which is a name and value. Names and values are ultimately sequence of attributes each of which is a name and value. Names and
sequences of octets values are ultimately sequences of octets
The encoding consists of octets as the most primitive type. There are
several types built from octets, but three important types are
integers, character strings and octet strings, on which most other
data types are built. Every character string in this encoding MUST be a
sequence of characters where the characters are associated with some
charset and some natural language. A character string MUST be in
"reading order" with the first character in the value (according to
reading order) being the first character in the encoding. A character
string whose associated charset is US-ASCII whose associated natural
language is US English is henceforth called a US-ASCII-STRING. A
character string whose associated charset and natural language are
specified in a request or response as described in the model document is
henceforth called a LOCALIZED-STRING. An octet string MUST be in "IPP
model document order" with the first octet in the value (according to
the IPP model document order) being the first octet in the encoding
Every integer in this encoding MUST be encoded as a signed integer using
two's-complement binary encoding with big-endian format (also known as
"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.
Such one-octet integers, henceforth called SIGNED-BYTE, are used for the
version-number and tag fields. Such two-byte integers, henceforth called
SIGNED-SHORT are used for the operation-id, status-code and length
Moore and Turner Expires May 16, 1999 The encoding consists of octets as the most primitive type. There are
fields. Four byte integers, henceforth called SIGNED-INTEGER, are used several types built from octets, but three important types are
for values fields and the sequence number. integers, character strings and octet strings, on which most other
data types are built. Every character string in this encoding MUST be
a sequence of characters where the characters are associated with
some charset and some natural language. A character string MUST be in
"reading order" with the first character in the value (according to
reading order) being the first character in the encoding. A character
string whose associated charset is US-ASCII whose associated natural
language is US English is henceforth called a US-ASCII-STRING. A
character string whose associated charset and natural language are
specified in a request or response as described in the model document
is henceforth called a LOCALIZED-STRING. An octet string MUST be in
"IPP model document order" with the first octet in the value
(according to the IPP model document order) being the first octet in
the encoding Every integer in this encoding MUST be encoded as a
signed integer using two's-complement binary encoding with big-endian
format (also known as "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. Such one-octet integers,
henceforth called SIGNED-BYTE, are used for the version-number and
tag fields. Such two-byte integers, henceforth called SIGNED-SHORT
are used for the operation-id, status-code and length fields. Four
byte integers, henceforth called SIGNED-INTEGER, are used 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
RFC 2234 [rfc2234] by RFC 2234 [RFC2234]
3.1 Picture of the Encoding 3.1 Picture of the Encoding
The encoding for an operation request or response consists of: The encoding for an operation request or response consists of:
----------------------------------------------- -----------------------------------------------
| version-number | 2 bytes - required | version-number | 2 bytes - required
----------------------------------------------- -----------------------------------------------
| operation-id (request) | | operation-id (request) |
| or | 2 bytes - required | or | 2 bytes - required
| 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 |
----------------------------------------------- |-0 or more ----------------------------------------------- |-0 or more
| xxx-attribute-sequence | n bytes | | xxx-attribute-sequence | n bytes |
----------------------------------------------------------- -----------------------------------------------------------
| end-of-attributes-tag | 1 byte - required | end-of-attributes-tag | 1 byte - required
----------------------------------------------- -----------------------------------------------
| data | q bytes - optional | data | q bytes - optional
----------------------------------------------- -----------------------------------------------
The xxx-attributes-tag and xxx-attribute-sequence represents four The xxx-attributes-tag and xxx-attribute-sequence represents four
different values of "xxx", namely, operation, job, printer and different values of "xxx", namely, operation, job, printer and
unsupported. The xxx-attributes-tag and an xxx-attribute-sequence unsupported. The xxx-attributes-tag and an xxx-attribute-sequence
represent attribute groups in the model document. The xxx-attributes-tag represent attribute groups in the model document. The xxx-
identifies the attribute group and the xxx-attribute-sequence contains attributes-tag identifies the attribute group and the xxx-attribute-
the attributes. sequence contains the attributes.
The expected sequence of xxx-attributes-tag and xxx-attribute-sequence
is specified in the IPP model document for each operation request and
operation response.
A request or response SHOULD contain each xxx-attributes-tag defined for
that request or response even if there are no attributes except for the
unsupported-attributes-tag which SHOULD be present only if the
unsupported-attribute-sequence is non-empty. A receiver of a request
MUST be able to process as equivalent empty attribute groups:
a) an xxx-attributes-tag with an empty xxx-attribute-sequence, The expected sequence of xxx-attributes-tag and xxx-attribute-
sequence is specified in the IPP model document for each operation
request and operation response.
b) an expected but missing xxx-attributes-tag. A request or response SHOULD contain each xxx-attributes-tag defined
for that request or response even if there are no attributes except
for the unsupported-attributes-tag which SHOULD be present only if
the unsupported-attribute-sequence is non-empty. A receiver of a
request MUST be able to process as equivalent empty attribute groups:
The data is omitted from some operations, but the end-of-attributes-tag a) an xxx-attributes-tag with an empty xxx-attribute-sequence,
is present even when the data is omitted. Note, the xxx-attributes-tags b) an expected but missing xxx-attributes-tag.
Moore and Turner Expires May 16, 1999 The data is omitted from some operations, but the end-of-attributes-
and end-of-attributes-tag are called 'delimiter-tags'. Note: the xxx- tag is present even when the data is omitted. Note, the xxx-
attribute-sequence, shown above may consist of 0 bytes, according to the attributes-tags and end-of-attributes-tag are called 'delimiter-
rule below. tags'. Note: the xxx-attribute-sequence, shown above may consist of 0
bytes, according to the rule below.
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.
Note: a 'compound-attribute' represents a single attribute in the model Note: a 'compound-attribute' represents a single attribute in the
document. The 'additional value' syntax is for attributes with 2 or model document. The 'additional value' syntax is for attributes with
more values. 2 or 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
----------------------------------------------- -----------------------------------------------
| name | u bytes | name | u bytes
----------------------------------------------- -----------------------------------------------
| value-length (value is v) | 2 bytes | value-length (value is v) | 2 bytes
----------------------------------------------- -----------------------------------------------
| value | v bytes | value | v bytes
----------------------------------------------- -----------------------------------------------
An additional value consists of:
An additional value consists of:
----------------------------------------------------------- -----------------------------------------------------------
| value-tag | 1 byte | | value-tag | 1 byte |
----------------------------------------------- | ----------------------------------------------- |
| name-length (value is 0x0000) | 2 bytes | | name-length (value is 0x0000) | 2 bytes |
----------------------------------------------- |-0 or more ----------------------------------------------- |-0 or more
| value-length (value is w) | 2 bytes | | value-length (value is w) | 2 bytes |
----------------------------------------------- | ----------------------------------------------- |
| value | w bytes | | value | w bytes |
----------------------------------------------------------- -----------------------------------------------------------
Note: an additional value is like an attribute whose name-length is 0. Note: an additional value is like an attribute whose name-length is 0.
>From the standpoint of a parsing loop, the encoding consists of: From the standpoint of a parsing loop, the encoding consists of:
Moore and Turner Expires May 16, 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
----------------------------------------------------------- -----------------------------------------------------------
| tag (delimiter-tag or value-tag) | 1 byte | | tag (delimiter-tag or value-tag) | 1 byte |
----------------------------------------------- |-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:
@ 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
case sensitive. For example 'a' means lower case 'a' and not upper case be case sensitive. For example 'a' means lower case 'a' and not
'A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields are represented upper case 'A'. In addition, SIGNED-BYTE and SIGNED-SHORT fields
as '%x' values which show their range of values. are represented as '%x' values which show their range of values.
ipp-message = ipp-request / ipp-response ipp-message = ipp-request / ipp-response
ipp-request = version-number operation-id request-id ipp-request = version-number operation-id request-id
*(xxx-attributes-tag xxx-attribute-sequence) end-of- *(xxx-attributes-tag xxx-attribute-sequence)
attributes-tag data end-of-attributes-tag data
ipp-response = version-number status-code request-id ipp-response = version-number status-code request-id
*(xxx-attributes-tag xxx-attribute-sequence) end-of- *(xxx-attributes-tag xxx-attribute-sequence)
attributes-tag data end-of-attributes-tag data
xxx-attribute-sequence = *compound-attribute xxx-attribute-sequence = *compound-attribute
xxx-attributes-tag = operation-attributes-tag / job-attributes-tag / xxx-attributes-tag = operation-attributes-tag / job-attributes-tag /
printer-attributes-tag / unsupported-attributes-tag printer-attributes-tag / unsupported-attributes-tag
version-number = major-version-number minor-version-number version-number = major-version-number minor-version-number
major-version-number = SIGNED-BYTE ; initially %d1 major-version-number = SIGNED-BYTE ; initially %d1
minor-version-number = SIGNED-BYTE ; initially %d0 minor-version-number = SIGNED-BYTE ; initially %d0
operation-id = SIGNED-SHORT ; mapping from model defined below operation-id = SIGNED-SHORT ; mapping from model defined below
status-code = SIGNED-SHORT ; mapping from model defined below status-code = SIGNED-SHORT ; mapping from model defined below
request-id = SIGNED-INTEGER ; whose value is > 0 request-id = SIGNED-INTEGER ; whose value is > 0
compound-attribute = attribute *additional-values compound-attribute = attribute *additional-values
Moore and Turner Expires May 16, 1999
attribute = value-tag name-length name value-length value attribute = value-tag name-length name value-length value
additional-values = value-tag zero-name-length value-length value additional-values = value-tag zero-name-length value-length value
name-length = SIGNED-SHORT ; number of octets of 'name' name-length = SIGNED-SHORT ; number of octets of 'name'
name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." ) name = LALPHA *( LALPHA / DIGIT / "-" / "_" / "." )
value-length = SIGNED-SHORT ; number of octets of 'value' value-length = SIGNED-SHORT ; number of octets of 'value'
value = OCTET-STRING value = OCTET-STRING
data = OCTET-STRING data = OCTET-STRING
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
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
attribute-sequence that follows is empty. The syntax is defined this way way to allow for the response of Get-Jobs where no attributes are
to allow for the response of Get-Jobs where no attributes are returned returned for some job-objects. Although it is RECOMMENDED that the
for some job-objects. Although it is RECOMMENDED that the sender not sender not send an xxx-attributes-tag if there are no attributes
send an xxx-attributes-tag if there are no attributes (except in the (except in the Get-Jobs response just mentioned), the receiver MUST
Get-Jobs response just mentioned), the receiver MUST be able to decode be able to decode such syntax.
such syntax.
3.3 Version-number 3.3 Version-number
The version-number MUST consist of a major and minor version-number, The version-number MUST consist of a major and minor version-number,
each of which MUST be represented by a SIGNED-BYTE. The protocol each of which MUST be represented by a SIGNED-BYTE. The protocol
described in this document MUST have a major version-number of 1 (0x01) described in this document MUST have a major version-number of 1
and a minor version-number of 0 (0x00). The ABNF for these two bytes (0x01) and a minor version-number of 0 (0x00). The ABNF for these
MUST be %x01.00. two bytes MUST be %x01.00.
3.4 Operation-id 3.4 Operation-id
Operation-ids are defined as enums in the model document. An operation- Operation-ids are defined as enums in the model document. An
ids enum value MUST be encoded as a SIGNED-SHORT. operation-ids enum value MUST be encoded as a SIGNED-SHORT.
Note: the values 0x4000 to 0xFFFF are reserved for private extensions. Note: the values 0x4000 to 0xFFFF are reserved for private
extensions.
Moore and Turner Expires May 16, 1999
3.5 Status-code 3.5 Status-code
Status-codes are defined as enums in the model document. A status-code Status-codes are defined as enums in the model document. A status-
enum value MUST be encoded as a SIGNED-SHORT. code enum value MUST be encoded as a SIGNED-SHORT.
The status-code is an operation attribute in the model document. In the The status-code is an operation attribute in the model document. In
protocol, the status-code is in a special position, outside of the the protocol, the status-code is in a special position, outside of
operation attributes. the operation attributes.
If an IPP status-code is returned, then the HTTP Status-Code MUST be 200 If an IPP status-code is returned, then the HTTP Status-Code MUST be
(successful-ok). With any other HTTP Status-Code value, the HTTP 200 (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
code is returned. status-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.
mechanism is unnecessary in HTTP, but may be useful when application/ipp This mechanism is unnecessary in HTTP, but may be useful when
entity bodies are used in another context. application/ipp entity bodies are used in another context.
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
in each request to a unique value or a constant value, such as 1, request-id in each request to a unique value or a constant value,
depending on what the client does with the request-id returned in the such as 1, depending on what the client does with the request-id
response. The value of the request-id MUST be greater than zero. returned in the 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
0x00 reserved Tag Value (Hex) Delimiter
0x01 operation-attributes-tag
0x02 job-attributes-tag
0x03 end-of-attributes-tag
0x04 printer-attributes-tag
0x05 unsupported-attributes-tag
0x06-0x0e reserved for future delimiters
0x0F reserved for future chunking-end-of-attributes-
tag
Moore and Turner Expires May 16, 1999 0x00 reserved
0x01 operation-attributes-tag
0x02 job-attributes-tag
0x03 end-of-attributes-tag
0x04 printer-attributes-tag
0x05 unsupported-attributes-tag
0x06-0x0e reserved for future delimiters
0x0F reserved for future chunking-end-of-attributes-
tag
When an xxx-attributes-tag occurs in the protocol, it MUST mean that When an xxx-attributes-tag occurs in the protocol, it MUST mean that
zero or more following attributes up to the next delimiter tag are zero or more following attributes up to the next delimiter tag are
attributes belonging to group xxx as defined in the model document, attributes belonging to group xxx as defined in the model document,
where xxx is operation, job, printer, unsupported. where xxx is operation, job, printer, unsupported.
Doing substitution for xxx in the above paragraph, this means the Doing substitution for xxx in the above paragraph, this means the
following. When an operation-attributes-tag occurs in the protocol, it following. When an operation-attributes-tag occurs in the protocol,
MUST mean that the zero or more following attributes up to the next it MUST mean that the zero or more following attributes up to the
delimiter tag are operation attributes as defined in the model document. next delimiter tag are operation attributes as defined in the model
When an job-attributes-tag occurs in the protocol, it MUST mean that the document. When an job-attributes-tag occurs in the protocol, it MUST
zero or more following attributes up to the next delimiter tag are job mean that the zero or more following attributes up to the next
attributes or job template attributes as defined in the model document. delimiter tag are job attributes or job template attributes as
When a printer-attributes-tag occurs in the protocol, it MUST mean that defined in the model document. When a printer-attributes-tag occurs
the zero or more following attributes up to the next delimiter tag are in the protocol, it MUST mean that the zero or more following
printer attributes as defined in the model document. When an attributes up to the next delimiter tag are printer attributes as
unsupported-attributes-tag occurs in the protocol, it MUST mean that the defined in the model document. When an unsupported-attributes-tag
zero or more following attributes up to the next delimiter tag are occurs in the protocol, it MUST mean that the zero or more following
unsupported attributes as defined in the model document. attributes up to the next delimiter tag are 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
exactly once in an operation. The operation-attributes-tag MUST be the occur exactly once in an operation. The operation-attributes-tag MUST
first tag delimiter, and the end-of-attributes-tag MUST be the last tag be the first tag delimiter, and the end-of-attributes-tag MUST be the
delimiter. If the operation has a document-content group, the document last tag delimiter. If the operation has a document-content group,
data in that group MUST follow the end-of-attributes-tag. the document 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
in an operation and each MUST occur at most once in an operation, except OPTIONAL in an operation and each MUST occur at most once in an
for job-attributes-tag in a Get-Jobs response which may occur zero or operation, except for job-attributes-tag in a Get-Jobs response which
more times. may occur zero or 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
each operation response MUST be that defined in the model document. For and each operation response MUST be that defined in the model
further details, see section 3.9 "(Attribute) Name" and section 9 document. For further details, see section 3.9 "(Attribute) Name" and
"Appendix A: Protocol Examples". section 9 "Appendix A: Protocol Examples".
A Printer MUST treat the reserved delimiter tags differently from A Printer MUST treat the reserved delimiter tags differently from
reserved value tags so that the Printer knows that there is an entire reserved value tags so that the Printer knows that there is an entire
attribute group that it doesn't understand as opposed to a single value attribute group that it doesn't understand as opposed to a single
that it doesn't understand. value that it doesn't understand.
3.7.2 Value Tags 3.7.2 Value Tags
The remaining tables show values for the value-tag, which is the first The remaining tables show values for the value-tag, which is the
octet of an attribute. The value-tag specifies the type of the value of first octet of an attribute. The value-tag specifies the type of the
the attribute. The following table specifies the "out-of-band" values value of the attribute. The following table specifies the "out-of-
for the value-tag. band" values for the value-tag.
Tag Value (Hex) Meaning
0x10 unsupported Tag Value (Hex) Meaning
0x11 reserved for future 'default'
0x12 unknown
0x13 no-value
Moore and Turner Expires May 16, 1999 0x10 unsupported
Tag Value (Hex) Meaning 0x11 reserved for future 'default'
0x12 unknown
0x13 no-value
0x14-0x1F reserved for future "out-of-band" values. Tag Value (Hex) Meaning
The "unsupported" value MUST be used in the attribute-sequence of an 0x14-0x1F reserved for future "out-of-band" values.
error response for those attributes which the printer does not support.
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
supported attribute when its value is temporarily unknown. The "no-
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
implementation supports this attribute, but an administrator has not
configured the printer to have a limit.
The following table specifies the integer values for the value-tag: The "unsupported" value MUST be used in the attribute-sequence of an
error response for those attributes which the printer does not
support. 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 supported attribute when its value is temporarily
unknown. The "no-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 implementation supports this attribute, but an
administrator has not configured the printer to have a limit.
Tag Value (Hex) Meaning The following table specifies the integer values for the value-tag:
0x20 reserved Tag Value (Hex) Meaning
0x21 integer
0x22 boolean
0x23 enum
0x24-0x2F reserved for future integer types
NOTE: 0x20 is reserved for "generic integer" if it should ever be 0x20 reserved
needed. 0x21 integer
0x22 boolean
0x23 enum
0x24-0x2F reserved for future integer types
The following table specifies the octetString values for the value-tag: NOTE: 0x20 is reserved for "generic integer" if it should ever be
needed.
Tag Value (Hex) Meaning The following table specifies the octetString values for the value-
tag:
0x30 octetString with an unspecified format Tag Value (Hex) Meaning
0x31 dateTime
0x32 resolution
0x33 rangeOfInteger
0x34 reserved for collection (in the future)
0x35 textWithLanguage
0x36 nameWithLanguage
0x37-0x3F reserved for future octetString types
The following table specifies the character-string values for the value- 0x30 octetString with an unspecified format
tag: 0x31 dateTime
0x32 resolution
0x33 rangeOfInteger
0x34 reserved for collection (in the future)
0x35 textWithLanguage
0x36 nameWithLanguage
0x37-0x3F reserved for future octetString types
Tag Value (Hex) Meaning The following table specifies the character-string values for the
value-tag:
0x40 reserved Tag Value (Hex) Meaning
0x41 textWithoutLanguage
0x42 nameWithoutLanguage
0x43 reserved
0x44 keyword
0x45 uri
0x46 uriScheme
0x47 charset
0x48 naturalLanguage
Moore and Turner Expires May 16, 1999 0x40 reserved
Tag Value (Hex) Meaning 0x41 textWithoutLanguage
0x42 nameWithoutLanguage
0x43 reserved
0x44 keyword
0x45 uri
0x46 uriScheme
0x47 charset
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
be needed. ever 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".
attribute's name has an implicit type, which is keyword. An attribute's name has an implicit type, which is keyword.
The values 0x60-0xFF are reserved for future types. There are no values The values 0x60-0xFF are reserved for future types. There are no
allocated for private extensions. A new type MUST be registered via the values allocated for private extensions. A new type MUST be
type 2 registration process [ipp-mod]. registered via the type 2 registration process [RFC2566].
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
first 4 bytes of the value field are interpreted as the tag value. the first 4 bytes of the value field are interpreted as the tag
Note, this future extension doesn't affect parsers that are unaware of value. Note, this future extension doesn't affect parsers that are
this special tag. The tag is like any other unknown tag, and the value unaware of this special tag. The tag is like any other unknown tag,
length specifies the length of a value which contains a value that the and the value length specifies the length of a value which contains a
parser treats atomically. All these 4 byte tag values are currently value that the parser treats atomically. All these 4 byte tag values
unallocated except that the values 0x40000000-0x7FFFFFFF are reserved are currently unallocated except that the values 0x40000000-
for experimental use. 0x7FFFFFFF are reserved for experimental use.
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
length field, excluding the two bytes of the name-length field. name-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
value for the preceding attribute. Within an attribute-sequence, if two additional value for the preceding attribute. Within an attribute-
attributes have the same name, the first occurrence MUST be ignored. The sequence, if two attributes have the same name, the first occurrence
zero-length name is the only mechanism for multi-valued attributes. MUST be ignored. The 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 [RFC2566]. They MUST be encoded in a special position and they MUST
appear as an operation attributes. These parameters are: NOT appear as an operation attributes. These parameters are:
@ "version-number": The parameter named "version-number" in the IPP
model document MUST become the "version-number" field in the
operation layer request or response.
@ "operation-id": The parameter named "operation-id" in the IPP model
document MUST become the "operation-id" field in the operation
layer request.
Moore and Turner Expires May 16, 1999
@ "status-code": The parameter named "status-code" in the IPP model - "version-number": The parameter named "version-number" in the
document MUST become the "status-code" field in the operation layer IPP model document MUST become the "version-number" field in the
response. operation layer request or response.
@ "request-id": The parameter named "request-id" in the IPP model
document MUST become the "request-id" field in the operation layer
request or response.
All Printer and Job objects are identified by a Uniform Resource - "operation-id": The parameter named "operation-id" in the IPP
Identifier (URI) [rfc2396] so that they can be persistently and model document MUST become the "operation-id" field in the
unambiguously referenced. The notion of a URI is a useful concept, operation layer request.
however, until the notion of URI is more stable (i.e., defined more - "status-code": The parameter named "status-code" in the IPP
completely and deployed more widely), it is expected that the URIs used model document MUST become the "status-code" field in the
for IPP objects will actually be URLs [rfc1738] [rfc1808]. Since every operation layer response.
URL is a specialized form of a URI, even though the more generic term - "request-id": The parameter named "request-id" in the IPP model
URI is used throughout the rest of this document, its usage is intended document MUST become the "request-id" field in the operation
to cover the more specific notion of URL as well. layer request or response.
Some operation elements are encoded twice, once as the request-URI on All Printer and Job objects are identified by a Uniform Resource
the HTTP Request-Line and a second time as a REQUIRED operation Identifier (URI) [RFC2396] so that they can be persistently and
attribute in the application/ipp entity. These attributes are the unambiguously referenced. The notion of a URI is a useful concept,
target URI for the operation: 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 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 URI is used throughout the rest of this document, its
usage is intended to cover the more specific notion of URL as well.
@ "printer-uri": When the target is a printer and the transport is Some operation elements are encoded twice, once as the request-URI on
HTTP or HTTPS (for SSL3 [ssl]), the target printer-uri defined in the HTTP Request-Line and a second time as a REQUIRED operation
each operation in the IPP model document MUST be an operation attribute in the application/ipp entity. These attributes are the
attribute called "printer-uri" and it MUST also be specified target URI for the operation:
outside of the operation layer as the request-URI on the Request-
Line at the HTTP level.
@ "job-uri": When the target is a job and the transport is HTTP or
HTTPS (for SSL3), the target job-uri of each operation in the IPP
model document MUST be an operation attribute called "job-uri" and
it MUST also be specified outside of the operation layer as the
request-URI on the Request-Line at the HTTP level.
Note: The target URI is included twice in an operation referencing the - "printer-uri": When the target is a printer and the transport is
same IPP object, but the two URIs NEED NOT be literally identical. One HTTP or HTTPS (for SSL3 [ssl]), the target printer-uri defined
can be a relative URI and the other can be an absolute URI. HTTP/1.1 in each operation in the IPP model document MUST be an operation
allows clients to generate and send a relative URI rather than an attribute called "printer-uri" and it MUST also be specified
absolute URI. A relative URI identifies a resource with the scope of outside of the operation layer as the request-URI on the
the HTTP server, but does not include scheme, host or port. The Request-Line at the HTTP level.
following statements characterize how URLs should be used in the mapping - "job-uri": When the target is a job and the transport is HTTP or
of IPP onto HTTP/1.1: HTTPS (for SSL3), the target job-uri of each operation in the
IPP model document MUST be an operation attribute called "job-
uri" and it MUST also be specified outside of the operation
layer as the request-URI on the Request-Line at the HTTP level.
1. Although potentially redundant, a client MUST supply the target of Note: The target URI is included twice in an operation referencing
the operation both as an operation attribute and as a URI at the the same IPP object, but the two URIs NEED NOT be literally
HTTP layer. The rationale for this decision is to maintain a identical. One can be a relative URI and the other can be an absolute
consistent set of rules for mapping application/ipp to possibly URI. HTTP/1.1 allows clients to generate and send a relative URI
many communication layers, even where URLs are not used as the rather than an absolute URI. A relative URI identifies a resource
addressing mechanism in the transport layer. with the scope of the HTTP server, but does not include scheme, host
2. Even though these two URLs might not be literally identical (one or port. The following statements characterize how URLs should be
being relative and the other being absolute), they MUST both used in the mapping of IPP onto HTTP/1.1:
reference the same IPP object.
3. The URI in the HTTP layer is either relative or absolute and is
used by the HTTP server to route the HTTP request to the correct
Moore and Turner Expires May 16, 1999 1. Although potentially redundant, a client MUST supply the target
resource relative to that HTTP server. The HTTP server need not be of the operation both as an operation attribute and as a URI at
aware of the URI within the operation request. the HTTP layer. The rationale for this decision is to maintain
4. Once the HTTP server resource begins to process the HTTP request, a consistent set of rules for mapping application/ipp to
it might get the reference to the appropriate IPP Printer object possibly many communication layers, even where URLs are not
from either the HTTP URI (using to the context of the HTTP server used as the addressing mechanism in the transport layer.
for relative URLs) or from the URI within the operation request; 2. Even though these two URLs might not be literally identical
the choice is up to the implementation. (one being relative and the other being absolute), they MUST
5. HTTP URIs can be relative or absolute, but the target URI in the both reference the same IPP object.
operation MUST be an absolute URI. 3. The URI in the HTTP layer is either relative or absolute and is
used by the HTTP server to route the HTTP request to the
correct resource relative to that HTTP server. The HTTP server
need not be aware of the URI within the operation request.
4. Once the HTTP server resource begins to process the HTTP
request, it might get the reference to the appropriate IPP
Printer object from either the HTTP URI (using to the context
of the HTTP server for relative URLs) or from the URI within
the operation request; the choice is up to the implementation.
5. HTTP URIs can be relative or absolute, but the target URI in
the operation MUST be an absolute URI.
The model document arranges the remaining attributes into groups for The model document arranges the remaining attributes into groups for
each operation request and response. Each such group MUST be represented each operation request and response. Each such group MUST be
in the protocol by an xxx-attribute-sequence preceded by the appropriate represented in the protocol by an xxx-attribute-sequence preceded by
xxx-attributes-tag (See the table below and section 9 "Appendix A: the appropriate xxx-attributes-tag (See the table below and section 9
Protocol Examples"). In addition, the order of these xxx-attributes-tags "Appendix A: Protocol Examples"). In addition, the order of these
and xxx-attribute-sequences in the protocol MUST be the same as in the xxx-attributes-tags and xxx-attribute-sequences in the protocol MUST
model document, but the order of attributes within each xxx-attribute- be the same as in the model document, but the order of attributes
sequence MUST be unspecified. The table below maps the model document within each xxx-attribute-sequence MUST be unspecified. The table
group name to xxx-attributes-sequence: below maps the model document group name to xxx-attributes-sequence:
Model Document Group xxx-attributes-sequence Model Document Group xxx-attributes-sequence
Operation Attributes operations-attributes-sequence Operation Attributes operations-attributes-sequence
Job Template Attributes job-attributes-sequence Job Template Attributes job-attributes-sequence
Job Object Attributes job-attributes-sequence Job Object Attributes job-attributes-sequence
Unsupported Attributes unsupported- attributes-sequence Unsupported Attributes unsupported-attributes-sequence
Requested Attributes (Get- job-attributes-sequence Requested Attributes job-attributes-sequence
Job-Attributes) Get-Job-Attributes)
Requested Attributes (Get- printer-attributes-sequence Requested Attributes printer-attributes-sequence
Printer-Attributes) Get-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
Get-Jobs response), the attributes from each job object MUST be in a (e.g. Get-Jobs response), the attributes from each job object MUST
separate job-attribute-sequence, such that the attributes from the ith be in a separate job-attribute-sequence, such that the attributes
job object are in the ith job-attribute-sequence. See Section 9 from the ith job object are in the ith job-attribute-sequence. See
"Appendix A: Protocol Examples" for table showing the application of the Section 9 "Appendix A: Protocol Examples" for table showing the
rules above. application of the rules above.
3.10 Value Length 3.10 Value Length
Each attribute value MUST be preceded by a SIGNED-SHORT, which MUST Each attribute value MUST be preceded by a SIGNED-SHORT, which MUST
specify the number of octets in the value which follows this length, specify the number of octets in the value which follows this length,
exclusive of the two bytes specifying the length. exclusive of the two bytes specifying the length.
For any of the types represented by binary signed integers, the sender For any of the types represented by binary signed integers, the
MUST encode the value in exactly four octets. sender 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
encode the value with all the characters of the string and without any MUST encode the value with all the characters of the string and
padding characters. without any padding characters.
Moore and Turner Expires May 16, 1999 If a value-tag contains an "out-of-band" value, such as
If a value-tag contains an "out-of-band" value, such as "unsupported", "unsupported", the value-length MUST be 0 and the value empty. The
the value-length MUST be 0 and the value empty . the value has no value has no meaning when the value-tag has an "out-of-band" value.
meaning when the value-tag has an "out-of-band" value. If a client If a client receives a response with a nonzero value-length in this
receives a response with a nonzero value-length in this case, it MUST case, it MUST ignore the value field. If a printer receives a request
ignore the value field. If a printer receives a request with a nonzero with a nonzero value-length in this case, it MUST reject the request.
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
model document in terms of the 5 basic types defined in section 3 the model document in terms of the 5 basic types defined in section 3
"Encoding of the Operation Layer". The 5 types are US-ASCII-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
STRING. OCTET-STRING.
Syntax of Attribute Encoding Syntax of Attribute Encoding
Value Value
textWithoutLanguage, LOCALIZED-STRING. textWithoutLanguage, LOCALIZED-STRING.
nameWithoutLanguage nameWithoutLanguage
textWithLanguage OCTET_STRING consisting of 4 fields: textWithLanguage OCTET_STRING consisting of 4 fields:
a) a 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
skipping to change at page 16, line 5 skipping to change at page 17, line 28
charset, US-ASCII-STRING. charset, US-ASCII-STRING.
naturalLanguage, naturalLanguage,
mimeMediaType, mimeMediaType,
keyword, uri, and keyword, uri, and
uriScheme uriScheme
boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is
'true'. 'true'.
Moore and Turner Expires May 16, 1999
Syntax of Attribute Encoding Syntax of Attribute Encoding
Value Value
integer and enum a SIGNED-INTEGER. integer and enum a SIGNED-INTEGER.
dateTime OCTET-STRING consisting of eleven octets whose dateTime OCTET-STRING consisting of eleven octets whose
contents are defined by "DateAndTime" in RFC contents are defined by "DateAndTime" in RFC
1903 [rfc1903]. 2579 [RFC2579].
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.
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
the value and the value of the value-tag. in the value and the value of the value-tag.
3.12 Data 3.12 Data
The data part MUST include any data required by the operation The data part MUST include any data required by the operation
4. Encoding of Transport Layer 4. Encoding of Transport Layer
HTTP/1.1 [rfc2068] is the transport layer for this protocol. HTTP/1.1 [RFC2068] is the transport layer for this protocol.
The operation layer has been designed with the assumption that the
transport layer contains the following information:
@ the URI of the target job or printer operation The operation layer has been designed with the assumption that the
@ the total length of the data in the operation layer, either as a transport layer contains the following information:
single length or as a sequence of chunks each with a length.
It is REQUIRED that a printer implementation support HTTP over the IANA - the URI of the target job or printer operation
assigned Well Known Port 631 (the IPP default port), though a printer - the total length of the data in the operation layer, either as a
implementation may support HTTP over some other port as well. In single length or as a sequence of chunks each with a length.
Moore and Turner Expires May 16, 1999 It is REQUIRED that a printer implementation support HTTP over the
addition, a printer may have to support another port for privacy (See IANA assigned Well Known Port 631 (the IPP default port), though a
Section 5 "Security Considerations"). printer implementation may support HTTP over some other port as well.
In addition, a printer may have to support another port for privacy
(See Section 5 "Security Considerations").
Note: even though port 631 is the IPP default, port 80 remains the Note: even though port 631 is the IPP default, port 80 remains the
default for an HTTP URI. Thus a URI for a printer using port 631 MUST default for an HTTP URI. Thus a URI for a printer using port 631
contain an explicit port, e.g. "http://forest:631/pinetree". An HTTP MUST contain an explicit port, e.g. "http://forest:631/pinetree". An
URI for IPP with no explicit port implicitly reference port 80, which is HTTP URI for IPP with no explicit port implicitly reference port 80,
consistent with the rules for HTTP/1.1. Each HTTP operation MUST use the which is consistent with the rules for HTTP/1.1. Each HTTP operation
POST method where the request-URI is the object target of the operation, MUST use the POST method where the request-URI is the object target
and where the "Content-Type" of the message-body in each request and of the operation, and where the "Content-Type" of the message-body in
response MUST be "application/ipp". The message-body MUST contain the each request and response MUST be "application/ipp". The message-body
operation layer and MUST have the syntax described in section 3.2 MUST contain the operation layer and MUST have the syntax described
"Syntax of Encoding". A client implementation MUST adhere to the rules in section 3.2 "Syntax of Encoding". A client implementation MUST
for a client described for HTTP1.1 [rfc2068] . A printer (server) adhere to the rules for a client described for HTTP1.1 [RFC2068]. A
implementation MUST adhere the rules for an origin server described for printer (server) implementation MUST adhere the rules for an origin
HTTP1.1 [rfc2068] . server described for HTTP1.1 [RFC2068].
An IPP server sends a response for each request that it receives. If an An IPP server sends a response for each request that it receives. If
IPP server detects an error, it MAY send a response before it has read an IPP server detects an error, it MAY send a response before it has
the entire request. If the HTTP layer of the IPP server completes read the entire request. If the HTTP layer of the IPP server
processing the HTTP headers successfully, it MAY send an intermediate completes processing the HTTP headers successfully, it MAY send an
response, such as "100 Continue", with no IPP data before sending the intermediate response, such as "100 Continue", with no IPP data
IPP response. A client MUST expect such a variety of responses from an before sending the IPP response. A client MUST expect such a variety
IPP server. For further information on HTTP/1.1, consult the HTTP of responses from an IPP server. For further information on HTTP/1.1,
documents [rfc2068]. consult the HTTP documents [RFC2068].
5. Security Considerations 5. Security Considerations
The IPP Model document defines an IPP implementation with "privacy" as The IPP Model document defines an IPP implementation with "privacy"
one that implements Secure Socket Layer Version 3 (SSL3). Note: SSL3 as one that implements Secure Socket Layer Version 3 (SSL3). Note:
is not an IETF standards track specification. SSL3 meets the SSL3 is not an IETF standards track specification. SSL3 meets the
requirements for IPP security with regards to features such as mutual requirements for IPP security with regards to features such as mutual
authentication and privacy (via encryption). The IPP Model document also authentication and privacy (via encryption). The IPP Model document
outlines IPP-specific security considerations and should be the primary also outlines IPP-specific security considerations and should be the
reference for security implications with regards to the IPP protocol primary reference for security implications with regards to the IPP
itself. protocol itself.
The IPP Model document defines an IPP implementation with The IPP Model document defines an IPP implementation with
"authentication" as one that implements the standard way for "authentication" as one that implements the standard way for
transporting IPP messages within HTTP 1.1. These include the security transporting IPP messages within HTTP 1.1. These include the security
considerations outlined in the HTTP 1.1 standard document [rfc2068] and considerations outlined in the HTTP 1.1 standard document [RFC2068]
Digest Access Authentication extension [rfc2069]. and Digest Access Authentication extension [RFC2069].
The current HTTP infrastructure supports HTTP over TCP port 80. IPP The current HTTP infrastructure supports HTTP over TCP port 80. IPP
server implementations MUST offer IPP services using HTTP over the IANA server implementations MUST offer IPP services using HTTP over the
assigned Well Known Port 631 (the IPP default port). IPP server IANA assigned Well Known Port 631 (the IPP default port). IPP server
implementations may support other ports, in addition to this port. implementations may support other ports, in addition to this port.
See further discussion of IPP security concepts in the model document See further discussion of IPP security concepts in the model document
[ipp-mod]. [RFC2566].
Moore and Turner Expires May 16, 1999
5.1 Using IPP with SSL3 5.1 Using IPP with SSL3
An assumption is that the URI for a secure IPP Printer object has been An assumption is that the URI for a secure IPP Printer object has
found by means outside the IPP printing protocol, via a directory been found by means outside the IPP printing protocol, via a
service, web site or other means. directory service, web site or other means.
IPP provides a transparent connection to SSL by calling the IPP provides a transparent connection to SSL by calling the
corresponding URL (a https URI connects by default to port 443). corresponding URL (a https URI connects by default to port 443).
However, the following functions can be provided to ease the integration However, the following functions can be provided to ease the
of IPP with SSL during implementation: integration of IPP with SSL during implementation:
connect (URI), returns a status connect (URI), returns a status
"connect" makes an https call and returns the immediate status of "connect" makes an https call and returns the immediate status
the connection as returned by SSL to the user. The status values of the connection as returned by SSL to the user. The status
are explained in section 5.4.2 of the SSL document [ssl]. values are explained in section 5.4.2 of the SSL document
[ssl].
A session-id may also be retained to later resume a session. The A session-id may also be retained to later resume a session.
SSL handshake protocol may also require the cipher specifications The SSL handshake protocol may also require the cipher
supported by the client, key length of the ciphers, compression specifications supported by the client, key length of the
methods, certificates, etc. These should be sent to the server and ciphers, compression methods, certificates, etc. These should
hence should be available to the IPP client (although as part of be sent to the server and hence should be available to the IPP
administration features). client (although as part of administration features).
disconnect (session) disconnect (session)
to disconnect a particular session. to disconnect a particular session.
The session-id available from the "connect" could be used. The session-id available from the "connect" could be used.
resume (session) resume (session)
to reconnect using a previous session-id. to reconnect using a previous session-id.
The availability of this information as administration features are left The availability of this information as administration features are
for implementers, and need not be specified at this time. left for implementers, and need not be specified at this time.
6. References 6. References
[char] N. Freed, J. Postel: IANA Charset Registration Procedures, Work [RFC2278] Freed, N. and J. Postel, "IANA Charset Registration
in Progress (draft-freed-charset-reg-02.txt). Procedures", BCP 19, RFC 2278, January 1998.
[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:
notes/iana/assignments/character-sets. ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.
[ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.0: [ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.0:
Implementer's Guide", draft-ietf-ipp-implementers-guide-00.txt, Implementer's Guide", Work in Progress.
November 1998, work in progress.
Moore and Turner Expires May 16, 1999 [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
"Mapping between LPD and IPP Protocols", RFC 2569, April
1999.
[ipp-lpd] Herriot, R., Hastings, T., Jacobs, N., Martin, J., [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
"Mapping between LPD and IPP Protocols", draft-ietf-ipp-lpd-ipp- Powell, "Internet Printing Protocol/1.0: Model and
map-05.txt, November 1998. Semantics", RFC 2566, April 1999.
[ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. [RFC2565] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet
Powell, "Internet Printing Protocol/1.0: Model and Semantics", Printing Protocol/1.0: Encoding and Transport", RFC 2565,
<draft-ietf-ipp-model-11.txt>, November, 1998. April 1999.
[ipp-pro] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet [RFC2568] Zilles, S., "Rationale for the Structure and Model and
Printing Protocol/1.0: Encoding and Transport", draft-ietf-ipp- Protocol for the Internet Printing Protocol", RFC 2568,
pro-07.txt, November 1998. April 1999.
[ipp-rat] Zilles, S., "Rationale for the Structure and Model and [RFC2567] Wright, D., "Design Goals for an Internet Printing
Protocol for the Internet Printing Protocol", draft-ietf-ipp- Protocol", RFC 2567, April 1999.
rat-04.txt, November 1998.
[ipp-req] Wright, D., "Design Goals for an Internet Printing [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
Protocol", draft-ietf-ipp-req-03.txt, November, 1998. Messages", STD 11, RFC 822, August 1982.
[rfc822] Crocker, D., "Standard for the Format of ARPA [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
Internet Text Messages", RFC 822, August 1982. and Support", STD 3, RFC 1123, October 1989.
[rfc1123] Braden, S., "Requirements for Internet Hosts - [RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon
Application and Support", RFC 1123, October, 1989. Protocol" RFC 1179, August 1990.
[rfc1179] McLaughlin, L. III, (editor), "Line Printer Daemon [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
Protocol" RFC 1179, August 1990. RFC 2223, October 1997.
[rfc1543] Postel, J., "Instructions to RFC Authors", RFC 1543, [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
October 1993. Resource Locators (URL)", RFC 1738, December 1994.
[rfc1738] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
Resource Locators (URL)", RFC 1738, December, 1994. Gyllenskog, "Printer MIB", RFC 1759, March 1995.
[rfc1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and [RFC1766] Alvestrand, H., " Tags for the Identification of
Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. Languages", RFC 1766, March 1995.
[rfc1766] H. Alvestrand, " Tags for the Identification of [RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC
Languages", RFC 1766, March 1995. 1808, June 1995.
[rfc1808] R. Fielding, "Relative Uniform Resource Locators", [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual
RFC1808, June 1995. Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[rfc1903] J. Case, et al. "Textual Conventions for Version 2 of [RFC2046] Freed, N. and N. Borenstein, Multipurpose Internet Mail
the Simple Network Management Protocol (SNMPv2)", RFC 1903, Extensions (MIME) Part Two: Media Types", RFC 2046,
January 1996. November 1996.
[rfc2046] N. Freed & N. Borenstein, Multipurpose Internet Mail [RFC2048] Freed, N., Klensin J. and J. Postel. Multipurpose Internet
Extensions (MIME) Part Two: Media Types. November 1996, RFC 2046. Mail Extension (MIME) Part Four: Registration Procedures",
BCP 13, RFC 2048, November 1996.
[rfc2048] N. Freed, J. Klensin & J. Postel. Multipurpose Internet [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
Mail Extension (MIME) Part Four: Registration Procedures. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
November 1996 (Also BCP0013), RFC 2048. 2068, January 1997.
Moore and Turner Expires May 16, 1999 [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
Luotonen, A., Sink, E. and L. Stewart, "An Extension to
HTTP: Digest Access Authentication", RFC 2069, January
1997.
[rfc2068] R Fielding, et al, "Hypertext Transfer Protocol . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
HTTP/1.1" RFC 2068, January 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[rfc2069] J. Franks, et al, "An Extension to HTTP: Digest Access [RFC2184] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Authentication" RFC 2069, January 1997. Word Extensions: Character Sets, Languages, and
Continuations", RFC 2184, August 1997.
[rfc2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Requirement Levels", RFC 2119 , March 1997. Specifications: ABNF", RFC 2234. November 1997.
[rfc2184] N. Freed, K. Moore, "MIME Parameter Value and Encoded [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Word Extensions: Character Sets, Languages, and Continuations", Resource Identifiers (URI): Generic Syntax", RFC 2396,
RFC 2184, August 1997. August 1998.
[rfc2234] D. Crocker et al., "Augmented BNF for Syntax 7. Authors' Addresses
Specifications: ABNF", RFC 2234. November 1997.
[rfc2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Robert Herriot (Editor)
Resource Identifiers (URI): Generic Syntax", RFC 2396, August Xerox Corporation
1998. 3400 Hillview Ave., Bldg #1
Palo Alto, CA 94304
7. Author's Address Phone: 650-813-7696
Fax: 650-813-6860
EMail: rherriot@pahv.xerox.com
Paul Moore Sylvan Butler
Robert Herriot (editor) Hewlett-Packard
Microsoft 11311 Chinden Blvd.
Sun Microsystems Inc. Boise, ID 83714
One Microsoft Way
901 San Antonio Road, MPK-17
Redmond, WA 98053
Palo Alto, CA 94303
Phone: 425-936-0908 Phone: 208-396-6000
Phone: 650-786-8995 Fax: 208-396-3457
Fax: 425-93MS-FAX EMail: sbutler@boi.hp.com
Fax: 650-786-7077 Paul Moore
Email: paulmo@microsoft.com Microsoft
Email: robert.herriot@eng.sun.com One Microsoft Way
Redmond, WA 98053
Randy Turner Phone: 425-936-0908
Sylvan Butler Fax: 425-93MS-FAX
Sharp Laboratories EMail: paulmo@microsoft.com
Hewlett-Packard
5750 NW Pacific Rim Blvd
11311 Chinden Blvd.
Camas, WA 98607
Boise, ID 83714
Phone: 360-817-8456 Randy Turner
Phone: 208-396-6000 Sharp Laboratories
Fax: : 360-817-8436 5750 NW Pacific Rim Blvd
Fax: 208-396-3457 Camas, WA 98607
Email: rturner@sharplabs.com
Email: sbutler@boi.hp.com
IPP Mailing List: ipp@pwg.org Phone: 360-817-8456
IPP Mailing List Subscription: ipp-request@pwg.org Fax: 360-817-8436
IPP Web Page: http://www.pwg.org/ipp/ EMail: rturner@sharplabs.com
8. Other Participants: IPP Mailing List: ipp@pwg.org
IPP Mailing List Subscription: ipp-request@pwg.org
IPP Web Page: http://www.pwg.org/ipp/
Chuck Adams - Tektronix Harry Lewis - IBM 8. Other Participants:
Ron Bergman - Dataproducts Tony Liao - Vivid Image
Keith Carter - IBM David Manchala - Xerox
Angelo Caruso - Xerox Carl-Uno Manros - Xerox
Moore and Turner Expires May 16, 1999 Chuck Adams - Tektronix Harry Lewis - IBM
Jeff Copeland - QMS Jay Martin - Underscore Ron Bergman - Dataproducts Tony Liao - Vivid Image
Roger deBry - IBM Larry Masinter - Xerox Keith Carter - IBM David Manchala - Xerox
Lee Farrell - Canon Ira McDonald - High North Inc. Angelo Caruso - Xerox Carl-Uno Manros - Xerox
Sue Gleeson - Digital Bob Pentecost - Hewlett-Packard Jeff Copeland - QMS Jay Martin - Underscore
Charles Gordon - Osicom Patrick Powell - Astart Roger deBry - IBM Larry Masinter - Xerox
Lee Farrell - Canon Ira McDonald - High North Inc.
Sue Gleeson - Digital Bob Pentecost - Hewlett-Packard
Charles Gordon - Osicom Patrick Powell - Astart
Technologies Technologies
Brian Grimshaw - Apple Jeff Rackowitz - Intermec Brian Grimshaw - Apple Jeff Rackowitz - Intermec
Jerry Hadsell - IBM Xavier Riley - Xerox Jerry Hadsell - IBM Xavier Riley - Xerox
Richard Hart - Digital Gary Roberts - Ricoh Richard Hart - Digital Gary Roberts - Ricoh
Tom Hastings - Xerox Stuart Rowley - Kyocera Tom Hastings - Xerox Stuart Rowley - Kyocera
Stephen Holmstead Richard Schneider - Epson Stephen Holmstead Richard Schneider - Epson
Zhi-Hong Huang - Zenographics Shigern Ueda - Canon Zhi-Hong Huang - Zenographics Shigern Ueda - Canon
Scott Isaacson - Novell Bob Von Andel - Allegro Software Scott Isaacson - Novell Bob Von Andel - Allegro Software
Rich Lomicka - Digital William Wagner - Digital Products Rich Lomicka - Digital William Wagner - Digital Products
David Kellerman - Northlake Jasper Wong - Xionics David Kellerman - Northlake Jasper Wong - Xionics
Software Software
Robert Kline - TrueSpectra Don Wright - Lexmark Robert Kline - TrueSpectra Don Wright - Lexmark
Dave Kuntz - Hewlett-Packard Rick Yardumian - Xerox Dave Kuntz - Hewlett-Packard Rick Yardumian - Xerox
Takami Kurono - Brother Lloyd Young - Lexmark Takami Kurono - Brother Lloyd Young - Lexmark
Rich Landau - Digital Peter Zehler - Xerox Rich Landau - Digital Peter Zehler - Xerox
Greg LeClair - Epson Frank Zhao - Panasonic Greg LeClair - Epson Frank Zhao - Panasonic
Steve Zilles - Adobe Steve Zilles - Adobe
9. Appendix A: Protocol Examples 9. Appendix A: Protocol Examples
9.1 Print-Job Request 9.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
set to 'true' so that the print request will fail if the "copies" or the is set to 'true' so that the print request will fail if the "copies"
"sides" attribute are not supported or their values are not supported. or the "sides" attribute are not supported or their values are not
supported.
Octets Symbolic Value Protocol field
0x0100 1.0 version-number
0x0002 Print-Job operation-id
0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
en-us en-US value
0x45 uri type value-tag
0x000B name-length
Moore and Turner Expires May 16, 1999 Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
printer-uri printer-uri name 0x0100 1.0 version-number
0x001A value-length 0x0002 Print-Job operation-id
http://forest: printer pinetree value 0x00000001 1 request-id
631/pinetree 0x01 start operation-attributes operation-attributes-tag
0x42 nameWithoutLanguage type value-tag 0x47 charset type value-tag
0x0008 name-length 0x0012 name-length
job-name job-name name attributes- attributes-charset name
0x0006 value-length charset
foobar foobar value 0x0008 value-length
0x22 boolean type value-tag us-ascii US-ASCII value
0x16 name-length 0x48 natural-language type value-tag
ipp-attribute- ipp-attribute-fidelity name 0x001B name-length
fidelity attributes- attributes-natural-language name
0x01 value-length natural-
0x01 true value language
0x02 start job-attributes job-attributes-tag 0x0005 value-length
0x21 integer type value-tag en-us en-US value
0x0006 name-length 0x45 uri type value-tag
copies copies name 0x000B name-length
0x0004 value-length printer-uri printer-uri name
0x00000014 20 value 0x001A value-length
0x44 keyword type value-tag http://forest: printer pinetree value
0x0005 name-length 631/pinetree
sides sides name 0x42 nameWithoutLanguage type value-tag
0x0013 value-length 0x0008 name-length
two-sided- two-sided-long-edge value job-name job-name name
long-edge 0x0006 value-length
0x03 end-of-attributes end-of-attributes-tag foobar foobar value
%!PS... <PostScript> data 0x22 boolean type value-tag
0x16 name-length
ipp-attribute- ipp-attribute-fidelity name
fidelity
0x01 value-length
0x01 true value
0x02 start job-attributes job-attributes-tag
0x21 integer type value-tag
0x0006 name-length
copies copies name
0x0004 value-length
0x00000014 20 value
0x44 keyword type value-tag
0x0005 name-length
sides sides name
0x0013 value-length
two-sided- two-sided-long-edge value
long-edge
0x03 end-of-attributes end-of-attributes-tag
%!PS... <PostScript> data
9.2 Print-Job Response (successful) 9.2 Print-Job Response (successful)
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
0x0100 1.0 version-number Octets Symbolic Value Protocol field
0x0000 successful-ok status-code
0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural- name
Moore and Turner Expires May 16, 1999 0x0100 1.0 version-number
Octets Symbolic Value Protocol field 0x0000 successful-ok status-code
0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural- name
natural-language language
0x0005 value-length
en-us en-US value
0x41 textWithoutLanguage type value-tag
0x000E name-length
status-message status-message name
0x000D value-length
successful-ok successful-ok value
0x02 start job-attributes job-attributes-tag
0x21 integer value-tag
0x0006 name-length
Octets Symbolic Value Protocol field
natural-language language job-id job-id name
0x0005 value-length 0x0004 value-length
en-us en-US value 147 147 value
0x41 textWithoutLanguage type value-tag 0x45 uri type value-tag
0x000E name-length 0x0007 name-length
status-message status-message name job-uri job-uri name
0x000D value-length 0x001E value-length
successful-ok successful-ok value http://forest:63 job 123 on pinetree value
0x02 start job-attributes job-attributes-tag 1/pinetree/123
0x21 integer value-tag 0x42 nameWithoutLanguage type value-tag
0x0006 name-length 0x0009 name-length
job-id job-id name job-state job-state name
0x0004 value-length 0x0004 value-length
147 147 value 0x0003 pending value
0x45 uri type value-tag 0x03 end-of-attributes end-of-attributes-tag
0x0007 name-length
job-uri job-uri name
0x001E value-length
http://forest:63 job 123 on pinetree value
1/pinetree/123
0x42 nameWithoutLanguage type value-tag
0x0009 name-length
job-state job-state name
0x0004 value-length
0x0003 pending value
0x03 end-of-attributes end-of-attributes-tag
9.3 Print-Job Response (failure) 9.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
Print-Job request. It fails because, in this case, the printer does not previous Print-Job request. It fails because, in this case, the
support the "sides" attribute and because the value '20' for the printer does not support the "sides" attribute and because the value
"copies" attribute is not supported. Therefore, no job is created, and '20' for the "copies" attribute is not supported. Therefore, no job
neither a "job-id" nor a "job-uri" operation attribute is returned. The is created, and neither a "job-id" nor a "job-uri" operation
error code returned is 'client-error-attributes-or-values-not-supported' attribute is returned. The error code returned is 'client-error-
(0x040B). attributes-or-values-not-supported' (0x040B).
Octets Symbolic Value Protocol field
0x0100 1.0 version-number Octets Symbolic Value Protocol field
0x040B client-error-attributes-or- status-code
values-not-supported
0x00000001 1 request-id
0x01 start operation-attributes operation-attribute tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
Moore and Turner Expires May 16, 1999 0x0100 1.0 version-number
Octets Symbolic Value Protocol field 0x040B client-error-attributes-or- status-code
values-not-supported
0x00000001 1 request-id
0x01 start operation-attributes operation-attribute tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
Octets Symbolic Value Protocol field
attributes- attributes-natural-language name en-us en-US value
natural- 0x41 textWithoutLanguage type value-tag
language 0x000E name-length
0x0005 value-length status- status-message name
en-us en-US value message
0x41 textWithoutLanguage type value-tag 0x002F value-length
0x000E name-length client-error- client-error-attributes-or- value
status- status-message name attributes- values-not-supported
message or-values-
0x002F value-length not-supported
client-error- client-error-attributes-or- value 0x05 start unsupported-attributes unsupported-attributes tag
attributes- values-not-supported 0x21 integer type value-tag
or-values- 0x0006 name-length
not-supported copies copies name
0x05 start unsupported-attributes unsupported-attributes tag 0x0004 value-length
0x21 integer type value-tag 0x00000014 20 value
0x0006 name-length 0x10 unsupported (type) value-tag
copies copies name 0x0005 name-length
0x0004 value-length sides sides name
0x00000014 20 value 0x0000 value-length
0x10 unsupported (type) value-tag 0x03 end-of-attributes end-of-attributes-tag
0x0005 name-length
sides sides name
0x0000 value-length
0x03 end-of-attributes end-of-attributes-tag
9.4 Print-Job Response (success with attributes ignored) 9.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"
nor the value '20' for the "copies" attribute. Therefore, a job is attribute nor the value '20' for the "copies" attribute. Therefore, a
created, and both a "job-id" and a "job-uri" operation attribute are job is created, and both a "job-id" and a "job-uri" operation
returned. The unsupported attributes are also returned in an Unsupported attribute are returned. The unsupported attributes are also returned
Attributes Group. The error code returned is 'successful-ok-ignored-or- in an Unsupported Attributes Group. The error code returned is '
substituted-attributes' (0x0001). successful-ok-ignored-or-substituted-attributes' (0x0001).
Octets Symbolic Value Protocol field
0x0100 1.0 version-number Octets Symbolic Value Protocol field
0x0001 successful-ok-ignored-or- status-code
substituted-attributes
0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
Moore and Turner Expires May 16, 1999 0x0100 1.0 version-number
Octets Symbolic Value Protocol field 0x0001 successful-ok-ignored-or- status-code
substituted-attributes
0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
Octets Symbolic Value Protocol field
0x001B name-length us-ascii US-ASCII value
attributes- attributes-natural- name 0x48 natural-language type value-tag
natural-language language 0x001B name-length
0x0005 value-length attributes- attributes-natural- name
en-us en-US value natural-language language
0x41 textWithoutLanguage type value-tag 0x0005 value-length
0x000E name-length en-us en-US value
status-message status-message name 0x41 textWithoutLanguage type value-tag
0x002F value-length 0x000E name-length
successful-ok- successful-ok-ignored-or- value status-message status-message name
ignored-or- substituted-attributes 0x002F value-length
substituted- successful-ok- successful-ok-ignored-or- value
attributes ignored-or- substituted-attributes
0x05 start unsupported- unsupported-attributes substituted-
attributes tag attributes
0x21 integer type value-tag 0x05 start unsupported- unsupported-attributes
0x0006 name-length attributes tag
copies copies name 0x21 integer type value-tag
0x0004 value-length 0x0006 name-length
0x00000014 20 value copies copies name
0x10 unsupported (type) value-tag 0x0004 value-length
0x0005 name-length 0x00000014 20 value
sides sides name 0x10 unsupported (type) value-tag
0x0000 value-length 0x0005 name-length
0x02 start job-attributes job-attributes-tag sides sides name
0x21 integer value-tag 0x0000 value-length
0x0006 name-length 0x02 start job-attributes job-attributes-tag
job-id job-id name 0x21 integer value-tag
0x0004 value-length 0x0006 name-length
147 147 value job-id job-id name
0x45 uri type value-tag 0x0004 value-length
0x0007 name-length 147 147 value
job-uri job-uri name 0x45 uri type value-tag
0x001E value-length 0x0007 name-length
http://forest:63 job 123 on pinetree value job-uri job-uri name
1/pinetree/123 0x001E value-length
0x42 nameWithoutLanguage type value-tag http://forest:63 job 123 on pinetree value
0x0009 name-length 1/pinetree/123
job-state job-state name 0x42 nameWithoutLanguage type value-tag
0x0004 value-length 0x0009 name-length
0x0003 pending value job-state job-state name
0x03 end-of-attributes end-of-attributes-tag 0x0004 value-length
0x0003 pending value
0x03 end-of-attributes end-of-attributes-tag
9.5 Print-URI Request 9.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
name parameters: job-name parameters:
Octets Symbolic Value Protocol field Octets Symbolic Value Protocol field
0x0100 1.0 version-number
Moore and Turner Expires May 16, 1999 0x0100 1.0 version-number
Octets Symbolic Value Protocol field
0x0003 Print-URI operation-id Octets Symbolic Value Protocol field
0x00000001 1 request-id 0x0003 Print-URI operation-id
0x01 start operation-attributes operation-attributes-tag 0x00000001 1 request-id
0x47 charset type value-tag 0x01 start operation-attributes operation-attributes-tag
0x0012 name-length 0x47 charset type value-tag
attributes- attributes-charset name 0x0012 name-length
charset attributes- attributes-charset name
0x0008 value-length charset
us-ascii US-ASCII value 0x0008 value-length
0x48 natural-language type value-tag us-ascii US-ASCII value
0x001B name-length 0x48 natural-language type value-tag
attributes- attributes-natural-language name 0x001B name-length
natural- attributes- attributes-natural-language name
language natural-
0x0005 value-length language
en-us en-US value 0x0005 value-length
0x45 uri type value-tag en-us en-US value
0x000B name-length 0x45 uri type value-tag
printer-uri printer-uri name 0x000B name-length
0x001A value-length printer-uri printer-uri name
http://forest printer pinetree value 0x001A value-length
:631/pinetree http://forest printer pinetree value
0x45 uri type value-tag :631/pinetree
0x000C name-length 0x45 uri type value-tag
document-uri document-uri name 0x000C name-length
0x11 value-length document-uri document-uri name
ftp://foo.com ftp://foo.com/foo value 0x11 value-length
/foo ftp://foo.com ftp://foo.com/foo value
0x42 nameWithoutLanguage type value-tag /foo
0x0008 name-length 0x42 nameWithoutLanguage type value-tag
job-name job-name name 0x0008 name-length
0x0006 value-length job-name job-name name
foobar foobar value 0x0006 value-length
0x02 start job-attributes job-attributes-tag foobar foobar value
0x21 integer type value-tag 0x02 start job-attributes job-attributes-tag
0x0006 name-length 0x21 integer type value-tag
copies copies name 0x0006 name-length
0x0004 value-length copies copies name
0x00000001 1 value 0x0004 value-length
0x03 end-of-attributes end-of-attributes-tag 0x00000001 1 value
0x03 end-of-attributes end-of-attributes-tag
9.6 Create-Job Request 9.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
no attributes: and no attributes:
Octets Symbolic Value Protocol field Octets Symbolic Value Protocol field
0x0100 1.0 version-number 0x0100 1.0 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
0x47 charset type value-tag 0x47 charset type value-tag
0x0012 name-length 0x0012 name-length
Moore and Turner Expires May 16, 1999 Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field 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-language name
attributes- attributes-natural-language name natural-
natural- language
language 0x0005 value-length
0x0005 value-length en-us en-US value
en-us en-US value 0x45 uri type value-tag
0x45 uri type value-tag 0x000B name-length
0x000B name-length printer-uri printer-uri name
printer-uri printer-uri name 0x001A value-length
0x001A value-length http://forest: printer pinetree value
http://forest: printer pinetree value 631/pinetree
631/pinetree 0x03 end-of-attributes end-of-attributes-tag
0x03 end-of-attributes end-of-attributes-tag
9.7 Get-Jobs Request 9.7 Get-Jobs Request
The following is an example of Get-Jobs request with parameters but no The following is an example of Get-Jobs request with parameters but
attributes: no attributes:
Octets Symbolic Value Protocol field
0x0100 1.0 version-number
0x000A Get-Jobs operation-id
0x00000123 0x123 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
en-us en-US value
0x45 uri type value-tag
0x000B name-length
printer-uri printer-uri name
0x001A value-length
http://forest:6 printer pinetree value
31/pinetree
0x21 integer type value-tag
0x0005 name-length
limit limit name
0x0004 value-length
0x00000032 50 value
Moore and Turner Expires May 16, 1999 Octets Symbolic Value Protocol field
Octets Symbolic Value Protocol field
0x44 keyword type value-tag
0x0014 name-length
requested- requested-attributes name
attributes
0x0006 value-length
job-id job-id value
0x44 keyword type value-tag
0x0000 additional value name-length
0x0008 value-length
job-name job-name value
0x44 keyword type value-tag
0x0000 additional value name-length
0x000F value-length
document-format document-format value
0x03 end-of-attributes end-of-attributes-tag
9.8 Get-Jobs Response 0x0100 1.0 version-number
0x000A Get-Jobs operation-id
0x00000123 0x123 request-id
0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag
Octets Symbolic Value Protocol field
The following is an of Get-Jobs response from previous request with 3 0x0012 name-length
jobs. The Printer returns no information about the second job (because attributes- attributes-charset name
of security reasons): charset
0x0008 value-length
us-ascii US-ASCII value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
en-us en-US value
0x45 uri type value-tag
0x000B name-length
printer-uri printer-uri name
0x001A value-length
http://forest:6 printer pinetree value
31/pinetree
0x21 integer type value-tag
0x0005 name-length
limit limit name
0x0004 value-length
0x00000032 50 value
0x44 keyword type value-tag
0x0014 name-length
requested- requested-attributes name
attributes
0x0006 value-length
job-id job-id value
0x44 keyword type value-tag
0x0000 additional value name-length
0x0008 value-length
job-name job-name value
0x44 keyword type value-tag
0x0000 additional value name-length
0x000F value-length
document-format document-format value
0x03 end-of-attributes end-of-attributes-tag
Octets Symbolic Value Protocol field 9.8 Get-Jobs Response
0x0100 1.0 version-number
0x0000 successful-ok status-code
0x00000123 0x123 request-id (echoed
back)
0x01 start operation-attributes operation-attribute-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x000A value-length
ISO-8859-1 ISO-8859-1 value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
en-us en-US value
0x41 textWithoutLanguage type value-tag
0x000E name-length
status-message status-message name
0x000D value-length
successful-ok successful-ok value
0x02 start job-attributes (1st job-attributes-tag
object)
0x21 integer type value-tag
0x0006 name-length
job-id job-id name
0x0004 value-length
147 147 value
Moore and Turner Expires May 16, 1999 The following is an of Get-Jobs response from previous request with 3
Octets Symbolic Value Protocol field jobs. The Printer returns no information about the second job
0x36 nameWithLanguage value-tag (because of security reasons):
0x0008 name-length
job-name job-name name
0x000C value-length
0x0005 sub-value-length
fr-ca fr-CA value
0x0003 sub-value-length
fou fou name
0x02 start job-attributes (2nd job-attributes-tag
object)
0x02 start job-attributes (3rd job-attributes-tag
object)
0x21 integer type value-tag
0x0006 name-length
job-id job-id name
0x0004 value-length
148 148 value
0x36 nameWithLanguage value-tag
0x0008 name-length
job-name job-name name
0x0012 value-length
0x0005 sub-value-length
de-CH de-CH value
0x0009 sub-value-length
isch guet isch guet name
0x03 end-of-attributes end-of-attributes-tag
10. Appendix C: Registration of MIME Media Type Information for Octets Symbolic Value Protocol field
"application/ipp"
This appendix contains the information that IANA requires for 0x0100 1.0 version-number
registering a MIME media type. The information following this paragraph 0x0000 successful-ok status-code
will be forwarded to IANA to register application/ipp whose contents are 0x00000123 0x123 request-id (echoed
defined in Section 3 "Encoding of the Operation Layer" in this back)
document: 0x01 start operation-attributes operation-attribute-tag
0x47 charset type value-tag
0x0012 name-length
attributes- attributes-charset name
charset
0x000A value-length
ISO-8859-1 ISO-8859-1 value
0x48 natural-language type value-tag
0x001B name-length
attributes- attributes-natural-language name
natural-
language
0x0005 value-length
en-us en-US value
0x41 textWithoutLanguage type value-tag
0x000E name-length
status-message status-message name
0x000D value-length
successful-ok successful-ok value
0x02 start job-attributes (1st job-attributes-tag
object)
0x21 integer type value-tag
0x0006 name-length
job-id job-id name
0x0004 value-length
147 147 value
0x36 nameWithLanguage value-tag
0x0008 name-length
job-name job-name name
0x000C value-length
0x0005 sub-value-length
fr-ca fr-CA value
0x0003 sub-value-length
fou fou name
0x02 start job-attributes (2nd job-attributes-tag
object)
0x02 start job-attributes (3rd job-attributes-tag
object)
0x21 integer type value-tag
0x0006 name-length
job-id job-id name
0x0004 value-length
Octets Symbolic Value Protocol field
MIME type name: application 148 148 value
0x36 nameWithLanguage value-tag
0x0008 name-length
job-name job-name name
0x0012 value-length
0x0005 sub-value-length
de-CH de-CH value
0x0009 sub-value-length
isch guet isch guet name
0x03 end-of-attributes end-of-attributes-tag
MIME subtype name: ipp 10. Appendix C: Registration of MIME Media Type Information for
"application/ipp"
A Content-Type of "application/ipp" indicates an Internet Printing This appendix contains the information that IANA requires for
Protocol message body (request or response). Currently there is one registering a MIME media type. The information following this
version: IPP/1.0, whose syntax is described in Section 3 "Encoding of paragraph will be forwarded to IANA to register application/ipp whose
the Operation Layer" of [ipp-pro], and whose semantics are described in contents are defined in Section 3 "Encoding of the Operation Layer"
[ipp-mod]. in this document:
Required parameters: none MIME type name: application
Optional parameters: none MIME subtype name: ipp
Encoding considerations: A Content-Type of "application/ipp" indicates an Internet Printing
Protocol message body (request or response). Currently there is one
version: IPP/1.0, whose syntax is described in Section 3 "Encoding of
the Operation Layer" of [RFC2565], and whose semantics are described
in [RFC2566].
Moore and Turner Expires May 16, 1999 Required parameters: none
IPP/1.0 protocol requests/responses MAY contain long lines and ALWAYS
contain binary data (for example attribute value lengths).
Security considerations: Optional parameters: none
IPP/1.0 protocol requests/responses do not introduce any security risks Encoding considerations:
not already inherent in the underlying transport protocols. Protocol
mixed-version interworking rules in [ipp-mod] as well as protocol
encoding rules in [ipp-pro] are complete and unambiguous.
Interoperability considerations: IPP/1.0 protocol requests/responses MAY contain long lines and ALWAYS
contain binary data (for example attribute value lengths).
IPP/1.0 requests (generated by clients) and responses (generated by Security considerations:
servers) MUST comply with all conformance requirements imposed by the
normative specifications [ipp-mod] and [ipp-pro]. Protocol encoding
rules specified in [ipp-pro] are comprehensive, so that interoperability
between conforming implementations is guaranteed (although support for
specific optional features is not ensured). Both the "charset" and
"natural-language" of all IPP/1.0 attribute values which are a
LOCALIZED-STRING are explicit within IPP protocol requests/responses
(without recourse to any external information in HTTP, SMTP, or other
message transport headers).
Published specification: IPP/1.0 protocol requests/responses do not introduce any security
risks not already inherent in the underlying transport protocols.
Protocol mixed-version interworking rules in [RFC2566] as well as
protocol encoding rules in [RFC2565] are complete and unambiguous.
[ipp-mod] Isaacson, S., deBry, R., Hastings, T., Herriot, R., Interoperability considerations:
Powell, P., "Internet Printing Protocol/1.0: Model and
Semantics" draft-ietf-ipp-mod-11.txt, November, 1998.
[ipp-pro] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet IPP/1.0 requests (generated by clients) and responses (generated by
Printing Protocol/1.0: Encoding and Transport", draft-ietf-ipp- servers) MUST comply with all conformance requirements imposed by the
pro-07.txt, November, 1998. normative specifications [RFC2566] and [RFC2565]. Protocol encoding
rules specified in [RFC2565] are comprehensive, so that
interoperability between conforming implementations is guaranteed
(although support for specific optional features is not ensured).
Both the "charset" and "natural-language" of all IPP/1.0 attribute
values which are a LOCALIZED-STRING are explicit within IPP protocol
requests/responses (without recourse to any external information in
HTTP, SMTP, or other message transport headers).
Applications which use this media type: Published specification:
Internet Printing Protocol (IPP) print clients and print servers, [RFC2566] Isaacson, S., deBry, R., Hastings, T., Herriot, R. and P.
communicating using HTTP/1.1 (see [IPP-PRO]), SMTP/ESMTP, FTP, or other Powell, "Internet Printing Protocol/1.0: Model and
transport protocol. Messages of type "application/ipp" are self- Semantics" RFC 2566, April 1999.
contained and transport-independent, including "charset" and "natural-
language" context for any LOCALIZED-STRING value.
Person & email address to contact for further information: [RFC2565] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet
Printing Protocol/1.0: Encoding and Transport", RFC 2565,
April 1999.
Scott A. Isaacson Applications which use this media type:
Novell, Inc.
122 E 1700 S
Provo, UT 84606
Phone: 801-861-7366 Internet Printing Protocol (IPP) print clients and print servers,
Fax: 801-861-4025 communicating using HTTP/1.1 (see [RFC2565]), SMTP/ESMTP, FTP, or
Email: sisaacson@novell.com other transport protocol. Messages of type "application/ipp" are
self-contained and transport-independent, including "charset" and
"natural-language" context for any LOCALIZED-STRING value.
or Person & email address to contact for further information:
Moore and Turner Expires May 16, 1999 Scott A. Isaacson
Robert Herriot Novell, Inc.
Sun Microsystems Inc. 122 E 1700 S
901 San Antonio Road, MPK-17 Provo, UT 84606
Palo Alto, CA 94303
Phone: 650-786-8995 Phone: 801-861-7366
Fax: 650-786-7077 Fax: 801-861-4025
Email: robert.herriot@eng.sun.com Email: sisaacson@novell.com
Intended usage: or
COMMON Robert Herriot (Editor)
Xerox Corporation
3400 Hillview Ave., Bldg #1
Palo Alto, CA 94304
11. Appendix D: Full Copyright Statement Phone: 650-813-7696
Fax: 650-813-6860
EMail: rherriot@pahv.xerox.com
Copyright (C)The Internet Society (1998). All Rights Reserved 11. Full Copyright Statement
This document and translations of it may be copied and furnished to Copyright (C) The Internet Society (1999). All Rights Reserved.
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
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
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be This document and translations of it may be copied and furnished to
revoked by the Internet Society or its successors or assigns. others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included 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 or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
This document and the information contained herein is provided on an "AS The limited permissions granted above are perpetual and will not be
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK revoked by the Internet Society or its successors or assigns.
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Moore and Turner Expires May 16, 1999 This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 233 change blocks. 
1189 lines changed or deleted 1159 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/