Network Working Group Ira McDonald INTERNET-DRAFT High North Inc Updates: 2910, 2911 (if approved) Michael Sweet Intended Status: Standards Track Apple Inc Expires: 7 October 2014 7 April 2014 IPP over HTTPS Transport Binding and 'ipps' URI Scheme draft-mcdonald-ipps-uri-scheme-11.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 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 (PWG 5100.14) project for secure mobile printing with vendor-neutral Client software. This memo defines an alternate IPP transport binding to that defined in the original IPP URL Scheme (RFC 3510), but this memo does not update or obsolete (RFC 3510). 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 7 October 2014. McDonald, Sweet Expires 7 October 2014 [Page 1] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 Copyright Notice Copyright (c) 2014 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. Table of Contents 1. Introduction ............................................... 4 1.1. Structure of this document ............................. 4 1.2. Rationale for this document ............................ 5 2. Conventions Used in this Document .......................... 5 2.1. Printing Terminology ................................... 5 2.2. Abbreviations .......................................... 6 3. IPP over HTTPS Transport Binding ........................... 7 4. Definition of 'ipps' URI Scheme ............................ 8 4.1. Applicability of 'ipps' URI Scheme ..................... 8 4.2. Syntax of 'ipps' URI Scheme ............................ 9 4.3. Associated Port for 'ipps' URI Scheme .................. 10 4.4. Associated MIME Type for 'ipps' URI Scheme ............. 11 4.5. Character Encoding of 'ipps' URI Scheme ................ 11 4.6. Examples of 'ipps' URI ................................. 11 4.6.1. Examples of 'ipps' URI for Printers ................ 11 4.6.2. Examples of 'ipps' URI for Jobs .................... 12 4.7. Comparisons of 'ipps' URI .............................. 13 5. Applicability of this Specification ........................ 13 5.1. Applicability to IPP Clients ........................... 13 5.2. Applicability to IPP Printers .......................... 14 6. IANA Considerations ........................................ 15 7. Security Considerations .................................... 16 7.1. Problem Statement ...................................... 16 7.1.1. Targets of Attacks ................................. 16 7.1.2. Layers of Attacks .................................. 17 7.2. Attacks and Defenses ................................... 17 7.2.1. Faked 'ipps' URI ................................... 17 7.2.2. Unauthorized Access by IPP Client .................. 18 7.2.3. Compromise at Application Layer Gateway ............ 18 7.2.4. No Client Authentication for 'ipps' URI ............ 18 7.3. TLS Cipher Suite Requirements .......................... 18 McDonald, Sweet Expires 7 October 2014 [Page 2] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 8. Acknowledgments ............................................ 19 9. References ................................................. 20 9.1. Normative References ................................... 20 9.2. Informative References ................................. 21 10. Appendix A - Summary of IPP URL Scheme (Informative) ...... 22 11. Appendix X - Change History ............................... 23 12. Authors' Addresses ........................................ 28 McDonald, Sweet Expires 7 October 2014 [Page 3] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 1. Introduction This document defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, that is used to designate the access to the network location of a secure IPP print service or a network resource (for example, a print job) managed by such a service. 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]. This document updates [RFC2910] and [RFC2911]. This document updates: a) IPP/1.1 Encoding and Transport [RFC2910], by extending section 4 'Encoding of the Transport Layer', section 5 'IPP URL Scheme', and section 8.2 'Using IPP with TLS'; b) IPP/1.1 Model and Semantics [RFC2911], by extending section 4.1.6 'uriScheme' and section 4.4.1 'printer-uri-supported'; and c) IEEE-ISTO PWG IPP Version 2.0 Second Edition [PWG5100.12], by extending section 4 'IPP Standards' and section 10 'Security Considerations'. The following versions of IPP are currently defined: - 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. McDonald, Sweet Expires 7 October 2014 [Page 4] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 Section 4 defines the 'ipps' URI scheme. Section 5 defines the applicability of this specification to IPP Clients and IPP Printers. Sections 6 and 7 contain IANA and security considerations, respectively. Section 8 containes acknowledgments. Section 9 contains references. Appendix A contains an informative summary of the original IPP URL Scheme [RFC3510] and associated IPP over HTTP transport binding. 1.2. Rationale for this document The 'ipps' URI scheme was defined for the following reasons: 1) Some existing IPP Client and IPP Printer implementations of Upgrading to TLS Within HTTP/1.1 [RFC 2817] are flawed and unreliable. 2) Some existing IPP Client and IPP Printer implementations of HTTP Upgrade [RFC 2717] do not perform upgrade at the beginning of every HTTP connection, but instead only shift to secure IPP for selected IPP operations (inherently dangerous behavior on the same underlying TCP connection). 3) IPP Printer server-mandated HTTP Upgrade [RFC 2817] can still lead to exposure of IPP Client data if the Expect request header is not used - basically the IPP Client can send its whole Print-Job request before the IPP Printer has a chance to respond and say, "Wait! You need to encrypt first!" 2. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.1. Printing Terminology The reader of this document needs to be familiar with the printing terms defined in IPP/1.1 Model and Semantics [RFC2911] as well as the McDonald, Sweet Expires 7 October 2014 [Page 5] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 following: IPP Client: The software (on some hardware platform) that submits IPP Job creation and IPP Printer and IPP Job management operations via the IPP over HTTP transport binding defined in the IPP/1.1 Encoding and Transport [RFC2910] and/or the IPP over HTTPS transport binding defined in section 3 of this specification to a downstream IPP Printer (print spooler, print gateway, or physical printing device). IPP Job: The set of attributes and documents for one print job instantiated in an IPP Printer. IPP Job object: Synonym for IPP Job. IPP Printer: The software (on some hardware platform) that receives IPP Job creation and IPP Printer and IPP Job management operations via the IPP over HTTP transport binding defined in the IPP/1.1 Encoding and Transport [RFC2910] and/or the IPP over HTTPS transport binding defined in section 3 of this specification from an upstream IPP Client or IPP Printer. IPP Printer object: Synonym for IPP Printer. 'ipps' URI: A URI using the 'ipps' URI scheme defined in section 4 of this specification. 2.2. Abbreviations This document makes use of the following abbreviations (given with their expanded forms and references for further reading): ABNF - Augmented Backus-Naur Form [STD68] ASCII - American Standard Code for Information Interchange [ASCII] HTTP - HyperText Transfer Protocol [RFC2616] HTTPS - HTTP over TLS [RFC2818] IANA - Internet Assigned Numbers Authority IEEE - Institute of Electrical and Electronics Engineers IESG - Internet Engineering Steering Group McDonald, Sweet Expires 7 October 2014 [Page 6] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 IPP - Internet Printing Protocol [RFC2911] and [PWG5100.12] ISTO - IEEE Industry Standards and Technology Organization LPD - Line Printer Daemon Protocol [RFC1179] PWG - IEEE-ISTO Printer Working Group RFC - Request for Comments 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] 3. IPP over HTTPS Transport Binding This section is a normative description of the protocol steps taken by an IPP Client using and an IPP Printer supporting the 'ipps' URI scheme. This document defines the following alternate IPP over HTTPS transport binding for the abstract protocol defined in IPP/1.1 Model and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version 2.0 Second Edition [PWG5100.12]. When using an 'ipps' URI, an IPP Client MUST establish an IPP application layer connection according to the following sequence: 1) The IPP Client selects an 'ipps' URI value from "printer-uri-supported" Printer attribute [RFC2911], a directory entry, discovery info, a web page, etc.; 2) The IPP Client converts the 'ipps' URI to an 'https' URI (replacing 'ipps' with 'https' and inserting the port number from the URI or port 631 if the URI doesn't include a port number); 3) The IPP Client establishes a TCP [STD7] reliable transport layer connection to the target endpoint - see section 3.4 'Establishing McDonald, Sweet Expires 7 October 2014 [Page 7] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 a connection' in TCP [STD7]; 4) The IPP Client establishes a TLS/1.0 [RFC2246], TLS/1.1 [RFC4346], TLS/1.2 [RFC5246], or later TLS version secure transport layer connection to the target endpoint - see section 7 'The TLS Handshake Protocol' in [RFC2246], [RFC4346], and [RFC5246]; 5) The IPP Client establishes an HTTPS [RFC2818] secure session layer connection over the TLS secure transport layer to the target endpoint; and 6) The IPP Client sends IPP application layer requests to and receives responses from the IPP Printer over the HTTPS [RFC2818] secure 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 'Security Considerations' in [RFC2818]. See: Section 10 'Security Considerations' in [PWG5100.12]. 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 4.2 (syntax) of this document. See: Section 4.4.1 'printer-uri-supported' in IPP/1.1 Model and Semantics [RFC2911]. McDonald, Sweet Expires 7 October 2014 [Page 8] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 See: Section 5 'IPP URL Scheme' in IPP/1.1 Encoding and Transport [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 SHOULD be cautious about depending on URI lengths above 255 octets, 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 ]] If the port is empty or not given, then port 631 MUST be used. See: Section 4.3 (port) of this document. 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'. Note: The higher-level "authority" production is not imported from [STD66], because it includes an optional "userinfo" component which cannot be used in 'ipps' URI. Note: The "query" production does not have defined semantics in IPP and was never used in examples in IPP/1.1 Encoding and Transport [RFC2910] or the original IPP URL Scheme [RFC3510]. The "query" is retained here for consistency, but IPP Clients SHOULD avoid its use McDonald, Sweet Expires 7 October 2014 [Page 9] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 (because the semantics could only be implementation-defined). Note: Literal IPv4 or IPv6 addresses SHOULD NOT be used in 'ipps' URI, because: a) IP addresses are often changed after network device installation (for example, based on DHCP reassignment after a power cycle); b) IP addresses often don't map simply to security domains; c) IP addresses are difficult to validate with X.509 server certificates (because they do not map to common name or alternate name attributes); and d) IPv6 link local addresses are not "portable" due to link identity 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 4.3 (port) of this document. 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, already registered in [PORTREG] for IPP/1.1 Encoding and Transport [RFC2910]. Note: Port 631 is overloaded here for both 'ipp' [RFC3510] and 'ipps' URI, both of which refer to an IPP print service or a network resource managed by such a service (for example, a print job), for consistency with recent IETF best practices. IPP Printer implementors can refer to the CUPS source at "https://www.cups.org/" for an example of incoming connection handling for the dual-use of port 631. Note: For compatibility with existing IPP Client and IPP Printer implementations, explicit port 443 (assigned in the 'https' URI scheme [RFC2818]) MUST be accepted in 'ipps' URI and processed normally by IPP Clients and IPP Printers. See: IANA Port Numbers Registry [PORTREG]. See: IPP/1.1 Encoding and Transport [RFC2910]. McDonald, Sweet Expires 7 October 2014 [Page 10] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 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 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://example.com ipps://example.com/ipp ipps://example.com/ipp/tiger ipps://example.com/ipp/fox ipps://example.com/ipp/tiger/bob ipps://example.com/ipp/tiger/ira Each of the above URI 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 McDonald, Sweet Expires 7 October 2014 [Page 11] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 with (optional) ports and paths: ipps://example.com ipps://example.com/ipp ipps://example.com:631/ipp ipps://example.com:443/ipp The first and second 'ipps' URI above 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). The third 'ipps' URI above uses the explicit port 443 (see section 4.3 above). See: Section 4.2 (syntax) and section 4.3 (port) of this document. 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://example.com/ipp/123 ipps://example.com/ipp/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 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]. Note: IPP Printers that implement this specification SHOULD only McDonald, Sweet Expires 7 October 2014 [Page 12] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 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. 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 4.3 (port) in this document. See: Section 3.2.3 'URI Comparison' in [RFC2616]. See: Section 2.4 'URI Format' in [RFC2818]. 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 use 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; McDonald, Sweet Expires 7 October 2014 [Page 13] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 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. See: Section 4.2 (syntax) and section 4.3 (port) 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); c) MUST support the IPP over HTTPS transport binding defined in section 3 of this specification; d) MUST use the required TLS version(s) according to the corresponding IPP versions as defined in section 7 of this specification; e) 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); f) 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); 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); h) SHOULD NOT generate 'ipps' URI that use literal IPv6 or IPv4 addresses (see section 4.2 for rationale). McDonald, Sweet Expires 7 October 2014 [Page 14] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 See: Section 4.2 (syntax) and section 4.3 (port) of this document. 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]. 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 (for example, print spoolers) wishing to forward a print Job for processing. Interoperability Considerations: The widely deployed IPP print service CUPS (on most UNIX, Linux, and Mac OS X systems) has supported 'ipps' URI for several years before the publication of this document. CUPS source code is freely available at "https://www.cups.org/". 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 McDonald, Sweet Expires 7 October 2014 [Page 15] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 Michael Sweet 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 confidentiality) in this dynamic environment (for example, wireless hotspots in hotels, airports, and restaurants). See: Section 1 Introduction of [PWG5100.14]. See: Section 3.1 Rationale of [PWG5100.14]. 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, for example, by creating congestion); b) the Internet Printing Protocol (IPP) [RFC2911] (for example, to compromise the normal behavior of IPP); or c) the print document content itself (for example, to corrupt the documents being transferred). McDonald, Sweet Expires 7 October 2014 [Page 16] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 7.1.2. Layers of Attacks Attacks against print services can be launched: a) against the network infrastructure (for example, TCP congestion control). b) against the IPP data flow itself (for example, by sending forged packets or forcing TLS version downgrade); or c) against the IPP operation parameters (for example, by corrupting requested document processing attributes). 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]. 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. McDonald, Sweet Expires 7 October 2014 [Page 17] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 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. 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 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: McDonald, Sweet Expires 7 October 2014 [Page 18] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 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 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. McDonald, Sweet Expires 7 October 2014 [Page 19] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 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. [PWG5100.14] McDonald, I. and M. Sweet, "PWG IPP Everywhere", PWG 5100.14, January 2013. [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. McDonald, Sweet Expires 7 October 2014 [Page 20] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 [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. 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" [PORTREG] Internet Assigned Numbers Authority (IANA) Registry "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. McDonald, Sweet Expires 7 October 2014 [Page 21] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 [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 the port number from the URI or port 631 if the URI doesn't include a port number); 3) The IPP Client establishes a TCP [STD7] 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]. McDonald, Sweet Expires 7 October 2014 [Page 22] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 11. Appendix X - Change History [RFC Editor: Delete this section before publication as an RFC] 7 April 2014 - draft-mcdonald-ipps-uri-scheme-11.txt Global - revised all references to section 4.2 and section 4.3, to add parenthetic (syntax) and (port) respectively, per IEEE-ISTO PWG IPP WG review. Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, to correct two typos (extra words) in section 4.3 references, per IEEE-ISTO PWG IPP WG review. Editorial - Revised section 4.3 Associated Port for 'ipps' URI Scheme, to add note about compatibility for IPP Clients and IPP Printers that MUST accept explicit port 443 (assigned in 'https' URI scheme [RFC2818]) and process normally, per IEEE-ISTO PWG IPP WG review. Editorial - Revised section 4.6.1 Examples of 'ipps' URI for Printers, to add example of explicit port 443, per IEEE-ISTO PWG IPP WG review. 30 March 2014 - draft-mcdonald-ipps-uri-scheme-10.txt Global - Updated references, per IEEE-ISTO PWG IPP WG review. Global - Changed "e.g." to "for example", for readability. Editorial - Revised section Copyright Notice, to correct year. Editorial - Revised section 3 IPP over HTTPS Transport Binding, item 2), to clarify that port 631 is ONLY inserted in the derived 'https' URI when an explicit port is NOT specified in the original 'ipps' URI, per Smith Kennedy and IEEE-ISTO PWG IPP WG review. Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, note about URI lengths greater than 255 octets, to change 'ought to' to 'SHOULD', per Smith Kennedy and IEEE-ISTO PWG IPP WG review. Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, to add reference to section 4.3 for use of port 631, per Smith Kennedy and IEEE-ISTO PWG IPP WG review. Editorial - Revised section 4.3 Associated Port for 'ipps' URI Scheme, to add note about dual-use of port 631 for 'ipp' URI and 'ipps' URI with reference to CUPS source for example of incoming connection handling, per Smith Kennedy and IEEE-ISTO PWG IPP WG review. Editorial - Revised section 4.3 Associated Port for 'ipps' URI Scheme, to add note about compatibility for IPP Clients and IPP Printers that should accept explicit port 443 (assigned in 'https' URI scheme [RFC2818]) and process normally, per IEEE-ISTO PWG IPP WG review. Editorial - Revised section 4.6.1 Examples of 'ipps' URI for Printers, to add reference to section 4.2 (syntax) and section 4.3 (port), per Smith Kennedy and IEEE-ISTO PWG IPP WG review. McDonald, Sweet Expires 7 October 2014 [Page 23] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 Editorial - Revised section 4.7 Comparisons of 'ipps' URI, to add reference to section 4.3 (port), per Smith Kennedy and IEEE-ISTO PWG IPP WG review. Editorial - Revised section 5.1 Applicability to IPP Clients, to add reference to section 4.2 (syntax) and section 4.3 (port), per Smith Kennedy and IEEE-ISTO PWG IPP WG review. Editorial - Revised section 5.1 Applicability to IPP Clients, item d), to change 'MUST the' to 'MUST use the', per Smith Kennedy and IEEE-ISTO PWG IPP WG review. Editorial - Revised section 5.2 Applicability to IPP Printers, to add reference to section 4.2 (syntax) and section 4.3 (port), per Smith Kennedy and IEEE-ISTO PWG IPP WG review. Editorial - Revised section 5.2 Applicability to IPP Printers, item d), to change 'MUST the' to 'MUST use the', per Smith Kennedy and IEEE-ISTO PWG IPP WG review. Editorial - Revised section 5.2 Applicability to IPP Printers, to delete former item e) (listen only on port 631) which conflicted with existing IPP implementations (for example, listening on port 443 as well), per Smith Kennedy and IEEE-ISTO PWG IPP WG review. Editorial - Revised section 6 IANA Considerations, to add URI for CUPS source, per IEEE-ISTO PWG IPP WG review. Editorial - Revised section 7.2.4 No Client Authentication for 'ipps' URI, to change "or or" to "or" (typo), per Smith Kennedy and IEEE-ISTO PWG IPP WG review. Editorial - Revised Appendix A Summary of IPP URL Scheme, item 2), to clarify that port 631 is ONLY inserted in the derived 'http' URI when an explicit port is NOT specified in the original 'ipp' URI, per Smith Kennedy and IEEE-ISTO PWG IPP WG review. 5 November 2013 - draft-mcdonald-ipps-uri-scheme-09.txt Global - Updated references, per IPP WG review. Editorial - Revised Abstract, section 1 Introduction, and section 8 Acknowledgments to clarify that this document is an individual submission to the IETF by the IPP WG of the IEEE-ISTO PWG, per S Mooneswamy. Editorial - Revised Abstract, section 1 Introduction, and section 8 Acknowledgments to clarify that this document does not update or obsolete [RFC3510], per S Mooneswamy and Tom Petch. Editorial - Revised section 1.1 Structure of this Document to align with changes below, per Tom Petch. Editorial - Revised section 2 Conventions Used in this Document to add section 2.1 Printing Terminology and to remove redundant "In this document" and clarify definitions, per Tom Petch. Editorial - Moved former Appendix B - Abbreviations Used in this Document to become section 2.2 Abbreviations, per Tom Petch. Technical - Revised section 3 IPP over HTTPS Transport Binding, section 5 Applicability of this Specification, and section 7 Security Considerations to address specific TLS/1.0 [RFC2246], TLS/1.1 [RFC4346], and TLS/1.2 [RFC5246] requirements, per Tom Petch. Editorial - Moved former section 3.1 IPP over HTTP Transport Binding to become Appendix A - Summary of IPP URL Scheme (Informative), per McDonald, Sweet Expires 7 October 2014 [Page 24] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 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. 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 McDonald, Sweet Expires 7 October 2014 [Page 25] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 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 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 McDonald, Sweet Expires 7 October 2014 [Page 26] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 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. - 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 McDonald, Sweet Expires 7 October 2014 [Page 27] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 [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 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 McDonald, Sweet Expires 7 October 2014 [Page 28] Internet Draft IPP over HTTPS and 'ipps' URI Scheme 7 April 2014 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 7 October 2014 [Page 29]