idnits 2.17.1 draft-mcdonald-ipps-uri-scheme-15.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 (27 October 2014) is 3469 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 123, but not defined ** Obsolete undefined reference: RFC 2566 (Obsoleted by RFC 2911) == Missing Reference: 'RFC 2817' is mentioned on line 165, but not defined == Missing Reference: 'RFC 2717' is mentioned on line 160, but not defined ** Obsolete undefined reference: RFC 2717 (Obsoleted by RFC 4395) == Missing Reference: 'RFC2818' is mentioned on line 780, but not defined ** Obsolete undefined reference: RFC 2818 (Obsoleted by RFC 9110) == Missing Reference: 'RFC2616' is mentioned on line 872, 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 874, but not defined ** Obsolete undefined reference: RFC 7235 (Obsoleted by RFC 9110) == Missing Reference: 'RFC2246' is mentioned on line 1000, but not defined ** Obsolete undefined reference: RFC 2246 (Obsoleted by RFC 4346) == Missing Reference: 'RFC4346' is mentioned on line 1000, 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 (~~), 9 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: 27 April 2015 27 October 2014 8 IPP over HTTPS Transport Binding and 'ipps' URI Scheme 9 draft-mcdonald-ipps-uri-scheme-15.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 27 April 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. Associated Media Type for 'ipps' URI Scheme ............ 9 73 4.5. Character Encoding of 'ipps' URI Scheme ................ 9 74 4.6. Examples of 'ipps' URI ................................. 10 75 4.7. Comparisons of 'ipps' URI .............................. 10 76 5. IANA Considerations ........................................ 11 77 6. Security Considerations .................................... 12 78 6.1. Problem Statement ...................................... 12 79 6.1.1. Targets of Attacks ................................. 12 80 6.1.2. Layers of Attacks .................................. 13 81 6.2. Attacks and Defenses ................................... 13 82 6.2.1. Faked 'ipps' URI ................................... 13 83 6.2.2. Unauthorized Access by IPP Client .................. 14 84 6.2.3. Compromise at Application Layer Gateway ............ 14 85 6.2.4. No Client Authentication for 'ipps' URI ............ 14 86 6.3. TLS Version Requirements ............................... 14 87 7. Acknowledgments ............................................ 15 88 8. References ................................................. 15 89 8.1. Normative References ................................... 15 90 8.2. Informative References ................................. 16 91 9. Appendix A - Abbreviations ................................. 17 92 10. Appendix X - Change History ............................... 18 93 11. Authors' Addresses ........................................ 26 94 1. Introduction 96 This document defines the Internet Printing Protocol (IPP) over HTTPS 97 transport binding and the corresponding 'ipps' URI scheme, that is 98 used to designate the access to the network location of a secure IPP 99 print service or a network resource managed by such a service. 101 This document has been submitted to the IETF by the Internet Printing 102 Protocol Working Group of the IEEE-ISTO Printer Working Group, as 103 part of their PWG IPP Everywhere (PWG 5100.14) project for secure 104 mobile printing with vendor-neutral Client software. 106 This document defines an alternate IPP transport binding to that 107 defined in the original IPP URL Scheme [RFC3510], but this document 108 does not update or obsolete [RFC3510]. 110 This document updates [RFC2910] and [RFC2911]. 112 This document updates: 113 a) IPP/1.1 Encoding and Transport [RFC2910], by extending section 4 114 'Encoding of the Transport Layer', section 5 'IPP URL Scheme', and 115 section 8.2 'Using IPP with TLS'; 116 b) IPP/1.1 Model and Semantics [RFC2911], by extending section 4.1.6 117 'uriScheme' and section 4.4.1 'printer-uri-supported'; and 118 c) IEEE-ISTO PWG IPP Version 2.0 Second Edition [PWG5100.12], by 119 extending section 4 'IPP Standards' and section 10 'Security 120 Considerations'. 122 The following versions of IPP are currently defined: 123 - 1.0 in [RFC2566] (obsolete) 124 - 1.1 in [RFC2911] 125 - 2.0 in [PWG5100.12] 126 - 2.1 in [PWG5100.12] 127 - 2.2 in [PWG5100.12] 129 Overview information about IPP is available in section 1 of RFC 2911 130 [RFC2911], section 1 of RFC 3196 [RFC3196], and section 1 of PWG IPP 131 Version 2.0 Second Edition [PWG5100.12]. 133 1.1. Structure of this Document 135 This document contains the following sections: 137 Section 2 defines the conventions and terms used throughout the 138 document. 140 Section 3 defines the IPP over HTTPS transport binding. 142 Section 4 defines the 'ipps' URI scheme. 144 Sections 5 and 6 contain IANA and security considerations, 145 respectively. 147 Section 7 contains acknowledgments. 149 Section 8 contains references. 151 1.2. Rationale for this document 153 The 'ipps' URI scheme was defined for the following reasons: 155 1) Some existing IPP Client and IPP Printer implementations of 156 Upgrading to TLS Within HTTP/1.1 [RFC 2817] are flawed and 157 unreliable. 159 2) Some existing IPP Client and IPP Printer implementations of HTTP 160 Upgrade [RFC 2717] do not perform upgrade at the beginning of 161 every HTTP connection, but instead only shift to secure IPP for 162 selected IPP operations (inherently dangerous behavior on the same 163 underlying TCP connection). 165 3) IPP Printer server-mandated HTTP Upgrade [RFC 2817] can still lead 166 to exposure of IPP Client data if the Expect request header is not 167 used - basically the IPP Client can send its whole Print-Job 168 request before the IPP Printer has a chance to respond and say, 169 "Wait! You need to encrypt first!" 171 2. Conventions Used in this Document 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC 2119 [RFC2119]. 177 2.1. Printing Terminology 179 The reader of this document needs to be familiar with the printing 180 terms defined in IPP/1.1 Model and Semantics [RFC2911] as well as the 181 following: 183 IPP Client: The software (on some hardware platform) that submits 184 IPP Job creation and IPP Printer and IPP Job management operations 185 via the IPP over HTTP transport binding defined in the IPP/1.1 186 Encoding and Transport [RFC2910] and/or the IPP over HTTPS transport 187 binding defined in section 3 of this specification to a downstream 188 IPP Printer (print spooler, print gateway, or physical printing 189 device). 191 IPP Job: The set of attributes and documents for one print job 192 instantiated in an IPP Printer. 194 IPP Job object: Synonym for IPP Job. 196 IPP Printer: The software (on some hardware platform) that receives 197 IPP Job creation and IPP Printer and IPP Job management operations 198 via the IPP over HTTP transport binding defined in the IPP/1.1 199 Encoding and Transport [RFC2910] and/or the IPP over HTTPS transport 200 binding defined in section 3 of this specification from an upstream 201 IPP Client or IPP Printer. 203 IPP Printer object: Synonym for IPP Printer. 205 'ipps' URI: A URI using the 'ipps' URI scheme defined in section 4 206 of this specification. 208 3. IPP over HTTPS Transport Binding 210 This document defines the following alternate IPP over HTTPS 211 transport binding for the abstract protocol defined in IPP/1.1 Model 212 and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version 2.0 Second 213 Edition [PWG5100.12]. 215 When using an 'ipps' URI, an IPP Client MUST establish an IPP 216 application layer connection according to the following sequence: 218 1) The IPP Client selects an 'ipps' URI value from 219 "printer-uri-supported" Printer attribute [RFC2911], a directory 220 entry, discovery info, a web page, etc.; 222 2) The IPP Client converts the 'ipps' URI to an 'https' URI [RFC7230] 223 (replacing 'ipps' with 'https' and inserting the port number from 224 the URI or port 631 if the URI doesn't include a port number); 226 3) The IPP Client establishes a TCP [STD7] transport layer connection 227 to the target endpoint - see section 3.4 'Establishing a 228 connection' in TCP [STD7]; 230 4) The IPP Client establishes a TLS/1.2 [RFC5246] or higher version 231 secure transport layer connection to the target endpoint - see 232 section 7 'The TLS Handshake Protocol' in [RFC5246]; 234 5) The IPP Client establishes an HTTPS [RFC7230] secure session layer 235 connection over the TLS secure transport layer to the target 236 endpoint; and 238 6) The IPP Client sends IPP application layer requests to and 239 receives responses from the IPP Printer over the HTTPS [RFC7230] 240 secure session layer connection using the POST method defined in 241 [RFC7231]. 243 4. Definition of 'ipps' URI Scheme 245 4.1. Applicability of 'ipps' URI Scheme 247 The 'ipps' URI scheme MUST only be used to specify absolute URI 248 (relative 'ipps' URI are not allowed) for IPP secure print services 249 and their associated network resources. The 'ipps' URI scheme MUST 250 only be used to specify the use of the abstract protocol defined in 251 IPP/1.1 Model and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version 252 2.0 Second Edition [PWG5100.12] over an HTTPS [RFC7230] transport, as 253 defined in this specification. Any other transport binding for IPP 254 would require a different URI scheme. 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 IPP Printers SHOULD NOT generate (or allow administrators to 283 configure) URI lengths above 255 octets, because many older IPP 284 Client implementations do not properly support these lengths. 286 'ipps' URI MUST be represented in absolute form. Absolute URI MUST 287 always begin with a scheme name followed by a colon. For definitive 288 information on URI syntax and semantics, see "Uniform Resource 289 Identifiers (URI) Generic Syntax and Semantics" [STD66]. This 290 specification adopts the definitions of "host", "port", and "query" 291 from [STD66]. This specification adopts the definition of 292 "absolute-path" from [RFC7230]. 294 The 'ipps' URI scheme syntax in ABNF [STD68] is defined as follows: 296 ipps-uri = 297 "ipps:" "//" host [ ":" port ] [ absolute-path [ "?" query ]] 299 If the port is empty or not given, then port 631 MUST be used. 301 See: Section 4.3 (port) of this document. 303 The semantics are that the identified resource (see [RFC7230]) is 304 located at the IPP secure print service listening for HTTPS 305 connections on that port of that host, and the Request-URI for the 306 identified resource is 'absolute-path'. 308 Note: The higher-level "authority" production is not imported from 309 [STD66], because it includes an optional "userinfo" component which 310 cannot be used in 'ipps' URI. 312 Note: The "query" production does not have defined semantics in IPP 313 and was never used in examples in IPP/1.1 Encoding and Transport 314 [RFC2910] or the original IPP URL Scheme [RFC3510]. The "query" is 315 retained here for consistency, but IPP Clients SHOULD avoid its use 316 (because the semantics could only be implementation-defined). 318 Note: Literal IPv4 or IPv6 addresses SHOULD NOT be used in 'ipps' 319 URI, because: 320 a) IP addresses are often changed after network device installation 321 (for example, based on DHCP reassignment after a power cycle); 322 b) IP addresses often don't map simply to security domains; 323 c) IP addresses are difficult to validate with X.509 server 324 certificates (because they do not map to common name or alternate 325 name attributes); and 326 d) IPv6 link local addresses are not "portable" due to link identity 328 If the 'absolute-path' is not present in the URI, it MUST be given as 329 "/" when used as a Request-URI for a resource (see [RFC7230]). 331 An 'ipps' URI is transformed into an 'https' URI by replacing "ipps:" 332 with "https:" and inserting port 631 (if the 'port' is not present in 333 the original 'ipps' URI). 335 See: Section 4.3 (port) of this document. 337 4.3. Associated Port for 'ipps' URI Scheme 339 All 'ipps' URI which do NOT explicitly specify a port MUST be 340 resolved to IANA-assigned well-known port 631, already registered in 341 [PORTREG] for IPP/1.1 Encoding and Transport [RFC2910]. 343 Note: Port 631 is used for both 'ipp' [RFC3510] and 'ipps' URI, both 344 of which refer to an IPP print service or a network resource managed 345 by such a service, for consistency with recent IETF best practices. 346 IPP Printer implementors can refer to the CUPS [CUPS] source code for 347 an example of incoming connection handling for the dual use of port 348 631. 350 For compatibility with existing IPP Client and IPP Printer 351 implementations, explicit port 443 (assigned in the 'https' URI 352 scheme [RFC7230]) MUST be accepted in 'ipps' URI and MUST be 353 processed normally by IPP Clients and IPP Printers. 355 See: IANA Port Numbers Registry [PORTREG]. 357 See: IPP/1.1 Encoding and Transport [RFC2910]. 359 4.4. Associated Media Type for 'ipps' URI Scheme 361 All 'ipps' URI MUST be used to specify secure print services which 362 support the "application/ipp" media type as registered in [MEDIAREG] 363 for IPP protocol requests and responses. 365 See: IANA Media Types Registry [MEDIAREG]. 367 See: IPP/1.1 Encoding and Transport [RFC2910]. 369 4.5. Character Encoding of 'ipps' URI Scheme 371 'ipps' URI MUST use the UTF-8 [STD63] charset for all components. 372 'ipps' URI MUST use [STD66] rules for percent encoding data octets 373 outside the US-ASCII coded character set [ASCII]. 375 4.6. 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 MUST 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.7 below). The fourth 'ipps' 411 URI above uses the explicit port 443 (see section 4.3 above). 413 See: Section 4.2 (syntax) and section 4.3 (port) of this document. 415 4.7. Comparisons of 'ipps' URI 417 When comparing two 'ipps' URI to decide if they match or not, an IPP 418 Client MUST use the same rules as those defined for 'http' and 419 'https' URI comparisons in [RFC7230], with the sole following 420 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 as specified in HTTP/1.1 [RFC7230]. 450 Encoding Considerations: See section 4.3 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 as specified in HTTP/1.1 [RFC7230]. Such applications may 458 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 are at greater risk than ever 493 before. This IPP over HTTPS transport binding and 'ipps' URI scheme 494 specification was defined to enable high availability combined with 495 secure operation (mandatory data integrity and negotiable data 496 confidentiality) in this dynamic environment (for example, wireless 497 hotspots in hotels, 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: 508 a) The network (to compromise the routing infrastructure, for 509 example, by creating congestion); 511 b) the Internet Printing Protocol (IPP) [RFC2911] (for example, to 512 compromise the normal behavior of IPP); or 514 c) 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 congestion 522 control). 524 b) against the IPP data flow itself (for example, by sending forged 525 packets or forcing TLS version downgrade); or 527 c) against the IPP operation parameters (for example, by corrupting 528 requested document processing attributes). 530 6.2. Attacks and Defenses 532 This 'ipps' URI Scheme specification adds the following additional 533 security considerations to those described in [RFC7230], [RFC2910], 534 [RFC2911], [RFC5246], [RFC7230], [PWG5100.12], and [STD66]. 536 See: Section 8 'Security Considerations' in [RFC2910]. 538 See: Section 8 'Security Considerations' in [RFC2911]. 540 See: Appendix D 'Implementation Notes', Appendix E 'Backward 541 Compatibility', and Appendix F 'Security Analysis' of [RFC5246]. 543 See: Section 10 'Security Considerations' in [PWG5100.12]. 545 See: Section 7 'Security Considerations' in [STD66]. 547 6.2.1. Faked 'ipps' URI 549 An 'ipps' URI might be faked to point to a rogue IPP secure print 550 service, thus collecting confidential document contents from IPP 551 Clients. 553 Server authentication mechanisms and security mechanisms specified in 554 IPP/1.1 Encoding and Transport [RFC2910], HTTP/1.1 [RFC7230], and 555 TLS/1.2 [RFC5246] can be used to address this threat. 557 6.2.2. Unauthorized Access by IPP Client 559 An 'ipps' URI might be used to access an IPP secure print service by 560 an unauthorized IPP Client. 562 Client authentication mechanisms and security mechanisms specified in 563 IPP/1.1 Encoding and Transport [RFC2910], HTTP/1.1 [RFC7230], and 564 TLS/1.2 [RFC5246] can be used to address this threat. 566 6.2.3. Compromise at Application Layer Gateway 568 An 'ipps' URI might be used to access an IPP secure print service at 569 a print protocol application layer gateway (for example, an IPP to 570 LPD [RFC1179] gateway [RFC2569]), potentially causing silent 571 compromise of IPP security mechanisms. 573 There is no general defense against this threat by an IPP Client. 574 System administrators SHOULD avoid such configurations. 576 6.2.4. No Client Authentication for 'ipps' URI 578 An 'ipps' URI does not define parameters to specify the required IPP 579 Client authentication mechanism (for example, 'certificate' as 580 defined in section 4.4.2 'uri-authentication-supported' of IPP Model 581 [RFC2911]). 583 Either service discovery or directory protocols SHOULD be used first 584 or an IPP Client SHOULD first establish an 'ipp' connection (without 585 TLS or any client authentication) to the target IPP Printer and use a 586 Get-Printer-Attributes query to discover the required IPP Client 587 authentication mechanism(s) associated with a given 'ipps' URI. 589 6.3. TLS Version Requirements 591 In according with security best practices and all existing 592 deployments of the 'ipps' URI scheme, IPP Clients and IPP Printers 593 that support this specification MUST use TLS/1.2 [RFC5246] or higher 594 version, for all 'ipps' secure transport layer connections. 596 7. Acknowledgments 598 This document has been submitted to the IETF by the Internet Printing 599 Protocol Working Group of the IEEE-ISTO Printer Working Group, as 600 part of their PWG IPP Everywhere [PWG5100.14] project for secure 601 mobile printing with vendor-neutral Client software. 603 This document defines an alternate IPP transport binding to that 604 defined in the original IPP URL Scheme [RFC3510], but this document 605 does not update or obsolete [RFC3510]. 607 Thanks to Claudio Allochio, Tom Hastings (retired from Xerox), Bjoern 608 Hoerhmann, Barry Leiba, S. Mooneswamy, Tom Petch, Jerry Thrasher 609 (Lexmark), Mykyta Yevstifeyev, Pete Zehler (Xerox), and the members 610 of the IEEE-ISTO PWG IPP WG. 612 8. References 614 8.1. Normative References 616 [ASCII] "American National Standards Institute, Coded Character 617 Set -- 7-bit American Standard Code for Information 618 Interchange", ANSI X3.4, 1986. 620 [HTTP1.1] HTTP/1.1. See [RFC7230], [RFC7231], [RFC7232], 621 [RFC7233], [RFC7234], and [RFC7235]. 623 [PWG5100.12] Bergman, R., Lewis, H., McDonald, I., and M. Sweet, 624 "Internet Printing Protocol Version 2.0 Second Edition 625 (IPP/2.0 SE)", PWG 5100.12, February 2011. 626 628 [PWG5100.14] McDonald, I. and M. Sweet, "PWG IPP Everywhere", PWG 629 5100.14, January 2013. 630 632 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 633 Requirement Levels, BCP 14, RFC 2119, March 1997. 635 [RFC2910] Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and 636 J. Wenn, "Internet Printing Protocol/1.1: Encoding and 637 Transport", RFC 2910, September 2000. 639 [RFC2911] Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S., 640 and P. Powell, "Internet Printing Protocol/1.1: Model and 641 Semantics", RFC 2911, September 2000. 643 [RFC5246] Dierks, T., and E. Rescorla, "The Transport Layer Security 644 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 646 [RFC7230] Fielding, R., and J. Reschke, "Hypertext Transfer Protocol 647 (HTTP/1.1): Message Syntax and Routing, RFC 7230, June 648 2014. 650 [RFC7231] Fielding, R., and J. Reschke, "Hypertext Transfer Protocol 651 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 653 [RFC7232] Fielding, R., and J. Reschke, "Hypertext Transfer Protocol 654 (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 656 [RFC7233] Fielding, R., Lafon, Y., and J. Reschke, "Hypertext 657 Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, 658 June 2014. 660 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 661 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 662 2014. 664 [RFC7234] Fielding, R., and J. Reschke, "Hypertext Transfer Protocol 665 (HTTP/1.1): Authentication", RFC 7235, June 2014. 667 [STD7] Postel, J., "Transmission Control Protocol", STD 7, RFC 668 793, September 1981. 670 [STD63] Yergeau, F., "UTF-8, a transformation format of ISO 671 10646", STD 63, RFC 3629, November 2003. 673 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, Uniform 674 Resource Identifiers (URI) Generic Syntax, STD 66, RFC 675 3986, January 2005. 677 [STD68] Crocker, D., Ed., and P. Overell, "Augmented BNF for 678 Syntax Specifications: ABNF", STD 68, RFC 5234, January 679 2008. 681 8.2. Informative References 683 [BCP35] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 684 Registration Procedures for New URI Schemes", BCP 35, RFC 685 4395, February 2006. 687 [CUPS] Apple, "CUPS standards-based, open source printing system 688 for OS X and other UNIX-like operating systems" 689 691 [MEDIAREG] Internet Assigned Numbers Authority (IANA) Registry "Media 692 Types" 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 [RFC2569] Herriot, R., Ed., Hastings, T., Jacobs, N., and J. 703 Martin, "Mapping between LPD and IPP Protocols", RFC 2569, 704 April 1999. 706 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 707 HTTP/1.1", RFC 2817, May 2000. 709 [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. 710 Holst, "Internet Printing Protocol/1.1: Implementor's 711 Guide", RFC 3196, November 2001. 713 [RFC3510] Herriot, R. and I. McDonald, "Internet Printing 714 Protocol/1.1: IPP URL Scheme", RFC 3510, April 2003. 716 9. Appendix A - Abbreviations 718 This document makes use of the following abbreviations (given with 719 their expanded forms and references for further reading): 721 ABNF - Augmented Backus-Naur Form [STD68] 723 ASCII - American Standard Code for Information Interchange [ASCII] 725 HTTP - HyperText Transfer Protocol [HTTP1.1] 727 HTTPS - HTTP over TLS [RFC7230] 729 IANA - Internet Assigned Numbers Authority 730 732 IEEE - Institute of Electrical and Electronics Engineers 733 735 IESG - Internet Engineering Steering Group 736 738 IPP - Internet Printing Protocol [RFC2911] and [PWG5100.12] 739 741 ISTO - IEEE Industry Standards and Technology Organization 742 744 LPD - Line Printer Daemon Protocol [RFC1179] 746 PWG - IEEE-ISTO Printer Working Group 747 749 RFC - Request for Comments 750 752 TCP - Transmission Control Protocol [STD7] 754 TLS - Transport Layer Security [RFC5246] 756 URI - Uniform Resource Identifier [STD66] 758 URL - Uniform Resource Locator [STD66] 760 UTF-8 - Unicode Transformation Format - 8-bit [STD63] 762 10. Appendix X - Change History 764 [RFC Editor: Delete this section before publication as an RFC] 766 27 October 2014 - draft-mcdonald-ipps-uri-scheme-15.txt 767 Editorial - Kept "Intended Status" as "Standards Track", with AD 768 sponsoring, per advice of Barry Leiba on 22 October 2014. 769 Editorial - Revised Abstract to delete mention of submission from 770 PWG, per advice of S. Mooneswamy on 13 October 2014 and Barry Leiba 771 on 22 October 2014. 772 Editorial - Revised Boilerplate to reflect IETF standards-track, per 773 advice of Barry Leiba on 22 October 2014. 774 Editorial - Revised Introduction and Acknowledgments to say "This 775 document has been submitted to IETF...", per advice of Barry Leiba on 776 22 October 2014. 777 Editorial - Replaced "this memo" with "this document", per advice of 778 S. Mooneswamy on 13 October 2014 and Barry Leiba on 22 October 2014. 779 Editorial - Replaced [RFC2818] with [RFC7230] for HTTPS and deleted 780 [RFC2818] from references, per advice of S. Mooneswamy on 13 October 781 2014. 782 Editorial - Revised section 1.1 Structure of this Document to correct 783 list of sections per revisions in this draft, per IEEE-ISTO PWG IPP 784 WG review, 785 Editorial - Kept section 2.2 Abbreviations to become Appendix A, as a 786 compromise to request to remove entirely, per discussion with 787 S. Mooneswamy on 13 October 2014. 788 Editorial - Revised section 3 IPP over HTTPS Transport Binding to 789 delete (redundant) first paragraph, per advice of S. Mooneswamy on 13 790 October 2014. 791 Editorial - Revised section 3 IPP over HTTPS Transport Binding to add 792 reference to [RFC7230] for 'https' URI scheme in bullet (2), per 793 advice of S. Mooneswamy on 13 October 2014. 794 Editorial - Revised section 3 IPP over HTTPS Transport Binding to 795 delete (redundant) "reliable" qualifier of a TCP transport layer 796 connection in bullet (3), per advice of S. Mooneswamy on 13 October 797 2014. 798 Editorial - Revised section 3 IPP over HTTPS Transport Binding to 799 replace "TLS 1.2 [RFC5246], or later TLS version," with "TLS 1.2 800 [RFC5246] or higher version" in bullet (4), consistent with TLS 801 future-proofing in current HTTP/2.0 draft, per IEEE-ISTO PWG IPP WG 802 review, rejecting request of S. Mooneswamy on 13 October 2014. 803 Editorial - Revised section 3 IPP over HTTPS Transport Binding to 804 delete (out-of-date) reference to [RFC2910] in bullet (6), per advice 805 of S. Mooneswamy on 13 October 2014. 806 Editorial - Revised section 3 IPP over HTTPS Transport Binding to 807 delete references to Security Considerations in other documents, per 808 advice of S. Mooneswamy on 13 October 2014. 809 Editorial - Revised section 4.1 Applicability of 'ipps' URI Scheme to 810 delete references to Security Considerations in other documents, per 811 advice of S. Mooneswamy on 13 October 2014. 812 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme to 813 replace out-of-date reference to [RFC2911] w/ [STD66] (i.e., RFC 814 3986), per advice of S. Mooneswamy on 13 October 2014. 815 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme to move 816 conformance requirement out of "Note" and rewrite conformance that 817 IPP Printers SHOULD NOT *generate* 'ipps' URI longer than 255 octets, 818 due to known implementation bugs in many older IPP Clients, per 819 advice of S. Mooneswamy on 13 October 2014. 820 Editorial - Revisions section 4.3 Associated Port for 'ipps' URI 821 Scheme to move conformance requirement out of "Note", per advice of 822 S. Mooneswamy on 13 October 2014. 823 Editorial - Revised section 4.4 and References to change "MIME type" 824 or "MIME media type" to "media type" and "[MIMEREG]"to "[MEDIAREG]", 825 per advice of Barry Leiba on 22 October 2014. 826 Editorial - Revised section 4.6.1 to correct plural/singular 827 confusion, per advice of Barry Leiba on 22 October 2014. 828 Editorial - Deleted section 4.6.2 Examples of 'ipps' URI for Jobs, 829 because IPP "job-uri" attribute will be deprecated in the future, per 830 IEEE-ISTO PWG IPP WG review. 831 Editorial - Delete section 5 Applicability of this Specification 832 because it was redundant with conformance imperatives in section 4, 833 per advice of S. Mooneswamy on 13 October 2014. 834 Editorial - Kept IESG as change controller in (former) section 6 IANA 835 Considerations (since the document remains standards-track), 836 rejecting request of S. Mooneswamy on 13 October 2014. 837 Editorial - Revised (former) section 7.3 TLS Version Requirements to 838 replace "TLS 1.2 [RFC5246], or later TLS version," with "TLS 1.2 839 [RFC5246] or higher version", consistent with TLS future-proofing in 840 current HTTP/2.0 draft, per IEEE-ISTO PWG IPP WG review, rejecting 841 request of S. Mooneswamy on 13 October 2014. 842 Editorial - Deleted Appendix A - Summary of IPP URL Scheme, due to 843 ambiguity and for future-proofing, per IEEE-ISTO PWG IPP WG review. 845 28 September 2014 - draft-mcdonald-ipps-uri-scheme-14.txt 846 Editorial - Kept "Intended Status" as "Standards Track", with AD 847 sponsoring, per advice of Barry Leiba on 18 August 2014. 848 Editorial - Revised Abstract, Boilerplate, and Introduction to state 849 that this document is an Independent Submission to the RFC Editor 850 Stream with IETF AD sponsoring, per advice of Barry Leiba on 18 851 August 2014. 852 Technical - Revised section 3 IPP over HTTPS Transport Binding, to 853 require TLS/1.2, or later TLS version, for all 'ipps' connections, 854 per IEEE-ISTO PWG IPP WG review. 855 Technical - Revised section 7.2.1 Faked 'ipps' URI and section 7.2.2 856 Unauthorized Access by IPP Client, to delete all references to 857 TLS/1.0 and TLS/1.1, per IEEE-ISTO PWG IPP WG review. 858 Technical - Renamed section 7.3 TLS Cipher Suite Requirements to TLS 859 Version Requirements and deleted all requirements for specific cipher 860 suites, per IEEE-ISTO PWG IPP WG review. 861 Technical - Revised section 9.1 Normative References, to delete all 862 references to TLS/1.0 and TLS/1.1, per IEEE-ISTO PWG IPP WG review. 864 3 July 2014 - draft-mcdonald-ipps-uri-scheme-13.txt 865 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, to 866 replace old 'path-absolute' from RFC 2616 with 'absolute-path' from 867 [RFC7230], per IEEE-ISTO PWG IPP WG review. 868 Editorial - Revised section 2.2 Abbreviations, section 3 IPP over 869 HTTPS Transport Binding, section 4.2 Syntax of 'ipps' URI Scheme, 870 section 4.7 Comparisons of 'ipps' URI, section 7.2 Attacks and 871 Defenses, section 9.1 Normative References, and section 10 Appendix A 872 - Summary of IPP URL Scheme, to replace [RFC2616] with either 873 [RFC7230] or [HTTP1.1] - a new collective reference to [RFC7230], 874 [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235], per 875 IEEE-ISTO PWG IPP WG review. 877 20 April 2014 - draft-mcdonald-ipps-uri-scheme-12.txt 878 Editorial - Revised section 4.3 Associated Port for 'ipps' URI 879 Scheme, to add informative reference to CUPS, per IEEE-ISTO PWG IPP 880 WG review. 882 Editorial - Revised section 4.6.1 Examples of 'ipps' URI for 883 Printers, to change "third" to "fourth" for the port 443 example, per 884 IEEE-ISTO PWG IPP WG review. 885 Editorial - Revised section 6 IANA Considerations, to add informative 886 reference to CUPS, per IEEE-ISTO PWG IPP WG review. 888 Editorial - Revised section 9.2 Informative References, to add 889 informative reference to CUPS, per IEEE-ISTO PWG IPP WG review. 891 7 April 2014 - draft-mcdonald-ipps-uri-scheme-11.txt 892 Global - revised all references to section 4.2 and section 4.3, to 893 add parenthetic (syntax) and (port) respectively, per IEEE-ISTO PWG 894 IPP WG review. 895 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, to 896 correct two typos (extra words) in section 4.3 references, per 897 IEEE-ISTO PWG IPP WG review. 898 Editorial - Revised section 4.3 Associated Port for 'ipps' URI 899 Scheme, to add note about compatibility for IPP Clients and IPP 900 Printers that MUST accept explicit port 443 (assigned in 'https' URI 901 scheme [RFC7230]) and process normally, per IEEE-ISTO PWG IPP WG 902 review. 903 Editorial - Revised section 4.6.1 Examples of 'ipps' URI for 904 Printers, to add example of explicit port 443, per IEEE-ISTO PWG IPP 905 WG review. 907 30 March 2014 - draft-mcdonald-ipps-uri-scheme-10.txt 908 Global - Updated references, per IEEE-ISTO PWG IPP WG review. 909 Global - Changed "e.g." to "for example", for readability. 910 Editorial - Revised section Copyright Notice, to correct year. 911 Editorial - Revised section 3 IPP over HTTPS Transport Binding, item 912 2), to clarify that port 631 is ONLY inserted in the derived 'https' 913 URI when an explicit port is NOT specified in the original 'ipps' 914 URI, per Smith Kennedy and IEEE-ISTO PWG IPP WG review. 915 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, note 916 about URI lengths greater than 255 octets, to change 'ought to' to 917 'SHOULD', per Smith Kennedy and IEEE-ISTO PWG IPP WG review. 918 Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, to add 919 reference to section 4.3 for use of port 631, per Smith Kennedy and 920 IEEE-ISTO PWG IPP WG review. 921 Editorial - Revised section 4.3 Associated Port for 'ipps' URI 922 Scheme, to add note about dual-use of port 631 for 'ipp' URI and 923 'ipps' URI with reference to CUPS source for example of incoming 924 connection handling, per Smith Kennedy and IEEE-ISTO PWG IPP WG 925 review. 926 Editorial - Revised section 4.3 Associated Port for 'ipps' URI 927 Scheme, to add note about compatibility for IPP Clients and IPP 928 Printers that should accept explicit port 443 (assigned in 'https' 929 URI scheme [RFC7230]) and process normally, per IEEE-ISTO PWG IPP WG 930 review. 931 Editorial - Revised section 4.6.1 Examples of 'ipps' URI for 932 Printers, to add reference to section 4.2 (syntax) and section 4.3 933 (port), per Smith Kennedy and IEEE-ISTO PWG IPP WG review. 934 Editorial - Revised section 4.7 Comparisons of 'ipps' URI, to add 935 reference to section 4.3 (port), per Smith Kennedy and IEEE-ISTO PWG 936 IPP WG review. 938 Editorial - Revised section 5.1 Applicability to IPP Clients, to add 939 reference to section 4.2 (syntax) and section 4.3 (port), per Smith 940 Kennedy and IEEE-ISTO PWG IPP WG review. 941 Editorial - Revised section 5.1 Applicability to IPP Clients, item 942 d), to change 'MUST the' to 'MUST use the', per Smith Kennedy and 943 IEEE-ISTO PWG IPP WG review. 944 Editorial - Revised section 5.2 Applicability to IPP Printers, to add 945 reference to section 4.2 (syntax) and section 4.3 (port), per Smith 946 Kennedy and IEEE-ISTO PWG IPP WG review. 947 Editorial - Revised section 5.2 Applicability to IPP Printers, item 948 d), to change 'MUST the' to 'MUST use the', per Smith Kennedy and 949 IEEE-ISTO PWG IPP WG review. 950 Editorial - Revised section 5.2 Applicability to IPP Printers, to 951 delete former item e) (listen only on port 631) which conflicted with 952 existing IPP implementations (for example, listening on port 443 as 953 well), per Smith Kennedy and IEEE-ISTO PWG IPP WG review. 954 Editorial - Revised section 6 IANA Considerations, to add URI for 955 CUPS source, per IEEE-ISTO PWG IPP WG review. 956 Editorial - Revised section 7.2.4 No Client Authentication for 'ipps' 957 URI, to change "or or" to "or" (typo), per Smith Kennedy and 958 IEEE-ISTO PWG IPP WG review. 959 Editorial - Revised Appendix A Summary of IPP URL Scheme, item 2), to 960 clarify that port 631 is ONLY inserted in the derived 'http' URI when 961 an explicit port is NOT specified in the original 'ipp' URI, per 962 Smith Kennedy and IEEE-ISTO PWG IPP WG review. 964 5 November 2013 - draft-mcdonald-ipps-uri-scheme-09.txt 965 Global - Updated references, per IPP WG review. 966 Editorial - Revised Abstract, section 1 Introduction, and section 8 967 Acknowledgments to clarify that this document is an individual 968 submission to the IETF by the IPP WG of the IEEE-ISTO PWG, per 969 S. Mooneswamy. 970 Editorial - Revised Abstract, section 1 Introduction, and section 8 971 Acknowledgments to clarify that this document does not update or 972 obsolete [RFC3510], per S. Mooneswamy and Tom Petch. 973 Editorial - Revised section 1.1 Structure of this Document to align 974 with changes below, per Tom Petch. 975 Editorial - Revised section 2 Conventions Used in this Document to 976 add section 2.1 Printing Terminology and to remove redundant "In this 977 document" and clarify definitions, per Tom Petch. 978 Editorial - Moved former Appendix B - Abbreviations Used in this 979 Document to become section 2.2 Abbreviations, per Tom Petch. 980 Technical - Revised section 3 IPP over HTTPS Transport Binding, 981 section 5 Applicability of this Specification, and section 7 Security 982 Considerations to address specific TLS/1.0 [RFC2246], TLS/1.1 983 [RFC4346], and TLS/1.2 [RFC5246] requirements, per Tom Petch. 984 Editorial - Moved former section 3.1 IPP over HTTP Transport Binding 985 to become Appendix A - Summary of IPP URL Scheme (Informative), per 986 Tom Petch. 987 Technical - Revised section 4.2 Syntax of 'ipps' URI Scheme to add 988 note about the retention of the (unused) "query" production for 989 consistency with IPP/1.1 Encoding and Transport [RFC2910] and the 990 original IPP URL Scheme [RFC3510], but warn that it has no defined 991 semantics in IPP and therefore its use is unsafe for IPP Clients, per 992 Tom Petch. 993 Technical - Revised section 7 Security Considerations to add section 994 8.1 Problem Statement, section 8.2 Attacks, and section 8.3 TLS 995 Security Considerations, per Tom Petch. 996 Editorial - Moved former section Appendix A - Acknowledgments to 997 become section 8 Acknowledgements (in body of document) and updated 998 to reflect recent comments on this document, per Tom Petch. 999 Technical - Revised section 9.1 Normative References to add TLS/1.0 1000 [RFC2246] and TLS/1.1 [RFC4346], per Tom Petch. 1002 19 September 2013 - draft-mcdonald-ipps-uri-scheme-08.txt 1003 Global - Updated references, per IPP WG review. 1005 12 May 2013 - draft-mcdonald-ipps-uri-scheme-07.txt 1006 Editorial - Revised section 1 (introduction) to add 'Rationale for 1007 this document', per Smith Kennedy. 1008 Editorial - Global - Changed 'Conformance Requirements' to 1009 'Applicability', per Barry Leiba. 1010 Editorial - Global - Changed '[PWG5100.EW]' to '[PWG5100.14]', 1011 corrected date and URI, and moved section 8.1 (normative references), 1012 per IPP WG review. 1014 10 November 2012 - draft-mcdonald-ipps-uri-scheme-06.txt 1015 Editorial - Global - Fixed typos and indentation, per IPP WG review. 1016 Editorial - Global - changed 'generic drivers' to 'vendor-neutral 1017 Client software', per IPP WG review. 1018 Editorial - Revised section 8.2 (informative references, to correct 1019 title of "PWG IPP Everywhere" (i.e., delete version number), per IPP 1020 WG review. 1022 14 May 2012 - draft-mcdonald-ipps-uri-scheme-05.txt 1023 Editorial - Global - Fixed typos and indentation, per IPP WG review. 1024 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to 1025 insert missing "to" in "connection to the target endpoint", per IPP 1026 WG review. 1027 Editorial - Revised section 4.2 (syntax), to correct indentation of 1028 first "Note:", per IPP WG review. 1029 Editorial - Revised sections 5.1 and 5.2 (client/printer conformance) 1030 and section 7 (security considerations) to delete the out-of-scope 1031 normative references to [RFC2817], per IPP WG review. 1033 22 November 2011 - draft-mcdonald-ipps-uri-scheme-04.txt 1034 Editorial - Global - Fixed typos and indentation, per IPP WG review. 1035 Editorial - Revised Introduction and Acknowledgments to say 'project 1036 for mobile, ubiquitous printing with generic drivers', per IPP WG 1037 review. 1038 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to add 1039 references to HTTP POST and section 4 of RFC 2910, per IPP WG review. 1041 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to add 1042 section references to all well-known standards (connection setup, 1043 etc.), per IPP WG review. 1044 Editorial - Revised section 4.2 (syntax) to move note from from 1045 section 4.6 (examples) and explain why literal IP addresses SHOULD 1046 NOT be used in 'ipps' URI, per IPP WG review. 1047 Editorial - Revised sections 4.6.1 and 4.6.2 (examples) to replace 1048 'abc.com' w/ 'example.com' (per IETF) and replace '/printer' path 1049 element w/ '/ipp' (better practice), per IPP WG review. 1050 Editorial - Revised section 5.2 (Printer conformance) to fold former 1051 (c) and (d) into a single requirement for standard port 631 and 1052 reordered other requirements to group MUSTs before SHOULDs, per IPP 1053 WG review. 1054 Editorial - Revised section 5.2 (Printer conformance) to add backward 1055 reference to section 4.2 for rationale for not using IP literal 1056 addresses, per IPP WG review. 1057 Editorial - Revised section 6 (IANA) to explicitly state that 'ipps' 1058 uses secure communications using HTTP over TLS, per IPP WG review. 1059 Editorial - Revised section 7 (Security) to cleanup numerous loose 1060 ends, per IPP WG review. 1061 Editorial - Revised section 8 (References) to cleanup typos and 1062 links, per IPP WG review. 1063 Editorial - Revised section 1 (introduction), section 8.2 1064 (informative references, and section 9 (appendix A) to change 1065 "[IPPEVE]" to "[PWG5100.EW]", per IPP WG review. 1067 26 August 2011 - draft-mcdonald-ipps-uri-scheme-03.txt 1068 Editorial - Revised Abstract and Introduction to state published by 1069 the IETF on behalf of IEEE-ISTO PWG (to avoid status ambiguity), per 1070 Mykyta Yevstifeyev. 1071 Editorial - Revised section 1 to list all currently defined versions 1072 of IPP in RFC 2566, RFC 2911, and PWG 5100.12, per Mykyta 1073 Yevstifeyev. 1074 Technical - Revised section 1, section 2, section 3.2, section 4.1, 1075 and section 7, to reference IPP Version 2.0 Second Edition (PWG 1076 5100.12), per Mykyta Yevstifeyev. 1077 Editorial - Revised section 3.1, to fix broken STD7 reference, per 1078 Mykyta Yevstifeyev. 1079 Editorial - Revised section 6, to add BCP35 reference for template 1080 (regression loss when the template was moved up from former 1081 appendix), per Mykyta Yevstifeyev. 1082 Editorial - Revised section 8.1 to add PWG 5100.12 (normative), 1083 Editorial - Revised section 8.2 to add PWG IPP Everywhere 1084 (informative) and RFC 1179 (informative), per Mykyta Yevstifeyev. 1085 Editorial - Revised appendix B to add references for more reading, 1086 per Mykyta Yevstifeyev. 1088 28 February 2011 - draft-mcdonald-ipps-uri-scheme-02.txt 1089 Editorial - Revised document title to emphasize IPP over HTTPS 1090 Transport Binding (reason for IETF standards-track status). 1092 Editorial - Replaced "IPP URI" with "'ipp' URI", "IPPS URI" with 1093 "'ipps' URI", "HTTP URI" with "'http' URI", and "HTTPS URI" with 1094 "'https' URI" throughout this document for conformance to section 3.1 1095 of [STD66], per Mykyta Yevstifeyev. 1096 Editorial - Revised and simplified Abstract, per Mykyta Yevstifeyev. 1097 Editorial - Revised and simplified section 1 'Introduction', per 1098 Mykyta Yevstifeyev. 1099 Editorial - Renamed section 2 from 'Conformance Terminology' to 1100 'Conventions Used in this Document', per Mykyta Yevstifeyev. 1101 Editorial - Moved former section 3.1 'IPP Model Terminology 1102 (Normative)' content into section 2 'Conventions Used in this 1103 Document' for readability, per Mykyta Yevstifeyev. 1104 Editorial - Reordered subsections and reversed word order in all 1105 subsection titles in section 4 'The 'ipps' URI Scheme' for 1106 readability, per Mykyta Yevstifeyev. 1107 Editorial - Added note to section 4.2 'Syntax of 'ipps' URI Scheme' 1108 to explain why 'authority' production is NOT imported from [STD66], 1109 because it includes an optional 'userinfo' component which cannot be 1110 used in 'ipps' URI values. 1111 Editorial - Deleted note describing empty 'host' component from 1112 section 4.2 'Syntax of 'ipps' URI Scheme', because 'host' component 1113 is mandatory in [STD66]. 1114 Editorial - Deleted 'Internationalization Considerations' section 1115 which was redundant with section 4.3 'Character Encoding of 'ipps' 1116 URI Scheme', per Mykyta Yevstifeyev. 1117 Editorial - Revised all references to follow current RFC Editor 1118 style, per Mykyta Yevstifeyev. 1119 Editorial - Moved former 'Appendix A - Registration of IPPS URI 1120 Scheme' content inline into section 6 'IANA Considerations', per 1121 Mykyta Yevstifeyev. 1122 Editorial - Moved former body section 'Acknowledgements' to 'Appendix 1123 A - Acknowledgements', per Mykyta Yevstifeyev. 1124 Editorial - Added new 'Appendix B - Abbreviations Used in this 1125 Document' for readability, per Mykyta Yevstifeyev. 1126 Editorial - Moved section 'Authors' Addresses' to end of document, 1127 per Mykyta Yevstifeyev. 1129 1 December 2010 - draft-mcdonald-ipps-uri-scheme-01.txt 1130 - Technical - added UTF-8 [STD63] as required charset for all IPPS 1131 URI in section 4.4 and section 7, per Bjoern Hoehrmann. 1132 - Technical - corrected percent encoding for data octets outside the 1133 US-ASCII range in section 4.4 and section 7, per Bjoern Hoehrmann. 1134 - Editorial - global - changed "[RFC4395]" to "[BCP35]", changed 1135 "[RFC3629]" to "[STD63]", changed "[RFC3986]" to "[STD66]", and 1136 changed "[RFC5234]" to "[STD68]", per Bjoern Hoehrmann. 1137 - Editorial - restored trailing "]]" in ABNF syntax in section 4.5, 1138 per Bjoern Hoehrmann. 1139 - Editorial - changed "Author/Change controller" to "IESG" in section 1140 12 Appendix A registration template, as required by section 5.3 of 1141 [BCP35], per Bjoern Hoehrmann. 1143 10 October 2010 - draft-mcdonald-ipps-uri-scheme-00.txt 1144 - Editorial - complete rewrite of RFC 3510 for new transport binding 1145 - Editorial - moved Abstract to beginning of first page, per ID-Nits 1146 - Editorial - fixed copyright, boilerplate, and typos, per ID-Nits 1147 - Editorial - added references to RFCs 2119 and 3510, per ID-Nits 1148 - Editorial - deleted obsolete references to RFCs 2246 and 4346, per 1149 ID-Nits 1150 - Technical - changed Intended Status to Standards Track to reflect 1151 the new normative IPPS URI scheme and transport binding 1152 - Technical - added section 3.2 IPP over HTTP Transport Binding 1153 (informative) 1154 - Technical - added section 3.3 IPP over HTTPS Transport Binding 1155 (normative) 1156 - Technical - updated section 5 Conformance Requirements to require 1157 HTTP Upgrade (RFC 2817) support (for interoperability with existing 1158 IPP implementations), per discussion on IPP WG mailing list 1159 - Editorial - updated Appendix A w/ registration template from RFC 1160 4395 1162 11. Authors' Addresses 1164 Ira McDonald 1165 High North Inc 1166 221 Ridge Ave 1167 Grand Marais, MI 49839 1169 Phone: +1 906-494-2434 1170 Email: blueroofmusic@gmail.com 1172 Michael Sweet 1173 Apple Inc 1174 10431 N De Anza Blvd, M/S 38-4LPT 1175 Cupertino, CA 95014 1177 Phone: +1 408-974-8798 1178 Email: msweet@apple.com 1180 Usage questions and comments on this 'ipps' URI Scheme can be sent 1181 directly to the editors at their above addresses and also to the PWG 1182 IPP WG mailing list. Instructions for subscribing to the PWG IPP WG 1183 mailing list can be found at: 1185 PWG IPP WG Web Page: http://www.pwg.org/ipp/ 1186 PWG IPP WG Mailing List: ipp@pwg.org 1187 PWG IPP WG Subscription: http://www.pwg.org/mailhelp.html 1188 Implementers of this specification are encouraged to join the PWG IPP 1189 WG Mailing List in order to participate in any discussions of 1190 clarification issues and comments. Note that this IEEE-ISTO PWG 1191 mailing list rejects mail from non-subscribers (in order to reduce 1192 spam).