idnits 2.17.1 draft-mcdonald-ipps-uri-scheme-07.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. 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 (12 May 2013) is 4001 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 117, but not defined ** Obsolete undefined reference: RFC 2566 (Obsoleted by RFC 2911) == Missing Reference: 'RFC 2817' is mentioned on line 162, but not defined == Missing Reference: 'RFC 2717' is mentioned on line 157, but not defined ** Obsolete undefined reference: RFC 2717 (Obsoleted by RFC 4395) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2910 (Obsoleted by RFC 8010) ** Obsolete normative reference: RFC 2911 (Obsoleted by RFC 8011) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 793 (ref. 'STD7') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4395 (ref. 'BCP35') (Obsoleted by RFC 7595) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ira McDonald 3 INTERNET-DRAFT High North Inc 4 Updates: 2910, 2911 (if approved) Michael Sweet 5 Intended Status: Standards Track Apple Inc 6 Expires: 12 November 2013 12 May 2013 8 IPP over HTTPS Transport Binding and 'ipps' URI Scheme 9 draft-mcdonald-ipps-uri-scheme-07.txt 11 Abstract 13 This memo defines the Internet Printing Protocol (IPP) over HTTPS 14 transport binding and the corresponding 'ipps' URI scheme, that is 15 used to designate the access to the network location of a secure IPP 16 print service or a network resource (for example, a print job) 17 managed by such a service. 19 This memo is published by the IETF on behalf of the Internet Printing 20 Protocol Working Group of the IEEE-ISTO Printer Working Group. 22 This memo 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 12 November 2013. 45 Copyright Notice 47 Copyright (c) 2012 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 ............................................... 3 63 1.1. Structure of this document ............................. 3 64 1.2. Rationale for this document ............................ 4 65 2. Conventions Used in this Document .......................... 4 66 3. IPP Transport Bindings ..................................... 5 67 3.1. IPP over HTTP Transport Binding (Informative) .......... 5 68 3.2. IPP over HTTPS Transport Binding (Normative) ........... 6 69 4. Definition of 'ipps' URI Scheme ............................ 7 70 4.1. Applicability of 'ipps' URI Scheme ..................... 7 71 4.2. Syntax of 'ipps' URI Scheme ............................ 7 72 4.3. Associated Port for 'ipps' URI Scheme .................. 9 73 4.4. Associated MIME Type for 'ipps' URI Scheme ............. 9 74 4.5. Character Encoding of 'ipps' URI Scheme ................ 9 75 4.6. Examples of 'ipps' URI ................................. 9 76 4.6.1. Examples of 'ipps' URI for Printers ................ 9 77 4.6.2. Examples of 'ipps' URI for Jobs .................... 10 78 4.7. Comparisons of 'ipps' URI .............................. 11 79 5. Applicability of this Specification ........................ 11 80 5.1. Applicability to IPP Clients ........................... 11 81 5.2. Applicability to IPP Printers .......................... 12 82 6. IANA Considerations ........................................ 13 83 7. Security Considerations .................................... 14 84 8. References ................................................. 15 85 8.1. Normative References ................................... 15 86 8.2. Informative References ................................. 16 87 9. Appendix A - Acknowledgments ............................... 17 88 10. Appendix B - Abbreviations Used in this Document .......... 17 89 11. Appendix X - Change History ............................... 18 90 12. Authors' Addresses ........................................ 21 91 1. Introduction 93 This memo defines the Internet Printing Protocol (IPP) over HTTPS 94 transport binding and the corresponding 'ipps' URI scheme, that is 95 used to designate the access to the network location of a secure IPP 96 print service or a network resource (for example, a print job) 97 managed by such a service. Therefore, this memo defines 'ipps' URI 98 scheme applicability, associated port, associated MIME type, 99 character encoding, and syntax. 101 This memo updates: 102 a) IPP/1.1 Encoding and Transport [RFC2910], by extending section 4 103 'Encoding of the Transport Layer', section 5 'IPP URL Scheme', and 104 section 8.2 'Using IPP with TLS'; 105 b) IPP/1.1 Model and Semantics [RFC2911], by extending section 4.1.6 106 'uriScheme' and section 4.4.1 'printer-uri-supported'; and 107 c) IEEE-ISTO PWG IPP Version 2.0 Second Edition [PWG5100.12], by 108 extending section 4 'IPP Standards' and section 10 'Security 109 Considerations'. 111 This memo is published by IETF on behalf of the Internet Printing 112 Protocol Working Group of the IEEE-ISTO Printer Working Group, as 113 part of their PWG IPP Everywhere [PWG5100.14] project for secure 114 mobile printing with vendor-neutral Client software. 116 The following versions of IPP are currently defined: 117 - 1.0 in [RFC2566] (obsolete) 118 - 1.1 in [RFC2911] 119 - 2.0 in [PWG5100.12] 120 - 2.1 in [PWG5100.12] 121 - 2.2 in [PWG5100.12] 123 Overview information about IPP is available in section 1 of RFC 2911 124 [RFC2911], section 1 of RFC 3196 [RFC3196], and section 1 of PWG IPP 125 Version 2.0 Second Edition [PWG5100.12]. 127 1.1. Structure of this document 129 This document contains the following sections: Section 2 defines the 130 conventions used throughout the document. 132 Section 3 defines the IPP over HTTPS transport binding, after first 133 summarizing the original IPP over HTTP transport binding. 135 Section 4 defines the 'ipps' URI scheme. 137 Section 5 defines the applicability of this specification to IPP 138 Clients and IPP Printers. 140 Sections 6 and 7 contain IANA and security considerations, 141 respectively. 143 Section 8 contains references. 145 Appendix A contains acknowledgments and Appendix B explains 146 abbreviations used in this document. 148 1.2. Rationale for this document 150 The 'ipps' URI scheme was defined for the following reasons: 152 1) Many existing IPP Client and IPP Printer implementations of 153 Upgrading to TLS Within HTTP/1.1 [RFC 2817] are flawed and 154 unreliable. 156 2) Some existing IPP Client and IPP Printer implementations of HTTP 157 Upgrade [RFC 2717] do not perform upgrade at the beginning of 158 every HTTP connection, but instead only shift to secure IPP for 159 selected IPP operations (inherently dangerous behavior on the same 160 underlying TCP connection). 162 3) IPP Printer server-mandated HTTP Upgrade [RFC 2817] can still lead 163 to exposure of IPP Client data if the Expect request header is not 164 used - basically the IPP Client can send its whole Print-Job 165 request before the IPP Printer has a chance to respond and say, 166 "Wait! You need to encrypt first!" 168 2. Conventions Used in this Document 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 174 The reader of this document should be familiar with the terminology 175 in IPP/1.1 Model and Semantics [RFC2911] (particularly, with the 176 definition of 'IPP Objects', 'Printer Object' and 'Job Object'), 177 abbreviations described in Appendix B and the following terms. 179 In this document, "IPP Client" means the software (on some hardware 180 platform) that submits, monitors, and/or manages secure print jobs 181 via the IPP/1.1 Encoding and Transport [RFC2910] or IEEE-ISTO PWG IPP 182 Version 2.0 Second Edition [PWG5100.12] to a secure print spooler, 183 secure print gateway, or secure physical printing device. 185 In this document, "IPP Printer object" means the software (on some 186 hardware platform) that receives secure print jobs and/or secure 187 printer/job operations via the IPP/1.1 Encoding and Transport 188 [RFC2910] or IEEE-ISTO PWG IPP Version 2.0 Second Edition 189 [PWG5100.12] from an "IPP Client". 191 In this document, "IPP Printer" is a synonym for "IPP Printer 192 object". 194 In this document, "IPP Job object" means the set of attributes and 195 documents for one secure print job instantiated on an "IPP Printer". 197 In this document, "IPP Job" is a synonym for "IPP Job object". 199 In this document, "'ipps' URI" means a URI using the 'ipps' URI 200 scheme defined in section 4 of this specification. 202 3. IPP Transport Bindings 204 3.1. IPP over HTTP Transport Binding (Informative) 206 This section is informative. 208 When using an 'ipp' URI [RFC3510], an IPP Client establishes an IPP 209 application layer connection according to the following sequence: 211 1) The IPP Client selects an 'ipp' URI value from 212 "printer-uri-supported" Printer attribute [RFC2911], a directory 213 entry, discovery info, a web page, etc.; 215 2) The IPP Client converts the 'ipp' URI to an 'http' URI (replacing 216 'ipp' with 'http' and inserting port 631); 218 3) The IPP Client establishes a TCP [STD7] reliable transport layer 219 connection to the target endpoint - see section 3.4 'Establishing 220 a connection' in TCP [STD7]; 222 4) The IPP Client establishes an HTTP [RFC2616] session layer 223 connection to the target endpoint - see section 8 'Connections' in 224 HTTP/1.1 [RFC2616]; 226 5) Optionally, either the IPP Client upgrades to TLS within HTTP/1.1 227 per section 3 'Client Requested Upgrade to HTTP over TLS' of 228 [RFC2817] or the IPP Printer upgrades to TLS within HTTP/1.1 per 229 section 4 'Server Requested Upgrade to HTTP over TLS' of 231 [RFC2817], in order to establish a TLS Protocol [RFC5246] secure 232 transport sublayer within the original TCP/HTTP connection - per 233 the "uri-security-supported" (section 4.4.3 in [RFC2911]) Printer 234 attribute value parallel to the "printer-uri-supported" (see 235 section 4.4.1 in [RFC2911]) value that matches this connection; 236 and 238 6) The IPP Client sends IPP application layer requests to and 239 receives responses from the IPP Printer over the HTTP [RFC2616] 240 session layer connection using the POST method defined in section 241 9.5 of HTTP/1.1 [RFC2616], as specified in section 4 'Encoding of 242 Transport Layer' in IPP/1.1 Encoding and Transport [RFC2910]. 244 See: Section 8 'Security Considerations' in [RFC2817]. 246 3.2. IPP over HTTPS Transport Binding (Normative) 248 This section is normative. 250 This document defines the following IPP over HTTPS alternate 251 transport binding for the abstract protocol defined in IPP/1.1 Model 252 and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version 2.0 Second 253 Edition [PWG5100.12]. 255 When using an 'ipps' URI, an IPP Client MUST establish an IPP 256 application layer connection according to the following sequence: 258 1) The IPP Client selects an 'ipps' URI value from 259 "printer-uri-supported" Printer attribute [RFC2911], a directory 260 entry, discovery info, a web page, etc.; 262 2) The IPP Client converts the 'ipps' URI to an 'https' URI 263 (replacing 'ipps' with 'https' and inserting port 631); 265 3) The IPP Client establishes a TCP [STD7] reliable transport layer 266 connection to the target endpoint - see section 3.4 'Establishing 267 a connection' in TCP [STD7]; 269 4) The IPP Client establishes a TLS [RFC5246] secure transport layer 270 connection to the target endpoint - see section 7 'The TLS 271 Handshaking Protocols' in TLS [RFC5246]; 273 5) The IPP Client establishes an HTTPS [RFC2818] secure session layer 274 connection over the TLS [RFC5246] secure transport layer to the 275 target endpoint; and 277 6) The IPP Client sends IPP application layer requests to and 278 receives responses from the IPP Printer over the HTTPS [RFC2818] 279 secure session layer connection using the POST method defined in 280 section 9.5 of HTTP/1.1 [RFC2616], as specified in section 4 281 'Encoding of Transport Layer' in IPP/1.1 Encoding and Transport 282 [RFC2910]. 284 See: Section 'Security Considerations' in [RFC2818]. 286 4. Definition of 'ipps' URI Scheme 288 4.1. Applicability of 'ipps' URI Scheme 290 The 'ipps' URI scheme MUST only be used to specify absolute URI 291 (relative 'ipps' URI are not allowed) for IPP secure print services 292 and their associated network resources. The 'ipps' URI scheme MUST 293 only be used to specify the use of the abstract protocol defined in 294 IPP/1.1 Model and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version 295 2.0 Second Edition [PWG5100.12] over an HTTPS [RFC2818] transport, as 296 defined in this specification. Any other transport binding for IPP 297 would require a different URI scheme. 299 The 'ipps' URI scheme allows an IPP Client to choose an appropriate 300 IPP secure print service (for example, from a directory). The IPP 301 Client can establish an HTTPS connection to the specified IPP secure 302 print service. The IPP Client can send IPP protocol requests (for 303 example, 'Print-Job' requests) and receive IPP protocol responses 304 over that HTTPS connection. 306 See: Section 3.2 of this document. 308 See: Section 4.4.1 'printer-uri-supported' in IPP/1.1 Model and 309 Semantics [RFC2911]. 311 See: Section 5 'IPP URL Scheme' in IPP/1.1 Encoding and Transport 312 [RFC2910]. 314 See: Section 4 'IPP Standards' and section 10 'Security 315 Considerations' of IEEE-ISTO PWG IPP Version 2.0 Second Edition 316 [PWG5100.12]. 318 4.2. Syntax of 'ipps' URI Scheme 320 The abstract protocol defined in IPP/1.1 Model and Semantics 321 [RFC2911] places a limit of 1023 octets (NOT characters) on the 322 length of a URI. 324 See: Section 4.1.5 'uri' in [RFC2911]. 326 Note: IPP Printers ought to be cautious about depending on URI 327 lengths above 255 bytes, because some older IPP Client 328 implementations might not properly support these lengths. 330 'ipps' URI MUST be represented in absolute form. Absolute URI MUST 331 always begin with a scheme name followed by a colon. For definitive 332 information on URI syntax and semantics, see "Uniform Resource 333 Identifiers (URI) Generic Syntax and Semantics" [STD66]. This 334 specification adopts the definitions of "host", "port", 335 "path-absolute", and "query" from [STD66]. 337 The 'ipps' URI scheme syntax in ABNF [STD68] is defined as follows: 339 ipps-uri = 340 "ipps:" "//" host [ ":" port ] [ path-absolute [ "?" query ]] 342 Note: The higher-level production "authority" is not imported from 343 [STD66], because it includes an optional "userinfo" component which 344 cannot be used in 'ipps' URI. 346 If the port is empty or not given, then port 631 MUST be used. The 347 semantics are that the identified resource (see section 5.1.2 of 348 [RFC2616]) is located at the IPP secure print service listening for 349 HTTPS connections on that port of that host, and the Request-URI for 350 the identified resource is 'path-absolute'. 352 Note: Literal IPv4 or IPv6 addresses SHOULD NOT be used in 'ipps' 353 URI, because: 354 a) IP addresses are often changed after network device installation 355 (e.g., based on DHCP reassignment after a power cycle); 356 b) IP addresses often don't map simply to security domains; 357 c) IP addresses are difficult to validate with X.509 server 358 certificates (because they do not map to common name or alternate 359 name attributes); and 360 d) IPv6 link local addresses are not "portable" due to link identity 362 If the 'path-absolute' is not present in the URI, it MUST be given as 363 "/" when used as a Request-URI for a resource (see section 5.1.2 of 364 [RFC2616]). 366 An 'ipps' URI is transformed into an 'https' URI by replacing "ipps:" 367 with "https:" and inserting port 631 (if the 'port' is not present in 368 the original 'ipps' URI). 370 See: Section 3.2 of this document. 372 4.3. Associated Port for 'ipps' URI Scheme 374 All 'ipps' URI which do NOT explicitly specify a port MUST be 375 resolved to IANA-assigned well-known port 631, as registered in 376 [PORTREG]. 378 See: IANA Port Numbers Registry [PORTREG]. 380 See: IPP/1.1 Encoding and Transport [RFC2910]. 382 4.4. Associated MIME Type for 'ipps' URI Scheme 384 All 'ipps' URI MUST be used to specify secure print services which 385 support the "application/ipp" MIME media type as registered in 386 [MIMEREG] for IPP protocol requests and responses. 388 See: IANA MIME Media Types Registry [MIMEREG]. 390 See: IPP/1.1 Encoding and Transport [RFC2910]. 392 4.5. Character Encoding of 'ipps' URI Scheme 394 'ipps' URI MUST use the UTF-8 [STD63] charset for all components. 395 'ipps' URI MUST use [STD66] rules for percent encoding data octets 396 outside the US-ASCII coded character set [ASCII]. 398 4.6. Examples of 'ipps' URI 400 4.6.1. Examples of 'ipps' URI for Printers 402 The following are examples of well-formed 'ipps' URI for IPP Printers 403 (for example, to be used as protocol elements in 'printer-uri' 404 operation attributes of 'Print-Job' request messages): 406 ipps://example.com 407 ipps://example.com/ipp 408 ipps://example.com/ipp/tiger 409 ipps://example.com/ipp/fox 410 ipps://example.com/ipp/tiger/bob 411 ipps://example.com/ipp/tiger/ira 413 Each of the above URI are well-formed URI for IPP Printers and each 414 would reference a logically different IPP Printer, even though some 415 of those IPP Printers might share the same host system. The 'bob' or 416 'ira' last path components might represent two different physical 417 printer devices, while 'tiger' might represent some grouping of IPP 418 Printers (for example, a load-balancing spooler). Or the 'bob' and 419 'ira' last path components might represent separate human recipients 420 on the same physical printer device (for example, a physical printer 421 supporting two job queues). In either case, both 'bob' and 'ira' 422 would behave as different and independent IPP Printers. 424 The following are examples of well-formed 'ipps' URI for IPP Printers 425 with (optional) ports and paths: 427 ipps://example.com 428 ipps://example.com/ipp 429 ipps://example.com:631/ipp 431 The first and second 'ipps' URI above MUST be resolved to port 631 432 (IANA assigned well-known port for IPP). The second and third 'ipps' 433 URI above are equivalent (see section 4.7 below). 435 4.6.2. Examples of 'ipps' URI for Jobs 437 The following are examples of well-formed 'ipps' URI for IPP Jobs 438 (for example, to be used as protocol elements in 'job-uri' attributes 439 of 'Print-Job' response messages): 441 ipps://example.com/ipp/123 442 ipps://example.com/ipp/tiger/job123 444 'ipps' URI for Jobs are valid and meaningful only until Job 445 completion and possibly an implementation defined optional period of 446 persistence after Job completion (see IPP Model [RFC2911]). 448 Ambiguously, section 4.3.1 'job-uri' of IPP Model [RFC2911] states 449 that: 451 "the precise format of a Job URI is implementation dependent." 453 Thus, the relationship between the value of the "printer-uri" 454 operation attribute used in a 'Print-Job' request and the value of 455 the "job-uri" attribute returned in the corresponding 'Print-Job' 456 response is entirely implementation dependent. Also, section 4.3.3 457 'job-printer-uri' of IPP Model [RFC2911] states that the 458 'job-printer-uri' attribute of a Job object: 460 "permits a client to identify the Printer object that created this 461 Job object when only the Job object's URI is available to the 462 client." 464 However, the above statement is erroneous, because the transform from 465 a URI for an IPP Job to the corresponding URI for the associated IPP 466 Printer is unspecified in either IPP/1.1 Model and Semantics 467 [RFC2911] or IPP/1.1 Encoding and Transport [RFC2910]. 469 IPP Printers that implement this specification SHOULD only generate 470 'ipps' URI for Jobs (for example, in the "job-uri" attribute in a 471 'Print-Job' response) by appending exactly one path component to the 472 corresponding 'ipps' URI for the associated Printer (for 473 interoperability). 475 4.7. Comparisons of 'ipps' URI 477 When comparing two 'ipps' URI to decide if they match or not, an IPP 478 Client MUST use the same rules as those defined for 'http' URI 479 comparisons in [RFC2616] as updated by the 'https' URI scheme 480 [RFC2818], with the sole following exception: 482 - A port that is empty or not given MUST be treated as equivalent to 483 the well-known port for that 'ipps' URI (port 631). 485 See: Section 3.2.3 'URI Comparison' in [RFC2616]. 487 See: Section 2.4 'URI Format' in [RFC2818]. 489 5. Applicability of this Specification 491 5.1. Applicability to IPP Clients 493 IPP Clients that implement this specification: 495 a) MUST support the IPP over HTTPS transport binding defined in 496 section 3.2 and the 'ipps' URI scheme defined in section 4; 498 b) MUST support the IPP over HTTP transport binding with TLS defined 499 in section 8.2 'Using IPP with TLS' of IPP/1.1 Encoding and 500 Transport [RFC2910] (for interoperability with existing IPP 501 implementations); 503 c) MUST only send IPP protocol connections to IANA assigned 504 well-known port 631 or to the explicit port specified in a given 505 'ipps' URI; 507 d) MUST only send 'ipps' URI used as protocol elements in outgoing 508 IPP protocol request messages that conform to the ABNF specified 509 in section 4.2 of this document (for example, in the "printer-uri" 510 operation attribute in a 'Print-Job' request); 512 e) MUST only convert 'ipps' URI to their corresponding 'https' URI 513 forms [RFC2818] according to the rules in section 4.2 of this 514 document. 516 5.2. Applicability to IPP Printers 518 IPP Printers that implement this specification: 520 a) MUST support the IPP over HTTPS transport binding defined in 521 section 3.2 and the 'ipps' URI scheme defined in section 4; 523 b) MUST support the IPP over HTTP transport binding with TLS defined 524 in section 8.2 'Using IPP with TLS' of IPP/1.1 Encoding and 525 Transport [RFC2910] (for interoperability with existing IPP 526 implementations); 528 c) MUST only listen for incoming IPP protocol connections on 529 IANA-assigned well-known port 631 and MUST NOT listen for incoming 530 IPP protocol connections on any other port, unless explicitly 531 configured by system administrators or site policies; 533 d) MUST only generate 'ipps' URI used as protocol elements in 534 outgoing IPP protocol response messages that conform to the ABNF 535 specified in section 4.2 of this document (for example, in the 536 "job-uri" attribute in a 'Print-Job' response); 538 e) SHOULD only accept 'ipps' URI used as protocol elements in 539 incoming IPP protocol request messages that conform to the ABNF 540 specified in section 4.2 of this document (for example, in the 541 "printer-uri" operation attribute in a 'Print-Job' request); 543 f) SHOULD only generate 'ipps' URI for Jobs by appending exactly one 544 path component to the corresponding 'ipps' URI for the associated 545 Printer (for example, in the "job-uri" attribute in a 'Print-Job' 546 response); 548 g) SHOULD NOT generate 'ipps' URI that use literal IPv6 or IPv4 549 addresses (see section 4.2 for rationale). 551 6. IANA Considerations 553 IANA is asked to register the 'ipps' URI scheme using the following 554 template, which conforms to [BCP35]. 556 URI scheme name: ipps 558 Status: Permanent 560 URI scheme syntax: See section 4.2 of RFC xxxx. 562 URI scheme semantics: The 'ipps' URI scheme is used to designate 563 secure IPP Printer objects (spoolers, application gateways, print 564 devices, etc.) on Internet hosts accessible using the IPP protocol 565 enhanced to support guaranteed data integrity and negotiable data 566 privacy using TLS [RFC5246] as specified in HTTP over TLS 567 [RFC2818]. 569 Encoding Considerations: See section 4.3 of RFC xxxx. 571 Applications/protocols that use this URI scheme name: 573 The 'ipps' URI scheme is intended to be used by applications that 574 need to access secure IPP Printers using the IPP protocol enhanced 575 to support guaranteed data integrity and negotiable data privacy 576 using TLS [RFC5246] as specified in HTTP over TLS [RFC2818]. Such 577 applications may include (but are not limited to) IPP-capable web 578 browsers, IPP Clients that wish to print a file, and servers (e.g., 579 print spoolers) that wish to forward a print Job for processing. 581 Interoperability Considerations: A widely deployed IPP print 582 service CUPS (on most UNIX, Linux, and Mac OS X client systems) has 583 supported 'ipps' URI for several years. PWG IPP Everywhere 584 [PWG5100.14] (IPP secure, mobile printing extensions) requires the 585 use of 'ipps' URI for mandatory data integrity and optional data 586 confidentiality. 588 Security Considerations: See: Section 8 of RFC xxxx. 590 Contact: 592 Ira McDonald 594 Michael Sweet 596 Author/Change controller: 598 IESG 599 References: RFC 2910, RFC 2911, and RFC xxxx. 601 [RFC Editor: Replace 'xxxx' with assigned RFC number before 602 publication] 604 7. Security Considerations 606 This 'ipps' URI Scheme specification adds the following additional 607 security considerations to those described in [RFC2910], [RFC2911], 608 [RFC2818], and [PWG5100.12]: 610 a) An 'ipps' URI might be faked to point to a rogue IPP secure print 611 service, thus collecting confidential document contents from IPP 612 Clients. 614 Server authentication mechanisms and security mechanisms specified 615 in IPP/1.1 Encoding and Transport [RFC2910], TLS/1.2 Protocol 616 [RFC5246], and HTTP over TLS [RFC2818] can be used to address this 617 threat. 619 b) An 'ipps' URI might be used to access an IPP secure print service 620 by an unauthorized IPP Client. 622 Client authentication mechanisms and security mechanisms specified 623 in IPP/1.1 Encoding and Transport [RFC2910], TLS/1.2 Protocol 624 [RFC5246], and HTTP over TLS [RFC2818] can be used to address this 625 threat. 627 c) An 'ipps' URI might be used to access an IPP secure print service 628 at a print protocol application layer gateway (for example, an IPP 629 to LPD [RFC1179] gateway [RFC2569]), potentially causing silent 630 compromise of IPP security mechanisms. 632 There is no general defense against this threat by an IPP Client. 633 System administrators should avoid such configurations. 635 d) An 'ipps' URI does not define parameters to specify the required 636 IPP Client authentication mechanism (for example, 'certificate' as 637 defined in section 4.4.2 'uri-authentication-supported' of IPP 638 Model [RFC2911]). 640 Service discovery or directory protocols should be used to 641 discover the required IPP Client authentication mechanisms 642 associated with given 'ipps' URI. 644 See: Section 8 'Security Considerations' in [RFC2910]. 646 See: Section 8 'Security Considerations' in [RFC2911]. 648 See: Section 10 'Security Considerations' in [PWG5100.12]. 650 See: Section 'Security Considerations' in [RFC2818]. 652 See: Section 15 'Security Considerations' in [RFC2616]. 654 See: Section 7 'Security Considerations' in [STD66]. 656 8. References 658 8.1. Normative References 660 [ASCII] "American National Standards Institute, Coded Character 661 Set -- 7-bit American Standard Code for Information 662 Interchange", ANSI X3.4, 1986. 664 [PWG5100.12] Bergman, R., Lewis, H., McDonald, I., and M. Sweet, 665 "Internet Printing Protocol Version 2.0 Second Edition 666 (IPP/2.0 SE)", PWG 5100.12, February 2011. 667 669 [PWG5100.14] McDonald, I. and M. Sweet, "PWG IPP Everywhere", PWG 670 5100.14, January 2013. 671 673 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 674 Requirement Levels, BCP 14, RFC 2119, March 1997. 676 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 677 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 678 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 680 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 682 [RFC2910] Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and 683 J. Wenn, "Internet Printing Protocol/1.1: Encoding and 684 Transport", RFC 2910, September 2000. 686 [RFC2911] Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S., 687 and P. Powell, "Internet Printing Protocol/1.1: Model and 688 Semantics", RFC 2911, September 2000. 690 [RFC5246] Dierks, T., and E. Rescorla, "The Transport Layer Security 691 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 693 [STD7] Postel, J., "Transmission Control Protocol", STD 7, RFC 694 793, September 1981. 696 [STD63] Yergeau, F., "UTF-8, a transformation format of ISO 697 10646", STD 63, RFC 3629, November 2003. 699 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, Uniform 700 Resource Identifiers (URI) Generic Syntax, STD 66, RFC 701 3986, January 2005. 703 [STD68] Crocker, D., Ed., and P. Overell, "Augmented BNF for 704 Syntax Specifications: ABNF", STD 68, RFC 5234, January 705 2008. 707 8.2. Informative References 709 [BCP35] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 710 Registration Procedures for New URI Schemes", BCP 35, RFC 711 4395, February 2006. 713 [MIMEREG] Internet Assigned Numbers Authority (IANA) Registry "MIME 714 Media Types" 715 717 [PORTREG] Internet Assigned Numbers Authority (IANA) Registry "Port 718 Numbers" 719 721 [RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, 722 August 1990. 724 [RFC2569] Herriot, R., Ed., Hastings, T., Jacobs, N., and J. 725 Martin, "Mapping between LPD and IPP Protocols", RFC 2569, 726 April 1999. 728 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 729 HTTP/1.1", RFC 2817, May 2000. 731 [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. 732 Holst, "Internet Printing Protocol/1.1: Implementor's 733 Guide", RFC 3196, November 2001. 735 [RFC3510] Herriot, R. and I. McDonald, "Internet Printing 736 Protocol/1.1: IPP URL Scheme", RFC 3510, April 2003. 738 9. Appendix A - Acknowledgments 740 This memo is published by IETF on behalf of the Internet Printing 741 Protocol Working Group of the IEEE-ISTO Printer Working Group, as 742 part of their PWG IPP Everywhere [PWG5100.14] project for secure 743 mobile printing with vendor-neutral Client software. 745 Thanks to Tom Hastings (retired from Xerox), Bjoern Hoerhmann, Jerry 746 Thrasher (Lexmark), Mykyta Yevstifeyev, Pete Zehler (Xerox), and the 747 members of the PWG IPP WG. 749 The IPP URL Scheme [RFC3510] was the primary source for this 750 document. 752 10. Appendix B - Abbreviations Used in this Document 754 This document makes use of the following abbreviations (given with 755 their expanded forms and references for further reading): 757 ABNF - Augmented Backus-Naur Form [STD68] 759 ASCII - American Standard Code for Information Interchange [ASCII] 761 HTTP - HyperText Transfer Protocol [RFC2616] 763 HTTPS - HTTP over TLS [RFC2818] 765 IANA - Internet Assigned Numbers Authority 766 768 IEEE - Institute of Electrical and Electronics Engineers 769 771 IESG - Internet Engineering Steering Group 772 774 IPP - Internet Printing Protocol [RFC2911] and [PWG5100.12] 775 777 ISTO - IEEE Industry Standards and Technology Organization 778 780 LPD - Line Printer Daemon Protocol [RFC1179] 782 PWG - IEEE-ISTO Printer Working Group 783 785 RFC - Request for Comments 786 788 TCP - Transmission Control Protocol [STD7] 790 TLS - Transport Layer Security [RFC5246] 792 URI - Uniform Resource Identifier [STD66] 794 URL - Uniform Resource Locator [STD66] 796 UTF-8 - Unicode Transformation Format - 8-bit [STD63] 798 11. Appendix X - Change History 800 [RFC Editor: Delete this section before publication as an RFC] 802 12 May 2013 - draft-mcdonald-ipps-uri-scheme-07.txt 803 Editorial - Revised section 1 (introduction) to add 'Rationale for 804 this document', per Smith Kennedy. 805 Editorial - Global - Changed 'Conformance Requirements' to 806 'Applicability', per Barry Leiba. 807 Editorial - Global - Changed '[PWG5100.EW]' to '[PWG5100.14]', 808 corrected date and URI, and moved section 8.1 (normative 809 references), per IPP WG review. 811 10 November 2012 - draft-mcdonald-ipps-uri-scheme-06.txt 812 Editorial - Global - Fixed typos and indentation, per IPP WG 813 review. 814 Editorial - Global - changed 'generic drivers' to 'vendor-neutral 815 Client software', per IPP WG review. 816 Editorial - Revised section 8.2 (informative references, to correct 817 title of "PWG IPP Everywhere" (i.e., delete version number), per 818 IPP WG review. 820 14 May 2012 - draft-mcdonald-ipps-uri-scheme-05.txt 821 Editorial - Global - Fixed typos and indentation, per IPP WG 822 review. 823 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to 824 insert missing "to" in "connection to the target endpoint", per 825 IPP WG review. 826 Editorial - Revised section 4.2 (syntax), to correct indentation of 827 first "Note:", per IPP WG review. 828 Editorial - Revised sections 5.1 and 5.2 (client/printer 829 conformance) and section 7 (security considerations) to delete 830 the out-of-scope normative references to [RFC2817], per IPP WG 831 review. 833 22 November 2011 - draft-mcdonald-ipps-uri-scheme-04.txt 834 Editorial - Global - Fixed typos and indentation, per IPP WG 835 review. 836 Editorial - Revised Introduction and Acknowledgments to say 837 'project for mobile, ubiquitous printing with generic drivers', 838 per IPP WG review. 839 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to 840 add references to HTTP POST and section 4 of RFC 2910, per IPP WG 841 review. 842 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to 843 add section references to all well-known standards (connection 844 setup, etc.), per IPP WG review. 845 Editorial - Revised section 4.2 (syntax) to move note from from 846 section 4.6 (examples) and explain why literal IP addresses 847 should NOT be used in 'ipps' URI, per IPP WG review. 848 Editorial - Revised sections 4.6.1 and 4.6.2 (examples) to replace 849 'abc.com' w/ 'example.com' (per IETF) and replace '/printer' path 850 element w/ '/ipp' (better practice), per IPP WG review. 851 Editorial - Revised section 5.2 (Printer conformance) to fold 852 former (c) and (d) into a single requirement for standard port 853 631 and reordered other requirements to group MUSTs before 854 SHOULDs, per IPP WG review. 855 Editorial - Revised section 5.2 (Printer conformance) to add 856 backward reference to section 4.2 for rationale for not using IP 857 literal addresses, per IPP WG review. 858 Editorial - Revised section 6 (IANA) to explicitly state that 859 'ipps' uses secure communications using HTTP over TLS, per IPP WG 860 review. 861 Editorial - Revised section 7 (Security) to cleanup numerous loose 862 ends, per IPP WG review. 863 Editorial - Revised section 8 (References) to cleanup typos and 864 links, per IPP WG review. 865 Editorial - Revised section 1 (introduction), section 8.2 866 (informative references, and section 9 (appendix A) to change 867 "[IPPEVE]" to "[PWG5100.EW]", per IPP WG review. 869 26 August 2011 - draft-mcdonald-ipps-uri-scheme-03.txt 870 Editorial - Revised Abstract and Introduction to state published by 871 the IETF on behalf of IEEE-ISTO PWG (to avoid status ambiguity), 872 per Mykyta Yevstifeyev. 873 Editorial - Revised section 1 to list all currently defined 874 versions of IPP in RFC 2566, RFC 2911, and PWG 5100.12, per 875 Mykyta Yevstifeyev. 876 Technical - Revised section 1, section 2, section 3.2, section 4.1, 877 and section 7, to reference IPP Version 2.0 Second Edition (PWG 878 5100.12), per Mykyta Yevstifeyev. 879 Editorial - Revised section 3.1, to fix broken STD7 reference, per 880 Mykyta Yevstifeyev. 881 Editorial - Revised section 6, to add BCP35 reference for template 882 (regression loss when the template was moved up from former 883 appendix), per Mykyta Yevstifeyev. 884 Editorial - Revised section 8.1 to add PWG 5100.12 (normative), 885 Editorial - Revised section 8.2 to add PWG IPP Everywhere 886 (informative) and RFC 1179 (informative), per Mykyta Yevstifeyev. 887 Editorial - Revised appendix B to add references for more reading, 888 per Mykyta Yevstifeyev. 890 28 February 2011 - draft-mcdonald-ipps-uri-scheme-02.txt 891 Editorial - Revised document title to emphasize IPP over HTTPS 892 Transport Binding (reason for IETF standards-track status). 893 Editorial - Replaced "IPP URI" with "'ipp' URI", "IPPS URI" with 894 "'ipps' URI", "HTTP URI" with "'http' URI", and "HTTPS URI" with 895 "'https' URI" throughout this document for conformance to section 896 3.1 of [STD66], per Mykyta Yevstifeyev. 897 Editorial - Revised and simplified Abstract, per Mykyta 898 Yevstifeyev. 899 Editorial - Revised and simplified section 1 'Introduction', per 900 Mykyta Yevstifeyev. 901 Editorial - Renamed section 2 from 'Conformance Terminology' to 902 'Conventions Used in this Document', per Mykyta Yevstifeyev. 903 Editorial - Moved former section 3.1 'IPP Model Terminology 904 (Normative)' content into section 2 'Conventions Used in this 905 Document' for readability, per Mykyta Yevstifeyev. 906 Editorial - Reordered subsections and reversed word order in all 907 subsection titles in section 4 'The 'ipps' URI Scheme' for 908 readability, per Mykyta Yevstifeyev. 909 Editorial - Added note to section 4.2 'Syntax of 'ipps' URI Scheme' 910 to explain why 'authority' production is NOT imported from 911 [STD66], because it includes an optional 'userinfo' component 912 which cannot be used in 'ipps' URI values. 913 Editorial - Deleted note describing empty 'host' component from 914 section 4.2 'Syntax of 'ipps' URI Scheme', because 'host' 915 component is mandatory in [STD66]. 916 Editorial - Deleted 'Internationalization Considerations' section 917 which was redundant with section 4.3 'Character Encoding of 918 'ipps' URI Scheme', per Mykyta Yevstifeyev. 919 Editorial - Revised all references to follow current RFC Editor 920 style, per Mykyta Yevstifeyev. 921 Editorial - Moved former 'Appendix A - Registration of IPPS URI 922 Scheme' content inline into section 6 'IANA Considerations', per 923 Mykyta Yevstifeyev. 924 Editorial - Moved former body section 'Acknowledgements' to 925 'Appendix A - Acknowledgements', per Mykyta Yevstifeyev. 926 Editorial - Added new 'Appendix B - Abbreviations Used in this 927 Document' for readability, per Mykyta Yevstifeyev. 928 Editorial - Moved section 'Authors' Addresses' to end of document, 929 per Mykyta Yevstifeyev. 931 1 December 2010 - draft-mcdonald-ipps-uri-scheme-01.txt 932 - Technical - added UTF-8 [STD63] as required charset for all IPPS 933 URI in section 4.4 and section 7, per Bjoern Hoehrmann. 935 - Technical - corrected percent encoding for data octets outside 936 the US-ASCII range in section 4.4 and section 7, per Bjoern 937 Hoehrmann. 938 - Editorial - global - changed "[RFC4395]" to "[BCP35]", changed 939 "[RFC3629]" to "[STD63]", changed "[RFC3986]" to "[STD66]", and 940 changed "[RFC5234]" to "[STD68]", per Bjoern Hoehrmann. 941 - Editorial - restored trailing "]]" in ABNF syntax in section 4.5, 942 per Bjoern Hoehrmann. 943 - Editorial - changed "Author/Change controller" to "IESG" in 944 section 12 Appendix A registration template, as required by 945 section 5.3 of [BCP35], per Bjoern Hoehrmann. 947 10 October 2010 - draft-mcdonald-ipps-uri-scheme-00.txt 948 - Editorial - complete rewrite of RFC 3510 for new transport 949 binding 950 - Editorial - moved Abstract to beginning of first page, per 951 ID-Nits 952 - Editorial - fixed copyright, boilerplate, and typos, per ID-Nits 953 - Editorial - added references to RFCs 2119 and 3510, per ID-Nits 954 - Editorial - deleted obsolete references to RFCs 2246 and 4346, 955 per ID-Nits 956 - Technical - changed Intended Status to Standards Track to reflect 957 the new normative IPPS URI scheme and transport binding 958 - Technical - added section 3.2 IPP over HTTP Transport Binding 959 (informative) 960 - Technical - added section 3.3 IPP over HTTPS Transport Binding 961 (normative) 962 - Technical - updated section 5 Conformance Requirements to require 963 HTTP Upgrade (RFC 2817) support (for interoperability with 964 existing IPP implementations), per discussion on IPP WG mailing 965 list 966 - Editorial - updated Appendix A w/ registration template from RFC 967 4395 969 12. Authors' Addresses 971 Ira McDonald 972 High North Inc 973 221 Ridge Ave 974 Grand Marais, MI 49839 976 Phone: +1 906-494-2434 977 Email: blueroofmusic@gmail.com 979 Michael Sweet 980 Apple Inc 981 10431 N De Anza Blvd, M/S 38-4LPT 982 Cupertino, CA 95014 984 Phone: +1 408-974-8798 985 Email: msweet@apple.com 987 Usage questions and comments on this 'ipps' URI Scheme should be 988 sent directly to the editors at their above addresses and also to 989 the PWG IPP WG mailing list. Instructions for subscribing to the 990 PWG IPP WG mailing list can be found at: 992 PWG IPP WG Web Page: http://www.pwg.org/ipp/ 993 PWG IPP WG Mailing List: ipp@pwg.org 994 PWG IPP WG Subscription: http://www.pwg.org/mailhelp.html 996 Implementers of this specification are encouraged to join the PWG 997 IPP WG Mailing List in order to participate in any discussions of 998 clarification issues and comments. Note that this IEEE-ISTO PWG 999 mailing list rejects mail from non-subscribers (in order to reduce 1000 spam).