draft-ietf-ipp-protocol-v11-03.txt   draft-ietf-ipp-protocol-v11-04.txt 
INTERNET-DRAFT Robert Herriot (editor) INTERNET-DRAFT Robert Herriot (editor)
<draft-ietf-ipp-protocol-v11-03.txt> Xerox Corporation <draft-ietf-ipp-protocol-v11-04.txt> Xerox Corporation
Sylvan Butler Sylvan Butler
Hewlett-Packard Hewlett-Packard
Paul Moore Paul Moore
Microsoft Peerless Systems Networking
Randy Turner Randy Turner
2wire.com 2wire.com
John Wenn John Wenn
Xerox Corporation Xerox Corporation
June 23, 1999 February 23, 2000
Internet Printing Protocol/1.1: Encoding and Transport Internet Printing Protocol/1.1: Encoding and Transport
Copyright (C)The Internet Society (2000). All Rights Reserved.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC2026]. Internet-Drafts are working provisions of Section 10 of [RFC2026]. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress". or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed as The list of Internet-Draft Shadow Directories can be accessed as
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C)The Internet Society (1998, 1999). All Rights Reserved.
Abstract Abstract
This document is one of a set of documents, which together describe all This document is one of a set of documents, which together describe all
aspects of a new Internet Printing Protocol (IPP). IPP is an application aspects of a new Internet Printing Protocol (IPP). IPP is an application
level protocol that can be used for distributed printing using Internet level protocol that can be used for distributed printing using Internet
tools and technologies. This document defines the rules for encoding IPP tools and technologies. This document defines the rules for encoding IPP
operations and IPP attributes into a new Internet mime media type called operations and IPP attributes into a new Internet mime media type called
"application/ipp". This document also defines the rules for "application/ipp". This document also defines the rules for
transporting over HTTP a message body whose Content-Type is transporting over HTTP a message body whose Content-Type is
"application/ipp". This document defines a new scheme named 'ipp' for "application/ipp". This document defines a new scheme named 'ipp' for
skipping to change at page 3, line 7 skipping to change at page 3, line 7
The document "Internet Printing Protocol/1.1: Implementer's Guide", The document "Internet Printing Protocol/1.1: Implementer's Guide",
gives advice to implementers of IPP clients and IPP objects. gives advice to implementers of IPP clients and IPP objects.
The document "Mapping between LPD and IPP Protocols" gives some advice The document "Mapping between LPD and IPP Protocols" gives some advice
to implementers of gateways between IPP and LPD (Line Printer Daemon) to implementers of gateways between IPP and LPD (Line Printer Daemon)
implementations. implementations.
Table of Contents Table of Contents
1. Introduction........................................................4 1. Introduction........................................................3
2. Conformance Terminology.............................................4 2. Conformance Terminology.............................................4
3. Encoding of the Operation Layer....................................4 3. Encoding of the Operation Layer....................................4
3.1 Picture of the Encoding........................................5 3.1 Picture of the Encoding........................................5
3.2 Syntax of Encoding.............................................7 3.2 Syntax of Encoding.............................................7
3.3 Version-number.................................................8 3.3 Version-number.................................................8
3.4 Operation-id...................................................8 3.4 Operation-id...................................................8
3.5 Status-code....................................................9 3.5 Status-code....................................................9
3.6 Request-id.....................................................9 3.6 Request-id.....................................................9
3.7 Tags...........................................................9 3.7 Tags...........................................................9
3.7.1 Delimiter Tags...........................................9 3.7.1 Delimiter Tags...........................................9
3.7.2 Value Tags..............................................11 3.7.2 Value Tags..............................................11
3.8 Name-Length...................................................12 3.8 Name-Length...................................................13
3.9 (Attribute) Name..............................................12 3.9 (Attribute) Name..............................................13
3.10Value Length..................................................14 3.10Value Length..................................................15
3.11(Attribute) Value.............................................15 3.11(Attribute) Value.............................................15
3.12Data..........................................................17 3.12Data..........................................................17
4. Encoding of Transport Layer........................................17 4. Encoding of Transport Layer........................................17
5. IPP URL Scheme.....................................................18 5. IPP URL Scheme.....................................................18
6. Security Considerations............................................19 6. IANA Considerations................................................19
6.1 Security Conformance Requirements.............................20 7. Internationalization Considerations................................20
6.1.1 Digest Authentication...................................20 8. Security Considerations............................................20
6.1.2 Transport Layer Security (TLS)..........................20 8.1 Security Conformance Requirements.............................20
6.2 Using IPP with TLS............................................21 8.1.1 Digest Authentication...................................20
7. Interoperability with IPP/1.0 Implementations......................21 8.1.2 Transport Layer Security (TLS)..........................21
7.1 The "version-number" Parameter................................21 8.2 Using IPP with TLS............................................22
7.2 Security and URL Schemes......................................22 9. Interoperability with IPP/1.0 Implementations......................22
8. References.........................................................23 9.1 The "version-number" Parameter................................22
9. Author's Address...................................................24 9.2 Security and URL Schemes......................................23
10.Other Participants:...............................................25 10.References........................................................23
11.Appendix A: Protocol Examples.....................................26 11.Author's Address..................................................25
11.1Print-Job Request.............................................26 12.Other Participants:...............................................27
11.2Print-Job Response (successful)...............................27 13.Appendix A: Protocol Examples.....................................28
11.3Print-Job Response (failure)..................................28 13.1Print-Job Request.............................................28
11.4Print-Job Response (success with attributes ignored)..........29 13.2Print-Job Response (successful)...............................29
11.5Print-URI Request.............................................32 13.3Print-Job Response (failure)..................................30
11.6Create-Job Request............................................33 13.4Print-Job Response (success with attributes ignored)..........31
11.7Get-Jobs Request..............................................34 13.5Print-URI Request.............................................34
11.8Get-Jobs Response.............................................35 13.6Create-Job Request............................................35
12.Appendix C: Registration of MIME Media Type Information for 13.7Get-Jobs Request..............................................36
"application/ipp".....................................................37 13.8Get-Jobs Response.............................................37
13.Appendix D: Changes from IPP /1.0.................................38 14.Appendix B: Registration of MIME Media Type Information for
14.Full Copyright Statement..........................................39 "application/ipp".....................................................39
15.Appendix C: Changes from IPP/1.0..................................40
16.Full Copyright Statement..........................................41
1. Introduction 1. Introduction
This document contains the rules for encoding IPP operations and This document contains the rules for encoding IPP operations and
describes two layers: the transport layer and the operation layer. describes two layers: the transport layer and the operation layer.
The transport layer consists of an HTTP/1.1 request or response. RFC The transport layer consists of an HTTP/1.1 request or response. RFC
2616 [RFC2616] describes HTTP/1.1. This document specifies the HTTP 2616 [RFC2616] describes HTTP/1.1. This document specifies the HTTP
headers that an IPP implementation supports. headers that an IPP implementation supports.
skipping to change at page 8, line 55 skipping to change at page 9, line 5
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 (0x01)
and a minor version-number of 1 (0x01). The ABNF for these two bytes and a minor version-number of 1 (0x01). The ABNF for these two bytes
MUST be %x01.01. MUST be %x01.01.
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 operation-
ids enum value MUST be encoded as a SIGNED-SHORT. ids enum value MUST be encoded as a SIGNED-SHORT.
Note: the values 0x4000 to 0xFFFF are reserved for private extensions.
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-code
enum value MUST be encoded as a SIGNED-SHORT. 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 the
protocol, the status-code is in a special position, outside of the protocol, the status-code is in a special position, outside of the
operation attributes. 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 200
skipping to change at page 10, line 7 skipping to change at page 10, line 7
attributes and data attributes and data
- value tags: specify the type of each attribute value - value tags: specify the type of each attribute value
3.7.1 Delimiter Tags 3.7.1 Delimiter Tags
The following table specifies the values for the delimiter tags: The following table specifies the values for the delimiter tags:
Tag Value (Hex) Delimiter Tag Value (Hex) Delimiter
0x00 reserved 0x00 reserved for definition in a future IETF
standards track document
0x01 operation-attributes-tag 0x01 operation-attributes-tag
0x02 job-attributes-tag 0x02 job-attributes-tag
0x03 end-of-attributes-tag 0x03 end-of-attributes-tag
0x04 printer-attributes-tag 0x04 printer-attributes-tag
0x05 unsupported-attributes-tag 0x05 unsupported-attributes-tag
0x06-0x0e reserved for future delimiters 0x06-0x0e reserved for future delimiters in IETF
standards track documents
0x0F reserved for future chunking-end-of-attributes- 0x0F reserved for future chunking-end-of-attributes-
tag tag for definition in a future IETF standards
track document
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, it
MUST mean that the zero or more following attributes up to the next MUST mean that the zero or more following attributes up to the next
delimiter tag are operation attributes as defined in the model document. delimiter tag are operation attributes as defined in the model document.
skipping to change at page 10, line 49 skipping to change at page 10, line 52
delimiter. If the operation has a document-content group, the document delimiter. If the operation has a document-content group, the document
data in that group MUST follow the end-of-attributes-tag. data in that group MUST follow the end-of-attributes-tag.
Each of the other three xxx-attributes-tags defined above is OPTIONAL Each of the other three xxx-attributes-tags defined above is OPTIONAL
in an operation and each MUST occur at most once in an operation, except in an operation and each MUST occur at most once in an operation, except
for job-attributes-tag in a Get-Jobs response which may occur zero or for job-attributes-tag in a Get-Jobs response which may occur zero or
more times. more times.
The order and presence of delimiter tags for each operation request and The order and presence of delimiter tags for each operation request and
each operation response MUST be that defined in the model document. For each operation response MUST be that defined in the model document. For
further details, see section 3.9 "(Attribute) Name" and 11 "Appendix A: further details, see section 3.9 "Operation Requests and Responses" and
Protocol Examples". 13 "Appendix A: Protocol Examples".
A Printer MUST treat the reserved delimiter tags differently from A Printer MUST treat the reserved delimiter tags differently from
reserved value tags so that the Printer knows that there is an entire reserved value tags so that the Printer knows that there is an entire
attribute group that it doesn't understand as opposed to a single value attribute group that it doesn't understand as opposed to a single value
that it doesn't understand. that it doesn't understand.
3.7.2 Value Tags 3.7.2 Value Tags
The remaining tables show values for the value-tag, which is the first The remaining tables show values for the value-tag, which is the first
octet of an attribute. The value-tag specifies the type of the value of octet of an attribute. The value-tag specifies the type of the value of
the attribute. The following table specifies the "out-of-band" values the attribute. The following table specifies the "out-of-band" values
for the value-tag. for the value-tag.
Tag Value (Hex) Meaning Tag Value (Hex) Meaning
0x10 unsupported 0x10 unsupported
0x11 reserved for future 'default' 0x11 reserved for 'default' for definition in a future
IETF standards track document
0x12 unknown 0x12 unknown
0x13 no-value 0x13 no-value
0x14-0x1F reserved for future "out-of-band" values. 0x14-0x1F reserved for "out-of-band" values in future IETF
standards track documents.
The "unsupported" value MUST be used in the attribute-sequence of an The "unsupported" value MUST be used in the attribute-sequence of an
error response for those attributes which the printer does not support. error response for those attributes which the printer does not support.
The "default" value is reserved for future use of setting value back to The "default" value is reserved for future use of setting value back to
their default value. The "unknown" value is used for the value of a their default value. The "unknown" value is used for the value of a
supported attribute when its value is temporarily unknown. The "no- supported attribute when its value is temporarily unknown. The "no-
value" value is used for a supported attribute to which no value has value" value is used for a supported attribute to which no value has
been assigned, e.g. "job-k-octets-supported" has no value if an been assigned, e.g. "job-k-octets-supported" has no value if an
implementation supports this attribute, but an administrator has not implementation supports this attribute, but an administrator has not
configured the printer to have a limit. configured the printer to have a limit.
The following table specifies the integer values for the value-tag: The following table specifies the integer values for the value-tag:
Tag Value (Hex) Meaning Tag Value (Hex) Meaning
0x20 reserved 0x20 reserved for definition in a future IETF
standards track document
0x21 integer 0x21 integer
0x22 boolean 0x22 boolean
0x23 enum 0x23 enum
0x24-0x2F reserved for future integer types 0x24-0x2F reserved for integer types for definition in
future IETF standards track documents
NOTE: 0x20 is reserved for "generic integer" if it should ever be NOTE: 0x20 is reserved for "generic integer" if it should ever be
needed. needed.
The following table specifies the octetString values for the value-tag: The following table specifies the octetString values for the value-tag:
Tag Value (Hex) Meaning Tag Value (Hex) Meaning
0x30 octetString with an unspecified format 0x30 octetString with an unspecified format
0x31 dateTime 0x31 dateTime
0x32 resolution 0x32 resolution
0x33 rangeOfInteger 0x33 rangeOfInteger
0x34 reserved for collection (in the future) 0x34 reserved for definition in a future IETF
standards track document
0x35 textWithLanguage 0x35 textWithLanguage
0x36 nameWithLanguage 0x36 nameWithLanguage
0x37-0x3F reserved for future octetString types 0x37-0x3F reserved for octetString type definitions in
future IETF standards track documents
The following table specifies the character-string values for the value- The following table specifies the character-string values for the value-
tag: tag:
Tag Value (Hex) Meaning Tag Value (Hex) Meaning
0x40 reserved 0x40 reserved for definition in a future IETF
standards track document
0x41 textWithoutLanguage 0x41 textWithoutLanguage
0x42 nameWithoutLanguage 0x42 nameWithoutLanguage
0x43 reserved 0x43 reserved for definition in a future IETF
standards track document
0x44 keyword 0x44 keyword
0x45 uri 0x45 uri
0x46 uriScheme 0x46 uriScheme
0x47 charset 0x47 charset
0x48 naturalLanguage 0x48 naturalLanguage
0x49 mimeMediaType 0x49 mimeMediaType
0x4A-0x5F reserved for future character string types 0x4A-0x5F reserved for character string type definitions
in future IETF standards track documents
NOTE: 0x40 is reserved for "generic character-string" if it should ever NOTE: 0x40 is reserved for "generic character-string" if it should ever
be needed. be needed.
NOTE: an attribute value always has a type, which is explicitly NOTE: an attribute value always has a type, which is explicitly
specified by its tag; one such tag value is "nameWithoutLanguage". An specified by its tag; one such tag value is "nameWithoutLanguage". An
attribute's name has an implicit type, which is keyword. attribute's name has an implicit type, which is keyword.
The values 0x60-0xFF are reserved for future types. There are no values The values 0x60-0xFF are reserved for future type definations in IETF
allocated for private extensions. A new type MUST be registered via the standards track documents.
type 2 registration process [ipp-mod].
The tag 0x7F is reserved for extending types beyond the 255 values The tag 0x7F is reserved for extending types beyond the 255 values
available with a single byte. A tag value of 0x7F MUST signify that the available with a single byte. A tag value of 0x7F MUST signify that the
first 4 bytes of the value field are interpreted as the tag value. first 4 bytes of the value field are interpreted as the tag value.
Note, this future extension doesn't affect parsers that are unaware of Note, this future extension doesn't affect parsers that are unaware of
this special tag. The tag is like any other unknown tag, and the value this special tag. The tag is like any other unknown tag, and the value
length specifies the length of a value which contains a value that the length specifies the length of a value which contains a value that the
parser treats atomically. All these 4 byte tag values are currently parser treats atomically. Values from 0x00 to 0x37777777 are reserved
unallocated except that the values 0x40000000-0x7FFFFFFF are reserved for definition in future IETF standard track documents. The values
for experimental use. 0x40000000 to0x7FFFFFFF are reserved for vendor extensions.
3.8 Name-Length 3.8 Name-Length
The name-length field MUST consist of a SIGNED-SHORT. This field MUST The name-length field MUST consist of a SIGNED-SHORT. This field MUST
specify the number of octets in the name field which follows the name- specify the number of octets in the name field which follows the name-
length field, excluding the two bytes of the name-length field. length field, excluding the two bytes of the name-length field.
If a name-length field has a value of zero, the following name field If a name-length field has a value of zero, the following name field
MUST be empty, and the following value MUST be treated as an additional MUST be empty, and the following value MUST be treated as an additional
value for the preceding attribute. Within an attribute-sequence, if two value for the preceding attribute. Within an attribute-sequence, if two
attributes have the same name, the first occurrence MUST be ignored. The or more attributes have the same name, the attribute-sequence is mal-
zero-length name is the only mechanism for multi-valued attributes. formed (see [ipp-mod] section 3.1.3). The zero-length name is the only
mechanism for multi-valued attributes.
3.9 (Attribute) Name 3.9 Operation Requests and Responses
Some operation elements are called parameters in the model document Some operation elements are called parameters in the model document
[ipp-mod]. They MUST be encoded in a special position and they MUST NOT [ipp-mod]. They MUST be encoded in a special position and they MUST NOT
appear as an operation attributes. These parameters are: appear as an operation attributes. These parameters are:
- "version-number": The parameter named "version-number" in the IPP - "version-number": The parameter named "version-number" in the IPP
model document MUST become the "version-number" field in the model document MUST become the "version-number" field in the
operation layer request or response. operation layer request or response.
- "operation-id": The parameter named "operation-id" in the IPP model - "operation-id": The parameter named "operation-id" in the IPP model
skipping to change at page 14, line 16 skipping to change at page 14, line 37
it might get the reference to the appropriate IPP Printer object it might get the reference to the appropriate IPP Printer object
from either the HTTP URI (using to the context of the HTTP server from either the HTTP URI (using to the context of the HTTP server
for relative URLs) or from the URI within the operation request; for relative URLs) or from the URI within the operation request;
the choice is up to the implementation. the choice is up to the implementation.
5. HTTP URIs can be relative or absolute, but the target URI in the 5. HTTP URIs can be relative or absolute, but the target URI in the
operation MUST be an absolute URI. operation MUST be an absolute URI.
The model document arranges the remaining attributes into groups for The model document arranges the remaining attributes into groups for
each operation request and response. Each such group MUST be represented each operation request and response. Each such group MUST be represented
in the protocol by an xxx-attribute-sequence preceded by the appropriate in the protocol by an xxx-attribute-sequence preceded by the appropriate
xxx-attributes-tag (See the table below and section 11 "Appendix A: xxx-attributes-tag (See the table below and section 13 "Appendix A:
Protocol Examples"). In addition, the order of these xxx-attributes-tags Protocol Examples"). In addition, the order of these xxx-attributes-tags
and xxx-attribute-sequences in the protocol MUST be the same as in the and xxx-attribute-sequences in the protocol MUST be the same as in the
model document, but the order of attributes within each xxx-attribute- model document, but the order of attributes within each xxx-attribute-
sequence MUST be unspecified. The table below maps the model document sequence MUST be unspecified. The table below maps the model document
group name to xxx-attributes-sequence: 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
skipping to change at page 14, line 38 skipping to change at page 15, line 4
Unsupported Attributes unsupported- attributes-sequence Unsupported Attributes unsupported- attributes-sequence
Requested Attributes (Get-Job- job-attributes-sequence Requested Attributes (Get-Job- job-attributes-sequence
Attributes) Attributes)
Requested Attributes (Get- printer-attributes-sequence Requested Attributes (Get- printer-attributes-sequence
Printer-Attributes) Printer-Attributes)
Document Content in a special position as described Document Content in a special position as described
above above
If an operation contains attributes from more than one job object (e.g. If an operation contains attributes from more than one job object (e.g.
Get-Jobs response), the attributes from each job object MUST be in a Get-Jobs response), the attributes from each job object MUST be in a
separate job-attribute-sequence, such that the attributes from the ith separate job-attribute-sequence, such that the attributes from the ith
job object are in the ith job-attribute-sequence. See Section 11 job object are in the ith job-attribute-sequence. See Section 13
"Appendix A: Protocol Examples" for table showing the application of the "Appendix A: Protocol Examples" for table showing the application of the
rules above. rules above.
3.10 Value Length 3.10 Value Length
Each attribute value MUST be preceded by a SIGNED-SHORT, which MUST Each attribute value MUST be preceded by a SIGNED-SHORT, which MUST
specify the number of octets in the value which follows this length, specify the number of octets in the value which follows this length,
exclusive of the two bytes specifying the length. exclusive of the two bytes specifying the length.
For any of the types represented by binary signed integers, the sender For any of the types represented by binary signed integers, the sender
MUST encode the value in exactly four octets. MUST encode the value in exactly four octets.
For any of the types represented by character-strings, the sender MUST For any of the types represented by character-strings, the sender MUST
encode the value with all the characters of the string and without any encode the value with all the characters of the string and without any
padding characters. padding characters.
If a value-tag contains an "out-of-band" value, such as "unsupported", If a value-tag contains an "out-of-band" value, such as "unsupported",
the value-length MUST be 0 and the value empty . the value has no the value-length MUST be 0 and the value empty ¨ the value has no
meaning when the value-tag has an "out-of-band" value. meaning when the value-tag has an "out-of-band" value.
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 the representation of
defined in the IPP model document. The table below augments the attribute values are defined in the IPP model document. The table below
information in the model document, and defines the syntax types from the augments the information in the model document, and defines the syntax
model document in terms of the 5 basic types defined in section 3 types from the model document in terms of the 5 basic types defined in
"Encoding of the Operation Layer". The 5 types are US-ASCII-STRING, section 3 "Encoding of the Operation Layer". The 5 types are US-ASCII-
LOCALIZED-STRING, SIGNED-INTEGER, SIGNED-SHORT, SIGNED-BYTE, and OCTET- STRING, 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
b) a value of type natural-language, b)
c) a SIGNED-SHORT which is the number of octets a value of type natural-language,
c)
a SIGNED-SHORT which is the number of octets
in the following field, in the following field,
d) a value of type textWithoutLanguage. d)
a value of type textWithoutLanguage.
The length of a textWithLanguage value MUST be 4 The length of a textWithLanguage value MUST be 4
+ the value of field a + the value of field c. + the value of field a + the value of field c.
nameWithLanguage OCTET_STRING consisting of 4 fields: nameWithLanguage OCTET_STRING consisting of 4 fields:
a) a SIGNED-SHORT which is the number of octets a)
a SIGNED-SHORT which is the number of octets
in the following field in the following field
b) a value of type natural-language, b)
c) a SIGNED-SHORT which is the number of octets a value of type natural-language,
c)
a SIGNED-SHORT which is the number of octets
in the following field in the following field
d) a value of type nameWithoutLanguage. d)
a value of type nameWithoutLanguage.
The length of a nameWithLanguage value MUST be 4 The length of a nameWithLanguage value MUST be 4
+ the value of field a + the value of field c. + the value of field a + the value of field c.
charset, US-ASCII-STRING. charset, US-ASCII-STRING.
naturalLanguage, naturalLanguage,
mimeMediaType, mimeMediaType,
keyword, uri, and keyword, uri, and
uriScheme uriScheme
boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is boolean SIGNED-BYTE where 0x00 is 'false' and 0x01 is
skipping to change at page 17, line 4 skipping to change at page 16, line 65
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.
Syntax of Attribute Encoding Syntax of Attribute Encoding
Value Value
upper bound.
1setOf X Encoding according to the rules for an attribute 1setOf X Encoding according to the rules for an attribute
with more than 1 value. Each value X is encoded with more than 1 value. Each value X is encoded
according to the rules for encoding its type. according to the rules for encoding its type.
octetString OCTET-STRING octetString OCTET-STRING
The type of the value in the model document determines the encoding in The type of the value in the model document determines the encoding in
the value and the value of the value-tag. the value and the value of the value-tag.
3.12 Data 3.12 Data
skipping to change at page 19, line 7 skipping to change at page 18, line 56
If a printer registers its URL with a directory service, the printer If a printer registers its URL with a directory service, the printer
MUST register an ipp-URL. MUST register an ipp-URL.
User interfaces are beyond the scope of this document. But if software User interfaces are beyond the scope of this document. But if software
exposes the ipp-URL values of any of the above five attributes to a exposes the ipp-URL values of any of the above five attributes to a
human user, it is REQUIRED that the human see the ipp-URL as is. human user, it is REQUIRED that the human see the ipp-URL as is.
When a client sends a request, it MUST convert a target ipp-URL to a When a client sends a request, it MUST convert a target ipp-URL to a
target http-URL for the HTTP layer according to the following rules: target http-URL for the HTTP layer according to the following rules:
1. change the 'ipp' scheme to 'http' 1.
2. add an explicit port 631 if the URL does not contain an explicit change the 'ipp' scheme to 'http'
2.
add an explicit port 631 if the URL does not contain an explicit
port. Note: port 631 is the IANA assigned Well Known Port for the port. Note: port 631 is the IANA assigned Well Known Port for the
'ipp' scheme. 'ipp' scheme.
The client MUST use the target http-URL in both the HTTP Request-Line The client MUST use the target http-URL in both the HTTP Request-Line
and HTTP headers, as specified by HTTP[RFC2616][RFC2617] . However, the and HTTP headers, as specified by HTTP[RFC2616][RFC2617] . However, the
client MUST use the target ipp-URL for the value of the "printer-uri" or client MUST use the target ipp-URL for the value of the "printer-uri" or
"job-uri" operation attribute within the application/ipp body of the "job-uri" operation attribute within the application/ipp body of the
request. The server MUST use the ipp-URL for the value of the "printer- request. The server MUST use the ipp-URL for the value of the "printer-
uri", "job-uri" or "printer-uri-supported" attributes within the uri", "job-uri" or "printer-uri-supported" attributes within the
application/ipp body of the response. application/ipp body of the response.
skipping to change at page 19, line 50 skipping to change at page 19, line 47
Content-type: application/ipp Content-type: application/ipp
Transfer-Encoding: chunked Transfer-Encoding: chunked
... ...
"printer-uri" "ipp://myhost.com/myprinter/myqueue" "printer-uri" "ipp://myhost.com/myprinter/myqueue"
(encoded in application/ipp message body) (encoded in application/ipp message body)
... ...
The proxy then connects to the IPP origin server with headers that are The proxy then connects to the IPP origin server with headers that are
the same as the "no-proxy" example above. the same as the "no-proxy" example above.
6. Security Considerations 6. IANA Considerations
This section describes the procedures for allocating encoding for the
following IETF standards track extensions and vendor extensions to the
IPP/1.1 Encoding and Transport document:
1. attribute syntaxes - see [ipp-mod] section 6.3
2. attribute groups - see [ipp-mod] section 6.5
3. out-of-band attribute values - see [ipp-mod] section 6.7
These extensions follow the "type2" registration procedures defined in
[ipp-mod] section 6. Extensions registered for use with IPP/1.1 are
OPTIONAL for client and IPP object conformance to the IPP/1.1 Encoding
and Transport document.
These extension procedures are aligned with the guidelines as set forth
by the IESG [IANA-CON]. The [ipp-mod] Section 11 describes how to
propose new registrations for consideration. IANA will reject
registration proposals that leave out required information or do not
follow the appropriate format described in [ipp-mod] Section 11. The
IPP/1.1 Encoding and Transport document may also be extended by an
appropriate RFC that specifies any of the above extensions.
7. Internationalization Considerations
See the section on ˘Internationalization Considerations÷ in the document
"Internet Printing Protocol/1.1: Model and Semantics" [ipp-mod] for
information on internationalization. This document adds no additional
issues.
8. Security Considerations
The IPP Model and Semantics document [ipp-mod] discusses high level The IPP Model and Semantics document [ipp-mod] discusses high level
security requirements (Client Authentication, Server Authentication and security requirements (Client Authentication, Server Authentication and
Operation Privacy). Client Authentication is the mechanism by which the Operation Privacy). Client Authentication is the mechanism by which the
client proves its identity to the server in a secure manner. Server client proves its identity to the server in a secure manner. Server
Authentication is the mechanism by which the server proves its identity Authentication is the mechanism by which the server proves its identity
to the client in a secure manner. Operation Privacy is defined as a to the client in a secure manner. Operation Privacy is defined as a
mechanism for protecting operations from eavesdropping. mechanism for protecting operations from eavesdropping.
6.1 Security Conformance Requirements 8.1 Security Conformance Requirements
This section defines the security requirements for IPP clients and IPP This section defines the security requirements for IPP clients and IPP
objects. objects.
6.1.1 Digest Authentication 8.1.1 Digest Authentication
IPP clients MUST support: IPP clients MUST support:
Digest Authentication [RFC2617]. Digest Authentication [RFC2617].
MD5 and MD5-sess MUST be implemented and supported. MD5 and MD5-sess MUST be implemented and supported.
The Message Integrity feature NEED NOT be used. The Message Integrity feature NEED NOT be used.
IPP Printers SHOULD support: IPP Printers SHOULD support:
Digest Authentication [RFC2617]. Digest Authentication [RFC2617].
MD5 and MD5-sess MUST be implemented and supported. MD5 and MD5-sess MUST be implemented and supported.
The Message Integrity feature NEED NOT be used. The Message Integrity feature NEED NOT be used.
The reasons that IPP Printers SHOULD (rather than MUST) support Digest The reasons that IPP Printers SHOULD (rather than MUST) support Digest
Authentication are: Authentication are:
1.While Client Authentication is important, there is a certain class of 1.
While Client Authentication is important, there is a certain class of
printer devices where it does not make sense. Specifically, a low- printer devices where it does not make sense. Specifically, a low-
end device with limited ROM space and low paper throughput may not end device with limited ROM space and low paper throughput may not
need Client Authentication. This class of device typically requires need Client Authentication. This class of device typically requires
firmware designers to make trade-offs between protocols and firmware designers to make trade-offs between protocols and
functionality to arrive at the lowest-cost solution possible. functionality to arrive at the lowest-cost solution possible.
Factored into the designer.s decisions is not just the size of the Factored into the designerĂs decisions is not just the size of the
code, but also the testing, maintenance, usefulness, and time-to- code, but also the testing, maintenance, usefulness, and time-to-
market impact for each feature delivered to the customer. Forcing market impact for each feature delivered to the customer. Forcing
such low-end devices to provide security in order to claim IPP/1.1 such low-end devices to provide security in order to claim IPP/1.1
conformance would not make business sense and could potentially stall conformance would not make business sense and could potentially stall
the adoption of the standard. the adoption of the standard.
2.Print devices that have high-volume throughput and have available ROM 2.
Print devices that have high-volume throughput and have available ROM
space have a compelling argument to provide support for Client space have a compelling argument to provide support for Client
Authentication that safeguards the device from unauthorized access. Authentication that safeguards the device from unauthorized access.
These devices are prone to a high loss of consumables and paper if These devices are prone to a high loss of consumables and paper if
unauthorized access should occur. unauthorized access should occur.
6.1.2 Transport Layer Security (TLS) 8.1.2 Transport Layer Security (TLS)
IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246] for IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246] for
Server Authentication and Operation Privacy. IPP Printers MAY also Server Authentication and Operation Privacy. IPP Printers MAY also
support TLS for Client Authentication. If an IPP Printer supports TLS, support TLS for Client Authentication. If an IPP Printer supports TLS,
it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as
mandated by RFC 2246 [RFC2246]. All other cipher suites are OPTIONAL. mandated by RFC 2246 [RFC2246]. All other cipher suites are OPTIONAL.
An IPP Printer MAY support Basic Authentication (described in HTTP/1.1 An IPP Printer MAY support Basic Authentication (described in HTTP/1.1
[RFC2617]) for Client Authentication if the channel is secure. TLS with [RFC2617]) for Client Authentication if the channel is secure. TLS with
the above mandated cipher suite can provide such a secure channel. the above mandated cipher suite can provide such a secure channel.
If a IPP client supports TLS, it MUST support the If a IPP client supports TLS, it MUST support the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246
[RFC2246]. All other cipher suites are OPTIONAL. [RFC2246]. All other cipher suites are OPTIONAL.
The IPP Model and Semantics document defines two printer attributes The IPP Model and Semantics document defines two printer attributes
skipping to change at page 21, line 20 skipping to change at page 21, line 52
If a IPP client supports TLS, it MUST support the If a IPP client supports TLS, it MUST support the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246
[RFC2246]. All other cipher suites are OPTIONAL. [RFC2246]. All other cipher suites are OPTIONAL.
The IPP Model and Semantics document defines two printer attributes The IPP Model and Semantics document defines two printer attributes
("uri-authentication-supported" and "uri-security-supported") that the ("uri-authentication-supported" and "uri-security-supported") that the
client can use to discover the security policy of a printer. That client can use to discover the security policy of a printer. That
document also outlines IPP-specific security considerations and should document also outlines IPP-specific security considerations and should
be the primary reference for security implications with regard to the be the primary reference for security implications with regard to the
IPP protocol itself. For backward compatibility with IPP version 1.0, IPP protocol itself. For backward compatibility with IPP version 1.0,
IPP clients and printers may also support SSL3. This is in addition to IPP clients and printers may also support SSL3 [ssl]. This is in
the security required in this document. addition to the security required in this document.
6.2 Using IPP with TLS 8.2 Using IPP with TLS
IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism [http- IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism [http-
tls]. An initial IPP request never uses TLS. The client requests a tls]. An initial IPP request never uses TLS. The client requests a
secure TLS connection by using the HTTP .Upgrade. header, while the secure TLS connection by using the HTTP ˘Upgrade÷ header, while the
server agrees in the HTTP response. The switch to TLS occurs either server agrees in the HTTP response. The switch to TLS occurs either
because the server grants the client.s request to upgrade to TLS, or a because the server grants the clientĂs request to upgrade to TLS, or a
server asks to switch to TLS in its response. Secure communication server asks to switch to TLS in its response. Secure communication
begins with a server.s response to switch to TLS. begins with a serverĂs response to switch to TLS.
7. Interoperability with IPP/1.0 Implementations 9. Interoperability with IPP/1.0 Implementations
It is beyond the scope of this specification to mandate conformance with It is beyond the scope of this specification to mandate conformance with
previous versions. IPP/1.1 was deliberately designed, however, to make previous versions. IPP/1.1 was deliberately designed, however, to make
supporting previous versions easy. It is worth noting that, at the time supporting previous versions easy. It is worth noting that, at the time
of composing this specification (1999), we would expect IPP/1.1 Printer of composing this specification (1999), we would expect IPP/1.1 Printer
implementations to: implementations to:
understand any valid request in the format of IPP/1.0, or 1.1; understand any valid request in the format of IPP/1.0, or 1.1;
respond appropriately with a response containing the same "version- respond appropriately with a response containing the same "version-
number" parameter value used by the client in the request. number" parameter value used by the client in the request.
And we would expect IPP/1.1 clients to: And we would expect IPP/1.1 clients to:
understand any valid response in the format of IPP/1.0, or 1.1. understand any valid response in the format of IPP/1.0, or 1.1.
7.1 The "version-number" Parameter 9.1 The "version-number" Parameter
The following are rules regarding the "version-number" parameter (see The following are rules regarding the "version-number" parameter (see
section 3.3): section 3.3):
1. Clients MUST send requests containing a "version-number" parameter 1.
Clients MUST send requests containing a "version-number" parameter
with a '1.1' value and SHOULD try supplying alternate version with a '1.1' value and SHOULD try supplying alternate version
numbers if they receive a 'server-error-version-not-supported' numbers if they receive a 'server-error-version-not-supported'
error return in a response. error return in a response.
2. IPP objects MUST accept requests containing a "version-number" 2.
IPP objects MUST accept requests containing a "version-number"
parameter with a '1.1' value (or reject the request for reasons parameter with a '1.1' value (or reject the request for reasons
other than 'server-error-version-not-supported'). other than 'server-error-version-not-supported').
3. It is recommended that IPP objects accept any request with the 3.
It is recommended that IPP objects accept any request with the
major version '1' (or reject the request for reasons other than major version '1' (or reject the request for reasons other than
'server-error-version-not-supported'). See [ipp-mod] "versions" 'server-error-version-not-supported'). See [ipp-mod] "versions"
sub-section. sub-section.
4. In any case, security MUST NOT be compromised when a client 4.
In any case, security MUST NOT be compromised when a client
supplies a lower "version-number" parameter in a request. For supplies a lower "version-number" parameter in a request. For
example, if an IPP/1.1 conforming Printer object accepts version example, if an IPP/1.1 conforming Printer object accepts version
'1.0' requests and is configured to enforce Digest Authentication, '1.0' requests and is configured to enforce Digest Authentication,
it MUST do the same for a version '1.0' request. it MUST do the same for a version '1.0' request.
7.2 Security and URL Schemes 9.2 Security and URL Schemes
The following are rules regarding security, the "version-number" The following are rules regarding security, the "version-number"
parameter, and the URL scheme supplied in target attributes and parameter, and the URL scheme supplied in target attributes and
responses: responses:
1. When a client supplies a request, the "printer-uri" or "job-uri" 1.
When a client supplies a request, the "printer-uri" or "job-uri"
target operation attribute MUST have the same scheme as that target operation attribute MUST have the same scheme as that
indicated in one of the values of the "printer-uri-supported" indicated in one of the values of the "printer-uri-supported"
Printer attribute. Printer attribute.
2. When the server returns the "job-printer-uri" or "job-uri" Job 2.
When the server returns the "job-printer-uri" or "job-uri" Job
Description attributes, it SHOULD return the same scheme ('ipp', Description attributes, it SHOULD return the same scheme ('ipp',
'https', 'http', etc.) that the client supplied in the "printer- 'https', 'http', etc.) that the client supplied in the "printer-
uri" or "job-uri" target operation attributes in the Get-Job- uri" or "job-uri" target operation attributes in the Get-Job-
Attributes or Get-Jobs request, rather than the scheme used when Attributes or Get-Jobs request, rather than the scheme used when
the job was created. However, when a client requests job the job was created. However, when a client requests job
attributes using the Get-Job-Attributes or Get-Jobs operations, the attributes using the Get-Job-Attributes or Get-Jobs operations, the
jobs and job attributes that the server returns depends on: (1) the jobs and job attributes that the server returns depends on: (1) the
security in effect when the job was created, (2) the security in security in effect when the job was created, (2) the security in
effect in the query request, and (3) the security policy in force. effect in the query request, and (3) the security policy in force.
3. It is recommended that if a server registers a non-secure ipp-URL 3.
It is recommended that if a server registers a non-secure ipp-URL
with a directory service (see [IPP-MOD] "Generic Directory Schema" with a directory service (see [IPP-MOD] "Generic Directory Schema"
Appendix), then it also register an http-URL for interoperability Appendix), then it also register an http-URL for interoperability
with IPP/1.0 clients (see section 7). with IPP/1.0 clients (see section 9).
4. In any case, security MUST NOT be compromised when a client 4.
In any case, security MUST NOT be compromised when a client
supplies an 'http' or other non-secure URL scheme in the target supplies an 'http' or other non-secure URL scheme in the target
"printer-uri" and "job-uri" operation attributes in a request. "printer-uri" and "job-uri" operation attributes in a request.
8. References 10. References
[dpa] ISO/IEC 10175 Document Printing Application (DPA), June 1996. [dpa] ISO/IEC 10175 Document Printing Application (DPA), June 1996.
[http-tls]R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1", [http-tls]R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1",
<draft-ietf-tls-http-upgrade-02>, June 1999. <draft-ietf-tls-http-upgrade-02>, June 1999.
[iana]IANA Registry of Coded Character Sets: ftp://ftp.isi.edu/in- [iana]IANA Registry of Coded Character Sets: ftp://ftp.isi.edu/in-
notes/iana/assignments/character-sets. notes/iana/assignments/character-sets.
[ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.1: [ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.1:
Implementer's Guide", work in progress. Implementer's Guide", draft-ietf-ipp-implementers-guide-v11-
00.txt, work in progress, September 27, 1999.
[ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, [ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
"Internet Printing Protocol/1.0: Model and Semantics", <draft- "Internet Printing Protocol/1.1: Model and Semantics", <draft-
ietf-ipp-model-v11-03.txt>, June, 1999. ietf-ipp-model-v11-05.txt>, February 23, 2000.
[ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet [ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet
Printing Protocol/1.1: Encoding and Transport", draft-ietf-ipp- Printing Protocol/1.1: Encoding and Transport", draft-ietf-ipp-
protocol-v11-02-.txt, June 1999. protocol-v11-04-.txt, February 23, 2000.
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", RFC 822, August 1982. Messages", RFC 822, August 1982.
[RFC1123] Braden, S., "Requirements for Internet Hosts - Application [RFC1123] Braden, S., "Requirements for Internet Hosts - Application
and Support", RFC 1123, October, 1989. and Support", RFC 1123, October, 1989.
[RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" [RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol"
RFC 1179, August 1990. RFC 1179, August 1990.
skipping to change at page 24, line 26 skipping to change at page 24, line 57
[RFC2234] D. Crocker et al., "Augmented BNF for Syntax Specifications: [RFC2234] D. Crocker et al., "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234. November 1997. ABNF", RFC 2234. November 1997.
[RFC2246] T. Dierks et al., "The TLS Protocol", RFC 2246. January 1999. [RFC2246] T. Dierks et al., "The TLS Protocol", RFC 2246. January 1999.
[RFC2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform [RFC2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998. 1998.
[RFC2565] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet [RFC2565] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet
Printing Protocol/1.0: Encoding and Transport", rfc 2565, April Printing Protocol/1.0: Encoding and Transport", RFC 2565, April
1999. 1999.
[RFC2566] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, [RFC2566] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
"Internet Printing Protocol/1.0: Model and Semantics", rfc 2566, "Internet Printing Protocol/1.0: Model and Semantics", rfc 2566,
April, 1999. April, 1999.
[RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", [RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol",
RFC2567, April 1999. RFC2567, April 1999.
[RFC2568] Zilles, S., "Rationale for the Structure and Model and [RFC2568] Zilles, S., "Rationale for the Structure and Model and
Protocol for the Internet Printing Protocol", RC 2568,April 1999. Protocol for the Internet Printing Protocol", RC 2568, April
1999.
[RFC2569] Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping [RFC2569] Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping
between LPD and IPP Protocols RFC 2569, April 1999. between LPD and IPP Protocols RFC 2569, April 1999.
[RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. [RFC2616]
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
RFC 2616, June 1999. RFC 2616, June 1999.
[RFC2069] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. [RFC2617]
Leach, A. Luotonen, L. Stewart, "HTTP Authentication: Basic and J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach,
Digest Access Authentication", RFC 2617, June 1999. A. Luotonen, L. Stewart, "HTTP Authentication: Basic and Digest
Access Authentication", RFC 2617, June 1999.
9. Author's Address [SSL]
Netscape, The SSL Protocol, Version 3, (Text version 3.02),
November 1996.
11. Author's Address
Robert Herriot (editor) Paul Moore Robert Herriot (editor) Paul Moore
Xerox Corporation Microsoft Xerox Corporation Peerless Systems Networking
3400 Hillview Ave., Bldg #1 One Microsoft Way 3400 Hillview Ave., Bldg #1 10900 NE 8th St #900
Palo Alto, CA 94304 Redmond, WA 98053 Palo Alto, CA 94304 Bellevue, WA 98004
Phone: 650-813-7696 Phone: 425-936-0908 Phone: 650-813-7696 Phone: 425-462-5852
Fax: 650-813-6860 Fax: 425-93MS-FAX Fax: 650-813-6860
Email: Email: paulmo@microsoft.com Email: Email: pmoore@peerless.com
robert.herriot@pahv.xerox.com robert.herriot@pahv.xerox.com
Sylvan Butler Randy Turner Sylvan Butler Randy Turner
Hewlett-Packard 2Wire, Inc. Hewlett-Packard 2Wire, Inc.
11311 Chinden Blvd. 694 Tasman Dr. 11311 Chinden Blvd. 694 Tasman Dr.
Boise, ID 83714 Milpitas, CA 95035 Boise, ID 83714 Milpitas, CA 95035
Phone: 208-396-6000 Phone: 408-546-1273 Phone: 208-396-6000 Phone: 408-546-1273
Fax: 208-396-3457 Fax: 208-396-3457
Email: sbutler@boi.hp.com Email: sbutler@boi.hp.com
skipping to change at page 25, line 35 skipping to change at page 27, line 5
Xerox Corporation Xerox Corporation
737 Hawaii St 737 Hawaii St
El Segundo, CA 90245 El Segundo, CA 90245
IPP Mailing List: ipp@pwg.org Phone: 310-333-5764 IPP Mailing List: ipp@pwg.org Phone: 310-333-5764
IPP Mailing List Subscription: Fax: 310-333-5514 IPP Mailing List Subscription: Fax: 310-333-5514
ipp-request@pwg.org ipp-request@pwg.org
IPP Web Page: Email: jwenn@cp10.es.xerox.com IPP Web Page: Email: jwenn@cp10.es.xerox.com
http://www.pwg.org/ipp/ http://www.pwg.org/ipp/
10. Other Participants: 12. Other Participants:
Chuck Adams - Tektronix Shivaun Albright - HP Chuck Adams - Tektronix Shivaun Albright - HP
Jeff Barnett - IBM Ron Bergman - Dataproducts Stefan Andersson - Axis Jeff Barnett - IBM
Ron Bergman - Hitachi Koki Imaging Dennis Carney - IBM
Systems
Keith Carter - IBM Angelo Caruso - Xerox Keith Carter - IBM Angelo Caruso - Xerox
Rajesh Chawla - TR Computing Josh Cohen - Microsoft Rajesh Chawla - TR Computing Nancy Chen - Okidata
Solutions Solutions
Jeff Copeland - QMS Andy Davidson - Tektronix Josh Cohen - Microsoft Jeff Copeland - QMS
Roger deBry - IBM Mabry Dozier - QMS Andy Davidson - Tektronix Roger deBry - IBM
Lee Farrell - Canon Steve Gebert - IBM Maulik Desai - Auco Mabry Dozier - QMS
Sue Gleeson - Digital Charles Gordon - Osicom Lee Farrell - Canon Information Satoshi Fujitami - Ricoh
Brian Grimshaw - Apple Jerry Hadsell - IBM Systems
Richard Hart - Digital Tom Hastings - Xerox Steve Gebert - IBM Sue Gleeson - Digital
Charles Gordon - Osicom Brian Grimshaw - Apple
Jerry Hadsell - IBM Richard Hart - Digital
Tom Hastings - Xerox Henrik Holst - I-data
Stephen Holmstead Zhi-Hong Huang - Zenographics Stephen Holmstead Zhi-Hong Huang - Zenographics
Scott Isaacson - Novell Babek Jahromi - Microsoft Scott Isaacson - Novell Babek Jahromi - Microsoft
Swen Johnson - Xerox David Kellerman - Northlake Swen Johnson - Xerox David Kellerman - Northlake
Software Software
Robert Kline - TrueSpectra Carl Kugler - IBM Robert Kline - TrueSpectra Charles Kong - Panasonic
Dave Kuntz - Hewlett-Packard Takami Kurono - Brother Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
Rick Landau - Digital Scott Lawrence - Agranot Systems Takami Kurono - Brother Rick Landau - Digital
Greg LeClair - Epson Harry Lewis - IBM Scott Lawrence - Agranot Systems Greg LeClair - Epson
Dwight Lewis - Lexmark Harry Lewis - IBM
Tony Liao - Vivid Image Roy Lomicka - Digital Tony Liao - Vivid Image Roy Lomicka - Digital
Pete Loya - HP Ray Lutz - Cognisys Pete Loya - HP Ray Lutz - Cognisys
Mike MacKay - Novell, Inc. David Manchala - Xerox Mike MacKay - Novell, Inc. David Manchala - Xerox
Carl-Uno Manros - Xerox Jay Martin - Underscore Carl-Uno Manros - Xerox Jay Martin - Underscore
Larry Masinter - Xerox Stan McConnell - Xerox Stan McConnell - Xerox Larry Masinter - Xerox
Ira McDonald - High North Inc. Peter Michalek - Shinesoft Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
Pat Nogay - IBM Ron Norton - Printronics Pat Nogay - IBM Ron Norton - Printronics
Bob Pentecost - Hewlett-Packard Patrick Powell - Astart Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
Patrick Powell - Astart Jeff Rackowitz - Intermec
Technologies Technologies
Jeff Rackowitz - Intermec Rob Rhoads - Intel Eric Random - Peerless Rob Rhoads - Intel
Xavier Riley - Xerox Gary Roberts - Ricoh Xavier Riley - Xerox Gary Roberts - Ricoh
David Roach - Unisys Stuart Rowley - Kyocera David Roach - Unisys Stuart Rowley - Kyocera
Richard Schneider - Epson Kris Schoff - HP Yuji Sasaki - Japan Computer Richard Schneider - Epson
Bob Setterbo - Adobe Devon Taylor - Novell, Inc. Industry
Mike Timperman - Lexmark Shigern Ueda - Canon Kris Schoff - HP Katsuaki Sekiguchi - Canon
Bob Von Andel - Allegro Software William Wagner - Osicom Information Systems
Jim Walker - DAZEL Chris Wellens - Interworking Labs Bob Setterbo - Adobe Gail Songer - Peerless
Rob Whittle - Novell, Inc. Jasper Wong - Xionics Hideki Tanaka - Cannon Information Devon Taylor - Novell, Inc.
Don Wright - Lexmark Rick Yardumian - Xerox Systems
Lloyd Young - Lexmark Atsushi Yuki - Kyocera Mike Timperman - Lexmark Atsushi Uchino - Epson
Peter Zehler - Xerox Frank Zhao - Panasonic Shigeru Ueda - Canon Bob Von Andel - Allegro Software
Steve Zilles - Adobe William Wagner - NetSilicon/DPI Jim Walker - DAZEL
Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
11. Appendix A: Protocol Examples Jasper Wong - Xionics Don Wright - Lexmark
Michael Wu - Heidelberg Digital Rick Yardumian - Xerox
Michael Yeung - Canon Information Lloyd Young - Lexmark
Systems
Atsushi Yuki - Kyocera Peter Zehler - Xerox
William Zhang- Canon Information Frank Zhao - Panasonic
Systems
Steve Zilles - Adobe Rob Zirnstein - Canon Information
Systems
11.1 Print-Job Request 13. Appendix A: Protocol Examples
13.1 Print-Job Request
The following is an example of a Print-Job request with job-name, The following is an example of a Print-Job request with job-name,
copies, and sides specified. The "ipp-attribute-fidelity" attribute is copies, and sides specified. The "ipp-attribute-fidelity" attribute is
set to 'true' so that the print request will fail if the "copies" or the set to 'true' so that the print request will fail if the "copies" or the
"sides" attribute are not supported or their values are not supported. "sides" attribute are not supported or their values are not supported.
Octets Symbolic Value Protocol field Octets Symbolic Value Protocol field
0x0101 1.1 version-number 0x0101 1.1 version-number
0x0002 Print-Job operation-id 0x0002 Print-Job operation-id
skipping to change at page 27, line 56 skipping to change at page 29, line 56
0x00000014 20 value 0x00000014 20 value
0x44 keyword type value-tag 0x44 keyword type value-tag
0x0005 name-length 0x0005 name-length
sides sides name sides sides name
0x0013 value-length 0x0013 value-length
two-sided- two-sided-long-edge value two-sided- two-sided-long-edge value
long-edge long-edge
0x03 end-of-attributes end-of-attributes-tag 0x03 end-of-attributes end-of-attributes-tag
%!PS... <PostScript> data %!PS... <PostScript> data
11.2 Print-Job Response (successful) 13.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 Octets Symbolic Value Protocol field
0x0101 1.1 version-number 0x0101 1.1 version-number
0x0000 successful-ok status-code 0x0000 successful-ok status-code
skipping to change at page 28, line 52 skipping to change at page 30, line 52
0x0019 value-length 0x0019 value-length
ipp://forest/pin job 123 on pinetree value ipp://forest/pin job 123 on pinetree value
etree/123 etree/123
0x23 enum type value-tag 0x23 enum type value-tag
0x0009 name-length 0x0009 name-length
job-state job-state name job-state job-state name
0x0004 value-length 0x0004 value-length
0x0003 pending value 0x0003 pending value
0x03 end-of-attributes end-of-attributes-tag 0x03 end-of-attributes end-of-attributes-tag
11.3 Print-Job Response (failure) 13.3 Print-Job Response (failure)
Here is an example of an unsuccessful Print-Job response to the previous Here is an example of an unsuccessful Print-Job response to the previous
Print-Job request. It fails because, in this case, the printer does not Print-Job request. It fails because, in this case, the printer does not
support the "sides" attribute and because the value '20' for the support the "sides" attribute and because the value '20' for the
"copies" attribute is not supported. Therefore, no job is created, and "copies" attribute is not supported. Therefore, no job is created, and
neither a "job-id" nor a "job-uri" operation attribute is returned. The neither a "job-id" nor a "job-uri" operation attribute is returned. The
error code returned is 'client-error-attributes-or-values-not-supported' error code returned is 'client-error-attributes-or-values-not-supported'
(0x040B). (0x040B).
skipping to change at page 29, line 49 skipping to change at page 31, line 49
0x0006 name-length 0x0006 name-length
copies copies name copies copies name
0x0004 value-length 0x0004 value-length
0x00000014 20 value 0x00000014 20 value
0x10 unsupported (type) value-tag 0x10 unsupported (type) value-tag
0x0005 name-length 0x0005 name-length
sides sides name sides sides name
0x0000 value-length 0x0000 value-length
0x03 end-of-attributes end-of-attributes-tag 0x03 end-of-attributes end-of-attributes-tag
11.4 Print-Job Response (success with attributes ignored) 13.4 Print-Job Response (success with attributes ignored)
Here is an example of a successful Print-Job response to a Print-Job Here is an example of a successful Print-Job response to a Print-Job
request like the previous Print-Job request, except that the value of request like the previous Print-Job request, except that the value of
'ipp-attribute-fidelity' is false. The print request succeeds, even 'ipp-attribute-fidelity' is false. The print request succeeds, even
though, in this case, the printer supports neither the "sides" attribute though, in this case, the printer supports neither the "sides" attribute
nor the value '20' for the "copies" attribute. Therefore, a job is nor the value '20' for the "copies" attribute. Therefore, a job is
created, and both a "job-id" and a "job-uri" operation attribute are created, and both a "job-id" and a "job-uri" operation attribute are
returned. The unsupported attributes are also returned in an Unsupported returned. The unsupported attributes are also returned in an Unsupported
Attributes Group. The error code returned is 'successful-ok-ignored-or- Attributes Group. The error code returned is 'successful-ok-ignored-or-
skipping to change at page 32, line 10 skipping to change at page 34, line 10
0x23 enum type value-tag 0x23 enum type value-tag
0x0009 name-length 0x0009 name-length
job-state job-state name job-state job-state name
0x0004 value-length 0x0004 value-length
Octets Symbolic Value Protocol field Octets Symbolic Value Protocol field
0x0003 pending value 0x0003 pending value
0x03 end-of-attributes end-of-attributes-tag 0x03 end-of-attributes end-of-attributes-tag
11.5 Print-URI Request 13.5 Print-URI Request
The following is an example of Print-URI request with copies and job- The following is an example of Print-URI request with copies and job-
name parameters: name parameters:
Octets Symbolic Value Protocol field Octets Symbolic Value Protocol field
0x0101 1.1 version-number 0x0101 1.1 version-number
0x0003 Print-URI operation-id 0x0003 Print-URI operation-id
0x00000001 1 request-id 0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag 0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag 0x47 charset type value-tag
skipping to change at page 33, line 48 skipping to change at page 35, line 48
0x0006 value-length 0x0006 value-length
foobar foobar value foobar foobar value
0x02 start job-attributes job-attributes-tag 0x02 start job-attributes job-attributes-tag
0x21 integer type value-tag 0x21 integer type value-tag
0x0006 name-length 0x0006 name-length
copies copies name copies copies name
0x0004 value-length 0x0004 value-length
0x00000001 1 value 0x00000001 1 value
0x03 end-of-attributes end-of-attributes-tag 0x03 end-of-attributes end-of-attributes-tag
11.6 Create-Job Request 13.6 Create-Job Request
The following is an example of Create-Job request with no parameters and The following is an example of Create-Job request with no parameters and
no attributes: no attributes:
Octets Symbolic Value Protocol field Octets Symbolic Value Protocol field
0x0101 1.1 version-number 0x0101 1.1 version-number
0x0005 Create-Job operation-id 0x0005 Create-Job operation-id
0x00000001 1 request-id 0x00000001 1 request-id
0x01 start operation-attributes operation-attributes-tag 0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag 0x47 charset type value-tag
skipping to change at page 34, line 31 skipping to change at page 36, line 31
0x0005 value-length 0x0005 value-length
en-us en-US value en-us en-US value
0x45 uri type value-tag 0x45 uri type value-tag
0x000B name-length 0x000B name-length
printer-uri printer-uri name printer-uri printer-uri name
0x0015 value-length 0x0015 value-length
ipp://forest/p printer pinetree value ipp://forest/p printer pinetree value
inetree inetree
0x03 end-of-attributes end-of-attributes-tag 0x03 end-of-attributes end-of-attributes-tag
11.7 Get-Jobs Request 13.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 no
attributes: attributes:
Octets Symbolic Value Protocol field Octets Symbolic Value Protocol field
0x0101 1.1 version-number 0x0101 1.1 version-number
0x000A Get-Jobs operation-id 0x000A Get-Jobs operation-id
0x00000123 0x123 request-id 0x00000123 0x123 request-id
0x01 start operation-attributes operation-attributes-tag 0x01 start operation-attributes operation-attributes-tag
0x47 charset type value-tag 0x47 charset type value-tag
skipping to change at page 35, line 50 skipping to change at page 37, line 50
0x44 keyword type value-tag 0x44 keyword type value-tag
0x0000 additional value name-length 0x0000 additional value name-length
0x0008 value-length 0x0008 value-length
job-name job-name value job-name job-name value
0x44 keyword type value-tag 0x44 keyword type value-tag
0x0000 additional value name-length 0x0000 additional value name-length
0x000F value-length 0x000F value-length
document-format document-format value document-format document-format value
0x03 end-of-attributes end-of-attributes-tag 0x03 end-of-attributes end-of-attributes-tag
11.8 Get-Jobs Response 13.8 Get-Jobs Response
The following is an of Get-Jobs response from previous request with 3 The following is an of Get-Jobs response from previous request with 3
jobs. The Printer returns no information about the second job (because jobs. The Printer returns no information about the second job (because
of security reasons): of security reasons):
Octets Symbolic Value Protocol field Octets Symbolic Value Protocol field
0x0101 1.1 version-number 0x0101 1.1 version-number
0x0000 successful-ok status-code 0x0000 successful-ok status-code
0x00000123 0x123 request-id (echoed 0x00000123 0x123 request-id (echoed
back) back)
skipping to change at page 37, line 10 skipping to change at page 39, line 10
job-name job-name name job-name job-name name
0x0012 value-length 0x0012 value-length
0x0005 sub-value-length 0x0005 sub-value-length
de-CH de-CH value de-CH de-CH value
Octets Symbolic Value Protocol field Octets Symbolic Value Protocol field
0x0009 sub-value-length 0x0009 sub-value-length
isch guet isch guet name isch guet isch guet name
0x03 end-of-attributes end-of-attributes-tag 0x03 end-of-attributes end-of-attributes-tag
12. Appendix C: Registration of MIME Media Type Information for 14. Appendix B: Registration of MIME Media Type Information for
"application/ipp" "application/ipp"
This appendix contains the information that IANA requires for This appendix contains the information that IANA requires for
registering a MIME media type. The information following this paragraph registering a MIME media type. The information following this paragraph
will be forwarded to IANA to register application/ipp whose contents are will be forwarded to IANA to register application/ipp whose contents are
defined in Section 3 "Encoding of the Operation Layer" in this defined in Section 3 "Encoding of the Operation Layer" in this
document: document:
MIME type name: application MIME type name: application
skipping to change at page 38, line 7 skipping to change at page 40, line 7
specific optional features is not ensured). Both the "charset" and specific optional features is not ensured). Both the "charset" and
"natural-language" of all IPP/1.1 attribute values which are a "natural-language" of all IPP/1.1 attribute values which are a
LOCALIZED-STRING are explicit within IPP protocol requests/responses LOCALIZED-STRING are explicit within IPP protocol requests/responses
(without recourse to any external information in HTTP, SMTP, or other (without recourse to any external information in HTTP, SMTP, or other
message transport headers). message transport headers).
Published specifications: Published specifications:
[ipp-mod] Isaacson, S., deBry, R., Hastings, T., Herriot, R., [ipp-mod] Isaacson, S., deBry, R., Hastings, T., Herriot, R.,
Powell, P., "Internet Printing Protocol/1.1: Model and Powell, P., "Internet Printing Protocol/1.1: Model and
Semantics" draft-ietf-ipp-model-v11-03.txt, June, 1999. Semantics" draft-ietf-ipp-model-v11-05.txt, February 23, 2000.
[ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R., [ipp-pro] Herriot, R., Butler, S., Moore, P., Turner, R.,
"Internet Printing Protocol/1.1: Encoding and Transport", draft- "Internet Printing Protocol/1.1: Encoding and Transport", draft-
ietf-ipp-protocol-v11-02.txt, June, 1999. ietf-ipp-protocol-v11-04.txt, February 23, 2000.
Applications which use this media type: Applications which use this media type:
Internet Printing Protocol (IPP) print clients and print servers, Internet Printing Protocol (IPP) print clients and print servers,
communicating using HTTP/1.1 (see [IPP-PRO]), SMTP/ESMTP, FTP, or other communicating using HTTP/1.1 (see [IPP-PRO]), SMTP/ESMTP, FTP, or other
transport protocol. Messages of type "application/ipp" are self- transport protocol. Messages of type "application/ipp" are self-
contained and transport-independent, including "charset" and "natural- contained and transport-independent, including "charset" and "natural-
language" context for any LOCALIZED-STRING value. language" context for any LOCALIZED-STRING value.
Person & email address to contact for further information: Person & email address to contact for further information:
Tom Hastings Tom Hastings
Xerox Corporation Xerox Corporation
737 Hawaii St. ESAE-231 737 Hawaii St. ESAE-231
El Segundo, CA El Segundo, CA
Phone: 310-333-6413 Phone: 310-333-6413
Fax: 310-333-5514 Fax: 310-333-5514
Email: thastings@cp10.es.xerox.com Email: hastings@cp10.es.xerox.com
or or
Robert Herriot Robert Herriot
Xerox Corporation Xerox Corporation
3400 Hillview Ave., Bldg #1 3400 Hillview Ave., Bldg #1
Palo Alto, CA 94304 Palo Alto, CA 94304
Phone: 650-813-7696 Phone: 650-813-7696
Fax: 650-813-6860 Fax: 650-813-6860
Email: robert.herriot@pahv.xerox.com Email: robert.herriot@pahv.xerox.com
Intended usage: Intended usage:
COMMON COMMON
13. Appendix D: Changes from IPP/1.0 15. Appendix C: Changes from IPP/1.0
IPP/1.1 is identical to IPP/1.0 [RFC2565] with the follow changes: IPP/1.1 is identical to IPP/1.0 [RFC2565] with the follow changes:
1.Attributes values that identify a printer or job object use a new 1.
Attributes values that identify a printer or job object use a new
'ipp' scheme. The 'http' and 'https' schemes are supported only for 'ipp' scheme. The 'http' and 'https' schemes are supported only for
backward compatibility. See section 5. backward compatibility. See section 5.
2.Clients MUST support of Digest Authentication, IPP Printers SHOULD 2.
support Digest Authentication. See Section 6.1.1 Clients MUST support of Digest Authentication, IPP Printers SHOULD
support Digest Authentication. See Section 8.1.1
3.TLS is recommended for channel security. In addition, SSL3 may be 3.
supported for backward compatibility. See Section 6.1.2 TLS is recommended for channel security. In addition, SSL3 may be
supported for backward compatibility. See Section 8.1.2
4.It is recommended that IPP/1.1 objects accept any request with major 4.
version number '1'. See section 7.1. It is recommended that IPP/1.1 objects accept any request with major
version number '1'. See section 9.1.
5.IPP objects SHOULD return the URL scheme requested for "job-printer- 5.
IPP objects SHOULD return the URL scheme requested for "job-printer-
uri" and "job-uri" Job Attributes, rather than the URL scheme used to uri" and "job-uri" Job Attributes, rather than the URL scheme used to
create the job. See section 7.2 create the job. See section 9.2.
14. Full Copyright Statement 6.
The IANA and Internationalization sections have been added. The
terms "private use" and "experimental" have been changed to "vendor
extension". The reserved allocations for attribute group tags,
attribute syntax tags, and out-of-band attribute values have been
clarified as to which are reserved to future IETF standards track
documents and which are reserved to vendor extension. Both kinds of
extensions use the type2 registration procedures as defined in [ipp-
mod].
16. Full Copyright Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards- procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11[BCP-11]. Copies of claims related documentation can be found in BCP-11[BCP-11]. Copies of claims
of rights made available for publication and any assurances of licenses of rights made available for publication and any assurances of licenses
 End of changes. 

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