idnits 2.17.1 draft-mcdonald-ipps-uri-scheme-09.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 (5 November 2013) is 3824 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 137, but not defined ** Obsolete undefined reference: RFC 2566 (Obsoleted by RFC 2911) == Missing Reference: 'RFC 2817' is mentioned on line 183, but not defined == Missing Reference: 'RFC 2717' is mentioned on line 178, but not defined ** Obsolete undefined reference: RFC 2717 (Obsoleted by RFC 4395) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** 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 4346 (Obsoleted by RFC 5246) ** 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: 10 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ira McDonald 3 INTERNET-DRAFT High North Inc 4 Updates: 2910, 2911 (if approved) Michael Sweet 5 Intended Status: Standards Track Apple Inc 6 Expires: 5 May 2014 5 November 2013 8 IPP over HTTPS Transport Binding and 'ipps' URI Scheme 9 draft-mcdonald-ipps-uri-scheme-09.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 an individual submission to the IETF by the Internet 20 Printing Protocol Working Group of the IEEE-ISTO Printer Working 21 Group, as part of their PWG IPP Everywhere (PWG 5100.14) project for 22 secure mobile printing with vendor-neutral Client software. 24 This memo defines an alternate IPP transport binding to that defined 25 in the original IPP URL Scheme (RFC 3510), but this memo does not 26 update or obsolete (RFC 3510). 28 This memo updates RFC 2910 and RFC 2911. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. Internet-Drafts are working 34 documents of the Internet Engineering Task Force (IETF), its areas, 35 and its working groups. Note that other groups may also distribute 36 working documents as Internet-Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 This Internet-Draft will expire on 5 May 2014. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction ............................................... 4 69 1.1. Structure of this document ............................. 4 70 1.2. Rationale for this document ............................ 5 71 2. Conventions Used in this Document .......................... 5 72 2.1. Printing Terminology ................................... 5 73 2.2. Abbreviations .......................................... 6 74 3. IPP over HTTPS Transport Binding ........................... 7 75 4. Definition of 'ipps' URI Scheme ............................ 8 76 4.1. Applicability of 'ipps' URI Scheme ..................... 8 77 4.2. Syntax of 'ipps' URI Scheme ............................ 9 78 4.3. Associated Port for 'ipps' URI Scheme .................. 10 79 4.4. Associated MIME Type for 'ipps' URI Scheme ............. 10 80 4.5. Character Encoding of 'ipps' URI Scheme ................ 10 81 4.6. Examples of 'ipps' URI ................................. 11 82 4.6.1. Examples of 'ipps' URI for Printers ................ 11 83 4.6.2. Examples of 'ipps' URI for Jobs .................... 11 84 4.7. Comparisons of 'ipps' URI .............................. 12 85 5. Applicability of this Specification ........................ 13 86 5.1. Applicability to IPP Clients ........................... 13 87 5.2. Applicability to IPP Printers .......................... 13 88 6. IANA Considerations ........................................ 14 89 7. Security Considerations .................................... 15 90 7.1. Problem Statement ...................................... 15 91 7.1.1. Targets of Attacks ................................. 16 92 7.1.2. Layers of Attacks .................................. 16 93 7.2. Attacks and Defenses ................................... 16 94 7.2.1. Faked 'ipps' URI ................................... 17 95 7.2.2. Unauthorized Access by IPP Client .................. 17 96 7.2.3. Compromise at Application Layer Gateway ............ 17 97 7.2.4. No Client Authentication for 'ipps' URI ............ 18 98 7.3. TLS Cipher Suite Requirements .......................... 18 100 8. Acknowledgments ............................................ 19 101 9. References ................................................. 19 102 9.1. Normative References ................................... 19 103 9.2. Informative References ................................. 21 104 10. Appendix A - Summary of IPP URL Scheme (Informative) ...... 21 105 11. Appendix X - Change History ............................... 22 106 12. Authors' Addresses ........................................ 26 107 1. Introduction 109 This document defines the Internet Printing Protocol (IPP) over HTTPS 110 transport binding and the corresponding 'ipps' URI scheme, that is 111 used to designate the access to the network location of a secure IPP 112 print service or a network resource (for example, a print job) 113 managed by such a service. 115 This document is an individual submission to the IETF by the Internet 116 Printing Protocol Working Group of the IEEE-ISTO Printer Working 117 Group, as part of their PWG IPP Everywhere [PWG5100.14] project for 118 secure mobile printing with vendor-neutral Client software. 120 This document defines an alternate IPP transport binding to that 121 defined in the original IPP URL Scheme [RFC3510], but this document 122 does not update or obsolete [RFC3510]. 124 This document updates [RFC2910] and [RFC2911]. 126 This document updates: 127 a) IPP/1.1 Encoding and Transport [RFC2910], by extending section 4 128 'Encoding of the Transport Layer', section 5 'IPP URL Scheme', and 129 section 8.2 'Using IPP with TLS'; 130 b) IPP/1.1 Model and Semantics [RFC2911], by extending section 4.1.6 131 'uriScheme' and section 4.4.1 'printer-uri-supported'; and 132 c) IEEE-ISTO PWG IPP Version 2.0 Second Edition [PWG5100.12], by 133 extending section 4 'IPP Standards' and section 10 'Security 134 Considerations'. 136 The following versions of IPP are currently defined: 137 - 1.0 in [RFC2566] (obsolete) 138 - 1.1 in [RFC2911] 139 - 2.0 in [PWG5100.12] 140 - 2.1 in [PWG5100.12] 141 - 2.2 in [PWG5100.12] 143 Overview information about IPP is available in section 1 of RFC 2911 144 [RFC2911], section 1 of RFC 3196 [RFC3196], and section 1 of PWG IPP 145 Version 2.0 Second Edition [PWG5100.12]. 147 1.1. Structure of this document 149 This document contains the following sections: Section 2 defines the 150 conventions used throughout the document. 152 Section 3 defines the IPP over HTTPS transport binding. 154 Section 4 defines the 'ipps' URI scheme. 156 Section 5 defines the applicability of this specification to IPP 157 Clients and IPP Printers. 159 Sections 6 and 7 contain IANA and security considerations, 160 respectively. 162 Section 8 containes acknowledgments. 164 Section 9 contains references. 166 Appendix A contains an informative summary of the original IPP URL 167 Scheme [RFC3510] and associated IPP over HTTP transport binding. 169 1.2. Rationale for this document 171 The 'ipps' URI scheme was defined for the following reasons: 173 1) Some existing IPP Client and IPP Printer implementations of 174 Upgrading to TLS Within HTTP/1.1 [RFC 2817] are flawed and 175 unreliable. 177 2) Some existing IPP Client and IPP Printer implementations of HTTP 178 Upgrade [RFC 2717] do not perform upgrade at the beginning of 179 every HTTP connection, but instead only shift to secure IPP for 180 selected IPP operations (inherently dangerous behavior on the same 181 underlying TCP connection). 183 3) IPP Printer server-mandated HTTP Upgrade [RFC 2817] can still lead 184 to exposure of IPP Client data if the Expect request header is not 185 used - basically the IPP Client can send its whole Print-Job 186 request before the IPP Printer has a chance to respond and say, 187 "Wait! You need to encrypt first!" 189 2. Conventions Used in this Document 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in RFC 2119 [RFC2119]. 195 2.1. Printing Terminology 197 The reader of this document needs to be familiar with the printing 198 terms defined in IPP/1.1 Model and Semantics [RFC2911] as well as the 199 following: 201 IPP Client: The software (on some hardware platform) that submits 202 IPP Job creation and IPP Printer and IPP Job management operations 203 via the IPP over HTTP transport binding defined in the IPP/1.1 204 Encoding and Transport [RFC2910] and/or the IPP over HTTPS transport 205 binding defined in section 3 of this specification to a downstream 206 IPP Printer (print spooler, print gateway, or physical printing 207 device). 209 IPP Job: The set of attributes and documents for one print job 210 instantiated in an IPP Printer. 212 IPP Job object: Synonym for IPP Job. 214 IPP Printer: The software (on some hardware platform) that receives 215 IPP Job creation and IPP Printer and IPP Job management operations 216 via the IPP over HTTP transport binding defined in the IPP/1.1 217 Encoding and Transport [RFC2910] and/or the IPP over HTTPS transport 218 binding defined in section 3 of this specification from an upstream 219 IPP Client or IPP Printer. 221 IPP Printer object: Synonym for IPP Printer. 223 'ipps' URI: A URI using the 'ipps' URI scheme defined in section 4 224 of this specification. 226 2.2. Abbreviations 228 This document makes use of the following abbreviations (given with 229 their expanded forms and references for further reading): 231 ABNF - Augmented Backus-Naur Form [STD68] 233 ASCII - American Standard Code for Information Interchange [ASCII] 235 HTTP - HyperText Transfer Protocol [RFC2616] 237 HTTPS - HTTP over TLS [RFC2818] 239 IANA - Internet Assigned Numbers Authority 240 242 IEEE - Institute of Electrical and Electronics Engineers 243 245 IESG - Internet Engineering Steering Group 246 248 IPP - Internet Printing Protocol [RFC2911] and [PWG5100.12] 249 251 ISTO - IEEE Industry Standards and Technology Organization 252 254 LPD - Line Printer Daemon Protocol [RFC1179] 256 PWG - IEEE-ISTO Printer Working Group 257 259 RFC - Request for Comments 260 262 TCP - Transmission Control Protocol [STD7] 264 TLS - Transport Layer Security [RFC5246] 266 URI - Uniform Resource Identifier [STD66] 268 URL - Uniform Resource Locator [STD66] 270 UTF-8 - Unicode Transformation Format - 8-bit [STD63] 272 3. IPP over HTTPS Transport Binding 274 This section is a normative description of the protocol steps taken 275 by an IPP Client using and an IPP Printer supporting the 'ipps' URI 276 scheme. 278 This document defines the following alternate IPP over HTTPS 279 transport binding for the abstract protocol defined in IPP/1.1 Model 280 and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version 2.0 Second 281 Edition [PWG5100.12]. 283 When using an 'ipps' URI, an IPP Client MUST establish an IPP 284 application layer connection according to the following sequence: 286 1) The IPP Client selects an 'ipps' URI value from 287 "printer-uri-supported" Printer attribute [RFC2911], a directory 288 entry, discovery info, a web page, etc.; 290 2) The IPP Client converts the 'ipps' URI to an 'https' URI 291 (replacing 'ipps' with 'https' and inserting port 631); 293 3) The IPP Client establishes a TCP [STD7] reliable transport layer 294 connection to the target endpoint - see section 3.4 'Establishing 295 a connection' in TCP [STD7]; 297 4) The IPP Client establishes a TLS/1.0 [RFC2246], TLS/1.1 [RFC4346], 298 TLS/1.2 [RFC5246], or later TLS version secure transport layer 299 connection to the target endpoint - see section 7 'The TLS 300 Handshake Protocol' in [RFC2246], [RFC4346], and [RFC5246]; 302 5) The IPP Client establishes an HTTPS [RFC2818] secure session layer 303 connection over the TLS secure transport layer to the target 304 endpoint; and 306 6) The IPP Client sends IPP application layer requests to and 307 receives responses from the IPP Printer over the HTTPS [RFC2818] 308 secure session layer connection using the POST method defined in 309 section 9.5 of HTTP/1.1 [RFC2616], as specified in section 4 310 'Encoding of Transport Layer' in IPP/1.1 Encoding and Transport 311 [RFC2910]. 313 See: Section 'Security Considerations' in [RFC2818]. 315 See: Section 10 'Security Considerations' in [PWG5100.12]. 317 4. Definition of 'ipps' URI Scheme 319 4.1. Applicability of 'ipps' URI Scheme 321 The 'ipps' URI scheme MUST only be used to specify absolute URI 322 (relative 'ipps' URI are not allowed) for IPP secure print services 323 and their associated network resources. The 'ipps' URI scheme MUST 324 only be used to specify the use of the abstract protocol defined in 325 IPP/1.1 Model and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version 326 2.0 Second Edition [PWG5100.12] over an HTTPS [RFC2818] transport, as 327 defined in this specification. Any other transport binding for IPP 328 would require a different URI scheme. 330 The 'ipps' URI scheme allows an IPP Client to choose an appropriate 331 IPP secure print service (for example, from a directory). The IPP 332 Client can establish an HTTPS connection to the specified IPP secure 333 print service. The IPP Client can send IPP protocol requests (for 334 example, 'Print-Job' requests) and receive IPP protocol responses 335 over that HTTPS connection. 337 See: Section 3.2 of this document. 339 See: Section 4.4.1 'printer-uri-supported' in IPP/1.1 Model and 340 Semantics [RFC2911]. 342 See: Section 5 'IPP URL Scheme' in IPP/1.1 Encoding and Transport 344 [RFC2910]. 346 See: Section 4 'IPP Standards' and section 10 'Security 347 Considerations' of IEEE-ISTO PWG IPP Version 2.0 Second Edition 348 [PWG5100.12]. 350 4.2. Syntax of 'ipps' URI Scheme 352 The abstract protocol defined in IPP/1.1 Model and Semantics 353 [RFC2911] places a limit of 1023 octets (NOT characters) on the 354 length of a URI. 356 See: Section 4.1.5 'uri' in [RFC2911]. 358 Note: IPP Printers ought to be cautious about depending on URI 359 lengths above 255 bytes, because some older IPP Client 360 implementations might not properly support these lengths. 362 'ipps' URI MUST be represented in absolute form. Absolute URI MUST 363 always begin with a scheme name followed by a colon. For definitive 364 information on URI syntax and semantics, see "Uniform Resource 365 Identifiers (URI) Generic Syntax and Semantics" [STD66]. This 366 specification adopts the definitions of "host", "port", 367 "path-absolute", and "query" from [STD66]. 369 The 'ipps' URI scheme syntax in ABNF [STD68] is defined as follows: 371 ipps-uri = 372 "ipps:" "//" host [ ":" port ] [ path-absolute [ "?" query ]] 374 If the port is empty or not given, then port 631 MUST be used. The 375 semantics are that the identified resource (see section 5.1.2 of 376 [RFC2616]) is located at the IPP secure print service listening for 377 HTTPS connections on that port of that host, and the Request-URI for 378 the identified resource is 'path-absolute'. 380 Note: The higher-level "authority" production is not imported from 381 [STD66], because it includes an optional "userinfo" component which 382 cannot be used in 'ipps' URI. 384 Note: The "query" production does not have defined semantics in IPP 385 and was never used in examples in IPP/1.1 Encoding and Transport 386 [RFC2910] or the original IPP URL Scheme [RFC3510]. The "query" is 387 retained here for consistency, but IPP Clients SHOULD avoid its use 388 (because the semantics could only be implementation-defined). 390 Note: Literal IPv4 or IPv6 addresses SHOULD NOT be used in 'ipps' 391 URI, because: 393 a) IP addresses are often changed after network device installation 394 (e.g., based on DHCP reassignment after a power cycle); 395 b) IP addresses often don't map simply to security domains; 396 c) IP addresses are difficult to validate with X.509 server 397 certificates (because they do not map to common name or alternate 398 name attributes); and 399 d) IPv6 link local addresses are not "portable" due to link identity 401 If the 'path-absolute' is not present in the URI, it MUST be given as 402 "/" when used as a Request-URI for a resource (see section 5.1.2 of 403 [RFC2616]). 405 An 'ipps' URI is transformed into an 'https' URI by replacing "ipps:" 406 with "https:" and inserting port 631 (if the 'port' is not present in 407 the original 'ipps' URI). 409 See: Section 3.2 of this document. 411 4.3. Associated Port for 'ipps' URI Scheme 413 All 'ipps' URI which do NOT explicitly specify a port MUST be 414 resolved to IANA-assigned well-known port 631, as registered in 415 [PORTREG]. 417 See: IANA Port Numbers Registry [PORTREG]. 419 See: IPP/1.1 Encoding and Transport [RFC2910]. 421 4.4. Associated MIME Type for 'ipps' URI Scheme 423 All 'ipps' URI MUST be used to specify secure print services which 424 support the "application/ipp" MIME media type as registered in 425 [MIMEREG] for IPP protocol requests and responses. 427 See: IANA MIME Media Types Registry [MIMEREG]. 429 See: IPP/1.1 Encoding and Transport [RFC2910]. 431 4.5. Character Encoding of 'ipps' URI Scheme 433 'ipps' URI MUST use the UTF-8 [STD63] charset for all components. 434 'ipps' URI MUST use [STD66] rules for percent encoding data octets 435 outside the US-ASCII coded character set [ASCII]. 437 4.6. Examples of 'ipps' URI 439 4.6.1. Examples of 'ipps' URI for Printers 441 The following are examples of well-formed 'ipps' URI for IPP Printers 442 (for example, to be used as protocol elements in 'printer-uri' 443 operation attributes of 'Print-Job' request messages): 445 ipps://example.com 446 ipps://example.com/ipp 447 ipps://example.com/ipp/tiger 448 ipps://example.com/ipp/fox 449 ipps://example.com/ipp/tiger/bob 450 ipps://example.com/ipp/tiger/ira 452 Each of the above URI are well-formed URI for IPP Printers and each 453 would reference a logically different IPP Printer, even though some 454 of those IPP Printers might share the same host system. The 'bob' or 455 'ira' last path components might represent two different physical 456 printer devices, while 'tiger' might represent some grouping of IPP 457 Printers (for example, a load-balancing spooler). Or the 'bob' and 458 'ira' last path components might represent separate human recipients 459 on the same physical printer device (for example, a physical printer 460 supporting two job queues). In either case, both 'bob' and 'ira' 461 would behave as different and independent IPP Printers. 463 The following are examples of well-formed 'ipps' URI for IPP Printers 464 with (optional) ports and paths: 466 ipps://example.com 467 ipps://example.com/ipp 468 ipps://example.com:631/ipp 470 The first and second 'ipps' URI above MUST be resolved to port 631 471 (IANA assigned well-known port for IPP). The second and third 'ipps' 472 URI above are equivalent (see section 4.7 below). 474 4.6.2. Examples of 'ipps' URI for Jobs 476 The following are examples of well-formed 'ipps' URI for IPP Jobs 477 (for example, to be used as protocol elements in 'job-uri' attributes 478 of 'Print-Job' response messages): 480 ipps://example.com/ipp/123 481 ipps://example.com/ipp/tiger/job123 483 'ipps' URI for Jobs are valid and meaningful only until Job 484 completion and possibly an implementation defined optional period of 485 persistence after Job completion (see IPP Model [RFC2911]). 487 Ambiguously, section 4.3.1 'job-uri' of IPP Model [RFC2911] states 488 that: 490 "the precise format of a Job URI is implementation dependent." 492 Thus, the relationship between the value of the "printer-uri" 493 operation attribute used in a 'Print-Job' request and the value of 494 the "job-uri" attribute returned in the corresponding 'Print-Job' 495 response is entirely implementation dependent. Also, section 4.3.3 496 'job-printer-uri' of IPP Model [RFC2911] states that the 497 'job-printer-uri' attribute of a Job object: 499 "permits a client to identify the Printer object that created this 500 Job object when only the Job object's URI is available to the 501 client." 503 However, the above statement is erroneous, because the transform from 504 a URI for an IPP Job to the corresponding URI for the associated IPP 505 Printer is unspecified in either IPP/1.1 Model and Semantics 506 [RFC2911] or IPP/1.1 Encoding and Transport [RFC2910]. 508 IPP Printers that implement this specification SHOULD only generate 509 'ipps' URI for Jobs (for example, in the "job-uri" attribute in a 510 'Print-Job' response) by appending exactly one path component to the 511 corresponding 'ipps' URI for the associated Printer (for 512 interoperability). 514 4.7. Comparisons of 'ipps' URI 516 When comparing two 'ipps' URI to decide if they match or not, an IPP 517 Client MUST use the same rules as those defined for 'http' URI 518 comparisons in [RFC2616] as updated by the 'https' URI scheme 519 [RFC2818], with the sole following exception: 521 - A port that is empty or not given MUST be treated as equivalent to 522 the well-known port for that 'ipps' URI (port 631). 524 See: Section 3.2.3 'URI Comparison' in [RFC2616]. 526 See: Section 2.4 'URI Format' in [RFC2818]. 528 5. Applicability of this Specification 530 5.1. Applicability to IPP Clients 532 IPP Clients that implement this specification: 534 a) MUST support the IPP over HTTPS transport binding defined in 535 section 3 and the 'ipps' URI scheme defined in section 4; 537 b) MUST support the IPP over HTTP transport binding with TLS defined 538 in section 8.2 'Using IPP with TLS' of IPP/1.1 Encoding and 539 Transport [RFC2910] (for interoperability with existing IPP 540 implementations); 542 c) MUST support the IPP over HTTPS transport binding defined in 543 section 3 of this specification; 545 d) MUST the required TLS version(s) according to the corresponding 546 IPP versions as defined in section 7 of this specification; 548 e) MUST only send IPP protocol connections to IANA assigned 549 well-known port 631 or to the explicit port specified in a given 550 'ipps' URI; 552 f) MUST only send 'ipps' URI used as protocol elements in outgoing 553 IPP protocol request messages that conform to the ABNF specified 554 in section 4.2 of this document (for example, in the "printer-uri" 555 operation attribute in a 'Print-Job' request); 557 g) MUST only convert 'ipps' URI to their corresponding 'https' URI 558 forms [RFC2818] according to the rules in section 4.2 of this 559 document. 561 5.2. Applicability to IPP Printers 563 IPP Printers that implement this specification: 565 a) MUST support the IPP over HTTPS transport binding defined in 566 section 3 and the 'ipps' URI scheme defined in section 4; 568 b) MUST support the IPP over HTTP transport binding with TLS defined 569 in section 8.2 'Using IPP with TLS' of IPP/1.1 Encoding and 570 Transport [RFC2910] (for interoperability with existing IPP 571 implementations); 573 c) MUST support the IPP over HTTPS transport binding defined in 574 section 3 of this specification; 576 d) MUST the required TLS version(s) according to the corresponding 577 IPP versions as defined in section 7 of this specification; 579 e) MUST only listen for incoming IPP protocol connections on 580 IANA-assigned well-known port 631 and MUST NOT listen for incoming 581 IPP protocol connections on any other port, unless explicitly 582 configured by system administrators or site policies; 584 f) MUST only generate 'ipps' URI used as protocol elements in 585 outgoing IPP protocol response messages that conform to the ABNF 586 specified in section 4.2 of this document (for example, in the 587 "job-uri" attribute in a 'Print-Job' response); 589 g) SHOULD only accept 'ipps' URI used as protocol elements in 590 incoming IPP protocol request messages that conform to the ABNF 591 specified in section 4.2 of this document (for example, in the 592 "printer-uri" operation attribute in a 'Print-Job' request); 594 h) SHOULD only generate 'ipps' URI for Jobs by appending exactly one 595 path component to the corresponding 'ipps' URI for the associated 596 Printer (for example, in the "job-uri" attribute in a 'Print-Job' 597 response); 599 i) SHOULD NOT generate 'ipps' URI that use literal IPv6 or IPv4 600 addresses (see section 4.2 for rationale). 602 6. IANA Considerations 604 [RFC Editor: Replace 'xxxx' with assigned RFC number before 605 publication] 607 IANA is asked to register the 'ipps' URI scheme using the following 608 template, which conforms to [BCP35]. 610 URI scheme name: ipps 612 Status: Permanent 614 URI scheme syntax: See section 4.2 of RFC xxxx. 616 URI scheme semantics: The 'ipps' URI scheme is used to designate 617 secure IPP Printer objects (print spoolers, print gateways, print 618 devices, etc.) on Internet hosts accessible using the IPP protocol 619 enhanced to support guaranteed data integrity and negotiable data 620 privacy using TLS as specified in HTTP over TLS [RFC2818]. 622 Encoding Considerations: See section 4.3 of RFC xxxx. 624 Applications/protocols that use this URI scheme name: 626 The 'ipps' URI scheme is intended to be used by applications that 627 need to access secure IPP Printers using the IPP protocol enhanced to 628 support guaranteed data integrity and negotiable data privacy using 629 TLS as specified in HTTP over TLS [RFC2818]. Such applications may 630 include (but are not limited to) IPP-capable web browsers, IPP 631 Clients that wish to print a file, and servers (e.g., print spoolers) 632 that wish to forward a print Job for processing. 634 Interoperability Considerations: The widely deployed IPP print 635 service CUPS (on most UNIX, Linux, and Mac OS X client systems) has 636 supported 'ipps' URI for several years. PWG IPP Everywhere 637 [PWG5100.14] (IPP secure, mobile printing extensions) requires the 638 use of 'ipps' URI for mandatory data integrity and negotiable data 639 confidentiality. 641 Security Considerations: See: Section 7 of RFC xxxx. 643 Contact: 645 Ira McDonald 647 Michael Sweet 649 Author/Change controller: 651 IESG 653 References: RFC 2910, RFC 2911, RFC xxxx, and IEEE-ISTO PWG 5100.12. 655 7. Security Considerations 657 7.1. Problem Statement 659 Powerful mobile devices (laptops, tablets, smartphones, etc.) are now 660 commonly used to access enterprise and Cloud print services across 661 the public Internet. This is the primary use case for PWG IPP 662 Everywhere [PWG5100.14], which has already been adopted by operating 663 system and printer vendors and several other public standards bodies. 664 End user and enterprise documents are at greater risk than ever 665 before. This IPP over HTTPS transport binding and 'ipps' URI scheme 666 specification was defined to enable high availability combined with 667 secure operation (mandatory data integrity and negotiable data 668 confidentiality) in this dynamic environment (e.g., wireless hotspots 669 in hotels, airports, and restaurants). 671 See: Section 1 Introduction of [PWG5100.14]. 673 See: Section 3.1 Rationale of [PWG5100.14]. 675 7.1.1. Targets of Attacks 677 A network print spooler (logical printer) or print device (physical 678 printer) is potentially subject to attacks, which may target: 680 a) The network (to compromise the routing infrastructure, e.g., by 681 creating congestion); 683 b) the Internet Printing Protocol (IPP) [RFC2911] (e.g., to 684 compromise the normal behavior of IPP); or 686 c) the print document content itself (e.g., to corrupt the documents 687 being transferred). 689 7.1.2. Layers of Attacks 691 Attacks against print services can be launched: 693 a) against the network infrastructure (e.g., TCP congestion control). 695 b) against the IPP data flow itself (e.g., by sending forged packets 696 or forcing TLS version downgrade); 698 c) against the IPP operation parameters (e.g., by corrupting 699 requested document processing attributes); or 701 7.2. Attacks and Defenses 703 This 'ipps' URI Scheme specification adds the following additional 704 security considerations to those described in [RFC2616], [RFC2818], 705 [RFC2910], [RFC2911], [RFC5246], [PWG5100.12], and [STD66]. 707 See: Section 15 'Security Considerations' in [RFC2616]. 709 See: Section 'Security Considerations' in [RFC2818]. 711 See: Section 8 'Security Considerations' in [RFC2910]. 713 See: Section 8 'Security Considerations' in [RFC2911]. 715 See: Appendix D 'Implementation Notes', Appendix E 'Backward 716 Compatibility', and Appendix F 'Security Analysis' of [RFC5246]. 718 See: Section 10 'Security Considerations' in [PWG5100.12]. 720 See: Section 7 'Security Considerations' in [STD66]. 722 7.2.1. Faked 'ipps' URI 724 An 'ipps' URI might be faked to point to a rogue IPP secure print 725 service, thus collecting confidential document contents from IPP 726 Clients. 728 Server authentication mechanisms and security mechanisms specified in 729 IPP/1.1 Encoding and Transport [RFC2910], TLS/1.0 [RFC2246], TLS/1.1 730 [RFC4346], TLS/1.2 [RFC5246], and HTTP over TLS [RFC2818] can be used 731 to address this threat. 733 7.2.2. Unauthorized Access by IPP Client 735 An 'ipps' URI might be used to access an IPP secure print service by 736 an unauthorized IPP Client. 738 Client authentication mechanisms and security mechanisms specified in 739 IPP/1.1 Encoding and Transport [RFC2910], TLS/1.0 [RFC2246], TLS/1.1 740 [RFC4346], TLS/1.2 [RFC5246], and HTTP over TLS [RFC2818] can be used 741 to address this threat. 743 7.2.3. Compromise at Application Layer Gateway 745 An 'ipps' URI might be used to access an IPP secure print service at 746 a print protocol application layer gateway (for example, an IPP to 747 LPD [RFC1179] gateway [RFC2569]), potentially causing silent 748 compromise of IPP security mechanisms. 750 There is no general defense against this threat by an IPP Client. 751 System administrators SHOULD avoid such configurations. 753 7.2.4. No Client Authentication for 'ipps' URI 755 An 'ipps' URI does not define parameters to specify the required IPP 756 Client authentication mechanism (for example, 'certificate' as 757 defined in section 4.4.2 'uri-authentication-supported' of IPP Model 758 [RFC2911]). 760 Either service discovery or directory protocols SHOULD be used first 761 or or an IPP Client SHOULD first establish an 'ipp' connection 762 (without TLS or any client authentication) to the target IPP Printer 763 and use a Get-Printer-Attributes query to discover the required IPP 764 Client authentication mechanism(s) associated with a given 'ipps' 765 URI. 767 7.3. TLS Cipher Suite Requirements 769 In accordance with section 10 Security Considerations of 770 [PWG5100.12], IPP Clients and IPP Printers that support this 771 specification and support a given version of TLS MUST support at 772 least the mandatory cipher suite(s) required in each supported TLS 773 version, which are as follows: 775 TLS/1.0 [RFC2246] - TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 776 TLS/1.1 [RFC4346] - TLS_RSA_WITH_3DES_EDE_CBC_SHA 777 TLS/1.2 [RFC5246] - TLS_RSA_WITH_AES_128_CBC_SHA 779 Note: IPP Client and IPP Printer implementors SHOULD consider known 780 attacks against the mandatory cipher suite(s) in each supported TLS 781 version and SHOULD follow best practice advice for alternative cipher 782 suites in later IETF specifications. 784 In accordance with section 10 Security Considerations of 785 [PWG5100.12], this IPP over HTTPS transport binding and 'ipps' URI 786 Scheme specification adds the following TLS version support 787 requirements: 789 a) An IPP Client or IPP Printer that supports this specification and 790 supports IPP/1.1 defined in [RFC2911], MUST support TLS/1.0 791 [RFC2246], MAY support TLS/1.1 [RFC4346], MAY support TLS/1.2 792 [RFC5246], and MAY support future versions of TLS, in every case 793 with at least the mandatory cipher suite(s) required in each 794 supported TLS version. 796 b) An IPP Client or IPP Printer that supports this specification and 797 supports IPP/2.0 defined in [PWG5100.12], MUST support TLS/1.0 798 [RFC2246], SHOULD support TLS/1.1 [RFC4346], MAY support TLS/1.2 799 [RFC5246], and MAY support future versions of TLS, in every case 800 with at least the mandatory cipher suite(s) required in each 801 supported TLS version. 803 c) An IPP Client or IPP Printer that supports this specification and 804 supports IPP/2.1 defined in [PWG5100.12], MUST support TLS/1.0 805 [RFC2246], MUST support TLS/1.1 [RFC4346], SHOULD support TLS/1.2 806 [RFC5246], and MAY support future versions of TLS, in every case 807 with at least the mandatory cipher suite(s) required in each 808 supported TLS version. 810 d) An IPP Client or IPP Printer that supports this specification and 811 supports IPP/2.2 defined in [PWG5100.12], MUST support TLS/1.0 812 [RFC2246], MUST support TLS/1.1 [RFC4346], MUST support TLS/1.2 813 [RFC5246], and MAY support future versions of TLS, in every case 814 with at least the mandatory cipher suite(s) required in each 815 supported TLS version. 817 8. Acknowledgments 819 This document is an individual submission to the IETF by the Internet 820 Printing Protocol Working Group of the IEEE-ISTO Printer Working 821 Group, as part of their PWG IPP Everywhere [PWG5100.14] project for 822 secure mobile printing with vendor-neutral Client software. 824 This document defines an alternate IPP transport binding to that 825 defined in the original IPP URL Scheme [RFC3510], but this document 826 does not update or obsolete [RFC3510]. 828 Thanks to Claudio Allochio, Tom Hastings (retired from Xerox), Bjoern 829 Hoerhmann, S. Mooneswamy, Tom Petch, Jerry Thrasher (Lexmark), Mykyta 830 Yevstifeyev, Pete Zehler (Xerox), and the members of the IEEE-ISTO 831 PWG IPP WG. 833 9. References 835 9.1. Normative References 837 [ASCII] "American National Standards Institute, Coded Character 838 Set -- 7-bit American Standard Code for Information 839 Interchange", ANSI X3.4, 1986. 841 [PWG5100.12] Bergman, R., Lewis, H., McDonald, I., and M. Sweet, 842 "Internet Printing Protocol Version 2.0 Second Edition 843 (IPP/2.0 SE)", PWG 5100.12, February 2011. 845 847 [PWG5100.14] McDonald, I. and M. Sweet, "PWG IPP Everywhere", PWG 848 5100.14, January 2013. 849 851 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 852 Requirement Levels, BCP 14, RFC 2119, March 1997. 854 [RFC2246] Dierks, T., and C. Allen, "The TLS Protocol Version 1.0", 855 RFC 2246, January 1999. 857 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 858 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 859 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 861 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 863 [RFC2910] Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and 864 J. Wenn, "Internet Printing Protocol/1.1: Encoding and 865 Transport", RFC 2910, September 2000. 867 [RFC2911] Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S., 868 and P. Powell, "Internet Printing Protocol/1.1: Model and 869 Semantics", RFC 2911, September 2000. 871 [RFC4346] Dierks, T., and E. Rescorla, "The Transport Layer Security 872 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 874 [RFC5246] Dierks, T., and E. Rescorla, "The Transport Layer Security 875 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 877 [STD7] Postel, J., "Transmission Control Protocol", STD 7, RFC 878 793, September 1981. 880 [STD63] Yergeau, F., "UTF-8, a transformation format of ISO 881 10646", STD 63, RFC 3629, November 2003. 883 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, Uniform 884 Resource Identifiers (URI) Generic Syntax, STD 66, RFC 885 3986, January 2005. 887 [STD68] Crocker, D., Ed., and P. Overell, "Augmented BNF for 888 Syntax Specifications: ABNF", STD 68, RFC 5234, January 889 2008. 891 9.2. Informative References 893 [BCP35] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 894 Registration Procedures for New URI Schemes", BCP 35, RFC 895 4395, February 2006. 897 [MIMEREG] Internet Assigned Numbers Authority (IANA) Registry "MIME 898 Media Types" 899 901 [PORTREG] Internet Assigned Numbers Authority (IANA) Registry "Port 902 Numbers" 903 905 [RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, 906 August 1990. 908 [RFC2569] Herriot, R., Ed., Hastings, T., Jacobs, N., and J. 909 Martin, "Mapping between LPD and IPP Protocols", RFC 2569, 910 April 1999. 912 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 913 HTTP/1.1", RFC 2817, May 2000. 915 [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. 916 Holst, "Internet Printing Protocol/1.1: Implementor's 917 Guide", RFC 3196, November 2001. 919 [RFC3510] Herriot, R. and I. McDonald, "Internet Printing 920 Protocol/1.1: IPP URL Scheme", RFC 3510, April 2003. 922 10. Appendix A - Summary of IPP URL Scheme (Informative) 924 This section is an informative summary of the original IPP URL Scheme 925 [RFC3510] and the associated IPP over HTTP transport binding defined 926 in [RFC2910]. 928 When using an 'ipp' URI [RFC3510], an IPP Client establishes an IPP 929 application layer connection according to the following sequence: 931 1) The IPP Client selects an 'ipp' URI value from 932 "printer-uri-supported" Printer attribute [RFC2911], a directory 933 entry, discovery info, a web page, etc.; 935 2) The IPP Client converts the 'ipp' URI to an 'http' URI (replacing 936 'ipp' with 'http' and inserting port 631); 938 3) The IPP Client establishes a TCP [STD7] reliable transport layer 939 connection to the target endpoint - see section 3.4 'Establishing 940 a connection' in TCP [STD7]; 942 4) The IPP Client establishes an HTTP [RFC2616] session layer 943 connection to the target endpoint - see section 8 'Connections' in 944 HTTP/1.1 [RFC2616]; 946 5) Optionally, either the IPP Client upgrades to TLS within HTTP/1.1 947 per section 3 'Client Requested Upgrade to HTTP over TLS' of 948 [RFC2817] or the IPP Printer upgrades to TLS within HTTP/1.1 per 949 section 4 'Server Requested Upgrade to HTTP over TLS' of 950 [RFC2817], in order to establish a TLS secure transport sublayer 951 within the original TCP/HTTP connection - per the 952 "uri-security-supported" (section 4.4.3 in [RFC2911]) Printer 953 attribute value parallel to the "printer-uri-supported" (see 954 section 4.4.1 in [RFC2911]) value that matches this connection; 955 and 957 6) The IPP Client sends IPP application layer requests to and 958 receives responses from the IPP Printer over the HTTP [RFC2616] 959 session layer connection using the POST method defined in section 960 9.5 of HTTP/1.1 [RFC2616], as specified in section 4 'Encoding of 961 Transport Layer' in IPP/1.1 Encoding and Transport [RFC2910]. 963 See: Section 8 'Security Considerations' in [RFC2911]. 965 See: Section 8 'Security Considerations' in [RFC2817]. 967 11. Appendix X - Change History 969 [RFC Editor: Delete this section before publication as an RFC] 971 5 November 2013 - draft-mcdonald-ipps-uri-scheme-09.txt 972 Global - Updated references, per IPP WG review. 973 Editorial - Revised Abstract, section 1 Introduction, and section 8 974 Acknowledgments to clarify that this document is an individual 975 submission to the IETF by the IPP WG of the IEEE-ISTO PWG, per S 976 Mooneswamy. 977 Editorial - Revised Abstract, section 1 Introduction, and section 8 978 Acknowledgments to clarify that this document does not update or 979 obsolete [RFC3510], per S Mooneswamy and Tom Petch. 980 Editorial - Revised section 1.1 Structure of this Document to align 981 with changes below, per Tom Petch. 982 Editorial - Revised section 2 Conventions Used in this Document to 983 add section 2.1 Printing Terminology and to remove redundant "In this 984 document" and clarify definitions, per Tom Petch. 986 Editorial - Moved former Appendix B - Abbreviations Used in this 987 Document to become section 2.2 Abbreviations, per Tom Petch. 988 Technical - Revised section 3 IPP over HTTPS Transport Binding, 989 section 5 Applicability of this Specification, and section 7 Security 990 Considerations to address specific TLS/1.0 [RFC2246], TLS/1.1 991 [RFC4346], and TLS/1.2 [RFC5246] requirements, per Tom Petch. 992 Editorial - Moved former section 3.1 IPP over HTTP Transport Binding 993 to become Appendix A - Summary of IPP URL Scheme (Informative), per 994 Tom Petch. 995 Technical - Revised section 4.2 Syntax of 'ipps' URI Scheme to add 996 note about the retention of the (unused) "query" production for 997 consistency with IPP/1.1 Encoding and Transport [RFC2910] and the 998 original IPP URL Scheme [RFC3510], but warn that it has no defined 999 semantics in IPP and therefore its use is unsafe for IPP Clients, per 1000 Tom Petch. 1001 Technical - Revised section 7 Security Considerations to add section 1002 8.1 Problem Statement, section 8.2 Attacks, and section 8.3 TLS 1003 Security Considerations, per Tom Petch. 1004 Editorial - Moved former section Appendix A - Acknowledgments to 1005 become section 8 Acknowledgements (in body of document) and updated 1006 to reflect recent comments on this document, per Tom Petch. 1007 Technical - Revised section 9.1 Normative References to add TLS/1.0 1008 [RFC2246] and TLS/1.1 [RFC4346], per Tom Petch. 1010 19 September 2013 - draft-mcdonald-ipps-uri-scheme-08.txt 1011 Global - Updated references, per IPP WG review. 1013 12 May 2013 - draft-mcdonald-ipps-uri-scheme-07.txt 1014 Editorial - Revised section 1 (introduction) to add 'Rationale for 1015 this document', per Smith Kennedy. 1016 Editorial - Global - Changed 'Conformance Requirements' to 1017 'Applicability', per Barry Leiba. 1018 Editorial - Global - Changed '[PWG5100.EW]' to '[PWG5100.14]', 1019 corrected date and URI, and moved section 8.1 (normative references), 1020 per IPP WG review. 1022 10 November 2012 - draft-mcdonald-ipps-uri-scheme-06.txt 1023 Editorial - Global - Fixed typos and indentation, per IPP WG review. 1024 Editorial - Global - changed 'generic drivers' to 'vendor-neutral 1025 Client software', per IPP WG review. 1026 Editorial - Revised section 8.2 (informative references, to correct 1027 title of "PWG IPP Everywhere" (i.e., delete version number), per IPP 1028 WG review. 1030 14 May 2012 - draft-mcdonald-ipps-uri-scheme-05.txt 1031 Editorial - Global - Fixed typos and indentation, per IPP WG review. 1032 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to 1033 insert missing "to" in "connection to the target endpoint", per IPP 1034 WG review. 1035 Editorial - Revised section 4.2 (syntax), to correct indentation of 1036 first "Note:", per IPP WG review. 1038 Editorial - Revised sections 5.1 and 5.2 (client/printer conformance) 1039 and section 7 (security considerations) to delete the out-of-scope 1040 normative references to [RFC2817], per IPP WG review. 1042 22 November 2011 - draft-mcdonald-ipps-uri-scheme-04.txt 1043 Editorial - Global - Fixed typos and indentation, per IPP WG review. 1044 Editorial - Revised Introduction and Acknowledgments to say 'project 1045 for mobile, ubiquitous printing with generic drivers', per IPP WG 1046 review. 1047 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to add 1048 references to HTTP POST and section 4 of RFC 2910, per IPP WG review. 1049 Editorial - Revised sections 3.1 and 3.2 (transport bindings) to add 1050 section references to all well-known standards (connection setup, 1051 etc.), per IPP WG review. 1052 Editorial - Revised section 4.2 (syntax) to move note from from 1053 section 4.6 (examples) and explain why literal IP addresses SHOULD 1054 NOT be used in 'ipps' URI, per IPP WG review. 1055 Editorial - Revised sections 4.6.1 and 4.6.2 (examples) to replace 1056 'abc.com' w/ 'example.com' (per IETF) and replace '/printer' path 1057 element w/ '/ipp' (better practice), per IPP WG review. 1058 Editorial - Revised section 5.2 (Printer conformance) to fold former 1059 (c) and (d) into a single requirement for standard port 631 and 1060 reordered other requirements to group MUSTs before SHOULDs, per IPP 1061 WG review. 1062 Editorial - Revised section 5.2 (Printer conformance) to add backward 1063 reference to section 4.2 for rationale for not using IP literal 1064 addresses, per IPP WG review. 1065 Editorial - Revised section 6 (IANA) to explicitly state that 'ipps' 1066 uses secure communications using HTTP over TLS, per IPP WG review. 1067 Editorial - Revised section 7 (Security) to cleanup numerous loose 1068 ends, per IPP WG review. 1069 Editorial - Revised section 8 (References) to cleanup typos and 1070 links, per IPP WG review. 1071 Editorial - Revised section 1 (introduction), section 8.2 1072 (informative references, and section 9 (appendix A) to change 1073 "[IPPEVE]" to "[PWG5100.EW]", per IPP WG review. 1075 26 August 2011 - draft-mcdonald-ipps-uri-scheme-03.txt 1076 Editorial - Revised Abstract and Introduction to state published by 1077 the IETF on behalf of IEEE-ISTO PWG (to avoid status ambiguity), per 1078 Mykyta Yevstifeyev. 1079 Editorial - Revised section 1 to list all currently defined versions 1080 of IPP in RFC 2566, RFC 2911, and PWG 5100.12, per Mykyta 1081 Yevstifeyev. 1082 Technical - Revised section 1, section 2, section 3.2, section 4.1, 1083 and section 7, to reference IPP Version 2.0 Second Edition (PWG 1084 5100.12), per Mykyta Yevstifeyev. 1085 Editorial - Revised section 3.1, to fix broken STD7 reference, per 1086 Mykyta Yevstifeyev. 1087 Editorial - Revised section 6, to add BCP35 reference for template 1088 (regression loss when the template was moved up from former 1089 appendix), per Mykyta Yevstifeyev. 1090 Editorial - Revised section 8.1 to add PWG 5100.12 (normative), 1091 Editorial - Revised section 8.2 to add PWG IPP Everywhere 1092 (informative) and RFC 1179 (informative), per Mykyta Yevstifeyev. 1093 Editorial - Revised appendix B to add references for more reading, 1094 per Mykyta Yevstifeyev. 1096 28 February 2011 - draft-mcdonald-ipps-uri-scheme-02.txt 1097 Editorial - Revised document title to emphasize IPP over HTTPS 1098 Transport Binding (reason for IETF standards-track status). 1099 Editorial - Replaced "IPP URI" with "'ipp' URI", "IPPS URI" with 1100 "'ipps' URI", "HTTP URI" with "'http' URI", and "HTTPS URI" with 1101 "'https' URI" throughout this document for conformance to section 3.1 1102 of [STD66], per Mykyta Yevstifeyev. 1103 Editorial - Revised and simplified Abstract, per Mykyta Yevstifeyev. 1104 Editorial - Revised and simplified section 1 'Introduction', per 1105 Mykyta Yevstifeyev. 1106 Editorial - Renamed section 2 from 'Conformance Terminology' to 1107 'Conventions Used in this Document', per Mykyta Yevstifeyev. 1108 Editorial - Moved former section 3.1 'IPP Model Terminology 1109 (Normative)' content into section 2 'Conventions Used in this 1110 Document' for readability, per Mykyta Yevstifeyev. 1111 Editorial - Reordered subsections and reversed word order in all 1112 subsection titles in section 4 'The 'ipps' URI Scheme' for 1113 readability, per Mykyta Yevstifeyev. 1114 Editorial - Added note to section 4.2 'Syntax of 'ipps' URI Scheme' 1115 to explain why 'authority' production is NOT imported from [STD66], 1116 because it includes an optional 'userinfo' component which cannot be 1117 used in 'ipps' URI values. 1118 Editorial - Deleted note describing empty 'host' component from 1119 section 4.2 'Syntax of 'ipps' URI Scheme', because 'host' component 1120 is mandatory in [STD66]. 1121 Editorial - Deleted 'Internationalization Considerations' section 1122 which was redundant with section 4.3 'Character Encoding of 'ipps' 1123 URI Scheme', per Mykyta Yevstifeyev. 1124 Editorial - Revised all references to follow current RFC Editor 1125 style, per Mykyta Yevstifeyev. 1126 Editorial - Moved former 'Appendix A - Registration of IPPS URI 1127 Scheme' content inline into section 6 'IANA Considerations', per 1128 Mykyta Yevstifeyev. 1129 Editorial - Moved former body section 'Acknowledgements' to 'Appendix 1130 A - Acknowledgements', per Mykyta Yevstifeyev. 1131 Editorial - Added new 'Appendix B - Abbreviations Used in this 1132 Document' for readability, per Mykyta Yevstifeyev. 1133 Editorial - Moved section 'Authors' Addresses' to end of document, 1134 per Mykyta Yevstifeyev. 1136 1 December 2010 - draft-mcdonald-ipps-uri-scheme-01.txt 1137 - Technical - added UTF-8 [STD63] as required charset for all IPPS 1138 URI in section 4.4 and section 7, per Bjoern Hoehrmann. 1140 - Technical - corrected percent encoding for data octets outside the 1141 US-ASCII range in section 4.4 and section 7, per Bjoern Hoehrmann. 1142 - Editorial - global - changed "[RFC4395]" to "[BCP35]", changed 1143 "[RFC3629]" to "[STD63]", changed "[RFC3986]" to "[STD66]", and 1144 changed "[RFC5234]" to "[STD68]", per Bjoern Hoehrmann. 1145 - Editorial - restored trailing "]]" in ABNF syntax in section 4.5, 1146 per Bjoern Hoehrmann. 1147 - Editorial - changed "Author/Change controller" to "IESG" in section 1148 12 Appendix A registration template, as required by section 5.3 of 1149 [BCP35], per Bjoern Hoehrmann. 1151 10 October 2010 - draft-mcdonald-ipps-uri-scheme-00.txt 1152 - Editorial - complete rewrite of RFC 3510 for new transport binding 1153 - Editorial - moved Abstract to beginning of first page, per ID-Nits 1154 - Editorial - fixed copyright, boilerplate, and typos, per ID-Nits 1155 - Editorial - added references to RFCs 2119 and 3510, per ID-Nits 1156 - Editorial - deleted obsolete references to RFCs 2246 and 4346, per 1157 ID-Nits 1158 - Technical - changed Intended Status to Standards Track to reflect 1159 the new normative IPPS URI scheme and transport binding 1160 - Technical - added section 3.2 IPP over HTTP Transport Binding 1161 (informative) 1162 - Technical - added section 3.3 IPP over HTTPS Transport Binding 1163 (normative) 1164 - Technical - updated section 5 Conformance Requirements to require 1165 HTTP Upgrade (RFC 2817) support (for interoperability with existing 1166 IPP implementations), per discussion on IPP WG mailing list 1167 - Editorial - updated Appendix A w/ registration template from RFC 1168 4395 1170 12. Authors' Addresses 1172 Ira McDonald 1173 High North Inc 1174 221 Ridge Ave 1175 Grand Marais, MI 49839 1177 Phone: +1 906-494-2434 1178 Email: blueroofmusic@gmail.com 1180 Michael Sweet 1181 Apple Inc 1182 10431 N De Anza Blvd, M/S 38-4LPT 1183 Cupertino, CA 95014 1185 Phone: +1 408-974-8798 1186 Email: msweet@apple.com 1187 Usage questions and comments on this 'ipps' URI Scheme can be sent 1188 directly to the editors at their above addresses and also to the PWG 1189 IPP WG mailing list. Instructions for subscribing to the PWG IPP WG 1190 mailing list can be found at: 1192 PWG IPP WG Web Page: http://www.pwg.org/ipp/ 1193 PWG IPP WG Mailing List: ipp@pwg.org 1194 PWG IPP WG Subscription: http://www.pwg.org/mailhelp.html 1196 Implementers of this specification are encouraged to join the PWG IPP 1197 WG Mailing List in order to participate in any discussions of 1198 clarification issues and comments. Note that this IEEE-ISTO PWG 1199 mailing list rejects mail from non-subscribers (in order to reduce 1200 spam).