idnits 2.17.1 draft-ietf-ipp-output-bin-attr-00.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: ---------------------------------------------------------------------------- ** 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 the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 6) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2568], [RFC2616], [RFC2569], [RFC2566], [RFC2567]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** 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 36: '... OPTIONAL "output-bin" Job Templat...' RFC 2119 keyword, line 59: '... IPP/1.0. A few OPTIONAL operator ope...' RFC 2119 keyword, line 170: '...or 'name' values MAY possess any of th...' RFC 2119 keyword, line 172: '...ion. However, each output bin MUST be...' RFC 2119 keyword, line 184: '...allowed as a destination for a job MAY...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 123 has weird spacing: '...user to selec...' -- 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 (October 21, 1999) is 8951 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 section? 'RFC2026' on line 20 looks like a reference -- Missing reference section? 'RFC2566' on line 34 looks like a reference -- Missing reference section? 'RFC2567' on line 45 looks like a reference -- Missing reference section? 'RFC2568' on line 47 looks like a reference -- Missing reference section? 'RFC2569' on line 51 looks like a reference -- Missing reference section? 'RFC2616' on line 70 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 2 3 T. Hastings 4 Xerox Corporation 5 R. Bergman 6 Dataproducts Corp. 7 October 21, 1999 9 Internet Printing Protocol/1.1: "output-bin" attribute extension 11 Copyright (C) The Internet Society (1999). All Rights Reserved. 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of [RFC2026]. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, and 18 its working groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference material 24 or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed as 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document defines an extension to the IPP/1.0 [RFC2566] & 35 IPP/1.1 [ipp-mod] Model and Semantics specification for the 36 OPTIONAL "output-bin" Job Template attribute. This attribute 37 allows the client to specify in which output bin a job is to be 38 placed and to query the Printer's default and supported output 39 bins. 41 Expires: April 21, 2000 43 The full set of IPP documents includes: 45 Design Goals for an Internet Printing Protocol [RFC2567] 46 Rationale for the Structure and Model and Protocol for the Internet 47 Printing Protocol [RFC2568] 48 Internet Printing Protocol/1.1: Model and Semantics [ipp-mod] 49 Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro] 50 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 51 Mapping between LPD and IPP Protocols [RFC2569] 53 The "Design Goals for an Internet Printing Protocol" document takes a 54 broad look at distributed printing functionality, and it enumerates 55 real-life scenarios that help to clarify the features that need to be 56 included in a printing protocol for the Internet. It identifies 57 requirements for three types of users: end users, operators, and 58 administrators. It calls out a subset of end user requirements that are 59 satisfied in IPP/1.0. A few OPTIONAL operator operations have been 60 added to IPP/1.1. 62 The "Rationale for the Structure and Model and Protocol for the Internet 63 Printing Protocol" document describes IPP from a high level view, 64 defines a roadmap for the various documents that form the suite of IPP 65 specification documents, and gives background and rationale for the IETF 66 working group's major decisions. 68 The "Internet Printing Protocol/1.1: Encoding and Transport" document is 69 a formal mapping of the abstract operations and attributes defined in 70 the model document onto HTTP/1.1 [RFC2616]. It defines the encoding 71 rules for a new Internet MIME media type called "application/ipp". This 72 document also defines the rules for transporting over HTTP a message 73 body whose Content-Type is "application/ipp". This document defines a 74 new scheme named 'ipp' for identifying IPP printers and jobs. 76 The "Internet Printing Protocol/1.1: Implementer's Guide" document gives 77 insight and advice to implementers of IPP clients and IPP objects. It 78 is intended to help them understand IPP/1.1 and some of the 79 considerations that may assist them in the design of their client and/or 80 IPP object implementations. For example, a typical order of processing 81 requests is given, including error checking. Motivation for some of the 82 specification decisions is also included. 84 The "Mapping between LPD and IPP Protocols" document gives some advice 85 to implementers of gateways between IPP and LPD (Line Printer Daemon) 86 implementations. 88 Expires: April 21, 2000 89 TABLE OF CONTENTS 91 1 Add new "output-bin" Job Template attributes.....................4 93 1.1 Problem.......................................................4 95 1.2 Suggested solution............................................4 97 1.3 Proposed text.................................................4 99 2 IANA Considerations..............................................7 101 3 Internationalization Considerations..............................7 103 4 Security Considerations..........................................7 105 5 Author's Addresses...............................................7 107 6 Appendix A: Full Copyright Statement.............................8 109 Expires: April 21, 2000 110 1 Add new "output-bin" Job Template attributes 112 1.1 Problem 114 Many printers have multiple output bins, that the job submission 115 protocol permits the submitter to select in which to put the entire job. 117 1.2 Suggested solution 119 Add a single-valued "output-bin" Job Template attribute that captures 120 existing practice. Allow integer values, so that the number of output 121 bins is not constrained. Do not specify internal mechanisms, such as 122 collators. Do specify an externally accessible stacker, since current 123 devices allow a user to select a stacker. Do not make the attribute 124 multi-valued. Add the corresponding Job Template Printer attributes: 125 "output-bin-default" and "output-bin-supported". 127 Note: If it is desired to allow the job submitter to select several 128 output bin mail boxes that can be identified by number or recipient's 129 name, propose a separate multi-valued attribute. Since the destination 130 may also be electronic and have a method associated with it, also allow 131 the uri attribute syntax. Probably call this other attribute "output- 132 destination" with an attribute syntax of (1setOf uri | name). Or 133 possibly the output-destination should be a parameter on the URL? If 134 both "output-bin" and "output-destination" are specified, the job is 135 both printed and sent to the specified destination. This note is 136 provided so that the "output-bin" attribute will not suffer "scope 137 creep" during the review and be changed into "output-destination". 138 Printers have been allowing something like the "output-bin" 139 specification for many years. Supporting something like "output- 140 destination" is just starting to appear now. 142 1.3 Proposed text 144 +===================+======================+======================+ 145 | Job Attribute |Printer: Default Value| Printer: Supported | 146 | | Attribute | Values Attribute | 147 +===================+======================+======================+ 148 | output-bin | output-bin-default | output-bin-supported | 149 | (type2 keyword | | (type2 keyword | | (1setOf ( | 150 | name(MAX) | | name(MAX)) | | type2 keyword | | 151 | integer(1:MAX) | integer(1:MAX) | name(MAX) | | 152 | | | integer(1:MAX))) | 153 +===================+======================+======================+ 155 output-bin (type2 keyword | name(MAX) | integer(1:MAX)) 157 Expires: April 21, 2000 158 This Job Template attribute identifies the device output bin to which 159 the job is to be delivered. There are standard values whose attribute 160 syntax is 'keyword', but there are no standard values whose attribute 161 syntax is 'name' or 'integer'. Output bins whose attribute syntax is 162 'name', if any, are assigned by local administrators (by means outside 163 the scope of IPP/1.0 and IPP/1.1). Output bins whose attribute syntax 164 is 'integer', if any, are assigned by a printer vendor or local 165 administrator to identify a number of similar output bins which are 166 better differentiated by number than by one of the descriptive names 167 defined in the following keyword list. 169 Each output bin may have implementation-dependent properties. Output 170 bins identified by 'integer' or 'name' values MAY possess any of the 171 properties of the output bins identified by the following keywords, 172 depending on implementation. However, each output bin MUST be 173 identified by only one value of any attribute syntax type. Otherwise, 174 clients might be mis-led as to the capabilities of the device when 175 querying the associated Printer object's "output-bin-supported" 176 attribute. 178 Note: Output bin types, such as sorter(s) or collator(s), have not been 179 included in the values of this attribute, since implementations that 180 employ such internal or external bins, determine which to use by the 181 values of other job attributes, such as "finishings", and "copies". 183 When validating a job in a create (or Validate-Job) operation, which 184 subset of the output bins are allowed as a destination for a job MAY 185 depend on the user submitting that job, the user's authentication, and 186 possibly other job attributes, such as "finishings" and "copies". When 187 returning the values of the associated "output-bin-supported" attribute, 188 the values returned MAY depend on the user issuing the Get-Printer- 189 Attributes operation. For example, some implementations MAY omit the 190 'my-mailbox' value for users who do not have a defined mailbox for this 191 IPP Printer object, while others MAY always return 'my-mailbox' to all 192 users even if only supported for certain users. 194 If this IPP Printer object is associated with multiple devices (fan-out) 195 (see [ipp-mod] section 2.1), the value of its "output-bin-supported" 196 attribute is the union of the values supported with duplicates removed. 198 Standard keyword values are: 200 'top': The output-bin that, when facing the device, is best 201 identified as the "top" bin with respect to the device. 203 'middle' The output-bin that, when facing the device, is best 204 identified as the "middle" bin with respect to the device. 206 'bottom' The output-bin that, when facing the device, is best 207 identified as the "bottom" bin with respect to the device. 209 Expires: April 21, 2000 211 'side' The output-bin that, when facing the device, is best 212 identified as the "side" bin with respect to the device. 214 'left' The output-bin that, when facing the device, is best 215 identified as the "left" bin with respect to the device. 217 'right'The output-bin that, when facing the device, is best 218 identified as the "right" bin with respect to the device. 220 'center' The output-bin that, when facing the device, is best 221 identified as the "center" bin with respect to the device. 223 'rear':The output-bin that, when facing the device, is best 224 identified as the "rear" bin with respect to the device. 226 'face-up' The output-bin that is best identified as the "face-up" 227 bin with respect to the device. The selection of this output 228 bin does not cause output to be made face-up; rather this 229 output bin is given this name because a sheet with printing on 230 one-side arrives in the output bin in the face-up position. 232 'face-down. The output-bin that is best identified as the "face-down" 233 bin with respect to the device. The selection of this output 234 bin does not cause output to be made face-down; rather this 235 output bin is given this name because a sheet with printing on 236 one-side arrives in the output bin in the face-down position. 238 'large-capacity' The output-bin that is best identified as the 239 "large-capacity" bin (in terms of the number of sheets) with 240 respect to the device. 242 'stacker-N': The output-bin that is best identified as the 243 stacker with values 'stacker-1', 'stacker-2', .... A stacker 244 is typically used to collate sheets within a single document 245 (not to be confused with collated copies in which document 246 copies are collated within a job - see the description of the 247 'separate-documents-collated-copies' value of the "multiple- 248 document-handling" attribute in [ipp-mod] section 4.2.4). The 249 correspondence between the 'stacker-N' keyword and the actual 250 stacker in the device is implementation-dependent, as is the 251 number of stackers. If this group of values is supported, at 252 least the 'stacker-1' value MUST be supported, unless the 253 system administrator has assigned names or integer values. 255 For client implementations that require distinct keywords for 256 each possible value, say, for localization purposes, it is 257 recommended for interoperability with other vendor's Printer 258 implementations that 'stacker-1' to 'stacker-10' keywords be 259 represented. 261 'mailbox-N':The output-bin that is best identified as a mailbox with 262 values 'mailbox-1', 'mailbox-2', 'mailbox-3', .. Each mailbox 263 is typically used to collect jobs for an individual or group. 264 Whether the mailbox has doors and/or locks or is open, depends 265 on implementation. The correspondence between the 'mailbox-N' 266 keyword and the actual output-bin in the device is 267 implementation-dependent, as is the number of mailboxes. A 268 system administrator MAY be able to assign a name to each 270 Expires: April 21, 2000 271 mailbox in order to make selection of a mailbox easier for the 272 user. If this group of values is supported, at least the 273 'mailbox-1' value MUST be supported, unless the system 274 administrator has assigned names or integer values to 275 mailboxes. 277 For client implementations that require distinct keywords for 278 each possible value, say, for localization purposes, it is 279 recommended for interoperability with other vendor's Printer 280 implementations that 'mailbox-1' to 'mailbox-25' keywords be 281 represented. 283 'my-mailbox': The output-bin that is best identified as 284 functioning like a private "mailbox" with respect to the 285 device. An output-bin functions like a private mailbox if a 286 printer selects the actual output bin using additional 287 implementation-dependent criteria, such as the "authenticated 288 user" (see [ipp-mod] section 8.3) that depends on the user 289 submitting the job. Whether the mailbox has doors and/or 290 locks or is open, depends on implementation, as is the number 291 of mailboxes. 293 2 IANA Considerations 295 This "output-bin" attribute registration proposal will be published by 296 IANA according to the procedures in RFC 2566 [rfc2566] section 6.2 with 297 the following URL: 299 ftp.isi.edu/iana/assignments/ipp/attributes/output-bin.txt 301 3 Internationalization Considerations 303 Normally a client will provide localization of the keywords values of 304 this attribute to the language of the user, but will not localize the 305 name values (see [ipp-mod] section 4.1.2 and 4.1.3). The numeric form 306 for the output bin may be simpler for a client to localize. 308 4 Security Considerations 310 The 'my-mailbox' attribute requires some form of Client Authorization to 311 be really secure. See [ipp-mod] section 8. 313 5 Author's Addresses 315 Tom Hastings 316 Xerox Corporation 317 737 Hawaii St. ESAE 231 318 El Segundo, CA 90245 320 Expires: April 21, 2000 321 Phone: 310-333-6413 322 Fax: 310-333-5514 323 e-mail: hastings@cp10.es.xerox.com 325 Ron Bergman (Editor) 326 Hitachi Koki Imaging Systems, Inc. 327 1757 Tapo Canyon Road 328 Simi Valley, CA 93063-3394 330 Phone: 805-578-4421 331 Fax: 805-578-4001 332 Email: rbergman@dpc.com 334 6 Appendix A: Full Copyright Statement 336 Copyright (C) The Internet Society (1998,1999). All Rights Reserved 338 This document and translations of it may be copied and furnished to 339 others, and derivative works that comment on or otherwise explain it or 340 assist in its implementation may be prepared, copied, published and 341 distributed, in whole or in part, without restriction of any kind, 342 provided that the above copyright notice and this paragraph are included 343 on all such copies and derivative works. However, this document itself 344 may not be modified in any way, such as by removing the copyright notice 345 or references to the Internet Society or other Internet organizations, 346 except as needed for the purpose of developing Internet standards in 347 which case the procedures for copyrights defined in the Internet 348 Standards process must be followed, or as required to translate it into 349 languages other than English. 351 The limited permissions granted above are perpetual and will not be 352 revoked by the Internet Society or its successors or assigns. 354 This document and the information contained herein is provided on an "AS 355 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 356 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 357 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 358 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 359 FITNESS FOR A PARTICULAR PURPOSE. 361 Expires: April 21, 2000