[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: 1 June 2011                                     1 December 2010


                 IPPS URI Scheme and Transport Binding
                 draft-mcdonald-ipps-uri-scheme-01.txt


Abstract

   This memo defines the IPPS URI scheme and the corresponding IPP over
   HTTPS transport binding.  This memo updates the Internet Printing
   Protocol/1.1 Model and Semantics (RFC 2911), by extending section
   4.1.6 'uriScheme' and section 4.4.1 'printer-uri-supported'.  This
   memo updates the Internet Printing Protocol/1.1 Encoding and
   Transport (RFC 2910), by extending section 4 'Encoding of the
   Transport Layer', section 5 'IPP URL Scheme', and section 8.2 'Using
   IPP with TLS'.  This memo complements (but does not update) the
   Internet Printing Protocol/1.1 IPP URL Scheme (RFC 3510).

   This memo is a product of the Internet Printing Protocol Working
   Group in the IEEE-ISTO Printer Working Group, as part of their IPP
   Everywhere project for mobile, driverless, ubiquitous printing.

   An IPPS URI is used to specify the network location of a secure print
   service that supports the IPP/1.1 Model and Semantics (RFC 2911), or
   of a network resource (for example, a print job) managed by such a
   secure print service.


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


McDonald, Sweet               Expires 1 June 2011               [Page 1]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010


   This Internet-Draft will expire on April 11, 2011.


Copyright Notice

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

   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 1 June 2011               [Page 2]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010


                           Table of Contents

1.  Introduction ...............................................       4
2.  Conformance Terminology ....................................       5
3.  IPP Transport Bindings .....................................       6
  3.1.  IPP Model Terminology (Normative) ......................       6
  3.2.  IPP Over HTTP Transport Binding (Informative) ..........       6
  3.3.  IPP over HTTPS Transport Binding (Normative) ...........       7
4.  IPPS URI Scheme ............................................       9
  4.1.  IPPS URI Scheme Applicability ..........................       9
  4.2.  IPPS URI Scheme Associated Port ........................       9
  4.3.  IPPS URI Scheme Associated MIME Type ...................       9
  4.4.  IPPS URI Scheme Character Encoding .....................      10
  4.5.  IPPS URI Scheme Syntax .................................      10
  4.6.  IPPS URI Examples ......................................      11
    4.6.1.  IPPS Printer URI Examples ..........................      11
    4.6.2.  IPPS Job URI Examples ..............................      12
  4.7.  IPPS URI Comparisons ...................................      12
5.  Conformance Requirements ...................................      14
  5.1.  IPP Client Conformance Requirements ....................      14
  5.2.  IPP Printer Conformance Requirements ...................      14
6.  IANA Considerations ........................................      16
7.  Internationalization Considerations ........................      16
8.  Security Considerations ....................................      17
9.  References .................................................      19
  9.1.  Normative References ...................................      19
  9.2.  Informative References .................................      19
10.  Acknowledgments ...........................................      20
11.  Authors' Addresses ........................................      20
12.  Appendix A - Registration of IPPS URI Scheme ..............      21
13.  Appendix X - Change History ...............................      24




















McDonald, Sweet               Expires 1 June 2011               [Page 3]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010



1.  Introduction

   This memo conforms to all of the requirements and recommendations in
   Guidelines and Registration Procedures for New URI Schemes [BCP35].

   This memo defines the IPPS URI scheme and the corresponding IPP over
   HTTPS transport binding.  This memo updates the Internet Printing
   Protocol/1.1 Model and Semantics [RFC2911], by extending section
   4.1.6 'uriScheme' and section 4.4.1 'printer-uri-supported'.  This
   memo updates the Internet Printing Protocol/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'.  This memo complements (but does not update) the
   Internet Printing Protocol/1.1 IPP URL Scheme [RFC3510].

   This memo is a product of the Internet Printing Protocol Working
   Group in the IEEE-ISTO Printer Working Group, as part of their IPP
   Everywhere project for mobile, driverless, ubiquitous printing.

   An IPPS URI is used to specify the network location of a secure print
   service that supports the IPP/1.1 Model and Semantics [RFC2911], or
   of a network resource (for example, a print job) managed by such a
   secure print service.

   Overview information about the Internet Printing Protocol (IPP) is
   available in section 1 'Introduction' of IPP/1.1 Model and Semantics
   [RFC2911] and section 1 'Introduction' of IPP Implementor's Guide
   [RFC3196].

   The IPPS URI scheme defined in this document is based on the ABNF
   [STD68] for the HTTPS URI scheme [RFC2818], which in turn is updated
   by the URI Generic Syntax [STD66].  An IPPS URI is transformed into
   an HTTPS URI according to the rules specified in section 4.5 of this
   specification.

   This document defines IPPS URI scheme applicability, associated port
   (631), associated MIME type ("application/ipp"), character encoding
   (UTF-8), and syntax.

   This document contains the following sections:
   - Section 2 defines the conformance terminology used throughout the
     document.

   - Section 3 defines the IPP over HTTPS transport binding, after first
     summarizing the IPP object model terminology and the original IPP
     over HTTP transport binding.

   - Section 4 defines the IPPS URI scheme.


McDonald, Sweet               Expires 1 June 2011               [Page 4]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010


   - Section 5 defines the conformance requirements for IPP Clients and
     IPP Printers that claim conformance to this document.

   - Sections 6, 7, and 8 contain IANA, internationalization, and
     security considerations.

   - Sections 9, 10, and 11 contain references, acknowledgements, and
     authors' addresses.

   - Section 12 (Appendix A) contains a complete IANA registration for
     the IPPS URI Scheme, per [BCP35].



2.  Conformance Terminology

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
































McDonald, Sweet               Expires 1 June 2011               [Page 5]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010



3.  IPP Transport Bindings



   3.1.  IPP Model Terminology (Normative)

   See:  Section 12.2 'Model Terminology' in IPP/1.1 Model and Semantics
   [RFC2911].

   See:  Section 2 'IPP Objects', section 2.1 'Printer Object', and
   section 2.2 'Job Object' in IPP/1.1 Encoding and Transport [RFC2911]
   for a full description of the IPP object model and terminology.

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

   In this document, "IPPS URI" is a synonym for the "ipps-uri" ABNF
   [STD68] production defined in section 4.5 of this specification.



   3.2.  IPP Over HTTP Transport Binding (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.;



McDonald, Sweet               Expires 1 June 2011               [Page 6]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010

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

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

   4) The IPP Client establishes an HTTP 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 session
      layer connection.

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



   3.3.  IPP over HTTPS Transport Binding (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].

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

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

   4) The IPP Client establishes an HTTP 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 session
      layer connection.

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


McDonald, Sweet               Expires 1 June 2011               [Page 7]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010





















































McDonald, Sweet               Expires 1 June 2011               [Page 8]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010



4.  IPPS URI Scheme



   4.1.  IPPS URI Scheme Applicability

   The IPPS URI scheme MUST only be used to specify absolute URIs
   (relative IPPS URIs 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] over an HTTPS [RFC2818]
   transport, as defined in this specification.  Any other transport
   binding for the abstract protocol defined in IPP/1.1 Model and
   Semantics [RFC2911] 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.3 'IPP over HTTPS Transport Binding'.

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



   4.2.  IPPS URI Scheme Associated Port

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

   See:  IANA Port Numbers Registry [IANA-PORTREG].

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



   4.3.  IPPS URI Scheme Associated MIME Type

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

McDonald, Sweet               Expires 1 June 2011               [Page 9]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010


   See:  IANA MIME Media Types Registry [IANA-MIMEREG].

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



   4.4.  IPPS URI Scheme Character Encoding

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



   4.5.  IPPS URI Scheme Syntax

   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 URIs MUST be represented in absolute form.  Absolute URIs 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 ]]

   If the host is empty, then "localhost" MUST be used.

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


McDonald, Sweet              Expires 1 June 2011               [Page 10]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010


   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.3 'IPP over HTTPS Transport Binding'.



   4.6.  IPPS URI Examples

   Note:  Literal IPv4 or IPv6 addresses SHOULD NOT be used in IPPS
   URIs.



   4.6.1.  IPPS Printer URI Examples

   The following are examples of well-formed IPPS URIs for IPP Printers
   (for example, to be used as protocol elements in 'printer-uri'
   operation attributes of 'Print-Job' request messages):

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

   Each of the above URIs are well-formed URIs 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 URIs 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 URIs above MUST be resolved to port 631
   (IANA assigned well-known port for IPP).  The second and third IPPS
   URIs above are equivalent (see section 4.7 below).


McDonald, Sweet              Expires 1 June 2011               [Page 11]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010




   4.6.2.  IPPS Job URI Examples

   The following are examples of well-formed IPPS URIs 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 Job URIs 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
   '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 Job URI to the corresponding IPP Printer URI 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 Job URIs (for example, in the "job-uri" attribute in a
   'Print-Job' response) by appending exactly one path component to the
   corresponding IPPS Printer URI (for interoperability).



   4.7.  IPPS URI Comparisons

   When comparing two IPPS URIs 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:


McDonald, Sweet              Expires 1 June 2011               [Page 12]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010


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













































McDonald, Sweet              Expires 1 June 2011               [Page 13]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010



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.3 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 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 URIs used as protocol elements in outgoing IPP
      protocol request messages that conform to the ABNF specified in
      section 4.5 'IPPS URI Scheme Syntax' of this document (for
      example, in the "printer-uri" operation attribute in a 'Print-Job'
      request);

   e) MUST only convert IPPS URIs to their corresponding HTTPS URI forms
      [RFC2818] according to the rules in section 4.5 'IPPS URI Scheme
      Syntax' 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.3 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;



McDonald, Sweet              Expires 1 June 2011               [Page 14]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010

   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 URIs used as protocol elements in incoming
      IPP protocol request messages that conform to the ABNF specified
      in section 4.5 'IPPS URI Scheme Syntax' of this document (for
      example, in the "printer-uri" operation attribute in a 'Print-Job'
      request);

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

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

   h) SHOULD NOT generate IPPS URIs that use literal IPv6 or IPv4
      addresses.































McDonald, Sweet              Expires 1 June 2011               [Page 15]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010



6.  IANA Considerations

   This document requests the addition of the IPPS URI scheme to the
   IANA URI Schemes Registry and defines the registration information in
   section 12 Appendix A.

   This document does not require any change to the IANA IPP Registry,
   because it only defines a new URI scheme that may be used in the
   'uriScheme' type (whose values are not enumerated) that is defined in
   section 4.1.6 of IPP/1.1 Model and Semantics [RFC2911].

   There are no other IANA considerations associated with this document.

   See:  Section 12 'Appendix A - Registration of IPPS URI Scheme'.



7.  Internationalization Considerations

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

   See:  Section 7 'Internationalization Considerations' in [RFC2910].

   See:  Section 7 'Internationalization Considerations' in [RFC2911].
























McDonald, Sweet              Expires 1 June 2011               [Page 16]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010



8.  Security Considerations

   This IPPS URI Scheme specification does not introduce any additional
   security considerations, beyond those described in [RFC2910],
   [RFC2911], and [RFC2818], 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 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 URIs.

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

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

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

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


McDonald, Sweet              Expires 1 June 2011               [Page 17]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010


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

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
















































McDonald, Sweet              Expires 1 June 2011               [Page 18]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010



9.  References



9.1.  Normative References

   [ASCII] American National Standards Institute, Coded Character Set --
   7-bit American Standard Code for Information Interchange, ANSI X3.4,
   1986.

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

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

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

   [RFC2910] R.  Herriot, S.  Butler, P.  Moore, R.  Turner, J.  Wenn.
   IPP/1.1 Encoding and Transport, RFC 2910, September 2000.

   [RFC2911] T.  Hastings, R.  Herriot, R.  deBry, S.  Isaacson, P.
   Powell.  IPP/1.1 Model and Semantics, RFC 2911, September 2000.

   [RFC5246] T.  Dierks, E.  Rescorla.  The Transport Layer Security
   (TLS) Protocol Version 1.2, RFC 5246, August 2008.

   [STD63] F.  Yergeau.  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] D.  Crocker, P.  Overell.  Augmented BNF for Syntax
   Specifications ABNF, STD 68, RFC 5234, January 2008.



9.2.  Informative References

   See:  Section 10 'References' in [RFC2910] and Section 9 'References'
   [RFC2911].

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

   [IANA-MIMEREG] IANA MIME Media Types Registry.

McDonald, Sweet              Expires 1 June 2011               [Page 19]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010

   http://www.iana.org/assignments/media-types/

   [IANA-PORTREG] IANA Port Numbers Registry.
   http://www.iana.org/assignments/port-numbers

   [RFC2569] R.  Herriot, T.  Hastings, N.  Jacobs, J.  Martin.  Mapping
   between LPD and IPP Protocols, RFC 2569, April 1999.

   [RFC2817] R.  Khare, S.  Lawrence.  Upgrading to TLS Within HTTP/1.1,
   RFC 2817, May 2000.

   [RFC3196] T.  Hastings, C.  Manros, P.  Zehler, C.  Kugler, H.
   Holst.  Internet Printing Protocol/1.1 Implementor's Guide, RFC 3196,
   November 2001.

   [RFC3510] R.  Herriot, I.  McDonald.  Internet Printing Protocol/1.1:
   IPP URL Scheme, RFC 3510, April 2003.



10.  Acknowledgments

   This memo is a product of the Internet Printing Protocol Working
   Group in the IEEE-ISTO Printer Working Group, as part of their IPP
   Everywhere project for mobile, driverless, ubiquitous printing.

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

   The IPP URL Scheme [RFC3510] was the primary source for this IPPS URI
   Scheme specification.



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


McDonald, Sweet              Expires 1 June 2011               [Page 20]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010


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



12.  Appendix A - Registration of IPPS URI Scheme

   Note:  The following section defines the IANA registration for the
   IPPS URI scheme, per [BCP35].

   URI scheme name:  ipps

   Status:  permanent

   URI scheme syntax:

      See:  Section 4.5 'IPPS URI Scheme Syntax' of RFC xxxx.

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

   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.

      The associated MIME type is "application/ipp" defined in IPP/1.1
      Model and Semantics [RFC2911] and registered with IANA.

   Encoding Considerations:

      See:  Section 7 'Internationalization Considerations' of RFC xxxx.


McDonald, Sweet              Expires 1 June 2011               [Page 21]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010


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

   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.

      An IPPS URI is used to specify the network location of a secure
      print service that supports the IPP/1.1 Encoding and Transport
      [RFC2910], or of a network resource (for example, a print job)
      managed by such a secure print service.

      See:  Section 4.1 'IPPS URI Scheme Applicability' of RFC xxxx.

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

   Interoperability Considerations:

      A widely deployed IPP print service CUPS (on most UNIX, Linux, and
      MacOS client systems) has supported IPPS URIs 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
      URIs exclusively for data integrity and optional data
      confidentiality.

   Security Considerations:

      See:  Section 8 'Security Considerations' of RFC xxxx.

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

   Contact:

      Ira McDonald <blueroofmusic@gmail.com>

      Michael Sweet <msweet@apple.com>

   Author/Change controller:

      IESG

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

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

McDonald, Sweet              Expires 1 June 2011               [Page 22]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010

      publication]



















































McDonald, Sweet              Expires 1 June 2011               [Page 23]


Internet Draft    IPPS URI Scheme & Transport Binding    1 December 2010



13.  Appendix X - Change History

   [RFC Editor:  Section 13 (Appendix X Change History), should be
   deleted before publication as an RFC]

   1 December 2010 - draft-mcdonald-ipps-uri-scheme-01.txt
   - Technical - added UTF-8 [STD63] as required charset for all IPPS
     URIs 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)
     - 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










McDonald, Sweet              Expires 1 June 2011               [Page 24]


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