idnits 2.17.1 draft-ietf-ipp-ipp-scheme-00.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-26) 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 4 longer pages, the longest (page 3) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 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 57: '...i.e. the server) SHOULD support the 'i...' RFC 2119 keyword, line 76: '... However, it is RECOMMENDED that if a...' RFC 2119 keyword, line 78: '... 'x'. It is also RECOMMENDED that if a...' RFC 2119 keyword, line 84: '...f the target URL SHOULD be 'ipp'. If ...' RFC 2119 keyword, line 86: '... but it is RECOMMENDED that the clien...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 107 has weird spacing: '...xplicit port....' -- 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 (March 7, 1999) is 9182 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-MOD' is defined on line 151, but no explicit reference was found in the text == Unused Reference: 'IPP-PRO' is defined on line 157, but no explicit reference was found in the text == Unused Reference: 'IPP-REQ' is defined on line 163, 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' Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 4 Carl-Uno Manros 5 Xerox Corporation 7 August 7, 1998 Expires March 7, 1999 9 Internet Printing Protocol Scheme 11 Status of this memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. Internet-Drafts are draft 17 documents valid for a maximum of six months and may be updated, 18 replaced, or obsoleted by other documents at any time. It is 19 inappropriate to use Internet-Drafts as reference material or to cite 20 them other than as "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 IPP is an application level protocol that can be used for distributed 31 printing on the Internet. Related IPP documents: 33 Design Goals for an Internet Printing Protocol 34 Internet Printing Protocol/1.0: Model and Semantics 35 Internet Printing Protocol/1.0: Encoding and Transport 37 This document decribes a possible solution to an IESG request for a 38 separate naming scheme for IPP. This is for further discussion, no 39 consensus is yet reached on this in the IPP WG. 41 Introduction 43 The quick summary is that IPP should support a new scheme 'ipp', 44 which clients and servers use in IPP attributes. Such attributes are 45 in a message body whose Content-Type is application/ipp. A client 46 maps 'ipp' URLs to 'http' URLs, and then follows the HTTP/1.1 rules 47 for constructing a Request-Line and HTTP headers. 49 The IPP document will not prohibit implementations from supporting 50 other schemes in IPP attributes, but such support is not defined by 51 this document. 53 Details 54 August 7, 1998 Expires March 7, 1999 55 Internet Printing Protocol Scheme 57 A client and an IPP object (i.e. the server) SHOULD support the 'ipp' 58 scheme in the following IPP attributes. Each of these attributes 59 identifies a printer or job object. The 'ipp' scheme is not intended 60 for use in 'uri' valued attributes not in this list. 62 job attributes - 63 job-uri 64 job-printer-uri 66 printer attributes - 67 printer-uri-supported 69 operation attributes - 70 job-uri 71 printer-uri 73 If the scheme of the target URL in a request (i.e. the value of 74 "printer-uri" or "job-uri" operation attribute) is some scheme 'x', 75 other than 'ipp', the behavior of the IPP object is not defined by 76 this document. However, it is RECOMMENDED that if an operation on an 77 IPP object creates a new value for any of the above attributes, that 78 attribute has the same scheme 'x'. It is also RECOMMENDED that if an 79 IPP object returns any of the seven attributes above in the response, 80 that the IPP object returns those URL values as is, regardless of the 81 scheme of the target URL. 83 If the client obtains a target URL from a directory service, the 84 scheme of the target URL SHOULD be 'ipp'. If the scheme is not 85 'ipp', the behavior of the client is not defined by this document, 86 but it is RECOMMENDED that the client use the URL as is as the target 87 URL. 89 Although user interfaces are beyond the scope of this document, it is 90 RECOMMENDED that if software exposes the URL values of any of the 91 above seven attributes to a human user, that the human see the URL as 92 is. 94 When a client sends a request, it MUST convert an 'ipp' target URL to 95 an 'http' target URL for use in the HTTP Request-Line and HTTP 96 headers as specified by HTTP/1.1. However, the 'ipp' target URL 97 remains as is for the value of the "printer-uri" or "job-uri" 98 attribute in the message body. If the scheme of the target URL is 99 not 'ipp', the behavior of the client is not defined by this 100 document, but it is RECOMMENDED that the client use the target URL as 101 is in the Request-Line and HTTP headers. 103 A client converts an 'ipp' URL to an 'http' URL by: 105 1) replacing the 'ipp' scheme by 'http' 106 2) adding an explicit port 631 if the URL does not contain an 107 explicit port. 109 When an IPP client sends a request directly (i.e. no proxy) to an 110 'ipp' URL such as "ipp://myhost.com/myprinter/myqueue", it MUST open 111 a TCP connection to some port (this example uses the IPP default port 112 August 7, 1998 Expires March 7, 1999 113 Internet Printing Protocol Scheme 115 631) on some host ("myhost.com" in this example) with the following 116 headers: 118 POST /myprinter/myqueue HTTP/1.1 119 Host: myhost.com:631 120 Content-type: application/ipp 121 Transfer-Encoding: chunked 122 ... 124 "printer-uri" "ipp://myhost.com/myprinter/myqueue" (encoded in 125 application/ipp message body) 127 ... 129 When an IPP client sends a request via a proxy, such as 130 "myproxy.com", to an 'ipp' URL, such as 131 "ipp://myhost.com/myprinter/myqueue", it MUST open a TCP connection 132 to some port (8080 in this example) on some proxy ("myproxy.com" in 133 this example) with the following headers: 135 POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 136 Host: myproxy.com:8080 137 Content-type: application/ipp 138 Transfer-Encoding: chunked 139 ... 141 "printer-uri" "ipp://myhost.com/myprinter/myqueue" (encoded in 142 application/ipp message body) 144 ... 146 The proxy then connects to the IPP origin server with headers that 147 are the same as the "no-proxy" example above. 149 References 151 [IPP-MOD] 153 Isaacson, S., deBry, R., Hastings, T., Herriot, R., Powell, P. 154 "Internet Printing Protocol/1.0: Model and Semantics" draft-ietf-ipp- 155 mod-10.txt, June, 1998. 157 [IPP-PRO] 159 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 160 Protocol/1.0: Encoding and Transport", draft-ietf-ipp-pro-06.txt, 161 June, 1998. 163 [IPP-REQ] 165 Wright, D., "Design Goals for an Internet Printing Protocol", draft- 166 ietf-ipp-req-02.txt, June, 1998. 168 August 7, 1998 Expires March 7, 1999 169 Internet Printing Protocol Scheme 171 Author's Address 173 Carl-Uno Manros 174 Xerox Corporation 175 701 Aviation Blvd. 176 El Segundo, CA 90245 177 manros@cp10.es.xerox.com