idnits 2.17.1 draft-ietf-ipp-ipp-scheme-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 6 months document validity. ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 4) being 69 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 ([IPP-PRO], [IPP-MOD]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 66: '...i.e. the server) MUST support the ipp-...' RFC 2119 keyword, line 88: '...uman user, it is REQUIRED that the hum...' RFC 2119 keyword, line 90: '...ds a request, it MUST convert a target...' RFC 2119 keyword, line 96: '...The client MUST use the target http-U...' RFC 2119 keyword, line 137: '.../1.0 request, it MUST return an IPP/1....' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 169 has weird spacing: '... https htt...' == Line 170 has weird spacing: '...or http http...' -- 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 (November 16, 1998) is 9294 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) == Unused Reference: 'IPP-REQ' is defined on line 205, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IPP-MOD' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPP-PRO' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPP-REQ' ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 2069 (Obsoleted by RFC 2617) Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 4 6 Robert Herriot 7 Sun Microsystems 8 Carl-Uno Manros 9 Xerox Corporation 11 November 16, 1998 13 Internet Printing Protocol/NV: IPP URL Scheme 15 Status of this memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, and 19 its working groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. Internet-Drafts are draft documents valid 21 for a maximum of six months and may be updated, replaced, or obsoleted 22 by other documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as "work in 24 progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 Internet Printing Protocol/NV (IPP/NV) is the next version of IPP, which 35 is an application level protocol for distributed printing on the 36 Internet. This document describes a new 'ipp' scheme, which is intended 37 to identify URLs that reference an IPP printing service. 39 IPP/1.0 is described by the following documents: 41 Internet Printing Protocol/1.0: Model and Semantics [IPP-MOD] 43 Internet Printing Protocol/1.0: Encoding and Transport [IPP-PRO] 45 Expires May 16, 1999 47 1 Introduction 49 This document states that IPP must support a new scheme 'ipp', which 50 clients and servers use in IPP attributes. Such attributes are in a 51 message body whose Content-Type is application/ipp. A client maps 'ipp' 52 URLs to 'http' URLs, and then follows the HTTP [RFC2068][RFC2069] rules 53 for constructing a Request-Line and HTTP headers. The 'ipp' scheme 54 implies all of the same protocol semantics as that of the 'http' scheme 55 [RFC2068], except that it represents a print service and the implicit 56 (default) port number that clients use to connect to a server is port 57 631. 59 In the remainder of this document the term 'ipp-URL' means a URL whose 60 scheme is 'ipp' and whose implicit (default) port is 631. The term 61 'http-URL' means a URL whose scheme is 'http', and the term 'https-URL' 62 means a URL whose scheme is 'https', 64 2 IPP URL Scheme 66 A client and an IPP object (i.e. the server) MUST support the ipp-URL 67 value in the following IPP attributes. 68 job attributes: 69 job-uri 70 job-printer-uri 71 printer attributes: 72 printer-uri-supported 73 operation attributes: 74 job-uri 75 printer-uri 77 Each of the above attributes identifies a printer or job object. The 78 ipp-URL is intended as the value of the attributes in this list, and for 79 no other attributes. All of these attributes have a syntax type of 80 'uri', but there are attributes with a syntax type of 'uri' that do not 81 use the 'ipp' scheme, e.g. 'job-more-info'. 83 If a printer registers its URL with a directory service, the printer 84 MUST register an ipp-URL. 86 User interfaces are beyond the scope of this document. But if software 87 exposes the ipp-URL values of any of the above five attributes to a 88 human user, it is REQUIRED that the human see the ipp-URL as is. 90 When a client sends a request, it MUST convert a target ipp-URL to a 91 target http-URL according to the following rules: 92 1. change the 'ipp' scheme to 'http' 93 2. add an explicit port 631 if the URL does not contain an explicit 94 port. Note: port 631 is the IANA-reserved TCP port number. 96 The client MUST use the target http-URL in both the HTTP Request-Line 97 and HTTP headers, as specified by HTTP[RFC2068][RFC2069] . However, the 98 client must use the target ipp-URL for the value of the "printer-uri" or 99 "job-uri" attribute within the application/ipp body of the request. 101 Expires May 16, 1999 102 For example, when an IPP client sends a request directly (i.e. no proxy) 103 to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a TCP 104 connection to port 631 (the ipp implicit port) on the host "myhost.com" 105 and sends the following data: 107 POST /myprinter/myqueue HTTP/1.1 108 Host: myhost.com:631 109 Content-type: application/ipp 110 Transfer-Encoding: chunked 111 ... 112 "printer-uri" "ipp://myhost.com/myprinter/myqueue" 113 (encoded in application/ipp message body) 114 ... 116 As another example, when an IPP client sends the same request as above 117 via a proxy "myproxy.com", it opens a TCP connection to the proxy port 118 8080 on the proxy host "myproxy.com" and sends the following data: 120 POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 121 Host: myhost.com:631 122 Content-type: application/ipp 123 Transfer-Encoding: chunked 124 ... 125 "printer-uri" "ipp://myhost.com/myprinter/myqueue" 126 (encoded in application/ipp message body) 127 ... 129 The proxy then connects to the IPP origin server with headers that are 130 the same as the "no-proxy" example above. 132 3 Compatibility with IPP/1.0 134 For compatibility with IPP/1.0, clients and IPP objects (i.e. a server) 135 MUST support additional schemes as described in this section: 137 @ If a server receives an IPP/1.0 request, it MUST return an IPP/1.0 138 response. That is, it MUST support an http-URL in the target 139 "printer-uri" and "job-uri" operation attributes in a request. If 140 the server returns any of the 3 attributes, "job-uri", "job- 141 printer-uri" or "printer-uri-supported" in the response, the value 142 of these attributes MUST be http-URLs. For security, a server MAY 143 also support https-URLs. 145 @ When a server returns the printer attribute "printer-uri- 146 supported", it MUST return all supported values for an IPP/NV 147 request. For an IPP/1.0 request, a server MUST NOT return values 148 that are ipp-URLs, i.e. it MUST return only the http-URLs and 149 https-URLs. 151 @ The table below shows the type of URL that a server returns for the 152 "job-uri" and "job-printer-uri" job attributes for all operations 153 based on how the job was created. The "or" in the table below 154 indicates an implementation option. 156 Expires May 16, 1999 157 Operation Job created via 158 attribute 159 ipp http https 160 s for a 161 request 163 ipp ipp ipp No URL 164 returned 166 http http http No URL 167 returned 169 https https https or https 170 or http http 172 @ If a server registers an ipp-URL with a name service, then it MUST 173 also register an http-URL. If a printer supports a secure 174 connection using SSL3, then it MUST register an https-URL. 176 @ An IPP/NV client MUST use an ipp-URL for non-secure printers unless 177 it receives a "version not supported" error message. Then it MUST 178 try to send a request in version 1.0, using the http-URL in place 179 of the ipp-URL for the target "job-uri" and "printer-uri" operation 180 attributes in the request. For secure printers, an IPP/NV client 181 must operate as an IPP/1.0 client and use an https-URL. An IPP/1.0 182 client MUST use an http-URL for non-secure printers and an https- 183 URL for secure printers. 185 4 Security 187 See the sections on security in the "Internet Printing Protocol/1.0: 188 Model and Semantics" [IPP-MOD] and "Internet Printing Protocol/1.0: 189 Encoding and Transport" [IPP-PRO]. 191 5 References 193 [IPP-MOD] 195 Isaacson, S., deBry, R., Hastings, T., Herriot, R., Powell, P. 196 "Internet Printing Protocol/1.0: Model and Semantics" draft-ietf-ipp- 197 mod-11.txt, November, 1998. 199 [IPP-PRO] 201 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 202 Protocol/1.0: Encoding and Transport", draft-ietf-ipp-pro-07.txt, 203 November, 1998. 205 [IPP-REQ] 207 Wright, D., "Design Goals for an Internet Printing Protocol", draft- 208 ietf-ipp-req-03.txt, November, 1998. 210 Expires May 16, 1999 212 [RFC2068] 214 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, 215 "Hypertext Transfer Protocol - HTTP/1.1", RFC 2068, January 1997 217 [RFC2069] 219 J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. 220 Sink, L. Stewart, "An Extension to HTTP: Digest Access 221 Authentication", RFC-2069, Jan 1997. 223 5.1 Authors' Address 225 Robert Herriot 226 Sun Microsystems 227 901 San Antonio Road, MPK-17 228 Palo Alto, CA 94303 229 robert.herriot@eng.sun.com 231 Carl-Uno Manros 232 Xerox Corporation 233 701 Aviation Blvd. 234 El Segundo, CA 90245 235 manros@cp10.es.xerox.com 237 Expires May 16, 1999