idnits 2.17.1 draft-mcdonald-ipps-uri-scheme-04.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 (22 November 2011) is 4539 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: 22 May 2012 22 November 2011 8 IPP over HTTPS Transport Binding and 'ipps' URI Scheme 9 draft-mcdonald-ipps-uri-scheme-04.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 22 May 2012. 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 ..................................... 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 ........................................ 20 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 IPP Everywhere [IPPEVE] project for mobile, ubiquitous 113 printing with generic drivers. 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 the target endpoint - see section 3.4 'Establishing a 199 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 the target endpoint - see section 3.4 'Establishing a 245 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 that includes 476 HTTP Upgrade [RFC2817] defined in section 8.2 'Using IPP with TLS' 477 of IPP/1.1 Encoding and Transport [RFC2910] (for interoperability 478 with existing IPP 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 that includes 501 HTTP Upgrade [RFC2817] defined in section 8.2 'Using IPP with TLS' 502 of IPP/1.1 Encoding and Transport [RFC2910] (for interoperability 503 with existing IPP 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 8 'Security Considerations' in [RFC2817]. 631 See: Section 'Security Considerations' in [RFC2818]. 633 See: Section 15 'Security Considerations' in [RFC2616]. 635 See: Section 7 'Security Considerations' in [STD66]. 637 8. References 639 8.1. Normative References 641 [ASCII] "American National Standards Institute, Coded Character 642 Set -- 7-bit American Standard Code for Information 643 Interchange", ANSI X3.4, 1986. 645 [PWG5100.12] Bergman, R., Lewis, H., McDonald, I., and M. Sweet, 646 "Internet Printing Protocol Version 2.0 Second Edition 647 (IPP/2.0 SE)", PWG 5100.12, February 2011. 648 650 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 651 Requirement Levels, BCP 14, RFC 2119, March 1997. 653 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 654 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 655 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 657 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 659 [RFC2910] Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and 660 J. Wenn, "Internet Printing Protocol/1.1: Encoding and 661 Transport", RFC 2910, September 2000. 663 [RFC2911] Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S., 664 and P. Powell, "Internet Printing Protocol/1.1: Model and 665 Semantics", RFC 2911, September 2000. 667 [RFC5246] Dierks, T., and E. Rescorla, "The Transport Layer Security 668 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 670 [STD7] Postel, J., "Transmission Control Protocol", STD 7, RFC 671 793, September 1981. 673 [STD63] Yergeau, F., "UTF-8, a transformation format of ISO 674 10646", STD 63, RFC 3629, November 2003. 676 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, Uniform 677 Resource Identifiers (URI) Generic Syntax, STD 66, RFC 678 3986, January 2005. 680 [STD68] Crocker, D., Ed., and P. Overell, "Augmented BNF for 681 Syntax Specifications: ABNF", STD 68, RFC 5234, January 682 2008. 684 8.2. Informative References 686 [BCP35] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 687 Registration Procedures for New URI Schemes", BCP 35, RFC 688 4395, February 2006. 690 [MIMEREG] Internet Assigned Numbers Authority (IANA) Registry "MIME 691 Media Types" 692 694 [PORTREG] Internet Assigned Numbers Authority (IANA) Registry "Port 695 Numbers" 696 698 [IPPEVE] McDonald, I. and M. Sweet, "PWG IPP Everywhere 1.0", 699 work-in-progress, August 2011. 700 702 [RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, 703 August 1990. 705 [RFC2569] Herriot, R., Ed., Hastings, T., Jacobs, N., and J. 706 Martin, "Mapping between LPD and IPP Protocols", RFC 2569, 707 April 1999. 709 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 710 HTTP/1.1", RFC 2817, May 2000. 712 [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. 713 Holst, "Internet Printing Protocol/1.1: Implementor's 714 Guide", RFC 3196, November 2001. 716 [RFC3510] Herriot, R. and I. McDonald, "Internet Printing 717 Protocol/1.1: IPP URL Scheme", RFC 3510, April 2003. 719 9. Appendix A - Acknowledgments 721 This memo is published by IETF on behalf of the Internet Printing 722 Protocol Working Group of the IEEE-ISTO Printer Working Group, as 723 part of their IPP Everywhere [IPPEVE] project for mobile, ubiquitous 724 printing with generic drivers. 726 Thanks to Tom Hastings (retired from Xerox), Bjoern Hoerhmann, Jerry 727 Thrasher (Lexmark), Mykyta Yevstifeyev, Pete Zehler (Xerox), and the 728 members of the PWG IPP WG. 730 The IPP URL Scheme [RFC3510] was the primary source for this 731 document. 733 10. Appendix B - Abbreviations Used in this Document 735 This document makes use of the following abbreviations (given with 736 their expanded forms and references for further reading): 738 ABNF - Augmented Backus-Naur Form [STD68] 740 ASCII - American Standard Code for Information Interchange [ASCII] 742 HTTP - HyperText Transfer Protocol [RFC2616] 744 HTTPS - HTTP over TLS [RFC2818] 746 IANA - Internet Assigned Numbers Authority 747 749 IEEE - Institute of Electrical and Electronics Engineers 750 752 IESG - Internet Engineering Steering Group 753 755 IPP - Internet Printing Protocol [RFC2911] and [PWG5100.12] 756 758 ISTO - IEEE Industry Standards and Technology Organization 759 761 LPD - Line Printer Daemon Protocol [RFC1179] 763 PWG - IEEE-ISTO Printer Working Group 764 766 RFC - Request for Comments 767 769 TCP - Transmission Control Protocol [STD7] 771 TLS - Transport Layer Security [RFC5246] 773 URI - Uniform Resource Identifier [STD66] 775 URL - Uniform Resource Locator [STD66] 777 UTF-8 - Unicode Transformation Format - 8-bit [STD63] 779 11. Appendix X - Change History 781 [RFC Editor: Delete this section before publication as an RFC] 783 22 November 2011 - draft-mcdonald-ipps-uri-scheme-04.txt 784 Editorial - Global - Fixed typos and indentation, per IPP WG review. 785 Editorial - Revised Introduction and Acknowledgments to say 'project 786 for mobile, ubiquitous printing with generic drivers', per IPP WG 787 review. 788 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to add 789 references to HTTP POST and section 4 of RFC 2910, per IPP WG 790 review. 791 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to add 792 section references to all well-known standards (connection setup, 793 etc.), per IPP WG review. 794 Editorial - Revised section 4.2 (syntax) to move note from from 795 section 4.6 (examples) and explain why literal IP addresses should 796 NOT be used in 'ipps' URI, per IPP WG review. 797 Editorial - Revised sections 4.6.1 and 4.6.2 (examples) to replace 798 'abc.com' w/ 'example.com' (per IETF) and replace '/printer' path 799 element w/ '/ipp' (better practice), per IPP WG review. 800 Editorial - Revised section 5.2 (Printer conformance) to fold former 801 (c) and (d) into a single requirement for standard port 631 and 802 reordered other requirements to group MUSTs before SHOULDs, per IPP 803 WG review. 804 Editorial - Revised section 5.2 (Printer conformance) to add backward 805 reference to section 4.2 for rationale for not using IP literal 806 addresses, per IPP WG review. 807 Editorial - Revised section 6 (IANA) to explicitly state that 'ipps' 808 uses secure communications using HTTP over TLS, per IPP WG review. 809 Editorial - Revised section 7 (Security) to cleanup numerous loose 810 ends, per IPP WG review. 811 Editorial - Revised section 8 (References) to cleanup typos and 812 links, per IPP WG review. 814 26 August 2011 - draft-mcdonald-ipps-uri-scheme-03.txt 815 Editorial - Revised Abstract and Introduction to state published by 816 the IETF on behalf of IEEE-ISTO PWG (to avoid status ambiguity), 817 per Mykyta Yevstifeyev. 818 Editorial - Revised section 1 to list all currently defined versions 819 of IPP in RFC 2566, RFC 2911, and PWG 5100.12, per Mykyta 820 Yevstifeyev. 821 Technical - Revised section 1, section 2, section 3.2, section 4.1, 822 and section 7, to reference IPP Version 2.0 Second Edition (PWG 823 5100.12), per Mykyta Yevstifeyev. 824 Editorial - Revised section 3.1, to fix broken STD7 reference, per 825 Mykyta Yevstifeyev. 827 Editorial - Revised section 6, to add BCP35 reference for template 828 (regression loss when the template was moved up from former 829 appendix), per Mykyta Yevstifeyev. 830 Editorial - Revised section 8.1 to add PWG 5100.12 (normative), 831 Editorial - Revised section 8.2 to add PWG IPP Everywhere 832 (informative) and RFC 1179 (informative), per Mykyta Yevstifeyev. 833 Editorial - Revised appendix B to add references for more reading, 834 per Mykyta Yevstifeyev. 836 28 February 2011 - draft-mcdonald-ipps-uri-scheme-02.txt 837 Editorial - Revised document title to emphasize IPP over HTTPS 838 Transport Binding (reason for IETF standards-track status). 839 Editorial - Replaced "IPP URI" with "'ipp' URI", "IPPS URI" with 840 "'ipps' URI", "HTTP URI" with "'http' URI", and "HTTPS URI" with 841 "'https' URI" throughout this document for conformance to section 842 3.1 of [STD66], per Mykyta Yevstifeyev. 843 Editorial - Revised and simplified Abstract, per Mykyta Yevstifeyev. 844 Editorial - Revised and simplified section 1 'Introduction', per 845 Mykyta Yevstifeyev. 846 Editorial - Renamed section 2 from 'Conformance Terminology' to 847 'Conventions Used in this Document', per Mykyta Yevstifeyev. 848 Editorial - Moved former section 3.1 'IPP Model Terminology 849 (Normative)' content into section 2 'Conventions Used in this 850 Document' for readability, per Mykyta Yevstifeyev. 851 Editorial - Reordered subsections and reversed word order in all 852 subsection titles in section 4 'The 'ipps' URI Scheme' for 853 readability, per Mykyta Yevstifeyev. 854 Editorial - Added note to section 4.2 'Syntax of 'ipps' URI Scheme' 855 to explain why 'authority' production is NOT imported from [STD66], 856 because it includes an optional 'userinfo' component which cannot 857 be used in 'ipps' URI values. 858 Editorial - Deleted note describing empty 'host' component from 859 section 4.2 'Syntax of 'ipps' URI Scheme', because 'host' component 860 is mandatory in [STD66]. 861 Editorial - Deleted 'Internationalization Considerations' section 862 which was redundant with section 4.3 'Character Encoding of 'ipps' 863 URI Scheme', per Mykyta Yevstifeyev. 864 Editorial - Revised all references to follow current RFC Editor 865 style, per Mykyta Yevstifeyev. 866 Editorial - Moved former 'Appendix A - Registration of IPPS URI 867 Scheme' content inline into section 6 'IANA Considerations', per 868 Mykyta Yevstifeyev. 869 Editorial - Moved former body section 'Acknowledgements' to 'Appendix 870 A - Acknowledgements', per Mykyta Yevstifeyev. 871 Editorial - Added new 'Appendix B - Abbreviations Used in this 872 Document' for readability, per Mykyta Yevstifeyev. 873 Editorial - Moved section 'Authors' Addresses' to end of document, 874 per Mykyta Yevstifeyev. 876 1 December 2010 - draft-mcdonald-ipps-uri-scheme-01.txt 877 - Technical - added UTF-8 [STD63] as required charset for all IPPS 878 URI in section 4.4 and section 7, per Bjoern Hoehrmann. 879 - Technical - corrected percent encoding for data octets outside the 880 US-ASCII range in section 4.4 and section 7, per Bjoern Hoehrmann. 881 - Editorial - global - changed "[RFC4395]" to "[BCP35]", changed 882 "[RFC3629]" to "[STD63]", changed "[RFC3986]" to "[STD66]", and 883 changed "[RFC5234]" to "[STD68]", per Bjoern Hoehrmann. 884 - Editorial - restored trailing "]]" in ABNF syntax in section 4.5, 885 per Bjoern Hoehrmann. 886 - Editorial - changed "Author/Change controller" to "IESG" in section 887 12 Appendix A registration template, as required by section 5.3 of 888 [BCP35], per Bjoern Hoehrmann. 890 10 October 2010 - draft-mcdonald-ipps-uri-scheme-00.txt 891 - Editorial - complete rewrite of RFC 3510 for new transport binding 892 - Editorial - moved Abstract to beginning of first page, per ID-Nits 893 - Editorial - fixed copyright, boilerplate, and typos, per ID-Nits 894 - Editorial - added references to RFCs 2119 and 3510, per ID-Nits 895 - Editorial - deleted obsolete references to RFCs 2246 and 4346, per 896 ID-Nits 897 - Technical - changed Intended Status to Standards Track to reflect 898 the new normative IPPS URI scheme and transport binding 899 - Technical - added section 3.2 IPP over HTTP Transport Binding 900 (informative) 901 - Technical - added section 3.3 IPP over HTTPS Transport Binding 902 (normative) 903 - Technical - updated section 5 Conformance Requirements to require 904 HTTP Upgrade (RFC 2817) support (for interoperability with existing 905 IPP implementations), per discussion on IPP WG mailing list 906 - Editorial - updated Appendix A w/ registration template from RFC 907 4395 909 12. Authors' Addresses 911 Ira McDonald 912 High North Inc 913 221 Ridge Ave 914 Grand Marais, MI 49839 916 Phone: +1 906-494-2434 917 Email: blueroofmusic@gmail.com 919 Michael Sweet 920 Apple Inc 921 10431 N De Anza Blvd, M/S 38-4LPT 922 Cupertino, CA 95014 923 Phone: +1 408-974-8798 924 Email: msweet@apple.com 926 Usage questions and comments on this 'ipps' URI Scheme should be sent 927 directly to the editors at their above addresses and also to the IPP 928 WG mailing list. Instructions for subscribing to the IPP WG mailing 929 list can be found at: 931 IPP WG Web Page: http://www.pwg.org/ipp/ 932 IPP WG Mailing List: ipp@pwg.org 933 IPP WG Subscription: http://www.pwg.org/mailhelp.html 935 Implementers of this specification are encouraged to join the IPP WG 936 Mailing List in order to participate in any discussions of 937 clarification issues and comments. Note that this IEEE-ISTO PWG 938 mailing list rejects mail from non-subscribers (in order to reduce 939 spam).