idnits 2.17.1 draft-mcdonald-ipps-uri-scheme-17.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (28 November 2014) is 3436 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: 'MEDIAREG' is mentioned on line 829, but not defined == Missing Reference: 'RFC2818' is mentioned on line 862, but not defined ** Obsolete undefined reference: RFC 2818 (Obsoleted by RFC 9110) == Missing Reference: 'RFC2616' is mentioned on line 955, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Missing Reference: 'RFC2246' is mentioned on line 1082, but not defined ** Obsolete undefined reference: RFC 2246 (Obsoleted by RFC 4346) == Missing Reference: 'RFC4346' is mentioned on line 1082, but not defined ** Obsolete undefined reference: RFC 4346 (Obsoleted by RFC 5246) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' ** 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 7233 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7235 (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) -- Obsolete informational reference (is this intentional?): RFC 2566 (Obsoleted by RFC 2911) Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 5 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 May 2015 28 November 2014 8 IPP over HTTPS Transport Binding and 'ipps' URI Scheme 9 draft-mcdonald-ipps-uri-scheme-17.txt 11 Abstract 13 This document 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 managed by such a service. 18 This document defines an alternate IPP transport binding to that 19 defined in the original IPP URL Scheme (RFC 3510), but this document 20 does not update or obsolete RFC 3510. 22 This document updates RFC 2910 and RFC 2911. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. Internet-Drafts are working 28 documents of the Internet Engineering Task Force (IETF), its areas, 29 and its working groups. Note that other groups may also distribute 30 working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on 28 May 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction ............................................... 4 75 1.1. Structure of this Document ............................. 4 76 1.2. Rationale for this Document ............................ 5 77 2. Conventions Used in this Document .......................... 5 78 2.1. Printing Terminology ................................... 5 79 3. IPP over HTTPS Transport Binding ........................... 6 80 4. Definition of 'ipps' URI Scheme ............................ 7 81 4.1. Applicability of 'ipps' URI Scheme ..................... 7 82 4.2. Syntax of 'ipps' URI Scheme ............................ 7 83 4.3. Associated Port for 'ipps' URI Scheme .................. 9 84 4.4. Character Encoding of 'ipps' URI Scheme ................ 9 85 4.5. Examples of 'ipps' URI ................................. 9 86 4.6. Comparisons of 'ipps' URI .............................. 10 87 5. IANA Considerations ........................................ 11 88 6. Security Considerations .................................... 12 89 6.1. Problem Statement ...................................... 12 90 6.1.1. Targets of Attacks ................................. 12 91 6.1.2. Layers of Attacks .................................. 12 92 6.2. Attacks and Defenses ................................... 13 93 6.2.1. Faked 'ipps' URI ................................... 13 94 6.2.2. Unauthorized Access by IPP Client .................. 13 95 6.2.3. Compromise at Application Layer Gateway ............ 14 96 6.2.4. No Client Authentication for 'ipps' URI ............ 14 97 6.3. TLS Version Requirements ............................... 14 98 7. Acknowledgments ............................................ 14 99 8. References ................................................. 15 100 8.1. Normative References ................................... 15 101 8.2. Informative References ................................. 16 102 9. Appendix A - Abbreviations ................................. 17 103 10. Appendix X - Change History ............................... 18 104 11. Authors' Addresses ........................................ 27 105 1. Introduction 107 This document defines the Internet Printing Protocol (IPP) over HTTPS 108 transport binding and the corresponding 'ipps' URI scheme, that is 109 used to designate the access to the network location of a secure IPP 110 print service or a network resource managed by such a service. 112 This document has been submitted to the IETF by the Internet Printing 113 Protocol Working Group of the IEEE-ISTO Printer Working Group, as 114 part of their PWG IPP Everywhere (PWG 5100.14) project for secure 115 mobile printing with vendor-neutral Client software. 117 This document defines an alternate IPP transport binding to that 118 defined in the original IPP URL Scheme [RFC3510], but this document 119 does not update or obsolete [RFC3510]. 121 This document updates [RFC2910] and [RFC2911]. 123 This document updates: 124 a) IPP/1.1 Encoding and Transport [RFC2910], by extending section 4 125 'Encoding of the Transport Layer', section 5 'IPP URL Scheme', and 126 section 8.2 'Using IPP with TLS'; 127 b) IPP/1.1 Model and Semantics [RFC2911], by extending section 4.1.6 128 'uriScheme' and section 4.4.1 'printer-uri-supported'; and 129 c) IEEE-ISTO PWG IPP Version 2.0 Second Edition [PWG5100.12], by 130 extending section 4 'IPP Standards' and section 10 'Security 131 Considerations'. 133 The following versions of IPP are currently defined: 134 a) 1.0 in [RFC2566] (obsolete); 135 b) 1.1 in [RFC2911]; 136 c) 2.0 in [PWG5100.12]; 137 d) 2.1 in [PWG5100.12]; and 138 e) 2.2 in [PWG5100.12]. 140 Overview information about IPP is available in section 1 of RFC 2911 141 [RFC2911], section 1 of RFC 3196 [RFC3196], and section 1 of PWG IPP 142 Version 2.0 Second Edition [PWG5100.12]. 144 1.1. Structure of this Document 146 This document contains the following sections: 148 Section 2 defines the conventions and terms used throughout the 149 document. 151 Section 3 defines the IPP over HTTPS transport binding. 153 Section 4 defines the 'ipps' URI scheme. 155 Sections 5 and 6 contain IANA and security considerations, 156 respectively. 158 Section 7 contains acknowledgments. 160 Section 8 contains references. 162 1.2. Rationale for this Document 164 The 'ipps' URI scheme was defined for the following reasons: 166 1) Some existing IPP Client and IPP Printer implementations of 167 Upgrading to TLS Within HTTP/1.1 [RFC2817] are flawed and 168 unreliable. 170 2) Some existing IPP Client and IPP Printer implementations of HTTP 171 Upgrade [RFC2817] do not perform upgrade at the beginning of every 172 HTTP [RFC7230] connection, but instead only shift to secure IPP 173 for selected IPP operations (inherently dangerous behavior on the 174 same underlying TCP [STD7] connection). 176 3) IPP Printer server-mandated HTTP Upgrade [RFC2817] can still lead 177 to exposure of IPP Client data if the Expect request header is not 178 used - basically the IPP Client can send its whole Print-Job 179 request before the IPP Printer has a chance to respond and say, 180 "Wait! You need to encrypt first!" 182 2. Conventions Used in this Document 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in RFC 2119 [RFC2119]. 188 2.1. Printing Terminology 190 The reader of this document needs to be familiar with the printing 191 terms defined in IPP/1.1 Model and Semantics [RFC2911] as well as the 192 following: 194 IPP Client: The software (on some hardware platform) that submits 195 IPP Job creation and IPP Printer and IPP Job management operations 196 via the IPP over HTTP transport binding defined in the IPP/1.1 197 Encoding and Transport [RFC2910] and/or the IPP over HTTPS transport 198 binding defined in section 3 of this specification to a downstream 199 IPP Printer (print spooler, print gateway, or physical printing 200 device). 202 IPP Job: The set of attributes and documents for one print job 203 instantiated in an IPP Printer. 205 IPP Job object: Synonym for IPP Job. 207 IPP Printer: The software (on some hardware platform) that receives 208 IPP Job creation and IPP Printer and IPP Job management operations 209 via the IPP over HTTP transport binding defined in the IPP/1.1 210 Encoding and Transport [RFC2910] and/or the IPP over HTTPS transport 211 binding defined in section 3 of this specification from an upstream 212 IPP Client or IPP Printer. 214 IPP Printer object: Synonym for IPP Printer. 216 'ipps' URI: A URI using the 'ipps' URI scheme defined in section 4 217 of this specification. 219 3. IPP over HTTPS Transport Binding 221 This document defines the following alternate IPP over HTTPS 222 transport binding for the abstract protocol defined in IPP/1.1 Model 223 and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version 2.0 Second 224 Edition [PWG5100.12]. 226 When using an 'ipps' URI, an IPP Client MUST establish an IPP 227 application layer connection according to the following sequence: 229 1) The IPP Client selects an 'ipps' URI value from 230 "printer-uri-supported" Printer attribute [RFC2911], a directory 231 entry, discovery info, a web page, etc.; 233 2) The IPP Client converts the 'ipps' URI to an 'https' URI [RFC7230] 234 (replacing 'ipps' with 'https' and inserting the port number from 235 the URI or port 631 if the URI doesn't include an explicit port 236 number); 238 3) The IPP Client establishes an HTTPS [RFC7230] secure session layer 239 connection to the target endpoint; and 241 4) The IPP Client sends requests to and receives responses from the 242 target IPP application layer resource over the HTTPS [RFC7230] 243 secure session layer connection using the POST method defined in 244 [RFC7231]. 246 4. Definition of 'ipps' URI Scheme 248 4.1. Applicability of 'ipps' URI Scheme 250 Per PWG IPP Everywhere [PWG5100.14], in IPP protocol exchanges, the 251 'ipps' URI scheme MUST only be used: 252 a) To specify absolute URI for IPP secure print services and their 253 their associated network resources; 254 b) To specify the use of the abstract protocol defined in IPP/1.1 255 Model and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version 2.0 256 Second Edition [PWG5100.12]; and 257 c) To specify the use of the transport binding defined in this 258 document. 260 The 'ipps' URI scheme allows an IPP Client to choose an appropriate 261 IPP secure print service (for example, from a directory). The IPP 262 Client can establish an HTTPS connection to the specified IPP secure 263 print service. The IPP Client can send IPP protocol requests (for 264 example, 'Print-Job' requests) and receive IPP protocol responses 265 over that HTTPS connection. 267 See: Section 4.2 (syntax) of this document. 269 See: Section 4.4.1 'printer-uri-supported' in IPP/1.1 Model and 270 Semantics [RFC2911]. 272 See: Section 5 'IPP URL Scheme' in IPP/1.1 Encoding and Transport 273 [RFC2910]. 275 See: Section 4 'IPP Standards' of IEEE-ISTO PWG IPP Version 2.0 276 Second Edition [PWG5100.12]. 278 4.2. Syntax of 'ipps' URI Scheme 280 The abstract protocol defined in IPP/1.1 Model and Semantics 281 [RFC2911] places a limit of 1023 octets (NOT characters) on the 282 length of a URI. 284 See: URI Generic Syntax [STD66]. 286 Per PWG IPP Everywhere [PWG5100.14], for compatibility with existing 287 IPP implementations, IPP Printers SHOULD NOT generate (or allow 288 administrators to configure) URI lengths above 255 octets, because 289 many older IPP Client implementations do not properly support these 290 lengths. 292 Per PWG IPP Everywhere [PWG5100.14], in IPP protocol exchanges, 293 'ipps' URI MUST be represented in absolute form. Absolute URI always 294 begin with a scheme name followed by a colon. For definitive 295 information on URI syntax and semantics, see "Uniform Resource 296 Identifiers (URI) Generic Syntax and Semantics" [STD66]. This 297 specification adopts the definitions of "host", "port", and "query" 298 from [STD66]. This specification adopts the definition of 299 "absolute-path" from [RFC7230]. 301 The 'ipps' URI scheme syntax in ABNF [STD68] is defined as follows: 303 ipps-uri = 304 "ipps:" "//" host [ ":" port ] [ absolute-path [ "?" query ]] 306 Per IPP/1.1 Encoding and Transport [RFC2910], if the port is empty or 307 not given, then port 631 MUST be used. 309 See: Section 4.3 (port) in this document. 311 The semantics are that the identified resource (see [RFC7230]) is 312 located at the IPP secure print service listening for HTTPS 313 connections on that port of that host; and the Request-URI for the 314 identified resource is 'absolute-path'. 316 Note: The higher-level "authority" production is not imported from 317 [STD66], because it includes an optional "userinfo" component which 318 cannot be used in 'ipps' URI. 320 Note: The "query" production does not have defined semantics in IPP 321 and was never used in examples in IPP/1.1 Encoding and Transport 322 [RFC2910] or the original IPP URL Scheme [RFC3510]. The "query" is 323 retained here for consistency, but IPP Clients SHOULD avoid its use 324 (because the semantics would be implementation-defined). 326 Note: Per PWG IPP Everywhere [PWG5100.14], literal IPv4 or IPv6 327 addresses SHOULD NOT be used in 'ipps' URI, because: 328 a) IP addresses are often changed after network device installation 329 (for example, based on DHCP reassignment after a power cycle); 330 b) IP addresses often don't map simply to security domains; 331 c) IP addresses are difficult to validate with X.509 server 332 certificates (because they do not map to common name or alternate 333 name attributes); and 334 d) IP link local addresses are not "portable" due to link identity 336 Per IPP/1.1 Encoding and Transport [RFC2910], if the 'absolute-path' 337 is not present in an IPP URI, it MUST be given as "/" when used as a 338 Request-URI for a resource (see [RFC7230]). An 'ipps' URI is 339 transformed into an 'https' URI by replacing "ipps:" with "https:" 340 and inserting port 631 (if an explicit 'port' is not present in the 341 original 'ipps' URI). 343 See: Section 4.3 (port) in this document. 345 4.3. Associated Port for 'ipps' URI Scheme 347 Per IPP/1.1 Encoding and Transport [RFC2910], all 'ipps' URI which do 348 NOT explicitly specify a port MUST be resolved to IANA-assigned 349 well-known port 631, already registered in [PORTREG] by [RFC2910]. 351 Note: Per direction of the IESG, as described in [RFC2910], port 631 352 is used for all IPP protocol connections (with or without TLS 353 [RFC5246]). Port 631 is therefore used for both 'ipp' [RFC3510] and 354 'ipps' URI, which both refer to an IPP Printer or a network resource 355 managed by an IPP Printer. IPP Printer implementors can refer to the 356 CUPS [CUPS] source code for an example of incoming connection 357 handling for the dual use of port 631. 359 Per PWG IPP Everywhere [PWG5100.14], for compatibility with existing 360 IPP implementations, IPP Clients and IPP Printers MUST accept 361 explicit port 443 (assigned in the 'https' URI scheme [RFC7230]) in 362 'ipps' URI values. 364 See: IANA Port Numbers Registry [PORTREG]. 366 See: IPP/1.1 Encoding and Transport [RFC2910]. 368 4.4. Character Encoding of 'ipps' URI Scheme 370 Per PWG IPP Everywhere [PWG5100.14], 'ipps' URI MUST: 371 a) Use the UTF-8 [STD63] charset for all components; and 372 b) Use [STD66] rules for percent encoding data octets outside the 373 US-ASCII coded character set [ASCII]. 375 4.5. Examples of 'ipps' URI 377 The following are examples of well-formed 'ipps' URI for IPP Printers 378 (for example, to be used as protocol elements in 'printer-uri' 379 operation attributes of 'Print-Job' request messages): 381 ipps://example.com/ 382 ipps://example.com/ipp/ 383 ipps://example.com/ipp/tiger/ 384 ipps://example.com/ipp/fox/ 385 ipps://example.com/ipp/tiger/bob/ 386 ipps://example.com/ipp/tiger/ira/ 388 Each of the above URI is a well-formed URI for an IPP Printer and 389 each would reference a logically different IPP Printer, even though 390 some of those IPP Printers might share the same host system. The 391 'bob' or 'ira' last path components might represent two different 392 physical printer devices, while 'tiger' might represent some grouping 393 of IPP Printers (for example, a load-balancing spooler). Or the 394 'bob' and 'ira' last path components might represent separate human 395 recipients on the same physical printer device (for example, a 396 physical printer supporting two job queues). In either case, both 397 'bob' and 'ira' would behave as different and independent IPP 398 Printers. 400 The following are examples of well-formed 'ipps' URI for IPP Printers 401 with (optional) ports and paths: 403 ipps://example.com/ 404 ipps://example.com/ipp/ 405 ipps://example.com:631/ipp/ 406 ipps://example.com:443/ipp/ 408 The first and second 'ipps' URI above will be resolved to port 631 409 (IANA assigned well-known port for IPP). The second and third 'ipps' 410 URI above are equivalent (see section 4.6). The fourth 'ipps' URI 411 above uses the explicit port 443 (see section 4.3). 413 See: Section 4.2 (syntax) and section 4.3 (port) in this document. 415 4.6. Comparisons of 'ipps' URI 417 Per PWG IPP Everywhere [PWG5100.14], when comparing two 'ipps' URI to 418 decide if they match or not, an IPP Client MUST use the same rules as 419 those defined for 'http' and 'https' URI comparisons in [RFC7230], 420 with the single following exception: 422 - A port that is empty or not given MUST be treated as equivalent to 423 the well-known port for that 'ipps' URI (port 631). 425 See: Section 4.3 (port) in this document. 427 See: Section 2.7.3 'http and https URI Normalization and Comparison' 428 in [RFC7230]. 430 5. IANA Considerations 432 [RFC Editor: Replace 'xxxx' with assigned RFC number before 433 publication] 435 IANA is asked to register the 'ipps' URI scheme using the following 436 template, which conforms to [BCP35]. 438 URI scheme name: ipps 440 Status: Permanent 442 URI scheme syntax: See section 4.2 of RFC xxxx. 444 URI scheme semantics: The 'ipps' URI scheme is used to designate 445 secure IPP Printer objects (print spoolers, print gateways, print 446 devices, etc.) on Internet hosts accessible using the IPP protocol 447 enhanced to support guaranteed data integrity and negotiable data 448 privacy using TLS [RFC5246] as specified in HTTP/1.1 [RFC7230]. 450 Encoding Considerations: See section 4.4 of RFC xxxx. 452 Applications/protocols that use this URI scheme name: 454 The 'ipps' URI scheme is intended to be used by applications that 455 need to access secure IPP Printers using the IPP protocol enhanced to 456 support guaranteed data integrity and negotiable data privacy using 457 TLS [RFC5246] as specified in HTTP/1.1 [RFC7230]. Such applications 458 may include (but are not limited to) IPP-capable web browsers, IPP 459 Clients that wish to print a file, and servers (for example, print 460 spoolers) wishing to forward a Job for processing. 462 Interoperability Considerations: The widely deployed, open source 463 IPP print service CUPS [CUPS] (on most UNIX, Linux, and Apple OS X 464 systems) has supported 'ipps' URI for several years before the 465 publication of this document. PWG IPP Everywhere [PWG5100.14] (IPP 466 secure, mobile printing extensions) requires the use of 'ipps' URI 467 for mandatory data integrity and negotiable data confidentiality. 469 Security Considerations: See section 6 of RFC xxxx. 471 Contact: 473 Ira McDonald 475 Michael Sweet 477 Author/Change controller: 479 IESG 481 References: RFC 2910, RFC 2911, RFC xxxx, and IEEE-ISTO PWG 5100.12. 483 6. Security Considerations 485 6.1. Problem Statement 487 Powerful mobile devices (laptops, tablets, smartphones, etc.) are now 488 commonly used to access enterprise and Cloud print services across 489 the public Internet. This is the primary use case for PWG IPP 490 Everywhere [PWG5100.14], which has already been adopted by operating 491 system and printer vendors and several other public standards bodies. 492 End user and enterprise documents and user privacy-sensitive 493 information are at greater risk than ever before. This IPP over 494 HTTPS transport binding and 'ipps' URI scheme specification was 495 defined to enable high availability combined with secure operation in 496 this dynamic environment (for example, wireless hotspots in hotels, 497 airports, and restaurants). 499 See: Section 1 Introduction of [PWG5100.14]. 501 See: Section 3.1 Rationale of [PWG5100.14]. 503 6.1.1. Targets of Attacks 505 A network print spooler (logical printer) or print device (physical 506 printer) is potentially subject to attacks, which may target: 507 a) The network (to compromise the routing infrastructure, for 508 example, by creating congestion); 509 b) The Internet Printing Protocol (IPP) [RFC2911] (for example, to 510 compromise the normal behavior of IPP); 511 c) The print job metadata (for example, to extract privacy-sensitive 512 information from the job submission request or via query of the 513 job on the IPP Printer); or 514 d) The print document content itself (for example, to corrupt the 515 documents being transferred). 517 6.1.2. Layers of Attacks 519 Attacks against print services can be launched: 521 a) Against the network infrastructure (for example, TCP [STD7] 522 congestion control); 523 b) Against the IPP data flow itself (for example, by sending forged 524 packets or forcing TLS [RFC5246] version downgrade); or 525 c) Against the IPP operation parameters (for example, by corrupting 526 requested document processing attributes). 528 6.2. Attacks and Defenses 530 This 'ipps' URI Scheme specification adds the following additional 531 security considerations to those described in [RFC7230], [RFC2910], 532 [RFC2911], [RFC5246], [RFC7230], [PWG5100.12], and [STD66]. 534 See: Section 8 'Security Considerations' in [RFC2910]. 536 See: Section 8 'Security Considerations' in [RFC2911]. 538 See: Appendix D 'Implementation Notes', Appendix E 'Backward 539 Compatibility', and Appendix F 'Security Analysis' of [RFC5246]. 541 See: Section 10 'Security Considerations' in [PWG5100.12]. 543 See: Section 7 'Security Considerations' in [STD66]. 545 6.2.1. Faked 'ipps' URI 547 An 'ipps' URI might be faked to point to a rogue IPP secure print 548 service, thus collecting confidential job metadata or document 549 contents from IPP Clients. 551 Due to administrator reconfiguration or physical relocation of an IPP 552 Printer, a former literal IPv4 or IPv6 address might no longer be 553 valid - see section 4.2 for the recommendation against the use of 554 literal IP addresses in 'ipps' URI. 556 Server authentication mechanisms and security mechanisms specified in 557 IPP/1.1 Encoding and Transport [RFC2910], HTTP/1.1 [RFC7230], and 558 TLS/1.2 [RFC5246] can be used to address this threat. 560 6.2.2. Unauthorized Access by IPP Client 562 An 'ipps' URI might be used to access an IPP secure print service by 563 an unauthorized IPP Client, for example, extracting privacy-sensitive 564 information such as "job-originating-user-name" job metadata defined 565 in IPP/1.1 Model and Semantics [RFC2911]. 567 Client authentication mechanisms and security mechanisms specified in 568 IPP/1.1 Encoding and Transport [RFC2910], HTTP/1.1 [RFC7230], and 569 TLS/1.2 [RFC5246] can be used to address this threat. 571 6.2.3. Compromise at Application Layer Gateway 573 An 'ipps' URI might be used to access an IPP secure print service at 574 a print protocol application layer gateway (for example, an IPP to 575 LPD [RFC1179] gateway [RFC2569]), potentially causing silent 576 compromise of IPP security mechanisms. 578 There is no general defense against this threat by an IPP Client. 579 System administrators SHOULD avoid such configurations. 581 6.2.4. No Client Authentication for 'ipps' URI 583 An 'ipps' URI does not define parameters to specify the required IPP 584 Client authentication mechanism (for example, 'certificate' as 585 defined in section 4.4.2 'uri-authentication-supported' of IPP Model 586 [RFC2911]). 588 Either service discovery or directory protocols SHOULD be used first 589 or an IPP Client SHOULD first establish an 'ipp' connection (without 590 TLS [RFC5246] or any client authentication) to the target IPP Printer 591 and use a Get-Printer-Attributes operation to discover the required 592 IPP Client authentication mechanism(s) associated with a given 'ipps' 593 URI. 595 6.3. TLS Version Requirements 597 Per PWG IPP Everywhere [PWG5100.14] (and in accordance with security 598 best practices and all existing deployments of the 'ipps' URI 599 scheme), IPP Clients and IPP Printers that support this specification 600 MUST use TLS/1.2 [RFC5246] or higher version, for all 'ipps' secure 601 transport layer connections. 603 7. Acknowledgments 605 This document has been submitted to the IETF by the Internet Printing 606 Protocol Working Group of the IEEE-ISTO Printer Working Group, as 607 part of their PWG IPP Everywhere [PWG5100.14] project for secure 608 mobile printing with vendor-neutral Client software. 610 This document defines an alternate IPP transport binding to that 611 defined in the original IPP URL Scheme [RFC3510], but this document 612 does not update or obsolete [RFC3510]. 614 Thanks to Claudio Allochio, Tom Hastings (retired from Xerox), Bjoern 615 Hoerhmann, Graham Klyne, Barry Leiba, S. Mooneswamy, Tom Petch, 616 Robert Sparks, Jerry Thrasher (Lexmark), Mykyta Yevstifeyev, Pete 617 Zehler (Xerox), and the members of the IEEE-ISTO PWG IPP WG. 619 8. References 621 8.1. Normative References 623 [ASCII] "American National Standards Institute, Coded Character 624 Set -- 7-bit American Standard Code for Information 625 Interchange", ANSI X3.4, 1986. 627 [PWG5100.12] Bergman, R., Lewis, H., McDonald, I., and M. Sweet, 628 "Internet Printing Protocol Version 2.0 Second Edition 629 (IPP/2.0 SE)", PWG 5100.12, February 2011. 630 632 [PWG5100.14] McDonald, I. and M. Sweet, "PWG IPP Everywhere", PWG 633 5100.14, January 2013. 634 636 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 637 Requirement Levels, BCP 14, RFC 2119, March 1997. 639 [RFC2910] Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and 640 J. Wenn, "Internet Printing Protocol/1.1: Encoding and 641 Transport", RFC 2910, September 2000. 643 [RFC2911] Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S., 644 and P. Powell, "Internet Printing Protocol/1.1: Model and 645 Semantics", RFC 2911, September 2000. 647 [RFC5246] Dierks, T., and E. Rescorla, "The Transport Layer Security 648 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 650 [RFC7230] Fielding, R., and J. Reschke, "Hypertext Transfer Protocol 651 (HTTP/1.1): Message Syntax and Routing, RFC 7230, June 652 2014. 654 [RFC7231] Fielding, R., and J. Reschke, "Hypertext Transfer Protocol 655 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 657 [RFC7232] Fielding, R., and J. Reschke, "Hypertext Transfer Protocol 658 (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 660 [RFC7233] Fielding, R., Lafon, Y., and J. Reschke, "Hypertext 661 Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, 662 June 2014. 664 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 665 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 666 2014. 668 [RFC7235] Fielding, R., and J. Reschke, "Hypertext Transfer Protocol 669 (HTTP/1.1): Authentication", RFC 7235, June 2014. 671 [STD7] Postel, J., "Transmission Control Protocol", STD 7, RFC 672 793, September 1981. 674 [STD63] Yergeau, F., "UTF-8, a transformation format of ISO 675 10646", STD 63, RFC 3629, November 2003. 677 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, Uniform 678 Resource Identifiers (URI) Generic Syntax, STD 66, RFC 679 3986, January 2005. 681 [STD68] Crocker, D., Ed., and P. Overell, "Augmented BNF for 682 Syntax Specifications: ABNF", STD 68, RFC 5234, January 683 2008. 685 8.2. Informative References 687 [BCP35] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 688 Registration Procedures for New URI Schemes", BCP 35, RFC 689 4395, February 2006. 691 [CUPS] Apple, "CUPS standards-based, open source printing system 692 for OS X and other UNIX-like operating systems" 693 695 [PORTREG] Internet Assigned Numbers Authority (IANA) Registry "Port 696 Numbers" 697 699 [RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, 700 August 1990. 702 [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and 703 P. Powell, "Internet Printing Protocol/1.0: Model and 704 Semantics", RFC 2566, April 1999. 706 [RFC2569] Herriot, R., Ed., Hastings, T., Jacobs, N., and J. 707 Martin, "Mapping between LPD and IPP Protocols", RFC 2569, 708 April 1999. 710 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 711 HTTP/1.1", RFC 2817, May 2000. 713 [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. 714 Holst, "Internet Printing Protocol/1.1: Implementor's 715 Guide", RFC 3196, November 2001. 717 [RFC3510] Herriot, R. and I. McDonald, "Internet Printing 718 Protocol/1.1: IPP URL Scheme", RFC 3510, April 2003. 720 9. Appendix A - Abbreviations 722 This document makes use of the following abbreviations (given with 723 their expanded forms and references for further reading): 725 ABNF - Augmented Backus-Naur Form [STD68] 727 ASCII - American Standard Code for Information Interchange [ASCII] 729 HTTP - HyperText Transfer Protocol [RFC7230] 731 HTTPS - HTTP over TLS [RFC7230] 733 IANA - Internet Assigned Numbers Authority 734 736 IEEE - Institute of Electrical and Electronics Engineers 737 739 IESG - Internet Engineering Steering Group 740 742 IPP - Internet Printing Protocol [RFC2911] and [PWG5100.12] 743 745 ISTO - IEEE Industry Standards and Technology Organization 746 748 LPD - Line Printer Daemon Protocol [RFC1179] 750 PWG - IEEE-ISTO Printer Working Group 751 753 RFC - Request for Comments 754 756 TCP - Transmission Control Protocol [STD7] 758 TLS - Transport Layer Security [RFC5246] 760 URI - Uniform Resource Identifier [STD66] 762 URL - Uniform Resource Locator [STD66] 764 UTF-8 - Unicode Transformation Format - 8-bit [STD63] 766 10. Appendix X - Change History 768 [RFC Editor: Delete this section before publication as an RFC] 770 28 November 2014 - draft-mcdonald-ipps-uri-scheme-16.txt 771 Editorial - Revised section Copyright Notice to add boilerplate for 772 updates to pre-RFC5378 work, per ID-Nits and Robert Sparks on 21 773 November 2014. 774 Editorial - Revised section 1.2 Rationale for this Document, to 775 correct three malformed references to [RFC2817] and to add missing 776 references to [RFC7230] and [STD7], per ID-Nits and Robert Sparks on 777 21 November 2014. 778 Editorial - Revised section 3 IPP over HTTPS Transport Binding, to 779 collapse former steps 3-5 (explicit TCP, explicit TLS, explicit 780 HTTPS) to just explicit HTTPS to avoid ambiguity about TLS 781 certificate checks (which could otherwise differed from HTTPS), per 782 advice of Robert Sparks on 21 November 2014. 783 Editorial - Revised section 4.3 Associated Port for 'ipps' URI 784 Scheme, to add missing reference to [RFC5246], per ID-Nits and Robert 785 Sparks on 21 November 2014. 786 Editorial - Revised section 5 IANA Considerations, to add missing 787 references to [RFC5246], per ID-Nits and Robert Sparks on 21 November 788 2014. 789 Editorial - Revised section 6.1.2 Layers of Attacks, to add missing 790 references to [STD7] and [RFC5246], per ID-Nits and Robert Sparks on 791 21 November 2014. 792 Editorial - Revised section 6.2.4 No Client Authentication for 'ipps' 793 URI, to add missing reference to [RFC5246], 794 per ID-Nits and Robert Sparks on 21 November 2014. Editorial - 795 Revised section 8.1 Normative References, to delete obscure composite 796 reference [HTTP1.1] and to correct reference [RFC7235], per ID-Nits 797 and Robert Sparks on 21 November 2014. 798 Editorial - Revised section 8.2 Informative References, to add 799 missing reference [RFC2566], per ID-Nits and Robert Sparks on 21 800 November 2014. 801 Editorial - Revised section Appendix A - Abbreviations, to replace 802 obscure composite reference [HTTP1.1] with [RFC7230], per ID-Nits and 803 Robert Sparks on 21 November 2014. 805 11 November 2014 - draft-mcdonald-ipps-uri-scheme-16.txt 806 Editorial - Revised section 3 IPP over HTTPS Transport Binding to 807 correct reference to section 7 'TLS Handshaking Protocols' in 808 [RFC5246], per advice of Tom Petch on 30 October 2014. 809 Editorial - Revised section 4 Definition of 'ipps' URI Scheme to 810 narrow scope to the URI scheme and avoid discussion of associated 811 media type, per advice of Graham Klyne and Barry Leiba on 9 November 812 2014. 813 Editorial - Revised section 4 Definition of 'ipps' URI Scheme and all 814 subsections to state the explicit source of all conformance 815 constraints as [RFC2910] or [PWG5100.14], as appropriate, per advice 816 of Graham Klyne on 4 November 2014. 817 Editorial - Revised section 4.1 Applicability of 'ipps' URI Scheme to 818 add the conformance requirement that the 'ipps' URI scheme MUST only 819 be used with the transport binding defined in this document, per 820 advice of Tom Petch on 30 October 2014. 821 Editorial - Revised section 4.1 Applicability of 'ipps' URI Scheme to 822 remove out-of-scope mention of relative URI, per advice of Graham 823 Klyne on 4 November 2014. 824 Editorial - Revised section 4.3 Associated Port for 'ipps' URI Scheme 825 to clarify that the dual use of port 631 in the IPP protocol (with or 826 without TLS) was an IESG decision, per advice of Graham Klyne on 4 827 November 2014. 828 Editorial - Deleted (former) section 4.4 Associated Media Type for 829 'ipps' URI Scheme and removed widowed [MEDIAREG] from section 8.2 830 Informative References, per advice of Graham Klyne and Barry Leiba on 831 9 November 2014. 832 Editorial - Revised section 4.5 Examples of 'ipps' URI to add missing 833 trailing forward slash to all URI examples, consistent w/ section 834 4.2, per advice of Graham Klyne on 4 November 2014. 835 Editorial - Revised section 5 IANA Considerations to correct section 836 4.4 cross-reference in "Encoding Considerations" clause, per advice 837 of Tom Petch on 30 October 2014. 838 Editorial - Revised section 6.1 Problem Statement, section 6.1.1 839 Targets of Attacks, and section 6.2.2 Unauthorized Access by IPP 840 Client, to address privacy-sensitive job metadata, per advice of 841 Graham Klyne on 4 November 2014. 842 Editorial - Revised section 6.2.1 Faked 'ipps' URI to add discussion 843 of the reasons to avoid use of literal IP addresses in 'ipps' URI and 844 a cross-reference to section 4.2 Syntax of 'ipps' URI Scheme, per 845 advice of Tom Petch on 30 October 2014. 847 27 October 2014 - draft-mcdonald-ipps-uri-scheme-15.txt 848 Editorial - Kept "Intended Status" as "Standards Track", with AD 849 sponsoring, per advice of Barry Leiba on 22 October 2014. 850 Editorial - Revised Abstract to delete mention of submission from 851 PWG, per advice of S. Mooneswamy on 13 October 2014 and Barry Leiba 852 on 22 October 2014. 854 Editorial - Revised Boilerplate to reflect IETF standards-track, per 855 advice of Barry Leiba on 22 October 2014. 856 Editorial - Revised Introduction and Acknowledgments to say "This 857 document has been submitted to IETF...", per advice of Barry Leiba on 858 22 October 2014. 859 Editorial - Replaced "this memo" with "this document", per advice of 860 S. Mooneswamy on 13 October 2014 and Barry Leiba on 22 October 2014. 861 Editorial - Replaced [RFC2818] with [RFC7230] for HTTPS and deleted 862 [RFC2818] from references, per advice of S. Mooneswamy on 13 October 863 2014. 864 Editorial - Revised section 1.1 Structure of this Document to correct 865 list of sections per revisions in this draft, per IEEE-ISTO PWG IPP 866 WG review, 867 Editorial - Kept section 2.2 Abbreviations to become Appendix A, as a 868 compromise to request to remove entirely, per discussion with 869 S. Mooneswamy on 13 October 2014. 870 Editorial - Revised section 3 IPP over HTTPS Transport Binding to 871 delete (redundant) first paragraph, per advice of S. Mooneswamy on 13 872 October 2014. 873 Editorial - Revised section 3 IPP over HTTPS Transport Binding to add 874 reference to [RFC7230] for 'https' URI scheme in bullet (2), per 875 advice of S. Mooneswamy on 13 October 2014. 876 Editorial - Revised section 3 IPP over HTTPS Transport Binding to 877 delete (redundant) "reliable" qualifier of a TCP transport layer 878 connection in bullet (3), per advice of S. Mooneswamy on 13 October 879 2014. 880 Editorial - Revised section 3 IPP over HTTPS Transport Binding to 881 replace "TLS 1.2 [RFC5246], or later TLS version," with "TLS 1.2 882 [RFC5246] or higher version" in bullet (4), consistent with TLS 883 future-proofing in current HTTP/2.0 draft, per IEEE-ISTO PWG IPP WG 884 review, rejecting request of S. Mooneswamy on 13 October 2014. 885 Editorial - Revised section 3 IPP over HTTPS Transport Binding to 886 delete (out-of-date) reference to [RFC2910] in bullet (6), per advice 887 of S. Mooneswamy on 13 October 2014. 888 Editorial - Revised section 3 IPP over HTTPS Transport Binding to 889 delete references to Security Considerations in other documents, per 890 advice of S. Mooneswamy on 13 October 2014. 891 Editorial - Revised section 4.1 Applicability of 'ipps' URI Scheme to 892 delete references to Security Considerations in other documents, per 893 advice of S. Mooneswamy on 13 October 2014. 894 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme to 895 replace out-of-date reference to [RFC2911] w/ [STD66] (i.e., RFC 896 3986), per advice of S. Mooneswamy on 13 October 2014. 897 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme to move 898 conformance requirement out of "Note" and rewrite conformance that 899 IPP Printers SHOULD NOT *generate* 'ipps' URI longer than 255 octets, 900 due to known implementation bugs in many older IPP Clients, per 901 advice of S. Mooneswamy on 13 October 2014. 902 Editorial - Revisions section 4.3 Associated Port for 'ipps' URI 903 Scheme to move conformance requirement out of "Note", per advice of 904 S. Mooneswamy on 13 October 2014. 906 Editorial - Revised section 4.4 and References to change "MIME type" 907 or "MIME media type" to "media type" and "[MIMEREG]"to "[MEDIAREG]", 908 per advice of Barry Leiba on 22 October 2014. 909 Editorial - Revised section 4.6.1 to correct plural/singular 910 confusion, per advice of Barry Leiba on 22 October 2014. 911 Editorial - Deleted section 4.6.2 Examples of 'ipps' URI for Jobs, 912 because IPP "job-uri" attribute will be deprecated in the future, per 913 IEEE-ISTO PWG IPP WG review. 914 Editorial - Delete section 5 Applicability of this Specification 915 because it was redundant with conformance imperatives in section 4, 916 per advice of S. Mooneswamy on 13 October 2014. 917 Editorial - Kept IESG as change controller in (former) section 6 IANA 918 Considerations (since the document remains standards-track), 919 rejecting request of S. Mooneswamy on 13 October 2014. 920 Editorial - Revised (former) section 7.3 TLS Version Requirements to 921 replace "TLS 1.2 [RFC5246], or later TLS version," with "TLS 1.2 922 [RFC5246] or higher version", consistent with TLS future-proofing in 923 current HTTP/2.0 draft, per IEEE-ISTO PWG IPP WG review, rejecting 924 request of S. Mooneswamy on 13 October 2014. 925 Editorial - Deleted Appendix A - Summary of IPP URL Scheme, due to 926 ambiguity and for future-proofing, per IEEE-ISTO PWG IPP WG review. 928 28 September 2014 - draft-mcdonald-ipps-uri-scheme-14.txt 929 Editorial - Kept "Intended Status" as "Standards Track", with AD 930 sponsoring, per advice of Barry Leiba on 18 August 2014. 931 Editorial - Revised Abstract, Boilerplate, and Introduction to state 932 that this document is an Independent Submission to the RFC Editor 933 Stream with IETF AD sponsoring, per advice of Barry Leiba on 18 934 August 2014. 935 Technical - Revised section 3 IPP over HTTPS Transport Binding, to 936 require TLS/1.2, or later TLS version, for all 'ipps' connections, 937 per IEEE-ISTO PWG IPP WG review. 938 Technical - Revised section 7.2.1 Faked 'ipps' URI and section 7.2.2 939 Unauthorized Access by IPP Client, to delete all references to 940 TLS/1.0 and TLS/1.1, per IEEE-ISTO PWG IPP WG review. 941 Technical - Renamed section 7.3 TLS Cipher Suite Requirements to TLS 942 Version Requirements and deleted all requirements for specific cipher 943 suites, per IEEE-ISTO PWG IPP WG review. 944 Technical - Revised section 9.1 Normative References, to delete all 945 references to TLS/1.0 and TLS/1.1, per IEEE-ISTO PWG IPP WG review. 947 3 July 2014 - draft-mcdonald-ipps-uri-scheme-13.txt 948 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, to 949 replace old 'path-absolute' from RFC 2616 with 'absolute-path' from 950 [RFC7230], per IEEE-ISTO PWG IPP WG review. 951 Editorial - Revised section 2.2 Abbreviations, section 3 IPP over 952 HTTPS Transport Binding, section 4.2 Syntax of 'ipps' URI Scheme, 953 section 4.7 Comparisons of 'ipps' URI, section 7.2 Attacks and 954 Defenses, section 9.1 Normative References, and section 10 Appendix A 955 - Summary of IPP URL Scheme, to replace [RFC2616] with either 956 [RFC7230] or [HTTP1.1] - a new collective reference to [RFC7230], 958 [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235], per 959 IEEE-ISTO PWG IPP WG review. 961 20 April 2014 - draft-mcdonald-ipps-uri-scheme-12.txt 962 Editorial - Revised section 4.3 Associated Port for 'ipps' URI 963 Scheme, to add informative reference to CUPS, per IEEE-ISTO PWG IPP 964 WG review. 966 Editorial - Revised section 4.6.1 Examples of 'ipps' URI for 967 Printers, to change "third" to "fourth" for the port 443 example, per 968 IEEE-ISTO PWG IPP WG review. 969 Editorial - Revised section 6 IANA Considerations, to add informative 970 reference to CUPS, per IEEE-ISTO PWG IPP WG review. 971 Editorial - Revised section 9.2 Informative References, to add 972 informative reference to CUPS, per IEEE-ISTO PWG IPP WG review. 974 7 April 2014 - draft-mcdonald-ipps-uri-scheme-11.txt 975 Global - revised all references to section 4.2 and section 4.3, to 976 add parenthetic (syntax) and (port) respectively, per IEEE-ISTO PWG 977 IPP WG review. 978 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, to 979 correct two typos (extra words) in section 4.3 references, per 980 IEEE-ISTO PWG IPP WG review. 981 Editorial - Revised section 4.3 Associated Port for 'ipps' URI 982 Scheme, to add note about compatibility for IPP Clients and IPP 983 Printers that MUST accept explicit port 443 (assigned in 'https' URI 984 scheme [RFC7230]) and process normally, per IEEE-ISTO PWG IPP WG 985 review. 986 Editorial - Revised section 4.6.1 Examples of 'ipps' URI for 987 Printers, to add example of explicit port 443, per IEEE-ISTO PWG IPP 988 WG review. 990 30 March 2014 - draft-mcdonald-ipps-uri-scheme-10.txt 991 Global - Updated references, per IEEE-ISTO PWG IPP WG review. 992 Global - Changed "e.g." to "for example", for readability. 993 Editorial - Revised section Copyright Notice, to correct year. 994 Editorial - Revised section 3 IPP over HTTPS Transport Binding, item 995 2), to clarify that port 631 is ONLY inserted in the derived 'https' 996 URI when an explicit port is NOT specified in the original 'ipps' 997 URI, per Smith Kennedy and IEEE-ISTO PWG IPP WG review. 998 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, note 999 about URI lengths greater than 255 octets, to change 'ought to' to 1000 'SHOULD', per Smith Kennedy and IEEE-ISTO PWG IPP WG review. 1001 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, to add 1002 reference to section 4.3 for use of port 631, per Smith Kennedy and 1003 IEEE-ISTO PWG IPP WG review. 1004 Editorial - Revised section 4.3 Associated Port for 'ipps' URI 1005 Scheme, to add note about dual-use of port 631 for 'ipp' URI and 1006 'ipps' URI with reference to CUPS source for example of incoming 1007 connection handling, per Smith Kennedy and IEEE-ISTO PWG IPP WG 1008 review. 1009 Editorial - Revised section 4.3 Associated Port for 'ipps' URI 1010 Scheme, to add note about compatibility for IPP Clients and IPP 1011 Printers that should accept explicit port 443 (assigned in 'https' 1012 URI scheme [RFC7230]) and process normally, per IEEE-ISTO PWG IPP WG 1013 review. 1014 Editorial - Revised section 4.6.1 Examples of 'ipps' URI for 1015 Printers, to add reference to section 4.2 (syntax) and section 4.3 1016 (port), per Smith Kennedy and IEEE-ISTO PWG IPP WG review. 1017 Editorial - Revised section 4.7 Comparisons of 'ipps' URI, to add 1018 reference to section 4.3 (port), per Smith Kennedy and IEEE-ISTO PWG 1019 IPP WG review. 1020 Editorial - Revised section 5.1 Applicability to IPP Clients, to add 1021 reference to section 4.2 (syntax) and section 4.3 (port), per Smith 1022 Kennedy and IEEE-ISTO PWG IPP WG review. 1023 Editorial - Revised section 5.1 Applicability to IPP Clients, item 1024 d), to change 'MUST the' to 'MUST use the', per Smith Kennedy and 1025 IEEE-ISTO PWG IPP WG review. 1026 Editorial - Revised section 5.2 Applicability to IPP Printers, to add 1027 reference to section 4.2 (syntax) and section 4.3 (port), per Smith 1028 Kennedy and IEEE-ISTO PWG IPP WG review. 1029 Editorial - Revised section 5.2 Applicability to IPP Printers, item 1030 d), to change 'MUST the' to 'MUST use the', per Smith Kennedy and 1031 IEEE-ISTO PWG IPP WG review. 1032 Editorial - Revised section 5.2 Applicability to IPP Printers, to 1033 delete former item e) (listen only on port 631) which conflicted with 1034 existing IPP implementations (for example, listening on port 443 as 1035 well), per Smith Kennedy and IEEE-ISTO PWG IPP WG review. 1036 Editorial - Revised section 6 IANA Considerations, to add URI for 1037 CUPS source, per IEEE-ISTO PWG IPP WG review. 1038 Editorial - Revised section 7.2.4 No Client Authentication for 'ipps' 1039 URI, to change "or or" to "or" (typo), per Smith Kennedy and 1040 IEEE-ISTO PWG IPP WG review. 1041 Editorial - Revised Appendix A Summary of IPP URL Scheme, item 2), to 1042 clarify that port 631 is ONLY inserted in the derived 'http' URI when 1043 an explicit port is NOT specified in the original 'ipp' URI, per 1044 Smith Kennedy and IEEE-ISTO PWG IPP WG review. 1046 5 November 2013 - draft-mcdonald-ipps-uri-scheme-09.txt 1047 Global - Updated references, per IPP WG review. 1048 Editorial - Revised Abstract, section 1 Introduction, and section 8 1049 Acknowledgments to clarify that this document is an individual 1050 submission to the IETF by the IPP WG of the IEEE-ISTO PWG, per 1051 S. Mooneswamy. 1052 Editorial - Revised Abstract, section 1 Introduction, and section 8 1053 Acknowledgments to clarify that this document does not update or 1054 obsolete [RFC3510], per S. Mooneswamy and Tom Petch. 1055 Editorial - Revised section 1.1 Structure of this Document to align 1056 with changes below, per Tom Petch. 1057 Editorial - Revised section 2 Conventions Used in this Document to 1058 add section 2.1 Printing Terminology and to remove redundant "In this 1059 document" and clarify definitions, per Tom Petch. 1060 Editorial - Moved former Appendix B - Abbreviations Used in this 1061 Document to become section 2.2 Abbreviations, per Tom Petch. 1062 Technical - Revised section 3 IPP over HTTPS Transport Binding, 1063 section 5 Applicability of this Specification, and section 7 Security 1064 Considerations to address specific TLS/1.0 [RFC2246], TLS/1.1 1065 [RFC4346], and TLS/1.2 [RFC5246] requirements, per Tom Petch. 1066 Editorial - Moved former section 3.1 IPP over HTTP Transport Binding 1067 to become Appendix A - Summary of IPP URL Scheme (Informative), per 1068 Tom Petch. 1069 Technical - Revised section 4.2 Syntax of 'ipps' URI Scheme to add 1070 note about the retention of the (unused) "query" production for 1071 consistency with IPP/1.1 Encoding and Transport [RFC2910] and the 1072 original IPP URL Scheme [RFC3510], but warn that it has no defined 1073 semantics in IPP and therefore its use is unsafe for IPP Clients, per 1074 Tom Petch. 1075 Technical - Revised section 7 Security Considerations to add section 1076 8.1 Problem Statement, section 8.2 Attacks, and section 8.3 TLS 1077 Security Considerations, per Tom Petch. 1078 Editorial - Moved former section Appendix A - Acknowledgments to 1079 become section 8 Acknowledgements (in body of document) and updated 1080 to reflect recent comments on this document, per Tom Petch. 1081 Technical - Revised section 9.1 Normative References to add TLS/1.0 1082 [RFC2246] and TLS/1.1 [RFC4346], per Tom Petch. 1084 19 September 2013 - draft-mcdonald-ipps-uri-scheme-08.txt 1085 Global - Updated references, per IPP WG review. 1087 12 May 2013 - draft-mcdonald-ipps-uri-scheme-07.txt 1088 Editorial - Revised section 1 (introduction) to add 'Rationale for 1089 this document', per Smith Kennedy. 1090 Editorial - Global - Changed 'Conformance Requirements' to 1091 'Applicability', per Barry Leiba. 1092 Editorial - Global - Changed '[PWG5100.EW]' to '[PWG5100.14]', 1093 corrected date and URI, and moved section 8.1 (normative references), 1094 per IPP WG review. 1096 10 November 2012 - draft-mcdonald-ipps-uri-scheme-06.txt 1097 Editorial - Global - Fixed typos and indentation, per IPP WG review. 1098 Editorial - Global - changed 'generic drivers' to 'vendor-neutral 1099 Client software', per IPP WG review. 1100 Editorial - Revised section 8.2 (informative references, to correct 1101 title of "PWG IPP Everywhere" (i.e., delete version number), per IPP 1102 WG review. 1104 14 May 2012 - draft-mcdonald-ipps-uri-scheme-05.txt 1105 Editorial - Global - Fixed typos and indentation, per IPP WG review. 1106 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to 1107 insert missing "to" in "connection to the target endpoint", per IPP 1108 WG review. 1110 Editorial - Revised section 4.2 (syntax), to correct indentation of 1111 first "Note:", per IPP WG review. 1112 Editorial - Revised sections 5.1 and 5.2 (client/printer conformance) 1113 and section 7 (security considerations) to delete the out-of-scope 1114 normative references to [RFC2817], per IPP WG review. 1116 22 November 2011 - draft-mcdonald-ipps-uri-scheme-04.txt 1117 Editorial - Global - Fixed typos and indentation, per IPP WG review. 1118 Editorial - Revised Introduction and Acknowledgments to say 'project 1119 for mobile, ubiquitous printing with generic drivers', per IPP WG 1120 review. 1121 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to add 1122 references to HTTP POST and section 4 of RFC 2910, per IPP WG review. 1123 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to add 1124 section references to all well-known standards (connection setup, 1125 etc.), per IPP WG review. 1126 Editorial - Revised section 4.2 (syntax) to move note from from 1127 section 4.6 (examples) and explain why literal IP addresses SHOULD 1128 NOT be used in 'ipps' URI, per IPP WG review. 1129 Editorial - Revised sections 4.6.1 and 4.6.2 (examples) to replace 1130 'abc.com' w/ 'example.com' (per IETF) and replace '/printer' path 1131 element w/ '/ipp' (better practice), per IPP WG review. 1132 Editorial - Revised section 5.2 (Printer conformance) to fold former 1133 (c) and (d) into a single requirement for standard port 631 and 1134 reordered other requirements to group MUSTs before SHOULDs, per IPP 1135 WG review. 1136 Editorial - Revised section 5.2 (Printer conformance) to add backward 1137 reference to section 4.2 for rationale for not using IP literal 1138 addresses, per IPP WG review. 1139 Editorial - Revised section 6 (IANA) to explicitly state that 'ipps' 1140 uses secure communications using HTTP over TLS, per IPP WG review. 1141 Editorial - Revised section 7 (Security) to cleanup numerous loose 1142 ends, per IPP WG review. 1143 Editorial - Revised section 8 (References) to cleanup typos and 1144 links, per IPP WG review. 1145 Editorial - Revised section 1 (introduction), section 8.2 1146 (informative references, and section 9 (appendix A) to change 1147 "[IPPEVE]" to "[PWG5100.EW]", per IPP WG review. 1149 26 August 2011 - draft-mcdonald-ipps-uri-scheme-03.txt 1150 Editorial - Revised Abstract and Introduction to state published by 1151 the IETF on behalf of IEEE-ISTO PWG (to avoid status ambiguity), per 1152 Mykyta Yevstifeyev. 1153 Editorial - Revised section 1 to list all currently defined versions 1154 of IPP in RFC 2566, RFC 2911, and PWG 5100.12, per Mykyta 1155 Yevstifeyev. 1156 Technical - Revised section 1, section 2, section 3.2, section 4.1, 1157 and section 7, to reference IPP Version 2.0 Second Edition (PWG 1158 5100.12), per Mykyta Yevstifeyev. 1159 Editorial - Revised section 3.1, to fix broken STD7 reference, per 1160 Mykyta Yevstifeyev. 1162 Editorial - Revised section 6, to add BCP35 reference for template 1163 (regression loss when the template was moved up from former 1164 appendix), per Mykyta Yevstifeyev. 1165 Editorial - Revised section 8.1 to add PWG 5100.12 (normative), 1166 Editorial - Revised section 8.2 to add PWG IPP Everywhere 1167 (informative) and RFC 1179 (informative), per Mykyta Yevstifeyev. 1168 Editorial - Revised appendix B to add references for more reading, 1169 per Mykyta Yevstifeyev. 1171 28 February 2011 - draft-mcdonald-ipps-uri-scheme-02.txt 1172 Editorial - Revised document title to emphasize IPP over HTTPS 1173 Transport Binding (reason for IETF standards-track status). 1174 Editorial - Replaced "IPP URI" with "'ipp' URI", "IPPS URI" with 1175 "'ipps' URI", "HTTP URI" with "'http' URI", and "HTTPS URI" with 1176 "'https' URI" throughout this document for conformance to section 3.1 1177 of [STD66], per Mykyta Yevstifeyev. 1178 Editorial - Revised and simplified Abstract, per Mykyta Yevstifeyev. 1179 Editorial - Revised and simplified section 1 'Introduction', per 1180 Mykyta Yevstifeyev. 1181 Editorial - Renamed section 2 from 'Conformance Terminology' to 1182 'Conventions Used in this Document', per Mykyta Yevstifeyev. 1183 Editorial - Moved former section 3.1 'IPP Model Terminology 1184 (Normative)' content into section 2 'Conventions Used in this 1185 Document' for readability, per Mykyta Yevstifeyev. 1186 Editorial - Reordered subsections and reversed word order in all 1187 subsection titles in section 4 'The 'ipps' URI Scheme' for 1188 readability, per Mykyta Yevstifeyev. 1189 Editorial - Added note to section 4.2 'Syntax of 'ipps' URI Scheme' 1190 to explain why 'authority' production is NOT imported from [STD66], 1191 because it includes an optional 'userinfo' component which cannot be 1192 used in 'ipps' URI values. 1193 Editorial - Deleted note describing empty 'host' component from 1194 section 4.2 'Syntax of 'ipps' URI Scheme', because 'host' component 1195 is mandatory in [STD66]. 1196 Editorial - Deleted 'Internationalization Considerations' section 1197 which was redundant with section 4.3 'Character Encoding of 'ipps' 1198 URI Scheme', per Mykyta Yevstifeyev. 1199 Editorial - Revised all references to follow current RFC Editor 1200 style, per Mykyta Yevstifeyev. 1201 Editorial - Moved former 'Appendix A - Registration of IPPS URI 1202 Scheme' content inline into section 6 'IANA Considerations', per 1203 Mykyta Yevstifeyev. 1204 Editorial - Moved former body section 'Acknowledgements' to 'Appendix 1205 A - Acknowledgements', per Mykyta Yevstifeyev. 1206 Editorial - Added new 'Appendix B - Abbreviations Used in this 1207 Document' for readability, per Mykyta Yevstifeyev. 1208 Editorial - Moved section 'Authors' Addresses' to end of document, 1209 per Mykyta Yevstifeyev. 1211 1 December 2010 - draft-mcdonald-ipps-uri-scheme-01.txt 1212 - Technical - added UTF-8 [STD63] as required charset for all IPPS 1213 URI in section 4.4 and section 7, per Bjoern Hoehrmann. 1214 - Technical - corrected percent encoding for data octets outside the 1215 US-ASCII range in section 4.4 and section 7, per Bjoern Hoehrmann. 1216 - Editorial - global - changed "[RFC4395]" to "[BCP35]", changed 1217 "[RFC3629]" to "[STD63]", changed "[RFC3986]" to "[STD66]", and 1218 changed "[RFC5234]" to "[STD68]", per Bjoern Hoehrmann. 1219 - Editorial - restored trailing "]]" in ABNF syntax in section 4.5, 1220 per Bjoern Hoehrmann. 1221 - Editorial - changed "Author/Change controller" to "IESG" in section 1222 12 Appendix A registration template, as required by section 5.3 of 1223 [BCP35], per Bjoern Hoehrmann. 1225 10 October 2010 - draft-mcdonald-ipps-uri-scheme-00.txt 1226 - Editorial - complete rewrite of RFC 3510 for new transport binding 1227 - Editorial - moved Abstract to beginning of first page, per ID-Nits 1228 - Editorial - fixed copyright, boilerplate, and typos, per ID-Nits 1229 - Editorial - added references to RFCs 2119 and 3510, per ID-Nits 1230 - Editorial - deleted obsolete references to RFCs 2246 and 4346, per 1231 ID-Nits 1232 - Technical - changed Intended Status to Standards Track to reflect 1233 the new normative IPPS URI scheme and transport binding 1234 - Technical - added section 3.2 IPP over HTTP Transport Binding 1235 (informative) 1236 - Technical - added section 3.3 IPP over HTTPS Transport Binding 1237 (normative) 1238 - Technical - updated section 5 Conformance Requirements to require 1239 HTTP Upgrade (RFC 2817) support (for interoperability with existing 1240 IPP implementations), per discussion on IPP WG mailing list 1241 - Editorial - updated Appendix A w/ registration template from RFC 1242 4395 1244 11. Authors' Addresses 1246 Ira McDonald 1247 High North Inc 1248 221 Ridge Ave 1249 Grand Marais, MI 49839 1251 Phone: +1 906-494-2434 1252 Email: blueroofmusic@gmail.com 1254 Michael Sweet 1255 Apple Inc 1256 10431 N De Anza Blvd, M/S 38-4LPT 1257 Cupertino, CA 95014 1258 Phone: +1 408-974-8798 1259 Email: msweet@apple.com 1261 Usage questions and comments on this 'ipps' URI Scheme can be sent 1262 directly to the editors at their above addresses and also to the PWG 1263 IPP WG mailing list. Instructions for subscribing to the PWG IPP WG 1264 mailing list can be found at: 1266 PWG IPP WG Web Page: http://www.pwg.org/ipp/ 1267 PWG IPP WG Mailing List: ipp@pwg.org 1268 PWG IPP WG Subscription: http://www.pwg.org/mailhelp.html 1270 Implementers of this specification are encouraged to join the PWG IPP 1271 WG Mailing List in order to participate in any discussions of 1272 clarification issues and comments. Note that this IEEE-ISTO PWG 1273 mailing list rejects mail from non-subscribers (in order to reduce 1274 spam).