idnits 2.17.1 draft-mcdonald-ipps-uri-scheme-01.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 draft header indicates that this document updates RFC2910, but the abstract doesn't seem to directly say this. It does mention RFC2910 though, so this could be OK. -- The draft header indicates that this document updates RFC2911, but the abstract doesn't seem to directly say this. It does mention RFC2911 though, so this could be OK. 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 (1 December 2010) is 4894 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) -- 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 informational reference (is this intentional?): RFC 4395 (ref. 'BCP35') (Obsoleted by RFC 7595) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 6 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: 1 June 2011 1 December 2010 8 IPPS URI Scheme and Transport Binding 9 draft-mcdonald-ipps-uri-scheme-01.txt 11 Abstract 13 This memo defines the IPPS URI scheme and the corresponding IPP over 14 HTTPS transport binding. This memo updates the Internet Printing 15 Protocol/1.1 Model and Semantics (RFC 2911), by extending section 16 4.1.6 'uriScheme' and section 4.4.1 'printer-uri-supported'. This 17 memo updates the Internet Printing Protocol/1.1 Encoding and 18 Transport (RFC 2910), by extending section 4 'Encoding of the 19 Transport Layer', section 5 'IPP URL Scheme', and section 8.2 'Using 20 IPP with TLS'. This memo complements (but does not update) the 21 Internet Printing Protocol/1.1 IPP URL Scheme (RFC 3510). 23 This memo is a product of the Internet Printing Protocol Working 24 Group in the IEEE-ISTO Printer Working Group, as part of their IPP 25 Everywhere project for mobile, driverless, ubiquitous printing. 27 An IPPS URI is used to specify the network location of a secure print 28 service that supports the IPP/1.1 Model and Semantics (RFC 2911), or 29 of a network resource (for example, a print job) managed by such a 30 secure print service. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. Internet-Drafts are working 36 documents of the Internet Engineering Task Force (IETF), its areas, 37 and its working groups. Note that other groups may also distribute 38 working documents as Internet-Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html 50 This Internet-Draft will expire on April 11, 2011. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction ............................................... 4 70 2. Conformance Terminology .................................... 5 71 3. IPP Transport Bindings ..................................... 6 72 3.1. IPP Model Terminology (Normative) ...................... 6 73 3.2. IPP Over HTTP Transport Binding (Informative) .......... 6 74 3.3. IPP over HTTPS Transport Binding (Normative) ........... 7 75 4. IPPS URI Scheme ............................................ 9 76 4.1. IPPS URI Scheme Applicability .......................... 9 77 4.2. IPPS URI Scheme Associated Port ........................ 9 78 4.3. IPPS URI Scheme Associated MIME Type ................... 9 79 4.4. IPPS URI Scheme Character Encoding ..................... 10 80 4.5. IPPS URI Scheme Syntax ................................. 10 81 4.6. IPPS URI Examples ...................................... 11 82 4.6.1. IPPS Printer URI Examples .......................... 11 83 4.6.2. IPPS Job URI Examples .............................. 12 84 4.7. IPPS URI Comparisons ................................... 12 85 5. Conformance Requirements ................................... 14 86 5.1. IPP Client Conformance Requirements .................... 14 87 5.2. IPP Printer Conformance Requirements ................... 14 88 6. IANA Considerations ........................................ 16 89 7. Internationalization Considerations ........................ 16 90 8. Security Considerations .................................... 17 91 9. References ................................................. 19 92 9.1. Normative References ................................... 19 93 9.2. Informative References ................................. 19 94 10. Acknowledgments ........................................... 20 95 11. Authors' Addresses ........................................ 20 96 12. Appendix A - Registration of IPPS URI Scheme .............. 21 97 13. Appendix X - Change History ............................... 24 98 1. Introduction 100 This memo conforms to all of the requirements and recommendations in 101 Guidelines and Registration Procedures for New URI Schemes [BCP35]. 103 This memo defines the IPPS URI scheme and the corresponding IPP over 104 HTTPS transport binding. This memo updates the Internet Printing 105 Protocol/1.1 Model and Semantics [RFC2911], by extending section 106 4.1.6 'uriScheme' and section 4.4.1 'printer-uri-supported'. This 107 memo updates the Internet Printing Protocol/1.1 Encoding and 108 Transport [RFC2910], by extending section 4 'Encoding of the 109 Transport Layer', section 5 'IPP URL Scheme', and section 8.2 'Using 110 IPP with TLS'. This memo complements (but does not update) the 111 Internet Printing Protocol/1.1 IPP URL Scheme [RFC3510]. 113 This memo is a product of the Internet Printing Protocol Working 114 Group in the IEEE-ISTO Printer Working Group, as part of their IPP 115 Everywhere project for mobile, driverless, ubiquitous printing. 117 An IPPS URI is used to specify the network location of a secure print 118 service that supports the IPP/1.1 Model and Semantics [RFC2911], or 119 of a network resource (for example, a print job) managed by such a 120 secure print service. 122 Overview information about the Internet Printing Protocol (IPP) is 123 available in section 1 'Introduction' of IPP/1.1 Model and Semantics 124 [RFC2911] and section 1 'Introduction' of IPP Implementor's Guide 125 [RFC3196]. 127 The IPPS URI scheme defined in this document is based on the ABNF 128 [STD68] for the HTTPS URI scheme [RFC2818], which in turn is updated 129 by the URI Generic Syntax [STD66]. An IPPS URI is transformed into 130 an HTTPS URI according to the rules specified in section 4.5 of this 131 specification. 133 This document defines IPPS URI scheme applicability, associated port 134 (631), associated MIME type ("application/ipp"), character encoding 135 (UTF-8), and syntax. 137 This document contains the following sections: 138 - Section 2 defines the conformance terminology used throughout the 139 document. 141 - Section 3 defines the IPP over HTTPS transport binding, after first 142 summarizing the IPP object model terminology and the original IPP 143 over HTTP transport binding. 145 - Section 4 defines the IPPS URI scheme. 147 - Section 5 defines the conformance requirements for IPP Clients and 148 IPP Printers that claim conformance to this document. 150 - Sections 6, 7, and 8 contain IANA, internationalization, and 151 security considerations. 153 - Sections 9, 10, and 11 contain references, acknowledgements, and 154 authors' addresses. 156 - Section 12 (Appendix A) contains a complete IANA registration for 157 the IPPS URI Scheme, per [BCP35]. 159 2. Conformance Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC 2119 [RFC2119]. 165 3. IPP Transport Bindings 167 3.1. IPP Model Terminology (Normative) 169 See: Section 12.2 'Model Terminology' in IPP/1.1 Model and Semantics 170 [RFC2911]. 172 See: Section 2 'IPP Objects', section 2.1 'Printer Object', and 173 section 2.2 'Job Object' in IPP/1.1 Encoding and Transport [RFC2911] 174 for a full description of the IPP object model and terminology. 176 In this document, "IPP Client" means the software (on some hardware 177 platform) that submits, monitors, and/or manages secure print jobs 178 via the IPP/1.1 Encoding and Transport [RFC2910] to a secure print 179 spooler, secure print gateway, or secure physical printing device. 181 In this document, "IPP Printer object" means the software (on some 182 hardware platform) that receives secure print jobs and/or secure 183 printer/job operations via the IPP/1.1 Encoding and Transport 184 [RFC2910] from an "IPP Client". 186 In this document, "IPP Printer" is a synonym for "IPP Printer 187 object". 189 In this document, "IPP Job object" means the set of attributes and 190 documents for one secure print job instantiated on an "IPP Printer". 192 In this document, "IPP Job" is a synonym for "IPP Job object". 194 In this document, "IPPS URI" means a URI using the IPPS URI scheme 195 defined in section 4 of this specification. 197 In this document, "IPPS URI" is a synonym for the "ipps-uri" ABNF 198 [STD68] production defined in section 4.5 of this specification. 200 3.2. IPP Over HTTP Transport Binding (Informative) 202 When using an IPP URI [RFC3510], an IPP Client establishes an IPP 203 application layer connection according to the following sequence: 205 1) The IPP Client selects an IPP URI value from 206 "printer-uri-supported" Printer attribute [RFC2911], a directory 207 entry, discovery info, a web page, etc.; 209 2) The IPP Client converts the IPP URI to an HTTP URI (with inserted 210 port 631); 212 3) The IPP Client establishes a TCP transport layer connection to the 213 target endpoint; 215 4) The IPP Client establishes an HTTP session layer connection to the 216 target endpoint; 218 5) Optionally, the IPP Client upgrades to TLS within HTTP/1.1 219 [RFC2817] to establish a TLS Protocol [RFC5246] secure transport 220 sublayer within the original TCP/HTTP connection, based on the 221 value of the "uri-security-supported" Printer attribute [RFC2911] 222 parallel to the selected value of "printer-uri-supported"; and 224 6) The IPP Client sends IPP application layer requests to and 225 receives responses from the IPP Printer over the HTTP session 226 layer connection. 228 See: Section 8 'Security Considerations' in [RFC2817]. 230 3.3. IPP over HTTPS Transport Binding (Normative) 232 This document defines the following IPP over HTTPS alternate 233 transport binding for the abstract protocol defined in IPP/1.1 Model 234 and Semantics [RFC2911]. 236 When using an IPPS URI, an IPP Client MUST establish an IPP 237 application layer connection according to the following sequence: 239 1) The IPP Client selects an IPPS URI value from 240 "printer-uri-supported" Printer attribute [RFC2911], a directory 241 entry, discovery info, a web page, etc.; 243 2) The IPP Client converts the IPPS URI to an HTTPS URI (with 244 inserted port 631); 246 3) The IPP Client establishes a TLS Protocol [RFC5246] over TCP 247 secure transport layer connection to the target endpoint; 249 4) The IPP Client establishes an HTTP session layer connection to the 250 target endpoint; and 252 5) The IPP Client sends IPP application layer requests to and 253 receives responses from the IPP Printer over the HTTP session 254 layer connection. 256 See: Section 'Security Considerations' in [RFC2818]. 258 4. IPPS URI Scheme 260 4.1. IPPS URI Scheme Applicability 262 The IPPS URI scheme MUST only be used to specify absolute URIs 263 (relative IPPS URIs are not allowed) for IPP secure print services 264 and their associated network resources. The IPPS URI scheme MUST 265 only be used to specify the use of the abstract protocol defined in 266 IPP/1.1 Model and Semantics [RFC2911] over an HTTPS [RFC2818] 267 transport, as defined in this specification. Any other transport 268 binding for the abstract protocol defined in IPP/1.1 Model and 269 Semantics [RFC2911] would require a different URI scheme. 271 The IPPS URI scheme allows an IPP Client to choose an appropriate IPP 272 secure print service (for example, from a directory). The IPP Client 273 can establish an HTTPS connection to the specified IPP secure print 274 service. The IPP Client can send IPP protocol requests (for example, 275 'Print-Job' requests) and receive IPP protocol responses over that 276 HTTPS connection. 278 See: Section 3.3 'IPP over HTTPS Transport Binding'. 280 See: Section 4.4.1 'printer-uri-supported' in IPP/1.1 Model and 281 Semantics [RFC2911]. 283 See: Section 5 'IPP URL Scheme' in IPP/1.1 Encoding and Transport 284 [RFC2910]. 286 4.2. IPPS URI Scheme Associated Port 288 All IPPS URIs which do NOT explicitly specify a port MUST be resolved 289 to IANA-assigned well-known port 631, as registered in 290 [IANA-PORTREG]. 292 See: IANA Port Numbers Registry [IANA-PORTREG]. 294 See: IPP/1.1 Encoding and Transport [RFC2910]. 296 4.3. IPPS URI Scheme Associated MIME Type 298 All IPPS URIs MUST be used to specify secure print services which 299 support the "application/ipp" MIME media type as registered in 300 [IANA-MIMEREG] for IPP protocol requests and responses. 302 See: IANA MIME Media Types Registry [IANA-MIMEREG]. 304 See: IPP/1.1 Encoding and Transport [RFC2910]. 306 4.4. IPPS URI Scheme Character Encoding 308 IPPS URIs MUST use the UTF-8 [STD63] charset for all components. 309 IPPS URIs MUST use [STD66] rules for percent encoding data octets 310 outside the US-ASCII coded character set [ASCII]. 312 4.5. IPPS URI Scheme Syntax 314 The abstract protocol defined in IPP/1.1 Model and Semantics 315 [RFC2911] places a limit of 1023 octets (NOT characters) on the 316 length of a URI. 318 See: Section 4.1.5 'uri' in [RFC2911]. 320 Note: IPP Printers ought to be cautious about depending on URI 321 lengths above 255 bytes, because some older IPP Client 322 implementations might not properly support these lengths. 324 IPPS URIs MUST be represented in absolute form. Absolute URIs MUST 325 always begin with a scheme name followed by a colon. For definitive 326 information on URI syntax and semantics, see "Uniform Resource 327 Identifiers (URI) Generic Syntax and Semantics" [STD66]. This 328 specification adopts the definitions of "host", "port", 329 "path-absolute", and "query" from [STD66]. 331 The IPPS URI scheme syntax in ABNF [STD68] is defined as follows: 333 ipps-uri = 334 "ipps:" "//" host [ ":" port ] [ path-absolute [ "?" query ]] 336 If the host is empty, then "localhost" MUST be used. 338 If the port is empty or not given, then port 631 MUST be used. The 339 semantics are that the identified resource (see section 5.1.2 of 340 [RFC2616]) is located at the IPP secure print service listening for 341 HTTPS connections on that port of that host, and the Request-URI for 342 the identified resource is 'path-absolute'. 344 If the 'path-absolute' is not present in the URI, it MUST be given as 345 "/" when used as a Request-URI for a resource (see section 5.1.2 of 346 [RFC2616]). 348 An IPPS URI is transformed into an HTTPS URI by replacing "ipps:" 349 with "https:" and inserting port 631 (if the 'port' is not present in 350 the original IPPS URI). 352 See: Section 3.3 'IPP over HTTPS Transport Binding'. 354 4.6. IPPS URI Examples 356 Note: Literal IPv4 or IPv6 addresses SHOULD NOT be used in IPPS 357 URIs. 359 4.6.1. IPPS Printer URI Examples 361 The following are examples of well-formed IPPS URIs for IPP Printers 362 (for example, to be used as protocol elements in 'printer-uri' 363 operation attributes of 'Print-Job' request messages): 365 ipps://abc.com 366 ipps://abc.com/printer 367 ipps://abc.com/printer/tiger 368 ipps://abc.com/printer/fox 369 ipps://abc.com/printer/tiger/bob 370 ipps://abc.com/printer/tiger/ira 372 Each of the above URIs are well-formed URIs for IPP Printers and each 373 would reference a logically different IPP Printer, even though some 374 of those IPP Printers might share the same host system. The 'bob' or 375 'ira' last path components might represent two different physical 376 printer devices, while 'tiger' might represent some grouping of IPP 377 Printers (for example, a load-balancing spooler). Or the 'bob' and 378 'ira' last path components might represent separate human recipients 379 on the same physical printer device (for example, a physical printer 380 supporting two job queues). In either case, both 'bob' and 'ira' 381 would behave as different and independent IPP Printers. 383 The following are examples of well-formed IPPS URIs for IPP Printers 384 with (optional) ports and paths: 386 ipps://abc.com 387 ipps://abc.com/smith/printer 388 ipps://abc.com:631/smith/printer 390 The first and second IPPS URIs above MUST be resolved to port 631 391 (IANA assigned well-known port for IPP). The second and third IPPS 392 URIs above are equivalent (see section 4.7 below). 394 4.6.2. IPPS Job URI Examples 396 The following are examples of well-formed IPPS URIs for IPP Jobs (for 397 example, to be used as protocol elements in 'job-uri' attributes of 398 'Print-Job' response messages): 400 ipps://abc.com/printer/123 401 ipps://abc.com/printer/tiger/job123 403 IPPS Job URIs are valid and meaningful only until Job completion and 404 possibly an implementation defined optional period of persistence 405 after Job completion (see IPP Model [RFC2911]). 407 Ambiguously, section 4.3.1 'job-uri' of IPP Model [RFC2911] states 408 that: 410 "the precise format of a Job URI is implementation dependent." 412 Thus, the relationship between the value of the "printer-uri" 413 operation attribute used in a 'Print-Job' request and the value of 414 the "job-uri" attribute returned in the corresponding 'Print-Job' 415 response is implementation dependent. Also, section 4.3.3 416 'job-printer-uri' of IPP Model [RFC2911] states that the 417 'job-printer-uri' attribute of a Job object: 419 "permits a client to identify the Printer object that created this 420 Job object when only the Job object's URI is available to the 421 client." 423 However, the above statement is erroneous, because the transform from 424 an IPP Job URI to the corresponding IPP Printer URI is unspecified in 425 either IPP/1.1 Model and Semantics [RFC2911] or IPP/1.1 Encoding and 426 Transport [RFC2910]. 428 IPP Printers that conform to this specification SHOULD only generate 429 IPPS Job URIs (for example, in the "job-uri" attribute in a 430 'Print-Job' response) by appending exactly one path component to the 431 corresponding IPPS Printer URI (for interoperability). 433 4.7. IPPS URI Comparisons 435 When comparing two IPPS URIs to decide if they match or not, an IPP 436 Client MUST use the same rules as those defined for HTTP URI 437 comparisons in [RFC2616] as updated by the HTTPS URI scheme 438 [RFC2818], with the sole following exception: 440 - A port that is empty or not given MUST be treated as equivalent to 441 the well-known port for that IPPS URI (port 631). 443 See: Section 3.2.3 'URI Comparison' in [RFC2616]. 445 See: Section 2.4 'URI Format' in [RFC2818]. 447 5. Conformance Requirements 449 5.1. IPP Client Conformance Requirements 451 IPP Clients that conform to this specification: 453 a) MUST support the IPP over HTTPS transport binding defined in 454 section 3.3 and the IPPS URI scheme defined in section 4; 456 b) MUST support the IPP over HTTP transport binding that includes 457 HTTP Upgrade [RFC2817] defined in section 8.2 'Using IPP with TLS' 458 of IPP/1.1 Encoding and Transport [RFC2910] (for interoperability 459 with existing IPP implementations); 461 c) MUST only send IPP protocol connections to IANA assigned 462 well-known port 631 or to the explicit port specified in a given 463 IPPS URI; 465 d) MUST only send IPPS URIs used as protocol elements in outgoing IPP 466 protocol request messages that conform to the ABNF specified in 467 section 4.5 'IPPS URI Scheme Syntax' of this document (for 468 example, in the "printer-uri" operation attribute in a 'Print-Job' 469 request); 471 e) MUST only convert IPPS URIs to their corresponding HTTPS URI forms 472 [RFC2818] according to the rules in section 4.5 'IPPS URI Scheme 473 Syntax' of this document. 475 5.2. IPP Printer Conformance Requirements 477 IPP Printers that conform to this specification: 479 a) MUST support the IPP over HTTPS transport binding defined in 480 section 3.3 and the IPPS URI scheme defined in section 4; 482 b) MUST support the IPP over HTTP transport binding that includes 483 HTTP Upgrade [RFC2817] defined in section 8.2 'Using IPP with TLS' 484 of IPP/1.1 Encoding and Transport [RFC2910] (for interoperability 485 with existing IPP implementations); 487 c) MUST only listen for incoming IPP protocol connections on 488 IANA-assigned well-known port 631, unless explicitly configured by 489 system administrators or site policies; 491 d) MUST NOT listen for incoming IPP protocol connections on any other 492 port than IANA-assigned well-known port 631, unless explicitly 493 configured by system administrators or site policies; 495 e) SHOULD only accept IPPS URIs used as protocol elements in incoming 496 IPP protocol request messages that conform to the ABNF specified 497 in section 4.5 'IPPS URI Scheme Syntax' of this document (for 498 example, in the "printer-uri" operation attribute in a 'Print-Job' 499 request); 501 f) MUST only generate IPPS URIs used as protocol elements in outgoing 502 IPP protocol response messages that conform to the ABNF specified 503 in section 4.5 'IPPS URI Scheme Syntax' of this document (for 504 example, in the "job-uri" attribute in a 'Print-Job' response); 506 g) SHOULD only generate IPPS Job URIs by appending exactly one path 507 component to the corresponding IPPS Printer URI (for example, in 508 the "job-uri" attribute in a 'Print-Job' response); 510 h) SHOULD NOT generate IPPS URIs that use literal IPv6 or IPv4 511 addresses. 513 6. IANA Considerations 515 This document requests the addition of the IPPS URI scheme to the 516 IANA URI Schemes Registry and defines the registration information in 517 section 12 Appendix A. 519 This document does not require any change to the IANA IPP Registry, 520 because it only defines a new URI scheme that may be used in the 521 'uriScheme' type (whose values are not enumerated) that is defined in 522 section 4.1.6 of IPP/1.1 Model and Semantics [RFC2911]. 524 There are no other IANA considerations associated with this document. 526 See: Section 12 'Appendix A - Registration of IPPS URI Scheme'. 528 7. Internationalization Considerations 530 IPPS URIs MUST use the UTF-8 [STD63] charset for all components. 531 IPPS URIs MUST use [STD66] rules for percent encoding data octets 532 outside the US-ASCII coded character set [ASCII]. 534 See: Section 7 'Internationalization Considerations' in [RFC2910]. 536 See: Section 7 'Internationalization Considerations' in [RFC2911]. 538 8. Security Considerations 540 This IPPS URI Scheme specification does not introduce any additional 541 security considerations, beyond those described in [RFC2910], 542 [RFC2911], and [RFC2818], except the following: 544 a) An IPPS URI might be faked to point to a rogue IPP secure print 545 service, thus collecting confidential document contents from IPP 546 Clients. 548 Server authentication mechanisms and security mechanisms specified 549 in IPP/1.1 Encoding and Transport [RFC2910], TLS/1.2 Protocol 550 [RFC5246], and HTTP over TLS [RFC2818] are sufficient to address 551 this threat. 553 b) An IPPS URI might be used to access an IPP secure print service by 554 an unauthorized IPP Client. 556 Client authentication mechanisms and security mechanisms specified 557 in IPP/1.1 Encoding and Transport [RFC2910], TLS/1.2 Protocol 558 [RFC5246], and HTTP over TLS [RFC2818] are sufficient to address 559 this threat. 561 c) An IPPS URI might be used to access an IPP secure print service at 562 a print protocol application layer gateway (for example, an IPP to 563 LPD gateway [RFC2569]) causing silent compromise of IPP security 564 mechanisms. 566 There is no practical defense against this threat by an IPP 567 Client. System administrators should avoid such compromising 568 configurations. 570 d) An IPPS URI does not define parameters to specify the required IPP 571 Client authentication mechanism (for example, 'certificate' as 572 defined in section 4.4.2 'uri-authentication-supported' of IPP 573 Model [RFC2911]). 575 Service discovery or directory protocols should be used to 576 discover the required IPP Client authentication mechanisms 577 associated with given IPPS URIs. 579 See: Section 8 'Security Considerations' in [RFC2910]. 581 See: Section 8 'Security Considerations' in [RFC2911]. 583 See: Section 8 'Security Considerations' in [RFC2817]. 585 See: Section 'Security Considerations' in [RFC2818]. 587 See: Section 15 'Security Considerations' in [RFC2616]. 589 See: Section 7 'Security Considerations' in [STD66]. 591 9. References 593 9.1. Normative References 595 [ASCII] American National Standards Institute, Coded Character Set -- 596 7-bit American Standard Code for Information Interchange, ANSI X3.4, 597 1986. 599 [RFC2119] S. Bradner. Key words for use in RFCs to Indicate 600 Requirement Levels, BCP 14, RFC 2119, March 1997. 602 [RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. 603 Masinter, P. Leach, T. Berners-Lee. Hypertext Transfer Protocol -- 604 HTTP/1.1, RFC 2616, June 1999. 606 [RFC2818] E. Rescorla. HTTP Over TLS, RFC 2818, May 2000. 608 [RFC2910] R. Herriot, S. Butler, P. Moore, R. Turner, J. Wenn. 609 IPP/1.1 Encoding and Transport, RFC 2910, September 2000. 611 [RFC2911] T. Hastings, R. Herriot, R. deBry, S. Isaacson, P. 612 Powell. IPP/1.1 Model and Semantics, RFC 2911, September 2000. 614 [RFC5246] T. Dierks, E. Rescorla. The Transport Layer Security 615 (TLS) Protocol Version 1.2, RFC 5246, August 2008. 617 [STD63] F. Yergeau. UTF-8, a transformation format of ISO 10646, 618 STD 63, RFC 3629, November 2003. 620 [STD66] T. Berners-Lee, R. Fielding, L. Masinter. Uniform 621 Resource Identifiers (URI) Generic Syntax, STD 66, RFC 3986, January 622 2005. 624 [STD68] D. Crocker, P. Overell. Augmented BNF for Syntax 625 Specifications ABNF, STD 68, RFC 5234, January 2008. 627 9.2. Informative References 629 See: Section 10 'References' in [RFC2910] and Section 9 'References' 630 [RFC2911]. 632 [BCP35] T. Hanson, T. Hardie, L. Masinter. Guidelines and 633 Registration Procedures for New URI Schemes, RFC 4395, February 2006. 635 [IANA-MIMEREG] IANA MIME Media Types Registry. 637 http://www.iana.org/assignments/media-types/ 639 [IANA-PORTREG] IANA Port Numbers Registry. 640 http://www.iana.org/assignments/port-numbers 642 [RFC2569] R. Herriot, T. Hastings, N. Jacobs, J. Martin. Mapping 643 between LPD and IPP Protocols, RFC 2569, April 1999. 645 [RFC2817] R. Khare, S. Lawrence. Upgrading to TLS Within HTTP/1.1, 646 RFC 2817, May 2000. 648 [RFC3196] T. Hastings, C. Manros, P. Zehler, C. Kugler, H. 649 Holst. Internet Printing Protocol/1.1 Implementor's Guide, RFC 3196, 650 November 2001. 652 [RFC3510] R. Herriot, I. McDonald. Internet Printing Protocol/1.1: 653 IPP URL Scheme, RFC 3510, April 2003. 655 10. Acknowledgments 657 This memo is a product of the Internet Printing Protocol Working 658 Group in the IEEE-ISTO Printer Working Group, as part of their IPP 659 Everywhere project for mobile, driverless, ubiquitous printing. 661 Thanks to Tom Hastings (retired from Xerox), Bjoern Hoerhmann, Jerry 662 Thrasher (Lexmark), and Pete Zehler (Xerox), and the members of the 663 PWG IPP WG. 665 The IPP URL Scheme [RFC3510] was the primary source for this IPPS URI 666 Scheme specification. 668 11. Authors' Addresses 670 Ira McDonald 671 High North Inc 672 221 Ridge Ave 673 Grand Marais, MI 49839 675 Phone: +1 906-494-2434 676 Email: blueroofmusic@gmail.com 678 Michael Sweet 679 Apple Inc 680 10431 N De Anza Blvd, M/S 38-4LPT 681 Cupertino, CA 95014 682 Phone: +1 408-974-8798 683 Email: msweet@apple.com 685 Usage questions and comments on this IPPS URI Scheme should be sent 686 directly to the editors at their above addresses and also to the IPP 687 WG mailing list. Instructions for subscribing to the IPP WG mailing 688 list can be found at: 690 IPP WG Web Page: http://www.pwg.org/ipp/ 691 IPP WG Mailing List: ipp@pwg.org 692 IPP WG Subscription: http://www.pwg.org/mailhelp.html 694 Implementers of this specification are encouraged to join the IPP WG 695 Mailing List in order to participate in any discussions of 696 clarification issues and comments. Note that this IEEE-ISTO PWG 697 mailing list rejects mail from non-subscribers (in order to reduce 698 spam). 700 12. Appendix A - Registration of IPPS URI Scheme 702 Note: The following section defines the IANA registration for the 703 IPPS URI scheme, per [BCP35]. 705 URI scheme name: ipps 707 Status: permanent 709 URI scheme syntax: 711 See: Section 4.5 'IPPS URI Scheme Syntax' of RFC xxxx. 713 [RFC Editor: Replace 'xxxx' with assigned RFC number before 714 publication] 716 URI scheme semantics: 718 The IPPS URI scheme is used to designate IPP Printer objects 719 (spoolers, application gateways, print devices, etc.) on Internet 720 hosts accessible using the IPP protocol. 722 The associated MIME type is "application/ipp" defined in IPP/1.1 723 Model and Semantics [RFC2911] and registered with IANA. 725 Encoding Considerations: 727 See: Section 7 'Internationalization Considerations' of RFC xxxx. 729 [RFC Editor: Replace 'xxxx' with assigned RFC number before 730 publication] 732 Applications/protocols that use this URI scheme name: 734 The IPPS URI scheme is intended to be used by applications that 735 need to access IPP Printers. Such applications may include (but 736 are not limited to) IPP-capable web browsers, IPP Clients that 737 wish to print a file, and servers (e.g., print spoolers) that wish 738 to forward a print Job for processing. 740 An IPPS URI is used to specify the network location of a secure 741 print service that supports the IPP/1.1 Encoding and Transport 742 [RFC2910], or of a network resource (for example, a print job) 743 managed by such a secure print service. 745 See: Section 4.1 'IPPS URI Scheme Applicability' of RFC xxxx. 747 [RFC Editor: Replace 'xxxx' with assigned RFC number before 748 publication] 750 Interoperability Considerations: 752 A widely deployed IPP print service CUPS (on most UNIX, Linux, and 753 MacOS client systems) has supported IPPS URIs for several years. 754 Current work in progress in the IEEE-ISTO Printer Working Group on 755 IPP mobile printing extensions envisions requiring the use of IPPS 756 URIs exclusively for data integrity and optional data 757 confidentiality. 759 Security Considerations: 761 See: Section 8 'Security Considerations' of RFC xxxx. 763 [RFC Editor: Replace 'xxxx' with assigned RFC number before 764 publication] 766 Contact: 768 Ira McDonald 770 Michael Sweet 772 Author/Change controller: 774 IESG 776 References: RFC 2910, RFC 2911, and RFC xxxx. 778 [RFC Editor: Replace 'xxxx' with assigned RFC number before 779 publication] 781 13. Appendix X - Change History 783 [RFC Editor: Section 13 (Appendix X Change History), should be 784 deleted before publication as an RFC] 786 1 December 2010 - draft-mcdonald-ipps-uri-scheme-01.txt 787 - Technical - added UTF-8 [STD63] as required charset for all IPPS 788 URIs in section 4.4 and section 7, per Bjoern Hoehrmann. 789 - Technical - corrected percent encoding for data octets outside the 790 US-ASCII range in section 4.4 and section 7, per Bjoern Hoehrmann. 791 - Editorial - global - changed "[RFC4395]" to "[BCP35]", changed 792 "[RFC3629]" to "[STD63]", changed "[RFC3986]" to "[STD66]", and 793 changed "[RFC5234]" to "[STD68]", per Bjoern Hoehrmann. 794 - Editorial - restored trailing "]]" in ABNF syntax in section 4.5, 795 per Bjoern Hoehrmann. 796 - Editorial - changed "Author/Change controller" to "IESG" in section 797 12 Appendix A registration template, as required by section 5.3 of 798 [BCP35], per Bjoern Hoehrmann. 800 10 October 2010 - draft-mcdonald-ipps-uri-scheme-00.txt 801 - Editorial - complete rewrite of RFC 3510 for new transport 802 binding 803 - Editorial - moved Abstract to beginning of first page, per 804 ID-Nits 805 - Editorial - fixed copyright, boilerplate, and typos, per ID-Nits 806 - Editorial - added references to RFCs 2119 and 3510, per ID-Nits 807 - Editorial - deleted obsolete references to RFCs 2246 and 4346, 808 per ID-Nits 809 - Technical - changed Intended Status to Standards Track to reflect 810 the new normative IPPS URI scheme and transport binding 811 - Technical - added section 3.2 IPP over HTTP Transport Binding 812 (informative) 813 - Technical - added section 3.3 IPP over HTTPS Transport Binding 814 (normative) 815 - Technical - updated section 5 Conformance Requirements to require 816 HTTP Upgrade (RFC 2817) support (for interoperability with 817 existing IPP implementations), per discussion on IPP WG mailing 818 list 819 - Editorial - updated Appendix A w/ registration template from RFC 820 4395