[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 RFC 7472

Network Working Group                                       Ira McDonald
INTERNET-DRAFT                                            High North Inc
Updates: 2910, 2911 (if approved)                          Michael Sweet
Intended Status: Standards Track                               Apple Inc
Expires: 26 February 2012                                 26 August 2011


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


Abstract

   This memo 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 (for example, a print job)
   managed by such a service.

   This memo is published by the IETF on behalf of the Internet Printing
   Protocol Working Group of the IEEE-ISTO Printer Working Group.

   This memo 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 28 August 2011.


Copyright Notice

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


McDonald, Sweet             Expires 28 August 2011              [Page 1]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011


   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.


                           Table of Contents

1.  Introduction ...............................................       3
  1.1.  Structure of this document .............................       3
2.  Conventions Used in this Document ..........................       4
3.  IPP Transport Bindings .....................................       5
  3.1.  IPP Over HTTP Transport Binding (Informative) ..........       5
  3.2.  IPP over HTTPS Transport Binding (Normative) ...........       5
4.  Definition of 'ipps' URI Scheme ............................       6
  4.1.  Applicability of 'ipps' URI Scheme .....................       6
  4.2.  Syntax of 'ipps' URI Scheme ............................       7
  4.3.  Associated Port for 'ipps' URI Scheme ..................       8
  4.4.  Associated MIME Type for 'ipps' URI Scheme .............       8
  4.5.  Character Encoding of 'ipps' URI Scheme ................       8
  4.6.  Examples of 'ipps' URI .................................       8
    4.6.1.  Examples of 'ipps' URI for Printers ................       8
    4.6.2.  Examples of 'ipps' URI for Jobs ....................       9
  4.7.  Comparisons of 'ipps' URI ..............................      10
5.  Conformance Requirements ...................................      10
  5.1.  IPP Client Conformance Requirements ....................      10
  5.2.  IPP Printer Conformance Requirements ...................      11
6.  IANA Considerations ........................................      12
7.  Security Considerations ....................................      13
8.  References .................................................      14
  8.1.  Normative References ...................................      14
  8.2.  Informative References .................................      15
9.  Appendix A - Acknowledgments ...............................      16
10.  Appendix B - Abbreviations Used in this Document ..........      16
11.  Appendix X - Change History ...............................      17
12.  Authors' Addresses ........................................      19










McDonald, Sweet             Expires 28 August 2011              [Page 2]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011



1.  Introduction

   This memo 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 (for example, a print job)
   managed by such a service.  Therefore, this memo defines 'ipps' URI
   scheme applicability, associated port, associated MIME type,
   character encoding, and syntax.

   This memo 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'.

   This memo is published by IETF on behalf of the Internet Printing
   Protocol Working Group of the IEEE-ISTO Printer Working Group, as
   part of their IPP Everywhere [IPPEVE] project for mobile, driverless,
   ubiquitous printing.

   The following versions of IPP are currently defined:
   - 1.0 in [RFC2566] (obsolete)
   - 1.1 in [RFC2911]
   - 2.0 in [PWG5100.12]
   - 2.1 in [PWG5100.12]
   - 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 used throughout the document.

   Section 3 defines the IPP over HTTPS transport binding, after first
   summarizing the original IPP over HTTP transport binding.

   Section 4 defines the 'ipps' URI scheme.

   Section 5 defines the conformance requirements for IPP Clients and

McDonald, Sweet             Expires 28 August 2011              [Page 3]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011

   IPP Printers that claim conformance to this document.

   Sections 6 and 7 contain IANA and security considerations,
   respectively.

   Section 8 contains references.

   Appendix A contains acknowledgments and Appendix B explains
   abbreviations used in this document.



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].

   The reader of this document should be familiar with the terminology
   in IPP/1.1 Model and Semantics [RFC2911] (particularly, with the
   definition of 'IPP Objects', 'Printer Object' and 'Job Object'),
   abbreviations described in Appendix B and the following terms.

   In this document, "IPP Client" means the software (on some hardware
   platform) that submits, monitors, and/or manages secure print jobs
   via the IPP/1.1 Encoding and Transport [RFC2910] or IEEE-ISTO PWG IPP
   Version 2.0 Second Edition [PWG5100.12] to a secure print spooler,
   secure print gateway, or secure physical printing device.

   In this document, "IPP Printer object" means the software (on some
   hardware platform) that receives secure print jobs and/or secure
   printer/job operations via the IPP/1.1 Encoding and Transport
   [RFC2910] or IEEE-ISTO PWG IPP Version 2.0 Second Edition
   [PWG5100.12] from an "IPP Client".

   In this document, "IPP Printer" is a synonym for "IPP Printer
   object".

   In this document, "IPP Job object" means the set of attributes and
   documents for one secure print job instantiated on an "IPP Printer".

   In this document, "IPP Job" is a synonym for "IPP Job object".

   In this document, "'ipps' URI" means a URI using the 'ipps' URI
   scheme defined in section 4 of this specification.







McDonald, Sweet             Expires 28 August 2011              [Page 4]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011



3.  IPP Transport Bindings




   3.1.  IPP Over HTTP Transport Binding (Informative)

   This section is informative.

   When using an 'ipp' URI [RFC3510], an IPP Client establishes an IPP
   application layer connection according to the following sequence:

   1) The IPP Client selects an 'ipp' URI value from
      "printer-uri-supported" Printer attribute [RFC2911], a directory
      entry, discovery info, a web page, etc.;

   2) The IPP Client converts the 'ipp' URI to an 'http' URI (with
      inserted port 631);

   3) The IPP Client establishes a TCP [STD7] transport layer connection
      to the target endpoint;

   4) The IPP Client establishes an HTTP [RFC2616] session layer
      connection to the target endpoint;

   5) Optionally, the IPP Client upgrades to TLS within HTTP/1.1
      [RFC2817] to establish a TLS Protocol [RFC5246] secure transport
      sublayer within the original TCP/HTTP connection, based on the
      value of the "uri-security-supported" Printer attribute [RFC2911]
      parallel to the selected value of "printer-uri-supported"; and

   6) The IPP Client sends IPP application layer requests to and
      receives responses from the IPP Printer over the HTTP [RFC2616]
      session layer connection.

   See:  Section 8 'Security Considerations' in [RFC2817].



   3.2.  IPP over HTTPS Transport Binding (Normative)

   This section is normative.

   This document defines the following IPP over HTTPS alternate
   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

McDonald, Sweet             Expires 28 August 2011              [Page 5]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011

   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 (with
      inserted port 631);

   3) The IPP Client establishes a TLS Protocol [RFC5246] over TCP
      [STD7] secure transport layer connection to the target endpoint;

   4) The IPP Client establishes an HTTP [RFC2616] session layer
      connection to the target endpoint; and

   5) The IPP Client sends IPP application layer requests to and
      receives responses from the IPP Printer over the HTTP [RFC2616]
      session layer connection.

   See:  Section 'Security Considerations' in [RFC2818].



4.  Definition of 'ipps' URI Scheme



   4.1.  Applicability of 'ipps' URI Scheme

   The 'ipps' URI scheme MUST only be used to specify absolute URI
   (relative 'ipps' URI are not allowed) for IPP secure print services
   and their associated network resources.  The 'ipps' URI scheme MUST
   only be used 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] over an HTTPS [RFC2818] transport, as
   defined in this specification.  Any other transport binding for IPP
   would require a different URI scheme.

   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 3.2 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

McDonald, Sweet             Expires 28 August 2011              [Page 6]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011

   [RFC2910].

   See:  Section 4 'IPP Standards' and section 10 'Security
   Considerations' 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
   length of a URI.

   See:  Section 4.1.5 'uri' in [RFC2911].

      Note:  IPP Printers ought to be cautious about depending on URI
      lengths above 255 bytes, because some older IPP Client
      implementations might not properly support these lengths.

   'ipps' URI MUST be represented in absolute form.  Absolute URI MUST
   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",
   "path-absolute", and "query" from [STD66].

   The 'ipps' URI scheme syntax in ABNF [STD68] is defined as follows:

   ipps-uri =
       "ipps:" "//" host [ ":" port ] [ path-absolute [ "?" query ]]

   Note:  The higher-level production "authority" is not imported from
   [STD66], because it includes an optional "userinfo" component which
   cannot be used in 'ipps' URI.

   If the port is empty or not given, then port 631 MUST be used.  The
   semantics are that the identified resource (see section 5.1.2 of
   [RFC2616]) 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 'path-absolute'.

   If the 'path-absolute' is not present in the URI, it MUST be given as
   "/" when used as a Request-URI for a resource (see section 5.1.2 of
   [RFC2616]).

   An 'ipps' URI is transformed into an 'https' URI by replacing "ipps:"
   with "https:" and inserting port 631 (if the 'port' is not present in
   the original 'ipps' URI).

   See:  Section 3.2 of this document.

McDonald, Sweet             Expires 28 August 2011              [Page 7]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011




   4.3.  Associated Port for 'ipps' URI Scheme

   All 'ipps' URI which do NOT explicitly specify a port MUST be
   resolved to IANA-assigned well-known port 631, as registered in
   [PORTREG].

   See:  IANA Port Numbers Registry [PORTREG].

   See:  IPP/1.1 Encoding and Transport [RFC2910].



   4.4.  Associated MIME Type for 'ipps' URI Scheme

   All 'ipps' URI MUST be used to specify secure print services which
   support the "application/ipp" MIME media type as registered in
   [MIMEREG] for IPP protocol requests and responses.

   See:  IANA MIME Media Types Registry [MIMEREG].

   See:  IPP/1.1 Encoding and Transport [RFC2910].



   4.5.  Character Encoding of 'ipps' URI Scheme

   'ipps' URI MUST use the UTF-8 [STD63] charset for all components.
   'ipps' URI MUST use [STD66] rules for percent encoding data octets
   outside the US-ASCII coded character set [ASCII].



   4.6.  Examples of 'ipps' URI

   Note:  Literal IPv4 or IPv6 addresses SHOULD NOT be used in 'ipps'
   URI.



   4.6.1.  Examples of 'ipps' URI for Printers

   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://abc.com
       ipps://abc.com/printer
       ipps://abc.com/printer/tiger

McDonald, Sweet             Expires 28 August 2011              [Page 8]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011

       ipps://abc.com/printer/fox
       ipps://abc.com/printer/tiger/bob
       ipps://abc.com/printer/tiger/ira

   Each of the above URI are well-formed URI for IPP Printers 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://abc.com
       ipps://abc.com/smith/printer
       ipps://abc.com:631/smith/printer

   The first and second 'ipps' URI above MUST be resolved to port 631
   (IANA assigned well-known port for IPP).  The second and third 'ipps'
   URI above are equivalent (see section 4.7 below).



   4.6.2.  Examples of 'ipps' URI for Jobs

   The following are examples of well-formed 'ipps' URI for IPP Jobs
   (for example, to be used as protocol elements in 'job-uri' attributes
   of 'Print-Job' response messages):

       ipps://abc.com/printer/123
       ipps://abc.com/printer/tiger/job123

   'ipps' URI for Jobs are valid and meaningful only until Job
   completion and possibly an implementation defined optional period of
   persistence after Job completion (see IPP Model [RFC2911]).

   Ambiguously, section 4.3.1 'job-uri' of IPP Model [RFC2911] states
   that:

      "the precise format of a Job URI is implementation dependent."

   Thus, the relationship between the value of the "printer-uri"
   operation attribute used in a 'Print-Job' request and the value of
   the "job-uri" attribute returned in the corresponding 'Print-Job'
   response is implementation dependent.  Also, section 4.3.3
   'job-printer-uri' of IPP Model [RFC2911] states that the

McDonald, Sweet             Expires 28 August 2011              [Page 9]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011

   'job-printer-uri' attribute of a Job object:

      "permits a client to identify the Printer object that created this
      Job object when only the Job object's URI is available to the
      client."

   However, the above statement is erroneous, because the transform from
   an 'ipp' URI for a Job to the corresponding 'ipp' URI for the
   associated Printer is unspecified in either IPP/1.1 Model and
   Semantics [RFC2911] or IPP/1.1 Encoding and Transport [RFC2910].

   IPP Printers that conform to this specification SHOULD only generate
   'ipps' URI for Jobs (for example, in the "job-uri" attribute in a
   'Print-Job' response) by appending exactly one path component to the
   corresponding 'ipps' URI for the associated Printer (for
   interoperability).



   4.7.  Comparisons of 'ipps' URI

   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' URI
   comparisons in [RFC2616] as updated by the 'https' URI scheme
   [RFC2818], with the sole following 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:  Section 3.2.3 'URI Comparison' in [RFC2616].

   See:  Section 2.4 'URI Format' in [RFC2818].



5.  Conformance Requirements



   5.1.  IPP Client Conformance Requirements

   IPP Clients that conform to this specification:

   a) MUST support the IPP over HTTPS transport binding defined in
      section 3.2 and the 'ipps' URI scheme defined in section 4;

      b) MUST support the IPP over HTTP transport binding that includes
      HTTP Upgrade [RFC2817] defined in section 8.2 'Using IPP with TLS'
      of IPP/1.1 Encoding and Transport [RFC2910] (for interoperability
      with existing IPP implementations);


McDonald, Sweet             Expires 28 August 2011             [Page 10]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011


   c) MUST only send IPP protocol connections to IANA assigned
      well-known port 631 or to the explicit port specified in a given
      'ipps' URI;

   d) MUST only send 'ipps' URI used as protocol elements in outgoing
      IPP protocol request messages that conform to the ABNF specified
      in section 4.2 of this document (for example, in the "printer-uri"
      operation attribute in a 'Print-Job' request);

   e) MUST only convert 'ipps' URI to their corresponding 'https' URI
      forms [RFC2818] according to the rules in section 4.2 of this
      document.



   5.2.  IPP Printer Conformance Requirements

   IPP Printers that conform to this specification:

   a) MUST support the IPP over HTTPS transport binding defined in
      section 3.2 and the 'ipps' URI scheme defined in section 4;

      b) MUST support the IPP over HTTP transport binding that includes
      HTTP Upgrade [RFC2817] defined in section 8.2 'Using IPP with TLS'
      of IPP/1.1 Encoding and Transport [RFC2910] (for interoperability
      with existing IPP implementations);

   c) MUST only listen for incoming IPP protocol connections on
      IANA-assigned well-known port 631, unless explicitly configured by
      system administrators or site policies;

   d) MUST NOT listen for incoming IPP protocol connections on any other
      port than IANA-assigned well-known port 631, unless explicitly
      configured by system administrators or site policies;

   e) SHOULD only accept 'ipps' URI used as protocol elements in
      incoming IPP protocol request messages that conform to the ABNF
      specified in section 4.2 of this document (for example, in the
      "printer-uri" operation attribute in a 'Print-Job' request);

   f) MUST only generate 'ipps' URI used as protocol elements in
      outgoing IPP protocol response messages that conform to the ABNF
      specified in section 4.2 of this document (for example, in the
      "job-uri" attribute in a 'Print-Job' response);

   g) SHOULD only generate 'ipps' URI for Jobs by appending exactly one
      path component to the corresponding 'ipps' URI for the associated
      Printer (for example, in the "job-uri" attribute in a 'Print-Job'
      response);


McDonald, Sweet             Expires 28 August 2011             [Page 11]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011


   h) SHOULD NOT generate 'ipps' URI that use literal IPv6 or IPv4
      addresses.



6.  IANA Considerations

   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
     IPP Printer objects (spoolers, application gateways, print devices,
     etc.) on Internet hosts accessible using the IPP protocol.

     Encoding Considerations:  See section 4.3 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 IPP Printers.  Such applications may include (but
     are not limited to) IPP-capable web browsers, IPP Clients that wish
     to print a file, and servers (e.g., print spoolers) that wish to
     forward a print Job for processing.

     Interoperability Considerations:  A widely deployed IPP print
     service CUPS (on most UNIX, Linux, and MacOS client systems) has
     supported 'ipps' URI for several years.  Current work in progress
     in the IEEE-ISTO Printer Working Group on IPP mobile printing
     extensions envisions requiring the use of 'ipps' URI exclusively
     for data integrity and optional data confidentiality.

     Security Considerations:  See:  Section 8 of RFC xxxx.

     Contact:

     Ira McDonald <blueroofmusic@gmail.com>

     Michael Sweet <msweet@apple.com>

     Author/Change controller:

     IESG

     References:  RFC 2910, RFC 2911, and RFC xxxx.

McDonald, Sweet             Expires 28 August 2011             [Page 12]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011


   [RFC Editor:  Replace 'xxxx' with assigned RFC number before
   publication]



7.  Security Considerations

   This 'ipps' URI Scheme specification does not introduce any
   additional security considerations, beyond those described in
   [RFC2910], [RFC2911], [RFC2818], and [PWG5100.12], except the
   following:

   a) An 'ipps' URI might be faked to point to a rogue IPP secure print
      service, thus collecting confidential document contents from IPP
      Clients.

      Server authentication mechanisms and security mechanisms specified
      in IPP/1.1 Encoding and Transport [RFC2910], TLS/1.2 Protocol
      [RFC5246], and HTTP over TLS [RFC2818] are sufficient to address
      this threat.

   b) An 'ipps' URI might be used to access an IPP secure print service
      by an unauthorized IPP Client.

      Client authentication mechanisms and security mechanisms specified
      in IPP/1.1 Encoding and Transport [RFC2910], TLS/1.2 Protocol
      [RFC5246], and HTTP over TLS [RFC2818] are sufficient to address
      this threat.

   c) 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]) causing silent compromise of
      IPP security mechanisms.

      There is no practical defense against this threat by an IPP
      Client.  System administrators should avoid such compromising
      configurations.

   d) 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]).

      Service discovery or directory protocols should be used to
      discover the required IPP Client authentication mechanisms
      associated with given 'ipps' URI.

   See:  Section 8 'Security Considerations' in [RFC2910].

   See:  Section 8 'Security Considerations' in [RFC2911].

McDonald, Sweet             Expires 28 August 2011             [Page 13]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011


   See:  Section 10 'Security Considerations' in [PWG5100.12].

   See:  Section 8 'Security Considerations' in [RFC2817].

   See:  Section 'Security Considerations' in [RFC2818].

   See:  Section 15 'Security Considerations' in [RFC2616].

   See:  Section 7 'Security Considerations' in [STD66].



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.

   [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.
              <ftp://ftp.pwg.org/pub/pwg/candidates/cs-ipp20-20110214-51
              00.12.pdf>

   [RFC2119]  Bradner, S., Key words for use in RFCs to Indicate
              Requirement Levels, BCP 14, RFC 2119, March 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T.  Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [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.

   [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.



McDonald, Sweet             Expires 28 August 2011             [Page 14]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011

   [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] T.  Berners-Lee, R.  Fielding, 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.

   [MIMEREG]  Internet Assigned Numbers Authority (IANA) Registry "MIME
              Media Types"
              <http://www.iana.org/assignments/media-types/>

   [PORTREG]  Internet Assigned Numbers Authority (IANA) Registry "Port
              Numbers"
              <http://www.iana.org/assignments/port-numbers>

   [IPPEVE]  McDonald, I.  and M.  Sweet, "PWG IPP Everywhere First
              Edition", work-in-progress, August 2011.
              <ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeve10-20110803.pdf
              >

   [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.

McDonald, Sweet             Expires 28 August 2011             [Page 15]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011




9.  Appendix A - Acknowledgments


   This memo is published by IETF on behalf of the Internet Printing
   Protocol Working Group of the IEEE-ISTO Printer Working Group, as
   part of their IPP Everywhere [IPPEVE] project for mobile, driverless,
   ubiquitous printing.

   Thanks to Tom Hastings (retired from Xerox), Bjoern Hoerhmann, Jerry
   Thrasher (Lexmark), Mykyta Yevstifeyev, Pete Zehler (Xerox), and the
   members of the PWG IPP WG.

   The IPP URL Scheme [RFC3510] was the primary source for this
   document.



10.  Appendix B - Abbreviations Used in this Document

   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 [RFC2616]

   HTTPS  - HTTP over TLS [RFC2818]

   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/>

   ISTO   - IEEE Industry Standards and Technology Organization
            <http://www.ieee-isto.org/>

   LPD    - Line Printer Daemon Protocol [RFC1179]

   PWG    - IEEE-ISTO Printer Working Group

McDonald, Sweet             Expires 28 August 2011             [Page 16]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011

            <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]



11.  Appendix X - Change History

   [RFC Editor:  Delete this section before publication as an RFC]

   26 August 2011 - draft-mcdonald-ipps-uri-scheme-02.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.


McDonald, Sweet             Expires 28 August 2011             [Page 17]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011

   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.
   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


McDonald, Sweet             Expires 28 August 2011             [Page 18]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011

   - 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)
   - 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




12.  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 should be sent
   directly to the editors at their above addresses and also to the IPP
   WG mailing list.  Instructions for subscribing to the IPP WG mailing
   list can be found at:

   IPP WG Web Page:      http://www.pwg.org/ipp/
   IPP WG Mailing List:  ipp@pwg.org
   IPP WG Subscription:  http://www.pwg.org/mailhelp.html

   Implementers of this specification are encouraged to join the 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

McDonald, Sweet             Expires 28 August 2011             [Page 19]


Internet Draft    IPP over HTTPS and 'ipps' URI Scheme    26 August 2011

   spam).



















































McDonald, Sweet             Expires 28 August 2011             [Page 20]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/