Skip to main content

IPP over HTTPS Transport Binding and 'ipps' URI Scheme
draft-mcdonald-ipps-uri-scheme-16

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7472.
Authors Ira McDonald , Michael Sweet
Last updated 2014-11-25 (Latest revision 2014-11-11)
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources
Stream WG state (None)
Document shepherd Barry Leiba
Shepherd write-up Show Last changed 2014-10-22
IESG IESG state Became RFC 7472 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Barry Leiba
Send notices to blueroofmusic@gmail.com, msweet@apple.com, draft-mcdonald-ipps-uri-scheme.all@tools.ietf.org, barryleiba@computer.org
IANA IANA review state IANA OK - Actions Needed
draft-mcdonald-ipps-uri-scheme-16
Network Working Group                                       Ira McDonald
INTERNET-DRAFT                                            High North Inc
Updates: 2910, 2911 (if approved)                          Michael Sweet
Intended Status: Standards Track                               Apple Inc
Expires: 11 May 2015                                    11 November 2014

         IPP over HTTPS Transport Binding and 'ipps' URI Scheme
                 draft-mcdonald-ipps-uri-scheme-16.txt

Abstract 

   This document defines the Internet Printing Protocol (IPP) over HTTPS
   transport binding and the corresponding 'ipps' URI scheme, that 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.  
   
   This document updates RFC 2910 and RFC 2911.  

Status of this Memo 

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.  
   
   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress." 
   
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html 
   
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html 
   
   This Internet-Draft will expire on 11 May 2015.  

Copyright Notice 

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.  

McDonald, Sweet               Expires 10 May 2015               [Page 1]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   
   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) 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.  

McDonald, Sweet               Expires 10 May 2015               [Page 2]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

                           Table of Contents

1.  Introduction ...............................................       4
  1.1.  Structure of this Document .............................       4
  1.2.  Rationale for this document ............................       5
2.  Conventions Used in this Document ..........................       5
  2.1.  Printing Terminology ...................................       5
3.  IPP over HTTPS Transport Binding ...........................       6
4.  Definition of 'ipps' URI Scheme ............................       7
  4.1.  Applicability of 'ipps' URI Scheme .....................       7
  4.2.  Syntax of 'ipps' URI Scheme ............................       7
  4.3.  Associated Port for 'ipps' URI Scheme ..................       9
  4.4.  Character Encoding of 'ipps' URI Scheme ................       9
  4.5.  Examples of 'ipps' URI .................................      10
  4.6.  Comparisons of 'ipps' URI ..............................      10
5.  IANA Considerations ........................................      11
6.  Security Considerations ....................................      12
  6.1.  Problem Statement ......................................      12
    6.1.1.  Targets of Attacks .................................      12
    6.1.2.  Layers of Attacks ..................................      13
  6.2.  Attacks and Defenses ...................................      13
    6.2.1.  Faked 'ipps' URI ...................................      13
    6.2.2.  Unauthorized Access by IPP Client ..................      14
    6.2.3.  Compromise at Application Layer Gateway ............      14
    6.2.4.  No Client Authentication for 'ipps' URI ............      14
  6.3.  TLS Version Requirements ...............................      14
7.  Acknowledgments ............................................      15
8.  References .................................................      15
  8.1.  Normative References ...................................      15
  8.2.  Informative References .................................      16
9.  Appendix A - Abbreviations .................................      17
10.  Appendix X - Change History ...............................      18
11.  Authors' Addresses ........................................      27

McDonald, Sweet               Expires 10 May 2015               [Page 3]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

1.  Introduction

   This document defines the Internet Printing Protocol (IPP) over HTTPS
   transport binding and the corresponding 'ipps' URI scheme, that 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 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.  
   
   This document defines an alternate IPP transport binding to that
   defined in the original IPP URL Scheme [RFC3510], but this document
   does not update or obsolete [RFC3510].  
   
   This document updates [RFC2910] and [RFC2911].  
   
   This document updates:  
   a) IPP/1.1 Encoding and Transport [RFC2910], by extending section 4
      'Encoding of the Transport Layer', section 5 'IPP URL Scheme', and
      section 8.2 'Using IPP with TLS'; 
   b) IPP/1.1 Model and Semantics [RFC2911], by extending section 4.1.6 
      'uriScheme' and section 4.4.1 'printer-uri-supported'; and 
   c) IEEE-ISTO PWG IPP Version 2.0 Second Edition [PWG5100.12], by
      extending section 4 'IPP Standards' and section 10 'Security
      Considerations'.  
   
   The following versions of IPP are currently defined:  
   a) 1.0 in [RFC2566] (obsolete); 
   b) 1.1 in [RFC2911]; 
   c) 2.0 in [PWG5100.12]; 
   d) 2.1 in [PWG5100.12]; and 
   e) 2.2 in [PWG5100.12].  
   
   Overview information about IPP is available in section 1 of RFC 2911 
   [RFC2911], section 1 of RFC 3196 [RFC3196], and section 1 of PWG IPP 
   Version 2.0 Second Edition [PWG5100.12].  

1.1.  Structure of this Document

   This document contains the following sections:  
   
   Section 2 defines the conventions and terms used throughout the
   document.  
   
   Section 3 defines the IPP over HTTPS transport binding.  

McDonald, Sweet               Expires 10 May 2015               [Page 4]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   
   Section 4 defines the 'ipps' URI scheme.  
   
   Sections 5 and 6 contain IANA and security considerations,
   respectively.  
   
   Section 7 contains acknowledgments.  
   
   Section 8 contains references.  

1.2.  Rationale for this document

   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 [RFC 2817] are flawed and
      unreliable.  
      
   2) Some existing IPP Client and IPP Printer implementations of HTTP
      Upgrade [RFC 2717] do not perform upgrade at the beginning of
      every HTTP connection, but instead only shift to secure IPP for
      selected IPP operations (inherently dangerous behavior on the same
      underlying TCP connection).  
      
   3) IPP Printer server-mandated HTTP Upgrade [RFC 2817] 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!" 

2.  Conventions Used in this Document

   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 RFC 2119 [RFC2119].  

2.1.  Printing Terminology

   The reader of this document needs to be familiar with the printing
   terms defined in IPP/1.1 Model and Semantics [RFC2911] 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 [RFC2910] and/or the IPP over HTTPS transport

McDonald, Sweet               Expires 10 May 2015               [Page 5]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   binding defined in section 3 of this specification to a downstream
   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.  
   
   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 [RFC2910] and/or the IPP over HTTPS transport
   binding defined in section 3 of this specification from an upstream
   IPP Client or IPP Printer.  
   
   IPP Printer object:  Synonym for IPP Printer.  
   
   'ipps' URI:  A URI using the 'ipps' URI scheme defined in section 4
   of this specification.  

3.  IPP over HTTPS Transport Binding

   This document defines the following alternate IPP over HTTPS
   transport binding for the abstract protocol defined in IPP/1.1 Model
   and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version 2.0 Second
   Edition [PWG5100.12].  
   
   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
      "printer-uri-supported" Printer attribute [RFC2911], a directory
      entry, discovery info, a web page, etc.; 
      
   2) The IPP Client converts the 'ipps' URI to an 'https' URI [RFC7230]
      (replacing 'ipps' with 'https' and inserting the port number from
      the URI or port 631 if the URI doesn't include a port number); 
      
   3) The IPP Client establishes a TCP [STD7] transport layer connection
      to the target endpoint - see section 3.4 'Establishing a
      connection' in TCP [STD7]; 
      
   4) The IPP Client establishes a TLS/1.2 [RFC5246] or higher version
      secure transport layer connection to the target endpoint - see
      section 7 'TLS Handshaking Protocols' in [RFC5246]; 
      

McDonald, Sweet               Expires 10 May 2015               [Page 6]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   5) The IPP Client establishes an HTTPS [RFC7230] secure session layer
      connection over the TLS secure transport layer to the target
      endpoint; and 
      
   6) The IPP Client sends IPP application layer requests to and
      receives responses from the IPP Printer over the HTTPS [RFC7230]
      secure session layer connection using the POST method defined in
      [RFC7231].  

4.  Definition of 'ipps' URI Scheme

4.1.  Applicability of 'ipps' URI Scheme

   Per PWG IPP Everywhere [PWG5100.14], in IPP protocol exchanges, the
   'ipps' URI scheme MUST only be used:  
   a) To specify absolute URI for IPP secure print services and their
      their associated network resources; 
   b) To specify the use of the abstract protocol defined in IPP/1.1
      Model and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version 2.0
      Second Edition [PWG5100.12]; 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 protocol requests (for
   example, 'Print-Job' requests) and receive IPP protocol responses
   over that HTTPS connection.  
   
   See:  Section 4.2 (syntax) of this document.  
   
   See:  Section 4.4.1 'printer-uri-supported' in IPP/1.1 Model and
   Semantics [RFC2911].  
   
   See:  Section 5 'IPP URL Scheme' in IPP/1.1 Encoding and Transport
   [RFC2910].  
   
   See:  Section 4 'IPP Standards' of IEEE-ISTO PWG IPP Version 2.0
   Second Edition [PWG5100.12].  

4.2.  Syntax of 'ipps' URI Scheme

   The abstract protocol defined in IPP/1.1 Model and Semantics
   [RFC2911] places a limit of 1023 octets (NOT characters) on the

McDonald, Sweet               Expires 10 May 2015               [Page 7]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   length of a URI.  
   
   See:  URI Generic Syntax [STD66].  
   
   Per PWG IPP Everywhere [PWG5100.14], for compatibility with existing
   IPP implementations, IPP Printers SHOULD NOT generate (or allow
   administrators to configure) URI lengths above 255 octets, because
   many older IPP Client implementations do not properly support these
   lengths.  
   
   Per PWG IPP Everywhere [PWG5100.14], in IPP protocol exchanges,
   'ipps' URI MUST be represented in absolute form.  Absolute URI always
   begin with a scheme name followed by a colon.  For definitive
   information on URI syntax and semantics, see "Uniform Resource
   Identifiers (URI) Generic Syntax and Semantics" [STD66].  This
   specification adopts the definitions of "host", "port", and "query"
   from [STD66].  This specification adopts the definition of
   "absolute-path" from [RFC7230].  
   
   The 'ipps' URI scheme syntax in ABNF [STD68] is defined as follows:  
   
   ipps-uri =
       "ipps:" "//" host [ ":" port ] [ absolute-path [ "?" query ]]
   
   Per IPP/1.1 Encoding and Transport [RFC2910], if the port is empty or
   not given, then port 631 MUST be used.  
   
   See:  Section 4.3 (port) in this document.  
   
   The semantics are that the identified resource (see [RFC7230]) 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
   [STD66], because it includes an optional "userinfo" component which
   cannot be used in 'ipps' URI.  
   
   Note:  The "query" production does not have defined semantics in IPP 
   and was never used in examples in IPP/1.1 Encoding and Transport
   [RFC2910] or the original IPP URL Scheme [RFC3510].  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 [PWG5100.14], literal IPv4 or IPv6
   addresses SHOULD NOT be used in 'ipps' URI, 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

McDonald, Sweet               Expires 10 May 2015               [Page 8]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

      name attributes); and 
   d) IP link local addresses are not "portable" due to link identity 
   
   Per IPP/1.1 Encoding and Transport [RFC2910], 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 [RFC7230]).  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:  Section 4.3 (port) in this document.  

4.3.  Associated Port for 'ipps' URI Scheme

   Per IPP/1.1 Encoding and Transport [RFC2910], all 'ipps' URI which do
   NOT explicitly specify a port MUST be resolved to IANA-assigned
   well-known port 631, already registered in [PORTREG] by [RFC2910].  
   
   Note:  Per direction of the IESG, as described in [RFC2910], port 631
   is used for all IPP protocol connections (with or without TLS).  Port
   631 is therefore used for both 'ipp' [RFC3510] and 'ipps' URI, which 
   both refer to an IPP Printer or a network resource managed by an IPP 
   Printer.  IPP Printer implementors can refer to the CUPS [CUPS]
   source code for an example of incoming connection handling for the
   dual use of port 631.  
   
   Per PWG IPP Everywhere [PWG5100.14], for compatibility with existing
   IPP implementations, IPP Clients and IPP Printers MUST accept
   explicit port 443 (assigned in the 'https' URI scheme [RFC7230]) in
   'ipps' URI values.  
   
   See:  IANA Port Numbers Registry [PORTREG].  
   
   See:  IPP/1.1 Encoding and Transport [RFC2910].  

4.4.  Character Encoding of 'ipps' URI Scheme

   Per PWG IPP Everywhere [PWG5100.14], 'ipps' URI MUST:  
   a) Use the UTF-8 [STD63] charset for all components; and 
   b) Use [STD66] rules for percent encoding data octets outside the
      US-ASCII coded character set [ASCII].  

McDonald, Sweet               Expires 10 May 2015               [Page 9]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

4.5.  Examples of 'ipps' URI

   The following are examples of well-formed 'ipps' URI 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/tiger/
       ipps://example.com/ipp/fox/
       ipps://example.com/ipp/tiger/bob/
       ipps://example.com/ipp/tiger/ira/
   
   Each of the above URI 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.  The
   'bob' or 'ira' last path components might represent two different
   physical printer devices, while 'tiger' might represent some grouping
   of IPP Printers (for example, a load-balancing spooler).  Or the
   'bob' and 'ira' last path components might represent separate human
   recipients on the same physical printer device (for example, a
   physical printer supporting two job queues).  In either case, both
   'bob' and 'ira' would behave as different and independent IPP
   Printers.  
   
   The following are examples of well-formed 'ipps' URI for IPP Printers
   with (optional) ports and paths:  
   
       ipps://example.com/
       ipps://example.com/ipp/
       ipps://example.com:631/ipp/
       ipps://example.com:443/ipp/
   
   The first and second 'ipps' URI above will be resolved to port 631
   (IANA assigned well-known port for IPP).  The second and third 'ipps'
   URI above are equivalent (see section 4.6).  The fourth 'ipps' URI
   above uses the explicit port 443 (see section 4.3).  
   
   See:  Section 4.2 (syntax) and section 4.3 (port) in this document.  

4.6.  Comparisons of 'ipps' URI

   Per PWG IPP Everywhere [PWG5100.14], when comparing two 'ipps' URI to
   decide if they match or not, an IPP Client MUST use the same rules as
   those defined for 'http' and 'https' URI comparisons in [RFC7230],
   with the single following exception:  

McDonald, Sweet              Expires 10 May 2015               [Page 10]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   
   - 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:  Section 4.3 (port) in this document.  
   
   See:  Section 2.7.3 'http and https URI Normalization and Comparison'
   in [RFC7230].  

5.  IANA Considerations

   [RFC Editor:  Replace 'xxxx' with assigned RFC number before
   publication] 
   
   IANA is asked to register the 'ipps' URI scheme using the following
   template, which conforms to [BCP35].  
   
   URI scheme name:  ipps 
   
   Status:  Permanent 
   
   URI scheme syntax:  See section 4.2 of RFC xxxx.  
   
   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 protocol
   enhanced to support guaranteed data integrity and negotiable data
   privacy using TLS as specified in HTTP/1.1 [RFC7230].  
   
   Encoding Considerations:  See section 4.4 of RFC xxxx.  
   
   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 protocol enhanced to
   support guaranteed data integrity and negotiable data privacy using
   TLS as specified in HTTP/1.1 [RFC7230].  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.  
   
   Interoperability Considerations:  The widely deployed, open source
   IPP print service CUPS [CUPS] (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 [PWG5100.14] (IPP
   secure, mobile printing extensions) requires the use of 'ipps' URI
   for mandatory data integrity and negotiable data confidentiality.  
   
   Security Considerations:  See section 6 of RFC xxxx.  

McDonald, Sweet              Expires 10 May 2015               [Page 11]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   
   Contact:  
   
   Ira McDonald <blueroofmusic@gmail.com> 
   
   Michael Sweet <msweet@apple.com> 
   
   Author/Change controller:  
   
   IESG 
   
   References:  RFC 2910, RFC 2911, RFC xxxx, and IEEE-ISTO PWG 5100.12.

6.  Security Considerations

6.1.  Problem Statement

   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 [PWG5100.14], 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:  Section 1 Introduction of [PWG5100.14].  
   
   See:  Section 3.1 Rationale of [PWG5100.14].  

6.1.1.  Targets of Attacks

   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) [RFC2911] (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 

McDonald, Sweet              Expires 10 May 2015               [Page 12]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   d) The print document content itself (for example, to corrupt the
      documents being transferred).  

6.1.2.  Layers of Attacks

   Attacks against print services can be launched:  
   a) Against the network infrastructure (for example, TCP congestion
      control); 
   b) Against the IPP data flow itself (for example, by sending forged
      packets or forcing TLS version downgrade); or 
   c) Against the IPP operation parameters (for example, by corrupting
      requested document processing attributes).  

6.2.  Attacks and Defenses

   This 'ipps' URI Scheme specification adds the following additional
   security considerations to those described in [RFC7230], [RFC2910],
   [RFC2911], [RFC5246], [RFC7230], [PWG5100.12], and [STD66].  
   
   See:  Section 8 'Security Considerations' in [RFC2910].  
   
   See:  Section 8 'Security Considerations' in [RFC2911].  
   
   See:  Appendix D 'Implementation Notes', Appendix E 'Backward
   Compatibility', and Appendix F 'Security Analysis' of [RFC5246].  
   
   See:  Section 10 'Security Considerations' in [PWG5100.12].  
   
   See:  Section 7 'Security Considerations' in [STD66].  

6.2.1.  Faked 'ipps' URI

   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 section 4.2 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 [RFC2910], HTTP/1.1 [RFC7230], and
   TLS/1.2 [RFC5246] can be used to address this threat.  

McDonald, Sweet              Expires 10 May 2015               [Page 13]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

6.2.2.  Unauthorized Access by IPP Client

   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 IPP/1.1 Model and Semantics [RFC2911].  
   
   Client authentication mechanisms and security mechanisms specified in
   IPP/1.1 Encoding and Transport [RFC2910], HTTP/1.1 [RFC7230], and
   TLS/1.2 [RFC5246] can be used to address this threat.  

6.2.3.  Compromise at Application Layer Gateway

   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 [RFC1179] gateway [RFC2569]), 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.  

6.2.4.  No Client Authentication for 'ipps' URI

   An 'ipps' URI does not define parameters to specify the required IPP 
   Client authentication mechanism (for example, 'certificate' as
   defined in section 4.4.2 'uri-authentication-supported' of IPP Model
   [RFC2911]).  
   
   Either service discovery or directory protocols SHOULD be used first 
   or an IPP Client SHOULD first establish an 'ipp' connection (without 
   TLS or any client authentication) to the target IPP Printer and use a
   Get-Printer-Attributes operation to discover the required IPP Client 
   authentication mechanism(s) associated with a given 'ipps' URI.  

6.3.  TLS Version Requirements

   Per PWG IPP Everywhere [PWG5100.14] (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 [RFC5246] or higher version, for all 'ipps' secure
   transport layer connections.  

McDonald, Sweet              Expires 10 May 2015               [Page 14]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

7.  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 [PWG5100.14] 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 [RFC3510], but this document
   does not update or obsolete [RFC3510].  
   
   Thanks to Claudio Allochio, Tom Hastings (retired from Xerox), Bjoern
   Hoerhmann, Graham Klyne, Barry Leiba, S. Mooneswamy, Tom Petch, Jerry
   Thrasher (Lexmark), Mykyta Yevstifeyev, Pete Zehler (Xerox), and the 
   members of the IEEE-ISTO PWG IPP WG.  

8.  References

8.1.  Normative References

   [ASCII]    "American National Standards Institute, Coded Character
              Set -- 7-bit American Standard Code for Information
              Interchange", ANSI X3.4, 1986.  
              
   [HTTP1.1]     HTTP/1.1.  See [RFC7230], [RFC7231], [RFC7232],
              [RFC7233], [RFC7234], and [RFC7235].  
              
   [PWG5100.12] 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.  
              <http://www.pwg.org/standards.html> 
              
   [PWG5100.14] McDonald, I. and M. Sweet, "PWG IPP Everywhere", PWG
              5100.14, January 2013.  
              <http://www.pwg.org/standards.html> 
              
   [RFC2119]  Bradner, S., Key words for use in RFCs to Indicate
              Requirement Levels, BCP 14, RFC 2119, March 1997.  
              
   [RFC2910]  Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and
              J.  Wenn, "Internet Printing Protocol/1.1:  Encoding and
              Transport", RFC 2910, September 2000.  
              

McDonald, Sweet              Expires 10 May 2015               [Page 15]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   [RFC2911]  Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S.,
              and P. Powell, "Internet Printing Protocol/1.1:  Model and
              Semantics", RFC 2911, September 2000.  
              
   [RFC5246]  Dierks, T., and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.  
              
   [RFC7230]  Fielding, R., and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1):  Message Syntax and Routing, RFC 7230, June
              2014.  
              
   [RFC7231]  Fielding, R., and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1):  Semantics and Content", RFC 7231, June 2014.
              
   [RFC7232]  Fielding, R., and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1):  Conditional Requests", RFC 7232, June 2014.  
              
   [RFC7233]  Fielding, R., Lafon, Y., and J. Reschke, "Hypertext
              Transfer Protocol (HTTP/1.1):  Range Requests", RFC 7233,
              June 2014.  
              
   [RFC7234]  Fielding, R., Nottingham, M., and J. Reschke, "Hypertext
              Transfer Protocol (HTTP/1.1):  Caching", RFC 7234, June
              2014.  
              
   [RFC7234]  Fielding, R., and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1):  Authentication", RFC 7235, June 2014.  
              
   [STD7]     Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.  
              
   [STD63]    Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.  
              
   [STD66]    Berners-Lee, T., Fielding, R., and L. Masinter, Uniform
              Resource Identifiers (URI) Generic Syntax, STD 66, RFC
              3986, January 2005.  
              
   [STD68]    Crocker, D., Ed., and P. Overell, "Augmented BNF for
              Syntax Specifications:  ABNF", STD 68, RFC 5234, January
              2008.  

8.2.  Informative References

   [BCP35]    Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI Schemes", BCP 35, RFC
              4395, February 2006.  
              

McDonald, Sweet              Expires 10 May 2015               [Page 16]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   [CUPS]     Apple, "CUPS standards-based, open source printing system
              for OS X and other UNIX-like operating systems" 
              <https://www.cups.org/> 
              
   [PORTREG]  Internet Assigned Numbers Authority (IANA) Registry "Port
              Numbers" 
              <http://www.iana.org/assignments/port-numbers> 
              
   [RFC1179]  McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179,
              August 1990.  
              
   [RFC2569]  Herriot, R., Ed., Hastings, T., Jacobs, N., and J.
              Martin, "Mapping between LPD and IPP Protocols", RFC 2569,
              April 1999.  
              
   [RFC2817]  Khare, R.  and S.  Lawrence, "Upgrading to TLS Within
              HTTP/1.1", RFC 2817, May 2000.  
              
   [RFC3196]  Hastings, T., Manros, C., Zehler, P., Kugler, C., and H.
              Holst, "Internet Printing Protocol/1.1:  Implementor's
              Guide", RFC 3196, November 2001.  
              
   [RFC3510]  Herriot, R.  and I.  McDonald, "Internet Printing
              Protocol/1.1:  IPP URL Scheme", RFC 3510, April 2003.  

9.  Appendix A - Abbreviations

   This document makes use of the following abbreviations (given with
   their expanded forms and references for further reading):  
   
   ABNF   - Augmented Backus-Naur Form [STD68]
   
   ASCII  - American Standard Code for Information Interchange [ASCII]
   
   HTTP   - HyperText Transfer Protocol [HTTP1.1]
   
   HTTPS  - HTTP over TLS [RFC7230]
   
   IANA   - Internet Assigned Numbers Authority
            <http://www.iana.org>
   
   IEEE   - Institute of Electrical and Electronics Engineers
            <http://www.ieee.org>
   
   IESG   - Internet Engineering Steering Group
            <http://www.ietf.org/iesg/>
   
   IPP    - Internet Printing Protocol [RFC2911] and [PWG5100.12]
            <http://www.pwg.org/ipp/>

McDonald, Sweet              Expires 10 May 2015               [Page 17]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   
   ISTO   - IEEE Industry Standards and Technology Organization
            <http://www.ieee-isto.org/>
   
   LPD    - Line Printer Daemon Protocol [RFC1179]
   
   PWG    - IEEE-ISTO Printer Working Group
            <http://www.pwg.org>
   
   RFC    - Request for Comments
            <http://www.rfc-editor.org/rfc.html>
   
   TCP    - Transmission Control Protocol [STD7]
   
   TLS    - Transport Layer Security [RFC5246]
   
   URI    - Uniform Resource Identifier [STD66]
   
   URL    - Uniform Resource Locator [STD66]
   
   UTF-8  - Unicode Transformation Format - 8-bit [STD63]

10.  Appendix X - Change History

   [RFC Editor:  Delete this section before publication as an RFC] 
   
   11 November 2014 - draft-mcdonald-ipps-uri-scheme-16.txt 
   Editorial - Revised section 3 IPP over HTTPS Transport Binding to
   correct reference to section 7 'TLS Handshaking Protocols' in
   [RFC5246], per advice of Tom Petch on 30 October 2014.  
   Editorial - Revised section 4 Definition of 'ipps' URI Scheme to
   narrow scope to the URI scheme and avoid discussion of associated
   media type, per advice of Graham Klyne and Barry Leiba on 9 November
   2014.  
   Editorial - Revised section 4 Definition of 'ipps' URI Scheme and all
   subsections to state the explicit source of all conformance
   constraints as [RFC2910] or [PWG5100.14], as appropriate, per advice
   of Graham Klyne on 4 November 2014.  
   Editorial - Revised section 4.1 Applicability of 'ipps' URI Scheme to
   add the conformance requirement that the 'ipps' URI scheme MUST only
   be used with the transport binding defined in this document, per
   advice of Tom Petch on 30 October 2014.  
   Editorial - Revised section 4.1 Applicability of 'ipps' URI Scheme to
   remove out-of-scope mention of relative URI, per advice of Graham
   Klyne on 4 November 2014.  
   Editorial - Revised section 4.3 Associated Port for 'ipps' URI Scheme
   to clarify that the dual use of port 631 in the IPP protocol (with or
   without TLS) was an IESG decision, per advice of Graham Klyne on 4
   November 2014.  

McDonald, Sweet              Expires 10 May 2015               [Page 18]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   Editorial - Deleted (former) section 4.4 Associated Media Type for
   'ipps' URI Scheme and removed widowed [MEDIAREG] from section 8.2
   Informative References, per advice of Graham Klyne and Barry Leiba on
   9 November 2014.  
   Editorial - Revised section 4.5 Examples of 'ipps' URI to add missing
   trailing forward slash to all URI examples, consistent w/ section
   4.2, per advice of Graham Klyne on 4 November 2014.  
   Editorial - Revised section 5 IANA Considerations to correct section
   4.4 cross-reference in "Encoding Considerations" clause, per advice
   of Tom Petch on 30 October 2014.  
   Editorial - Revised section 6.1 Problem Statement, section 6.1.1
   Targets of Attacks, and section 6.2.2 Unauthorized Access by IPP
   Client, to address privacy-sensitive job metadata, per advice of
   Graham Klyne on 4 November 2014.  
   Editorial - Revised section 6.2.1 Faked 'ipps' URI to add discussion
   of the reasons to avoid use of literal IP addresses in 'ipps' URI and
   a cross-reference to section 4.2 Syntax of 'ipps' URI Scheme, per
   advice of Tom Petch on 30 October 2014.  
   
   27 October 2014 - draft-mcdonald-ipps-uri-scheme-15.txt 
   Editorial - Kept "Intended Status" as "Standards Track", with AD
   sponsoring, per advice of Barry Leiba on 22 October 2014.  
   Editorial - Revised Abstract to delete mention of submission from
   PWG, per advice of S. Mooneswamy on 13 October 2014 and Barry Leiba
   on 22 October 2014.  
   Editorial - Revised Boilerplate to reflect IETF standards-track, per
   advice of Barry Leiba on 22 October 2014.  
   Editorial - Revised Introduction and Acknowledgments to say "This
   document has been submitted to IETF...", per advice of Barry Leiba on
   22 October 2014.  
   Editorial - Replaced "this memo" with "this document", per advice of
   S. Mooneswamy on 13 October 2014 and Barry Leiba on 22 October 2014.
   Editorial - Replaced [RFC2818] with [RFC7230] for HTTPS and deleted
   [RFC2818] from references, per advice of S. Mooneswamy on 13 October
   2014.  
   Editorial - Revised section 1.1 Structure of this Document to correct
   list of sections per revisions in this draft, per IEEE-ISTO PWG IPP
   WG review, 
   Editorial - Kept section 2.2 Abbreviations to become Appendix A, as a
   compromise to request to remove entirely, per discussion with
   S. Mooneswamy on 13 October 2014.  
   Editorial - Revised section 3 IPP over HTTPS Transport Binding to
   delete (redundant) first paragraph, per advice of S. Mooneswamy on 13
   October 2014.  
   Editorial - Revised section 3 IPP over HTTPS Transport Binding to add
   reference to [RFC7230] for 'https' URI scheme in bullet (2), per
   advice of S. Mooneswamy on 13 October 2014.  
   Editorial - Revised section 3 IPP over HTTPS Transport Binding to
   delete (redundant) "reliable" qualifier of a TCP transport layer
   connection in bullet (3), per advice of S. Mooneswamy on 13 October
   2014.  

McDonald, Sweet              Expires 10 May 2015               [Page 19]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   Editorial - Revised section 3 IPP over HTTPS Transport Binding to
   replace "TLS 1.2 [RFC5246], or later TLS version," with "TLS 1.2
   [RFC5246] or higher version" in bullet (4), consistent with TLS
   future-proofing in current HTTP/2.0 draft, per IEEE-ISTO PWG IPP WG
   review, rejecting request of S. Mooneswamy on 13 October 2014.  
   Editorial - Revised section 3 IPP over HTTPS Transport Binding to
   delete (out-of-date) reference to [RFC2910] in bullet (6), per advice
   of S. Mooneswamy on 13 October 2014.  
   Editorial - Revised section 3 IPP over HTTPS Transport Binding to
   delete references to Security Considerations in other documents, per
   advice of S. Mooneswamy on 13 October 2014.  
   Editorial - Revised section 4.1 Applicability of 'ipps' URI Scheme to
   delete references to Security Considerations in other documents, per
   advice of S. Mooneswamy on 13 October 2014.  
   Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme to
   replace out-of-date reference to [RFC2911] w/ [STD66] (i.e., RFC
   3986), per advice of S. Mooneswamy on 13 October 2014.  
   Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme to move
   conformance requirement out of "Note" and rewrite conformance that
   IPP Printers SHOULD NOT *generate* 'ipps' URI longer than 255 octets,
   due to known implementation bugs in many older IPP Clients, per
   advice of S. Mooneswamy on 13 October 2014.  
   Editorial - Revisions section 4.3 Associated Port for 'ipps' URI
   Scheme to move conformance requirement out of "Note", per advice of
   S. Mooneswamy on 13 October 2014.  
   Editorial - Revised section 4.4 and References to change "MIME type"
   or "MIME media type" to "media type" and "[MIMEREG]"to "[MEDIAREG]", 
   per advice of Barry Leiba on 22 October 2014.  
   Editorial - Revised section 4.6.1 to correct plural/singular
   confusion, per advice of Barry Leiba on 22 October 2014.  
   Editorial - Deleted section 4.6.2 Examples of 'ipps' URI for Jobs,
   because IPP "job-uri" attribute will be deprecated in the future, per
   IEEE-ISTO PWG IPP WG review.  
   Editorial - Delete section 5 Applicability of this Specification
   because it was redundant with conformance imperatives in section 4,
   per advice of S. Mooneswamy on 13 October 2014.  
   Editorial - Kept IESG as change controller in (former) section 6 IANA
   Considerations (since the document remains standards-track),
   rejecting request of S. Mooneswamy on 13 October 2014.  
   Editorial - Revised (former) section 7.3 TLS Version Requirements to 
   replace "TLS 1.2 [RFC5246], or later TLS version," with "TLS 1.2
   [RFC5246] or higher version", consistent with TLS future-proofing in
   current HTTP/2.0 draft, per IEEE-ISTO PWG IPP WG review, rejecting
   request of S. Mooneswamy on 13 October 2014.  
   Editorial - Deleted Appendix A - Summary of IPP URL Scheme, due to
   ambiguity and for future-proofing, per IEEE-ISTO PWG IPP WG review.  
   
   28 September 2014 - draft-mcdonald-ipps-uri-scheme-14.txt 
   Editorial - Kept "Intended Status" as "Standards Track", with AD
   sponsoring, per advice of Barry Leiba on 18 August 2014.  

McDonald, Sweet              Expires 10 May 2015               [Page 20]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   Editorial - Revised Abstract, Boilerplate, and Introduction to state 
   that this document is an Independent Submission to the RFC Editor
   Stream with IETF AD sponsoring, per advice of Barry Leiba on 18
   August 2014.  
   Technical - Revised section 3 IPP over HTTPS Transport Binding, to
   require TLS/1.2, or later TLS version, for all 'ipps' connections,
   per IEEE-ISTO PWG IPP WG review.  
   Technical - Revised section 7.2.1 Faked 'ipps' URI and section 7.2.2 
   Unauthorized Access by IPP Client, to delete all references to
   TLS/1.0 and TLS/1.1, per IEEE-ISTO PWG IPP WG review.  
   Technical - Renamed section 7.3 TLS Cipher Suite Requirements to TLS 
   Version Requirements and deleted all requirements for specific cipher
   suites, per IEEE-ISTO PWG IPP WG review.  
   Technical - Revised section 9.1 Normative References, to delete all
   references to TLS/1.0 and TLS/1.1, per IEEE-ISTO PWG IPP WG review.  
   
   3 July 2014 - draft-mcdonald-ipps-uri-scheme-13.txt 
   Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, to
   replace old 'path-absolute' from RFC 2616 with 'absolute-path' from
   [RFC7230], per IEEE-ISTO PWG IPP WG review.  
   Editorial - Revised section 2.2 Abbreviations, section 3 IPP over
   HTTPS Transport Binding, section 4.2 Syntax of 'ipps' URI Scheme,
   section 4.7 Comparisons of 'ipps' URI, section 7.2 Attacks and
   Defenses, section 9.1 Normative References, and section 10 Appendix A
   - Summary of IPP URL Scheme, to replace [RFC2616] with either
   [RFC7230] or [HTTP1.1] - a new collective reference to [RFC7230],
   [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235], per
   IEEE-ISTO PWG IPP WG review.  
   
   20 April 2014 - draft-mcdonald-ipps-uri-scheme-12.txt 
   Editorial - Revised section 4.3 Associated Port for 'ipps' URI
   Scheme, to add informative reference to CUPS, per IEEE-ISTO PWG IPP
   WG review.  
   
   Editorial - Revised section 4.6.1 Examples of 'ipps' URI for
   Printers, to change "third" to "fourth" for the port 443 example, per
   IEEE-ISTO PWG IPP WG review.  
   Editorial - Revised section 6 IANA Considerations, to add informative
   reference to CUPS, per IEEE-ISTO PWG IPP WG review.  
   Editorial - Revised section 9.2 Informative References, to add
   informative reference to CUPS, per IEEE-ISTO PWG IPP WG review.  
   
   7 April 2014 - draft-mcdonald-ipps-uri-scheme-11.txt 
   Global - revised all references to section 4.2 and section 4.3, to
   add parenthetic (syntax) and (port) respectively, per IEEE-ISTO PWG
   IPP WG review.  
   Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, to
   correct two typos (extra words) in section 4.3 references, per
   IEEE-ISTO PWG IPP WG review.  
   Editorial - Revised section 4.3 Associated Port for 'ipps' URI
   Scheme, to add note about compatibility for IPP Clients and IPP

McDonald, Sweet              Expires 10 May 2015               [Page 21]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   Printers that MUST accept explicit port 443 (assigned in 'https' URI
   scheme [RFC7230]) and process normally, per IEEE-ISTO PWG IPP WG
   review.  
   Editorial - Revised section 4.6.1 Examples of 'ipps' URI for
   Printers, to add example of explicit port 443, per IEEE-ISTO PWG IPP
   WG review.  
   
   
   30 March 2014 - draft-mcdonald-ipps-uri-scheme-10.txt 
   Global - Updated references, per IEEE-ISTO PWG IPP WG review.  
   Global - Changed "e.g." to "for example", for readability.  
   Editorial - Revised section Copyright Notice, to correct year.  
   Editorial - Revised section 3 IPP over HTTPS Transport Binding, item
   2), to clarify that port 631 is ONLY inserted in the derived 'https'
   URI when an explicit port is NOT specified in the original 'ipps'
   URI, per Smith Kennedy and IEEE-ISTO PWG IPP WG review.  
   Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, note
   about URI lengths greater than 255 octets, to change 'ought to' to
   'SHOULD', per Smith Kennedy and IEEE-ISTO PWG IPP WG review.  
   Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, to add
   reference to section 4.3 for use of port 631, per Smith Kennedy and
   IEEE-ISTO PWG IPP WG review.  
   Editorial - Revised section 4.3 Associated Port for 'ipps' URI
   Scheme, to add note about dual-use of port 631 for 'ipp' URI and
   'ipps' URI with reference to CUPS source for example of incoming
   connection handling, per Smith Kennedy and IEEE-ISTO PWG IPP WG
   review.  
   Editorial - Revised section 4.3 Associated Port for 'ipps' URI
   Scheme, to add note about compatibility for IPP Clients and IPP
   Printers that should accept explicit port 443 (assigned in 'https'
   URI scheme [RFC7230]) and process normally, per IEEE-ISTO PWG IPP WG
   review.  
   Editorial - Revised section 4.6.1 Examples of 'ipps' URI for
   Printers, to add reference to section 4.2 (syntax) and section 4.3
   (port), per Smith Kennedy and IEEE-ISTO PWG IPP WG review.  
   Editorial - Revised section 4.7 Comparisons of 'ipps' URI, to add
   reference to section 4.3 (port), per Smith Kennedy and IEEE-ISTO PWG
   IPP WG review.  
   Editorial - Revised section 5.1 Applicability to IPP Clients, to add
   reference to section 4.2 (syntax) and section 4.3 (port), per Smith
   Kennedy and IEEE-ISTO PWG IPP WG review.  
   Editorial - Revised section 5.1 Applicability to IPP Clients, item
   d), to change 'MUST the' to 'MUST use the', per Smith Kennedy and
   IEEE-ISTO PWG IPP WG review.  
   Editorial - Revised section 5.2 Applicability to IPP Printers, to add
   reference to section 4.2 (syntax) and section 4.3 (port), per Smith
   Kennedy and IEEE-ISTO PWG IPP WG review.  
   Editorial - Revised section 5.2 Applicability to IPP Printers, item
   d), to change 'MUST the' to 'MUST use the', per Smith Kennedy and
   IEEE-ISTO PWG IPP WG review.  

McDonald, Sweet              Expires 10 May 2015               [Page 22]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   Editorial - Revised section 5.2 Applicability to IPP Printers, to
   delete former item e) (listen only on port 631) which conflicted with
   existing IPP implementations (for example, listening on port 443 as
   well), per Smith Kennedy and IEEE-ISTO PWG IPP WG review.  
   Editorial - Revised section 6 IANA Considerations, to add URI for
   CUPS source, per IEEE-ISTO PWG IPP WG review.  
   Editorial - Revised section 7.2.4 No Client Authentication for 'ipps'
   URI, to change "or or" to "or" (typo), per Smith Kennedy and
   IEEE-ISTO PWG IPP WG review.  
   Editorial - Revised Appendix A Summary of IPP URL Scheme, item 2), to
   clarify that port 631 is ONLY inserted in the derived 'http' URI when
   an explicit port is NOT specified in the original 'ipp' URI, per
   Smith Kennedy and IEEE-ISTO PWG IPP WG review.  
   
   5 November 2013 - draft-mcdonald-ipps-uri-scheme-09.txt 
   Global - Updated references, per IPP WG review.  
   Editorial - Revised Abstract, section 1 Introduction, and section 8
   Acknowledgments to clarify that this document is an individual
   submission to the IETF by the IPP WG of the IEEE-ISTO PWG, per
   S. Mooneswamy.  
   Editorial - Revised Abstract, section 1 Introduction, and section 8
   Acknowledgments to clarify that this document does not update or
   obsolete [RFC3510], per S. Mooneswamy and Tom Petch.  
   Editorial - Revised section 1.1 Structure of this Document to align
   with changes below, per Tom Petch.  
   Editorial - Revised section 2 Conventions Used in this Document to
   add section 2.1 Printing Terminology and to remove redundant "In this
   document" and clarify definitions, per Tom Petch.  
   Editorial - Moved former Appendix B - Abbreviations Used in this
   Document to become section 2.2 Abbreviations, per Tom Petch.  
   Technical - Revised section 3 IPP over HTTPS Transport Binding,
   section 5 Applicability of this Specification, and section 7 Security
   Considerations to address specific TLS/1.0 [RFC2246], TLS/1.1
   [RFC4346], and TLS/1.2 [RFC5246] requirements, per Tom Petch.  
   Editorial - Moved former section 3.1 IPP over HTTP Transport Binding 
   to become Appendix A - Summary of IPP URL Scheme (Informative), per
   Tom Petch.  
   Technical - Revised section 4.2 Syntax of 'ipps' URI Scheme to add
   note about the retention of the (unused) "query" production for
   consistency with IPP/1.1 Encoding and Transport [RFC2910] and the
   original IPP URL Scheme [RFC3510], but warn that it has no defined
   semantics in IPP and therefore its use is unsafe for IPP Clients, per
   Tom Petch.  
   Technical - Revised section 7 Security Considerations to add section 
   8.1 Problem Statement, section 8.2 Attacks, and section 8.3 TLS
   Security Considerations, per Tom Petch.  
   Editorial - Moved former section Appendix A - Acknowledgments to
   become section 8 Acknowledgements (in body of document) and updated
   to reflect recent comments on this document, per Tom Petch.  
   Technical - Revised section 9.1 Normative References to add TLS/1.0
   [RFC2246] and TLS/1.1 [RFC4346], per Tom Petch.  

McDonald, Sweet              Expires 10 May 2015               [Page 23]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   
   19 September 2013 - draft-mcdonald-ipps-uri-scheme-08.txt 
   Global - Updated references, per IPP WG review.  
   
   12 May 2013 - draft-mcdonald-ipps-uri-scheme-07.txt 
   Editorial - Revised section 1 (introduction) to add 'Rationale for
   this document', per Smith Kennedy.  
   Editorial - Global - Changed 'Conformance Requirements' to
   'Applicability', per Barry Leiba.  
   Editorial - Global - Changed '[PWG5100.EW]' to '[PWG5100.14]',
   corrected date and URI, and moved section 8.1 (normative references),
   per IPP WG review.  
   
   10 November 2012 - draft-mcdonald-ipps-uri-scheme-06.txt 
   Editorial - Global - Fixed typos and indentation, per IPP WG review.
   Editorial - Global - changed 'generic drivers' to 'vendor-neutral
   Client software', per IPP WG review.  
   Editorial - Revised section 8.2 (informative references, to correct
   title of "PWG IPP Everywhere" (i.e., delete version number), per IPP
   WG review.  
   
   14 May 2012 - draft-mcdonald-ipps-uri-scheme-05.txt 
   Editorial - Global - Fixed typos and indentation, per IPP WG review.
   Editorial - Revised sections 3.1 and 3.2 (transport bindings) to
   insert missing "to" in "connection to the target endpoint", per IPP
   WG review.  
   Editorial - Revised section 4.2 (syntax), to correct indentation of
   first "Note:", per IPP WG review.  
   Editorial - Revised sections 5.1 and 5.2 (client/printer conformance)
   and section 7 (security considerations) to delete the out-of-scope
   normative references to [RFC2817], per IPP WG review.  
   
   22 November 2011 - draft-mcdonald-ipps-uri-scheme-04.txt 
   Editorial - Global - Fixed typos and indentation, per IPP WG review.
   Editorial - Revised Introduction and Acknowledgments to say 'project
   for mobile, ubiquitous printing with generic drivers', per IPP WG
   review.  
   Editorial - Revised sections 3.1 and 3.2 (transport bindings) to add 
   references to HTTP POST and section 4 of RFC 2910, per IPP WG review.
   Editorial - Revised sections 3.1 and 3.2 (transport bindings) to add 
   section references to all well-known standards (connection setup,
   etc.), per IPP WG review.  
   Editorial - Revised section 4.2 (syntax) to move note from from
   section 4.6 (examples) and explain why literal IP addresses SHOULD
   NOT be used in 'ipps' URI, per IPP WG review.  
   Editorial - Revised sections 4.6.1 and 4.6.2 (examples) to replace
   'abc.com' w/ 'example.com' (per IETF) and replace '/printer' path
   element w/ '/ipp' (better practice), per IPP WG review.  
   Editorial - Revised section 5.2 (Printer conformance) to fold former
   (c) and (d) into a single requirement for standard port 631 and
   reordered other requirements to group MUSTs before SHOULDs, per IPP

McDonald, Sweet              Expires 10 May 2015               [Page 24]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   WG review.  
   Editorial - Revised section 5.2 (Printer conformance) to add backward
   reference to section 4.2 for rationale for not using IP literal
   addresses, per IPP WG review.  
   Editorial - Revised section 6 (IANA) to explicitly state that 'ipps' 
   uses secure communications using HTTP over TLS, per IPP WG review.  
   Editorial - Revised section 7 (Security) to cleanup numerous loose
   ends, per IPP WG review.  
   Editorial - Revised section 8 (References) to cleanup typos and
   links, per IPP WG review.  
   Editorial - Revised section 1 (introduction), section 8.2
   (informative references, and section 9 (appendix A) to change
   "[IPPEVE]" to "[PWG5100.EW]", per IPP WG review.  
   
   26 August 2011 - draft-mcdonald-ipps-uri-scheme-03.txt 
   Editorial - Revised Abstract and Introduction to state published by
   the IETF on behalf of IEEE-ISTO PWG (to avoid status ambiguity), per
   Mykyta Yevstifeyev.  
   Editorial - Revised section 1 to list all currently defined versions
   of IPP in RFC 2566, RFC 2911, and PWG 5100.12, per Mykyta
   Yevstifeyev.  
   Technical - Revised section 1, section 2, section 3.2, section 4.1,
   and section 7, to reference IPP Version 2.0 Second Edition (PWG
   5100.12), per Mykyta Yevstifeyev.  
   Editorial - Revised section 3.1, to fix broken STD7 reference, per
   Mykyta Yevstifeyev.  
   Editorial - Revised section 6, to add BCP35 reference for template
   (regression loss when the template was moved up from former
   appendix), per Mykyta Yevstifeyev.  
   Editorial - Revised section 8.1 to add PWG 5100.12 (normative), 
   Editorial - Revised section 8.2 to add PWG IPP Everywhere
   (informative) and RFC 1179 (informative), per Mykyta Yevstifeyev.  
   Editorial - Revised appendix B to add references for more reading,
   per Mykyta Yevstifeyev.  
   
   28 February 2011 - draft-mcdonald-ipps-uri-scheme-02.txt 
   Editorial - Revised document title to emphasize IPP over HTTPS
   Transport Binding (reason for IETF standards-track status).  
   Editorial - Replaced "IPP URI" with "'ipp' URI", "IPPS URI" with
   "'ipps' URI", "HTTP URI" with "'http' URI", and "HTTPS URI" with
   "'https' URI" throughout this document for conformance to section 3.1
   of [STD66], per Mykyta Yevstifeyev.  
   Editorial - Revised and simplified Abstract, per Mykyta Yevstifeyev.
   Editorial - Revised and simplified section 1 'Introduction', per
   Mykyta Yevstifeyev.  
   Editorial - Renamed section 2 from 'Conformance Terminology' to
   'Conventions Used in this Document', per Mykyta Yevstifeyev.  
   Editorial - Moved former section 3.1 'IPP Model Terminology
   (Normative)' content into section 2 'Conventions Used in this
   Document' for readability, per Mykyta Yevstifeyev.  

McDonald, Sweet              Expires 10 May 2015               [Page 25]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   Editorial - Reordered subsections and reversed word order in all
   subsection titles in section 4 'The 'ipps' URI Scheme' for
   readability, per Mykyta Yevstifeyev.  
   Editorial - Added note to section 4.2 'Syntax of 'ipps' URI Scheme'
   to explain why 'authority' production is NOT imported from [STD66],
   because it includes an optional 'userinfo' component which cannot be
   used in 'ipps' URI values.  
   Editorial - Deleted note describing empty 'host' component from
   section 4.2 'Syntax of 'ipps' URI Scheme', because 'host' component
   is mandatory in [STD66].  
   Editorial - Deleted 'Internationalization Considerations' section
   which was redundant with section 4.3 'Character Encoding of 'ipps'
   URI Scheme', per Mykyta Yevstifeyev.  
   Editorial - Revised all references to follow current RFC Editor
   style, per Mykyta Yevstifeyev.  
   Editorial - Moved former 'Appendix A - Registration of IPPS URI
   Scheme' content inline into section 6 'IANA Considerations', per
   Mykyta Yevstifeyev.  
   Editorial - Moved former body section 'Acknowledgements' to 'Appendix
   A - Acknowledgements', per Mykyta Yevstifeyev.  
   Editorial - Added new 'Appendix B - Abbreviations Used in this
   Document' for readability, per Mykyta Yevstifeyev.  
   Editorial - Moved section 'Authors' Addresses' to end of document,
   per Mykyta Yevstifeyev.  
   
   1 December 2010 - draft-mcdonald-ipps-uri-scheme-01.txt 
   - Technical - added UTF-8 [STD63] as required charset for all IPPS
   URI in section 4.4 and section 7, per Bjoern Hoehrmann.  
   - Technical - corrected percent encoding for data octets outside the 
   US-ASCII range in section 4.4 and section 7, per Bjoern Hoehrmann.  
   - Editorial - global - changed "[RFC4395]" to "[BCP35]", changed
   "[RFC3629]" to "[STD63]", changed "[RFC3986]" to "[STD66]", and
   changed "[RFC5234]" to "[STD68]", per Bjoern Hoehrmann.  
   - Editorial - restored trailing "]]" in ABNF syntax in section 4.5,
   per Bjoern Hoehrmann.  
   - Editorial - changed "Author/Change controller" to "IESG" in section
   12 Appendix A registration template, as required by section 5.3 of
   [BCP35], per Bjoern Hoehrmann.  
   
   10 October 2010 - draft-mcdonald-ipps-uri-scheme-00.txt 
   - Editorial - complete rewrite of RFC 3510 for new transport binding 
   - Editorial - moved Abstract to beginning of first page, per ID-Nits 
   - Editorial - fixed copyright, boilerplate, and typos, per ID-Nits 
   - Editorial - added references to RFCs 2119 and 3510, per ID-Nits 
   - Editorial - deleted obsolete references to RFCs 2246 and 4346, per 
   ID-Nits 
   - Technical - changed Intended Status to Standards Track to reflect
   the new normative IPPS URI scheme and transport binding 
   - Technical - added section 3.2 IPP over HTTP Transport Binding
   (informative) 

McDonald, Sweet              Expires 10 May 2015               [Page 26]
Internet Draft     IPP over HTTPS and 'ipps' URI Scheme      11 Nov 2014

   - Technical - added section 3.3 IPP over HTTPS Transport Binding
   (normative) 
   - Technical - updated section 5 Conformance Requirements to require
   HTTP Upgrade (RFC 2817) support (for interoperability with existing
   IPP implementations), per discussion on IPP WG mailing list 
   - Editorial - updated Appendix A w/ registration template from RFC
   4395 
   

11.  Authors' Addresses

   Ira McDonald
   High North Inc
   221 Ridge Ave
   Grand Marais, MI  49839
   
   Phone: +1 906-494-2434
   Email: blueroofmusic@gmail.com
   
   
   Michael Sweet
   Apple Inc
   10431 N De Anza Blvd, M/S 38-4LPT
   Cupertino, CA  95014
   
   Phone: +1 408-974-8798
   Email: msweet@apple.com
   
   
   Usage questions and comments on this 'ipps' URI Scheme can be sent
   directly to the editors at their above addresses and also to the PWG
   IPP WG mailing list.  Instructions for subscribing to the PWG IPP WG
   mailing list can be found at:  
   
   PWG IPP WG Web Page:      http://www.pwg.org/ipp/
   PWG IPP WG Mailing List:  ipp@pwg.org
   PWG IPP WG Subscription:  http://www.pwg.org/mailhelp.html
   
   Implementers of this specification are encouraged to join the PWG IPP
   WG Mailing List in order to participate in any discussions of
   clarification issues and comments.  Note that this IEEE-ISTO PWG
   mailing list rejects mail from non-subscribers (in order to reduce
   spam).  

McDonald, Sweet              Expires 10 May 2015               [Page 27]