idnits 2.17.1 draft-mcdonald-ipps-uri-scheme-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2910, updated by this document, for RFC5378 checks: 1999-02-22) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (28 September 2014) is 3498 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2566' is mentioned on line 133, but not defined ** Obsolete undefined reference: RFC 2566 (Obsoleted by RFC 2911) == Missing Reference: 'RFC 2817' is mentioned on line 179, but not defined == Missing Reference: 'RFC 2717' is mentioned on line 174, but not defined ** Obsolete undefined reference: RFC 2717 (Obsoleted by RFC 4395) == Missing Reference: 'RFC2616' is mentioned on line 988, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Missing Reference: 'RFC7235' is mentioned on line 990, but not defined ** Obsolete undefined reference: RFC 7235 (Obsoleted by RFC 9110) == Missing Reference: 'RFC2246' is mentioned on line 1116, but not defined ** Obsolete undefined reference: RFC 2246 (Obsoleted by RFC 4346) == Missing Reference: 'RFC4346' is mentioned on line 1116, but not defined ** Obsolete undefined reference: RFC 4346 (Obsoleted by RFC 5246) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' ** Obsolete normative reference: RFC 7233 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2910 (Obsoleted by RFC 8010) ** Obsolete normative reference: RFC 2911 (Obsoleted by RFC 8011) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7235 (ref. 'RFC7234') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 793 (ref. 'STD7') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4395 (ref. 'BCP35') (Obsoleted by RFC 7595) Summary: 16 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ira McDonald 3 INTERNET-DRAFT High North Inc 4 Updates: 2910, 2911 (if approved) Michael Sweet 5 Intended Status: Standards Track Apple Inc 6 Expires: 28 March 2015 28 September 2014 8 IPP over HTTPS Transport Binding and 'ipps' URI Scheme 9 draft-mcdonald-ipps-uri-scheme-14.txt 11 Abstract 13 This memo defines the Internet Printing Protocol (IPP) over HTTPS 14 transport binding and the corresponding 'ipps' URI scheme, that is 15 used to designate the access to the network location of a secure IPP 16 print service or a network resource (for example, a print job) 17 managed by such a service. 19 This memo is an independent submission to the RFC Editor Stream, with 20 IETF AD sponsoring, by the Internet Printing Protocol Working Group 21 of the IEEE-ISTO Printer Working Group, as part of their PWG IPP 22 Everywhere (PWG 5100.14) project for secure mobile printing with 23 vendor-neutral Client software. 25 This memo defines an alternate IPP transport binding to that defined 26 in the original IPP URL Scheme (RFC 3510), but this memo does not 27 update or obsolete (RFC 3510). 29 This memo updates RFC 2910 and RFC 2911. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 28 March 2015. 48 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction ............................................... 4 65 1.1. Structure of this document ............................. 4 66 1.2. Rationale for this document ............................ 5 67 2. Conventions Used in this Document .......................... 5 68 2.1. Printing Terminology ................................... 5 69 2.2. Abbreviations .......................................... 6 70 3. IPP over HTTPS Transport Binding ........................... 7 71 4. Definition of 'ipps' URI Scheme ............................ 8 72 4.1. Applicability of 'ipps' URI Scheme ..................... 8 73 4.2. Syntax of 'ipps' URI Scheme ............................ 9 74 4.3. Associated Port for 'ipps' URI Scheme .................. 10 75 4.4. Associated MIME Type for 'ipps' URI Scheme ............. 10 76 4.5. Character Encoding of 'ipps' URI Scheme ................ 11 77 4.6. Examples of 'ipps' URI ................................. 11 78 4.6.1. Examples of 'ipps' URI for Printers ................ 11 79 4.6.2. Examples of 'ipps' URI for Jobs .................... 12 80 4.7. Comparisons of 'ipps' URI .............................. 13 81 5. Applicability of this Specification ........................ 13 82 5.1. Applicability to IPP Clients ........................... 13 83 5.2. Applicability to IPP Printers .......................... 14 84 6. IANA Considerations ........................................ 15 85 7. Security Considerations .................................... 16 86 7.1. Problem Statement ...................................... 16 87 7.1.1. Targets of Attacks ................................. 16 88 7.1.2. Layers of Attacks .................................. 16 89 7.2. Attacks and Defenses ................................... 17 90 7.2.1. Faked 'ipps' URI ................................... 17 91 7.2.2. Unauthorized Access by IPP Client .................. 17 92 7.2.3. Compromise at Application Layer Gateway ............ 18 93 7.2.4. No Client Authentication for 'ipps' URI ............ 18 94 7.3. TLS Version Requirements ............................... 18 95 8. Acknowledgments ............................................ 18 96 9. References ................................................. 19 97 9.1. Normative References ................................... 19 98 9.2. Informative References ................................. 20 99 10. Appendix A - Summary of IPP URL Scheme (Informative) ...... 21 100 11. Appendix X - Change History ............................... 22 101 12. Authors' Addresses ........................................ 28 102 1. Introduction 104 This document defines the Internet Printing Protocol (IPP) over HTTPS 105 transport binding and the corresponding 'ipps' URI scheme, that is 106 used to designate the access to the network location of a secure IPP 107 print service or a network resource (for example, a print job) 108 managed by such a service. 110 This memo is an independent submission to the RFC Editor Stream, with 111 IETF AD sponsoring, by the Internet Printing Protocol Working Group 112 of the IEEE-ISTO Printer Working Group, as part of their PWG IPP 113 Everywhere (PWG 5100.14) project for secure mobile printing with 114 vendor-neutral Client software. 116 This document defines an alternate IPP transport binding to that 117 defined in the original IPP URL Scheme [RFC3510], but this document 118 does not update or obsolete [RFC3510]. 120 This document updates [RFC2910] and [RFC2911]. 122 This document updates: 123 a) IPP/1.1 Encoding and Transport [RFC2910], by extending section 4 124 'Encoding of the Transport Layer', section 5 'IPP URL Scheme', and 125 section 8.2 'Using IPP with TLS'; 126 b) IPP/1.1 Model and Semantics [RFC2911], by extending section 4.1.6 127 'uriScheme' and section 4.4.1 'printer-uri-supported'; and 128 c) IEEE-ISTO PWG IPP Version 2.0 Second Edition [PWG5100.12], by 129 extending section 4 'IPP Standards' and section 10 'Security 130 Considerations'. 132 The following versions of IPP are currently defined: 133 - 1.0 in [RFC2566] (obsolete) 134 - 1.1 in [RFC2911] 135 - 2.0 in [PWG5100.12] 136 - 2.1 in [PWG5100.12] 137 - 2.2 in [PWG5100.12] 139 Overview information about IPP is available in section 1 of RFC 2911 140 [RFC2911], section 1 of RFC 3196 [RFC3196], and section 1 of PWG IPP 141 Version 2.0 Second Edition [PWG5100.12]. 143 1.1. Structure of this document 145 This document contains the following sections: Section 2 defines the 146 conventions used throughout the document. 148 Section 3 defines the IPP over HTTPS transport binding. 150 Section 4 defines the 'ipps' URI scheme. 152 Section 5 defines the applicability of this specification to IPP 153 Clients and IPP Printers. 155 Sections 6 and 7 contain IANA and security considerations, 156 respectively. 158 Section 8 containes acknowledgments. 160 Section 9 contains references. 162 Appendix A contains an informative summary of the original IPP URL 163 Scheme [RFC3510] and associated IPP over HTTP transport binding. 165 1.2. Rationale for this document 167 The 'ipps' URI scheme was defined for the following reasons: 169 1) Some existing IPP Client and IPP Printer implementations of 170 Upgrading to TLS Within HTTP/1.1 [RFC 2817] are flawed and 171 unreliable. 173 2) Some existing IPP Client and IPP Printer implementations of HTTP 174 Upgrade [RFC 2717] do not perform upgrade at the beginning of 175 every HTTP connection, but instead only shift to secure IPP for 176 selected IPP operations (inherently dangerous behavior on the same 177 underlying TCP connection). 179 3) IPP Printer server-mandated HTTP Upgrade [RFC 2817] can still lead 180 to exposure of IPP Client data if the Expect request header is not 181 used - basically the IPP Client can send its whole Print-Job 182 request before the IPP Printer has a chance to respond and say, 183 "Wait! You need to encrypt first!" 185 2. Conventions Used in this Document 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in RFC 2119 [RFC2119]. 191 2.1. Printing Terminology 193 The reader of this document needs to be familiar with the printing 194 terms defined in IPP/1.1 Model and Semantics [RFC2911] as well as the 195 following: 197 IPP Client: The software (on some hardware platform) that submits 198 IPP Job creation and IPP Printer and IPP Job management operations 199 via the IPP over HTTP transport binding defined in the IPP/1.1 200 Encoding and Transport [RFC2910] and/or the IPP over HTTPS transport 201 binding defined in section 3 of this specification to a downstream 202 IPP Printer (print spooler, print gateway, or physical printing 203 device). 205 IPP Job: The set of attributes and documents for one print job 206 instantiated in an IPP Printer. 208 IPP Job object: Synonym for IPP Job. 210 IPP Printer: The software (on some hardware platform) that receives 211 IPP Job creation and IPP Printer and IPP Job management operations 212 via the IPP over HTTP transport binding defined in the IPP/1.1 213 Encoding and Transport [RFC2910] and/or the IPP over HTTPS transport 214 binding defined in section 3 of this specification from an upstream 215 IPP Client or IPP Printer. 217 IPP Printer object: Synonym for IPP Printer. 219 'ipps' URI: A URI using the 'ipps' URI scheme defined in section 4 220 of this specification. 222 2.2. Abbreviations 224 This document makes use of the following abbreviations (given with 225 their expanded forms and references for further reading): 227 ABNF - Augmented Backus-Naur Form [STD68] 229 ASCII - American Standard Code for Information Interchange [ASCII] 231 HTTP - HyperText Transfer Protocol [HTTP1.1] 233 HTTPS - HTTP over TLS [RFC2818] 235 IANA - Internet Assigned Numbers Authority 236 238 IEEE - Institute of Electrical and Electronics Engineers 239 241 IESG - Internet Engineering Steering Group 242 244 IPP - Internet Printing Protocol [RFC2911] and [PWG5100.12] 245 247 ISTO - IEEE Industry Standards and Technology Organization 248 250 LPD - Line Printer Daemon Protocol [RFC1179] 252 PWG - IEEE-ISTO Printer Working Group 253 255 RFC - Request for Comments 256 258 TCP - Transmission Control Protocol [STD7] 260 TLS - Transport Layer Security [RFC5246] 262 URI - Uniform Resource Identifier [STD66] 264 URL - Uniform Resource Locator [STD66] 266 UTF-8 - Unicode Transformation Format - 8-bit [STD63] 268 3. IPP over HTTPS Transport Binding 270 This section is a normative description of the protocol steps taken 271 by an IPP Client using and an IPP Printer supporting the 'ipps' URI 272 scheme. 274 This document defines the following alternate IPP over HTTPS 275 transport binding for the abstract protocol defined in IPP/1.1 Model 276 and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version 2.0 Second 277 Edition [PWG5100.12]. 279 When using an 'ipps' URI, an IPP Client MUST establish an IPP 280 application layer connection according to the following sequence: 282 1) The IPP Client selects an 'ipps' URI value from 283 "printer-uri-supported" Printer attribute [RFC2911], a directory 284 entry, discovery info, a web page, etc.; 286 2) The IPP Client converts the 'ipps' URI to an 'https' URI 287 (replacing 'ipps' with 'https' and inserting the port number from 288 the URI or port 631 if the URI doesn't include a port number); 290 3) The IPP Client establishes a TCP [STD7] reliable transport layer 291 connection to the target endpoint - see section 3.4 'Establishing 292 a connection' in TCP [STD7]; 294 4) The IPP Client establishes a TLS/1.2 [RFC5246], or later TLS 295 version, secure transport layer connection to the target endpoint 296 - see section 7 'The TLS Handshake Protocol' in [RFC5246]; 298 5) The IPP Client establishes an HTTPS [RFC2818] secure session layer 299 connection over the TLS secure transport layer to the target 300 endpoint; and 302 6) The IPP Client sends IPP application layer requests to and 303 receives responses from the IPP Printer over the HTTPS [RFC2818] 304 secure session layer connection using the POST method defined in 305 [RFC7231], as specified in section 4 'Encoding of Transport Layer' 306 in IPP/1.1 Encoding and Transport [RFC2910]. 308 See: Section 'Security Considerations' in [RFC2818]. 310 See: Section 10 'Security Considerations' in [PWG5100.12]. 312 4. Definition of 'ipps' URI Scheme 314 4.1. Applicability of 'ipps' URI Scheme 316 The 'ipps' URI scheme MUST only be used to specify absolute URI 317 (relative 'ipps' URI are not allowed) for IPP secure print services 318 and their associated network resources. The 'ipps' URI scheme MUST 319 only be used to specify the use of the abstract protocol defined in 320 IPP/1.1 Model and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version 321 2.0 Second Edition [PWG5100.12] over an HTTPS [RFC2818] transport, as 322 defined in this specification. Any other transport binding for IPP 323 would require a different URI scheme. 325 The 'ipps' URI scheme allows an IPP Client to choose an appropriate 326 IPP secure print service (for example, from a directory). The IPP 327 Client can establish an HTTPS connection to the specified IPP secure 328 print service. The IPP Client can send IPP protocol requests (for 329 example, 'Print-Job' requests) and receive IPP protocol responses 330 over that HTTPS connection. 332 See: Section 4.2 (syntax) of this document. 334 See: Section 4.4.1 'printer-uri-supported' in IPP/1.1 Model and 335 Semantics [RFC2911]. 337 See: Section 5 'IPP URL Scheme' in IPP/1.1 Encoding and Transport 338 [RFC2910]. 340 See: Section 4 'IPP Standards' and section 10 'Security 341 Considerations' of IEEE-ISTO PWG IPP Version 2.0 Second Edition 342 [PWG5100.12]. 344 4.2. Syntax of 'ipps' URI Scheme 346 The abstract protocol defined in IPP/1.1 Model and Semantics 347 [RFC2911] places a limit of 1023 octets (NOT characters) on the 348 length of a URI. 350 See: Section 4.1.5 'uri' in [RFC2911]. 352 Note: IPP Printers SHOULD be cautious about depending on URI lengths 353 above 255 octets, because some older IPP Client implementations might 354 not properly support these lengths. 356 'ipps' URI MUST be represented in absolute form. Absolute URI MUST 357 always begin with a scheme name followed by a colon. For definitive 358 information on URI syntax and semantics, see "Uniform Resource 359 Identifiers (URI) Generic Syntax and Semantics" [STD66]. This 360 specification adopts the definitions of "host", "port", and "query" 361 from [STD66]. This specification adopts the definition of 362 "absolute-path" from [RFC7230]. 364 The 'ipps' URI scheme syntax in ABNF [STD68] is defined as follows: 366 ipps-uri = 367 "ipps:" "//" host [ ":" port ] [ absolute-path [ "?" query ]] 369 If the port is empty or not given, then port 631 MUST be used. 371 See: Section 4.3 (port) of this document. 373 The semantics are that the identified resource (see [RFC7230]) is 374 located at the IPP secure print service listening for HTTPS 375 connections on that port of that host, and the Request-URI for the 376 identified resource is 'absolute-path'. 378 Note: The higher-level "authority" production is not imported from 379 [STD66], because it includes an optional "userinfo" component which 380 cannot be used in 'ipps' URI. 382 Note: The "query" production does not have defined semantics in IPP 383 and was never used in examples in IPP/1.1 Encoding and Transport 384 [RFC2910] or the original IPP URL Scheme [RFC3510]. The "query" is 385 retained here for consistency, but IPP Clients SHOULD avoid its use 386 (because the semantics could only be implementation-defined). 388 Note: Literal IPv4 or IPv6 addresses SHOULD NOT be used in 'ipps' 389 URI, because: 390 a) IP addresses are often changed after network device installation 391 (for example, based on DHCP reassignment after a power cycle); 392 b) IP addresses often don't map simply to security domains; 393 c) IP addresses are difficult to validate with X.509 server 394 certificates (because they do not map to common name or alternate 395 name attributes); and 396 d) IPv6 link local addresses are not "portable" due to link identity 398 If the 'absolute-path' is not present in the URI, it MUST be given as 399 "/" when used as a Request-URI for a resource (see [RFC7230]). 401 An 'ipps' URI is transformed into an 'https' URI by replacing "ipps:" 402 with "https:" and inserting port 631 (if the 'port' is not present in 403 the original 'ipps' URI). 405 See: Section 4.3 (port) of this document. 407 4.3. Associated Port for 'ipps' URI Scheme 409 All 'ipps' URI which do NOT explicitly specify a port MUST be 410 resolved to IANA-assigned well-known port 631, already registered in 411 [PORTREG] for IPP/1.1 Encoding and Transport [RFC2910]. 413 Note: Port 631 is used for both 'ipp' [RFC3510] and 'ipps' URI, both 414 of which refer to an IPP print service or a network resource managed 415 by such a service (for example, a print job), for consistency with 416 recent IETF best practices. IPP Printer implementors can refer to 417 the CUPS [CUPS] source code for an example of incoming connection 418 handling for the dual use of port 631. 420 Note: For compatibility with existing IPP Client and IPP Printer 421 implementations, explicit port 443 (assigned in the 'https' URI 422 scheme [RFC2818]) MUST be accepted in 'ipps' URI and processed 423 normally by IPP Clients and IPP Printers. 425 See: IANA Port Numbers Registry [PORTREG]. 427 See: IPP/1.1 Encoding and Transport [RFC2910]. 429 4.4. Associated MIME Type for 'ipps' URI Scheme 431 All 'ipps' URI MUST be used to specify secure print services which 432 support the "application/ipp" MIME media type as registered in 433 [MIMEREG] for IPP protocol requests and responses. 435 See: IANA MIME Media Types Registry [MIMEREG]. 437 See: IPP/1.1 Encoding and Transport [RFC2910]. 439 4.5. Character Encoding of 'ipps' URI Scheme 441 'ipps' URI MUST use the UTF-8 [STD63] charset for all components. 442 'ipps' URI MUST use [STD66] rules for percent encoding data octets 443 outside the US-ASCII coded character set [ASCII]. 445 4.6. Examples of 'ipps' URI 447 4.6.1. Examples of 'ipps' URI for Printers 449 The following are examples of well-formed 'ipps' URI for IPP Printers 450 (for example, to be used as protocol elements in 'printer-uri' 451 operation attributes of 'Print-Job' request messages): 453 ipps://example.com 454 ipps://example.com/ipp 455 ipps://example.com/ipp/tiger 456 ipps://example.com/ipp/fox 457 ipps://example.com/ipp/tiger/bob 458 ipps://example.com/ipp/tiger/ira 460 Each of the above URI are well-formed URI for IPP Printers and each 461 would reference a logically different IPP Printer, even though some 462 of those IPP Printers might share the same host system. The 'bob' or 463 'ira' last path components might represent two different physical 464 printer devices, while 'tiger' might represent some grouping of IPP 465 Printers (for example, a load-balancing spooler). Or the 'bob' and 466 'ira' last path components might represent separate human recipients 467 on the same physical printer device (for example, a physical printer 468 supporting two job queues). In either case, both 'bob' and 'ira' 469 would behave as different and independent IPP Printers. 471 The following are examples of well-formed 'ipps' URI for IPP Printers 472 with (optional) ports and paths: 474 ipps://example.com 475 ipps://example.com/ipp 476 ipps://example.com:631/ipp 477 ipps://example.com:443/ipp 479 The first and second 'ipps' URI above MUST be resolved to port 631 480 (IANA assigned well-known port for IPP). The second and third 'ipps' 481 URI above are equivalent (see section 4.7 below). The fourth 'ipps' 482 URI above uses the explicit port 443 (see section 4.3 above). 484 See: Section 4.2 (syntax) and section 4.3 (port) of this document. 486 4.6.2. Examples of 'ipps' URI for Jobs 488 The following are examples of well-formed 'ipps' URI for IPP Jobs 489 (for example, to be used as protocol elements in 'job-uri' attributes 490 of 'Print-Job' response messages): 492 ipps://example.com/ipp/123 493 ipps://example.com/ipp/tiger/job123 495 'ipps' URI for Jobs are valid and meaningful only until Job 496 completion and possibly an implementation defined optional period of 497 persistence after Job completion (see IPP Model [RFC2911]). 499 Ambiguously, section 4.3.1 'job-uri' of IPP Model [RFC2911] states 500 that: 502 "the precise format of a Job URI is implementation dependent." 504 Thus, the relationship between the value of the "printer-uri" 505 operation attribute used in a 'Print-Job' request and the value of 506 the "job-uri" attribute returned in the corresponding 'Print-Job' 507 response is entirely implementation dependent. Also, section 4.3.3 508 'job-printer-uri' of IPP Model [RFC2911] states that the 509 'job-printer-uri' attribute of a Job object: 511 "permits a client to identify the Printer object that created this 512 Job object when only the Job object's URI is available to the 513 client." 515 However, the above statement is erroneous, because the transform from 516 a URI for an IPP Job to the corresponding URI for the associated IPP 517 Printer is unspecified in either IPP/1.1 Model and Semantics 518 [RFC2911] or IPP/1.1 Encoding and Transport [RFC2910]. 520 Note: IPP Printers that implement this specification SHOULD only 521 generate 'ipps' URI for Jobs (for example, in the "job-uri" attribute 522 in a 'Print-Job' response) by appending exactly one path component to 523 the corresponding 'ipps' URI for the associated Printer. 525 4.7. Comparisons of 'ipps' URI 527 When comparing two 'ipps' URI to decide if they match or not, an IPP 528 Client MUST use the same rules as those defined for 'http' and 529 'https' URI comparisons in [RFC7230], with the sole following 530 exception: 532 - A port that is empty or not given MUST be treated as equivalent to 533 the well-known port for that 'ipps' URI (port 631). 535 See: Section 4.3 (port) in this document. 537 See: Section 2.7.3 'http and https URI Normalization and Comparison' 538 in [RFC7230]. 540 See: Section 2.4 'URI Format' in [RFC2818]. 542 5. Applicability of this Specification 544 5.1. Applicability to IPP Clients 546 IPP Clients that implement this specification: 548 a) MUST support the IPP over HTTPS transport binding defined in 549 section 3 and the 'ipps' URI scheme defined in section 4; 551 b) MUST support the IPP over HTTP transport binding with TLS defined 552 in section 8.2 'Using IPP with TLS' of IPP/1.1 Encoding and 553 Transport [RFC2910] (for interoperability with existing IPP 554 implementations); 556 c) MUST support the IPP over HTTPS transport binding defined in 557 section 3 of this specification; 559 d) MUST use the required TLS version(s) according to the 560 corresponding IPP versions as defined in section 7 of this 561 specification; 563 e) MUST only send IPP protocol connections to IANA assigned 564 well-known port 631 or to the explicit port specified in a given 565 'ipps' URI; 567 f) MUST only send 'ipps' URI used as protocol elements in outgoing 568 IPP protocol request messages that conform to the ABNF specified 569 in section 4.2 of this document (for example, in the "printer-uri" 570 operation attribute in a 'Print-Job' request); 572 g) MUST only convert 'ipps' URI to their corresponding 'https' URI 573 forms [RFC2818] according to the rules in section 4.2 of this 574 document. 576 See: Section 4.2 (syntax) and section 4.3 (port) of this document. 578 5.2. Applicability to IPP Printers 580 IPP Printers that implement this specification: 582 a) MUST support the IPP over HTTPS transport binding defined in 583 section 3 and the 'ipps' URI scheme defined in section 4; 585 b) MUST support the IPP over HTTP transport binding with TLS defined 586 in section 8.2 'Using IPP with TLS' of IPP/1.1 Encoding and 587 Transport [RFC2910] (for interoperability with existing IPP 588 implementations); 590 c) MUST support the IPP over HTTPS transport binding defined in 591 section 3 of this specification; 593 d) MUST use the required TLS version(s) according to the 594 corresponding IPP versions as defined in section 7 of this 595 specification; 597 e) MUST only generate 'ipps' URI used as protocol elements in 598 outgoing IPP protocol response messages that conform to the ABNF 599 specified in section 4.2 of this document (for example, in the 600 "job-uri" attribute in a 'Print-Job' response); 602 f) SHOULD only accept 'ipps' URI used as protocol elements in 603 incoming IPP protocol request messages that conform to the ABNF 604 specified in section 4.2 of this document (for example, in the 605 "printer-uri" operation attribute in a 'Print-Job' request); 607 g) SHOULD only generate 'ipps' URI for Jobs by appending exactly one 608 path component to the corresponding 'ipps' URI for the associated 609 Printer (for example, in the "job-uri" attribute in a 'Print-Job' 610 response); 612 h) SHOULD NOT generate 'ipps' URI that use literal IPv6 or IPv4 613 addresses (see section 4.2 for rationale). 615 See: Section 4.2 (syntax) and section 4.3 (port) of this document. 617 6. IANA Considerations 619 [RFC Editor: Replace 'xxxx' with assigned RFC number before 620 publication] 622 IANA is asked to register the 'ipps' URI scheme using the following 623 template, which conforms to [BCP35]. 625 URI scheme name: ipps 627 Status: Permanent 629 URI scheme syntax: See section 4.2 of RFC xxxx. 631 URI scheme semantics: The 'ipps' URI scheme is used to designate 632 secure IPP Printer objects (print spoolers, print gateways, print 633 devices, etc.) on Internet hosts accessible using the IPP protocol 634 enhanced to support guaranteed data integrity and negotiable data 635 privacy using TLS as specified in HTTP over TLS [RFC2818]. 637 Encoding Considerations: See section 4.3 of RFC xxxx. 639 Applications/protocols that use this URI scheme name: 641 The 'ipps' URI scheme is intended to be used by applications that 642 need to access secure IPP Printers using the IPP protocol enhanced to 643 support guaranteed data integrity and negotiable data privacy using 644 TLS as specified in HTTP over TLS [RFC2818]. Such applications may 645 include (but are not limited to) IPP-capable web browsers, IPP 646 Clients that wish to print a file, and servers (for example, print 647 spoolers) wishing to forward a print Job for processing. 649 Interoperability Considerations: The widely deployed, open source 650 IPP print service CUPS [CUPS] (on most UNIX, Linux, and Apple OS X 651 systems) has supported 'ipps' URI for several years before the 652 publication of this document. PWG IPP Everywhere [PWG5100.14] (IPP 653 secure, mobile printing extensions) requires the use of 'ipps' URI 654 for mandatory data integrity and negotiable data confidentiality. 656 Security Considerations: See: Section 7 of RFC xxxx. 658 Contact: 660 Ira McDonald 662 Michael Sweet 664 Author/Change controller: 666 IESG 668 References: RFC 2910, RFC 2911, RFC xxxx, and IEEE-ISTO PWG 5100.12. 670 7. Security Considerations 672 7.1. Problem Statement 674 Powerful mobile devices (laptops, tablets, smartphones, etc.) are now 675 commonly used to access enterprise and Cloud print services across 676 the public Internet. This is the primary use case for PWG IPP 677 Everywhere [PWG5100.14], which has already been adopted by operating 678 system and printer vendors and several other public standards bodies. 679 End user and enterprise documents are at greater risk than ever 680 before. This IPP over HTTPS transport binding and 'ipps' URI scheme 681 specification was defined to enable high availability combined with 682 secure operation (mandatory data integrity and negotiable data 683 confidentiality) in this dynamic environment (for example, wireless 684 hotspots in hotels, airports, and restaurants). 686 See: Section 1 Introduction of [PWG5100.14]. 688 See: Section 3.1 Rationale of [PWG5100.14]. 690 7.1.1. Targets of Attacks 692 A network print spooler (logical printer) or print device (physical 693 printer) is potentially subject to attacks, which may target: 695 a) The network (to compromise the routing infrastructure, for 696 example, by creating congestion); 698 b) the Internet Printing Protocol (IPP) [RFC2911] (for example, to 699 compromise the normal behavior of IPP); or 701 c) the print document content itself (for example, to corrupt the 702 documents being transferred). 704 7.1.2. Layers of Attacks 706 Attacks against print services can be launched: 708 a) against the network infrastructure (for example, TCP congestion 709 control). 711 b) against the IPP data flow itself (for example, by sending forged 712 packets or forcing TLS version downgrade); or 714 c) against the IPP operation parameters (for example, by corrupting 715 requested document processing attributes). 717 7.2. Attacks and Defenses 719 This 'ipps' URI Scheme specification adds the following additional 720 security considerations to those described in [RFC2818], [RFC2910], 721 [RFC2911], [RFC5246], [RFC7230], [PWG5100.12], and [STD66]. 723 See: Section 'Security Considerations' in [RFC2818]. 725 See: Section 8 'Security Considerations' in [RFC2910]. 727 See: Section 8 'Security Considerations' in [RFC2911]. 729 See: Appendix D 'Implementation Notes', Appendix E 'Backward 730 Compatibility', and Appendix F 'Security Analysis' of [RFC5246]. 732 See: Section 9 'Security Considerations' in [RFC7230]. 734 See: Section 10 'Security Considerations' in [PWG5100.12]. 736 See: Section 7 'Security Considerations' in [STD66]. 738 7.2.1. Faked 'ipps' URI 740 An 'ipps' URI might be faked to point to a rogue IPP secure print 741 service, thus collecting confidential document contents from IPP 742 Clients. 744 Server authentication mechanisms and security mechanisms specified in 745 IPP/1.1 Encoding and Transport [RFC2910], HTTP over TLS [RFC2818], 746 and TLS/1.2 [RFC5246] can be used to address this threat. 748 7.2.2. Unauthorized Access by IPP Client 750 An 'ipps' URI might be used to access an IPP secure print service by 751 an unauthorized IPP Client. 753 Client authentication mechanisms and security mechanisms specified in 754 IPP/1.1 Encoding and Transport [RFC2910], HTTP over TLS [RFC2818], 755 and TLS/1.2 [RFC5246] can be used to address this threat. 757 7.2.3. Compromise at Application Layer Gateway 759 An 'ipps' URI might be used to access an IPP secure print service at 760 a print protocol application layer gateway (for example, an IPP to 761 LPD [RFC1179] gateway [RFC2569]), potentially causing silent 762 compromise of IPP security mechanisms. 764 There is no general defense against this threat by an IPP Client. 765 System administrators SHOULD avoid such configurations. 767 7.2.4. No Client Authentication for 'ipps' URI 769 An 'ipps' URI does not define parameters to specify the required IPP 770 Client authentication mechanism (for example, 'certificate' as 771 defined in section 4.4.2 'uri-authentication-supported' of IPP Model 772 [RFC2911]). 774 Either service discovery or directory protocols SHOULD be used first 775 or an IPP Client SHOULD first establish an 'ipp' connection (without 776 TLS or any client authentication) to the target IPP Printer and use a 777 Get-Printer-Attributes query to discover the required IPP Client 778 authentication mechanism(s) associated with a given 'ipps' URI. 780 7.3. TLS Version Requirements 782 In according with security best practices and all existing 783 deployments of the 'ipps' URI scheme, IPP Clients and IPP Printers 784 that support this specification MUST use TLS/1.2 [RFC5246], or later 785 TLS version, for all 'ipps' secure transport layer connections. 787 8. Acknowledgments 789 This document is an independent submission to the IETF by the 790 Internet Printing Protocol Working Group of the IEEE-ISTO Printer 791 Working Group, as part of their PWG IPP Everywhere [PWG5100.14] 792 project for secure mobile printing with vendor-neutral Client 793 software. 795 This document defines an alternate IPP transport binding to that 796 defined in the original IPP URL Scheme [RFC3510], but this document 797 does not update or obsolete [RFC3510]. 799 Thanks to Claudio Allochio, Tom Hastings (retired from Xerox), Bjoern 800 Hoerhmann, S. Mooneswamy, Tom Petch, Jerry Thrasher (Lexmark), Mykyta 801 Yevstifeyev, Pete Zehler (Xerox), and the members of the IEEE-ISTO 802 PWG IPP WG. 804 9. References 806 9.1. Normative References 808 [ASCII] "American National Standards Institute, Coded Character 809 Set -- 7-bit American Standard Code for Information 810 Interchange", ANSI X3.4, 1986. 812 [HTTP1.1] HTTP/1.1. See [RFC7230], [RFC7231], [RFC7232], 813 [RFC7233], [RFC7234], and [RFC7235]. 815 [PWG5100.12] Bergman, R., Lewis, H., McDonald, I., and M. Sweet, 816 "Internet Printing Protocol Version 2.0 Second Edition 817 (IPP/2.0 SE)", PWG 5100.12, February 2011. 818 820 [PWG5100.14] McDonald, I. and M. Sweet, "PWG IPP Everywhere", PWG 821 5100.14, January 2013. 822 824 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 825 Requirement Levels, BCP 14, RFC 2119, March 1997. 827 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 829 [RFC2910] Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and 830 J. Wenn, "Internet Printing Protocol/1.1: Encoding and 831 Transport", RFC 2910, September 2000. 833 [RFC2911] Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S., 834 and P. Powell, "Internet Printing Protocol/1.1: Model and 835 Semantics", RFC 2911, September 2000. 837 [RFC5246] Dierks, T., and E. Rescorla, "The Transport Layer Security 838 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 840 [RFC7230] Fielding, R., and J. Reschke, "Hypertext Transfer Protocol 841 (HTTP/1.1): Message Syntax and Routing, RFC 7230, June 842 2014. 844 [RFC7231] Fielding, R., and J. Reschke, "Hypertext Transfer Protocol 845 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 847 [RFC7232] Fielding, R., and J. Reschke, "Hypertext Transfer Protocol 848 (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 850 [RFC7233] Fielding, R., Lafon, Y., and J. Reschke, "Hypertext 851 Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, 852 June 2014. 854 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 855 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 856 2014. 858 [RFC7234] Fielding, R., and J. Reschke, "Hypertext Transfer Protocol 859 (HTTP/1.1): Authentication", RFC 7235, June 2014. 861 [STD7] Postel, J., "Transmission Control Protocol", STD 7, RFC 862 793, September 1981. 864 [STD63] Yergeau, F., "UTF-8, a transformation format of ISO 865 10646", STD 63, RFC 3629, November 2003. 867 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, Uniform 868 Resource Identifiers (URI) Generic Syntax, STD 66, RFC 869 3986, January 2005. 871 [STD68] Crocker, D., Ed., and P. Overell, "Augmented BNF for 872 Syntax Specifications: ABNF", STD 68, RFC 5234, January 873 2008. 875 9.2. Informative References 877 [BCP35] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 878 Registration Procedures for New URI Schemes", BCP 35, RFC 879 4395, February 2006. 881 [CUPS] Apple, "CUPS standards-based, open source printing system 882 for OS X and other UNIX-like operating systems" 883 885 [MIMEREG] Internet Assigned Numbers Authority (IANA) Registry "MIME 886 Media Types" 887 889 [PORTREG] Internet Assigned Numbers Authority (IANA) Registry "Port 890 Numbers" 891 893 [RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, 894 August 1990. 896 [RFC2569] Herriot, R., Ed., Hastings, T., Jacobs, N., and J. 897 Martin, "Mapping between LPD and IPP Protocols", RFC 2569, 898 April 1999. 900 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 901 HTTP/1.1", RFC 2817, May 2000. 903 [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. 904 Holst, "Internet Printing Protocol/1.1: Implementor's 905 Guide", RFC 3196, November 2001. 907 [RFC3510] Herriot, R. and I. McDonald, "Internet Printing 908 Protocol/1.1: IPP URL Scheme", RFC 3510, April 2003. 910 10. Appendix A - Summary of IPP URL Scheme (Informative) 912 This section is an informative summary of the original IPP URL Scheme 913 [RFC3510] and the associated IPP over HTTP transport binding defined 914 in [RFC2910]. 916 When using an 'ipp' URI [RFC3510], an IPP Client establishes an IPP 917 application layer connection according to the following sequence: 919 1) The IPP Client selects an 'ipp' URI value from 920 "printer-uri-supported" Printer attribute [RFC2911], a directory 921 entry, discovery info, a web page, etc.; 923 2) The IPP Client converts the 'ipp' URI to an 'http' URI (replacing 924 'ipp' with 'http' and inserting the port number from the URI or 925 port 631 if the URI doesn't include a port number); 927 3) The IPP Client establishes a TCP [STD7] reliable transport layer 928 connection to the target endpoint - see section 3.4 'Establishing 929 a connection' in TCP [STD7]; 931 4) The IPP Client establishes an HTTP [RFC7230] session layer 932 connection to the target endpoint - see section 6 Connection 933 Management in [RFC7230]; 935 5) Optionally, either the IPP Client upgrades to TLS within HTTP/1.1 936 per section 3 'Client Requested Upgrade to HTTP over TLS' of 938 [RFC2817] or the IPP Printer upgrades to TLS within HTTP/1.1 per 939 section 4 'Server Requested Upgrade to HTTP over TLS' of 940 [RFC2817], in order to establish a TLS secure transport sublayer 941 within the original TCP/HTTP connection - per the 942 "uri-security-supported" (section 4.4.3 in [RFC2911]) Printer 943 attribute value parallel to the "printer-uri-supported" (see 944 section 4.4.1 in [RFC2911]) value that matches this connection; 945 and 947 6) The IPP Client sends IPP application layer requests to and 948 receives responses from the IPP Printer over the HTTP [RFC7230] 949 session layer connection using the POST method defined in section 950 9.5 of HTTP/1.1 [RFC7230], as specified in section 4 'Encoding of 951 Transport Layer' in IPP/1.1 Encoding and Transport [RFC2910]. 953 See: Section 8 'Security Considerations' in [RFC2911]. 955 See: Section 8 'Security Considerations' in [RFC2817]. 957 11. Appendix X - Change History 959 [RFC Editor: Delete this section before publication as an RFC] 961 28 September 2014 - draft-mcdonald-ipps-uri-scheme-14.txt 962 Editorial - Kept "Intended Status" as "Standards Track", with AD 963 sponsoring, per advice of Barry Leiba on 18 August 2014. 964 Editorial - Revised Abstract, Boilerplate, and Introduction to state 965 that this document is an Independent Submission to the RFC Editor 966 Stream with IETF AD sponsoring, per advice of Barry Leiba on 18 967 August 2014. 968 Technical - Revised section 3 IPP over HTTPS Transport Binding, to 969 require TLS/1.2, or later TLS version, for all 'ipps' connections, 970 per IEEE-ISTO PWG IPP WG review. 971 Technical - Revised section 7.2.1 Faked 'ipps' URI and section 7.2.2 972 Unauthorized Access by IPP Client, to delete all references to 973 TLS/1.0 and TLS/1.1, per IEEE-ISTO PWG IPP WG review. 974 Technical - Renamed section 7.3 TLS Cipher Suite Requirements to TLS 975 Version Requirements and deleted all requirements for specific cipher 976 suites, per IEEE-ISTO PWG IPP WG review. 977 Technical - Revised section 9.1 Normative References, to delete all 978 references to TLS/1.0 and TLS/1.1, per IEEE-ISTO PWG IPP WG review. 980 3 July 2014 - draft-mcdonald-ipps-uri-scheme-13.txt 981 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, to 982 replace old 'path-absolute' from RFC 2616 with 'absolute-path' from 983 [RFC7230], per IEEE-ISTO PWG IPP WG review. 984 Editorial - Revised section 2.2 Abbreviations, section 3 IPP over 985 HTTPS Transport Binding, section 4.2 Syntax of 'ipps' URI Scheme, 986 section 4.7 Comparisons of 'ipps' URI, section 7.2 Attacks and 987 Defenses, section 9.1 Normative References, and section 10 Appendix A 988 - Summary of IPP URL Scheme, to replace [RFC2616] with either 989 [RFC7230] or [HTTP1.1] - a new collective reference to [RFC7230], 990 [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235], per 991 IEEE-ISTO PWG IPP WG review. 993 20 April 2014 - draft-mcdonald-ipps-uri-scheme-12.txt 994 Editorial - Revised section 4.3 Associated Port for 'ipps' URI 995 Scheme, to add informative reference to CUPS, per IEEE-ISTO PWG IPP 996 WG review. 998 Editorial - Revised section 4.6.1 Examples of 'ipps' URI for 999 Printers, to change "third" to "fourth" for the port 443 example, per 1000 IEEE-ISTO PWG IPP WG review. 1001 Editorial - Revised section 6 IANA Considerations, to add informative 1002 reference to CUPS, per IEEE-ISTO PWG IPP WG review. 1003 Editorial - Revised section 9.2 Informative References, to add 1004 informative reference to CUPS, per IEEE-ISTO PWG IPP WG review. 1006 7 April 2014 - draft-mcdonald-ipps-uri-scheme-11.txt 1007 Global - revised all references to section 4.2 and section 4.3, to 1008 add parenthetic (syntax) and (port) respectively, per IEEE-ISTO PWG 1009 IPP WG review. 1010 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, to 1011 correct two typos (extra words) in section 4.3 references, per 1012 IEEE-ISTO PWG IPP WG review. 1013 Editorial - Revised section 4.3 Associated Port for 'ipps' URI 1014 Scheme, to add note about compatibility for IPP Clients and IPP 1015 Printers that MUST accept explicit port 443 (assigned in 'https' URI 1016 scheme [RFC2818]) and process normally, per IEEE-ISTO PWG IPP WG 1017 review. 1018 Editorial - Revised section 4.6.1 Examples of 'ipps' URI for 1019 Printers, to add example of explicit port 443, per IEEE-ISTO PWG IPP 1020 WG review. 1022 30 March 2014 - draft-mcdonald-ipps-uri-scheme-10.txt 1023 Global - Updated references, per IEEE-ISTO PWG IPP WG review. 1024 Global - Changed "e.g." to "for example", for readability. 1025 Editorial - Revised section Copyright Notice, to correct year. 1026 Editorial - Revised section 3 IPP over HTTPS Transport Binding, item 1027 2), to clarify that port 631 is ONLY inserted in the derived 'https' 1028 URI when an explicit port is NOT specified in the original 'ipps' 1029 URI, per Smith Kennedy and IEEE-ISTO PWG IPP WG review. 1030 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, note 1031 about URI lengths greater than 255 octets, to change 'ought to' to 1032 'SHOULD', per Smith Kennedy and IEEE-ISTO PWG IPP WG review. 1033 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, to add 1034 reference to section 4.3 for use of port 631, per Smith Kennedy and 1035 IEEE-ISTO PWG IPP WG review. 1037 Editorial - Revised section 4.3 Associated Port for 'ipps' URI 1038 Scheme, to add note about dual-use of port 631 for 'ipp' URI and 1039 'ipps' URI with reference to CUPS source for example of incoming 1040 connection handling, per Smith Kennedy and IEEE-ISTO PWG IPP WG 1041 review. 1042 Editorial - Revised section 4.3 Associated Port for 'ipps' URI 1043 Scheme, to add note about compatibility for IPP Clients and IPP 1044 Printers that should accept explicit port 443 (assigned in 'https' 1045 URI scheme [RFC2818]) and process normally, per IEEE-ISTO PWG IPP WG 1046 review. 1047 Editorial - Revised section 4.6.1 Examples of 'ipps' URI for 1048 Printers, to add reference to section 4.2 (syntax) and section 4.3 1049 (port), per Smith Kennedy and IEEE-ISTO PWG IPP WG review. 1050 Editorial - Revised section 4.7 Comparisons of 'ipps' URI, to add 1051 reference to section 4.3 (port), per Smith Kennedy and IEEE-ISTO PWG 1052 IPP WG review. 1053 Editorial - Revised section 5.1 Applicability to IPP Clients, to add 1054 reference to section 4.2 (syntax) and section 4.3 (port), per Smith 1055 Kennedy and IEEE-ISTO PWG IPP WG review. 1056 Editorial - Revised section 5.1 Applicability to IPP Clients, item 1057 d), to change 'MUST the' to 'MUST use the', per Smith Kennedy and 1058 IEEE-ISTO PWG IPP WG review. 1059 Editorial - Revised section 5.2 Applicability to IPP Printers, to add 1060 reference to section 4.2 (syntax) and section 4.3 (port), per Smith 1061 Kennedy and IEEE-ISTO PWG IPP WG review. 1062 Editorial - Revised section 5.2 Applicability to IPP Printers, item 1063 d), to change 'MUST the' to 'MUST use the', per Smith Kennedy and 1064 IEEE-ISTO PWG IPP WG review. 1065 Editorial - Revised section 5.2 Applicability to IPP Printers, to 1066 delete former item e) (listen only on port 631) which conflicted with 1067 existing IPP implementations (for example, listening on port 443 as 1068 well), per Smith Kennedy and IEEE-ISTO PWG IPP WG review. 1069 Editorial - Revised section 6 IANA Considerations, to add URI for 1070 CUPS source, per IEEE-ISTO PWG IPP WG review. 1071 Editorial - Revised section 7.2.4 No Client Authentication for 'ipps' 1072 URI, to change "or or" to "or" (typo), per Smith Kennedy and 1073 IEEE-ISTO PWG IPP WG review. 1074 Editorial - Revised Appendix A Summary of IPP URL Scheme, item 2), to 1075 clarify that port 631 is ONLY inserted in the derived 'http' URI when 1076 an explicit port is NOT specified in the original 'ipp' URI, per 1077 Smith Kennedy and IEEE-ISTO PWG IPP WG review. 1079 5 November 2013 - draft-mcdonald-ipps-uri-scheme-09.txt 1080 Global - Updated references, per IPP WG review. 1081 Editorial - Revised Abstract, section 1 Introduction, and section 8 1082 Acknowledgments to clarify that this document is an individual 1083 submission to the IETF by the IPP WG of the IEEE-ISTO PWG, per S 1084 Mooneswamy. 1085 Editorial - Revised Abstract, section 1 Introduction, and section 8 1086 Acknowledgments to clarify that this document does not update or 1087 obsolete [RFC3510], per S Mooneswamy and Tom Petch. 1089 Editorial - Revised section 1.1 Structure of this Document to align 1090 with changes below, per Tom Petch. 1091 Editorial - Revised section 2 Conventions Used in this Document to 1092 add section 2.1 Printing Terminology and to remove redundant "In this 1093 document" and clarify definitions, per Tom Petch. 1094 Editorial - Moved former Appendix B - Abbreviations Used in this 1095 Document to become section 2.2 Abbreviations, per Tom Petch. 1096 Technical - Revised section 3 IPP over HTTPS Transport Binding, 1097 section 5 Applicability of this Specification, and section 7 Security 1098 Considerations to address specific TLS/1.0 [RFC2246], TLS/1.1 1099 [RFC4346], and TLS/1.2 [RFC5246] requirements, per Tom Petch. 1100 Editorial - Moved former section 3.1 IPP over HTTP Transport Binding 1101 to become Appendix A - Summary of IPP URL Scheme (Informative), per 1102 Tom Petch. 1103 Technical - Revised section 4.2 Syntax of 'ipps' URI Scheme to add 1104 note about the retention of the (unused) "query" production for 1105 consistency with IPP/1.1 Encoding and Transport [RFC2910] and the 1106 original IPP URL Scheme [RFC3510], but warn that it has no defined 1107 semantics in IPP and therefore its use is unsafe for IPP Clients, per 1108 Tom Petch. 1109 Technical - Revised section 7 Security Considerations to add section 1110 8.1 Problem Statement, section 8.2 Attacks, and section 8.3 TLS 1111 Security Considerations, per Tom Petch. 1112 Editorial - Moved former section Appendix A - Acknowledgments to 1113 become section 8 Acknowledgements (in body of document) and updated 1114 to reflect recent comments on this document, per Tom Petch. 1115 Technical - Revised section 9.1 Normative References to add TLS/1.0 1116 [RFC2246] and TLS/1.1 [RFC4346], per Tom Petch. 1118 19 September 2013 - draft-mcdonald-ipps-uri-scheme-08.txt 1119 Global - Updated references, per IPP WG review. 1121 12 May 2013 - draft-mcdonald-ipps-uri-scheme-07.txt 1122 Editorial - Revised section 1 (introduction) to add 'Rationale for 1123 this document', per Smith Kennedy. 1124 Editorial - Global - Changed 'Conformance Requirements' to 1125 'Applicability', per Barry Leiba. 1126 Editorial - Global - Changed '[PWG5100.EW]' to '[PWG5100.14]', 1127 corrected date and URI, and moved section 8.1 (normative references), 1128 per IPP WG review. 1130 10 November 2012 - draft-mcdonald-ipps-uri-scheme-06.txt 1131 Editorial - Global - Fixed typos and indentation, per IPP WG review. 1132 Editorial - Global - changed 'generic drivers' to 'vendor-neutral 1133 Client software', per IPP WG review. 1134 Editorial - Revised section 8.2 (informative references, to correct 1135 title of "PWG IPP Everywhere" (i.e., delete version number), per IPP 1136 WG review. 1138 14 May 2012 - draft-mcdonald-ipps-uri-scheme-05.txt 1139 Editorial - Global - Fixed typos and indentation, per IPP WG review. 1140 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to 1141 insert missing "to" in "connection to the target endpoint", per IPP 1142 WG review. 1143 Editorial - Revised section 4.2 (syntax), to correct indentation of 1144 first "Note:", per IPP WG review. 1145 Editorial - Revised sections 5.1 and 5.2 (client/printer conformance) 1146 and section 7 (security considerations) to delete the out-of-scope 1147 normative references to [RFC2817], per IPP WG review. 1149 22 November 2011 - draft-mcdonald-ipps-uri-scheme-04.txt 1150 Editorial - Global - Fixed typos and indentation, per IPP WG review. 1151 Editorial - Revised Introduction and Acknowledgments to say 'project 1152 for mobile, ubiquitous printing with generic drivers', per IPP WG 1153 review. 1154 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to add 1155 references to HTTP POST and section 4 of RFC 2910, per IPP WG review. 1156 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to add 1157 section references to all well-known standards (connection setup, 1158 etc.), per IPP WG review. 1159 Editorial - Revised section 4.2 (syntax) to move note from from 1160 section 4.6 (examples) and explain why literal IP addresses SHOULD 1161 NOT be used in 'ipps' URI, per IPP WG review. 1162 Editorial - Revised sections 4.6.1 and 4.6.2 (examples) to replace 1163 'abc.com' w/ 'example.com' (per IETF) and replace '/printer' path 1164 element w/ '/ipp' (better practice), per IPP WG review. 1165 Editorial - Revised section 5.2 (Printer conformance) to fold former 1166 (c) and (d) into a single requirement for standard port 631 and 1167 reordered other requirements to group MUSTs before SHOULDs, per IPP 1168 WG review. 1169 Editorial - Revised section 5.2 (Printer conformance) to add backward 1170 reference to section 4.2 for rationale for not using IP literal 1171 addresses, per IPP WG review. 1172 Editorial - Revised section 6 (IANA) to explicitly state that 'ipps' 1173 uses secure communications using HTTP over TLS, per IPP WG review. 1174 Editorial - Revised section 7 (Security) to cleanup numerous loose 1175 ends, per IPP WG review. 1176 Editorial - Revised section 8 (References) to cleanup typos and 1177 links, per IPP WG review. 1178 Editorial - Revised section 1 (introduction), section 8.2 1179 (informative references, and section 9 (appendix A) to change 1180 "[IPPEVE]" to "[PWG5100.EW]", per IPP WG review. 1182 26 August 2011 - draft-mcdonald-ipps-uri-scheme-03.txt 1183 Editorial - Revised Abstract and Introduction to state published by 1184 the IETF on behalf of IEEE-ISTO PWG (to avoid status ambiguity), per 1185 Mykyta Yevstifeyev. 1186 Editorial - Revised section 1 to list all currently defined versions 1187 of IPP in RFC 2566, RFC 2911, and PWG 5100.12, per Mykyta 1188 Yevstifeyev. 1190 Technical - Revised section 1, section 2, section 3.2, section 4.1, 1191 and section 7, to reference IPP Version 2.0 Second Edition (PWG 1192 5100.12), per Mykyta Yevstifeyev. 1193 Editorial - Revised section 3.1, to fix broken STD7 reference, per 1194 Mykyta Yevstifeyev. 1195 Editorial - Revised section 6, to add BCP35 reference for template 1196 (regression loss when the template was moved up from former 1197 appendix), per Mykyta Yevstifeyev. 1198 Editorial - Revised section 8.1 to add PWG 5100.12 (normative), 1199 Editorial - Revised section 8.2 to add PWG IPP Everywhere 1200 (informative) and RFC 1179 (informative), per Mykyta Yevstifeyev. 1201 Editorial - Revised appendix B to add references for more reading, 1202 per Mykyta Yevstifeyev. 1204 28 February 2011 - draft-mcdonald-ipps-uri-scheme-02.txt 1205 Editorial - Revised document title to emphasize IPP over HTTPS 1206 Transport Binding (reason for IETF standards-track status). 1207 Editorial - Replaced "IPP URI" with "'ipp' URI", "IPPS URI" with 1208 "'ipps' URI", "HTTP URI" with "'http' URI", and "HTTPS URI" with 1209 "'https' URI" throughout this document for conformance to section 3.1 1210 of [STD66], per Mykyta Yevstifeyev. 1211 Editorial - Revised and simplified Abstract, per Mykyta Yevstifeyev. 1212 Editorial - Revised and simplified section 1 'Introduction', per 1213 Mykyta Yevstifeyev. 1214 Editorial - Renamed section 2 from 'Conformance Terminology' to 1215 'Conventions Used in this Document', per Mykyta Yevstifeyev. 1216 Editorial - Moved former section 3.1 'IPP Model Terminology 1217 (Normative)' content into section 2 'Conventions Used in this 1218 Document' for readability, per Mykyta Yevstifeyev. 1219 Editorial - Reordered subsections and reversed word order in all 1220 subsection titles in section 4 'The 'ipps' URI Scheme' for 1221 readability, per Mykyta Yevstifeyev. 1222 Editorial - Added note to section 4.2 'Syntax of 'ipps' URI Scheme' 1223 to explain why 'authority' production is NOT imported from [STD66], 1224 because it includes an optional 'userinfo' component which cannot be 1225 used in 'ipps' URI values. 1226 Editorial - Deleted note describing empty 'host' component from 1227 section 4.2 'Syntax of 'ipps' URI Scheme', because 'host' component 1228 is mandatory in [STD66]. 1229 Editorial - Deleted 'Internationalization Considerations' section 1230 which was redundant with section 4.3 'Character Encoding of 'ipps' 1231 URI Scheme', per Mykyta Yevstifeyev. 1232 Editorial - Revised all references to follow current RFC Editor 1233 style, per Mykyta Yevstifeyev. 1234 Editorial - Moved former 'Appendix A - Registration of IPPS URI 1235 Scheme' content inline into section 6 'IANA Considerations', per 1236 Mykyta Yevstifeyev. 1237 Editorial - Moved former body section 'Acknowledgements' to 'Appendix 1238 A - Acknowledgements', per Mykyta Yevstifeyev. 1239 Editorial - Added new 'Appendix B - Abbreviations Used in this 1240 Document' for readability, per Mykyta Yevstifeyev. 1242 Editorial - Moved section 'Authors' Addresses' to end of document, 1243 per Mykyta Yevstifeyev. 1245 1 December 2010 - draft-mcdonald-ipps-uri-scheme-01.txt 1246 - Technical - added UTF-8 [STD63] as required charset for all IPPS 1247 URI in section 4.4 and section 7, per Bjoern Hoehrmann. 1248 - Technical - corrected percent encoding for data octets outside the 1249 US-ASCII range in section 4.4 and section 7, per Bjoern Hoehrmann. 1250 - Editorial - global - changed "[RFC4395]" to "[BCP35]", changed 1251 "[RFC3629]" to "[STD63]", changed "[RFC3986]" to "[STD66]", and 1252 changed "[RFC5234]" to "[STD68]", per Bjoern Hoehrmann. 1253 - Editorial - restored trailing "]]" in ABNF syntax in section 4.5, 1254 per Bjoern Hoehrmann. 1255 - Editorial - changed "Author/Change controller" to "IESG" in section 1256 12 Appendix A registration template, as required by section 5.3 of 1257 [BCP35], per Bjoern Hoehrmann. 1259 10 October 2010 - draft-mcdonald-ipps-uri-scheme-00.txt 1260 - Editorial - complete rewrite of RFC 3510 for new transport binding 1261 - Editorial - moved Abstract to beginning of first page, per ID-Nits 1262 - Editorial - fixed copyright, boilerplate, and typos, per ID-Nits 1263 - Editorial - added references to RFCs 2119 and 3510, per ID-Nits 1264 - Editorial - deleted obsolete references to RFCs 2246 and 4346, per 1265 ID-Nits 1266 - Technical - changed Intended Status to Standards Track to reflect 1267 the new normative IPPS URI scheme and transport binding 1268 - Technical - added section 3.2 IPP over HTTP Transport Binding 1269 (informative) 1270 - Technical - added section 3.3 IPP over HTTPS Transport Binding 1271 (normative) 1272 - Technical - updated section 5 Conformance Requirements to require 1273 HTTP Upgrade (RFC 2817) support (for interoperability with existing 1274 IPP implementations), per discussion on IPP WG mailing list 1275 - Editorial - updated Appendix A w/ registration template from RFC 1276 4395 1278 12. Authors' Addresses 1280 Ira McDonald 1281 High North Inc 1282 221 Ridge Ave 1283 Grand Marais, MI 49839 1285 Phone: +1 906-494-2434 1286 Email: blueroofmusic@gmail.com 1288 Michael Sweet 1289 Apple Inc 1290 10431 N De Anza Blvd, M/S 38-4LPT 1291 Cupertino, CA 95014 1293 Phone: +1 408-974-8798 1294 Email: msweet@apple.com 1296 Usage questions and comments on this 'ipps' URI Scheme can be sent 1297 directly to the editors at their above addresses and also to the PWG 1298 IPP WG mailing list. Instructions for subscribing to the PWG IPP WG 1299 mailing list can be found at: 1301 PWG IPP WG Web Page: http://www.pwg.org/ipp/ 1302 PWG IPP WG Mailing List: ipp@pwg.org 1303 PWG IPP WG Subscription: http://www.pwg.org/mailhelp.html 1305 Implementers of this specification are encouraged to join the PWG IPP 1306 WG Mailing List in order to participate in any discussions of 1307 clarification issues and comments. Note that this IEEE-ISTO PWG 1308 mailing list rejects mail from non-subscribers (in order to reduce 1309 spam).