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

#x27; URI Scheme      5 Nov 2013

   
   '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 entirely 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
   a URI for an IPP Job to the corresponding URI for the associated IPP 
   Printer is unspecified in either IPP/1.1 Model and Semantics
   [RFC2911] or IPP/1.1 Encoding and Transport [RFC2910].  
   
   IPP Printers that implement 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].  

McDonald, Sweet             Expires 19 March 2014              [Page 12]
Internet Draft      IPP over HTTPS and 'ipps' URI Scheme      5 Nov 2013

5.  Applicability of this Specification

5.1.  Applicability to IPP Clients

   IPP Clients that implement this specification:  
   
   a) MUST support the IPP over HTTPS transport binding defined in
      section 3 and the 'ipps' URI scheme defined in section 4; 
      
   b) MUST support the IPP over HTTP transport binding with TLS 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 support the IPP over HTTPS transport binding defined in
      section 3 of this specification; 
      
   d) MUST the required TLS version(s) according to the corresponding
      IPP versions as defined in section 7 of this specification; 
      
   e) MUST only send IPP protocol connections to IANA assigned
      well-known port 631 or to the explicit port specified in a given
      'ipps' URI; 
      
   f) 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); 
      
   g) 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.  Applicability to IPP Printers

   IPP Printers that implement this specification:  
   
   a) MUST support the IPP over HTTPS transport binding defined in
      section 3 and the 'ipps' URI scheme defined in section 4; 
      
   b) MUST support the IPP over HTTP transport binding with TLS 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 19 March 2014              [Page 13]
Internet Draft      IPP over HTTPS and 'ipps' URI Scheme      5 Nov 2013

      
   c) MUST support the IPP over HTTPS transport binding defined in
      section 3 of this specification; 
      
   d) MUST the required TLS version(s) according to the corresponding
      IPP versions as defined in section 7 of this specification; 
      
   e) MUST only listen for incoming IPP protocol connections on
      IANA-assigned well-known port 631 and MUST NOT listen for incoming
      IPP protocol connections on any other port, unless explicitly
      configured by system administrators or site policies; 
      
   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 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); 
      
   h) 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); 
      
   i) SHOULD NOT generate 'ipps' URI that use literal IPv6 or IPv4
      addresses (see section 4.2 for rationale).  

6.  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 over TLS [RFC2818].  

McDonald, Sweet             Expires 19 March 2014              [Page 14]
Internet Draft      IPP over HTTPS and 'ipps' URI Scheme      5 Nov 2013

   
   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 secure IPP Printers using the IPP protocol enhanced to
   support guaranteed data integrity and negotiable data privacy using
   TLS as specified in HTTP over TLS [RFC2818].  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:  The widely deployed IPP print
   service CUPS (on most UNIX, Linux, and Mac OS X client systems) has
   supported 'ipps' URI for several years.  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 7 of RFC xxxx.  
   
   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.

7.  Security Considerations

7.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 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 (mandatory data integrity and negotiable data

McDonald, Sweet             Expires 19 March 2014              [Page 15]
Internet Draft      IPP over HTTPS and 'ipps' URI Scheme      5 Nov 2013

   confidentiality) in this dynamic environment (e.g., wireless hotspots
   in hotels, airports, and restaurants).  
   
   See:  Section 1 Introduction of [PWG5100.14].  
   
   See:  Section 3.1 Rationale of [PWG5100.14].  

7.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, e.g., by
      creating congestion); 
      
   b) the Internet Printing Protocol (IPP) [RFC2911] (e.g., to
      compromise the normal behavior of IPP); or 
      
   c) the print document content itself (e.g., to corrupt the documents 
      being transferred).  

7.1.2.  Layers of Attacks

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

7.2.  Attacks and Defenses

   This 'ipps' URI Scheme specification adds the following additional
   security considerations to those described in [RFC2616], [RFC2818],
   [RFC2910], [RFC2911], [RFC5246], [PWG5100.12], and [STD66].  
   
   See:  Section 15 'Security Considerations' in [RFC2616].  
   
   See:  Section 'Security Considerations' in [RFC2818].  
   
   See:  Section 8 'Security Considerations' in [RFC2910].  

McDonald, Sweet             Expires 19 March 2014              [Page 16]
Internet Draft      IPP over HTTPS and 'ipps' URI Scheme      5 Nov 2013

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

7.2.1.  Faked 'ipps' URI

   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.0 [RFC2246], TLS/1.1 
   [RFC4346], TLS/1.2 [RFC5246], and HTTP over TLS [RFC2818] can be used
   to address this threat.  

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

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

McDonald, Sweet             Expires 19 March 2014              [Page 17]
Internet Draft      IPP over HTTPS and 'ipps' URI Scheme      5 Nov 2013

7.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 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 query to discover the required IPP
   Client authentication mechanism(s) associated with a given 'ipps'
   URI.  

7.3.  TLS Cipher Suite Requirements

   In accordance with section 10 Security Considerations of
   [PWG5100.12], IPP Clients and IPP Printers that support this
   specification and support a given version of TLS MUST support at
   least the mandatory cipher suite(s) required in each supported TLS
   version, which are as follows:  
   
       TLS/1.0 [RFC2246] - TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
       TLS/1.1 [RFC4346] - TLS_RSA_WITH_3DES_EDE_CBC_SHA
       TLS/1.2 [RFC5246] - TLS_RSA_WITH_AES_128_CBC_SHA
   
   Note:  IPP Client and IPP Printer implementors SHOULD consider known 
   attacks against the mandatory cipher suite(s) in each supported TLS
   version and SHOULD follow best practice advice for alternative cipher
   suites in later IETF specifications.  
   
   In accordance with section 10 Security Considerations of
   [PWG5100.12], this IPP over HTTPS transport binding and 'ipps' URI
   Scheme specification adds the following TLS version support
   requirements:  
   
   a) An IPP Client or IPP Printer that supports this specification and 
      supports IPP/1.1 defined in [RFC2911], MUST support TLS/1.0
      [RFC2246], MAY support TLS/1.1 [RFC4346], MAY support TLS/1.2
      [RFC5246], and MAY support future versions of TLS, in every case
      with at least the mandatory cipher suite(s) required in each
      supported TLS version.  
      
   b) An IPP Client or IPP Printer that supports this specification and 
      supports IPP/2.0 defined in [PWG5100.12], MUST support TLS/1.0
      [RFC2246], SHOULD support TLS/1.1 [RFC4346], MAY support TLS/1.2
      [RFC5246], and MAY support future versions of TLS, in every case

McDonald, Sweet             Expires 19 March 2014              [Page 18]
Internet Draft      IPP over HTTPS and 'ipps' URI Scheme      5 Nov 2013

      with at least the mandatory cipher suite(s) required in each
      supported TLS version.  
      
   c) An IPP Client or IPP Printer that supports this specification and 
      supports IPP/2.1 defined in [PWG5100.12], MUST support TLS/1.0
      [RFC2246], MUST support TLS/1.1 [RFC4346], SHOULD support TLS/1.2
      [RFC5246], and MAY support future versions of TLS, in every case
      with at least the mandatory cipher suite(s) required in each
      supported TLS version.  
      
   d) An IPP Client or IPP Printer that supports this specification and 
      supports IPP/2.2 defined in [PWG5100.12], MUST support TLS/1.0
      [RFC2246], MUST support TLS/1.1 [RFC4346], MUST support TLS/1.2
      [RFC5246], and MAY support future versions of TLS, in every case
      with at least the mandatory cipher suite(s) required in each
      supported TLS version.  

8.  Acknowledgments

   This document is an individual submission 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, S. Mooneswamy, Tom Petch, Jerry Thrasher (Lexmark), Mykyta
   Yevstifeyev, Pete Zehler (Xerox), and the members of the IEEE-ISTO
   PWG IPP WG.  

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

McDonald, Sweet             Expires 19 March 2014              [Page 19]
Internet Draft      IPP over HTTPS and 'ipps' URI Scheme      5 Nov 2013

              <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.  
              
   [RFC2246]  Dierks, T., and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.  
              
   [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.  
              
   [RFC4346]  Dierks, T., and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.  
              
   [RFC5246]  Dierks, T., and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.  
              
   [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.  

McDonald, Sweet             Expires 19 March 2014              [Page 20]
Internet Draft      IPP over HTTPS and 'ipps' URI Scheme      5 Nov 2013

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

10.  Appendix A - Summary of IPP URL Scheme (Informative)

   This section is an informative summary of the original IPP URL Scheme
   [RFC3510] and the associated IPP over HTTP transport binding defined
   in [RFC2910].  
   
   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 (replacing 
      'ipp' with 'http' and inserting port 631); 

McDonald, Sweet             Expires 19 March 2014              [Page 21]
Internet Draft      IPP over HTTPS and 'ipps' URI Scheme      5 Nov 2013

      
   3) The IPP Client establishes a TCP [STD7] reliable transport layer
      connection to the target endpoint - see section 3.4 'Establishing
      a connection' in TCP [STD7]; 
      
   4) The IPP Client establishes an HTTP [RFC2616] session layer
      connection to the target endpoint - see section 8 'Connections' in
      HTTP/1.1 [RFC2616]; 
      
   5) Optionally, either the IPP Client upgrades to TLS within HTTP/1.1
      per section 3 'Client Requested Upgrade to HTTP over TLS' of
      [RFC2817] or the IPP Printer upgrades to TLS within HTTP/1.1 per
      section 4 'Server Requested Upgrade to HTTP over TLS' of
      [RFC2817], in order to establish a TLS secure transport sublayer
      within the original TCP/HTTP connection - per the
      "uri-security-supported" (section 4.4.3 in [RFC2911]) Printer
      attribute value parallel to the "printer-uri-supported" (see
      section 4.4.1 in [RFC2911]) value that matches this connection;
      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 using the POST method defined in section
      9.5 of HTTP/1.1 [RFC2616], as specified in section 4 'Encoding of
      Transport Layer' in IPP/1.1 Encoding and Transport [RFC2910].  
   
   See:  Section 8 'Security Considerations' in [RFC2911].  
   
   See:  Section 8 'Security Considerations' in [RFC2817].  

11.  Appendix X - Change History

   [RFC Editor:  Delete this section before publication as an RFC] 
   
   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.  

McDonald, Sweet             Expires 19 March 2014              [Page 22]
Internet Draft      IPP over HTTPS and 'ipps' URI Scheme      5 Nov 2013

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

McDonald, Sweet             Expires 19 March 2014              [Page 23]
Internet Draft      IPP over HTTPS and 'ipps' URI Scheme      5 Nov 2013

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

McDonald, Sweet             Expires 19 March 2014              [Page 24]
Internet Draft      IPP over HTTPS and 'ipps' URI Scheme      5 Nov 2013

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

McDonald, Sweet             Expires 19 March 2014              [Page 25]
Internet Draft      IPP over HTTPS and 'ipps' URI Scheme      5 Nov 2013

   - 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 
   

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

McDonald, Sweet             Expires 19 March 2014              [Page 26]
Internet Draft      IPP over HTTPS and 'ipps' URI Scheme      5 Nov 2013

   
   
   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 19 March 2014              [Page 27]