idnits 2.17.1 draft-ietf-ipp-url-scheme-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2717], [RFC2910], [RFC2911]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 176: '...citly specify a port MUST be used over...' RFC 2119 keyword, line 184: '...quests and responses) MUST be conveyed...' RFC 2119 keyword, line 186: '... [IANA-MIMEREG]. IPP URLs MUST refer to IPP Printers which support...' RFC 2119 keyword, line 203: '... [RFC2396]. Codepoints outside [US-ASCII] MUST be hex escaped by the...' RFC 2119 keyword, line 223: '... Printer MUST return 'client-error-r...' (20 more instances...) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2910, but the abstract doesn't seem to directly say this. It does mention RFC2910 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in '[Target Category: Standards Track]', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) (Using the creation date from RFC2910, updated by this document, for RFC5378 checks: 1999-02-22) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (10 July 2002) is 7960 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: 'RFC2119' is mentioned on line 123, but not defined == Missing Reference: 'RFC1900' is mentioned on line 575, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-MIMEREG' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-PORTREG' ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2717 (Obsoleted by RFC 4395) ** Obsolete normative reference: RFC 2732 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2910 (Obsoleted by RFC 8010) ** Obsolete normative reference: RFC 2911 (Obsoleted by RFC 8011) -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Printing Protocol Working Group Bob Herriot 3 INTERNET DRAFT Consultant 4 Ira McDonald 5 Updates: RFC 2910 High North Inc 6 [Target Category: Standards Track] 10 January 2002 7 Expires 10 July 2002 9 IPP URL Scheme 10 12 Copyright (C) The Internet Society (2002). All Rights Reserved. 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 To view the list of Internet-Draft Shadow Directories, see 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This memo defines the "ipp" URL scheme for registration by IANA in 33 the IETF tree. This memo fully conforms to the requirements in 34 [RFC2717]. The "ipp" URL (Uniform Resource Locator) scheme is used 35 for specifying the location of an IPP Printer, IPP Job, or other IPP 36 object (defined in any future version of IPP) which implements the 37 IPP/1.1 Model [RFC2911] and the IPP/1.1 Protocol encoding over HTTP 38 [RFC2910] or any later version of IPP. The intended usage of the 39 "ipp" URL scheme is COMMON. 41 Table of Contents 43 1. Introduction ............................................... 3 44 2. Terminology ................................................ 4 45 2.1. Conformance Terminology ................................ 4 46 2.2. Model Terminology ...................................... 4 47 3. IPP Model for Printers and Jobs ............................ 5 48 4. IPP URL Scheme ............................................. 6 49 4.1. Applicability and Intended Usage ....................... 6 50 4.2. Associated IPP Port .................................... 6 51 4.3. Associated IPP MIME Type ............................... 6 52 4.4. Character Encoding ..................................... 6 53 4.5. Syntax in ABNF ......................................... 7 54 4.5.1. IPP URL Examples ................................... 8 55 4.5.2. IPP URL Comparisons ................................ 9 56 5. Conformance Requirements ................................... 10 57 5.1. Conformance Requirements for IPP Clients ............... 10 58 5.2. Conformance Requirements for IPP Printers .............. 10 59 6. IANA Considerations ........................................ 11 60 7. Internationalization Considerations ........................ 11 61 8. Security Considerations .................................... 11 62 9. References ................................................. 12 63 10. Acknowledgments ........................................... 12 64 11. Authors' Addresses ........................................ 13 65 12. Full Copyright Statement .................................. 14 66 13. Appendix X - Change History ............................... 15 67 1. Introduction 69 See section 1 'Introduction' in [RFC2911] for a full description of 70 the IPP document set and overview information about IPP. 72 This memo defines the "ipp" URL scheme for registration by IANA in 73 the IETF tree. This memo fully conforms to the requirements in 74 [RFC2717]. The "ipp" URL (Uniform Resource Locator) scheme is used 75 for specifying the location of an IPP Printer, IPP Job, or other IPP 76 object (defined in any future version of IPP) which implements the 77 IPP/1.1 Model [RFC2911] and the IPP/1.1 Protocol encoding over HTTP 78 [RFC2910] or any later version of IPP. The intended usage of the 79 "ipp" URL scheme is COMMON. 81 The IPP URL scheme defined in this document is based on the ABNF for 82 the HTTP URL scheme defined in HTTP/1.1 [RFC2616], which is derived 83 from the URI Generic Syntax [RFC2396] and further updated by 84 [RFC2732] and [RFC2373] (for IPv6 addresses in URLs). An IPP URL is 85 transformed into an HTTP URL according to the rules specified in 86 section 5 of the IPP/1.1 Encoding and Transport [RFC2910]. 88 This document defines: 89 - IPP URL scheme applicability and intended usage; 90 - IPP URL scheme associated port (i.e., well-known port 631); 91 - IPP URL scheme associated MIME type (i.e., "application/ipp"); 92 - IPP URL scheme character encoding; 93 - IPP URL scheme syntax in ABNF [RFC2234]; 94 - IPP URL scheme IANA, internationalization, and security 95 considerations. 97 This document is laid out as follows: 98 - Section 2 is the terminology used throughout the document. 100 - Section 3 provides references to the IPP Printer and IPP Job object 101 model. 103 - Section 4 specifies the IPP URL scheme. 105 - Section 5 specifies the conformance requirements for IPP Clients 106 and IPP Printers that claim conformance to this document. 108 - Sections 6, 7, and 8 specify IANA, internationalization, and 109 security considerations. 111 - Sections 9, 10, 11, and 12 list references, acknowledgements, 112 authors' addresses, and full IETF copyright statement. 114 2. Terminology 116 This specification document uses the terminology defined in this 117 section. 119 2.1. Conformance Terminology 121 The uppercase terms "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 122 NOT" "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 123 this document are to be interpreted as described in [RFC2119]. These 124 terms are used to specify conformance requirements for all 125 implementations of this specification. 127 2.2. Model Terminology 129 See section 12.2 'Model Terminology' in [RFC2911]. 131 3. IPP Model for Printers and Jobs 133 See section 2 'IPP Objects', section 2.1 'Printer Object', and 134 section 2.2 'Job Object' in [RFC2911] for a full description of the 135 IPP object model and terminology. 137 In this document, "IPP Client" means the software (on some hardware 138 platform) that submits, monitors, and/or manages print jobs via 139 IPP/1.1 [RFC2910] [RFC2911], or any later version of IPP to a 140 spooler, gateway, or actual printing device. 142 In this document, "IPP Printer object" means the software (on some 143 hardware platform) that receives print jobs and/or printer/job 144 operations via IPP/1.1 [RFC2910] [RFC2911], or any later version of 145 IPP from an "IPP Client". 147 In this document, "IPP Printer" is a synonym for "IPP Printer 148 object". 150 In this document, "IPP Job object" means the set of attributes and 151 documents for one print job on an "IPP Printer". 153 In this document, "IPP Job" is a synonym for "IPP Job object". 155 In this document, "IPP URL" means a URL with the "ipp" scheme. 157 Note: In this document, "IPP URL" is a synonym for "ipp_URL" (in 158 section 4 'IPP URL Scheme' of this document) and "ipp-URL" (in 159 section 5 'IPP URL Scheme' of [RFC2910]). 161 4. IPP URL Scheme 163 4.1. Applicability and Intended Usage 165 This memo defines the "ipp" URL scheme for registration by IANA in 166 the IETF tree. This memo fully conforms to the requirements in 167 [RFC2717]. The "ipp" URL (Uniform Resource Locator) scheme is used 168 for specifying the location of an IPP Printer, IPP Job, or other IPP 169 object (defined in any future version of IPP) which implements the 170 IPP/1.1 Model [RFC2911] and the IPP/1.1 Protocol encoding over HTTP 171 [RFC2910] or any later version of IPP. The intended usage of the 172 "ipp" URL scheme is COMMON. 174 4.2. Associated IPP Port 176 All IPP URLs which do NOT explicitly specify a port MUST be used over 177 IANA-assigned well-known port 631, as registered in [IANA-PORTREG]. 179 See: IANA Port Numbers Registry [IANA-PORTREG]. 180 See: IPP Encoding and Transport [RFC2910]. 182 4.3. Associated IPP MIME Type 184 All IPP protocol operations (requests and responses) MUST be conveyed 185 in an "application/ipp" MIME media type as registered in 186 [IANA-MIMEREG]. IPP URLs MUST refer to IPP Printers which support 187 this "application/ipp" MIME media type. 189 See: IANA MIME Media Types Registry [IANA-MIMEREG]. 190 See: IPP Encoding and Transport [RFC2910]. 192 4.4. Character Encoding 194 The IPP URL scheme defined in this document is based on the ABNF for 195 the HTTP URL scheme defined in HTTP/1.1 [RFC2616], which is derived 196 from the URI Generic Syntax [RFC2396] and further updated by 197 [RFC2732] and [RFC2373] (for IPv6 addresses in URLs). An IPP URL is 198 transformed into an HTTP URL according to the rules specified in 199 section 5 of the IPP/1.1 Encoding and Transport [RFC2910]. 201 The IPP URL scheme is case-insensitive in the host name or host 202 address part; however the path part is case-sensitive, as in 203 [RFC2396]. Codepoints outside [US-ASCII] MUST be hex escaped by the 204 mechanism specified in [RFC2396]. 206 4.5. Syntax in ABNF 208 Note: In this document, "IPP URL" is a synonym for "ipp_URL" (in 209 section 4 'IPP URL Scheme' of this document) and "ipp-URL" (in 210 section 5 'IPP URL Scheme' of [RFC2910]). 212 This memo defines the "ipp" URL scheme for registration by IANA in 213 the IETF tree. This memo fully conforms to the requirements in 214 [RFC2717]. The "ipp" URL (Uniform Resource Locator) scheme is used 215 for specifying the location of an IPP Printer, IPP Job, or other IPP 216 object (defined in any future version of IPP) which implements the 217 IPP/1.1 Model [RFC2911] and the IPP/1.1 Protocol encoding over HTTP 218 [RFC2910] or any later version of IPP. The intended usage of the 219 "ipp" URL scheme is COMMON. 221 The IPP protocol places a limit of 1023 octets (NOT characters) on 222 the length of a URI (see section 4.1.5 'uri' in [RFC2911]). An IPP 223 Printer MUST return 'client-error-request-value-too-long' (see 224 section 13.1.4.10 in [RFC2911]) when a URI received in a request 225 (e.g., in the "printer-uri" attribute) is too long. 227 Note: IPP Printers ought to be cautious about depending on URI 228 lengths above 255 bytes, because some older client implementations 229 might not properly support these lengths. 231 IPP URLs MUST be represented in absolute form. Absolute URLs always 232 begin with a scheme name followed by a colon. For definitive 233 information on URL syntax and semantics, see "Uniform Resource 234 Identifiers (URI): Generic Syntax and Semantics" [RFC2396]. This 235 specification adopts the definitions of "host", "port", "abs_path", 236 "rel_path", and "query" from [RFC2396], as updated by [RFC2732] and 237 [RFC2373] (for IPv6 addresses in URLs). 239 The IPP URL scheme syntax in ABNF is as follows: 241 ipp_URL = "ipp:" "//" host [ ":" port ] [ abs_path [ "?" query ]] 243 If the port is empty or not given, port 631 is assumed. The 244 semantics are that the identified resource (see section 5.1.2 of 245 [RFC2616]) is located at the IPP Printer or IPP Job listening for 246 HTTP connections on that port of that host, and the Request-URI for 247 the identified resource is 'abs_path'. 249 If the 'abs_path' is not present in the URL, it MUST be given as "/" 250 when used as a Request-URI for a resource (see section 5.1.2 of 252 [RFC2616]). 254 4.5.1. IPP URL Examples 256 The following are examples of valid IPP URLs for IPP Printers: 258 ipp://abc.com 259 ipp://abc.com/printer 260 ipp://abc.com/tiger 261 ipp://abc.com/printers/tiger 262 ipp://abc.com/printers/fox 263 ipp://abc.com/printers/tiger/bob 264 ipp://abc.com/printers/tiger/ira 265 ipp://printer.abc.com 266 ipp://printers.abc.com/tiger 267 ipp://printers.abc.com/tiger/bob 268 ipp://printers.abc.com/tiger/ira 270 Each of the above URLs are legitimate URLs for IPP Printers and each 271 references a logically different IPP Printer, even though some of the 272 IPP Printers may share the same hardware. The last part of the path 273 'bob' or 'ira' may represent two different hardware devices where 274 'tiger' represents some grouping of IPP Printers (e.g., a 275 load-balancing spooler) or the two names may represent separate human 276 recipients ('bob' and 'ira') on the same hardware device (e.g., a 277 printer supporting two job queues). In either case both 'bob' and 278 'ira' behave as different IPP Printers. 280 The following are examples of IPP URLs with (optional) ports and 281 paths: 283 ipp://abc.com 284 ipp://abc.com/~smith/printer 285 ipp://abc.com:631/~smith/printer 287 The first and second IPP URLs above MUST be resolved to port 631 288 (IANA assigned well-known port for IPP). The second and third IPP 289 URLs above are equivalent (see section 4.5.2 below). 291 The following literal IPv4 addresses: 293 192.9.5.5 ; IPv4 address in IPv4 style 294 186.7.8.9 ; IPv4 address in IPv4 style 296 are represented in the following example IPP URLs: 298 ipp://192.9.5.5/prt1 299 ipp://186.7.8.9/printers/tiger/bob 301 The following literal IPv6 addresses (conformant to [RFC2373]): 303 ::192.9.5.5 ; IPv4 address in IPv6 style 304 ::FFFF:129.144.52.38 ; IPv4 address in IPv6 style 305 2010:836B:4179::836B:4179 ; IPv6 address per RFC 2373 307 are represented in the following example IPP URLs: 309 ipp://[::192.9.5.5]/prt1 310 ipp://[::FFFF:129.144.52.38]:631/printers/tiger 311 ipp://[2010:836B:4179::836B:4179]/printers/tiger/bob 313 4.5.2. IPP URL Comparisons 315 When comparing two IPP URLs to decide if they match or not, an IPP 316 Client MUST use the same rules as those defined for HTTP URI 317 comparisons in [RFC2616], with the sole following exception: 319 - A port that is empty or not given MUST be treated as equivalent to 320 the well-known port for that IPP URL (port 631); 322 See: Section 3.2.3 'URI Comparison' in [RFC2616]. 324 5. Conformance Requirements 326 5.1. Conformance Requirements for IPP Clients 328 IPP Clients that conform to this specification: 330 a) MUST send IPP URLs (e.g., in the "printer-uri" operation attribute 331 in 'Print-Job') that conform to the ABNF specified in section 4.5 332 of this document; 334 b) MUST send IPP operations via the port specified in the IPP URL (if 335 present) or otherwise via IANA assigned well-known port 631; 337 c) MUST convert IPP URLs to their corresponding HTTP URL forms 338 according to the rules in section 5 'IPP URL Scheme' in [RFC2910]; 340 d) SHOULD interoperate with IPP/1.0 Printers according to the rules 341 in section 9 'Interoperability with IPP/1.0 Implementations' and 342 section 9.2 'Security and URL Schemes' in [RFC2910]. 344 5.2. Conformance Requirements for IPP Printers 346 IPP Printers that conform to this specification: 348 a) SHOULD reject received IPP URLs in "application/ipp" request 349 bodies (e.g., in the "printer-uri" attribute in a 'Print-Job' 350 request) that do not conform to the ABNF for IPP URLs specified in 351 section 4.5 of this document; 353 b) SHOULD return IPP URLs in "application/ipp" response bodies (e.g., 354 in the "job-uri" attribute in a 'Print-Job' response) that do 355 conform to the ABNF for IPP URLs specified in section 4.5 of this 356 document; 358 c) MUST listen for IPP operations on IANA-assigned well-known port 359 631, unless explicitly configured by system administrators or site 360 policies; 362 d) SHOULD NOT listen for IPP operations on any other port, unless 363 explicitly configured by system administrators or site policies; 365 e) SHOULD interoperate with IPP/1.0 Clients according to the rules in 366 section 9 'Interoperability with IPP/1.0 Implementations' and 367 section 9.2 'Security and URL Schemes' in [RFC2910]. 369 6. IANA Considerations 371 This memo defines the "ipp" URL scheme for registration by IANA in 372 the IETF tree. This memo fully conforms to the requirements in 373 [RFC2717]. The "ipp" URL (Uniform Resource Locator) scheme is used 374 for specifying the location of an IPP Printer, IPP Job, or other IPP 375 object (defined in any future version of IPP) which implements the 376 IPP/1.1 Model [RFC2911] and the IPP/1.1 Protocol encoding over HTTP 377 [RFC2910] or any later version of IPP. The intended usage of the 378 "ipp" URL scheme is COMMON. 380 This IPP URL Scheme specification does not introduce any additional 381 IANA considerations, beyond those described in [RFC2910] and 382 [RFC2911]. 384 See: Section 6 'IANA Considerations' in [RFC2910] 385 See: Section 6 'IANA Considerations' in [RFC2911]. 387 7. Internationalization Considerations 389 This IPP URL Scheme specification does not introduce any additional 390 internationalization considerations, beyond those described in 391 [RFC2910] and [RFC2911]. 393 See: Section 7 'Internationalization Considerations' in [RFC2910]. 394 See: Section 7 'Internationalization Considerations' in [RFC2911]. 396 8. Security Considerations 398 This IPP URL Scheme specification does not introduce any additional 399 security considerations, beyond those described in [RFC2910] and 400 [RFC2911]. 402 See: Section 8 'Security Considerations' in [RFC2910]. 403 See: Section 8 'Security Considerations' in [RFC2911]. 405 9. References 407 See: Section 10 'References' in [RFC2910]. 409 [IANA-MIMEREG] IANA MIME Media Types Registry. 410 ftp://ftp.iana.org/in-notes/iana/assignments/media-types/... 412 [IANA-PORTREG] IANA Port Numbers Registry. 413 ftp://ftp.iana.org/in-notes/iana/assignments/port-numbers 415 [RFC2234] D. Crocker, P. Overell. Augmented BNF for Syntax 416 Specifications: ABNF, RFC 2234, November 1997. 418 [RFC2373] R. Hinden, S. Deering. IP Version 6 Addressing 419 Architecture, RFC 2373, July 1998. 421 [RFC2396] T. Berners-Lee, R. Fielding, L. Masinter. Uniform Resource 422 Identifiers (URI): Generic Syntax, RFC 2396, August 1998. 424 [RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, 425 P. Leach, T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1, 426 RFC 2616, June 1999. 428 [RFC2717] R. Petke, I. King. Registration Procedures for URL Scheme 429 Names, RFC 2717, November 1999. 431 [RFC2732] R. Hinden,B. Carpenter, L. Masinter. Format for Literal 432 IPv6 Addresses in URL's, RFC 2732, December 1999. 434 [RFC2910] R. Herriot, S. Butler, P. Moore, R. Turner, J. Wenn. 435 IPP/1.1 Encoding and Transport, RFC 2910, September 2000. 437 [RFC2911] T. Hastings, R. Herriot, R. deBry, S. Isaacson, P. Powell. 438 IPP/1.1 Model and Semantics, RFC 2911, September 2000. 440 [US-ASCII] Coded Character Set -- 7-bit American Standard Code for 441 Information Interchange, ANSI X3.4-1986. 443 10. Acknowledgments 445 This document is a product of the Internet Printing Protocol Working 446 Group of the Internet Engineering Task Force (IETF). 448 Thanks to Pat Fleming (IBM), Tom Hastings (Xerox), Harry Lewis (IBM), 449 Hugo Parra (Novell), Don Wright (Lexmark), and all the members of the 450 IETF IPP WG. 452 Section 5 'IPP URL Scheme' in IPP/1.1 Encoding and Transport 453 [RFC2910] was the primary input to this IPP URL Scheme specification. 455 11. Authors' Addresses 457 Robert Herriot 458 Consultant 459 706 Colorado Ave 460 Palo Alto, CA 94303 462 Phone: +1 650-327-4466 463 Fax: +1 650-327-4466 464 Email: bob@herriot.com 466 Ira McDonald 467 High North Inc 468 221 Ridge Ave 469 Grand Marais, MI 49839 471 Phone: +1 906-494-2434 or +1 906-494-2697 472 Email: imcdonald@sharplabs.com 474 Usage questions and comments on this IPP URL Scheme should be sent 475 directly to the editors at their above addresses (and to the IPP 476 mailing list, if you are a subscriber - see below). 478 IPP Web Page: http://www.pwg.org/ipp/ 479 IPP Mailing List: ipp@pwg.org 481 To subscribe to the IPP mailing list, send the following email: 482 1) send it to majordomo@pwg.org 483 2) leave the subject line blank 484 3) put the following two lines in the message body: 485 subscribe ipp 486 end 488 Implementers of this specification are encouraged to join the IPP 489 Mailing List in order to participate in any discussions of 490 clarification issues and comments. In order to reduce spam the 491 mailing list rejects mail from non-subscribers, so you must subscribe 492 to the mailing list in order to send a question or comment to the IPP 493 mailing list. 495 12. Full Copyright Statement 497 Copyright (C) The Internet Society (2002). All Rights Reserved. 499 This document and translations of it may be copied and furnished to 500 others, and derivative works that comment on or otherwise explain it 501 or assist in its implementation may be prepared, copied, published 502 and distributed, in whole or in part, without restriction of any 503 kind, provided that the above copyright notice and this paragraph are 504 included on all such copies and derivative works. However, this 505 document itself may not be modified in any way, such as by removing 506 the copyright notice or references to the Internet Society or other 507 Internet organizations, except as needed for the purpose of 508 developing Internet standards in which case the procedures for 509 copyrights defined in the Internet Standards process must be 510 followed, or as required to translate it into languages other than 511 English. 513 The limited permissions granted above are perpetual and will not be 514 revoked by the Internet Society or its successors or assigns. 516 This document and the information contained herein is provided on an 517 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 518 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 519 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 520 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 521 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 523 13. Appendix X - Change History 525 [To be deleted before RFC publication] 527 10 January 2002 - draft-ietf-ipp-url-scheme-04.txt 528 - final edits after IESG 'last call' comments; 529 - revised all titles in sections 4.x to remove redundant prefix of 530 'IPP URL Scheme', for readability; 531 - revised 'Abstract', section 1 'Introduction', section 4.1 532 'Applicability and Intended Usage', section 4.5 'Syntax in ABNF', 533 and section 6 'IANA Considerations', to explicitly state that the 534 "ipp" URL scheme is intended for IANA registration in the IETF URL 535 scheme tree; 536 - revised section 4.5 'Syntax in ABNF', to delete references to 537 unused ABNF components from [RFC2396]; 538 - revised section 11 'Authors' Addresses', to update contact info for 539 both editors and to add the IPP Web page and mailing list 540 subscription info; 541 - moved 'Appendix X - Change History' to back of document, to 542 facilitate final edits for RFC publication (including deletion of 543 change history); 545 2 April 2001 - draft-ietf-ipp-url-scheme-03.txt 546 - final edits after IETF IPP WG 'last call' comments; 547 - revised 'Abstract' and section 1 'Introduction' to remove 548 references to ISSUE's and request for comments to the 'ipp@pwg.org' 549 mailing list, in preparation for publication as an RFC; 550 - revised section 4.5 'IPP URL Scheme Syntax in ABNF' to delete all 551 references to HTTP proxy behavior (which IPP does NOT specify), per 552 request of Don Wright; 553 - revised section 4.5.1 'IPP URL Examples' to remove note 554 discouraging the use of literal IP addresses in URLs, to remove 555 dependency on Informational [RFC1900]; 556 - revised section 4.5.2 'IPP URL Comparisons' to specify the use of 557 rules defined in section 3.2.3 'URI Comparison' in [RFC2616], with 558 the sole exception that an empty port MUST be treated as equivalent 559 to the IPP well-known port 631, per request of Don Wright; 560 - revised section 9 'References' to delete all unused references; 561 - revised section 11 'Authors' Addresses' to add the address of the 562 IPP WG mailing list for usage questions and comments; 564 13 February 2001 - draft-ietf-ipp-url-scheme-02.txt 565 - revised section 3 'IPP Model for Printers and Jobs' and section 4.5 566 'IPP URL Scheme Syntax in ABNF' to add notes stating that "IPP URL" 567 (in this document) is a synonym for "ipp-URL" in [RFC2910], per 568 request of Bob Herriot; 569 - revised section 4.5 'IPP URL Scheme Syntax in ABNF' to correct typo 570 that showed "http:" rather than "ipp:" in the one-line ABNF, per 571 request of Tom Hastings; 573 - revised section 4.5.1 'IPP URL Examples' to add a note discouraging 574 the use of literal IP addresses in URLs, per [RFC2616] and 575 [RFC1900]; 577 5 February 2001 - draft-ietf-ipp-url-scheme-01.txt 578 - revised section 4.1 'IPP URL Applicability and Intended Usage' to 579 clarify that a given IPP URL MAY identify an IPP Printer object or 580 an IPP Job object, per request of Tom Hastings; 581 - revised section 4.5 'IPP URL Scheme Syntax in ABNF' to define IPP 582 URLs consistently with section 3.2.2 'http URL' of HTTP/1.1 583 [RFC2616], per request of Tom Hastings; 584 - revised section 4.5 'IPP URL Scheme Syntax in ABNF' to clarify that 585 IPP URLs may reference IPP Printer objects, IPP Job objects, or 586 (possibly other future) IPP objects, per request of Bob Herriot; 587 - added section 4.5.1 'IPP URL Examples' to supply meaningful 588 examples of IPP URLs with host names, IPv4 addresses, and IPv6 589 addresses, per request of Tom Hastings; 590 - added section 4.5.2 'IPP URL Comparisons' to define IPP URL 591 comparisons consistently with section 3.3 'URI Comparison' of 592 HTTP/1.1 [RFC2616], per request of Tom Hastings; 593 - revised section 5.1 'Conformance Requirements for IPP Clients' to 594 clarify that an IPP Client MUST convert IPP URLs to their 595 corresponding HTTP URL forms according to section 5 'IPP URL 596 Scheme' in [RFC2910], per request of Tom Hastings and Bob Herriot; 597 - revised section 5.1 'Conformance Requirements for IPP Clients' and 598 section 5.2 'Conformance Requirements for IPP Printers' to clarify 599 that IPP Clients and IPP Printers SHOULD interoperate with IPP/1.0 600 systems according to section 9 'Interoperability with IPP/1.0 601 Implementations' in [RFC2910], per request of Carl Kugler; 602 - revised section 5.2 'Conformance Requirements for IPP Printers' to 603 clarify that an IPP Printer MUST listen on (IANA assigned 604 well-known) port 631, unless explicitly configured, per request of 605 Michael Sweet; 606 - revised section 5.2 'Conformance Requirements for IPP Printers' to 607 clarify that an IPP Printer SHOULD NOT listen on ports other than 608 (IANA assigned well-known) port 631, unless explicitly configured, 609 per request of Don Wright; 610 - revised section 6 'IANA Considerations' to clarify that the sole 611 purpose of the entire document is IANA registration of the "ipp" 612 URL scheme; 613 - deleted Appendix A 'Registration of IPP Port' as unnecessary (port 614 is already registered); 615 - deleted Appendix B 'Registration of MIME "application/ipp" as 616 unnecessary (MIME registry has recently caught up to RFC 2910); 618 11 January 2001 - draft-ietf-ipp-url-scheme-00.txt 619 - initial version - simple "ipp" URL scheme without parameters or 620 query part (consistent with existing and IPP/1.1 implementations); 621 - added Appendix A 'Registration of IPP Port' (placeholder) for 622 updated IANA registration of port 631 with references to IPP/1.1; 624 - added Appendix B 'Registration of MIME "application/ipp"' with 625 updated IANA registration for IPP MIME type with references to both 626 IPP/1.0 and IPP/1.1;