7472
PROPOSED STANDARD
Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme
Authors: I. McDonald, M. Sweet
Date: March 2015
Working Group: NON WORKING GROUP
Stream: IETF
Updates:
RFC 2910
Abstract
This document defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, which is used to designate the access to the network location of a secure IPP print service or a network resource managed by such a service.
This document defines an alternate IPP transport binding to that defined in the original IPP URL Scheme (RFC 3510), but this document does not update or obsolete RFC 3510.
RFC 7472
PROPOSED STANDARD
Internet Engineering Task Force (IETF) I. McDonald
Request for Comments: 7472 High North, Inc.
Updates: <a href="./rfc2910">2910</a>, <a href="./rfc2911">2911</a> M. Sweet
Category: Standards Track Apple, Inc.
ISSN: 2070-1721 March 2015
<span class="h1">Internet Printing Protocol (IPP) over HTTPS Transport Binding</span>
<span class="h1">and the 'ipps' URI Scheme</span>
Abstract
This document defines the Internet Printing Protocol (IPP) over HTTPS
transport binding and the corresponding 'ipps' URI scheme, which is
used to designate the access to the network location of a secure IPP
print service or a network resource managed by such a service.
This document defines an alternate IPP transport binding to that
defined in the original IPP URL Scheme (<a href="./rfc3510">RFC 3510</a>), but this document
does not update or obsolete <a href="./rfc3510">RFC 3510</a>.
This document updates RFCs 2910 and 2911.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc7472">http://www.rfc-editor.org/info/rfc7472</a>.
<span class="grey">McDonald & Sweet Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc7472">RFC 7472</a> IPP over HTTPS and 'ipps' URI Scheme March 2015</span>
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
<span class="grey">McDonald & Sweet Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc7472">RFC 7472</a> IPP over HTTPS and 'ipps' URI Scheme March 2015</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Structure of This Document .................................<a href="#page-4">4</a>
<a href="#section-1.2">1.2</a>. Rationale for This Document ................................<a href="#page-5">5</a>
<a href="#section-2">2</a>. Conventions Used in This Document ...............................<a href="#page-5">5</a>
<a href="#section-2.1">2.1</a>. Requirements Language ......................................<a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. Printing Terminology .......................................<a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. Abbreviations ..............................................<a href="#page-6">6</a>
<a href="#section-3">3</a>. IPP over HTTPS Transport Binding ................................<a href="#page-7">7</a>
<a href="#section-4">4</a>. Definition of 'ipps' URI Scheme .................................<a href="#page-8">8</a>
<a href="#section-4.1">4.1</a>. Applicability of 'ipps' URI Scheme .........................<a href="#page-8">8</a>
<a href="#section-4.2">4.2</a>. Syntax of 'ipps' URI Scheme ................................<a href="#page-8">8</a>
<a href="#section-4.3">4.3</a>. Associated Port for 'ipps' URI Scheme .....................<a href="#page-10">10</a>
<a href="#section-4.4">4.4</a>. Character Encoding of 'ipps' URI Scheme ...................<a href="#page-10">10</a>
<a href="#section-4.5">4.5</a>. Examples of 'ipps' URIs ...................................<a href="#page-11">11</a>
<a href="#section-4.6">4.6</a>. Comparisons of 'ipps' URIs ................................<a href="#page-12">12</a>
<a href="#section-5">5</a>. IANA Considerations ............................................<a href="#page-12">12</a>
<a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-13">13</a>
<a href="#section-6.1">6.1</a>. Problem Statement .........................................<a href="#page-13">13</a>
<a href="#section-6.1.1">6.1.1</a>. Targets of Attacks .................................<a href="#page-14">14</a>
<a href="#section-6.1.2">6.1.2</a>. Layers of Attacks ..................................<a href="#page-14">14</a>
<a href="#section-6.2">6.2</a>. Attacks and Defenses ......................................<a href="#page-14">14</a>
<a href="#section-6.2.1">6.2.1</a>. Faked 'ipps' URI ...................................<a href="#page-15">15</a>
<a href="#section-6.2.2">6.2.2</a>. Unauthorized Access by IPP Client ..................<a href="#page-15">15</a>
<a href="#section-6.2.3">6.2.3</a>. Compromise at Application Layer Gateway ............<a href="#page-15">15</a>
<a href="#section-6.2.4">6.2.4</a>. No Client Authentication for 'ipps' URI ............<a href="#page-15">15</a>
<a href="#section-6.3">6.3</a>. TLS Version Requirements ..................................<a href="#page-16">16</a>
<a href="#section-7">7</a>. References .....................................................<a href="#page-16">16</a>
<a href="#section-7.1">7.1</a>. Normative References ......................................<a href="#page-16">16</a>
<a href="#section-7.2">7.2</a>. Informative References ....................................<a href="#page-17">17</a>
Acknowledgments ...................................................<a href="#page-19">19</a>
Authors' Addresses ................................................<a href="#page-19">19</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document defines the Internet Printing Protocol (IPP) over HTTPS
transport binding and the corresponding 'ipps' URI scheme, which is
used to designate the access to the network location of a secure IPP
print service or a network resource managed by such a service.
This document has been submitted to the IETF by the Internet Printing
Protocol Working Group (WG) of the IEEE-ISTO Printer Working Group,
as part of their PWG "IPP Everywhere" (PWG 5100.14) project for
secure mobile printing with vendor-neutral Client software.
<span class="grey">McDonald & Sweet Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc7472">RFC 7472</a> IPP over HTTPS and 'ipps' URI Scheme March 2015</span>
This document defines an alternate IPP transport binding to that
defined in the original IPP URL Scheme [<a href="./rfc3510" title=""Internet Printing Protocol/1.1: IPP URL Scheme"">RFC3510</a>], but this document
does not update or obsolete [<a href="./rfc3510" title=""Internet Printing Protocol/1.1: IPP URL Scheme"">RFC3510</a>].
This document updates:
a) "Internet Printing Protocol/1.1: Encoding and Transport"
[<a href="./rfc2910" title=""Internet Printing Protocol/1.1: Encoding and Transport"">RFC2910</a>], by extending <a href="#section-4">Section 4</a> ("Encoding of Transport Layer"),
<a href="#section-5">Section 5</a> ("IPP URL Scheme"); and <a href="#section-8.2">Section 8.2</a> ("Using IPP with
TLS") to add the new standard URI scheme of 'ipps' for IPP
Printers; and
b) "Internet Printing Protocol/1.1: Model and Semantics" [<a href="./rfc2911" title=""Internet Printing Protocol/1.1: Model and Semantics"">RFC2911</a>],
by extending <a href="#section-4.1.6">Section 4.1.6</a> ("uriScheme") and <a href="#section-4.4.1">Section 4.4.1</a>
("printer-uri-supported") to add the new standard URI scheme of
'ipps' for IPP Printers.
The following versions of IPP are currently defined:
a) 1.0 in [<a href="./rfc2566" title=""Internet Printing Protocol/1.0: Model and Semantics"">RFC2566</a>] (obsolete);
b) 1.1 in [<a href="./rfc2911" title=""Internet Printing Protocol/1.1: Model and Semantics"">RFC2911</a>];
c) 2.0 in [<a href="#ref-PWG5100.12" title=""Internet Printing Protocol"">PWG5100.12</a>];
d) 2.1 in [<a href="#ref-PWG5100.12" title=""Internet Printing Protocol"">PWG5100.12</a>]; and
e) 2.2 in [<a href="#ref-PWG5100.12" title=""Internet Printing Protocol"">PWG5100.12</a>].
Overview information about IPP is available in <a href="./rfc2911#section-1">Section 1 of
[RFC2911]</a>, <a href="./rfc3196#section-1">Section 1 of [RFC3196]</a>, and <a href="#section-1">Section 1</a> of PWG "IPP Version
2.0 Second Edition (IPP/2.0 SE)" [<a href="#ref-PWG5100.12" title=""Internet Printing Protocol"">PWG5100.12</a>].
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Structure of This Document</span>
This document contains the following sections:
<a href="#section-2">Section 2</a> defines the conventions and terms used throughout the
document.
<a href="#section-3">Section 3</a> defines the IPP over HTTPS transport binding.
<a href="#section-4">Section 4</a> defines the 'ipps' URI scheme.
Sections <a href="#section-5">5</a> and <a href="#section-6">6</a> contain IANA and security considerations,
respectively.
<a href="#section-7">Section 7</a> contains references.
<span class="grey">McDonald & Sweet Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc7472">RFC 7472</a> IPP over HTTPS and 'ipps' URI Scheme March 2015</span>
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Rationale for This Document</span>
The 'ipps' URI scheme was defined for the following reasons:
1) Some existing IPP Client and IPP Printer implementations of
"Upgrading to TLS Within HTTP/1.1" [<a href="./rfc2817" title=""Upgrading to TLS Within HTTP/1.1"">RFC2817</a>] are flawed and
unreliable, although this is not due to specification defects in
[<a href="./rfc2817" title=""Upgrading to TLS Within HTTP/1.1"">RFC2817</a>] itself.
2) Some existing IPP Client and IPP Printer implementations of HTTP
upgrade [<a href="./rfc2817" title=""Upgrading to TLS Within HTTP/1.1"">RFC2817</a>] do not perform an upgrade at the beginning of
every HTTP [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>] connection; instead, they only shift to
secure IPP for selected IPP operations (inherently dangerous
behavior on the same underlying TCP [<a href="./rfc793" title=""Transmission Control Protocol"">RFC793</a>] connection).
3) IPP Printer server-mandated HTTP upgrade [<a href="./rfc2817" title=""Upgrading to TLS Within HTTP/1.1"">RFC2817</a>] can still lead
to exposure of IPP Client data if the Expect request header is not
used -- basically, the IPP Client can send its whole Print-Job
request before the IPP Printer has a chance to respond and say,
"Wait! You need to encrypt first!".
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Requirements Language</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Printing Terminology</span>
The reader of this document needs to be familiar with the printing
terms defined in "Internet Printing Protocol/1.1: Model and
Semantics" [<a href="./rfc2911" title=""Internet Printing Protocol/1.1: Model and Semantics"">RFC2911</a>] as well as the following:
IPP Client: The software (on some hardware platform) that submits IPP
Job creation and IPP Printer and IPP Job management operations via
the IPP over HTTP transport binding defined in the IPP/1.1
Encoding and Transport document [<a href="./rfc2910" title=""Internet Printing Protocol/1.1: Encoding and Transport"">RFC2910</a>] and/or the IPP over
HTTPS transport binding defined in <a href="#section-3">Section 3</a> of this specification
to an IPP Printer (print spooler, print gateway, or physical
printing device).
IPP Job: The set of attributes and documents for one print job
instantiated in an IPP Printer.
IPP Job object: Synonym for IPP Job.
<span class="grey">McDonald & Sweet Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc7472">RFC 7472</a> IPP over HTTPS and 'ipps' URI Scheme March 2015</span>
IPP Printer: The software (on some hardware platform) that receives
IPP Job creation and IPP Printer and IPP Job management operations
via the IPP over HTTP transport binding defined in the IPP/1.1
Encoding and Transport document [<a href="./rfc2910" title=""Internet Printing Protocol/1.1: Encoding and Transport"">RFC2910</a>] and/or the IPP over
HTTPS transport binding defined in <a href="#section-3">Section 3</a> of this specification
from an IPP Client.
IPP Printer object: Synonym for IPP Printer.
'ipps' URI: A URI using the 'ipps' URI scheme defined in <a href="#section-4">Section 4</a>
of this specification.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Abbreviations</span>
This document makes use of the following abbreviations (given with
their expanded forms and references for further reading):
ABNF - Augmented Backus-Naur Form [<a href="#ref-STD68" title=""Augmented BNF for Syntax Specifications: ABNF"">STD68</a>]
ASCII - American Standard Code for Information Interchange [<a href="#ref-ASCII" title=""Coded Character Set -- 7-bit American Standard Code for Information Interchange"">ASCII</a>]
HTTP - HyperText Transfer Protocol [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>]
HTTPS - HTTP over TLS [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>]
IANA - Internet Assigned Numbers Authority
<<a href="http://www.iana.org">http://www.iana.org</a>>
IEEE - Institute of Electrical and Electronics Engineers
<<a href="http://www.ieee.org">http://www.ieee.org</a>>
IESG - Internet Engineering Steering Group
<<a href="http://www.ietf.org/iesg/">http://www.ietf.org/iesg/</a>>
IPP - Internet Printing Protocol [<a href="./rfc2911" title=""Internet Printing Protocol/1.1: Model and Semantics"">RFC2911</a>] and [<a href="#ref-PWG5100.12" title=""Internet Printing Protocol"">PWG5100.12</a>]
<<a href="http://www.pwg.org/ipp/">http://www.pwg.org/ipp/</a>>
ISTO - IEEE Industry Standards and Technology Organization
<<a href="http://www.ieee-isto.org/">http://www.ieee-isto.org/</a>>
LPD - Line Printer Daemon Protocol [<a href="./rfc1179" title=""Line printer daemon protocol"">RFC1179</a>]
PWG - IEEE-ISTO Printer Working Group
<<a href="http://www.pwg.org">http://www.pwg.org</a>>
RFC - Request for Comments
<<a href="https://www.rfc-editor.org">http://www.rfc-editor.org</a>>
<span class="grey">McDonald & Sweet Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc7472">RFC 7472</a> IPP over HTTPS and 'ipps' URI Scheme March 2015</span>
TCP - Transmission Control Protocol [<a href="./rfc793" title=""Transmission Control Protocol"">RFC793</a>]
TLS - Transport Layer Security [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>]
URI - Uniform Resource Identifier [<a href="#ref-STD66" title=""Uniform Resource Identifier (URI): Generic Syntax"">STD66</a>]
URL - Uniform Resource Locator [<a href="#ref-STD66" title=""Uniform Resource Identifier (URI): Generic Syntax"">STD66</a>]
UTF-8 - Unicode Transformation Format - 8-bit [<a href="#ref-STD63" title=""UTF-8, a transformation format of ISO 10646"">STD63</a>]
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. IPP over HTTPS Transport Binding</span>
This document defines the following alternate IPP over HTTPS
transport binding for the abstract protocol defined in "Internet
Printing Protocol/1.1: Model and Semantics" [<a href="./rfc2911" title=""Internet Printing Protocol/1.1: Model and Semantics"">RFC2911</a>] and IEEE-ISTO
PWG "IPP Version 2.0 Second Edition (IPP/2.0 SE)" [<a href="#ref-PWG5100.12" title=""Internet Printing Protocol"">PWG5100.12</a>].
When using an 'ipps' URI, an IPP Client MUST establish an IPP
application-layer connection according to the following sequence:
1) The IPP Client selects an 'ipps' URI value from a "printer-uri-
supported" Printer attribute [<a href="./rfc2911" title=""Internet Printing Protocol/1.1: Model and Semantics"">RFC2911</a>], a directory entry,
discovery info, a web page, etc.;
2) The IPP Client converts the 'ipps' URI to an 'https' URI [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>]
(replacing 'ipps' with 'https' and inserting the port number from
the URI or port 631 if the URI doesn't include an explicit port
number);
3) The IPP Client establishes an HTTPS [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>] secure session layer
connection to the target endpoint; and
4) The IPP Client sends requests to and receives responses from the
target IPP application-layer resource over the HTTPS [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>]
secure session layer connection using the POST method defined in
[<a href="./rfc7231" title=""Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"">RFC7231</a>].
<span class="grey">McDonald & Sweet Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc7472">RFC 7472</a> IPP over HTTPS and 'ipps' URI Scheme March 2015</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Definition of 'ipps' URI Scheme</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Applicability of 'ipps' URI Scheme</span>
Per PWG "IPP Everywhere" [<a href="#ref-PWG5100.14" title=""PWG IPP Everywhere"">PWG5100.14</a>], in IPP exchanges, the 'ipps'
URI scheme MUST only be used:
a) To specify an absolute URI for IPP secure print services and their
associated network resources;
b) To specify the use of the abstract protocol defined in "Internet
Printing Protocol/1.1: Model and Semantics" [<a href="./rfc2911" title=""Internet Printing Protocol/1.1: Model and Semantics"">RFC2911</a>] and IEEE-
ISTO PWG "IPP Version 2.0 Second Edition (IPP/2.0 SE)"
[<a href="#ref-PWG5100.12" title=""Internet Printing Protocol"">PWG5100.12</a>]; and
c) To specify the use of the transport binding defined in this
document.
The 'ipps' URI scheme allows an IPP Client to choose an appropriate
IPP secure print service (for example, from a directory). The IPP
Client can establish an HTTPS connection to the specified IPP secure
print service. The IPP Client can send IPP requests (for example,
Print-Job requests) and receive IPP responses over that HTTPS
connection.
See: <a href="#section-4.2">Section 4.2</a> ("Syntax of 'ipps' URI Scheme") of this document.
See: <a href="#section-4.4.1">Section 4.4.1</a> ("printer-uri-supported") in [<a href="./rfc2911" title=""Internet Printing Protocol/1.1: Model and Semantics"">RFC2911</a>].
See: <a href="#section-5">Section 5</a> ("IPP URL Scheme") in [<a href="./rfc2910" title=""Internet Printing Protocol/1.1: Encoding and Transport"">RFC2910</a>].
See: <a href="#section-4">Section 4</a> ("IPP Standards") of IEEE-ISTO PWG "IPP Version 2.0
Second Edition (IPP/2.0 SE)" [<a href="#ref-PWG5100.12" title=""Internet Printing Protocol"">PWG5100.12</a>].
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Syntax of 'ipps' URI Scheme</span>
The abstract protocol defined in [<a href="./rfc2911" title=""Internet Printing Protocol/1.1: Model and Semantics"">RFC2911</a>] places a limit of 1023
octets (NOT characters) on the length of a URI.
See: "Uniform Resource Identifier (URI): Generic Syntax" [<a href="#ref-STD66" title=""Uniform Resource Identifier (URI): Generic Syntax"">STD66</a>].
Per PWG "IPP Everywhere" [<a href="#ref-PWG5100.14" title=""PWG IPP Everywhere"">PWG5100.14</a>], for compatibility with
existing IPP implementations, IPP Printers SHOULD NOT generate 'ipp'
[<a href="./rfc3510" title=""Internet Printing Protocol/1.1: IPP URL Scheme"">RFC3510</a>] or 'ipps' URI (or allow administrators to configure)
lengths above 255 octets, because many older IPP Client
implementations do not properly support these lengths.
<span class="grey">McDonald & Sweet Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc7472">RFC 7472</a> IPP over HTTPS and 'ipps' URI Scheme March 2015</span>
Per PWG "IPP Everywhere" [<a href="#ref-PWG5100.14" title=""PWG IPP Everywhere"">PWG5100.14</a>], in IPP exchanges, 'ipps' URIs
MUST be represented in absolute form. Absolute URIs always begin
with a scheme name followed by a colon. For definitive information
on URI syntax and semantics, see "Uniform Resource Identifier (URI):
Generic Syntax and Semantics" [<a href="#ref-STD66" title=""Uniform Resource Identifier (URI): Generic Syntax"">STD66</a>]. This specification adopts the
definitions of "host", "port", and "query" from [<a href="#ref-STD66" title=""Uniform Resource Identifier (URI): Generic Syntax"">STD66</a>]. This
specification adopts the definition of "absolute-path" from
[<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>].
The 'ipps' URI scheme syntax in ABNF [<a href="#ref-STD68" title=""Augmented BNF for Syntax Specifications: ABNF"">STD68</a>] is defined as follows:
ipps-uri =
"ipps:" "//" host [ ":" port ] [ absolute-path [ "?" query ]]
Per [<a href="./rfc2910" title=""Internet Printing Protocol/1.1: Encoding and Transport"">RFC2910</a>], if the port is empty or not given, then port 631 MUST
be used.
See: <a href="#section-4.3">Section 4.3</a> ("Associated Port for 'ipps' URI Scheme") in this
document.
The semantics are that the identified resource (see [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>]) is
located at the IPP secure print service listening for HTTPS
connections on that port of that host; and the Request-URI for the
identified resource is 'absolute-path'.
Note: The higher-level "authority" production is not imported from
[<a href="#ref-STD66" title=""Uniform Resource Identifier (URI): Generic Syntax"">STD66</a>], because it includes an optional "userinfo" component that
cannot be used in 'ipps' URIs.
Note: The "query" production does not have defined semantics in IPP
and was never used in examples in the IPP/1.1 Encoding and Transport
document [<a href="./rfc2910" title=""Internet Printing Protocol/1.1: Encoding and Transport"">RFC2910</a>] or the original IPP URL Scheme [<a href="./rfc3510" title=""Internet Printing Protocol/1.1: IPP URL Scheme"">RFC3510</a>]. The
"query" is retained here for consistency, but IPP Clients SHOULD
avoid its use (because the semantics would be implementation
defined).
Note: Per PWG "IPP Everywhere" [<a href="#ref-PWG5100.14" title=""PWG IPP Everywhere"">PWG5100.14</a>], literal IPv4 or IPv6
addresses SHOULD NOT be used in 'ipps' URIs, because:
a) IP addresses are often changed after network device installation
(for example, based on DHCP reassignment after a power cycle);
b) IP addresses often don't map simply to security domains;
c) IP addresses are difficult to validate with X.509 server
certificates (because they do not map to common name or alternate
name attributes); and
<span class="grey">McDonald & Sweet Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc7472">RFC 7472</a> IPP over HTTPS and 'ipps' URI Scheme March 2015</span>
d) IP link local addresses are not "portable" due to link identity.
Per [<a href="./rfc2910" title=""Internet Printing Protocol/1.1: Encoding and Transport"">RFC2910</a>], if the 'absolute-path' is not present in an IPP URI,
it MUST be given as "/" when used as a Request-URI for a resource
(see [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>]). An 'ipps' URI is transformed into an 'https' URI by
replacing "ipps:" with "https:" and inserting port 631 (if an
explicit 'port' is not present in the original 'ipps' URI).
See: <a href="#section-4.3">Section 4.3</a> ("Associated Port for 'ipps' URI Scheme") in this
document.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Associated Port for 'ipps' URI Scheme</span>
Per [<a href="./rfc2910" title=""Internet Printing Protocol/1.1: Encoding and Transport"">RFC2910</a>], all 'ipps' URIs that do NOT explicitly specify a port
MUST be resolved to IANA-assigned well-known port 631, already
registered in [<a href="#ref-PORTREG" title=""Service Name and Transport Protocol Port Number Registry"">PORTREG</a>] by [<a href="./rfc2910" title=""Internet Printing Protocol/1.1: Encoding and Transport"">RFC2910</a>].
Note: Per direction of the IESG, as described in [<a href="./rfc2910" title=""Internet Printing Protocol/1.1: Encoding and Transport"">RFC2910</a>], port 631
is used for all IPP connections (with or without TLS [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>]).
Therefore, port 631 is used for both 'ipp' [<a href="./rfc3510" title=""Internet Printing Protocol/1.1: IPP URL Scheme"">RFC3510</a>] and 'ipps' URIs,
which both refer to an IPP Printer or a network resource managed by
an IPP Printer. IPP Printer implementors can refer to the CUPS
[<a href="#ref-CUPS" title=""CUPS"">CUPS</a>] source code for an example of incoming connection handling for
the dual use of port 631.
See: IANA Port Numbers Registry [<a href="#ref-PORTREG" title=""Service Name and Transport Protocol Port Number Registry"">PORTREG</a>].
See: [<a href="./rfc2910" title=""Internet Printing Protocol/1.1: Encoding and Transport"">RFC2910</a>].
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Character Encoding of 'ipps' URI Scheme</span>
Per PWG "IPP Everywhere" [<a href="#ref-PWG5100.14" title=""PWG IPP Everywhere"">PWG5100.14</a>], 'ipps' URIs MUST:
a) Use the UTF-8 [<a href="#ref-STD63" title=""UTF-8, a transformation format of ISO 10646"">STD63</a>] charset for all components; and
b) Use [<a href="#ref-STD66" title=""Uniform Resource Identifier (URI): Generic Syntax"">STD66</a>] rules for percent encoding data octets outside the US-
ASCII-coded character set [<a href="#ref-ASCII" title=""Coded Character Set -- 7-bit American Standard Code for Information Interchange"">ASCII</a>].
<span class="grey">McDonald & Sweet Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc7472">RFC 7472</a> IPP over HTTPS and 'ipps' URI Scheme March 2015</span>
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Examples of 'ipps' URIs</span>
The following are examples of well-formed 'ipps' URIs for IPP
Printers (for example, to be used as protocol elements in 'printer-
uri' operation attributes of Print-Job request messages):
ipps://example.com/
ipps://example.com/ipp
ipps://example.com/ipp/faxout
ipps://example.com/ipp/print
ipps://example.com/ipp/scan
ipps://example.com/ipp/print/bob
ipps://example.com/ipp/print/ira
Note: The use of an explicit 'ipp' path component followed by
explicit 'print', 'faxout', 'scan', or other standard or vendor
service component is best practice per [<a href="#ref-PWG5100.14" title=""PWG IPP Everywhere"">PWG5100.14</a>], [<a href="#ref-PWG5100.15" title=""PWG IPP FaxOut Service"">PWG5100.15</a>],
and [<a href="#ref-PWG5100.17" title=""PWG IPP Scan Service"">PWG5100.17</a>].
Each of the above URIs is a well-formed URI for an IPP Printer and
each would reference a logically different IPP Printer, even though
some of those IPP Printers might share the same host system. Note
that 'print' might represent some grouping of IPP Printers (for
example, a load-balancing spooler), while the 'bob' or 'ira' last
path components might represent two different physical printer
devices, or 'bob' and 'ira' might represent separate human recipients
on the same physical printer device (for example, a physical printer
supporting two job queues). Regardless, both 'bob' and 'ira' would
behave as different and independent IPP Printers.
The following are examples of well-formed 'ipps' URIs for IPP
Printers with (optional) ports and paths:
ipps://example.com/
ipps://example.com/ipp/print
ipps://example.com:631/ipp/print
The first and second 'ipps' URIs above will be resolved to port 631
(IANA-assigned well-known port for IPP). The second and third 'ipps'
URIs above are equivalent (see <a href="#section-4.6">Section 4.6</a>).
See: Sections <a href="#section-4.2">4.2</a> ("Syntax of 'ipps' URI Scheme") and 4.3
("Associated Port for 'ipps' URI Scheme") in this document.
<span class="grey">McDonald & Sweet Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc7472">RFC 7472</a> IPP over HTTPS and 'ipps' URI Scheme March 2015</span>
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. Comparisons of 'ipps' URIs</span>
Per PWG "IPP Everywhere" [<a href="#ref-PWG5100.14" title=""PWG IPP Everywhere"">PWG5100.14</a>], when comparing two 'ipps' URIs
to decide whether or not they match, an IPP Client MUST use the same
rules as those defined for 'http' and 'https' URI comparisons in
[<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>], with the following single exception:
- A port that is empty or not given MUST be treated as equivalent to
the well-known port for that 'ipps' URI (port 631).
See: <a href="#section-4.3">Section 4.3</a> ("Associated Port for 'ipps' URI Scheme") in this
document.
See: <a href="#section-2.7.3">Section 2.7.3</a> ("http and https URI Normalization and
Comparison") in [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
IANA has registered the new keyword value 'ipps' for the IPP Printer
"printer-uri-supported" attribute in the IANA IPP Registry [<a href="#ref-IPPREG" title=""Internet Printing Protocol (IPP) Registrations"">IPPREG</a>],
per <a href="#section-6.2">Section 6.2</a> ("Attribute Extensibility") of [<a href="./rfc2911" title=""Internet Printing Protocol/1.1: Model and Semantics"">RFC2911</a>] as follows:
IANA has registered the 'ipps' URI scheme using the following
template, which conforms to [<a href="#ref-BCP35" title=""Guidelines and Registration Procedures for New URI Schemes"">BCP35</a>].
URI scheme name: ipps
Status: Permanent
URI scheme syntax: See <a href="./rfc7472#section-4.2">Section 4.2 of RFC 7472</a>.
URI scheme semantics: The 'ipps' URI scheme is used to designate
secure IPP Printer objects (print spoolers, print gateways, print
devices, etc.) on Internet hosts accessible using the IPP enhanced
to support guaranteed data integrity and negotiable data privacy
using TLS [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] as specified in HTTP/1.1 [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>].
Encoding Considerations: See <a href="./rfc7472#section-4.4">Section 4.4 of RFC 7472</a>.
Applications/protocols that use this URI scheme name: The 'ipps' URI
scheme is intended to be used by applications that need to access
secure IPP Printers using the IPP enhanced to support guaranteed
data integrity and negotiable data privacy using TLS [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] as
specified in HTTP/1.1 [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>]. Such applications may include
(but are not limited to) IPP-capable web browsers, IPP Clients
that wish to print a file, and servers (for example, print
spoolers) wishing to forward a Job for processing.
<span class="grey">McDonald & Sweet Standards Track [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc7472">RFC 7472</a> IPP over HTTPS and 'ipps' URI Scheme March 2015</span>
Interoperability Considerations: The widely deployed, open source IPP
print service CUPS [<a href="#ref-CUPS" title=""CUPS"">CUPS</a>] (on most UNIX, Linux, and Apple OS X
systems) has supported 'ipps' URI for several years before the
publication of this document. PWG "IPP Everywhere" [<a href="#ref-PWG5100.14" title=""PWG IPP Everywhere"">PWG5100.14</a>]
(IPP secure, mobile printing extensions) requires the use of
'ipps' URI for mandatory data integrity and negotiable data
confidentiality.
Security Considerations: See <a href="./rfc7472#section-6">Section 6 of RFC 7472</a>.
Contact: Ira McDonald <blueroofmusic@gmail.com>,
Michael Sweet <msweet@apple.com>
Author/Change controller: IESG
References: RFCs 2910, 2911, and 7472; IEEE-ISTO PWG 5100.12.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Problem Statement</span>
Powerful mobile devices (laptops, tablets, smartphones, etc.) are now
commonly used to access enterprise and Cloud print services across
the public Internet. This is the primary use case for PWG "IPP
Everywhere" [<a href="#ref-PWG5100.14" title=""PWG IPP Everywhere"">PWG5100.14</a>], which has already been adopted by operating
system and printer vendors and several other public standards bodies.
End-user and enterprise documents and user privacy-sensitive
information are at greater risk than ever before. This IPP-over-
HTTPS transport binding and 'ipps' URI scheme specification was
defined to enable high availability combined with secure operation in
this dynamic environment (for example, wireless hotspots in hotels,
airports, and restaurants).
See: <a href="#section-1">Section 1</a> ("Introduction") of [<a href="#ref-PWG5100.14" title=""PWG IPP Everywhere"">PWG5100.14</a>].
See: <a href="#section-3.1">Section 3.1</a> ("Rationale") of [<a href="#ref-PWG5100.14" title=""PWG IPP Everywhere"">PWG5100.14</a>].
<span class="grey">McDonald & Sweet Standards Track [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc7472">RFC 7472</a> IPP over HTTPS and 'ipps' URI Scheme March 2015</span>
<span class="h4"><a class="selflink" id="section-6.1.1" href="#section-6.1.1">6.1.1</a>. Targets of Attacks</span>
A network print spooler (logical printer) or print device (physical
printer) is potentially subject to attacks, which may target:
a) The network (to compromise the routing infrastructure, for
example, by creating congestion);
b) The Internet Printing Protocol (IPP) [<a href="./rfc2911" title=""Internet Printing Protocol/1.1: Model and Semantics"">RFC2911</a>] (for example, to
compromise the normal behavior of IPP);
c) The print job metadata (for example, to extract privacy-sensitive
information from the job submission request or via query of the
job on the IPP Printer); or
d) The print document content itself (for example, to steal the data
or to corrupt the documents being transferred).
<span class="h4"><a class="selflink" id="section-6.1.2" href="#section-6.1.2">6.1.2</a>. Layers of Attacks</span>
Attacks against print services can be launched:
a) Against the network infrastructure (for example, TCP [<a href="./rfc793" title=""Transmission Control Protocol"">RFC793</a>]
congestion control);
b) Against the IPP data flow itself (for example, by sending forged
packets or forcing TLS [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] version downgrade); or
c) Against the IPP operation parameters (for example, by corrupting
requested document processing attributes).
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Attacks and Defenses</span>
This 'ipps' URI Scheme specification adds the following additional
security considerations to those described in [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>], [<a href="./rfc2910" title=""Internet Printing Protocol/1.1: Encoding and Transport"">RFC2910</a>],
[<a href="./rfc2911" title=""Internet Printing Protocol/1.1: Model and Semantics"">RFC2911</a>], [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>], [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>], [<a href="#ref-PWG5100.12" title=""Internet Printing Protocol"">PWG5100.12</a>], and [<a href="#ref-STD66" title=""Uniform Resource Identifier (URI): Generic Syntax"">STD66</a>].
See: <a href="#section-8">Section 8</a> ("Security Considerations") in [<a href="./rfc2910" title=""Internet Printing Protocol/1.1: Encoding and Transport"">RFC2910</a>].
See: <a href="#section-8">Section 8</a> ("Security Considerations") in [<a href="./rfc2911" title=""Internet Printing Protocol/1.1: Model and Semantics"">RFC2911</a>].
See: <a href="#appendix-D">Appendix D</a> ("Implementation Notes"), <a href="#appendix-E">Appendix E</a> ("Backward
Compatibility"), and <a href="#appendix-F">Appendix F</a> ("Security Analysis") of
[<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>].
See: <a href="#section-10">Section 10</a> ("Security Considerations") in [<a href="#ref-PWG5100.12" title=""Internet Printing Protocol"">PWG5100.12</a>].
See: <a href="#section-7">Section 7</a> ("Security Considerations") in [<a href="#ref-STD66" title=""Uniform Resource Identifier (URI): Generic Syntax"">STD66</a>].
<span class="grey">McDonald & Sweet Standards Track [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc7472">RFC 7472</a> IPP over HTTPS and 'ipps' URI Scheme March 2015</span>
<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>. Faked 'ipps' URI</span>
An 'ipps' URI might be faked to point to a rogue IPP secure print
service, thus collecting confidential job metadata or document
contents from IPP Clients.
Due to administrator reconfiguration or physical relocation of an IPP
Printer, a former literal IPv4 or IPv6 address might no longer be
valid. See <a href="#section-4.2">Section 4.2</a> ("Syntax of 'ipps' URI Scheme") for the
recommendation against the use of literal IP addresses in 'ipps' URI.
Server authentication mechanisms and security mechanisms specified in
IPP/1.1 Encoding and Transport [<a href="./rfc2910" title=""Internet Printing Protocol/1.1: Encoding and Transport"">RFC2910</a>], HTTP/1.1 [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>], and
TLS/1.2 [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] can be used to address this threat.
<span class="h4"><a class="selflink" id="section-6.2.2" href="#section-6.2.2">6.2.2</a>. Unauthorized Access by IPP Client</span>
An 'ipps' URI might be used to access an IPP secure print service by
an unauthorized IPP Client, for example, extracting privacy-sensitive
information such as "job-originating-user-name" job metadata defined
in [<a href="./rfc2911" title=""Internet Printing Protocol/1.1: Model and Semantics"">RFC2911</a>].
Client authentication mechanisms and security mechanisms specified in
IPP/1.1 Encoding and Transport [<a href="./rfc2910" title=""Internet Printing Protocol/1.1: Encoding and Transport"">RFC2910</a>], HTTP/1.1 [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>], and
TLS/1.2 [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] can be used to address this threat.
<span class="h4"><a class="selflink" id="section-6.2.3" href="#section-6.2.3">6.2.3</a>. Compromise at Application Layer Gateway</span>
An 'ipps' URI might be used to access an IPP secure print service at
a print protocol application layer gateway (for example, an IPP to
LPD [<a href="./rfc1179" title=""Line printer daemon protocol"">RFC1179</a>] gateway [<a href="./rfc2569" title=""Mapping between LPD and IPP Protocols"">RFC2569</a>]), potentially causing silent
compromise of IPP security mechanisms.
There is no general defense against this threat by an IPP Client.
System administrators SHOULD avoid such configurations.
<span class="h4"><a class="selflink" id="section-6.2.4" href="#section-6.2.4">6.2.4</a>. No Client Authentication for 'ipps' URI</span>
An 'ipps' URI does not define parameters to specify the required IPP
Client authentication mechanism (for example, 'certificate' as
defined in <a href="#section-4.4.2">Section 4.4.2</a> ("uri-authentication-supported") of
[<a href="./rfc2911" title=""Internet Printing Protocol/1.1: Model and Semantics"">RFC2911</a>]).
An IPP Client SHOULD first use service discovery or directory
protocols (e.g., the "Lightweight Directory Access Protocol (LDAP):
Schema for Printer Services" [<a href="./rfc3712" title=""Lightweight Directory Access Protocol (LDAP): Schema for Printer Services"">RFC3712</a>]) or directly send an IPP Get-
Printer-Attributes operation to the target IPP Printer to read
<span class="grey">McDonald & Sweet Standards Track [Page 15]</span><span id="page-16" ></span>
<span class="grey"><a href="./rfc7472">RFC 7472</a> IPP over HTTPS and 'ipps' URI Scheme March 2015</span>
"printer-uri-supported", "uri-authentication-supported", and "uri-
security-supported" attributes to discover the required IPP Client
authentication and security mechanisms for each supported URI.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. TLS Version Requirements</span>
Per PWG "IPP Everywhere" [<a href="#ref-PWG5100.14" title=""PWG IPP Everywhere"">PWG5100.14</a>] (and in accordance with
security best practices and all existing deployments of the 'ipps'
URI scheme), IPP Clients and IPP Printers that support this
specification MUST use TLS/1.2 [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] or a higher version, for all
'ipps' secure transport layer connections.
Implementors will find useful advice in the "Recommendations for
Secure Use of TLS and DTLS" [<a href="#ref-TLSBCP" title=""Recommendations for Secure Use of TLS and DTLS"">TLSBCP</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-ASCII">ASCII</a>] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
[<a id="ref-PWG5100.12">PWG5100.12</a>] Bergman, R., Lewis, H., McDonald, I., and M. Sweet,
"Internet Printing Protocol", Version 2.0, Second
Edition (IPP/2.0 SE), PWG 5100.12, February 2011,
<<a href="http://www.pwg.org/standards.html">http://www.pwg.org/standards.html</a>>.
[<a id="ref-PWG5100.14">PWG5100.14</a>] McDonald, I. and M. Sweet, "PWG IPP Everywhere", PWG
5100.14, January 2013,
<<a href="http://www.pwg.org/standards.html">http://www.pwg.org/standards.html</a>>.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC2910">RFC2910</a>] Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and
J. Wenn, "Internet Printing Protocol/1.1: Encoding and
Transport", <a href="./rfc2910">RFC 2910</a>, September 2000,
<<a href="https://www.rfc-editor.org/info/rfc2910">http://www.rfc-editor.org/info/rfc2910</a>>.
[<a id="ref-RFC2911">RFC2911</a>] Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S.,
and P. Powell, "Internet Printing Protocol/1.1: Model
and Semantics", <a href="./rfc2911">RFC 2911</a>, September 2000,
<<a href="https://www.rfc-editor.org/info/rfc2911">http://www.rfc-editor.org/info/rfc2911</a>>.
<span class="grey">McDonald & Sweet Standards Track [Page 16]</span><span id="page-17" ></span>
<span class="grey"><a href="./rfc7472">RFC 7472</a> IPP over HTTPS and 'ipps' URI Scheme March 2015</span>
[<a id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>, August
2008, <<a href="https://www.rfc-editor.org/info/rfc5246">http://www.rfc-editor.org/info/rfc5246</a>>.
[<a id="ref-RFC7230">RFC7230</a>] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Message Syntax and
Routing", <a href="./rfc7230">RFC 7230</a>, June 2014,
<<a href="https://www.rfc-editor.org/info/rfc7230">http://www.rfc-editor.org/info/rfc7230</a>>.
[<a id="ref-RFC7231">RFC7231</a>] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Semantics and Content",
<a href="./rfc7231">RFC 7231</a>, June 2014,
<<a href="https://www.rfc-editor.org/info/rfc7231">http://www.rfc-editor.org/info/rfc7231</a>>.
[<a id="ref-STD63">STD63</a>] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, <a href="./rfc3629">RFC 3629</a>, November 2003,
<<a href="https://www.rfc-editor.org/info/sstd63">http://www.rfc-editor.org/info/sstd63</a>>.
[<a id="ref-STD66">STD66</a>] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, <a href="./rfc3986">RFC</a>
<a href="./rfc3986">3986</a>, January 2005,
<<a href="https://www.rfc-editor.org/info/std66">http://www.rfc-editor.org/info/std66</a>>.
[<a id="ref-STD68">STD68</a>] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>, January
2008, <<a href="https://www.rfc-editor.org/info/std68">http://www.rfc-editor.org/info/std68</a>>.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-BCP35">BCP35</a>] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", <a href="https://www.rfc-editor.org/bcp/bcp35">BCP 35</a>,
<a href="./rfc4395">RFC 4395</a>, February 2006,
<<a href="https://www.rfc-editor.org/info/bcp35">http://www.rfc-editor.org/info/bcp35</a>>.
[<a id="ref-CUPS">CUPS</a>] Apple, "CUPS", Version 2.0.2, <<a href="https://www.cups.org/">https://www.cups.org/</a>>.
[<a id="ref-IPPREG">IPPREG</a>] Internet Assigned Numbers Authority (IANA) Registries,
"Internet Printing Protocol (IPP) Registrations",
<<a href="http://www.iana.org/assignments/ipp-registrations/">http://www.iana.org/assignments/ipp-registrations/</a>>.
[<a id="ref-PORTREG">PORTREG</a>] Internet Assigned Numbers Authority (IANA) Registries,
"Service Name and Transport Protocol Port Number
Registry",
<<a href="http://www.iana.org/assignments/port-numbers">http://www.iana.org/assignments/port-numbers</a>>.
[<a id="ref-PWG5100.15">PWG5100.15</a>] M. Sweet, "PWG IPP FaxOut Service", PWG 5100.15, June
2014, <<a href="http://www.pwg.org/standards.html">http://www.pwg.org/standards.html</a>>.
<span class="grey">McDonald & Sweet Standards Track [Page 17]</span><span id="page-18" ></span>
<span class="grey"><a href="./rfc7472">RFC 7472</a> IPP over HTTPS and 'ipps' URI Scheme March 2015</span>
[<a id="ref-PWG5100.17">PWG5100.17</a>] P. Zehler, "PWG IPP Scan Service", PWG 5100.17,
September 2014, <<a href="http://www.pwg.org/standards.html">http://www.pwg.org/standards.html</a>>.
[<a id="ref-RFC793">RFC793</a>] Postel, J., "Transmission Control Protocol", STD 7, <a href="./rfc793">RFC</a>
<a href="./rfc793">793</a>, September 1981,
<<a href="https://www.rfc-editor.org/info/rfc793">http://www.rfc-editor.org/info/rfc793</a>>.
[<a id="ref-RFC1179">RFC1179</a>] McLaughlin, L., "Line printer daemon protocol", <a href="./rfc1179">RFC</a>
<a href="./rfc1179">1179</a>, August 1990,
<<a href="https://www.rfc-editor.org/info/rfc1179">http://www.rfc-editor.org/info/rfc1179</a>>.
[<a id="ref-RFC2566">RFC2566</a>] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and
P. Powell, "Internet Printing Protocol/1.0: Model and
Semantics", <a href="./rfc2566">RFC 2566</a>, April 1999,
<<a href="https://www.rfc-editor.org/info/rfc2566">http://www.rfc-editor.org/info/rfc2566</a>>.
[<a id="ref-RFC2569">RFC2569</a>] Herriot, R., Ed., Hastings, T., Jacobs, N., and J.
Martin, "Mapping between LPD and IPP Protocols", <a href="./rfc2569">RFC</a>
<a href="./rfc2569">2569</a>, April 1999,
<<a href="https://www.rfc-editor.org/info/rfc2569">http://www.rfc-editor.org/info/rfc2569</a>>.
[<a id="ref-RFC2817">RFC2817</a>] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", <a href="./rfc2817">RFC 2817</a>, May 2000,
<<a href="https://www.rfc-editor.org/info/rfc2817">http://www.rfc-editor.org/info/rfc2817</a>>.
[<a id="ref-RFC3196">RFC3196</a>] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H.
Holst, "Internet Printing Protocol/1.1: Implementor's
Guide", <a href="./rfc3196">RFC 3196</a>, November 2001,
<<a href="https://www.rfc-editor.org/info/rfc3196">http://www.rfc-editor.org/info/rfc3196</a>>.
[<a id="ref-RFC3510">RFC3510</a>] Herriot, R. and I. McDonald, "Internet Printing
Protocol/1.1: IPP URL Scheme", <a href="./rfc3510">RFC 3510</a>, April 2003,
<<a href="https://www.rfc-editor.org/info/rfc3510">http://www.rfc-editor.org/info/rfc3510</a>>.
[<a id="ref-RFC3712">RFC3712</a>] Fleming, P. and I. McDonald, "Lightweight Directory
Access Protocol (LDAP): Schema for Printer Services",
<a href="./rfc3712">RFC 3712</a>, February 2004,
<<a href="https://www.rfc-editor.org/info/rfc3712">http://www.rfc-editor.org/info/rfc3712</a>>.
[<a id="ref-TLSBCP">TLSBCP</a>] Scheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", Work
in Progress, <a href="./draft-ietf-uta-tls-bcp">draft-ietf-uta-tls-bcp</a>, December 2014.
<span class="grey">McDonald & Sweet Standards Track [Page 18]</span><span id="page-19" ></span>
<span class="grey"><a href="./rfc7472">RFC 7472</a> IPP over HTTPS and 'ipps' URI Scheme March 2015</span>
Acknowledgments
This document has been submitted to the IETF by the Internet Printing
Protocol Working Group of the IEEE-ISTO Printer Working Group, as
part of their PWG IPP Everywhere [<a href="#ref-PWG5100.14" title=""PWG IPP Everywhere"">PWG5100.14</a>] project for secure
mobile printing with vendor-neutral Client software.
This document defines an alternate IPP transport binding to that
defined in the original IPP URL Scheme [<a href="./rfc3510" title=""Internet Printing Protocol/1.1: IPP URL Scheme"">RFC3510</a>], but this document
does not update or obsolete [<a href="./rfc3510" title=""Internet Printing Protocol/1.1: IPP URL Scheme"">RFC3510</a>].
Thanks to Claudio Allochio, Jari Arrko, Spencer Dawkins, Adrian
Farrel, Tom Hastings, Bjoern Hoerhmann, Smith Kennedy, Graham Klyne,
Barry Leiba, S. Moonesamy, Kathleen Moriarty, Sandra Murphy, Tom
Petch, Pete Resnick, Benson Schliesser, Robert Sparks, Jerry
Thrasher, Mykyta Yevstifeyev, Pete Zehler, and the members of the
IEEE-ISTO PWG IPP WG.
Authors' Addresses
Ira McDonald
High North, Inc.
221 Ridge Ave
Grand Marais, MI 49839
United States
Phone: +1 906-494-2434
EMail: [email protected]
Michael Sweet
Apple, Inc.
1 Infinite Loop, M/S 111-HOMC
Cupertino, CA 95014
United States
EMail: [email protected]
McDonald & Sweet Standards Track [Page 19]
Annotations
Select text to annotate