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