idnits 2.17.1 draft-mcdonald-ipps-uri-scheme-06.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 (10 November 2012) is 4183 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 116, but not defined ** Obsolete undefined reference: RFC 2566 (Obsoleted by RFC 2911) -- 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: 7 errors (**), 0 flaws (~~), 2 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: 10 May 2013 10 November 2012 8 IPP over HTTPS Transport Binding and 'ipps' URI Scheme 9 draft-mcdonald-ipps-uri-scheme-06.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 10 May 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 2. Conventions Used in this Document .......................... 4 65 3. IPP Transport Bindings ..................................... 5 66 3.1. IPP over HTTP Transport Binding (Informative) .......... 5 67 3.2. IPP over HTTPS Transport Binding (Normative) ........... 6 68 4. Definition of 'ipps' URI Scheme ............................ 6 69 4.1. Applicability of 'ipps' URI Scheme ..................... 7 70 4.2. Syntax of 'ipps' URI Scheme ............................ 7 71 4.3. Associated Port for 'ipps' URI Scheme .................. 8 72 4.4. Associated MIME Type for 'ipps' URI Scheme ............. 9 73 4.5. Character Encoding of 'ipps' URI Scheme ................ 9 74 4.6. Examples of 'ipps' URI ................................. 9 75 4.6.1. Examples of 'ipps' URI for Printers ................ 9 76 4.6.2. Examples of 'ipps' URI for Jobs .................... 10 77 4.7. Comparisons of 'ipps' URI .............................. 11 78 5. Conformance Requirements ................................... 11 79 5.1. IPP Client Conformance Requirements .................... 11 80 5.2. IPP Printer Conformance Requirements ................... 12 81 6. IANA Considerations ........................................ 12 82 7. Security Considerations .................................... 13 83 8. References ................................................. 15 84 8.1. Normative References ................................... 15 85 8.2. Informative References ................................. 16 86 9. Appendix A - Acknowledgments ............................... 16 87 10. Appendix B - Abbreviations Used in this Document .......... 17 88 11. Appendix X - Change History ............................... 18 89 12. Authors' Addresses ........................................ 21 90 1. Introduction 92 This memo defines the Internet Printing Protocol (IPP) over HTTPS 93 transport binding and the corresponding 'ipps' URI scheme, that is 94 used to designate the access to the network location of a secure IPP 95 print service or a network resource (for example, a print job) 96 managed by such a service. Therefore, this memo defines 'ipps' URI 97 scheme applicability, associated port, associated MIME type, 98 character encoding, and syntax. 100 This memo updates: 101 a) IPP/1.1 Encoding and Transport [RFC2910], by extending section 4 102 'Encoding of the Transport Layer', section 5 'IPP URL Scheme', and 103 section 8.2 'Using IPP with TLS'; 104 b) IPP/1.1 Model and Semantics [RFC2911], by extending section 4.1.6 105 'uriScheme' and section 4.4.1 'printer-uri-supported'; and 106 c) IEEE-ISTO PWG IPP Version 2.0 Second Edition [PWG5100.12], by 107 extending section 4 'IPP Standards' and section 10 'Security 108 Considerations'. 110 This memo is published by IETF on behalf of the Internet Printing 111 Protocol Working Group of the IEEE-ISTO Printer Working Group, as 112 part of their PWG IPP Everywhere [PWG5100.EW] project for mobile, 113 ubiquitous printing with vendor-neutral Client software. 115 The following versions of IPP are currently defined: 116 - 1.0 in [RFC2566] (obsolete) 117 - 1.1 in [RFC2911] 118 - 2.0 in [PWG5100.12] 119 - 2.1 in [PWG5100.12] 120 - 2.2 in [PWG5100.12] 122 Overview information about IPP is available in section 1 of RFC 2911 123 [RFC2911], section 1 of RFC 3196 [RFC3196], and section 1 of PWG IPP 124 Version 2.0 Second Edition [PWG5100.12]. 126 1.1. Structure of this document 128 This document contains the following sections: Section 2 defines the 129 conventions used throughout the document. 131 Section 3 defines the IPP over HTTPS transport binding, after first 132 summarizing the original IPP over HTTP transport binding. 134 Section 4 defines the 'ipps' URI scheme. 136 Section 5 defines the conformance requirements for IPP Clients and 137 IPP Printers that claim conformance to this document. 139 Sections 6 and 7 contain IANA and security considerations, 140 respectively. 142 Section 8 contains references. 144 Appendix A contains acknowledgments and Appendix B explains 145 abbreviations used in this document. 147 2. Conventions Used in this Document 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 The reader of this document should be familiar with the terminology 154 in IPP/1.1 Model and Semantics [RFC2911] (particularly, with the 155 definition of 'IPP Objects', 'Printer Object' and 'Job Object'), 156 abbreviations described in Appendix B and the following terms. 158 In this document, "IPP Client" means the software (on some hardware 159 platform) that submits, monitors, and/or manages secure print jobs 160 via the IPP/1.1 Encoding and Transport [RFC2910] or IEEE-ISTO PWG IPP 161 Version 2.0 Second Edition [PWG5100.12] to a secure print spooler, 162 secure print gateway, or secure physical printing device. 164 In this document, "IPP Printer object" means the software (on some 165 hardware platform) that receives secure print jobs and/or secure 166 printer/job operations via the IPP/1.1 Encoding and Transport 167 [RFC2910] or IEEE-ISTO PWG IPP Version 2.0 Second Edition 168 [PWG5100.12] from an "IPP Client". 170 In this document, "IPP Printer" is a synonym for "IPP Printer 171 object". 173 In this document, "IPP Job object" means the set of attributes and 174 documents for one secure print job instantiated on an "IPP Printer". 176 In this document, "IPP Job" is a synonym for "IPP Job object". 178 In this document, "'ipps' URI" means a URI using the 'ipps' URI 179 scheme defined in section 4 of this specification. 181 3. IPP Transport Bindings 183 3.1. IPP over HTTP Transport Binding (Informative) 185 This section is informative. 187 When using an 'ipp' URI [RFC3510], an IPP Client establishes an IPP 188 application layer connection according to the following sequence: 190 1) The IPP Client selects an 'ipp' URI value from 191 "printer-uri-supported" Printer attribute [RFC2911], a directory 192 entry, discovery info, a web page, etc.; 194 2) The IPP Client converts the 'ipp' URI to an 'http' URI (replacing 195 'ipp' with 'http' and inserting port 631); 197 3) The IPP Client establishes a TCP [STD7] reliable transport layer 198 connection to the target endpoint - see section 3.4 'Establishing 199 a connection' in TCP [STD7]; 201 4) The IPP Client establishes an HTTP [RFC2616] session layer 202 connection to the target endpoint - see section 8 'Connections' in 203 HTTP/1.1 [RFC2616]; 205 5) Optionally, either the IPP Client upgrades to TLS within HTTP/1.1 206 per section 3 'Client Requested Upgrade to HTTP over TLS' of 207 [RFC2817] or the IPP Printer upgrades to TLS within HTTP/1.1 per 208 section 4 'Server Requested Upgrade to HTTP over TLS' of 209 [RFC2817], in order to establish a TLS Protocol [RFC5246] secure 210 transport sublayer within the original TCP/HTTP connection - per 211 the "uri-security-supported" (section 4.4.3 in [RFC2911]) Printer 212 attribute value parallel to the "printer-uri-supported" (see 213 section 4.4.1 in [RFC2911]) value that matches this connection; 214 and 216 6) The IPP Client sends IPP application layer requests to and 217 receives responses from the IPP Printer over the HTTP [RFC2616] 218 session layer connection using the POST method defined in section 219 9.5 of HTTP/1.1 [RFC2616], as specified in section 4 'Encoding of 220 Transport Layer' in IPP/1.1 Encoding and Transport [RFC2910]. 222 See: Section 8 'Security Considerations' in [RFC2817]. 224 3.2. IPP over HTTPS Transport Binding (Normative) 226 This section is normative. 228 This document defines the following IPP over HTTPS alternate 229 transport binding for the abstract protocol defined in IPP/1.1 Model 230 and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version 2.0 Second 231 Edition [PWG5100.12]. 233 When using an 'ipps' URI, an IPP Client MUST establish an IPP 234 application layer connection according to the following sequence: 236 1) The IPP Client selects an 'ipps' URI value from 237 "printer-uri-supported" Printer attribute [RFC2911], a directory 238 entry, discovery info, a web page, etc.; 240 2) The IPP Client converts the 'ipps' URI to an 'https' URI 241 (replacing 'ipps' with 'https' and inserting port 631); 243 3) The IPP Client establishes a TCP [STD7] reliable transport layer 244 connection to the target endpoint - see section 3.4 'Establishing 245 a connection' in TCP [STD7]; 247 4) The IPP Client establishes a TLS [RFC5246] secure transport layer 248 connection to the target endpoint - see section 7 'The TLS 249 Handshaking Protocols' in TLS [RFC5246]; 251 5) The IPP Client establishes an HTTPS [RFC2818] secure session layer 252 connection over the TLS [RFC5246] secure transport layer to the 253 target endpoint; and 255 6) The IPP Client sends IPP application layer requests to and 256 receives responses from the IPP Printer over the HTTPS [RFC2818] 257 secure session layer connection using the POST method defined in 258 section 9.5 of HTTP/1.1 [RFC2616], as specified in section 4 259 'Encoding of Transport Layer' in IPP/1.1 Encoding and Transport 260 [RFC2910]. 262 See: Section 'Security Considerations' in [RFC2818]. 264 4. Definition of 'ipps' URI Scheme 265 4.1. Applicability of 'ipps' URI Scheme 267 The 'ipps' URI scheme MUST only be used to specify absolute URI 268 (relative 'ipps' URI are not allowed) for IPP secure print services 269 and their associated network resources. The 'ipps' URI scheme MUST 270 only be used to specify the use of the abstract protocol defined in 271 IPP/1.1 Model and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version 272 2.0 Second Edition [PWG5100.12] over an HTTPS [RFC2818] transport, as 273 defined in this specification. Any other transport binding for IPP 274 would require a different URI scheme. 276 The 'ipps' URI scheme allows an IPP Client to choose an appropriate 277 IPP secure print service (for example, from a directory). The IPP 278 Client can establish an HTTPS connection to the specified IPP secure 279 print service. The IPP Client can send IPP protocol requests (for 280 example, 'Print-Job' requests) and receive IPP protocol responses 281 over that HTTPS connection. 283 See: Section 3.2 of this document. 285 See: Section 4.4.1 'printer-uri-supported' in IPP/1.1 Model and 286 Semantics [RFC2911]. 288 See: Section 5 'IPP URL Scheme' in IPP/1.1 Encoding and Transport 289 [RFC2910]. 291 See: Section 4 'IPP Standards' and section 10 'Security 292 Considerations' of IEEE-ISTO PWG IPP Version 2.0 Second Edition 293 [PWG5100.12]. 295 4.2. Syntax of 'ipps' URI Scheme 297 The abstract protocol defined in IPP/1.1 Model and Semantics 298 [RFC2911] places a limit of 1023 octets (NOT characters) on the 299 length of a URI. 301 See: Section 4.1.5 'uri' in [RFC2911]. 303 Note: IPP Printers ought to be cautious about depending on URI 304 lengths above 255 bytes, because some older IPP Client 305 implementations might not properly support these lengths. 307 'ipps' URI MUST be represented in absolute form. Absolute URI MUST 308 always begin with a scheme name followed by a colon. For definitive 309 information on URI syntax and semantics, see "Uniform Resource 310 Identifiers (URI) Generic Syntax and Semantics" [STD66]. This 311 specification adopts the definitions of "host", "port", 312 "path-absolute", and "query" from [STD66]. 314 The 'ipps' URI scheme syntax in ABNF [STD68] is defined as follows: 316 ipps-uri = 317 "ipps:" "//" host [ ":" port ] [ path-absolute [ "?" query ]] 319 Note: The higher-level production "authority" is not imported from 320 [STD66], because it includes an optional "userinfo" component which 321 cannot be used in 'ipps' URI. 323 If the port is empty or not given, then port 631 MUST be used. The 324 semantics are that the identified resource (see section 5.1.2 of 325 [RFC2616]) is located at the IPP secure print service listening for 326 HTTPS connections on that port of that host, and the Request-URI for 327 the identified resource is 'path-absolute'. 329 Note: Literal IPv4 or IPv6 addresses SHOULD NOT be used in 'ipps' 330 URI, because: 331 a) IP addresses are often changed after network device installation 332 (e.g., based on DHCP reassignment after a power cycle); 333 b) IP addresses often don't map simply to security domains; 334 c) IP addresses are difficult to validate with X.509 server 335 certificates (because they do not map to common name or alternate 336 name attributes); and 337 d) IPv6 link local addresses are not "portable" due to link identity 339 If the 'path-absolute' is not present in the URI, it MUST be given as 340 "/" when used as a Request-URI for a resource (see section 5.1.2 of 341 [RFC2616]). 343 An 'ipps' URI is transformed into an 'https' URI by replacing "ipps:" 344 with "https:" and inserting port 631 (if the 'port' is not present in 345 the original 'ipps' URI). 347 See: Section 3.2 of this document. 349 4.3. Associated Port for 'ipps' URI Scheme 351 All 'ipps' URI which do NOT explicitly specify a port MUST be 352 resolved to IANA-assigned well-known port 631, as registered in 353 [PORTREG]. 355 See: IANA Port Numbers Registry [PORTREG]. 357 See: IPP/1.1 Encoding and Transport [RFC2910]. 359 4.4. Associated MIME Type for 'ipps' URI Scheme 361 All 'ipps' URI MUST be used to specify secure print services which 362 support the "application/ipp" MIME media type as registered in 363 [MIMEREG] for IPP protocol requests and responses. 365 See: IANA MIME Media Types Registry [MIMEREG]. 367 See: IPP/1.1 Encoding and Transport [RFC2910]. 369 4.5. Character Encoding of 'ipps' URI Scheme 371 'ipps' URI MUST use the UTF-8 [STD63] charset for all components. 372 'ipps' URI MUST use [STD66] rules for percent encoding data octets 373 outside the US-ASCII coded character set [ASCII]. 375 4.6. Examples of 'ipps' URI 377 4.6.1. Examples of 'ipps' URI for Printers 379 The following are examples of well-formed 'ipps' URI for IPP Printers 380 (for example, to be used as protocol elements in 'printer-uri' 381 operation attributes of 'Print-Job' request messages): 383 ipps://example.com 384 ipps://example.com/ipp 385 ipps://example.com/ipp/tiger 386 ipps://example.com/ipp/fox 387 ipps://example.com/ipp/tiger/bob 388 ipps://example.com/ipp/tiger/ira 390 Each of the above URI are well-formed URI for IPP Printers and each 391 would reference a logically different IPP Printer, even though some 392 of those IPP Printers might share the same host system. The 'bob' or 393 'ira' last path components might represent two different physical 394 printer devices, while 'tiger' might represent some grouping of IPP 395 Printers (for example, a load-balancing spooler). Or the 'bob' and 396 'ira' last path components might represent separate human recipients 397 on the same physical printer device (for example, a physical printer 398 supporting two job queues). In either case, both 'bob' and 'ira' 399 would behave as different and independent IPP Printers. 401 The following are examples of well-formed 'ipps' URI for IPP Printers 402 with (optional) ports and paths: 404 ipps://example.com 405 ipps://example.com/ipp 406 ipps://example.com:631/ipp 408 The first and second 'ipps' URI above MUST be resolved to port 631 409 (IANA assigned well-known port for IPP). The second and third 'ipps' 410 URI above are equivalent (see section 4.7 below). 412 4.6.2. Examples of 'ipps' URI for Jobs 414 The following are examples of well-formed 'ipps' URI for IPP Jobs 415 (for example, to be used as protocol elements in 'job-uri' attributes 416 of 'Print-Job' response messages): 418 ipps://example.com/ipp/123 419 ipps://example.com/ipp/tiger/job123 421 'ipps' URI for Jobs are valid and meaningful only until Job 422 completion and possibly an implementation defined optional period of 423 persistence after Job completion (see IPP Model [RFC2911]). 425 Ambiguously, section 4.3.1 'job-uri' of IPP Model [RFC2911] states 426 that: 428 "the precise format of a Job URI is implementation dependent." 430 Thus, the relationship between the value of the "printer-uri" 431 operation attribute used in a 'Print-Job' request and the value of 432 the "job-uri" attribute returned in the corresponding 'Print-Job' 433 response is entirely implementation dependent. Also, section 4.3.3 434 'job-printer-uri' of IPP Model [RFC2911] states that the 435 'job-printer-uri' attribute of a Job object: 437 "permits a client to identify the Printer object that created this 438 Job object when only the Job object's URI is available to the 439 client." 441 However, the above statement is erroneous, because the transform from 442 a URI for an IPP Job to the corresponding URI for the associated IPP 443 Printer is unspecified in either IPP/1.1 Model and Semantics 444 [RFC2911] or IPP/1.1 Encoding and Transport [RFC2910]. 446 IPP Printers that conform to this specification SHOULD only generate 447 'ipps' URI for Jobs (for example, in the "job-uri" attribute in a 448 'Print-Job' response) by appending exactly one path component to the 449 corresponding 'ipps' URI for the associated Printer (for 450 interoperability). 452 4.7. Comparisons of 'ipps' URI 454 When comparing two 'ipps' URI to decide if they match or not, an IPP 455 Client MUST use the same rules as those defined for 'http' URI 456 comparisons in [RFC2616] as updated by the 'https' URI scheme 457 [RFC2818], with the sole following exception: 459 - A port that is empty or not given MUST be treated as equivalent to 460 the well-known port for that 'ipps' URI (port 631). 462 See: Section 3.2.3 'URI Comparison' in [RFC2616]. 464 See: Section 2.4 'URI Format' in [RFC2818]. 466 5. Conformance Requirements 468 5.1. IPP Client Conformance Requirements 470 IPP Clients that conform to this specification: 472 a) MUST support the IPP over HTTPS transport binding defined in 473 section 3.2 and the 'ipps' URI scheme defined in section 4; 475 b) MUST support the IPP over HTTP transport binding with TLS defined 476 in section 8.2 'Using IPP with TLS' of IPP/1.1 Encoding and 477 Transport [RFC2910] (for interoperability with existing IPP 478 implementations); 480 c) MUST only send IPP protocol connections to IANA assigned 481 well-known port 631 or to the explicit port specified in a given 482 'ipps' URI; 484 d) MUST only send 'ipps' URI used as protocol elements in outgoing 485 IPP protocol request messages that conform to the ABNF specified 486 in section 4.2 of this document (for example, in the "printer-uri" 487 operation attribute in a 'Print-Job' request); 489 e) MUST only convert 'ipps' URI to their corresponding 'https' URI 490 forms [RFC2818] according to the rules in section 4.2 of this 491 document. 493 5.2. IPP Printer Conformance Requirements 495 IPP Printers that conform to this specification: 497 a) MUST support the IPP over HTTPS transport binding defined in 498 section 3.2 and the 'ipps' URI scheme defined in section 4; 500 b) MUST support the IPP over HTTP transport binding with TLS defined 501 in section 8.2 'Using IPP with TLS' of IPP/1.1 Encoding and 502 Transport [RFC2910] (for interoperability with existing IPP 503 implementations); 505 c) MUST only listen for incoming IPP protocol connections on 506 IANA-assigned well-known port 631 and MUST NOT listen for incoming 507 IPP protocol connections on any other port, unless explicitly 508 configured by system administrators or site policies; 510 d) MUST only generate 'ipps' URI used as protocol elements in 511 outgoing IPP protocol response messages that conform to the ABNF 512 specified in section 4.2 of this document (for example, in the 513 "job-uri" attribute in a 'Print-Job' response); 515 e) SHOULD only accept 'ipps' URI used as protocol elements in 516 incoming IPP protocol request messages that conform to the ABNF 517 specified in section 4.2 of this document (for example, in the 518 "printer-uri" operation attribute in a 'Print-Job' request); 520 f) SHOULD only generate 'ipps' URI for Jobs by appending exactly one 521 path component to the corresponding 'ipps' URI for the associated 522 Printer (for example, in the "job-uri" attribute in a 'Print-Job' 523 response); 525 g) SHOULD NOT generate 'ipps' URI that use literal IPv6 or IPv4 526 addresses (see section 4.2 for rationale). 528 6. IANA Considerations 530 IANA is asked to register the 'ipps' URI scheme using the following 531 template, which conforms to [BCP35]. 533 URI scheme name: ipps 535 Status: Permanent 537 URI scheme syntax: See section 4.2 of RFC xxxx. 539 URI scheme semantics: The 'ipps' URI scheme is used to designate 540 secure IPP Printer objects (spoolers, application gateways, print 541 devices, etc.) on Internet hosts accessible using the IPP protocol 542 enhanced to support guaranteed data integrity and negotiable data 543 privacy using TLS [RFC5246] as specified in HTTP over TLS 544 [RFC2818]. 546 Encoding Considerations: See section 4.3 of RFC xxxx. 548 Applications/protocols that use this URI scheme name: 550 The 'ipps' URI scheme is intended to be used by applications that 551 need to access secure IPP Printers using the IPP protocol enhanced 552 to support guaranteed data integrity and negotiable data privacy 553 using TLS [RFC5246] as specified in HTTP over TLS [RFC2818]. Such 554 applications may include (but are not limited to) IPP-capable web 555 browsers, IPP Clients that wish to print a file, and servers (e.g., 556 print spoolers) that wish to forward a print Job for processing. 558 Interoperability Considerations: A widely deployed IPP print 559 service CUPS (on most UNIX, Linux, and Mac OS X client systems) has 560 supported 'ipps' URI for several years. Current work in progress 561 in the IEEE-ISTO Printer Working Group on IPP mobile printing 562 extensions envisions requiring the use of 'ipps' URI exclusively 563 for data integrity and optional data confidentiality. 565 Security Considerations: See: Section 8 of RFC xxxx. 567 Contact: 569 Ira McDonald 571 Michael Sweet 573 Author/Change controller: 575 IESG 577 References: RFC 2910, RFC 2911, and RFC xxxx. 579 [RFC Editor: Replace 'xxxx' with assigned RFC number before 580 publication] 582 7. Security Considerations 584 This 'ipps' URI Scheme specification does not introduce any 585 additional security considerations, beyond those described in 586 [RFC2910], [RFC2911], [RFC2818], and [PWG5100.12], except the 587 following: 589 a) An 'ipps' URI might be faked to point to a rogue IPP secure print 590 service, thus collecting confidential document contents from IPP 591 Clients. 593 Server authentication mechanisms and security mechanisms specified 594 in IPP/1.1 Encoding and Transport [RFC2910], TLS/1.2 Protocol 595 [RFC5246], and HTTP over TLS [RFC2818] can be used to address this 596 threat. 598 b) An 'ipps' URI might be used to access an IPP secure print service 599 by an unauthorized IPP Client. 601 Client authentication mechanisms and security mechanisms specified 602 in IPP/1.1 Encoding and Transport [RFC2910], TLS/1.2 Protocol 603 [RFC5246], and HTTP over TLS [RFC2818] can be used to address this 604 threat. 606 c) An 'ipps' URI might be used to access an IPP secure print service 607 at a print protocol application layer gateway (for example, an IPP 608 to LPD [RFC1179] gateway [RFC2569]), potentially causing silent 609 compromise of IPP security mechanisms. 611 There is no general defense against this threat by an IPP Client. 612 System administrators should avoid such configurations. 614 d) An 'ipps' URI does not define parameters to specify the required 615 IPP Client authentication mechanism (for example, 'certificate' as 616 defined in section 4.4.2 'uri-authentication-supported' of IPP 617 Model [RFC2911]). 619 Service discovery or directory protocols should be used to 620 discover the required IPP Client authentication mechanisms 621 associated with given 'ipps' URI. 623 See: Section 8 'Security Considerations' in [RFC2910]. 625 See: Section 8 'Security Considerations' in [RFC2911]. 627 See: Section 10 'Security Considerations' in [PWG5100.12]. 629 See: Section 'Security Considerations' in [RFC2818]. 631 See: Section 15 'Security Considerations' in [RFC2616]. 633 See: Section 7 'Security Considerations' in [STD66]. 635 8. References 637 8.1. Normative References 639 [ASCII] "American National Standards Institute, Coded Character 640 Set -- 7-bit American Standard Code for Information 641 Interchange", ANSI X3.4, 1986. 643 [PWG5100.12] Bergman, R., Lewis, H., McDonald, I., and M. Sweet, 644 "Internet Printing Protocol Version 2.0 Second Edition 645 (IPP/2.0 SE)", PWG 5100.12, February 2011. 646 648 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 649 Requirement Levels, BCP 14, RFC 2119, March 1997. 651 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 652 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 653 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 655 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 657 [RFC2910] Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and 658 J. Wenn, "Internet Printing Protocol/1.1: Encoding and 659 Transport", RFC 2910, September 2000. 661 [RFC2911] Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S., 662 and P. Powell, "Internet Printing Protocol/1.1: Model and 663 Semantics", RFC 2911, September 2000. 665 [RFC5246] Dierks, T., and E. Rescorla, "The Transport Layer Security 666 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 668 [STD7] Postel, J., "Transmission Control Protocol", STD 7, RFC 669 793, September 1981. 671 [STD63] Yergeau, F., "UTF-8, a transformation format of ISO 672 10646", STD 63, RFC 3629, November 2003. 674 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, Uniform 675 Resource Identifiers (URI) Generic Syntax, STD 66, RFC 676 3986, January 2005. 678 [STD68] Crocker, D., Ed., and P. Overell, "Augmented BNF for 679 Syntax Specifications: ABNF", STD 68, RFC 5234, January 680 2008. 682 8.2. Informative References 684 [BCP35] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 685 Registration Procedures for New URI Schemes", BCP 35, RFC 686 4395, February 2006. 688 [MIMEREG] Internet Assigned Numbers Authority (IANA) Registry "MIME 689 Media Types" 690 692 [PORTREG] Internet Assigned Numbers Authority (IANA) Registry "Port 693 Numbers" 694 696 [PWG5100.EW] McDonald, I. and M. Sweet, "PWG IPP Everywhere", 697 work-in-progress, November 2012. 698 700 [RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, 701 August 1990. 703 [RFC2569] Herriot, R., Ed., Hastings, T., Jacobs, N., and J. 704 Martin, "Mapping between LPD and IPP Protocols", RFC 2569, 705 April 1999. 707 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 708 HTTP/1.1", RFC 2817, May 2000. 710 [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. 711 Holst, "Internet Printing Protocol/1.1: Implementor's 712 Guide", RFC 3196, November 2001. 714 [RFC3510] Herriot, R. and I. McDonald, "Internet Printing 715 Protocol/1.1: IPP URL Scheme", RFC 3510, April 2003. 717 9. Appendix A - Acknowledgments 719 This memo is published by IETF on behalf of the Internet Printing 720 Protocol Working Group of the IEEE-ISTO Printer Working Group, as 721 part of their PWG IPP Everywhere [PWG5100.EW] project for mobile, 722 ubiquitous printing with vendor-neutral Client software. 724 Thanks to Tom Hastings (retired from Xerox), Bjoern Hoerhmann, Jerry 725 Thrasher (Lexmark), Mykyta Yevstifeyev, Pete Zehler (Xerox), and the 726 members of the PWG IPP WG. 728 The IPP URL Scheme [RFC3510] was the primary source for this 729 document. 731 10. Appendix B - Abbreviations Used in this Document 733 This document makes use of the following abbreviations (given with 734 their expanded forms and references for further reading): 736 ABNF - Augmented Backus-Naur Form [STD68] 738 ASCII - American Standard Code for Information Interchange [ASCII] 740 HTTP - HyperText Transfer Protocol [RFC2616] 742 HTTPS - HTTP over TLS [RFC2818] 744 IANA - Internet Assigned Numbers Authority 745 747 IEEE - Institute of Electrical and Electronics Engineers 748 750 IESG - Internet Engineering Steering Group 751 753 IPP - Internet Printing Protocol [RFC2911] and [PWG5100.12] 754 756 ISTO - IEEE Industry Standards and Technology Organization 757 759 LPD - Line Printer Daemon Protocol [RFC1179] 761 PWG - IEEE-ISTO Printer Working Group 762 764 RFC - Request for Comments 765 767 TCP - Transmission Control Protocol [STD7] 769 TLS - Transport Layer Security [RFC5246] 771 URI - Uniform Resource Identifier [STD66] 773 URL - Uniform Resource Locator [STD66] 775 UTF-8 - Unicode Transformation Format - 8-bit [STD63] 777 11. Appendix X - Change History 779 [RFC Editor: Delete this section before publication as an RFC] 781 14 May 2012 - draft-mcdonald-ipps-uri-scheme-05.txt 782 Editorial - Global - Fixed typos and indentation, per IPP WG review. 783 Editorial - Global - changed 'generic drivers' to 'vendor-neutral 784 Client software', per IPP WG review. 785 Editorial - Revised section 8.2 (informative references, to correct 786 title of "PWG IPP Everywhere" (i.e., delete version number), per 787 IPP WG review. 789 14 May 2012 - draft-mcdonald-ipps-uri-scheme-05.txt 790 Editorial - Global - Fixed typos and indentation, per IPP WG review. 791 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to 792 insert missing "to" in "connection to the target endpoint", per IPP 793 WG review. 794 Editorial - Revised section 4.2 (syntax), to correct indentation of 795 first "Note:", per IPP WG review. 796 Editorial - Revised sections 5.1 and 5.2 (client/printer conformance) 797 and section 7 (security considerations) to delete the out-of-scope 798 normative references to [RFC2817], per IPP WG review. 800 22 November 2011 - draft-mcdonald-ipps-uri-scheme-04.txt 801 Editorial - Global - Fixed typos and indentation, per IPP WG review. 802 Editorial - Revised Introduction and Acknowledgments to say 'project 803 for mobile, ubiquitous printing with generic drivers', per IPP WG 804 review. 805 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to add 806 references to HTTP POST and section 4 of RFC 2910, per IPP WG 807 review. 808 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to add 809 section references to all well-known standards (connection setup, 810 etc.), per IPP WG review. 811 Editorial - Revised section 4.2 (syntax) to move note from from 812 section 4.6 (examples) and explain why literal IP addresses should 813 NOT be used in 'ipps' URI, per IPP WG review. 814 Editorial - Revised sections 4.6.1 and 4.6.2 (examples) to replace 815 'abc.com' w/ 'example.com' (per IETF) and replace '/printer' path 816 element w/ '/ipp' (better practice), per IPP WG review. 817 Editorial - Revised section 5.2 (Printer conformance) to fold former 818 (c) and (d) into a single requirement for standard port 631 and 819 reordered other requirements to group MUSTs before SHOULDs, per IPP 820 WG review. 821 Editorial - Revised section 5.2 (Printer conformance) to add backward 822 reference to section 4.2 for rationale for not using IP literal 823 addresses, per IPP WG review. 825 Editorial - Revised section 6 (IANA) to explicitly state that 'ipps' 826 uses secure communications using HTTP over TLS, per IPP WG review. 827 Editorial - Revised section 7 (Security) to cleanup numerous loose 828 ends, per IPP WG review. 829 Editorial - Revised section 8 (References) to cleanup typos and 830 links, per IPP WG review. 831 Editorial - Revised section 1 (introduction), section 8.2 832 (informative references, and section 9 (appendix A) to change 833 "[IPPEVE]" to "[PWG5100.EW]", per IPP WG review. 835 26 August 2011 - draft-mcdonald-ipps-uri-scheme-03.txt 836 Editorial - Revised Abstract and Introduction to state published by 837 the IETF on behalf of IEEE-ISTO PWG (to avoid status ambiguity), 838 per Mykyta Yevstifeyev. 839 Editorial - Revised section 1 to list all currently defined versions 840 of IPP in RFC 2566, RFC 2911, and PWG 5100.12, per Mykyta 841 Yevstifeyev. 842 Technical - Revised section 1, section 2, section 3.2, section 4.1, 843 and section 7, to reference IPP Version 2.0 Second Edition (PWG 844 5100.12), per Mykyta Yevstifeyev. 845 Editorial - Revised section 3.1, to fix broken STD7 reference, per 846 Mykyta Yevstifeyev. 847 Editorial - Revised section 6, to add BCP35 reference for template 848 (regression loss when the template was moved up from former 849 appendix), per Mykyta Yevstifeyev. 850 Editorial - Revised section 8.1 to add PWG 5100.12 (normative), 851 Editorial - Revised section 8.2 to add PWG IPP Everywhere 852 (informative) and RFC 1179 (informative), per Mykyta Yevstifeyev. 853 Editorial - Revised appendix B to add references for more reading, 854 per Mykyta Yevstifeyev. 856 28 February 2011 - draft-mcdonald-ipps-uri-scheme-02.txt 857 Editorial - Revised document title to emphasize IPP over HTTPS 858 Transport Binding (reason for IETF standards-track status). 859 Editorial - Replaced "IPP URI" with "'ipp' URI", "IPPS URI" with 860 "'ipps' URI", "HTTP URI" with "'http' URI", and "HTTPS URI" with 861 "'https' URI" throughout this document for conformance to section 862 3.1 of [STD66], per Mykyta Yevstifeyev. 863 Editorial - Revised and simplified Abstract, per Mykyta Yevstifeyev. 864 Editorial - Revised and simplified section 1 'Introduction', per 865 Mykyta Yevstifeyev. 866 Editorial - Renamed section 2 from 'Conformance Terminology' to 867 'Conventions Used in this Document', per Mykyta Yevstifeyev. 868 Editorial - Moved former section 3.1 'IPP Model Terminology 869 (Normative)' content into section 2 'Conventions Used in this 870 Document' for readability, per Mykyta Yevstifeyev. 871 Editorial - Reordered subsections and reversed word order in all 872 subsection titles in section 4 'The 'ipps' URI Scheme' for 873 readability, per Mykyta Yevstifeyev. 874 Editorial - Added note to section 4.2 'Syntax of 'ipps' URI Scheme' 875 to explain why 'authority' production is NOT imported from [STD66], 876 because it includes an optional 'userinfo' component which cannot 877 be used in 'ipps' URI values. 878 Editorial - Deleted note describing empty 'host' component from 879 section 4.2 'Syntax of 'ipps' URI Scheme', because 'host' component 880 is mandatory in [STD66]. 881 Editorial - Deleted 'Internationalization Considerations' section 882 which was redundant with section 4.3 'Character Encoding of 'ipps' 883 URI Scheme', per Mykyta Yevstifeyev. 884 Editorial - Revised all references to follow current RFC Editor 885 style, per Mykyta Yevstifeyev. 886 Editorial - Moved former 'Appendix A - Registration of IPPS URI 887 Scheme' content inline into section 6 'IANA Considerations', per 888 Mykyta Yevstifeyev. 889 Editorial - Moved former body section 'Acknowledgements' to 'Appendix 890 A - Acknowledgements', per Mykyta Yevstifeyev. 891 Editorial - Added new 'Appendix B - Abbreviations Used in this 892 Document' for readability, per Mykyta Yevstifeyev. 893 Editorial - Moved section 'Authors' Addresses' to end of document, 894 per Mykyta Yevstifeyev. 896 1 December 2010 - draft-mcdonald-ipps-uri-scheme-01.txt 897 - Technical - added UTF-8 [STD63] as required charset for all IPPS 898 URI in section 4.4 and section 7, per Bjoern Hoehrmann. 899 - Technical - corrected percent encoding for data octets outside the 900 US-ASCII range in section 4.4 and section 7, per Bjoern Hoehrmann. 901 - Editorial - global - changed "[RFC4395]" to "[BCP35]", changed 902 "[RFC3629]" to "[STD63]", changed "[RFC3986]" to "[STD66]", and 903 changed "[RFC5234]" to "[STD68]", per Bjoern Hoehrmann. 904 - Editorial - restored trailing "]]" in ABNF syntax in section 4.5, 905 per Bjoern Hoehrmann. 906 - Editorial - changed "Author/Change controller" to "IESG" in section 907 12 Appendix A registration template, as required by section 5.3 of 908 [BCP35], per Bjoern Hoehrmann. 910 10 October 2010 - draft-mcdonald-ipps-uri-scheme-00.txt 911 - Editorial - complete rewrite of RFC 3510 for new transport binding 912 - Editorial - moved Abstract to beginning of first page, per ID-Nits 913 - Editorial - fixed copyright, boilerplate, and typos, per ID-Nits 914 - Editorial - added references to RFCs 2119 and 3510, per ID-Nits 915 - Editorial - deleted obsolete references to RFCs 2246 and 4346, per 916 ID-Nits 917 - Technical - changed Intended Status to Standards Track to reflect 918 the new normative IPPS URI scheme and transport binding 919 - Technical - added section 3.2 IPP over HTTP Transport Binding 920 (informative) 921 - Technical - added section 3.3 IPP over HTTPS Transport Binding 922 (normative) 923 - Technical - updated section 5 Conformance Requirements to require 924 HTTP Upgrade (RFC 2817) support (for interoperability with existing 925 IPP implementations), per discussion on IPP WG mailing list 927 - Editorial - updated Appendix A w/ registration template from RFC 928 4395 930 12. Authors' Addresses 932 Ira McDonald 933 High North Inc 934 221 Ridge Ave 935 Grand Marais, MI 49839 937 Phone: +1 906-494-2434 938 Email: blueroofmusic@gmail.com 940 Michael Sweet 941 Apple Inc 942 10431 N De Anza Blvd, M/S 38-4LPT 943 Cupertino, CA 95014 945 Phone: +1 408-974-8798 946 Email: msweet@apple.com 948 Usage questions and comments on this 'ipps' URI Scheme should be sent 949 directly to the editors at their above addresses and also to the PWG 950 IPP WG mailing list. Instructions for subscribing to the PWG IPP WG 951 mailing list can be found at: 953 PWG IPP WG Web Page: http://www.pwg.org/ipp/ 954 PWG IPP WG Mailing List: ipp@pwg.org 955 PWG IPP WG Subscription: http://www.pwg.org/mailhelp.html 957 Implementers of this specification are encouraged to join the PWG IPP 958 WG Mailing List in order to participate in any discussions of 959 clarification issues and comments. Note that this IEEE-ISTO PWG 960 mailing list rejects mail from non-subscribers (in order to reduce 961 spam).