idnits 2.17.1 draft-ietf-ipp-collection-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 9 longer pages, the longest (page 8) being 67 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 ([RFC2565,RFC2566]), 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 31: '...ent specifies an OPTIONAL attribute sy...' RFC 2119 keyword, line 72: '...member attribute MUST be unique within...' RFC 2119 keyword, line 73: '...but MAY be the same as the name of a m...' RFC 2119 keyword, line 75: '...member attribute MUST be different fro...' RFC 2119 keyword, line 82: '...attribute MUST NOT exceed the limit of...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 171 has weird spacing: '...rotocol comm...' == Line 173 has weird spacing: '...ollecti value...' == Line 180 has weird spacing: '...fy-coll job-n...' == Line 192 has weird spacing: '...rd type valu...' == Line 200 has weird spacing: '...rd type valu...' == (4 more instances...) -- 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 (December 8, 1999) is 8899 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: 'RFC2026' is mentioned on line 17, but not defined == Unused Reference: 'ISO-10175' is defined on line 309, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-10175' ** Obsolete normative reference: RFC 2565 (Obsoleted by RFC 2910) ** Obsolete normative reference: RFC 2566 (Obsoleted by RFC 2911) Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Roger deBry 2 IBM Printing Company 3 T. Hastings 4 Xerox Corporation 5 R. Herriot 6 Xerox Corporation 7 December 8, 1999 8 Internet Printing Protocol/1.1: 9 The 'collection' attribute syntax 10 Status of this Memo: 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of [RFC2026]. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed as 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document specifies an OPTIONAL attribute syntax called 32 'collection' for use with the Internet Printing Protocol/1.0 33 (IPP) [RFC2565, RFC2566] and IPP/1.1 [ipp-mod, ipp-pro]. A 34 'collection' is a container holding one or more named values, 35 which are called "member" attributes. A collection allows data 36 to be grouped like a C struct. 38 Table of Contents 40 1 Problem Statement.................................................2 41 2 Solution..........................................................2 42 3 Definition of a collection type...................................2 43 4 Unsupported Values................................................3 44 5 Encoding..........................................................3 45 6 Legacy issues.....................................................5 46 7 IANA Considerations...............................................6 47 8 Internationalization Considerations...............................6 48 9 Security Considerations...........................................6 49 10 References........................................................6 50 11 Author's Addresses................................................7 51 12 APPENDIX A: Example of collection usage...........................7 52 12.1"job-notify" Operation attribute...............................7 53 13 Appendix A: Full Copyright Statement..............................8 55 [Expires: June 8, 2000] 56 1 Problem Statement 58 IPP supports most of the common data structures that are available in 59 programming languages. It lacks a mechanism for grouping several values 60 of different types. The C language uses the struct to solve this 61 problem. 63 2 Solution 65 The IPP 'collection' is a container holding one or more named values 66 (i.e. attributes), which are called member attributes. A collection also 67 has a type name, which identifies the allowed member attributes, as does 68 the name of a C struct or Java class. A collection value is similar to a 69 group, such as an operation group. They both consist of a series of 70 attributes. 72 The name of each member attribute MUST be unique within a collection, 73 but MAY be the same as the name of a member attribute in another 74 collection type. In order to support legacy IPP implementations, the 75 name of a member attribute MUST be different from any attribute in an 76 operation or object unless its semantics are identical to those in the 77 operation or object. 79 Each member attribute can have any syntax type, including collection, 80 and can be either single-valued or multi-valued. The length of a 81 collection value is not limited. However, the length of each member 82 attribute MUST NOT exceed the limit of its attribute syntax. 84 Note: if a collection contains two or more member attributes with the 85 same attribute name, the collection is not well formed. The receiver of 86 such a collection can either treat the collection as a bad value or 87 ignore all but one of the identically named members. 89 3 Definition of a collection type 91 When a specification defines an attribute whose syntax type is 92 'collection' or '1setOf collection', it must define following aspects of 93 the collection. 95 1.the name of the collection type, whose characters are the same as 96 those for a keyword. 98 2.the following information about each member attribute: 100 a) its name, which is a keyword like all attributes. It must be unique 101 within the collection type. It must also be unique with respect to 102 operation and object attributes unless its semantics are identical 103 to those in the operation or object. 105 [Expires: June 8, 2000] 107 b) its syntax type, which may be any IPP syntax type, include 108 collection. If the syntax type starts with "1setOf", the member 109 attribute is multi-valued. 111 c) its allowed values, either enumerated explicitly or specified by 112 the values of a referenced attribute. 114 d) whether it MUST be or MAY be supplied by a client. 116 e) its default value if a client MAY supply it. The default value can 117 be stated explicitly or can come from a specified attribute. 119 f) whether it MUST be or MAY be supported by the printer. 121 g) its semantics 123 4 Unsupported Values 125 The rules for returning an unsupported collection attribute are an 126 extension to the current rules. 128 1.If a collection contains unrecognized, unsupported member 129 attributes and/or conflicting value, the attribute returned in 130 the Unsupported Group is a collection containing the 131 unrecognized, unsupported member attributes, and/or conflicting 132 values. The unrecognized member attributes have an out-of-band 133 value of unsupported. The unsupported member attributes and 134 conflicting values have their unsupported values. 136 5 Encoding 138 This section defines the encoding of a collection syntax type. A 139 collection is encoded by using three new tags: 141 Tag name Tag Meaning 142 value 144 beginCollection 0x34 Begin the named collection. 146 endCollection 0x37 End the named collection. 148 sepCollection 0x38 Separate two collections of a multi- 149 valued attribute 151 A collection value is encoded as a sequence of attribute values 152 preceded by a beginCollection value and followed by an endCollection 153 value. The value field of a beginCollection and an endCollection both 154 contain the name of the collection type, which is a string of ASCII 155 characters. These values allow a receiver to optionally match an 156 endCollection value with a beginCollection. A 1setOf collection is 157 encoded using the rules for 1setOf and collection, except that adjacent 158 endCollection and beginCollection values MUST be combined into a single 160 [Expires: June 8, 2000] 161 sepCollection value. Its value field contains the collection type. In a 162 1setOf collection, the endCollection value marks the end of last 163 collection in the 1setOf collection. For legacy reasons, the name field 164 for the endCollection and sepCollection must be non-empty. The name is 165 arbitrarily assigned to be "c". 167 The following example is written in the style of the IPP/1.1 "Encoding 168 and Transport" document [ipp-pro]. The following example is for a job- 169 notify attribute containing a set of 2 collections. 171 Octets Symbolic Protocol comments 172 Value field 173 0x34 beginCollecti value-tag Beginning of the collection 174 on 175 0x000a name- 176 length 177 job-notify job-notify Name 178 0x000f Value- 179 length 180 job-notify-coll job-notify- Value Collection type 181 coll 182 0x45 uri type value-tag "notify-recipients" 183 attribute 184 0x0010 name- 185 length 186 notify- notify- Name 187 recipient recipient 188 0x0013 value- 189 length 190 ipp- Value 191 notify:port=700 192 0x44 keyword type value-tag "notify-event-groups" 193 attribute 194 0x000d name- 195 length 196 notify-events Name 197 0x0d value- 198 length 199 job-completed Value 200 0x44 keyword type value-tag 2nd "notify-event-groups" 201 attribute 202 0x0000 name- 0 length means next 203 length multiple value 204 0x0011 value- 205 length 206 job-state- job- Value 207 changed completion 208 0x38 sepCollection value-tag Separator between 209 collection values 210 0x0001 name- 211 length 212 c Name Non-empty for legacy 214 [Expires: June 8, 2000] 215 Octets Symbolic Protocol comments 216 Value field 217 0x000f value- 218 length 219 job-notify-coll Value Matches value of 220 beginCollection 221 0x45 uri type value-tag "notify-recipients" 222 attribute 223 0x0010 name- 224 length 225 notify- Name 226 recipient 227 0x0014 value- 228 length 229 mailto:smith@fo Value 230 o.com 231 0x44 keyword type value-tag "notify-event-groups" 232 attribute 233 0x000d name- 234 length 235 notify-events Name 236 0x0d value- 237 length 238 job-completed Value 239 0x37 endCollection value-tag End of last collection 240 0x0001 name- 241 length 242 c Name Non-empty for legacy 243 0x000f value- 244 length 245 job-notify-coll Value Matches value of 246 beginCollection 248 6 Legacy issues 250 The encoding has been designed to work with IPP/1.0 and IPP/1.1 251 implementations. An IPP/1.0 or IPP/1.1 receiver will treat the three new 252 syntax types, beginCollection, endCollection and sepCollection as 253 unrecognized syntax types. A legacy implementation is expected to 254 behave as follows. 256 A beginCollection value appears to be an attribute with an unsupported 257 value. 259 The member attributes that follow the beginCollection appear to be 260 normal attributes within their group (e.g. normal for the operation 261 attributes group). If an attribute has the same name as an attribute 262 allowed in the group, it as a recognized member of the group (e.g. as a 263 normal operation attribute). 265 [Expires: June 8, 2000] 266 An endCollection value appears to be an attribute with an unsupported 267 value and unrecognized name "c". The same is true for a sepCollection 268 value. 270 7 IANA Considerations 272 This attribute syntax will be registered with IANA after the WG approves 273 its specification according to the procedures for extension of the 274 IPP/1.1 Model and Semantics [ipp-mod] and after IPP becomes a proposed 275 IETF standard. 277 8 Internationalization Considerations 279 This attribute syntax by itself has no impact on internationalization. 280 However, the member attributes that are subsequently defined for use in 281 a collection may have internationalization considerations, as may any 282 attribute. 284 9 Security Considerations 286 This attribute syntax causes no more security concerns than any other 287 attribute syntax. It is only the attributes that are subsequently 288 defined to use this or any other attribute syntax that may have security 289 concerns, depending on the semantics of the attribute. 291 10 References 293 [ipp-mod] 294 Isaacson, S., deBry, R., Hastings, T., Herriot, R., Powell, P., 295 "Internet Printing Protocol/1.1: Model and Semantics" draft-ietf- 296 ipp-model-v11-04.txt, June 23, 1999. 298 [ipp-not] 299 Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M., 300 Bergman, R. " Internet Printing Protocol/1.0 & 1.1: IPP Event 301 Notification Specification" draft-ietf-ipp-not-spec-01.doc, work in 302 progress, October 10, 1999. 304 [ipp-pro] 305 Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing 306 Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11- 307 03.txt, June 23, 1999. 309 [ISO-10175] 310 ISO/IEC 10175 Document Printing Application (DPA), June 1996. 312 [RFC2565] 313 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 314 Protocol/1.0: Encoding and Transport", RFC 2565, April 1999. 316 [Expires: June 8, 2000] 318 [RFC2566] 319 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 320 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, 321 April 1999. 323 11 Author's Addresses 325 Tom Hastings 326 Xerox Corporation 327 737 Hawaii St. ESAE 231 328 El Segundo, CA 90245 330 Phone: 310-333-6413 331 Fax: 310-333-5514 332 e-mail: hastings@cp10.es.xerox.com 334 Robert Herriot 335 Xerox Corp. 336 3400 Hill View Ave, Building 1 337 Palo Alto, CA 94304 339 Phone: 650-813-7696 340 Fax: 650-813-6860 341 e-mail: robert.herriot@pahv.xerox.com 343 Roger deBry 344 Utah Valley State College 345 Orem, UT 84058 347 Phone: (801) 222-8000 348 EMail: debryro@uvsc.edu 350 12 APPENDIX A: Example of collection usage 352 This section describes one collection Job Template example. 354 12.1"job-notify" Operation attribute 356 The following example illustrates the definition of a collection 357 attribute for the "job-notify" operation attribute. Each column of the 358 table corresponds to information that is required for member attributes. 359 Only the semantics have been omitted. 361 1.collection type: "job-notify-coll" 363 2.members of the collection 365 [Expires: June 8, 2000] 366 Member name Member type Supported- Client Printer 367 values supplied/ support 368 default 370 notify- uri notify- MUST MUST 371 recipient recipient- 372 schemes- 373 supported 375 notify-events 1setOf type2 notify-events- notify-events- MUST 376 keyword supported default 378 subscriber- octetString(63) octetString> 381 notify- charset charset- attributes- MAY 382 attributes- supported charset in 383 charset operation 384 group 386 notify- naturalLanguage generated- attributes- MAY 387 attributes- natural- natural- 388 natural- language- language in 389 language supported operation 390 group 392 Note: for the "client supplied/default" column, the default is specified 393 if the client MAY supply it. 395 13 Appendix A: Full Copyright Statement 397 Copyright (C) The Internet Society (1998,1999). All Rights Reserved 399 This document and translations of it may be copied and furnished to 400 others, and derivative works that comment on or otherwise explain it or 401 assist in its implementation may be prepared, copied, published and 402 distributed, in whole or in part, without restriction of any kind, 403 provided that the above copyright notice and this paragraph are included 404 on all such copies and derivative works. However, this document itself 405 may not be modified in any way, such as by removing the copyright notice 406 or references to the Internet Society or other Internet organizations, 407 except as needed for the purpose of developing Internet standards in 408 which case the procedures for copyrights defined in the Internet 409 Standards process must be followed, or as required to translate it into 410 languages other than English. 412 The limited permissions granted above are perpetual and will not be 413 revoked by the Internet Society or its successors or assigns. 415 This document and the information contained herein is provided on an "AS 416 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 417 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 418 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 419 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 420 FITNESS FOR A PARTICULAR PURPOSE. 422 [Expires: June 8, 2000] 424 [Expires: June 8, 2000]