idnits 2.17.1 draft-mcdonald-ipps-uri-scheme-12.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 (20 April 2014) is 3657 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 137, but not defined ** Obsolete undefined reference: RFC 2566 (Obsoleted by RFC 2911) == Missing Reference: 'RFC 2817' is mentioned on line 183, but not defined == Missing Reference: 'RFC 2717' is mentioned on line 178, but not defined ** Obsolete undefined reference: RFC 2717 (Obsoleted by RFC 4395) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** 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 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** 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: 10 errors (**), 0 flaws (~~), 4 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: 20 October 2014 20 April 2014 8 IPP over HTTPS Transport Binding and 'ipps' URI Scheme 9 draft-mcdonald-ipps-uri-scheme-12.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 individual submission to the IETF by the Internet 20 Printing Protocol Working Group of the IEEE-ISTO Printer Working 21 Group, as part of their PWG IPP Everywhere (PWG 5100.14) project for 22 secure mobile printing with vendor-neutral Client software. 24 This memo defines an alternate IPP transport binding to that defined 25 in the original IPP URL Scheme (RFC 3510), but this memo does not 26 update or obsolete (RFC 3510). 28 This memo updates RFC 2910 and RFC 2911. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. Internet-Drafts are working 34 documents of the Internet Engineering Task Force (IETF), its areas, 35 and its working groups. Note that other groups may also distribute 36 working documents as Internet-Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 This Internet-Draft will expire on 20 October 2014. 51 Copyright Notice 53 Copyright (c) 2014 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction ............................................... 4 69 1.1. Structure of this document ............................. 4 70 1.2. Rationale for this document ............................ 5 71 2. Conventions Used in this Document .......................... 5 72 2.1. Printing Terminology ................................... 5 73 2.2. Abbreviations .......................................... 6 74 3. IPP over HTTPS Transport Binding ........................... 7 75 4. Definition of 'ipps' URI Scheme ............................ 8 76 4.1. Applicability of 'ipps' URI Scheme ..................... 8 77 4.2. Syntax of 'ipps' URI Scheme ............................ 9 78 4.3. Associated Port for 'ipps' URI Scheme .................. 10 79 4.4. Associated MIME Type for 'ipps' URI Scheme ............. 11 80 4.5. Character Encoding of 'ipps' URI Scheme ................ 11 81 4.6. Examples of 'ipps' URI ................................. 11 82 4.6.1. Examples of 'ipps' URI for Printers ................ 11 83 4.6.2. Examples of 'ipps' URI for Jobs .................... 12 84 4.7. Comparisons of 'ipps' URI .............................. 13 85 5. Applicability of this Specification ........................ 13 86 5.1. Applicability to IPP Clients ........................... 13 87 5.2. Applicability to IPP Printers .......................... 14 88 6. IANA Considerations ........................................ 15 89 7. Security Considerations .................................... 16 90 7.1. Problem Statement ...................................... 16 91 7.1.1. Targets of Attacks ................................. 16 92 7.1.2. Layers of Attacks .................................. 17 93 7.2. Attacks and Defenses ................................... 17 94 7.2.1. Faked 'ipps' URI ................................... 17 95 7.2.2. Unauthorized Access by IPP Client .................. 18 96 7.2.3. Compromise at Application Layer Gateway ............ 18 97 7.2.4. No Client Authentication for 'ipps' URI ............ 18 98 7.3. TLS Cipher Suite Requirements .......................... 18 100 8. Acknowledgments ............................................ 19 101 9. References ................................................. 20 102 9.1. Normative References ................................... 20 103 9.2. Informative References ................................. 21 104 10. Appendix A - Summary of IPP URL Scheme (Informative) ...... 22 105 11. Appendix X - Change History ............................... 23 106 12. Authors' Addresses ........................................ 28 107 1. Introduction 109 This document defines the Internet Printing Protocol (IPP) over HTTPS 110 transport binding and the corresponding 'ipps' URI scheme, that is 111 used to designate the access to the network location of a secure IPP 112 print service or a network resource (for example, a print job) 113 managed by such a service. 115 This document is an individual submission to the IETF by the Internet 116 Printing Protocol Working Group of the IEEE-ISTO Printer Working 117 Group, as part of their PWG IPP Everywhere [PWG5100.14] project for 118 secure mobile printing with vendor-neutral Client software. 120 This document defines an alternate IPP transport binding to that 121 defined in the original IPP URL Scheme [RFC3510], but this document 122 does not update or obsolete [RFC3510]. 124 This document updates [RFC2910] and [RFC2911]. 126 This document updates: 127 a) IPP/1.1 Encoding and Transport [RFC2910], by extending section 4 128 'Encoding of the Transport Layer', section 5 'IPP URL Scheme', and 129 section 8.2 'Using IPP with TLS'; 130 b) IPP/1.1 Model and Semantics [RFC2911], by extending section 4.1.6 131 'uriScheme' and section 4.4.1 'printer-uri-supported'; and 132 c) IEEE-ISTO PWG IPP Version 2.0 Second Edition [PWG5100.12], by 133 extending section 4 'IPP Standards' and section 10 'Security 134 Considerations'. 136 The following versions of IPP are currently defined: 137 - 1.0 in [RFC2566] (obsolete) 138 - 1.1 in [RFC2911] 139 - 2.0 in [PWG5100.12] 140 - 2.1 in [PWG5100.12] 141 - 2.2 in [PWG5100.12] 143 Overview information about IPP is available in section 1 of RFC 2911 144 [RFC2911], section 1 of RFC 3196 [RFC3196], and section 1 of PWG IPP 145 Version 2.0 Second Edition [PWG5100.12]. 147 1.1. Structure of this document 149 This document contains the following sections: Section 2 defines the 150 conventions used throughout the document. 152 Section 3 defines the IPP over HTTPS transport binding. 154 Section 4 defines the 'ipps' URI scheme. 156 Section 5 defines the applicability of this specification to IPP 157 Clients and IPP Printers. 159 Sections 6 and 7 contain IANA and security considerations, 160 respectively. 162 Section 8 containes acknowledgments. 164 Section 9 contains references. 166 Appendix A contains an informative summary of the original IPP URL 167 Scheme [RFC3510] and associated IPP over HTTP transport binding. 169 1.2. Rationale for this document 171 The 'ipps' URI scheme was defined for the following reasons: 173 1) Some existing IPP Client and IPP Printer implementations of 174 Upgrading to TLS Within HTTP/1.1 [RFC 2817] are flawed and 175 unreliable. 177 2) Some existing IPP Client and IPP Printer implementations of HTTP 178 Upgrade [RFC 2717] do not perform upgrade at the beginning of 179 every HTTP connection, but instead only shift to secure IPP for 180 selected IPP operations (inherently dangerous behavior on the same 181 underlying TCP connection). 183 3) IPP Printer server-mandated HTTP Upgrade [RFC 2817] can still lead 184 to exposure of IPP Client data if the Expect request header is not 185 used - basically the IPP Client can send its whole Print-Job 186 request before the IPP Printer has a chance to respond and say, 187 "Wait! You need to encrypt first!" 189 2. Conventions Used in this Document 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in RFC 2119 [RFC2119]. 195 2.1. Printing Terminology 197 The reader of this document needs to be familiar with the printing 198 terms defined in IPP/1.1 Model and Semantics [RFC2911] as well as the 199 following: 201 IPP Client: The software (on some hardware platform) that submits 202 IPP Job creation and IPP Printer and IPP Job management operations 203 via the IPP over HTTP transport binding defined in the IPP/1.1 204 Encoding and Transport [RFC2910] and/or the IPP over HTTPS transport 205 binding defined in section 3 of this specification to a downstream 206 IPP Printer (print spooler, print gateway, or physical printing 207 device). 209 IPP Job: The set of attributes and documents for one print job 210 instantiated in an IPP Printer. 212 IPP Job object: Synonym for IPP Job. 214 IPP Printer: The software (on some hardware platform) that receives 215 IPP Job creation and IPP Printer and IPP Job management operations 216 via the IPP over HTTP transport binding defined in the IPP/1.1 217 Encoding and Transport [RFC2910] and/or the IPP over HTTPS transport 218 binding defined in section 3 of this specification from an upstream 219 IPP Client or IPP Printer. 221 IPP Printer object: Synonym for IPP Printer. 223 'ipps' URI: A URI using the 'ipps' URI scheme defined in section 4 224 of this specification. 226 2.2. Abbreviations 228 This document makes use of the following abbreviations (given with 229 their expanded forms and references for further reading): 231 ABNF - Augmented Backus-Naur Form [STD68] 233 ASCII - American Standard Code for Information Interchange [ASCII] 235 HTTP - HyperText Transfer Protocol [RFC2616] 237 HTTPS - HTTP over TLS [RFC2818] 239 IANA - Internet Assigned Numbers Authority 240 242 IEEE - Institute of Electrical and Electronics Engineers 243 245 IESG - Internet Engineering Steering Group 246 248 IPP - Internet Printing Protocol [RFC2911] and [PWG5100.12] 249 251 ISTO - IEEE Industry Standards and Technology Organization 252 254 LPD - Line Printer Daemon Protocol [RFC1179] 256 PWG - IEEE-ISTO Printer Working Group 257 259 RFC - Request for Comments 260 262 TCP - Transmission Control Protocol [STD7] 264 TLS - Transport Layer Security [RFC5246] 266 URI - Uniform Resource Identifier [STD66] 268 URL - Uniform Resource Locator [STD66] 270 UTF-8 - Unicode Transformation Format - 8-bit [STD63] 272 3. IPP over HTTPS Transport Binding 274 This section is a normative description of the protocol steps taken 275 by an IPP Client using and an IPP Printer supporting the 'ipps' URI 276 scheme. 278 This document defines the following alternate IPP over HTTPS 279 transport binding for the abstract protocol defined in IPP/1.1 Model 280 and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version 2.0 Second 281 Edition [PWG5100.12]. 283 When using an 'ipps' URI, an IPP Client MUST establish an IPP 284 application layer connection according to the following sequence: 286 1) The IPP Client selects an 'ipps' URI value from 287 "printer-uri-supported" Printer attribute [RFC2911], a directory 288 entry, discovery info, a web page, etc.; 290 2) The IPP Client converts the 'ipps' URI to an 'https' URI 291 (replacing 'ipps' with 'https' and inserting the port number from 292 the URI or port 631 if the URI doesn't include a port number); 294 3) The IPP Client establishes a TCP [STD7] reliable transport layer 295 connection to the target endpoint - see section 3.4 'Establishing 296 a connection' in TCP [STD7]; 298 4) The IPP Client establishes a TLS/1.0 [RFC2246], TLS/1.1 [RFC4346], 299 TLS/1.2 [RFC5246], or later TLS version secure transport layer 300 connection to the target endpoint - see section 7 'The TLS 301 Handshake Protocol' in [RFC2246], [RFC4346], and [RFC5246]; 303 5) The IPP Client establishes an HTTPS [RFC2818] secure session layer 304 connection over the TLS secure transport layer to the target 305 endpoint; and 307 6) The IPP Client sends IPP application layer requests to and 308 receives responses from the IPP Printer over the HTTPS [RFC2818] 309 secure session layer connection using the POST method defined in 310 section 9.5 of HTTP/1.1 [RFC2616], as specified in section 4 311 'Encoding of Transport Layer' in IPP/1.1 Encoding and Transport 312 [RFC2910]. 314 See: Section 'Security Considerations' in [RFC2818]. 316 See: Section 10 'Security Considerations' in [PWG5100.12]. 318 4. Definition of 'ipps' URI Scheme 320 4.1. Applicability of 'ipps' URI Scheme 322 The 'ipps' URI scheme MUST only be used to specify absolute URI 323 (relative 'ipps' URI are not allowed) for IPP secure print services 324 and their associated network resources. The 'ipps' URI scheme MUST 325 only be used to specify the use of the abstract protocol defined in 326 IPP/1.1 Model and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version 327 2.0 Second Edition [PWG5100.12] over an HTTPS [RFC2818] transport, as 328 defined in this specification. Any other transport binding for IPP 329 would require a different URI scheme. 331 The 'ipps' URI scheme allows an IPP Client to choose an appropriate 332 IPP secure print service (for example, from a directory). The IPP 333 Client can establish an HTTPS connection to the specified IPP secure 334 print service. The IPP Client can send IPP protocol requests (for 335 example, 'Print-Job' requests) and receive IPP protocol responses 336 over that HTTPS connection. 338 See: Section 4.2 (syntax) of this document. 340 See: Section 4.4.1 'printer-uri-supported' in IPP/1.1 Model and 341 Semantics [RFC2911]. 343 See: Section 5 'IPP URL Scheme' in IPP/1.1 Encoding and Transport 344 [RFC2910]. 346 See: Section 4 'IPP Standards' and section 10 'Security 347 Considerations' of IEEE-ISTO PWG IPP Version 2.0 Second Edition 348 [PWG5100.12]. 350 4.2. Syntax of 'ipps' URI Scheme 352 The abstract protocol defined in IPP/1.1 Model and Semantics 353 [RFC2911] places a limit of 1023 octets (NOT characters) on the 354 length of a URI. 356 See: Section 4.1.5 'uri' in [RFC2911]. 358 Note: IPP Printers SHOULD be cautious about depending on URI lengths 359 above 255 octets, because some older IPP Client implementations might 360 not properly support these lengths. 362 'ipps' URI MUST be represented in absolute form. Absolute URI MUST 363 always begin with a scheme name followed by a colon. For definitive 364 information on URI syntax and semantics, see "Uniform Resource 365 Identifiers (URI) Generic Syntax and Semantics" [STD66]. This 366 specification adopts the definitions of "host", "port", 367 "path-absolute", and "query" from [STD66]. 369 The 'ipps' URI scheme syntax in ABNF [STD68] is defined as follows: 371 ipps-uri = 372 "ipps:" "//" host [ ":" port ] [ path-absolute [ "?" query ]] 374 If the port is empty or not given, then port 631 MUST be used. 376 See: Section 4.3 (port) of this document. 378 The semantics are that the identified resource (see section 5.1.2 of 379 [RFC2616]) is located at the IPP secure print service listening for 380 HTTPS connections on that port of that host, and the Request-URI for 381 the identified resource is 'path-absolute'. 383 Note: The higher-level "authority" production is not imported from 384 [STD66], because it includes an optional "userinfo" component which 385 cannot be used in 'ipps' URI. 387 Note: The "query" production does not have defined semantics in IPP 388 and was never used in examples in IPP/1.1 Encoding and Transport 389 [RFC2910] or the original IPP URL Scheme [RFC3510]. The "query" is 390 retained here for consistency, but IPP Clients SHOULD avoid its use 391 (because the semantics could only be implementation-defined). 393 Note: Literal IPv4 or IPv6 addresses SHOULD NOT be used in 'ipps' 394 URI, because: 395 a) IP addresses are often changed after network device installation 396 (for example, based on DHCP reassignment after a power cycle); 397 b) IP addresses often don't map simply to security domains; 398 c) IP addresses are difficult to validate with X.509 server 399 certificates (because they do not map to common name or alternate 400 name attributes); and 401 d) IPv6 link local addresses are not "portable" due to link identity 403 If the 'path-absolute' is not present in the URI, it MUST be given as 404 "/" when used as a Request-URI for a resource (see section 5.1.2 of 405 [RFC2616]). 407 An 'ipps' URI is transformed into an 'https' URI by replacing "ipps:" 408 with "https:" and inserting port 631 (if the 'port' is not present in 409 the original 'ipps' URI). 411 See: Section 4.3 (port) of this document. 413 4.3. Associated Port for 'ipps' URI Scheme 415 All 'ipps' URI which do NOT explicitly specify a port MUST be 416 resolved to IANA-assigned well-known port 631, already registered in 417 [PORTREG] for IPP/1.1 Encoding and Transport [RFC2910]. 419 Note: Port 631 is used for both 'ipp' [RFC3510] and 'ipps' URI, both 420 of which refer to an IPP print service or a network resource managed 421 by such a service (for example, a print job), for consistency with 422 recent IETF best practices. IPP Printer implementors can refer to 423 the CUPS [CUPS] source code for an example of incoming connection 424 handling for the dual use of port 631. 426 Note: For compatibility with existing IPP Client and IPP Printer 427 implementations, explicit port 443 (assigned in the 'https' URI 428 scheme [RFC2818]) MUST be accepted in 'ipps' URI and processed 429 normally by IPP Clients and IPP Printers. 431 See: IANA Port Numbers Registry [PORTREG]. 433 See: IPP/1.1 Encoding and Transport [RFC2910]. 435 4.4. Associated MIME Type for 'ipps' URI Scheme 437 All 'ipps' URI MUST be used to specify secure print services which 438 support the "application/ipp" MIME media type as registered in 439 [MIMEREG] for IPP protocol requests and responses. 441 See: IANA MIME Media Types Registry [MIMEREG]. 443 See: IPP/1.1 Encoding and Transport [RFC2910]. 445 4.5. Character Encoding of 'ipps' URI Scheme 447 'ipps' URI MUST use the UTF-8 [STD63] charset for all components. 448 'ipps' URI MUST use [STD66] rules for percent encoding data octets 449 outside the US-ASCII coded character set [ASCII]. 451 4.6. Examples of 'ipps' URI 453 4.6.1. Examples of 'ipps' URI for Printers 455 The following are examples of well-formed 'ipps' URI for IPP Printers 456 (for example, to be used as protocol elements in 'printer-uri' 457 operation attributes of 'Print-Job' request messages): 459 ipps://example.com 460 ipps://example.com/ipp 461 ipps://example.com/ipp/tiger 462 ipps://example.com/ipp/fox 463 ipps://example.com/ipp/tiger/bob 464 ipps://example.com/ipp/tiger/ira 466 Each of the above URI are well-formed URI for IPP Printers and each 467 would reference a logically different IPP Printer, even though some 468 of those IPP Printers might share the same host system. The 'bob' or 469 'ira' last path components might represent two different physical 470 printer devices, while 'tiger' might represent some grouping of IPP 471 Printers (for example, a load-balancing spooler). Or the 'bob' and 472 'ira' last path components might represent separate human recipients 473 on the same physical printer device (for example, a physical printer 474 supporting two job queues). In either case, both 'bob' and 'ira' 475 would behave as different and independent IPP Printers. 477 The following are examples of well-formed 'ipps' URI for IPP Printers 478 with (optional) ports and paths: 480 ipps://example.com 481 ipps://example.com/ipp 482 ipps://example.com:631/ipp 483 ipps://example.com:443/ipp 485 The first and second 'ipps' URI above MUST be resolved to port 631 486 (IANA assigned well-known port for IPP). The second and third 'ipps' 487 URI above are equivalent (see section 4.7 below). The fourth 'ipps' 488 URI above uses the explicit port 443 (see section 4.3 above). 490 See: Section 4.2 (syntax) and section 4.3 (port) of this document. 492 4.6.2. Examples of 'ipps' URI for Jobs 494 The following are examples of well-formed 'ipps' URI for IPP Jobs 495 (for example, to be used as protocol elements in 'job-uri' attributes 496 of 'Print-Job' response messages): 498 ipps://example.com/ipp/123 499 ipps://example.com/ipp/tiger/job123 501 'ipps' URI for Jobs are valid and meaningful only until Job 502 completion and possibly an implementation defined optional period of 503 persistence after Job completion (see IPP Model [RFC2911]). 505 Ambiguously, section 4.3.1 'job-uri' of IPP Model [RFC2911] states 506 that: 508 "the precise format of a Job URI is implementation dependent." 510 Thus, the relationship between the value of the "printer-uri" 511 operation attribute used in a 'Print-Job' request and the value of 512 the "job-uri" attribute returned in the corresponding 'Print-Job' 513 response is entirely implementation dependent. Also, section 4.3.3 514 'job-printer-uri' of IPP Model [RFC2911] states that the 515 'job-printer-uri' attribute of a Job object: 517 "permits a client to identify the Printer object that created this 518 Job object when only the Job object's URI is available to the 519 client." 521 However, the above statement is erroneous, because the transform from 522 a URI for an IPP Job to the corresponding URI for the associated IPP 523 Printer is unspecified in either IPP/1.1 Model and Semantics 524 [RFC2911] or IPP/1.1 Encoding and Transport [RFC2910]. 526 Note: IPP Printers that implement this specification SHOULD only 527 generate 'ipps' URI for Jobs (for example, in the "job-uri" attribute 528 in a 'Print-Job' response) by appending exactly one path component to 529 the corresponding 'ipps' URI for the associated Printer. 531 4.7. Comparisons of 'ipps' URI 533 When comparing two 'ipps' URI to decide if they match or not, an IPP 534 Client MUST use the same rules as those defined for 'http' URI 535 comparisons in [RFC2616] as updated by the 'https' URI scheme 536 [RFC2818], with the sole following exception: 538 - A port that is empty or not given MUST be treated as equivalent to 539 the well-known port for that 'ipps' URI (port 631). 541 See: Section 4.3 (port) in this document. 543 See: Section 3.2.3 'URI Comparison' in [RFC2616]. 545 See: Section 2.4 'URI Format' in [RFC2818]. 547 5. Applicability of this Specification 549 5.1. Applicability to IPP Clients 551 IPP Clients that implement this specification: 553 a) MUST support the IPP over HTTPS transport binding defined in 554 section 3 and the 'ipps' URI scheme defined in section 4; 556 b) MUST support the IPP over HTTP transport binding with TLS defined 557 in section 8.2 'Using IPP with TLS' of IPP/1.1 Encoding and 558 Transport [RFC2910] (for interoperability with existing IPP 559 implementations); 561 c) MUST support the IPP over HTTPS transport binding defined in 562 section 3 of this specification; 564 d) MUST use the required TLS version(s) according to the 565 corresponding IPP versions as defined in section 7 of this 566 specification; 568 e) MUST only send IPP protocol connections to IANA assigned 569 well-known port 631 or to the explicit port specified in a given 570 'ipps' URI; 572 f) MUST only send 'ipps' URI used as protocol elements in outgoing 573 IPP protocol request messages that conform to the ABNF specified 574 in section 4.2 of this document (for example, in the "printer-uri" 575 operation attribute in a 'Print-Job' request); 577 g) MUST only convert 'ipps' URI to their corresponding 'https' URI 578 forms [RFC2818] according to the rules in section 4.2 of this 579 document. 581 See: Section 4.2 (syntax) and section 4.3 (port) of this document. 583 5.2. Applicability to IPP Printers 585 IPP Printers that implement this specification: 587 a) MUST support the IPP over HTTPS transport binding defined in 588 section 3 and the 'ipps' URI scheme defined in section 4; 590 b) MUST support the IPP over HTTP transport binding with TLS defined 591 in section 8.2 'Using IPP with TLS' of IPP/1.1 Encoding and 592 Transport [RFC2910] (for interoperability with existing IPP 593 implementations); 595 c) MUST support the IPP over HTTPS transport binding defined in 596 section 3 of this specification; 598 d) MUST use the required TLS version(s) according to the 599 corresponding IPP versions as defined in section 7 of this 600 specification; 602 e) MUST only generate 'ipps' URI used as protocol elements in 603 outgoing IPP protocol response messages that conform to the ABNF 604 specified in section 4.2 of this document (for example, in the 605 "job-uri" attribute in a 'Print-Job' response); 607 f) SHOULD only accept 'ipps' URI used as protocol elements in 608 incoming IPP protocol request messages that conform to the ABNF 609 specified in section 4.2 of this document (for example, in the 610 "printer-uri" operation attribute in a 'Print-Job' request); 612 g) SHOULD only generate 'ipps' URI for Jobs by appending exactly one 613 path component to the corresponding 'ipps' URI for the associated 614 Printer (for example, in the "job-uri" attribute in a 'Print-Job' 615 response); 617 h) SHOULD NOT generate 'ipps' URI that use literal IPv6 or IPv4 618 addresses (see section 4.2 for rationale). 620 See: Section 4.2 (syntax) and section 4.3 (port) of this document. 622 6. IANA Considerations 624 [RFC Editor: Replace 'xxxx' with assigned RFC number before 625 publication] 627 IANA is asked to register the 'ipps' URI scheme using the following 628 template, which conforms to [BCP35]. 630 URI scheme name: ipps 632 Status: Permanent 634 URI scheme syntax: See section 4.2 of RFC xxxx. 636 URI scheme semantics: The 'ipps' URI scheme is used to designate 637 secure IPP Printer objects (print spoolers, print gateways, print 638 devices, etc.) on Internet hosts accessible using the IPP protocol 639 enhanced to support guaranteed data integrity and negotiable data 640 privacy using TLS as specified in HTTP over TLS [RFC2818]. 642 Encoding Considerations: See section 4.3 of RFC xxxx. 644 Applications/protocols that use this URI scheme name: 646 The 'ipps' URI scheme is intended to be used by applications that 647 need to access secure IPP Printers using the IPP protocol enhanced to 648 support guaranteed data integrity and negotiable data privacy using 649 TLS as specified in HTTP over TLS [RFC2818]. Such applications may 650 include (but are not limited to) IPP-capable web browsers, IPP 651 Clients that wish to print a file, and servers (for example, print 652 spoolers) wishing to forward a print Job for processing. 654 Interoperability Considerations: The widely deployed, open source 655 IPP print service CUPS [CUPS] (on most UNIX, Linux, and Apple OS X 656 systems) has supported 'ipps' URI for several years before the 657 publication of this document. PWG IPP Everywhere [PWG5100.14] (IPP 658 secure, mobile printing extensions) requires the use of 'ipps' URI 659 for mandatory data integrity and negotiable data confidentiality. 661 Security Considerations: See: Section 7 of RFC xxxx. 663 Contact: 665 Ira McDonald 667 Michael Sweet 668 Author/Change controller: 670 IESG 672 References: RFC 2910, RFC 2911, RFC xxxx, and IEEE-ISTO PWG 5100.12. 674 7. Security Considerations 676 7.1. Problem Statement 678 Powerful mobile devices (laptops, tablets, smartphones, etc.) are now 679 commonly used to access enterprise and Cloud print services across 680 the public Internet. This is the primary use case for PWG IPP 681 Everywhere [PWG5100.14], which has already been adopted by operating 682 system and printer vendors and several other public standards bodies. 683 End user and enterprise documents are at greater risk than ever 684 before. This IPP over HTTPS transport binding and 'ipps' URI scheme 685 specification was defined to enable high availability combined with 686 secure operation (mandatory data integrity and negotiable data 687 confidentiality) in this dynamic environment (for example, wireless 688 hotspots in hotels, airports, and restaurants). 690 See: Section 1 Introduction of [PWG5100.14]. 692 See: Section 3.1 Rationale of [PWG5100.14]. 694 7.1.1. Targets of Attacks 696 A network print spooler (logical printer) or print device (physical 697 printer) is potentially subject to attacks, which may target: 699 a) The network (to compromise the routing infrastructure, for 700 example, by creating congestion); 702 b) the Internet Printing Protocol (IPP) [RFC2911] (for example, to 703 compromise the normal behavior of IPP); or 705 c) the print document content itself (for example, to corrupt the 706 documents being transferred). 708 7.1.2. Layers of Attacks 710 Attacks against print services can be launched: 712 a) against the network infrastructure (for example, TCP congestion 713 control). 715 b) against the IPP data flow itself (for example, by sending forged 716 packets or forcing TLS version downgrade); or 718 c) against the IPP operation parameters (for example, by corrupting 719 requested document processing attributes). 721 7.2. Attacks and Defenses 723 This 'ipps' URI Scheme specification adds the following additional 724 security considerations to those described in [RFC2616], [RFC2818], 725 [RFC2910], [RFC2911], [RFC5246], [PWG5100.12], and [STD66]. 727 See: Section 15 'Security Considerations' in [RFC2616]. 729 See: Section 'Security Considerations' in [RFC2818]. 731 See: Section 8 'Security Considerations' in [RFC2910]. 733 See: Section 8 'Security Considerations' in [RFC2911]. 735 See: Appendix D 'Implementation Notes', Appendix E 'Backward 736 Compatibility', and Appendix F 'Security Analysis' of [RFC5246]. 738 See: Section 10 'Security Considerations' in [PWG5100.12]. 740 See: Section 7 'Security Considerations' in [STD66]. 742 7.2.1. Faked 'ipps' URI 744 An 'ipps' URI might be faked to point to a rogue IPP secure print 745 service, thus collecting confidential document contents from IPP 746 Clients. 748 Server authentication mechanisms and security mechanisms specified in 749 IPP/1.1 Encoding and Transport [RFC2910], TLS/1.0 [RFC2246], TLS/1.1 750 [RFC4346], TLS/1.2 [RFC5246], and HTTP over TLS [RFC2818] can be used 751 to address this threat. 753 7.2.2. Unauthorized Access by IPP Client 755 An 'ipps' URI might be used to access an IPP secure print service by 756 an unauthorized IPP Client. 758 Client authentication mechanisms and security mechanisms specified in 759 IPP/1.1 Encoding and Transport [RFC2910], TLS/1.0 [RFC2246], TLS/1.1 760 [RFC4346], TLS/1.2 [RFC5246], and HTTP over TLS [RFC2818] can be used 761 to address this threat. 763 7.2.3. Compromise at Application Layer Gateway 765 An 'ipps' URI might be used to access an IPP secure print service at 766 a print protocol application layer gateway (for example, an IPP to 767 LPD [RFC1179] gateway [RFC2569]), potentially causing silent 768 compromise of IPP security mechanisms. 770 There is no general defense against this threat by an IPP Client. 771 System administrators SHOULD avoid such configurations. 773 7.2.4. No Client Authentication for 'ipps' URI 775 An 'ipps' URI does not define parameters to specify the required IPP 776 Client authentication mechanism (for example, 'certificate' as 777 defined in section 4.4.2 'uri-authentication-supported' of IPP Model 778 [RFC2911]). 780 Either service discovery or directory protocols SHOULD be used first 781 or an IPP Client SHOULD first establish an 'ipp' connection (without 782 TLS or any client authentication) to the target IPP Printer and use a 783 Get-Printer-Attributes query to discover the required IPP Client 784 authentication mechanism(s) associated with a given 'ipps' URI. 786 7.3. TLS Cipher Suite Requirements 788 In accordance with section 10 Security Considerations of 789 [PWG5100.12], IPP Clients and IPP Printers that support this 790 specification and support a given version of TLS MUST support at 791 least the mandatory cipher suite(s) required in each supported TLS 792 version, which are as follows: 794 TLS/1.0 [RFC2246] - TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 795 TLS/1.1 [RFC4346] - TLS_RSA_WITH_3DES_EDE_CBC_SHA 796 TLS/1.2 [RFC5246] - TLS_RSA_WITH_AES_128_CBC_SHA 798 Note: IPP Client and IPP Printer implementors SHOULD consider known 799 attacks against the mandatory cipher suite(s) in each supported TLS 800 version and SHOULD follow best practice advice for alternative cipher 801 suites in later IETF specifications. 803 In accordance with section 10 Security Considerations of 804 [PWG5100.12], this IPP over HTTPS transport binding and 'ipps' URI 805 Scheme specification adds the following TLS version support 806 requirements: 808 a) An IPP Client or IPP Printer that supports this specification and 809 supports IPP/1.1 defined in [RFC2911], MUST support TLS/1.0 810 [RFC2246], MAY support TLS/1.1 [RFC4346], MAY support TLS/1.2 811 [RFC5246], and MAY support future versions of TLS, in every case 812 with at least the mandatory cipher suite(s) required in each 813 supported TLS version. 815 b) An IPP Client or IPP Printer that supports this specification and 816 supports IPP/2.0 defined in [PWG5100.12], MUST support TLS/1.0 817 [RFC2246], SHOULD support TLS/1.1 [RFC4346], MAY support TLS/1.2 818 [RFC5246], and MAY support future versions of TLS, in every case 819 with at least the mandatory cipher suite(s) required in each 820 supported TLS version. 822 c) An IPP Client or IPP Printer that supports this specification and 823 supports IPP/2.1 defined in [PWG5100.12], MUST support TLS/1.0 824 [RFC2246], MUST support TLS/1.1 [RFC4346], SHOULD support TLS/1.2 825 [RFC5246], and MAY support future versions of TLS, in every case 826 with at least the mandatory cipher suite(s) required in each 827 supported TLS version. 829 d) An IPP Client or IPP Printer that supports this specification and 830 supports IPP/2.2 defined in [PWG5100.12], MUST support TLS/1.0 831 [RFC2246], MUST support TLS/1.1 [RFC4346], MUST support TLS/1.2 832 [RFC5246], and MAY support future versions of TLS, in every case 833 with at least the mandatory cipher suite(s) required in each 834 supported TLS version. 836 8. Acknowledgments 838 This document is an individual submission to the IETF by the Internet 839 Printing Protocol Working Group of the IEEE-ISTO Printer Working 840 Group, as part of their PWG IPP Everywhere [PWG5100.14] project for 841 secure mobile printing with vendor-neutral Client software. 843 This document defines an alternate IPP transport binding to that 844 defined in the original IPP URL Scheme [RFC3510], but this document 845 does not update or obsolete [RFC3510]. 847 Thanks to Claudio Allochio, Tom Hastings (retired from Xerox), Bjoern 848 Hoerhmann, S. Mooneswamy, Tom Petch, Jerry Thrasher (Lexmark), Mykyta 849 Yevstifeyev, Pete Zehler (Xerox), and the members of the IEEE-ISTO 850 PWG IPP WG. 852 9. References 854 9.1. Normative References 856 [ASCII] "American National Standards Institute, Coded Character 857 Set -- 7-bit American Standard Code for Information 858 Interchange", ANSI X3.4, 1986. 860 [PWG5100.12] Bergman, R., Lewis, H., McDonald, I., and M. Sweet, 861 "Internet Printing Protocol Version 2.0 Second Edition 862 (IPP/2.0 SE)", PWG 5100.12, February 2011. 863 865 [PWG5100.14] McDonald, I. and M. Sweet, "PWG IPP Everywhere", PWG 866 5100.14, January 2013. 867 869 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 870 Requirement Levels, BCP 14, RFC 2119, March 1997. 872 [RFC2246] Dierks, T., and C. Allen, "The TLS Protocol Version 1.0", 873 RFC 2246, January 1999. 875 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 876 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 877 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 879 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 881 [RFC2910] Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and 882 J. Wenn, "Internet Printing Protocol/1.1: Encoding and 883 Transport", RFC 2910, September 2000. 885 [RFC2911] Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S., 886 and P. Powell, "Internet Printing Protocol/1.1: Model and 887 Semantics", RFC 2911, September 2000. 889 [RFC4346] Dierks, T., and E. Rescorla, "The Transport Layer Security 890 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 892 [RFC5246] Dierks, T., and E. Rescorla, "The Transport Layer Security 893 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 895 [STD7] Postel, J., "Transmission Control Protocol", STD 7, RFC 896 793, September 1981. 898 [STD63] Yergeau, F., "UTF-8, a transformation format of ISO 899 10646", STD 63, RFC 3629, November 2003. 901 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, Uniform 902 Resource Identifiers (URI) Generic Syntax, STD 66, RFC 903 3986, January 2005. 905 [STD68] Crocker, D., Ed., and P. Overell, "Augmented BNF for 906 Syntax Specifications: ABNF", STD 68, RFC 5234, January 907 2008. 909 9.2. Informative References 911 [BCP35] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 912 Registration Procedures for New URI Schemes", BCP 35, RFC 913 4395, February 2006. 915 [CUPS] Apple, "CUPS standards-based, open source printing system 916 for OS X and other UNIX-like operating systems" 917 919 [MIMEREG] Internet Assigned Numbers Authority (IANA) Registry "MIME 920 Media Types" 921 923 [PORTREG] Internet Assigned Numbers Authority (IANA) Registry "Port 924 Numbers" 925 927 [RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, 928 August 1990. 930 [RFC2569] Herriot, R., Ed., Hastings, T., Jacobs, N., and J. 931 Martin, "Mapping between LPD and IPP Protocols", RFC 2569, 932 April 1999. 934 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 935 HTTP/1.1", RFC 2817, May 2000. 937 [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. 938 Holst, "Internet Printing Protocol/1.1: Implementor's 939 Guide", RFC 3196, November 2001. 941 [RFC3510] Herriot, R. and I. McDonald, "Internet Printing 942 Protocol/1.1: IPP URL Scheme", RFC 3510, April 2003. 944 10. Appendix A - Summary of IPP URL Scheme (Informative) 946 This section is an informative summary of the original IPP URL Scheme 947 [RFC3510] and the associated IPP over HTTP transport binding defined 948 in [RFC2910]. 950 When using an 'ipp' URI [RFC3510], an IPP Client establishes an IPP 951 application layer connection according to the following sequence: 953 1) The IPP Client selects an 'ipp' URI value from 954 "printer-uri-supported" Printer attribute [RFC2911], a directory 955 entry, discovery info, a web page, etc.; 957 2) The IPP Client converts the 'ipp' URI to an 'http' URI (replacing 958 'ipp' with 'http' and inserting the port number from the URI or 959 port 631 if the URI doesn't include a port number); 961 3) The IPP Client establishes a TCP [STD7] reliable transport layer 962 connection to the target endpoint - see section 3.4 'Establishing 963 a connection' in TCP [STD7]; 965 4) The IPP Client establishes an HTTP [RFC2616] session layer 966 connection to the target endpoint - see section 8 'Connections' in 967 HTTP/1.1 [RFC2616]; 969 5) Optionally, either the IPP Client upgrades to TLS within HTTP/1.1 970 per section 3 'Client Requested Upgrade to HTTP over TLS' of 971 [RFC2817] or the IPP Printer upgrades to TLS within HTTP/1.1 per 972 section 4 'Server Requested Upgrade to HTTP over TLS' of 973 [RFC2817], in order to establish a TLS secure transport sublayer 974 within the original TCP/HTTP connection - per the 975 "uri-security-supported" (section 4.4.3 in [RFC2911]) Printer 976 attribute value parallel to the "printer-uri-supported" (see 977 section 4.4.1 in [RFC2911]) value that matches this connection; 978 and 980 6) The IPP Client sends IPP application layer requests to and 981 receives responses from the IPP Printer over the HTTP [RFC2616] 982 session layer connection using the POST method defined in section 983 9.5 of HTTP/1.1 [RFC2616], as specified in section 4 'Encoding of 984 Transport Layer' in IPP/1.1 Encoding and Transport [RFC2910]. 986 See: Section 8 'Security Considerations' in [RFC2911]. 988 See: Section 8 'Security Considerations' in [RFC2817]. 990 11. Appendix X - Change History 992 [RFC Editor: Delete this section before publication as an RFC] 994 20 April 2014 - draft-mcdonald-ipps-uri-scheme-12.txt 995 Editorial - Revised section 4.3 Associated Port for 'ipps' URI 996 Scheme, to add informative reference to CUPS, per IEEE-ISTO PWG IPP 997 WG review. 999 Editorial - Revised section 4.6.1 Examples of 'ipps' URI for 1000 Printers, to change "third" to "fourth" for the port 443 example, per 1001 IEEE-ISTO PWG IPP WG review. 1002 Editorial - Revised section 6 IANA Considerations, to add informative 1003 reference to CUPS, per IEEE-ISTO PWG IPP WG review. 1004 Editorial - Revised section 9.2 Informative References, to add 1005 informative reference to CUPS, per IEEE-ISTO PWG IPP WG review. 1007 7 April 2014 - draft-mcdonald-ipps-uri-scheme-11.txt 1008 Global - revised all references to section 4.2 and section 4.3, to 1009 add parenthetic (syntax) and (port) respectively, per IEEE-ISTO PWG 1010 IPP WG review. 1011 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, to 1012 correct two typos (extra words) in section 4.3 references, per 1013 IEEE-ISTO PWG IPP WG review. 1014 Editorial - Revised section 4.3 Associated Port for 'ipps' URI 1015 Scheme, to add note about compatibility for IPP Clients and IPP 1016 Printers that MUST accept explicit port 443 (assigned in 'https' URI 1017 scheme [RFC2818]) and process normally, per IEEE-ISTO PWG IPP WG 1018 review. 1019 Editorial - Revised section 4.6.1 Examples of 'ipps' URI for 1020 Printers, to add example of explicit port 443, per IEEE-ISTO PWG IPP 1021 WG review. 1023 30 March 2014 - draft-mcdonald-ipps-uri-scheme-10.txt 1024 Global - Updated references, per IEEE-ISTO PWG IPP WG review. 1025 Global - Changed "e.g." to "for example", for readability. 1026 Editorial - Revised section Copyright Notice, to correct year. 1027 Editorial - Revised section 3 IPP over HTTPS Transport Binding, item 1028 2), to clarify that port 631 is ONLY inserted in the derived 'https' 1029 URI when an explicit port is NOT specified in the original 'ipps' 1030 URI, per Smith Kennedy and IEEE-ISTO PWG IPP WG review. 1031 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, note 1032 about URI lengths greater than 255 octets, to change 'ought to' to 1033 'SHOULD', per Smith Kennedy and IEEE-ISTO PWG IPP WG review. 1034 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, to add 1035 reference to section 4.3 for use of port 631, per Smith Kennedy and 1036 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. 1088 Editorial - Revised section 1.1 Structure of this Document to align 1089 with changes below, per Tom Petch. 1090 Editorial - Revised section 2 Conventions Used in this Document to 1091 add section 2.1 Printing Terminology and to remove redundant "In this 1092 document" and clarify definitions, per Tom Petch. 1093 Editorial - Moved former Appendix B - Abbreviations Used in this 1094 Document to become section 2.2 Abbreviations, per Tom Petch. 1095 Technical - Revised section 3 IPP over HTTPS Transport Binding, 1096 section 5 Applicability of this Specification, and section 7 Security 1097 Considerations to address specific TLS/1.0 [RFC2246], TLS/1.1 1098 [RFC4346], and TLS/1.2 [RFC5246] requirements, per Tom Petch. 1099 Editorial - Moved former section 3.1 IPP over HTTP Transport Binding 1100 to become Appendix A - Summary of IPP URL Scheme (Informative), per 1101 Tom Petch. 1102 Technical - Revised section 4.2 Syntax of 'ipps' URI Scheme to add 1103 note about the retention of the (unused) "query" production for 1104 consistency with IPP/1.1 Encoding and Transport [RFC2910] and the 1105 original IPP URL Scheme [RFC3510], but warn that it has no defined 1106 semantics in IPP and therefore its use is unsafe for IPP Clients, per 1107 Tom Petch. 1108 Technical - Revised section 7 Security Considerations to add section 1109 8.1 Problem Statement, section 8.2 Attacks, and section 8.3 TLS 1110 Security Considerations, per Tom Petch. 1111 Editorial - Moved former section Appendix A - Acknowledgments to 1112 become section 8 Acknowledgements (in body of document) and updated 1113 to reflect recent comments on this document, per Tom Petch. 1114 Technical - Revised section 9.1 Normative References to add TLS/1.0 1115 [RFC2246] and TLS/1.1 [RFC4346], per Tom Petch. 1117 19 September 2013 - draft-mcdonald-ipps-uri-scheme-08.txt 1118 Global - Updated references, per IPP WG review. 1120 12 May 2013 - draft-mcdonald-ipps-uri-scheme-07.txt 1121 Editorial - Revised section 1 (introduction) to add 'Rationale for 1122 this document', per Smith Kennedy. 1123 Editorial - Global - Changed 'Conformance Requirements' to 1124 'Applicability', per Barry Leiba. 1125 Editorial - Global - Changed '[PWG5100.EW]' to '[PWG5100.14]', 1126 corrected date and URI, and moved section 8.1 (normative references), 1127 per IPP WG review. 1129 10 November 2012 - draft-mcdonald-ipps-uri-scheme-06.txt 1130 Editorial - Global - Fixed typos and indentation, per IPP WG review. 1131 Editorial - Global - changed 'generic drivers' to 'vendor-neutral 1132 Client software', per IPP WG review. 1133 Editorial - Revised section 8.2 (informative references, to correct 1134 title of "PWG IPP Everywhere" (i.e., delete version number), per IPP 1135 WG review. 1137 14 May 2012 - draft-mcdonald-ipps-uri-scheme-05.txt 1138 Editorial - Global - Fixed typos and indentation, per IPP WG review. 1139 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to 1140 insert missing "to" in "connection to the target endpoint", per IPP 1141 WG review. 1142 Editorial - Revised section 4.2 (syntax), to correct indentation of 1143 first "Note:", per IPP WG review. 1144 Editorial - Revised sections 5.1 and 5.2 (client/printer conformance) 1145 and section 7 (security considerations) to delete the out-of-scope 1146 normative references to [RFC2817], per IPP WG review. 1148 22 November 2011 - draft-mcdonald-ipps-uri-scheme-04.txt 1149 Editorial - Global - Fixed typos and indentation, per IPP WG review. 1150 Editorial - Revised Introduction and Acknowledgments to say 'project 1151 for mobile, ubiquitous printing with generic drivers', per IPP WG 1152 review. 1153 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to add 1154 references to HTTP POST and section 4 of RFC 2910, per IPP WG review. 1155 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to add 1156 section references to all well-known standards (connection setup, 1157 etc.), per IPP WG review. 1158 Editorial - Revised section 4.2 (syntax) to move note from from 1159 section 4.6 (examples) and explain why literal IP addresses SHOULD 1160 NOT be used in 'ipps' URI, per IPP WG review. 1161 Editorial - Revised sections 4.6.1 and 4.6.2 (examples) to replace 1162 'abc.com' w/ 'example.com' (per IETF) and replace '/printer' path 1163 element w/ '/ipp' (better practice), per IPP WG review. 1164 Editorial - Revised section 5.2 (Printer conformance) to fold former 1165 (c) and (d) into a single requirement for standard port 631 and 1166 reordered other requirements to group MUSTs before SHOULDs, per IPP 1167 WG review. 1168 Editorial - Revised section 5.2 (Printer conformance) to add backward 1169 reference to section 4.2 for rationale for not using IP literal 1170 addresses, per IPP WG review. 1171 Editorial - Revised section 6 (IANA) to explicitly state that 'ipps' 1172 uses secure communications using HTTP over TLS, per IPP WG review. 1173 Editorial - Revised section 7 (Security) to cleanup numerous loose 1174 ends, per IPP WG review. 1175 Editorial - Revised section 8 (References) to cleanup typos and 1176 links, per IPP WG review. 1177 Editorial - Revised section 1 (introduction), section 8.2 1178 (informative references, and section 9 (appendix A) to change 1179 "[IPPEVE]" to "[PWG5100.EW]", per IPP WG review. 1181 26 August 2011 - draft-mcdonald-ipps-uri-scheme-03.txt 1182 Editorial - Revised Abstract and Introduction to state published by 1183 the IETF on behalf of IEEE-ISTO PWG (to avoid status ambiguity), per 1184 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. 1189 Technical - Revised section 1, section 2, section 3.2, section 4.1, 1190 and section 7, to reference IPP Version 2.0 Second Edition (PWG 1191 5100.12), per Mykyta Yevstifeyev. 1192 Editorial - Revised section 3.1, to fix broken STD7 reference, per 1193 Mykyta Yevstifeyev. 1194 Editorial - Revised section 6, to add BCP35 reference for template 1195 (regression loss when the template was moved up from former 1196 appendix), per Mykyta Yevstifeyev. 1197 Editorial - Revised section 8.1 to add PWG 5100.12 (normative), 1198 Editorial - Revised section 8.2 to add PWG IPP Everywhere 1199 (informative) and RFC 1179 (informative), per Mykyta Yevstifeyev. 1200 Editorial - Revised appendix B to add references for more reading, 1201 per Mykyta Yevstifeyev. 1203 28 February 2011 - draft-mcdonald-ipps-uri-scheme-02.txt 1204 Editorial - Revised document title to emphasize IPP over HTTPS 1205 Transport Binding (reason for IETF standards-track status). 1206 Editorial - Replaced "IPP URI" with "'ipp' URI", "IPPS URI" with 1207 "'ipps' URI", "HTTP URI" with "'http' URI", and "HTTPS URI" with 1208 "'https' URI" throughout this document for conformance to section 3.1 1209 of [STD66], per Mykyta Yevstifeyev. 1210 Editorial - Revised and simplified Abstract, per Mykyta Yevstifeyev. 1211 Editorial - Revised and simplified section 1 'Introduction', per 1212 Mykyta Yevstifeyev. 1213 Editorial - Renamed section 2 from 'Conformance Terminology' to 1214 'Conventions Used in this Document', per Mykyta Yevstifeyev. 1215 Editorial - Moved former section 3.1 'IPP Model Terminology 1216 (Normative)' content into section 2 'Conventions Used in this 1217 Document' for readability, per Mykyta Yevstifeyev. 1218 Editorial - Reordered subsections and reversed word order in all 1219 subsection titles in section 4 'The 'ipps' URI Scheme' for 1220 readability, per Mykyta Yevstifeyev. 1221 Editorial - Added note to section 4.2 'Syntax of 'ipps' URI Scheme' 1222 to explain why 'authority' production is NOT imported from [STD66], 1223 because it includes an optional 'userinfo' component which cannot be 1224 used in 'ipps' URI values. 1225 Editorial - Deleted note describing empty 'host' component from 1226 section 4.2 'Syntax of 'ipps' URI Scheme', because 'host' component 1227 is mandatory in [STD66]. 1228 Editorial - Deleted 'Internationalization Considerations' section 1229 which was redundant with section 4.3 'Character Encoding of 'ipps' 1230 URI Scheme', per Mykyta Yevstifeyev. 1231 Editorial - Revised all references to follow current RFC Editor 1232 style, per Mykyta Yevstifeyev. 1233 Editorial - Moved former 'Appendix A - Registration of IPPS URI 1234 Scheme' content inline into section 6 'IANA Considerations', per 1235 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. 1241 Editorial - Moved section 'Authors' Addresses' to end of document, 1242 per Mykyta Yevstifeyev. 1244 1 December 2010 - draft-mcdonald-ipps-uri-scheme-01.txt 1245 - Technical - added UTF-8 [STD63] as required charset for all IPPS 1246 URI in section 4.4 and section 7, per Bjoern Hoehrmann. 1247 - Technical - corrected percent encoding for data octets outside the 1248 US-ASCII range in section 4.4 and section 7, per Bjoern Hoehrmann. 1249 - Editorial - global - changed "[RFC4395]" to "[BCP35]", changed 1250 "[RFC3629]" to "[STD63]", changed "[RFC3986]" to "[STD66]", and 1251 changed "[RFC5234]" to "[STD68]", per Bjoern Hoehrmann. 1252 - Editorial - restored trailing "]]" in ABNF syntax in section 4.5, 1253 per Bjoern Hoehrmann. 1254 - Editorial - changed "Author/Change controller" to "IESG" in section 1255 12 Appendix A registration template, as required by section 5.3 of 1256 [BCP35], per Bjoern Hoehrmann. 1258 10 October 2010 - draft-mcdonald-ipps-uri-scheme-00.txt 1259 - Editorial - complete rewrite of RFC 3510 for new transport binding 1260 - Editorial - moved Abstract to beginning of first page, per ID-Nits 1261 - Editorial - fixed copyright, boilerplate, and typos, per ID-Nits 1262 - Editorial - added references to RFCs 2119 and 3510, per ID-Nits 1263 - Editorial - deleted obsolete references to RFCs 2246 and 4346, per 1264 ID-Nits 1265 - Technical - changed Intended Status to Standards Track to reflect 1266 the new normative IPPS URI scheme and transport binding 1267 - Technical - added section 3.2 IPP over HTTP Transport Binding 1268 (informative) 1269 - Technical - added section 3.3 IPP over HTTPS Transport Binding 1270 (normative) 1271 - Technical - updated section 5 Conformance Requirements to require 1272 HTTP Upgrade (RFC 2817) support (for interoperability with existing 1273 IPP implementations), per discussion on IPP WG mailing list 1274 - Editorial - updated Appendix A w/ registration template from RFC 1275 4395 1277 12. Authors' Addresses 1279 Ira McDonald 1280 High North Inc 1281 221 Ridge Ave 1282 Grand Marais, MI 49839 1284 Phone: +1 906-494-2434 1285 Email: blueroofmusic@gmail.com 1287 Michael Sweet 1288 Apple Inc 1289 10431 N De Anza Blvd, M/S 38-4LPT 1290 Cupertino, CA 95014 1292 Phone: +1 408-974-8798 1293 Email: msweet@apple.com 1295 Usage questions and comments on this 'ipps' URI Scheme can be sent 1296 directly to the editors at their above addresses and also to the PWG 1297 IPP WG mailing list. Instructions for subscribing to the PWG IPP WG 1298 mailing list can be found at: 1300 PWG IPP WG Web Page: http://www.pwg.org/ipp/ 1301 PWG IPP WG Mailing List: ipp@pwg.org 1302 PWG IPP WG Subscription: http://www.pwg.org/mailhelp.html 1304 Implementers of this specification are encouraged to join the PWG IPP 1305 WG Mailing List in order to participate in any discussions of 1306 clarification issues and comments. Note that this IEEE-ISTO PWG 1307 mailing list rejects mail from non-subscribers (in order to reduce 1308 spam).