idnits 2.17.1 draft-mcdonald-ipps-uri-scheme-02.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 (28 February 2011) is 4805 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 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: 6 errors (**), 0 flaws (~~), 1 warning (==), 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: 28 August 2011 28 February 2011 8 IPP over HTTPS Transport Binding and 'ipps' URI Scheme 9 draft-mcdonald-ipps-uri-scheme-02.txt 11 Abstract 13 This memo defines the Internet Printing Protocol (IPP) over HTTPS 14 transport binding and corresponding 'ipps' URI scheme, that is used 15 to designate the access to the network location of a secure IPP print 16 service or a network resource (for example, a print job) managed by 17 such a service. 19 This memo is a product of the Internet Printing Protocol Working 20 Group in 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 28 August 2011. 45 Copyright Notice 47 Copyright (c) 2011 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 2. Conventions Used in this Document .......................... 4 65 3. IPP Transport Bindings ..................................... 4 66 3.1. IPP Over HTTP Transport Binding (Informative) .......... 4 67 3.2. IPP over HTTPS Transport Binding (Normative) ........... 5 68 4. Definition of 'ipps' URI Scheme ............................ 6 69 4.1. Applicability of 'ipps' URI Scheme ..................... 6 70 4.2. Syntax of 'ipps' URI Scheme ............................ 6 71 4.3. Associated Port for 'ipps' URI Scheme .................. 7 72 4.4. Associated MIME Type for 'ipps' URI Scheme ............. 7 73 4.5. Character Encoding of 'ipps' URI Scheme ................ 8 74 4.6. Examples of 'ipps' URI ................................. 8 75 4.6.1. Examples of 'ipps' URI for Printers ................ 8 76 4.6.2. Examples of 'ipps' URI for Jobs .................... 9 77 4.7. Comparisons of 'ipps' URI .............................. 10 78 5. Conformance Requirements ................................... 10 79 5.1. IPP Client Conformance Requirements .................... 10 80 5.2. IPP Printer Conformance Requirements ................... 11 81 6. IANA Considerations ........................................ 11 82 7. Security Considerations .................................... 12 83 8. References ................................................. 13 84 8.1. Normative References ................................... 14 85 8.2. Informative References ................................. 14 86 9. Appendix A - Acknowledgments ............................... 15 87 10. Appendix B - Abbreviations Used in this Document .......... 15 88 11. Appendix X - Change History ............................... 16 89 12. Authors' Addresses ........................................ 17 90 1. Introduction 92 This memo defines the Internet Printing (IPP) over HTTPS transport 93 binding and corresponding 'ipps' URI scheme, that is used to 94 designate the access to the network location of a secure IPP print 95 service or a network resource (for example, a print job) managed by 96 such a service. Therefore, this memo defines 'ipps' URI scheme 97 applicability, associated port, associated MIME type, character 98 encoding, and syntax. 100 This memo updates the IPP/1.1 Encoding and Transport [RFC2910], by 101 extending section 4 'Encoding of the Transport Layer', section 5 'IPP 102 URL Scheme', and section 8.2 'Using IPP with TLS' and the IPP1.1 103 Model and Semantics [RFC2911], by extending section 4.1.6 'uriScheme' 104 and section 4.4.1 'printer-uri-supported'. 106 This memo is a product of the Internet Printing Protocol Working 107 Group in the IEEE-ISTO Printer Working Group, as part of their IPP 108 Everywhere project for mobile, driverless, ubiquitous printing. 110 Overview information about IPP is available in section 1 of RFC 2911 111 [RFC2911] and section 1 of RFC 3196 [RFC3196]. 113 1.1. Structure of this document 115 This document contains the following sections: Section 2 defines the 116 conventions used throughout the document. 118 Section 3 defines the IPP over HTTPS transport binding, after first 119 summarizing the original IPP over HTTP transport binding. 121 Section 4 defines the 'ipps' URI scheme. 123 Section 5 defines the conformance requirements for IPP Clients and 124 IPP Printers that claim conformance to this document. 126 Sections 6 and 7 contain IANA and security considerations, 127 respectively. 129 Section 8 contains references. 131 Appendix A contains acknowledgments and Appendix B explains 132 abbreviations used in this document. 134 2. Conventions Used in this Document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 The reader of this document should be familiar with the terminology 141 in IPP/1.1 Model and Semantics [RFC2911] (particularly, with the 142 definition of 'IPP Objects', 'Printer Object' and 'Job Object'), 143 abbreviations described in Appendix B and the following terms. 145 In this document, "IPP Client" means the software (on some hardware 146 platform) that submits, monitors, and/or manages secure print jobs 147 via the IPP/1.1 Encoding and Transport [RFC2910] to a secure print 148 spooler, secure print gateway, or secure physical printing device. 150 In this document, "IPP Printer object" means the software (on some 151 hardware platform) that receives secure print jobs and/or secure 152 printer/job operations via the IPP/1.1 Encoding and Transport 153 [RFC2910] from an "IPP Client". 155 In this document, "IPP Printer" is a synonym for "IPP Printer 156 object". 158 In this document, "IPP Job object" means the set of attributes and 159 documents for one secure print job instantiated on an "IPP Printer". 161 In this document, "IPP Job" is a synonym for "IPP Job object". 163 In this document, "'ipps' URI" means a URI using the 'ipps' URI 164 scheme defined in section 4 of this specification. 166 3. IPP Transport Bindings 168 3.1. IPP Over HTTP Transport Binding (Informative) 170 This section is informative. 172 When using an 'ipp' URI [RFC3510], an IPP Client establishes an IPP 173 application layer connection according to the following sequence: 175 1) The IPP Client selects an 'ipp' URI value from 176 "printer-uri-supported" Printer attribute [RFC2911], a directory 177 entry, discovery info, a web page, etc.; 179 2) The IPP Client converts the 'ipp' URI to an 'http' URI (with 180 inserted port 631); 182 3) The IPP Client establishes a TCP (STD7) transport layer connection 183 to the target endpoint; 185 4) The IPP Client establishes an HTTP [RFC2616] session layer 186 connection to the target endpoint; 188 5) Optionally, the IPP Client upgrades to TLS within HTTP/1.1 189 [RFC2817] to establish a TLS Protocol [RFC5246] secure transport 190 sublayer within the original TCP/HTTP connection, based on the 191 value of the "uri-security-supported" Printer attribute [RFC2911] 192 parallel to the selected value of "printer-uri-supported"; and 194 6) The IPP Client sends IPP application layer requests to and 195 receives responses from the IPP Printer over the HTTP [RFC2616] 196 session layer connection. 198 See: Section 8 'Security Considerations' in [RFC2817]. 200 3.2. IPP over HTTPS Transport Binding (Normative) 202 This section is normative. 204 This document defines the following IPP over HTTPS alternate 205 transport binding for the abstract protocol defined in IPP/1.1 Model 206 and Semantics [RFC2911]. 208 When using an 'ipps' URI, an IPP Client MUST establish an IPP 209 application layer connection according to the following sequence: 211 1) The IPP Client selects an 'ipps' 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 'ipps' URI to an 'https' URI (with 216 inserted port 631); 218 3) The IPP Client establishes a TLS Protocol [RFC5246] over TCP 219 [STD7] secure transport layer connection to the target endpoint; 221 4) The IPP Client establishes an HTTP [RFC2616] session layer 222 connection to the target endpoint; and 224 5) The IPP Client sends IPP application layer requests to and 225 receives responses from the IPP Printer over the HTTP [RFC2616] 226 session layer connection. 228 See: Section 'Security Considerations' in [RFC2818]. 230 4. Definition of 'ipps' URI Scheme 232 4.1. Applicability of 'ipps' URI Scheme 234 The 'ipps' URI scheme MUST only be used to specify absolute URI 235 (relative 'ipps' URI are not allowed) for IPP secure print services 236 and their associated network resources. The 'ipps' URI scheme MUST 237 only be used to specify the use of the abstract protocol defined in 238 IPP/1.1 Model and Semantics [RFC2911] over an HTTPS [RFC2818] 239 transport, as defined in this specification. Any other transport 240 binding for the abstract protocol defined in IPP/1.1 Model and 241 Semantics [RFC2911] would require a different URI scheme. 243 The 'ipps' URI scheme allows an IPP Client to choose an appropriate 244 IPP secure print service (for example, from a directory). The IPP 245 Client can establish an HTTPS connection to the specified IPP secure 246 print service. The IPP Client can send IPP protocol requests (for 247 example, 'Print-Job' requests) and receive IPP protocol responses 248 over that HTTPS connection. 250 See: Section 3.2 of this document. 252 See: Section 4.4.1 'printer-uri-supported' in IPP/1.1 Model and 253 Semantics [RFC2911]. 255 See: Section 5 'IPP URL Scheme' in IPP/1.1 Encoding and Transport 256 [RFC2910]. 258 4.2. Syntax of 'ipps' URI Scheme 260 The abstract protocol defined in IPP/1.1 Model and Semantics 261 [RFC2911] places a limit of 1023 octets (NOT characters) on the 262 length of a URI. 264 See: Section 4.1.5 'uri' in [RFC2911]. 266 Note: IPP Printers ought to be cautious about depending on URI 267 lengths above 255 bytes, because some older IPP Client 268 implementations might not properly support these lengths. 270 'ipps' URI MUST be represented in absolute form. Absolute URI MUST 271 always begin with a scheme name followed by a colon. For definitive 272 information on URI syntax and semantics, see "Uniform Resource 273 Identifiers (URI) Generic Syntax and Semantics" [STD66]. This 274 specification adopts the definitions of "host", "port", 275 "path-absolute", and "query" from [STD66]. 277 The 'ipps' URI scheme syntax in ABNF [STD68] is defined as follows: 279 ipps-uri = 280 "ipps:" "//" host [ ":" port ] [ path-absolute [ "?" query ]] 282 Note: The higher-level production "authority" is not imported from 283 [STD66], because it includes an optional "userinfo" component which 284 cannot be used in 'ipps' URI. 286 If the port is empty or not given, then port 631 MUST be used. The 287 semantics are that the identified resource (see section 5.1.2 of 288 [RFC2616]) is located at the IPP secure print service listening for 289 HTTPS connections on that port of that host, and the Request-URI for 290 the identified resource is 'path-absolute'. 292 If the 'path-absolute' is not present in the URI, it MUST be given as 293 "/" when used as a Request-URI for a resource (see section 5.1.2 of 294 [RFC2616]). 296 An 'ipps' URI is transformed into an 'https' URI by replacing "ipps:" 297 with "https:" and inserting port 631 (if the 'port' is not present in 298 the original 'ipps' URI). 300 See: Section 3.2 of this document. 302 4.3. Associated Port for 'ipps' URI Scheme 304 All 'ipps' URI which do NOT explicitly specify a port MUST be 305 resolved to IANA-assigned well-known port 631, as registered in 306 [PORTREG]. 308 See: IANA Port Numbers Registry [PORTREG]. 310 See: IPP/1.1 Encoding and Transport [RFC2910]. 312 4.4. Associated MIME Type for 'ipps' URI Scheme 314 All 'ipps' URI MUST be used to specify secure print services which 315 support the "application/ipp" MIME media type as registered in 316 [MIMEREG] for IPP protocol requests and responses. 318 See: IANA MIME Media Types Registry [MIMEREG]. 320 See: IPP/1.1 Encoding and Transport [RFC2910]. 322 4.5. Character Encoding of 'ipps' URI Scheme 324 'ipps' URI MUST use the UTF-8 [STD63] charset for all components. 325 'ipps' URI MUST use [STD66] rules for percent encoding data octets 326 outside the US-ASCII coded character set [ASCII]. 328 4.6. Examples of 'ipps' URI 330 Note: Literal IPv4 or IPv6 addresses SHOULD NOT be used in 'ipps' 331 URI. 333 4.6.1. Examples of 'ipps' URI for Printers 335 The following are examples of well-formed 'ipps' URI for IPP Printers 336 (for example, to be used as protocol elements in 'printer-uri' 337 operation attributes of 'Print-Job' request messages): 339 ipps://abc.com 340 ipps://abc.com/printer 341 ipps://abc.com/printer/tiger 342 ipps://abc.com/printer/fox 343 ipps://abc.com/printer/tiger/bob 344 ipps://abc.com/printer/tiger/ira 346 Each of the above URI are well-formed URI for IPP Printers and each 347 would reference a logically different IPP Printer, even though some 348 of those IPP Printers might share the same host system. The 'bob' or 349 'ira' last path components might represent two different physical 350 printer devices, while 'tiger' might represent some grouping of IPP 351 Printers (for example, a load-balancing spooler). Or the 'bob' and 352 'ira' last path components might represent separate human recipients 353 on the same physical printer device (for example, a physical printer 354 supporting two job queues). In either case, both 'bob' and 'ira' 355 would behave as different and independent IPP Printers. 357 The following are examples of well-formed 'ipps' URI for IPP Printers 358 with (optional) ports and paths: 360 ipps://abc.com 361 ipps://abc.com/smith/printer 362 ipps://abc.com:631/smith/printer 364 The first and second 'ipps' URI above MUST be resolved to port 631 365 (IANA assigned well-known port for IPP). The second and third 'ipps' 366 URI above are equivalent (see section 4.7 below). 368 4.6.2. Examples of 'ipps' URI for Jobs 370 The following are examples of well-formed 'ipps' URI for IPP Jobs 371 (for example, to be used as protocol elements in 'job-uri' attributes 372 of 'Print-Job' response messages): 374 ipps://abc.com/printer/123 375 ipps://abc.com/printer/tiger/job123 377 'ipps' URI for Jobs are valid and meaningful only until Job 378 completion and possibly an implementation defined optional period of 379 persistence after Job completion (see IPP Model [RFC2911]). 381 Ambiguously, section 4.3.1 'job-uri' of IPP Model [RFC2911] states 382 that: 384 "the precise format of a Job URI is implementation dependent." 386 Thus, the relationship between the value of the "printer-uri" 387 operation attribute used in a 'Print-Job' request and the value of 388 the "job-uri" attribute returned in the corresponding 'Print-Job' 389 response is implementation dependent. Also, section 4.3.3 390 'job-printer-uri' of IPP Model [RFC2911] states that the 391 'job-printer-uri' attribute of a Job object: 393 "permits a client to identify the Printer object that created this 394 Job object when only the Job object's URI is available to the 395 client." 397 However, the above statement is erroneous, because the transform from 398 an 'ipp' URI for a Job to the corresponding 'ipp' URI for the 399 associated Printer is unspecified in either IPP/1.1 Model and 400 Semantics [RFC2911] or IPP/1.1 Encoding and Transport [RFC2910]. 402 IPP Printers that conform to this specification SHOULD only generate 403 'ipps' URI for Jobs (for example, in the "job-uri" attribute in a 404 'Print-Job' response) by appending exactly one path component to the 405 corresponding 'ipps' URI for the associated Printer (for 406 interoperability). 408 4.7. Comparisons of 'ipps' URI 410 When comparing two 'ipps' URI to decide if they match or not, an IPP 411 Client MUST use the same rules as those defined for 'http' URI 412 comparisons in [RFC2616] as updated by the 'https' URI scheme 413 [RFC2818], with the sole following exception: 415 - A port that is empty or not given MUST be treated as equivalent to 416 the well-known port for that 'ipps' URI (port 631). 418 See: Section 3.2.3 'URI Comparison' in [RFC2616]. 420 See: Section 2.4 'URI Format' in [RFC2818]. 422 5. Conformance Requirements 424 5.1. IPP Client Conformance Requirements 426 IPP Clients that conform to this specification: 428 a) MUST support the IPP over HTTPS transport binding defined in 429 section 3.2 and the 'ipps' URI scheme defined in section 4; 431 b) MUST support the IPP over HTTP transport binding that includes 432 HTTP Upgrade [RFC2817] defined in section 8.2 'Using IPP with TLS' 433 of IPP/1.1 Encoding and Transport [RFC2910] (for interoperability 434 with existing IPP implementations); 436 c) MUST only send IPP protocol connections to IANA assigned 437 well-known port 631 or to the explicit port specified in a given 438 'ipps' URI; 440 d) MUST only send 'ipps' URI used as protocol elements in outgoing 441 IPP protocol request messages that conform to the ABNF specified 442 in section 4.2 of this document (for example, in the "printer-uri" 443 operation attribute in a 'Print-Job' request); 445 e) MUST only convert 'ipps' URI to their corresponding 'https' URI 446 forms [RFC2818] according to the rules in section 4.2 of this 447 document. 449 5.2. IPP Printer Conformance Requirements 451 IPP Printers that conform to this specification: 453 a) MUST support the IPP over HTTPS transport binding defined in 454 section 3.2 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 listen for incoming IPP protocol connections on 462 IANA-assigned well-known port 631, unless explicitly configured by 463 system administrators or site policies; 465 d) MUST NOT listen for incoming IPP protocol connections on any other 466 port than IANA-assigned well-known port 631, unless explicitly 467 configured by system administrators or site policies; 469 e) SHOULD only accept 'ipps' URI used as protocol elements in 470 incoming IPP protocol request messages that conform to the ABNF 471 specified in section 4.2 of this document (for example, in the 472 "printer-uri" operation attribute in a 'Print-Job' request); 474 f) MUST only generate 'ipps' URI used as protocol elements in 475 outgoing IPP protocol response messages that conform to the ABNF 476 specified in section 4.2 of this document (for example, in the 477 "job-uri" attribute in a 'Print-Job' response); 479 g) SHOULD only generate 'ipps' URI for Jobs by appending exactly one 480 path component to the corresponding 'ipps' URI for the associated 481 Printer (for example, in the "job-uri" attribute in a 'Print-Job' 482 response); 484 h) SHOULD NOT generate 'ipps' URI that use literal IPv6 or IPv4 485 addresses. 487 6. IANA Considerations 489 IANA is asked to register the 'ipps' URI scheme using the following 490 template. 492 URI scheme name: ipps 494 Status: Permanent 495 URI scheme syntax: See section 4.2 of RFC xxxx. 497 URI scheme semantics: The 'ipps' URI scheme is used to designate 498 IPP Printer objects (spoolers, application gateways, print devices, 499 etc.) on Internet hosts accessible using the IPP protocol. 501 Encoding Considerations: See section 4.3 of RFC xxxx. 503 Applications/protocols that use this URI scheme name: 505 The 'ipps' URI scheme is intended to be used by applications that 506 need to access IPP Printers. Such applications may include (but 507 are not limited to) IPP-capable web browsers, IPP Clients that wish 508 to print a file, and servers (e.g., print spoolers) that wish to 509 forward a print Job for processing. 511 Interoperability Considerations: A widely deployed IPP print 512 service CUPS (on most UNIX, Linux, and MacOS client systems) has 513 supported 'ipps' URI for several years. Current work in progress 514 in the IEEE-ISTO Printer Working Group on IPP mobile printing 515 extensions envisions requiring the use of 'ipps' URI exclusively 516 for data integrity and optional data confidentiality. 518 Security Considerations: See: Section 8 of RFC xxxx. 520 Contact: 522 Ira McDonald 524 Michael Sweet 526 Author/Change controller: 528 IESG 530 References: RFC 2910, RFC 2911, and RFC xxxx. 532 [RFC Editor: Replace 'xxxx' with assigned RFC number before 533 publication] 535 7. Security Considerations 537 This 'ipps' URI Scheme specification does not introduce any 538 additional security considerations, beyond those described in 539 [RFC2910], [RFC2911], and [RFC2818], except the following: 541 a) An 'ipps' URI might be faked to point to a rogue IPP secure print 542 service, thus collecting confidential document contents from IPP 543 Clients. 545 Server authentication mechanisms and security mechanisms specified 546 in IPP/1.1 Encoding and Transport [RFC2910], TLS/1.2 Protocol 547 [RFC5246], and HTTP over TLS [RFC2818] are sufficient to address 548 this threat. 550 b) An 'ipps' URI might be used to access an IPP secure print service 551 by an unauthorized IPP Client. 553 Client authentication mechanisms and security mechanisms specified 554 in IPP/1.1 Encoding and Transport [RFC2910], TLS/1.2 Protocol 555 [RFC5246], and HTTP over TLS [RFC2818] are sufficient to address 556 this threat. 558 c) An 'ipps' URI might be used to access an IPP secure print service 559 at a print protocol application layer gateway (for example, an IPP 560 to LPD gateway [RFC2569]) causing silent compromise of IPP 561 security mechanisms. 563 There is no practical defense against this threat by an IPP 564 Client. System administrators should avoid such compromising 565 configurations. 567 d) An 'ipps' URI does not define parameters to specify the required 568 IPP Client authentication mechanism (for example, 'certificate' as 569 defined in section 4.4.2 'uri-authentication-supported' of IPP 570 Model [RFC2911]). 572 Service discovery or directory protocols should be used to 573 discover the required IPP Client authentication mechanisms 574 associated with given 'ipps' URI. 576 See: Section 8 'Security Considerations' in [RFC2910]. 578 See: Section 8 'Security Considerations' in [RFC2911]. 580 See: Section 8 'Security Considerations' in [RFC2817]. 582 See: Section 'Security Considerations' in [RFC2818]. 584 See: Section 15 'Security Considerations' in [RFC2616]. 586 See: Section 7 'Security Considerations' in [STD66]. 588 8. References 589 8.1. Normative References 591 [ASCII] "American National Standards Institute, Coded Character 592 Set -- 7-bit American Standard Code for Information 593 Interchange", ANSI X3.4, 1986. 595 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 596 Requirement Levels, BCP 14, RFC 2119, March 1997. 598 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 599 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 600 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 602 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 604 [RFC2910] Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and 605 J. Wenn, "Internet Printing Protocol/1.1: Encoding and 606 Transport", RFC 2910, September 2000. 608 [RFC2911] Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S., 609 and P. Powell, "Internet Printing Protocol/1.1: Model 610 and Semantics", RFC 2911, September 2000. 612 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 613 Security (TLS) Protocol Version 1.2", RFC 5246, August 614 2008. 616 [STD7] Postel, J., "Transmission Control Protocol", STD 7, RFC 617 793, September 1981. 619 [STD63] Yergeau, F., "UTF-8, a transformation format of ISO 620 10646", STD 63, RFC 3629, November 2003. 622 [STD66] T. Berners-Lee, R. Fielding, L. Masinter. Uniform 623 Resource Identifiers (URI) Generic Syntax, STD 66, RFC 624 3986, January 2005. 626 [STD68] Crocker, D., Ed., and P. Overell, "Augmented BNF for 627 Syntax Specifications: ABNF", STD 68, RFC 5234, January 628 2008. 630 8.2. Informative References 632 [BCP35] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 633 Registration Procedures for New URI Schemes", BCP 35, RFC 634 4395, February 2006. 636 [MIMEREG] Internet Assigned Numbers Authority (IANA) Registry "MIME 637 Media Types" 638 640 [PORTREG] Internet Assigned Numbers Authority (IANA) Registry "Port 641 Numbers" 642 644 [RFC2569] Herriot, R., Ed., Hastings, T., Jacobs, N., and J. 645 Martin, "Mapping between LPD and IPP Protocols", RFC 2569, 646 April 1999. 648 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 649 HTTP/1.1", RFC 2817, May 2000. 651 [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. 652 Holst, "Internet Printing Protocol/1.1: Implementor's 653 Guide", RFC 3196, November 2001. 655 [RFC3510] Herriot, R. and I. McDonald, "Internet Printing 656 Protocol/1.1: IPP URL Scheme", RFC 3510, April 2003. 658 9. Appendix A - Acknowledgments 660 This memo is a product of the Internet Printing Protocol Working 661 Group in the IEEE-ISTO Printer Working Group, as part of their IPP 662 Everywhere project for mobile, driverless, ubiquitous printing. 664 Thanks to Tom Hastings (retired from Xerox), Bjoern Hoerhmann, Jerry 665 Thrasher (Lexmark), Mykyta Yevstifeyev, Pete Zehler (Xerox), and the 666 members of the PWG IPP WG. 668 The IPP URL Scheme [RFC3510] was the primary source for this 'ipps' 669 URI Scheme specification. 671 10. Appendix B - Abbreviations Used in this Document 673 This document makes use of the following abbreviations (given with 674 their expanded forms): 676 ABNF - Augmented Backus-Naur Form 677 ASCII - American Standard Code for Information Interchange 678 HTTP - HyperText Transfer Protocol 679 HTTPS - Secure HyperText Transfer Protocol 680 IANA - Internet Assigned Numbers Authority 681 IEEE - Institute of Electrical and Electronics Engineers 682 IESG - Internet Engineering Steering Group 683 IPP - Internet Printing Protocol 684 ISTO - IEEE Industry Standards and Technology Organization 685 LPD - Line Printer Daemon protocol 686 RFC - Request for Comments 687 TCP - Transmission Control Protocol 688 TLS - Transport Layer Security 689 URI - Uniform Resource Identifier 690 URL - Uniform Resource Locator 691 UTF-8 - Unicode Transformation Format - 8-bit 693 11. Appendix X - Change History 695 [RFC Editor: Delete this section before publication as an RFC] 697 28 February 2011 - draft-mcdonald-ipps-uri-scheme-02.txt 698 Editorial - Revised document title to emphasize IPP over HTTPS 699 Transport Binding (reason for IETF standards-track status). 700 Editorial - Replaced "IPP URI" with "'ipp' URI", "IPPS URI" with 701 "'ipps' URI", "HTTP URI" with "'http' URI", and "HTTPS URI" with 702 "'https' URI" throughout this document for conformance to section 703 3.1 of [STD66], per Mykyta Yevstifeyev. 704 Editorial - Revised and simplified Abstract, per Mykyta Yevstifeyev. 705 Editorial - Revised and simplified section 1 'Introduction', per 706 Mykyta Yevstifeyev. 707 Editorial - Renamed section 2 from 'Conformance Terminology' to 708 'Conventions Used in this Document', per Mykyta Yevstifeyev. 709 Editorial - Moved former section 3.1 'IPP Model Terminology 710 (Normative)' content into section 2 'Conventions Used in this 711 Document' for readability, per Mykyta Yevstifeyev. 712 Editorial - Reordered subsections and reversed word order in all 713 subsection titles in section 4 'The 'ipps' URI Scheme' for 714 readability, per Mykyta Yevstifeyev. 715 Editorial - Added note to section 4.2 'Syntax of 'ipps' URI Scheme' 716 to explain why 'authority' production is NOT imported from [STD66], 717 because it includes an optional 'userinfo' component which cannot 718 be used in 'ipps' URI values. 719 Editorial - Deleted note describing empty 'host' component from 720 section 4.2 'Syntax of 'ipps' URI Scheme', because 'host' component 721 is mandatory in [STD66]. 722 Editorial - Deleted 'Internationalization Considerations' section 723 which was redundant with section 4.3 'Character Encoding of 'ipps' 724 URI Scheme', per Mykyta Yevstifeyev. 725 Editorial - Revised all references to follow current RFC Editor 726 style, per Mykyta Yevstifeyev. 727 Editorial - Moved former 'Appendix A - Registration of IPPS URI 728 Scheme' content inline into section 6 'IANA Considerations', per 729 Mykyta Yevstifeyev. 731 Editorial - Moved former body section 'Acknowledgements' to 'Appendix 732 A - Acknowledgements', per Mykyta Yevstifeyev. 733 Editorial - Added new 'Appendix B - Abbreviations Used in this 734 Document' for readability, per Mykyta Yevstifeyev. 735 Editorial - Moved section 'Authors' Addresses' to end of document, 736 per Mykyta Yevstifeyev. 738 1 December 2010 - draft-mcdonald-ipps-uri-scheme-01.txt 739 - Technical - added UTF-8 [STD63] as required charset for all IPPS 740 URI in section 4.4 and section 7, per Bjoern Hoehrmann. 741 - Technical - corrected percent encoding for data octets outside the 742 US-ASCII range in section 4.4 and section 7, per Bjoern Hoehrmann. 743 - Editorial - global - changed "[RFC4395]" to "[BCP35]", changed 744 "[RFC3629]" to "[STD63]", changed "[RFC3986]" to "[STD66]", and 745 changed "[RFC5234]" to "[STD68]", per Bjoern Hoehrmann. 746 - Editorial - restored trailing "]]" in ABNF syntax in section 4.5, 747 per Bjoern Hoehrmann. 748 - Editorial - changed "Author/Change controller" to "IESG" in section 749 12 Appendix A registration template, as required by section 5.3 of 750 [BCP35], per Bjoern Hoehrmann. 752 10 October 2010 - draft-mcdonald-ipps-uri-scheme-00.txt 753 - Editorial - complete rewrite of RFC 3510 for new transport binding 754 - Editorial - moved Abstract to beginning of first page, per ID-Nits 755 - Editorial - fixed copyright, boilerplate, and typos, per ID-Nits 756 - Editorial - added references to RFCs 2119 and 3510, per ID-Nits 757 - Editorial - deleted obsolete references to RFCs 2246 and 4346, per 758 ID-Nits 759 - Technical - changed Intended Status to Standards Track to reflect 760 the new normative IPPS URI scheme and transport binding 761 - Technical - added section 3.2 IPP over HTTP Transport Binding 762 (informative) 763 - Technical - added section 3.3 IPP over HTTPS Transport Binding 764 (normative) 765 - Technical - updated section 5 Conformance Requirements to require 766 HTTP Upgrade (RFC 2817) support (for interoperability with existing 767 IPP implementations), per discussion on IPP WG mailing list 768 - Editorial - updated Appendix A w/ registration template from RFC 769 4395 771 12. Authors' Addresses 773 Ira McDonald 774 High North Inc 775 221 Ridge Ave 776 Grand Marais, MI 49839 778 Phone: +1 906-494-2434 779 Email: blueroofmusic@gmail.com 781 Michael Sweet 782 Apple Inc 783 10431 N De Anza Blvd, M/S 38-4LPT 784 Cupertino, CA 95014 786 Phone: +1 408-974-8798 787 Email: msweet@apple.com 789 Usage questions and comments on this 'ipps' URI Scheme should be sent 790 directly to the editors at their above addresses and also to the IPP 791 WG mailing list. Instructions for subscribing to the IPP WG mailing 792 list can be found at: 794 IPP WG Web Page: http://www.pwg.org/ipp/ 795 IPP WG Mailing List: ipp@pwg.org 796 IPP WG Subscription: http://www.pwg.org/mailhelp.html 798 Implementers of this specification are encouraged to join the IPP WG 799 Mailing List in order to participate in any discussions of 800 clarification issues and comments. Note that this IEEE-ISTO PWG 801 mailing list rejects mail from non-subscribers (in order to reduce 802 spam).