ROM space have a compelling argument to provide support for Client
Authentication that safeguards the device from unauthorized
access. These devices are prone to a high loss of consumables and
paper if unauthorized access should occur.
8.1.2 Transport Layer Security (TLS)
IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246]
for Server Authentication and Operation Privacy. IPP Printers MAY
also 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 mandated by RFC2246 [RFC2246]. All other cipher
suites are OPTIONAL. An IPP Printer MAY support Basic Authentication
(described in HTTP/1.1 [RFC2617]) for Client Authentication if the
channel is secure. TLS with the above mandated cipher suite can
provide such a secure channel.
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 [RFC2246]. All other cipher suites are OPTIONAL.
The IPP Model and Semantics document defines two printer attributes
("uri-authentication-supported" and "uri-security-supported") that
the client can use to discover the security policy of a printer. That
document also outlines IPP-specific security considerations and
should be the primary reference for security implications with regard
to the IPP protocol itself. For backward compatibility with IPP
version 1.0, IPP clients and printers may also support SSL3 [ssl].
This is in addition to the security required in this document.
8.2 Using IPP with TLS
IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism
[RFC2817]. An initial IPP request never uses TLS. The client
requests a secure TLS connection by using the HTTP "Upgrade" header,
while the server agrees in the HTTP response. The switch to TLS
occurs either because the server grants the client's request to
upgrade to TLS, or a server asks to switch to TLS in its response.
Secure communication begins with a server's response to switch to
TLS.
9. Interoperability with IPP/1.0 Implementations
It is beyond the scope of this specification to mandate conformance
with previous versions. IPP/1.1 was deliberately designed, however,
to make supporting previous versions easy. It is worth noting that,
at the time of composing this specification (1999), we would expect
IPP/1.1 Printer implementations to:
understand any valid request in the format of IPP/1.0, or 1.1;
respond appropriately with a response containing the same
"version-number" parameter value used by the client in the
request.
And we would expect IPP/1.1 clients to:
understand any valid response in the format of IPP/1.0, or 1.1.
9.1 The "version-number" Parameter
The following are rules regarding the "version-number" parameter (see
section 3.3):
1. Clients MUST send requests containing a "version-number"
parameter with a '1.1' value and SHOULD try supplying alternate
version numbers if they receive a 'server-error-version-not-
supported' error return in a response.
2. IPP objects MUST accept requests containing a "version-number"
parameter with a '1.1' value (or reject the request for reasons
other than 'server-error-version-not-supported').
3. It is recommended that IPP objects accept any request with the
major version '1' (or reject the request for reasons other than
'server-error-version-not-supported'). See [RFC2911]
"versions" sub-section.
4. In any case, security MUST NOT be compromised when a client
supplies a lower "version-number" parameter in a request. For
example, if an IPP/1.1 conforming Printer object accepts
version '1.0' requests and is configured to enforce Digest
Authentication, it MUST do the same for a version '1.0'
request.
9.2 Security and URL Schemes
The following are rules regarding security, the "version-number"
parameter, and the URL scheme supplied in target attributes and
responses:
1. When a client supplies a request, the "printer-uri" or "job-
uri" target operation attribute MUST have the same scheme as
that indicated in one of the values of the "printer-uri-
supported" Printer attribute.
2. When the server returns the "job-printer-uri" or "job-uri" Job
Description attributes, it SHOULD return the same scheme
('ipp', 'https', 'http', etc.) that the client supplied in the
"printer-uri" or "job-uri" target operation attributes in the
Get-Job-Attributes or Get-Jobs request, rather than the scheme
used when the job was created. However, when a client requests
job attributes using the Get-Job-Attributes or Get-Jobs
operations, 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 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 with a directory service (see [RFC2911] "Generic Directory
Schema" Appendix), then it also register an http-URL for
interoperability with IPP/1.0 clients (see section 9).
4. In any case, security MUST NOT be compromised when a client
supplies an 'http' or other non-secure URL scheme in the target
"printer-uri" and "job-uri" operation attributes in a request.
10. References
[dpa] ISO/IEC 10175 Document Printing Application (DPA), June
1996.
[iana] IANA Registry of Coded Character Sets:
ftp://ftp.isi.edu/in-notes/iana/assignments/character-
sets.
[IANA-CON] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC2434,
October 1998.
[ipp-iig] Hastings, Tom, et al., "Internet Printing Protocol/1.1:
Implementer's Guide", Work in Progress.
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC822, August 1982.
[RFC1123] Braden, S., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC1123, October, 1989.
[RFC1179] McLaughlin, L. III, (editor), "Line Printer Daemon
Protocol", RFC1179, August 1990.
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFCAuthors",
RFC2223, October 1997.
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
Resource Locators (URL)", RFC1738, December 1994.
[RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
Gyllenskog, "Printer MIB", RFC1759, March 1995.
[RFC1766] Alvestrand, H., "Tags for the Identification of
Languages", RFC1766, March 1995.
[RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC
1808, June 1995.
[RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Textual Conventions for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC1903, January 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC2046,
November 1996.
[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extension (MIME) Part Four: Registration
Procedures", BCP 13, RFC2048, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC2184] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and
Continuations", RFC2184, August 1997.
[RFC2234] Crocker, D. and P. Overall, "Augmented BNF for Syntax
Specifications: ABNF", RFC2234, November 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC2246.
January 1999.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC2396,
August 1998.
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Turner,
"Internet Printing Protocol/1.0: Encoding and Transport",
RFC2565, April 1999.
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
Powell, "Internet Printing Protocol/1.0: Model and
Semantics", RFC2566, April 1999.
[RFC2567] Wright, D., "Design Goals for an Internet Printing
Protocol", RFC2567, April 1999.
[RFC2568] Zilles, S., "Rationale for the Structure and Model and
Protocol for the Internet Printing Protocol", RFC2568,
April 1999.
[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
"Mapping between LPD and IPP Protocols", RFC2569, April
1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol - HTTP/1.1", RFC2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC2617, June 1999.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC2817, May 2000.
[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J.
Wenn, "Internet Printing Protocol/1.1: Encoding and
Transport", RFC2910, September 2000.
[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P.
Powell, "Internet Printing Protocol/1.1: Model and
Semantics", RFC2911, September 2000.
[SSL] Netscape, The SSL Protocol, Version 3, (Text version
3.02), November 1996.
11. Authors' Addresses
Robert Herriot, Editor
Xerox Corporation
3400 Hillview Ave., Bldg #1
Palo Alto, CA 94304
Phone: 650-813-7696
Fax: 650-813-6860
EMail: robert.herriot@pahv.xerox.com
Sylvan Butler
Hewlett-Packard
11311 Chinden Blvd.
Boise, ID 83714
Phone: 208-396-6000
Fax: 208-396-3457
EMail: sbutler@boi.hp.com
Paul Moore
Peerless Systems Networking
10900 NE 8th St #900
Bellevue, WA 98004
Phone: 425-462-5852
EMail: pmoore@peerless.com
Randy Turner
2Wire, Inc.
694 Tasman Dr.
Milpitas, CA 95035
Phone: 408-546-1273
John Wenn
Xerox Corporation
737 Hawaii St
El Segundo, CA 90245
Phone: 310-333-5764
Fax: 310-333-5514
EMail: jwenn@cp10.es.xerox.com
IPP Web Page: http://www.pwg.org/ipp/
IPP Mailing List: ipp@pwg.org
To subscribe to the ipp mailing list, send the following email:
1) send it to majordomo@pwg.org
2) leave the subject line blank
3) put the following two lines in the message body:
subscribe ipp
end
12. Other Participants:
Chuck Adams - Tektronix Shivaun Albright - HP
Stefan Andersson - Axis Jeff Barnett - IBM
Ron Bergman - Hitachi Koki Imaging Dennis Carney - IBM
Systems
Keith Carter - IBM Angelo Caruso - Xerox
Rajesh Chawla - TR Computing Nancy Chen - Okidata
Solutions
Josh Cohen - Microsoft Jeff Copeland - QMS
Andy Davidson - Tektronix Roger deBry - IBM
Maulik Desai - Auco Mabry Dozier - QMS
Lee Farrell - Canon Information Satoshi Fujitami - Ricoh
Systems
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
Scott Isaacson - Novell Babek Jahromi - Microsoft
Swen Johnson - Xerox David Kellerman - Northlake
Software
Robert Kline - TrueSpectra Charles Kong - Panasonic
Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
Takami Kurono - Brother Rick Landau - Digital
Scott Lawrence - Agranot Systems Greg LeClair - Epson
Dwight Lewis - Lexmark Harry Lewis - IBM
Tony Liao - Vivid Image Roy Lomicka - Digital
Pete Loya - HP Ray Lutz - Cognisys
Mike MacKay - Novell, Inc. David Manchala - Xerox
Carl-Uno Manros - Xerox Jay Martin - Underscore
Stan McConnell - Xerox Larry Masinter - Xerox
Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
Pat Nogay - IBM Ron Norton - Printronics
Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
Patrick Powell - Astart Jeff Rackowitz - Intermec
Technologies
Eric Random - Peerless Rob Rhoads - Intel
Xavier Riley - Xerox Gary Roberts - Ricoh
David Roach - Unisys Stuart Rowley - Kyocera
Yuji Sasaki - Japan Computer Richard Schneider - Epson
Industry
Kris Schoff - HP Katsuaki Sekiguchi - Canon
Information Systems
Bob Setterbo - Adobe Gail Songer - Peerless
Hideki Tanaka - Cannon Information Devon Taylor - Novell, Inc.
Systems
Mike Timperman - Lexmark Atsushi Uchino - Epson
Shigeru Ueda - Canon Bob Von Andel - Allegro Software
William Wagner - NetSilicon/DPI Jim Walker - DAZEL
Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
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
13. Appendix A: Protocol Examples
13.1 Print-Job Request
The following is an example of a Print-Job request with job-name,
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 "sides" attribute are not supported or their values are not
supported.
Octets Symbolic Value Protocol field
0x0101 1.1 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- name
natural- attributes-natural-language
language
0x0005 value-length
en-us en-US value
0x45 uri type value-tag
0x000B name-length
printer-uri printer-uri name
0x0015 value-length
ipp://forest/ printer pinetree value
pinetree
0x42 nameWithoutLanguage type value-tag
0x0008 name-length
job-name job-name name
0x0006 value-length
foobar foobar value
0x22 boolean type value-tag
0x0016 name-length
ipp-attribute- ipp-attribute-fidelity name
fidelity
0x0001 value-length
0x01 true value
Octets Symbolic Value Protocol field
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
13.2 Print-Job Response (successful)
Here is an example of a successful Print-Job response to the previous
Print-Job request. The printer supported the "copies" and "sides"
attributes and their supplied values. The status code returned is
'successful-ok'.
Octets Symbolic Value Protocol field
0x0101 1.1 version-number
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
Octets Symbolic Value Protocol field
successful-ok successful-ok value
0x02 start job-attributes job-attributes-tag
0x21 integer value-tag
0x0006 name-length
job-id job-id name
0x0004 value-length
147 147 value
0x45 uri type value-tag
0x0007 name-length
job-uri job-uri name
0x0019 value-length
ipp://forest/ job 123 on pinetree value
pinetree/123
0x23 enum 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
13.3 Print-Job Response (failure)
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 support the "sides" attribute and because the value
'20' for the "copies" attribute is not supported. Therefore, no job
is created, and neither a "job-id" nor a "job-uri" operation
attribute is returned. The error code returned is 'client-error-
attributes-or-values-not-supported' (0x040B).
0x0101 1.1 version-number
0x040B client-error-attributes-or- status-code
values-not-supported
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
Octets Symbolic Value Protocol field
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- status-message name
message
0x002F value-length
client-error- value
attributes- values-not-supported
or-values- client-error-attributes-or-
not-supported
0x05 start unsupported-attributes unsupported-attributes tag
0x21 integer type value-tag
0x0006 name-length
copies copies name
0x0004 value-length
0x00000014 20 value
0x10 unsupported (type) value-tag
0x0005 name-length
sides sides name
0x0000 value-length
0x03 end-of-attributes end-of-attributes-tag
13.4 Print-Job Response (success with attributes ignored)
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
'ipp-attribute-fidelity' is false. The print request succeeds, even
though, in this case, the printer supports neither the "sides"
attribute 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 returned. The unsupported attributes are also returned
in an Unsupported Attributes Group. The error code returned is
'successful-ok-ignored-or-substituted-attributes' (0x0001).
Octets Symbolic Value Protocol field
0x0101 1.1 version-number
0x0001 successful-ok-ignored-or- status-code
Octets Symbolic Value Protocol field
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
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
0x002F value-length
successful-ok- successful-ok-ignored-or- value
ignored-or- substituted-attributes
substituted-
attributes
0x05 start unsupported- unsupported-attributes
attributes tag
0x21 integer type value-tag
0x0006 name-length
copies copies name
0x0004 value-length
0x00000014 20 value
0x10 unsupported (type) value-tag
0x0005 name-length
sides sides name
0x0000 value-length
0x02 start job-attributes job-attributes-tag
0x21 integer value-tag
0x0006 name-length
job-id job-id name
0x0004 value-length
147 147 value
0x45 uri type value-tag
0x0007 name-length
job-uri job-uri name
0x0019 value-length
ipp://forest/ job 123 on pinetree value
pinetree/123
Octets Symbolic Value Protocol field
0x23 enum 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
13.5 Print-URI Request
The following is an example of Print-URI request with copies and
job-name parameters:
Octets Symbolic Value Protocol field
0x0101 1.1 version-number
0x0003 Print-URI 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
printer-uri printer-uri name
0x0015 value-length
ipp://forest/ printer pinetree value
pinetree
0x45 uri type value-tag
0x000C name-length
document-uri document-uri name
0x0011 value-length
ftp://foo.com ftp://foo.com/foo value
Octets Symbolic Value Protocol field
/foo
0x42 nameWithoutLanguage type value-tag
0x0008 name-length
job-name job-name name
0x0006 value-length
foobar foobar value
0x02 start job-attributes job-attributes-tag
0x21 integer type value-tag
0x0006 name-length
copies copies name
0x0004 value-length
0x00000001 1 value
0x03 end-of-attributes end-of-attributes-tag
13.6 Create-Job Request
The following is an example of Create-Job request with no parameters
and no attributes:
Octets Symbolic Value Protocol field
0x0101 1.1 version-number
0x0005 Create-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
printer-uri printer-uri name
0x0015 value-length
ipp://forest/ printer pinetree value
pinetree
Octets Symbolic Value Protocol field
inetree
0x03 end-of-attributes end-of-attributes-tag
13.7 Get-Jobs Request
The following is an example of Get-Jobs request with parameters but
no attributes:
Octets Symbolic Value Protocol field
0x0101 1.1 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
0x0015 value-length
ipp://forest/ printer pinetree value
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
Octets Symbolic Value Protocol field
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
13.8 Get-Jobs Response
The following is an of Get-Jobs response from previous request with 3
jobs. The Printer returns no information about the second job
(because of security reasons):
Octets Symbolic Value Protocol field
0x0101 1.1 version-number
0x0000 successful-ok status-code
0x00000123 0x123 request-id (echoed
back)
0x01 start operation-attributes operation-attributes-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
Octets Symbolic Value Protocol field
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
148 149 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
14. Appendix B: Registration of MIME Media Type Information for
"application/ipp"
This appendix contains the information that IANA requires for
registering a MIME media type. The information following this
paragraph will be forwarded to IANA to register application/ipp whose
contents are defined in Section 3 "Encoding of the Operation Layer"
in this document:
MIME type name: application
MIME subtype name: ipp
A Content-Type of "application/ipp" indicates an Internet Printing
Protocol message body (request or response). Currently there is one
version: IPP/1.1, whose syntax is described in Section 3 "Encoding of
the Operation Layer" of [RFC2910], and whose semantics are described
in [RFC2911].
Required parameters: none
Optional parameters: none
Encoding considerations:
IPP/1.1 protocol requests/responses MAY contain long lines and ALWAYS
contain binary data (for example attribute value lengths).
Security considerations:
IPP/1.1 protocol requests/responses do not introduce any security
risks not already inherent in the underlying transport protocols.
Protocol mixed-version interworking rules in [RFC2911] as well as
protocol encoding rules in [RFC2910] are complete and unambiguous.
Interoperability considerations:
IPP/1.1 requests (generated by clients) and responses (generated by
servers) MUST comply with all conformance requirements imposed by the
normative specifications [RFC2911] and [RFC2910]. Protocol encoding
rules specified in [RFC2910] 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.1 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 specifications:
[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S. and P.
Powell, "Internet Printing Protocol/1.1: Model and
Semantics", RFC2911, September 2000.
[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J.
Wenn, "Internet Printing Protocol/1.1: Encoding and
Transport", RFC2910, September 2000.
Applications which use this media type:
Internet Printing Protocol (IPP) print clients and print servers,
communicating using HTTP/1.1 (see [RFC2910]), SMTP/ESMTP, FTP, or
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.
Person & email address to contact for further information:
Tom Hastings
Xerox Corporation
737 Hawaii St. ESAE-231
El Segundo, CA
Phone: 310-333-6413
Fax: 310-333-5514
EMail: hastings@cp10.es.xerox.com
or
Robert Herriot
Xerox Corporation
3400 Hillview Ave., Bldg #1
Palo Alto, CA 94304
Phone: 650-813-7696
Fax: 650-813-6860
EMail: robert.herriot@pahv.xerox.com
Intended usage:
COMMON
15. Appendix C: Changes from IPP/1.0
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
'ipp' scheme. The 'http' and 'https' schemes are supported only
for backward compatibility. See section 5.
2. 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
supported for backward compatibility. See Section 8.1.2
4. 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-uri" and "job-uri" Job Attributes, rather than the URL
scheme used to create the job. See section 9.2.
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 [RFC2911].
7. Clarified that future "out-of-band" value definitions may use the
value field if additional information is needed.
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
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
revoked by the Internet Society or its successors or assigns.
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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.